On Tue, Apr 06, 2021 at 07:09:12PM -0500, Aditya Pakki wrote:
> --- a/net/rds/send.c
> +++ b/net/rds/send.c
> @@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head
> *messages, int status)
> unlock_and_drop:
> spin_unlock_irqrestore(&rm->m_rs_lock, flags);
>
On Sat, Apr 17, 2021 at 07:36:39AM -0700, Alexei Starovoitov wrote:
> The kernel will perform the same work with FDs. The same locks are held
> and the same execution conditions are in both cases. The LSM hooks,
> fsnotify, etc will be called the same way.
> It's no different if new syscall was in
On Fri, Apr 16, 2021 at 08:46:05PM -0700, Alexei Starovoitov wrote:
> On Fri, Apr 16, 2021 at 8:42 PM Al Viro wrote:
> >
> > On Fri, Apr 16, 2021 at 08:32:20PM -0700, Alexei Starovoitov wrote:
> > > From: Alexei Starovoitov
> > >
> > > Add bpf_sys_close
On Fri, Apr 16, 2021 at 08:32:20PM -0700, Alexei Starovoitov wrote:
> From: Alexei Starovoitov
>
> Add bpf_sys_close() helper to be used by the syscall/loader program to close
> intermediate FDs and other cleanup.
Conditional NAK. In a lot of contexts close_fd() is very much unsafe.
In particul
On Mon, Feb 22, 2021 at 07:12:29PM +, Al Viro wrote:
> On Mon, Feb 22, 2021 at 07:06:00PM +, Al Viro wrote:
> > On Sat, Feb 20, 2021 at 09:08:56PM +, Al Viro wrote:
> >
> > > *shrug*
> > >
> > > If anything, __unix_complete_bind() mig
unix_bind_bsd() and unix_bind_abstract() respectively.
Signed-off-by: Al Viro
---
net/unix/af_unix.c | 147 +++--
1 file changed, 74 insertions(+), 73 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 496b069c99fe
Signed-off-by: Al Viro
---
net/unix/af_unix.c | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 56443f05ed9d..5e04e16e6b88 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -983,45
We only care about exclusive or of those, so pass that directly.
Makes life simpler for callers as well...
Signed-off-by: Al Viro
---
net/unix/af_unix.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index
On Mon, Feb 22, 2021 at 07:06:00PM +, Al Viro wrote:
> On Sat, Feb 20, 2021 at 09:08:56PM +, Al Viro wrote:
>
> > *shrug*
> >
> > If anything, __unix_complete_bind() might make a better name for that,
> > with dropping ->bindlock also pulled in,
Duplicated logics in all bind variants (autobind, bind-to-path,
bind-to-abstract) gets taken into a common helper.
Signed-off-by: Al Viro
---
net/unix/af_unix.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix
done_path_create
return 0
would be deadlock-free. Here we massage unix_bind_bsd() to that
form. We are still doing equivalent transformations.
Next commit will *not* be an equivalent transformation - it will
add a call of vfs_unlink() before done_path_create() in "alread bound
makes it easier to massage; we do pay for that by extra work
(kmalloc+memcpy+kfree) in some error cases, but those are not
on the hot paths anyway.
Signed-off-by: Al Viro
---
net/unix/af_unix.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a
ewhere, or put something else in its place - locked
parent prevents that.
Signed-off-by: Al Viro
---
net/unix/af_unix.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 36837662..8bbdcddbf598 100644
We do get some duplication that way, but it's minor compared to
parts that are different. What we get is an ability to change
locking in BSD case without making failure exits very hard to
follow.
Signed-off-by: Al Viro
---
net/unix/af_unix.c
On Sat, Feb 20, 2021 at 09:08:56PM +, Al Viro wrote:
> *shrug*
>
> If anything, __unix_complete_bind() might make a better name for that,
> with dropping ->bindlock also pulled in, but TBH I don't have sufficiently
> strong preferences - might as well leave drop
he
patch below - csum_fold() returns reduced *complement* of its argument, so we
want to give it SUM(from) - SUM(to) - seed, not seed - SUM(from) + SUM(to).
And it's probably a separate followup (adding normalization, that is).
commit 1dd99d9664ec36e9068afb3ca0017c0a43ee420f
Author: Al Viro
Date:
On Fri, Nov 13, 2020 at 02:22:16PM +0100, Björn Töpel wrote:
> Folding Al's input to this reply.
>
> I think the bpf_csum_diff() is supposed to be used in combination with
> another helper(s) (e.g. bpf_l4_csum_replace) so I'd guess the returned
> __wsum should be seen as an opaque value, not some
On Fri, Nov 13, 2020 at 11:36:08AM +0100, Björn Töpel wrote:
> I was running the selftest/bpf on riscv, and had a closer look at one
> of the failing cases:
>
> #14/p valid read map access into a read-only array 2 FAIL retval
> 65507 != -29 (run 1/1)
>
> The test does a csum_partial() call via
's no realistic cause to ever need other errors
there (well, short of some clown attaching a hook, pardon the obscenity),
so I would recommend something like the patch below (completely untested):
sanitize sock_from_file() calling conventions
deal with error value (always -ENOTSOCK) in the
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 call
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 exp
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.
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_.
>
>
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 inte
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
>
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() (
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 A
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
> > Signed-off-b
On Wed, Oct 14, 2020 at 03:51:00PM -0700, Linus Torvalds wrote:
> On Wed, Oct 14, 2020 at 3:27 PM Jason A. Donenfeld wrote:
> >
> > This patch is causing crashes in WireGuard's CI over at
> > https://www.wireguard.com/build-status/ . Apparently sending a simple
> > network packet winds up triggeri
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 mea
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 i
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,
> >
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
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:
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,
> > > -
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
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...
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
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 fram
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) t
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.
&
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;
>
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 g
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 compat_iove
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 refe
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 doi
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 un
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.
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.
> > IO
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 '^[-
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 wer
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 thr
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 that,
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 wo
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:
>
> DEFINE_MULTIARCH
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:
&
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
> >
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_
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 Hellwig
On Mon, Aug 31, 2020 at 12:48:13PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16a8566990
> kernel
On Sat, Aug 15, 2020 at 11:23:43AM -0700, Pascal Bouchareine wrote:
> Let caller specify allocation.
> Preserve existing calls with GFP_USER.
Bloody bad idea, unless you slap a BUG_ON(flags & GFP_ATOMIC) on it,
to make sure nobody tries _that_. Note that copying from userland
is an inherently blo
On Thu, Aug 06, 2020 at 12:59:16PM +0100, Al Viro wrote:
> On Thu, Aug 06, 2020 at 07:53:16PM +0800, linmiaohe wrote:
> > From: Miaohe Lin
> >
> > We should fput() file iff FDPUT_FPUT is set. So we should set fput_needed
> > accordingly.
> >
> > Fi
On Thu, Aug 06, 2020 at 07:53:16PM +0800, linmiaohe wrote:
> From: Miaohe Lin
>
> We should fput() file iff FDPUT_FPUT is set. So we should set fput_needed
> accordingly.
>
> Fixes: 00e188ef6a7e ("sockfd_lookup_light(): switch to fdget^W^Waway from
> fget_light")
Explain, please. We are getti
On Wed, Jul 22, 2020 at 11:12:19PM +0200, Jiri Olsa wrote:
> +BTF_SET_START(btf_whitelist_d_path)
> +BTF_ID(func, vfs_truncate)
> +BTF_ID(func, vfs_fallocate)
> +BTF_ID(func, dentry_open)
> +BTF_ID(func, vfs_getattr)
> +BTF_ID(func, filp_close)
> +BTF_SET_END(btf_whitelist_d_path)
While we are at
On Wed, Jul 22, 2020 at 11:12:19PM +0200, Jiri Olsa wrote:
> +BPF_CALL_3(bpf_d_path, struct path *, path, char *, buf, u32, sz)
> +{
> + char *p = d_path(path, buf, sz - 1);
> + int len;
> +
> + if (IS_ERR(p)) {
> + len = PTR_ERR(p);
> + } else {
> + len = s
compat sendmsg() with several different-sized cmsg
attached started to fail with EINVAL. Trivial to fix, fortunately.
Reported-by: Nick Bowler
Tested-by: Nick Bowler
Fixes: 547ce4cfb34c ("switch cmsghdr_from_user_compat_to_kern() to
copy_from_user()")
Signed-off-by: Al Viro
---
diff -
On Mon, Jul 27, 2020 at 05:05:54PM +0100, Al Viro wrote:
> On Thu, Jul 23, 2020 at 11:51:01AM -0400, Nick Bowler wrote:
> > Hi,
> >
> > After installing Linux 5.8-rc6, it seems cryptsetup can no longer
> > open LUKS volumes. Regardless of the entered passphrase (cor
On Mon, Jul 27, 2020 at 09:51:45AM +, David Laight wrote:
> I'm sure there is code that processes options in chunks.
> This probably means it is possible to put a chunk boundary
> at the end of userspace and continue processing the very start
> of kernel memory.
>
> At best this faults on the
On Tue, Jul 21, 2020 at 07:23:26AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 21, 2020 at 04:40:16AM +0200, Luc Van Oostenryck wrote:
> > > req.pid = current->pid;
> > > req.cmd = optname;
> > > - req.addr = (long __force __user)optval;
> > > + req.addr = (__force long)optval;
> >
> > For c
On Tue, Jun 30, 2020 at 12:14:01PM +1000, Herbert Xu wrote:
> Could you please fold these changes into your tree?
Done and pushed. Sorry, had been buried in the regset mess
lately... ;-/
On Wed, Jun 17, 2020 at 12:38:07AM +1000, Herbert Xu wrote:
> On Tue, Jun 16, 2020 at 04:38:49AM +0100, Al Viro wrote:
> >
> > Folded and pushed
>
> Thanks Al. Here's another one that I just got, could you add this
> one too?
Done...
On Tue, Jun 16, 2020 at 11:05:02AM +1000, Herbert Xu wrote:
> On Tue, Jun 16, 2020 at 10:34:40AM +1000, Stephen Rothwell wrote:
> > [Just adding Herbert to cc]
> >
> > On Tue, 16 Jun 2020 10:33:30 +1000 Stephen Rothwell
> > wrote:
> > >
> > > Hi all,
> > >
> > > After merging the vfs tree, toda
On Fri, Jun 12, 2020 at 04:57:37PM +1000, Herbert Xu wrote:
> The header file linux/uio.h includes crypto/hash.h which pulls in
> most of the Crypto API. Since linux/uio.h is used throughout the
> kernel this means that every tiny bit of change to the Crypto API
> causes the entire kernel to get r
On Sun, Jun 14, 2020 at 09:41:17PM +0200, Alexander A. Klimov wrote:
> Hello there!
>
> At the moment one can't checkout a clean working directory w/o any changed
> files on a case-insensitive FS as the following file names have lower-case
> duplicates:
And if you use a filesystem that is limited
On Thu, Jun 04, 2020 at 06:10:23AM -0400, Michael S. Tsirkin wrote:
> stac()
> for (i = 0; i < 64; ++i) {
>get_user(flags, desc[i].flags)
unsafe_get_user(), please.
>smp_rmb()
>if (!(flags & VALID))
> break;
>copy_from_user(&adesc[i], desc
On Thu, Jun 04, 2020 at 02:10:27PM +0800, Jason Wang wrote:
> > > get_user(flags, desc->flags)
> > > smp_rmb()
> > > if (flags & VALID)
> > > copy_from_user(&adesc, desc, sizeof adesc);
> > >
> > > this would be a good candidate I think.
> > Perhaps, once we get stac/clac out of raw_copy_from_use
On Wed, Jun 03, 2020 at 01:29:00AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
> > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > So vhost needs to poke at userspace *a lot* in a quick succession.
On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
> > How widely do you hope to stretch the user_access areas, anyway?
>
>
> To have best performance for small packets like 64B, if possible, we want to
> disable STAC not only for the metadata access done by vhost accessors but
> also t
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> So vhost needs to poke at userspace *a lot* in a quick succession. It
> is thus benefitial to enable userspace access, do our thing, then
> disable. Except access_ok has already been pre-validated with all the
> relevant nospec
On Tue, Jun 02, 2020 at 04:42:03PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jun 02, 2020 at 05:30:48PM +0100, Al Viro wrote:
> > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > So vhost needs to poke at userspace *a lot* in a quick succession.
On Tue, Jun 02, 2020 at 08:41:38PM +, David Laight wrote:
> In which case you need a 'user_access_begin' that takes the mm
> as an additional parameter.
What does any of that have to do with mm? Details, please.
On Tue, Jun 02, 2020 at 06:44:30PM +0100, Al Viro wrote:
> On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote:
>
>
> > You have exactly two cases:
> >
> > (a) the access_ok() would be right above the code and can't be missed
> >
> > (b)
On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote:
> You have exactly two cases:
>
> (a) the access_ok() would be right above the code and can't be missed
>
> (b) not
(c) what you really want is not quite access_ok().
Again, that "not quite access_ok()" should be right next
On Tue, Jun 02, 2020 at 06:15:57PM +0800, Jason Wang wrote:
>
> On 2020/6/2 下午4:45, Michael S. Tsirkin wrote:
> > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > is thus benefitial to enable userspace access, do our thing, then
> > disable. Except access_ok has already b
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> So vhost needs to poke at userspace *a lot* in a quick succession. It
> is thus benefitial to enable userspace access, do our thing, then
> disable. Except access_ok has already been pre-validated with all the
> relevant nospec
no point getting compat_cmsghdr field-by-field
Signed-off-by: Al Viro
---
diff --git a/net/compat.c b/net/compat.c
index afd7b444e0bf..5e3041a2c37d 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -183,20 +183,21 @@ int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg,
struct sock *sk
From: Al Viro
Parallel to what the native setsockopt() does, except that unlike
the native setsockopt() we do not use memdup_user() - we want
the sockaddr_storage fields properly aligned, so we allocate
4 bytes more and copy compat_group_filter at the offset 4,
which yields the proper alignments
From: Al Viro
We want to check if optname is among the MCAST_... ones; do that as
an explicit switch.
Signed-off-by: Al Viro
---
net/ipv4/ip_sockglue.c | 10 +-
net/ipv6/ipv6_sockglue.c | 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/net/ipv4
From: Al Viro
that way we'll be able to reuse it for compat case
Signed-off-by: Al Viro
---
include/net/ipv6.h | 3 ++-
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/mcast.c | 7 ---
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/include/net/ipv6.h b/includ
From: Al Viro
pass the userland pointer to the array in its tail, so that part
gets copied out by our functions; copyout of everything else is
done in the callers. Rationale: reuse for compat; the array
is the same in native and compat, the layout of parts before it
is different for compat
From: Al Viro
We want to get rid of compat_mc_[sg]etsockopt() and to have that stuff
handled without compat_alloc_user_space(), extra copying through
userland, etc. To do that we'll need ipv4 and ipv6 instances of
->compat_[sg]etsockopt() to manipulate the 32bit variants of mcast
requ
From: Al Viro
similar to the ipv4 counterpart of that patch - the same
trick used to align the tail array properly.
Signed-off-by: Al Viro
---
net/ipv6/ipv6_sockglue.c | 48 +++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/net/ipv6
From: Al Viro
now we can do MCAST_MSFILTER in compat ->getsockopt() without
playing silly buggers with copying things back and forth.
We can form a native struct group_filter (sans the variable-length
tail) on stack, pass that + pointer to the tail of original request
to the helper doing
From: Al Viro
Signed-off-by: Al Viro
---
net/atm/ioctl.c | 19 ++-
net/atm/resources.c | 19 +--
net/atm/resources.h | 2 +-
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/net/atm/ioctl.c b/net/atm/ioctl.c
index 0b4b07740fe4..e239cebf48da
From: Al Viro
Signed-off-by: Al Viro
---
net/ipv4/ip_sockglue.c | 83 ++
1 file changed, 44 insertions(+), 39 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 34c3a43a9c98..7f065a68664e 100644
--- a/net/ipv4
From: Al Viro
Signed-off-by: Al Viro
---
net/ipv4/ip_sockglue.c | 73 +++---
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 65a30e7672ff..cc0441157b02 100644
--- a/net/ipv4
From: Al Viro
Signed-off-by: Al Viro
---
net/atm/ioctl.c | 25 -
net/atm/resources.c | 35 +--
net/atm/resources.h | 4 ++--
3 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/net/atm/ioctl.c b/net/atm/ioctl.c
index
From: Al Viro
address is passed only to copy_to_user()
Signed-off-by: Al Viro
---
net/batman-adv/icmp_socket.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/batman-adv/icmp_socket.c b/net/batman-adv/icmp_socket.c
index ccb535c77e5d..8bdabc03b0b2 100644
--- a/net/batman-adv
From: Al Viro
Signed-off-by: Al Viro
---
net/atm/ioctl.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/net/atm/ioctl.c b/net/atm/ioctl.c
index 52f2c77e656f..838ebf0cabbf 100644
--- a/net/atm/ioctl.c
+++ b/net/atm/ioctl.c
@@ -286,30 +286,13
From: Al Viro
Signed-off-by: Al Viro
---
net/ipv6/ipv6_sockglue.c | 65 +++-
1 file changed, 36 insertions(+), 29 deletions(-)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 209d827950cc..bb049feeb787 100644
--- a/net/ipv6
1 - 100 of 597 matches
Mail list logo
