linux-kernel - Re: [PATCH v6 01/34] vfs: Unconditionally set IOCB_WRITE in call_write

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: <Y8jYrahu45kkCRlq@infradead.org>
Date:   Wed, 18 Jan 2023 21:44:13 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Christoph Hellwig <hch@...radead.org>,
        David Howells <dhowells@...hat.com>,
        Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
        linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
        Jeff Layton <jlayton@...nel.org>,
        Logan Gunthorpe <logang@...tatee.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 01/34] vfs: Unconditionally set IOCB_WRITE in
 call_write_iter()

On Wed, Jan 18, 2023 at 10:11:45PM +0000, Al Viro wrote:
> On Mon, Jan 16, 2023 at 11:52:43PM -0800, Christoph Hellwig wrote:
> 
> > This doesn't remove the existing setting of IOCB_WRITE, and also
> > feelds like the wrong place.
> > 
> > I suspect the best is to:
> > 
> >  - rename init_sync_kiocb to init_kiocb
> >  - pass a new argument for the destination to it.  I'm not entirely
> >    sure if flags is a good thing, or an explicit READ/WRITE might be
> >    better because it's harder to get wrong, even if a the compiler
> >    might generate worth code for it.
> >  - also use it in the async callers (io_uring, aio, overlayfs, loop,
> >    nvmet, target, cachefs, file backed swap)
> 
> Do you want it to mess with get_current_ioprio() for those?  Looks
> wrong...

We want to be consistent for sync vs async submission.  So I think yes,
we want to do the get_current_ioprio for most of them, exceptions
beeing aio and io_uring - those could use a __init_iocb or
init_iocb_ioprio variant that passs in the explicit priority if we want
to avoid the call if it would be overriden later.