Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-17 Thread Al Viro
On Sat, Jun 09, 2018 at 06:10:51AM +0100, Al Viro wrote: > On Fri, Jun 08, 2018 at 11:57:06AM -0700, Linus Torvalds wrote: > > I'm obviously biased since I asked for this, but: > > > > On Fri, Jun 8, 2018 at 11:48 AM Al Viro wrote: > > > > > > 33 files changed, 135 insertions(+), 180

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-17 Thread Al Viro
On Sat, Jun 09, 2018 at 06:10:51AM +0100, Al Viro wrote: > On Fri, Jun 08, 2018 at 11:57:06AM -0700, Linus Torvalds wrote: > > I'm obviously biased since I asked for this, but: > > > > On Fri, Jun 8, 2018 at 11:48 AM Al Viro wrote: > > > > > > 33 files changed, 135 insertions(+), 180

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-09 Thread Al Viro
On Sat, Jun 09, 2018 at 06:10:51AM +0100, Al Viro wrote: > That leaves > * anon_inode_getfile() - converts to similar form, at the price of > ihold done slightly earlier, so that failure exit needs a (non-final, i.e. > very cheap) iput() we currently avoid. Not a problem. > *

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-09 Thread Al Viro
On Sat, Jun 09, 2018 at 06:10:51AM +0100, Al Viro wrote: > That leaves > * anon_inode_getfile() - converts to similar form, at the price of > ihold done slightly earlier, so that failure exit needs a (non-final, i.e. > very cheap) iput() we currently avoid. Not a problem. > *

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-08 Thread Al Viro
On Fri, Jun 08, 2018 at 11:57:06AM -0700, Linus Torvalds wrote: > I'm obviously biased since I asked for this, but: > > On Fri, Jun 8, 2018 at 11:48 AM Al Viro wrote: > > > > 33 files changed, 135 insertions(+), 180 deletions(-) > > this already looks nice. > > I'll go through the individual

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-08 Thread Al Viro
On Fri, Jun 08, 2018 at 11:57:06AM -0700, Linus Torvalds wrote: > I'm obviously biased since I asked for this, but: > > On Fri, Jun 8, 2018 at 11:48 AM Al Viro wrote: > > > > 33 files changed, 135 insertions(+), 180 deletions(-) > > this already looks nice. > > I'll go through the individual

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-08 Thread Linus Torvalds
I'm obviously biased since I asked for this, but: On Fri, Jun 8, 2018 at 11:48 AM Al Viro wrote: > > 33 files changed, 135 insertions(+), 180 deletions(-) this already looks nice. I'll go through the individual patches and see if there's anything there that raises my hackles. Silence will

Re: [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-08 Thread Linus Torvalds
I'm obviously biased since I asked for this, but: On Fri, Jun 8, 2018 at 11:48 AM Al Viro wrote: > > 33 files changed, 135 insertions(+), 180 deletions(-) this already looks nice. I'll go through the individual patches and see if there's anything there that raises my hackles. Silence will

[RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-08 Thread Al Viro
->atomic_open() calling conventions are nasty; we have two bits of state ("has file gotten past ->open()" and "have we created a new file here") passed by reference, with rather brittle logics in the callers. In some error cases do_last() et.al. end up doing a full-blow fput() (and

[RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends

2018-06-08 Thread Al Viro
->atomic_open() calling conventions are nasty; we have two bits of state ("has file gotten past ->open()" and "have we created a new file here") passed by reference, with rather brittle logics in the callers. In some error cases do_last() et.al. end up doing a full-blow fput() (and