linux-kernel - Re: [PATCH v3 1/3] splice: always fsnotify_access(in), fsnotify

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: <7mlwx7lqzzyrqwqu3kcgnhxgittvmz44d3dlcfaifpnljsuxa2@25c7ypaofxy5>
Date:   Tue, 27 Jun 2023 22:13:50 +0200
From:   Ahelenia Ziemiańska 
        <nabijaczleweli@...ijaczleweli.xyz>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jan Kara <jack@...e.cz>,
        Chung-Chiang Cheng <cccheng@...ology.com>, ltp@...ts.linux.it
Subject: Re: [PATCH v3 1/3] splice: always fsnotify_access(in),
 fsnotify_modify(out) on success

On Tue, Jun 27, 2023 at 09:10:09PM +0300, Amir Goldstein wrote:
> On Tue, Jun 27, 2023 at 7:55 PM Ahelenia Ziemiańska
> <nabijaczleweli@...ijaczleweli.xyz> wrote:
> > @@ -1209,18 +1204,20 @@ long do_splice(struct file *in, loff_t *off_in, struct file *out,
> >
> >                 ret = splice_file_to_pipe(in, opipe, &offset, len, flags);
> >
> > -               if (ret > 0)
> > -                       fsnotify_access(in);
> > -
> >                 if (!off_in)
> >                         in->f_pos = offset;
> >                 else
> >                         *off_in = offset;
> > +       } else
> > +               return -EINVAL;
> >
> > -               return ret;
> > -       }
> > +       if (ret > 0)
> > +               fsnotify_modify(out);
> > +noaccessout:
> > +       if (ret > 0)
> > +               fsnotify_access(in);
> >
> As I wrote, I don't like this special case.
> I prefer that we generate double IN_MODIFY than
> having to maintain unreadable code.
> 
> Let's see what Jan has to say about this.
Yes, in principle I definitely agree, but I don't know what the official
policy is on (effectively-)spurious/duplicate events; neither the kernel
documentation nor the manual speak to the reliability of the signal,
so I defaulted to the variant I thought to be correcter, if filthy.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)