<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs, branch v2.6.35.4</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Fix init ordering of /dev/console vs callers of modprobe</title>
<updated>2010-08-26T23:46:04+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2010-08-06T15:34:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ea554ee37bcf4ad4f70b100287ffc84c2cf33066'/>
<id>ea554ee37bcf4ad4f70b100287ffc84c2cf33066</id>
<content type='text'>
commit 31d1d48e199e99077fb30f6fb9a793be7bec756f upstream.

Make /dev/console get initialised before any initialisation routine that
invokes modprobe because if modprobe fails, it's going to want to open
/dev/console, presumably to write an error message to.

The problem with that is that if the /dev/console driver is not yet
initialised, the chardev handler will call request_module() to invoke
modprobe, which will fail, because we never compile /dev/console as a
module.

This will lead to a modprobe loop, showing the following in the kernel
log:

	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1

This can happen, for example, when the built in md5 module can't find
the built in cryptomgr module (because the latter fails to initialise).
The md5 module comes before the call to tty_init(), presumably because
'crypto' comes before 'drivers' alphabetically.

Fix this by calling tty_init() from chrdev_init().

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 31d1d48e199e99077fb30f6fb9a793be7bec756f upstream.

Make /dev/console get initialised before any initialisation routine that
invokes modprobe because if modprobe fails, it's going to want to open
/dev/console, presumably to write an error message to.

The problem with that is that if the /dev/console driver is not yet
initialised, the chardev handler will call request_module() to invoke
modprobe, which will fail, because we never compile /dev/console as a
module.

This will lead to a modprobe loop, showing the following in the kernel
log:

	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1

This can happen, for example, when the built in md5 module can't find
the built in cryptomgr module (because the latter fails to initialise).
The md5 module comes before the call to tty_init(), presumably because
'crypto' comes before 'drivers' alphabetically.

Fix this by calling tty_init() from chrdev_init().

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>NFS: Fix an Oops in the NFSv4 atomic open code</title>
<updated>2010-08-26T23:45:53+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2010-08-18T13:25:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=31e682b1a760001e14a5965ee1a3b0c582fbf125'/>
<id>31e682b1a760001e14a5965ee1a3b0c582fbf125</id>
<content type='text'>
commit 0a377cff9428af2da2b293d11e07bc4dbf064ee5 upstream.

Adam Lackorzynski reports:

with 2.6.35.2 I'm getting this reproducible Oops:

