linux-kernel - Re: [PATCH 1/7] ext4: avoid buffer_head leak in ext4_mark_inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240815144905.GA6039@frogsfrogsfrogs>
Date: Thu, 15 Aug 2024 07:49:05 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Kemeng Shi <shikemeng@...weicloud.com>
Cc: Markus Elfring <Markus.Elfring@....de>, linux-ext4@...r.kernel.org,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Theodore Ts'o <tytso@....edu>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/7] ext4: avoid buffer_head leak in ext4_mark_inode_used

On Thu, Aug 15, 2024 at 09:17:10PM +0800, Kemeng Shi wrote:
> 
> 
> on 8/15/2024 5:55 PM, Markus Elfring wrote:
> >> Release inode_bitmap_bh from ext4_read_inode_bitmap in
> >> ext4_mark_inode_used to avoid buffer_head leak.
> >> By the way, remove unneeded goto for invalid ino when inode_bitmap_bh
> >> is NULL.
> > 
> > 1. I suggest to split such changes into separate update steps.
> >    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.11-rc3#n81
> It's acceptable to me, but I'm not sure if it worth separate patches
> to others. I will do separate in next version if no person is against
> this.

No, that suggestion is stupid.  There's no reason to generate even more
patches for a three line fix, it's very obvious that you're fixing a
missing resource release and rearranging the first error out
accordingly.

--D

> > 2. How do you think about to add any tags (like “Fixes” and “Cc”) accordingly?
> > 
> > 3. Would you like to append parentheses to any function names?
> Thanks for remind me of these. I will improve the series in next
> version.
> 
> Thanks,
> Kemeng
> > 
> > Regards,
> > Markus
> > 
> 
>