On Sun, Sep 24, 2023 at 5:27 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Sun, Sep 24, 2023 at 02:47:42PM +0300, Amir Goldstein wrote: > > Since you joined the discussion, you have the opportunity to agree or > > disagree with our decision to change readahead() to ESPIPE. > > Judging by your citing of lseek and posix_fadvise standard, > > I assume that you will be on board? > > I'm fine with returning ESPIPE (it's like ENOTTY in a sense). but > that's not what kbuild reported: kbuild report is from v1 patch that was posted to the list this is not the patch (v2) that is applied to vfs.misc and has been in linux-next for a few days. Oliver, Can you say the failure (on socket) is reproduced on https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.misc? I would expect the pipe test to fail for getting ESPIPE but according to Reuben the socket test does not fail. > > readahead01.c:62: TFAIL: readahead(fd[0], 0, getpagesize()) succeeded > > 61: fd[0] = SAFE_SOCKET(AF_INET, SOCK_STREAM, 0); > 62: TST_EXP_FAIL(readahead(fd[0], 0, getpagesize()), EINVAL); > > I think LTP would report 'wrong error code' rather than 'succeeded' > if it were returning ESPIPE. > > I'm not OK with readahead() succeeding on a socket. Agree. Reuben reported that this does not happen on v2 although I cannot explain why it was reported on v1... > I think that should > also return ESPIPE. I think posix_fadvise() should return ESPIPE on a > socket too, but reporting bugs to the Austin Group seems quite painful. > Perhaps somebody has been through this process and can do that for us? > This is Reuben's first kernel patch. Let's agree that changing the standard of posix_fadvise() for socket is beyond the scope of his contribution :) Thanks, Amir.