[  110.825396] BUG: unable to handle kernel NULL pointer dereference at
(null)
[  110.828638] IP: [&lt;ffffffff811247b7&gt;] encode_attrs+0x1a/0x2a4
[  110.828638] PGD be89f067 PUD bf18f067 PMD 0
[  110.828638] Oops: 0000 [#1] SMP
[  110.828638] last sysfs file: /sys/class/net/lo/operstate
[  110.828638] CPU 2
[  110.828638] Modules linked in: rtc_cmos rtc_core rtc_lib amd64_edac_mod
i2c_amd756 edac_core i2c_core dm_mirror dm_region_hash dm_log dm_snapshot
sg sr_mod usb_storage ohci_hcd mptspi tg3 mptscsih mptbase usbcore nls_base
[last unloaded: scsi_wait_scan]
[  110.828638]
[  110.828638] Pid: 11264, comm: setchecksum Not tainted 2.6.35.2 #1
[  110.828638] RIP: 0010:[&lt;ffffffff811247b7&gt;]  [&lt;ffffffff811247b7&gt;]
encode_attrs+0x1a/0x2a4
[  110.828638] RSP: 0000:ffff88003bf5b878  EFLAGS: 00010296
[  110.828638] RAX: ffff8800bddb48a8 RBX: ffff88003bf5bb18 RCX:
0000000000000000
[  110.828638] RDX: ffff8800be258800 RSI: 0000000000000000 RDI:
ffff88003bf5b9f8
[  110.828638] RBP: 0000000000000000 R08: ffff8800bddb48a8 R09:
0000000000000004
[  110.828638] R10: 0000000000000003 R11: ffff8800be779000 R12:
ffff8800be258800
[  110.828638] R13: ffff88003bf5b9f8 R14: ffff88003bf5bb20 R15:
ffff8800be258800
[  110.828638] FS:  0000000000000000(0000) GS:ffff880041e00000(0063)
knlGS:00000000556bd6b0
[  110.828638] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
[  110.828638] CR2: 0000000000000000 CR3: 00000000be8ef000 CR4:
00000000000006e0
[  110.828638] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[  110.828638] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[  110.828638] Process setchecksum (pid: 11264, threadinfo
ffff88003bf5a000, task ffff88003f232210)
[  110.828638] Stack:
[  110.828638]  0000000000000000 ffff8800bfbcf920 0000000000000000
0000000000000ffe
[  110.828638] &lt;0&gt; 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[  110.828638] &lt;0&gt; 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[  110.828638] Call Trace:
[  110.828638]  [&lt;ffffffff81124c1f&gt;] ? nfs4_xdr_enc_setattr+0x90/0xb4
[  110.828638]  [&lt;ffffffff81371161&gt;] ? call_transmit+0x1c3/0x24a
[  110.828638]  [&lt;ffffffff813774d9&gt;] ? __rpc_execute+0x78/0x22a
[  110.828638]  [&lt;ffffffff81371a91&gt;] ? rpc_run_task+0x21/0x2b
[  110.828638]  [&lt;ffffffff81371b7e&gt;] ? rpc_call_sync+0x3d/0x5d
[  110.828638]  [&lt;ffffffff8111e284&gt;] ? _nfs4_do_setattr+0x11b/0x147
[  110.828638]  [&lt;ffffffff81109466&gt;] ? nfs_init_locked+0x0/0x32
[  110.828638]  [&lt;ffffffff810ac521&gt;] ? ifind+0x4e/0x90
[  110.828638]  [&lt;ffffffff8111e2fb&gt;] ? nfs4_do_setattr+0x4b/0x6e
[  110.828638]  [&lt;ffffffff8111e634&gt;] ? nfs4_do_open+0x291/0x3a6
[  110.828638]  [&lt;ffffffff8111ed81&gt;] ? nfs4_open_revalidate+0x63/0x14a
[  110.828638]  [&lt;ffffffff811056c4&gt;] ? nfs_open_revalidate+0xd7/0x161
[  110.828638]  [&lt;ffffffff810a2de4&gt;] ? do_lookup+0x1a4/0x201
[  110.828638]  [&lt;ffffffff810a4733&gt;] ? link_path_walk+0x6a/0x9d5
[  110.828638]  [&lt;ffffffff810a42b6&gt;] ? do_last+0x17b/0x58e
[  110.828638]  [&lt;ffffffff810a5fbe&gt;] ? do_filp_open+0x1bd/0x56e
[  110.828638]  [&lt;ffffffff811cd5e0&gt;] ? _atomic_dec_and_lock+0x30/0x48
[  110.828638]  [&lt;ffffffff810a9b1b&gt;] ? dput+0x37/0x152
[  110.828638]  [&lt;ffffffff810ae063&gt;] ? alloc_fd+0x69/0x10a
[  110.828638]  [&lt;ffffffff81099f39&gt;] ? do_sys_open+0x56/0x100
[  110.828638]  [&lt;ffffffff81027a22&gt;] ? ia32_sysret+0x0/0x5
[  110.828638] Code: 83 f1 01 e8 f5 ca ff ff 48 83 c4 50 5b 5d 41 5c c3 41
57 41 56 41 55 49 89 fd 41 54 49 89 d4 55 48 89 f5 53 48 81 ec 18 01 00 00
&lt;8b&gt; 06 89 c2 83 e2 08 83 fa 01 19 db 83 e3 f8 83 c3 18 a8 01 8d
[  110.828638] RIP  [&lt;ffffffff811247b7&gt;] encode_attrs+0x1a/0x2a4
[  110.828638]  RSP &lt;ffff88003bf5b878&gt;
[  110.828638] CR2: 0000000000000000
[  112.840396] ---[ end trace 95282e83fd77358f ]---

We need to ensure that the O_EXCL flag is turned off if the user doesn't
set O_CREAT.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0a377cff9428af2da2b293d11e07bc4dbf064ee5 upstream.

Adam Lackorzynski reports:

with 2.6.35.2 I'm getting this reproducible Oops:

[  110.825396] BUG: unable to handle kernel NULL pointer dereference at
(null)
[  110.828638] IP: [&lt;ffffffff811247b7&gt;] encode_attrs+0x1a/0x2a4
[  110.828638] PGD be89f067 PUD bf18f067 PMD 0
[  110.828638] Oops: 0000 [#1] SMP
[  110.828638] last sysfs file: /sys/class/net/lo/operstate
[  110.828638] CPU 2
[  110.828638] Modules linked in: rtc_cmos rtc_core rtc_lib amd64_edac_mod
i2c_amd756 edac_core i2c_core dm_mirror dm_region_hash dm_log dm_snapshot
sg sr_mod usb_storage ohci_hcd mptspi tg3 mptscsih mptbase usbcore nls_base
[last unloaded: scsi_wait_scan]
[  110.828638]
[  110.828638] Pid: 11264, comm: setchecksum Not tainted 2.6.35.2 #1
[  110.828638] RIP: 0010:[&lt;ffffffff811247b7&gt;]  [&lt;ffffffff811247b7&gt;]
encode_attrs+0x1a/0x2a4
[  110.828638] RSP: 0000:ffff88003bf5b878  EFLAGS: 00010296
[  110.828638] RAX: ffff8800bddb48a8 RBX: ffff88003bf5bb18 RCX:
0000000000000000
[  110.828638] RDX: ffff8800be258800 RSI: 0000000000000000 RDI:
ffff88003bf5b9f8
[  110.828638] RBP: 0000000000000000 R08: ffff8800bddb48a8 R09:
0000000000000004
[  110.828638] R10: 0000000000000003 R11: ffff8800be779000 R12:
ffff8800be258800
[  110.828638] R13: ffff88003bf5b9f8 R14: ffff88003bf5bb20 R15:
ffff8800be258800
[  110.828638] FS:  0000000000000000(0000) GS:ffff880041e00000(0063)
knlGS:00000000556bd6b0
[  110.828638] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
[  110.828638] CR2: 0000000000000000 CR3: 00000000be8ef000 CR4:
00000000000006e0
[  110.828638] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[  110.828638] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[  110.828638] Process setchecksum (pid: 11264, threadinfo
ffff88003bf5a000, task ffff88003f232210)
[  110.828638] Stack:
[  110.828638]  0000000000000000 ffff8800bfbcf920 0000000000000000
0000000000000ffe
[  110.828638] &lt;0&gt; 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[  110.828638] &lt;0&gt; 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[  110.828638] Call Trace:
[  110.828638]  [&lt;ffffffff81124c1f&gt;] ? nfs4_xdr_enc_setattr+0x90/0xb4
[  110.828638]  [&lt;ffffffff81371161&gt;] ? call_transmit+0x1c3/0x24a
[  110.828638]  [&lt;ffffffff813774d9&gt;] ? __rpc_execute+0x78/0x22a
[  110.828638]  [&lt;ffffffff81371a91&gt;] ? rpc_run_task+0x21/0x2b
[  110.828638]  [&lt;ffffffff81371b7e&gt;] ? rpc_call_sync+0x3d/0x5d
[  110.828638]  [&lt;ffffffff8111e284&gt;] ? _nfs4_do_setattr+0x11b/0x147
[  110.828638]  [&lt;ffffffff81109466&gt;] ? nfs_init_locked+0x0/0x32
[  110.828638]  [&lt;ffffffff810ac521&gt;] ? ifind+0x4e/0x90
[  110.828638]  [&lt;ffffffff8111e2fb&gt;] ? nfs4_do_setattr+0x4b/0x6e
[  110.828638]  [&lt;ffffffff8111e634&gt;] ? nfs4_do_open+0x291/0x3a6
[  110.828638]  [&lt;ffffffff8111ed81&gt;] ? nfs4_open_revalidate+0x63/0x14a
[  110.828638]  [&lt;ffffffff811056c4&gt;] ? nfs_open_revalidate+0xd7/0x161
[  110.828638]  [&lt;ffffffff810a2de4&gt;] ? do_lookup+0x1a4/0x201
[  110.828638]  [&lt;ffffffff810a4733&gt;] ? link_path_walk+0x6a/0x9d5
[  110.828638]  [&lt;ffffffff810a42b6&gt;] ? do_last+0x17b/0x58e
[  110.828638]  [&lt;ffffffff810a5fbe&gt;] ? do_filp_open+0x1bd/0x56e
[  110.828638]  [&lt;ffffffff811cd5e0&gt;] ? _atomic_dec_and_lock+0x30/0x48
[  110.828638]  [&lt;ffffffff810a9b1b&gt;] ? dput+0x37/0x152
[  110.828638]  [&lt;ffffffff810ae063&gt;] ? alloc_fd+0x69/0x10a
[  110.828638]  [&lt;ffffffff81099f39&gt;] ? do_sys_open+0x56/0x100
[  110.828638]  [&lt;ffffffff81027a22&gt;] ? ia32_sysret+0x0/0x5
[  110.828638] Code: 83 f1 01 e8 f5 ca ff ff 48 83 c4 50 5b 5d 41 5c c3 41
57 41 56 41 55 49 89 fd 41 54 49 89 d4 55 48 89 f5 53 48 81 ec 18 01 00 00
&lt;8b&gt; 06 89 c2 83 e2 08 83 fa 01 19 db 83 e3 f8 83 c3 18 a8 01 8d
[  110.828638] RIP  [&lt;ffffffff811247b7&gt;] encode_attrs+0x1a/0x2a4
[  110.828638]  RSP &lt;ffff88003bf5b878&gt;
[  110.828638] CR2: 0000000000000000
[  112.840396] ---[ end trace 95282e83fd77358f ]---

We need to ensure that the O_EXCL flag is turned off if the user doesn't
set O_CREAT.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfs: Add "lookupcache" to displayed mount options</title>
<updated>2010-08-26T23:45:53+00:00</updated>
<author>
<name>Patrick J. LoPresti</name>
<email>lopresti@gmail.com</email>
</author>
<published>2010-08-10T21:28:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=286ba0c3d1e5526a0d9600cec80f04d187465c2d'/>
<id>286ba0c3d1e5526a0d9600cec80f04d187465c2d</id>
<content type='text'>
commit 9b00c64318cc337846a7a08a5678f5f19aeff188 upstream.

Running "cat /proc/mounts" fails to display the "lookupcache" option.
This oversight cost me a bunch of wasted time recently.

The following simple patch fixes it.

Signed-off-by: Patrick LoPresti &lt;lopresti@gmail.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b00c64318cc337846a7a08a5678f5f19aeff188 upstream.

Running "cat /proc/mounts" fails to display the "lookupcache" option.
This oversight cost me a bunch of wasted time recently.

The following simple patch fixes it.

Signed-off-by: Patrick LoPresti &lt;lopresti@gmail.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix the nested PR lock calling issue in ACL</title>
<updated>2010-08-26T23:45:50+00:00</updated>
<author>
<name>Jiaju Zhang</name>
<email>jjzhang.linux@gmail.com</email>
</author>
<published>2010-07-28T05:21:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=53aaf5f20c73f7f35364aaefc01494b9cbe460b9'/>
<id>53aaf5f20c73f7f35364aaefc01494b9cbe460b9</id>
<content type='text'>
commit 845b6cf34150100deb5f58c8a37a372b111f2918 upstream.

Hi,

Thanks a lot for all the review and comments so far;) I'd like to send
the improved (V4) version of this patch.

This patch fixes a deadlock in OCFS2 ACL. We found this bug in OCFS2
and Samba integration using scenario, the symptom is several smbd
processes will be hung under heavy workload. Finally we found out it
is the nested PR lock calling that leads to this deadlock:

 node1        node2
              gr PR
                |
                V
 PR(EX)---&gt; BAST:OCFS2_LOCK_BLOCKED
                |
                V
              rq PR
                |
                V
              wait=1

After requesting the 2nd PR lock, the process "smbd" went into D
state. It can only be woken up when the 1st PR lock's RO holder equals
zero. There should be an ocfs2_inode_unlock in the calling path later
on, which can decrement the RO holder. But since it has been in
uninterruptible sleep, the unlock function has no chance to be called.

The related stack trace is:
smbd          D ffff8800013d0600     0  9522   5608 0x00000000
 ffff88002ca7fb18 0000000000000282 ffff88002f964500 ffff88002ca7fa98
 ffff8800013d0600 ffff88002ca7fae0 ffff88002f964340 ffff88002f964340
 ffff88002ca7ffd8 ffff88002ca7ffd8 ffff88002f964340 ffff88002f964340
Call Trace:
[&lt;ffffffff80350425&gt;] schedule_timeout+0x175/0x210
[&lt;ffffffff8034f580&gt;] wait_for_common+0xf0/0x210
[&lt;ffffffffa03e12b9&gt;] __ocfs2_cluster_lock+0x3b9/0xa90 [ocfs2]
[&lt;ffffffffa03e7665&gt;] ocfs2_inode_lock_full_nested+0x255/0xdb0 [ocfs2]
[&lt;ffffffffa0446019&gt;] ocfs2_get_acl+0x69/0x120 [ocfs2]
[&lt;ffffffffa0446368&gt;] ocfs2_check_acl+0x28/0x80 [ocfs2]
[&lt;ffffffff800e3507&gt;] acl_permission_check+0x57/0xb0
[&lt;ffffffff800e357d&gt;] generic_permission+0x1d/0xc0
[&lt;ffffffffa03eecea&gt;] ocfs2_permission+0x10a/0x1d0 [ocfs2]
[&lt;ffffffff800e3f65&gt;] inode_permission+0x45/0x100
[&lt;ffffffff800d86b3&gt;] sys_chdir+0x53/0x90
[&lt;ffffffff80007458&gt;] system_call_fastpath+0x16/0x1b
[&lt;00007f34a4ef6927&gt;] 0x7f34a4ef6927

For details, please see:
https://bugzilla.novell.com/show_bug.cgi?id=614332 and
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1278

Signed-off-by: Jiaju Zhang &lt;jjzhang@suse.de&gt;
Acked-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 845b6cf34150100deb5f58c8a37a372b111f2918 upstream.

Hi,

Thanks a lot for all the review and comments so far;) I'd like to send
the improved (V4) version of this patch.

