linux-kernel - Re: [RFC][PATCH] cifs: Fix cifs_writepages

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: <2675059.1677504046@warthog.procyon.org.uk>
Date:   Mon, 27 Feb 2023 13:20:46 +0000
From:   David Howells <dhowells@...hat.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     dhowells@...hat.com,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Steve French <stfrench@...rosoft.com>,
        Vishal Moola <vishal.moola@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>, Paulo Alcantara <pc@....nz>,
        Huang Ying <ying.huang@...el.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Xin Hao <xhao@...ux.alibaba.com>, linux-mm@...ck.org,
        mm-commits@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] cifs: Fix cifs_writepages_region()

Matthew Wilcox <willy@...radead.org> wrote:

> On Fri, Feb 24, 2023 at 12:16:49PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 24, 2023 at 12:14 PM David Howells <dhowells@...hat.com> wrote:
> > >
> > > Then why do we have to wait for PG_writeback to complete?
> > 
> > At least for PG_writeback, it's about "the _previous_ dirty write is
> > still under way, but - since PG_dirty is set again - the page has been
> > dirtied since".
> > 
> > So we have to start _another_ writeback, because while the current
> > writeback *might* have written the updated data, that is not at all
> > certain or clear.
> 
> also, we only have a writeback bit, not a writeback count.  And when
> the current writeback completes, it'll clear that bit.  We're also
> being kind to our backing store and not writing to the same block twice
> at the same time.

It's not so much being kind to the backing store, I think, as avoiding the
possibility that the writes happen out of order.

> > I'm not sure what the fscache rules are.
> 
> My understanding is that the fscache bit is set under several
> circumstances, but if the folio is dirty _and_ the fscache bit
> is set, it means the folio is currently being written to the cache
> device.  I don't see a conflict there; we can write to the backing
> store and the cache device at the same time.

The dirty bit is nothing to do with it.  If the fscache bit is set, then the
page is currently being written to the cache - and we need to wait before
starting another write.

Sometimes we start a write to the cache from a clean page (e.g. we just read
it from the server) and sometimes we start a write to the cache from
writepages (e.g. the data is dirty and we're writing it to the server as
well).

Things will become more 'interesting' should we ever get around to
implementing disconnected operation.  Then we might end up staging dirty data
through the cache.

David