linux-kernel - Re: [regression, bisected] Bug 216738 - Adding O_APPEND to O_RDWR with fcntl(fd, F

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] [day] [month] [year] [list]

Message-ID: <687f308d-b221-9c2d-24c1-6a4417d27843@leemhuis.info>
Date:   Fri, 25 Nov 2022 08:38:09 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        "Christian Brauner (Microsoft)" <brauner@...nel.org>,
        Pierre Labastie <pierre.labastie@...f.fr>,
        linux-unionfs@...r.kernel.org
Subject: Re: [regression, bisected] Bug 216738 - Adding O_APPEND to O_RDWR with fcntl(fd, F_SETFL) does not work on overlayfs

On 24.11.22 18:03, Al Viro wrote:
> On Thu, Nov 24, 2022 at 04:47:56PM +0100, Thorsten Leemhuis wrote:
> [...]

Al: thx for fixing this!

> I could pick it in vfs.git #fixes, or Miklos could put it through his tree.
> Miklos, which way would you prefer that to go?
>
> [PATCH] update ->f_iocb_flags when ovl_change_flags() modifies ->f_flags
> 
> ovl_change_flags() is an open-coded variant of fs/fcntl.c:setfl() and it got
> missed by 164f4064ca81e "keep iocb_flags() result cached in struct file";
> the same change applies there.
> 
> Reported-by: Pierre Labastie <pierre.labastie@...f.fr>

Miklos, if you pick this up, could you for the sake of future code
archeologists please add this here:

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216738

tia! To explain: Linus[1] and others considered proper link tags in
cases like this important, as they allow anyone to look into the
backstory weeks or years from now. That why they should be placed here,
as outlined by the documentation[2]. I care personally, because these
tags make my regression tracking efforts a whole lot easier, as they
allow my tracking bot 'regzbot' to automatically connect reports with
patches posted or committed to fix tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/

[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)