This patch fixes a deadlock in OCFS2 ACL. We found this bug in OCFS2
and Samba integration using scenario, the symptom is several smbd
processes will be hung under heavy workload. Finally we found out it
is the nested PR lock calling that leads to this deadlock:

 node1        node2
              gr PR
                |
                V
 PR(EX)---&gt; BAST:OCFS2_LOCK_BLOCKED
                |
                V
              rq PR
                |
                V
              wait=1

After requesting the 2nd PR lock, the process "smbd" went into D
state. It can only be woken up when the 1st PR lock's RO holder equals
zero. There should be an ocfs2_inode_unlock in the calling path later
on, which can decrement the RO holder. But since it has been in
uninterruptible sleep, the unlock function has no chance to be called.

The related stack trace is:
smbd          D ffff8800013d0600     0  9522   5608 0x00000000
 ffff88002ca7fb18 0000000000000282 ffff88002f964500 ffff88002ca7fa98
 ffff8800013d0600 ffff88002ca7fae0 ffff88002f964340 ffff88002f964340
 ffff88002ca7ffd8 ffff88002ca7ffd8 ffff88002f964340 ffff88002f964340
Call Trace:
[&lt;ffffffff80350425&gt;] schedule_timeout+0x175/0x210
[&lt;ffffffff8034f580&gt;] wait_for_common+0xf0/0x210
[&lt;ffffffffa03e12b9&gt;] __ocfs2_cluster_lock+0x3b9/0xa90 [ocfs2]
[&lt;ffffffffa03e7665&gt;] ocfs2_inode_lock_full_nested+0x255/0xdb0 [ocfs2]
[&lt;ffffffffa0446019&gt;] ocfs2_get_acl+0x69/0x120 [ocfs2]
[&lt;ffffffffa0446368&gt;] ocfs2_check_acl+0x28/0x80 [ocfs2]
[&lt;ffffffff800e3507&gt;] acl_permission_check+0x57/0xb0
[&lt;ffffffff800e357d&gt;] generic_permission+0x1d/0xc0
[&lt;ffffffffa03eecea&gt;] ocfs2_permission+0x10a/0x1d0 [ocfs2]
[&lt;ffffffff800e3f65&gt;] inode_permission+0x45/0x100
[&lt;ffffffff800d86b3&gt;] sys_chdir+0x53/0x90
[&lt;ffffffff80007458&gt;] system_call_fastpath+0x16/0x1b
[&lt;00007f34a4ef6927&gt;] 0x7f34a4ef6927

For details, please see:
https://bugzilla.novell.com/show_bug.cgi?id=614332 and
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1278

Signed-off-by: Jiaju Zhang &lt;jjzhang@suse.de&gt;
Acked-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix list corruption after ifile creation failure</title>
<updated>2010-08-26T23:45:47+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2010-08-13T03:42:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3ab47fa1a288f370ced9e9575655151df20c04fc'/>
<id>3ab47fa1a288f370ced9e9575655151df20c04fc</id>
<content type='text'>
commit af4e36318edb848fcc0a8d5f75000ca00cdc7595 upstream.

If nilfs_attach_checkpoint() gets a memory allocation failure during
creation of ifile, it will return without removing nilfs_sb_info
struct from ns_supers list.  When a concurrently mounted snapshot is
unmounted or another new snapshot is mounted after that, this causes
kernel oops as below:

&gt; BUG: unable to handle kernel NULL pointer dereference at (null)
&gt; IP: [&lt;f83662ff&gt;] nilfs_find_sbinfo+0x74/0xa4 [nilfs2]
&gt; *pde = 00000000
&gt; Oops: 0000 [#1] SMP
&lt;snip&gt;
&gt; Call Trace:
&gt;  [&lt;f835dc29&gt;] ? nilfs_get_sb+0x165/0x532 [nilfs2]
&gt;  [&lt;c1173c87&gt;] ? ida_get_new_above+0x16d/0x187
&gt;  [&lt;c109a7f8&gt;] ? alloc_vfsmnt+0x7e/0x10a
&gt;  [&lt;c1070790&gt;] ? kstrdup+0x2c/0x40
&gt;  [&lt;c1089041&gt;] ? vfs_kern_mount+0x96/0x14e
&gt;  [&lt;c108913d&gt;] ? do_kern_mount+0x32/0xbd
&gt;  [&lt;c109b331&gt;] ? do_mount+0x642/0x6a1
&gt;  [&lt;c101a415&gt;] ? do_page_fault+0x0/0x2d1
&gt;  [&lt;c1099c00&gt;] ? copy_mount_options+0x80/0xe2
&gt;  [&lt;c10705d8&gt;] ? strndup_user+0x48/0x67
&gt;  [&lt;c109b3f1&gt;] ? sys_mount+0x61/0x90
&gt;  [&lt;c10027cc&gt;] ? sysenter_do_call+0x12/0x22

This fixes the problem.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Tested-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit af4e36318edb848fcc0a8d5f75000ca00cdc7595 upstream.

If nilfs_attach_checkpoint() gets a memory allocation failure during
creation of ifile, it will return without removing nilfs_sb_info
struct from ns_supers list.  When a concurrently mounted snapshot is
unmounted or another new snapshot is mounted after that, this causes
kernel oops as below:

&gt; BUG: unable to handle kernel NULL pointer dereference at (null)
&gt; IP: [&lt;f83662ff&gt;] nilfs_find_sbinfo+0x74/0xa4 [nilfs2]
&gt; *pde = 00000000
&gt; Oops: 0000 [#1] SMP
&lt;snip&gt;
&gt; Call Trace:
&gt;  [&lt;f835dc29&gt;] ? nilfs_get_sb+0x165/0x532 [nilfs2]
&gt;  [&lt;c1173c87&gt;] ? ida_get_new_above+0x16d/0x187
&gt;  [&lt;c109a7f8&gt;] ? alloc_vfsmnt+0x7e/0x10a
&gt;  [&lt;c1070790&gt;] ? kstrdup+0x2c/0x40
&gt;  [&lt;c1089041&gt;] ? vfs_kern_mount+0x96/0x14e
&gt;  [&lt;c108913d&gt;] ? do_kern_mount+0x32/0xbd
&gt;  [&lt;c109b331&gt;] ? do_mount+0x642/0x6a1
&gt;  [&lt;c101a415&gt;] ? do_page_fault+0x0/0x2d1
&gt;  [&lt;c1099c00&gt;] ? copy_mount_options+0x80/0xe2
&gt;  [&lt;c10705d8&gt;] ? strndup_user+0x48/0x67
&gt;  [&lt;c109b3f1&gt;] ? sys_mount+0x61/0x90
&gt;  [&lt;c10027cc&gt;] ? sysenter_do_call+0x12/0x22

This fixes the problem.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Tested-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2/dlm: remove potential deadlock -V3</title>
<updated>2010-08-26T23:45:47+00:00</updated>
<author>
<name>Wengang Wang</name>
<email>wen.gang.wang@oracle.com</email>
</author>
<published>2010-07-30T15:18:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7b5b07e30b8341d54c1f311772c9183eaa1cfa7a'/>
<id>7b5b07e30b8341d54c1f311772c9183eaa1cfa7a</id>
<content type='text'>
commit b11f1f1ab73fd358b1b734a9427744802202ba68 upstream.

When we need to take both dlm_domain_lock and dlm-&gt;spinlock, we should take
them in order of: dlm_domain_lock then dlm-&gt;spinlock.

There is pathes disobey this order. That is calling dlm_lockres_put() with
dlm-&gt;spinlock held in dlm_run_purge_list. dlm_lockres_put() calls dlm_put() at
the ref and dlm_put() locks on dlm_domain_lock.

Fix:
Don't grab/put the dlm when the initialising/releasing lockres.
That grab is not required because we don't call dlm_unregister_domain()
based on refcount.

Signed-off-by: Wengang Wang &lt;wen.gang.wang@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b11f1f1ab73fd358b1b734a9427744802202ba68 upstream.

When we need to take both dlm_domain_lock and dlm-&gt;spinlock, we should take
them in order of: dlm_domain_lock then dlm-&gt;spinlock.

There is pathes disobey this order. That is calling dlm_lockres_put() with
dlm-&gt;spinlock held in dlm_run_purge_list. dlm_lockres_put() calls dlm_put() at
the ref and dlm_put() locks on dlm_domain_lock.

Fix:
Don't grab/put the dlm when the initialising/releasing lockres.
That grab is not required because we don't call dlm_unregister_domain()
based on refcount.

Signed-off-by: Wengang Wang &lt;wen.gang.wang@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2/dlm: avoid incorrect bit set in refmap on recovery master</title>
<updated>2010-08-26T23:45:47+00:00</updated>
<author>
<name>Wengang Wang</name>
<email>wen.gang.wang@oracle.com</email>
</author>
<published>2010-07-30T08:14:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d79caba7b9f51221576fb4afe7dc0e165bdd0485'/>
<id>d79caba7b9f51221576fb4afe7dc0e165bdd0485</id>
<content type='text'>
commit a524812b7eaa7783d7811198921100f079034e61 upstream.

In the following situation, there remains an incorrect bit in refmap on the
recovery master. Finally the recovery master will fail at purging the lockres
due to the incorrect bit in refmap.

1) node A has no interest on lockres A any longer, so it is purging it.
2) the owner of lockres A is node B, so node A is sending de-ref message
to node B.
3) at this time, node B crashed. node C becomes the recovery master. it recovers
lockres A(because the master is the dead node B).
4) node A migrated lockres A to node C with a refbit there.
5) node A failed to send de-ref message to node B because it crashed. The failure
is ignored. no other action is done for lockres A any more.

For mormal, re-send the deref message to it to recovery master can fix it. Well,
ignoring the failure of deref to the original master and not recovering the lockres
to recovery master has the same effect. And the later is simpler.

Signed-off-by: Wengang Wang &lt;wen.gang.wang@oracle.com&gt;
Acked-by: Srinivas Eeda &lt;srinivas.eeda@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a524812b7eaa7783d7811198921100f079034e61 upstream.

In the following situation, there remains an incorrect bit in refmap on the
recovery master. Finally the recovery master will fail at purging the lockres
due to the incorrect bit in refmap.

1) node A has no interest on lockres A any longer, so it is purging it.
2) the owner of lockres A is node B, so node A is sending de-ref message
to node B.
3) at this time, node B crashed. node C becomes the recovery master. it recovers
lockres A(because the master is the dead node B).
4) node A migrated lockres A to node C with a refbit there.
5) node A failed to send de-ref message to node B because it crashed. The failure
is ignored. no other action is done for lockres A any more.

For mormal, re-send the deref message to it to recovery master can fix it. Well,
ignoring the failure of deref to the original master and not recovering the lockres
to recovery master has the same effect. And the later is simpler.

Signed-off-by: Wengang Wang &lt;wen.gang.wang@oracle.com&gt;
Acked-by: Srinivas Eeda &lt;srinivas.eeda@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2: Count more refcount records in file system fragmentation.</title>
<updated>2010-08-26T23:45:46+00:00</updated>
<author>
<name>Tao Ma</name>
<email>tao.ma@oracle.com</email>
</author>
<published>2010-07-22T05:56:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6d4ff3b0d4438f1d3707720299c32aa7715a4317'/>
<id>6d4ff3b0d4438f1d3707720299c32aa7715a4317</id>
<content type='text'>
commit 8a2e70c40ff58f82dde67770e6623ca45f0cb0c8 upstream.

The refcount record calculation in ocfs2_calc_refcount_meta_credits
is too optimistic that we can always allocate contiguous clusters
and handle an already existed refcount rec as a whole. Actually
because of file system fragmentation, we may have the chance to split
a refcount record into 3 parts during the transaction. So consider
the worst case in record calculation.

Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8a2e70c40ff58f82dde67770e6623ca45f0cb0c8 upstream.

The refcount record calculation in ocfs2_calc_refcount_meta_credits
is too optimistic that we can always allocate contiguous clusters
and handle an already existed refcount rec as a whole. Actually
because of file system fragmentation, we may have the chance to split
a refcount record into 3 parts during the transaction. So consider
the worst case in record calculation.

Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2 fix o2dlm dlm run purgelist (rev 3)</title>
<updated>2010-08-26T23:45:46+00:00</updated>
<author>
<name>Srinivas Eeda</name>
<email>srinivas.eeda@oracle.com</email>
</author>
<published>2010-07-19T23:04:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=caee59ec914e90b06df487fc348fe4780d3c7a34'/>
<id>caee59ec914e90b06df487fc348fe4780d3c7a34</id>
<content type='text'>
commit 7beaf243787f85a2ef9213ccf13ab4a243283fde upstream.

This patch fixes two problems in dlm_run_purgelist

1. If a lockres is found to be in use, dlm_run_purgelist keeps trying to purge
the same lockres instead of trying the next lockres.

2. When a lockres is found unused, dlm_run_purgelist releases lockres spinlock
before setting DLM_LOCK_RES_DROPPING_REF and calls dlm_purge_lockres.
spinlock is reacquired but in this window lockres can get reused. This leads
to BUG.

This patch modifies dlm_run_purgelist to skip lockres if it's in use and purge
 next lockres. It also sets DLM_LOCK_RES_DROPPING_REF before releasing the
lockres spinlock protecting it from getting reused.

Signed-off-by: Srinivas Eeda &lt;srinivas.eeda@oracle.com&gt;
Acked-by: Sunil Mushran &lt;sunil.mushran@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7beaf243787f85a2ef9213ccf13ab4a243283fde upstream.

This patch fixes two problems in dlm_run_purgelist

1. If a lockres is found to be in use, dlm_run_purgelist keeps trying to purge
the same lockres instead of trying the next lockres.

2. When a lockres is found unused, dlm_run_purgelist releases lockres spinlock
before setting DLM_LOCK_RES_DROPPING_REF and calls dlm_purge_lockres.
spinlock is reacquired but in this window lockres can get reused. This leads
to BUG.

This patch modifies dlm_run_purgelist to skip lockres if it's in use and purge
 next lockres. It also sets DLM_LOCK_RES_DROPPING_REF before releasing the
