<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/sunrpc, branch linux-2.6.36.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>sunrpc: prevent use-after-free on clearing XPT_BUSY</title>
<updated>2011-01-07T21:58:17+00:00</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2010-11-16T05:55:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e98a198d7100de320d794ba26d03e087cc3c230d'/>
<id>e98a198d7100de320d794ba26d03e087cc3c230d</id>
<content type='text'>
commit ed2849d3ecfa339435818eeff28f6c3424300cec upstream.

When an xprt is created, it has a refcount of 1, and XPT_BUSY is set.
The refcount is *not* owned by the thread that created the xprt
(as is clear from the fact that creators never put the reference).
Rather, it is owned by the absence of XPT_DEAD.  Once XPT_DEAD is set,
(And XPT_BUSY is clear) that initial reference is dropped and the xprt
can be freed.

So when a creator clears XPT_BUSY it is dropping its only reference and
so must not touch the xprt again.

However svc_recv, after calling -&gt;xpo_accept (and so getting an XPT_BUSY
reference on a new xprt), calls svc_xprt_recieved.  This clears
XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference.
This is dangerous and has been seen to leave svc_xprt_enqueue working
with an xprt containing garbage.

So we need to hold an extra counted reference over that call to
svc_xprt_received.

For safety, any time we clear XPT_BUSY and then use the xprt again, we
first get a reference, and the put it again afterwards.

Note that svc_close_all does not need this extra protection as there are
no threads running, and the final free can only be called asynchronously
from such a thread.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.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 ed2849d3ecfa339435818eeff28f6c3424300cec upstream.

When an xprt is created, it has a refcount of 1, and XPT_BUSY is set.
The refcount is *not* owned by the thread that created the xprt
(as is clear from the fact that creators never put the reference).
Rather, it is owned by the absence of XPT_DEAD.  Once XPT_DEAD is set,
(And XPT_BUSY is clear) that initial reference is dropped and the xprt
can be freed.

So when a creator clears XPT_BUSY it is dropping its only reference and
so must not touch the xprt again.

However svc_recv, after calling -&gt;xpo_accept (and so getting an XPT_BUSY
reference on a new xprt), calls svc_xprt_recieved.  This clears
XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference.
This is dangerous and has been seen to leave svc_xprt_enqueue working
with an xprt containing garbage.

So we need to hold an extra counted reference over that call to
svc_xprt_received.

For safety, any time we clear XPT_BUSY and then use the xprt again, we
first get a reference, and the put it again afterwards.

Note that svc_close_all does not need this extra protection as there are
no threads running, and the final free can only be called asynchronously
from such a thread.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SUNRPC: After calling xprt_release(), we must restart from call_reserve</title>
<updated>2010-12-09T21:32:18+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2010-10-24T21:17:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2193d2c2d019b495320b442b18958400cd827b12'/>
<id>2193d2c2d019b495320b442b18958400cd827b12</id>
<content type='text'>
commit 118df3d17f11733b294ea2cd988d56ee376ef9fd upstream.

Rob Leslie reports seeing the following Oops after his Kerberos session
expired.

BUG: unable to handle kernel NULL pointer dereference at 00000058
IP: [&lt;e186ed94&gt;] rpcauth_refreshcred+0x11/0x12c [sunrpc]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/platform/pc87360.26144/temp3_input
Modules linked in: autofs4 authenc esp4 xfrm4_mode_transport ipt_LOG ipt_REJECT xt_limit xt_state ipt_REDIRECT xt_owner xt_HL xt_hl xt_tcpudp xt_mark cls_u32 cls_tcindex sch_sfq sch_htb sch_dsmark geodewdt deflate ctr twofish_generic twofish_i586 twofish_common camellia serpent blowfish cast5 cbc xcbc rmd160 sha512_generic sha1_generic hmac crypto_null af_key rpcsec_gss_krb5 nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip_gre sit tunnel4 dummy ext3 jbd nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pc8736x_gpio nsc_gpio pc87360 hwmon_vid loop aes_i586 aes_generic sha256_generic dm_crypt cs5535_gpio serio_raw cs5535_mfgpt hifn_795x des_generic geode_rng rng_core led_class ext4 mbcache jbd2 crc16 dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sd_mod crc_t10dif ide_pci_generic cs5536 amd74xx ide_core pata_cs5536 ata_generic libata usb_storage via_rhine mii scsi_mod btrfs zlib_deflate crc32c libcrc32c [last unloaded: scsi_wait_scan]

