On Thu, Oct 02, 2014 at 05:35:26AM -0500, Chuck Ebbert wrote:
> On Wed, 1 Oct 2014 01:16:15 +0100
> Al Viro wrote:
>
> Can we get the below added somewhere in Documentation/filesystems/ ? I
> don't see anything there that covers all this.
More documentation would of course be nice, but the root
On Wed, 1 Oct 2014 01:16:15 +0100
Al Viro wrote:
Can we get the below added somewhere in Documentation/filesystems/ ? I
don't see anything there that covers all this.
>
> Huh? copy_name() does copy a _reference_, not the name itself. All the
> copying involved is source->d_name.name = target-
On Wed, Oct 01, 2014 at 01:16:15AM +0100, Al Viro wrote:
> On Mon, Sep 29, 2014 at 11:42:18AM -0700, Paul E. McKenney wrote:
>
> > Assuming that incrementing the external name's reference count is
> > atomic_add_unless, I could believe this part. Or if you have some
> > locking that makes it impo
On Mon, Sep 29, 2014 at 11:42:18AM -0700, Paul E. McKenney wrote:
> Assuming that incrementing the external name's reference count is
> atomic_add_unless, I could believe this part. Or if you have some
> locking that makes it impossible to increment the reference count
> in any case where there i
On Sun, Sep 28, 2014 at 07:05:56PM +0100, Al Viro wrote:
> On Sun, Sep 28, 2014 at 08:47:47AM +0100, Al Viro wrote:
>
> > The root cause, of course, is that we delay decrementing the refcount on
> > dentry_free() path... One variant is to rip freeing these suckers out of
> > __d_free() and have d
On Mon, Sep 29, 2014 at 12:04 PM, Al Viro wrote:
>>
>> "dname_external()".
>
> That we do... Why is it in dcache.h, BTW? No users outside of fs/dcache.c
> and I can't imagine a valid use for it in a module, let alone out-of-tree
> one...
Yeah, no, remove the declaration in dcache.h, and make it
On Mon, Sep 29, 2014 at 10:54:59AM -0700, Linus Torvalds wrote:
> On Mon, Sep 29, 2014 at 9:27 AM, Al Viro wrote:
> >
> > What we get in free_dentry() is:
> > * external name not shared: refcount driven to 0, RCU-delayed
> > call of "free dentry, free ext name"
> > * external name
On Mon, Sep 29, 2014 at 9:27 AM, Al Viro wrote:
>
> What we get in free_dentry() is:
> * external name not shared: refcount driven to 0, RCU-delayed
> call of "free dentry, free ext name"
> * external name still shared: refcount positive after decrement,
> no freeing ext name
>
On Mon, Sep 29, 2014 at 09:07:00AM -0700, Linus Torvalds wrote:
> On Mon, Sep 29, 2014 at 8:59 AM, Al Viro wrote:
> >
> > Now RCU lookup starts. And on another CPU we move the first dentry over
> > the third one. copy_name() is called, it decrements the refcount down
> > to 1 (__d_free() hasn't
On Mon, Sep 29, 2014 at 8:59 AM, Al Viro wrote:
>
> Now RCU lookup starts. And on another CPU we move the first dentry over
> the third one. copy_name() is called, it decrements the refcount down
> to 1 (__d_free() hasn't happened yet) and doesn't schedule any freeing.
Ahh. If we were to do *al
On Mon, Sep 29, 2014 at 08:15:51AM -0700, Linus Torvalds wrote:
> On Sun, Sep 28, 2014 at 11:05 AM, Al Viro wrote:
> >
> > Folks, care to review and test the following?
>
> No testing, but having thought about this some more, I'm personally
> getting quite convinced that doing the RCU delaying of
On Sun, Sep 28, 2014 at 11:05 AM, Al Viro wrote:
>
> Folks, care to review and test the following?
No testing, but having thought about this some more, I'm personally
getting quite convinced that doing the RCU delaying of the external
name freeing in the __d_free() path is entirely pointless.
So
On Mon, Sep 29, 2014 at 06:16:13AM -0700, Paul E. McKenney wrote:
> The "textbook" approach is to avoid starting the grace period until
> the after the final reference count is dropped (and of course after
> the name has been made inaccessible to all readers). Not sure what
> the best way to adap
On Sun, Sep 28, 2014 at 08:47:47AM +0100, Al Viro wrote:
> On Sat, Sep 27, 2014 at 08:16:57PM +0100, Al Viro wrote:
> > On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote:
> >
> > > We can get the long name cases right, and I agree that it'll make the
> > > things nicer, but it might take a c
On Sun, Sep 28, 2014 at 07:05:56PM +0100, Al Viro wrote:
> One thing that worries me is the barriers that might be needed on assignments
> to ->d_name.name. We should be no worse than we are right now - either RCU
> accessors are careful enough with ACCESS_ONCE() and everything's fine,
> or they
On Sun, Sep 28, 2014 at 08:47:47AM +0100, Al Viro wrote:
> The root cause, of course, is that we delay decrementing the refcount on
> dentry_free() path... One variant is to rip freeing these suckers out of
> __d_free() and have dentry_free() do atomic_dec_and_test + kfree_rcu.
> That works (and
On Sat, 27 Sep 2014 10:56:57 -0700 Linus Torvalds wrote:
> (And Mikhail - I'm not ragging on you, even if I'm ragging on the
> patch. I understand why you did it the way you did, and it makes sense
> exactly in the "let's reinstate old hackery" model. I just think we
> can and should do better than
On Sat, Sep 27, 2014 at 08:16:57PM +0100, Al Viro wrote:
> On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote:
>
> > We can get the long name cases right, and I agree that it'll make the
> > things nicer, but it might take a couple of days to get right. The thing
> > I'm concerned about is n
On Sat, Sep 27, 2014 at 12:49 PM, Al Viro wrote:
>
> Fine by me. How about that s-o-b? Right now it's
Sure, add my sign-off too. Not that I feel I even need the credit, so
you could just have done it as yourself. But I'll take it, so..
Signed-off-by: Linus Torvalds
Thanks,
Linus
--
On Sat, Sep 27, 2014 at 12:39:02PM -0700, Linus Torvalds wrote:
> On Sat, Sep 27, 2014 at 12:37 PM, Linus Torvalds
> wrote:
> >
> > But yeah, I guess we can/should do the trivial ugly thing for 3.17.
> > Send me a proper pull-request,
>
> .. and if it can happen before tomorrow, that would be goo
On Sat, Sep 27, 2014 at 08:16:57PM +0100, Al Viro wrote:
> On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote:
>
> > We can get the long name cases right, and I agree that it'll make the
> > things nicer, but it might take a couple of days to get right. The thing
> > I'm concerned about is n
On Sat, Sep 27, 2014 at 12:37 PM, Linus Torvalds
wrote:
>
> But yeah, I guess we can/should do the trivial ugly thing for 3.17.
> Send me a proper pull-request,
.. and if it can happen before tomorrow, that would be good. I had to
give up on my wish to release 3.17 tomorrow due to the current siz
On Sat, Sep 27, 2014 at 12:16 PM, Al Viro wrote:
>
> FWIW, I suspect that the right approach is to put refcount + rcu_head in
> front of external name and do the following:
That's actually fancier than I was expecting. I was just thinking
doing a whole new allocation and freeing the old one using
On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote:
> We can get the long name cases right, and I agree that it'll make the
> things nicer, but it might take a couple of days to get right. The thing
> I'm concerned about is not screwing DCACHE_RCUACCESS up.
FWIW, I suspect that the right ap
On Sat, Sep 27, 2014 at 10:56:57AM -0700, Linus Torvalds wrote:
> - make a new "move_name(src,dst)" that explicitly moves names, and
> explicitly knows that the source needs to be kept alive (although it
> *could* also look at the source dentry refcount to decide whether it
> needs to be careful
On Fri, Sep 26, 2014 at 9:45 PM, Al Viro wrote:
>
> Linus, it's a real userland regression.
That's not the part I'm arguing against. I think the patch itself was
too ugly to live.
Yes, we had that hack before, but we didn't make it conditional. It
historically was more of a "it's easier to just
On Fri, Sep 26, 2014 at 05:44:42PM +0100, Al Viro wrote:
> FWIW, the longer I'm looking at that, the more it seems that __d_move() and
> __d_materialise_dentry() ought to be merged. The thing is, both callers of
> the latter are followed by the same sequence:
> write_sequn
On Thu, Sep 25, 2014 at 05:46:01AM +0100, Al Viro wrote:
> I really wonder if it's possible to get d_rehash() hitting the victim of
> (non-exchange) __d_move(). _Then_ this patch (as well as the historical
> behaviour it restores, all way back to 2.5, if not 2.3) would, indeed,
> be buggy.
More
On Thu, Sep 25, 2014 at 05:46:01AM +0100, Al Viro wrote:
> On Wed, Sep 24, 2014 at 09:18:13PM +0100, Al Viro wrote:
> > On Wed, Sep 24, 2014 at 12:20:38PM -0700, Linus Torvalds wrote:
> > > On Wed, Sep 24, 2014 at 11:55 AM, Al Viro wrote:
> > > >
> > > > Yecc... Applied, but it's very ugly.
On Wed, Sep 24, 2014 at 09:18:13PM +0100, Al Viro wrote:
> On Wed, Sep 24, 2014 at 12:20:38PM -0700, Linus Torvalds wrote:
> > On Wed, Sep 24, 2014 at 11:55 AM, Al Viro wrote:
> > >
> > > Yecc... Applied, but it's very ugly. Oh, well - regression is
> > > regression, and I don't see a cleane
On Wed, Sep 24, 2014 at 12:20:38PM -0700, Linus Torvalds wrote:
> On Wed, Sep 24, 2014 at 11:55 AM, Al Viro wrote:
> >
> > Yecc... Applied, but it's very ugly. Oh, well - regression is
> > regression, and I don't see a cleaner fix at the moment. If I don't
> > manage to come up with anythin
On Wed, Sep 24, 2014 at 12:20 PM, Linus Torvalds
wrote:
>
> There's no way that patch is correct.
Something like the appended might be a good idea regardless. And might
have made people notice that the len and the hash go together with the
name.
Linus
diff --git a/fs/dcac
On Wed, Sep 24, 2014 at 11:55 AM, Al Viro wrote:
>
> Yecc... Applied, but it's very ugly. Oh, well - regression is
> regression, and I don't see a cleaner fix at the moment. If I don't
> manage to come up with anything prettier, to Linus it goes in tonight
> pull request ;-/
Please don't.
On Wed, Sep 24, 2014 at 10:14:33PM +0400, Mikhail Efremov wrote:
> Only exchange source and destination filenames
> if flags contain RENAME_EXCHANGE.
> In case if executable file was running and replaced by
> other file /proc/PID/exe should still show correct file name,
> not the old name of the fi
Only exchange source and destination filenames
if flags contain RENAME_EXCHANGE.
In case if executable file was running and replaced by
other file /proc/PID/exe should still show correct file name,
not the old name of the file by which it was replaced.
The scenario when this bug manifests itself w
35 matches
Mail list logo
