linux-kernel - Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock

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:   Sat, 6 Apr 2019 07:07:14 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kirill Smelkov <kirr@...edi.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Yongzhi Pan <panyongzhi@...il.com>,
        Jonathan Corbet <corbet@....net>,
        David Vrabel <david.vrabel@...rix.com>,
        Juergen Gross <jgross@...e.com>,
        Miklos Szeredi <miklos@...redi.hu>, Tejun Heo <tj@...nel.org>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Arnd Bergmann <arnd@...db.de>, Christoph Hellwig <hch@....de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Julia Lawall <Julia.Lawall@...6.fr>,
        Nikolaus Rath <Nikolaus@...h.org>,
        Han-Wen Nienhuys <hanwen@...gle.com>
Subject: Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so
 that read and write can run simultaneously without deadlock

On Tue, Mar 26, 2019 at 12:20 PM Kirill Smelkov <kirr@...edi.com> wrote:
>
> Commit 9c225f2655 (vfs: atomic f_pos accesses as per POSIX) added locking for
> file.f_pos access and in particular made concurrent read and write not possible
> [...]

Ok, I have applied this patch - but this patch only - as a
well-researched preparatory patch.

The actual conversion patch looks fine to me too, and I see a few
acks, but I think I'd like to see it during a merge window just
because it's large and does significant changes, while this one is
purely preparatory.

Al, comments?

One small note: please don't use lkml.org references since they tend
to be slow and flaky - use lore.kernel.org instead. Also, fix your git
config to use 12-character git hashes (best done by just removing the
explicit hash size entirely, and letting modern git shorten hashes
appropriately automatically).

                  Linus