Pid: 12875, comm: sudo Not tainted 2.6.36-net5501 #1 /
EIP: 0060:[&lt;e186ed94&gt;] EFLAGS: 00010292 CPU: 0
EIP is at rpcauth_refreshcred+0x11/0x12c [sunrpc]
EAX: 00000000 EBX: defb13a0 ECX: 00000006 EDX: e18683b8
ESI: defb13a0 EDI: 00000000 EBP: 00000000 ESP: de571d58
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sudo (pid: 12875, ti=de570000 task=decd1430 task.ti=de570000)
Stack:
 e186e008 00000000 defb13a0 0000000d deda6000 e1868f22 e196f12b defb13a0
&lt;0&gt; defb13d8 00000000 00000000 e186e0aa 00000000 defb13a0 de571dac 00000000
&lt;0&gt; e186956c de571e34 debea5c0 de571dc8 e186967a 00000000 debea5c0 de571e34
Call Trace:
 [&lt;e186e008&gt;] ? rpc_wake_up_next+0x114/0x11b [sunrpc]
 [&lt;e1868f22&gt;] ? call_decode+0x24a/0x5af [sunrpc]
 [&lt;e196f12b&gt;] ? nfs4_xdr_dec_access+0x0/0xa2 [nfs]
 [&lt;e186e0aa&gt;] ? __rpc_execute+0x62/0x17b [sunrpc]
 [&lt;e186956c&gt;] ? rpc_run_task+0x91/0x97 [sunrpc]
 [&lt;e186967a&gt;] ? rpc_call_sync+0x40/0x5b [sunrpc]
 [&lt;e1969ca2&gt;] ? nfs4_proc_access+0x10a/0x176 [nfs]
 [&lt;e19572fa&gt;] ? nfs_do_access+0x2b1/0x2c0 [nfs]
 [&lt;e186ed61&gt;] ? rpcauth_lookupcred+0x62/0x84 [sunrpc]
 [&lt;e19573b6&gt;] ? nfs_permission+0xad/0x13b [nfs]
 [&lt;c0177824&gt;] ? exec_permission+0x15/0x4b
 [&lt;c0177fbd&gt;] ? link_path_walk+0x4f/0x456
 [&lt;c017867d&gt;] ? path_walk+0x4c/0xa8
 [&lt;c0179678&gt;] ? do_path_lookup+0x1f/0x68
 [&lt;c017a3fb&gt;] ? user_path_at+0x37/0x5f
 [&lt;c016359c&gt;] ? handle_mm_fault+0x229/0x55b
 [&lt;c0170a2d&gt;] ? sys_faccessat+0x93/0x146
 [&lt;c0170aef&gt;] ? sys_access+0xf/0x13
 [&lt;c02cf615&gt;] ? syscall_call+0x7/0xb
Code: 0f 94 c2 84 d2 74 09 8b 44 24 0c e8 6a e9 8b de 83 c4 14 89 d8 5b 5e 5f 5d c3 55 57 56 53 83 ec 1c fc 89 c6 8b 40 10 89 44 24 04 &lt;8b&gt; 58 58 85 db 0f 85 d4 00 00 00 0f b7 46 70 8b 56 20 89 c5 83
EIP: [&lt;e186ed94&gt;] rpcauth_refreshcred+0x11/0x12c [sunrpc] SS:ESP 0068:de571d58
CR2: 0000000000000058

This appears to be caused by the function rpc_verify_header() first
calling xprt_release(), then doing a call_refresh. If we release the
transport slot, we should _always_ jump back to call_reserve before
calling anything else.

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 118df3d17f11733b294ea2cd988d56ee376ef9fd upstream.

Rob Leslie reports seeing the following Oops after his Kerberos session
expired.

