On Wed, Apr 05, 2017 at 11:44:23AM -0700, Tony Luck wrote:
> On Wed, Apr 5, 2017 at 1:08 AM, Al Viro wrote:
> > ... and sure enough, on generic kernel (CONFIG_ITANIUM) that yields a nice
> > shiny oops at precisely that insn.
>
> The right fix here might be to delete all the CONFIG_ITANIUM paths.
On Wed, Apr 5, 2017 at 1:08 AM, Al Viro wrote:
> ... and sure enough, on generic kernel (CONFIG_ITANIUM) that yields a nice
> shiny oops at precisely that insn.
The right fix here might be to delete all the CONFIG_ITANIUM paths. I
doubt that anyone is still running upstream kernels on Merced CPUs
On Wed, Apr 05, 2017 at 06:05:08AM +0100, Al Viro wrote:
> Speaking of ia64: copy_user.S contains the following oddity:
> 2:
> EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
> (p16) ld8 val2[0]=[src2],16
>
> src1 is 16-byte aligned, src2 is src1 + 8.
>
> What guarantees that we can't rac
On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:
> And again, metag and ia64 parts are simply not there - both architectures
> zero-pad in __copy_from_user_inatomic() and that really needs fixing.
> In case of metag there's __copy_to_user() breakage as well, AFAICS, and
> I've been unable
On Tue, Apr 04, 2017 at 01:26:29PM -0700, Max Filippov wrote:
> On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:
> > I hope that infrastructure part is stable enough to put it into
> > never-rebased
> > state. Some of per-architecture branches might be even done right; however,
> > most o
On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:
> I hope that infrastructure part is stable enough to put it into never-rebased
> state. Some of per-architecture branches might be even done right; however,
> most of them got no testing whatsoever, so any help with testing (as well
> as "A
On 29/03/17 06:57, Al Viro wrote:
> The series lives in git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
> in #work.uaccess. It's based at 4.11-rc1. Infrastructure is in
> #uaccess.stem, then it splits into per-architecture branches (uaccess.),
> Comments, review, testing, replacement
On Thu, Mar 30, 2017 at 05:21:32PM -0700, Kees Cook wrote:
> On Tue, Mar 28, 2017 at 10:57 PM, Al Viro wrote:
> > At the moment I have that conversion done for everything except ia64 and
> > metag. Once everything is converted, I'll remove ARCH_HAS_RAW_COPY_USER
> > and make generic stuff uncondi
On Tue, Mar 28, 2017 at 10:57 PM, Al Viro wrote:
> We have several primitives for bulk kernel<->userland copying.
> That stuff lives in various asm/uaccess.h, with serious code duplication
> _and_ seriously inconsistent semantics.
>
> That code has grown a lot of cruft and more tha
On Thu, Mar 30, 2017 at 01:59:58PM -0700, Linus Torvalds wrote:
> On Thu, Mar 30, 2017 at 1:40 PM, Vineet Gupta
> wrote:
> >
> > So it's a mix bag really. Maybe we need some better directed test to really
> > drill
> > it down.
>
> As mentioned inn the discussion about ARM, I seriously doubt tha
On Thu, Mar 30, 2017 at 12:19:35PM -0700, Linus Torvalds wrote:
> On Thu, Mar 30, 2017 at 12:10 PM, Al Viro wrote:
> >
> > That they very definitely should not. And not because of access_ok() or
> > might_fault() - this is one place where zero-padding is absolutely wrong.
> > So unless you are go
On Thu, Mar 30, 2017 at 1:40 PM, Vineet Gupta
wrote:
>
> So it's a mix bag really. Maybe we need some better directed test to really
> drill
> it down.
As mentioned inn the discussion about ARM, I seriously doubt that the
inlining will even be noticeable compared to other effects here.
The case
On 03/29/2017 05:27 PM, Linus Torvalds wrote:
> On Wed, Mar 29, 2017 at 5:02 PM, Vineet Gupta
> wrote:
>>
>> I guess I can in next day or two - but mind you the inline version for ARC
>> is kind
>> of special vs. other arches. We have this "manual" constant propagation to
>> elide
>> the unrolle
On Thu, Mar 30, 2017 at 12:10 PM, Al Viro wrote:
>
> That they very definitely should not. And not because of access_ok() or
> might_fault() - this is one place where zero-padding is absolutely wrong.
> So unless you are going to take it out of copy_from_user() and pray
> that random shit ioctls
On Thu, Mar 30, 2017 at 11:59:16AM -0700, Linus Torvalds wrote:
> But regardless of that, I think you're being silly to even look at the
> iovec code. That code simply *isn't* critical enough that one or two
> extra instructions matter.
>
> Show me profiles to the contrary. I dare you.
>
> Those
On Thu, Mar 30, 2017 at 11:54 AM, Al Viro wrote:
>
> Not even that - again, it will happily trigger page faults unless the
> caller disables those. __copy_from_user_I_know_what_I_am_doing()?
That's a horrible name. Everybody always thinks they know what they are doing.
There's a reason I called
On Thu, Mar 30, 2017 at 11:48 AM, Al Viro wrote:
>
> This is not going into the tree - it's just a "let's check your
> theory about might_fault() overhead being the source of slowdown
> you are seeing" quick-and-dirty patch.
Note that for cached hdparm reads, I suspect a *much* bigger effects
tha
On Thu, Mar 30, 2017 at 07:48:24PM +0100, Al Viro wrote:
> BTW, ..._inatomic is a very unfortunate name, IMO - it's *not* safe
> to use in atomic contexts as-is, to start with; the caller needs to take
> care of pagefault_disable(). If anything, __copy_from_user_nofault() would
> probably be bett
On Thu, Mar 30, 2017 at 10:18:23AM -0700, Linus Torvalds wrote:
> This is all going in the wrong direction entirely.
This is not going into the tree - it's just a "let's check your
theory about might_fault() overhead being the source of slowdown
you are seeing" quick-and-dirty patch.
Speaking of
On Thu, Mar 30, 2017 at 9:43 AM, Al Viro wrote:
> On Thu, Mar 30, 2017 at 05:22:41PM +0100, Russell King - ARM Linux wrote:
> How would the following affect things?
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index e68604ae3ced..d24d338f0682 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_ite
On Thu, Mar 30, 2017 at 05:22:41PM +0100, Russell King - ARM Linux wrote:
> On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:
> > Comments, review, testing, replacement patches, etc. are very welcome.
>
> I've given this a spin, and it appears to work (in that the box boots).
>
> Kernel si
On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:
> Comments, review, testing, replacement patches, etc. are very welcome.
I've given this a spin, and it appears to work (in that the box boots).
Kernel size wise:
textdata bss dec hex filename
8020229 3014220 10243276
On Wed, Mar 29, 2017 at 04:43:05PM -0700, Linus Torvalds wrote:
> > As for __copy_in_user()... I'm not sure we want to keep it in the long run -
>
> I agree, it's probably not worth it at all.
>
> In fact, I suspect none of the "__copy_.*_user()" versions are worth
> it, and we should strive to
On Thu, Mar 30, 2017 at 02:32:12PM +0200, Martin Schwidefsky wrote:
> On Wed, 29 Mar 2017 06:57:06 +0100
> Al Viro wrote:
>
> > The patchset currently in vfs.git#work.uaccess is the result;
> > there's more work to do, but it takes care of a large part of the
> > problems. About 2.8KLoc remo
[cc linux-kernel]
On Thu, Mar 30, 2017 at 4:25 PM, Alexey Dobriyan wrote:
>> void *to, const void *from, unsigned long size
>
> Type of the last argument should be "unsigned int",
> for the following reasons:
> * on x86_64 actual copying is done as 32-bit: types flip to "unsigned"
> at some poi
On Wed, 29 Mar 2017 06:57:06 +0100
Al Viro wrote:
> The patchset currently in vfs.git#work.uaccess is the result;
> there's more work to do, but it takes care of a large part of the
> problems. About 2.8KLoc removed, a lot of cruft is gone and semantics
> is hopefully in sync now. All but
On Wed, Mar 29, 2017 at 05:27:40PM -0700, Linus Torvalds wrote:
> The basic "__" versions still do that constant-size thing, but they
> really are questionable. Exactly because it's just the "__" versions -
> the *regular* "copy_to/from_user()" is an unconditional function call,
> because inlining
On Wed, Mar 29, 2017 at 5:02 PM, Vineet Gupta
wrote:
>
> I guess I can in next day or two - but mind you the inline version for ARC is
> kind
> of special vs. other arches. We have this "manual" constant propagation to
> elide
> the unrolled LD/ST for 1-15 byte stragglers, when @sz is constant.
On 03/29/2017 04:42 PM, Al Viro wrote:
> On Wed, Mar 29, 2017 at 02:14:22PM -0700, Vineet Gupta wrote:
>
>>> BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a
>>> win.
>>
>> Just to be clear, your series was doing this for everyone.
>
> Huh? It's just that most of archite
On Wed, Mar 29, 2017 at 4:09 PM, Al Viro wrote:
>
> IMO that's a separate series. For now I would be bloody happy if we got
> * arch-dependent asm fixes out of the way
> * everything consolidated outside of arch/*
> * arch/*/include/uaccess*.h simplified.
Sure, I agree.
On Wed, Mar 29, 2017 at 02:14:22PM -0700, Vineet Gupta wrote:
> > BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a
> > win.
>
> Just to be clear, your series was doing this for everyone.
Huh? It's just that most of architectures *were* inlining that;
arc change was unin
On Wed, Mar 29, 2017 at 02:24:37PM -0700, Linus Torvalds wrote:
> I think one of the biggest problems with our current uaccess.h mess is
> just how illegible the header files are, and the
> INLINE_COPY_{TO,FROM}_USER thing is not helping.
>
> I think it would be much better if the header file jus
On Wed, Mar 29, 2017 at 2:03 PM, Al Viro wrote:
>
> it's not as if having the possibility to inline them
> would really complicate the generic side of things...
I disagree.
I think one of the biggest problems with our current uaccess.h mess is
just how illegible the header files are, and the
INL
On 03/29/2017 01:29 PM, Al Viro wrote:
> On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote:
>
>> Hi Al,
>>
>> Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely
>> due to
>> existing 2 variants (inline/out-of-line) we already have.
>> I've added a patch for tha
On Wed, Mar 29, 2017 at 01:37:30PM -0700, Linus Torvalds wrote:
> On Wed, Mar 29, 2017 at 1:29 PM, Al Viro wrote:
> >
> > BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a
> > win.
>
> I would suggest against it.
>
> The only part I think is worth inlining is the compile
On Wed, Mar 29, 2017 at 1:29 PM, Al Viro wrote:
>
> BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a win.
I would suggest against it.
The only part I think is worth inlining is the compile time size
checks for kasan - and that only because of the obvious "sizes are
consta
On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote:
> Hi Al,
>
> Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely
> due to
> existing 2 variants (inline/out-of-line) we already have.
> I've added a patch for that (attached too) - boot tested the series on ARC
On 03/28/2017 10:57 PM, Al Viro wrote:
> We have several primitives for bulk kernel<->userland copying.
> That stuff lives in various asm/uaccess.h, with serious code duplication
> _and_ seriously inconsistent semantics.
>
> That code has grown a lot of cruft and more than a few bugs.
>
We have several primitives for bulk kernel<->userland copying.
That stuff lives in various asm/uaccess.h, with serious code duplication
_and_ seriously inconsistent semantics.
That code has grown a lot of cruft and more than a few bugs.
Some got caught and fixed last year, but some
39 matches
Mail list logo
