On Sun, Feb 22, 2015 at 12:54:57PM +, David Howells wrote:
> You might want to remove dentry_inode_once(). I can still see it in your
> vfs/for-linus branch.
>
> It might also be worth renaming d_dentry() to d_backing_dentry() to match
> d_backing_inode().
Done and re-pushed; neither sucker
On Sun, Feb 22, 2015 at 10:37 AM, Al Viro wrote:
> On Sun, Feb 22, 2015 at 10:32:02AM +0100, Sedat Dilek wrote:
>
>> How do you test?
>
> Mostly xfstests and LTP, plus assorted tests depending on the areas touched...
> Any extra testing is welcome - the more, the merrier...
My base is Linux-v3.19
You might want to remove dentry_inode_once(). I can still see it in your
vfs/for-linus branch.
It might also be worth renaming d_dentry() to d_backing_dentry() to match
d_backing_inode().
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Linus Torvalds wrote:
> So the ACCESS_ONCE() thing is more special than just "done under RCU".
> It's more like "really special case done without any of the normal
> locking _or_ any of the normal RCU checks".
>
> That said, the overhead of using ACCESS_ONCE() is basically nil, so
> it's not lik
Linus Torvalds wrote:
> - dentry_inode*() is supposed to be "the inode that would be used if
> the dentry was opened"
>
>What part of "dentry_inode()" implies "if the dentry was opened" to
> you? Nothing. The name is fundamentally bad.
That because I wasn't thinking of it that way because i
Al Viro wrote:
> FWIW, I probably should've collapsed the per-fs patches together, or
> held them back until the next cycle; I understand why David did them
> that way (less painful rebasing that stuff)
Actually, that's not why I did it that way. What I wanted was to get the
wrappers upstream i
On Sun, Feb 22, 2015 at 10:37 AM, Al Viro wrote:
> On Sun, Feb 22, 2015 at 10:32:02AM +0100, Sedat Dilek wrote:
>
>> How do you test?
>
> Mostly xfstests and LTP, plus assorted tests depending on the areas touched...
> Any extra testing is welcome - the more, the merrier...
As said I wanted to te
On Sun, Feb 22, 2015 at 10:32:02AM +0100, Sedat Dilek wrote:
> How do you test?
Mostly xfstests and LTP, plus assorted tests depending on the areas touched...
Any extra testing is welcome - the more, the merrier...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sun, Feb 22, 2015 at 9:51 AM, Al Viro wrote:
> On Sat, Feb 21, 2015 at 07:16:16PM -0800, Linus Torvalds wrote:
>> On Sat, Feb 21, 2015 at 6:51 PM, Al Viro wrote:
>> >
>> > Umm... Works for me. Let's do it this way, then:
>> > * rename those guys through the whole series
>> >
On Sat, Feb 21, 2015 at 07:16:16PM -0800, Linus Torvalds wrote:
> On Sat, Feb 21, 2015 at 6:51 PM, Al Viro wrote:
> >
> > Umm... Works for me. Let's do it this way, then:
> > * rename those guys through the whole series
> > * leave the "annotate the filesystems" bits to sit in a
On Sat, Feb 21, 2015 at 6:51 PM, Al Viro wrote:
>
> Umm... Works for me. Let's do it this way, then:
> * rename those guys through the whole series
> * leave the "annotate the filesystems" bits to sit in a vfs.git
> branch
> * slap trylock_super() + bugfixes I'd been doin
On Sat, Feb 21, 2015 at 06:19:45PM -0800, Linus Torvalds wrote:
> > dentry_inode -> something. d_opened_inode() might do, but I'm not sure -
> > still sounds a bit wrong to me. What it's about is "the actual fs object
> > behind this name, maybe from upper fs, maybe showing through from underlyin
On Sat, Feb 21, 2015 at 6:02 PM, Al Viro wrote:
>
> I'm somewhat tempted to do this:
> fs_inode -> d_inode
> fs_inode_once ->d_inode_rcu (it's not quite ->d_revalidate()-only, there's
> a bit in autofs ->d_manage() as well)
Ok, those at least match our existing naming logic (ie "d_inode()"
would
On Sun, Feb 22, 2015 at 02:02:07AM +, Al Viro wrote:
> Hmm... ..._once() variants are trivially dropped, IMO. dentry_inode_once()
> is so bloody special that it *SHOULD* stick out; we don't have any places
> like that, anyway.
>
> I'm somewhat tempted to do this:
> fs_inode -> d_inode
> fs_i
On Sat, Feb 21, 2015 at 05:34:23PM -0800, Linus Torvalds wrote:
> On Sat, Feb 21, 2015 at 4:51 PM, Al Viro wrote:
> >
> > Looking at that queue, it might make sense to hold back everything in that
> > series past "fanotify: Fix up scripted S_ISDIR/S_ISREG/S_ISLNK conversions"
> > for now
>
> Hmm.
On Sat, Feb 21, 2015 at 4:51 PM, Al Viro wrote:
>
> Looking at that queue, it might make sense to hold back everything in that
> series past "fanotify: Fix up scripted S_ISDIR/S_ISREG/S_ISLNK conversions"
> for now
Hmm. Even I'd pull just that, quite frankly, I just think it's
*confusing* to have
On Sat, Feb 21, 2015 at 05:14:37PM -0800, Linus Torvalds wrote:
> .. and this is the one that makes no sense to me.
>
> It's the common case, and I don't see how it *possibly* adds any
> value. The "I want the inode of this dentry" is traditionally done as
> "dentry->d_inode".
>
> What is the *u
On Sat, Feb 21, 2015 at 4:18 PM, David Howells wrote:
>
> So what I want to do is:
>
> (1) Introduce wrappers around accesses to ->d_inode. These can be used to
> mark such accesses as being classified into two categories:
>
> (A) Some accesses should only consider the dentry they're g
On Sun, Feb 22, 2015 at 12:23:06AM +, David Howells wrote:
> Linus Torvalds wrote:
>
> > Also explain why that crap was done one file at a time?
>
> Because it wasn't. Here's the script for your perusal. Al cherry-picked the
> output, so you won't find everything the script produces in Al'
On Sat, Feb 21, 2015 at 02:45:34PM -0800, Linus Torvalds wrote:
> So I've pulled this, but quite frankly, I think I will unpull it again
> unless you actually state *what* the advantages of this pointless
> series of endless patches are.
> And no, that "explanation" in commit b717805b3c8b is not a
Linus Torvalds wrote:
> Also explain why that crap was done one file at a time?
Because it wasn't. Here's the script for your perusal. Al cherry-picked the
output, so you won't find everything the script produces in Al's pull request.
Breaking it down into one commit per fs makes it easier to
Linus Torvalds wrote:
> > Assorted stuff from this cycle. The big ones here are multilayer
> > overlayfs from Miklos and beginning of sorting ->d_inode accesses out from
> > David.
>
> So I've pulled this, but quite frankly, I think I will unpull it again
> unless you actually state *wh
On Sat, Feb 21, 2015 at 2:45 PM, Linus Torvalds
wrote:
>
> Explain it, or that crap gets undone.
Also explain why that crap was done one file at a time?
I'm getting really tired of people trying to inflate their commit
counts with tricks like this. What was the advantage of doing the same
thing
On Fri, Feb 20, 2015 at 7:34 PM, Al Viro wrote:
> Assorted stuff from this cycle. The big ones here are multilayer
> overlayfs from Miklos and beginning of sorting ->d_inode accesses out from
> David.
So I've pulled this, but quite frankly, I think I will unpull it again
unless you actua
Assorted stuff from this cycle. The big ones here are multilayer
overlayfs from Miklos and beginning of sorting ->d_inode accesses out from
David. And no, as far as I can tell David hadn't been taken over by
Malicious Entities From Beyond Spacetime^W^Wdrivers/staging - this series
is actu
Unfortunately, it looks like xattr series will have to wait until
the next cycle ;-/ This pile contains 9p cleanups and fixes (races in
v9fs_fid_add(), etc.), fixup for nommu breakage in shmem.c, several cleanups
and a bit more file_inode() work. Please, pull from
git://git.kernel.org/pub
26 matches
Mail list logo
