On Thu, Sep 7, 2023 at 8:44 AM Reuben Hawkins <reubenhwk@xxxxxxxxx> wrote: > > Hi, > > I found that this change broke readahead for block devices. I can change my application to call posix_fadvise easily enough, but would like to fix readahead for block devices nonetheless. Is there any reason why readahead should *not* work on block devices? Before this commit, 3d8f7615319b2bca87a4815e13787439e3339a93, readahead succeeded on block devices. Wow. It has been broken for 5 years and nobody complained about it. I guess it is not common for people to readahead from blockdev, but this does not justify the regression. TBH, I am not really sure why I put the S_ISREG() limitation in readahead(). Judging by my earlier comment in v4 revision [1], I probably added it to preserve -EINVAL value for readahead on pipes - generic_fadvise() returns -ESPIPE for POSIX_FADV_WILLNEED on pipes. I would either replace !S_ISREG() with S_ISFIFO() and explain the reason for this check in the comment above, or remove !S_ISREG() altogether. It will probably take at least 5 years until someone notices the change -EINVAL => -ESPIPE if at all. > > I've never submitted a patch to the kernel. There's a first time for everything :) > Can you advise me where I should send the patch and who should be copied? > Send the patch to the relevant mailing list: linux-fsdevel@xxxxxxxxxxxxxxx found in PAGE CACHE and FILESYSTEMS (VFS and infrastructure) entries of MAINTAINERS file, CC the PAGE CACHE and VFS maintainers and the authors of the patch (Miklos+myself). What & how to send the patch is more important. See submitting-patches doc [2]. Let me know if you have any questions. Thanks, Amir. [1] https://lore.kernel.org/linux-unionfs/1535443233-31068-1-git-send-email-amir73il@xxxxxxxxx/ [2] https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst
