- 20 Mar, 2013 8 commits
-
-
Bjørn Mork authored
commit ab4b7164 upstream. This reverts commit 200e0d99 ("USB: storage: optimize to match the Huawei USB storage devices and support new switch command" and the followup bugfix commit cd060956 ("USB: storage: properly handle the endian issues of idProduct"). The commit effectively added a large number of Huawei devices to the deprecated usb-storage mode switching logic. Many of these devices have been in use and supported by the userspace usb_modeswitch utility for years. Forcing the switching inside the kernel causes a number of regressions as a result of ignoring existing onfigurations, and also completely takes away the ability to configure mode switching per device/system/user. Known regressions caused by this: - Some of the devices support multiple modes, using different switching commands. There are existing configurations taking advantage of this. - There is a real use case for disabling mode switching and instead mounting the exposed storage device. This becomes impossible with switching logic inside the usb-storage driver. - At least on device fail as a result of the usb-storage switching command, becoming completely unswitchable. This is possibly a firmware bug, but still a regression because the device work as expected using usb_modeswitch defaults. In-kernel mode switching was deprecated years ago with the development of the more user friendly userspace alternatives. The existing list of devices in usb-storage was only kept to prevent breaking already working systems. The long term plan is to remove the list, not to add to it. Ref: http://permalink.gmane.org/gmane.linux.usb.general/28543Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: <fangxiaozhi@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Steve Conklin authored
commit a57e82a1 upstream. The Rigblaster Advantage is an amateur radio interface sold by West Mountain Radio. It contains a cp210x serial interface but the device ID is not in the driver. Signed-off-by:
Steve Conklin <sconklin@canonical.com> Signed-off-by:
-
Christian Schmiedl authored
commit 1941138e upstream. add support for Cinterion's products AH6 and PLS8 by adding Product IDs and USB_DEVICE tuples. Signed-off-by:
Christian Schmiedl <christian.schmiedl@gemalto.com> Signed-off-by:
-
Matwey V. Kornilov authored
commit be3101c2 upstream. This patch adds support for the Lake Shore Cryotronics devices to the CP210x driver. These lines are ported from cp210x driver distributed by Lake Shore web site: http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz and licensed under the terms of GPLv2. Moreover, I've tested this changes with Lake Shore 335 in my labs. Signed-off-by:
Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by:
-
Oliver Neukum authored
commit c0f5ecee upstream. The buffer for responses must not overflow. If this would happen, set a flag, drop the data and return an error after user space has read all remaining data. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Bjørn Mork authored
commit daec90e7 upstream. Another device using CDC ACM with vendor specific protocol to mark serial functions. Signed-off-by:
-
Amit Shah authored
commit e84e7a56 upstream. The code currently only supports one virtio-rng device at a time. Invoking guests with multiple devices causes the guest to blow up. Check if we've already registered and initialised the driver. Also cleanup in case of registration errors or hot-unplug so that a new device can be used. Reported-by:
Peter Krempa <pkrempa@redhat.com> Reported-by: <yunzheng@redhat.com> Signed-off-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Dan Williams authored
commit 2d90e636 upstream. 4 ports; AT/PPP is standard CDC-ACM. The other three (added by this patch) are QCDM/DIAG, possibly GPS, and unknown. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
- 14 Mar, 2013 22 commits
-
-
Greg Kroah-Hartman authored
-
Ben Hutchings authored
commit a40e7cf8 upstream. Commit 9f9c9cbb ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") hoisted the check for "_DMI_" into dmi_scan_machine(), which means that we don't bother to check for "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call dmi_present() for an address where we found "_SM_", if it failed further validation. Check for "_DMI_" in smbios_present() before calling dmi_present(). [akpm@linux-foundation.org: fix build] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Reported-by:
Tim McGrath <tmhikaru@gmail.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Eric W. Biederman authored
When decnet is built as a module a simple: echo 0.0 >/proc/sys/net/decnet/node_address results in most of the sysctl entries under /proc/sys/net/decnet and /proc/sys/net/decnet/conf disappearing. For more details see http://www.spinics.net/lists/netdev/msg226123.html. This change applies the same workaround used in net/core/sysctl_net_core.c and net/ipv6/sysctl_net_ipv6.c of creating a skeleton of decnet sysctl entries before doing anything else. The problem first appeared in kernel 2.6.27. The later rewrite of sysctl in kernel 3.4 restored the previous behavior and eliminated the need for this workaround. This patch was heavily inspired by a similar but more complex patch by Larry Baker. Reported-by:
Larry Baker <baker@usgs.gov> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Acked-by:
David Miller <davem@redhat.com> Signed-off-by:
-
Steven Rostedt authored
commit db05021d upstream. The prompt to enable DYNAMIC_FTRACE (the ability to nop and enable function tracing at run time) had a confusing statement: "enable/disable ftrace tracepoints dynamically" This was written before tracepoints were added to the kernel, but now that tracepoints have been added, this is very confusing and has confused people enough to give wrong information during presentations. Not only that, I looked at the help text, and it still references that dreaded daemon that use to wake up once a second to update the nop locations and brick NICs, that hasn't been around for over five years. Time to bring the text up to the current decade. Reported-by:
Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tu, Xiaobing authored
commit e3773677 upstream. When system enters sleep, non-boot CPUs will be disabled. Cpufreq stats sysfs is created when the CPU is up, but it is not freed when the CPU is going down. This will cause memory leak. Signed-off-by:
xiaobing tu <xiaobing.tu@intel.com> Signed-off-by:
guifang tang <guifang.tang@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Colin Cross <ccross@google.com> Signed-off-by:
-
Al Viro authored
commit a930d879 upstream. If you open a pipe for neither read nor write, the pipe code will not add any usage counters to the pipe, causing the 'struct pipe_inode_info" to be potentially released early. That doesn't normally matter, since you cannot actually use the pipe, but the pipe release code - particularly fasync handling - still expects the actual pipe infrastructure to all be there. And rather than adding NULL pointer checks, let's just disallow this case, the same way we already do for the named pipe ("fifo") case. This is ancient going back to pre-2.4 days, and until trinity, nobody naver noticed. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
David Howells authored
commit 0da9dfdd upstream. This fixes CVE-2013-1792. There is a race in install_user_keyrings() that can cause a NULL pointer dereference when called concurrently for the same user if the uid and uid-session keyrings are not yet created. It might be possible for an unprivileged user to trigger this by calling keyctl() from userspace in parallel immediately after logging in. Assume that we have two threads both executing lookup_user_key(), both looking for KEY_SPEC_USER_SESSION_KEYRING. THREAD A THREAD B =============================== =============================== ==>call install_user_keyrings(); if (!cred->user->session_keyring) ==>call install_user_keyrings() ... user->uid_keyring = uid_keyring; if (user->uid_keyring) return 0; <== key = cred->user->session_keyring [== NULL] user->session_keyring = session_keyring; atomic_inc(&key->usage); [oops] At the point thread A dereferences cred->user->session_keyring, thread B hasn't updated user->session_keyring yet, but thread A assumes it is populated because install_user_keyrings() returned ok. The race window is really small but can be exploited if, for example, thread B is interrupted or preempted after initializing uid_keyring, but before doing setting session_keyring. This couldn't be reproduced on a stock kernel. However, after placing systemtap probe on 'user->session_keyring = session_keyring;' that introduced some delay, the kernel could be crashed reliably. Fix this by checking both pointers before deciding whether to return. Alternatively, the test could be done away with entirely as it is checked inside the mutex - but since the mutex is global, that may not be the best way. Signed-off-by:
David Howells <dhowells@redhat.com> Reported-by:
Mateusz Guzik <mguzik@redhat.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 4e0855df upstream. This patch removes redundant and unbalanced pci_disable_device() from __e1000_shutdown(). pci_clear_master() is enough, device can go into suspended state with elevated enable_cnt. Bug was introduced in commit 23606cf5 ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35 Signed-off-by:
Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Bruce Allan <bruce.w.allan@intel.com> Acked-by:
Borislav Petkov <bp@suse.de> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit 2069d483 upstream. When a value of a vmaster slave control is changed, the ctl change notification is sometimes ignored. This happens when the master control overrides, e.g. when the corresponding master control is muted. The reason is that slave_put() returns the value of the actual slave put callback, and it doesn't reflect the virtual slave value change. This patch fixes the function just to return 1 whenever a slave value is changed. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sean Connor authored
commit 69a4cfdd upstream. Set card->private_data in snd_ice1712_create for fixing NULL dereference in snd_ice1712_remove(). Signed-off-by:
Sean Connor <sconnor004@allyinics.org> Signed-off-by:
-
Alex Deucher authored
commit e8fc4137 upstream. vbios values are wrong leading to colors that are too bright. Use the default values instead. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Mark Brown authored
commit 3e78080f upstream. Not having power is a pretty serious error so check that we are able to enable the supply and error out if we can't. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net>
-
NeilBrown authored
commit 58ebb34c upstream. Create_stripe_zones returns an error slightly differently to raid0_run and to raid0_takeover_*. The error returned used by the second was wrong and an error would result in mddev->private being set to NULL and sooner or later a crash. So never return NULL, return ERR_PTR(err), not NULL from create_stripe_zones. This bug has been present since 2.6.35 so the fix is suitable for any kernel since then. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Felix Fietkau authored
commit a3d63cad upstream. RSSI is being stored internally as s8 in several places. The indication of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been set to 127, but ended up being set to 0x127 because of a code cleanup mistake. This could lead to invalid signal strength values in a few places. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Rusty Russell authored
commit f7f154f1 upstream. virtio_rng feeds the randomness buffer handed by the core directly into the scatterlist, since commit bb347d98. However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address (at least on most archs). We could fix this in virtio_rng, but it's actually far easier to just do it in the core as virtio_rng would have to allocate a buffer every time (it doesn't know how much the core will want to read). Reported-by:
Aurelien Jarno <aurelien@aurel32.net> Tested-by:
-
Trond Myklebust authored
commit a9a6b52e upstream. If the socket is full, we're better off just waiting until it empties, or until the connection is broken. The reason why we generally don't want to time out is that the call to xprt->ops->release_xprt() will trigger a connection reset, which isn't helpful... Let's make an exception for soft RPC calls, since they have to provide timeout guarantees. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Jeff Layton authored
commit ce2ac521 upstream. Kjell Braden reported this oops: [ 833.211970] BUG: unable to handle kernel NULL pointer dereference at (null) [ 833.212816] IP: [< (null)>] (null) [ 833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0 [ 833.213874] Oops: 0010 [#1] SMP [ 833.214344] CPU 0 [ 833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000 [ 833.215629] [ 833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9+ #18 innotek GmbH VirtualBox/VirtualBox [ 833.215629] RIP: 0010:[<0000000000000000>] [< (null)>] (null) [ 833.215629] RSP: 0018:ffff8800119c9c50 EFLAGS: 00010282 [ 833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000 [ 833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8 [ 833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7 [ 833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8 [ 833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6 [ 833.215629] FS: 00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 [ 833.215629] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0 [ 833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0) [ 833.215629] Stack: [ 833.215629] ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286 [ 833.215629] 0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8 [ 833.215629] ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0 [ 833.215629] Call Trace: [ 833.215629] [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90 [ 833.215629] [<ffffffff81178075>] ? d_lookup+0x35/0x60 [ 833.215629] [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0 [ 833.215629] [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0 [ 833.215629] [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20 [ 833.215629] [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs] [ 833.215629] [<ffffffff81163bd3>] mount_fs+0x43/0x1b0 [ 833.215629] [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0 [ 833.215629] [<ffffffff8117e584>] do_kern_mount+0x54/0x110 [ 833.215629] [<ffffffff8117fdc2>] do_mount+0x262/0x840 [ 833.215629] [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50 [ 833.215629] [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180 [ 833.215629] [<ffffffff8118075d>] sys_mount+0x8d/0xe0 [ 833.215629] [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b [ 833.215629] Code: Bad RIP value. [ 833.215629] RIP [< (null)>] (null) [ 833.215629] RSP <ffff8800119c9c50> [ 833.215629] CR2: 0000000000000000 [ 833.238525] ---[ end trace ec00758b8d44f529 ]--- When walking down the path on the server, it's possible to hit a symlink. The path walking code assumes that the caller will handle that situation properly, but cifs_get_root() isn't set up for it. This patch prevents the oops by simply returning an error. A better solution would be to try and chase the symlinks here, but that's fairly complicated to handle. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=53221Reported-and-tested-by:
Kjell Braden <afflux@pentabarf.de> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Thomas Gleixner authored
commit 1cba0cdf upstream. __btrfs_close_devices() clones btrfs device structs with memcpy(). Some of the fields in the clone are reinitialized, but it's missing to init io_lock. In mainline this goes unnoticed, but on RT it leaves the plist pointing to the original about to be freed lock struct. Initialize io_lock after cloning, so no references to the original struct are left. Reported-and-tested-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Chris Mason <chris.mason@fusionio.com> Signed-off-by:
-
Asias He authored
commit 472b72f2 upstream. The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page address if the 'while (len > 0 && data_len > 0) { ... }' loop is executed more than one once. Signed-off-by:
Asias He <asias@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Dan Carpenter authored
commit 208afec4 upstream. This bug was introduced back in bitkeeper days in 2003. We use "dcb->dev_mode" before it has been initialized. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Russell King authored
commit b255188f upstream. Paolo Pisati reports that IPv6 triggers this warning: BUG: scheduling while atomic: swapper/0/0/0x40000100 Modules linked in: [<c001b1c4>] (unwind_backtrace+0x0/0xf0) from [<c0503c5c>] (__schedule_bug+0x48/0x5c) [<c0503c5c>] (__schedule_bug+0x48/0x5c) from [<c0508608>] (__schedule+0x700/0x740) [<c0508608>] (__schedule+0x700/0x740) from [<c007007c>] (__cond_resched+0x24/0x34) [<c007007c>] (__cond_resched+0x24/0x34) from [<c05086dc>] (_cond_resched+0x3c/0x44) [<c05086dc>] (_cond_resched+0x3c/0x44) from [<c0021f6c>] (do_alignment+0x178/0x78c) [<c0021f6c>] (do_alignment+0x178/0x78c) from [<c00083e0>] (do_DataAbort+0x34/0x98) [<c00083e0>] (do_DataAbort+0x34/0x98) from [<c0509a60>] (__dabt_svc+0x40/0x60) Exception stack(0xc0763d70 to 0xc0763db8) 3d60: e97e805e e97e806e 2c000000 11000000 3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c 3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff [<c0509a60>] (__dabt_svc+0x40/0x60) from [<c02a8490>] (__csum_ipv6_magic+0x8/0xc8) Fix this by using probe_kernel_address() stead of __get_user(). Reported-by:
Paolo Pisati <p.pisati@gmail.com> Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
commit 5e4ba617 upstream. Martin Storsjö reports that the sequence: ee312ac1 vsub.f32 s4, s3, s2 ee702ac0 vsub.f32 s5, s1, s0 e59f0028 ldr r0, [pc, #40] ee111a90 vmov r1, s3 on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5) where s3 is a denormal and s2 is zero results in incorrect behaviour - the instruction "vsub.f32 s5, s1, s0" is not executed: VFP: bounce: trigger ee111a90 fpexc d0000780 VFP: emulate: INST=0xee312ac1 SCR=0x00000000 ... As we can see, the instruction triggering the exception is the "vmov" instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to properly take account of the FPEXC_FP2V flag in FPEXC. This is because the test for the second instruction register being valid is bogus, and will always skip emulation of the second instruction. Reported-by:
Martin Storsjö <martin@martin.st> Tested-by:
-
- 03 Mar, 2013 10 commits
-
-
Greg Kroah-Hartman authored
-
Ian Abbott authored
commit cc400e18 upstream. Some low-level comedi drivers (incorrectly) point `dev->read_subdev` or `dev->write_subdev` to a subdevice that does not support asynchronous commands. Comedi's poll(), read() and write() file operation handlers assume these subdevices do support asynchronous commands. In particular, they assume `s->async` is valid (where `s` points to the read or write subdevice), which it won't be if it has been set incorrectly. This can lead to a NULL pointer dereference. Check `s->async` is non-NULL in `comedi_poll()`, `comedi_read()` and `comedi_write()` to avoid the bug. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Ian Abbott authored
Commit 22056e2b upstream. Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting meaningful output from a Lab-PC+ in differential mode for AI cmds, but AI insn reads gave correct readings. He tracked it down to two problems, one of which is addressed by this patch. It seems that writing to the command3 register after writing to the command4 register in `labpc_ai_cmd()` messes up the differential reference bit setting in the command4 register. Set up the command4 register after the command3 register (as in `labpc_ai_rinsn()`) to avoid the problem. Thanks to Tuomas for suggesting the fix. Signed-off-by:
-
Ian Abbott authored
Commit 4c4bc25d upstream. Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting meaningful output from a Lab-PC+ in differential mode for AI cmds, but AI insn reads gave correct readings. He tracked it down to two problems, one of which is addressed by this patch. It seems the setting of the channel bits for particular scanning modes was incorrect for differential mode. (Only half the number of channels are available in differential mode; comedi refers to them as channels 0, 1, 2 and 3, but the hardware documentation refers to them as channels 0, 2, 4 and 6.) In differential mode, the setting of the channel enable bits in the command1 register should depend on whether the scan enable bit is set. Effectively, we need to double the comedi channel number when the scan enable bit is not set in differential mode. The scan enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or `MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is `MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`. The existing test for whether the comedi channel number needs to be doubled in differential mode is incorrect in `labpc_ai_cmd()`. This patch corrects the test. Thanks to Tuomas for suggesting the fix. Signed-off-by:
-
Jiri Slaby authored
In 3.0.67, commit 58c9ce6f (s390/kvm: Fix store status for ACRS/FPRS), upstream commit 15bc8d84, added a call to save_access_regs to save ACRS. But we do not have ARCS in kvm_run in 3.0 yet, so this results in: arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vcpu_store_status': arch/s390/kvm/kvm-s390.c:593: error: 'struct kvm_run' has no member named 's' Fix it by saving guest_acrs which is where ARCS are in 3.0. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Jiri Slaby authored
In 3.0.67, commit 7a9a20ea (dca: check against empty dca_domains list before unregister provider), upstream commit c419fcfd, added a fail path to unregister_dca_provider. It added there also a call to raw_spin_unlock_irqrestore. But in 3.0, the lock is not raw, so this results in: drivers/dca/dca-core.c: In function 'unregister_dca_provider': drivers/dca/dca-core.c:413: warning: passing argument 1 of '_raw_spin_unlock_irqrestore' from incompatible pointer type Fix it by calling spin_unlock_irqrestore properly. Signed-off-by:
-
Li Zefan authored
commit 71b5707e upstream. In cgroup_exit() put_css_set_taskexit() is called without any lock, which might lead to accessing a freed cgroup: thread1 thread2 --------------------------------------------- exit() cgroup_exit() put_css_set_taskexit() atomic_dec(cgrp->count); rmdir(); /* not safe !! */ check_for_release(cgrp); rcu_read_lock() can be used to make sure the cgroup is alive. Signed-off-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Li Zefan authored
commit 63f43f55 upstream. rename() will change dentry->d_name. The result of this race can be worse than seeing partially rewritten name, but we might access a stale pointer because rename() will re-allocate memory to hold a longer name. It's safe in the protection of dentry->d_lock. v2: check NULL dentry before acquiring dentry lock. Signed-off-by:
-
Stoney Wang authored
commit cb214ede upstream. When a HP ProLiant DL980 G7 Server boots a regular kernel, there will be intermittent lost interrupts which could result in a hang or (in extreme cases) data loss. The reason is that this system only supports x2apic physical mode, while the kernel boots with a logical-cluster default setting. This bug can be worked around by specifying the "x2apic_phys" or "nox2apic" boot option, but we want to handle this system without requiring manual workarounds. The BIOS sets ACPI_FADT_APIC_PHYSICAL in FADT table. As all apicids are smaller than 255, BIOS need to pass the control to the OS with xapic mode, according to x2apic-spec, chapter 2.9. Current code handle x2apic when BIOS pass with xapic mode enabled: When user specifies x2apic_phys, or FADT indicates PHYSICAL: 1. During madt oem check, apic driver is set with xapic logical or xapic phys driver at first. 2. enable_IR_x2apic() will enable x2apic_mode. 3. if user specifies x2apic_phys on the boot line, x2apic_phys_probe() will install the correct x2apic phys driver and use x2apic phys mode. Otherwise it will skip the driver will let x2apic_cluster_probe to take over to install x2apic cluster driver (wrong one) even though FADT indicates PHYSICAL, because x2apic_phys_probe does not check FADT PHYSICAL. Add checking x2apic_fadt_phys in x2apic_phys_probe() to fix the problem. Signed-off-by:
Stoney Wang <song-bo.wang@hp.com> [ updated the changelog and simplified the code ] Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Zhang Lin-Bao <Linbao.zhang@hp.com> [ make a patch specially for 3.0.66] Link: http://lkml.kernel.org/r/1360263182-16226-1-git-send-email-yinghai@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Kees Cook authored
commit e575a86f upstream. Without this patch, it is trivial to determine kernel page mappings by examining the error code reported to dmesg[1]. Instead, declare the entire kernel memory space as a violation of a present page. Additionally, since show_unhandled_signals is enabled by default, switch branch hinting to the more realistic expectation, and unobfuscate the setting of the PF_PROT bit to improve readability. [1] http://vulnfactory.org/blog/2013/02/06/a-linux-memory-trick/Reported-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Suggested-by:
Brad Spengler <spender@grsecurity.net> Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
H. Peter Anvin <hpa@zytor.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20130207174413.GA12485@www.outflux.netSigned-off-by:
CAI Qian <caiqian@redhat.com> Signed-off-by:
-
