- 25 Jan, 2012 16 commits
-
-
J. Bruce Fields authored
commit 61c8504c upstream. The pool_to and to_pool fields of the global svc_pool_map are freed on shutdown, but are initialized in nfsd startup only in the SVC_POOL_PERCPU and SVC_POOL_PERNODE cases. They *are* initialized to zero on kernel startup. So as long as you use only SVC_POOL_GLOBAL (the default), this will never be a problem. You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE. However, the following sequence events leads to a double-free: 1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE 2. start nfsd: both fields are initialized. 3. shutdown nfsd: both fields are freed. 4. set SVC_POOL_GLOBAL 5. start nfsd: the fields are left untouched. 6. shutdown nfsd: now we try to free them again. Step 4 is actually unnecessary, since (for some bizarre reason), nfsd automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit 6c06108b upstream. If ctrls->count is too high the multiplication could overflow and array_size would be lower than expected. Mauro and Hans Verkuil suggested that we cap it at 1024. That comes from the maximum number of controls with lots of room for expantion. $ grep V4L2_CID include/linux/videodev2.h | wc -l 211 Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Jean Delvare authored
commit 7c1f59c9 upstream. When adding checks for ACPI resource conflicts to many bus drivers, not enough attention was paid to the error paths, and for several drivers this causes 0 to be returned on error in some cases. Fix this by properly returning a non-zero value on every error. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Richard Weinberger authored
commit 4a59c797 upstream. Currently it's possible to create a volume without a name. E.g: ubimkvol -n 32 -s 2MiB -t static /dev/ubi0 -N "" After that vtbl_check() will always fail because it does not permit empty strings. Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> Signed-off-by:
-
Ludwig Nussel authored
commit 9af0c7a6 upstream. On x86_32 casting the unsigned int result of get_random_int() to long may result in a negative value. On x86_32 the range of mmap_rnd() therefore was -255 to 255. The 32bit mode on x86_64 used 0 to 255 as intended. The bug was introduced by 675a0813 ("x86: unify mmap_{32|64}.c") in January 2008. Signed-off-by:
Ludwig Nussel <ludwig.nussel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: harvey.harrison@gmail.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Bjorn Helgaas authored
commit eb31aae8 upstream. Some Dell BIOSes have MCFG tables that don't report the entire MMCONFIG area claimed by the chipset. If we move PCI devices into that claimed-but-unreported area, they don't work. This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as needed to cover the entire area. Example problem scenario: BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved) Fam 10h mmconf [d0000000, dfffffff] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000) pnp 00:0c: [mem 0xd0000000-0xd3ffffff] pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff] Reported-by:
Lisa Salimbas <lisa.salimbas@canonical.com> Reported-by: <thuban@singularity.fr> Tested-by:
dann frazier <dann.frazier@canonical.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=31602 References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043 References: https://bugzilla.redhat.com/show_bug.cgi?id=770308Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Roberto Sassu authored
commit 45fae749 upstream. Info about new measurements are cached in the iint for performance. When the inode is flushed from cache, the associated iint is flushed as well. Subsequent access to the inode will cause the inode to be re-measured and will attempt to add a duplicate entry to the measurement list. This patch frees the duplicate measurement memory, fixing a memory leak. Signed-off-by:
Roberto Sassu <roberto.sassu@polito.it> Signed-off-by:
Mimi Zohar <zohar@us.ibm.com> Signed-off-by:
-
Ian Campbell authored
commit 9e7860ce upstream. Haogang Chen found out that: There is a potential integer overflow in process_msg() that could result in cross-domain attack. body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH); When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent call to xb_read() would write to a zero-length buffer. The other end of this connection is always the xenstore backend daemon so there is no guest (malicious or otherwise) which can do this. The xenstore daemon is a trusted component in the system. However this seem like a reasonable robustness improvement so we should have it. And Ian when read the API docs found that: The payload length (len field of the header) is limited to 4096 (XENSTORE_PAYLOAD_MAX) in both directions. If a client exceeds the limit, its xenstored connection will be immediately killed by xenstored, which is usually catastrophic from the client's point of view. Clients (particularly domains, which cannot just reconnect) should avoid this. so this patch checks against that instead. This also avoids a potential integer overflow pointed out by Haogang Chen. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Cc: Haogang Chen <haogangchen@gmail.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Eric W. Biederman authored
commit a776c491 upstream. I traced a nasty kexec on panic boot failure to the fact that we had screaming msi interrupts and we were not disabling the msi messages at kernel startup. The booting kernel had not enabled those interupts so was not prepared to handle them. I can see no reason why we would ever want to leave the msi interrupts enabled at boot if something else has enabled those interrupts. The pci spec specifies that msi interrupts should be off by default. Drivers are expected to enable the msi interrupts if they want to use them. Our interrupt handling code reprograms the interrupt handlers at boot and will not be be able to do anything useful with an unexpected interrupt. This patch applies cleanly all of the way back to 2.6.32 where I noticed the problem. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Alex Williamson authored
commit 1830ea91 upstream. Spec shows this as 1010b = 0xa Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Artem Bityutskiy authored
commit e57e0d8e upstream. When we fail to erase a PEB, we free the corresponding erase entry object, but then re-schedule this object if the error code was something like -EAGAIN. Obviously, it is a bug to use the object after we have freed it. Reported-by:
Emese Revfy <re.emese@gmail.com> Signed-off-by:
-
Chase Douglas authored
commit e46e927b upstream. This allows the latest N-Trig devices to function properly. BugLink: https://bugs.launchpad.net/bugs/724831Signed-off-by:
Chase Douglas <chase.douglas@canonical.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Takashi Iwai authored
commit 3a90274d upstream. When an invalid NID is given, get_wcaps() returns zero as the error, but get_wcaps_type() takes it as the normal value and returns a bogus AC_WID_AUD_OUT value. This confuses the parser. With this patch, get_wcaps_type() returns -1 when value 0 is given, i.e. an invalid NID is passed to get_wcaps(). Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Pavel Hofman authored
commit e7848163 upstream. Cards with identical PCI ids but no AC97 config in EEPROM do not have the ac97 field initialized. We must check for this case to avoid kernel oops. Signed-off-by:
Pavel Hofman <pavel.hofman@ivitera.com> Signed-off-by:
-
Karsten Wiese authored
commit d0f3a2eb upstream. They are not needed here. Signed-off-by:
Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by:
-
Xi Wang authored
commit d50f2ab6 upstream. Commit 503358ae ("ext4: avoid divide by zero when trying to mount a corrupted file system") fixes CVE-2009-4307 by performing a sanity check on s_log_groups_per_flex, since it can be set to a bogus value by an attacker. sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex; groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex < 2) { ... } This patch fixes two potential issues in the previous commit. 1) The sanity check might only work on architectures like PowerPC. On x86, 5 bits are used for the shifting amount. That means, given a large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36 is essentially 1 << 4 = 16, rather than 0. This will bypass the check, leaving s_log_groups_per_flex and groups_per_flex inconsistent. 2) The sanity check relies on undefined behavior, i.e., oversized shift. A standard-confirming C compiler could rewrite the check in unexpected ways. Consider the following equivalent form, assuming groups_per_flex is unsigned for simplicity. groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex == 0 || groups_per_flex == 1) { We compile the code snippet using Clang 3.0 and GCC 4.6. Clang will completely optimize away the check groups_per_flex == 0, leaving the patched code as vulnerable as the original. GCC keeps the check, but there is no guarantee that future versions will do the same. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
- 12 Jan, 2012 21 commits
-
-
Greg Kroah-Hartman authored
-
Xi Wang authored
commit 093019cf upstream. Commit fa8b18ed didn't prevent the integer overflow and possible memory corruption. "count" can go negative and bypass the check. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Christoph Hellwig authored
commit fa8b18ed upstream. This prevents in-memory corruption and possible panics if the on-disk ACL is badly corrupted. Signed-off-by:
-
Moger, Babu authored
commit a18a920c upstream. This patch validates sdev pointer in scsi_dh_activate before proceeding further. Without this check we might see the panic as below. I have seen this panic multiple times.. Call trace: #0 [ffff88007d647b50] machine_kexec at ffffffff81020902 #1 [ffff88007d647ba0] crash_kexec at ffffffff810875b0 #2 [ffff88007d647c70] oops_end at ffffffff8139c650 #3 [ffff88007d647c90] __bad_area_nosemaphore at ffffffff8102dd15 #4 [ffff88007d647d50] page_fault at ffffffff8139b8cf [exception RIP: scsi_dh_activate+0x82] RIP: ffffffffa0041922 RSP: ffff88007d647e00 RFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000093c5 RDX: 00000000000093c5 RSI: ffffffffa02e6640 RDI: ffff88007cc88988 RBP: 000000000000000f R8: ffff88007d646000 R9: 0000000000000000 R10: ffff880082293790 R11: 00000000ffffffff R12: ffff88007cc88988 R13: 0000000000000000 R14: 0000000000000286 R15: ffff880037b845e0 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000 #5 [ffff88007d647e38] run_workqueue at ffffffff81060268 #6 [ffff88007d647e78] worker_thread at ffffffff81060386 #7 [ffff88007d647ee8] kthread at ffffffff81064436 #8 [ffff88007d647f48] kernel_thread at ffffffff81003fba Signed-off-by:
Babu Moger <babu.moger@netapp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Srivatsa S. Bhat authored
commit 79cfbdfa upstream. The CPU hotplug notifications sent out by the _cpu_up() and _cpu_down() functions depend on the value of the 'tasks_frozen' argument passed to them (which indicates whether tasks have been frozen or not). (Examples for such CPU hotplug notifications: CPU_ONLINE, CPU_ONLINE_FROZEN, CPU_DEAD, CPU_DEAD_FROZEN). Thus, it is essential that while the callbacks for those notifications are running, the state of the system with respect to the tasks being frozen or not remains unchanged, *throughout that duration*. Hence there is a need for synchronizing the CPU hotplug code with the freezer subsystem. Since the freezer is involved only in the Suspend/Hibernate call paths, this patch hooks the CPU hotplug code to the suspend/hibernate notifiers PM_[SUSPEND|HIBERNATE]_PREPARE and PM_POST_[SUSPEND|HIBERNATE] to prevent the race between CPU hotplug and freezer, thus ensuring that CPU hotplug notifications will always be run with the state of the system really being what the notifications indicate, _throughout_ their execution time. Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Aurelien Jacobs authored
commit 6c15d74d upstream. At this point if skb->len happens to be 2, the subsequant skb_pull(skb, 4) call won't work and the skb->len won't be decreased and won't ever reach 0, resulting in an infinite loop. With an ASIX 88772 under heavy load, without this patch, rx_fixup() reaches an infinite loop in less than a minute. With this patch applied, no infinite loop even after hours of heavy load. Signed-off-by:
Aurelien Jacobs <aurel@gnuage.org> Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Malte Schröder authored
commit 08e87d0d upstream. Hi, below patch adds the USB-ID of the serial adapters sold by Multiplex RC (www.multiplex-rc.de). Signed-off-by:
Malte Schröder <maltesch@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 694c6301 upstream. Fix regression introduced by commit 507ca9bc ([PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.) which inverted the logic in write_room so that it returns zero when the write urb is actually free. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Oliver Neukum authored
commit 35284b3d upstream. The Guillemot Webcam Hercules Dualpix Exchange camera has been reported with a second ID. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Huajun Li authored
usb: usb-storage doesn't support dynamic id currently, the patch disables the feature to fix an oops commit 1a3a026b upstream. Echo vendor and product number of a non usb-storage device to usb-storage driver's new_id, then plug in the device to host and you will find following oops msg, the root cause is usb_stor_probe1() refers invalid id entry if giving a dynamic id, so just disable the feature. [ 3105.018012] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC [ 3105.018062] CPU 0 [ 3105.018075] Modules linked in: usb_storage usb_libusual bluetooth dm_crypt binfmt_misc snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep hp_wmi ppdev sparse_keymap snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse snd serio_raw tpm_infineon soundcore i915 snd_page_alloc tpm_tis parport_pc tpm tpm_bios drm_kms_helper drm i2c_algo_bit video lp parport usbhid hid sg sr_mod sd_mod ehci_hcd uhci_hcd usbcore e1000e usb_common floppy [ 3105.018408] [ 3105.018419] Pid: 189, comm: khubd Tainted: G I 3.2.0-rc7+ #29 Hewlett-Packard HP Compaq dc7800p Convertible Minitower/0AACh [ 3105.018481] RIP: 0010:[<ffffffffa045830d>] [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20 [usb_storage] [ 3105.018536] RSP: 0018:ffff880056a3d830 EFLAGS: 00010286 [ 3105.018562] RAX: ffff880065f4e648 RBX: ffff88006bb28000 RCX: 0000000000000000 [ 3105.018597] RDX: ffff88006f23c7b0 RSI: 0000000000000001 RDI: 0000000000000206 [ 3105.018632] RBP: ffff880056a3d900 R08: 0000000000000000 R09: ffff880067365000 [ 3105.018665] R10: 00000000000002ac R11: 0000000000000010 R12: ffff6000b41a7340 [ 3105.018698] R13: ffff880065f4ef60 R14: ffff88006bb28b88 R15: ffff88006f23d270 [ 3105.018733] FS: 0000000000000000(0000) GS:ffff88007a200000(0000) knlGS:0000000000000000 [ 3105.018773] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3105.018801] CR2: 00007fc99c8c4650 CR3: 0000000001e05000 CR4: 00000000000006f0 [ 3105.018835] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3105.018870] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 3105.018906] Process khubd (pid: 189, threadinfo ffff880056a3c000, task ffff88005677a400) [ 3105.018945] Stack: [ 3105.018959] 0000000000000000 0000000000000000 ffff880056a3d8d0 0000000000000002 [ 3105.019011] 0000000000000000 ffff880056a3d918 ffff880000000000 0000000000000002 [ 3105.019058] ffff880056a3d8d0 0000000000000012 ffff880056a3d8d0 0000000000000006 [ 3105.019105] Call Trace: [ 3105.019128] [<ffffffffa0458cd4>] storage_probe+0xa4/0xe0 [usb_storage] [ 3105.019173] [<ffffffffa0097822>] usb_probe_interface+0x172/0x330 [usbcore] [ 3105.019211] [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0 [ 3105.019243] [<ffffffff815fdd43>] __device_attach+0x73/0x90 [ 3105.019272] [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110 [ 3105.019303] [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0 [ 3105.019334] [<ffffffff815fd6c7>] device_attach+0xf7/0x120 [ 3105.019364] [<ffffffff815fc905>] bus_probe_device+0x45/0x80 [ 3105.019396] [<ffffffff815f98a6>] device_add+0x876/0x990 [ 3105.019434] [<ffffffffa0094e42>] usb_set_configuration+0x822/0x9e0 [usbcore] [ 3105.019479] [<ffffffffa00a3492>] generic_probe+0x62/0xf0 [usbcore] [ 3105.019518] [<ffffffffa0097a46>] usb_probe_device+0x66/0xb0 [usbcore] [ 3105.019555] [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0 [ 3105.019589] [<ffffffff815fdd43>] __device_attach+0x73/0x90 [ 3105.019617] [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110 [ 3105.019648] [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0 [ 3105.019680] [<ffffffff815fd6c7>] device_attach+0xf7/0x120 [ 3105.019709] [<ffffffff815fc905>] bus_probe_device+0x45/0x80 [ 3105.021040] usb usb6: usb auto-resume [ 3105.021045] usb usb6: wakeup_rh [ 3105.024849] [<ffffffff815f98a6>] device_add+0x876/0x990 [ 3105.025086] [<ffffffffa0088987>] usb_new_device+0x1e7/0x2b0 [usbcore] [ 3105.025086] [<ffffffffa008a4d7>] hub_thread+0xb27/0x1ec0 [usbcore] [ 3105.025086] [<ffffffff810d5200>] ? wake_up_bit+0x50/0x50 [ 3105.025086] [<ffffffffa00899b0>] ? usb_remote_wakeup+0xa0/0xa0 [usbcore] [ 3105.025086] [<ffffffff810d49b8>] kthread+0xd8/0xf0 [ 3105.025086] [<ffffffff81939884>] kernel_thread_helper+0x4/0x10 [ 3105.025086] [<ffffffff8192a8c0>] ? _raw_spin_unlock_irq+0x50/0x80 [ 3105.025086] [<ffffffff8192b1b4>] ? retint_restore_args+0x13/0x13 [ 3105.025086] [<ffffffff810d48e0>] ? __init_kthread_worker+0x80/0x80 [ 3105.025086] [<ffffffff81939880>] ? gs_change+0x13/0x13 [ 3105.025086] Code: 00 48 83 05 cd ad 00 00 01 48 83 05 cd ad 00 00 01 4c 8b ab 30 0c 00 00 48 8b 50 08 48 83 c0 30 48 89 45 a0 4c 89 a3 40 0c 00 00 <41> 0f b6 44 24 10 48 89 55 a8 3c ff 0f 84 b8 04 00 00 48 83 05 [ 3105.025086] RIP [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20 [usb_storage] [ 3105.025086] RSP <ffff880056a3d830> [ 3105.060037] hub 6-0:1.0: hub_resume [ 3105.062616] usb usb5: usb auto-resume [ 3105.064317] ehci_hcd 0000:00:1d.7: resume root hub [ 3105.094809] ---[ end trace a7919e7f17c0a727 ]--- [ 3105.130069] hub 5-0:1.0: hub_resume [ 3105.132131] usb usb4: usb auto-resume [ 3105.132136] usb usb4: wakeup_rh [ 3105.180059] hub 4-0:1.0: hub_resume [ 3106.290052] usb usb6: suspend_rh (auto-stop) [ 3106.290077] usb usb4: suspend_rh (auto-stop) Signed-off-by:
Huajun Li <huajun.li.lee@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 59bf5cf9 upstream. We were sending data on the stack when uploading firmware, which causes some machines fits, and is not allowed. Fix this by using the buffer we already had around for this very purpose. Reported-by:
Wouter M. Koolen <wmkoolen@cwi.nl> Tested-by:
-
Julia Lawall authored
commit e7c8e860 upstream. On some failures, the country_code field of an acm structure is freed without freeing the acm structure itself. Elsewhere, operations including memcpy and kfree are performed on the country_code field. The patch sets the country_code field to NULL when it is freed, and likewise sets the country_code_size field to 0. Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
-
Alan Stern authored
commit d8cae98c upstream. The documentation for usbmon is out of date; the usbfs "devices" file now exists in /sys/kernel/debug/usb rather than /proc/bus/usb. This patch (as1505) updates the documentation accordingly, and also mentions that the necessary information can be found by running lsusb. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Jeff Mahoney authored
commit a9e36da6 upstream. This patch fixes a crash in reiserfs_delete_xattrs during umount. When shrink_dcache_for_umount clears the dcache from generic_shutdown_super, delayed evictions are forced to disk. If an evicted inode has extended attributes associated with it, it will need to walk the xattr tree to locate and remove them. But since shrink_dcache_for_umount will BUG if it encounters active dentries, the xattr tree must be released before it's called or it will crash during every umount. This patch forces the evictions to occur before generic_shutdown_super by calling shrink_dcache_sb first. The additional evictions caused by the removal of each associated xattr file and dir will be automatically handled as they're added to the LRU list. CC: reiserfs-devel@vger.kernel.org Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jan Kara authored
commit a06d789b upstream. When jqfmt mount option is not specified on remount, we mistakenly clear s_jquota_fmt value stored in superblock. Fix the problem. CC: reiserfs-devel@vger.kernel.org Signed-off-by:
-
Aurelien Jacobs authored
commit e8303a3b upstream. Adds the device id needed for the USB Ethernet Adapter delivered by ASUS with their Zenbook. Signed-off-by:
Grant Grundler <grundler@chromium.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit c055fe07 upstream. We used to try to request 8 times more vram than needed, which would fail if the card has a too small BAR (observed with qemu & kvm). Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 1bb0b7d2 upstream. When using a >8bpp framebuffer, offb advertises truecolor, not directcolor, and doesn't touch the color map even if it has a corresponding access method for the real hardware. Thus it needs to set the pseudo-palette with all 3 components of the color, like other truecolor framebuffers, not with copies of the color index like a directcolor framebuffer would do. This went unnoticed for a long time because it's pretty hard to get offb to kick in with anything but 8bpp (old BootX under MacOS will do that and qemu does it). Signed-off-by:
-
Neil Horman authored
commit eea915bb upstream. This oops was reported recently: firmware_loading_store+0xf9/0x17b dev_attr_store+0x20/0x22 sysfs_write_file+0x101/0x134 vfs_write+0xac/0xf3 sys_write+0x4a/0x6e system_call_fastpath+0x16/0x1b The complete backtrace was unfortunately not captured, but details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=769920 The cause is fairly clear. Its caused by the fact that firmware_loading_store has a case 0 in its switch statement that reads and writes the fw_priv->fw poniter without the protection of the fw_lock mutex. since there is a window between the time that _request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs file is unregistered, its possible for a user space application to race in, and write a zero to the loading file, causing a NULL dereference in firmware_loading_store. Fix it by extending the protection of the fw_lock mutex to cover all of the firware_loading_store function. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Joe Perches authored
commit 2eb7f204 upstream. The Japanese/Korean/Chinese versions still need updating. Also, the stable kernel 2.6.x.y descriptions are out of date and should be updated as well. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
commit bc7a2f3a upstream. The old address hasn't worked since the great intrusion of August 2011. Signed-off-by:
-
- 06 Jan, 2012 3 commits
-
-
Greg Kroah-Hartman authored
-
Mohammed Shafi Shajakhan authored
commit b25bfda3 upstream. don't do aggregation related stuff for 'AP mode client power save handling' if aggregation is not enabled in the driver, otherwise it will lead to panic because those data structures won't be never intialized in 'ath_tx_node_init' if aggregation is disabled EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k] EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000 ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860 task.ti=f40dc000) Stack: 0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac f40e1cb0 f8186741 f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001 c0b4ba43 00000000 0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac f2a30000 00010020 Call Trace: [<f8186741>] ath9k_sta_notify+0x41/0x50 [ath9k] [<f8186700>] ? ath9k_get_survey+0x110/0x110 [ath9k] [<f922988d>] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350 [mac80211] [<c018dc75>] ? __module_address+0x95/0xb0 [<f92465b3>] ap_sta_ps_end+0x63/0xa0 [mac80211] [<f9246746>] ieee80211_rx_h_sta_process+0x156/0x2b0 [mac80211] [<f9247d1e>] ieee80211_rx_handlers+0xce/0x510 [mac80211] [<c018440b>] ? trace_hardirqs_on+0xb/0x10 [<c056936e>] ? skb_queue_tail+0x3e/0x50 [<f9248271>] ieee80211_prepare_and_rx_handle+0x111/0x750 [mac80211] [<f9248bf9>] ieee80211_rx+0x349/0xb20 [mac80211] [<f9248949>] ? ieee80211_rx+0x99/0xb20 [mac80211] [<f818b0b8>] ath_rx_tasklet+0x818/0x1d00 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187b33>] ath9k_tasklet+0xf3/0x1c0 [ath9k] [<c0151b7e>] tasklet_action+0xbe/0x180 Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Reported-by:
Ashwin Mendonca <ashwinloyal@gmail.com> Tested-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Mandeep Singh Baines authored
commit f9fab10b upstream. vfork parent uninterruptibly and unkillably waits for its child to exec/exit. This wait is of unbounded length. Ignore such waits in the hung_task detector. Signed-off-by:
Mandeep Singh Baines <msb@chromium.org> Reported-by:
Sasha Levin <levinsasha928@gmail.com> LKML-Reference: <1325344394.28904.43.camel@lappy> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Kacur <jkacur@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