BUG: unable to handle kernel NULL pointer dereference at 00000058
IP: [&lt;e186ed94&gt;] rpcauth_refreshcred+0x11/0x12c [sunrpc]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/platform/pc87360.26144/temp3_input
Modules linked in: autofs4 authenc esp4 xfrm4_mode_transport ipt_LOG ipt_REJECT xt_limit xt_state ipt_REDIRECT xt_owner xt_HL xt_hl xt_tcpudp xt_mark cls_u32 cls_tcindex sch_sfq sch_htb sch_dsmark geodewdt deflate ctr twofish_generic twofish_i586 twofish_common camellia serpent blowfish cast5 cbc xcbc rmd160 sha512_generic sha1_generic hmac crypto_null af_key rpcsec_gss_krb5 nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip_gre sit tunnel4 dummy ext3 jbd nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pc8736x_gpio nsc_gpio pc87360 hwmon_vid loop aes_i586 aes_generic sha256_generic dm_crypt cs5535_gpio serio_raw cs5535_mfgpt hifn_795x des_generic geode_rng rng_core led_class ext4 mbcache jbd2 crc16 dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sd_mod crc_t10dif ide_pci_generic cs5536 amd74xx ide_core pata_cs5536 ata_generic libata usb_storage via_rhine mii scsi_mod btrfs zlib_deflate crc32c libcrc32c [last unloaded: scsi_wait_scan]

Pid: 12875, comm: sudo Not tainted 2.6.36-net5501 #1 /
EIP: 0060:[&lt;e186ed94&gt;] EFLAGS: 00010292 CPU: 0
EIP is at rpcauth_refreshcred+0x11/0x12c [sunrpc]
EAX: 00000000 EBX: defb13a0 ECX: 00000006 EDX: e18683b8
ESI: defb13a0 EDI: 00000000 EBP: 00000000 ESP: de571d58
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sudo (pid: 12875, ti=de570000 task=decd1430 task.ti=de570000)
Stack:
 e186e008 00000000 defb13a0 0000000d deda6000 e1868f22 e196f12b defb13a0
&lt;0&gt; defb13d8 00000000 00000000 e186e0aa 00000000 defb13a0 de571dac 00000000
&lt;0&gt; e186956c de571e34 debea5c0 de571dc8 e186967a 00000000 debea5c0 de571e34
Call Trace:
 [&lt;e186e008&gt;] ? rpc_wake_up_next+0x114/0x11b [sunrpc]
 [&lt;e1868f22&gt;] ? call_decode+0x24a/0x5af [sunrpc]
 [&lt;e196f12b&gt;] ? nfs4_xdr_dec_access+0x0/0xa2 [nfs]
 [&lt;e186e0aa&gt;] ? __rpc_execute+0x62/0x17b [sunrpc]
 [&lt;e186956c&gt;] ? rpc_run_task+0x91/0x97 [sunrpc]
 [&lt;e186967a&gt;] ? rpc_call_sync+0x40/0x5b [sunrpc]
 [&lt;e1969ca2&gt;] ? nfs4_proc_access+0x10a/0x176 [nfs]
 [&lt;e19572fa&gt;] ? nfs_do_access+0x2b1/0x2c0 [nfs]
 [&lt;e186ed61&gt;] ? rpcauth_lookupcred+0x62/0x84 [sunrpc]
 [&lt;e19573b6&gt;] ? nfs_permission+0xad/0x13b [nfs]
 [&lt;c0177824&gt;] ? exec_permission+0x15/0x4b
 [&lt;c0177fbd&gt;] ? link_path_walk+0x4f/0x456
 [&lt;c017867d&gt;] ? path_walk+0x4c/0xa8
 [&lt;c0179678&gt;] ? do_path_lookup+0x1f/0x68
 [&lt;c017a3fb&gt;] ? user_path_at+0x37/0x5f
 [&lt;c016359c&gt;] ? handle_mm_fault+0x229/0x55b
 [&lt;c0170a2d&gt;] ? sys_faccessat+0x93/0x146
 [&lt;c0170aef&gt;] ? sys_access+0xf/0x13
 [&lt;c02cf615&gt;] ? syscall_call+0x7/0xb
Code: 0f 94 c2 84 d2 74 09 8b 44 24 0c e8 6a e9 8b de 83 c4 14 89 d8 5b 5e 5f 5d c3 55 57 56 53 83 ec 1c fc 89 c6 8b 40 10 89 44 24 04 &lt;8b&gt; 58 58 85 db 0f 85 d4 00 00 00 0f b7 46 70 8b 56 20 89 c5 83
EIP: [&lt;e186ed94&gt;] rpcauth_refreshcred+0x11/0x12c [sunrpc] SS:ESP 0068:de571d58
CR2: 0000000000000058

