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:   Thu, 3 Aug 2023 16:49:54 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Petr Mladek <pmladek@...e.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        John Ogness <john.ogness@...utronix.de>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking
 in do_write_seqcount_begin_nested()

On Thu 03-08-23 22:18:10, Tetsuo Handa wrote:
> On 2023/07/31 23:25, Michal Hocko wrote:
> > On Sat 29-07-23 20:05:43, Tetsuo Handa wrote:
> >> On 2023/07/29 14:31, Tetsuo Handa wrote:
> >>> On 2023/07/28 0:10, Sebastian Andrzej Siewior wrote:
> >>>> On 2023-06-28 21:14:16 [+0900], Tetsuo Handa wrote:
> >>>>>> Anyway, please do not do this change only because of printk().
> >>>>>> IMHO, the current ordering is more logical and the printk() problem
> >>>>>> should be solved another way.
> >>>>>
> >>>>> Then, since [PATCH 1/2] cannot be applied, [PATCH 2/2] is automatically
> >>>>> rejected.
> >>>>
> >>>> My understanding is that this patch gets applied and your objection will
> >>>> be noted.
> >>>
> >>> My preference is that zonelist_update_seq is not checked by !__GFP_DIRECT_RECLAIM
> >>> allocations, which is a low-hanging fruit towards GFP_LOCKLESS mentioned at
> >>> https://lkml.kernel.org/r/ZG3+l4qcCWTPtSMD@dhcp22.suse.cz and
> >>> https://lkml.kernel.org/r/ZJWWpGZMJIADQvRS@dhcp22.suse.cz .
> >>>
> >>> Maybe we can defer checking zonelist_update_seq till retry check like below,
> >>> for this is really an infrequent event.
> >>>
> >>
> >> An updated version with comments added.
> > 
> > Seriously, don't you see how hairy all this is? And for what? Nitpicking
> > something that doesn't seem to be a real problem in the first place?
> 
> Seriously, can't you find "zonelist_update_seq is not checked by !__GFP_DIRECT_RECLAIM
> allocations, which is a low-hanging fruit towards GFP_LOCKLESS" !?

I do not think we have concluded that we want to support GFP_LOCKLESS.
This might be trivial straightforward now but it imposes some constrains
for future maintainability. So far we haven't heard about many usecases
where this would be needed and a single one is not sufficient IMHO.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