On Sun, Oct 13, 2019 at 12:22:38PM -0700, Linus Torvalds wrote:
> On Sun, Oct 13, 2019 at 12:10 PM Al Viro wrote:
> >
> > No arguments re put_user_ex side of things... Below is a completely
> > untested patch for get_user_ex elimination (it seems to build, but that's
> > it); in any case, I would
On Tue, Oct 15, 2019 at 08:40:12PM +0100, Al Viro wrote:
> or this
> static void ntb_memcpy_tx(struct ntb_queue_entry *entry, void __iomem *offset)
> {
> #ifdef ARCH_HAS_NOCACHE_UACCESS
> /*
> * Using non-temporal mov to improve performance on non-cached
> * writes, even t
On Tue, Oct 15, 2019 at 12:00:34PM -0700, Linus Torvalds wrote:
> On Tue, Oct 15, 2019 at 11:08 AM Al Viro wrote:
> >
> > Another question: right now we have
> > if (!access_ok(uaddr, sizeof(u32)))
> > return -EFAULT;
> >
> > ret = arch_futex_atomic_op_inuser(op, op
On Tue, Oct 15, 2019 at 11:08 AM Al Viro wrote:
>
> Another question: right now we have
> if (!access_ok(uaddr, sizeof(u32)))
> return -EFAULT;
>
> ret = arch_futex_atomic_op_inuser(op, oparg, &oldval, uaddr);
> if (ret)
> return ret;
> in ke
[futex folks and linux-arch Cc'd]
On Sun, Oct 13, 2019 at 08:59:49PM +0100, Al Viro wrote:
> Re plotting: how strongly would you object against passing the range to
> user_access_end()? Powerpc folks have a very close analogue of stac/clac,
> currently buried inside their __get_user()/__put_user
Linus Torvalds writes:
> On Sun, Oct 13, 2019 at 12:59 PM Al Viro wrote:
>> Re plotting: how strongly would you object against passing the range to
>> user_access_end()? Powerpc folks have a very close analogue of stac/clac,
>> currently buried inside their __get_user()/__put_user()/etc. - the s
On Sun, Oct 13, 2019 at 12:59 PM Al Viro wrote:
>
> Re plotting: how strongly would you object against passing the range to
> user_access_end()? Powerpc folks have a very close analogue of stac/clac,
> currently buried inside their __get_user()/__put_user()/etc. - the same
> places where x86 does
On Sun, Oct 13, 2019 at 12:22:38PM -0700, Linus Torvalds wrote:
> On Sun, Oct 13, 2019 at 12:10 PM Al Viro wrote:
> >
> > No arguments re put_user_ex side of things... Below is a completely
> > untested patch for get_user_ex elimination (it seems to build, but that's
> > it); in any case, I would
On Sun, Oct 13, 2019 at 12:10 PM Al Viro wrote:
>
> No arguments re put_user_ex side of things... Below is a completely
> untested patch for get_user_ex elimination (it seems to build, but that's
> it); in any case, I would really like to see comments from x86 folks
> before it goes anywhere.
Pl
On Sun, Oct 13, 2019 at 11:43:57AM -0700, Linus Torvalds wrote:
> On Sun, Oct 13, 2019 at 11:13 AM Al Viro wrote:
> >
> > Umm... TBH, I wonder if we would be better off if restore_sigcontext()
> > (i.e. sigreturn()/rt_sigreturn()) would flat-out copy_from_user() the
> > entire[*] struct sigcontex
On Sun, Oct 13, 2019 at 11:13 AM Al Viro wrote:
>
> Umm... TBH, I wonder if we would be better off if restore_sigcontext()
> (i.e. sigreturn()/rt_sigreturn()) would flat-out copy_from_user() the
> entire[*] struct sigcontext into a local variable and then copied fields
> to pt_regs...
Probably o
On Thu, Oct 10, 2019 at 05:31:13PM -0700, Linus Torvalds wrote:
> So the code actually needs to properly return the error early, or
> initialize the segments that didn't get loaded to 0, or something.
>
> And when I posted that, Luto said "just get rid of the get_user_ex()
> entirely, instead of
On Thu, Oct 10, 2019 at 5:11 PM Al Viro wrote:
>
> On Thu, Oct 10, 2019 at 03:12:49PM -0700, Linus Torvalds wrote:
>
> > But I've not gotten around to rewriting those disgusting sequences to
> > the unsafe_get/put_user() model. I did look at it, and it requires
> > some changes exactly *because* t
On Thu, Oct 10, 2019 at 03:12:49PM -0700, Linus Torvalds wrote:
> On Thu, Oct 10, 2019 at 12:55 PM Al Viro wrote:
> >
> > Anyway, another question you way: what do you think of try/catch approaches
> > to __get_user() blocks, like e.g. restore_sigcontext() is doing?
>
> I'd rather have them conve
On Thu, Oct 10, 2019 at 12:55 PM Al Viro wrote:
>
> Anyway, another question you way: what do you think of try/catch approaches
> to __get_user() blocks, like e.g. restore_sigcontext() is doing?
I'd rather have them converted to our unsafe_get/put_user() instead.
We don't generate great code for
On Mon, Oct 07, 2019 at 09:24:17PM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
> wrote:
> >
> > Try the attached patch, and then count the number of "rorx"
> > instructions in the kernel. Hint: not many. On my personal config,
> > this triggers 15 times in the whol
On Tue, Oct 08, 2019 at 08:58:58PM +0100, Al Viro wrote:
> The difference is, they have separate "for read" and "for write" primitives
> and they want the range in their user_access_end() analogue. Separating
> the read and write isn't a problem for callers (we want them close to
> the actual mem
On Tue, Oct 08, 2019 at 08:58:58PM +0100, Al Viro wrote:
> That's powerpc. And while the constant-sized bits are probably pretty
> useless there as well, note the
> allow_read_from_user()/prevent_read_from_user()
> part. Looks suspiciously similar to user_access_begin()/user_access_end()...
>
On Mon, Oct 07, 2019 at 11:26:35AM -0700, Linus Torvalds wrote:
> The good news is that right now x86 is the only architecture that does
> that user_access_begin(), so we don't need to worry about anything
> else. Apparently the ARM people haven't had enough performance
> problems with the PAN bit
On Tue, Oct 08, 2019 at 05:38:31PM +0200, Greg KH wrote:
> On Tue, Oct 08, 2019 at 04:29:00PM +0100, Al Viro wrote:
> > On Tue, Oct 08, 2019 at 03:14:16PM +0200, Greg KH wrote:
> > > On Tue, Oct 08, 2019 at 05:57:12AM +0100, Al Viro wrote:
> > > >
> > > > OK... BTW, do you agree that the
On Tue, Oct 08, 2019 at 04:29:00PM +0100, Al Viro wrote:
> On Tue, Oct 08, 2019 at 03:14:16PM +0200, Greg KH wrote:
> > On Tue, Oct 08, 2019 at 05:57:12AM +0100, Al Viro wrote:
> > >
> > > OK... BTW, do you agree that the use of access_ok() in
> > > drivers/tty/n_hdlc.c:n_hdlc_tty_read() is wro
On Tue, Oct 08, 2019 at 03:14:16PM +0200, Greg KH wrote:
> On Tue, Oct 08, 2019 at 05:57:12AM +0100, Al Viro wrote:
> >
> > OK... BTW, do you agree that the use of access_ok() in
> > drivers/tty/n_hdlc.c:n_hdlc_tty_read() is wrong? It's used as an early
> > cutoff, so we don't bother waiting
On Tue, Oct 08, 2019 at 05:57:12AM +0100, Al Viro wrote:
>
> OK... BTW, do you agree that the use of access_ok() in
> drivers/tty/n_hdlc.c:n_hdlc_tty_read() is wrong? It's used as an early
> cutoff, so we don't bother waiting if user has passed an obviously bogus
> address. copy_to_user()
From: Linus Torvalds
> Sent: 07 October 2019 19:11
...
> I've been very close to just removing __get_user/__put_user several
> times, exactly because people do completely the wrong thing with them
> - not speeding code up, but making it unsafe and buggy.
They could do the very simple check that '
On Tue, Oct 8, 2019 at 1:30 AM Guenter Roeck wrote:
> m68k:
>
> c2p_iplan2.c:(.text+0x98): undefined reference to `c2p_unsupported'
>
> I don't know the status.
Fall-out from the (non)inline optimization. Patch available:
https://lore.kernel.org/lkml/20190927094708.11563-1-ge...@linux-m68k.org/
On Mon, Oct 07, 2019 at 09:14:51PM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
> wrote:
> >
> > Try the attached patch, and then count the number of "rorx"
> > instructions in the kernel. Hint: not many. On my personal config,
> > this triggers 15 times in the whol
On Mon, Oct 07, 2019 at 09:09:14PM -0700, Linus Torvalds wrote:
> > 1) cross-architecture user_access_begin_dont_use(): on everything
> > except x86 it's empty, on x86 - __uaccess_begin_nospec().
>
> No, just do a proper range check, and use user_access_begin()
>
> Stop trying to optimize that r
On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
wrote:
>
> Try the attached patch, and then count the number of "rorx"
> instructions in the kernel. Hint: not many. On my personal config,
> this triggers 15 times in the whole kernel build (not counting
> modules).
.. and four of them are in perf_ca
On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
wrote:
>
> Try the attached patch, and then count the number of "rorx"
> instructions in the kernel. Hint: not many. On my personal config,
> this triggers 15 times in the whole kernel build (not counting
> modules).
So here's a serious patch that doe
On Mon, Oct 7, 2019 at 8:29 PM Al Viro wrote:
>
> For x86? Sure, why not... Note, BTW, that for short constant-sized
> copies we *do* STAC/CLAC at the call site - see those
> __uaccess_begin_nospec();
> in raw_copy_{from,to}_user() in the switches...
Yeah, an that code almost ne
On Mon, Oct 07, 2019 at 11:26:35AM -0700, Linus Torvalds wrote:
> But on x86, if we move the STAC/CLAC out of the low-level copy
> routines and into the callers, we'll have a _lot_ of churn. I thought
> it would be mostly a "teach objtool" thing, but we have lots of
> different versions of it. Not
On 10/7/19 12:21 PM, Linus Torvalds wrote:
On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck wrote:
this patch causes all my sparc64 emulations to stall during boot. It causes
all alpha emulations to crash with [1a] and [1b] when booting from a virtual
disk, and one of the xtensa emulations to cras
On Mon, Oct 07, 2019 at 12:21:25PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck wrote:
> >
> > this patch causes all my sparc64 emulations to stall during boot. It causes
> > all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> > disk, and o
On Mon, Oct 7, 2019 at 12:49 PM Tony Luck wrote:
>
> If PSR.ac is set, we trap. If it isn't set, then model specific
> (though all implementations will
> trap for an unaligned access that crosses a 4K boundary).
Ok. At that point, setting AC unconditionally is the better model just
to get test co
On Mon, Oct 7, 2019 at 12:09 PM Linus Torvalds
wrote:
> Hmm? I thought ia64 did unaligneds ok.
If PSR.ac is set, we trap. If it isn't set, then model specific
(though all implementations will
trap for an unaligned access that crosses a 4K boundary).
Linux sets PSR.ac. Applications can use prctl(
On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck wrote:
>
> this patch causes all my sparc64 emulations to stall during boot. It causes
> all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> disk, and one of the xtensa emulations to crash with [2].
So I think your alpha emul
On Mon, Oct 7, 2019 at 11:36 AM Tony Luck wrote:
>
> Late to this party ,,, but my ia64 console today is full of:
Hmm? I thought ia64 did unaligneds ok.
But regardless, this is my current (as yet untested) patch. This is
not the big user access cleanup that I hope Al will do, this is just a
"ok
On Mon, Oct 7, 2019 at 11:28 AM Linus Torvalds
wrote:
>
> On Sun, Oct 6, 2019 at 8:11 PM Linus Torvalds
> wrote:
> >
> > >
> > > The last two should just do user_access_begin()/user_access_end()
> > > instead of access_ok(). __copy_to_user_inatomic() has very few callers
> > > as well:
> >
> >
On Sun, Oct 6, 2019 at 8:11 PM Linus Torvalds
wrote:
>
> >
> > The last two should just do user_access_begin()/user_access_end()
> > instead of access_ok(). __copy_to_user_inatomic() has very few callers as
> > well:
>
> Yeah, good points.
Looking at it some more this morning, I think it's actu
On Mon, Oct 07, 2019 at 11:13:27AM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2019 at 10:34 AM Al Viro wrote:
> >
> > Tangentially related: copy_regster_to_user() and copy_regset_from_user().
>
> Not a worry. It's not performance-critical code, and if it ever is, it
> needs to be rewritten any
On Mon, Oct 7, 2019 at 10:34 AM Al Viro wrote:
>
> Tangentially related: copy_regster_to_user() and copy_regset_from_user().
Not a worry. It's not performance-critical code, and if it ever is, it
needs to be rewritten anyway.
> The former variant tends to lead to few calls
> of __copy_{to,from}
On Mon, Oct 7, 2019 at 8:40 AM David Laight wrote:
>
> You don't really want an extra access_ok() for every 'word' of a copy.
Yes you do.
> Some copies have to be done a word at a time.
Completely immaterial. If you can't see the access_ok() close to the
__get/put_user(), you have a bug.
Plus
On Sun, Oct 06, 2019 at 08:11:42PM -0700, Linus Torvalds wrote:
> > So do we want to bother with separation between raw_copy_to_user() and
> > unsafe_copy_to_user()? After all, __copy_to_user() also has only few
> > callers, most of them in arch/*
>
> No, you're right. Just switch over.
>
> > I
> From: Linus Torvalds
> Sent: 07 October 2019 04:12
...
> In this case, I think it's done a few callers up in i915_gem_pread_ioctl():
>
> if (!access_ok(u64_to_user_ptr(args->data_ptr),
>args->size))
> return -EFAULT;
>
> but honestly, trying to op
Hi Max,
On 10/6/19 9:04 PM, Max Filippov wrote:
On Sun, Oct 6, 2019 at 3:25 PM Guenter Roeck wrote:
this patch causes all my sparc64 emulations to stall during boot. It causes
all alpha emulations to crash with [1a] and [1b] when booting from a virtual
disk, and one of the xtensa emulations to
On Sun, Oct 6, 2019 at 3:25 PM Guenter Roeck wrote:
> this patch causes all my sparc64 emulations to stall during boot. It causes
> all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> disk, and one of the xtensa emulations to crash with [2].
[...]
> [2]
>
> Unable to h
On Sun, Oct 6, 2019 at 7:30 PM Guenter Roeck wrote:
>
> > Mind humoring me and trying that on your alpha machine (or emulator,
> > or whatever)?
>
> Here you are. This is with v5.4-rc2 and your previous patch applied
> on top.
>
> / # ./mmtest
> Unable to handle kernel paging request at virtual ad
On Sun, Oct 6, 2019 at 7:50 PM Al Viro wrote:
>
> Out of those, only __copy_to_user_inatomic(), __copy_to_user(),
> _copy_to_user() and iov_iter.c:copyout() can be called on
> any architecture.
>
> The last two should just do user_access_begin()/user_access_end()
> instead of access_ok(). __copy_
On Sun, Oct 06, 2019 at 07:06:19PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 6:24 PM Al Viro wrote:
> >
> > Ugh... I wonder if it would be better to lift STAC/CLAC out of
> > raw_copy_to_user(), rather than trying to reinvent its guts
> > in readdir.c...
>
> Yeah, I suspect that's th
On 10/6/19 6:17 PM, Linus Torvalds wrote:
On Sun, Oct 6, 2019 at 5:04 PM Guenter Roeck wrote:
[ ... ]
And yes, I'll fix that name copy loop in filldir to align the
destination first, *but* if I'm right, it means that something like
this should also likely cause issues:
#define _GNU_SOURCE
On Sun, Oct 6, 2019 at 6:24 PM Al Viro wrote:
>
> Ugh... I wonder if it would be better to lift STAC/CLAC out of
> raw_copy_to_user(), rather than trying to reinvent its guts
> in readdir.c...
Yeah, I suspect that's the best option.
Do something like
- lift STAC/CLAC out of raw_copy_to_user
On Sun, Oct 06, 2019 at 06:17:02PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 5:04 PM Guenter Roeck wrote:
> >
> > All my alpha, sparc64, and xtensa tests pass with the attached patch
> > applied on top of v5.4-rc2. I didn't test any others.
>
> Okay... I really wish my guess had been
On Sun, Oct 6, 2019 at 5:04 PM Guenter Roeck wrote:
>
> All my alpha, sparc64, and xtensa tests pass with the attached patch
> applied on top of v5.4-rc2. I didn't test any others.
Okay... I really wish my guess had been wrong.
Because fixing filldir64 isn't the problem. I can come up with
multi
On Sun, Oct 06, 2019 at 04:06:16PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck wrote:
> >
> > this patch causes all my sparc64 emulations to stall during boot. It causes
> > all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> > disk, and o
On 10/6/19 4:35 PM, Linus Torvalds wrote:
[ ... ]
Anyway, let me think about this, but just for testing, does the
attached patch make any difference? It's not the right thing in
general (and most definitely not on x86), but for testing whether this
is about unaligned accesses it might work.
A
On Sun, Oct 6, 2019 at 4:06 PM Linus Torvalds
wrote:
>
> Ho humm. I've run variations of that patch over a few years on x86,
> but obviously not on alpha/sparc.
Oooh.
I wonder... This may be the name string copy loop. And it's special in
that the result may not be aligned.
Now, a "__put_user()"
On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck wrote:
>
> this patch causes all my sparc64 emulations to stall during boot. It causes
> all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> disk, and one of the xtensa emulations to crash with [2].
Ho humm. I've run variatio
On Sat, May 21, 2016 at 09:59:07PM -0700, Linus Torvalds wrote:
> We really should avoid the "__{get,put}_user()" functions entirely,
> because they can easily be mis-used and the original intent of being
> used for simple direct user accesses no longer holds in a post-SMAP/PAN
> world.
>
> Manual
58 matches
Mail list logo