This appears to be caused by the function rpc_verify_header() first
calling xprt_release(), then doing a call_refresh. If we release the
transport slot, we should _always_ jump back to call_reserve before
calling anything else.

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>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6</title>
<updated>2010-09-28T19:01:26+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-09-28T19:01:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a2724f28d9f99b7b42e800b528902f0e3321873b'/>
<id>a2724f28d9f99b7b42e800b528902f0e3321873b</id>
<content type='text'>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (47 commits)
  tcp: Fix &gt;4GB writes on 64-bit.
  net/9p: Mount only matching virtio channels
  de2104x: fix ethtool
  tproxy: check for transparent flag in ip_route_newports
  ipv6: add IPv6 to neighbour table overflow warning
  tcp: fix TSO FACK loss marking in tcp_mark_head_lost
  3c59x: fix regression from patch "Add ethtool WOL support"
  ipv6: add a missing unregister_pernet_subsys call
  s390: use free_netdev(netdev) instead of kfree()
  sgiseeq: use free_netdev(netdev) instead of kfree()
  rionet: use free_netdev(netdev) instead of kfree()
  ibm_newemac: use free_netdev(netdev) instead of kfree()
  smsc911x: Add MODULE_ALIAS()
  net: reset skb queue mapping when rx'ing over tunnel
  br2684: fix scheduling while atomic
  de2104x: fix TP link detection
  de2104x: fix power management
  de2104x: disable autonegotiation on broken hardware
  net: fix a lockdep splat
  e1000e: 82579 do not gate auto config of PHY by hardware during nominal use
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (47 commits)
  tcp: Fix &gt;4GB writes on 64-bit.
  net/9p: Mount only matching virtio channels
  de2104x: fix ethtool
  tproxy: check for transparent flag in ip_route_newports
  ipv6: add IPv6 to neighbour table overflow warning
  tcp: fix TSO FACK loss marking in tcp_mark_head_lost
  3c59x: fix regression from patch "Add ethtool WOL support"
  ipv6: add a missing unregister_pernet_subsys call
  s390: use free_netdev(netdev) instead of kfree()
  sgiseeq: use free_netdev(netdev) instead of kfree()
  rionet: use free_netdev(netdev) instead of kfree()
  ibm_newemac: use free_netdev(netdev) instead of kfree()
  smsc911x: Add MODULE_ALIAS()
  net: reset skb queue mapping when rx'ing over tunnel
  br2684: fix scheduling while atomic
  de2104x: fix TP link detection
  de2104x: fix power management
  de2104x: disable autonegotiation on broken hardware
  net: fix a lockdep splat
  e1000e: 82579 do not gate auto config of PHY by hardware during nominal use
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>net: fix a lockdep splat</title>
<updated>2010-09-25T05:26:10+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2010-09-22T12:43:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f064af1e500a2bf4607706f0f458163bdb2a6ea5'/>
<id>f064af1e500a2bf4607706f0f458163bdb2a6ea5</id>
<content type='text'>
We have for each socket :

One spinlock (sk_slock.slock)
One rwlock (sk_callback_lock)

Possible scenarios are :

(A) (this is used in net/sunrpc/xprtsock.c)
read_lock(&amp;sk-&gt;sk_callback_lock) (without blocking BH)
&lt;BH&gt;
spin_lock(&amp;sk-&gt;sk_slock.slock);
...
read_lock(&amp;sk-&gt;sk_callback_lock);
...

(B)
write_lock_bh(&amp;sk-&gt;sk_callback_lock)
stuff
write_unlock_bh(&amp;sk-&gt;sk_callback_lock)

(C)
spin_lock_bh(&amp;sk-&gt;sk_slock)
...
write_lock_bh(&amp;sk-&gt;sk_callback_lock)
stuff
write_unlock_bh(&amp;sk-&gt;sk_callback_lock)
spin_unlock_bh(&amp;sk-&gt;sk_slock)

This (C) case conflicts with (A) :

CPU1 [A]                         CPU2 [C]
read_lock(callback_lock)
&lt;BH&gt;                             spin_lock_bh(slock)
&lt;wait to spin_lock(slock)&gt;
                                 &lt;wait to write_lock_bh(callback_lock)&gt;

We have one problematic (C) use case in inet_csk_listen_stop() :

local_bh_disable();
bh_lock_sock(child); // spin_lock_bh(&amp;sk-&gt;sk_slock)
WARN_ON(sock_owned_by_user(child));
...
sock_orphan(child); // write_lock_bh(&amp;sk-&gt;sk_callback_lock)

lockdep is not happy with this, as reported by Tetsuo Handa

It seems only way to deal with this is to use read_lock_bh(callbacklock)
everywhere.

Thanks to Jarek for pointing a bug in my first attempt and suggesting
this solution.

Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Tested-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
CC: Jarek Poplawski &lt;jarkao2@gmail.com&gt;
Tested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have for each socket :

One spinlock (sk_slock.slock)
One rwlock (sk_callback_lock)

Possible scenarios are :

(A) (this is used in net/sunrpc/xprtsock.c)
read_lock(&amp;sk-&gt;sk_callback_lock) (without blocking BH)
&lt;BH&gt;
spin_lock(&amp;sk-&gt;sk_slock.slock);
...
read_lock(&amp;sk-&gt;sk_callback_lock);
...

(B)
write_lock_bh(&amp;sk-&gt;sk_callback_lock)
stuff
write_unlock_bh(&amp;sk-&gt;sk_callback_lock)

(C)
spin_lock_bh(&amp;sk-&gt;sk_slock)
...
write_lock_bh(&amp;sk-&gt;sk_callback_lock)
stuff
write_unlock_bh(&amp;sk-&gt;sk_callback_lock)
spin_unlock_bh(&amp;sk-&gt;sk_slock)

This (C) case conflicts with (A) :

CPU1 [A]                         CPU2 [C]
read_lock(callback_lock)
&lt;BH&gt;                             spin_lock_bh(slock)
&lt;wait to spin_lock(slock)&gt;
                                 &lt;wait to write_lock_bh(callback_lock)&gt;

We have one problematic (C) use case in inet_csk_listen_stop() :

local_bh_disable();
bh_lock_sock(child); // spin_lock_bh(&amp;sk-&gt;sk_slock)
WARN_ON(sock_owned_by_user(child));
...
sock_orphan(child); // write_lock_bh(&amp;sk-&gt;sk_callback_lock)

lockdep is not happy with this, as reported by Tetsuo Handa

It seems only way to deal with this is to use read_lock_bh(callbacklock)
everywhere.

Thanks to Jarek for pointing a bug in my first attempt and suggesting
this solution.

Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Tested-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
CC: Jarek Poplawski &lt;jarkao2@gmail.com&gt;
Tested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sunrpc: increase MAX_HASHTABLE_BITS to 14</title>
<updated>2010-09-12T23:55:26+00:00</updated>
<author>
<name>Miquel van Smoorenburg</name>
<email>mikevs@xs4all.net</email>
</author>
<published>2010-09-12T23:55:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db5fe26541b6b48460104a0d949a27cdc7786957'/>
<id>db5fe26541b6b48460104a0d949a27cdc7786957</id>
<content type='text'>
The maximum size of the authcache is now set to 1024 (10 bits),
but on our server we need at least 4096 (12 bits). Increase
MAX_HASHTABLE_BITS to 14. This is a maximum of 16384 entries,
each containing a pointer (8 bytes on x86_64). This is
exactly the limit of kmalloc() (128K).

Signed-off-by: Miquel van Smoorenburg &lt;mikevs@xs4all.net&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The maximum size of the authcache is now set to 1024 (10 bits),
but on our server we need at least 4096 (12 bits). Increase
MAX_HASHTABLE_BITS to 14. This is a maximum of 16384 entries,
each containing a pointer (8 bytes on x86_64). This is
exactly the limit of kmalloc() (128K).

Signed-off-by: Miquel van Smoorenburg &lt;mikevs@xs4all.net&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gss:spkm3 miss returning error to caller when import security context</title>
<updated>2010-09-12T23:55:26+00:00</updated>
<author>
<name>Bian Naimeng</name>
<email>biannm@cn.fujitsu.com</email>
</author>
<published>2010-09-12T23:55:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=651b2933b22a0c060e6bb940c4104eb447a61f9a'/>
<id>651b2933b22a0c060e6bb940c4104eb447a61f9a</id>
<content type='text'>
spkm3 miss returning error to up layer when import security context,
it may be return ok though it has failed to import security context.

