linux-kernel - Re: [GIT PULL] AFFS update for 6.9

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]

Date: Tue, 12 Mar 2024 22:22:59 +0100
From: David Sterba <dsterba@...e.cz>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Sterba <dsterba@...e.com>, linux-kernel@...r.kernel.org,
	vbabka@...e.cz
Subject: Re: [GIT PULL] AFFS update for 6.9

On Tue, Mar 12, 2024 at 01:02:47PM -0700, Linus Torvalds wrote:
> On Mon, 11 Mar 2024 at 12:37, David Sterba <dsterba@...e.com> wrote:
> >
> > please pull one change to AFFS that removes use of SLAB_MEM_SPREAD,
> > which is going to be removed from MM code.
> 
> I've pulled this, but I don't really see the point in removing these
> one by one like this.
> 
> SLAB_MEM_SPREAD is already a no-op, the MM people could just do a
> coccinelle thing to remove it everywhere.

That's of course valid and was also suggested as an option. However I
would prefer to let actively maintained code pick the patches first
and then do the rest as sed or coccinelle script. This usually leaves
whitespace damage behind and not everybody takes the care to fix it
manually.

I agree that for AFFS it's a bit too much for just one change but I did
not realize that as I happened to do the same change for btrfs.

> I think you could do 90% even just using a few variations of 'sed', eg
> variations on
> 
>    git grep -l 'SLAB_MEM_SPREAD' |
>         xargs sed -i 's/SLAB_MEM_SPREAD *|//'
> 
>    git grep -l 'SLAB_MEM_SPREAD' |
>         xargs sed -i 's/| *SLAB_MEM_SPREAD//'
> 
> and then some manual fixups for (a) whitespace cleanup of the result
> and (b) the couple of cases where it wasn't a bitwise or into other
> fields (or where the bitwise or was on a different line)
> 
> And then you'd end up with something like the attached.

I don't know if MM people have such change queued but you could apply
the diff at the end of 6.9, the formatting seems OK.