user/sven/linux.git/drivers/char, branch v3.10.36

raw: test against runtime value of max_raw_minors

2014-02-22T20:41:27Z

commit 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf upstream. bind_get() checks the device number it is called with. It uses MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile time while the actual number of raw devices can be set at runtime. This means the test can either be too strict or too lenient. And if the test ends up being too lenient bind_get() might try to access memory beyond what was allocated for "raw_devices". So check against the runtime value (max_raw_minors) in this function. Signed-off-by: Paul Bolle Acked-by: Jan Kara Signed-off-by: Greg Kroah-Hartman

tpm/tpm_ppi: Do not compare strcmp(a,b) == -1

2014-02-06T19:08:15Z

commit 747d35bd9bb4ae6bd74b19baa5bbe32f3e0cee11 upstream. Depending on the implementation strcmp might return the difference between two strings not only -1,0,1 consequently if (strcmp (a,b) == -1) might lead to taking the wrong branch -> compare with < 0 instead, which in any case is more canonical. Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman

tpm/tpm_i2c_stm_st33: Check return code of get_burstcount

2014-02-06T19:08:15Z

commit 85c5e0d451125c6ddb78663972e40af810b83644 upstream. The 'get_burstcount' function can in some circumstances 'return -EBUSY' which in tpm_stm_i2c_send is stored in an 'u32 burstcnt' thus converting the signed value into an unsigned value, resulting in 'burstcnt' being huge. Changing the type to u32 only does not solve the problem as the signed value is converted to an unsigned in I2C_WRITE_DATA, resulting in the same effect. Thus -> Change type of burstcnt to u32 (the return type of get_burstcount) -> Add a check for the return value of 'get_burstcount' and propagate a potential error. This makes also sense in the 'I2C_READ_DATA' case, where the there is no signed/unsigned conversion. found by coverity Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman

ACPI / TPM: fix memory leak when walking ACPI namespace

2014-01-15T23:28:52Z

commit df45c712d1f4ef37714245fb75de726f4ca2bf8d upstream. In function ppi_callback(), memory allocated by acpi_get_name() will get leaked when current device isn't the desired TPM device, so fix the memory leak. Signed-off-by: Jiang Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

drivers/char/i8k.c: add Dell XPLS L421X

2013-12-12T06:36:29Z

commit 9aa5b0181bdf335f0b731d8502e128a862884bcd upstream. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=60772 Signed-off-by: Alan Cox Reported-by: Leho Kraav Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

random: run random_int_secret_init() run after all late_initcalls

2013-10-18T14:45:44Z

commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream. The some platforms (e.g., ARM) initializes their clocks as late_initcalls for some unknown reason. So make sure random_int_secret_init() is run after all of the late_initcalls are run. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

virtio: console: return -ENODEV on all read operations after unplug

2013-08-15T05:59:09Z

commit 96f97a83910cdb9d89d127c5ee523f8fc040a804 upstream. If a port gets unplugged while a user is blocked on read(), -ENODEV is returned. However, subsequent read()s returned 0, indicating there's no host-side connection (but not indicating the device went away). This also happened when a port was unplugged and the user didn't have any blocking operation pending. If the user didn't monitor the SIGIO signal, they won't have a chance to find out if the port went away. Fix by returning -ENODEV on all read()s after the port gets unplugged. write() already behaves this way. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman

virtio: console: fix raising SIGIO after port unplug

2013-08-15T05:59:08Z

commit 92d3453815fbe74d539c86b60dab39ecdf01bb99 upstream. SIGIO should be sent when a port gets unplugged. It should only be sent to prcesses that have the port opened, and have asked for SIGIO to be delivered. We were clearing out guest_connected before calling send_sigio_to_port(), resulting in a sigio not getting sent to processes. Fix by setting guest_connected to false after invoking the sigio function. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman

virtio: console: clean up port data immediately at time of unplug

2013-08-15T05:59:08Z

commit ea3768b4386a8d1790f4cc9a35de4f55b92d6442 upstream. We used to keep the port's char device structs and the /sys entries around till the last reference to the port was dropped. This is actually unnecessary, and resulted in buggy behaviour: 1. Open port in guest 2. Hot-unplug port 3. Hot-plug a port with the same 'name' property as the unplugged one This resulted in hot-plug being unsuccessful, as a port with the same name already exists (even though it was unplugged). This behaviour resulted in a warning message like this one: -------------------8<--------------------------------------- WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) Hardware name: KVM sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1' Call Trace: [] ? warn_slowpath_common+0x87/0xc0 [] ? warn_slowpath_fmt+0x46/0x50 [] ? sysfs_add_one+0xc9/0x130 [] ? create_dir+0x68/0xb0 [] ? sysfs_create_dir+0x39/0x50 [] ? kobject_add_internal+0xb9/0x260 [] ? kobject_add_varg+0x38/0x60 [] ? kobject_add+0x44/0x70 [] ? get_device_parent+0xf4/0x1d0 [] ? device_add+0xc9/0x650 -------------------8<--------------------------------------- Instead of relying on guest applications to release all references to the ports, we should go ahead and unregister the port from all the core layers. Any open/read calls on the port will then just return errors, and an unplug/plug operation on the host will succeed as expected. This also caused buggy behaviour in case of the device removal (not just a port): when the device was removed (which means all ports on that device are removed automatically as well), the ports with active users would clean up only when the last references were dropped -- and it would be too late then to be referencing char device pointers, resulting in oopses: -------------------8<--------------------------------------- PID: 6162 TASK: ffff8801147ad500 CPU: 0 COMMAND: "cat" #0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322 #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50 #3 [ffff88011b9d5bf0] die at ffffffff8100f26b #4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2 #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5 [exception RIP: strlen+2] RIP: ffffffff81272ae2 RSP: ffff88011b9d5d00 RFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880118901c18 RCX: 0000000000000000 RDX: ffff88011799982c RSI: 00000000000000d0 RDI: 3a303030302f3030 RBP: ffff88011b9d5d38 R8: 0000000000000006 R9: ffffffffa0134500 R10: 0000000000001000 R11: 0000000000001000 R12: ffff880117a1cc10 R13: 00000000000000d0 R14: 0000000000000017 R15: ffffffff81aff700 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551 #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb #9 [ffff88011b9d5de0] device_del at ffffffff813440c7 -------------------8<--------------------------------------- So clean up when we have all the context, and all that's left to do when the references to the port have dropped is to free up the port struct itself. Reported-by: chayang Reported-by: YOGANANTH SUBRAMANIAN Reported-by: FuXiangChun Reported-by: Qunfang Zhang Reported-by: Sibiao Luo Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman

virtio: console: fix race in port_fops_open() and port unplug

2013-08-15T05:59:08Z

commit 671bdea2b9f210566610603ecbb6584c8a201c8c upstream. Between open() being called and processed, the port can be unplugged. Check if this happened, and bail out. A simple test script to reproduce this is: while true; do for i in $(seq 1 100); do echo $i > /dev/vport0p3; done; done; This opens and closes the port a lot of times; unplugging the port while this is happening triggers the bug. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman