linux-toradex.git/fs, branch v2.6.31.2

Fix idle time field in /proc/uptime

2009-10-05T16:33:01+00:00

commit 96830a57de1197519b62af6a4c9ceea556c18c3d upstream.

Git commit 79741dd changes idle cputime accounting, but unfortunately
the /proc/uptime file hasn't caught up.  Here the idle time calculation
from /proc/stat is copied over.

Signed-off-by: Michael Abbott 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

/proc/kcore: work around a BUG()

2009-10-05T16:32:54+00:00

Not upstream due to other fixes in .32


Works around a BUG() which is triggered when the kernel accesses holes in
vmalloc regions.

BUG: unable to handle kernel paging request at fa54c000
IP: [] read_kcore+0x260/0x31a
*pde = 3540b067 *pte = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0/state
Modules linked in: fuse sco bridge stp llc bnep l2cap bluetooth sunrpc nf_conntrack_ftp ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput usb_storage arc4 ecb snd_hda_codec_realtek snd_hda_intel ath5k snd_hda_codec snd_hwdep iTCO_wdt snd_pcm iTCO_vendor_support pcspkr i2c_i801 mac80211 joydev snd_timer serio_raw r8169 snd soundcore mii snd_page_alloc ath cfg80211 ata_generic i915 drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
Sep  4 12:45:16 tuxedu kernel: Pid: 2266, comm: cat Not tainted (2.6.31-rc8 #2) Joybook Lite U101
EIP: 0060:[] EFLAGS: 00010286 CPU: 0
EIP is at read_kcore+0x260/0x31a
EAX: f5e5ea00 EBX: fa54d000 ECX: 00000400 EDX: 00001000
ESI: fa54c000 EDI: f44ad000 EBP: e4533f4c ESP: e4533f24
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process cat (pid: 2266, ti=e4532000 task=f09d19a0 task.ti=e4532000)
Stack:
00005000 00000000 f44ad000 09d9c000 00003000 fa54c000 00001000 f6d16f60
 e4520b80 fffffffb e4533f70 c04ef8eb e4533f98 00008000 09d97000 c04f661a
 e4520b80 09d97000 c04ef88c e4533f8c c04ba531 e4533f98 c04c0930 e4520b80
Call Trace:
[] ? proc_reg_read+0x5f/0x73
[] ? read_kcore+0x0/0x31a
[] ? proc_reg_read+0x0/0x73
[] ? vfs_read+0x82/0xe1
[] ? path_put+0x1a/0x1d
[] ? sys_read+0x40/0x62
[] ? sysenter_do_call+0x12/0x2d
Code: 39 f3 89 ca 0f 43 f3 89 fb 29 f2 29 f3 39 cf 0f 46 d3 29 55 dc 8d 1c 32 f6 40 0c 01 75 18 89 d1 89 f7 c1 e9 02 2b 7d ec 03 7d e0  a5 89 d1 83 e1 03 74 02 f3 a4 8b 00 83 7d dc 00 74 04 85 c0
EIP: [] read_kcore+0x260/0x31a SS:ESP 0068:e4533f24
CR2: 00000000fa54c000


To access vmalloc area which may have memory holes, copy_from_user is
useful.  So this:

 # cat /proc/kcore > /dev/null

will not panic.

This is a minimal fix, suitable for 2.6.30.x and 2.6.31.  More extensive
/proc/kcore changes are planned for 2.6.32.

Signed-off-by: KAMEZAWA Hiroyuki 
Tested-by: Nick Craig-Wood 
Cc: Pekka Enberg 
Reported-by: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

nfsd4: fix null dereference creating nfsv4 callback client

2009-10-05T16:32:12+00:00

commit 886e3b7fe6054230c89ae078a09565ed183ecc73 upstream.

On setting up the callback to the client, we attempt to use the same
authentication flavor the client did.  We find an rpc cred to use by
calling rpcauth_lookup_credcache(), which assumes that the given
authentication flavor has a credentials cache.  However, this is not
required to be true--in particular, auth_null does not use one.
Instead, we should call the auth's lookup_cred() method.

Without this, a client attempting to mount using nfsv4 and auth_null
triggers a null dereference.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

nilfs2: fix missing zero-fill initialization of btree node cache

2009-10-05T16:31:50+00:00

commit 1f28fcd925b2b3157411bbd08f0024b55b70d8dd upstream.

This will fix file system corruption which infrequently happens after
mount.  The problem was reported from users with the title "[NILFS
users] Fail to mount NILFS." (Message-ID:
<200908211918.34720.yuri@itinteg.net>), and so forth.  I've also
experienced the corruption multiple times on kernel 2.6.30 and 2.6.31.

The problem turned out to be caused due to discordance between
mapping->nrpages of a btree node cache and the actual number of pages
hung on the cache; if the mapping->nrpages becomes zero even as it has
pages, truncate_inode_pages() returns without doing anything.  Usually
this is harmless except it may cause page leak, but garbage collection
fairly infrequently sees a stale page remained in the btree node cache
of DAT (i.e. disk address translation file of nilfs), and induces the
corruption.

I identified a missing initialization in btree node caches was the
root cause.  This corrects the bug.

I've tested this for kernel 2.6.30 and 2.6.31.

Reported-by: Yuri Chislov 
Signed-off-by: Ryusuke Konishi 
Signed-off-by: Greg Kroah-Hartman

Re-enable Lanman security

2009-10-05T16:31:42+00:00

commit 20d1752f3d6bd32beb90949559e0d14a0b234445 upstream.

commit ac68392460ffefed13020967bae04edc4d3add06 ("[CIFS] Allow raw
ntlmssp code to be enabled with sec=ntlmssp") added a new bit to the
allowed security flags mask but seems to have inadvertently removed
Lanman security from the allowed flags. Add it back.

Signed-off-by: Chuck Ebbert 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Prevent lower dentry from going negative during unlink

2009-10-05T16:31:42+00:00

commit 9c2d2056647790c5034d722bd24e9d913ebca73c upstream.

When calling vfs_unlink() on the lower dentry, d_delete() turns the
dentry into a negative dentry when the d_count is 1.  This eventually
caused a NULL pointer deref when a read() or write() was done and the
negative dentry's d_inode was dereferenced in
ecryptfs_read_update_atime() or ecryptfs_getxattr().

Placing mutt's tmpdir in an eCryptfs mount is what initially triggered
the oops and I was able to reproduce it with the following sequence:

open("/tmp/upper/foo", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 3
link("/tmp/upper/foo", "/tmp/upper/bar") = 0
unlink("/tmp/upper/foo")                = 0
open("/tmp/upper/bar", O_RDWR|O_CREAT|O_NOFOLLOW, 0600) = 4
unlink("/tmp/upper/bar")                = 0
write(4, "eCryptfs test\n"..., 14 
+++ killed by SIGKILL +++

https://bugs.launchpad.net/ecryptfs/+bug/387073

Reported-by: Loïc Minier 
Cc: Serge Hallyn 
Cc: Dave Kleikamp 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Validate global auth tok keys

2009-10-05T16:31:41+00:00

commit 3891959846709a19f76628e33478cd85edb0e79f upstream.

When searching through the global authentication tokens for a given key
signature, verify that a matching key has not been revoked and has not
expired.  This allows the `keyctl revoke` command to be properly used on
keys in use by eCryptfs.

Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Filename encryption only supports password auth tokens

2009-10-05T16:31:41+00:00

commit df6ad33ba1b9846bd5f0e2b9016c30c20bc2d948 upstream.

Returns -ENOTSUPP when attempting to use filename encryption with
something other than a password authentication token, such as a private
token from openssl.  Using filename encryption with a userspace eCryptfs
key module is a future goal.  Until then, this patch handles the
situation a little better than simply using a BUG_ON().

Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Check for O_RDONLY lower inodes when opening lower files

2009-10-05T16:31:40+00:00

commit ac22ba23b659e34a5961aec8c945608e471b0d5b upstream.

If the lower inode is read-only, don't attempt to open the lower file
read/write and don't hand off the open request to the privileged
eCryptfs kthread for opening it read/write.  Instead, only try an
unprivileged, read-only open of the file and give up if that fails.
This patch fixes an oops when eCryptfs is mounted on top of a read-only
mount.

Acked-by: Serge Hallyn 
Cc: Eric Sandeen 
Cc: Dave Kleikamp 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Handle unrecognized tag 3 cipher codes

2009-10-05T16:31:40+00:00

commit b0105eaefa7cce8f4a941d0fc6354b250d30e745 upstream.

Returns an error when an unrecognized cipher code is present in a tag 3
packet or an ecryptfs_crypt_stat cannot be initialized.  Also sets an
crypt_stat->tfm error pointer to NULL to ensure that it will not be
incorrectly freed in ecryptfs_destroy_crypt_stat().

Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman