- 24 Mar, 2008 28 commits
-
-
James Bottomley authored
commit: ff83efac The spinlock is held over too large a region: pscratch is a permanent address (it's allocated at boot time and never changes). All you need the smp lock for is mediating the scratch in use flag, so fix this by moving the spinlock into the case where we set the pscratch_busy flag to false. Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit: 2b28a472 This fixes a bug that can't handle a passthru command with more than two sg entries. Big thanks to Tim Pepper for debugging the problem. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
Mark Salyzyn <Mark_Salyzyn@adaptec.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
This patch (as1038) fixes a bug in usb_stor_access_xfer_buf() and usb_stor_set_xfer_buf() (the bug was originally found by Boaz Harrosh): The routine must not attempt to write beyond the end of a scatter-gather list or beyond the number of bytes requested. This is the minimal 2.6.24 equivalent to as1035 + as1037 (7084191d "USB: usb-storage: don't access beyond the end of the sg buffer" + 6d512a80 "usb-storage: update earlier scatter-gather bug fix"). Mark Glines has confirmed that it fixes his problem. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Cc: Mark Glines <mark@glines.org> Cc: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Miklos Szeredi authored
[upstream commit 1a823ac9 ] I added a nasty local variable shadowing bug to fuse in 2.6.24, with the result, that the 'default_permissions' mount option is basically ignored. How did this happen? - old err declaration in inner scope - new err getting declared in outer scope - 'return err' from inner scope getting removed - old declaration not being noticed -Wshadow would have saved us, but it doesn't seem practical for the kernel :( More testing would have also saved us :(( Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sebastian Siewior authored
[ Upstream commit: 6212f2c7 ] The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Tested-by:
Stefan Hellermann <stefan@the2masters.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Joy Latten authored
[ Upstream commit: 2f40a178 ] When using aes-xcbc-mac for authentication in IPsec, the kernel crashes. It seems this algorithm doesn't account for the space IPsec may make in scatterlist for authtag. Thus when crypto_xcbc_digest_update2() gets called, nbytes may be less than sg[i].length. Since nbytes is an unsigned number, it wraps at the end of the loop allowing us to go back into loop and causing crash in memcpy. I used update function in digest.c to model this fix. Please let me know if it looks ok. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jeff Garzik authored
commit 2551a13e Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Acked-by:
Mark Salyzyn <mark_salyzyn@adaptec.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> FUJITA Tomonori notes: It didn't intend to fix a critical bug, however, it turned out that it does. Without this patch, the ips driver in 2.6.23 and 2.6.24 doesn't work at all. You can find the more details at the following thread: http://marc.info/?t=120293911900023&r=1&w=2 Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jan Beulich authored
commit e9427101 Its previous use in a call to on_each_cpu() was pointless, as at the time that code gets executed only one CPU is online. Further, the function can be __cpuinit, and for this to work without CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one can even be __init; on 64-bits check_timer() also was lacking that attribute). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> [ tglx@linutronix.de: backport to 2.6.24.3] Cc: Justin Piszcz <jpiszcz@lucidpixels.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
James Bottomley authored
commit: e88a0c2c Date: Sun, 9 Mar 2008 11:57:56 -0500 Subject: drivers: fix dma_get_required_mask There's a bug in the current implementation of dma_get_required_mask() where it ands the returned mask with the current device mask. This rather defeats the purpose if you're using the call to determine what your mask should be (since you will at that time have the default DMA_32BIT_MASK). This bug results in any driver that uses this function *always* getting a 32 bit mask, which is wrong. Fix by removing the and with dev->dma_mask. Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Nick Piggin authored
commit: f7009264 iov_iter_advance() skips over zero-length iovecs, however it does not properly terminate at the end of the iovec array. Fix this by checking against i->count before we skip a zero-length iov. The bug was reproduced with a test program that continually randomly creates iovs to writev. The fix was also verified with the same program and also it could verify that the correct data was contained in the file after each writev. Signed-off-by:
Nick Piggin <npiggin@suse.de> Tested-by:
"Kevin Coffman" <kwc@citi.umich.edu> Cc: "Alexey Dobriyan" <adobriyan@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Aurelien Jarno authored
x86: Clear DF before calling signal handler The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. This become a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. This is a backport of patch e40cd10c ("x86: clear DF before calling signal handler") that has been applied in 2.6.25-rc. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Pete Zaitcev authored
Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Cc: "Oliver Pinter" <oliver.pntr@gmail.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Greg KH <greg@kroah.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ralf Baechle authored
Use set_irq_noprobe() to mark all MIPS interrupts as non-probe. Override that default for i8259 interrupts. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Acked-and-tested-by:
Rob Landley <rob@landley.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ralf Baechle authored
Probing non-ISA interrupts using the handle_percpu_irq as their handle_irq method may crash the system because handle_percpu_irq does not check IRQ_WAITING. This for example hits the MIPS Qemu configuration. This patch provides two helper functions set_irq_noprobe and set_irq_probe to set rsp. clear the IRQ_NOPROBE flag. The only current caller is MIPS code but this really belongs into generic code. As an aside, interrupt probing these days has become a mostly obsolete if not dangerous art. I think Linux interrupts should be changed to default to non-probing but that's subject of this patch. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Acked-and-tested-by:
Rob Landley <rob@landley.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Herbert Xu authored
Upstream commit: 21e43188 Because we use shared tfm objects in order to conserve memory, (each tfm requires 128K of vmalloc memory), BH needs to be turned off on output as that can occur in process context. Previously this was done implicitly by the xfrm output code. That was lost when it became lockless. So we need to add the BH disabling to IPComp directly. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Stephen Hemminger authored
Upstream commit: dea75bdf From: Stephen Hemminger <shemminger@linux-foundation.org> Based upon a patch by Marcel Wappler: This patch fixes a DHCP issue of the kernel: some DHCP servers (i.e. in the Linksys WRT54Gv5) are very strict about the contents of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131 page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'. These DHCP servers ignore Linux kernel's DHCP discovery packets with these two fields set to '255.255.255.255' (in contrast to popular DHCP clients, such as 'dhclient' or 'udhcpc'). This leads to a not booting system. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
David S. Miller authored
Upstream commit: e4f8b5d4 Various RFCs have all sorts of things to say about the CS field of the DSCP value. In particular they try to make the distinction between values that should be used by "user applications" and things like routing daemons. This seems to have influenced the CAP_NET_ADMIN check which exists for IP_TOS socket option settings, but in fact it has an off-by-one error so it wasn't allowing CS5 which is meant for "user applications" as well. Further adding to the inconsistency and brokenness here, IPV6 does not validate the DSCP values specified for the IPV6_TCLASS socket option. The real actual uses of these TOS values are system specific in the final analysis, and these RFC recommendations are just that, "a recommendation". In fact the standards very purposefully use "SHOULD" and "SHOULD NOT" when describing how these values can be used. In the final analysis the only clean way to provide consistency here is to remove the CAP_NET_ADMIN check. The alternatives just don't work out: 1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing setups. 2) If we just fix the off-by-one error in the class comparison in IPV4, certain DSCP values can be used in IPV6 but not IPV4 by default. So people will just ask for a sysctl asking to override that. I checked several other freely available kernel trees and they do not make any privilege checks in this area like we do. For the BSD stacks, this goes back all the way to Stevens Volume 2 and beyond. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Denis V. Lunev authored
Upstream commit: 9937ded8 The result of the ip_route_output is not assigned to skb. This means that - it is leaked - possible OOPS below dereferrencing skb->dst - no ICMP message for this case Signed-off-by:
Denis V. Lunev <den@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Herbert Xu authored
Upstream commits: 28a89453 b5c15fc0 This is a long-standing bug in the IPsec IPv6 code that breaks when we emit a IPsec tunnel-mode datagram packet. The problem is that the code the emits the packet assumes the IPv6 stack will fragment it later, but the IPv6 stack assumes that whoever is emitting the packet is going to pre-fragment the packet. In the long term we need to fix both sides, e.g., to get the datagram code to pre-fragment as well as to get the IPv6 stack to fragment locally generated tunnel-mode packet. For now this patch does the second part which should make it work for the IPsec host case. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Matti Linnanvuori authored
Upstream commit: d8b2a4d2 There is a race in Linux kernel file net/core/dev.c, function dev_close. The function calls function dev_deactivate, which calls function dev_watchdog_down that deletes the watchdog timer. However, after that, a driver can call netif_carrier_ok, which calls function __netdev_watchdog_up that can add the watchdog timer again. Function unregister_netdevice calls function dev_shutdown that traps the bug !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after netif_running() has been cleared prevents function netif_carrier_on from calling __netdev_watchdog_up and adding the watchdog timer again. Signed-off-by:
Matti Linnanvuori <mattilinnanvuori@yahoo.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Jorge Boncompte [DTI2] authored
Upstream commit: 12aa343a Commit a0a400d7 ("[NET]: dev_mcast: add multicast list synchronization helpers") from you introduced a new field "da_synced" to struct dev_addr_list that is not properly initialized to 0. So when any of the current users (8021q, macvlan, mac80211) calls dev_mc_sync/unsync they mess the address list for both devices. The attached patch fixed it for me and avoid future problems. Signed-off-by:
Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
David S. Miller authored
Upstream commit: a4425859 Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Matheos Worku authored
Upstream commit: 3b5bcede BMAC port alternate MAC address index needs to start at 1. Index 0 is used for the main MAC address. Signed-off-by:
Matheos Worku <matheos.worku@sun.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Matheos Worku authored
Upstream commit: fa907895 From: Matheos Worku <Matheos.Worku@Sun.COM> 1) niu_enable_alt_mac() needs to be adjusted so that the mask is computed properly for the BMAC case. 2) BMAC has 6 alt MAC addresses available, not 7. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
David S. Miller authored
Upstream commit: 7adc3830 If all of the entropy is in the local and foreign addresses, but xor'ing together would cancel out that entropy, the current hash performs poorly. Suggested by Cosmin Ratiu: Basically, the situation is as follows: There is a client machine and a server machine. Both create 15000 virtual interfaces, open up a socket for each pair of interfaces and do SIP traffic. By profiling I noticed that there is a lot of time spent walking the established hash chains with this particular setup. The addresses were distributed like this: client interfaces were 198.18.0.1/16 with increments of 1 and server interfaces were 198.18.128.1/16 with increments of 1. As I said, there were 15000 interfaces. Source and destination ports were 5060 for each connection. So in this case, ports don't matter for hashing purposes, and the bits from the address pairs used cancel each other, meaning there are no differences in the whole lot of pairs, so they all end up in the same hash chain. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
David S. Miller authored
Upstream commit: f0e98c38 Reported by Adrian Bunk. Just like in changeset a3f99858 ("[SPARC64]: Move kernel unaligned trap handlers into assembler file.") we have to move the assembler bits into a seperate asm file because as far as the compiler is concerned these inline bits we're doing in unaligned.c are unreachable. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
David S. Miller authored
Upstream commits: 622eaec6 be71716e Some parts of the kernel now do things like do *_user() accesses while set_fs(KERNEL_DS) that fault on purpose. See, for example, the code added by changeset a0c1e907 ("futex: runtime enable pi and robust functionality"). That trips up the ASI sanity checking we make in do_kernel_fault(). Just remove it for now. Maybe we can add it back later with an added conditional which looks at the current get_fs() value. Also, because of the new futex validation init handler, we have to accept faults in init section text as well as the normal kernel text. Thanks to Tom Callaway for the bug report. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Greg Kroah-Hartman authored
This reverts commit 5fb7ba76 . It was incorrectly added to the .24.y stable tree and causes build breakages. Cc: Stephen Hemminger <stephen.hemminger@vyatta.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
- 26 Feb, 2008 12 commits
-
-
Greg Kroah-Hartman authored
-
Ingo Molnar authored
(no matching git id as the upstream code is rewritten) fix CPA cache attribute bug in v2.6.24. When phys_base is nonzero (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates the secondary alias address by -14 MB (depending on the configured offset). The default 64-bit kernels of Fedora and Ubuntu are affected: $ grep RELOCA /boot/config-2.6.23.9-85.fc8 CONFIG_RELOCATABLE=y $ grep RELOC /boot/config-2.6.22-14-generic CONFIG_RELOCATABLE=y and probably on many other distros as well. the bug affects all pages in the first 40 MB of physical RAM that are allocated by some subsystem that does ioremap_nocache() on them: if (__pa(address) < KERNEL_TEXT_SIZE) { Hence we might leave page table entries with inconsistent cache attributes around (pages mapped at both UnCacheable and Write-Back), and we can also set the wrong kernel text pages to UnCacheable. the effects of this bug can be random slowdowns and other misbehavior. If for example AGP allocates its aperture pages into the first 40 MB of physical RAM, then the -14 MB bug might mark random kernel texto pages as uncacheable, slowing down a random portion of the 64-bit kernel until the AGP driver is unloaded. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jay Vosburgh authored
patch 4fe4763c in mainline. Fix the "are we creating a duplicate" check to not compare the name if the name is NULL (meaning that the system should select a name). Bug reported by Benny Amorsen <benny+usenet@amorsen.dk>. Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Olaf Hering authored
Commit: 092ca5bd [POWERPC] Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos Commit 6d98bda7 changed the init order for chrp_pci_fixup_vt8231_ata(). It can not work anymore because either the irq is not yet set to 14 or pci_get_device() returns nothing. At least the printk() in chrp_pci_fixup_vt8231_ata() does not trigger anymore. pata_via works again on Pegasos with the change below. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Paul Mackerras <paulus@samba.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Chuck Ebbert authored
Commit: a1a98b72 Fix station address detection in smc Megahertz EM1144 PCMCIA ethernet adapter needs special handling because it has two VERS_1 tuples and the station address is in the second one. Conversion to generic handling of these fields broke it. Reverting that fixes the device. https://bugzilla.redhat.com/show_bug.cgi?id=233255 Thanks go to Jon Stanley for not giving up on this one until the problem was found. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Boaz Harrosh authored
commit: 61c92814 The patch: "gdth: switch to modern scsi host registration" missed one simple fact when moving a way from scsi_module.c. That is to call scsi_scan_host() on the probed host. With this the gdth driver from 2.6.24 is again able to see drives and boot. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Tested-by:
Joerg Dorchain <joerg@dorchain.net> Tested-by:
Stefan Priebe <s.priebe@allied-internet.ag> Tested-by:
Jon Chelton <jchelton@ffpglobal.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Oliver Neukum authored
commit 19028690 upstream if you fail in open() you must decrement the pm counter again. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Heiko Carstens authored
commit: d5b02b3f upstream Add missing exception table entry so that the kernel can handle proctection exceptions as well on the cs instruction. Currently only specification exceptions are handled correctly. The missing entry allows user space to crash the kernel. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Gleixner authored
commit 89d694b9 The default_disable() function was changed in commit: 76d21601 genirq: do not mask interrupts by default It removed the mask function in favour of the default delayed interrupt disabling. Unfortunately this also broke the shutdown in free_irq() when the last handler is removed from the interrupt for those architectures which rely on the default implementations. Now we can end up with a enabled interrupt line after the last handler was removed, which can result in spurious interrupts. Fix this by adding a default_shutdown function, which is only installed, when the irqchip implementation does provide neither a shutdown nor a disable function. Pointed-out-by:
Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Tested-by:
Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Gleixner authored
commit 63070a79 A CLOCK_REALTIME timer, which has an absolute expiry time less than the clock realtime offset calls with a negative delta into the clock events code and triggers the WARN_ON() there. This is a false positive and needs to be prevented. Check the result of timer->expires - timer->base->offset right away and return -ETIME right away. Thanks to Frans Pop, who reported the problem and tested the fixes. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Frans Pop <elendil@planet.nl> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Gleixner authored
commit: 5a7780e7 Various user space callers ask for relative timeouts. While we fixed that overflow issue in hrtimer_start(), the sites which convert relative user space values to absolute timeouts themself were uncovered. Instead of putting overflow checks into each place add a function which does the sanity checking and convert all affected callers to use it. Thanks to Frans Pop, who reported the problem and tested the fixes. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Tested-by:
Frans Pop <elendil@planet.nl> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Christoph Lameter authored
patch 5bb983b0 in mainline. gcc 4.2 spits out an annoying warning if one casts a const void * pointer to a void * pointer. No warning is generated if the conversion is done through an assignment. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-