On Mon, 4 May 2015 06:11:29 +0100 Al Viro wrote:
> On Fri, Apr 24, 2015 at 02:42:03PM +0100, Al Viro wrote:
>
> > That avoids this spin_lock() on each absolute symlink at the price of extra
> > 32 bits in struct nameidata. It looks like doing on-demand reallocation
> > of nd->stack is the right
On Fri, Apr 24, 2015 at 02:42:03PM +0100, Al Viro wrote:
> That avoids this spin_lock() on each absolute symlink at the price of extra
> 32 bits in struct nameidata. It looks like doing on-demand reallocation
> of nd->stack is the right way to go anyway, so the pressure on nameidata size
> is goi
On Fri, Apr 24, 2015 at 04:35:34PM +1000, NeilBrown wrote:
> > * path_init() arranges for that to be true in the beginning of the walk.
> >
> > * symlinks aside, walk_component() preserves that.
> > + normal name components go through lookup_fast(), where we have
> > __d_lookup_rcu() fin
On Thu, 23 Apr 2015 19:07:55 +0100 Al Viro wrote:
> On Thu, Apr 23, 2015 at 05:45:44PM +1000, NeilBrown wrote:
>
> > follow_link calls link_path_walk -> walk_component -> lookup_fast which
> > sets
> > nd->seq. Is that not enough? I guess not when nd_jump_link is called. Is
> > that what I
On Thu, Apr 23, 2015 at 05:45:44PM +1000, NeilBrown wrote:
> follow_link calls link_path_walk -> walk_component -> lookup_fast which sets
> nd->seq. Is that not enough? I guess not when nd_jump_link is called. Is
> that what I missed?
No. Potential nd_jump_link() callers are just refusing to
On Wed, 22 Apr 2015 22:05:53 +0100 Al Viro wrote:
> On Wed, Apr 22, 2015 at 09:12:38PM +0100, Al Viro wrote:
> > On Wed, Apr 22, 2015 at 07:07:59PM +0100, Al Viro wrote:
> > > And one more: may_follow_link() is now potentially oopsable. Look:
> > > suppose
> > > we've reached the link in RCU mo
On Tue, Apr 21, 2015 at 10:20:07PM +0100, Al Viro wrote:
> I agree that unlazy_walk() attempted when walking a symlink ought to fail
> with -ECHILD; we can't legitimize the symlink itself, so once we are out
> of RCU mode, there's nothing to hold the inode of symlink (and its body)
> from getting
On Wed, Apr 22, 2015 at 09:12:38PM +0100, Al Viro wrote:
> On Wed, Apr 22, 2015 at 07:07:59PM +0100, Al Viro wrote:
> > And one more: may_follow_link() is now potentially oopsable. Look: suppose
> > we've reached the link in RCU mode, just as it got unlinked. link->dentry
> > has become negative
On Wed, Apr 22, 2015 at 07:07:59PM +0100, Al Viro wrote:
> And one more: may_follow_link() is now potentially oopsable. Look: suppose
> we've reached the link in RCU mode, just as it got unlinked. link->dentry
> has become negative and may_follow_link() steps into
> /* Allowed if owner an
On Tue, Apr 21, 2015 at 10:20:07PM +0100, Al Viro wrote:
> I agree that unlazy_walk() attempted when walking a symlink ought to fail
> with -ECHILD; we can't legitimize the symlink itself, so once we are out
> of RCU mode, there's nothing to hold the inode of symlink (and its body)
> from getting
On Tue, Apr 21, 2015 at 04:45:04PM +0100, Al Viro wrote:
> On Tue, Apr 21, 2015 at 05:12:01PM +0200, Richard Weinberger wrote:
>
> > I'm pretty sure we can kill it. I had the plan to rip it out during this
> > merge window
> > along with other broken UML stuff but I was too late to ask on the UML
On 04/21/2015 06:45 PM, Al Viro wrote:
> On Tue, Apr 21, 2015 at 05:12:01PM +0200, Richard Weinberger wrote:
>
>> I'm pretty sure we can kill it. I had the plan to rip it out during this
>> merge window
>> along with other broken UML stuff but I was too late to ask on the UML
>> mailinglist
>> i
On Tue, Apr 21, 2015 at 05:12:01PM +0200, Richard Weinberger wrote:
> I'm pretty sure we can kill it. I had the plan to rip it out during this
> merge window
> along with other broken UML stuff but I was too late to ask on the UML
> mailinglist
> if someone is using it (which I really doubt).
>
Am 21.04.2015 um 17:04 schrieb Christoph Hellwig:
> On Tue, Apr 21, 2015 at 03:49:59PM +0100, Al Viro wrote:
>> On Mon, Apr 20, 2015 at 07:12:22PM +0100, Al Viro wrote:
>>
>>> Patches 2/24..6/24 are from Neil's RCU follow_link patchset; the
>>> rest of his patchset is, of course, derailed by th
On Tue, Apr 21, 2015 at 03:49:59PM +0100, Al Viro wrote:
> On Mon, Apr 20, 2015 at 07:12:22PM +0100, Al Viro wrote:
>
> > Patches 2/24..6/24 are from Neil's RCU follow_link patchset; the
> > rest of his patchset is, of course, derailed by the massage done here,
> > but AFAICS we should be able
On Mon, Apr 20, 2015 at 07:12:22PM +0100, Al Viro wrote:
> Patches 2/24..6/24 are from Neil's RCU follow_link patchset; the
> rest of his patchset is, of course, derailed by the massage done here,
> but AFAICS we should be able to port it on top of this one with reasonably
> little PITA.
BT
The patchset below gets rid of recursion in pathname resolution.
As the result, stack footprint of fs/namei.c stuff doesn't depend upon
the symlink nesting anymore and is much less than the worst cases in
mainline - as the matter of fact, it's around the footprint mainline gets
with just on
17 matches
Mail list logo
