lwn.git, branch v3.12.38

Linux 3.12.38

2015-02-16T15:15:42+00:00

iscsi_ibft: Fix finding Broadcom specific ibft sign

2015-02-16T15:11:00+00:00

commit 629c27aa0c930b9c67188cfc625bf6cdd2af6764 upstream. Search for Broadcom specific ibft sign "BIFT" along with other possible values on UEFI This patch is fix for regression introduced in “935a9fee51c945b8942be2d7b4bae069167b4886”. https://lkml.org/lkml/2011/12/16/353 This impacts Broadcom CNA for iSCSI Boot on UEFI platform. Signed-off-by: Vikas Chaudhary Signed-off-by: Konrad Rzeszutek Wilk Acked-by: Mike Christie Signed-off-by: Jiri Slaby

ACPI: Fix bug when ACPI reset register is implemented in system memory

2015-02-16T15:11:00+00:00

commit a4714a898e85205e1118ec923cde43d88eb105f6 upstream. Use acpi_os_map_generic_address to pre-map the reset register if it is memory mapped, thereby preventing the BUG_ON() in line 1319 of mm/vmalloc.c from triggering during panic-triggered reboots. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77131 Signed-off-by: Randy Wright Signed-off-by: David E. Box [rjw: Changelog, simplified code] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby

x86: UV BAU: Avoid NULL pointer reference in ptc_seq_show

2015-02-16T15:10:59+00:00

commit fa2a79ce6aef5de35a4d50487da35deb6b634944 upstream. In init_per_cpu(), when get_cpu_topology() fails, init_per_cpu_tunables() is not called afterwards. This means that bau_control->statp is NULL. If a user then reads /proc/sgi_uv/ptc_statistics ptc_seq_show() references a NULL pointer. Therefore, since uv_bau_init calls set_bau_off when init_per_cpu() fails, we add code that detects when the bau is off in ptc_seq_show() to avoid referencing a NULL pointer. Signed-off-by: James Custer Cc: Russ Anderson Link: http://lkml.kernel.org/r/1414952199-185319-2-git-send-email-jcuster@sgi.com Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby

SELinux: fix selinuxfs policy file on big endian systems

2015-02-16T15:10:58+00:00

commit b138004ea0382bdc6d02599c39392651b4f63889 upstream. The /sys/fs/selinux/policy file is not valid on big endian systems like ppc64 or s390. Let's see why: static int hashtab_cnt(void *key, void *data, void *ptr) { int *cnt = ptr; *cnt = *cnt + 1; return 0; } static int range_write(struct policydb *p, void *fp) { size_t nel; [...] /* count the number of entries in the hashtab */ nel = 0; rc = hashtab_map(p->range_tr, hashtab_cnt, &nel); if (rc) return rc; buf[0] = cpu_to_le32(nel); rc = put_entry(buf, sizeof(u32), 1, fp); So size_t is 64 bits. But then we pass a pointer to it as we do to hashtab_cnt. hashtab_cnt thinks it is a 32 bit int and only deals with the first 4 bytes. On x86_64 which is little endian, those first 4 bytes and the least significant, so this works out fine. On ppc64/s390 those first 4 bytes of memory are the high order bits. So at the end of the call to hashtab_map nel has a HUGE number. But the least significant 32 bits are all 0's. We then pass that 64 bit number to cpu_to_le32() which happily truncates it to a 32 bit number and does endian swapping. But the low 32 bits are all 0's. So no matter how many entries are in the hashtab, big endian systems always say there are 0 entries because I screwed up the counting. The fix is easy. Use a 32 bit int, as the hashtab_cnt expects, for nel. Signed-off-by: Eric Paris Signed-off-by: Paul Moore Signed-off-by: Jiri Slaby

dm: do not call dm_sync_table() when creating new devices

2015-02-16T15:10:58+00:00

