- 29 Oct, 2010 16 commits
-
-
Jeremy Fitzhardinge authored
commit 9ecd4e16 upstream. When using a paravirt clock, pvclock.c can be used by sched_clock(), which in turn is used by the tracing mechanism for timestamps, which leads to infinite recursion. Disable mcount/tracing for pvclock.o. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> LKML-Reference: <4C9A9A3F.4040201@goop.org> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Joerg Roedel authored
commit 4c894f47 upstream. This patch adds a workaround for an IOMMU BIOS problem to the AMD IOMMU driver. The result of the bug is that the IOMMU does not execute commands anymore when the system comes out of the S3 state resulting in system failure. The bug in the BIOS is that is does not restore certain hardware specific registers correctly. This workaround reads out the contents of these registers at boot time and restores them on resume from S3. The workaround is limited to the specific IOMMU chipset where this problem occurs. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Joerg Roedel authored
commit 04e0463e upstream. In the __unmap_single function the dma_addr is rounded down to a page boundary before the dma pages are unmapped. The address is later also used to flush the TLB entries for that mapping. But without the offset into the dma page the amount of pages to flush might be miscalculated in the TLB flushing path. This patch fixes this bug by using the original address to flush the TLB. Signed-off-by:
-
Joerg Roedel authored
commit e9bf5197 upstream. This patch moves the setting of the configuration and feature flags out out the acpi table parsing path and moves it into the iommu-enable path. This is needed to reliably fix resume-from-s3. Signed-off-by:
-
Marek Szyprowski authored
commit 9320f7cb upstream. If not all clocks have been defined in platform data, the driver will cause a null pointer dereference when it is removed. This patch fixes this issue. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Steve Wise authored
commit bec658ff upstream. The HW by default has RX coalescing on. For iWARP connections, this causes a 100ms delay in connection establishement due to the ingress MPA Start message being stalled in HW. So explicitly turn RX coalescing off when setting up iWARP connections. This was causing very bad performance for NP64 gather operations using Open MPI, due to the way it sets up connections on larger jobs. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Jiri Olsa authored
commit bb7ab785 upstream. This patch adds CPU type detection for dunnington processor (Family 6 / Model 29) to be identified as core 2 family cpu type (wikipedia source). I tested oprofile on Intel(R) Xeon(R) CPU E7440 reporting itself as model 29, and it runs without an issue. Spec: http://www.intel.com/Assets/en_US/PDF/specupdate/320336.pdfSigned-off-by:
Jiri Olsa <jolsa@redhat.com> Acked-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Sergei Shtylyov authored
commit a666e3e6 upstream. Commit 46034dca (USB: musb_gadget_ep0: stop abusing musb_gadget_set_halt()) forgot to restart a queued request after clearing the endpoint halt feature. This results in a couple of USB resets while enumerating the file-backed storage gadget due to CSW packet not being sent for the MODE SENSE(10) command. Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Ming Lei authored
commit bd2e74d6 upstream. For shared fifo hw endpoint(with FIFO_TXRX style), only ep_in field of musb_hw_ep is intialized in musb_g_init_endpoints, and ep_out is not initialized, but musb_g_rx and rxstate may access ep_out field of musb_hw_ep by the method below: musb_ep = &musb->endpoints[epnum].ep_out which can cause the kernel panic[1] below, this patch fixes the issue by getting 'musb_ep' from '&musb->endpoints[epnum].ep_in' for shared fifo endpoint. [1], kernel panic [root@OMAP3EVM /]# musb_interrupt 1583: ** IRQ peripheral usb0008 tx0000 rx4000 musb_stage0_irq 460: <== Power=f0, DevCtl=99, int_usb=0x8 musb_g_rx 772: <== (null), rxcsr 4007 ffffffe8 musb_g_rx 786: iso overrun on ffffffe8 Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c0004000 [00000008] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/platform/musb_hdrc/usb1/usb_device/usbdev1.1/dev Modules linked in: g_zero CPU: 0 Tainted: G W (2.6.35-rc6-gkh-wl+ #92) PC is at musb_g_rx+0xfc/0x2ec LR is at vprintk+0x3f4/0x458 pc : [<c02c07a4>] lr : [<c006ccb0>] psr: 20000193 sp : c760bd78 ip : c03c9d70 fp : c760bdbc r10: 00000000 r9 : fa0ab1e0 r8 : 0000000e r7 : c7e80158 r6 : ffffffe8 r5 : 00000001 r4 : 00004003 r3 : 00010003 r2 : c760bcd8 r1 : c03cd030 r0 : 0000002e Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8778c019 DAC: 00000017 Process kmemleak (pid: 421, stack limit = 0xc760a2e8) Stack: (0xc760bd78 to 0xc760c000) bd60: ffffffe8 c04b1b58 bd80: ffffffe8 c7c01ac0 00000000 c7e80d24 c0084238 00000001 00000001 c7e80158 bda0: 0000000e 00000008 00000099 000000f0 c760be04 c760bdc0 c02bcd68 c02c06b4 bdc0: 00000099 00000008 00004000 c760bdd8 c03cc4f8 00000000 00000002 c7e80158 bde0: c7d2e300 60000193 c760a000 0000005c 00000000 00000000 c760be24 c760be08 be00: c02bcecc c02bc1ac c7d2e300 c7d2e300 0000005c c760a000 c760be54 c760be28 be20: c00ad698 c02bce6c 00000000 c7d2e300 c067c258 0000005c c067c294 00000001 be40: c760a000 00000000 c760be74 c760be58 c00af984 c00ad5fc 0000005c 00000000 be60: 00000000 00000002 c760be8c c760be78 c0039080 c00af8d0 ffffffff fa200000 be80: c760beec c760be90 c0039b6c c003900c 00000001 00000000 c7d1e240 00000000 bea0: 00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff 00000000 c068bae8 bee0: c760bf24 c760bef0 c00ff7d0 c0064ec4 00000001 00000000 c00ff700 00000000 bf00: c0087f00 00000000 60000013 c0d76a70 c0e23795 00000001 c760bf4c c760bf28 bf20: c00ffdd8 c00ff70c c068bb08 c068bae8 60000013 c0100938 c068bb30 00000000 bf40: c760bf84 c760bf50 c010014c c00ffd84 00000001 00000000 c010000c 00012c00 bf60: c7c33f04 00012c00 c7c33f04 00000000 c0100938 00000000 c760bf9c c760bf88 bf80: c01009a8 c0100018 c760bfa8 c7c33f04 c760bff4 c760bfa0 c0088000 c0100944 bfa0: c760bf98 00000000 00000000 00000001 dead4ead ffffffff ffffffff c08ba2bc bfc0: 00000000 c049e7fa 00000000 c0087f70 c760bfd0 c760bfd0 c7c33f04 c0087f70 bfe0: c006f5e8 00000013 00000000 c760bff8 c006f5e8 c0087f7c 7f0004ff df2000ff Backtrace: [<c02c06a8>] (musb_g_rx+0x0/0x2ec) from [<c02bcd68>] (musb_interrupt+0xbc8/0xcc0) [<c02bc1a0>] (musb_interrupt+0x0/0xcc0) from [<c02bcecc>] (generic_interrupt+0x6c/0x84) [<c02bce60>] (generic_interrupt+0x0/0x84) from [<c00ad698>] (handle_IRQ_event+0xa8/0x1ec) r7:c760a000 r6:0000005c r5:c7d2e300 r4:c7d2e300 [<c00ad5f0>] (handle_IRQ_event+0x0/0x1ec) from [<c00af984>] (handle_level_irq+0xc0/0x13c) [<c00af8c4>] (handle_level_irq+0x0/0x13c) from [<c0039080>] (asm_do_IRQ+0x80/0xa0) r7:00000002 r6:00000000 r5:00000000 r4:0000005c [<c0039000>] (asm_do_IRQ+0x0/0xa0) from [<c0039b6c>] (__irq_svc+0x4c/0xb4) Exception stack(0xc760be90 to 0xc760bed8) be80: 00000001 00000000 c7d1e240 00000000 bea0: 00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff r5:fa200000 r4:ffffffff [<c0064eb8>] (sub_preempt_count+0x0/0x100) from [<c00ff7d0>] (find_and_get_object+0xd0/0x110) r5:c068bae8 r4:00000000 [<c00ff700>] (find_and_get_object+0x0/0x110) from [<c00ffdd8>] (scan_block+0x60/0x104) r8:00000001 r7:c0e23795 r6:c0d76a70 r5:60000013 r4:00000000 [<c00ffd78>] (scan_block+0x0/0x104) from [<c010014c>] (kmemleak_scan+0x140/0x484) [<c010000c>] (kmemleak_scan+0x0/0x484) from [<c01009a8>] (kmemleak_scan_thread+0x70/0xcc) r8:00000000 r7:c0100938 r6:00000000 r5:c7c33f04 r4:00012c00 [<c0100938>] (kmemleak_scan_thread+0x0/0xcc) from [<c0088000>] (kthread+0x90/0x98) r5:c7c33f04 r4:c760bfa8 [<c0087f70>] (kthread+0x0/0x98) from [<c006f5e8>] (do_exit+0x0/0x684) r7:00000013 r6:c006f5e8 r5:c0087f70 r4:c7c33f04 Code: e3002312 e58d6000 e2833e16 eb0422d5 (e5963020) ---[ end trace f3d5e96f75c297b7 ]--- Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Reviewed-by:
Sergei Shtylyov <sshtylyov@mvista.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Anand Gadiyar <gadiyar@ti.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Alan Stern authored
commit 0026e005 upstream. Recent changes in the usbhid layer exposed a bug in usbcore. If CONFIG_USB_DYNAMIC_MINORS is enabled then an interface may be assigned a minor number of 0. However interfaces that aren't registered as USB class devices also have their minor number set to 0, during initialization. As a result usb_find_interface() may return the wrong interface, leading to a crash. This patch (as1418) fixes the problem by initializing every interface's minor number to -1. It also cleans up the usb_register_dev() function, which besides being somewhat awkwardly written, does not unwind completely on all its error paths. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Philip J. Turmel <philip@turmel.org> Tested-by:
Gabriel Craciunescu <nix.or.die@googlemail.com> Tested-by:
Alex Riesen <raa.lkml@gmail.com> Tested-by:
Matthias Bayer <jackdachef@gmail.com> CC: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Clemens Ladisch authored
commit aa73aec6 upstream. When a driver module is unloaded and the last still open file is a raw MIDI device, the card and its devices will be actually freed in the snd_card_file_remove() call when that file is closed. Afterwards, rmidi and rmidi->card point into freed memory, so the module pointer is likely to be garbage. (This was introduced by commit 9a1b64ca.) Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Reported-by:
Krzysztof Foltman <wdev@foltman.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Dan Rosenberg authored
commit 5591bf07 upstream. The snd_ctl_new() function in sound/core/control.c allocates space for a snd_kcontrol struct by performing arithmetic operations on a user-provided size without checking for integer overflow. If a user provides a large enough size, an overflow will occur, the allocated chunk will be too small, and a second user-influenced value will be written repeatedly past the bounds of this chunk. This code is reachable by unprivileged users who have permission to open a /dev/snd/controlC* device (on many distros, this is group "audio") via the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
-
Luke Yelavich authored
commit 0f9f1ee9 upstream. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/643891 Set the Dell Latitude E6400 (1028:0233) SSID to use AD1984_DELL_DESKTOP Signed-off-by:
Luke Yelavich <luke.yelavich@canonical.com> Signed-off-by:
-
Erik J. Staab authored
commit 0873a5ae upstream. On the HT-Omega Claro halo card, the ADC data must be captured from the second I2S input. Using the default first input, which isn't connected to anything, would result in silence. Signed-off-by:
Erik J. Staab <ejs@insightbb.com> Signed-off-by:
-
Dan Rosenberg authored
commit e68d3b31 upstream. The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow unprivileged users to read uninitialized kernel stack memory, because several fields of the hdsp{m}_config_info structs declared on the stack are not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Signed-off-by:
-
H. Peter Anvin authored
commit d900329e upstream. After uncapping the CPUID level, we need to also re-run the CPU feature detection code. This resolves kernel bugzilla 16322. Reported-by:
boris64 <bugzilla.kernel.org@boris64.net> LKML-Reference: <tip-@git.kernel.org> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
- 01 Oct, 2010 2 commits
-
-
Greg Kroah-Hartman authored
-
James Dingwall authored
Correctly name the irq_chip structure to fix an immediate failure when booting as a xen pv_ops guest with a NULL pointer exception. The missing 'x' was introduced in commit [fb412a17] applied to 2.6.3[25]-stable trees. The commit to mainline was [aaca4964] which did not have the problem. Signed-off-by:
James Dingwall <james@dingwall.me.uk> Reported-by:
Pawel Zuzelski <pawelz@pld-linux.org> Tested-by:
-
- 27 Sep, 2010 22 commits
-
-
Greg Kroah-Hartman authored
-
H. Peter Anvin authored
commit 113fc5a6 upstream. [ Backport to .32 by Tomáš Janoušek <tomi@nomi.cz> ] xchg() and cmpxchg() modify their memory operands, not merely read them. For some versions of gcc the "memory" clobber has apparently dealt with the situation, but not for all. Originally-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: Glauber Costa <glommer@redhat.com> Cc: Avi Kivity <avi@redhat.com> Cc: Peter Palfrader <peter@palfrader.org> Cc: Greg KH <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Zachary Amsden <zamsden@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> LKML-Reference: <4C4F7277.8050306@zytor.com> Signed-off-by:
-
Michael Cree authored
commit 3e073367 upstream. When compiling alpha generic build get errors such as: arch/alpha/kernel/err_marvel.c: In function ‘marvel_print_err_cyc’: arch/alpha/kernel/err_marvel.c:119: error: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘u64’ Replaced a number of %ld format specifiers with %lld since u64 is unsigned long long. Signed-off-by:
Michael Cree <mcree@orcon.net.nz> Signed-off-by:
Matt Turner <mattst88@gmail.com> Signed-off-by:
-
Ben Hutchings authored
commit d831692a upstream. SIS 760 is listed in the device tables for both amd64-agp and sis-agp. amd64-agp is apparently preferable since it has workarounds for some BIOS misconfigurations that sis-agp doesn't handle. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ralf Baechle authored
commit 3d45285d upstream. The M3 workaround needs to cmpare the region and VPN2 fields only. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit 750e519d upstream. PDC2026x chipsets need the same treatment as PDC20246 one. This is completely untested but will hopefully fix UDMA issues that people have been reporting against pata_pdc202xx_old for the last couple of years. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit a75032e8 upstream. On Monday 04 January 2010 02:30:24 pm Russell King wrote: > Found the problem - getting rid of the read of the alt status register > after the command has been written fixes the UDMA CRC errors on write: > > @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct > ata_taskfile *tf) > DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command); > > iowrite8(tf->command, ap->ioaddr.command_addr); > - ata_sff_pause(ap); > + ndelay(400); > +// ata_sff_pause(ap); > } > EXPORT_SYMBOL_GPL(ata_sff_exec_command); > > > This rather makes sense. The PDC20247 handles the UDMA part of the > protocol. It has no way to tell the PDC20246 to wait while it suspends > UDMA, so that a normal register access can take place - the 246 ploughs > on with the register access without any regard to the state of the 247. > > If the drive immediately starts the UDMA protocol after a write to the > command register (as it probably will for the DMA WRITE command), then > we'll be accessing the taskfile in the middle of the UDMA setup, which > can't be good. It's certainly a violation of the ATA specs. Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets. Debugged-by:
Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Ralf Baechle authored
commit 5808184f upstream. This is needed for the fix of the M3 workaround. Signed-off-by:
-
Ben Hutchings authored
commit 8faf2e6c upstream. Several MIPS platforms don't set pci_controller::io_map_base for their PCI bridges. This results in a panic in pci_iomap(). (The panic is conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI MIPS systems.) Signed-off-by:
-
David Daney authored
commit f2a68272 upstream. For 64-bit, we must use DADDU and DSUBU. Signed-off-by:
David Daney <ddaney@caviumnetworks.com> To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/1483/Signed-off-by:
-
Dmitry Torokhov authored
commit 15e184af upstream. Input core displays capabilities bitmasks in form of one or more longs printed in hex form and separated by spaces. Unfortunately it does not work well for 32-bit applications running on 64-bit kernels since applications expect that number is "worth" only 32 bits when kernel advances by 64 bits. Fix that by ensuring that output produced for compat tasks uses 32-bit units. Reported-and-tested-by:
Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Eric Paris authored
commit ff311008 upstream. During the large inotify rewrite to fsnotify I completely dropped support for IN_ONESHOT. Reimplement that support. Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
John W. Linville authored
commit 0f4da2d7 upstream. "hostap: Protect against initialization interrupt" (which reinstated "wireless: hostap, fix oops due to early probing interrupt") reintroduced Bug 16111. This is because hostap_pci wasn't setting dev->base_addr, which is now checked in prism2_interrupt. As a result, initialization was failing for PCI-based hostap devices. This corrects that oversight. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Herbert Xu authored
commit 622e0ca1 upstream. When GRO produces fraglist entries, and the resulting skb hits an interface that is incapable of TSO but capable of FRAGLIST, we end up producing a bogus packet with gso_size non-zero. This was reported in the field with older versions of KVM that did not set the TSO bits on tuntap. This patch fixes that. Reported-by:
Igor Zhang <yugzhang@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Aurelien Jarno authored
commit 66f49121 upstream. Since commit 98962465 ("nohz: Prevent clocksource wrapping during idle"), the CPU of an R2D board never goes to idle. This commit assumes that mult and shift are assigned before the clocksource is registered. As a consequence the safe maximum sleep time is negative and the CPU never goes into idle. This patch fixes the problem by moving mult and shift initialization from sh_tmu_clocksource_enable() to sh_tmu_register_clocksource(). Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Peter Oberparleiter authored
commit cffab6bc upstream. Partition boundary calculation fails for DASD FBA disks under the following conditions: - disk is formatted with CMS FORMAT with a blocksize of more than 512 bytes - all of the disk is reserved to a single CMS file using CMS RESERVE - the disk is accessed using the DIAG mode of the DASD driver Under these circumstances, the partition detection code tries to read the CMS label block containing partition-relevant information from logical block offset 1, while it is in fact located at physical block offset 1. Fix this problem by using the correct CMS label block location depending on the device type as determined by the DASD SENSE ID information. Signed-off-by:
Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> [bwh: Adjust for 2.6.32] Signed-off-by:
-
Jussi Kivilinna authored
commit 7f29a3ba upstream. Setting new MAC address only worked when device was set to promiscuous mode. Fix MAC address by writing new address to device using undocumented command AX_CMD_READ_NODE_ID+1. Patch is tested with AX88772 device. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by:
David Hollis <dhollis@davehollis.com> Signed-off-by:
-
Ben Hutchings authored
commit b0cf4dfb upstream. The driver attempts to select an IRQ for the NIC automatically by testing which of the supported IRQs are available and then probing each available IRQ with probe_irq_{on,off}(). There are obvious race conditions here, besides which: 1. The test for availability is done by passing a NULL handler, which now always returns -EINVAL, thus the device cannot be opened: <http://bugs.debian.org/566522> 2. probe_irq_off() will report only the first ISA IRQ handled, potentially leading to a false negative. There was another bug that meant it ignored all error codes from request_irq() except -EBUSY, so it would 'succeed' despite this (possibly causing conflicts with other ISA devices). This was fixed by ab08999d 'WARNING: some request_irq() failures ignored in el2_open()', which exposed bug 1. This patch: 1. Replaces the use of probe_irq_{on,off}() with a real interrupt handler 2. Adds a delay before checking the interrupt-seen flag 3. Disables interrupts on all failure paths 4. Distinguishes error codes from the second request_irq() call, consistently with the first Compile-tested only. Signed-off-by:
-
Vlad Yasevich authored
commit 4bdab433 upstream. sctp_packet_config() is called when getting the packet ready for appending of chunks. The function should not touch the current state, since it's possible to ping-pong between two transports when sending, and that can result packet corruption followed by skb overlfow crash. Reported-by:
Thomas Dreibholz <dreibh@iem.uni-due.de> Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
-
Daniel J Blueman authored
commit f362b732 upstream. Using a program like the following: #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> int main() { id_t id; siginfo_t infop; pid_t res; id = fork(); if (id == 0) { sleep(1); exit(0); } kill(id, SIGSTOP); alarm(1); waitid(P_PID, id, &infop, WCONTINUED); return 0; } to call waitid() on a stopped process results in access to the child task's credentials without the RCU read lock being held - which may be replaced in the meantime - eliciting the following warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/exit.c:1460 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by waitid02/22252: #0: (tasklist_lock){.?.?..}, at: [<ffffffff81061ce5>] do_wait+0xc5/0x310 #1: (&(&sighand->siglock)->rlock){-.-...}, at: [<ffffffff810611da>] wait_consider_task+0x19a/0xbe0 stack backtrace: Pid: 22252, comm: waitid02 Not tainted 2.6.35-323cd+ #3 Call Trace: [<ffffffff81095da4>] lockdep_rcu_dereference+0xa4/0xc0 [<ffffffff81061b31>] wait_consider_task+0xaf1/0xbe0 [<ffffffff81061d15>] do_wait+0xf5/0x310 [<ffffffff810620b6>] sys_waitid+0x86/0x1f0 [<ffffffff8105fce0>] ? child_wait_callback+0x0/0x70 [<ffffffff81003282>] system_call_fastpath+0x16/0x1b This is fixed by holding the RCU read lock in wait_task_continued() to ensure that the task's current credentials aren't destroyed between us reading the cred pointer and us reading the UID from those credentials. Furthermore, protect wait_task_stopped() in the same way. We don't need to keep holding the RCU read lock once we've read the UID from the credentials as holding the RCU read lock doesn't stop the target task from changing its creds under us - so the credentials may be outdated immediately after we've read the pointer, lock or no lock. Signed-off-by:
Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Luck, Tony authored
commit 8ca3eb08 upstream. pa-risc and ia64 have stacks that grow upwards. Check that they do not run into other mappings. By making VM_GROWSUP 0x0 on architectures that do not ever use it, we can avoid some unpleasant #ifdefs in check_stack_guard_page(). Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Mel Gorman authored
commit 72853e29 upstream. When allocating a page, the system uses NR_FREE_PAGES counters to determine if watermarks would remain intact after the allocation was made. This check is made without interrupts disabled or the zone lock held and so is race-prone by nature. Unfortunately, when pages are being freed in batch, the counters are updated before the pages are added on the list. During this window, the counters are misleading as the pages do not exist yet. When under significant pressure on systems with large numbers of CPUs, it's possible for processes to make progress even though they should have been stalled. This is particularly problematic if a number of the processes are using GFP_ATOMIC as the min watermark can be accidentally breached and in extreme cases, the system can livelock. This patch updates the counters after the pages have been added to the list. This makes the allocator more cautious with respect to preserving the watermarks and mitigates livelock possibilities. [akpm@linux-foundation.org: avoid modifying incoming args] Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Reviewed-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Christoph Lameter <cl@linux.com> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
