linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Linux regression tracking (Thorsten Leemhuis)" <regressions@leemhuis.info>
To: Bagas Sanjaya <bagasdotme@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
	Linux Regressions <regressions@lists.linux.dev>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	vladbu@nvidia.com
Subject: Re: Fwd: Memleaks in offset_ctx->xa (shmem)
Date: Tue, 24 Oct 2023 16:18:44 +0200	[thread overview]
Message-ID: <f21c7064-dac1-4667-96c6-0d85368300ca@leemhuis.info> (raw)
In-Reply-To: <429b452c-2211-436a-9af7-21332f68db7d@gmail.com>

On 24.10.23 09:55, Bagas Sanjaya wrote:
> 
> I notice a regression report on Bugzilla [1]. Quoting from it:
> 
>> We have been getting memleaks in offset_ctx->xa in our networking tests:
>>
>> unreferenced object 0xffff8881004cd080 (size 576):
> [...]
> #regzbot introduced: 6faddda69f623d https://bugzilla.kernel.org/show_bug.cgi?id=218039
> #regzbot title: stable offsets directory operation support triggers offset_ctx->xa memory leak

Thx for adding this to regzbot.

Bagas, FWIW, before doing so you in the future might want to search lore
for an abbreviated commit-id with a wildcard (e.g.
https://lore.kernel.org/all/?q=6faddda6* ) and the bugzilla url (e.g.
https://lore.kernel.org/all/?q=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D218039).
Because then in this case you would have noticed that this was already
discussed on the lists and Chuck asked to bring it to bugzilla for
further tracking, so forwarding this likely was not worth it:
https://lore.kernel.org/all/87ttqhq0i7.fsf@nvidia.com/

OTOH I wonder if what Chuck asked for was wise: '''Looks like "Memory
Management / Other" is appropriate for shmem, and Hugh or Andrew can
re-assign ownership to me.'''

Not sure if Hugh or Andrew actually do anything like that. I doubt that,
but maybe I'm wrong. Ahh, the joys of our bugzilla instance that many
core developers avoid... (FWIW, I don't blame anyone for that, I
understand why it's like that; but it complicated things...).

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

P.S., FWIW:

#regzbot monitor: https://lore.kernel.org/all/87y1g9xjre.fsf@nvidia.com/


  reply	other threads:[~2023-10-24 14:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24  7:55 Bagas Sanjaya
2023-10-24 14:18 ` Linux regression tracking (Thorsten Leemhuis) [this message]
2023-10-25  0:01   ` Bagas Sanjaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f21c7064-dac1-4667-96c6-0d85368300ca@leemhuis.info \
    --to=regressions@leemhuis.info \
    --cc=akpm@linux-foundation.org \
    --cc=bagasdotme@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=regressions@lists.linux.dev \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vladbu@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox