All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [git pull] vfs.git pile 2 - lseek stuff
Date: Mon, 1 Aug 2022 21:31:30 +0100	[thread overview]
Message-ID: <Yug4Is18ZrZ3fEAy@ZenIV> (raw)

	Jason's lseek series.  One note: after that no_llseek is defined
to NULL; boilerplate initializers ought to be removed, but that's better
done at the end of merge window - fewer conflicts that way.  Could you run

git grep -l -w no_llseek | grep -v porting.rst | while read i; do
	sed -i '/\<no_llseek\>/d' $i
done

just before -rc1 to take that boilerplate out?

The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3:

  Linux 5.19-rc2 (2022-06-12 16:11:37 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-work.lseek

for you to fetch changes up to 868941b14441282ba08761b770fc6cad69d5bdb7:

  fs: remove no_llseek (2022-07-16 09:19:47 -0400)

----------------------------------------------------------------
	Saner handling of "lseek should fail with ESPIPE" - gets rid of
magical no_llseek thing and makes checks consistent.  In particular,
ad-hoc "can we do splice via internal pipe" checks got saner (and
somewhat more permissive, which is what Jason had been after, AFAICT)

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

----------------------------------------------------------------
Jason A. Donenfeld (6):
      fs: clear or set FMODE_LSEEK based on llseek function
      fs: do not compare against ->llseek
      dma-buf: remove useless FMODE_LSEEK flag
      vfio: do not set FMODE_LSEEK flag
      fs: check FMODE_LSEEK to control internal pipe splicing
      fs: remove no_llseek

 Documentation/filesystems/porting.rst |  8 ++++++++
 drivers/dma-buf/dma-buf.c             |  1 -
 drivers/gpu/drm/drm_file.c            |  3 +--
 drivers/vfio/vfio.c                   |  2 +-
 fs/coredump.c                         |  4 ++--
 fs/file_table.c                       |  2 ++
 fs/open.c                             |  2 ++
 fs/overlayfs/copy_up.c                |  3 +--
 fs/read_write.c                       | 17 +++--------------
 fs/splice.c                           | 10 ++++------
 include/linux/fs.h                    |  2 +-
 kernel/bpf/bpf_iter.c                 |  3 +--
 12 files changed, 26 insertions(+), 31 deletions(-)

             reply	other threads:[~2022-08-01 20:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 20:31 Al Viro [this message]
2022-08-03 19:00 ` [git pull] vfs.git pile 2 - lseek stuff pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yug4Is18ZrZ3fEAy@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=Jason@zx2c4.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.