lockres spinlock protecting it from getting reused.

Signed-off-by: Srinivas Eeda &lt;srinivas.eeda@oracle.com&gt;
Acked-by: Sunil Mushran &lt;sunil.mushran@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2/dlm: fix a dead lock</title>
<updated>2010-08-26T23:45:46+00:00</updated>
<author>
<name>Wengang Wang</name>
<email>wen.gang.wang@oracle.com</email>
</author>
<published>2010-07-16T15:13:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3730039f40020c1f8d1d94752ecbd1375cf705f9'/>
<id>3730039f40020c1f8d1d94752ecbd1375cf705f9</id>
<content type='text'>
commit 6d98c3ccb52f692f1a60339dde7c700686a5568b upstream.

When we have to take both dlm-&gt;master_lock and lockres-&gt;spinlock,
take them in order

lockres-&gt;spinlock and then dlm-&gt;master_lock.

The patch fixes a violation of the rule.
We can simply move taking dlm-&gt;master_lock to where we have dropped res-&gt;spinlock
since when we access res-&gt;state and free mle memory we don't need master_lock's
protection.

Signed-off-by: Wengang Wang &lt;wen.gang.wang@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6d98c3ccb52f692f1a60339dde7c700686a5568b upstream.

When we have to take both dlm-&gt;master_lock and lockres-&gt;spinlock,
take them in order

lockres-&gt;spinlock and then dlm-&gt;master_lock.

The patch fixes a violation of the rule.
We can simply move taking dlm-&gt;master_lock to where we have dropped res-&gt;spinlock
since when we access res-&gt;state and free mle memory we don't need master_lock's
protection.

Signed-off-by: Wengang Wang &lt;wen.gang.wang@oracle.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
