Re: [git pull] uaccess-related bits of vfs.git

On Sun, May 14, 2017 at 08:13:56PM +0200, Ingo Molnar wrote: > I'd say that the CLAC/STAC addition pretty much killed any argument in favor > of > "optimized" __get_user() code, so I'd be very happy to see these interfaces > gone > altogether. You and everybody else - these interfaces suck.

Re: [git pull] uaccess-related bits of vfs.git

On Sun, May 14, 2017 at 08:13:56PM +0200, Ingo Molnar wrote: > I'd say that the CLAC/STAC addition pretty much killed any argument in favor > of > "optimized" __get_user() code, so I'd be very happy to see these interfaces > gone > altogether. You and everybody else - these interfaces suck.

Re: [git pull] uaccess-related bits of vfs.git

* Linus Torvalds wrote: > On Fri, May 12, 2017 at 11:57 PM, Al Viro wrote: > > > > First, some stats: there's a thousand-odd callers of __get_user(). Out of > > those, about 70% are in arch/, mostly in sigframe-related code. > > Sure.

Re: [git pull] uaccess-related bits of vfs.git

* Linus Torvalds wrote: > On Fri, May 12, 2017 at 11:57 PM, Al Viro wrote: > > > > First, some stats: there's a thousand-odd callers of __get_user(). Out of > > those, about 70% are in arch/, mostly in sigframe-related code. > > Sure. And they can be trivially converted, and none of them

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 01:52:29PM -0700, Linus Torvalds wrote: > I wouldn't change the existing "memdup_user()" interface itself, but > if there really are users that can validly pass in a maxbyte value, > why not add a new helper: > > void *memdup_user_limit(userptr, nmember, nsize, maxsize);

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 01:52:29PM -0700, Linus Torvalds wrote: > I wouldn't change the existing "memdup_user()" interface itself, but > if there really are users that can validly pass in a maxbyte value, > why not add a new helper: > > void *memdup_user_limit(userptr, nmember, nsize, maxsize);

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 1:37 PM, Al Viro wrote: > > That's a valid point and it might apply to memdup_user() callers out there. > Potential variants: > * add an explicit upper bound on the size and turn that into > memdup_user() (and check that all memdup_user()

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 1:37 PM, Al Viro wrote: > > That's a valid point and it might apply to memdup_user() callers out there. > Potential variants: > * add an explicit upper bound on the size and turn that into > memdup_user() (and check that all memdup_user() callers are bounded). >

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 10:32:31PM +0200, Geert Uytterhoeven wrote: > You better run that one through linux-spi, to avoid conflicts, cfr. > https://patchwork.kernel.org/patch/9714993/ What I'm going to do is never-rebased #for-spi (well, never after -rc1) merged into #work.uaccess and proposed

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 10:32:31PM +0200, Geert Uytterhoeven wrote: > You better run that one through linux-spi, to avoid conflicts, cfr. > https://patchwork.kernel.org/patch/9714993/ What I'm going to do is never-rebased #for-spi (well, never after -rc1) merged into #work.uaccess and proposed

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote: > From: Linus Torvalds > Date: Tue, 24 Mar 2015 10:42:18 -0700 > > > > So I'd suggest we should just do a wholesale replacement of > > __copy_to/from_user() with the non-underlined cases. Then, we could

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote: > From: Linus Torvalds > Date: Tue, 24 Mar 2015 10:42:18 -0700 > > > > So I'd suggest we should just do a wholesale replacement of > > __copy_to/from_user() with the non-underlined cases. Then, we could > > switch insividual ones

Re: [git pull] uaccess-related bits of vfs.git