Signed-off-by: Bian Naimeng &lt;biannm@cn.fujitsu.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
spkm3 miss returning error to up layer when import security context,
it may be return ok though it has failed to import security context.

Signed-off-by: Bian Naimeng &lt;biannm@cn.fujitsu.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gss:krb5 miss returning error to caller when import security context</title>
<updated>2010-09-12T23:55:25+00:00</updated>
<author>
<name>Bian Naimeng</name>
<email>biannm@cn.fujitsu.com</email>
</author>
<published>2010-09-12T23:55:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ce8477e1176389ed920550f4c925ad4a815b22d5'/>
<id>ce8477e1176389ed920550f4c925ad4a815b22d5</id>
<content type='text'>
krb5 miss returning error to up layer when import security context,
it may be return ok though it has failed to import security context.

Signed-off-by: Bian Naimeng &lt;biannm@cn.fujitsu.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
krb5 miss returning error to up layer when import security context,
it may be return ok though it has failed to import security context.

Signed-off-by: Bian Naimeng &lt;biannm@cn.fujitsu.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>SUNRPC: cleanup state-machine ordering</title>
<updated>2010-09-12T23:55:25+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2010-09-12T23:55:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=55576244eba805307a2b2b6a145b8f85f8c7c124'/>
<id>55576244eba805307a2b2b6a145b8f85f8c7c124</id>
<content type='text'>
This is just a minor cleanup: net/sunrpc/clnt.c clarifies the rpc client
state machine by commenting each state and by laying out the functions
implementing each state in the order that each state is normally
executed (in the absence of errors).

The previous patch "Fix null dereference in call_allocate" changed the
order of the states.  Move the functions and update the comments to
reflect the change.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is just a minor cleanup: net/sunrpc/clnt.c clarifies the rpc client
state machine by commenting each state and by laying out the functions
implementing each state in the order that each state is normally
executed (in the absence of errors).

The previous patch "Fix null dereference in call_allocate" changed the
order of the states.  Move the functions and update the comments to
reflect the change.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>SUNRPC: Fix a race in rpc_info_open</title>
<updated>2010-09-12T23:55:25+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2010-09-12T23:55:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=006abe887c5e637d059c44310de6c92f36aded3b'/>
<id>006abe887c5e637d059c44310de6c92f36aded3b</id>
<content type='text'>
There is a race between rpc_info_open and rpc_release_client()
in that nothing stops a process from opening the file after
the clnt-&gt;cl_kref goes to zero.

Fix this by using atomic_inc_unless_zero()...

Reported-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Cc: stable@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is a race between rpc_info_open and rpc_release_client()
in that nothing stops a process from opening the file after
the clnt-&gt;cl_kref goes to zero.

Fix this by using atomic_inc_unless_zero()...

Reported-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Cc: stable@kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>SUNRPC: Fix race corrupting rpc upcall</title>
<updated>2010-09-12T23:55:25+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2010-09-12T23:55:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5a67657a2e90c9e4a48518f95d4ba7777aa20fbb'/>
<id>5a67657a2e90c9e4a48518f95d4ba7777aa20fbb</id>
<content type='text'>
If rpc_queue_upcall() adds a new upcall to the rpci-&gt;pipe list just
after rpc_pipe_release calls rpc_purge_list(), but before it calls
gss_pipe_release (as rpci-&gt;ops-&gt;release_pipe(inode)), then the latter
will free a message without deleting it from the rpci-&gt;pipe list.

We will be left with a freed object on the rpc-&gt;pipe list.  Most
frequent symptoms are kernel crashes in rpc.gssd system calls on the
pipe in question.

Reported-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Cc: stable@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If rpc_queue_upcall() adds a new upcall to the rpci-&gt;pipe list just
after rpc_pipe_release calls rpc_purge_list(), but before it calls
gss_pipe_release (as rpci-&gt;ops-&gt;release_pipe(inode)), then the latter
will free a message without deleting it from the rpci-&gt;pipe list.

We will be left with a freed object on the rpc-&gt;pipe list.  Most
frequent symptoms are kernel crashes in rpc.gssd system calls on the
pipe in question.

Reported-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Cc: stable@kernel.org
</pre>
</div>
</content>
</entry>
</feed>
