Re: [PATCH v2 08/92] fs: new helper: simple_rename_timestamp

On Wed, Jul 05, 2023 at 02:58:11PM -0400, Jeff Layton wrote: > + * POSIX mandates that the old and new parent directories have their ctime > and > + * mtime updated, and that inodes of @old_dentry and @new_dentry (if any), > have > + * their ctime updated. APPLICATION USAGE Some

Re: [PATCH] net: unexport csum_and_copy_{from,to}_user

On Thu, Apr 21, 2022 at 09:04:40AM +0200, Christoph Hellwig wrote: > csum_and_copy_from_user and csum_and_copy_to_user are exported by > a few architectures, but not actually used in modular code. Drop > the exports. > > Signed-off-by: Christoph Hellwig Acked-by: Al Viro Not

Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good

On Thu, Feb 17, 2022 at 08:49:59AM +0100, Arnd Bergmann wrote: > Same here: architectures can already provide a __put_user_fn() > and __get_user_fn(), to get the generic versions of the interface, > but few architectures use that. You can actually get all the interfaces > by just providing

Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good

On Thu, Feb 17, 2022 at 07:20:11AM +, Christophe Leroy wrote: > And we have also > user_access_begin()/user_read_access_begin()/user_write_access_begin() > which call access_ok() then do the real work. Could be made generic with > call to some arch specific __user_access_begin() and

Re: [PATCH 09/14] m68k: drop custom __access_ok()

