Nobody checks the error flag on orangefs folios, so stop setting and
clearing it.  We can also use folio_end_read() to simplify
orangefs_read_folio().

Cc: Martin Brandenburg <martin@omnibond.com>
Cc: devel@lists.orangefs.org
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Link: https://lore.kernel.org/r/20240530202110.2653630-11-willy@infradead.org
Tested-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>

Pull orangefs update from Mike Marshall:
 "Fix out-of-bounds fsid access.

  Small fix to quiet warnings from string fortification helpers,
  suggested by Arnd Bergmann"

* tag 'for-linus-6.10-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
  orangefs: fix out-of-bounds fsid access

Arnd Bergmann sent a patch to fsdevel, he says:

"orangefs_statfs() copies two consecutive fields of the superblock into
the statfs structure, which triggers a warning from the string fortification
helpers"

Jan Kara suggested an alternate way to do the patch to make it more readable.

I ran both ideas through xfstests and both seem fine. This patch
is based on Jan Kara's suggestion.

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.

There is some care taken to ensure these destination buffers are
NUL-terminated by bounding the strncpy()'s by ORANGEFS_NAME_MAX - 1 or
ORANGEFS_MAX_SERVER_ADDR_LEN - 1. Instead, we can use the new 2-argument
version of strscpy() to guarantee NUL-termination on the destination
buffers while simplifying the code.

Based on usage with printf-likes, we can see these buffers are expected
to be NUL-terminated:
|	gossip_debug(GOSSIP_NAME_DEBUG,
|			"%s: doing lookup on %s under %pU,%d\n",
|			__func__,
|			new_op->upcall.req.lookup.d_name,
|			&new_op->upcall.req.lookup.parent_refn.khandle,
|			new_op->upcall.req.lookup.parent_refn.fs_id);
...
|	gossip_debug(GOSSIP_SUPER_DEBUG,
|			"Attempting ORANGEFS Remount via host %s\n",
|			new_op->upcall.req.fs_mount.orangefs_config_server);

NUL-padding isn't required for any of these destination buffers as
they've all been zero-allocated with op_alloc() or kzalloc().

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240322-strncpy-fs-orangefs-dcache-c-v1-1-15d12debbf38@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

The flags were set to SLAB_RED_ZONE when CONFIG_DEBUG_SLAB was enabled.
With SLAB gone, this is now dead code so remove it. With SLUB, debugging
options including red zoning can be set for orangefs caches by the
slab_debug boot parameter.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

orangefs_dir_fill() doesn't use oi and dentry arguments at all
do_readdir() gets dentry, uses only dentry->d_inode; it also
gets oi, which is ORANGEFS_I(dentry->d_inode) (i.e. ->d_inode -
constant offset).
orangefs_dir_mode() gets dentry and oi, uses only to pass those
to do_readdir().
orangefs_dir_iterate() uses dentry and oi only to pass those to
orangefs_dir_fill() and orangefs_dir_more().

The only thing it really needs is ->d_inode; moreover, that's
better expressed as file_inode(file) - no need to go through
->f_path.dentry->d_inode.

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

Pull vfs inode time accessor updates from Christian Brauner:
 "This finishes the conversion of all inode time fields to accessor
  functions as discussed on list. Changing timestamps manually as we
  used to do before is error prone. Using accessors function makes this
  robust.

  It does not contain the switch of the time fields to discrete 64 bit
  integers to replace struct timespec and free up space in struct inode.
  But after this, the switch can be trivially made and the patch should
  only affect the vfs if we decide to do it"

* tag 'vfs-6.7.ctime' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs: (86 commits)
  fs: rename inode i_atime and i_mtime fields
  security: convert to new timestamp accessors
  selinux: convert to new timestamp accessors
  apparmor: convert to new timestamp accessors
  sunrpc: convert to new timestamp accessors
  mm: convert to new timestamp accessors
  bpf: convert to new timestamp accessors
  ipc: convert to new timestamp accessors
  linux: convert to new timestamp accessors
  zonefs: convert to new timestamp accessors
  xfs: convert to new timestamp accessors
  vboxsf: convert to new timestamp accessors
  ufs: convert to new timestamp accessors
  udf: convert to new timestamp accessors
  ubifs: convert to new timestamp accessors
  tracefs: convert to new timestamp accessors
  sysv: convert to new timestamp accessors
  squashfs: convert to new timestamp accessors
  server: convert to new timestamp accessors
  client: convert to new timestamp accessors
  ...

Convert to using the new inode timestamp accessor functions.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20231004185347.80880-57-jlayton@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>

This makes it harder for accidental or malicious changes to
orangefs_xattr_handlers at runtime.

Cc: Mike Marshall <hubcap@omnibond.com>
Cc: Martin Brandenburg <martin@omnibond.com>
Cc: devel@lists.orangefs.org
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
Link: https://lore.kernel.org/r/20230930050033.41174-22-wedsonaf@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>