Hi Al, On Sat, May 13, 2017 at 10:08 PM, Al Viro wrote: > On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote: > >> FWIW, just this cycle (this one I remembered off-hand, there might be >> more): > > And looking through my queue (will be pushed to -next as soon as

Re: [git pull] uaccess-related bits of vfs.git

Hi Al, On Sat, May 13, 2017 at 10:08 PM, Al Viro wrote: > On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote: > >> FWIW, just this cycle (this one I remembered off-hand, there might be >> more): > > And looking through my queue (will be pushed to -next as soon as -rc1 goes > out): > >

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote: > FWIW, just this cycle (this one I remembered off-hand, there might be > more): And looking through my queue (will be pushed to -next as soon as -rc1 goes out): commit 87fb4c8c103a4cdf17fead4aba58e96940a19a09 Author: Al Viro

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote: > FWIW, just this cycle (this one I remembered off-hand, there might be > more): And looking through my queue (will be pushed to -next as soon as -rc1 goes out): commit 87fb4c8c103a4cdf17fead4aba58e96940a19a09 Author: Al Viro Date: Thu

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote: > > We should probably even consider looking at __get_user/__put_user(). > > Few of them are actually performance-critical. > > Look at that date. It's over two years ago. In the intervening two > years, how many of those conversions

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote: > > We should probably even consider looking at __get_user/__put_user(). > > Few of them are actually performance-critical. > > Look at that date. It's over two years ago. In the intervening two > years, how many of those conversions

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 08:11:42PM +0100, Al Viro wrote: > It's not impossible to review; the problem is in figuring out which codepaths > are hot enough to worry about them. And I'm even more convinced that > bulk search-and-replace is the right approach here; we probably _can_ get

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 08:11:42PM +0100, Al Viro wrote: > It's not impossible to review; the problem is in figuring out which codepaths > are hot enough to worry about them. And I'm even more convinced that > bulk search-and-replace is the right approach here; we probably _can_ get

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote: > On Sat, May 13, 2017 at 11:04 AM, Al Viro wrote: > > > > > > My point is, this stuff needs looking at. > > No. > > You don't have a point. I've tried to explain that there's no > performance difference,

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote: > On Sat, May 13, 2017 at 11:04 AM, Al Viro wrote: > > > > > > My point is, this stuff needs looking at. > > No. > > You don't have a point. I've tried to explain that there's no > performance difference, and there is no way in

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:26:56PM +0100, Al Viro wrote: > BTW, even in arch/* they tend to nest. E.g. arch/alpha has 133 callers > total. Distribution by files: > 35 arch/alpha/kernel/osf_sys.c > 92 arch/alpha/kernel/signal.c > 1 arch/alpha/kernel/traps.c > 4

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:26:56PM +0100, Al Viro wrote: > BTW, even in arch/* they tend to nest. E.g. arch/alpha has 133 callers > total. Distribution by files: > 35 arch/alpha/kernel/osf_sys.c > 92 arch/alpha/kernel/signal.c > 1 arch/alpha/kernel/traps.c > 4

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 11:04 AM, Al Viro wrote: > > > My point is, this stuff needs looking at. No. You don't have a point. I've tried to explain that there's no performance difference, and there is no way in hell that the current "__" versions are better. So what's

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 11:04 AM, Al Viro wrote: > > > My point is, this stuff needs looking at. No. You don't have a point. I've tried to explain that there's no performance difference, and there is no way in hell that the current "__" versions are better. So what's the point in looking? All

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:04:13PM +0100, Al Viro wrote: > My point is, this stuff needs looking at. Even this quick look in arch/x86 > has shown several fairly different classes of that stuff, probably needing > different approaches. And that - on an architecture that had tons of TLC > around

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:04:13PM +0100, Al Viro wrote: > My point is, this stuff needs looking at. Even this quick look in arch/x86 > has shown several fairly different classes of that stuff, probably needing > different approaches. And that - on an architecture that had tons of TLC > around

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 10:18:22AM -0700, Linus Torvalds wrote: > > x86 actually tends to use get_user_ex/put_user_ex instead. > > Yes. Because anybody who *really* cared about performance will have > converted already. The real cost has been stac/clac for a few years > now. On x86. Which has

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 10:18:22AM -0700, Linus Torvalds wrote: > > x86 actually tends to use get_user_ex/put_user_ex instead. > > Yes. Because anybody who *really* cared about performance will have > converted already. The real cost has been stac/clac for a few years > now. On x86. Which has

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 10:00 AM, Al Viro wrote: > On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote: >> > IOW, we have >> > * most of users in arch/* (heavily dominated by signal-related >> > code, >> > both loads and stores). Those need careful

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 10:00 AM, Al Viro wrote: > On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote: >> > IOW, we have >> > * most of users in arch/* (heavily dominated by signal-related >> > code, >> > both loads and stores). Those need careful massage; maybe unsafe-based

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 06:00:56PM +0100, Al Viro wrote: > > But I don't see the excuse for not just doing it. If nobody notices, > > it's an obvious improvement. And if somebody *does* notice, we know > > how to do it properly with unsafe_xyz_user(), because "__xyz_user()" > > most definitely

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 06:00:56PM +0100, Al Viro wrote: > > But I don't see the excuse for not just doing it. If nobody notices, > > it's an obvious improvement. And if somebody *does* notice, we know > > how to do it properly with unsafe_xyz_user(), because "__xyz_user()" > > most definitely

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote: > > IOW, we have > > * most of users in arch/* (heavily dominated by signal-related code, > > both loads and stores). Those need careful massage; maybe unsafe-based > > solution, maybe something else, but it's obviously

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote: > > IOW, we have > > * most of users in arch/* (heavily dominated by signal-related code, > > both loads and stores). Those need careful massage; maybe unsafe-based > > solution, maybe something else, but it's obviously

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 02:05:27PM +0200, Adam Borowski wrote: > As someone from the peanuts gallery, I took a look for __put_user() in my > usual haunt, drivers/tty/vt/ > > * use 1: con_[gs]et_trans_*(): > Copies a linear array of 256 bytes/shorts, one by one. > The obvious patch has 9

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 02:05:27PM +0200, Adam Borowski wrote: > As someone from the peanuts gallery, I took a look for __put_user() in my > usual haunt, drivers/tty/vt/ > > * use 1: con_[gs]et_trans_*(): > Copies a linear array of 256 bytes/shorts, one by one. > The obvious patch has 9

Re: [git pull] uaccess-related bits of vfs.git

Oops. *Really* adding the x86 guys now. Blush. Linus On Sat, May 13, 2017 at 9:15 AM, Linus Torvalds wrote: > On Fri, May 12, 2017 at 11:57 PM, Al Viro wrote: >> >> First, some stats: there's a thousand-odd callers of

Re: [git pull] uaccess-related bits of vfs.git

Oops. *Really* adding the x86 guys now. Blush. Linus On Sat, May 13, 2017 at 9:15 AM, Linus Torvalds wrote: > On Fri, May 12, 2017 at 11:57 PM, Al Viro wrote: >> >> First, some stats: there's a thousand-odd callers of __get_user(). Out of >> those, about 70% are in arch/, mostly

Re: [git pull] uaccess-related bits of vfs.git

On Fri, May 12, 2017 at 11:57 PM, Al Viro wrote: > > First, some stats: there's a thousand-odd callers of __get_user(). Out of > those, about 70% are in arch/, mostly in sigframe-related code. Sure. And they can be trivially converted, and none of them should care at

Re: [git pull] uaccess-related bits of vfs.git

On Fri, May 12, 2017 at 11:57 PM, Al Viro wrote: > > First, some stats: there's a thousand-odd callers of __get_user(). Out of > those, about 70% are in arch/, mostly in sigframe-related code. Sure. And they can be trivially converted, and none of them should care at all. > IOW, we have >

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 8:05 AM, Adam Borowski wrote: > On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote: >> On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: >> > But the *first* thing I'd like to do would be to just get rid of >> > __get_user/__put_user

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 8:05 AM, Adam Borowski wrote: > On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote: >> On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: >> > But the *first* thing I'd like to do would be to just get rid of >> > __get_user/__put_user as a thing. It

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote: > On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: > > But the *first* thing I'd like to do would be to just get rid of > > __get_user/__put_user as a thing. It really does generate nasty code, > > and we might as well just

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote: > On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: > > But the *first* thing I'd like to do would be to just get rid of > > __get_user/__put_user as a thing. It really does generate nasty code, > > and we might as well just

Re: [git pull] uaccess-related bits of vfs.git

On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: > So I should have asked earlier, but I was feeling rather busy during > the early merge window.. > So I'm actually more interested to hear if you have any pending work > on cleaning up the __get/put_user() mess we have. Is that on

Re: [git pull] uaccess-related bits of vfs.git

On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: > So I should have asked earlier, but I was feeling rather busy during > the early merge window.. > So I'm actually more interested to hear if you have any pending work > on cleaning up the __get/put_user() mess we have. Is that on

Re: [git pull] uaccess-related bits of vfs.git

So I should have asked earlier, but I was feeling rather busy during the early merge window.. On Sun, Apr 30, 2017 at 8:45 PM, Al Viro wrote: > uaccess unification pile. It's _not_ the end of uaccess work, but > the next batch of that will go into the next

Re: [git pull] uaccess-related bits of vfs.git

So I should have asked earlier, but I was feeling rather busy during the early merge window.. On Sun, Apr 30, 2017 at 8:45 PM, Al Viro wrote: > uaccess unification pile. It's _not_ the end of uaccess work, but > the next batch of that will go into the next cycle. This one mostly takes

[git pull] uaccess-related bits of vfs.git

uaccess unification pile. It's _not_ the end of uaccess work, but the next batch of that will go into the next cycle. This one mostly takes copy_from_user() and friends out of arch/* and gets the zero-padding behaviour in sync for all architectures. Dealing with the

[git pull] uaccess-related bits of vfs.git

uaccess unification pile. It's _not_ the end of uaccess work, but the next batch of that will go into the next cycle. This one mostly takes copy_from_user() and friends out of arch/* and gets the zero-padding behaviour in sync for all architectures. Dealing with the