commit 41abc4e1af369bb5438eaee398e3beee690cc8ca upstream. When creating new devices dm_sync_table() calls synchronize_rcu_expedited(), causing _all_ pending RCU pointers to be flushed. This causes a latency overhead that is especially noticeable when creating lots of devices. And all of this is pointless as there are no old maps to be disconnected, and hence no stale pointers which would need to be cleared up. Signed-off-by: Hannes Reinecke Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby

parport: parport_pc, do not remove parent devices early

2015-02-16T15:10:57+00:00

commit 91905b6f4afe51e23a3f58df93e4cdc5e49cf40c upstream. When the parport_pc module is removed from the system, all parport devices are iterated in parport_pc_exit and removed by a call to parport_pc_unregister_port. Note that some parport devices have its 'struct device' parent, known as port->dev. And when port->dev is a platform device, it is destroyed in parport_pc_exit too. Now, when parport_pc_unregister_port is called for a going port, drv->detach(port) is called for every parport driver in the system. ppdev can be one of them. ppdev's detach() tears down its per-port sysfs directory, which established port->dev as a parent earlier. But since parport_pc_exit kills port->dev parents before unregisters ports proper, ppdev's sysfs directory has no living parent anymore. This results in the following warning: WARNING: CPU: 1 PID: 785 at fs/sysfs/group.c:219 sysfs_remove_group+0x9b/0xa0 sysfs group ffffffff81c69e20 not found for kobject 'parport1' Modules linked in: parport_pc(E-) ppdev(E) [last unloaded: ppdev] CPU: 1 PID: 785 Comm: rmmod Tainted: G W E 3.18.0-rc5-next-20141120+ #824 ... Call Trace: ... [] warn_slowpath_fmt+0x46/0x50 [] sysfs_remove_group+0x9b/0xa0 [] dpm_sysfs_remove+0x57/0x60 [] device_del+0x49/0x240 [] device_unregister+0x22/0x70 [] device_destroy+0x3c/0x50 [] pp_detach+0x4a/0x60 [ppdev] [] parport_remove_port+0x11d/0x150 [] parport_pc_unregister_port+0x28/0xf0 [parport_pc] [] parport_pc_exit+0x76/0x468 [parport_pc] [] SyS_delete_module+0x18c/0x230 It is also easily reproducible on qemu with two dummy ports '-parallel /dev/null -parallel /dev/null'. So switch the order of killing the two structures. But since port is freed by parport_pc_unregister_port, we have to remember port->dev in a local variable. Perhaps nothing worse than the warning happens thanks to the device refcounting. We *should* be on the safe side. Signed-off-by: Jiri Slaby Reviewed-by: Takashi Iwai Tested-by: Martin Pluskal Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

x86/early quirk: use gen6 stolen detection for VLV

2015-02-16T15:10:57+00:00

commit 7bd40c16ccb2cb6877dd00b0e66249c171e6fa43 upstream. We've always been able to use either method on VLV, but it appears more recent BIOSes only support the gen6 method, so switch over to that. References: https://bugs.freedesktop.org/show_bug.cgi?id=71370 Signed-off-by: Jesse Barnes Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Jiri Slaby

udf: Check component length before reading it

2015-02-16T15:10:56+00:00

commit e237ec37ec154564f8690c5bd1795339955eeef9 upstream. Check that length specified in a component of a symlink fits in the input buffer we are reading. Also properly ignore component length for component types that do not use it. Otherwise we read memory after end of buffer for corrupted udf image. Reported-by: Carl Henrik Lunde CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby

udf: Check path length when reading symlink

2015-02-16T15:10:55+00:00

commit 0e5cc9a40ada6046e6bc3bdfcd0c0d7e4b706b14 upstream. Symlink reading code does not check whether the resulting path fits into the page provided by the generic code. This isn't as easy as just checking the symlink size because of various encoding conversions we perform on path. So we have to check whether there is still enough space in the buffer on the fly. CC: stable@vger.kernel.org Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby