- 20 Jul, 2009 10 commits
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit a137802e upstream. This causes kernel images that don't run init to completion with certain broken gcc versions. This fixes kernel bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=13012 I suspect the gcc problem is this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230 Fix the problem by using the -fno-strict-overflow flag instead, which not only does not exist in the known-to-be-broken versions of gcc (it was introduced later than fwrapv), but seems to be much less disturbing to gcc too: the difference in the generated code by -fno-strict-overflow are smaller (compared to using neither flag) than when using -fwrapv. Reported-by:
Barry K. Nathan <barryn@pobox.com> Pushed-by:
Frans Pop <elendil@planet.nl> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tomasz Lemiech authored
commit 1f8ae0a2 upstream. The original patch was submitted last year but wasn't discussed or applied because of missing maintainer's CCs. I only fixed some formatting errors, but as I saw tulip is very badly formatted and needs further work. Original description: This patch fixes MTU problem, which occurs when using 802.1q VLANs. We should allow receiving frames of up to 1518 bytes in length, instead of 1514. Based on patch written by Ben McKeegan for 2.4.x kernels. It is archived at http://www.candelatech.com/~greear/vlan/howto.html#tulip I've adjusted a few things to make it apply on 2.6.x kernels. Tested on D-Link DFE-570TX quad-fastethernet card. Signed-off-by:
Tomasz Lemiech <szpajder@staszic.waw.pl> Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Signed-off-by:
Ben McKeegan <ben@netservers.co.uk> Acked-by:
Grant Grundler <grundler@parisc-linux.org> Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Zhang Rui authored
commit 8bc1ad7d upstream. When the 32-bit signed quantities get assigned to the u64 resource_size_t, they are incorrectly sign-extended. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13253 Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9905 Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Reported-by:
Leann Ogasawara <leann@ubuntu.com> Cc: Pierre Ossman <drzeus@drzeus.cx> Reported-by: <pablomme@googlemail.com> Tested-by: <pablomme@googlemail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jiri Slaby authored
commit 8516a500 upstream. A crappy macro prevents us unlocking on a fail path. Expand the macro and unlock appropriatelly. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
David Woodhouse authored
commit a15a519e upstream. This fixes kernel.org bug #13584. The IOVA code attempted to optimise the insertion of new ranges into the rbtree, with the unfortunate result that some ranges just didn't get inserted into the tree at all. Then those ranges would be handed out more than once, and things kind of go downhill from there. Introduced after 2.6.25 by ddf02886 ("PCI: iova RB tree setup tweak"). Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Cc: mark gross <mgross@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Christoph Lameter authored
commit e0a94c2a upstream. This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY. It also sets a default mmap_min_addr of 4096. mmapping of addresses below 4096 will only be possible for processes with CAP_SYS_RAWIO. Signed-off-by:
Christoph Lameter <cl@linux-foundation.org> Acked-by:
Eric Paris <eparis@redhat.com> Looks-ok-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Julien Tinnes authored
commit f9fabcb5 upstream. We have found that the current PER_CLEAR_ON_SETID mask on Linux doesn't include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO. The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE. We believe it is important to add MMAP_PAGE_ZERO, because by using this personality it is possible to have the first page mapped inside a process running as setuid root. This could be used in those scenarios: - Exploiting a NULL pointer dereference issue in a setuid root binary - Bypassing the mmap_min_addr restrictions of the Linux kernel: by running a setuid binary that would drop privileges before giving us control back (for instance by loading a user-supplied library), we could get the first page mapped in a process we control. By further using mremap and mprotect on this mapping, we can then completely bypass the mmap_min_addr restrictions. Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added since on x86 32bits it will in practice disable most of the address space layout randomization (only the stack will remain randomized). Signed-off-by:
Julien Tinnes <jt@cr0.org> Signed-off-by:
Tavis Ormandy <taviso@sdf.lonestar.org> Acked-by:
Christoph Hellwig <hch@infradead.org> Acked-by:
Kees Cook <kees@ubuntu.com> Acked-by:
Eugene Teo <eugene@redhat.com> [ Shortened lines and fixed whitespace as per Christophs' suggestion ] Signed-off-by:
-
Eugene Teo authored
commit a3ca86ae upstream. Turning on this flag could prevent the compiler from optimising away some "useless" checks for null pointers. Such bugs can sometimes become exploitable at compile time because of the -O2 optimisation. See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html An example that clearly shows this 'problem' is commit 6bf67672 . static void __devexit agnx_pci_remove(struct pci_dev *pdev) { struct ieee80211_hw *dev = pci_get_drvdata(pdev); - struct agnx_priv *priv = dev->priv; + struct agnx_priv *priv; AGNX_TRACE; if (!dev) return; + priv = dev->priv; By reverting this patch, and compile it with and without -fno-delete-null-pointer-checks flag, we can see that the check for dev is compiled away. call printk # - testq %r12, %r12 # dev - je .L94 #, movq %r12, %rdi # dev, Clearly the 'fix' is to stop using dev before it is tested, but building with -fno-delete-null-pointer-checks flag at least makes it harder to abuse. Signed-off-by:
Eugene Teo <eugeneteo@kernel.sg> Acked-by:
Wang Cong <amwang@redhat.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 9fad9f26. It is really commit 4d89b7b4 that is being reverted here, it's a patch that should not have been applied to the .27 tree. Signed-off-by:
-
- 02 Jul, 2009 30 commits
-
-
Greg Kroah-Hartman authored
-
Justin P. Mattock authored
commit d15bd106 upstream. This fixes an error when compiling the kernel. CHK include/linux/version.h HOSTCC scripts/unifdef scripts/unifdef.c:209: error: conflicting types for 'getline' /usr/include/stdio.h:651: note: previous declaration of 'getline' was here make[1]: *** [scripts/unifdef] Error 1 make: *** [__headers] Error 2 Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Gilles Espinasse <g.esp@free.fr> Signed-off-by:
-
Renaud Lottiaux authored
commit df279ca8 upstream. The file opened in acct_on and freshly stored in the ns->bacct struct can be closed in acct_file_reopen by a concurrent call after we release acct_lock and before we call mntput(file->f_path.mnt). Record file->f_path.mnt in a local variable and use this variable only. Signed-off-by:
Renaud Lottiaux <renaud.lottiaux@kerlabs.com> Signed-off-by:
Louis Rilling <louis.rilling@kerlabs.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Milan Broz authored
commit 4d89b7b4 upstream. Do not process sysfs attributes when device is being destroyed. Otherwise code can cause BUG_ON(test_bit(DMF_FREEING, &md->flags)); in dm_put() call. Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 0e0497c0 upstream. The parser reads the argument count as a number but doesn't check that sufficient arguments are supplied. This command triggers the bug: dmsetup create mpath --table "0 `blockdev --getsize /dev/mapper/cr0` multipath 0 0 2 1 round-robin 1000 0 1 1 /dev/mapper/cr0 round-robin 0 1 1 /dev/mapper/cr1 1000" kernel BUG at drivers/md/dm-mpath.c:530! Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit e094f4f1 upstream. Fix arg count parsing error in hw handlers. Signed-off-by:
-
Dimitri Sivanich authored
commit 364df0eb upstream. After downing/upping a cpu, an attempt to set /proc/sys/vm/percpu_pagelist_fraction results in an oops in percpu_pagelist_fraction_sysctl_handler(). If a processor is downed then we need to set the pageset pointer back to the boot pageset. Updates of the high water marks should not access pagesets of unpopulated zones (those pointer go to the boot pagesets which would be no longer functional if their size would be increased beyond zero). Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Clemens Ladisch authored
commit 6423f9ea upstream. When decoding (N)RPN sequencer events into raw MIDI commands, the extra_decode_xrpn() function had accidentally swapped the MSB and LSB controller values of both the parameter number and the data value. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jiri Slaby authored
commit 69ae59d7 upstream. Don't return from switch/case, break instead, so that we unlock BKL. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit f62795f1 upstream. According to the PCI PM specification (PCI Bus Power Management Interface Specification, Rev. 1.2, Section 5.4.1) we are supposed to reinitialize devices that have PCI_PM_CTRL_NO_SOFT_RESET clear during all transitions from PCI_D3hot to PCI_D0, but we only do it if the device's current_state field is equal to PCI_UNKNOWN. This may lead to problems if a device with PCI_PM_CTRL_NO_SOFT_RESET unset is put into PCI_D3hot at run time by its driver and pci_set_power_state() is used to put it back into PCI_D0, because in that case the device will remain uninitialized after pci_set_power_state() has returned. Prevent that from happening by modifying pci_raw_set_power_state() to reinitialize devices with PCI_PM_CTRL_NO_SOFT_RESET unset during all transitions from D3 to D0. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit d2abdf62 upstream. If a PCI device is not power-manageable either by the platform, or with the help of the native PCI PM interface, pci_target_state() will return either PCI_D3hot, or PCI_POWER_ERROR for it, depending on whether or not the device is configured to wake up the system. Alas, none of these return values is correct, because each of them causes pci_prepare_to_sleep() to return error code, although it should complete successfully in such a case. Fix this problem by making pci_target_state() always return PCI_D0 for devices that cannot be power managed. Signed-off-by:
-
FUJITA Tomonori authored
commit dfa7c4d8 upstream. parport_pc_probe_port() creates the own 'parport_pc' device if the device argument is NULL. Then parport_pc_probe_port() doesn't initialize the dma_mask and coherent_dma_mask of the device and calls dma_alloc_coherent with it. dma_alloc_coherent fails because dma_alloc_coherent() doesn't accept the uninitialized dma_mask: http://lkml.org/lkml/2009/6/16/150 Long ago, X86_32 and X86_64 had the own dma_alloc_coherent implementations; X86_32 accepted a device having dma_mask that is not initialized however X86_64 didn't. When we merged them, we chose to prohibit a device having dma_mask that is not initialized. I think that it's good to require drivers to set up dma_mask (and coherent_dma_mask) properly if the drivers want DMA. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Reported-by:
Malcom Blaney <malcolm.blaney@maptek.com.au> Tested-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jens Rottmann authored
commit e2434dc1 upstream. CONFIG_PARPORT_PC_SUPERIO probes for various superio chips by writing byte sequences to a set of different potential I/O ranges. But the probed ranges are not exclusive to parallel ports. Some of our boards just happen to have a watchdog in one of them. Took us almost a week to figure out why some distros reboot without warning after running flawlessly for 3 hours. For exactly 170 = 0xAA minutes, that is ... Fixed by restoring original values after probing. Also fixed too small request_region() in detect_and_report_it87(). Signed-off-by:
Jens Rottmann <JRottmann@LiPPERTEmbedded.de> Signed-off-by:
-
Tom Quetchenbach authored
commit f5fff5dc upstream. I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS for both sides of a bidirectional connection. man tcp says: "If this option is set before connection establishment, it also changes the MSS value announced to the other end in the initial packet." However, the kernel only uses the MTU/route cache to set the advertised MSS. That means if I set the MSS to, say, 500 before calling connect(), I will send at most 500-byte packets, but I will still receive 1500-byte packets in reply. This is a bug, either in the kernel or the documentation. This patch (applies to latest net-2.6) reduces the advertised value to that requested by the user as long as setsockopt() is called before connect() or accept(). This seems like the behavior that one would expect as well as that which is documented. I've tried to make sure that things that depend on the advertised MSS are set correctly. Signed-off-by:
Tom Quetchenbach <virtualphtn@gmail.com> Signed-off-by:
-
Dan Williams authored
commit 7a3ab908 upstream. In the unlikely event that reshape progresses past the current request while it is waiting for a stripe we need to schedule() before retrying for 2 reasons: 1/ Prevent list corruption from duplicated list_add() calls without intervening list_del(). 2/ Give the reshape code a chance to make some progress to resolve the conflict. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Peter Zijlstra authored
commit 00540e5d upstream. x86 stack traces are a piece of crap without frame pointers, and its not like the 'performance gain' of not having stack pointers matters when you selected lockdep. Reported-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Yinghai Lu authored
commit 8c5dd8f4 upstream. On a system where system memory (according e820) is not covered by mtrr, mtrr_trim_memory converts a portion of memory to reserved, but bootloader has already put the initrd in that range. Thus, we need to have 64bit to use relocate_initrd too. [ Impact: fix using initrd when mtrr_trim_memory happen ] Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Jack Morgenstein authored
commit 2ac6bf4d upstream. The ConnectX Programmer's Reference Manual states that the "SO" bit must be set when posting Fast Register and Local Invalidate send work requests. When this bit is set, the work request will be executed only after all previous work requests on the send queue have been executed. (If the bit is not set, Fast Register and Local Invalidate WQEs may begin execution too early, which violates the defined semantics for these operations) This fixes the issue with NFS/RDMA reported in <http://lists.openfabrics.org/pipermail/general/2009-April/059253.html > Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Philippe De Muyter authored
commit 5a74db06 upstream. The floppy driver requests an I/O port it doesn't need, and sometimes this causes a conflict with a motherboard device reported by PNPBIOS. This patch makes the floppy driver request and release only the ports it actually uses. It also factors out the request/release stuff and the io-ports list so they're all in one place now. The current floppy driver uses only these ports: 0x3f2 (FD_DOR) 0x3f4 (FD_STATUS) 0x3f5 (FD_DATA) 0x3f7 (FD_DCR/FD_DIR) but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port 0x3f3. Some BIOSes report 0x3f3 as a motherboard resource. The PNP system driver reserves that, which causes a conflict when the floppy driver requests 0x3f2-0x3f5 later. Philippe reported that this conflict broke the floppy driver between 2.6.11 and 2.6.22. His PNPBIOS reports these devices: $ cat 00:07/id 00:07/resources # motherboard device PNP0c02 state = active io 0x80-0x80 io 0x10-0x1f io 0x22-0x3f io 0x44-0x5f io 0x90-0x9f io 0xa2-0xbf io 0x3f0-0x3f1 io 0x3f3-0x3f3 $ cat 00:03/id 00:03/resources # floppy device PNP0700 state = active io 0x3f4-0x3f5 io 0x3f2-0x3f2 Reference: http://lkml.org/lkml/2009/1/31/162 Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Philippe De Muyter <phdm@macqel.be> Reported-by:
-
Scott James Remnant authored
commit 83f9ef46 upstream. The missing device table means that the floppy module is not auto-loaded, even when the appropriate PNP device (0700) is found. We don't actually use the table in the module, since the device doesn't have a struct pnp_driver, but it's sufficient to cause an alias in the module that udev/modprobe will use. Signed-off-by:
Scott James Remnant <scott@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Philippe De Muyter <phdm@macqel.be> Acked-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
-
Takashi Iwai authored
commit 601e1cc5 upstream. Although the vmaster controls are created, they aren't registered thus they don't appear in the real world. Added the missing snd_ctl_add() calls. Signed-off-by:
-
Steve Conklin authored
commit 093bac15 upstream. Dell Optiplex 330 appears to hang on reboot. This is resolved by adding a quirk to set bios reboot. Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
Steve Conklin <steve.conklin@canonical.com> Signed-off-by:
-
Jean Delvare authored
commit 4a4aca64 upstream. The Dell Optiplex 360 hangs on reboot, just like the Optiplex 330, so the same quirk is needed. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Steve Conklin <steve.conklin@canonical.com> Cc: Leann Ogasawara <leann.ogasawara@canonical.com> LKML-Reference: <200906051202.38311.jdelvare@suse.de> Signed-off-by:
-
Karsten Keil authored
commit 8a745b9d upstream. Replace wrong code with correct DMA API functions. Signed-off-by:
Karsten Keil <keil@b1-systems.de> Signed-off-by:
-
Eric Dumazet authored
commit fdd7b4c3 upstream. Michael Tokarev reported receiving a large packet could crash a machine with RTL8169 NIC. ( original thread at http://lkml.org/lkml/2009/6/8/192 ) Problem is this driver tells that NIC frames up to 16383 bytes can be received but provides skb to rx ring allocated with smaller sizes (1536 bytes in case standard 1500 bytes MTU is used) When a frame larger than what was allocated by driver is received, dma transfert can occurs past the end of buffer and corrupt kernel memory. Fix is to tell to NIC what is the maximum size a frame can be. This bug is very old, (before git introduction, linux-2.6.10), and should be backported to stable versions. Reported-by:
Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Tested-by:
-
Shaohua Li authored
commit 8e822df7 upstream. VIA has a strange chipset, it has root port under a bridge. Disable ASPM for such strange chipset. Tested-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Jan Kara authored
commit a61d90d7 upstream. In commit code, we scan buffers attached to a transaction. During this scan, we sometimes have to drop j_list_lock and then we recheck whether the journal buffer head didn't get freed by journal_try_to_free_buffers(). But checking for buffer_jbd(bh) isn't enough because a new journal head could get attached to our buffer head. So add a check whether the journal head remained the same and whether it's still at the same transaction and list. This is a nasty bug and can cause problems like memory corruption (use after free) or trigger various assertions in JBD code (observed). Signed-off-by:
Jan Kara <jack@suse.cz> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Yinghai Lu authored
commit 3b0fde0f upstream. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484 Peer reported: | The bug is introduced from kernel 2.6.27, if E820 table reserve the memory | above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000 | (reserved)), system will report Int 6 error and hang up. The bug is caused by | the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit | variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6 | error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this | bug. |====== |static int firmware_map_add_entry(resource_size_t start, resource_size_t end, | const char *type, | struct firmware_map_entry *entry) and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set. it turns out we need to pass u64 instead of resource_size_t for that. [akpm@linux-foundation.org: add comment] Reported-and-tested-by:
Peer Chen <pchen@nvidia.com> Signed-off-by:
-
Peter Botha authored
commit 96050dfb upstream. There's a bug in the mxser kernel module that still appears in the 2.6.29.4 kernel. mxser_get_ISA_conf takes a ioaddress as its first argument, by passing the not of the ioaddr, you're effectively passing 0 which means it won't be able to talk to an ISA card. I have tested this, and removing the ! fixes the problem. Cc: "Peter Botha" <peterb@goldcircle.co.za> Signed-off-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Dirk Eibach authored
commit a90b0375 upstream. In moxa.c there are 32 minor numbers reserved for each device. The number of ports actually available per device is stored in moxa_board_conf->numPorts. This number is not considered in moxa_open(). Opening a port that is not available results in a kernel oops. This patch adds a test to moxa_open() that prevents opening unavailable ports. [akpm@linux-foundation.org: avoid multiple returns] Signed-off-by:
Dirk Eibach <eibach@gdsys.de> Signed-off-by:
-
