linux-kernel - Re: [PATCH 9/9] u64_stat: Remove the obsolete fetch

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: <20220818104505.010ff950@kernel.org>
Date:   Thu, 18 Aug 2022 10:45:05 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>, netdev@...r.kernel.org
Subject: Re: [PATCH 9/9] u64_stat: Remove the obsolete fetch_irq() variants

On Thu, 18 Aug 2022 18:59:00 +0200 Sebastian Andrzej Siewior wrote:
> On 2022-08-18 09:02:00 [-0700], Jakub Kicinski wrote:
> > No ack, I'd much rather you waited for after the next merge window 
> > and queued this refactoring to net-next. Patch 9 is changing 70
> > files in networking. Unless I'm missing something and this is time
> > sensitive.  
> 
> It started with the clean up of the mess that has been made in the merge
> and then it went on a little.
> 
> Any opinion on 8/9? It could wait for the next merge window if you want
> to avoid a feature branch to pull from.

A question of priority, hard for me to judge how urgent any of it is.
But practically speaking the chances of a conflict on that one header
are pretty small, so ack if needed.

> Regarding 9/9. This is a clean up, which is possible after 8/9. It can
> definitely be applied later.
> I assume you want only see the networking bits so I would split the
> other subsystem out. I guess instead the big net patch I split them on
> per driver vendor basis + net/ subsys?

Oh, don't care for per vendor split on a big refactoring like that.
You can split out the SPI patch and maybe BPF, the rest can be one 
big chunk AFAICT.

BTW, I have a hazy memory of people saying they switched to the _irq()
version because it reduced the number of retries significantly under
traffic. Dunno how practical that is but would you be willing to scan
the git history to double check that's not some of the motivation?