- 09 May, 2011 17 commits
-
-
James Bottomley authored
commit 4a5fa359 upstream. Slub makes assumptions about page_to_nid() which are violated by DISCONTIGMEM and !NUMA. This violation results in a panic because page_to_nid() can be non-zero for pages in the discontiguous ranges and this leads to a null return by get_node(). The assertion by the maintainer is that DISCONTIGMEM should only be allowed when NUMA is also defined. However, at least six architectures: alpha, ia64, m32r, m68k, mips, parisc violate this. The panic is a regression against slab, so just mark slub broken in the problem configuration to prevent users reporting these panics. Acked-by:
David Rientjes <rientjes@google.com> Acked-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Herbert Xu authored
commit 26cde9f7 upstream. It has been reported that the new UFO software fallback path fails under certain conditions with NFS. I tracked the problem down to the generation of UFO packets that are smaller than the MTU. The software fallback path simply discards these packets. This patch fixes the problem by not generating such packets on the UFO path. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Jie Yang authored
commit 678b77e2 upstream. remove duplicate atl1c_get_tpd, it may cause hardware to send wrong packets. Signed-off-by:
Jie Yang <jie.yang@atheros.com> Signed-off-by:
-
Fry, Donald H authored
commit 41504cce upstream. New iwlwifi-5000 microcode requires driver support for API version 5. Signed-off-by:
Don Fry <donald.h.fry@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Stefan Haberland authored
commit 5da24b76 upstream. The 3880 storage control unit supports a 3380 device type, but not a 3390 device type. Reported-by:
Stephen Powell <zlinuxman@wowway.com> Signed-off-by:
Stefan Haberland <stefan.haberland@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Stephen Powell <zlinuxman@wowway.com> Cc: Jonathan Nieder <jrnieder@gmail.com> Cc: Bastian Blank <waldi@debian.org>
-
Greg Rose authored
commit b1d670f1 upstream. declaration. Reported-by:
Andi Kleen <andi@firstfloor.org> Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Tested-by:
Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Andreas Radke <a.radke@arcor.de> Signed-off-by:
-
Artem Bityutskiy authored
commit 6e0d9fd3 upstream. This patch fixes the following symptoms: 1. Unmount UBIFS cleanly. 2. Start mounting UBIFS R/W and have a power cut immediately 3. Start mounting UBIFS R/O, this succeeds 4. Try to re-mount UBIFS R/W - this fails immediately or later on, because UBIFS will write the master node to the flash area which has been written before. The analysis of the problem: 1. UBIFS is unmounted cleanly, both copies of the master node are clean. 2. UBIFS is being mounter R/W, starts changing master node copy 1, and a power cut happens. The copy N1 becomes corrupted. 3. UBIFS is being mounted R/O. It notices the copy N1 is corrupted and reads copy N2. Copy N2 is clean. 4. Because of R/O mode, UBIFS cannot recover copy 1. 5. The mount code (ubifs_mount()) sees that the master node is clean, so it decides that no recovery is needed. 6. We are re-mounting R/W. UBIFS believes no recovery is needed and starts updating the master node, but copy N1 is still corrupted and was not recovered! Fix this problem by marking the master node as dirty every time we recover it and we are in R/O mode. This forces further recovery and the UBIFS cleans-up the corruptions and recovers the copy N1 when re-mounting R/W later. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
-
Ben Hutchings authored
commit 3ba41621 upstream. Commit 40aee729 ('kconfig: fix default value for choice input') fixed some cases where kconfig would select the wrong option from a choice with a single valid option and thus enter an infinite loop. However, this broke the test for user input of the form 'N?', because when kconfig selects the single valid option the input is zero-length and the test will read the byte before the input buffer. If this happens to contain '?' (as it will in a mips build on Debian unstable today) then kconfig again enters an infinite loop. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mark Brown authored
commit 39cca168 upstream. The output PGA was not being powered up in headphone and speaker paths, removing the ability to offer volume control and mute with the output PGA. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Uwe Kleine-König authored
commit 5680e941 upstream. If cts changes between reading the level at the cts input (USR1_RTSS) and acking the irq (USR1_RTSD) the last edge doesn't generate an irq and uart_handle_cts_change is called with a outdated value for cts. The race was introduced by commit ceca629e ([ARM] 2971/1: i.MX uart handle rts irq) Reported-by:
Arwed Springer <Arwed.Springer@de.trumpf.com> Tested-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Trond Myklebust authored
commit 27dc1cd3 upstream. If the call to nfs_wcc_update_inode() results in an attribute update, we need to ensure that the inode's attr_gencount gets bumped too, otherwise we are not protected against races with other GETATTR calls. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Alex Deucher authored
commit 8e461123 upstream. Noticed by Patrick Lowry. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Williamson authored
commit 2fe9723d upstream. If we run out of domain_ids and fail iommu_attach_domain(), we fall into domain_exit() without having setup enough of the domain structure for this to do anything useful. In fact, it typically runs off into the weeds walking the bogus domain->devices list. Just free the domain. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Acked-by:
Donald Dutile <ddutile@redhat.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Alex Williamson authored
commit a97590e5 upstream. When we remove a device, we unlink the iommu from the domain, but we never do the reverse unlinking of the domain from the iommu. This means that we never clear iommu->domain_ids, eventually leading to resource exhaustion if we repeatedly bind and unbind a device to a driver. Also free empty domains to avoid a resource leak. Signed-off-by:
-
Jason Conti authored
commit a6756da9 upstream. This patch fixes a very serious off-by-one bug in the driver, which could leave the device in an unresponsive state. The problem was that the extra_len variable [used to reserve extra scratch buffer space for the firmware] was left uninitialized. Because p54_assign_address later needs the value to reserve additional space, the resulting frame could be to big for the small device's memory window and everything would immediately come to a grinding halt. Reference: https://bugs.launchpad.net/bugs/722185Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
Jason Conti <jason.conti@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Liu Yuan authored
commit ed5302d3 upstream. We do not call blk_trace_remove_sysfs() in err return path if kobject_add() fails. This path fixes it. Signed-off-by:
Liu Yuan <tailai.ly@taobao.com> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Christian Lamparter authored
commit bd39a274 upstream. Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Reported-by:
Joe Culler <joe.culler@gmail.com> Acked-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
- 22 Apr, 2011 23 commits
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit 1b1f693d upstream. As reported by Thomas Pollet, the rdma page counting can overflow. We get the rdma sizes in 64-bit unsigned entities, but then limit it to UINT_MAX bytes and shift them down to pages (so with a possible "+1" for an unaligned address). So each individual page count fits comfortably in an 'unsigned int' (not even close to overflowing into signed), but as they are added up, they might end up resulting in a signed return value. Which would be wrong. Catch the case of tot_pages turning negative, and return the appropriate error code. Reported-by:
Thomas Pollet <thomas.pollet@gmail.com> Signed-off-by:
Andy Grover <andy.grover@oracle.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Kees Cook authored
commit 5b919f83 upstream. Commit fe10ae53 adds a memset() to clear the structure being sent back to userspace, but accidentally used the wrong size. Reported-by:
Brad Spengler <spender@grsecurity.net> Signed-off-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
-
Hans Rosenfeld authored
commit 07a7795c upstream. A bug in the family-model-stepping matching code caused the presence of errata to go undetected when OSVW was not used. This causes hangs on some K8 systems because the E400 workaround is not enabled. Signed-off-by:
Hans Rosenfeld <hans.rosenfeld@amd.com> LKML-Reference: <1282141190-930137-1-git-send-email-hans.rosenfeld@amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Dmitry Torokhov authored
commit dfa49c4a upstream. When parsing exponent-expressed intervals we subtract 1 from the value and then expect it to match with original + 1, which is highly unlikely, and we end with frequent spew: usb 3-4: ep 0x83 - rounding interval to 512 microframes Also, parsing interval for fullspeed isochronous endpoints was incorrect - according to USB spec they use exponent-based intervals (but xHCI spec claims frame-based intervals). I trust USB spec more, especially since USB core agrees with it. This should be queued for stable kernels back to 2.6.31. Reviewed-by:
Micah Elizabeth Scott <micah@vmware.com> Signed-off-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Dmitry Torokhov authored
commit 5a6c2f3f upstream. Macro arguments used in expressions need to be enclosed in parenthesis to avoid unpleasant surprises. This should be queued for kernels back to 2.6.31 Signed-off-by:
-
Dmitry Torokhov authored
commit 2868a2b1 upstream. Isochronous and interrupt SuperSpeed endpoints use the same mechanisms for decoding bInterval values as HighSpeed ones so adjust the code accordingly. Also bandwidth reservation for SuperSpeed matches highspeed, not low/full speed. Signed-off-by:
-
Alan Stern authored
commit 94ae4976 upstream. This patch (as1458) fixes a problem affecting ultra-reliable systems: When hardware failover of an EHCI controller occurs, the data structures do not get released correctly. This is because the routine responsible for removing unused QHs from the async schedule assumes the controller is running properly (the frame counter is used in determining how long the QH has been idle) -- but when a failover causes the controller to be electronically disconnected from the PCI bus, obviously it stops running. The solution is simple: Allow scan_async() to remove a QH from the async schedule if it has been idle for long enough _or_ if the controller is stopped. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-Tested-by:
Dan Duval <dan.duval@stratus.com> Signed-off-by:
-
Linus Torvalds authored
commit d8bdc59f upstream. Rather than pass in some random truncated offset to the pid-related functions, check that the offset is in range up-front. This is just cleanup, the previous commit fixed the real problem. Signed-off-by:
-
Linus Torvalds authored
commit c78193e9 upstream. next_pidmap() just quietly accepted whatever 'last' pid that was passed in, which is not all that safe when one of the users is /proc. Admittedly the proc code should do some sanity checking on the range (and that will be the next commit), but that doesn't mean that the helper functions should just do that pidmap pointer arithmetic without checking the range of its arguments. So clamp 'last' to PID_MAX_LIMIT. The fact that we then do "last+1" doesn't really matter, the for-loop does check against the end of the pidmap array properly (it's only the actual pointer arithmetic overflow case we need to worry about, and going one bit beyond isn't going to overflow). [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ] Reported-by:
Tavis Ormandy <taviso@cmpxchg8b.com> Analyzed-by:
Robert Święcki <robert@swiecki.net> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
-
Marius B. Kotsbak authored
commit 80f9df3e upstream. Bind only modem AT command endpoint to option. Signed-off-by:
Marius B. Kotsbak <marius@kotsbak.com> Signed-off-by:
-
Enrico Mioso authored
commit c6991b6f upstream. This patch, adds to the option driver the Onda Communication (http://www.ondacommunication.com) vendor id, and the MT825UP modem device id. Note that many variants of this same device are being release here in Italy (at least one or two per telephony operator). These devices are perfectly equivalent except for some predefined settings (which can be changed of course). It should be noted that most ONDA devices are allready supported (they used other vendor's ids in the past). The patch seems working fine here, and the rest of the driver seems uninfluenced. Signed-off-by:
Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by:
-
Paul Friedrich authored
commit c53c2fab upstream. usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720 and HO730 Signed-off-by:
-
Johan Hovold authored
commit 11a31d84 upstream. Add PID 0x0103 for serial port of the OCT DK201 docking station. Reported-by:
Jan Hoogenraad <jan@hoogenraad.net> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Christian Simon authored
commit 5a9443f0 upstream. I added new ProdutIds for two devices from CTI GmbH Leipzig. Signed-off-by:
Christian Simon <simon@swine.de> Signed-off-by:
-
Joerg Roedel authored
commit 5bbc097d upstream. This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS forgets to do is (or is just too old). Letting these errors enabled can cause a sync-flood on the CPU causing a reboot. The AMD BKDG recommends disabling GART TLB Wlk Error completely. This patch is the fix for https://bugzilla.kernel.org/show_bug.cgi?id=33012 on my machine. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Link: http://lkml.kernel.org/r/20110415131152.GJ18463@8bytes.orgTested-by:
Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Boris Ostrovsky authored
commit b87cf80a upstream. Support for Always Running APIC timer (ARAT) was introduced in commit db954b58. This feature allows us to avoid switching timers from LAPIC to something else (e.g. HPET) and go into timer broadcasts when entering deep C-states. AMD processors don't provide a CPUID bit for that feature but they also keep APIC timers running in deep C-states (except for cases when the processor is affected by erratum 400). Therefore we should set ARAT feature bit on AMD CPUs. Tested-by:
Borislav Petkov <borislav.petkov@amd.com> Acked-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Acked-by:
Mark Langsdorf <mark.langsdorf@amd.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@amd.com> LKML-Reference: <1300205624-4813-1-git-send-email-ostr@amd64.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Hans Rosenfeld authored
commit 9d8888c2 upstream. Remove check_c1e_idle() and use the new AMD errata checking framework instead. Signed-off-by:
-
Hans Rosenfeld authored
commit d78d671d upstream. Errata are defined using the AMD_LEGACY_ERRATUM() or AMD_OSVW_ERRATUM() macros. The latter is intended for newer errata that have an OSVW id assigned, which it takes as first argument. Both take a variable number of family-specific model-stepping ranges created by AMD_MODEL_RANGE(). Iff an erratum has an OSVW id, OSVW is available on the CPU, and the OSVW id is known to the hardware, it is used to determine whether an erratum is present. Otherwise, the model-stepping ranges are matched against the current CPU to find out whether the erratum applies. For certain special errata, the code using this framework might have to conduct further checks to make sure an erratum is really (not) present. Signed-off-by:
-
Artem Bityutskiy authored
commit 78530bf7 upstream. This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an file on R/O-mounter file-system. We (the UBIFS authors) incorrectly thought that VFS would not propagate 'fsync()' down to the file-system if it is read-only, but this is not the case. It is easy to exploit this bug using the following simple perl script: use strict; use File::Sync qw(fsync sync); die "File path is not specified" if not defined $ARGV[0]; my $path = $ARGV[0]; open FILE, "<", "$path" or die "Cannot open $path: $!"; fsync(\*FILE) or die "cannot fsync $path: $!"; close FILE or die "Cannot close $path: $!"; Thanks to Reuben Dowle <Reuben.Dowle@navico.com> for reporting about this issue. Signed-off-by:
Reuben Dowle <Reuben.Dowle@navico.com> Signed-off-by:
-
Randy Dunlap authored
commit d00ebeac upstream. Drop Chris Wright from STABLE maintainers. He hasn't done STABLE release work for quite some time. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Bob Liu authored
commit b836aec5 upstream. On no-mmu arch, there is a memleak during shmem test. The cause of this memleak is ramfs_nommu_expand_for_mapping() added page refcount to 2 which makes iput() can't free that pages. The simple test file is like this: int main(void) { int i; key_t k = ftok("/etc", 42); for ( i=0; i<100; ++i) { int id = shmget(k, 10000, 0644|IPC_CREAT); if (id == -1) { printf("shmget error\n"); } if(shmctl(id, IPC_RMID, NULL ) == -1) { printf("shm rm error\n"); return -1; } } printf("run ok...\n"); return 0; } And the result: root:/> free total used free shared buffers Mem: 60320 17912 42408 0 0 -/+ buffers: 17912 42408 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 19096 41224 0 0 -/+ buffers: 19096 41224 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 20296 40024 0 0 -/+ buffers: 20296 40024 ... After this patch the test result is:(no memleak anymore) root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 Signed-off-by:
Bob Liu <lliubbo@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Jeff Mahoney authored
commit c1d036c4 upstream. ia64_mca_cpu_init has a void *data local variable that is assigned the value from either __get_free_pages() or mca_bootmem(). The problem is that __get_free_pages returns an unsigned long and mca_bootmem, via alloc_bootmem(), returns a void *. format_mca_init_stack takes the void *, and it's also used with __pa(), but that casts it to long anyway. This results in the following build warning: arch/ia64/kernel/mca.c:1898: warning: assignment makes pointer from integer without a cast Cast the return of __get_free_pages to a void * to avoid the warning. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
