https://github.com/torvalds/linux

sort by:
Revision Author Date Message Commit Date
69964ea Linux 3.4-rc5 29 April 2012, 22:19:10 UTC
6cfdd02 Merge tag 'pm-for-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael J. Wysocki: "Fix for an issue causing hibernation to hang on systems with highmem (that practically means i386) due to broken memory management (bug introduced in 3.2, so -stable material) and PM documentation update making the freezer documentation follow the code again after some recent updates." * tag 'pm-for-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM / Freezer / Docs: Update documentation about freezing of tasks PM / Hibernate: fix the number of pages used for hibernate/thaw buffering 29 April 2012, 22:00:44 UTC
64f371b autofs: make the autofsv5 packet file descriptor use a packetized pipe The autofs packet size has had a very unfortunate size problem on x86: because the alignment of 'u64' differs in 32-bit and 64-bit modes, and because the packet data was not 8-byte aligned, the size of the autofsv5 packet structure differed between 32-bit and 64-bit modes despite looking otherwise identical (300 vs 304 bytes respectively). We first fixed that up by making the 64-bit compat mode know about this problem in commit a32744d4abae ("autofs: work around unhappy compat problem on x86-64"), and that made a 32-bit 'systemd' work happily on a 64-bit kernel because everything then worked the same way as on a 32-bit kernel. But it turned out that 'automount' had actually known and worked around this problem in user space, so fixing the kernel to do the proper 32-bit compatibility handling actually *broke* 32-bit automount on a 64-bit kernel, because it knew that the packet sizes were wrong and expected those incorrect sizes. As a result, we ended up reverting that compatibility mode fix, and thus breaking systemd again, in commit fcbf94b9dedd. With both automount and systemd doing a single read() system call, and verifying that they get *exactly* the size they expect but using different sizes, it seemed that fixing one of them inevitably seemed to break the other. At one point, a patch I seriously considered applying from Michael Tokarev did a "strcmp()" to see if it was automount that was doing the operation. Ugly, ugly. However, a prettier solution exists now thanks to the packetized pipe mode. By marking the communication pipe as being packetized (by simply setting the O_DIRECT flag), we can always just write the bigger packet size, and if user-space does a smaller read, it will just get that partial end result and the extra alignment padding will simply be thrown away. This makes both automount and systemd happy, since they now get the size they asked for, and the kernel side of autofs simply no longer needs to care - it could pad out the packet arbitrarily. Of course, if there is some *other* user of autofs (please, please, please tell me it ain't so - and we haven't heard of any) that tries to read the packets with multiple writes, that other user will now be broken - the whole point of the packetized mode is that one system call gets exactly one packet, and you cannot read a packet in pieces. Tested-by: Michael Tokarev <mjt@tls.msk.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Miller <davem@davemloft.net> Cc: Ian Kent <raven@themaw.net> Cc: Thomas Meyer <thomas@m3y3r.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 29 April 2012, 20:30:08 UTC
26e0f90 PM / Freezer / Docs: Update documentation about freezing of tasks The file Documentation/power/freezing-of-tasks.txt was still referencing the TIF_FREEZE flag, that was removed by the commit d88e4cb67197d007fb778d62fe17360e970d5bfa(freezer: remove now unused TIF_FREEZE). This patch removes all the references of TIF_FREEZE that were left behind. Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> 29 April 2012, 20:29:30 UTC
9883035 pipes: add a "packetized pipe" mode for writing The actual internal pipe implementation is already really about individual packets (called "pipe buffers"), and this simply exposes that as a special packetized mode. When we are in the packetized mode (marked by O_DIRECT as suggested by Alan Cox), a write() on a pipe will not merge the new data with previous writes, so each write will get a pipe buffer of its own. The pipe buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn will tell the reader side to break the read at that boundary (and throw away any partial packet contents that do not fit in the read buffer). End result: as long as you do writes less than PIPE_BUF in size (so that the pipe doesn't have to split them up), you can now treat the pipe as a packet interface, where each read() system call will read one packet at a time. You can just use a sufficiently big read buffer (PIPE_BUF is sufficient, since bigger than that doesn't guarantee atomicity anyway), and the return value of the read() will naturally give you the size of the packet. NOTE! We do not support zero-sized packets, and zero-sized reads and writes to a pipe continue to be no-ops. Also note that big packets will currently be split at write time, but that the size at which that happens is not really specified (except that it's bigger than PIPE_BUF). Currently that limit is the system page size, but we might want to explicitly support bigger packets some day. The main user for this is going to be the autofs packet interface, allowing us to stop having to care so deeply about exact packet sizes (which have had bugs with 32/64-bit compatibility modes). But user space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will fail with an EINVAL on kernels that do not support this interface. Tested-by: Michael Tokarev <mjt@tls.msk.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Miller <davem@davemloft.net> Cc: Ian Kent <raven@themaw.net> Cc: Thomas Meyer <thomas@m3y3r.de> Cc: stable@kernel.org # needed for systemd/autofs interaction fix Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 29 April 2012, 20:12:42 UTC
de9e24e Merge tag 'staging-3.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging tree fixes from Greg Kroah-Hartman: "Here are some tiny drivers/staging/ bugfixes. Some build fixes that were recently reported, as well as one kfree bug that is hitting a number of users." * tag 'staging-3.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: ozwpan: Fix bug where kfree is called twice. staging: octeon-ethernet: fix build errors by including interrupt.h staging: zcache: fix Kconfig crypto dependency staging: tidspbridge: remove usage of OMAP2_L4_IO_ADDRESS 29 April 2012, 19:19:13 UTC
8d7d1ad Merge tag 'usb-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg Kroah-Hartman: "Here are a number of small USB fixes for 3.4-rc5. Nothing major, as before, some USB gadget fixes. There's a crash fix for a number of ASUS laptops on resume that had been reported by a number of different people. We think the fix might also pertain to other machines, as this was a BIOS bug, and they seem to travel to different models and manufacturers quite easily. Other than that, some other reported problems fixed as well." * tag 'usb-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: gadget: udc-core: fix incompatibility with dummy-hcd usb: gadget: udc-core: fix wrong call order USB: cdc-wdm: fix race leading leading to memory corruption USB: EHCI: fix crash during suspend on ASUS computers usb gadget: uvc: uvc_request_data::length field must be signed usb: gadget: dummy: do not call pullup() on udc_stop() usb: musb: davinci.c: add missing unregister usb: musb: drop __deprecated flag USB: gadget: storage gadgets send wrong error code for unknown commands usb: otg: gpio_vbus: Add otg transceiver events and notifiers 29 April 2012, 19:17:54 UTC
f7b0069 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fixes from Chris Mason: "This has our collection of bug fixes. I missed the last rc because I thought our patches were making NFS crash during my xfs test runs. Turns out it was an NFS client bug fixed by someone else while I tried to bisect it. All of these fixes are small, but some are fairly high impact. The biggest are fixes for our mount -o remount handling, a deadlock due to GFP_KERNEL allocations in readdir, and a RAID10 error handling bug. This was tested against both 3.3 and Linus' master as of this morning." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: (26 commits) Btrfs: reduce lock contention during extent insertion Btrfs: avoid deadlocks from GFP_KERNEL allocations during btrfs_real_readdir Btrfs: Fix space checking during fs resize Btrfs: fix block_rsv and space_info lock ordering Btrfs: Prevent root_list corruption Btrfs: fix repair code for RAID10 Btrfs: do not start delalloc inodes during sync Btrfs: fix that check_int_data mount option was ignored Btrfs: don't count CRC or header errors twice while scrubbing Btrfs: fix btrfs_ioctl_dev_info() crash on missing device btrfs: don't return EINTR Btrfs: double unlock bug in error handling Btrfs: always store the mirror we read the eb from fs/btrfs/volumes.c: add missing free_fs_devices btrfs: fix early abort in 'remount' Btrfs: fix max chunk size check in chunk allocator Btrfs: add missing read locks in backref.c Btrfs: don't call free_extent_buffer twice in iterate_irefs Btrfs: Make free_ipath() deal gracefully with NULL pointers Btrfs: avoid possible use-after-free in clear_extent_bit() ... 28 April 2012, 16:30:07 UTC
b990f9b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Nothing controversial, just another batch of fixes: - Samsung/exynos fixes for more merge window fallout: build errors and warnings mostly, but also some clock/device setup issues on exynos4/5 - PXA bug and warning fixes related to gpio and pinmux - IRQ domain conversion bugfixes for U300 and MSM - A regulator setup fix for U300" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: PXA2xx: MFP: fix potential direction bug ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT arm/sa1100: fix sa1100-rtc memory resource ARM: pxa: fix gpio wakeup setting ARM: SAMSUNG: add missing MMC_CAP2_BROKEN_VOLTAGE capability ARM: EXYNOS: Fix compilation error when CONFIG_OF is not defined ARM: EXYNOS: Fix resource on dev-dwmci.c ARM: S3C24XX: Fix build warning for S3C2410_PM ARM: mini2440_defconfig: Fix build error ARM: msm: Fix gic irqdomain support ARM: EXYNOS: Fix incorrect initialization of GIC ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers ARM: u300: bump all IRQ numbers by one ARM: ux300: Fix unimplementable regulation constraints 28 April 2012, 16:28:43 UTC
cd88e3a Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "As soon as I sent the non-urgent stack, two important fixes come in: - i915: fixes SNB GPU hangs in a number of 3D apps - radeon: initial fix for VGA on LLano system, 3 or 4 of us have spent time debugging this, and Jerome finally figured out the magic bit the BIOS/fglrx set that we didn't. This at least should get things working, there may be future reliability fixes." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. drm/radeon/kms: need to set up ss on DP bridges as well 28 April 2012, 16:27:07 UTC
fcbf94b Revert "autofs: work around unhappy compat problem on x86-64" This reverts commit a32744d4abae24572eff7269bc17895c41bd0085. While that commit was technically the right thing to do, and made the x86-64 compat mode work identically to native 32-bit mode (and thus fixing the problem with a 32-bit systemd install on a 64-bit kernel), it turns out that the automount binaries had workarounds for this compat problem. Now, the workarounds are disgusting: doing an "uname()" to find out the architecture of the kernel, and then comparing it for the 64-bit cases and fixing up the size of the read() in automount for those. And they were confused: it's not actually a generic 64-bit issue at all, it's very much tied to just x86-64, which has different alignment for an 'u64' in 64-bit mode than in 32-bit mode. But the end result is that fixing the compat layer actually breaks the case of a 32-bit automount on a x86-64 kernel. There are various approaches to fix this (including just doing a "strcmp()" on current->comm and comparing it to "automount"), but I think that I will do the one that teaches pipes about a special "packet mode", which will allow user space to not have to care too deeply about the padding at the end of the autofs packet. That change will make the compat workaround unnecessary, so let's revert it first, and get automount working again in compat mode. The packetized pipes will then fix autofs for systemd. Reported-and-requested-by: Michael Tokarev <mjt@tls.msk.ru> Cc: Ian Kent <raven@themaw.net> Cc: stable@kernel.org # for 3.3 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 28 April 2012, 15:29:56 UTC
3a69ddd drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when using separate stencil buffers. Without it, the GPU tries to use the LRA eviction policy, which isn't supported. This was supposed to be off by default, but seems to be on for many machines. This cannot be done in gen6_init_clock_gating with most of the other workaround bits; the render ring needs to exist. Otherwise, the register write gets dropped on the floor (one printk will show it changed, but a second printk immediately following shows the value reverts to the old one). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Cc: stable@vger.kernel.org Cc: Rob Castle <futuredub@gmail.com> Cc: Eric Appleman <erappleman@gmail.com> Cc: aaron667@gmx.net Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> 28 April 2012, 07:05:15 UTC
700698e drm/radeon/kms: need to set up ss on DP bridges as well Makes Nutmeg DP to VGA bridges work for me. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=42490 Noticed by Jerome Glisse (after weeks of debugging). Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> 28 April 2012, 07:04:34 UTC
c629eaf Merge git://git.samba.org/sfrench/cifs-2.6 Pull CIFS fixes from Steve French. * git://git.samba.org/sfrench/cifs-2.6: Use correct conversion specifiers in cifs_show_options CIFS: Show backupuid/gid in /proc/mounts cifs: fix offset handling in cifs_iovec_write 28 April 2012, 03:56:54 UTC
4bbbf13 Merge tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull Xen fixes from Konrad Rzeszutek Wilk: "Some of these had been in existence since the 2.6.27 days, some since 3.0 - and some due to new features added in v3.4. The one that is most interesting is David's one - in the low-level assembler code we had be checking events needlessly. With his patch now we do it when the appropriate flag is set - with the added benefit that we can process events faster. Stefano's is fixing a mistake where the Linux IRQ numbers were ACK-ed instead of the Xen IRQ, resulting in missing interrupts. The other ones are bootup related that can show up on various hardware." - In the low-level assembler code we would jump to check events even if none were present. This incorrect behavior had been there since 2.6.27 days! - When using the fast-path for ACK-ing interrupts we were using the Linux IRQ numbers instead of the Xen ones (and they can differ) and missing interrupts in process. - Fix bootup crashes when ACPI hotplug CPUs were present and they would expand past the set number of CPUs we were allocated. - Deal with broken BIOSes when uploading C-states to the hypervisor. - Disable the cpuid check for MWAIT_LEAF if the ACPI PAD driver is loaded. If the ACPI PAD driver is used it will crash, so lets not export the functionality so the ACPI PAD driver won't load. * tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xen: correctly check for pending events when restoring irq flags xen/acpi: Workaround broken BIOSes exporting non-existing C-states. xen/smp: Fix crash when booting with ACPI hotplug CPUs. xen: use the pirq number to check the pirq_eoi_map xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded. 28 April 2012, 02:56:22 UTC
84c6a81 Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 Pull misc SPI device driver bug fixes from Grant Likely. * tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6: spi/spi-bfin5xx: Fix flush of last bit after each spi transfer spi/spi-bfin5xx: fix reversed if condition in interrupt mode spi/spi_bfin_sport: drop bits_per_word from client data spi/bfin_spi: drop bits_per_word from client data spi/spi-bfin-sport: move word length setup to transfer handler spi/bfin5xx: rename config macro name for bfin5xx spi controller driver spi/pl022: Allow request for higher frequency than maximum possible spi/bcm63xx: set master driver mode_bits. spi/bcm63xx: don't use the stopping state spi/bcm63xx: convert to the pump message infrastructure spi/spi-ep93xx.c: use dma_transfer_direction instead of dma_data_direction spi: fix spi.h kernel-doc warning spi/pl022: Fix calculate_effective_freq() spi/pl022: Fix range checking for bits per word 28 April 2012, 02:52:30 UTC
9f7e2f9 Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon patches from Guenter Roeck: - Fix build warning in ad7314 driver - Fix pci_device_id array access in fam15h_power driver, introduced by commit 00250ec90963 ("hwmon: fam15h_power: fix bogus values with current BIOSes") * tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (fam15h_power) Fix pci_device_id array hwmon: (ad7314) Fix build warning 28 April 2012, 02:50:56 UTC
a882a4d Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "For your Friday pull request stack, nothing astounding or shattering this week some exynos, some intel, some radeon fixes. One intel fix for a regression somwehere back in 2.6.35 land." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon/kms: use frac fb div on APUs drm/radeon: add a missing entry to encoder_names drm/i915: handle input/output sdvo timings separately in mode_set drm/i915: fix integer overflow in i915_gem_do_execbuffer() drm/i915: fix integer overflow in i915_gem_execbuffer2() drm/exynos: added missed vm area region mapping type. drm/exynos: fixed exynos_drm_gem_map_pages bug. drm/exynos: fixed duplicatd memory allocation bug. drm/i915: fixup load-detect on enabled, but not active pipe 28 April 2012, 02:46:31 UTC
78e97a4 Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull RCU fix from Ingo Molnar. * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: rcu: Permit call_rcu() from CPU_DYING notifiers 28 April 2012, 02:40:56 UTC
c28c485 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar. * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/apic: Use x2apic physical mode based on FADT setting x86/mrst: Quiet sparse noise about plain integer as NULL pointer x86, intel_cacheinfo: Fix error return code in amd_set_l3_disable_slot() 28 April 2012, 02:40:17 UTC
daae677 Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar. * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched: Fix OOPS when build_sched_domains() percpu allocation fails sched: Fix more load-balancing fallout 28 April 2012, 02:37:00 UTC
06fc5d3 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar. * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix perf_event_for_each() to use sibling perf symbols: Read plt symbols from proper symtab_type binary tracing: Fix stacktrace of latency tracers (irqsoff and friends) perf tools: Add 'G' and 'H' modifiers to event parsing tracing: Fix regression with tracing_on perf tools: Drop CROSS_COMPILE from flex and bison calls perf report: Fix crash showing warning related to kernel maps tracing: Fix build breakage without CONFIG_PERF_EVENTS (again) 28 April 2012, 02:35:50 UTC
f607245 Merge branch 'for-v3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux Pull build fixes for less mainstream architectures from Paul Gortmaker: "These are fixes for frv(1), blackfin(2), powerpc(1) and xtensa(4). Fortunately the touches are nearly all specific to files just used by the arch in question. The two touches to shared/common files [kernel/irq/debug.h and drivers/pci/Makefile] are trivial to assess as no risk to anyone. Half of them relate to xtensa directly. It was only when I fixed the last xtensa issue that I realized that the arch has been broken for a significant time, and isn't a specific v3.4 regression. So if you wanted, we could leave xtensa lying bleeding in the street for a couple more weeks and queue those for 3.5. But given they are no risk to anyone outside of xtensa, I figured to just leave them in. If you are OK with taking the xtensa fixes, then please pull to get: - one last implicit include uncovered by system.h that is in a file specific to just one powerpc defconfig. (I'd sync'd with BenH). - fix an oversight in the PCI makefile where shared code wasn't being compiled for ARCH=frv - fix a missing include for GPIO in blackfin framebuffer. - audit and tag endif in blackfin ezkit board file, in order to find and fix the misplaced endif masking a block of code. - fix irq/debug.h choice of temporary macro names to be more internal so they don't conflict with names used by xtensa. - fix a reference to an undeclared local var in xtensa's signal.c - fix an implicit bug.h usage in xtensa's asm/io.h uncovered by my removing bug.h from kernel.h - fix xtensa to properly indicate it is using asm-generic/hardirq.h in order to resolve the link error - undefined ack_bad_irq The xtensa still fails final link as my latest binutils does something evil when ld forward-relocates unlikely() blocks, but in theory people who have older/valid toolchains could now use the thing." * 'for-v3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: xtensa: fix build fail on undefined ack_bad_irq blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c blackfin: fix compile error in bfin-lq035q1-fb.c pci: frv architecture needs generic setup-bus infrastructure irq: hide debug macros so they don't collide with others. xtensa: fix build error in xtensa/include/asm/io.h xtensa: fix build failure in xtensa/kernel/signal.c powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig] 28 April 2012, 02:32:37 UTC
d7e69bc Merge tag 'sh-for-linus' of git://github.com/pmundt/linux-sh Pull SuperH fixes from Paul Mundt. * tag 'sh-for-linus' of git://github.com/pmundt/linux-sh: sh: Fix up tracepoint build fallout from static key introduction. sh: Fix error synchronising kernel page tables 28 April 2012, 02:31:10 UTC
9c68770 Merge branch 'docs-3.4' of git://git.samba.org/jlayton/linux Pull security key doc update from Jeff Layton: "Ordinarily, I send my patches through others' trees, but David suggested I just send this one to you directly since it's just a Documentation/ update" * 'docs-3.4' of git://git.samba.org/jlayton/linux: keys: update the documentation with info about "logon" keys 28 April 2012, 02:27:26 UTC
7eb7ce4 xen: correctly check for pending events when restoring irq flags In xen_restore_fl_direct(), xen_force_evtchn_callback() was being called even if no events were pending. This resulted in (depending on workload) about a 100 times as many xen_version hypercalls as necessary. Fix this by correcting the sense of the conditional jump. This seems to give a significant performance benefit for some workloads. There is some subtle tricksy "..since the check here is trying to check both pending and masked in a single cmpw, but I think this is correct. It will call check_events now only when the combined mask+pending word is 0x0001 (aka unmasked, pending)." (Ian) CC: stable@kernel.org Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 27 April 2012, 20:04:21 UTC
dc7fdde Btrfs: reduce lock contention during extent insertion We're spending huge amounts of time on lock contention during end_io processing because we unconditionally assume we are overwriting an existing extent in the file for each IO. This checks to see if we are outside i_size, and if so, it uses a less expensive readonly search of the btree to look for existing extents. Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 18:51:05 UTC
fede766 Btrfs: avoid deadlocks from GFP_KERNEL allocations during btrfs_real_readdir Btrfs has an optimization where it will preallocate dentries during readdir to fill in enough information to open the inode without an extra lookup. But, we're calling d_alloc, which is doing GFP_KERNEL allocations, and that leads to deadlocks because our readdir code has tree locks held. For now, disable this optimization. We'll fix the gfp mask in the next merge window. Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 18:23:22 UTC
2431a81 spi/spi-bfin5xx: Fix flush of last bit after each spi transfer This patch ensures that the last bit of a transfer gets correctly flushed out of the register. Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:20:39 UTC
128465c spi/spi-bfin5xx: fix reversed if condition in interrupt mode This condition is used to determine 8 bits or 16 and 32 bits transfer. Obviously it is reversed. Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:19:01 UTC
8d9d2a4 spi/spi_bfin_sport: drop bits_per_word from client data Since the member was dropped from the common Blackfin header, we need to stop using it in the SPORT driver too. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:17:25 UTC
7666fd8 spi/bfin_spi: drop bits_per_word from client data No other SPI controller has this field, and SPI clients should be setting this up in their own drivers. So drop it from the Blackfin controller to keep people from using it. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:16:39 UTC
488e1a9 spi/spi-bfin-sport: move word length setup to transfer handler Each transfer may have its own bits per word. Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:16:21 UTC
22ac3e8 spi/bfin5xx: rename config macro name for bfin5xx spi controller driver This controller is only for blackfin 5xx soc, so rename it to BFIN5XX Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:15:45 UTC
ea505bc spi/pl022: Allow request for higher frequency than maximum possible Currently, if we request for frequency greater than maximum possible, spi driver returns error. For example, if the spi block src frequency is 333/4 MHz, i.e. 83.33.. MHz, maximum frequency programmable would be src/2. Which would come around 41.6... It is difficult to pass frequency in these figures. We normally try to program in round figures, like 42 MHz and it should get programmed to <= requested_frequency, i.e. 41.6... For this to happen, we must not return error even if requested freq is higher than max possible. But should program it to max possible. Reported-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com> Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 18:07:40 UTC
7654b72 Btrfs: Fix space checking during fs resize Fix out-of-space checking, addressing a warning and potential resource leak when resizing the filesystem down while allocating blocks. Signed-off-by: Daniel J Blueman <daniel@quora.org> Reviewed-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 17:55:14 UTC
1f699d3 Btrfs: fix block_rsv and space_info lock ordering may_commit_transaction() calls spin_lock(&space_info->lock); spin_lock(&delayed_rsv->lock); and update_global_block_rsv() calls spin_lock(&block_rsv->lock); spin_lock(&sinfo->lock); Lockdep complains about this at run time. Everywhere except in update_global_block_rsv(), the space_info lock is the outer lock, therefore the locking order in update_global_block_rsv() is changed. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 17:55:14 UTC
1daf354 Btrfs: Prevent root_list corruption I was seeing root_list corruption on unmount during fs resize in 3.4-rc4; add correct locking to address this. Signed-off-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 17:55:13 UTC
3e74317 Btrfs: fix repair code for RAID10 btrfs_map_block sets mirror_num, so that the repair code knows eventually which device gave us the read error. For RAID10, mirror_num must be 1 or 2. Before this fix mirror_num was incorrectly related to our stripe index. Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net> Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 17:55:13 UTC
996d282 Btrfs: do not start delalloc inodes during sync btrfs_start_delalloc_inodes will just walk the list of delalloc inodes and start writing them out, but it doesn't splice the list or anything so as long as somebody is doing work on the box you could end up in this section _forever_. So just remove it, it's not needed anyway since sync will start writeback on all inodes anyway, all we need to do is wait for ordered extents and then we can commit the transaction. In my horrible torture test sync goes from taking 4 minutes to about 1.5 minutes. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com> 27 April 2012, 17:55:12 UTC
88a3a25 spi/bcm63xx: set master driver mode_bits. We were not properly advertising the MODE bits supported by this driver, fix that. Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 17:19:15 UTC
1e41dc0 spi/bcm63xx: don't use the stopping state We do not need to use a flag to indicate if the master driver is stopping it is sufficient to perform spi master unregistering in the platform driver's remove function. Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 17:16:46 UTC
cde4384 spi/bcm63xx: convert to the pump message infrastructure This patch converts the bcm63xx SPI driver to use the SPI infrastructure pump message queue. Since we were previously sleeping in the SPI driver's transfer() function (which is not allowed) this is now fixed as well. To complete that conversion a certain number of changes have been made: - the transfer len is split into multiple hardware transfers in case its size is bigger than the hardware FIFO size - the FIFO refill is no longer done in the interrupt context, which was a bad idea leading to quick interrupt handler re-entrancy Tested-by: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com> Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 17:15:41 UTC
d4b9b57 spi/spi-ep93xx.c: use dma_transfer_direction instead of dma_data_direction A new enum indicating the dma channel direction was introduced by: commit 49920bc66984a512f4bcc7735a61642cd0e4d6f2 dmaengine: add new enum dma_transfer_direction The following commit changed spi-ep93xx to use the new enum: commit a485df4b4404379786c4bdd258bc528b2617449d spi, serial: move to dma_transfer_direction In doing so a sparse warning was introduced: warning: mixing different enum types int enum dma_data_direction versus int enum dma_transfer_direction This is produced because the 'dir' passed in ep93xx_spi_dma_prepare is an enum dma_data_direction and is being used to set the dma_slave_config 'direction' which is now an enum dma_transfer_direction. Fix this by converting spi-ep93xx to use the new enum type in all places. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: Mika Westerberg <mika.westerberg@iki.fi> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 17:11:28 UTC
dbabe0d spi: fix spi.h kernel-doc warning Fix kernel-doc warning in spi.h (copy/paste): Warning(include/linux/spi/spi.h:365): No description found for parameter 'unprepare_transfer_hardware' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 17:03:38 UTC
5eb806a spi/pl022: Fix calculate_effective_freq() calculate_effective_freq() was still not optimized and there were cases when it returned without error and with values of cpsr and scr as zero. Also, the variable named found is not used well. This patch targets to optimize and correct this routine. Tested for SPEAr. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Tested-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 27 April 2012, 16:47:51 UTC
6e76538 Merge branch 'v3.4-samsung-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes * 'v3.4-samsung-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: SAMSUNG: add missing MMC_CAP2_BROKEN_VOLTAGE capability ARM: EXYNOS: Fix compilation error when CONFIG_OF is not defined ARM: EXYNOS: Fix resource on dev-dwmci.c ARM: S3C24XX: Fix build warning for S3C2410_PM ARM: mini2440_defconfig: Fix build error ARM: EXYNOS: Fix incorrect initialization of GIC ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers 27 April 2012, 16:40:06 UTC
dadb366 Merge branch 'fixes' of git://github.com/hzhuang1/linux into fixes * 'fixes' of git://github.com/hzhuang1/linux: ARM: PXA2xx: MFP: fix potential direction bug ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT arm/sa1100: fix sa1100-rtc memory resource ARM: pxa: fix gpio wakeup setting 27 April 2012, 16:31:02 UTC
41c8a48 Merge tag 'fixes-for-v3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus usb: fixes for v3.4-rc cycle A few more fixes for v3.4-rc cycle. It includes a couple of fixes to the ordering of the methods in udc-core.c. Without these two patches, we will have issues when either unregistering a gadget driver (triggered with dummy_hcd only) or issuing a device-initiated disconnect through sysfs. There's also a fix on dummy_hcd to not call ->pullup() from udc_stop() because udc-core.c already handles that. A fix to MUSB as promised, to kill the compile warnings regarding deprecated interfaces. We are essentially dropping the __deprecated flag because it doesn't look like we will ever be able to live without it when we consider the amount of silicon issues we find on different MUSB instantiations. A couple of other fixes are also available, one adding the missing transceiver events to gpio_vbus and another adding a missing unregister call to MUSB's davinci glue layer. 27 April 2012, 14:50:34 UTC
320cd1e usb: gadget: udc-core: fix incompatibility with dummy-hcd This patch (as1548) fixes a recently-introduced incompatibility between the UDC core and the dummy-hcd driver. Commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 (usb: gadget: udc-core: fix asymmetric calls in remove_driver) moved the usb_gadget_udc_stop() call in usb_gadget_remove_driver() below the usb_gadget_disconnect() call. As a result, usb_gadget_disconnect() gets called at a time when the gadget driver believes it has been unbound but dummy-hcd believes it has not. A nasty error ensues when dummy-hcd calls the gadget driver's disconnect method a second time. To fix the problem, this patch moves the gadget driver's unbind notification after the usb_gadget_disconnect() call. Now nothing happens between the two unbind notifications, so nothing goes wrong. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> 27 April 2012, 08:06:15 UTC
83a787a usb: gadget: udc-core: fix wrong call order commit 6d258a4 (usb: gadget: udc-core: stop UDC on device-initiated disconnect) introduced another case of asymmetric calls when issuing a device-initiated disconnect. Fix it. Reported-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Felipe Balbi <balbi@ti.com> 27 April 2012, 08:02:15 UTC
37d4174 drm/radeon/kms: use frac fb div on APUs Seems to be more stable on certain monitors. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48880 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> 27 April 2012, 07:30:19 UTC
df391c0 drm/radeon: add a missing entry to encoder_names An entry for INTERNAL_VCE encoder was missing. Add it. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> 27 April 2012, 07:29:50 UTC
792ac99 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes From Daniel Vetter - VGA load-detect fix. This bug seems to be as old as the load-detect code (2.6.30), but needs stupid userspace (upowerd trying to detect connectors on dpms-off outputs) to actually kill the machine. And obviously a machine without VGA-hotplug, otherwise we don't do load detect. - 2 interger overflow fixes for unpriviledged ioctls from Xi Wang. - Fix SDVO regression for low-res (pixelclock < 100MHz) digital outputs, introduce in 2.6.36. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: handle input/output sdvo timings separately in mode_set drm/i915: fix integer overflow in i915_gem_do_execbuffer() drm/i915: fix integer overflow in i915_gem_execbuffer2() drm/i915: fixup load-detect on enabled, but not active pipe 27 April 2012, 07:21:31 UTC
b9556e0 Merge branch 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung into drm-fixes From Inki Dae: this patch set fixes gem allocation and mapping issue between user space and physical memory region. * 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung: drm/exynos: added missed vm area region mapping type. drm/exynos: fixed exynos_drm_gem_map_pages bug. drm/exynos: fixed duplicatd memory allocation bug. 27 April 2012, 07:20:35 UTC
ef7c7c6 ARM: PXA2xx: MFP: fix potential direction bug Pins configured as input and have MFP_LPM_DRIVE_* flag set, can have a wrong output value for some period of time (spike) during the suspend sequence. This can happen because the direction of the pins (GPDR) is set by software and the output level is set by hardware (PGSR) at a later stage. Fix the above potential bug by setting the output levels first. Also save the actual levels of the pins before the suspend and restore them after the resume, but before the direction settings take place, so the same bug as described above will not happen in the resume sequence. Reported-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com> 27 April 2012, 03:14:06 UTC
a13b878 ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT Pins that have MFP_LPM_KEEP_OUTPUT set and are configured for output must retain the output state in low power mode. Currently, the pin direction configuration is overrided with values in gpdr_lpm[] array and do not obey the MFP_LPM_KEEP_OUTPUT setting. Fix the above bug and add some documentation to clarify the MFP_LPM_KEEP_OUTPUT setting purpose. Reported-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com> 27 April 2012, 03:11:50 UTC
9f9d27e arm/sa1100: fix sa1100-rtc memory resource DEFINE_RES_MEM() takes the size of resource as a second argument, not the end address. Passing end address leads to following error in runtime during device registration: sa1100-rtc: failed to claim resource 0 Fix it. Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com> 27 April 2012, 03:02:14 UTC
b95ace5 ARM: pxa: fix gpio wakeup setting In 3.3, gpio wakeup setting was broken. The call enable_irq_wake() didn't set up the PXA gpio registers (PWER, ...) anymore. Fix it at least for pxa27x. The driver doesn't seem to be used in pxa25x (weird ...), and the fix doesn't extend to pxa3xx and pxa95x (which don't have a gpio_set_wake() available). Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com> 27 April 2012, 02:46:45 UTC
b930fe5 xen/acpi: Workaround broken BIOSes exporting non-existing C-states. We did a similar check for the P-states but did not do it for the C-states. What we want to do is ignore cases where the DSDT has definition for sixteen CPUs, but the machine only has eight CPUs and we get: xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14 Reported-by: Tobias Geiger <tobias.geiger@vido.info> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 27 April 2012, 02:07:28 UTC
cf405ae xen/smp: Fix crash when booting with ACPI hotplug CPUs. When we boot on a machine that can hotplug CPUs and we are using 'dom0_max_vcpus=X' on the Xen hypervisor line to clip the amount of CPUs available to the initial domain, we get this: (XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all .. snip.. DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011 .. snip. SMP: Allowing 64 CPUs, 32 hotplug CPUs installing Xen timer for CPU 7 cpu 7 spinlock event irq 361 NMI watchdog: disabled (cpu7): hardware events not enabled Brought up 8 CPUs .. snip.. [acpi processor finds the CPUs are not initialized and starts calling arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online] CPU 8 got hotplugged CPU 9 got hotplugged CPU 10 got hotplugged .. snip.. initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs calling erst_init+0x0/0x2bb @ 1 [and the scheduler sticks newly started tasks on the new CPUs, but said CPUs cannot be initialized b/c the hypervisor has limited the amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag. The spinlock tries to kick the other CPU, but the structure for that is not initialized and we crash.] BUG: unable to handle kernel paging request at fffffffffffffed8 IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60 PGD 180d067 PUD 180e067 PMD 0 Oops: 0002 [#1] SMP CPU 7 Modules linked in: Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP RIP: e030:[<ffffffff81035289>] [<ffffffff81035289>] xen_spin_lock+0x29/0x60 RSP: e02b:ffff8801fb9b3a70 EFLAGS: 00010282 With this patch, we cap the amount of vCPUS that the initial domain can run, to exactly what dom0_max_vcpus=X has specified. In the future, if there is a hypercall that will allow a running domain to expand past its initial set of vCPUS, this patch should be re-evaluated. CC: stable@kernel.org Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 27 April 2012, 02:07:21 UTC
3c3c801 Merge branch 'sh/urgent' into sh-fixes-for-linus 27 April 2012, 01:57:34 UTC
ec2ccd8 sh: Fix up tracepoint build fallout from static key introduction. With the introduction of static keys, anything using tracepoints blows up in the following manner: include/trace/events/oom.h:8:13: error: initializer element is not constant include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update') include/trace/events/oom.h:8:13: error: initializer element is not constant include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update.key') This is a result of the STATIC_KEY_INIT_xxx defs wrapping ATOMIC_INIT() which on sh includes an atomic_t typecast. Given that we don't really need the typecast for anything anymore, the simplest solution is simply to kill off the cast. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org> 27 April 2012, 01:42:38 UTC
5c22837 USB: cdc-wdm: fix race leading leading to memory corruption This patch fixes a race whereby a pointer to a buffer would be overwritten while the buffer was in use leading to a double free and a memory leak. This causes crashes. This bug was introduced in 2.6.34 Signed-off-by: Oliver Neukum <oneukum@suse.de> Tested-by: Bjørn Mork <bjorn@mork.no> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 26 April 2012, 23:59:44 UTC
82b7690 Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile Pull arch/tile fixes from Chris Metcalf: "One change fixes a platform-independent bug about environment var handling in the boot command line. The other is a trivial tile-specific bug fix to avoid a link-time warning." * 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: arch/tile: fix a couple of functions that should be __init init: fix bug where environment vars can't be passed via boot args 26 April 2012, 22:36:27 UTC
ebcf596 Merge tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband Pull infiniband fixes from Roland Dreier: "A few fixes for regressions introduced in 3.4-rc1: - fix memory leak in mlx4 - fix two problems with new MAD response generation code" * tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: IB/mlx4: Fix memory leaks in ib_link_query_port() IB/mad: Don't send response for failed MADs IB/mad: Set 'D' bit in response for unhandled MADs 26 April 2012, 22:35:35 UTC
8e12a03 xtensa: fix build fail on undefined ack_bad_irq Commit e520c410854bab763be24e0fce7ba89dc252efee "xtensa: convert to asm-generic/hardirq.h" converted over to using the asm-generic parts, but it also added the sentinel #define ack_bad_irq ack_bad_irq which tells asm-generic to _not_ use the common ack_bad_irq. Since e520c41 deleted the duplicated code from the arch specific file, we _do_ want the asm-generic one in scope. So delete the trigger define above which hides it. In doing so we'll realize that we've got to delete the almost-duplicate prototype as well to avoid "static declaration ... follows non-static". Cc: Christoph Hellwig <hch@lst.de> Cc: Chris Zankel <chris@zankel.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 26 April 2012, 22:35:32 UTC
acdf2fc Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma Pull [GIT PULL] slave-dmaengine fixes from Vinod Koul. * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine/amba-pl08x : reset phychan_hold on terminate all dma: pl330: fix a couple of compilation warnings dma/ste_dma40: fix erroneous comparison dma/ste_dma40: explicitly include regulator consumer header dma40: Improve the logic of stopping logical chan dmaengine: at_hdmac: remove clear-on-read in atc_dostart() dma: mxs-dma: enable channel in device_issue_pending call dmaengine: imx-dma: dont complete descriptor for cyclic dma 26 April 2012, 22:33:36 UTC
2390c0f Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A workaround for an ASUS laptop and a few ASoC changes; most of the commits are tagged for stable, too." * tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: wm8994: Improve sequencing of AIF channel enables ALSA: HDA: Add external mic quirk for Asus Zenbook UX31E ASoC: fsi: update for dmaengine prep_slave_sg fallout. ASoC: core: Fix card RTD count for deferred probe. ASoC: cs42l73: don't use negative array index ASoC: dapm: Ensure power gets managed for line widgets 26 April 2012, 22:32:39 UTC
65dd4b9 Merge git://www.linux-watchdog.org/linux-watchdog Pull a watchdog fix from Wim Van Sebroeck: "It will fix the size when reading or writing to WD Timer port 0x72 in the hpwdt driver." * git://www.linux-watchdog.org/linux-watchdog: hpwdt: Only BYTE reads/writes to WD Timer port 0x72 26 April 2012, 22:31:53 UTC
aaaf069 Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Thomas Gleixner. * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tick: Fix the spurious broadcast timer ticks after resume tick: Ensure that the broadcast device is initialized tick: Fix oneshot broadcast setup really 26 April 2012, 22:30:26 UTC
110a5c8 Merge branch 'akpm' (Andrew's patch-bomb) Merge fixes from Andrew Morton: "13 fixes. The acerhdf patches aren't (really) fixes. But they've been stuck in my tree for up to two years, sent to Matthew multiple times and the developers are unhappy." * emailed from Andrew Morton <akpm@linux-foundation.org>: (13 patches) mm: fix NULL ptr dereference in move_pages mm: fix NULL ptr dereference in migrate_pages revert "proc: clear_refs: do not clear reserved pages" drivers/rtc/rtc-ds1307.c: fix BUG shown with lock debugging enabled arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file hugetlbfs: lockdep annotate root inode properly acerhdf: lowered default temp fanon/fanoff values acerhdf: add support for new hardware acerhdf: add support for Aspire 1410 BIOS v1.3314 fs/buffer.c: remove BUG() in possible but rare condition mm: fix up the vmscan stat in vmstat epoll: clear the tfile_check_list on -ELOOP mm/hugetlb: fix warning in alloc_huge_page/dequeue_huge_page_vma 26 April 2012, 22:24:45 UTC
521394e xen: use the pirq number to check the pirq_eoi_map In pirq_check_eoi_map use the pirq number rather than the Linux irq number to check whether an eoi is needed in the pirq_eoi_map. The reason is that the irq number is not always identical to the pirq number so if we wrongly use the irq number to check the pirq_eoi_map we are going to check for the wrong pirq to EOI. As a consequence some interrupts might not be EOI'ed by the guest correctly. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Tested-by: Tobias Geiger <tobias.geiger@vido.info> [v1: Added some extra wording to git commit] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 26 April 2012, 22:02:02 UTC
df88b2d xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded. There are exactly four users of __monitor and __mwait: - cstate.c (which allows acpi_processor_ffh_cstate_enter to be called when the cpuidle API drivers are used. However patch "cpuidle: replace xen access to x86 pm_idle and default_idle" provides a mechanism to disable the cpuidle and use safe_halt. - smpboot (which allows mwait_play_dead to be called). However safe_halt is always used so we skip that. - intel_idle (same deal as above). - acpi_pad.c. This the one that we do not want to run as we will hit the below crash. Why do we want to expose MWAIT_LEAF in the first place? We want it for the xen-acpi-processor driver - which uploads C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c sets the proper address in the C-states so that the hypervisor can benefit from using the MWAIT functionality. And that is the sole reason for using it. Without this patch, if a module performs mwait or monitor we get this: invalid opcode: 0000 [#1] SMP CPU 2 .. snip.. Pid: 5036, comm: insmod Tainted: G O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP RIP: e030:[<ffffffffa000a017>] [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check] RSP: e02b:ffff8801c298bf18 EFLAGS: 00010282 RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200 RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003 FS: 00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0) Stack: ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd 000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6 00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000 Call Trace: [<ffffffff81002124>] do_one_initcall+0x124/0x170 [<ffffffff810c41e6>] sys_init_module+0xc6/0x220 [<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00 RIP [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check] RSP <ffff8801c298bf18> ---[ end trace 16582fc8a3d1e29a ]--- Kernel panic - not syncing: Fatal exception With this module (which is what acpi_pad.c would hit): MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>"); MODULE_DESCRIPTION("mwait_check_and_back"); MODULE_LICENSE("GPL"); MODULE_VERSION(); static int __init mwait_check_init(void) { __monitor((void *)&current_thread_info()->flags, 0, 0); __mwait(0, 0); return 0; } static void __exit mwait_check_exit(void) { } module_init(mwait_check_init); module_exit(mwait_check_exit); Reported-by: Liu, Jinsong <jinsong.liu@intel.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 26 April 2012, 21:46:20 UTC
89f21cc staging: ozwpan: Fix bug where kfree is called twice. Signed-off-by: Rupesh Gujare <rgujare@ozmodevices.com> Signed-off-by: Chris Kelly <ckelly@ozmodevices.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 26 April 2012, 19:40:53 UTC
fa83af7 blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c This file has lots and lots of ifdef, around structure decls and structure usages. The failure issue was that we would build the BF538-EZKIT_defconfig and get: arch/blackfin/mach-bf538/boards/ezkit.c:924:3: error: 'bfin_lq035q1_device' undeclared here (not in a function) even though the same ifdef _appeared_ to enable both the struct declaration and the code that used it. Yet cpp was telling us we didn't have the struct, but we still had the usage of it. However, _appeared_ is the operative word. After marking all the anonymous #endif with their parent #ifdef config options, it was _then_ clear that there was a misplaced #endif that was hiding the struct declaration. The real guts of the patch boils down to this: -#endif +#endif /* CONFIG_MTD_M25P80 */ +#endif /* CONFIG_SPI_BFIN5XX */ [...] -#endif /* spi master and devices */ but since I had to tag the #endif with their respective #ifdef options to find this misplaced SPI endif, it would be silly to then go and delete them all. So they stay. Cc: Sonic Zhang <sonic.zhang@analog.com> Cc: Bob Liu <lliubbo@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 26 April 2012, 18:46:51 UTC
bc856a6 blackfin: fix compile error in bfin-lq035q1-fb.c This file has an implicit dependency on GPIO stuff, showing up as the following build failure: drivers/video/bfin-lq035q1-fb.c:369:6: error: 'GPIOF_OUT_INIT_LOW' undeclared Other more global bfin build issues prevent an automated bisect, but it really doesn't matter - simply add in the appropriate header. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 26 April 2012, 18:46:51 UTC
cd0a2bf pci: frv architecture needs generic setup-bus infrastructure Otherwise we get this link failure for frv's defconfig: LD .tmp_vmlinux1 drivers/built-in.o: In function `pci_assign_resource': (.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment' drivers/built-in.o: In function `pci_setup': pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt' pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt' make[1]: *** [.tmp_vmlinux1] Error 1 Cc: David Howells <dhowells@redhat.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 26 April 2012, 18:46:17 UTC
6651819 drm/i915: handle input/output sdvo timings separately in mode_set We seem to have a decent confusion between the output timings and the input timings of the sdvo encoder. If I understand the code correctly, we use the original mode unchanged for the output timings, safe for the lvds case. And we should use the adjusted mode for input timings. Clarify the situation by adding an explicit output_dtd to the sdvo mode_set function and streamline the code-flow by moving the input and output mode setting in the sdvo encode together. Furthermore testing showed that the sdvo input timing needs the unadjusted dotclock, the sdvo chip will automatically compute the required pixel multiplier to get a dotclock above 100 MHz. Fix this up when converting a drm mode to an sdvo dtd. This regression was introduced in commit c74696b9c890074c1e1ee3d7496fc71eb3680ced Author: Pavel Roskin <proski@gnu.org> Date: Thu Sep 2 14:46:34 2010 -0400 i915: revert some checks added by commit 32aad86f particularly the following hunk: diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 093e914..62d22ae 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder, /* We have tried to get input timing in mode_fixup, and filled into adjusted_mode */ - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) { - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); + if (intel_sdvo->is_tv || intel_sdvo->is_lvds) input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags; - } else - intel_sdvo_get_dtd_from_mode(&input_dtd, mode); /* If it's a TV, we already set the output timing in mode_fixup. * Otherwise, the output timing is equal to the input timing. Due to questions raised in review, below a more elaborate analysis of the bug at hand: Sdvo seems to have two timings, one is the output timing which will be sent over whatever is connected on the other side of the sdvo chip (panel, hdmi screen, tv), the other is the input timing which will be generated by the gmch pipe. It looks like sdvo is expected to scale between the two. To make things slightly more complicated, we have a bunch of special cases: - For lvds panel we always use a fixed output timing, namely intel_sdvo->sdvo_lvds_fixed_mode, hence that special case. - Sdvo has an interface to generate a preferred input timing for a given output timing. This is the confusing thing that I've tried to clear up with the follow-on patches. - A special requirement is that the input pixel clock needs to be between 100MHz and 200MHz (likely to keep it within the electromechanical design range of PCIe), 270MHz on later gen4+. Lower pixel clocks are doubled/quadrupled. The thing this patch tries to fix is that the pipe needs to be explicitly instructed to double/quadruple the pixels and needs the correspondingly higher pixel clock, whereas the sdvo adaptor seems to do that itself and needs the unadjusted pixel clock. For the sdvo encode side we already set the pixel mutliplier with a different command (0x21). This patch tries to fix this mess by: - Keeping the output mode timing in the unadjusted plain mode, safe for the lvds case. - Storing the input timing in the adjusted_mode with the adjusted pixel clock. This way we don't need to frob around with the core crtc mode set code. - Fixing up the pixelclock when constructing the sdvo dtd timing struct. This is why the first hunk of the patch is an integral part of the series. - Dropping the is_tv special case because input_dtd is equivalent to adjusted_mode after these changes. Follow-up patches clear this up further (by simply ripping out intel_sdvo->input_dtd because it's not needed). v2: Extend commit message with an in-depth bug analysis. Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 26 April 2012, 16:56:26 UTC
c3e40a9 hwmon: (fam15h_power) Fix pci_device_id array pci_match_id() takes an *array* of IDs which must be properly zero- terminated. Reported-by: Ben Hutchings <ben@decadent.org.uk> Cc: stable@vger.kernel.org # 3.0+: 00250ec hwmon: fam15h_power: fix bogus values Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Acked-by: Jean Delvare <khali@linux-fr.org> 26 April 2012, 15:40:08 UTC
d08c9a3 hpwdt: Only BYTE reads/writes to WD Timer port 0x72 This patch is to correct the use of the iLO port 0x72 usage. The port 0x72 is a byte size write/read and hpwdt is currently writing a WORD. Signed-off by: Thomas Mingarelli <thomas.mingarelli@hp.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> 26 April 2012, 12:38:07 UTC
724b6da perf: Fix perf_event_for_each() to use sibling In perf_event_for_each() we call a function on an event, and then iterate over the siblings of the event. However we don't call the function on the siblings, we call it repeatedly on the original event - it seems "obvious" that we should be calling it with sibling as the argument. It looks like this broke in commit 75f937f24bd9 ("Fix ctx->mutex vs counter->mutex inversion"). The only effect of the bug is that the PERF_IOC_FLAG_GROUP parameter to the ioctls doesn't work. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1334109253-31329-1-git-send-email-michael@ellerman.id.au Signed-off-by: Ingo Molnar <mingo@kernel.org> 26 April 2012, 11:51:31 UTC
fb2cf2c sched: Fix OOPS when build_sched_domains() percpu allocation fails Under extreme memory used up situations, percpu allocation might fail. We hit it when system goes to suspend-to-ram, causing a kworker panic: EIP: [<c124411a>] build_sched_domains+0x23a/0xad0 Kernel panic - not syncing: Fatal exception Pid: 3026, comm: kworker/u:3 3.0.8-137473-gf42fbef #1 Call Trace: [<c18cc4f2>] panic+0x66/0x16c [...] [<c1244c37>] partition_sched_domains+0x287/0x4b0 [<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210 [<c123712d>] cpuset_cpu_inactive+0x1d/0x30 [...] With this fix applied build_sched_domains() will return -ENOMEM and the suspend attempt fails. Signed-off-by: he, bo <bo.he@intel.com> Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/1335355161.5892.17.camel@hebo [ So, we fail to deallocate a CPU because we cannot allocate RAM :-/ I don't like that kind of sad behavior but nevertheless it should not crash under high memory load. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> 26 April 2012, 10:54:53 UTC
eb95308 sched: Fix more load-balancing fallout Commits 367456c756a6 ("sched: Ditch per cgroup task lists for load-balancing") and 5d6523ebd ("sched: Fix load-balance wreckage") left some more wreckage. By setting loop_max unconditionally to ->nr_running load-balancing could take a lot of time on very long runqueues (hackbench!). So keep the sysctl as max limit of the amount of tasks we'll iterate. Furthermore, the min load filter for migration completely fails with cgroups since inequality in per-cpu state can easily lead to such small loads :/ Furthermore the change to add new tasks to the tail of the queue instead of the head seems to have some effect.. not quite sure I understand why. Combined these fixes solve the huge hackbench regression reported by Tim when hackbench is ran in a cgroup. Reported-by: Tim Chen <tim.c.chen@linux.intel.com> Acked-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/1335365763.28150.267.camel@twins [ got rid of the CONFIG_PREEMPT tuning and made small readability edits ] Signed-off-by: Ingo Molnar <mingo@kernel.org> 26 April 2012, 10:54:52 UTC
2300fd6 Merge tag 'nfs-for-3.4-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client bugfixes from Trond Myklebust: - Fix NFSv4 infinite loops on open(O_TRUNC) - Fix an Oops and an infinite loop in the NFSv4 flock code - Don't register the PipeFS filesystem until it has been set up - Fix an Oops in nfs_try_to_update_request - Don't reuse NFSv4 open owners: fixes a bad sequence id storm. * tag 'nfs-for-3.4-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4: Keep dropped state owners on the LRU list for a while NFSv4: Ensure that we don't drop a state owner more than once NFSv4: Ensure we do not reuse open owner names nfs: Enclose hostname in brackets when needed in nfs_do_root_mount NFS: put open context on error in nfs_flush_multi NFS: put open context on error in nfs_pagein_multi NFSv4: Fix open(O_TRUNC) and ftruncate() error handling NFSv4: Ensure that we check lock exclusive/shared type against open modes NFSv4: Ensure that the LOCK code sets exception->inode NFS: check for req==NULL in nfs_try_to_update_request cleanup SUNRPC: register PipeFS file system after pernet sybsystem 26 April 2012, 04:38:44 UTC
b7b617c Merge branch 'u300-fixes-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into fixes * 'u300-fixes-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson: ARM: u300: bump all IRQ numbers by one ARM: ux300: Fix unimplementable regulation constraints 26 April 2012, 04:31:39 UTC
86ec090 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from H. Peter Anvin. * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x32, siginfo: Provide proper overrides for x32 siginfo_t asm-generic: Allow overriding clock_t and add attributes to siginfo_t x32: Check __ILP32__ instead of __LP64__ for x32 x86, acpi: Call acpi_enter_sleep_state via an asmlinkage C function from assembler ACPI: Convert wake_sleep_flags to a value instead of function x86, apic: APIC code touches invalid MSR on P5 class machines i387: ptrace breaks the lazy-fpu-restore logic x86/platform: Remove incorrect error message in x86_default_fixup_cpu_id() x86, efi: Add dedicated EFI stub entry point x86/amd: Remove broken links from comment and kernel message x86, microcode: Ensure that module is only loaded on supported AMD CPUs x86, microcode: Fix sysfs warning during module unload on unsupported CPUs 26 April 2012, 04:29:26 UTC
bdd4f70 Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86 Pull x86 platform driver fixes from Matthew Garrett: "One annoyance fix (make intel_ips stop complaining unnecessarily) and one oops fix (unterminated list in dell-laptop). Both have been in -next for a while with no complaints." * 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86: dell-laptop: Terminate quirks list properly intel_ips: Hush the i915 symbols message 26 April 2012, 04:28:10 UTC
6e8b09e mm: fix NULL ptr dereference in move_pages Commit 3268c63 ("mm: fix move/migrate_pages() race on task struct") has added an odd construct where 'mm' is checked for being NULL, and if it is, it would get dereferenced anyways by mput()ing it. Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Hugh Dickins <hughd@google.com> Acked-by: Christoph Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
f2a9ef8 mm: fix NULL ptr dereference in migrate_pages Commit 3268c63 ("mm: fix move/migrate_pages() race on task struct") has added an odd construct where 'mm' is checked for being NULL, and if it is, it would get dereferenced anyways by mput()ing it. This would lead to the following NULL ptr deref and BUG() when calling migrate_pages() with a pid that has no mm struct: [25904.193704] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [25904.194235] IP: [<ffffffff810b0de7>] mmput+0x27/0xf0 [25904.194235] PGD 773e6067 PUD 77da0067 PMD 0 [25904.194235] Oops: 0002 [#1] PREEMPT SMP [25904.194235] CPU 2 [25904.194235] Pid: 31608, comm: trinity Tainted: G W 3.4.0-rc2-next-20120412-sasha #69 [25904.194235] RIP: 0010:[<ffffffff810b0de7>] [<ffffffff810b0de7>] mmput+0x27/0xf0 [25904.194235] RSP: 0018:ffff880077d49e08 EFLAGS: 00010202 [25904.194235] RAX: 0000000000000286 RBX: 0000000000000000 RCX: 0000000000000000 [25904.194235] RDX: ffff880075ef8000 RSI: 000000000000023d RDI: 0000000000000286 [25904.194235] RBP: ffff880077d49e18 R08: 0000000000000001 R09: 0000000000000001 [25904.194235] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [25904.194235] R13: 00000000ffffffea R14: ffff880034287740 R15: ffff8800218d3010 [25904.194235] FS: 00007fc8b244c700(0000) GS:ffff880029800000(0000) knlGS:0000000000000000 [25904.194235] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [25904.194235] CR2: 0000000000000050 CR3: 00000000767c6000 CR4: 00000000000406e0 [25904.194235] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [25904.194235] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [25904.194235] Process trinity (pid: 31608, threadinfo ffff880077d48000, task ffff880075ef8000) [25904.194235] Stack: [25904.194235] ffff8800342876c0 0000000000000000 ffff880077d49f78 ffffffff811b8020 [25904.194235] ffffffff811b7d91 ffff880075ef8000 ffff88002256d200 0000000000000000 [25904.194235] 00000000000003ff 0000000000000000 0000000000000000 0000000000000000 [25904.194235] Call Trace: [25904.194235] [<ffffffff811b8020>] sys_migrate_pages+0x340/0x3a0 [25904.194235] [<ffffffff811b7d91>] ? sys_migrate_pages+0xb1/0x3a0 [25904.194235] [<ffffffff8266cbb9>] system_call_fastpath+0x16/0x1b [25904.194235] Code: c9 c3 66 90 55 31 d2 48 89 e5 be 3d 02 00 00 48 83 ec 10 48 89 1c 24 4c 89 64 24 08 48 89 fb 48 c7 c7 cf 0e e1 82 e8 69 18 03 00 <f0> ff 4b 50 0f 94 c0 84 c0 0f 84 aa 00 00 00 48 89 df e8 72 f1 [25904.194235] RIP [<ffffffff810b0de7>] mmput+0x27/0xf0 [25904.194235] RSP <ffff880077d49e08> [25904.194235] CR2: 0000000000000050 [25904.348999] ---[ end trace a307b3ed40206b4b ]--- Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Hugh Dickins <hughd@google.com> Cc: Christoph Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
63f61a6 revert "proc: clear_refs: do not clear reserved pages" Revert commit 85e72aa5384 ("proc: clear_refs: do not clear reserved pages"), which was a quick fix suitable for -stable until ARM had been moved over to the gate_vma mechanism: https://lkml.org/lkml/2012/1/14/55 With commit f9d4861f ("ARM: 7294/1: vectors: use gate_vma for vectors user mapping"), ARM does now use the gate_vma, so the PageReserved check can be removed from the proc code. Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Nicolas Pitre <nico@linaro.org> Acked-by: Hugh Dickins <hughd@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
3f5ec5e drivers/rtc/rtc-ds1307.c: fix BUG shown with lock debugging enabled Add struct bin_attribute initialization to fix the following bug: rtc-ds1307 3-0068: rtc core: registered ds1307 as rtc0 BUG: key cfb14fcc not in .data! ------------[ cut here ]------------ WARNING: at kernel/lockdep.c:2986 sysfs_add_file_mode+0x84/0xdc() Modules linked in: [<c0018d94>] (unwind_backtrace+0x0/0xf8) from [<c0031f7c>] (warn_slowpath_common+0x4c/0x64) [<c0031f7c>] (warn_slowpath_common+0x4c/0x64) from [<c0031fb0>] (warn_slowpath_null+0x1c/0x24) [<c0031fb0>] (warn_slowpath_null+0x1c/0x24) from [<c012f7ac>] (sysfs_add_file_mode+0x84/0xdc) [<c012f7ac>] (sysfs_add_file_mode+0x84/0xdc) from [<c04b11e4>] (ds1307_probe+0x5e4/0x6ac) [<c04b11e4>] (ds1307_probe+0x5e4/0x6ac) from [<c036e600>] (i2c_device_probe+0xdc/0x108) [<c036e600>] (i2c_device_probe+0xdc/0x108) from [<c02cdf84>] (driver_probe_device+0x90/0x210) [<c02cdf84>] (driver_probe_device+0x90/0x210) from [<c02ce198>] (__driver_attach+0x94/0x98) [<c02ce198>] (__driver_attach+0x94/0x98) from [<c02cc824>] (bus_for_each_dev+0x50/0x7c) [<c02cc824>] (bus_for_each_dev+0x50/0x7c) from [<c02cd780>] (bus_add_driver+0x184/0x244) [<c02cd780>] (bus_add_driver+0x184/0x244) from [<c02ce43c>] (driver_register+0x78/0x12c) [<c02ce43c>] (driver_register+0x78/0x12c) from [<c03701ac>] (i2c_register_driver+0x2c/0xb4) [<c03701ac>] (i2c_register_driver+0x2c/0xb4) from [<c0008798>] (do_one_initcall+0x34/0x178) [<c0008798>] (do_one_initcall+0x34/0x178) from [<c0691860>] (kernel_init+0xdc/0x194) [<c0691860>] (kernel_init+0xdc/0x194) from [<c0013cf0>] (kernel_thread_exit+0x0/0x8) Since commit 6992f5334995af4 ("sysfs: Use one lockdep class per sysfs attribute") this initialization is required. Reported-by: Stefano Babic <sbabic@denx.de> Tested-by: Stefano Babic <sbabic@denx.de> Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Stefano Babic <sbabic@denx.de> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
db7b122 arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file Don't allow everybody to use a modem. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
65ed760 hugetlbfs: lockdep annotate root inode properly This fixes the below reported false lockdep warning. e096d0c7e2e4 ("lockdep: Add helper function for dir vs file i_mutex annotation") added a similar annotation for every other inode in hugetlbfs but missed the root inode because it was allocated by a separate function. For HugeTLB fs we allow taking i_mutex in mmap. HugeTLB fs doesn't support file write and its file read callback is modified in a05b0855fd ("hugetlbfs: avoid taking i_mutex from hugetlbfs_read()") to not take i_mutex. Hence for HugeTLB fs with regular files we really don't take i_mutex with mmap_sem held. ====================================================== [ INFO: possible circular locking dependency detected ] 3.4.0-rc1+ #322 Not tainted ------------------------------------------------------- bash/1572 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<ffffffff810f1618>] might_fault+0x40/0x90 but task is already holding lock: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [<ffffffff81125f88>] vfs_readdir+0x56/0xa8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#12){+.+.+.}: [<ffffffff810a09e5>] lock_acquire+0xd5/0xfa [<ffffffff816a2f5e>] __mutex_lock_common+0x48/0x350 [<ffffffff816a3325>] mutex_lock_nested+0x2a/0x31 [<ffffffff811fb8e1>] hugetlbfs_file_mmap+0x7d/0x104 [<ffffffff810f859a>] mmap_region+0x272/0x47d [<ffffffff810f8a39>] do_mmap_pgoff+0x294/0x2ee [<ffffffff810f8b65>] sys_mmap_pgoff+0xd2/0x10e [<ffffffff8103d19e>] sys_mmap+0x1d/0x1f [<ffffffff816a5922>] system_call_fastpath+0x16/0x1b -> #0 (&mm->mmap_sem){++++++}: [<ffffffff810a0256>] __lock_acquire+0xa81/0xd75 [<ffffffff810a09e5>] lock_acquire+0xd5/0xfa [<ffffffff810f1645>] might_fault+0x6d/0x90 [<ffffffff81125d62>] filldir+0x6a/0xc2 [<ffffffff81133a83>] dcache_readdir+0x5c/0x222 [<ffffffff81125fa8>] vfs_readdir+0x76/0xa8 [<ffffffff811260b6>] sys_getdents+0x79/0xc9 [<ffffffff816a5922>] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sb->s_type->i_mutex_key#12); lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#12); lock(&mm->mmap_sem); *** DEADLOCK *** 1 lock held by bash/1572: #0: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [<ffffffff81125f88>] vfs_readdir+0x56/0xa8 stack backtrace: Pid: 1572, comm: bash Not tainted 3.4.0-rc1+ #322 Call Trace: [<ffffffff81699a3c>] print_circular_bug+0x1f8/0x209 [<ffffffff810a0256>] __lock_acquire+0xa81/0xd75 [<ffffffff810f38aa>] ? handle_pte_fault+0x5ff/0x614 [<ffffffff8109e622>] ? mark_lock+0x2d/0x258 [<ffffffff810f1618>] ? might_fault+0x40/0x90 [<ffffffff810a09e5>] lock_acquire+0xd5/0xfa [<ffffffff810f1618>] ? might_fault+0x40/0x90 [<ffffffff816a3249>] ? __mutex_lock_common+0x333/0x350 [<ffffffff810f1645>] might_fault+0x6d/0x90 [<ffffffff810f1618>] ? might_fault+0x40/0x90 [<ffffffff81125d62>] filldir+0x6a/0xc2 [<ffffffff81133a83>] dcache_readdir+0x5c/0x222 [<ffffffff81125cf8>] ? sys_ioctl+0x74/0x74 [<ffffffff81125cf8>] ? sys_ioctl+0x74/0x74 [<ffffffff81125cf8>] ? sys_ioctl+0x74/0x74 [<ffffffff81125fa8>] vfs_readdir+0x76/0xa8 [<ffffffff811260b6>] sys_getdents+0x79/0xc9 [<ffffffff816a5922>] system_call_fastpath+0x16/0x1b Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Dave Jones <davej@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
351963b acerhdf: lowered default temp fanon/fanoff values Due to new supported hardware, of which the actual temperature limits of processor, harddisk and other components are unknown, it feels safer with lower fanon / fanoff settings. It won't change much for most people, already using acerhdf, as they use their own fanon/fanoff variable settings when loading the module. Furthermore seems like kernel and userspace tools have been improved to work more efficient and netbooks don't get so hot anymore. Signed-off-by: Peter Feuerer <peter@piie.net> Acked-by: Borislav Petkov <petkovbb@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:34 UTC
43ae1e3 acerhdf: add support for new hardware Add support for new hardware: Acer Aspire LT-10Q/531/751/1810/1825, Acer Travelmate 7730, Packard Bell ENBFT/DOTVR46 Signed-off-by: Peter Feuerer <peter@piie.net> Acked-by: Borislav Petkov <petkovbb@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:33 UTC
e39a9ba acerhdf: add support for Aspire 1410 BIOS v1.3314 Add support for Aspire 1410 BIOS v1.3314. Fixes the following error: acerhdf: unknown (unsupported) BIOS version Acer/Aspire 1410/v1.3314, please report, aborting! Signed-off-by: Clay Carpenter <claycarpenter@gmail.com> Signed-off-by: Peter Feuerer <peter@piie.net> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:33 UTC
61065a3 fs/buffer.c: remove BUG() in possible but rare condition While stressing the kernel with with failing allocations today, I hit the following chain of events: alloc_page_buffers(): bh = alloc_buffer_head(GFP_NOFS); if (!bh) goto no_grow; <= path taken grow_dev_page(): bh = alloc_page_buffers(page, size, 0); if (!bh) goto failed; <= taken, consequence of the above and then the failed path BUG()s the kernel. The failure is inserted a litte bit artificially, but even then, I see no reason why it should be deemed impossible in a real box. Even though this is not a condition that we expect to see around every time, failed allocations are expected to be handled, and BUG() sounds just too much. As a matter of fact, grow_dev_page() can return NULL just fine in other circumstances, so I propose we just remove it, then. Signed-off-by: Glauber Costa <glommer@parallels.com> Cc: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:33 UTC
904249a mm: fix up the vmscan stat in vmstat The "pgsteal" stat is confusing because it counts both direct reclaim as well as background reclaim. However, we have "kswapd_steal" which also counts background reclaim value. This patch fixes it and also makes it match the existng "pgscan_" stats. Test: pgsteal_kswapd_dma32 447623 pgsteal_kswapd_normal 42272677 pgsteal_kswapd_movable 0 pgsteal_direct_dma32 2801 pgsteal_direct_normal 44353270 pgsteal_direct_movable 0 Signed-off-by: Ying Han <yinghan@google.com> Reviewed-by: Rik van Riel <riel@redhat.com> Acked-by: Christoph Lameter <cl@linux.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Mel Gorman <mel@csn.ul.ie> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Hillf Danton <dhillf@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Dan Magenheimer <dan.magenheimer@oracle.com> Reviewed-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:33 UTC
13d5180 epoll: clear the tfile_check_list on -ELOOP An epoll_ctl(,EPOLL_CTL_ADD,,) operation can return '-ELOOP' to prevent circular epoll dependencies from being created. However, in that case we do not properly clear the 'tfile_check_list'. Thus, add a call to clear_tfile_check_list() for the -ELOOP case. Signed-off-by: Jason Baron <jbaron@redhat.com> Reported-by: Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru> Cc: Nelson Elhage <nelhage@nelhage.com> Cc: Davide Libenzi <davidel@xmailserver.org> Tested-by: Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 April 2012, 04:26:33 UTC
back to top