commit 5b765b08fa5fbbba1131dcc459f8991d81e4f8d7 Author: Paul Gortmaker Date: Mon Aug 20 14:45:22 2012 -0400 Linux 2.6.34.13 Signed-off-by: Paul Gortmaker commit 201095fcd2b848cd22711f9a58d1ffd0c9f3e458 Author: Tony Luck Date: Fri Jul 20 13:15:20 2012 -0700 dmi: Feed DMI table to /dev/random driver commit d114a33387472555188f142ed8e98acdb8181c6d upstream. Send the entire DMI (SMBIOS) table to the /dev/random driver to help seed its pools. Signed-off-by: Tony Luck Signed-off-by: Theodore Ts'o Signed-off-by: Paul Gortmaker commit 3c3c74c6f281415dddd68a645d89dde2f0d9eadd Author: Mark Brown Date: Thu Jul 5 20:23:21 2012 +0000 mfd: wm831x: Feed the device UUID into device_add_randomness() commit 27130f0cc3ab97560384da437e4621fc4e94f21c upstream. wm831x devices contain a unique ID value. Feed this into the newly added device_add_randomness() to add some per device seed data to the pool. Signed-off-by: Mark Brown Signed-off-by: Theodore Ts'o Signed-off-by: Paul Gortmaker commit 81976041c01befe815e8411d78b7118a8522251c Author: Mark Brown Date: Thu Jul 5 20:19:17 2012 +0000 rtc: wm831x: Feed the write counter into device_add_randomness() commit 9dccf55f4cb011a7552a8a2749a580662f5ed8ed upstream. The tamper evident features of the RTC include the "write counter" which is a pseudo-random number regenerated whenever we set the RTC. Since this value is unpredictable it should provide some useful seeding to the random number generator. Only do this on boot since the goal is to seed the pool rather than add useful entropy. Signed-off-by: Mark Brown Signed-off-by: Theodore Ts'o Signed-off-by: Paul Gortmaker commit aed22e34348fd7914fafcd9d35c58de486ce7a0a Author: Tony Luck Date: Mon Jul 23 09:47:57 2012 -0700 random: Add comment to random_initialize() commit cbc96b7594b5691d61eba2db8b2ea723645be9ca upstream. Many platforms have per-machine instance data (serial numbers, asset tags, etc.) squirreled away in areas that are accessed during early system bringup. Mixing this data into the random pools has a very high value in providing better random data, so we should allow (and even encourage) architecture code to call add_device_randomness() from the setup_arch() paths. However, this limits our options for internal structure of the random driver since random_initialize() is not called until long after setup_arch(). Add a big fat comment to rand_initialize() spelling out this requirement. Suggested-by: Theodore Ts'o Signed-off-by: Tony Luck Signed-off-by: Theodore Ts'o Signed-off-by: Paul Gortmaker commit b1e34220df49a66f2bdd52eb2326252e819eefe1 Author: Theodore Ts'o Date: Sat Jul 14 20:27:52 2012 -0400 random: remove rand_initialize_irq() commit c5857ccf293968348e5eb4ebedc68074de3dcda6 upstream. With the new interrupt sampling system, we are no longer using the timer_rand_state structure in the irq descriptor, so we can stop initializing it now. [ Merged in fixes from Sedat to find some last missing references to rand_initialize_irq() ] Signed-off-by: "Theodore Ts'o" Signed-off-by: Sedat Dilek [PG: in .34 the irqdesc.h content is in irq.h instead.] Signed-off-by: Paul Gortmaker commit e0e0a1bbba898b34a416c5e646fc374a5f55b3ab Author: Theodore Ts'o Date: Wed Jul 4 21:23:25 2012 -0400 net: feed /dev/random with the MAC address when registering a device commit 7bf2357524408b97fec58344caf7397f8140c3fd upstream. Cc: David Miller Cc: Linus Torvalds Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit ec0b0f6434c99db2c51cbdfcfc62b1daeca47b96 Author: Theodore Ts'o Date: Wed Jul 4 11:22:20 2012 -0400 usb: feed USB device information to the /dev/random driver commit b04b3156a20d395a7faa8eed98698d1e17a36000 upstream. Send the USB device's serial, product, and manufacturer strings to the /dev/random driver to help seed its pools. Cc: Linus Torvalds Acked-by: Greg KH Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 327fb10ff1a3a59679e3cc36fe795c913300e80e Author: Theodore Ts'o Date: Wed Jul 4 11:32:48 2012 -0400 MAINTAINERS: Theodore Ts'o is taking over the random driver commit 330e0a01d54c2b8606c56816f99af6ebc58ec92c upstream. Matt Mackall stepped down as the /dev/random driver maintainer last year, so Theodore Ts'o is taking back the /dev/random driver. Cc: Matt Mackall Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 239b3337f4b6773eaedfee2e32f84d305faaeef3 Author: H. Peter Anvin Date: Fri Jul 27 22:26:08 2012 -0400 random: mix in architectural randomness in extract_buf() commit d2e7c96af1e54b507ae2a6a7dd2baf588417a7e5 upstream. Mix in any architectural randomness in extract_buf() instead of xfer_secondary_buf(). This allows us to mix in more architectural randomness, and it also makes xfer_secondary_buf() faster, moving a tiny bit of additional CPU overhead to process which is extracting the randomness. [ Commit description modified by tytso to remove an extended advertisement for the RDRAND instruction. ] Signed-off-by: H. Peter Anvin Acked-by: Ingo Molnar Cc: DJ Johnston Signed-off-by: Theodore Ts'o Signed-off-by: Paul Gortmaker commit 8dd6c36ae7dfc0b226bd8037c0e42b46e0f2f521 Author: Theodore Ts'o Date: Wed Jul 4 16:19:30 2012 -0400 random: add tracepoints for easier debugging and verification commit 00ce1db1a634746040ace24c09a4e3a7949a3145 upstream. Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 07a7a14461916efd7bc42aa6a31aac5fed972191 Author: Theodore Ts'o Date: Thu Jul 5 10:35:23 2012 -0400 random: add new get_random_bytes_arch() function commit c2557a303ab6712bb6e09447df828c557c710ac9 upstream. Create a new function, get_random_bytes_arch() which will use the architecture-specific hardware random number generator if it is present. Change get_random_bytes() to not use the HW RNG, even if it is avaiable. The reason for this is that the hw random number generator is fast (if it is present), but it requires that we trust the hardware manufacturer to have not put in a back door. (For example, an increasing counter encrypted by an AES key known to the NSA.) It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure. Since users of get_random_bytes() in the Linux kernel need to be able to support hardware systems where the HW RNG is not present, most time-sensitive users of this interface have already created their own cryptographic RNG interface which uses get_random_bytes() as a seed. So it's much better to use the HW RNG to improve the existing random number generator, by mixing in any entropy returned by the HW RNG into /dev/random's entropy pool, but to always _use_ /dev/random's entropy pool. This way we get almost of the benefits of the HW RNG without any potential liabilities. The only benefits we forgo is the speed/performance enhancements --- and generic kernel code can't depend on depend on get_random_bytes() having the speed of a HW RNG anyway. For those places that really want access to the arch-specific HW RNG, if it is available, we provide get_random_bytes_arch(). Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 477ebbedc0cfbaf923e53c5bcf65958cdd167404 Author: Theodore Ts'o Date: Thu Jul 5 10:21:01 2012 -0400 random: use the arch-specific rng in xfer_secondary_pool commit e6d4947b12e8ad947add1032dd754803c6004824 upstream. If the CPU supports a hardware random number generator, use it in xfer_secondary_pool(), where it will significantly improve things and where we can afford it. Also, remove the use of the arch-specific rng in add_timer_randomness(), since the call is significantly slower than get_cycles(), and we're much better off using it in xfer_secondary_pool() anyway. Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 79df207bf71de0fc8c2de8d0eead6cd9283a85ed Author: Linus Torvalds Date: Wed Jul 4 11:16:01 2012 -0400 random: create add_device_randomness() interface commit a2080a67abe9e314f9e9c2cc3a4a176e8a8f8793 upstream. Add a new interface, add_device_randomness() for adding data to the random pool that is likely to differ between two devices (or possibly even per boot). This would be things like MAC addresses or serial numbers, or the read-out of the RTC. This does *not* add any actual entropy to the pool, but it initializes the pool to different values for devices that might otherwise be identical and have very little entropy available to them (particularly common in the embedded world). [ Modified by tytso to mix in a timestamp, since there may be some variability caused by the time needed to detect/configure the hardware in question. ] Signed-off-by: Linus Torvalds Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 9233ef75a68d43f82dbd4bf699177c4f9f55a1a3 Author: Theodore Ts'o Date: Wed Jul 4 10:38:30 2012 -0400 random: use lockless techniques in the interrupt path commit 902c098a3663de3fa18639efbb71b6080f0bcd3c upstream. The real-time Linux folks don't like add_interrupt_randomness() taking a spinlock since it is called in the low-level interrupt routine. This also allows us to reduce the overhead in the fast path, for the random driver, which is the interrupt collection path. Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 17ef73f8c0be242d38efe9b28d9caaca9c3ef442 Author: Theodore Ts'o Date: Mon Jul 2 07:52:16 2012 -0400 random: make 'add_interrupt_randomness()' do something sane commit 775f4b297b780601e61787b766f306ed3e1d23eb upstream. We've been moving away from add_interrupt_randomness() for various reasons: it's too expensive to do on every interrupt, and flooding the CPU with interrupts could theoretically cause bogus floods of entropy from a somewhat externally controllable source. This solves both problems by limiting the actual randomness addition to just once a second or after 64 interrupts, whicever comes first. During that time, the interrupt cycle data is buffered up in a per-cpu pool. Also, we make sure the the nonblocking pool used by urandom is initialized before we start feeding the normal input pool. This assures that /dev/urandom is returning unpredictable data as soon as possible. (Based on an original patch by Linus, but significantly modified by tytso.) Tested-by: Eric Wustrow Reported-by: Eric Wustrow Reported-by: Nadia Heninger Reported-by: Zakir Durumeric Reported-by: J. Alex Halderman . Signed-off-by: Linus Torvalds Signed-off-by: "Theodore Ts'o" [PG: minor adjustment required since .34 doesn't have f9e4989eb8 which renames "status" to "random" in kernel/irq/handle.c ] Signed-off-by: Paul Gortmaker commit a5c606bc8eef5c3153477f1eb0c6fbf54972e40a Author: Mathieu Desnoyers Date: Thu Apr 12 12:49:12 2012 -0700 drivers/char/random.c: fix boot id uniqueness race commit 44e4360fa3384850d65dd36fb4e6e5f2f112709b upstream. /proc/sys/kernel/random/boot_id can be read concurrently by userspace processes. If two (or more) user-space processes concurrently read boot_id when sysctl_bootid is not yet assigned, a race can occur making boot_id differ between the reads. Because the whole point of the boot id is to be unique across a kernel execution, fix this by protecting this operation with a spinlock. Given that this operation is not frequently used, hitting the spinlock on each call should not be an issue. Signed-off-by: Mathieu Desnoyers Cc: "Theodore Ts'o" Cc: Matt Mackall Signed-off-by: Eric Dumazet Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 82cffd3ed464797e5f6f5095591748a04f076e01 Author: H. Peter Anvin Date: Mon Jan 16 11:23:29 2012 -0800 random: Adjust the number of loops when initializing commit 2dac8e54f988ab58525505d7ef982493374433c3 upstream. When we are initializing using arch_get_random_long() we only need to loop enough times to touch all the bytes in the buffer; using poolwords for that does twice the number of operations necessary on a 64-bit machine, since in the random number generator code "word" means 32 bits. Signed-off-by: H. Peter Anvin Cc: "Theodore Ts'o" Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu Signed-off-by: Paul Gortmaker commit 7d81bad9704b9c54ea18edd32ba95fd84c4190c8 Author: Theodore Ts'o Date: Thu Dec 22 16:28:01 2011 -0500 random: Use arch-specific RNG to initialize the entropy store commit 3e88bdff1c65145f7ba297ccec69c774afe4c785 upstream. If there is an architecture-specific random number generator (such as RDRAND for Intel architectures), use it to initialize /dev/random's entropy stores. Even in the worst case, if RDRAND is something like AES(NSA_KEY, counter++), it won't hurt, and it will definitely help against any other adversaries. Signed-off-by: "Theodore Ts'o" Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit fdc3835ef99c2912c8dc1216023a23f913f9ee94 Author: Linus Torvalds Date: Thu Dec 22 11:36:22 2011 -0800 random: Use arch_get_random_int instead of cycle counter if avail commit cf833d0b9937874b50ef2867c4e8badfd64948ce upstream. We still don't use rdrand in /dev/random, which just seems stupid. We accept the *cycle*counter* as a random input, but we don't accept rdrand? That's just broken. Sure, people can do things in user space (write to /dev/random, use rdrand in addition to /dev/random themselves etc etc), but that *still* seems to be a particularly stupid reason for saying "we shouldn't bother to try to do better in /dev/random". And even if somebody really doesn't trust rdrand as a source of random bytes, it seems singularly stupid to trust the cycle counter *more*. So I'd suggest the attached patch. I'm not going to even bother arguing that we should add more bits to the entropy estimate, because that's not the point - I don't care if /dev/random fills up slowly or not, I think it's just stupid to not use the bits we can get from rdrand and mix them into the strong randomness pool. Link: http://lkml.kernel.org/r/CA%2B55aFwn59N1=m651QAyTy-1gO1noGbK18zwKDwvwqnravA84A@mail.gmail.com Acked-by: "David S. Miller" Acked-by: "Theodore Ts'o" Acked-by: Herbert Xu Cc: Matt Mackall Cc: Tony Luck Cc: Eric Dumazet Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 5f5fe51544214bce4f5caa598a7a51e7663fbac1 Author: Luck, Tony Date: Wed Nov 16 10:50:56 2011 -0800 fix typo/thinko in get_random_bytes() commit bd29e568a4cb6465f6e5ec7c1c1f3ae7d99cbec1 upstream. If there is an architecture-specific random number generator we use it to acquire randomness one "long" at a time. We should put these random words into consecutive words in the result buffer - not just overwrite the first word again and again. Signed-off-by: Tony Luck Acked-by: H. Peter Anvin Acked-by: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit e4e2e412f4292b63031220064f6ab6f804bd5aaf Author: H. Peter Anvin Date: Sun Jul 31 13:59:29 2011 -0700 x86, random: Architectural inlines to get random integers with RDRAND commit 628c6246d47b85f5357298601df2444d7f4dd3fd upstream. Architectural inlines to get random ints and longs using the RDRAND instruction. Intel has introduced a new RDRAND instruction, a Digital Random Number Generator (DRNG), which is functionally an high bandwidth entropy source, cryptographic whitener, and integrity monitor all built into hardware. This enables RDRAND to be used directly, bypassing the kernel random number pool. For technical documentation, see: http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/ In this patch, this is *only* used for the nonblocking random number pool. RDRAND is a nonblocking source, similar to our /dev/urandom, and is therefore not a direct replacement for /dev/random. The architectural hooks presented in the previous patch only feed the kernel internal users, which only use the nonblocking pool, and so this is not a problem. Since this instruction is available in userspace, there is no reason to have a /dev/hw_rng device driver for the purpose of feeding rngd. This is especially so since RDRAND is a nonblocking source, and needs additional whitening and reduction (see the above technical documentation for details) in order to be of "pure entropy source" quality. The CONFIG_EXPERT compile-time option can be used to disable this use of RDRAND. Signed-off-by: H. Peter Anvin Originally-by: Fenghua Yu Cc: Matt Mackall Cc: Herbert Xu Cc: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit aae8201cb804c0c7582841fa9edc6ef6a43e5fd2 Author: H. Peter Anvin Date: Sun Jul 31 13:54:50 2011 -0700 random: Add support for architectural random hooks commit 63d77173266c1791f1553e9e8ccea65dc87c4485 upstream. Add support for architecture-specific hooks into the kernel-directed random number generator interfaces. This patchset does not use the architecture random number generator interfaces for the userspace-directed interfaces (/dev/random and /dev/urandom), thus eliminating the need to distinguish between them based on a pool pointer. Changes in version 3: - Moved the hooks from extract_entropy() to get_random_bytes(). - Changes the hooks to inlines. Signed-off-by: H. Peter Anvin Cc: Fenghua Yu Cc: Matt Mackall Cc: Herbert Xu Cc: "Theodore Ts'o" [PG: .34 already had "unsigned int ret" in get_random_int, so the diffstat here is slightly smaller than that of 63d7717. ] Signed-off-by: Paul Gortmaker commit 6c35e17eda15aca777df7e5d57214628987fa5f6 Author: Kees Cook Date: Tue May 24 16:29:26 2011 -0700 x86, cpufeature: Update CPU feature RDRND to RDRAND commit 7ccafc5f75c87853f3c49845d5a884f2376e03ce upstream. The Intel manual changed the name of the CPUID bit to match the instruction name. We should follow suit for sanity's sake. (See Intel SDM Volume 2, Table 3-20 "Feature Information Returned in the ECX Register".) [ hpa: we can only do this at this time because there are currently no CPUs with this feature on the market, hence this is pre-hardware enabling. However, Cc:'ing stable so that stable can present a consistent ABI. ] Signed-off-by: Kees Cook Link: http://lkml.kernel.org/r/20110524232926.GA27728@outflux.net Signed-off-by: H. Peter Anvin Cc: Fenghua Yu Signed-off-by: Paul Gortmaker commit 35ea221a23b7f4295713be3271f54d33f3bd5cec Author: H. Peter Anvin Date: Wed Jul 7 10:15:12 2010 -0700 x86, cpu: Add CPU flags for F16C and RDRND commit 24da9c26f3050aee9314ec09930a24c80fe76352 upstream. Add support for the newly documented F16C (16-bit floating point conversions) and RDRND (RDRAND instruction) CPU feature flags. Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit e133225eaec606e3ad08d94347fc40c51f350baa Author: Matt Mackall Date: Thu May 20 19:55:01 2010 +1000 random: simplify fips mode commit e954bc91bdd4bb08b8325478c5004b24a23a3522 upstream. Rather than dynamically allocate 10 bytes, move it to static allocation. This saves space and avoids the need for error checking. Signed-off-by: Matt Mackall Signed-off-by: Herbert Xu [PG: adding this simplifies required updates to random for .34 stable] Signed-off-by: Paul Gortmaker commit c983dc67d7497a1247c9116689198475755144df Author: sordna Date: Thu Oct 27 21:06:26 2011 -0700 USB: quirks: adding more quirky webcams to avoid squeaky audio commit 0d145d7d4a241c321c832a810bb6edad18e2217b upstream. The following patch contains additional affected webcam models, on top of the patches commited to linux-next 2394d67e446bf616a0885167d5f0d397bdacfdfc and 5b253d88cc6c65a23cefc457a5a4ef139913c5fc Signed-off-by: sordna Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 9b509e7ac1ac20aff5f0c13afcb1e4089227c022 Author: Josh Boyer Date: Wed Oct 26 13:53:17 2011 -0400 USB: add quirk for Logitech C600 web cam commit 60c71ca972a2dd3fd9d0165b405361c8ad48349b upstream. We've had another report of the "chipmunk" sound on a Logitech C600 webcam. This patch resolves the issue. Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 432bc4aa49105127524ad91672803924e4848f6e Author: Alan Stern Date: Tue Oct 25 10:50:58 2011 -0400 usb-storage: Accept 8020i-protocol commands longer than 12 bytes commit 2f640bf4c94324aeaa1b6385c10aab8c5ad1e1cf upstream. The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands; shorter commands must be padded. Simon Detheridge reports that his 3-TB USB disk drive claims to use the 8020i protocol (which is normally meant for ATAPI devices like CD drives), and because of its large size, the disk drive requires the use of 16-byte commands. However the usb_stor_pad12_command() routine in usb-storage always sets the command length to 12, making the drive impossible to use. Since the SFF-8020i specification allows for 16-byte commands in future extensions, we may as well accept them. This patch (as1490) changes usb_stor_pad12_command() to leave commands larger than 12 bytes alone rather than truncating them. Signed-off-by: Alan Stern Tested-by: Simon Detheridge CC: Matthew Dharm Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 87ece72cc91a8fb96013070ca12cb1a02c2d4605 Author: Johan Hovold Date: Wed Jan 18 01:46:00 2012 +0100 USB: ftdi_sio: fix initial baud rate commit 108e02b12921078a59dcacd048079ece48a4a983 upstream. Fix regression introduced by commit b1ffb4c851f1 ("USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c") which caused the termios settings to no longer be initialised at open. Consequently it was no longer possible to set the port to the default speed of 9600 baud without first changing to another baud rate and back again. Reported-by: Roland Ramthun Signed-off-by: Johan Hovold Tested-by: Roland Ramthun Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 0094fccd1201357997f37f796c6527b15d698e2a Author: Andrew Worsley Date: Fri Nov 18 23:13:33 2011 +1100 USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c commit b1ffb4c851f185e9051ba837c16d9b84ef688d26 upstream. Fix for ftdi_set_termios() glitching output ftdi_set_termios() is constantly setting the baud rate, data bits and parity unnecessarily on every call, . When called while characters are being transmitted can cause the FTDI chip to corrupt the serial port bit stream output by stalling the output half a bit during the output of a character. Simple fix by skipping this setting if the baud rate/data bits/parity are unchanged. Signed-off-by: Andrew Worsley ---- I had a brief run with strace on the getty and it was doing ioctl()s on each call but it didn't look relavant to the problem. I think the issue is that XON/XOFF flow control was being implmented via hardware - for the ixoff to allow the user to use XON/XOFF to control output. Unfortunately it would send 3 Control URBs updating all of the settings after each piece of input I am trying to work around the issue of gmail messing with the tab/spacing by submitting via SMTP via gmail which I believe should fix the issue. The patch is against v3.2-rc2 and compiles - but no additional testing in this kernel has been done. Thanks Andrew Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 3472a9cb47e2e56f57bd894654dad4491e0568ab Author: wangyanqing Date: Thu Nov 10 14:04:08 2011 +0800 USB: serial: pl2303: rm duplicate id commit 0c16595539b612fe948559433dda08ff96a8bdc7 upstream. I get report from customer that his usb-serial converter doesn't work well,it sometimes work, but sometimes it doesn't. The usb-serial converter's id: vendor_id product_id 0x4348 0x5523 Then I search the usb-serial codes, and there are two drivers announce support this device, pl2303 and ch341, commit 026dfaf1 cause it. Through many times to test, ch341 works well with this device, and pl2303 doesn't work quite often(it just work quite little). ch341 works well with this device, so we doesn't need pl2303 to support.I try to revert 026dfaf1 first, but it failed. So I prepare this patch by hand to revert it. Signed-off-by: Wang YanQing Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 0c40eb266446a96cd0f4ef361513105d5f2d8788 Author: Michal Marek Date: Mon May 2 12:51:15 2011 +0200 kbuild: Fix passing -Wno-* options to gcc 4.4+ commit 8417da6f2128008c431c7d130af6cd3d9079922e upstream. Starting with 4.4, gcc will happily accept -Wno- in the cc-option test and complain later when compiling a file that has some other warning. This rather unexpected behavior is intentional as per http://gcc.gnu.org/PR28322, so work around it by testing for support of the opposite option (without the no-). Introduce a new Makefile function cc-disable-warning that does this and update two uses of cc-option in the toplevel Makefile. Reported-and-tested-by: Stephen Rothwell Signed-off-by: Michal Marek Signed-off-by: Paul Gortmaker commit fe7ecaf6387edad730ee2461504e1c6454deea26 Author: Mel Gorman Date: Thu Dec 8 14:34:30 2011 -0800 mm: vmalloc: check for page allocation failure before vmlist insertion commit 1368edf0647ac112d8cfa6ce47257dc950c50f5c upstream. Commit f5252e00 ("mm: avoid null pointer access in vm_struct via /proc/vmallocinfo") adds newly allocated vm_structs to the vmlist after it is fully initialised. Unfortunately, it did not check that __vmalloc_area_node() successfully populated the area. In the event of allocation failure, the vmalloc area is freed but the pointer to freed memory is inserted into the vmlist leading to a a crash later in get_vmalloc_info(). This patch adds a check for ____vmalloc_area_node() failure within __vmalloc_node_range. It does not use "goto fail" as in the previous error path as a warning was already displayed by __vmalloc_area_node() before it called vfree in its failure path. Credit goes to Luciano Chavez for doing all the real work of identifying exactly where the problem was. Signed-off-by: Mel Gorman Reported-by: Luciano Chavez Tested-by: Luciano Chavez Reviewed-by: Rik van Riel Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 0a77f43daae1cfe1ef57349063a4a1b5b955e72c Author: Mitsuo Hayasaka Date: Mon Oct 31 17:08:13 2011 -0700 mm: avoid null pointer access in vm_struct via /proc/vmallocinfo commit f5252e009d5b87071a919221e4f6624184005368 upstream. The /proc/vmallocinfo shows information about vmalloc allocations in vmlist that is a linklist of vm_struct. It, however, may access pages field of vm_struct where a page was not allocated. This results in a null pointer access and leads to a kernel panic. Why this happens: In __vmalloc_node_range() called from vmalloc(), newly allocated vm_struct is added to vmlist at __get_vm_area_node() and then, some fields of vm_struct such as nr_pages and pages are set at __vmalloc_area_node(). In other words, it is added to vmlist before it is fully initialized. At the same time, when the /proc/vmallocinfo is read, it accesses the pages field of vm_struct according to the nr_pages field at show_numa_info(). Thus, a null pointer access happens. The patch adds the newly allocated vm_struct to the vmlist *after* it is fully initialized. So, it can avoid accessing the pages field with unallocated page when show_numa_info() is called. Signed-off-by: Mitsuo Hayasaka Cc: Andrew Morton Cc: David Rientjes Cc: Namhyung Kim Cc: "Paul E. McKenney" Cc: Jeremy Fitzhardinge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [PG: .34 has VMALLOC_START/END vs. start/end in f5252e009d5] Signed-off-by: Paul Gortmaker commit df7b176d61e6fcf6a5bc3b2905859882bc861844 Author: Chris Wilson Date: Sun Sep 26 20:21:44 2010 +0100 drm/i915: Rephrase pwrite bounds checking to avoid any potential overflow commit 7dcd2499deab8f10011713c40bc2f309c9b65077 upstream. ... and do the same for pread. Signed-off-by: Chris Wilson Signed-off-by: Paul Gortmaker commit 0618fab3584f661de31e8eaab044c8c30b0e8d74 Author: Chris Wilson Date: Sun Sep 26 20:50:05 2010 +0100 drm/i915: Sanity check pread/pwrite commit ce9d419dbecc292cc3e06e8b1d6d123d3fa813a4 upstream. Move the access control up from the fast paths, which are no longer universally taken first, up into the caller. This then duplicates some sanity checking along the slow paths, but is much simpler. Tracked as CVE-2010-2962. Reported-by: Kees Cook Signed-off-by: Chris Wilson Signed-off-by: Paul Gortmaker commit 471726290fb97c23c6f1324f42797f867f83588a Author: Mauro Carvalho Chehab Date: Mon Dec 27 08:27:05 2010 -0300 [media] Remove the old V4L1 v4lgrab.c file commit 55fe25b418640fad04190103274841b2c907bacd upstream. This example file uses the old V4L1 API. It also doesn't use libv4l. So, it is completely obsolete. A good example already exists at v4l-utils (v4l2grab.c): http://git.linuxtv.org/v4l-utils.git Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit 96f3b87bcf0a9b9143bf56c22b86db9be1119639 Author: NeilBrown Date: Tue Nov 8 16:22:01 2011 +1100 md/raid5: abort any pending parity operations when array fails. commit 9a3f530f39f4490eaa18b02719fb74ce5f4d2d86 upstream. When the number of failed devices exceeds the allowed number we must abort any active parity operations (checks or updates) as they are no longer meaningful, and can lead to a BUG_ON in handle_parity_checks6. This bug was introduce by commit 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 in 2.6.29. Reported-by: Manish Katiyar Tested-by: Manish Katiyar Acked-by: Dan Williams Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman [PG: use 2.6.32.49 backport since raid5.c @ 9a3f530f/v3.2 differs more] Signed-off-by: Paul Gortmaker commit 614c50ec7dfa104010a950c41984d021d8bcea88 Author: Dave Jones Date: Thu Apr 21 17:28:13 2011 -0400 kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0 commit af0e5d565d2fffcd97d1e2d89669d627cc04e8b8 upstream. Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0 It produces more false positives than useful warnings. This can still be enabled using W=1 Signed-off-by: Dave Jones Acked-by: Sam Ravnborg Tested-by: Sam Ravnborg Signed-off-by: Michal Marek Signed-off-by: Paul Gortmaker commit 51fce51d3a8a1e5a0082b62fbf5d1c46836bd577 Author: Sam Ravnborg Date: Wed Apr 27 22:15:27 2011 +0200 kbuild: implement several W= levels commit 28bc20dccadc610c56e27255aeef2938141a0cd3 upstream. Building a kernel with "make W=1" produces far too much noise to be useful. Divide the warning options in three groups: W=1 - warnings that may be relevant and does not occur too often W=2 - warnings that occur quite often but may still be relevant W=3 - the more obscure warnings, can most likely be ignored When building the whole kernel, those levels produce: W=1 - 4859 warnings W=2 - 1394 warnings W=3 - 86666 warnings respectively. Warnings have been counted with Geert's script at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/linux-log-summary.pl Many warnings occur from .h files so fixing one file may have a nice effect on the total number of warnings. With these changes I am actually tempted to try W=1 now and then. Previously there was just too much noise. Borislav: - make the W= levels exclusive - move very noisy and making little sense for the kernel warnings to W=3 - drop -Woverlength-strings due to useless warning message - copy explanatory text for the different warning levels to 'make help' - recount warnings per level Signed-off-by: Sam Ravnborg Signed-off-by: Borislav Petkov Cc: Dave Jones Cc: Geert Uytterhoeven Signed-off-by: Michal Marek [PG: used for 2.6.34 to better control new compilers on older code] Signed-off-by: Paul Gortmaker commit 0d34797e902e198b671075368d2280add20b518a Author: Borislav Petkov Date: Tue Mar 1 09:35:29 2011 +0100 kbuild: Add extra gcc checks commit 4a5838ad9d2d4f7354a310982483f4c76aa0abeb upstream. Add a 'W=1' Makefile switch which adds additional checking per build object. The idea behind this option is targeted at developers who, in the process of writing their code, want to do the occasional make W=1 [target.o] and let gcc do more extensive code checking for them. Then, they could eyeball the output for valid gcc warnings about various bugs/discrepancies which are not reported during the normal build process. For more background information and a use case, read through this thread: http://marc.info/?l=kernel-janitors&m=129802065918147&w=2 Cc: Michal Marek Cc: linux-kbuild@vger.kernel.org Acked-by: Sam Ravnborg Acked-by: Ingo Molnar Signed-off-by: Borislav Petkov Signed-off-by: Michal Marek [PG: used for 2.6.34 to better control new compilers on older code] Signed-off-by: Paul Gortmaker commit 2ccd3d16c41e5b6226f24bb168298f18b90c5415 Author: Dan Carpenter Date: Mon Nov 14 17:52:08 2011 +0300 hfs: add sanity check for file name length commit bc5b8a9003132ae44559edd63a1623b7b99dfb68 upstream. On a corrupted file system the ->len field could be wrong leading to a buffer overflow. Reported-and-acked-by: Clement LECIGNE Signed-off-by: Dan Carpenter Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 7db9f90917b40dde4c5ea003cf58cd9eddb557c1 Author: Dan Carpenter Date: Wed Sep 21 20:55:04 2011 +0200 PM / Suspend: Off by one in pm_suspend() commit 528f7ce6e439edeac38f6b3f8561f1be129b5e91 upstream. In enter_state() we use "state" as an offset for the pm_states[] array. The pm_states[] array only has PM_SUSPEND_MAX elements so this test is off by one. Signed-off-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki Signed-off-by: Paul Gortmaker commit c6817c1778ce37b9bb5a65881675f4cae17312f8 Author: Peter Wippich Date: Mon Jun 6 15:50:58 2011 +0200 mtd: mtdchar: add missing initializer on raw write commit bf5140817b2d65faac9b32fc9057a097044ac35b upstream. On writes in MODE_RAW the mtd_oob_ops struct is not sufficiently initialized which may cause nandwrite to fail. With this patch it is possible to write raw nand/oob data without additional ECC (either for testing or when some sectors need different oob layout e.g. bootloader) like nandwrite -n -r -o /dev/mtd0 Signed-off-by: Peter Wippich Tested-by: Ricard Wanderlof Signed-off-by: Artem Bityutskiy Signed-off-by: Paul Gortmaker commit b1a940b43437105b60f117555289558ea4d18d4d Author: Johannes Berg Date: Thu Nov 3 00:07:32 2011 +0000 netlink: validate NLA_MSECS length commit c30bc94758ae2a38a5eb31767c1985c0aae0950b upstream. L2TP for example uses NLA_MSECS like this: policy: [L2TP_ATTR_RECV_TIMEOUT] = { .type = NLA_MSECS, }, code: if (info->attrs[L2TP_ATTR_RECV_TIMEOUT]) cfg.reorder_timeout = nla_get_msecs(info->attrs[L2TP_ATTR_RECV_TIMEOUT]); As nla_get_msecs() is essentially nla_get_u64() plus the conversion to a HZ-based value, this will not properly reject attributes from userspace that aren't long enough and might overrun the message. Add NLA_MSECS to the attribute minlen array to check the size properly. Cc: Thomas Graf Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 64a211ecd8c813da236aef72eab7e76a8de4592f Author: NeilBrown Date: Tue Oct 25 10:25:49 2011 +1100 NFS/sunrpc: don't use a credential with extra groups. commit dc6f55e9f8dac4b6479be67c5c9128ad37bb491f upstream. The sunrpc layer keeps a cache of recently used credentials and 'unx_match' is used to find the credential which matches the current process. However unx_match allows a match when the cached credential has extra groups at the end of uc_gids list which are not in the process group list. So if a process with a list of (say) 4 group accesses a file and gains access because of the last group in the list, then another process with the same uid and gid, and a gid list being the first tree of the gids of the original process tries to access the file, it will be granted access even though it shouldn't as the wrong rpc credential will be used. Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit 649de82fef23a2b5ad04b7765c872f35651358a9 Author: Bart Van Assche Date: Fri Sep 23 19:48:18 2011 +0200 [SCSI] Make scsi_free_queue() kill pending SCSI commands commit 3308511c93e6ad0d3c58984ecd6e5e57f96b12c8 upstream. Make sure that SCSI device removal via scsi_remove_host() does finish all pending SCSI commands. Currently that's not the case and hence removal of a SCSI host during I/O can cause a deadlock. See also "blkdev_issue_discard() hangs forever if underlying storage device is removed" (http://bugzilla.kernel.org/show_bug.cgi?id=40472). See also http://lkml.org/lkml/2011/8/27/6. Signed-off-by: Bart Van Assche Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 97547b895b4485f7097ceefbbfd42806c8c03496 Author: Petr Uzel Date: Fri Oct 21 13:31:09 2011 +0200 [SCSI] st: fix race in st_scsi_execute_end commit c68bf8eeaa57c852e74adcf597237be149eef830 upstream. The call to complete() in st_scsi_execute_end() wakes up sleeping thread in write_behind_check(), which frees the st_request, thus invalidating the pointer to the associated bio structure, which is then passed to the blk_rq_unmap_user(). Fix by storing pointer to bio structure into temporary local variable. This bug is present since at least linux-2.6.32. Signed-off-by: Petr Uzel Reported-by: Juergen Groß Reviewed-by: Jan Kara Acked-by: Kai Mäkisara Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit d3f610aeedcdfda9967c612b52be2b2815f76156 Author: Thomas Gleixner Date: Tue Jul 17 17:49:31 2012 -0400 timekeeping: Add missing update call in timekeeping_resume() commit 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0 upstream. The leap second rework unearthed another issue of inconsistent data. On timekeeping_resume() the timekeeper data is updated, but nothing calls timekeeping_update(), so now the update code in the timer interrupt sees stale values. This has been the case before those changes, but then the timer interrupt was using stale data as well so this went unnoticed for quite some time. Add the missing update call, so all the data is consistent everywhere. Reported-by: Andreas Schwab Reported-and-tested-by: "Rafael J. Wysocki" Reported-and-tested-by: Martin Steigerwald Cc: LKML Cc: Linux PM list Cc: John Stultz Cc: Ingo Molnar Cc: Peter Zijlstra , Cc: Prarit Bhargava Signed-off-by: Thomas Gleixner Signed-off-by: John Stultz Signed-off-by: Linus Torvalds Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 68fc1ab0a89f6cfadde9ff077afae6607b83c9ce Author: John Stultz Date: Tue Jul 17 17:49:30 2012 -0400 hrtimer: Update hrtimer base offsets each hrtimer_interrupt commit 5baefd6d84163443215f4a99f6a20f054ef11236 upstream. The update of the hrtimer base offsets on all cpus cannot be made atomically from the timekeeper.lock held and interrupt disabled region as smp function calls are not allowed there. clock_was_set(), which enforces the update on all cpus, is called either from preemptible process context in case of do_settimeofday() or from the softirq context when the offset modification happened in the timer interrupt itself due to a leap second. In both cases there is a race window for an hrtimer interrupt between dropping timekeeper lock, enabling interrupts and clock_was_set() issuing the updates. Any interrupt which arrives in that window will see the new time but operate on stale offsets. So we need to make sure that an hrtimer interrupt always sees a consistent state of time and offsets. ktime_get_update_offsets() allows us to get the current monotonic time and update the per cpu hrtimer base offsets from hrtimer_interrupt() to capture a consistent state of monotonic time and the offsets. The function replaces the existing ktime_get() calls in hrtimer_interrupt(). The overhead of the new function vs. ktime_get() is minimal as it just adds two store operations. This ensures that any changes to realtime or boottime offsets are noticed and stored into the per-cpu hrtimer base structures, prior to any hrtimer expiration and guarantees that timers are not expired early. Signed-off-by: John Stultz Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Link: http://lkml.kernel.org/r/1341960205-56738-8-git-send-email-johnstul@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit bd77b8e820140e552098f5262aa4e91513614110 Author: Thomas Gleixner Date: Tue Jul 17 17:49:29 2012 -0400 timekeeping: Provide hrtimer update function commit f6c06abfb3972ad4914cef57d8348fcb2932bc3b upstream. To finally fix the infamous leap second issue and other race windows caused by functions which change the offsets between the various time bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a function which atomically gets the current monotonic time and updates the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic overhead. The previous patch which provides ktime_t offsets allows us to make this function almost as cheap as ktime_get() which is going to be replaced in hrtimer_interrupt(). Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Signed-off-by: John Stultz Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit a7368dd5947a2ab6e82ce5a3577896baac3d9306 Author: Thomas Gleixner Date: Tue Jul 17 17:49:28 2012 -0400 hrtimers: Move lock held region in hrtimer_interrupt() commit 196951e91262fccda81147d2bcf7fdab08668b40 upstream. We need to update the base offsets from this code and we need to do that under base->lock. Move the lock held region around the ktime_get() calls. The ktime_get() calls are going to be replaced with a function which gets the time and the offsets atomically. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Signed-off-by: John Stultz Link: http://lkml.kernel.org/r/1341960205-56738-6-git-send-email-johnstul@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit cf110b9408cdf2e539d194042da3853cb22c61b0 Author: Thomas Gleixner Date: Tue Jul 17 17:49:27 2012 -0400 timekeeping: Maintain ktime_t based offsets for hrtimers commit 5b9fe759a678e05be4937ddf03d50e950207c1c0 upstream. We need to update the hrtimer clock offsets from the hrtimer interrupt context. To avoid conversions from timespec to ktime_t maintain a ktime_t based representation of those offsets in the timekeeper. This puts the conversion overhead into the code which updates the underlying offsets and provides fast accessible values in the hrtimer interrupt. Signed-off-by: Thomas Gleixner Signed-off-by: John Stultz Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Link: http://lkml.kernel.org/r/1341960205-56738-4-git-send-email-johnstul@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 7e565a62054f05baecbc74ec28613b09bad57bcf Author: John Stultz Date: Tue Jul 17 17:49:26 2012 -0400 timekeeping: Fix leapsecond triggered load spike issue commit 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51 upstream. The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap second has been inserted or deleted until an operation is initiated which causes that update. Unless the update happens by some other means this discrepancy between the timekeeping and the hrtimer data stays forever and timers are expired either early or late. The reported immediate workaround - $ data -s "`date`" - is causing a call to clock_was_set() which updates the hrtimer data structures. See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix Add the missing clock_was_set() call to update_wall_time() in case of a leap second event. The actual update is deferred to softirq context as the necessary smp function call cannot be invoked from hard interrupt context. Signed-off-by: John Stultz Reported-by: Jan Engelhardt Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Link: http://lkml.kernel.org/r/1341960205-56738-3-git-send-email-johnstul@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 25b2871241b14b0b01b7aa1ffc958b565ad03e3e Author: John Stultz Date: Tue Jul 17 17:49:25 2012 -0400 hrtimer: Provide clock_was_set_delayed() commit f55a6faa384304c89cfef162768e88374d3312cb upstream. clock_was_set() cannot be called from hard interrupt context because it calls on_each_cpu(). For fixing the widely reported leap seconds issue it is necessary to call it from hard interrupt context, i.e. the timer tick code, which does the timekeeping updates. Provide a new function which denotes it in the hrtimer cpu base structure of the cpu on which it is called and raise the hrtimer softirq. We then execute the clock_was_set() notificiation from softirq context in run_hrtimer_softirq(). The hrtimer softirq is rarely used, so polling the flag there is not a performance issue. [ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get rid of all this ifdeffery ASAP ] Signed-off-by: John Stultz Reported-by: Jan Engelhardt Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Link: http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johnstul@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit d4a672b514b1d2d5384b1c82dccb11618118ddf1 Author: Thomas Gleixner Date: Tue Jul 17 17:49:24 2012 -0400 time: Move common updates to a function commit cc06268c6a87db156af2daed6e96a936b955cc82 upstream. While not a bugfix itself, it allows following fixes to backport in a more straightforward manner. CC: Thomas Gleixner CC: Eric Dumazet CC: Richard Cochran Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 7df892974c2bf2487c3a08a959f0aab56d057822 Author: John Stultz Date: Tue Jul 17 17:49:23 2012 -0400 timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond commit fad0c66c4bb836d57a5f125ecd38bed653ca863a upstream. which resolves a bug the previous commit. Commit 6b43ae8a61 (ntp: Fix leap-second hrtimer livelock) broke the leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC. Adjust wall_to_monotonic when NTP inserted a leapsecond. Reported-by: Richard Cochran Signed-off-by: John Stultz Tested-by: Richard Cochran Link: http://lkml.kernel.org/r/1338400497-12420-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit d9ccaf3143473c6dd11b10d49e524eaa39fabcec Author: John Stultz Date: Fri Jul 13 01:21:50 2012 -0400 ntp: Fix STA_INS/DEL clearing bug commit 6b1859dba01c7d512b72d77e3fd7da8354235189 upstream. In commit 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d, I introduced a bug that kept the STA_INS or STA_DEL bit from being cleared from time_status via adjtimex() without forcing STA_PLL first. Usually once the STA_INS is set, it isn't cleared until the leap second is applied, so its unlikely this affected anyone. However during testing I noticed it took some effort to cancel a leap second once STA_INS was set. Signed-off-by: John Stultz Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Richard Cochran Cc: Prarit Bhargava Link: http://lkml.kernel.org/r/1342156917-25092-2-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner commit 3d0f1226f01ff60e3850cfd8fec9c5e36f0297ae Author: Richard Cochran Date: Tue Jul 17 17:49:22 2012 -0400 ntp: Correct TAI offset during leap second commit dd48d708ff3e917f6d6b6c2b696c3f18c019feed upstream. When repeating a UTC time value during a leap second (when the UTC time should be 23:59:60), the TAI timescale should not stop. The kernel NTP code increments the TAI offset one second too late. This patch fixes the issue by incrementing the offset during the leap second itself. Signed-off-by: Richard Cochran Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 838955464ce6579492c1b863264ad6cfe79a9a14 Author: John Stultz Date: Tue Jul 17 17:49:21 2012 -0400 ntp: Fix leap-second hrtimer livelock commit 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d upstream. This should have been backported when it was commited, but I mistook the problem as requiring the ntp_lock changes that landed in 3.4 in order for it to occur. Unfortunately the same issue can happen (with only one cpu) as follows: do_adjtimex() write_seqlock_irq(&xtime_lock); process_adjtimex_modes() process_adj_status() ntp_start_leap_timer() hrtimer_start() hrtimer_reprogram() tick_program_event() clockevents_program_event() ktime_get() seq = req_seqbegin(xtime_lock); [DEADLOCK] This deadlock will no always occur, as it requires the leap_timer to force a hrtimer_reprogram which only happens if its set and there's no sooner timer to expire. NOTE: This patch, being faithful to the original commit, introduces a bug (we don't update wall_to_monotonic), which will be resovled by backporting a following fix. Original commit message below: Since commit 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 the ntp subsystem has used an hrtimer for triggering the leapsecond adjustment. However, this can cause a potential livelock. Thomas diagnosed this as the following pattern: CPU 0 CPU 1 do_adjtimex() spin_lock_irq(&ntp_lock); process_adjtimex_modes(); timer_interrupt() process_adj_status(); do_timer() ntp_start_leap_timer(); write_lock(&xtime_lock); hrtimer_start(); update_wall_time(); hrtimer_reprogram(); ntp_tick_length() tick_program_event() spin_lock(&ntp_lock); clockevents_program_event() ktime_get() seq = req_seqbegin(xtime_lock); This patch tries to avoid the problem by reverting back to not using an hrtimer to inject leapseconds, and instead we handle the leapsecond processing in the second_overflow() function. The downside to this change is that on systems that support highres timers, the leap second processing will occur on a HZ tick boundary, (ie: ~1-10ms, depending on HZ) after the leap second instead of possibly sooner (~34us in my tests w/ x86_64 lapic). This patch applies on top of tip/timers/core. CC: Sasha Levin CC: Thomas Gleixner Reported-by: Sasha Levin Diagnoised-by: Thomas Gleixner Tested-by: Sasha Levin Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 7e87b719a6d20bf63c25a9b5776ea39bab8051db Author: Lan Tianyu Date: Fri Jul 20 13:29:16 2012 +0800 ACPI/AC: prevent OOPS on some boxes due to missing check power_supply_register() return value check commit f197ac13f6eeb351b31250b9ab7d0da17434ea36 upstream. In the ac.c, power_supply_register()'s return value is not checked. As a result, the driver's add() ops may return success even though the device failed to initialize. For example, some BIOS may describe two ACADs in the same DSDT. The second ACAD device will fail to register, but ACPI driver's add() ops returns sucessfully. The ACPI device will receive ACPI notification and cause OOPS. https://bugzilla.redhat.com/show_bug.cgi?id=772730 Signed-off-by: Lan Tianyu Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit f5ffe713138d849096a56b88c26c38544ae72d7b Author: Artur Zimmer Date: Wed Aug 10 03:51:28 2011 +0200 USB: Serial: Add PID(0xF7C0) to FTDI SIO driver for a zeitcontrol-device commit ce7e9065958191e6b7ca49d7ed0e1099c486d198 upstream. Here is a patch for a new PID (zeitcontrol-device mifare-reader FT232BL(like FT232BM but lead free)). Signed-off-by: Artur Zimmer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit cf8457d6f311387f7345c659e1cfcbb3c4f43453 Author: Florian Echtler Date: Tue Aug 9 13:37:49 2011 +0200 USB: Serial: Add device ID for Sierra Wireless MC8305 commit 2f1def2695c223b2aa325e5e47d0d64200a45d23 upstream. A new device ID pair is added for Sierra Wireless MC8305. Signed-off-by: Florian Echtler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 3c6e1a9ba230c1f234857945cf0715156a68b80f Author: Theodore Ts'o Date: Wed Aug 31 11:54:51 2011 -0400 ext2,ext3,ext4: don't inherit APPEND_FL or IMMUTABLE_FL for new inodes commit 1cd9f0976aa4606db8d6e3dc3edd0aca8019372a upstream. This doesn't make much sense, and it exposes a bug in the kernel where attempts to create a new file in an append-only directory using O_CREAT will fail (but still leave a zero-length file). This was discovered when xfstests #79 was generalized so it could run on all file systems. Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit a0d7bcec0d32fa1f410648d2f8349397a353e905 Author: Alexandre Bounine Date: Wed Nov 2 13:39:15 2011 -0700 drivers/net/rionet.c: fix ethernet address macros for LE platforms commit e0c87bd95e8dad455c23bc56513af8dcb1737e55 upstream. Modify Ethernet addess macros to be compatible with BE/LE platforms Signed-off-by: Alexandre Bounine Cc: Chul Kim Cc: Kumar Gala Cc: Matt Porter Cc: Li Yang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 233e10c438b19b09663fa5e1aa21f70ce4b8de93 Author: Hugh Dickins Date: Mon May 9 17:44:42 2011 -0700 vm: fix vm_pgoff wrap in upward expansion commit 42c36f63ac1366ab0ecc2d5717821362c259f517 upstream. Commit a626ca6a6564 ("vm: fix vm_pgoff wrap in stack expansion") fixed the case of an expanding mapping causing vm_pgoff wrapping when you had downward stack expansion. But there was another case where IA64 and PA-RISC expand mappings: upward expansion. This fixes that case too. Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds [PG: .34 doesn't have perf call via 3af9e859 (in .36); adjust accordingly] Signed-off-by: Paul Gortmaker commit a9b4f1a56faac050bcccec67b01faa2e78d9735b Author: Filip Palian Date: Thu May 12 19:32:46 2011 +0200 Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace. commit 8d03e971cf403305217b8e62db3a2e5ad2d6263f upstream. Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding byte each. This byte in "cinfo" is copied to userspace uninitialized. Signed-off-by: Filip Palian Acked-by: Marcel Holtmann Signed-off-by: Gustavo F. Padovan [PG: l2cap_sock.c chunk is in l2cap.c in a 2.6.34 context/baseline] Signed-off-by: Paul Gortmaker commit ce838ded70a01b09d8429c62a63741cd000abb06 Author: Trond Myklebust Date: Tue May 31 15:15:34 2011 -0400 NLM: Don't hang forever on NLM unlock requests commit 0b760113a3a155269a3fba93a409c640031dd68f upstream. If the NLM daemon is killed on the NFS server, we can currently end up hanging forever on an 'unlock' request, instead of aborting. Basically, if the rpcbind request fails, or the server keeps returning garbage, we really want to quit instead of retrying. Tested-by: Vasily Averin Signed-off-by: Trond Myklebust [PG: struct rpc_task in sched.h slightly different layout vs. v3.0] Signed-off-by: Paul Gortmaker commit 834458c39725566f611cf05636dba38821dcf904 Author: Al Viro Date: Wed Mar 23 15:52:50 2011 -0400 deal with races in /proc/*/{syscall,stack,personality} commit a9712bc12c40c172e393f85a9b2ba8db4bf59509 upstream. All of those are rw-r--r-- and all are broken for suid - if you open a file before the target does suid-root exec, you'll be still able to access it. For personality it's not a big deal, but for syscall and stack it's a real problem. Fix: check that task is tracable for you at the time of read(). Signed-off-by: Al Viro [PG: in .34 cred_guard_mutex is in task, not task->signal] Signed-off-by: Paul Gortmaker commit 64eff52db9365f6479bb21ef1888c9aa1af7f60c Author: Eric Dumazet Date: Tue Nov 23 14:09:15 2010 +0000 scm: lower SCM_MAX_FD commit bba14de98753cb6599a2dae0e520714b2153522d upstream. Lower SCM_MAX_FD from 255 to 253 so that allocations for scm_fp_list are halved. (commit f8d570a4 added two pointers in this structure) scm_fp_dup() should not copy whole structure (and trigger kmemcheck warnings), but only the used part. While we are at it, only allocate needed size. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 64fa432f97ff50be5ab64c8502b4da1062aaa43f Author: Manoj Iyer Date: Sun May 8 18:04:29 2011 -0400 thinkpad-acpi: module autoloading for newer Lenovo ThinkPads. commit 9fbdaeb4f4dd14a0caa9fc35c496d5440c251a3a upstream. The newer Lenovo ThinkPads have HKEY HID of LEN0068 instead of IBM0068. Added new HID so that thinkpad_acpi module will auto load on these newer Lenovo ThinkPads. Acked-by: Henrique de Moraes Holschuh Signed-off-by: Manoj Iyer Signed-off-by: Andy Lutomirski Signed-off-by: Matthew Garrett Signed-off-by: Paul Gortmaker commit 6afb44e14bfc95f7aa57d1cd109a4c99ff145008 Author: Ian Campbell Date: Tue Feb 8 14:03:31 2011 +0000 xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend. commit f611f2da99420abc973c32cdbddbf5c365d0a20c upstream. The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via IRQF_TIMER. The following patch fixes the issue. With this fixlet PV guest migration works just fine. I also booted the entire series as a dom0 kernel and it appeared fine. Signed-off-by: Ian Campbell Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Paul Gortmaker commit 646c97408dc636ce5a4ffeaa285d070b0ea47e43 Author: Richard Weinberger Date: Wed Nov 2 13:17:27 2011 +0100 um: fix ubd cow size commit 8535639810e578960233ad39def3ac2157b0c3ec upstream. ubd_file_size() cannot use ubd_dev->cow.file because at this time ubd_dev->cow.file is not initialized. Therefore, ubd_file_size() will always report a wrong disk size when COW files are used. Reading from /dev/ubd* would crash the kernel. We have to read the correct disk size from the COW file's backing file. Signed-off-by: Richard Weinberger Signed-off-by: Paul Gortmaker commit 459d03f9128cec3e66a52d1cc805f9698c427af9 Author: Paul Fertser Date: Mon Oct 10 11:19:23 2011 +0400 plat-mxc: iomux-v3.h: implicitly enable pull-up/down when that's desired commit 6571534b600b8ca1936ff5630b9e0947f21faf16 upstream. To configure pads during the initialisation a set of special constants is used, e.g. #define MX25_PAD_FEC_MDIO__FEC_MDIO IOMUX_PAD(0x3c4, 0x1cc, 0x10, 0, 0, PAD_CTL_HYS | PAD_CTL_PUS_22K_UP) The problem is that no pull-up/down is getting activated unless both PAD_CTL_PUE (pull-up enable) and PAD_CTL_PKE (pull/keeper module enable) set. This is clearly stated in the i.MX25 datasheet and is confirmed by the measurements on hardware. This leads to some rather hard to understand bugs such as misdetecting an absent ethernet PHY (a real bug i had), unstable data transfer etc. This might affect mx25, mx35, mx50, mx51 and mx53 SoCs. It's reasonable to expect that if the pullup value is specified, the intention was to have it actually active, so we implicitly add the needed bits. Signed-off-by: Paul Fertser Signed-off-by: Sascha Hauer Signed-off-by: Paul Gortmaker commit 202dda5fc7451444e31a8770147e811761cf267d Author: Mauro Carvalho Chehab Date: Thu Jul 28 16:38:54 2011 -0300 tuner_xc2028: Allow selection of the frequency adjustment code for XC3028 commit 9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e upstream. This device is not using the proper demod IF. Instead of using the IF macro, it is specifying a IF frequency. This doesn't work, as xc3028 needs to load an specific SCODE for the tuner. In this case, there's no IF table for 5 MHz. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit 62c90b4f527ad58c906a42bbe6036952e16b8005 Author: Ming Lei Date: Sat Jul 16 00:51:00 2011 -0300 uvcvideo: Set alternate setting 0 on resume if the bus has been reset commit d59a7b1dbce8b972ec2dc9fcaaae0bfa23687423 upstream. If the bus has been reset on resume, set the alternate setting to 0. This should be the default value, but some devices crash or otherwise misbehave if they don't receive a SET_INTERFACE request before any other video control request. Microdia's 0c45:6437 camera has been found to require this change or it will stop sending video data after resume. uvc_video.c] Signed-off-by: Ming Lei Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit 1ba9201dc0c1d444241df3a2c1602996ac458dd5 Author: Jean Delvare Date: Fri Jul 8 11:04:38 2011 +0200 carminefb: Fix module parameters permissions commit c84c14224bbca6ec60d5851fcc87be0e34df2f44 upstream. The third parameter of module_param is supposed to be an octal value. The missing leading "0" causes the following: $ ls -l /sys/module/carminefb/parameters/ total 0 -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_displays -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode_str After fixing the perm parameter, we get the expected: $ ls -l /sys/module/carminefb/parameters/ total 0 -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_displays -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode_str Signed-off-by: Jean Delvare Cc: Paul Mundt Cc: Sebastian Siewior Signed-off-by: Paul Mundt Signed-off-by: Paul Gortmaker commit 989f980f9cf2a244122df4e52efe39798485e8c9 Author: Joerg Roedel Date: Tue Oct 11 17:41:32 2011 +0200 iommu/amd: Fix wrong shift direction commit fcd0861db1cf4e6ed99f60a815b7b72c2ed36ea4 upstream. The shift direction was wrong because the function takes a page number and i is the address is the loop. Signed-off-by: Joerg Roedel [PG: drivers/iommu/ was arch/x86/kernel/ in 2.6.34 context] Signed-off-by: Paul Gortmaker commit 263307853b1a49baf5b4152a07cbf79c6a26fede Author: Sebastian Ott Date: Sun Oct 30 15:16:52 2011 +0100 [S390] ccwgroup: move attributes to attribute group commit dbdf1afcaaabe83dea15a3cb9b9013e73ae3b1ad upstream. Put sysfs attributes of ccwgroup devices in an attribute group to ensure that these attributes are actually present when userspace is notified via uevents. Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Paul Gortmaker commit e5610fce4a41f90092714b6eb4b12f107a74b494 Author: Carsten Otte Date: Tue Oct 18 12:27:12 2011 +0200 KVM: s390: check cpu_id prior to using it commit 4d47555a80495657161a7e71ec3014ff2021e450 upstream. We use the cpu id provided by userspace as array index here. Thus we clearly need to check it first. Ooops. Signed-off-by: Carsten Otte Signed-off-by: Christian Borntraeger Signed-off-by: Marcelo Tosatti Signed-off-by: Paul Gortmaker commit dc2d951a77c74c8140e6cf9aab2cbc9f4315b7c7 Author: Axel Lin Date: Thu Oct 13 17:17:06 2011 +0800 ASoC: ak4535: fixup cache register table commit 7c04241acbdaf97f1448dcccd27ea0fcd1a57684 upstream. ak4535_reg should be 8bit, but cache table is defined as 16bit. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Paul Gortmaker commit 601d3dfb6ed46f796e7f018959eb57a7dcacf1e3 Author: Kuninori Morimoto Date: Thu Oct 13 02:03:54 2011 -0700 ASoC: ak4642: fixup cache register table commit 19b115e523208a926813751aac8934cf3fc6085e upstream. ak4642 register was 8bit, but cache table was defined as 16bit. ak4642 doesn't work correctry without this patch. Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Paul Gortmaker commit 2ac6881871827a8211e7eea59a9090ebf112277c Author: Axel Lin Date: Wed Oct 26 09:53:41 2011 +0800 ASoC: wm8940: Properly set codec->dapm.bias_level commit 5927f94700e860ae27ff24e7f3bc9e4f7b9922eb upstream. Reported-by: Chris Paulson-Ellis Signed-off-by: Axel Lin Signed-off-by: Mark Brown [PG: in .34 it uses codec->bias_level and not codec->dapm.bias_level] Signed-off-by: Paul Gortmaker commit 472f63d1e3530286e1b1773cd50d11add1faa54f Author: J. Bruce Fields Date: Mon Oct 10 17:34:31 2011 -0400 nfsd4: ignore WANT bits in open downgrade commit c30e92df30d7d5fe65262fbce5d1b7de675fe34e upstream. We don't use WANT bits yet--and sending them can probably trigger a BUG() further down. Signed-off-by: J. Bruce Fields Signed-off-by: Paul Gortmaker commit 7e449aacc38996607c90f83d5ebed53d14d08ee4 Author: Bernd Schubert Date: Mon Aug 8 17:38:08 2011 +0200 nfsd4: Remove check for a 32-bit cookie in nfsd4_readdir() commit 832023bffb4b493f230be901f681020caf3ed1f8 upstream. Fan Yong noticed setting FMODE_32bithash wouldn't work with nfsd v4, as nfsd4_readdir() checks for 32 bit cookies. However, according to RFC 3530 cookies have a 64 bit type and cookies are also defined as u64 in 'struct nfsd4_readdir'. So remove the test for >32-bit values. Signed-off-by: Bernd Schubert Signed-off-by: J. Bruce Fields Signed-off-by: Paul Gortmaker commit a019e7998fd21183e82409f8bf35ec0fc9b994e7 Author: hank Date: Tue Sep 20 13:53:39 2011 -0700 time: Change jiffies_to_clock_t() argument type to unsigned long commit cbbc719fccdb8cbd87350a05c0d33167c9b79365 upstream. The parameter's origin type is long. On an i386 architecture, it can easily be larger than 0x80000000, causing this function to convert it to a sign-extended u64 type. Change the type to unsigned long so we get the correct result. Signed-off-by: hank Cc: John Stultz [ build fix ] Signed-off-by: Andrew Morton Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 76bd0e219681e554f59988d6af3eaf21202809b0 Author: Jiri Kosina Date: Wed Oct 26 13:10:39 2011 +1030 kmod: prevent kmod_loop_msg overflow in __request_module() commit 37252db6aa576c34fd794a5a54fb32d7a8b3a07a upstream. Due to post-increment in condition of kmod_loop_msg in __request_module(), the system log can be spammed by much more than 5 instances of the 'runaway loop' message if the number of events triggering it makes the kmod_loop_msg to overflow. Fix that by making sure we never increment it past the threshold. Signed-off-by: Jiri Kosina Signed-off-by: Rusty Russell Signed-off-by: Paul Gortmaker commit c00a5101310a35a34f9c23bd9c9cda2187005abd Author: Milan Broz Date: Mon Aug 22 15:51:34 2011 +0200 kobj_uevent: Ignore if some listeners cannot handle message commit ebf4127cd677e9781b450e44dfaaa1cc595efcaa upstream. kobject_uevent() uses a multicast socket and should ignore if one of listeners cannot handle messages or nobody is listening at all. Easily reproducible when a process in system is cloned with CLONE_NEWNET flag. (See also http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5256) Signed-off-by: Milan Broz Acked-by: Kay Sievers Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 5ffddeb2125e7d45779724a1b0823a8ea9307f4e Author: Josh Boyer Date: Mon Oct 17 21:16:39 2011 -0400 Update email address for stable patch submission commit 5fa224295f0e0358c8bc0e5390702338df889def upstream. The stable@kernel.org email address has been replaced with the stable@vger.kernel.org mailing list. Change the stable kernel rules to reference the new list instead of the semi-defunct email alias. Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit f47b301ecc6ff8446524548b93b7675252a62d96 Author: Jerry Huang Date: Tue Oct 18 13:09:48 2011 +0800 QE/FHCI: fixed the CONTROL bug commit 273d23574f9dacd9c63c80e7d63639a669aad441 upstream. For USB CONTROL transaction, when the data length is zero, the IN package is needed to finish this transaction in status stage. Signed-off-by: Jerry Huang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ac14dfbeab9df9601d24627f4c074f05047e10c3 Author: Peter Stuge Date: Mon Oct 10 03:34:54 2011 +0200 USB: ftdi_sio: Support TI/Luminary Micro Stellaris BD-ICDI Board commit 3687f641307eeff6f7fe31a88dc39db88e89238b upstream. Some Stellaris evaluation kits have the JTAG/SWD FTDI chip onboard, and some, like EK-LM3S9B90, come with a separate In-Circuit Debugger Interface Board. The ICDI board can also be used stand-alone, for other boards and chips than the kit it came with. The ICDI has both old style 20-pin JTAG connector and new style JTAG/SWD 10-pin 1.27mm pitch connector. Tested with EK-LM3S9B90, where the BD-ICDI board is included. Signed-off-by: Peter Stuge Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit a9db7cf310f4aeb3c04ab3bd5d01f622ee95a601 Author: Hakan Kvist Date: Mon Oct 3 13:41:15 2011 +0200 USB: ftdi_sio: add PID for Sony Ericsson Urban commit 74bdf22b5c3858b06af46f19d05c23e76c40a3bb upstream. Add PID 0xfc8a, 0xfc8b for device Sony Ericsson Urban Signed-off-by: Hakan Kvist Signed-off-by: Oskar Andero Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ffa506c26fd4c00b247ca7c7d358303b6169b59e Author: Eric Benoit Date: Sat Sep 24 02:04:50 2011 -0400 USB: pl2303: add id for SMART device commit 598f0b703506da841d3459dc0c48506be14d1778 upstream. Add vendor and product ID for the SMART USB to serial adapter. These were meant to be used with their SMART Board whiteboards, but can be re-purposed for other tasks. Tested and working (at at least 9600 bps). Signed-off-by: Eric Benoit Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 07f83bc23ce63d41fe22da7e9e75842cb03e6c16 Author: Oliver Neukum Date: Tue Sep 13 08:42:21 2011 +0200 USB: add RESET_RESUME for webcams shown to be quirky commit 2394d67e446bf616a0885167d5f0d397bdacfdfc upstream. The new runtime PM code has shown that many webcams suffer from a race condition that may crash them upon resume. Runtime PM is especially prone to show the problem because it retains power to the cameras at all times. However system suspension may also crash the devices and retain power to the devices. The only way to solve this problem without races is in usbcore with the RESET_RESUME quirk. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d9724c0eaf683e14fb7a3868bbba6d1e0e48a7fe Author: Denis Pershin Date: Sun Sep 4 17:37:21 2011 +0700 usb: cdc-acm: Owen SI-30 support commit 65e52f41fa944cef2e6d4222b8c54f46cc575214 upstream. here is the patch to support Owen SI-30 device. This is a pulse counter controller. http://www.owen.ru/en/catalog/93788515 usb-drivers output: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03eb ProdID=0030 Rev=01.01 C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm This patch is installed on my home system which receives data from this controller connected to cold water counter. Signed-off-by: Denis Pershin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ab1bb990f4838f5e35e1b83ef2d19f6069af837a Author: Serge Hallyn Date: Mon Sep 26 10:18:29 2011 -0500 USB: pid_ns: ensure pid is not freed during kill_pid_info_as_uid commit aec01c5895051849ed842dc5b8794017a7751f28 upstream. Alan Stern points out that after spin_unlock(&ps->lock) there is no guarantee that ps->pid won't be freed. Since kill_pid_info_as_uid() is called after the spin_unlock(), the pid passed to it must be pinned. Reported-by: Alan Stern Signed-off-by: Serge Hallyn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 6e3312c6074e6dbef8c7f4abd086907573df39e4 Author: Luben Tuikov Date: Thu Nov 11 15:43:11 2010 -0800 USB: storage: Use normalized sense when emulating autosense commit e16da02fcdf1c5e824432f88abf42623dafdf191 upstream. This patch solves two things: 1) Enables autosense emulation code to correctly interpret descriptor format sense data, and 2) Fixes a bug whereby the autosense emulation code would overwrite descriptor format sense data with SENSE KEY HARDWARE ERROR in fixed format, to incorrectly look like this: Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex): Oct 21 14:11:07 localhost kernel: 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 Oct 21 14:11:07 localhost kernel: 00 4f 00 c2 00 50 Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d Signed-off-by: Luben Tuikov Acked-by: Alan Stern Acked-by: Matthew Dharm Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 4d066bcdc9897593b0e122a4bde501a449a76b10 Author: Johannes Stezenbach Date: Thu Sep 8 15:39:15 2011 +0200 usbmon vs. tcpdump: fix dropped packet count commit 236c448cb6e7f82096101e1ace4b77f8b38f82c8 upstream. Report the number of dropped packets instead of zero when using the binary usbmon interface with tcpdump. # tcpdump -i usbmon1 -w dump tcpdump: listening on usbmon1, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes ^C2155 packets captured 2155 packets received by filter 1019 packets dropped by kernel Signed-off-by: Johannes Stezenbach Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit bfaa681a1fa24010d0a26704429e4cc2dff793a4 Author: Nelson Elhage Date: Mon Oct 31 17:13:14 2011 -0700 epoll: fix spurious lockdep warnings commit d8805e633e054c816c47cb6e727c81f156d9253d upstream. epoll can acquire recursively acquire ep->mtx on multiple "struct eventpoll"s at once in the case where one epoll fd is monitoring another epoll fd. This is perfectly OK, since we're careful about the lock ordering, but it causes spurious lockdep warnings. Annotate the recursion using mutex_lock_nested, and add a comment explaining the nesting rules for good measure. Recent versions of systemd are triggering this, and it can also be demonstrated with the following trivial test program: --------------------8<-------------------- int main(void) { int e1, e2; struct epoll_event evt = { .events = EPOLLIN }; e1 = epoll_create1(0); e2 = epoll_create1(0); epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt); return 0; } --------------------8<-------------------- Reported-by: Paul Bolle Tested-by: Paul Bolle Signed-off-by: Nelson Elhage Acked-by: Jason Baron Cc: Dave Jones Cc: Davide Libenzi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 5fcd6584e3862639a6941551b6ae9eed40cde900 Author: Josh Stone Date: Mon Oct 24 10:15:51 2011 -0700 x86: Fix compilation bug in kprobes' twobyte_is_boostable commit 315eb8a2a1b7f335d40ceeeb11b9e067475eb881 upstream. When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I noticed a warning about the asm operand for test_bit in kprobes' can_boost. I discovered that this caused only the first long of twobyte_is_boostable[] to be output. Jakub filed and fixed gcc PR50571 to correct the warning and this output issue. But to solve it for less current gcc, we can make kprobes' twobyte_is_boostable[] non-const, and it won't be optimized out. Before: CC arch/x86/kernel/kprobes.o In file included from include/linux/bitops.h:22:0, from include/linux/kernel.h:17, from [...]/arch/x86/include/asm/percpu.h:44, from [...]/arch/x86/include/asm/current.h:5, from [...]/arch/x86/include/asm/processor.h:15, from [...]/arch/x86/include/asm/atomic.h:6, from include/linux/atomic.h:4, from include/linux/mutex.h:18, from include/linux/notifier.h:13, from include/linux/kprobes.h:34, from arch/x86/kernel/kprobes.c:43: [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’: [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input without lvalue in asm operand 1 is deprecated [enabled by default] $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt 551: 0f a3 05 00 00 00 00 bt %eax,0x0 554: R_386_32 .rodata.cst4 $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o arch/x86/kernel/kprobes.o: file format elf32-i386 Contents of section .data: 0000 48000000 00000000 00000000 00000000 H............... Contents of section .rodata.cst4: 0000 4c030000 L... Only a single long of twobyte_is_boostable[] is in the object file. After, without the const on twobyte_is_boostable: $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt 551: 0f a3 05 20 00 00 00 bt %eax,0x20 554: R_386_32 .data $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o arch/x86/kernel/kprobes.o: file format elf32-i386 Contents of section .data: 0000 48000000 00000000 00000000 00000000 H............... 0010 00000000 00000000 00000000 00000000 ................ 0020 4c030000 0f000200 ffff0000 ffcff0c0 L............... 0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77 ....;.......&..w Now all 32 bytes are output into .data instead. Signed-off-by: Josh Stone Cc: Masami Hiramatsu Cc: Jakub Jelinek Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit cea26a66c7b763f939bd63323b98d0f239bea753 Author: David Henningsson Date: Tue Oct 18 14:07:51 2011 +0200 ALSA: HDA: Add new revision for ALC662 commit cc667a72d471e79fd8e5e291ea115923cf44dca0 upstream. The revision 0x100300 was found for ALC662. It seems to work well with patch_alc662. BugLink: http://bugs.launchpad.net/bugs/877373 Tested-by: Shengyao Xue Signed-off-by: David Henningsson Acked-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 1d1a6db4a119fccb7e5c6d0cdbead00e069f27cf Author: Jack Wang Date: Fri Sep 23 14:32:32 2011 +0800 libsas: set sas_address and device type of rphy commit bb041a0e9c31229071b6e56e1d0d8374af0d2038 upstream. Libsas forget to set the sas_address and device type of rphy lead to file under /sys/class/sas_x show wrong value, fix that. Signed-off-by: Jack Wang Tested-by: Crystal Yu Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit b5a5ec9c0f013e63564aceb7e64a5cb9391fc6b8 Author: Anton Blanchard Date: Mon Aug 1 19:43:45 2011 +1000 ipr: Always initiate hard reset in kdump kernel commit 5d7c20b7fa5c6ca19e871b4050e321c99d32bd43 upstream. During kdump testing I noticed timeouts when initialising each IPR adapter. While the driver has logic to detect an adapter in an indeterminate state, it wasn't triggering and each adapter went through a 5 minute timeout before finally going operational. Some analysis showed the needs_hard_reset flag wasn't getting set. We can check the reset_devices kernel parameter which is set by kdump and force a full reset. This fixes the problem. Signed-off-by: Anton Blanchard Acked-by: Brian King Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 95e8d5a47d4b06822dbdb6eef332b4e3e05d2a12 Author: Kautuk Consul Date: Mon Sep 19 16:53:12 2011 -0700 xhci-mem.c: Check for ring->first_seg != NULL commit 0e6c7f746ea99089fb3263709075c20485a479ae upstream. There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by: Kautuk Consul Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 077e5f18f415645c7f180738f73a123bef9876e4 Author: Rigbert Hamisch Date: Tue Sep 27 10:46:43 2011 +0200 USB: qcserial: add device ID for "HP un2430 Mobile Broadband Module" commit 1bfac90d1b8e63a4d44158c3445d8fda3fb6d5eb upstream. add device ID for "HP un2430 Mobile Broadband Module" Signed-off-by: Rigbert Hamisch Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d6bf984a19fba5bf1d8efc86f2b1dc7c3e71b614 Author: Kautuk Consul Date: Wed Sep 14 08:56:21 2011 +0530 staging: quatech_usb2: Potential lost wakeup scenario in TIOCMIWAIT commit e8df1674d383d2ecc6efa8d7dba74c03aafdfdd7 upstream. If the usermode app does an ioctl over this serial device by using TIOCMIWAIT, then the code will wait by setting the current task state to TASK_INTERRUPTIBLE and then calling schedule(). This will be woken up by the qt2_process_modem_status on URB completion when the port_extra->shadowMSR is set to the new modem status. However, this could result in a lost wakeup scenario due to a race in the logic in the qt2_ioctl(TIOCMIWAIT) loop and the URB completion for new modem status in qt2_process_modem_status. Due to this, the usermode app's task will continue to sleep despite a change in the modem status. Signed-off-by: Kautuk Consul Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 634a1a9359529a289f764a26911eb1a5a3b85a42 Author: Matthew Daley Date: Fri Oct 14 18:45:05 2011 +0000 x25: Prevent skb overreads when checking call user data commit 7f81e25befdfb3272345a2e775f520e1d515fa20 upstream. x25_find_listener does not check that the amount of call user data given in the skb is big enough in per-socket comparisons, hence buffer overreads may occur. Fix this by adding a check. Signed-off-by: Matthew Daley Cc: Eric Dumazet Cc: Andrew Hendry Acked-by: Andrew Hendry Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit db9ef6e22cbfff5726fccdf509ae9581aa069a0b Author: Jean Delvare Date: Thu Oct 13 15:49:08 2011 -0400 hwmon: (w83627ehf) Properly report thermal diode sensors commit bf164c58e58328c40ebc597a8ac00cc6840f9703 upstream. The w83627ehf driver is improperly reporting thermal diode sensors as type 2, instead of 3. This caused "sensors" and possibly other monitoring tools to report these sensors as "transistor" instead of "thermal diode". Furthermore, diode subtype selection (CPU vs. external) is only supported by the original W83627EHF/EHG. All later models only support CPU diode type, and some (NCT6776F) don't even have the register in question so we should avoid reading from it. Signed-off-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Paul Gortmaker commit eee8d56e8f3ee34450b3f48733cf0c961daeecd0 Author: Jeremiah Matthey Date: Tue Aug 23 09:44:30 2011 +0200 HID: usbhid: Add support for SiGma Micro chip commit f5e4282586dc0c9dab8c7d32e6c43aa07f68586b upstream. Patch to add SiGma Micro-based keyboards (1c4f:0002) to hid-quirks. These keyboards dont seem to allow the records to be initialized, and hence a timeout occurs when the usbhid driver attempts to initialize them. The patch just adds the signature for these keyboards to the hid-quirks list with the setting HID_QUIRK_NO_INIT_REPORTS. This removes the 5-10 second wait for the timeout to occur. Signed-off-by: Jeremiah Matthey Signed-off-by: Jiri Kosina Signed-off-by: Paul Gortmaker commit a5a8c11639257c4f4c39f5903401dc5189221fea Author: Mark Nelson Date: Mon Jun 27 16:33:44 2011 +1000 ahci: Enable SB600 64bit DMA on Asus M3A commit 3c4aa91f21f65b7b40bdfb015eacbcb8453ccae2 upstream. Like e65cc194f7628ecaa02462f22f42fb09b50dcd49 this patch enables 64bit DMA for the AHCI SATA controller of a board that has the SB600 southbridge. In this case though we're enabling 64bit DMA for the Asus M3A motherboard. It is a new enough board that all of the BIOS releases since the initial release (0301 from 2007-10-22) work correctly with 64bit DMA enabled. Signed-off-by: Mark Nelson Signed-off-by: Jeff Garzik Signed-off-by: Paul Gortmaker commit 68f601e1db73840f79364d6ceedc9d590feb6dd2 Author: Mark Salyzyn Date: Thu Sep 22 08:32:23 2011 -0700 libsas: fix panic when single phy is disabled on a wide port commit a73914c35b05d80f8ce78288e10056c91090b666 upstream. When a wide port is being utilized to a target, if one disables only one of the phys, we get an OS crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000238 IP: [] mutex_lock+0x21/0x50 PGD 4103f5067 PUD 41dba9067 PMD 0 Oops: 0002 [#1] SMP last sysfs file: /sys/bus/pci/slots/5/address CPU 0 Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4 ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3 jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001] Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4 ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3 jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001] Pid: 5146, comm: scsi_wq_5 Not tainted 2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server RIP: 0010:[] [] mutex_lock+0x21/0x50 RSP: 0018:ffff8803e4e33d30 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238 RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task ffff8803e4e294a0) Stack: ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e <0> ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00 <0> ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200 Call Trace: [] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas] [] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas] [] sas_ex_revalidate_domain+0x204/0x330 [libsas] [] ? sas_revalidate_domain+0x0/0x90 [libsas] [] sas_revalidate_domain+0x65/0x90 [libsas] [] worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? worker_thread+0x0/0x2a0 [] kthread+0x96/0xa0 [] child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df ff 0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d RIP [] mutex_lock+0x21/0x50 RSP CR2: 0000000000000238 The following patch is admittedly a band-aid, and does not solve the root cause, but it still is a good candidate for hardening as a pointer check before reference. Signed-off-by: Mark Salyzyn Tested-by: Jack Wang Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 9118b81229e62eb080ec68a1dc98b36c509b66d2 Author: Jouni Malinen Date: Wed Sep 21 16:13:07 2011 +0300 cfg80211: Fix validation of AKM suites commit 1b9ca0272ffae212e726380f66777b30a56ed7a5 upstream. Incorrect variable was used in validating the akm_suites array from NL80211_ATTR_AKM_SUITES. In addition, there was no explicit validation of the array length (we only have room for NL80211_MAX_NR_AKM_SUITES). This can result in a buffer write overflow for stack variables with arbitrary data from user space. The nl80211 commands using the affected functionality require GENL_ADMIN_PERM, so this is only exposed to admin users. Signed-off-by: Jouni Malinen Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 78d645ad7c66e81342cfde0e90a701c32c11eee6 Author: Mark Salyzyn Date: Thu Sep 1 06:11:17 2011 -0700 libsas: fix failure to revalidate domain for anything but the first expander child. commit 24926dadc41cc566e974022b0e66231b82c6375f upstream. In an enclosure model where there are chaining expanders to a large body of storage, it was discovered that libsas, responding to a broadcast event change, would only revalidate the domain of first child expander in the list. The issue is that the pointer value to the discovered source device was used to break out of the loop, rather than the content of the pointer. This still remains non-compliant as the revalidate domain code is supposed to loop through all child expanders, and not stop at the first one it finds that reports a change count. However, the design of this routine does not allow multiple device discoveries and that would be a more complicated set of patches reserved for another day. We are fixing the glaring bug rather than refactoring the code. Signed-off-by: Mark Salyzyn Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit bd37804641016140043d6d1970b2667c534b01ae Author: Vasily Averin Date: Fri Sep 2 19:31:46 2011 +0400 aacraid: reset should disable MSI interrupt commit d0efab26f89506387a1bde898556660e06d7eb15 upstream. scsi reset on hardware with enabled MSI interrupts generates WARNING message [11027.798722] aacraid: Host adapter abort request (0,0,0,0) [11027.798814] aacraid: Host adapter reset request. SCSI hang ? [11087.762237] aacraid: SCSI bus appears hung [11135.082543] ------------[ cut here ]------------ [11135.082646] WARNING: at drivers/pci/msi.c:658 pci_enable_msi_block+0x251/0x290() Signed-off-by: Vasily Averin Acked-by: Mark Salyzyn Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 54b8e0add30691b9775d959ea0bf0f3acfce9fcb Author: James Bottomley Date: Sun Sep 18 18:56:20 2011 +0400 3w-9xxx: fix iommu_iova leak commit 96067723e46b0dd24ae7b934085ab4eff4d26a1b upstream. Following reports on the list, it looks like the 3e-9xxx driver will leak dma mappings every time we get a transient queueing error back from the card. This is because it maps the sg list in the routine that sends the command, but doesn't unmap again in the transient failure path (even though the command is sent back to the block layer). Fix by unmapping before returning the status. Reported-by: Chris Boot Tested-by: Chris Boot Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 0bd6318e63246b5ab0c0a088712b4e003bc4dbf1 Author: Takashi Iwai Date: Mon Sep 26 10:41:21 2011 +0200 ALSA: hda/realtek - Avoid bogus HP-pin assignment commit 5fe6e0151dbd969f5fbcd94d05c968b76d76952b upstream. When the headphone pin is assigned as primary output to line_out_pins[], the automatic HP-pin assignment by ASSID must be suppressed. Otherwise a wrong pin might be assigned to the headphone and breaks the auto-mute. Reference: https://bugzilla.novell.com/show_bug.cgi?id=716104 Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit d84de18582329b57ddbfe8d45e00f09e8ab6c682 Author: Michael Chan Date: Wed Jun 8 19:29:35 2011 +0000 cnic: Improve NETDEV_UP event handling commit db1d350fcb156b58f66a67680617077bcacfe6fc upstream. During NETDEV_UP, we use symbol_get() to get the net driver's cnic probe function. This sometimes doesn't work if NETDEV_UP happens right after NETDEV_REGISTER and the net driver is still running module init code. As a result, the cnic device may not be discovered. We fix this by probing on all NETDEV events if the device's netif_running state is up. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit a08b86e5d76cce96ddb20a851b3a700dc413fc6b Author: Mike Christie Date: Fri Jun 24 15:11:55 2011 -0500 libiscsi_tcp: fix LLD data allocation commit 74dcd0ec735ba9c5bef254b2f6e53068cf3f9ff0 upstream. Have libiscsi_tcp have upper layers allocate the LLD data along with the iscsi_cls_conn struct, so it is refcounted. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit d12ada2b99093154f32947710677afb302524f50 Author: Tim Gardner Date: Tue Dec 6 11:29:20 2011 -0700 TPM: Zero buffer whole after copying to userspace commit 3ab1aff89477dafb1aaeafe8c8669114a02b7226 upstream. Commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 correctly clears the TPM buffer if the user specified read length is >= the TPM buffer length. However, if the user specified read length is < the TPM buffer length, then part of the TPM buffer is left uncleared. Reported-by: Seth Forshee Cc: Debora Velarde Cc: Rajiv Andrade Cc: Marcel Selhorst Cc: tpmdd-devel@lists.sourceforge.net Signed-off-by: Tim Gardner Signed-off-by: Rajiv Andrade Signed-off-by: Paul Gortmaker commit 48d97426c833bcf9eab80bd0099da50016108ad2 Author: Peter Huewe Date: Thu Sep 15 14:47:42 2011 -0300 TPM: Zero buffer after copying to userspace commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 upstream. Since the buffer might contain security related data it might be a good idea to zero the buffer after we have copied it to userspace. This got assigned CVE-2011-1162. Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Paul Gortmaker commit 5fde0bd53b45fb5ad654cd341617ccc1617f5ba3 Author: Peter Huewe Date: Thu Sep 15 14:37:43 2011 -0300 TPM: Call tpm_transmit with correct size commit 6b07d30aca7e52f2881b8c8c20c8a2cd28e8b3d3 upstream. This patch changes the call of tpm_transmit by supplying the size of the userspace buffer instead of TPM_BUFSIZE. This got assigned CVE-2011-1161. [The first hunk didn't make sense given one could expect way less data than TPM_BUFSIZE, so added tpm_transmit boundary check over bufsiz instead The last parameter of tpm_transmit() reflects the amount of data expected from the device, and not the buffer size being supplied to it. It isn't ideal to parse it directly, so we just set it to the maximum the input buffer can handle and let the userspace API to do such job.] Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Paul Gortmaker commit a025a0064309ef1a73260b29995981db7485ed2a Author: Hendrik Brueckner Date: Tue Jul 5 21:50:18 2011 +0000 hvc_console: Improve tty/console put_chars handling commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 upstream. Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN. This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation. If a hvc backend returns -EAGAIN, the retry handling differs: - hvc_console_print() spins to write the complete console output. - hvc_push() behaves the same way as for returning 0. Now hvc backends can indirectly control the way how console output is handled through the hvc console layer. Signed-off-by: Hendrik Brueckner Acked-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt [PG: map drivers/tty/hvc/ --> drivers/char for v2.6.34 baseline] Signed-off-by: Paul Gortmaker commit f0181a142334064ca41976a72e6035222e89cb86 Author: Marek Vasut Date: Wed Jul 20 05:57:04 2011 +0000 ASIX: Add AX88772B USB ID commit 308859097831831a979f2e82cbeef0a94f438080 upstream. This device can be found in Acer Iconia TAB W500 tablet dock. Signed-off-by: Marek Vasut Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 67386cf77229f577e85fa9a69e5d7b9bea181e80 Author: Michał Sroczyński Date: Tue Jul 5 21:53:35 2011 +0200 USB: PL2303: correctly handle baudrates above 115200 commit 8d48fdf689fed2c73c493e5146d1463689246442 upstream. PL2303: correctly handle baudrates above 115200 Signed-off-by: Michal Sroczynski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 336786aa496e057d965a10b6b6c34c0df9eb8877 Author: Rajkumar Manoharan Date: Wed Sep 14 14:28:17 2011 +0530 wireless: Reset beacon_found while updating regulatory commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream. During the association, the regulatory is updated by country IE that reaps the previously found beacons. The impact is that after a STA disconnects *or* when for any reason a regulatory domain change happens the beacon hint flag is not cleared therefore preventing future beacon hints to be learned. This is important as a regulatory domain change or a restore of regulatory settings would set back the passive scan and no-ibss flags on the channel. This is the right place to do this given that it covers any regulatory domain change. Reviewed-by: Luis R. Rodriguez Signed-off-by: Rajkumar Manoharan Acked-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit d5e183bb68038c5a55ad2194500c0f65db10daa7 Author: Manual Munz Date: Sun Sep 18 18:24:03 2011 -0500 b43: Fix beacon problem in ad-hoc mode commit 8c23516fbb209ccf8f8c36268311c721faff29ee upstream. In ad-hoc mode, driver b43 does not issue beacons. Signed-off-by: Manual Munz Tested-by: Larry Finger Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit f5f0a75ad62ca506368c3933b3669d03ace14cda Author: David Henningsson Date: Wed Sep 14 13:22:54 2011 +0200 ALSA: HDA: Cirrus - fix "Surround Speaker" volume control name commit 2e1210bc3d065a6e26ff5fef228a9a7e08921d2c upstream. This patch fixes "Surround Speaker Playback Volume" being cut off. (Commit b4dabfc452a10 was probably meant to fix this, but it fixed only the "Switch" name, not the "Volume" name.) Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 02b5b4b9e8b63565a7b34ac01d1c1c3baedbb8df Author: Mark Brown Date: Sun Sep 4 08:18:18 2011 -0700 ASoC: Fix reporting of partial jack updates commit 747da0f80e566500421bd7760b2e050fea3fde5e upstream. We need to report the entire jack state to the core jack code, not just the bits that were being updated by the caller, otherwise the status reported by other detection methods will be omitted from the state seen by userspace. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Paul Gortmaker commit cbacf3dd3f2c453e3accaaa6743e27164943b030 Author: Jeff Kirsher Date: Tue Aug 30 20:58:56 2011 -0400 e1000: Fix driver to be used on PA RISC C8000 workstations commit e2faeec2de9e2c73958e6ea6065dde1e8cd6f3a2 upstream. The checksum field in the EEPROM on HPPA is really not a checksum but a signature (0x16d6). So allow 0x16d6 as the matching checksum on HPPA systems. This issue is present on longterm/stable kernels, I have verified that this patch is applicable back to at least 2.6.32.y kernels. v2- changed ifdef to use CONFIG_PARISC instead of __hppa__ CC: Guy Martin CC: Rolf Eike Beer CC: Matt Turner Reported-by: Mikulas Patocka Signed-off-by: Jeff Kirsher Acked-by: Jesse Brandeburg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 099baedd2737726de44404344a342b2ead1db5bc Author: Andrew Vasquez Date: Tue Aug 16 11:29:28 2011 -0700 qla2xxx: Correct inadvertent loop state transitions during port-update handling. commit 58b48576966ed0afd3f63ef17480ec12748a7119 upstream. Transitioning to a LOOP_UPDATE loop-state could cause the driver to miss normal link/target processing. LOOP_UPDATE is a crufty artifact leftover from at time the driver performed it's own internal command-queuing. Safely remove this state. Signed-off-by: Andrew Vasquez Signed-off-by: Chad Dupuis Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 0712e8e78ecee643b8f9221de7216f3d0685ce3f Author: Randy Dunlap Date: Tue Jun 21 20:32:53 2011 -0700 irda: fix smsc-ircc2 section mismatch warning commit f470e5ae34d68880a38aa79ee5c102ebc2a1aef6 upstream. Fix section mismatch warning: WARNING: drivers/net/irda/smsc-ircc2.o(.devinit.text+0x1a7): Section mismatch in reference from the function smsc_ircc_pnp_probe() to the function .init.text:smsc_ircc_open() Signed-off-by: Randy Dunlap Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 6abdcf00c946fabdc049c446cce5ab7387927ecd Author: Venkateswararao Jujjuri (JV) Date: Wed Jun 29 18:06:33 2011 -0700 net/9p: Fix the msize calculation. commit c9ffb05ca5b5098d6ea468c909dd384d90da7d54 upstream. msize represents the maximum PDU size that includes P9_IOHDRSZ. Signed-off-by: Venkateswararao Jujjuri " Signed-off-by: Aneesh Kumar K.V Signed-off-by: Eric Van Hensbergen Signed-off-by: Paul Gortmaker commit 23a36a52a22b44087459d72b9b787c226250e593 Author: Aneesh Kumar K.V Date: Mon Jul 11 16:40:58 2011 +0000 fs/9p: Fid is not valid after a failed clunk. commit 5034990e28efb2d232ee82443a9edd62defd17ba upstream. free the fid even in case of failed clunk. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Eric Van Hensbergen Signed-off-by: Paul Gortmaker commit 5e09270b0da603e9b49162f414993cd53db00548 Author: Eric Van Hensbergen Date: Wed Jul 13 19:12:18 2011 -0500 net/9p: fix client code to fail more gracefully on protocol error commit b85f7d92d7bd7e3298159e8b1eed8cb8cbbb0348 upstream. There was a BUG_ON to protect against a bad id which could be dealt with more gracefully. Reported-by: Natalie Orlin Signed-off-by: Eric Van Hensbergen Signed-off-by: Paul Gortmaker commit 4b1c5d9e91589db75cb1dc18c7615514c7eb7a8a Author: Rajashekhara, Sudhakar Date: Tue Jul 12 15:58:53 2011 +0530 ARM: davinci: da850 EVM: read mac address from SPI flash commit 810198bc9c109489dfadc57131c5183ce6ad2d7d upstream. DA850/OMAP-L138 EMAC driver uses random mac address instead of a fixed one because the mac address is not stuffed into EMAC platform data. This patch provides a function which reads the mac address stored in SPI flash (registered as MTD device) and populates the EMAC platform data. The function which reads the mac address is registered as a callback which gets called upon addition of MTD device. NOTE: In case the MAC address stored in SPI flash is erased, follow the instructions at [1] to restore it. [1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash Modifications in v2: Guarded registering the mtd_notifier only when MTD is enabled. Earlier this was handled using mtd_has_partitions() call, but this has been removed in Linux v3.0. Modifications in v3: a. Guarded da850_evm_m25p80_notify_add() function and da850evm_spi_notifier structure with CONFIG_MTD macros. b. Renamed da850_evm_register_mtd_user() function to da850_evm_setup_mac_addr() and removed the struct mtd_notifier argument to this function. c. Passed the da850evm_spi_notifier structure to register_mtd_user() function. Modifications in v4: Moved the da850_evm_setup_mac_addr() function within the first CONFIG_MTD ifdef construct. Signed-off-by: Rajashekhara, Sudhakar Signed-off-by: Sekhar Nori Signed-off-by: Paul Gortmaker commit e664376f21fc892ac0014d24ab48155115d8c79e Author: Konrad Rzeszutek Wilk Date: Thu Sep 1 09:48:27 2011 -0400 xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead. commit ed467e69f16e6b480e2face7bc5963834d025f91 upstream. We have hit a couple of customer bugs where they would like to use those parameters to run an UP kernel - but both of those options turn of important sources of interrupt information so we end up not being able to boot. The correct way is to pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and the kernel will patch itself to be a UP kernel. Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308 Acked-by: Ian Campbell Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Paul Gortmaker commit 51b5aa112c7c232dd85001a702c7ed82c1e7a394 Author: Igor Mammedov Date: Thu Sep 1 13:46:55 2011 +0200 xen: x86_32: do not enable iterrupts when returning from exception in interrupt context commit d198d499148a0c64a41b3aba9e7dd43772832b91 upstream. If vmalloc page_fault happens inside of interrupt handler with interrupts disabled then on exit path from exception handler when there is no pending interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): cmpw $0x0001, XEN_vcpu_info_pending(%eax) sete XEN_vcpu_info_mask(%eax) will enable interrupts even if they has been previously disabled according to eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) setz XEN_vcpu_info_mask(%eax) Solution is in setting XEN_vcpu_info_mask only when it should be set according to cmpw $0x0001, XEN_vcpu_info_pending(%eax) but not clearing it if there isn't any pending events. Reproducer for bug is attached to RHBZ 707552 Signed-off-by: Igor Mammedov Acked-by: Jeremy Fitzhardinge Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Paul Gortmaker commit f1f8529d1c288ff6487fb76a6947d0804cebdb8f Author: Sonny Rao Date: Mon May 10 15:13:41 2010 +0000 powerpc/pci: Check devices status property when scanning OF tree commit 5b339bdf164d8aee394609768f7e2e4415b0252a upstream. We ran into an issue where it looks like we're not properly ignoring a pci device with a non-good status property when we walk the device tree and instanciate the Linux side PCI devices. However, the EEH init code does look for the property and disables EEH on these devices. This leaves us in an inconsistent where we are poking at a supposedly bad piece of hardware and RTAS will block our config cycles because EEH isn't enabled anyway. Signed-of-by: Sonny Rao Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit f10776d80e1f238bd49b12713031908adbf40bf5 Author: NeilBrown Date: Thu Aug 25 14:43:53 2011 +1000 md/linear: avoid corrupting structure while waiting for rcu_free to complete. commit 1b6afa17581027218088a18a9ceda600e0ddba7a upstream. I don't know what I was thinking putting 'rcu' after a dynamically sized array! The array could still be in use when we call rcu_free() (That is the point) so we mustn't corrupt it. Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit 5f89d486598fd0c5e5e18793093251a392ebd598 Author: Marek Marczykowski Date: Tue May 3 12:04:52 2011 -0400 xen-blkfront: fix data size for xenbus_gather in blkfront_connect commit 4352b47ab7918108b389a48d2163c9a4c2aaf139 upstream. barrier variable is int, not long. This overflow caused another variable override: "err" (in PV code) and "binfo" (in xenlinux code - drivers/xen/blkfront/blkfront.c). The later caused incorrect device flags (RO/removable etc). Signed-off-by: Marek Marczykowski Acked-by: Ian Campbell [v1: Changed title] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Paul Gortmaker commit 50f72600c24d98a0e102a7e8b7e3133d455f821c Author: Michal Schmidt Date: Mon Jan 24 12:08:48 2011 +0000 GRO: fix merging a paged skb after non-paged skbs commit d1dc7abf2fafa34b0ffcd070fd59405aa9c0a4d8 upstream. Suppose that several linear skbs of the same flow were received by GRO. They were thus merged into one skb with a frag_list. Then a new skb of the same flow arrives, but it is a paged skb with data starting in its frags[]. Before adding the skb to the frag_list skb_gro_receive() will of course adjust the skb to throw away the headers. It correctly modifies the page_offset and size of the frag, but it leaves incorrect information in the skb: ->data_len is not decreased at all. ->len is decreased only by headlen, as if no change were done to the frag. Later in a receiving process this causes skb_copy_datagram_iovec() to return -EFAULT and this is seen in userspace as the result of the recv() syscall. In practice the bug can be reproduced with the sfc driver. By default the driver uses an adaptive scheme when it switches between using napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is reproduced when under rx load with enough successful GRO merging the driver decides to switch from the former to the latter. Manual control is also possible, so reproducing this is easy with netcat: - on machine1 (with sfc): nc -l 12345 > /dev/null - on machine2: nc machine1 12345 < /dev/zero - on machine1: echo 1 > /sys/module/sfc/parameters/rx_alloc_method # use skbs echo 2 > /sys/module/sfc/parameters/rx_alloc_method # use pages - See that nc has quit suddenly. [v2: Modified by Eric Dumazet to avoid advancing skb->data past the end and to use a temporary variable.] Signed-off-by: Michal Schmidt Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 90902c3233c4033050d5378ab3614881ee47d37b Author: Herbert Xu Date: Thu May 27 16:14:30 2010 -0700 ipv6: Add GSO support on forwarding path commit 0aa68271510ae2b221d4b60892103837be63afe4 upstream. Currently we disallow GSO packets on the IPv6 forward path. This patch fixes this. Note that I discovered that our existing GSO MTU checks (e.g., IPv4 forwarding) are buggy in that they skip the check altogether, when they really should be checking gso_size + header instead. I have also been lazy here in that I haven't bothered to segment the GSO packet by hand before generating an ICMP message. Someone should add that to be 100% correct. Reported-by: Ralf Baechle Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit ab07019ff3c4111c31ea3384b518ad15f0cb5cd4 Author: Ian Campbell Date: Wed Aug 17 22:14:57 2011 +0000 sparc: fix array bounds error setting up PCIC NMI trap commit 4a0342ca8e8150bd47e7118a76e300692a1b6b7b upstream. CC arch/sparc/kernel/pcic.o arch/sparc/kernel/pcic.c: In function 'pcic_probe': arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds] cc1: all warnings being treated as errors I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear to be 4 instructions long and I presume from the usage that instructions are int sized. Signed-off-by: Ian Campbell Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Reviewed-by: Sam Ravnborg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 0bd523cb775e5866c98f7e74c68f781f51049f78 Author: David S. Miller Date: Sat Aug 20 17:14:54 2011 -0700 sparc: Allow handling signals when stack is corrupted. commit 5598473a5b40c47a8c5349dd2c2630797169cf1a upstream. If we can't push the pending register windows onto the user's stack, we disallow signal delivery even if the signal would be delivered on a valid seperate signal stack. Add a register window save area in the signal frame, and store any unsavable windows there. On sigreturn, if any windows are still queued up in the signal frame, try to push them back onto the stack and if that fails we kill the process immediately. This allows the debug/tst-longjmp_chk2 glibc test case to pass. Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 0dc7814d12a5bdf6648edd635d5f52f50f0ca04b Author: Daniel Schwierzeck Date: Fri Aug 19 12:04:20 2011 +0000 atm: br2684: Fix oops due to skb->dev being NULL commit fbe5e29ec1886967255e76946aaf537b8cc9b81e upstream. This oops have been already fixed with commit 27141666b69f535a4d63d7bc6d9e84ee5032f82a atm: [br2684] Fix oops due to skb->dev being NULL It happens that if a packet arrives in a VC between the call to open it on the hardware and the call to change the backend to br2684, br2684_regvcc processes the packet and oopses dereferencing skb->dev because it is NULL before the call to br2684_push(). but have been introduced again with commit b6211ae7f2e56837c6a4849316396d1535606e90 atm: Use SKB queue and list helpers instead of doing it by-hand. Signed-off-by: Daniel Schwierzeck Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 695ef896f612667d70df4f837e2f110e079eaa68 Author: Stanislaw Gruszka Date: Fri Aug 12 14:02:04 2011 +0200 rt2x00: do not drop usb dev reference counter on suspend commit 543cc38c8fe86deba4169977c61eb88491036837 upstream. When hibernating ->resume may not be called by usb core, but disconnect and probe instead, so we do not increase the counter after decreasing it in ->supend. As a result we free memory early, and get crash when unplugging usb dongle. BUG: unable to handle kernel paging request at 6b6b6b9f IP: [] driver_sysfs_remove+0x10/0x30 *pdpt = 0000000034f21001 *pde = 0000000000000000 Pid: 20, comm: khubd Not tainted 3.1.0-rc1-wl+ #20 LENOVO 6369CTO/6369CTO EIP: 0060:[] EFLAGS: 00010202 CPU: 1 EIP is at driver_sysfs_remove+0x10/0x30 EAX: 6b6b6b6b EBX: f52bba34 ECX: 00000000 EDX: 6b6b6b6b ESI: 6b6b6b6b EDI: c0a0ea20 EBP: f61c9e68 ESP: f61c9e64 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process khubd (pid: 20, ti=f61c8000 task=f6138270 task.ti=f61c8000) Call Trace: [] __device_release_driver+0x1f/0xa0 [] device_release_driver+0x20/0x40 [] bus_remove_device+0x84/0xe0 [] ? device_remove_attrs+0x2a/0x80 [] device_del+0xe7/0x170 [] usb_disconnect+0xd4/0x180 [] hub_thread+0x691/0x1600 [] ? wake_up_bit+0x30/0x30 [] ? complete+0x49/0x60 [] ? hub_disconnect+0xd0/0xd0 [] ? hub_disconnect+0xd0/0xd0 [] kthread+0x74/0x80 [] ? kthread_worker_fn+0x150/0x150 [] kernel_thread_helper+0x6/0x10 Signed-off-by: Stanislaw Gruszka Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit ea855e30bc0e5064f021a4bb546af6be404d729d Author: Wang Zhi Date: Wed Aug 17 10:39:31 2011 +0800 USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ehci_bus_resume(). commit d0f2fb2500b1c5fe4967eb45d8c9bc758d7aef80 upstream. From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss the action of clearing PORT_RESUME. This will cause unexpected long resume signal on USB bus. Signed-off-by: Wang Zhi Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit cc8342849dfd6f0f693586c2c62d5283332aec82 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Thu Aug 25 11:46:58 2011 +0200 USB: ftdi_sio: add Calao reference board support commit c96fbdd0ab97235f930ebf24b38fa42a2e3458cf upstream. Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and port 1 for the UART They use the same VID and PID as FTDI Chip but they program the manufacturer name in the eeprom So use this information to detect it Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Cc: Gregory Hermant Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 7e8b079eed559b42a1b99f9c64b210296d6a815b Author: J. Bruce Fields Date: Mon Jul 23 15:17:17 2012 -0400 locks: fix checking of fcntl_setlease argument commit 0ec4f431eb56d633da3a55da67d5c4b88886ccc7 upstream. The only checks of the long argument passed to fcntl(fd,F_SETLEASE,.) are done after converting the long to an int. Thus some illegal values may be let through and cause problems in later code. [ They actually *don't* cause problems in mainline, as of Dave Jones's commit 8d657eb3b438 "Remove easily user-triggerable BUG from generic_setlease", but we should fix this anyway. And this patch will be necessary to fix real bugs on earlier kernels. ] Signed-off-by: J. Bruce Fields Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 7a38cd5587a22afeb4da5a1e626a47e317b38e95 Author: David Howells Date: Tue Nov 15 22:09:45 2011 +0000 KEYS: Fix a NULL pointer deref in the user-defined key type commit 9f35a33b8d06263a165efe3541d9aa0cdbd70b3b upstream. Fix a NULL pointer deref in the user-defined key type whereby updating a negative key into a fully instantiated key will cause an oops to occur when the code attempts to free the non-existent old payload. This results in an oops that looks something like the following: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [] __call_rcu+0x11/0x13e PGD 3391d067 PUD 3894a067 PMD 0 Oops: 0002 [#1] SMP CPU 1 Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140 /DG965RY RIP: 0010:[] [] __call_rcu+0x11/0x13e RSP: 0018:ffff88003d591df8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c R10: 0000000000000000 R11: 0000000000000300 R12: ffff88003b8f9538 R13: ffffffff8161d0c0 R14: ffff88003b8f9d50 R15: ffff88003c69f908 FS: 00007f97eb18c720(0000) GS:ffff88003bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000003d47a000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process keyctl (pid: 4354, threadinfo ffff88003d590000, task ffff88003c78a040) Stack: ffff88003e0ffde0 ffff88003b8f9538 0000000000000001 ffff88003b8f9d50 ffff88003d591e28 ffffffff810860f0 ffff88003d591e68 ffffffff8117bfea ffff88003d591e68 ffffffff00000000 ffff88003e0ffde1 ffff88003e0ffde0 Call Trace: [] call_rcu_sched+0x10/0x12 [] user_update+0x8d/0xa2 [] key_create_or_update+0x236/0x270 [] sys_add_key+0x123/0x17e [] system_call_fastpath+0x16/0x1b Signed-off-by: David Howells Acked-by: Jeff Layton Acked-by: Neil Horman Acked-by: Steve Dickson Acked-by: James Morris Signed-off-by: Linus Torvalds [PG: pre-3.0 kernels dont have kfree_rcu, so tweak accordingly] Signed-off-by: Paul Gortmaker commit 6fe11a45a879526aee876ab14eb52c03c904d186 Author: Eric Paris Date: Tue Apr 17 16:26:54 2012 -0400 fcaps: clear the same personality flags as suid when fcaps are used commit d52fc5dde171f030170a6cb78034d166b13c9445 upstream. If a process increases permissions using fcaps all of the dangerous personality flags which are cleared for suid apps should also be cleared. Thus programs given priviledge with fcaps will continue to have address space randomization enabled even if the parent tried to disable it to make it easier to attack. Signed-off-by: Eric Paris Reviewed-by: Serge Hallyn Signed-off-by: James Morris Signed-off-by: Paul Gortmaker commit 1b6d4f619a138abed594d3dff058d4fa82bef7cb Author: Jonghwan Choi Date: Wed Apr 18 17:23:04 2012 -0400 security: fix compile error in commoncap.c commit 51b79bee627d526199b2f6a6bef8ee0c0739b6d1 upstream. Add missing "personality.h" security/commoncap.c: In function 'cap_bprm_set_creds': security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function) security/commoncap.c:510: error: (Each undeclared identifier is reported only once security/commoncap.c:510: error: for each function it appears in.) Signed-off-by: Jonghwan Choi Acked-by: Serge Hallyn Signed-off-by: James Morris Signed-off-by: Paul Gortmaker commit b7dbece7db7a9a7400ab5786c3bd74f4a604500b Author: Avi Kivity Date: Mon Mar 5 14:23:29 2012 +0200 KVM: Ensure all vcpus are consistent with in-kernel irqchip settings commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream. If some vcpus are created before KVM_CREATE_IRQCHIP, then irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading to potential NULL pointer dereferences. Fix by: - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP This is somewhat long winded because vcpu->arch.apic is created without kvm->lock held. Based on earlier patch by Michael Ellerman. Signed-off-by: Michael Ellerman Signed-off-by: Avi Kivity [PG: in .34 label "unlock_vcpu_destroy" is just "vcpu_destroy"] Signed-off-by: Paul Gortmaker commit 46d9757e3c6e018f9b95d93752b5051d6100bb06 Author: Alex Williamson Date: Tue Dec 20 21:59:09 2011 -0700 KVM: Device assignment permission checks commit 3d27e23b17010c668db311140b17bbbb70c78fb9 upstream. Only allow KVM device assignment to attach to devices which: - Are not bridges - Have BAR resources (assume others are special devices) - The user has permissions to use Assigning a bridge is a configuration error, it's not supported, and typically doesn't result in the behavior the user is expecting anyway. Devices without BAR resources are typically chipset components that also don't have host drivers. We don't want users to hold such devices captive or cause system problems by fencing them off into an iommu domain. We determine "permission to use" by testing whether the user has access to the PCI sysfs resource files. By default a normal user will not have access to these files, so it provides a good indication that an administration agent has granted the user access to the device. [Yang Bai: add missing #include] [avi: fix comment style] Signed-off-by: Alex Williamson Signed-off-by: Yang Bai Signed-off-by: Marcelo Tosatti [PG: Drop Documentation api.txt chunk; 2.6.34 doesn't have the file] Signed-off-by: Paul Gortmaker commit bf46eeaae85b75371290f97f57e8f85afc1fd02c Author: Alex Williamson Date: Tue Dec 20 21:59:03 2011 -0700 KVM: Remove ability to assign a device without iommu support commit 423873736b78f549fbfa2f715f2e4de7e6c5e1e9 upstream. This option has no users and it exposes a security hole that we can allow devices to be assigned without iommu protection. Make KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option. Signed-off-by: Alex Williamson Signed-off-by: Marcelo Tosatti [PG: drop Documentation chunk; no api.txt file in .34 baseline] Signed-off-by: Paul Gortmaker commit c165148d4e8e88674a8fa548ec1a33712ad3f0e3 Author: Jan Kara Date: Wed Jan 11 18:52:10 2012 +0000 xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink() commit 9b025eb3a89e041bab6698e3858706be2385d692 upstream. Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted symplink and bailed out. Fix it by jumping to 'out' instead of doing return. CC: Carlos Maiolino Signed-off-by: Jan Kara Reviewed-by: Alex Elder Reviewed-by: Dave Chinner Signed-off-by: Ben Myers Signed-off-by: Paul Gortmaker commit 5ddd060caa74495dfadac5c94f5e47ff19063ea7 Author: Carlos Maiolino Date: Mon Nov 7 16:10:24 2011 +0000 xfs: Fix possible memory corruption in xfs_readlink commit b52a360b2aa1c59ba9970fb0f52bbb093fcc7a24 upstream. Fixes a possible memory corruption when the link is larger than MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the S_ISLNK assert, since the inode mode is checked previously in xfs_readlink_by_handle() and via VFS. Updated to address concerns raised by Ben Hutchings about the loose attention paid to 32- vs 64-bit values, and the lack of handling a potentially negative pathlen value: - Changed type of "pathlen" to be xfs_fsize_t, to match that of ip->i_d.di_size - Added checking for a negative pathlen to the too-long pathlen test, and generalized the message that gets reported in that case to reflect the change As a result, if a negative pathlen were encountered, this function would return EFSCORRUPTED (and would fail an assertion for a debug build)--just as would a too-long pathlen. Signed-off-by: Alex Elder Signed-off-by: Carlos Maiolino Reviewed-by: Christoph Hellwig [PG: no xfs_alert in 2.6.34; use xfs_fs_cmn_err(CE_ALERT, ...) instead] Signed-off-by: Paul Gortmaker commit 07ef0913ac247a69c396339e88b77c615636b3e8 Author: Greg Kroah-Hartman Date: Fri May 4 12:09:39 2012 -0700 hfsplus: Fix potential buffer overflows commit 6f24f892871acc47b40dd594c63606a17c714f77 upstream. Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by: Timo Warns Acked-by: WANG Cong Cc: Alexey Khoroshilov Cc: Miklos Szeredi Cc: Sage Weil Cc: Eugene Teo Cc: Roman Zippel Cc: Al Viro Cc: Christoph Hellwig Cc: Alexey Dobriyan Cc: Dave Anderson Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 8c5fbff9c14a04599bc003f1e2ab832a28d7bfb6 Author: Jeff Layton Date: Thu Feb 23 09:37:45 2012 -0500 cifs: fix dentry refcount leak when opening a FIFO on lookup commit 5bccda0ebc7c0331b81ac47d39e4b920b198b2cd upstream. The cifs code will attempt to open files on lookup under certain circumstances. What happens though if we find that the file we opened was actually a FIFO or other special file? Currently, the open filehandle just ends up being leaked leading to a dentry refcount mismatch and oops on umount. Fix this by having the code close the filehandle on the server if it turns out not to be a regular file. While we're at it, change this spaghetti if statement into a switch too. Reported-by: CAI Qian Tested-by: CAI Qian Reviewed-by: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Paul Gortmaker commit 9b8bef04268052450e00719b178f1879048a32b5 Author: Jeff Layton Date: Tue Aug 23 07:21:28 2011 -0400 cifs: fix possible memory corruption in CIFSFindNext commit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream. The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. Fix this by making the name_len an unsigned value in CIFSFindNext. Reported-by: Darren Lavender Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Paul Gortmaker commit a1fca431f3ae6019da1896bb2ed384dbe9b08ca4 Author: Xi Wang Date: Tue Jan 10 11:51:10 2012 -0500 ext4: fix undefined behavior in ext4_fill_flex_info() commit d50f2ab6f050311dbf7b8f5501b25f0bf64a439b upstream. Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by zero when trying to mount a corrupted file system") fixes CVE-2009-4307 by performing a sanity check on s_log_groups_per_flex, since it can be set to a bogus value by an attacker. sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex; groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex < 2) { ... } This patch fixes two potential issues in the previous commit. 1) The sanity check might only work on architectures like PowerPC. On x86, 5 bits are used for the shifting amount. That means, given a large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36 is essentially 1 << 4 = 16, rather than 0. This will bypass the check, leaving s_log_groups_per_flex and groups_per_flex inconsistent. 2) The sanity check relies on undefined behavior, i.e., oversized shift. A standard-confirming C compiler could rewrite the check in unexpected ways. Consider the following equivalent form, assuming groups_per_flex is unsigned for simplicity. groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex == 0 || groups_per_flex == 1) { We compile the code snippet using Clang 3.0 and GCC 4.6. Clang will completely optimize away the check groups_per_flex == 0, leaving the patched code as vulnerable as the original. GCC keeps the check, but there is no guarantee that future versions will do the same. Signed-off-by: Xi Wang Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 5800b0b508a0af7d6a0d91eeef3d159be80534ab Author: H. Peter Anvin Date: Fri Mar 2 10:43:48 2012 -0800 regset: Prevent null pointer reference on readonly regsets commit c8e252586f8d5de906385d8cf6385fee289a825e upstream. The regset common infrastructure assumed that regsets would always have .get and .set methods, but not necessarily .active methods. Unfortunately people have since written regsets without .set methods. Rather than putting in stub functions everywhere, handle regsets with null .get or .set methods explicitly. Signed-off-by: H. Peter Anvin Reviewed-by: Oleg Nesterov Acked-by: Roland McGrath Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 5bfc315baf02e3f3093c48af4ce7c798ea9778aa Author: Peter Zijlstra Date: Wed Aug 3 13:49:31 2011 +0200 perf: overflow/perf_count_sw_cpu_clock crashes recent kernels The below patch is for -stable only, upstream has a much larger patch that contains the below hunk in commit a8b0ca17b80e92faab46ee7179ba9e99ccb61233 Vince found that under certain circumstances software event overflows go wrong and deadlock. Avoid trying to delete a timer from the timer callback. Reported-by: Vince Weaver Signed-off-by: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman [PG: backport from 2.6.32 queue, see https://lkml.org/lkml/2011/8/3/125 ] Signed-off-by: Paul Gortmaker commit 2d5bea3e719eb7dc957f168155337578acded206 Author: Xi Wang Date: Wed Nov 23 01:12:01 2011 -0500 drm: integer overflow in drm_mode_dirtyfb_ioctl() commit a5cd335165e31db9dbab636fd29895d41da55dd2 upstream. There is a potential integer overflow in drm_mode_dirtyfb_ioctl() if userspace passes in a large num_clips. The call to kmalloc would allocate a small buffer, and the call to fb->funcs->dirty may result in a memory corruption. Reported-by: Haogang Chen Signed-off-by: Xi Wang Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 3d67f874fd94587baa38869d317d537242baa097 Author: Ben Hutchings Date: Sun Mar 20 06:48:05 2011 +0000 rose: Add length checks to CALL_REQUEST parsing commit e0bccd315db0c2f919e7fcf9cb60db21d9986f52 upstream. Define some constant offsets for CALL_REQUEST based on the description at and the definition of ROSE as using 10-digit (5-byte) addresses. Use them consistently. Validate all implicit and explicit facilities lengths. Validate the address length byte rather than either trusting or assuming its value. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 55e131e30e6fe07ab213a4ee1cf1b662fe64d90f Author: Linus Torvalds Date: Wed Apr 13 08:07:28 2011 -0700 vm: fix vm_pgoff wrap in stack expansion commit a626ca6a656450e9f4df91d0dda238fff23285f4 upstream. Commit 982134ba6261 ("mm: avoid wrapping vm_pgoff in mremap()") fixed the case of a expanding mapping causing vm_pgoff wrapping when you used mremap. But there was another case where we expand mappings hiding in plain sight: the automatic stack expansion. This fixes that case too. This one also found by Robert Święcki, using his nasty system call fuzzer tool. Good job. Reported-and-tested-by: Robert Święcki Signed-off-by: Linus Torvalds [PG: .34 doesn't have perf call via 3af9e859 (in .36); adjust accordingly] Signed-off-by: Paul Gortmaker commit bc661f5d238569cae7ca9da01e12451b7785fb01 Author: Jens Axboe Date: Thu Mar 17 11:13:12 2011 +0100 fs: assign sb->s_bdi to default_backing_dev_info if the bdi is going away commit 95f28604a65b1c40b6c6cd95e58439cd7ded3add upstream. We don't have proper reference counting for this yet, so we run into cases where the device is pulled and we OOPS on flushing the fs data. This happens even though the dirty inodes have already been migrated to the default_backing_dev_info. Reported-by: Torsten Hilbrich Tested-by: Torsten Hilbrich Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 075c4ced91c551cdc2e9bb99b1697c3d54be106e Author: Luciano Coelho Date: Tue Jun 7 20:42:26 2011 +0300 nl80211: fix overflow in ssid_len commit 57a27e1d6a3bb9ad4efeebd3a8c71156d6207536 upstream. When one of the SSID's length passed in a scan or sched_scan request is larger than 255, there will be an overflow in the u8 that is used to store the length before checking. This causes the check to fail and we overrun the buffer when copying the SSID. Fix this by checking the nl80211 attribute length before copying it to the struct. This is a follow up for the previous commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem entirely. Reported-by: Ido Yariv Signed-off-by: Luciano Coelho Signed-off-by: John W. Linville [PG: 34 codebase does not have nl80211_start_sched_scan part] Signed-off-by: Paul Gortmaker commit c88f1d0ac1138655c607b21d4eb7f2d45013ffc8 Author: Eric Dumazet Date: Sat May 22 20:37:44 2010 +0000 net_sched: Fix qdisc_notify() commit 53b0f08042f04813cd1a7473dacd3edfacb28eb3 upstream. Ben Pfaff reported a kernel oops and provided a test program to reproduce it. https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805 tc_fill_qdisc() should not be called for builtin qdisc, or it dereference a NULL pointer to get device ifindex. Fix is to always use tc_qdisc_dump_ignore() before calling tc_fill_qdisc(). Reported-by: Ben Pfaff Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker