snowball/legacy-kernel.git/include, branch igloo-dev

Squash

2011-12-16T14:04:55+00:00

Change-Id: I2fcf46d1fc4b0cd4c61e5be3654c43b80db86015

NFS: Fix spurious readdir cookie loop messages

2011-10-28T09:14:32+00:00

commit 0c0308066ca53fdf1423895f3a42838b67b3a5a8 upstream. If the directory contents change, then we have to accept that the file->f_pos value may shrink if we do a 'search-by-cookie'. In that case, we should turn off the loop detection and let the NFS client try to recover. The patch also fixes a second loop detection bug by ensuring that after turning on the ctx->duped flag, we read at least one new cookie into ctx->dir_cookie before attempting to match with ctx->dup_cookie. Reported-by: Petr Vandrovec Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Change-Id: Ibe4963eb5f9f34251713f1e5776d6b409e04616a Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35658 Tested-by: Per VAHLNE Reviewed-by: Jonas ABERG

mm/futex: fix futex writes on archs with SW tracking of dirty & young

2011-10-28T09:12:52+00:00

commit 2efaca927f5cd7ecd0f1554b8f9b6a9a2c329c03 upstream. I haven't reproduced it myself but the fail scenario is that on such machines (notably ARM and some embedded powerpc), if you manage to hit that futex path on a writable page whose dirty bit has gone from the PTE, you'll livelock inside the kernel from what I can tell. It will go in a loop of trying the atomic access, failing, trying gup to "fix it up", getting succcess from gup, go back to the atomic access, failing again because dirty wasn't fixed etc... So I think you essentially hang in the kernel. The scenario is probably rare'ish because affected architecture are embedded and tend to not swap much (if at all) so we probably rarely hit the case where dirty is missing or young is missing, but I think Shan has a piece of SW that can reliably reproduce it using a shared writable mapping & fork or something like that. On archs who use SW tracking of dirty & young, a page without dirty is effectively mapped read-only and a page without young unaccessible in the PTE. Additionally, some architectures might lazily flush the TLB when relaxing write protection (by doing only a local flush), and expect a fault to invalidate the stale entry if it's still present on another processor. The futex code assumes that if the "in_atomic()" access -EFAULT's, it can "fix it up" by causing get_user_pages() which would then be equivalent to taking the fault. However that isn't the case. get_user_pages() will not call handle_mm_fault() in the case where the PTE seems to have the right permissions, regardless of the dirty and young state. It will eventually update those bits ... in the struct page, but not in the PTE. Additionally, it will not handle the lazy TLB flushing that can be required by some architectures in the fault case. Basically, gup is the wrong interface for the job. The patch provides a more appropriate one which boils down to just calling handle_mm_fault() since what we are trying to do is simulate a real page fault. The futex code currently attempts to write to user memory within a pagefault disabled section, and if that fails, tries to fix it up using get_user_pages(). This doesn't work on archs where the dirty and young bits are maintained by software, since they will gate access permission in the TLB, and will not be updated by gup(). In addition, there's an expectation on some archs that a spurious write fault triggers a local TLB flush, and that is missing from the picture as well. I decided that adding those "features" to gup() would be too much for this already too complex function, and instead added a new simpler fixup_user_fault() which is essentially a wrapper around handle_mm_fault() which the futex code can call. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix some nits Darren saw, fiddle comment layout] Signed-off-by: Benjamin Herrenschmidt Reported-by: Shan Hai Tested-by: Shan Hai Cc: David Laight Acked-by: Peter Zijlstra Cc: Darren Hart Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Change-Id: I84219e4262cc051c141432cd60ac15809251e132 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35645 Tested-by: Per VAHLNE Reviewed-by: Jonas ABERG

pnfs: let layoutcommit handle a list of lseg

2011-10-28T09:10:49+00:00

commit a9bae5666d0510ad69bdb437371c9a3e6b770705 upstream. There can be multiple lseg per file, so layoutcommit should be able to handle it. [Needed in v3.0] Signed-off-by: Peng Tao Signed-off-by: Boaz Harrosh Signed-off-by: Jim Rees Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Change-Id: I713a4a2a5eede21594125db9682a025a82142559 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35632 Tested-by: Per VAHLNE Reviewed-by: Jonas ABERG

firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing

2011-10-28T09:07:42+00:00

commit 93b37905f70083d6143f5f4dba0a45cc64379a62 upstream. Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events to be read(2) by the client. The get_info ioctl is practically always issued right away after open, hence this condition only occurs if the client opens during a bus reset, especially during a rapid series of bus resets. The problem with this condition is twofold: - These bus reset events carry the (as yet undocumented) @closure value of 0. But it is not the kernel's place to choose closures; they are privat to the client. E.g., this 0 value forced from the kernel makes it unsafe for clients to dereference it as a pointer to a closure object without NULL pointer check. - It is impossible for clients to determine the relative order of bus reset events from get_info ioctl(2) versus those from read(2), except in one way: By comparison of closure values. Again, such a procedure imposes complexity on clients and reduces freedom in use of the bus reset closure. So, change the ABI to suppress queuing of bus reset events before the first FW_CDEV_IOC_GET_INFO ioctl was issued by the client. Note, this ABI change cannot be version-controlled. The kernel cannot distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO ioctl. We will try to back-merge this change into currently maintained stable/ longterm series, and we only document the new behaviour. The old behavior is now considered a kernel bug, which it basically is. Signed-off-by: Stefan Richter Cc: Change-Id: I790e269d95885c36b492d735bf457d4c2b103387 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35609 Tested-by: Per VAHLNE Reviewed-by: QABUILD Reviewed-by: Jonas ABERG

gro: Only reset frag0 when skb can be pulled

2011-10-28T09:03:43+00:00

commit 17dd759c67f21e34f2156abcf415e1f60605a188 upstream. Currently skb_gro_header_slow unconditionally resets frag0 and frag0_len. However, when we can't pull on the skb this leaves the GRO fields in an inconsistent state. This patch fixes this by only resetting those fields after the pskb_may_pull test. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Change-Id: Ib97b8d7f52c19c34283adf2382403c9bf9dac9f0 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35584 Tested-by: Per VAHLNE Reviewed-by: Jonas ABERG

ipv6: updates to privacy addresses per RFC 4941

2011-10-28T09:02:46+00:00

Update the code to handle some of the differences between RFC 3041 and RFC 4941, which obsoletes it. Also a couple of janitorial fixes. - Allow router advertisements to increase the lifetime of temporary addresses. This was not allowed by RFC 3041, but is specified by RFC 4941. It is useful when RA lifetimes are lower than TEMP_{VALID,PREFERRED}_LIFETIME: in this case, the previous code would delete or deprecate addresses prematurely. - Change the default of MAX_RETRY to 3 per RFC 4941. - Add a comment to clarify that the preferred and valid lifetimes in inet6_ifaddr are relative to the timestamp. - Shorten lines to 80 characters in a couple of places. Change-Id: I4da097664d4b1de7c1cebf410895319601c7f1cc Signed-off-by: Lorenzo Colitti Signed-off-by: JP Abgrall Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35579 Tested-by: Per VAHLNE Reviewed-by: Jonas ABERG

u8500 : USB :New notification events for BatMan

2011-10-28T06:22:54+00:00

Added notification events for ACA cases so that battery manager can distinguish between Standard Host and ACA charger. ST-Ericsson Linux next: NA ST-Ericsson ID: 362951 ST-Ericsson FOSS-OUT ID: Trivial Signed-off-by: rajaram Signed-off-by: Sakethram Bommisetti Change-Id: I02a19bced97b408990d8effb785418bf182ac27b Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34862 Tested-by: Rajaram REGUPATHY Reviewed-by: Praveena NADAHALLY Reviewed-by: Rabin VINCENT

u5500: add MTIMER clocksource

2011-10-28T03:03:33+00:00

ST-Ericsson ID: 368260 ST-Ericsson Linux next: NA ST-Ericsson FOSS-OUT ID: Trivial Depends-On: I5307cb7f58fdf890896d641a8e4f49098a90b68e Change-Id: I9ef4ff1c63f6ec9293ece4013f13cf3caa707d9d Signed-off-by: Rabin Vincent Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34307 Reviewed-by: QATOOLS Reviewed-by: QABUILD

PM / Runtime: Add new helper function: pm_runtime_status_suspended()

2011-10-27T14:35:24+00:00

This boolean function simply returns whether or not the runtime status of the device is 'suspended'. Unlike pm_runtime_suspended(), this function returns the runtime status whether or not runtime PM for the device has been disabled or not. Also add entry to Documentation/power/runtime.txt Signed-off-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Change-Id: I2e31841f087b5d44a0f4d6e2f8bba2d08cfc7b64 Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35338 Reviewed-by: QABUILD Reviewed-by: Linus WALLEIJ Tested-by: Ulf HANSSON