On Tue, Feb 15, 2022 at 07:29:42AM +0100, Christoph Hellwig wrote: > On Tue, Feb 15, 2022 at 12:37:41AM +0000, Al Viro wrote: > > Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES > > (and trim the comment down to "coldfire and 68000 will pick generic &

Re: [PATCH 14/14] uaccess: drop set_fs leftovers

On Mon, Feb 14, 2022 at 05:34:52PM +0100, Arnd Bergmann wrote: > diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h > index b5835325d44b..2f4a1b1ef387 100644 > --- a/arch/parisc/include/asm/futex.h > +++ b/arch/parisc/include/asm/futex.h > @@ -99,7 +99,7 @@

Re: [PATCH 04/14] x86: use more conventional access_ok() definition

On Mon, Feb 14, 2022 at 08:17:07PM +, Al Viro wrote: > On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote: > > On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote: > > > > > > As Al pointed out, they turned out to be necessary on sparc64, but the &

Re: [PATCH 11/14] sparc64: remove CONFIG_SET_FS support

On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote: > -/* > - * Sparc64 is segmented, though more like the M68K than the I386. > - * We use the secondary ASI to address user memory, which references a > - * completely different VM map, thus there is zero chance of the user > - * doing

Re: [PATCH 09/14] m68k: drop custom __access_ok()

On Mon, Feb 14, 2022 at 05:34:47PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > While most m68k platforms use separate address spaces for user > and kernel space, at least coldfire does not, and the other > ones have a TASK_SIZE that is less than the entire 4GB address > range. > >

Re: [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault

On Mon, Feb 14, 2022 at 05:34:43PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > All architectures that don't provide __{get,put}_kernel_nofault() yet > can implement this on top of __{get,put}_user. > > Add a generic version that lets everything use the normal >

Re: [PATCH 04/14] x86: use more conventional access_ok() definition

On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote: > On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote: > > > > As Al pointed out, they turned out to be necessary on sparc64, but the only > > definitions are on sparc64 and x86, so it's possible that they serve a > > similar > >

Re: [PATCH 07/14] uaccess: generalize access_ok()

On Mon, Feb 14, 2022 at 05:34:45PM +0100, Arnd Bergmann wrote: > diff --git a/arch/csky/kernel/signal.c b/arch/csky/kernel/signal.c > index c7b763d2f526..8867ddf3e6c7 100644 > --- a/arch/csky/kernel/signal.c > +++ b/arch/csky/kernel/signal.c > @@ -136,7 +136,7 @@ static inline void __user

Re: [PATCH 3/4] exec: simplify the compat syscall handling

On Fri, Mar 26, 2021 at 03:38:30PM +0100, Christoph Hellwig wrote: > -static const char __user *get_user_arg_ptr(struct user_arg_ptr argv, int nr) > +static const char __user * > +get_user_arg_ptr(const char __user *const __user *argv, int nr) > { > - const char __user *native; > - > -#ifdef

Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver

On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote: > Switch the alpha defconfig from the legacy ide driver to libata. Umm... I don't have an IDE alpha box in a usable shape (fans on CPU module shat themselves), and it would take a while to resurrect it, but I remember the joy it

Re: [PATCH 3/9] powerpc/pseries: remove the ppc-cmm file system

On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote: > Just use the generic anon_inode file system. Umm... The only problem I see here is the lifetime rules for that module, and that's not something introduced in this patchset. Said that, looks like the logics around that place is

Re: [PATCH 4/9] drm: remove the drm file system

On Tue, Mar 09, 2021 at 04:53:43PM +0100, Christoph Hellwig wrote: > Just use the generic anon_inode file system. Are you changing the lifetime rules for that module?

Re: [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed

On Mon, Oct 26, 2020 at 05:56:11PM -0600, Jens Axboe wrote: > On 10/26/20 4:55 PM, Kyle Huey wrote: > > A test program from the rr[0] test suite, vm_readv_writev[1], no > > longer works on 5.10-rc1 when compiled as a 32 bit binary and executed > > on a 64 bit kernel. The first process_vm_readv

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote: > Now, I am not a compiler expert, but as I already cited, at least on > x86-64 clang expects that the high bits were cleared by the caller - in > contrast to gcc. I suspect it's the same on arm64, but again, I am no > compiler

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Thu, Oct 22, 2020 at 01:59:32PM -0700, Eric Biggers wrote: > Also note the following program succeeds on Linux 5.9 on x86_64. On kernels > that have this bug, it should fail. (I couldn't get it to actually fail, so > it > must depend on the compiler and/or the kernel config...) It doesn't.

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Thu, Oct 22, 2020 at 09:06:29PM +0100, Al Viro wrote: > On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote: > > > Depending upon the calling conventions, compiler might do truncation in > > caller or > > in a callee, but it must be done _somewhere_. > >

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote: > Depending upon the calling conventions, compiler might do truncation in > caller or > in a callee, but it must be done _somewhere_. Unless I'm misreading AAPCS64, "Unlike in the 32-bit AAPCS, named integr

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote: > On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > > > Passing an `unsigned long` as an `unsigned int` does no such > > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail >

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). > So if rw_copy_check_uvector() is inlined into import_iovec()

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Thu, Oct 22, 2020 at 05:40:40PM +0100, Matthew Wilcox wrote: > On Thu, Oct 22, 2020 at 04:35:17PM +, David Laight wrote: > > Wait... > > readv(2) defines: > > ssize_t readv(int fd, const struct iovec *iov, int iovcnt); > > It doesn't really matter what the manpage says. What does the

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > > From: David Laight > > > > This lets the compiler inline it into import_iovec() generating > > much better code. > > > > Signed-off-by: David Laight > >

Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()

On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote: > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned > int size) > { > char *vto = kmap_atomic(to); > > memcpy(vto, vfrom, size); > kunmap_atomic(vto); > } > > in linux/highmem.h ? You

Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops

On Thu, Oct 01, 2020 at 03:38:52PM -0700, Eric Biggers wrote: > mutex_lock(>pipe_mutex); > while (bytes) { > - wr = __kernel_write(file, data, bytes, NULL); > + wr = __kernel_write(file, data, bytes, >f_pos); Better loff_t dummy = 0; ...

Re: let import_iovec deal with compat_iovecs as well v4

On Fri, Sep 25, 2020 at 06:51:37AM +0200, Christoph Hellwig wrote: > Hi Al, > > this series changes import_iovec to transparently deal with compat iovec > structures, and then cleanups up a lot of code dupliation. OK, I can live with that. Applied, let's see if it passes smoke tests into -next

Re: [PATCH 5/9] fs: remove various compat readv/writev helpers

On Wed, Sep 23, 2020 at 08:45:51PM +0200, Arnd Bergmann wrote: > On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote: > > > > I wonder if we should do something like > > > > SYSCALL_DECLARE3(readv, unsigned long, fd, const struct iovec __user *, vec, > >

Re: [PATCH 5/9] fs: remove various compat readv/writev helpers

On Wed, Sep 23, 2020 at 05:38:31PM +0100, Al Viro wrote: > On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote: > > > > That's a very good question. But it does not just compile but actually > > > works. Probably because all the syscall wrappers mean that we don't

Re: [PATCH 5/9] fs: remove various compat readv/writev helpers

On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote: > > That's a very good question. But it does not just compile but actually > > works. Probably because all the syscall wrappers mean that we don't > > actually generate the normal names. I just tried this: > >

Re: [PATCH 5/9] fs: remove various compat readv/writev helpers

On Wed, Sep 23, 2020 at 04:32:51PM +0200, Christoph Hellwig wrote: > On Wed, Sep 23, 2020 at 03:25:49PM +0100, Al Viro wrote: > > On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote: > > > COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd, > > > -

Re: [PATCH 3/9] iov_iter: refactor rw_copy_check_uvector and import_iovec

On Wed, Sep 23, 2020 at 02:38:24PM +, David Laight wrote: > From: Al Viro > > Sent: 23 September 2020 15:17 > > > > On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote: > > > > > +struct iovec *iovec_from_user(const struct iovec __user

Re: [PATCH 3/9] iov_iter: refactor rw_copy_check_uvector and import_iovec

On Wed, Sep 23, 2020 at 03:16:54PM +0100, Al Viro wrote: > On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote: > > > +struct iovec *iovec_from_user(const struct iovec __user *uvec, > > + unsigned long nr_segs, unsigned long fast_segs, > > Hmm...

Re: [PATCH 5/9] fs: remove various compat readv/writev helpers

On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote: > COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd, > - const struct compat_iovec __user *,vec, > + const struct iovec __user *, vec, Um... Will it even compile? > #ifdef __ARCH_WANT_COMPAT_SYS_PREADV64

Re: [PATCH 3/9] iov_iter: refactor rw_copy_check_uvector and import_iovec

On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote: > +struct iovec *iovec_from_user(const struct iovec __user *uvec, > + unsigned long nr_segs, unsigned long fast_segs, Hmm... For fast_segs unsigned long had always been ridiculous (4G struct iovec on caller stack

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Wed, Sep 23, 2020 at 11:01:34AM +0300, Pavel Begunkov wrote: > > I'm not following why that would be considered a valid option, > > as that clearly breaks existing users that update from a 32-bit > > kernel to a 64-bit one. > > Do you mean users who move 32-bit binaries (without recompiling)

Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()

On Mon, Sep 21, 2020 at 03:44:00PM +, David Laight wrote: > From: Al Viro > > Sent: 21 September 2020 16:30 > > > > On Mon, Sep 21, 2020 at 03:21:35PM +, David Laight wrote: > > > > > You really don't want to be looping through the array twice. > &

Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()

On Mon, Sep 21, 2020 at 03:21:35PM +, David Laight wrote: > You really don't want to be looping through the array twice. Profiles, please. > I think the 'length' check can be optimised to do something like: > for (...) { > ssize_t len = (ssize_t)iov[seg].iov_len; >

Re: [PATCH 06/11] iov_iter: handle the compat case in import_iovec

On Mon, Sep 21, 2020 at 04:34:29PM +0200, Christoph Hellwig wrote: > Use in compat_syscall to import either native or the compat iovecs, and > remove the now superflous compat_import_iovec, which removes the need for > special compat logic in most callers. Only io_uring needs special > treatment

Re: [PATCH 05/11] iov_iter: merge the compat case into rw_copy_check_uvector

On Mon, Sep 21, 2020 at 04:34:28PM +0200, Christoph Hellwig wrote: > +static int compat_copy_iovecs_from_user(struct iovec *iov, > + const struct iovec __user *uvector, unsigned long nr_segs) > +{ > + const struct compat_iovec __user *uiov = > + (const struct

Re: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector

On Mon, Sep 21, 2020 at 03:05:32PM +, David Laight wrote: > I've actually no idea: > 1) Why there is an access_ok() check here. >It will be repeated by the user copy functions. Early sanity check. > 2) Why it isn't done when called from mm/process_vm_access.c. >Ok, the addresses

Re: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector

On Mon, Sep 21, 2020 at 04:34:27PM +0200, Christoph Hellwig wrote: > Explicitly check for the magic value insted of implicitly relying on > its numeric representation. Also drop the rather pointless unlikely > annotation. See above - I would rather have CHECK_IOVEC_ONLY gone. The reason for

Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()

On Mon, Sep 21, 2020 at 04:34:25PM +0200, Christoph Hellwig wrote: > From: David Laight > > This is the only direct call of rw_copy_check_uvector(). Removing it > will allow rw_copy_check_uvector() to be inlined into import_iovec(), > while only paying a minor price by setting up an otherwise

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sun, Sep 20, 2020 at 08:22:59PM +0100, Matthew Wilcox wrote: > On Sun, Sep 20, 2020 at 08:10:31PM +0100, Al Viro wrote: > > IMO it's much saner to mark those and refuse to touch them from io_uring... > > Simpler solution is to remove io_uring from the 32-bit syscall list. >

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sun, Sep 20, 2020 at 08:01:59PM +0100, Matthew Wilcox wrote: > On Sun, Sep 20, 2020 at 07:07:42PM +0100, Al Viro wrote: > > 2) a few drivers are really fucked in head. They use different > > *DATA* layouts for reads/writes, depending upon the calling process. > >

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sun, Sep 20, 2020 at 07:07:42PM +0100, Al Viro wrote: > /proc/bus/input/devices (fucked bitmap-to-text representation) To illustrate the, er, beauty of that stuff: ; cat32 /proc/bus/input/devices >/tmp/a ; cat /proc/bus/input/devices >/tmp/b ; diff -u /tmp/a /tmp/b|grep '^[-+]'

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sun, Sep 20, 2020 at 09:59:36AM -0700, Andy Lutomirski wrote: > As one example, look at __sys_setsockopt(). It's called for the > native and compat versions, and it contains an in_compat_syscall() > check. (This particularly check looks dubious to me, but that's > another story.) If this

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sun, Sep 20, 2020 at 04:15:10PM +0100, Matthew Wilcox wrote: > On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote: > > Add a flag to force processing a syscall as a compat syscall. This is > > required so that in_compat_syscall() works for I/O submitted by io_uring > > helper

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sun, Sep 20, 2020 at 03:55:47PM +0200, Arnd Bergmann wrote: > On Sun, Sep 20, 2020 at 12:09 AM Al Viro wrote: > > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: > > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > > > Said t

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > 2) have you counted the syscalls that do and do not need that? > > No. Might be illuminating... > > 3) how many of those realistically *can* be unified with their > > compat counterparts? [hint: ioctl(2) cannot] > > There

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote: > > It would not be a win - most of the syscalls don't give a damn > > about 32bit vs. 64bit... > > Any reasonable implementation would optimize it out for syscalls that don’t > care. Or it could be explicit: > >

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote: > > > On Sep 19, 2020, at 3:09 PM, Al Viro wrote: > > > > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: > >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > Said that, why not provide a variant that would take an explicit > > "is it compat" argument and use it there? And have the normal >

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote: > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote: > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */ > > > - return pt_regs_trap_type(current_pt_regs()) == 0x110; > > > + return pt_

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote: > Add a flag to force processing a syscall as a compat syscall. This is > required so that in_compat_syscall() works for I/O submitted by io_uring > helper threads on behalf of compat syscalls. > > Signed-off-by: Christoph

Re: [PATCH 12/14] x86: remove address space overrides using set_fs()

On Fri, Sep 04, 2020 at 03:55:10AM +0100, Al Viro wrote: > On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote: > > > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S > > index c8a85b512796e1..94f7be4971ed04 100644 > > --- a/arch/x86/lib/getuser.

Re: [PATCH 12/14] x86: remove address space overrides using set_fs()

On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote: > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S > index c8a85b512796e1..94f7be4971ed04 100644 > --- a/arch/x86/lib/getuser.S > +++ b/arch/x86/lib/getuser.S > @@ -35,10 +35,19 @@ > #include > #include > >

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

On Thu, Sep 03, 2020 at 04:30:03PM +0200, Christoph Hellwig wrote: > On Thu, Sep 03, 2020 at 03:28:03PM +0100, Al Viro wrote: > > On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote: > > > > > Besides x86 and powerpc I plan to eventually convert all o

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote: > Besides x86 and powerpc I plan to eventually convert all other > architectures, although this will be a slow process, starting with the > easier ones once the infrastructure is merged. The process to convert > architectures is

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v2

On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote: > 10.92% dd [kernel.kallsyms] [k] iov_iter_zero Interesting... Could you get an instruction-level profile inside iov_iter_zero(), along with the disassembly of that sucker?

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.9-1 tag

On Fri, Aug 07, 2020 at 10:46:13AM -0700, Linus Torvalds wrote: > On Fri, Aug 7, 2020 at 6:14 AM Michael Ellerman wrote: > > > > Just one minor conflict, in a comment in drivers/misc/ocxl/config.c. > > Well, this morning I merged the ptrace ->regset_get() updates from Al, > and that brought in a

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote: > On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote: > > > Mainline, with: > > > > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \ > > -snapshot -drive file=

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote: > Mainline, with: > > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \ > -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \ > -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0" >

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote: > On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote: > > On 5/21/20 10:27 AM, Al Viro wrote: > > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote: > > >> On Mon, May 18, 20

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote: > On 5/21/20 10:27 AM, Al Viro wrote: > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote: > >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote: > >>> From: Ira Weiny

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote: > On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > The kunmap_atomic clean up failed to remove one set of pagefault/preempt > > enables when vaddr is not in the fixmap. > > > > Fixes:

Re: remove set_fs calls from the coredump code v6

On Tue, May 05, 2020 at 10:42:58PM +0200, Christoph Hellwig wrote: > On Tue, May 05, 2020 at 09:34:46PM +0100, Al Viro wrote: > > Looks good. Want me to put it into vfs.git? #work.set_fs-exec, perhaps? > > Sounds good. Applied, pushed and added into #for-next

Re: remove set_fs calls from the coredump code v6

On Tue, May 05, 2020 at 12:12:49PM +0200, Christoph Hellwig wrote: > Hi all, > > this series gets rid of playing with the address limit in the exec and > coredump code. Most of this was fairly trivial, the biggest changes are > those to the spufs coredump code. > > Changes since v5: > - fix

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote: > > || * arm: much, much worse. We have several files that pull > > linux/highmem.h: > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c, > > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c, >

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote: > Grepping for 'asm/highmem.h' and investigations don't reveal any issues... > But > you do have me worried. That said 0-day has been crunching on multiple > versions of this series without issues such as this (save the mips issue >

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > The kmap infrastructure has been copied almost verbatim to every architecture. > This series consolidates obvious duplicated code by defining core functions > which call into the architectures only when

Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's

On Fri, May 01, 2020 at 03:37:34AM +0100, Al Viro wrote: > On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote: > > > -static inline void *kmap_atomic(struct page *page) > > +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot) > > {

Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's

On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote: > -static inline void *kmap_atomic(struct page *page) > +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot) > { > preempt_disable(); > pagefault_disable(); > if (!PageHighMem(page)) >

Re: [PATCH V1 08/10] arch/kmap: Don't hard code kmap_prot values

On Thu, Apr 30, 2020 at 01:38:43PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > To support kmap_atomic_prot() on all architectures each arch must > support protections passed in to them. > > Change csky, mips, nds32 and xtensa to use their global kmap_prot value > rather than a hard

Re: [PATCH V1 05/10] arch/kmap_atomic: Consolidate duplicate code

On Thu, Apr 30, 2020 at 01:38:40PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > Every arch has the same code to ensure atomic operations and a check for > !HIGHMEM page. > > Remove the duplicate code by defining a core kmap_atomic() which only > calls the arch specific

Re: [PATCH 1/5] powerpc/spufs: simplify spufs core dumping

On Mon, Apr 27, 2020 at 10:06:21PM +0200, Christoph Hellwig wrote: > @@ -1988,7 +1984,12 @@ static ssize_t spufs_mbox_info_read(struct file *file, > char __user *buf, > if (ret) > return ret; > spin_lock(>csa.register_lock); > - ret = __spufs_mbox_info_read(ctx,

Re: [PATCH 1/7] powerpc/spufs: simplify spufs core dumping

On Tue, Apr 21, 2020 at 08:19:09PM +0100, Al Viro wrote: > On Tue, Apr 21, 2020 at 09:01:48PM +0200, Christoph Hellwig wrote: > > On Tue, Apr 21, 2020 at 07:49:41PM +0100, Al Viro wrote: > > > > spin_lock(>csa.register_lock); > > > > - ret = __sp

Re: [PATCH 1/7] powerpc/spufs: simplify spufs core dumping

On Tue, Apr 21, 2020 at 09:01:48PM +0200, Christoph Hellwig wrote: > On Tue, Apr 21, 2020 at 07:49:41PM +0100, Al Viro wrote: > > > spin_lock(>csa.register_lock); > > > - ret = __spufs_proxydma_info_read(ctx, buf, len, pos); > > > + __spufs_proxy

Re: [PATCH 1/7] powerpc/spufs: simplify spufs core dumping

On Tue, Apr 21, 2020 at 05:41:58PM +0200, Christoph Hellwig wrote: > static ssize_t spufs_proxydma_info_read(struct file *file, char __user *buf, > size_t len, loff_t *pos) > { > struct spu_context *ctx = file->private_data; > + struct

Re: [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()

[rmk Cc'd] On Fri, Apr 03, 2020 at 09:52:05PM +0100, Al Viro wrote: > I can do a 5.7-rc1-based branch with that; depending upon what we end > up doing for arm and s390 we can always change the calling conventions > come next cycle ;-/ > > My impressions after digging through arm

Re: [PATCH 3/6] binfmt_elf: remove the set_fs(KERNEL_DS) in elf_core_dump

On Mon, Apr 06, 2020 at 02:03:09PM +0200, Christoph Hellwig wrote: > There is no logic in elf_core_dump itself that uses uaccess routines > on kernel pointers, the file writes are nicely encapsulated in dump_emit > which does its own set_fs. ... assuming you've checked the asm/elf.h to see that

Re: [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()

On Fri, Apr 03, 2020 at 11:01:10AM -0700, Linus Torvalds wrote: > On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy > wrote: > > > > Now we have user_read_access_begin() and user_write_access_begin() > > in addition to user_access_begin(). > > I realize Al asked for this, but I don't think it

Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end

On Fri, Apr 03, 2020 at 02:37:19PM +0100, Russell King - ARM Linux admin wrote: > > I think uaccess_enable() could indeed switch the kernel domain if > > KERNEL_DS is set and move this out of set_fs(). It would reduce the > > window the kernel domain permissions are overridden. Anyway, > >

Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end

On Thu, Apr 02, 2020 at 11:35:57AM -0700, Kees Cook wrote: > Yup, I think it's a weakness of the ARM implementation and I'd like to > not extend it further. AFAIK we should never nest, but I would not be > surprised at all if we did. > > If we were looking at a design goal for all architectures,

Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end

On Thu, Apr 02, 2020 at 07:03:28PM +0200, Christophe Leroy wrote: > user_access_begin() grants both read and write. > > This patch adds user_read_access_begin() and user_write_access_begin() but > it doesn't remove user_access_begin() Ouch... So the most generic name is for the rarest case?

Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end

On Thu, Apr 02, 2020 at 07:34:16AM +, Christophe Leroy wrote: > Some architectures like powerpc64 have the capability to separate > read access and write access protection. > For get_user() and copy_from_user(), powerpc64 only open read access. > For put_user() and copy_to_user(), powerpc64

Re: [powerpc] Intermittent crashes ( link_path_walk) with linux-next

On Thu, Mar 26, 2020 at 10:40:06PM +1100, Michael Ellerman wrote: > > The code in question (link_path_walk() in fs/namei.c ) was recently changed > > by > > following commit: > > > > commit 881386f7e46a: > > link_path_walk(): sample parent's i_uid and i_mode for the last component > > That

Re: [PATCH v1 1/6] fs/readdir: Fix filldir() and filldir64() use of user_access_begin()

On Wed, Jan 22, 2020 at 08:13:12AM -0800, Linus Torvalds wrote: > On Wed, Jan 22, 2020 at 5:00 AM Christophe Leroy > wrote: > > > > Modify filldir() and filldir64() to request the real area they need > > to get access to. > > Not like this. > > This makes the situation for architectures like

Re: [PATCH v18 00/13] open: introduce openat2(2) syscall

On Sat, Dec 07, 2019 at 01:13:25AM +1100, Aleksa Sarai wrote: > This patchset is being developed here: > See #work.openat2; rebased on top of #fixes (there's a minor conflict in follow_managed()). I'll either leave that as-is or rebase to

Re: [PATCH v17 00/13] open: introduce openat2(2) syscall

Generally I can live with that - the only serious issue is with that WARN_ON() and the logics of the check in it.

Re: [PATCH v17 11/13] open: introduce openat2(2) syscall

On Sun, Nov 17, 2019 at 12:17:11PM +1100, Aleksa Sarai wrote: > +/* how->upgrade flags for openat2(2). */ > +/* First bit is reserved for a future UPGRADE_NOEXEC flag. */ > +#define UPGRADE_NOREAD 0x02 /* Block re-opening with MAY_READ. > */ > +#define UPGRADE_NOWRITE

Re: [PATCH v17 10/13] namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution

On Sun, Nov 17, 2019 at 12:17:10PM +1100, Aleksa Sarai wrote: > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) { > + /* > + * If there was a racing rename or mount along our > + * path, then we can't be sure that ".." hasn't

Re: [PATCH v17 08/13] namei: LOOKUP_BENEATH: O_BENEATH-like scoped resolution

On Sun, Nov 17, 2019 at 12:17:08PM +1100, Aleksa Sarai wrote: > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) { > + /* > + * Do a final check to ensure that the path didn't escape. Note > + * that this should already be guaranteed by all of the other > +

Re: [PATCH v16 09/12] namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution

On Sat, Nov 16, 2019 at 11:27:59AM +1100, Aleksa Sarai wrote: > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) { > + bool m_retry = read_seqretry(_lock, nd->m_seq); > + bool r_retry = read_seqretry(_lock, nd->r_seq); > + > +

Re: [PATCH v16 06/12] namei: LOOKUP_NO_XDEV: block mountpoint crossing

On Sat, Nov 16, 2019 at 11:27:56AM +1100, Aleksa Sarai wrote: > @@ -1383,6 +1398,8 @@ static int follow_dotdot_rcu(struct nameidata *nd) > return -ECHILD; > if (>mnt == nd->path.mnt) > break; > +

Re: [PATCH v16 02/12] namei: allow nd_jump_link() to produce errors

On Sat, Nov 16, 2019 at 11:27:52AM +1100, Aleksa Sarai wrote: > + error = nd_jump_link(); > + if (error) > + path_put(); > + error = nd_jump_link(_path); > + if (error) > + path_put(_path); > + error = nd_jump_link(); > + if (error) > +

Re: [PATCH v15 3/9] namei: LOOKUP_NO_XDEV: block mountpoint crossing

On Thu, Nov 14, 2019 at 03:49:45PM +1100, Aleksa Sarai wrote: > On 2019-11-13, Al Viro wrote: > > On Tue, Nov 05, 2019 at 08:05:47PM +1100, Aleksa Sarai wrote: > > > > > @@ -862,6 +870,8 @@ static int nd_jump_root(struct nameidata *nd) > > > vo

Re: [PATCH v15 5/9] namei: LOOKUP_IN_ROOT: chroot-like scoped resolution

On Wed, Nov 13, 2019 at 01:44:14PM +1100, Aleksa Sarai wrote: > On 2019-11-13, Al Viro wrote: > > On Tue, Nov 05, 2019 at 08:05:49PM +1100, Aleksa Sarai wrote: > > > > > @@ -2277,12 +2277,20 @@ static const char *path_init(struct nameidata > > > *nd, unsigned

Re: [PATCH v15 7/9] open: introduce openat2(2) syscall

On Tue, Nov 05, 2019 at 08:05:51PM +1100, Aleksa Sarai wrote: > +/* > + * Arguments for how openat2(2) should open the target path. If @resolve is > + * zero, then openat2(2) operates very similarly to openat(2). > + * > + * However, unlike openat(2), unknown bits in @flags result in -EINVAL

  1   2   >