vfs-scale, nd->inode after __do_follow_link()

vfs-scale, nd->inode after __do_follow_link()

[J. R. Okajima]

Isn't it path.dentry->d_inode instead of nd.inode?

J. R. Okajima

diff --git a/fs/namei.c b/fs/namei.c
index 5bb7588..1df3bee 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2356,8 +2374,9 @@ reval:
 			goto exit_dput;
 		error = __do_follow_link(&path, &nd, &cookie);
 		if (unlikely(error)) {
-			if (!IS_ERR(cookie) && nd.inode->i_op->put_link)
-				nd.inode->i_op->put_link(path.dentry, &nd, cookie);
+			struct dentry *i = path.dentry->d_inode;
+			if (!IS_ERR(cookie) && i->i_op->put_link)
+				i->i_op->put_link(path.dentry, &nd, cookie);
 			/* nd.path had been dropped */
 			nd.path = path;
 			goto out_path;

Re: vfs-scale, nd->inode after __do_follow_link()

[J. R. Okajima]

"J. R. Okajima":
> Isn't it path.dentry->d_inode instead of nd.inode?

There is another one just after.

J. R. Okajima

diff --git a/fs/namei.c b/fs/namei.c
index 5bb7588..03e45ae 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2356,8 +2374,9 @@ reval:
 			goto exit_dput;
 		error = __do_follow_link(&path, &nd, &cookie);
 		if (unlikely(error)) {
-			if (!IS_ERR(cookie) && nd.inode->i_op->put_link)
-				nd.inode->i_op->put_link(path.dentry, &nd, cookie);
+			struct inode *i = path.dentry->d_inode;
+			if (!IS_ERR(cookie) && i->i_op->put_link)
+				i->i_op->put_link(path.dentry, &nd, cookie);
 			/* nd.path had been dropped */
 			nd.path = path;
 			goto out_path;
@@ -2365,8 +2384,11 @@ reval:
 		holder = path;
 		nd.flags &= ~LOOKUP_PARENT;
 		filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname);
-		if (nd.inode->i_op->put_link)
-			nd.inode->i_op->put_link(holder.dentry, &nd, cookie);
+		{
+			struct inode *i = holder.dentry->d_inode;
+			if (i->i_op->put_link)
+				i->i_op->put_link(holder.dentry, &nd, cookie);
+		}
 		path_put(&holder);
 	}
 out:

Re: vfs-scale, nd->inode after __do_follow_link()

[Nick Piggin]

On Fri, Jan 14, 2011 at 1:10 PM, J. R. Okajima <hooanon05@yahoo.co.jp> wrote:
>
> Isn't it path.dentry->d_inode instead of nd.inode?
>
> J. R. Okajima
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 5bb7588..1df3bee 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2356,8 +2374,9 @@ reval:
>                        goto exit_dput;
>                error = __do_follow_link(&path, &nd, &cookie);
>                if (unlikely(error)) {
> -                       if (!IS_ERR(cookie) && nd.inode->i_op->put_link)
> -                               nd.inode->i_op->put_link(path.dentry, &nd, cookie);
> +                       struct dentry *i = path.dentry->d_inode;
> +                       if (!IS_ERR(cookie) && i->i_op->put_link)
> +                               i->i_op->put_link(path.dentry, &nd, cookie);
>                        /* nd.path had been dropped */
>                        nd.path = path;
>                        goto out_path;

It should be the inode we followed, rather than the inode of the
new path, I think.

Re: vfs-scale, nd->inode after __do_follow_link()

[Nick Piggin]

On Fri, Jan 14, 2011 at 1:10 PM, J. R. Okajima <hooanon05@yahoo.co.jp> wrote:
>
> Isn't it path.dentry->d_inode instead of nd.inode?
>
> J. R. Okajima
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 5bb7588..1df3bee 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2356,8 +2374,9 @@ reval:
>                        goto exit_dput;
>                error = __do_follow_link(&path, &nd, &cookie);
>                if (unlikely(error)) {
> -                       if (!IS_ERR(cookie) && nd.inode->i_op->put_link)
> -                               nd.inode->i_op->put_link(path.dentry, &nd, cookie);
> +                       struct dentry *i = path.dentry->d_inode;
> +                       if (!IS_ERR(cookie) && i->i_op->put_link)
> +                               i->i_op->put_link(path.dentry, &nd, cookie);
>                        /* nd.path had been dropped */
>                        nd.path = path;
>                        goto out_path;

It should be the inode we followed, rather than the inode of the
new path, I think.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: vfs-scale, nd->inode after __do_follow_link()

[J. R. Okajima]

Nick Piggin:
> > Isn't it path.dentry->d_inode instead of nd.inode?
	:::
> It should be the inode we followed, rather than the inode of the
> new path, I think.

In __do_follow_link(), path.dentry is what we followed, isn't it?

__do_follow_link()
{
	struct dentry *dentry = path->dentry;
	;;;
	*p = dentry->d_inode->i_op->follow_link(dentry, nd);
	;;;


J. R. Okajima

Re: vfs-scale, nd->inode after __do_follow_link()

[Al Viro]

On Fri, Jan 14, 2011 at 03:09:10PM +1100, Nick Piggin wrote:

> > + ? ? ? ? ? ? ? ? ? ? ? struct dentry *i = path.dentry->d_inode;
> > + ? ? ? ? ? ? ? ? ? ? ? if (!IS_ERR(cookie) && i->i_op->put_link)
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i->i_op->put_link(path.dentry, &nd, cookie);
> > ? ? ? ? ? ? ? ? ? ? ? ?/* nd.path had been dropped */
> > ? ? ? ? ? ? ? ? ? ? ? ?nd.path = path;
> > ? ? ? ? ? ? ? ? ? ? ? ?goto out_path;
> 
> It should be the inode we followed, rather than the inode of the
> new path, I think.

And that's what the first argument of __do_follow_link() is.  I'm actually
tempted to rename it from path to symlink and make it const to clarify
the things a bit.

BTW, "i" as a name for local struct inode * is -><- that close to being a
shootable offense.  Please, rename to e.g. struct inode *link (and it's
struct inode, not struct dentry).

Re: vfs-scale, nd->inode after __do_follow_link()

[J. R. Okajima]

Al Viro:
> BTW, "i" as a name for local struct inode * is -><- that close to being a
> shootable offense.  Please, rename to e.g. struct inode *link (and it's
> struct inode, not struct dentry).

I will do so when the patch will be merged.
I meant the code snippet is just showing what I thought. I didn't mean
it should be merged.


J. R. Okajima

Re: vfs-scale, nd->inode after __do_follow_link()

[J. R. Okajima]

"J. R. Okajima":
> Al Viro:
> > BTW, "i" as a name for local struct inode * is -><- that close to being a
> > shootable offense.  Please, rename to e.g. struct inode *link (and it's
> > struct inode, not struct dentry).
>
> I will do so when the patch will be merged.
> I meant the code snippet is just showing what I thought. I didn't mean
> it should be merged.

Forgot to write.
I noticed about the "struct dentry" too and it was fixed in my second code.

J. R. Okajima

Re: vfs-scale, nd->inode after __do_follow_link()

[Nick Piggin]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Fri, Jan 14, 2011 at 4:28 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Jan 14, 2011 at 03:09:10PM +1100, Nick Piggin wrote:
>
>> > + ? ? ? ? ? ? ? ? ? ? ? struct dentry *i = path.dentry->d_inode;
>> > + ? ? ? ? ? ? ? ? ? ? ? if (!IS_ERR(cookie) && i->i_op->put_link)
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i->i_op->put_link(path.dentry, &nd, cookie);
>> > ? ? ? ? ? ? ? ? ? ? ? ?/* nd.path had been dropped */
>> > ? ? ? ? ? ? ? ? ? ? ? ?nd.path = path;
>> > ? ? ? ? ? ? ? ? ? ? ? ?goto out_path;
>>
>> It should be the inode we followed, rather than the inode of the
>> new path, I think.
>
> And that's what the first argument of __do_follow_link() is.  I'm actually
> tempted to rename it from path to symlink and make it const to clarify
> the things a bit.

Yes I was completely wrong there, thanks again for another good
catch. I'll merge this in the vfs-scale branch, and ask to merge if
there are no objections.

[-- Attachment #2: fs-namei-putlink-fix.patch --]
[-- Type: application/octet-stream, Size: 3262 bytes --]

fs: namei fix ->put_link on wrong inode in do_filp_open

J. R. Okajima noticed that ->put_link is being attempted on the
wrong inode, and suggested the way to fix it. I changed it a bit
according to Al's suggestion to keep an explicit link path around.

Signed-off-by: Nick Piggin <npiggin@kernel.dk>

Index: linux-2.6/fs/namei.c
===================================================================
--- linux-2.6.orig/fs/namei.c	2011-01-14 18:26:02.000000000 +1100
+++ linux-2.6/fs/namei.c	2011-01-14 19:10:02.000000000 +1100
@@ -779,7 +779,8 @@ static void path_put_conditional(struct
 		mntput(path->mnt);
 }
 
-static inline void path_to_nameidata(struct path *path, struct nameidata *nd)
+static inline void path_to_nameidata(const struct path *path,
+					struct nameidata *nd)
 {
 	if (!(nd->flags & LOOKUP_RCU)) {
 		dput(nd->path.dentry);
@@ -791,20 +792,20 @@ static inline void path_to_nameidata(str
 }
 
 static __always_inline int
-__do_follow_link(struct path *path, struct nameidata *nd, void **p)
+__do_follow_link(const struct path *link, struct nameidata *nd, void **p)
 {
 	int error;
-	struct dentry *dentry = path->dentry;
+	struct dentry *dentry = link->dentry;
 
-	touch_atime(path->mnt, dentry);
+	touch_atime(link->mnt, dentry);
 	nd_set_link(nd, NULL);
 
-	if (path->mnt != nd->path.mnt) {
-		path_to_nameidata(path, nd);
+	if (link->mnt != nd->path.mnt) {
+		path_to_nameidata(link, nd);
 		nd->inode = nd->path.dentry->d_inode;
 		dget(dentry);
 	}
-	mntget(path->mnt);
+	mntget(link->mnt);
 
 	nd->last_type = LAST_BIND;
 	*p = dentry->d_inode->i_op->follow_link(dentry, nd);
@@ -2347,11 +2348,12 @@ struct file *do_filp_open(int dfd, const
 	nd.flags = flags;
 	filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname);
 	while (unlikely(!filp)) { /* trailing symlink */
-		struct path holder;
+		struct path link = path;
+		struct inode *linki = link.dentry->d_inode;
 		void *cookie;
 		error = -ELOOP;
 		/* S_ISDIR part is a temporary automount kludge */
-		if (!(nd.flags & LOOKUP_FOLLOW) && !S_ISDIR(nd.inode->i_mode))
+		if (!(nd.flags & LOOKUP_FOLLOW) && !S_ISDIR(linki->i_mode))
 			goto exit_dput;
 		if (count++ == 32)
 			goto exit_dput;
@@ -2367,23 +2369,22 @@ struct file *do_filp_open(int dfd, const
 		 * just set LAST_BIND.
 		 */
 		nd.flags |= LOOKUP_PARENT;
-		error = security_inode_follow_link(path.dentry, &nd);
+		error = security_inode_follow_link(link.dentry, &nd);
 		if (error)
 			goto exit_dput;
-		error = __do_follow_link(&path, &nd, &cookie);
+		error = __do_follow_link(&link, &nd, &cookie);
 		if (unlikely(error)) {
-			if (!IS_ERR(cookie) && nd.inode->i_op->put_link)
-				nd.inode->i_op->put_link(path.dentry, &nd, cookie);
+			if (!IS_ERR(cookie) && linki->i_op->put_link)
+				linki->i_op->put_link(link.dentry, &nd, cookie);
 			/* nd.path had been dropped */
-			nd.path = path;
+			nd.path = link;
 			goto out_path;
 		}
-		holder = path;
 		nd.flags &= ~LOOKUP_PARENT;
 		filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname);
-		if (nd.inode->i_op->put_link)
-			nd.inode->i_op->put_link(holder.dentry, &nd, cookie);
-		path_put(&holder);
+		if (linki->i_op->put_link)
+			linki->i_op->put_link(link.dentry, &nd, cookie);
+		path_put(&link);
 	}
 out:
 	if (nd.root.mnt)

Re: vfs-scale, nd->inode after __do_follow_link()

[Sedat Dilek]

On Fri, Jan 14, 2011 at 9:40 AM, Nick Piggin <npiggin@gmail.com> wrote:
> On Fri, Jan 14, 2011 at 4:28 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> On Fri, Jan 14, 2011 at 03:09:10PM +1100, Nick Piggin wrote:
>>
>>> > + ? ? ? ? ? ? ? ? ? ? ? struct dentry *i = path.dentry->d_inode;
>>> > + ? ? ? ? ? ? ? ? ? ? ? if (!IS_ERR(cookie) && i->i_op->put_link)
>>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i->i_op->put_link(path.dentry, &nd, cookie);
>>> > ? ? ? ? ? ? ? ? ? ? ? ?/* nd.path had been dropped */
>>> > ? ? ? ? ? ? ? ? ? ? ? ?nd.path = path;
>>> > ? ? ? ? ? ? ? ? ? ? ? ?goto out_path;
>>>
>>> It should be the inode we followed, rather than the inode of the
>>> new path, I think.
>>
>> And that's what the first argument of __do_follow_link() is.  I'm actually
>> tempted to rename it from path to symlink and make it const to clarify
>> the things a bit.
>
> Yes I was completely wrong there, thanks again for another good
> catch. I'll merge this in the vfs-scale branch, and ask to merge if
> there are no objections.
>

[ CCing patchwork ML ]

Can you send your patch separately, please?
Within a (long) thread it is eaten up.

As *.patch are somehow not presented as diff (see [1]), someone can't
catch them from <patchwork.k.o>.

Furthermore, it would be very cool to see linux-fsdevel (patches from
its ML) in <patchwork.d.o>.
I don't know whom to contact from the linux-fsdevel ML, sorry for this.

- Sedat -

[1] http://lkml.org/lkml/2011/1/14/55

Re: vfs-scale, nd->inode after __do_follow_link()

[Sedat Dilek]

On Fri, Jan 14, 2011 at 9:40 AM, Nick Piggin <npiggin@gmail.com> wrote:
> On Fri, Jan 14, 2011 at 4:28 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> On Fri, Jan 14, 2011 at 03:09:10PM +1100, Nick Piggin wrote:
>>
>>> > + ? ? ? ? ? ? ? ? ? ? ? struct dentry *i = path.dentry->d_inode;
>>> > + ? ? ? ? ? ? ? ? ? ? ? if (!IS_ERR(cookie) && i->i_op->put_link)
>>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i->i_op->put_link(path.dentry, &nd, cookie);
>>> > ? ? ? ? ? ? ? ? ? ? ? ?/* nd.path had been dropped */
>>> > ? ? ? ? ? ? ? ? ? ? ? ?nd.path = path;
>>> > ? ? ? ? ? ? ? ? ? ? ? ?goto out_path;
>>>
>>> It should be the inode we followed, rather than the inode of the
>>> new path, I think.
>>
>> And that's what the first argument of __do_follow_link() is.  I'm actually
>> tempted to rename it from path to symlink and make it const to clarify
>> the things a bit.
>
> Yes I was completely wrong there, thanks again for another good
> catch. I'll merge this in the vfs-scale branch, and ask to merge if
> there are no objections.
>

[ CCing patchwork ML ]

Can you send your patch separately, please?
Within a (long) thread it is eaten up.

As *.patch are somehow not presented as diff (see [1]), someone can't
catch them from <patchwork.k.o>.

Furthermore, it would be very cool to see linux-fsdevel (patches from
its ML) in <patchwork.d.o>.
I don't know whom to contact from the linux-fsdevel ML, sorry for this.

- Sedat -

[1] http://lkml.org/lkml/2011/1/14/55
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: vfs-scale, nd->inode after __do_follow_link()

[J. R. Okajima]

Nick Piggin:
> Yes I was completely wrong there, thanks again for another good
> catch. I'll merge this in the vfs-scale branch, and ask to merge if
> there are no objections.

I don't have any objection.

Thanks
J. R. Okajima

Re: vfs-scale, nd->inode after __do_follow_link()

[J.H.]

> [ CCing patchwork ML ]
> 
> Can you send your patch separately, please?
> Within a (long) thread it is eaten up.
> 
> As *.patch are somehow not presented as diff (see [1]), someone can't
> catch them from <patchwork.k.o>.

On a side note, due to some conversations with the ocfs2 devs yesterday,
I've actually got the vfs-scale code sitting compiled up waiting for
another kernel panic to happen on the dynamic web boxes, since 2.6.37+
was, literally, unusable with ocfs2 running.

> Furthermore, it would be very cool to see linux-fsdevel (patches from
> its ML) in <patchwork.d.o>.
> I don't know whom to contact from the linux-fsdevel ML, sorry for this.

As to getting a mailing list added into patchwork.kernel.org I just need
a request from someone who is responsible for the mailing list, and who
will actually use the resulting entry in patchwork to e-mail
ftpadmin@kernel.org with the mailing list, where I can deal with the
sign-up and the name / username of the individual (in patchwork) to add
as being in charge.

- John 'Warthog9' Hawley

[Ocfs2-devel] vfs-scale, nd->inode after __do_follow_link()

[J.H.]

Nick,

Just thought I'd let you know - with, or without, the vfs-scale code
that you've got I'm getting this:

[  472.666054] ------------[ cut here ]------------
[  472.670724] kernel BUG at fs/dcache.c:1358!
[  472.674944] invalid opcode: 0000 [#1] SMP
[  472.679112] last sysfs file:
/sys/devices/system/cpu/cpu15/cache/index2/shared_cpu_map
[  472.687105] last /proc..net open:  /proc/7687/net/route
[  472.695829] last /proc..net close: /proc/7687/net/route
[  472.704490] CPU 0
[  472.706361] Modules linked in: ocfs2 mptctl mptbase ipmi_devintf drbd
lru_cache nfsd lockd nfs_acl auth_rpcgss sunrpc ocfs2_dlmfs
ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs
8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables ipv6 xfs exportfs serio_raw iTCO_wdt bnx2
microcode hpwdt iTCO_vendor_support ipmi_si power_meter ipmi_msghandler
pcspkr hpilo i7core_edac edac_core shpchp hpsa radeon ttm drm_kms_helper
drm i2c_algo_bit i2c_core [last unloaded: speedstep_lib]
[  472.776643]
[  472.782039] Pid: 2716, comm: httpd Tainted: G        W   2.6.37+ #4
/ProLiant DL380 G6
[  472.793922] RIP: 0010:[<ffffffff8113ed85>]  [<ffffffff8113ed85>]
d_set_d_op+0x13/0x5e
[  472.793931] RSP: 0018:ffff8807d4f87c08  EFLAGS: 00010282
[  472.793933] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
0000000000000000
[  472.793936] RDX: 0000000000000246 RSI: ffffffffa04dc880 RDI:
ffff8803cf7bcbd0
[  472.793939] RBP: ffff8807d4f87c08 R08: ffffffffa0491049 R09:
0000000000000001
[  472.793942] R10: ffff8803fc70c778 R11: ffff880700000000 R12:
ffff8803cf737000
[  472.793945] R13: ffff8803cb822120 R14: ffff8803cb821460 R15:
ffff8803cf7bcbd0
[  472.793949] FS:  00002b86adeee660(0000) GS:ffff8800dd400000(0000)
knlGS:0000000000000000
[  472.793952] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  472.793955] CR2: 00002b86ad2c4888 CR3: 00000007d4f75000 CR4:
00000000000006f0
[  472.793958] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[  472.793961] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[  472.793964] Process httpd (pid: 2716, threadinfo ffff8807d4f86000,
task ffff8807d4e723b0)
[  472.793967] Stack:
[  472.793968]  ffff8807d4f87d28 ffffffffa04aac62 ffff8803ddabfe30
ffff8803cb820e78
[  472.793973]  ffff8803fbc38000 ffff8803cb820ee8 00000000a0491177
ffff8803f36cd000
[  472.793978]  00008000d4f87c98 ffff8803fbc38000 ffff8803cf727d90
0000000000000000
[  472.793983] Call Trace:
[  472.794010]  [<ffffffffa04aac62>] ocfs2_mknod+0xb0f/0xd3e [ocfs2]
[  472.794032]  [<ffffffffa04aaeb9>] ocfs2_create+0x13/0x15 [ocfs2]
[  472.794036]  [<ffffffff811392b7>] vfs_create+0x70/0x92
[  472.794041]  [<ffffffff81139fdc>] do_last+0x163/0x2e0
[  472.794045]  [<ffffffff8113a460>] do_filp_open+0x307/0x6f1
[  472.794050]  [<ffffffff81145394>] ? alloc_fd+0x3b/0x193
[  472.794055]  [<ffffffff81082e33>] ? lock_release+0x19a/0x1a6
[  472.794059]  [<ffffffff811454da>] ? alloc_fd+0x181/0x193
[  472.794063]  [<ffffffff8112d1f6>] do_sys_open+0x60/0xf2
[  472.794068]  [<ffffffff814a7aef>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  472.794072]  [<ffffffff8112d2a8>] sys_open+0x20/0x22
[  472.794077]  [<ffffffff8100ac42>] system_call_fastpath+0x16/0x1b
[  472.794079] Code: a9 ff 03 00 00 74 08 81 0b 80 00 00 00 eb 06 81 23
7f ff ff ff 5b c9 c3 55 48 89 e5 0f 1f 44 00 00 48 83 bf a8 00 00 00 00
74 02 <0f> 0b 8b 07 f6 c4 f0 74 02 0f 0b 48 85 f6 48 89 b7 a8 00 00 00
[  472.794112] RIP  [<ffffffff8113ed85>] d_set_d_op+0x13/0x5e
[  472.794116]  RSP <ffff8807d4f87c08>
[  472.794387] ---[ end trace 04b2ab2cb7dc3150 ]---

I only mention this as the ocfs2 folks suggested running your code might
solve that problem.  That said I'm going to punt this back over to the
ocfs2 folks for further review, as the bug makes ocfs2 completely
unusable on 2.6.37+

- John 'Warthog9' Hawley

[Ocfs2-devel] vfs-scale, nd->inode after __do_follow_link()

[Nick Piggin]

On Sat, Jan 15, 2011 at 12:20 PM, J.H. <warthog9@kernel.org> wrote:
> Nick,
>
> Just thought I'd let you know - with, or without, the vfs-scale code
> that you've got I'm getting this:
>
> [ ?472.666054] ------------[ cut here ]------------
> [ ?472.670724] kernel BUG at fs/dcache.c:1358!
> [ ?472.674944] invalid opcode: 0000 [#1] SMP
> [ ?472.679112] last sysfs file:
> /sys/devices/system/cpu/cpu15/cache/index2/shared_cpu_map
> [ ?472.687105] last /proc..net open: ?/proc/7687/net/route
> [ ?472.695829] last /proc..net close: /proc/7687/net/route
> [ ?472.704490] CPU 0
> [ ?472.706361] Modules linked in: ocfs2 mptctl mptbase ipmi_devintf drbd
> lru_cache nfsd lockd nfs_acl auth_rpcgss sunrpc ocfs2_dlmfs
> ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs
> 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> ip6table_filter ip6_tables ipv6 xfs exportfs serio_raw iTCO_wdt bnx2
> microcode hpwdt iTCO_vendor_support ipmi_si power_meter ipmi_msghandler
> pcspkr hpilo i7core_edac edac_core shpchp hpsa radeon ttm drm_kms_helper
> drm i2c_algo_bit i2c_core [last unloaded: speedstep_lib]
> [ ?472.776643]
> [ ?472.782039] Pid: 2716, comm: httpd Tainted: G ? ? ? ?W ? 2.6.37+ #4
> /ProLiant DL380 G6
> [ ?472.793922] RIP: 0010:[<ffffffff8113ed85>] ?[<ffffffff8113ed85>]
> d_set_d_op+0x13/0x5e
> [ ?472.793931] RSP: 0018:ffff8807d4f87c08 ?EFLAGS: 00010282
> [ ?472.793933] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
> 0000000000000000
> [ ?472.793936] RDX: 0000000000000246 RSI: ffffffffa04dc880 RDI:
> ffff8803cf7bcbd0
> [ ?472.793939] RBP: ffff8807d4f87c08 R08: ffffffffa0491049 R09:
> 0000000000000001
> [ ?472.793942] R10: ffff8803fc70c778 R11: ffff880700000000 R12:
> ffff8803cf737000
> [ ?472.793945] R13: ffff8803cb822120 R14: ffff8803cb821460 R15:
> ffff8803cf7bcbd0
> [ ?472.793949] FS: ?00002b86adeee660(0000) GS:ffff8800dd400000(0000)
> knlGS:0000000000000000
> [ ?472.793952] CS: ?0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ ?472.793955] CR2: 00002b86ad2c4888 CR3: 00000007d4f75000 CR4:
> 00000000000006f0
> [ ?472.793958] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ ?472.793961] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ ?472.793964] Process httpd (pid: 2716, threadinfo ffff8807d4f86000,
> task ffff8807d4e723b0)
> [ ?472.793967] Stack:
> [ ?472.793968] ?ffff8807d4f87d28 ffffffffa04aac62 ffff8803ddabfe30
> ffff8803cb820e78
> [ ?472.793973] ?ffff8803fbc38000 ffff8803cb820ee8 00000000a0491177
> ffff8803f36cd000
> [ ?472.793978] ?00008000d4f87c98 ffff8803fbc38000 ffff8803cf727d90
> 0000000000000000
> [ ?472.793983] Call Trace:
> [ ?472.794010] ?[<ffffffffa04aac62>] ocfs2_mknod+0xb0f/0xd3e [ocfs2]
> [ ?472.794032] ?[<ffffffffa04aaeb9>] ocfs2_create+0x13/0x15 [ocfs2]
> [ ?472.794036] ?[<ffffffff811392b7>] vfs_create+0x70/0x92
> [ ?472.794041] ?[<ffffffff81139fdc>] do_last+0x163/0x2e0
> [ ?472.794045] ?[<ffffffff8113a460>] do_filp_open+0x307/0x6f1
> [ ?472.794050] ?[<ffffffff81145394>] ? alloc_fd+0x3b/0x193
> [ ?472.794055] ?[<ffffffff81082e33>] ? lock_release+0x19a/0x1a6
> [ ?472.794059] ?[<ffffffff811454da>] ? alloc_fd+0x181/0x193
> [ ?472.794063] ?[<ffffffff8112d1f6>] do_sys_open+0x60/0xf2
> [ ?472.794068] ?[<ffffffff814a7aef>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ ?472.794072] ?[<ffffffff8112d2a8>] sys_open+0x20/0x22
> [ ?472.794077] ?[<ffffffff8100ac42>] system_call_fastpath+0x16/0x1b
> [ ?472.794079] Code: a9 ff 03 00 00 74 08 81 0b 80 00 00 00 eb 06 81 23
> 7f ff ff ff 5b c9 c3 55 48 89 e5 0f 1f 44 00 00 48 83 bf a8 00 00 00 00
> 74 02 <0f> 0b 8b 07 f6 c4 f0 74 02 0f 0b 48 85 f6 48 89 b7 a8 00 00 00
> [ ?472.794112] RIP ?[<ffffffff8113ed85>] d_set_d_op+0x13/0x5e
> [ ?472.794116] ?RSP <ffff8807d4f87c08>
> [ ?472.794387] ---[ end trace 04b2ab2cb7dc3150 ]---
>
> I only mention this as the ocfs2 folks suggested running your code might
> solve that problem. ?That said I'm going to punt this back over to the
> ocfs2 folks for further review, as the bug makes ocfs2 completely
> unusable on 2.6.37+

Oh this is the d_set_d_op thing again. Linus has changed that to a
WARN_ON_ONCE upstream now rather than BUG_ON now (which
in hindsight is how it should have first looked). So that will get you
going again. Thanks for testing and reporting it.

The underlying problem is not a new one, but race is very slim, so
a warning rather than BUG is appropriate.