linux-kernel - Re: [PATCH v2] fs-writeback: writeback_sb_inodes：Recalculate 'wrote' according skipped pages

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: <20220419081624.GM2731@worktop.programming.kicks-ass.net>
Date:   Tue, 19 Apr 2022 10:16:24 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Zhihao Cheng <chengzhihao1@...wei.com>,
        Ingo Molnar <mingo@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Christoph Hellwig <hch@....de>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        yukuai3@...wei.com
Subject: Re: [PATCH v2] fs-writeback: writeback_sb_inodes：Recalculate 'wrote'
 according skipped pages

On Mon, Apr 18, 2022 at 06:30:16PM -0600, Jens Axboe wrote:
> On 4/18/22 6:19 PM, Linus Torvalds wrote:
> > On Mon, Apr 18, 2022 at 3:12 PM Jens Axboe <axboe@...nel.dk> wrote:
> >>
> >> Hmm yes. But doesn't preemption imply a full barrier? As long as we
> >> assign the plug at the end, we should be fine. And just now looking that
> >> up, there's even already a comment to that effect in blk_start_plug().
> >> So barring any weirdness with that, maybe that's the solution.
> > 
> > My worry is more about the code that adds new cb_list entries to the
> > plug, racing with then some random preemption event that flushes the
> > plug.
> > 
> > preemption itself is perfectly fine wrt any per-thread data updates
> > etc, but if preemption then also *changes* the data that is updated,
> > that's not great.
> > 
> > So that worries me.
> 
> Yes, and the same is true for eg merge traversal. We'd then need to
> disable preempt for that as well...

One is only supposed to disable preemption for short and bounded things,
otherwise we'll get people complaining their latencies are going bad.