3.14.41-stable review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 25/92 ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <[email protected]>
commit 4e330ae4ab2915444f1e6dca1358a910aa259362 upstream.
There are two PMICs on Cragganmore, currently one dynamically assign its IRQ base and the other uses a fixed base. It is possible for the statically assigned PMIC to fail if its IRQ is taken by the dynamically assigned one. Fix this by statically assigning both the IRQ bases.
--- arch/arm/mach-s3c64xx/crag6410.h | 1 + arch/arm/mach-s3c64xx/mach-crag6410.c | 1 + 2 files changed, 2 insertions(+)
arch/arm/mach-s3c64xx/crag6410.h +1 -0
@@ -14,6 +14,7 @@#include <mach/gpio-samsung.h> #define GLENFARCLAS_PMIC_IRQ_BASE IRQ_BOARD_START +#define BANFF_PMIC_IRQ_BASE (IRQ_BOARD_START + 64)#define PCA935X_GPIO_BASE GPIO_BOARD_START#define CODEC_GPIO_BASE (GPIO_BOARD_START + 8)
arch/arm/mach-s3c64xx/mach-crag6410.c +1 -0
@@ -555,6 +555,7 @@ static struct wm831x_touch_pdata touch_pstatic struct wm831x_pdata crag_pmic_pdata = { .wm831x_num =1 , + .irq_base =BANFF_PMIC_IRQ_BASE , .gpio_base =BANFF_PMIC_GPIO_BASE , .soft_shutdown = true,
Greg Kroah-Hartman
maintainerPATCH 27/92 ARM: dts: dove: Fix uart[23] reg property
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Hesselbarth <[email protected]>
commit a74cd13b807029397f7232449df929bac11fb228 upstream.
Fix Dove's register addresses of uart2 and uart3 nodes that seem to be broken since ages due to a copy-and-paste error.
--- arch/arm/boot/dts/dove.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/dove.dtsi +2 -2
@@ -154,7 +154,7 @@ uart2: serial@12200 { compatible = "ns16550a"; - reg = <0x12000 0x100>; + reg = <0x12200 0x100>; reg-shift = <2>; interrupts = <9>; clocks = <&core_clk 0>;
@@ -163,7 +163,7 @@ uart3: serial@12300 { compatible = "ns16550a"; - reg = <0x12100 0x100>; + reg = <0x12300 0x100>; reg-shift = <2>; interrupts = <10>; clocks = <&core_clk 0>;
Greg Kroah-Hartman
maintainerPATCH 36/92 usb: host: sl811: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 08debfb13b199716da6153940c31968c556b195d upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/host/sl811-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/sl811-hcd.c +1 -1
@@ -1259,7 +1259,7 @@ sl811h_hub_control(sl811_write (sl811,SL11H_CTLREG1 , sl811->ctrl1);mod_timer (&sl811->timer, jiffies - +msecs_to_jiffies (20 )); + +msecs_to_jiffies (USB_RESUME_TIMEOUT ));break ;case USB_PORT_FEAT_POWER :port_power (sl811,0 );
Greg Kroah-Hartman
maintainerPATCH 40/92 Input: elantech - fix absolute mode setting on some ASUS laptops
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulrik De Bie <[email protected]>
commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream.
On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done.
In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware).
Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c
--- drivers/input/mouse/elantech.c | 22 ++++++++++++++++++++++ drivers/input/mouse/elantech.h | 1 + 2 files changed, 23 insertions(+)
drivers/input/mouse/elantech.c +22 -0
@@ -814,6 +814,21 @@ static psmouse_ret_t elantech_process_by }/* +* This writes the reg_07 value again to the hardware at the end of every +* set_rate call because the register loses its value. reg_07 allows setting +* absolute mode on v4 hardware +*/ +static void elantech_set_rate_restore_reg_07 (struct psmouse *psmouse, +unsigned int rate) +{ +struct elantech_data *etd = psmouse->private; + + etd->original_set_rate (psmouse, rate); +if (elantech_write_reg (psmouse,0x07 , etd->reg_07)) +psmouse_err (psmouse,"restoring reg_07 failed\n" ); +} + +/* * Put the touchpad into absolute mode */ static int elantech_set_absolute_mode (struct psmouse *psmouse)
@@ -1015,6 +1030,8 @@ static int elantech_get_resolution_v4(st* Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons +* Asus TP500LN 0x381f17 10, 14, 0e clickpad +* Asus X750JN 0x381f17 10, 14, 0e clickpad * Asus UX31 0x361f00 20, 15, 0e clickpad * Asus UX32VD 0x361f02 00, 15, 0e clickpad * Avatar AVIU-145A2 0x361f00 ? clickpad
@@ -1490,6 +1507,11 @@ int elantech_init(struct psmouse *psmous goto init_fail; } +if (etd->fw_version ==0x381f17 ) { + etd->original_set_rate = psmouse->set_rate; + psmouse->set_rate = elantech_set_rate_restore_reg_07; + } +if (elantech_set_input_params (psmouse)) {psmouse_err (psmouse,"failed to query touchpad range.\n" ); goto init_fail;
drivers/input/mouse/elantech.h +1 -0
@@ -139,6 +139,7 @@ struct elantech_data {struct finger_pos mt[ETP_MAX_FINGERS ];unsigned char parity[256 ];int (*send_cmd)(struct psmouse *psmouse,unsigned char c,unsigned char *param); +void (*original_set_rate)(struct psmouse *psmouse,unsigned int rate); };#ifdef CONFIG_MOUSE_PS2_ELANTECH
Greg Kroah-Hartman
maintainerPATCH 41/92 fs/binfmt_elf.c: fix bug in loading of PIE binaries
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Davidson <[email protected]>
commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream.
With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base.
Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary.
Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run).
Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure.
Fix this by calculating the total size of the binary in the same way as load_elf_interp().
--- fs/binfmt_elf.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
fs/binfmt_elf.c +8 -1
@@ -751,6 +751,7 @@ static int load_elf_binary(struct linux_ i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {int elf_prot =0 , elf_flags;unsigned long k, vaddr; +unsigned long total_size =0 ;if (elf_ppnt->p_type !=PT_LOAD )continue ;
@@ -815,10 +816,16 @@ static int load_elf_binary(struct linux_#else load_bias =ELF_PAGESTART (ELF_ET_DYN_BASE - vaddr);#endif + total_size =total_mapping_size (elf_phdata, + loc->elf_ex.e_phnum); +if (!total_size) { + error = -EINVAL ; + goto out_free_dentry; + } } error =elf_map (bprm->file, load_bias + vaddr, elf_ppnt, - elf_prot, elf_flags,0 ); + elf_prot, elf_flags, total_size);if (BAD_ADDR (error)) {send_sig (SIGKILL , current,0 ); retval = IS_ERR((void *)error) ?
Greg Kroah-Hartman
maintainerPATCH 54/92 UBI: initialize LEB number variable
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream.
In some of the 'out_not_moved' error paths, lnum may be used uninitialized. Don't ignore the warning; let's fix it.
This uninitialized variable doesn't have much visible effect in the end, since we just schedule the PEB for erasure, and its LEB number doesn't really matter (it just gets printed in debug messages). But let's get it straight anyway.
Coverity CID #113449
--- drivers/mtd/ubi/wl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/ubi/wl.c +1 -1
@@ -995,7 +995,7 @@ static int wear_leveling_worker(struct u int cancel) {int err, scrubbing =0 , torture =0 , protect =0 , erroneous =0 ; -int vol_id =-1 ,uninitialized_var (lnum ); +int vol_id =-1 , lnum =-1 ;#ifdef CONFIG_MTD_UBI_FASTMAP int anchor = wrk->anchor;#endif
Greg Kroah-Hartman
maintainerPATCH 58/92 target/file: Fix BUG() when CONFIG_DEBUG_SG=y and DIF protection enabled
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <[email protected]>
commit 38da0f49e8aa1649af397d53f88e163d0e60c058 upstream.
When CONFIG_DEBUG_SG=y and DIF protection support enabled, kernel BUG()s are triggered due to the following two issues:
1) prot_sg is not initialized by sg_init_table().
When CONFIG_DEBUG_SG=y, scatterlist helpers check sg entry has a correct magic value.
2) vmalloc'ed buffer is passed to sg_set_buf().
sg_set_buf() uses virt_to_page() to convert virtual address to struct page, but it doesn't work with vmalloc address. vmalloc_to_page() should be used instead. As prot_buf isn't usually too large, so fix it by allocating prot_buf by kmalloc instead of vmalloc.
--- drivers/target/target_core_file.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
drivers/target/target_core_file.c +8 -7
@@ -273,7 +273,7 @@ static int fd_do_prot_rw(struct se_cmd * se_dev->prot_length;if (!is_write) { - fd_prot->prot_buf =vzalloc (prot_size); + fd_prot->prot_buf =kzalloc (prot_size,GFP_KERNEL );if (!fd_prot->prot_buf) {pr_err ("Unable to allocate fd_prot->prot_buf\n" );return -ENOMEM ;
@@ -285,9 +285,10 @@ static int fd_do_prot_rw(struct se_cmd * fd_prot->prot_sg_nents, GFP_KERNEL);if (!fd_prot->prot_sg) {pr_err ("Unable to allocate fd_prot->prot_sg\n" ); -vfree (fd_prot->prot_buf); +kfree (fd_prot->prot_buf);return -ENOMEM ; } +sg_init_table (fd_prot->prot_sg, fd_prot->prot_sg_nents); size = prot_size;for_each_sg (fd_prot->prot_sg, sg, fd_prot->prot_sg_nents, i) {
@@ -317,7 +318,7 @@ static int fd_do_prot_rw(struct se_cmd *if (is_write || ret <0 ) {kfree (fd_prot->prot_sg); -vfree (fd_prot->prot_buf); +kfree (fd_prot->prot_buf); }return ret;
@@ -652,11 +653,11 @@ fd_execute_rw(struct se_cmd *cmd, struct 0, fd_prot.prot_sg, 0);if (rc) {kfree (fd_prot.prot_sg); -vfree (fd_prot.prot_buf); +kfree (fd_prot.prot_buf);return rc; }kfree (fd_prot.prot_sg); -vfree (fd_prot.prot_buf); +kfree (fd_prot.prot_buf); } }else {memset (&fd_prot,0 ,sizeof (struct fd_prot ));
@@ -672,7 +673,7 @@ fd_execute_rw(struct se_cmd *cmd, struct 0, fd_prot.prot_sg, 0);if (rc) {kfree (fd_prot.prot_sg); -vfree (fd_prot.prot_buf); +kfree (fd_prot.prot_buf);return rc; } }
@@ -703,7 +704,7 @@ fd_execute_rw(struct se_cmd *cmd, structif (ret <0 ) {kfree (fd_prot.prot_sg); -vfree (fd_prot.prot_buf); +kfree (fd_prot.prot_buf);return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE ; }
Greg Kroah-Hartman
maintainerPATCH 59/92 target/file: Fix SG table for prot_buf initialization
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <[email protected]>
commit c836777830428372074d5129ac513e1472c99791 upstream.
In fd_do_prot_rw(), it allocates prot_buf which is used to copy from se_cmd->t_prot_sg by sbc_dif_copy_prot(). The SG table for prot_buf is also initialized by allocating 'se_cmd->t_prot_nents' entries of scatterlist and setting the data length of each entry to PAGE_SIZE at most.
However if se_cmd->t_prot_sg contains a clustered entry (i.e. sg->length > PAGE_SIZE), the SG table for prot_buf can't be initialized correctly and sbc_dif_copy_prot() can't copy to prot_buf. (This actually happened with TCM loopback fabric module)
As prot_buf is allocated by kzalloc() and it's physically contiguous, we only need a single scatterlist entry.
--- drivers/target/target_core_file.c | 21 ++++++--------------- 1 file changed, 6 insertions(+), 15 deletions(-)
drivers/target/target_core_file.c +6 -15
@@ -263,11 +263,10 @@ static int fd_do_prot_rw(struct se_cmd *struct se_device *se_dev = cmd->se_dev;struct fd_dev *dev =FD_DEV (se_dev);struct file *prot_fd = dev->fd_prot_file; -struct scatterlist *sg;loff_t pos = (cmd->t_task_lba * se_dev->prot_length);unsigned char *buf; -u32 prot_size, len, size; -int rc, ret =1 , i; +u32 prot_size; +int rc, ret =1 ; prot_size = (cmd->data_length / se_dev->dev_attrib.block_size) * se_dev->prot_length;
@@ -280,24 +279,16 @@ static int fd_do_prot_rw(struct se_cmd * } buf = fd_prot->prot_buf; - fd_prot->prot_sg_nents = cmd->t_prot_nents; - fd_prot->prot_sg =kzalloc (sizeof (struct scatterlist ) * - fd_prot->prot_sg_nents,GFP_KERNEL ); + fd_prot->prot_sg_nents =1 ; + fd_prot->prot_sg =kzalloc (sizeof (struct scatterlist ), +GFP_KERNEL );if (!fd_prot->prot_sg) {pr_err ("Unable to allocate fd_prot->prot_sg\n" );kfree (fd_prot->prot_buf);return -ENOMEM ; }sg_init_table (fd_prot->prot_sg, fd_prot->prot_sg_nents); - size = prot_size; - -for_each_sg (fd_prot->prot_sg, sg, fd_prot->prot_sg_nents, i) { - - len =min_t (u32,PAGE_SIZE , size); -sg_set_buf (sg, buf, len); - size -= len; - buf += len; - } +sg_set_buf (fd_prot->prot_sg, buf, prot_size); }if (is_write) {
Greg Kroah-Hartman
maintainerPATCH 67/92 xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 01e84c70fe40c8111f960987bcf7f931842e6d07 upstream.
xtensa actually uses sync_file_range2 implementation, so it should define __NR_sync_file_range2 as other architectures that use that function. That fixes userspace interface (that apparently never worked) and avoids special-casing xtensa in libc implementations. See the thread ending at
http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html
for more details.
--- arch/xtensa/include/uapi/asm/unistd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/xtensa/include/uapi/asm/unistd.h +1 -1
@@ -715,7 +715,7 @@ __SYSCALL(323, sys_process_vm_writev, 6) __SYSCALL(324, sys_name_to_handle_at, 5)#define __NR_open_by_handle_at 325 __SYSCALL(325, sys_open_by_handle_at, 3) -#define __NR_sync_file_range 326 +#define __NR_sync_file_range2 326 __SYSCALL(326, sys_sync_file_range2, 6)#define __NR_perf_event_open 327__SYSCALL (327 , sys_perf_event_open,5 )
Greg Kroah-Hartman
maintainerPATCH 68/92 xtensa: ISS: fix locking in TAP network adapter
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 24e94454c8cb6a13634f5a2f5a01da53a546a58d upstream.
- don't lock lp->lock in the iss_net_timer for the call of iss_net_poll, it will lock it itself;
- invert order of lp->lock and opened_lock acquisition in the iss_net_open to make it consistent with iss_net_poll;
- replace spin_lock with spin_lock_bh when acquiring locks used in iss_net_timer from non-atomic context;
- replace spin_lock_irqsave with spin_lock_bh in the iss_net_start_xmit as the driver doesn't use lp->lock in the hard IRQ context;
- replace __SPIN_LOCK_UNLOCKED(lp.lock) with spin_lock_init, otherwise lockdep is unhappy about using non-static key.
--- arch/xtensa/platforms/iss/network.c | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-)
arch/xtensa/platforms/iss/network.c +15 -14
@@ -349,8 +349,8 @@ static void iss_net_timer(unsigned long {struct iss_net_private *lp = (struct iss_net_private *)priv; -spin_lock (&lp->lock);iss_net_poll (); +spin_lock (&lp->lock);mod_timer (&lp->timer, jiffies + lp->timer_val);spin_unlock (&lp->lock); }
@@ -361,7 +361,7 @@ static int iss_net_open(struct net_devicstruct iss_net_private *lp =netdev_priv (dev);int err; -spin_lock (&lp->lock); +spin_lock_bh (&lp->lock); err = lp->tp.open (lp);if (err <0 )
@@ -376,9 +376,11 @@ static int iss_net_open(struct net_devicwhile ((err =iss_net_rx (dev)) >0 ) ; -spin_lock (&opened_lock); +spin_unlock_bh (&lp->lock); +spin_lock_bh (&opened_lock);list_add (&lp->opened_list, &opened); -spin_unlock (&opened_lock); +spin_unlock_bh (&opened_lock); +spin_lock_bh (&lp->lock);init_timer (&lp->timer); lp->timer_val =ISS_NET_TIMER_VALUE ;
@@ -387,7 +389,7 @@ static int iss_net_open(struct net_devicmod_timer (&lp->timer, jiffies + lp->timer_val); out: -spin_unlock (&lp->lock); +spin_unlock_bh (&lp->lock);return err; }
@@ -395,7 +397,7 @@ static int iss_net_close(struct net_devi {struct iss_net_private *lp =netdev_priv (dev);netif_stop_queue (dev); -spin_lock (&lp->lock); +spin_lock_bh (&lp->lock);spin_lock (&opened_lock);list_del (&opened);
@@ -405,18 +407,17 @@ static int iss_net_close(struct net_devi lp->tp.close (lp); -spin_unlock (&lp->lock); +spin_unlock_bh (&lp->lock);return 0 ; }static int iss_net_start_xmit (struct sk_buff *skb,struct net_device *dev) {struct iss_net_private *lp =netdev_priv (dev); -unsigned long flags;int len;netif_stop_queue (dev); -spin_lock_irqsave (&lp->lock, flags); +spin_lock_bh (&lp->lock); len = lp->tp.write (lp, &skb);
@@ -438,7 +439,7 @@ static int iss_net_start_xmit(struct sk_pr_err ("%s: %s failed(%d)\n" , dev->name, __func__, len); } -spin_unlock_irqrestore (&lp->lock, flags); +spin_unlock_bh (&lp->lock);dev_kfree_skb (skb);return NETDEV_TX_OK ;
@@ -466,9 +467,9 @@ static int iss_net_set_mac(struct net_deif (!is_valid_ether_addr (hwaddr->sa_data))return -EADDRNOTAVAIL ; -spin_lock (&lp->lock); +spin_lock_bh (&lp->lock);memcpy (dev->dev_addr, hwaddr->sa_data,ETH_ALEN ); -spin_unlock (&lp->lock); +spin_unlock_bh (&lp->lock);return 0 ; }
@@ -520,11 +521,11 @@ static int iss_net_configure(int index, *lp = (struct iss_net_private ) { .device_list =LIST_HEAD_INIT (lp->device_list), .opened_list =LIST_HEAD_INIT (lp->opened_list), - .lock =__SPIN_LOCK_UNLOCKED (lp.lock), .dev = dev, .index = index, - }; + }; +spin_lock_init (&lp->lock);/* * If this name ends up conflicting with an existing registered * netdevice, that is OK, register_netdev{,ice}() will notice this
Greg Kroah-Hartman
maintainerPATCH 78/92 IB/core: dont disallow registering region starting at 0x0
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yann Droneaud <[email protected]>
commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream.
In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit 8494057ab5e4 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0).
This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages().
There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check.
--- drivers/infiniband/core/umem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/core/umem.c +2 -2
@@ -101,8 +101,8 @@ struct ib_umem *ib_umem_get(struct ib_uc* If the combination of the addr and size requested for this memory * region causes an integer overflow, return error. */ -if ((PAGE_ALIGN (addr + size) <= size) || - (PAGE_ALIGN (addr + size) <= addr)) +if (((addr + size) < addr) || +PAGE_ALIGN (addr + size) < (addr + size))return ERR_PTR (-EINVAL );if (!can_do_mlock ())
Greg Kroah-Hartman
maintainerPATCH 89/92 C6x: time: Ensure consistency in __init
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nishanth Menon <[email protected]>
commit f4831605f2dacd12730fe73961c77253cc2ea425 upstream.
time_init invokes timer64_init (which is __init annotation) since all of these are invoked at init time, lets maintain consistency by ensuring time_init is marked appropriately as well.
This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y
WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init() The function time_init() references
the function __init timer64_init().
This is often because time_init lacks a __init
annotation or the annotation of timer64_init is wrong.
--- arch/c6x/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/c6x/kernel/time.c +1 -1
@@ -49,7 +49,7 @@ u64 sched_clock(void)return (tsc * sched_clock_multiplier) >>SCHED_CLOCK_SHIFT ; } -void time_init (void ) +void __init time_init (void ) {u64 tmp = (u64 )NSEC_PER_SEC <<SCHED_CLOCK_SHIFT ;
Greg Kroah-Hartman
maintainerPATCH 1/92 ip_forward: Drop frames with attached skb->sk
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: =?UTF-8?q?Sebastian=20P=C3=B6hn?= <[email protected]>
[ Upstream commit 2ab957492d13bb819400ac29ae55911d50a82a13 ]
Initial discussion was:
[FYI] xfrm: Don't lookup sk_policy for timewait sockets
Forwarded frames should not have a socket attached. Especially tw sockets will lead to panics later-on in the stack.
This was observed with TPROXY assigning a tw socket and broken policy routing (misconfigured). As a result frame enters forwarding path instead of input. We cannot solve this in TPROXY as it cannot know that policy routing is broken.
v2:
Remove useless comment
--- net/ipv4/ip_forward.c | 3 +++ 1 file changed, 3 insertions(+)
net/ipv4/ip_forward.c +3 -0
@@ -127,6 +127,9 @@ int ip_forward(struct sk_buff *skb)struct rtable *rt;/* Route we use */ struct ip_options *opt = &(IPCB (skb)->opt); +if (unlikely (skb->sk)) + goto drop; +if (skb_warn_if_lro (skb)) goto drop;
Greg Kroah-Hartman
maintainerPATCH 10/92 sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Len Brown <[email protected]>
commit b253149b843f89cd300cbdbea27ce1f847506f99 upstream.
In Linux-3.9 we removed the mwait_idle() loop:
69fb3676df33 ("x86 idle: remove mwait_idle() and "idle=mwait" cmdline param")
The reasoning was that modern machines should be sufficiently happy during the boot process using the default_idle() HALT loop, until cpuidle loads and either acpi_idle or intel_idle invoke the newer MWAIT-with-hints idle loop.
But two machines reported problems:
1. Certain Core2-era machines support MWAIT-C1 and HALT only. MWAIT-C1 is preferred for optimal power and performance. But if they support just C1, cpuidle never loads and so they use the boot-time default idle loop forever.
2. Some laptops will boot-hang if HALT is used, but will boot successfully if MWAIT is used. This appears to be a hidden assumption in BIOS SMI, that is presumably valid on the proprietary OS where the BIOS was validated.
https://bugzilla.kernel.org/show_bug.cgi?id=60770
So here we effectively revert the patch above, restoring the mwait_idle() loop. However, we don't bother restoring the idle=mwait cmdline parameter, since it appears to add no value.
Maintainer notes:
For 3.9, simply revert 69fb3676df
for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context For 3.11, 3.12, 3.13, this patch applies cleanly
--- arch/x86/include/asm/mwait.h | 8 ++++++ arch/x86/kernel/process.c | 50 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+)
arch/x86/include/asm/mwait.h +8 -0
@@ -30,6 +30,14 @@ static inline void __mwait(unsigned long :: "a" (eax), "c" (ecx)); } +static inline void __sti_mwait (unsigned long eax,unsigned long ecx) +{ +trace_hardirqs_on (); +/* "mwait %eax, %ecx;" */ + asmvolatile ("sti; .byte 0x0f, 0x01, 0xc9;" + ::"a" (eax),"c" (ecx)); +} +/* * This uses new MONITOR/MWAIT instructions on P4 processors with PNI, * which can obviate IPI to trigger checking of need_resched.
arch/x86/kernel/process.c +50 -0
68 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 11/92 usb: gadget: composite: enable BESL support
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit a6615937bcd9234e6d6bb817c3701fce44d0a84d upstream.
According to USB 2.0 ECN Errata for Link Power
Management (USB2-LPM-Errata-final.pdf), BESL
must be enabled if LPM is enabled.
This helps with USB30CV TD 9.21 LPM L1
Suspend Resume Test.
--- drivers/usb/gadget/composite.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/composite.c +1 -1
@@ -528,7 +528,7 @@ static int bos_desc(struct usb_composite usb_ext->bLength =USB_DT_USB_EXT_CAP_SIZE ; usb_ext->bDescriptorType =USB_DT_DEVICE_CAPABILITY ; usb_ext->bDevCapabilityType =USB_CAP_TYPE_EXT ; - usb_ext->bmAttributes =cpu_to_le32 (USB_LPM_SUPPORT ); + usb_ext->bmAttributes =cpu_to_le32 (USB_LPM_SUPPORT |USB_BESL_SUPPORT );/* * The Superspeed USB Capability descriptor shall be implemented by all
Greg Kroah-Hartman
maintainerPATCH 12/92 KVM: s390: Zero out current VMDB of STSI before including level3 data.
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ekaterina Tumanova <[email protected]>
commit b75f4c9afac2604feb971441116c07a24ecca1ec upstream.
s390 documentation requires words 0 and 10-15 to be reserved and stored as zeros. As we fill out all other fields, we can memset the full structure.
--- arch/s390/kvm/priv.c | 1 + 1 file changed, 1 insertion(+)
arch/s390/kvm/priv.c +1 -0
@@ -414,6 +414,7 @@ static void handle_stsi_3_2_2(struct kvmfor (n = mem->count -1 ; n >0 ; n--)memcpy (&mem->vm[n], &mem->vm[n -1 ],sizeof (mem->vm[0 ])); +memset (&mem->vm[0 ],0 ,sizeof (mem->vm[0 ])); mem->vm[0 ].cpus_total = cpus; mem->vm[0 ].cpus_configured = cpus; mem->vm[0 ].cpus_standby =0 ;
Greg Kroah-Hartman
maintainerPATCH 13/92 s390/hibernate: fix save and restore of kernel text section
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Carstens <[email protected]>
commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
Sebastian reported a crash caused by a jump label mismatch after resume. This happens because we do not save the kernel text section during suspend and therefore also do not restore it during resume, but use the kernel image that restores the old system.
This means that after a suspend/resume cycle we lost all modifications done to the kernel text section.
The reason for this is the pfn_is_nosave() function, which incorrectly returns that read-only pages don't need to be saved. This is incorrect since we mark the kernel text section read-only.
We still need to make sure to not save and restore pages contained within NSS and DCSS segment.
To fix this add an extra case for the kernel text section and only save those pages if they are not contained within an NSS segment.
Fixes the following crash (and the above bugs as well):
Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0
Found: c0 04 00 00 00 00 Expected: c0 f4 00 00 00 11 New: c0 04 00 00 00 00 Kernel panic - not syncing: Corrupted kernel text CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4 Call Trace: [<0000000000113972>] show_stack+0x72/0xf0 [<000000000081f15e>] dump_stack+0x6e/0x90 [<000000000081c4e8>] panic+0x108/0x2b0 [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108 [<0000000000112176>] __jump_label_transform+0x9e/0xd0 [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50 [<00000000001d1136>] multi_cpu_stop+0x12e/0x170 [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168 [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0 [<0000000000158baa>] kthread+0x10a/0x110 [<0000000000824a86>] kernel_thread_starter+0x6/0xc
--- arch/s390/kernel/suspend.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/s390/kernel/suspend.c +4 -0
@@ -142,6 +142,8 @@ int pfn_is_nosave(unsigned long pfn) {unsigned long nosave_begin_pfn =PFN_DOWN (__pa (&__nosave_begin));unsigned long nosave_end_pfn =PFN_DOWN (__pa (&__nosave_end)); +unsigned long eshared_pfn =PFN_DOWN (__pa (&_eshared)) -1 ; +unsigned long stext_pfn =PFN_DOWN (__pa (&_stext));/* Always save lowcore pages (LC protection might be enabled). */ if (pfn <=LC_PAGES )
@@ -149,6 +151,8 @@ int pfn_is_nosave(unsigned long pfn)if (pfn >= nosave_begin_pfn && pfn < nosave_end_pfn)return 1 ;/* Skip memory holes and read-only pages (NSS, DCSS, ...). */ +if (pfn >= stext_pfn && pfn <= eshared_pfn) +return ipl_info.type ==IPL_TYPE_NSS ?1 :0 ;if (tprot (PFN_PHYS (pfn)))return 1 ;return 0 ;
Greg Kroah-Hartman
maintainerPATCH 15/92 MIPS: Hibernate: flush TLB entries earlier
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit a843d00d038b11267279e3b5388222320f9ddc1d upstream.
We found that TLB mismatch not only happens after kernel resume, but also happens during snapshot restore. So move it to the beginning of swsusp_arch_suspend().
Patchwork: https://patchwork.linux-mips.org/patch/9621/
--- arch/mips/power/hibernate.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/mips/power/hibernate.S +2 -1
@@ -30,6 +30,8 @@ LEAF(swsusp_arch_suspend) END(swsusp_arch_suspend) LEAF(swsusp_arch_resume) + /* Avoid TLB mismatch during and after kernel resume */ + jal local_flush_tlb_all PTR_L t0, restore_pblist 0: PTR_L t1, PBE_ADDRESS(t0) /* source */
@@ -43,7 +45,6 @@ LEAF(swsusp_arch_resume) bne t1, t3, 1b PTR_L t0, PBE_NEXT(t0) bnez t0, 0b - jal local_flush_tlb_all /* Avoid TLB mismatch after kernel resume */ PTR_LA t0, saved_regs PTR_L ra, PT_R31(t0) PTR_L sp, PT_R29(t0)
Greg Kroah-Hartman
maintainerPATCH 16/92 md/raid0: fix bug with chunksize not a power of 2.
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 47d68979cc968535cb87f3e5f2e6a3533ea48fbd upstream.
Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 in v3.14-rc1 RAID0 has performed incorrect calculations when the chunksize is not a power of 2.
This happens because "sector_div()" modifies its first argument, but this wasn't taken into account in the patch.
So restore that first arg before re-using the variable.
--- drivers/md/raid0.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/md/raid0.c +2 -1
@@ -320,7 +320,7 @@ static struct strip_zone *find_zone(stru/* * remaps the bio to the target device. we separate two flows. -* power 2 flow and a general flow for the sake of perfromance +* power 2 flow and a general flow for the sake of performance */ static struct md_rdev *map_sector (struct mddev *mddev,struct strip_zone *zone,sector_t sector,sector_t *sector_offset)
@@ -538,6 +538,7 @@ static void raid0_make_request(struct md split = bio; } + sector = bio->bi_iter.bi_sector; zone =find_zone (mddev->private, §or); tmp_dev =map_sector (mddev, zone, sector, §or); split->bi_bdev = tmp_dev->bdev;
Greg Kroah-Hartman
maintainerPATCH 17/92 cdc-wdm: fix endianness bug in debug statements
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 upstream.
Values directly from descriptors given in debug statements must be converted to native endianness.
--- drivers/usb/class/cdc-wdm.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/usb/class/cdc-wdm.c +7 -5
@@ -245,7 +245,7 @@ static void wdm_int_callback(struct urbcase USB_CDC_NOTIFY_RESPONSE_AVAILABLE :dev_dbg (&desc->intf->dev,"NOTIFY_RESPONSE_AVAILABLE received: index %d len %d" , - dr->wIndex, dr->wLength); +le16_to_cpu (dr->wIndex),le16_to_cpu (dr->wLength));break ;case USB_CDC_NOTIFY_NETWORK_CONNECTION :
@@ -262,7 +262,9 @@ static void wdm_int_callback(struct urbclear_bit (WDM_POLL_RUNNING , &desc->flags);dev_err (&desc->intf->dev,"unknown notification %d received: index %d len %d\n" , - dr->bNotificationType, dr->wIndex, dr->wLength); + dr->bNotificationType, +le16_to_cpu (dr->wIndex), +le16_to_cpu (dr->wLength)); goto exit; }
@@ -408,7 +410,7 @@ static ssize_t wdm_write USB_RECIP_INTERFACE); req->bRequest =USB_CDC_SEND_ENCAPSULATED_COMMAND ; req->wValue =0 ; - req->wIndex = desc->inum; + req->wIndex = desc->inum;/* already converted */ req->wLength =cpu_to_le16 (count);set_bit (WDM_IN_USE , &desc->flags); desc->outbuf = buf;
@@ -422,7 +424,7 @@ static ssize_t wdm_write rv =usb_translate_errors (rv); }else {dev_dbg (&desc->intf->dev,"Tx URB has been submitted index=%d" , - req->wIndex); +le16_to_cpu (req->wIndex)); } out:usb_autopm_put_interface (desc->intf);
@@ -820,7 +822,7 @@ static int wdm_create(struct usb_interfa desc->irq->bRequestType = (USB_DIR_IN |USB_TYPE_CLASS |USB_RECIP_INTERFACE ); desc->irq->bRequest =USB_CDC_GET_ENCAPSULATED_RESPONSE ; desc->irq->wValue =0 ; - desc->irq->wIndex = desc->inum; + desc->irq->wIndex = desc->inum;/* already converted */ desc->irq->wLength =cpu_to_le16 (desc->wMaxCommand); usb_fill_control_urb(
Greg Kroah-Hartman
maintainerPATCH 18/92 spi: spidev: fix possible arithmetic overflow for multi-transfer message
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Abbott <[email protected]>
commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream.
spidev_message() sums the lengths of the individual SPI transfers to determine the overall SPI message length. It restricts the total length, returning an error if too long, but it does not check for arithmetic overflow. For example, if the SPI message consisted of two transfers and the first has a length of 10 and the second has a length of (__u32)(-1), the total length would be seen as 9, even though the second transfer is actually very long. If the second transfer specifies a null rx_buf and a non-null tx_buf, the copy_from_user() could overrun the spidev's pre-allocated tx buffer before it reaches an invalid user memory address. Fix it by checking that neither the total nor the individual transfer lengths exceed the maximum allowed value.
Thanks to Dan Carpenter for reporting the potential integer overflow.
--- drivers/spi/spidev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/spi/spidev.c +4 -1
@@ -243,7 +243,10 @@ static int spidev_message(struct spidev_ k_tmp->len = u_tmp->len; total += k_tmp->len; -if (total > bufsiz) { +/* Check total length of transfers. Also check each +* transfer length to avoid arithmetic overflow. +*/ +if (total > bufsiz || k_tmp->len > bufsiz) { status = -EMSGSIZE ; goto done; }
Greg Kroah-Hartman
maintainerPATCH 19/92 compal-laptop: Check return value of power_supply_register
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 1915a718b1872edffcb13e5436a9f7302d3d36f0 upstream.
The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered.
This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply.
Fix this by checking return status of power_supply_register() call. In case of failure, clean up sysfs entries and fail the probe.
--- drivers/platform/x86/compal-laptop.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/platform/x86/compal-laptop.c +3 -1
@@ -1037,7 +1037,9 @@ static int compal_probe(struct platform_/* Power supply */ initialize_power_supply_data (data); -power_supply_register (&compal_device->dev, &data->psy); + err =power_supply_register (&compal_device->dev, &data->psy); +if (err <0 ) + goto remove;platform_set_drvdata (pdev, data);
Greg Kroah-Hartman
maintainerPATCH 2/92 tcp: fix possible deadlock in tcp_send_fin()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit d83769a580f1132ac26439f50068a29b02be535e ]
Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in case a huge process is killed by OOM, and tcp_mem[2] is hit.
To be able to free memory we need to make progress, so this patch allows FIN packets to not care about tcp_mem[2], if skb allocation succeeded.
In a follow-up patch, we might abort tcp_send_fin() infinite loop in case TIF_MEMDIE is set on this thread, as memory allocator did its best getting extra memory already.
This patch reverts d22e15371811 ("tcp: fix tcp fin memory accounting")
--- net/ipv4/tcp_output.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
net/ipv4/tcp_output.c +19 -1
@@ -2595,6 +2595,21 @@ begin_fwd: } } +/* We allow to exceed memory limits for FIN packets to expedite +* connection tear down and (memory) recovery. +* Otherwise tcp_send_fin() could loop forever. +*/ +static void sk_forced_wmem_schedule (struct sock *sk,int size) +{ +int amt, status; + +if (size <= sk->sk_forward_alloc) +return ; + amt =sk_mem_pages (size); + sk->sk_forward_alloc += amt *SK_MEM_QUANTUM ; +sk_memory_allocated_add (sk, amt, &status); +} +/* Send a fin. The caller locks the socket for us. This cannot be * allowed to fail queueing a FIN frame under any circumstances. */
@@ -2617,11 +2632,14 @@ void tcp_send_fin(struct sock *sk) }else {/* Socket is locked, keep trying until memory is available. */ for (;;) { - skb =sk_stream_alloc_skb (sk,0 , sk->sk_allocation); + skb =alloc_skb_fclone (MAX_TCP_HEADER , + sk->sk_allocation);if (skb)break ;yield (); } +skb_reserve (skb,MAX_TCP_HEADER ); +sk_forced_wmem_schedule (sk, skb->truesize);/* FIN eats a sequence byte, write_seq advanced by tcp_queue_skb(). */ tcp_init_nondata_skb (skb, tp->write_seq,TCPHDR_ACK |TCPHDR_FIN );
Greg Kroah-Hartman
maintainerPATCH 20/92 ring-buffer: Replace this_cpu_*() with __this_cpu_*()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 80a9b64e2c156b6523e7a01f2ba6e5d86e722814 upstream.
It has come to my attention that this_cpu_read/write are horrible on architectures other than x86. Worse yet, they actually disable preemption or interrupts! This caused some unexpected tracing results on ARM.
101.356868: preempt_count_add <-ring_buffer_lock_reserve 101.356870: preempt_count_sub <-ring_buffer_lock_reserve
The ring_buffer_lock_reserve has recursion protection that requires accessing a per cpu variable. But since preempt_disable() is traced, it too got traced while accessing the variable that is suppose to prevent recursion like this.
The generic version of this_cpu_read() and write() are:
#define this_cpu_generic_read(pcp) \
({ typeof(pcp) ret__; \
preempt_disable(); \
ret__ = *this_cpu_ptr(&(pcp)); \
preempt_enable(); \
ret__; \})
#define this_cpu_generic_to_op(pcp, val, op) \
do { \
unsigned long flags; \
raw_local_irq_save(flags); \
*__this_cpu_ptr(&(pcp)) op val; \
raw_local_irq_restore(flags); \} while (0)
Which is unacceptable for locations that know they are within preempt disabled or interrupt disabled locations.
Paul McKenney stated that __this_cpu_() versions produce much better code on other architectures than this_cpu_() does, if we know that the call is done in a preempt disabled location.
I also changed the recursive_unlock() to use two local variables instead of accessing the per_cpu variable twice.
--- kernel/trace/ring_buffer.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
kernel/trace/ring_buffer.c +5 -6
@@ -2651,7 +2651,7 @@ static DEFINE_PER_CPU(unsigned int, curr static __always_inline int trace_recursive_lock(void) { -unsigned int val =this_cpu_read (current_context); +unsigned int val =__this_cpu_read (current_context);int bit;if (in_interrupt ()) {
@@ -2668,18 +2668,17 @@ static __always_inline int trace_recursireturn 1 ; val |= (1 << bit); -this_cpu_write (current_context, val); +__this_cpu_write (current_context, val);return 0 ; } static __always_inline void trace_recursive_unlock(void) { -unsigned int val =this_cpu_read (current_context); +unsigned int val =__this_cpu_read (current_context); - val--; - val &=this_cpu_read (current_context); -this_cpu_write (current_context, val); + val &= val & (val -1 ); +__this_cpu_write (current_context, val); }#else
Greg Kroah-Hartman
maintainerPATCH 21/92 power_supply: twl4030_madc: Check return value of power_supply_register
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 68c3ed6fa7e0d69529ced772d650ab128916a81d upstream.
The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered.
This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply.
--- drivers/power/twl4030_madc_battery.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/power/twl4030_madc_battery.c +5 -2
@@ -192,6 +192,7 @@ static int twl4030_madc_battery_probe(st {struct twl4030_madc_battery *twl4030_madc_bat;struct twl4030_madc_bat_platform_data *pdata = pdev->dev.platform_data; +int ret =0 ; twl4030_madc_bat =kzalloc (sizeof (*twl4030_madc_bat),GFP_KERNEL );if (!twl4030_madc_bat)
@@ -216,9 +217,11 @@ static int twl4030_madc_battery_probe(st twl4030_madc_bat->pdata = pdata;platform_set_drvdata (pdev, twl4030_madc_bat); -power_supply_register (&pdev->dev, &twl4030_madc_bat->psy); + ret =power_supply_register (&pdev->dev, &twl4030_madc_bat->psy); +if (ret <0 ) +kfree (twl4030_madc_bat); -return 0 ; +return ret; }static int twl4030_madc_battery_remove (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 22/92 power_supply: lp8788-charger: Fix leaked power supply on probe fail
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit a7117f81e8391e035c49b3440792f7e6cea28173 upstream.
Driver forgot to unregister charger power supply if registering of battery supply failed in probe(). In such case the memory associated with power supply leaked.
--- drivers/power/lp8788-charger.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/power/lp8788-charger.c +3 -1
@@ -417,8 +417,10 @@ static int lp8788_psy_register(struct pl pchg->battery.num_properties =ARRAY_SIZE (lp8788_battery_prop); pchg->battery.get_property = lp8788_battery_get_property; -if (power_supply_register (&pdev->dev, &pchg->battery)) +if (power_supply_register (&pdev->dev, &pchg->battery)) { +power_supply_unregister (&pchg->charger);return -EPERM ; + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 3/92 tcp: avoid looping in tcp_send_fin()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ]
Presence of an unbound loop in tcp_send_fin() had always been hard to explain when analyzing crash dumps involving gigantic dying processes with millions of sockets.
Lets try a different strategy :
In case of memory pressure, try to add the FIN flag to last packet in write queue, even if packet was already sent. TCP stack will be able to deliver this FIN after a timeout event. Note that this FIN being delivered by a retransmit, it also carries a Push flag given our current implementation.
By checking sk_under_memory_pressure(), we anticipate that cooking many FIN packets might deplete tcp memory.
In the case we could not allocate a packet, even with __GFP_WAIT allocation, then not sending a FIN seems quite reasonable if it allows to get rid of this socket, free memory, and not block the process from eventually doing other useful work.
--- net/ipv4/tcp_output.c | 50 +++++++++++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 21 deletions(-)
net/ipv4/tcp_output.c +29 -21
@@ -2597,7 +2597,8 @@ begin_fwd:/* We allow to exceed memory limits for FIN packets to expedite * connection tear down and (memory) recovery. -* Otherwise tcp_send_fin() could loop forever. +* Otherwise tcp_send_fin() could be tempted to either delay FIN +* or even be forced to close flow without any FIN. */ static void sk_forced_wmem_schedule (struct sock *sk,int size) {
@@ -2610,33 +2611,40 @@ static void sk_forced_wmem_schedule(strusk_memory_allocated_add (sk, amt, &status); } -/* Send a fin. The caller locks the socket for us. This cannot be -* allowed to fail queueing a FIN frame under any circumstances. +/* Send a FIN. The caller locks the socket for us. +* We should try to send a FIN packet really hard, but eventually give up. */ void tcp_send_fin (struct sock *sk) { +struct sk_buff *skb, *tskb =tcp_write_queue_tail (sk);struct tcp_sock *tp =tcp_sk (sk); -struct sk_buff *skb =tcp_write_queue_tail (sk); -int mss_now; -/* Optimization, tack on the FIN if we have a queue of -* unsent frames. But be careful about outgoing SACKS -* and IP options. +/* Optimization, tack on the FIN if we have one skb in write queue and +* this skb was not yet sent, or we are under memory pressure. +* Note: in the latter case, FIN packet will be sent after a timeout, +* as TCP stack thinks it has already been transmitted. */ - mss_now =tcp_current_mss (sk); - -if (tcp_send_head (sk) !=NULL ) { -TCP_SKB_CB (skb)->tcp_flags |=TCPHDR_FIN ; -TCP_SKB_CB (skb)->end_seq++; +if (tskb && (tcp_send_head (sk) ||sk_under_memory_pressure (sk))) { +coalesce: +TCP_SKB_CB (tskb)->tcp_flags |=TCPHDR_FIN ; +TCP_SKB_CB (tskb)->end_seq++; tp->write_seq++; +if (!tcp_send_head (sk)) { +/* This means tskb was already sent. +* Pretend we included the FIN on previous transmit. +* We need to set tp->snd_nxt to the value it would have +* if FIN had been sent. This is because retransmit path +* does not change tp->snd_nxt. +*/ + tp->snd_nxt++; +return ; + } }else { -/* Socket is locked, keep trying until memory is available. */ -for (;;) { - skb =alloc_skb_fclone (MAX_TCP_HEADER , - sk->sk_allocation); -if (skb) -break ; -yield (); + skb =alloc_skb_fclone (MAX_TCP_HEADER , sk->sk_allocation); +if (unlikely (!skb)) { +if (tskb) + goto coalesce; +return ; }skb_reserve (skb,MAX_TCP_HEADER );sk_forced_wmem_schedule (sk, skb->truesize);
@@ -2645,7 +2653,7 @@ void tcp_send_fin(struct sock *sk) TCPHDR_ACK | TCPHDR_FIN);tcp_queue_skb (sk, skb); } -__tcp_push_pending_frames (sk, mss_now,TCP_NAGLE_OFF ); +__tcp_push_pending_frames (sk,tcp_current_mss (sk),TCP_NAGLE_OFF ); }/* We get here when a process closes a file descriptor (either due to
Greg Kroah-Hartman
maintainerPATCH 4/92 net: do not deplete pfmemalloc reserve
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 79930f5892e134c6da1254389577fffb8bd72c66 ]
build_skb() should look at the page pfmemalloc status. If set, this means page allocator allocated this page in the expectation it would help to free other pages. Networking stack can do that only if skb->pfmemalloc is also set.
Also, we must refrain using high order pages from the pfmemalloc reserve, so __page_frag_refill() must also use __GFP_NOMEMALLOC for them. Under memory pressure, using order-0 pages is probably the best strategy.
--- net/core/skbuff.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
net/core/skbuff.c +7 -2
@@ -309,7 +309,11 @@ struct sk_buff *build_skb(void *data, unmemset (skb,0 , offsetof(struct sk_buff , tail)); skb->truesize =SKB_TRUESIZE (size); - skb->head_frag = frag_size !=0 ; +if (frag_size) { + skb->head_frag =1 ; +if (virt_to_head_page (data)->pfmemalloc) + skb->pfmemalloc =1 ; + }atomic_set (&skb->users,1 ); skb->head = data; skb->data = data;
@@ -352,7 +356,8 @@ refill:gfp_t gfp = gfp_mask;if (order) - gfp |= __GFP_COMP | __GFP_NOWARN; + gfp |= __GFP_COMP | __GFP_NOWARN | + __GFP_NOMEMALLOC; nc->frag.page =alloc_pages (gfp, order);if (likely (nc->frag.page))break ;
Greg Kroah-Hartman
maintainerPATCH 5/92 net: fix crash in build_skb()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 2ea2f62c8bda242433809c7f4e9eae1c52c40bbe ]
When I added pfmemalloc support in build_skb(), I forgot netlink was using build_skb() with a vmalloc() area.
In this patch I introduce __build_skb() for netlink use, and build_skb() is a wrapper handling both skb->head_frag and skb->pfmemalloc
This means netlink no longer has to hack skb->head_frag
[ 1567.700067] kernel BUG at arch/x86/mm/physaddr.c:26! [ 1567.700067] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1567.700067] Dumping ftrace buffer: [ 1567.700067] (ftrace buffer empty) [ 1567.700067] Modules linked in: [ 1567.700067] CPU: 9 PID: 16186 Comm: trinity-c182 Not tainted 4.0.0-next-20150424-sasha-00037-g4796e21 #2167 [ 1567.700067] task: ffff880127efb000 ti: ffff880246770000 task.ti: ffff880246770000 [ 1567.700067] RIP: __phys_addr (arch/x86/mm/physaddr.c:26 (discriminator 3)) [ 1567.700067] RSP: 0018:ffff8802467779d8 EFLAGS: 00010202 [ 1567.700067] RAX: 000041000ed8e000 RBX: ffffc9008ed8e000 RCX: 000000000000002c [ 1567.700067] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffffb3fd6049 [ 1567.700067] RBP: ffff8802467779f8 R08: 0000000000000019 R09: ffff8801d0168000 [ 1567.700067] R10: ffff8801d01680c7 R11: ffffed003a02d019 R12: ffffc9000ed8e000 [ 1567.700067] R13: 0000000000000f40 R14: 0000000000001180 R15: ffffc9000ed8e000 [ 1567.700067] FS: 00007f2a7da3f700(0000) GS:ffff8801d1000000(0000) knlGS:0000000000000000 [ 1567.700067] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1567.700067] CR2: 0000000000738308 CR3: 000000022e329000 CR4: 00000000000007e0 [ 1567.700067] Stack: [ 1567.700067] ffffc9000ed8e000 ffff8801d0168000 ffffc9000ed8e000 ffff8801d0168000 [ 1567.700067] ffff880246777a28 ffffffffad7c0a21 0000000000001080 ffff880246777c08 [ 1567.700067] ffff88060d302e68 ffff880246777b58 ffff880246777b88 ffffffffad9a6821 [ 1567.700067] Call Trace: [ 1567.700067] build_skb (include/linux/mm.h:508 net/core/skbuff.c:316) [ 1567.700067] netlink_sendmsg (net/netlink/af_netlink.c:1633 net/netlink/af_netlink.c:2329) [ 1567.774369] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] sock_sendmsg (net/socket.c:614 net/socket.c:623) [ 1567.774369] sock_write_iter (net/socket.c:823) [ 1567.774369] ? sock_sendmsg (net/socket.c:806) [ 1567.774369] __vfs_write (fs/read_write.c:479 fs/read_write.c:491) [ 1567.774369] ? get_lock_stats (kernel/locking/lockdep.c:249) [ 1567.774369] ? default_llseek (fs/read_write.c:487) [ 1567.774369] ? vtime_account_user (kernel/sched/cputime.c:701) [ 1567.774369] ? rw_verify_area (fs/read_write.c:406 (discriminator 4)) [ 1567.774369] vfs_write (fs/read_write.c:539) [ 1567.774369] SyS_write (fs/read_write.c:586 fs/read_write.c:577) [ 1567.774369] ? SyS_read (fs/read_write.c:577) [ 1567.774369] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1567.774369] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636) [ 1567.774369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42) [ 1567.774369] system_call_fastpath (arch/x86/kernel/entry_64.S:261)
--- include/linux/skbuff.h | 1 + net/core/skbuff.c | 31 ++++++++++++++++++++++--------- net/netlink/af_netlink.c | 6 ++---- 3 files changed, 25 insertions(+), 13 deletions(-)
include/linux/skbuff.h +1 -0
@@ -661,6 +661,7 @@ bool skb_try_coalesce(struct sk_buff *tostruct sk_buff *__alloc_skb (unsigned int size,gfp_t priority,int flags,int node); +struct sk_buff *__build_skb (void *data,unsigned int frag_size);struct sk_buff *build_skb (void *data,unsigned int frag_size);static inline struct sk_buff *alloc_skb (unsigned int size,gfp_t priority)
net/core/skbuff.c +22 -9
@@ -278,13 +278,14 @@ nodata:EXPORT_SYMBOL (__alloc_skb);/** -* build_skb - build a network buffer +* __build_skb - build a network buffer * @data: data buffer provided by caller -* @frag_size: size of fragment, or 0 if head was kmalloced +* @frag_size: size of data, or 0 if head was kmalloced * * Allocate a new &sk_buff. Caller provides space holding head and * skb_shared_info. @data must have been allocated by kmalloc() only if -* @frag_size is 0, otherwise data should come from the page allocator. +* @frag_size is 0, otherwise data should come from the page allocator +* or vmalloc() * The return is the new skb buffer. * On a failure the return is %NULL, and @data is not freed. * Notes :
@@ -295,7 +296,7 @@ EXPORT_SYMBOL(__alloc_skb);* before giving packet to stack. * RX rings only contains data buffers, not full skbs. */ -struct sk_buff *build_skb (void *data,unsigned int frag_size) +struct sk_buff *__build_skb (void *data,unsigned int frag_size) {struct skb_shared_info *shinfo;struct sk_buff *skb;
@@ -309,11 +310,6 @@ struct sk_buff *build_skb(void *data, unmemset (skb,0 , offsetof(struct sk_buff , tail)); skb->truesize =SKB_TRUESIZE (size); -if (frag_size) { - skb->head_frag =1 ; -if (virt_to_head_page (data)->pfmemalloc) - skb->pfmemalloc =1 ; - }atomic_set (&skb->users,1 ); skb->head = data; skb->data = data;
@@ -330,6 +326,23 @@ struct sk_buff *build_skb(void *data, unreturn skb; } + +/* build_skb() is wrapper over __build_skb(), that specifically +* takes care of skb->head and skb->pfmemalloc +* This means that if @frag_size is not zero, then @data must be backed +* by a page fragment, not kmalloc() or vmalloc() +*/ +struct sk_buff *build_skb (void *data,unsigned int frag_size) +{ +struct sk_buff *skb =__build_skb (data, frag_size); + +if (skb && frag_size) { + skb->head_frag =1 ; +if (virt_to_head_page (data)->pfmemalloc) + skb->pfmemalloc =1 ; + } +return skb; +}EXPORT_SYMBOL (build_skb);struct netdev_alloc_cache {
net/netlink/af_netlink.c +2 -4
@@ -1624,13 +1624,11 @@ static struct sk_buff *netlink_alloc_larif (data ==NULL )return NULL ; - skb =build_skb (data, size); + skb =__build_skb (data, size);if (skb ==NULL )vfree (data); -else { - skb->head_frag =0 ; +else skb->destructor = netlink_skb_destructor; - }return skb; }
Greg Kroah-Hartman
maintainerPATCH 6/92 Btrfs: fix log tree corruption when fs mounted with -o discard
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit dcc82f4783ad91d4ab654f89f37ae9291cdc846a upstream.
While committing a transaction we free the log roots before we write the new super block. Freeing the log roots implies marking the disk location of every node/leaf (metadata extent) as pinned before the new super block is written. This is to prevent the disk location of log metadata extents from being reused before the new super block is written, otherwise we would have a corrupted log tree if before the new super block is written a crash/reboot happens and the location of any log tree metadata extent ended up being reused and rewritten.
Even though we pinned the log tree's metadata extents, we were issuing a discard against them if the fs was mounted with the -o discard option, resulting in corruption of the log tree if a crash/reboot happened before writing the new super block - the next time the fs was mounted, during the log replay process we would find nodes/leafs of the log btree with a content full of zeroes, causing the process to fail and require the use of the tool btrfs-zero-log to wipeout the log tree (and all data previously fsynced becoming lost forever).
Fix this by not doing a discard when pinning an extent. The discard will be done later when it's safe (after the new super block is committed) at extent-tree.c:btrfs_finish_extent_commit().
--- fs/btrfs/extent-tree.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
fs/btrfs/extent-tree.c +2 -3
@@ -6645,12 +6645,11 @@ static int __btrfs_free_reserved_extent(return -ENOSPC ; } -if (btrfs_test_opt (root,DISCARD )) - ret =btrfs_discard_extent (root, start, len,NULL ); -if (pin)pin_down_extent (root, cache, start, len,1 );else { +if (btrfs_test_opt (root,DISCARD )) + ret =btrfs_discard_extent (root, start, len,NULL );btrfs_add_free_space (cache, start, len);btrfs_update_reserved_bytes (cache, len,RESERVE_FREE ); }
Greg Kroah-Hartman
maintainerPATCH 7/92 btrfs: dont accept bare namespace as a valid xattr
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <[email protected]>
commit 3c3b04d10ff1811a27f86684ccd2f5ba6983211d upstream.
Due to insufficient check in btrfs_is_valid_xattr, this unexpectedly works:
$ touch file $ setfattr -n user. -v 1 file $ getfattr -d file user.="1"
ie. the missing attribute name after the namespace.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94291
--- fs/btrfs/xattr.c | 53 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 39 insertions(+), 14 deletions(-)
fs/btrfs/xattr.c +39 -14
@@ -324,22 +324,42 @@ const struct xattr_handler *btrfs_xattr_/* * Check if the attribute is in a supported namespace. * -* This applied after the check for the synthetic attributes in the system +* This is applied after the check for the synthetic attributes in the system * namespace. */ -static bool btrfs_is_valid_xattr (const char *name) +static int btrfs_is_valid_xattr (const char *name) { -return !strncmp (name,XATTR_SECURITY_PREFIX , -XATTR_SECURITY_PREFIX_LEN ) || - !strncmp (name,XATTR_SYSTEM_PREFIX ,XATTR_SYSTEM_PREFIX_LEN ) || - !strncmp (name,XATTR_TRUSTED_PREFIX ,XATTR_TRUSTED_PREFIX_LEN ) || - !strncmp (name,XATTR_USER_PREFIX ,XATTR_USER_PREFIX_LEN ) || - !strncmp (name,XATTR_BTRFS_PREFIX ,XATTR_BTRFS_PREFIX_LEN ); +int len =strlen (name); +int prefixlen =0 ; + +if (!strncmp (name,XATTR_SECURITY_PREFIX , +XATTR_SECURITY_PREFIX_LEN )) + prefixlen =XATTR_SECURITY_PREFIX_LEN ; +else if (!strncmp (name,XATTR_SYSTEM_PREFIX ,XATTR_SYSTEM_PREFIX_LEN )) + prefixlen =XATTR_SYSTEM_PREFIX_LEN ; +else if (!strncmp (name,XATTR_TRUSTED_PREFIX ,XATTR_TRUSTED_PREFIX_LEN )) + prefixlen =XATTR_TRUSTED_PREFIX_LEN ; +else if (!strncmp (name,XATTR_USER_PREFIX ,XATTR_USER_PREFIX_LEN )) + prefixlen =XATTR_USER_PREFIX_LEN ; +else if (!strncmp (name,XATTR_BTRFS_PREFIX ,XATTR_BTRFS_PREFIX_LEN )) + prefixlen =XATTR_BTRFS_PREFIX_LEN ; +else +return -EOPNOTSUPP ; + +/* +* The name cannot consist of just prefix +*/ +if (len <= prefixlen) +return -EINVAL ; + +return 0 ; }ssize_t btrfs_getxattr (struct dentry *dentry,const char *name,void *buffer,size_t size) { +int ret; +/* * If this is a request for a synthetic attribute in the system.* * namespace use the generic infrastructure to resolve a handler
@@ -348,8 +368,9 @@ ssize_t btrfs_getxattr(struct dentry *deif (!strncmp (name,XATTR_SYSTEM_PREFIX ,XATTR_SYSTEM_PREFIX_LEN ))return generic_getxattr (dentry, name, buffer, size); -if (!btrfs_is_valid_xattr (name)) -return -EOPNOTSUPP ; + ret =btrfs_is_valid_xattr (name); +if (ret) +return ret;return __btrfs_getxattr (dentry->d_inode, name, buffer, size); }
@@ -357,6 +378,7 @@ int btrfs_setxattr(struct dentry *dentry size_t size, int flags) {struct btrfs_root *root =BTRFS_I (dentry->d_inode)->root; +int ret;/* * The permission on security.* and system.* is not checked
@@ -373,8 +395,9 @@ int btrfs_setxattr(struct dentry *dentryif (!strncmp (name,XATTR_SYSTEM_PREFIX ,XATTR_SYSTEM_PREFIX_LEN ))return generic_setxattr (dentry, name, value, size, flags); -if (!btrfs_is_valid_xattr (name)) -return -EOPNOTSUPP ; + ret =btrfs_is_valid_xattr (name); +if (ret) +return ret;if (!strncmp (name,XATTR_BTRFS_PREFIX ,XATTR_BTRFS_PREFIX_LEN )) return btrfs_set_prop(dentry->d_inode, name,
@@ -390,6 +413,7 @@ int btrfs_setxattr(struct dentry *dentryint btrfs_removexattr (struct dentry *dentry,const char *name) {struct btrfs_root *root =BTRFS_I (dentry->d_inode)->root; +int ret;/* * The permission on security.* and system.* is not checked
@@ -406,8 +430,9 @@ int btrfs_removexattr(struct dentry *denif (!strncmp (name,XATTR_SYSTEM_PREFIX ,XATTR_SYSTEM_PREFIX_LEN ))return generic_removexattr (dentry, name); -if (!btrfs_is_valid_xattr (name)) -return -EOPNOTSUPP ; + ret =btrfs_is_valid_xattr (name); +if (ret) +return ret;if (!strncmp (name,XATTR_BTRFS_PREFIX ,XATTR_BTRFS_PREFIX_LEN )) return btrfs_set_prop(dentry->d_inode, name,
Greg Kroah-Hartman
maintainerPATCH 8/92 Btrfs: fix inode eviction infinite loop after cloning into it
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit ccccf3d67294714af2d72a6fd6fd7d73b01c9329 upstream.
If we attempt to clone a 0 length region into a file we can end up inserting a range in the inode's extent_io tree with a start offset that is greater then the end offset, which triggers immediately the following warning:
[ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3914.620886] BTRFS: end < start 4095 4096 (...) [ 3914.638093] Call Trace: [ 3914.638636] [<ffffffff81425fd9>] dump_stack+0x4c/0x65 [ 3914.639620] [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb [ 3914.640789] [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs] [ 3914.642041] [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48 [ 3914.643236] [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs] [ 3914.644441] [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3914.645711] [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs] [ 3914.646914] [<ffffffff8142b2fb>] ? _raw_spin_unlock+0x28/0x33 [ 3914.648058] [<ffffffffa03cbac4>] ? test_range_bit+0xcc/0xde [btrfs] [ 3914.650105] [<ffffffffa03cb3c3>] lock_extent+0x13/0x15 [btrfs] [ 3914.651361] [<ffffffffa03db39e>] lock_extent_range+0x3d/0xcd [btrfs] [ 3914.652761] [<ffffffffa03de1fe>] btrfs_ioctl_clone+0x278/0x388 [btrfs] [ 3914.654128] [<ffffffff811226dd>] ? might_fault+0x58/0xb5 [ 3914.655320] [<ffffffffa03e0909>] btrfs_ioctl+0xb51/0x2195 [btrfs] (...) [ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]---
This later makes the inode eviction handler enter an infinite loop that keeps dumping the following warning over and over:
[ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3915.119913] BTRFS: end < start 4095 4096 (...) [ 3915.137394] Call Trace: [ 3915.137913] [<ffffffff81425fd9>] dump_stack+0x4c/0x65 [ 3915.139154] [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb [ 3915.140316] [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs] [ 3915.141505] [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48 [ 3915.142709] [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs] [ 3915.143849] [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3915.145120] [<ffffffffa038c1e3>] ? btrfs_kill_super+0x17/0x23 [btrfs] [ 3915.146352] [<ffffffff811548f6>] ? deactivate_locked_super+0x3b/0x50 [ 3915.147565] [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs] [ 3915.148785] [<ffffffff8142b7e2>] ? _raw_write_unlock+0x28/0x33 [ 3915.149931] [<ffffffffa03bc325>] btrfs_evict_inode+0x196/0x482 [btrfs] [ 3915.151154] [<ffffffff81168904>] evict+0xa0/0x148 [ 3915.152094] [<ffffffff811689e5>] dispose_list+0x39/0x43 [ 3915.153081] [<ffffffff81169564>] evict_inodes+0xdc/0xeb [ 3915.154062] [<ffffffff81154418>] generic_shutdown_super+0x49/0xef [ 3915.155193] [<ffffffff811546d1>] kill_anon_super+0x13/0x1e [ 3915.156274] [<ffffffffa038c1e3>] btrfs_kill_super+0x17/0x23 [btrfs] (...) [ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]---
So just bail out of the clone ioctl if the length of the region to clone is zero, without locking any extent range, in order to prevent this issue (same behaviour as a pwrite with a 0 length for example).
This is trivial to reproduce. For example, the steps for the test I just made for fstests:
mkfs.btrfs -f SCRATCH_DEV
mount SCRATCH_DEV $SCRATCH_MNT
touch $SCRATCH_MNT/foo
touch $SCRATCH_MNT/bar
$CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar umount $SCRATCH_MNT
A test case for fstests follows soon.
--- fs/btrfs/ioctl.c | 5 +++++ 1 file changed, 5 insertions(+)
fs/btrfs/ioctl.c +5 -0
@@ -3226,6 +3226,11 @@ static noinline long btrfs_ioctl_clone(sif (off + len == src->i_size) len =ALIGN (src->i_size, bs) - off; +if (len ==0 ) { + ret =0 ; + goto out_unlock; + } +/* verify the end result is block aligned */ if (!IS_ALIGNED (off, bs) || !IS_ALIGNED (off + len, bs) || !IS_ALIGNED (destoff, bs))
Greg Kroah-Hartman
maintainerPATCH 9/92 Btrfs: fix inode eviction infinite loop after extent_same ioctl
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 113e8283869b9855c8b999796aadd506bbac155f upstream.
If we pass a length of 0 to the extent_same ioctl, we end up locking an extent range with a start offset greater then its end offset (if the destination file's offset is greater than zero). This results in a warning from extent_io.c:insert_state through the following call chain:
btrfs_extent_same()
btrfs_double_lock()
lock_extent_range()
lock_extent(inode->io_tree, offset, offset + len - 1)
lock_extent_bits()
__set_extent_bit()
insert_state()
--> WARN_ON(end < start)This leads to an infinite loop when evicting the inode. This is the same problem that my previous patch titled
"Btrfs: fix inode eviction infinite loop after cloning into it" addressed but for the extent_same ioctl instead of the clone ioctl.
--- fs/btrfs/ioctl.c | 3 +++ 1 file changed, 3 insertions(+)
fs/btrfs/ioctl.c +3 -0
@@ -2708,6 +2708,9 @@ static int btrfs_extent_same(struct inodif (src == dst)return -EINVAL ; +if (len ==0 ) +return 0 ; +btrfs_double_lock (src, loff, dst, dst_loff, len); ret =extent_same_check_offsets (src, loff, len);
Greg Kroah-Hartman
maintainercover 3.14.41-stable review
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.14.41-rc1
Jann Horn <[email protected]>
fs: take i_mutex during prepare_binprm for set[ug]id executables
Junjie Mao <[email protected]>
driver core: bus: Goto appropriate labels on failure in bus_add_device
Dan Carpenter <[email protected]>
memstick: mspro_block: add missing curly braces
Nishanth Menon <[email protected]>
C6x: time: Ensure consistency in __init
Vutla, Lokesh <[email protected]>
crypto: omap-aes - Fix support for unequal lengths
Nicolas Iooss <[email protected]>
wl18xx: show rx_frames_per_rates as an array as it really is
mancha security <[email protected]>
lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
Sabrina Dubroca <[email protected]>
e1000: add dummy allocator to fix race condition between mtu change and netpoll
Calvin Owens <[email protected]>
ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
Al Viro <[email protected]>
RCU pathwalk breakage when running into a symlink overmounting something
Dmitry Torokhov <[email protected]>
drm/i915: cope with large i2c transfers
Alex Deucher <[email protected]>
drm/radeon: fix doublescan modes (v2)
Mark Brown <[email protected]>
i2c: core: Export bus recovery functions
Erez Shitrit <[email protected]>
IB/mlx4: Fix WQE LSO segment calculation
Yann Droneaud <[email protected]>
IB/core: don't disallow registering region starting at 0x0
Yann Droneaud <[email protected]>
IB/core: disallow registering 0-sized memory region
Ezequiel Garcia <[email protected]>
stk1160: Make sure current buffer is released
James Bottomley <[email protected]>
mvsas: fix panic on expander attached SATA devices
K. Y. Srinivasan <[email protected]>
Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()
Ben Collins <[email protected]>
dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
Archit Taneja <[email protected]>
clk: qcom: fix RCG M/N counter configuration
Thierry Reding <[email protected]>
clk: tegra: Register the proper number of resets
Alexandre Courbot <[email protected]>
gpio: clamp returned values to the boolean range
Gregory CLEMENT <[email protected]>
gpio: mvebu: Fix mask/unmask managment per irq chip type
Max Filippov <[email protected]>
xtensa: ISS: fix locking in TAP network adapter
Max Filippov <[email protected]>
xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range
Max Filippov <[email protected]>
xtensa: xtfpga: fix hardware lockup caused by LCD driver
Rafael J. Wysocki <[email protected]>
ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()
Lv Zheng <[email protected]>
ACPICA: Utilities: split IO address types from data type models.
Manish Badarkhe <[email protected]>
ASoC: davinci-evm: drop un-necessary remove function
Michael Ellerman <[email protected]>
powerpc/cell: Fix cell iommu after it_page_shift changes
Dave Olson <[email protected]>
powerpc: Fix missing L2 cache size in /sys/devices/system/cpu
Alexander Ploumistos <[email protected]>
Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card
Akinobu Mita <[email protected]>
target/file: Fix SG table for prot_buf initialization
Akinobu Mita <[email protected]>
target/file: Fix BUG() when CONFIG_DEBUG_SG=y and DIF protection enabled
Nicholas Bellinger <[email protected]>
target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling
K. Y. Srinivasan <[email protected]>
scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
Brian Norris <[email protected]>
UBI: fix check for "too many bytes"
Brian Norris <[email protected]>
UBI: initialize LEB number variable
Brian Norris <[email protected]>
UBI: fix out of bounds write
Brian Norris <[email protected]>
UBI: account for bitflips in both the VID header and data
Thomas D <[email protected]>
tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile
Steven Rostedt (Red Hat) <[email protected]>
tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING
Anton Blanchard <[email protected]>
powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
Lukas Czerner <[email protected]>
ext4: make fsync to sync parent dir in no-journal for real this time
Rob Clark <[email protected]>
drm/msm: use componentised device support
Ben Hutchings <[email protected]>
bfa: Replace large udelay() with mdelay()
Arun Chandran <[email protected]>
arm64: vdso: fix build error when switching from LE to BE
Marek Vasut <[email protected]>
rtlwifi: rtl8192cu: Add new device ID
Larry Finger <[email protected]>
rtlwifi: rtl8192cu: Add new USB ID
Oleg Nesterov <[email protected]>
ptrace: fix race between ptrace_resume() and wait_task_stopped()
Michael Davidson <[email protected]>
fs/binfmt_elf.c: fix bug in loading of PIE binaries
Ulrik De Bie <[email protected]>
Input: elantech - fix absolute mode setting on some ASUS laptops
Michael Gernoth <[email protected]>
ALSA: emu10k1: don't deadlock in proc-functions
Felipe Balbi <[email protected]>
usb: core: hub: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: dwc2: hcd: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: sl811: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: xhci: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: isp116x: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: r8a66597: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: fotg210: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: uhci: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: fusbh200: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: define a generic USB_RESUME_TIMEOUT macro
Axel Lin <[email protected]>
usb: phy: Find the right match in devm_usb_phy_match
Sebastian Hesselbarth <[email protected]>
ARM: dts: dove: Fix uart[23] reg property
Nicolas Ferre <[email protected]>
ARM: at91/dt: sama5d3 xplained: add phy address for macb1
Charles Keepax <[email protected]>
ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
Andrey Ryabinin <[email protected]>
ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE
Andrew Elble <[email protected]>
NFS: fix BUG() crash in notify_change() with patch to chown_common()
Krzysztof Kozlowski <[email protected]>
power_supply: lp8788-charger: Fix leaked power supply on probe fail
Krzysztof Kozlowski <[email protected]>
power_supply: twl4030_madc: Check return value of power_supply_register
Steven Rostedt <[email protected]>
ring-buffer: Replace this_cpu_*() with __this_cpu_*()
Krzysztof Kozlowski <[email protected]>
compal-laptop: Check return value of power_supply_register
Ian Abbott <[email protected]>
spi: spidev: fix possible arithmetic overflow for multi-transfer message
Oliver Neukum <[email protected]>
cdc-wdm: fix endianness bug in debug statements
NeilBrown <[email protected]>
md/raid0: fix bug with chunksize not a power of 2.
Huacai Chen <[email protected]>
MIPS: Hibernate: flush TLB entries earlier
Radim Krčmář <[email protected]>
KVM: use slowpath for cross page cached accesses
Heiko Carstens <[email protected]>
s390/hibernate: fix save and restore of kernel text section
Ekaterina Tumanova <[email protected]>
KVM: s390: Zero out current VMDB of STSI before including level3 data.
Felipe Balbi <[email protected]>
usb: gadget: composite: enable BESL support
Len Brown <[email protected]>
sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance
Filipe Manana <[email protected]>
Btrfs: fix inode eviction infinite loop after extent_same ioctl
Filipe Manana <[email protected]>
Btrfs: fix inode eviction infinite loop after cloning into it
David Sterba <[email protected]>
btrfs: don't accept bare namespace as a valid xattr
Filipe Manana <[email protected]>
Btrfs: fix log tree corruption when fs mounted with -o discard
Eric Dumazet <[email protected]>
net: fix crash in build_skb()
Eric Dumazet <[email protected]>
net: do not deplete pfmemalloc reserve
Eric Dumazet <[email protected]>
tcp: avoid looping in tcp_send_fin()
Eric Dumazet <[email protected]>
tcp: fix possible deadlock in tcp_send_fin()
Sebastian Pöhn <[email protected]>
ip_forward: Drop frames with attached skb->sk
-------------
Diffstat:
Makefile | 4 +- arch/arm/boot/dts/at91-sama5d3_xplained.dts | 6 ++ arch/arm/boot/dts/dove.dtsi | 4 +- arch/arm/include/asm/elf.h | 2 +- arch/arm/mach-s3c64xx/crag6410.h | 1 + arch/arm/mach-s3c64xx/mach-crag6410.c | 1 + arch/arm64/kernel/vdso/Makefile | 2 +- arch/c6x/kernel/time.c | 2 +- arch/mips/power/hibernate.S | 3 +- arch/powerpc/kernel/cacheinfo.c | 44 ++++++-- arch/powerpc/perf/callchain.c | 2 +- arch/powerpc/platforms/cell/iommu.c | 2 +- arch/s390/kernel/suspend.c | 4 + arch/s390/kvm/priv.c | 1 + arch/x86/include/asm/mwait.h | 8 ++ arch/x86/kernel/process.c | 50 +++++++++ arch/xtensa/Kconfig | 30 ++++++ arch/xtensa/include/uapi/asm/unistd.h | 2 +- arch/xtensa/platforms/iss/network.c | 29 +++--- arch/xtensa/platforms/xtfpga/Makefile | 3 +- .../platforms/xtfpga/include/platform/hardware.h | 3 - .../xtensa/platforms/xtfpga/include/platform/lcd.h | 15 +++ arch/xtensa/platforms/xtfpga/lcd.c | 55 ++++++---- drivers/acpi/scan.c | 6 +- drivers/base/bus.c | 4 +- drivers/bluetooth/ath3k.c | 1 + drivers/bluetooth/btusb.c | 1 + drivers/clk/qcom/clk-rcg2.c | 2 +- drivers/clk/tegra/clk.c | 2 +- drivers/crypto/omap-aes.c | 14 ++- drivers/gpio/gpio-mvebu.c | 24 +++-- drivers/gpio/gpiolib.c | 12 +-- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_i2c.c | 66 ++++++++++-- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 49 ++++++--- drivers/gpu/drm/msm/hdmi/hdmi.c | 42 +++++--- drivers/gpu/drm/msm/msm_drv.c | 112 ++++++++++++++++++++- drivers/gpu/drm/msm/msm_drv.h | 4 + drivers/gpu/drm/radeon/atombios_crtc.c | 8 +- drivers/hv/channel.c | 7 +- drivers/i2c/i2c-core.c | 3 + drivers/infiniband/core/umem.c | 7 +- drivers/infiniband/hw/mlx4/qp.c | 3 +- drivers/input/mouse/elantech.c | 22 ++++ drivers/input/mouse/elantech.h | 1 + drivers/md/dm-crypt.c | 12 +-- drivers/md/raid0.c | 3 +- drivers/media/usb/stk1160/stk1160-v4l.c | 17 +++- drivers/memstick/core/mspro_block.c | 3 +- drivers/mtd/ubi/attach.c | 2 +- drivers/mtd/ubi/cdev.c | 2 +- drivers/mtd/ubi/eba.c | 3 +- drivers/mtd/ubi/wl.c | 2 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +- drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 2 + drivers/net/wireless/ti/wl18xx/debugfs.c | 2 +- drivers/net/wireless/ti/wlcore/debugfs.h | 4 +- drivers/platform/x86/compal-laptop.c | 4 +- drivers/power/lp8788-charger.c | 4 +- drivers/power/twl4030_madc_battery.c | 7 +- drivers/scsi/bfa/bfa_ioc.c | 2 +- drivers/scsi/mvsas/mv_sas.c | 5 +- drivers/scsi/storvsc_drv.c | 15 +-- drivers/spi/spidev.c | 5 +- drivers/target/target_core_file.c | 36 +++---- drivers/target/target_core_sbc.c | 15 ++- drivers/target/target_core_transport.c | 37 ++++++- drivers/usb/class/cdc-wdm.c | 12 ++- drivers/usb/core/hub.c | 4 +- drivers/usb/dwc2/hcd.c | 2 +- drivers/usb/gadget/composite.c | 2 +- drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/fusbh200-hcd.c | 3 +- drivers/usb/host/isp116x-hcd.c | 2 +- drivers/usb/host/r8a66597-hcd.c | 2 +- drivers/usb/host/sl811-hcd.c | 2 +- drivers/usb/host/uhci-hub.c | 5 +- drivers/usb/host/xhci-ring.c | 2 +- drivers/usb/phy/phy.c | 4 +- fs/binfmt_elf.c | 9 +- fs/btrfs/extent-tree.c | 5 +- fs/btrfs/ioctl.c | 8 ++ fs/btrfs/xattr.c | 53 +++++++--- fs/exec.c | 76 ++++++++------ fs/ext4/namei.c | 20 ++-- fs/namei.c | 6 +- fs/open.c | 2 +- include/acpi/actypes.h | 20 ++++ include/acpi/platform/acenv.h | 1 + include/linux/skbuff.h | 1 + include/linux/usb.h | 26 +++++ include/target/target_core_base.h | 2 +- kernel/ptrace.c | 20 ++++ kernel/softirq.c | 6 +- kernel/trace/ring_buffer.c | 11 +- lib/string.c | 2 +- net/core/skbuff.c | 30 ++++-- net/ipv4/ip_forward.c | 3 + net/ipv4/tcp_output.c | 64 ++++++++---- net/netlink/af_netlink.c | 6 +- sound/pci/emu10k1/emuproc.c | 12 --- sound/soc/davinci/davinci-evm.c | 10 -- tools/lib/traceevent/kbuffer-parse.c | 1 - tools/power/x86/turbostat/Makefile | 6 +- virt/kvm/kvm_main.c | 4 +- 105 files changed, 964 insertions(+), 338 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 24/92 ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Ryabinin <[email protected]>
commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream.
Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel split this is not so, because 2*TASK_SIZE overflows 32 bits, so the actual value of ELF_ET_DYN_BASE is:
(2 * TASK_SIZE / 3) = 0x2a000000
When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address. On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000] for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled as it fails to map shadow memory.
Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries has a high chance of loading somewhere in between [0x2a000000 - 0x40000000] even if ASLR enabled. This makes ASan with PIE absolutely incompatible.
Fix overflow by dividing TASK_SIZE prior to multiplying. After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y):
(TASK_SIZE / 3 * 2) = 0x7f555554
[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping
--- arch/arm/include/asm/elf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/include/asm/elf.h +1 -1
@@ -114,7 +114,7 @@ int dump_task_regs(struct task_struct *tthe loader. We need to make sure that it is out of the way of the program that it will "exec", and that there is sufficient room for the brk. */ -#define ELF_ET_DYN_BASE (2 * TASK_SIZE / 3) +#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)/* When the program starts, a1 contains a pointer to a function to be registered with atexit, as per the SVR4 ABI. A value of 0 means we
Greg Kroah-Hartman
maintainerPATCH 33/92 usb: host: r8a66597: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 7a606ac29752a3e571b83f9b3fceb1eaa1d37781 upstream.
While this driver was already using a 50ms resume timeout, let's make sure everybody uses the same macro so it's easy to fix later should anything go wrong.
It also gives a more "stable" expectation to Linux users.
--- drivers/usb/host/r8a66597-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/r8a66597-hcd.c +1 -1
@@ -2300,7 +2300,7 @@ static int r8a66597_bus_resume(struct us rh->port &= ~USB_PORT_STAT_SUSPEND ; rh->port |=USB_PORT_STAT_C_SUSPEND <<16 ;r8a66597_mdfy (r8a66597,RESUME ,RESUME |UACT , dvstctr_reg); -msleep (50 ); +msleep (USB_RESUME_TIMEOUT );r8a66597_mdfy (r8a66597,UACT ,RESUME |UACT , dvstctr_reg); }
Greg Kroah-Hartman
maintainerPATCH 34/92 usb: host: isp116x: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 8c0ae6574ccfd3d619876a65829aad74c9d22ba5 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/host/isp116x-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/isp116x-hcd.c +1 -1
@@ -1487,7 +1487,7 @@ static int isp116x_bus_resume(struct usbspin_unlock_irq (&isp116x->lock); hcd->state =HC_STATE_RESUMING ; -msleep (20 ); +msleep (USB_RESUME_TIMEOUT );/* Go operational */ spin_lock_irq (&isp116x->lock);
Greg Kroah-Hartman
maintainerPATCH 35/92 usb: host: xhci: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 upstream.
Make sure we're using the new macro, so our resume signaling will always pass certification.
--- drivers/usb/host/xhci-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci-ring.c +1 -1
@@ -1768,7 +1768,7 @@ static void handle_port_status(struct xh }else {xhci_dbg (xhci,"resume HS port %d\n" , port_id); bus_state->resume_done[faked_port_index] = jiffies + -msecs_to_jiffies (20 ); +msecs_to_jiffies (USB_RESUME_TIMEOUT );set_bit (faked_port_index, &bus_state->resuming_ports);mod_timer (&hcd->rh_timer, bus_state->resume_done[faked_port_index]);
Greg Kroah-Hartman
maintainerPATCH 37/92 usb: dwc2: hcd: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 74bd7b69801819707713b88e9d0bc074efa2f5e7 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/dwc2/hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/dwc2/hcd.c +1 -1
@@ -1501,7 +1501,7 @@ static int dwc2_hcd_hub_control(struct ddev_dbg (hsotg->dev,"ClearPortFeature USB_PORT_FEAT_SUSPEND\n" );writel (0 , hsotg->regs +PCGCTL ); -usleep_range (20000 ,40000 ); +msleep (USB_RESUME_TIMEOUT ); hprt0 =dwc2_read_hprt0 (hsotg); hprt0 |=HPRT0_RES ;
Greg Kroah-Hartman
maintainerPATCH 38/92 usb: core: hub: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit bbc78c07a51f6fd29c227b1220a9016e585358ba upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/core/hub.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/core/hub.c +2 -2
@@ -3289,10 +3289,10 @@ int usb_port_resume(struct usb_device *udev_dbg (hub->intfdev,"can't resume port %d, status %d\n" , port1, status); }else { -/* drive resume for at least 20 msec */ +/* drive resume for USB_RESUME_TIMEOUT msec */ dev_dbg (&udev->dev,"usb %sresume\n" , (PMSG_IS_AUTO (msg) ?"auto-" :"" )); -msleep (25 ); +msleep (USB_RESUME_TIMEOUT );/* Virtual root hubs can trigger on GET_PORT_STATUS to * stop resume signaling. Then finish the resume
Greg Kroah-Hartman
maintainerPATCH 39/92 ALSA: emu10k1: dont deadlock in proc-functions
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Gernoth <[email protected]>
commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream.
The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock.
Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock.
[removed superfluous flags variables too -- tiwai]
--- sound/pci/emu10k1/emuproc.c | 12 ------------ 1 file changed, 12 deletions(-)
sound/pci/emu10k1/emuproc.c +0 -12
@@ -241,31 +241,22 @@ static void snd_emu10k1_proc_spdif_read(struct snd_emu10k1 *emu = entry->private_data;u32 value;u32 value2; -unsigned long flags;u32 rate;if (emu->card_capabilities->emu_model) { -spin_lock_irqsave (&emu->emu_lock, flags);snd_emu1010_fpga_read (emu,0x38 , &value); -spin_unlock_irqrestore (&emu->emu_lock, flags);if ((value &0x1 ) ==0 ) { -spin_lock_irqsave (&emu->emu_lock, flags);snd_emu1010_fpga_read (emu,0x2a , &value);snd_emu1010_fpga_read (emu,0x2b , &value2); -spin_unlock_irqrestore (&emu->emu_lock, flags); rate =0x1770000 / (((value <<5 ) | value2)+1 );snd_iprintf (buffer,"ADAT Locked : %u\n" , rate); }else {snd_iprintf (buffer,"ADAT Unlocked\n" ); } -spin_lock_irqsave (&emu->emu_lock, flags);snd_emu1010_fpga_read (emu,0x20 , &value); -spin_unlock_irqrestore (&emu->emu_lock, flags);if ((value &0x4 ) ==0 ) { -spin_lock_irqsave (&emu->emu_lock, flags);snd_emu1010_fpga_read (emu,0x28 , &value);snd_emu1010_fpga_read (emu,0x29 , &value2); -spin_unlock_irqrestore (&emu->emu_lock, flags); rate =0x1770000 / (((value <<5 ) | value2)+1 );snd_iprintf (buffer,"SPDIF Locked : %d\n" , rate); }else {
@@ -410,14 +401,11 @@ static void snd_emu_proc_emu1010_reg_rea {struct snd_emu10k1 *emu = entry->private_data;u32 value; -unsigned long flags;int i;snd_iprintf (buffer,"EMU1010 Registers:\n\n" );for (i =0 ; i <0x40 ; i+=1 ) { -spin_lock_irqsave (&emu->emu_lock, flags);snd_emu1010_fpga_read (emu, i, &value); -spin_unlock_irqrestore (&emu->emu_lock, flags);snd_iprintf (buffer,"%02X: %08X, %02X\n" , i, value, (value >>8 ) &0x7f ); } }
Greg Kroah-Hartman
maintainerPATCH 42/92 ptrace: fix race between ptrace_resume() and wait_task_stopped()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.
ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee.
This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal.
Test-case:
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <pthread.h>
#include <assert.h>
int pid;
void *waiter(void *arg)
{
int stat;
for (;;) {
assert(pid == wait(&stat));
assert(WIFSTOPPED(stat));
if (WSTOPSIG(stat) == SIGHUP)
continue;
assert(WSTOPSIG(stat) == SIGCONT);
printf("ERR! extra/wrong report:%x\n", stat);
}
}
int main(void)
{
pthread_t thread;
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
for (;;)
kill(getpid(), SIGHUP);
}
assert(pthread_create(&thread, NULL, waiter, NULL) == 0);
for (;;)
ptrace(PTRACE_CONT, pid, 0, SIGCONT);
return 0;
}Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child).
--- kernel/ptrace.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
kernel/ptrace.c +20 -0
@@ -720,6 +720,8 @@ static int ptrace_peek_siginfo(struct tastatic int ptrace_resume (struct task_struct *child,long request,unsigned long data) { +bool need_siglock; +if (!valid_signal (data))return -EIO ;
@@ -747,8 +749,26 @@ static int ptrace_resume(struct task_struser_disable_single_step (child); } +/* +* Change ->exit_code and ->state under siglock to avoid the race +* with wait_task_stopped() in between; a non-zero ->exit_code will +* wrongly look like another report from tracee. +* +* Note that we need siglock even if ->exit_code == data and/or this +* status was not reported yet, the new status must not be cleared by +* wait_task_stopped() after resume. +* +* If data == 0 we do not care if wait_task_stopped() reports the old +* status and clears the code too; this can't race with the tracee, it +* takes siglock after resume. +*/ + need_siglock = data && !thread_group_empty (current); +if (need_siglock) +spin_lock_irq (&child->sighand->siglock); child->exit_code = data;wake_up_state (child, __TASK_TRACED); +if (need_siglock) +spin_unlock_irq (&child->sighand->siglock);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 43/92 rtlwifi: rtl8192cu: Add new USB ID
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream.
USB ID 2001:330d is used for a D-Link DWA-131.
--- drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c +1 -0
@@ -370,6 +370,7 @@ static struct usb_device_id rtl8192c_usb {RTL_USB_DEVICE(0x2001, 0x3307, rtl92cu_hal_cfg)}, /*D-Link-Cameo*/ {RTL_USB_DEVICE(0x2001, 0x3309, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/ {RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/ + {RTL_USB_DEVICE(0x2001, 0x330d, rtl92cu_hal_cfg)}, /*D-Link DWA-131 */ {RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/ {RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/ {RTL_USB_DEVICE(0x2357, 0x0100, rtl92cu_hal_cfg)}, /*TP-Link WN8200ND*/
Greg Kroah-Hartman
maintainerPATCH 44/92 rtlwifi: rtl8192cu: Add new device ID
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Vasut <[email protected]>
commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 upstream.
Add new ID for ASUS N10 WiFi dongle.
--- drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c +1 -0
@@ -314,6 +314,7 @@ static struct usb_device_id rtl8192c_usb {RTL_USB_DEVICE(0x07b8, 0x8188, rtl92cu_hal_cfg)}, /*Abocom - Abocom*/ {RTL_USB_DEVICE(0x07b8, 0x8189, rtl92cu_hal_cfg)}, /*Funai - Abocom*/ {RTL_USB_DEVICE(0x0846, 0x9041, rtl92cu_hal_cfg)}, /*NetGear WNA1000M*/ + {RTL_USB_DEVICE(0x0b05, 0x17ba, rtl92cu_hal_cfg)}, /*ASUS-Edimax*/ {RTL_USB_DEVICE(0x0bda, 0x5088, rtl92cu_hal_cfg)}, /*Thinkware-CC&C*/ {RTL_USB_DEVICE(0x0df6, 0x0052, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/ {RTL_USB_DEVICE(0x0df6, 0x005c, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
Greg Kroah-Hartman
maintainerPATCH 45/92 arm64: vdso: fix build error when switching from LE to BE
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arun Chandran <[email protected]>
commit 1915e2ad1cf548217c963121e4076b3d44dd0169 upstream.
Building a kernel with CPU_BIG_ENDIAN fails if there are stale objects from a !CPU_BIG_ENDIAN build. Due to a missing FORCE prerequisite on an if_changed rule in the VDSO Makefile, we attempt to link a stale LE object into the new BE kernel.
According to Documentation/kbuild/makefiles.txt, FORCE is required for if_changed rules and forgetting it is a common mistake, so fix it by 'Forcing' the build of vdso. This patch fixes build errors like these:
arch/arm64/kernel/vdso/note.o: compiled for a little endian system and target is big endian failed to merge target specific data of file arch/arm64/kernel/vdso/note.o
arch/arm64/kernel/vdso/sigreturn.o: compiled for a little endian system and target is big endian failed to merge target specific data of file arch/arm64/kernel/vdso/sigreturn.o
--- arch/arm64/kernel/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/vdso/Makefile +1 -1
@@ -43,7 +43,7 @@ $(obj)/vdso-offsets.h: $(obj)/vdso.so.db $(call if_changed,vdsosym) # Assembly rules for the .S files -$(obj-vdso): %.o: %.S +$(obj-vdso): %.o: %.S FORCE $(call if_changed_dep,vdsoas) # Actual build commands
Greg Kroah-Hartman
maintainerPATCH 46/92 bfa: Replace large udelay() with mdelay()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit b367dcaa512922e9207160bef0895622cfae4c9f upstream.
udelay() does not work on some architectures for values above 2000, in particular on ARM:
ERROR: "__bad_udelay" [drivers/scsi/bfa/bfa.ko] undefined!
--- drivers/scsi/bfa/bfa_ioc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/bfa/bfa_ioc.c +1 -1
@@ -7006,7 +7006,7 @@ bfa_flash_sem_get(void __iomem *bar)while (!bfa_raw_sem_get (bar)) {if (--n <=0 )return BFA_STATUS_BADFLASH ; -udelay (10000 ); +mdelay (10 ); }return BFA_STATUS_OK ; }
Greg Kroah-Hartman
maintainerPATCH 47/92 drm/msm: use componentised device support
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Clark <[email protected]>
commit 060530f1ea6740eb767085008d183f89ccdd289c upstream.
---
Please consider adding this patch to v3.14, to fix a build error seen with arm:allmodconfig.
Rob, it would be great if you can have a look to ensure that I did not miss anything.
Build results:
total: 125 pass: 125 fail: 0
Qemu test results:
total: 30 pass: 30 fail: 0
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 49 ++++++++++---- drivers/gpu/drm/msm/hdmi/hdmi.c | 42 +++++++++--- drivers/gpu/drm/msm/msm_drv.c | 112 ++++++++++++++++++++++++++++++++-- drivers/gpu/drm/msm/msm_drv.h | 4 + 4 files changed, 176 insertions(+), 31 deletions(-)
drivers/gpu/drm/msm/adreno/a3xx_gpu.c +34 -15
@@ -35,8 +35,6 @@ A3XX_INT0_CP_AHB_ERROR_HALT | \ A3XX_INT0_UCHE_OOB_ACCESS) -static struct platform_device *a3xx_pdev; -static void a3xx_me_init (struct msm_gpu *gpu) {struct msm_ringbuffer *ring = gpu->rb;
@@ -311,7 +309,6 @@ static void a3xx_destroy(struct msm_gpuocmem_free (OCMEM_GRAPHICS , a3xx_gpu->ocmem_hdl);#endif -put_device (&a3xx_gpu->pdev->dev);kfree (a3xx_gpu); }
@@ -439,7 +436,8 @@ struct msm_gpu *a3xx_gpu_init(struct drmstruct a3xx_gpu *a3xx_gpu =NULL ;struct adreno_gpu *adreno_gpu;struct msm_gpu *gpu; -struct platform_device *pdev = a3xx_pdev; +struct msm_drm_private *priv = dev->dev_private; +struct platform_device *pdev = priv->gpu_pdev;struct adreno_platform_config *config;int ret;
@@ -460,7 +458,6 @@ struct msm_gpu *a3xx_gpu_init(struct drm adreno_gpu = &a3xx_gpu->base; gpu = &adreno_gpu->base; -get_device (&pdev->dev); a3xx_gpu->pdev = pdev; gpu->fast_rate = config->fast_rate;
@@ -522,17 +519,24 @@ fail:# include <mach/kgsl.h> #endif -static int a3xx_probe (struct platform_device *pdev) +static void set_gpu_pdev (struct drm_device *dev, +struct platform_device *pdev) +{ +struct msm_drm_private *priv = dev->dev_private; + priv->gpu_pdev = pdev; +} + +static int a3xx_bind (struct device *dev,struct device *master,void *data) {static struct adreno_platform_config config = {};#ifdef CONFIG_OF -struct device_node *child, *node = pdev->dev.of_node; +struct device_node *child, *node = dev->of_node;u32 val;int ret; ret =of_property_read_u32 (node,"qcom,chipid" , &val);if (ret) { -dev_err (&pdev->dev,"could not find chipid: %d\n" , ret); +dev_err (dev,"could not find chipid: %d\n" , ret);return ret; }
@@ -548,7 +552,7 @@ static int a3xx_probe(struct platform_defor_each_child_of_node (child, pwrlvl) { ret =of_property_read_u32 (pwrlvl,"qcom,gpu-freq" , &val);if (ret) { -dev_err (&pdev->dev,"could not find gpu-freq: %d\n" , ret); +dev_err (dev,"could not find gpu-freq: %d\n" , ret);return ret; } config.fast_rate =max (config.fast_rate, val);
@@ -558,12 +562,12 @@ static int a3xx_probe(struct platform_de }if (!config.fast_rate) { -dev_err (&pdev->dev,"could not find clk rates\n" ); +dev_err (dev,"could not find clk rates\n" );return -ENXIO ; }#else -struct kgsl_device_platform_data *pdata = pdev->dev.platform_data; +struct kgsl_device_platform_data *pdata = dev->platform_data;uint32_t version =socinfo_get_version ();if (cpu_is_apq8064ab ()) { config.fast_rate =450000000 ;
@@ -609,14 +613,30 @@ static int a3xx_probe(struct platform_de config.bus_scale_table = pdata->bus_scale_table;# endif #endif - pdev->dev.platform_data = &config; - a3xx_pdev = pdev; + dev->platform_data = &config; +set_gpu_pdev (dev_get_drvdata (master),to_platform_device (dev));return 0 ; } +static void a3xx_unbind (struct device *dev,struct device *master, +void *data) +{ +set_gpu_pdev (dev_get_drvdata (master),NULL ); +} + +static const struct component_ops a3xx_ops = { + .bind = a3xx_bind, + .unbind = a3xx_unbind, +}; + +static int a3xx_probe (struct platform_device *pdev) +{ +return component_add (&pdev->dev, &a3xx_ops); +} +static int a3xx_remove (struct platform_device *pdev) { - a3xx_pdev =NULL ; +component_del (&pdev->dev, &a3xx_ops);return 0 ; }
@@ -624,7 +644,6 @@ static const struct of_device_id dt_matc { .compatible = "qcom,kgsl-3d0" }, {} }; -MODULE_DEVICE_TABLE (of, dt_match);static struct platform_driver a3xx_driver = { .probe = a3xx_probe,
drivers/gpu/drm/msm/hdmi/hdmi.c +30 -12
91 lines not on this page · raw message
drivers/gpu/drm/msm/msm_drv.c +108 -4
158 lines not on this page · raw message
drivers/gpu/drm/msm/msm_drv.h +4 -0
@@ -22,6 +22,7 @@#include <linux/clk.h> #include <linux/cpufreq.h> #include <linux/module.h> +#include <linux/component.h> #include <linux/platform_device.h> #include <linux/pm.h> #include <linux/pm_runtime.h>
@@ -69,6 +70,9 @@ struct msm_drm_private {struct msm_kms *kms; +/* subordinate devices, if present: */ +struct platform_device *hdmi_pdev, *gpu_pdev; +/* when we have more than one 'msm_gpu' these need to be an array: */ struct msm_gpu *gpu;struct msm_file_private *lastctx;
Greg Kroah-Hartman
maintainerPATCH 48/92 ext4: make fsync to sync parent dir in no-journal for real this time
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Czerner <[email protected]>
commit e12fb97222fc41e8442896934f76d39ef99b590a upstream.
Previously commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c added a support for for syncing parent directory of newly created inodes to make sure that the inode is not lost after a power failure in no-journal mode.
However this does not work in majority of cases, namely:
- if the directory has inline data
- if the directory is already indexed
- if the directory already has at least one block and:
- the new entry fits into it
- or we've successfully converted it to indexed
So in those cases we might lose the inode entirely even after fsync in the no-journal mode. This also includes ext2 default mode obviously.
I've noticed this while running xfstest generic/321 and even though the test should fail (we need to run fsck after a crash in no-journal mode) I could not find a newly created entries even when if it was fsynced before.
Fix this by adjusting the ext4_add_entry() successful exit paths to set the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the parent directory as well.
--- fs/ext4/namei.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)
fs/ext4/namei.c +11 -9
@@ -1869,7 +1869,7 @@ static int ext4_add_entry(handle_t *hand struct inode *inode) {struct inode *dir = dentry->d_parent->d_inode; -struct buffer_head *bh; +struct buffer_head *bh =NULL ;struct ext4_dir_entry_2 *de;struct ext4_dir_entry_tail *t;struct super_block *sb;
@@ -1893,14 +1893,14 @@ static int ext4_add_entry(handle_t *handreturn retval;if (retval ==1 ) { retval =0 ; -return retval; + goto out; } }if (is_dx (dir)) { retval =ext4_dx_add_entry (handle, dentry, inode);if (!retval || (retval !=ERR_BAD_DX_DIR )) -return retval; + goto out;ext4_clear_inode_flag (dir,EXT4_INODE_INDEX ); dx_fallback++;ext4_mark_inode_dirty (handle, dir);
@@ -1912,14 +1912,15 @@ static int ext4_add_entry(handle_t *handreturn PTR_ERR (bh); retval =add_dirent_to_buf (handle, dentry, inode,NULL , bh); -if (retval != -ENOSPC ) { -brelse (bh); -return retval; - } +if (retval != -ENOSPC ) + goto out;if (blocks ==1 && !dx_fallback && -EXT4_HAS_COMPAT_FEATURE (sb,EXT4_FEATURE_COMPAT_DIR_INDEX )) -return make_indexed_dir (handle, dentry, inode, bh); +EXT4_HAS_COMPAT_FEATURE (sb,EXT4_FEATURE_COMPAT_DIR_INDEX )) { + retval =make_indexed_dir (handle, dentry, inode, bh); + bh =NULL ;/* make_indexed_dir releases bh */ + goto out; + }brelse (bh); } bh =ext4_append (handle, dir, &block);
@@ -1935,6 +1936,7 @@ static int ext4_add_entry(handle_t *hand } retval =add_dirent_to_buf (handle, dentry, inode, de, bh); +out:brelse (bh);if (retval ==0 )ext4_set_inode_state (inode,EXT4_STATE_NEWENTRY );
Greg Kroah-Hartman
maintainerPATCH 49/92 powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream.
We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH (currently 127), but we forgot to do the same for 64bit backtraces.
--- arch/powerpc/perf/callchain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/perf/callchain.c +1 -1
@@ -243,7 +243,7 @@ static void perf_callchain_user_64(struc sp = regs->gpr[1 ];perf_callchain_store (entry, next_ip); -for (;;) { +while (entry->nr <PERF_MAX_STACK_DEPTH ) { fp = (unsigned long __user *) sp;if (!valid_user_sp (sp,1 ) ||read_user_stack_64 (fp, &next_sp))return ;
Greg Kroah-Hartman
maintainerPATCH 50/92 tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <[email protected]>
commit c5e691928bf166ac03430e957038b60adba3cf6c upstream.
When a event PADDING is hit (a deleted event that is still in the ring buffer), translate_data() sets the length of the padding and also updates the data pointer which is passed back to the caller.
This is unneeded because the caller also updates the data pointer with the passed back length. translate_data() should not update the pointer, only set the length.
--- tools/lib/traceevent/kbuffer-parse.c | 1 - 1 file changed, 1 deletion(-)
tools/lib/traceevent/kbuffer-parse.c +0 -1
@@ -372,7 +372,6 @@ translate_data(struct kbuffer *kbuf, voiswitch (type_len) {case KBUFFER_TYPE_PADDING : *length =read_4 (kbuf, data); - data += *length;break ;case KBUFFER_TYPE_TIME_EXTEND :
Greg Kroah-Hartman
maintainerPATCH 51/92 tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas D <[email protected]>
commit f82263c6989c31ae9b94cecddffb29dcbec38710 upstream.
Since commit ee0778a30153
("tools/power: turbostat: make Makefile a bit more capable") turbostat's Makefile is using
[...] BUILD_OUTPUT := $(PWD) [...]
which obviously causes trouble when building "turbostat" with
make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat
because GNU make does not update nor guarantee that $PWD is set.
This patch changes the Makefile to use $CURDIR instead, which GNU make guarantees to set and update (i.e. when using "make -C ...") and also adds support for the O= option (see "make help" in your root of your kernel source tree for more details).
--- tools/power/x86/turbostat/Makefile | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
tools/power/x86/turbostat/Makefile +5 -1
@@ -1,8 +1,12 @@ CC = $(CROSS_COMPILE)gcc -BUILD_OUTPUT := $(PWD) +BUILD_OUTPUT := $(CURDIR) PREFIX := /usr DESTDIR := +ifeq ("$(origin O)", "command line") + BUILD_OUTPUT := $(O) +endif + turbostat : turbostat.c CFLAGS += -Wall CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
Greg Kroah-Hartman
maintainerPATCH 52/92 UBI: account for bitflips in both the VID header and data
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream.
We are completely discarding the earlier value of 'bitflips', which could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the bitwise OR of header and data 'bitflip' statuses instead.
Coverity CID #1226856
--- drivers/mtd/ubi/attach.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/ubi/attach.c +1 -1
@@ -408,7 +408,7 @@ int ubi_compare_lebs(struct ubi_device * second_is_newer = !second_is_newer; }else {dbg_bld ("PEB %d CRC is OK" , pnum); - bitflips = !!err; + bitflips |= !!err; }mutex_unlock (&ubi->buf_mutex);
Greg Kroah-Hartman
maintainerPATCH 26/92 ARM: at91/dt: sama5d3 xplained: add phy address for macb1
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Ferre <[email protected]>
commit 98b80987c940956da48f0c703f60340128bb8521 upstream.
After 57a38effa598 (net: phy: micrel: disable broadcast for KSZ8081/KSZ8091) the macb1 interface refuses to work properly because it tries
to cling to address 0 which isn't able to communicate in broadcast with the mac anymore. The micrel phy on the board is actually configured to show up at address 1.
Adding the phy node and its real address fixes the issue.
--- arch/arm/boot/dts/at91-sama5d3_xplained.dts | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/boot/dts/at91-sama5d3_xplained.dts +6 -0
@@ -107,7 +107,13 @@ macb1: ethernet@f802c000 { phy-mode = "rmii"; + #address-cells = <1>; + #size-cells = <0>; status = "okay"; + + ethernet-phy@1 { + reg = <0x1>; + }; }; dbgu: serial@ffffee00 {
Greg Kroah-Hartman
maintainerPATCH 53/92 UBI: fix out of bounds write
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream.
If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping.
Caught by Coverity, CID #711212.
--- drivers/mtd/ubi/eba.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mtd/ubi/eba.c +2 -1
@@ -1362,7 +1362,8 @@ int ubi_eba_init(struct ubi_device *ubi,* during re-size. */ ubi_move_aeb_to_list (av, aeb, &ai->erase); - vol->eba_tbl[aeb->lnum] = aeb->pnum; + else + vol->eba_tbl[aeb->lnum] = aeb->pnum; } }
Greg Kroah-Hartman
maintainerPATCH 55/92 UBI: fix check for "too many bytes"
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream.
The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum.
Coverity CID #139400
--- drivers/mtd/ubi/cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/ubi/cdev.c +1 -1
@@ -451,7 +451,7 @@ static long vol_cdev_ioctl(struct file */* Validate the request */ err = -EINVAL ;if (req.lnum <0 || req.lnum >= vol->reserved_pebs || - req.bytes <0 || req.lnum >= vol->usable_leb_size) + req.bytes <0 || req.bytes > vol->usable_leb_size)break ; err =get_exclusive (desc);
Greg Kroah-Hartman
maintainerPATCH 56/92 scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "K. Y. Srinivasan" <[email protected]>
commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream.
We may exit this function without properly freeing up the maapings we may have acquired. Fix the bug.
--- drivers/scsi/storvsc_drv.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
drivers/scsi/storvsc_drv.c +8 -7
@@ -739,21 +739,22 @@ static unsigned int copy_to_bounce_buffeif (bounce_sgl[j].length ==PAGE_SIZE ) {/* full..move to next entry */ sg_kunmap_atomic (bounce_addr); + bounce_addr =0 ; j++; + } -/* if we need to use another bounce buffer */ -if (srclen || i != orig_sgl_count -1 ) - bounce_addr =sg_kmap_atomic (bounce_sgl,j); +/* if we need to use another bounce buffer */ +if (srclen && bounce_addr ==0 ) + bounce_addr =sg_kmap_atomic (bounce_sgl, j); - }else if (srclen ==0 && i == orig_sgl_count -1 ) { -/* unmap the last bounce that is < PAGE_SIZE */ -sg_kunmap_atomic (bounce_addr); - } }sg_kunmap_atomic (src_addr - orig_sgl[i].offset); } +if (bounce_addr) +sg_kunmap_atomic (bounce_addr); +local_irq_restore (flags);return total_copied;
Greg Kroah-Hartman
maintainerPATCH 57/92 target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit c8e639852ad720499912acedfd6b072325fd2807 upstream.
This patch fixes a bug for COMPARE_AND_WRITE handling with fabrics using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC.
It adds the missing allocation for cmd->t_bidi_data_sg within transport_generic_new_cmd() that is used by COMPARE_AND_WRITE for the initial READ payload, even if the fabric is already providing a pre-allocated buffer for cmd->t_data_sg.
Also, fix zero-length COMPARE_AND_WRITE handling within the compare_and_write_callback() and target_complete_ok_work() to queue the response, skipping the initial READ.
This fixes COMPARE_AND_WRITE emulation with loopback, vhost, and xen-backend fabric drivers using SG_TO_MEM_NOALLOC.
--- drivers/target/target_core_sbc.c | 15 ++++++++----- drivers/target/target_core_transport.c | 37 +++++++++++++++++++++++++++++---- include/target/target_core_base.h | 2 - 3 files changed, 44 insertions(+), 10 deletions(-)
drivers/target/target_core_sbc.c +10 -5
@@ -314,7 +314,7 @@ sbc_setup_write_same(struct se_cmd *cmd,return 0 ; } -static sense_reason_t xdreadwrite_callback (struct se_cmd *cmd) +static sense_reason_t xdreadwrite_callback (struct se_cmd *cmd,bool success) {unsigned char *buf, *addr;struct scatterlist *sg;
@@ -378,7 +378,7 @@ sbc_execute_rw(struct se_cmd *cmd) cmd->data_direction); } -static sense_reason_t compare_and_write_post (struct se_cmd *cmd) +static sense_reason_t compare_and_write_post (struct se_cmd *cmd,bool success) {struct se_device *dev = cmd->se_dev;
@@ -401,7 +401,7 @@ static sense_reason_t compare_and_write_return TCM_NO_SENSE ; } -static sense_reason_t compare_and_write_callback (struct se_cmd *cmd) +static sense_reason_t compare_and_write_callback (struct se_cmd *cmd,bool success) {struct se_device *dev = cmd->se_dev;struct scatterlist *write_sg =NULL , *sg;
@@ -416,11 +416,16 @@ static sense_reason_t compare_and_write_/* * Handle early failure in transport_generic_request_failure(), -* which will not have taken ->caw_mutex yet.. +* which will not have taken ->caw_sem yet.. */ -if (!cmd->t_data_sg || !cmd->t_bidi_data_sg) +if (!success && (!cmd->t_data_sg || !cmd->t_bidi_data_sg))return TCM_NO_SENSE ;/* +* Handle special case for zero-length COMPARE_AND_WRITE +*/ +if (!cmd->data_length) + goto out; +/* * Immediately exit + release dev->caw_sem if command has already * been failed with a non-zero SCSI status. */
drivers/target/target_core_transport.c +33 -4
@@ -1600,11 +1600,11 @@ void transport_generic_request_failure(stransport_complete_task_attr (cmd);/* * Handle special case for COMPARE_AND_WRITE failure, where the -* callback is expected to drop the per device ->caw_mutex. +* callback is expected to drop the per device ->caw_sem. */ if ((cmd->se_cmd_flags &SCF_COMPARE_AND_WRITE ) && cmd->transport_complete_callback) - cmd->transport_complete_callback (cmd); + cmd->transport_complete_callback (cmd, false);switch (sense_reason) {case TCM_NON_EXISTENT_LUN :
@@ -1941,8 +1941,12 @@ static void target_complete_ok_work(struif (cmd->transport_complete_callback) {sense_reason_t rc; - rc = cmd->transport_complete_callback (cmd); + rc = cmd->transport_complete_callback (cmd, true);if (!rc && !(cmd->se_cmd_flags &SCF_COMPARE_AND_WRITE_POST )) { +if ((cmd->se_cmd_flags &SCF_COMPARE_AND_WRITE ) && + !cmd->data_length) + goto queue_rsp; +return ; }else if (rc) { ret = transport_send_check_condition_and_sense(cmd,
@@ -1956,6 +1960,7 @@ static void target_complete_ok_work(stru } } +queue_rsp:switch (cmd->data_direction) {case DMA_FROM_DEVICE :spin_lock (&cmd->se_lun->lun_sep_lock);
@@ -2044,6 +2049,16 @@ static inline void transport_reset_sgl_ostatic inline void transport_free_pages (struct se_cmd *cmd) {if (cmd->se_cmd_flags &SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC ) { +/* +* Release special case READ buffer payload required for +* SG_TO_MEM_NOALLOC to function with COMPARE_AND_WRITE +*/ +if (cmd->se_cmd_flags &SCF_COMPARE_AND_WRITE ) { +transport_free_sgl (cmd->t_bidi_data_sg, + cmd->t_bidi_data_nents); + cmd->t_bidi_data_sg =NULL ; + cmd->t_bidi_data_nents =0 ; + }transport_reset_sgl_orig (cmd);return ; }
@@ -2192,6 +2207,7 @@ sense_reason_t transport_generic_new_cmd(struct se_cmd *cmd) {int ret =0 ; +bool zero_flag = !(cmd->se_cmd_flags &SCF_SCSI_DATA_CDB );/* * Determine is the TCM fabric module has already allocated physical
@@ -2200,7 +2216,6 @@ transport_generic_new_cmd(struct se_cmd*/ if (!(cmd->se_cmd_flags &SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC ) && cmd->data_length) { -bool zero_flag = !(cmd->se_cmd_flags &SCF_SCSI_DATA_CDB );if ((cmd->se_cmd_flags &SCF_BIDI ) || (cmd->se_cmd_flags &SCF_COMPARE_AND_WRITE )) {
@@ -2223,6 +2238,20 @@ transport_generic_new_cmd(struct se_cmd cmd->data_length, zero_flag);if (ret <0 )return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE ; + }else if ((cmd->se_cmd_flags &SCF_COMPARE_AND_WRITE ) && + cmd->data_length) { +/* +* Special case for COMPARE_AND_WRITE with fabrics +* using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC. +*/ +u32 caw_length = cmd->t_task_nolb * + cmd->se_dev->dev_attrib.block_size; + + ret =target_alloc_sgl (&cmd->t_bidi_data_sg, + &cmd->t_bidi_data_nents, + caw_length, zero_flag); +if (ret <0 ) +return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE ; }/* * If this command is not a write we can execute it right here,
include/target/target_core_base.h +1 -1
@@ -513,7 +513,7 @@ struct se_cmd {sense_reason_t (*execute_cmd)(struct se_cmd *);sense_reason_t (*execute_rw)(struct se_cmd *,struct scatterlist *,u32 ,enum dma_data_direction ); -sense_reason_t (*transport_complete_callback)(struct se_cmd *); +sense_reason_t (*transport_complete_callback)(struct se_cmd *,bool );unsigned char *t_task_cdb;unsigned char __t_task_cdb[TCM_MAX_COMMAND_SIZE ];
Greg Kroah-Hartman
maintainerPATCH 60/92 Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Ploumistos <[email protected]>
commit 2eeff0b4317a02f0e281df891d990194f0737aae upstream.
Add 04f2:aff1 to ath3k.c supported devices list and btusb.c blacklist, so that the device can load the ath3k firmware and re-enumerate itself as an AR3011 device.
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04f2 ProdID=aff1 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/ath3k.c | 1 + drivers/bluetooth/btusb.c | 1 + 2 files changed, 2 insertions(+)
drivers/bluetooth/ath3k.c +1 -0
@@ -64,6 +64,7 @@ static const struct usb_device_id ath3k_/* Atheros AR3011 with sflash firmware*/ { USB_DEVICE(0x0489, 0xE027) }, { USB_DEVICE(0x0489, 0xE03D) }, + { USB_DEVICE(0x04F2, 0xAFF1) }, { USB_DEVICE(0x0930, 0x0215) }, { USB_DEVICE(0x0CF3, 0x3002) }, { USB_DEVICE(0x0CF3, 0xE019) },
drivers/bluetooth/btusb.c +1 -0
@@ -142,6 +142,7 @@ static const struct usb_device_id blackl/* Atheros 3011 with sflash firmware */ { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE }, { USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE }, + { USB_DEVICE(0x04f2, 0xaff1), .driver_info = BTUSB_IGNORE }, { USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE }, { USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE }, { USB_DEVICE(0x0cf3, 0xe019), .driver_info = BTUSB_IGNORE },
Greg Kroah-Hartman
maintainerPATCH 61/92 powerpc: Fix missing L2 cache size in /sys/devices/system/cpu
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Olson <[email protected]>
commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream.
This problem appears to have been introduced in 2.6.29 by commit 93197a36a9c1 "Rewrite sysfs processor cache info code".
This caused lscpu to error out on at least e500v2 devices, eg:
error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory
Some embedded powerpc systems use cache-size in DTS for the unified L2 cache size, not d-cache-size, so we need to allow for both DTS names. Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle this.
--- arch/powerpc/kernel/cacheinfo.c | 44 ++++++++++++++++++++++++++++++---------- 1 file changed, 34 insertions(+), 10 deletions(-)
arch/powerpc/kernel/cacheinfo.c +34 -10
@@ -61,12 +61,22 @@ struct cache_type_info { };/* These are used to index the cache_type_info array. */ -#define CACHE_TYPE_UNIFIED 0 -#define CACHE_TYPE_INSTRUCTION 1 -#define CACHE_TYPE_DATA 2 +#define CACHE_TYPE_UNIFIED 0/* cache-size, cache-block-size, etc. */ +#define CACHE_TYPE_UNIFIED_D 1/* d-cache-size, d-cache-block-size, etc */ +#define CACHE_TYPE_INSTRUCTION 2 +#define CACHE_TYPE_DATA 3static const struct cache_type_info cache_type_info[] = { { +/* Embedded systems that use cache-size, cache-block-size, +* etc. for the Unified (typically L2) cache. */ + .name ="Unified" , + .size_prop ="cache-size" , + .line_size_props = {"cache-line-size" , +"cache-block-size" , }, + .nr_sets_prop ="cache-sets" , + }, + {/* PowerPC Processor binding says the [di]-cache-* * must be equal on unified caches, so just use * d-cache properties. */
@@ -293,7 +303,8 @@ static struct cache *cache_find_first_si {struct cache *iter; -if (cache->type ==CACHE_TYPE_UNIFIED ) +if (cache->type ==CACHE_TYPE_UNIFIED || + cache->type ==CACHE_TYPE_UNIFIED_D )return cache;list_for_each_entry (iter, &cache_list, list)
@@ -324,16 +335,29 @@ static bool cache_node_is_unified(constreturn of_get_property (np,"cache-unified" ,NULL ); } -static struct cache *cache_do_one_devnode_unified (struct device_node *node, -int level) +/* +* Unified caches can have two different sets of tags. Most embedded +* use cache-size, etc. for the unified cache size, but open firmware systems +* use d-cache-size, etc. Check on initialization for which type we have, and +* return the appropriate structure type. Assume it's embedded if it isn't +* open firmware. If it's yet a 3rd type, then there will be missing entries +* in /sys/devices/system/cpu/cpu0/cache/index2/, and this code will need +* to be extended further. +*/ +static int cache_is_unified_d (const struct device_node *np) { -struct cache *cache; +return of_get_property (np, + cache_type_info[CACHE_TYPE_UNIFIED_D ].size_prop,NULL ) ? +CACHE_TYPE_UNIFIED_D :CACHE_TYPE_UNIFIED ; +} +/* +*/ +static struct cache *cache_do_one_devnode_unified (struct device_node *node,int level) +{pr_debug ("creating L%d ucache for %s\n" , level, node->full_name); - cache =new_cache (CACHE_TYPE_UNIFIED , level, node); - -return cache; +return new_cache (cache_is_unified_d (node), level, node); } static struct cache *cache_do_one_devnode_split(struct device_node *node,
Greg Kroah-Hartman
maintainerPATCH 28/92 usb: phy: Find the right match in devm_usb_phy_match
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
commit 869aee0f31429fa9d94d5aef539602b73ae0cf4b upstream.
The res parameter passed to devm_usb_phy_match() is the location where the pointer to the usb_phy is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match.
--- drivers/usb/phy/phy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/phy/phy.c +3 -1
@@ -78,7 +78,9 @@ static void devm_usb_phy_release(structstatic int devm_usb_phy_match (struct device *dev,void *res,void *match_data) { -return res == match_data; +struct usb_phy **phy = res; + +return *phy == match_data; }/**
Greg Kroah-Hartman
maintainerPATCH 29/92 usb: define a generic USB_RESUME_TIMEOUT macro
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 62f0342de1f012f3e90607d39e20fce811391169 upstream.
Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus.
Currently, almost every single USB controller is using a 20ms timeout for resume signalling.
That's problematic for two reasons:
a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification
b) some (many) devices actually need more than 20ms resume signalling.
Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using.
At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure.
--- include/linux/usb.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
include/linux/usb.h +26 -0
@@ -206,6 +206,32 @@ void usb_put_intf(struct usb_interface *#define USB_MAXINTERFACES 32#define USB_MAXIADS (USB_MAXINTERFACES/2) +/* +* USB Resume Timer: Every Host controller driver should drive the resume +* signalling on the bus for the amount of time defined by this macro. +* +* That way we will have a 'stable' behavior among all HCDs supported by Linux. +* +* Note that the USB Specification states we should drive resume for *at least* +* 20 ms, but it doesn't give an upper bound. This creates two possible +* situations which we want to avoid: +* +* (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes +* us to fail USB Electrical Tests, thus failing Certification +* +* (b) Some (many) devices actually need more than 20 ms of resume signalling, +* and while we can argue that's against the USB Specification, we don't have +* control over which devices a certification laboratory will be using for +* certification. If CertLab uses a device which was tested against Windows and +* that happens to have relaxed resume signalling rules, we might fall into +* situations where we fail interoperability and electrical tests. +* +* In order to avoid both conditions, we're using a 40 ms resume timeout, which +* should cope with both LPJ calibration errors and devices not following every +* detail of the USB Specification. +*/ +#define USB_RESUME_TIMEOUT 40/* ms */ +/** * struct usb_interface_cache - long-term representation of a device interface * @num_altsetting: number of altsettings defined.
Greg Kroah-Hartman
maintainerPATCH 30/92 usb: host: fusbh200: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 595227db1f2d98bfc33f02a55842f268e12b247d upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/host/fusbh200-hcd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/usb/host/fusbh200-hcd.c +1 -2
@@ -1550,10 +1550,9 @@ static int fusbh200_hub_control (if ((temp &PORT_PE ) ==0 ) goto error; -/* resume signaling for 20 msec */ fusbh200_writel (fusbh200, temp |PORT_RESUME , status_reg); fusbh200->reset_done[wIndex] = jiffies - +msecs_to_jiffies (20 ); + +msecs_to_jiffies (USB_RESUME_TIMEOUT );break ;case USB_PORT_FEAT_C_SUSPEND :clear_bit (wIndex, &fusbh200->port_c_suspend);
Greg Kroah-Hartman
maintainerPATCH 31/92 usb: host: uhci: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit b8fb6f79f76f478acbbffccc966daa878f172a0a upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/host/uhci-hub.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/host/uhci-hub.c +3 -2
@@ -165,7 +165,7 @@ static void uhci_check_ports(struct uhci/* Port received a wakeup request */ set_bit (port, &uhci->resuming_ports); uhci->ports_timeout = jiffies + -msecs_to_jiffies (25 ); +msecs_to_jiffies (USB_RESUME_TIMEOUT );usb_hcd_start_port_resume ( &uhci_to_hcd (uhci)->self, port);
@@ -337,7 +337,8 @@ static int uhci_hub_control(struct usb_huhci_finish_suspend (uhci, port, port_addr);/* USB v2.0 7.1.7.5 */ - uhci->ports_timeout = jiffies +msecs_to_jiffies (50 ); + uhci->ports_timeout = jiffies + +msecs_to_jiffies (USB_RESUME_TIMEOUT );break ;case USB_PORT_FEAT_POWER :/* UHCI has no power switching */
Greg Kroah-Hartman
maintainerPATCH 32/92 usb: host: fotg210: use new USB_RESUME_TIMEOUT
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 7e136bb71a08e8b8be3bc492f041d9b0bea3856d upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
--- drivers/usb/host/fotg210-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/fotg210-hcd.c +1 -1
@@ -1595,7 +1595,7 @@ static int fotg210_hub_control(/* resume signaling for 20 msec */ fotg210_writel (fotg210, temp |PORT_RESUME , status_reg); fotg210->reset_done[wIndex] = jiffies - +msecs_to_jiffies (20 ); + +msecs_to_jiffies (USB_RESUME_TIMEOUT );break ;case USB_PORT_FEAT_C_SUSPEND :clear_bit (wIndex, &fotg210->port_c_suspend);
Greg Kroah-Hartman
maintainerPATCH 23/92 NFS: fix BUG() crash in notify_change() with patch to chown_common()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Elble <[email protected]>
commit c1b8940b42bb6487b10f2267a96b486276ce9ff7 upstream.
We have observed a BUG() crash in fs/attr.c:notify_change(). The crash occurs during an rsync into a filesystem that is exported via NFS.
1.) fs/attr.c:notify_change() modifies the caller's version of attr. 2.) 6de0ec00ba8d ("VFS: make notify_change pass ATTR_KILL_S*ID to
setattr operations") introduced a BUG() restriction such that "no function will ever call notify_change() with both ATTR_MODE and ATTR_KILL_S*ID set". Under some circumstances though, it will have assisted in setting the caller's version of attr to this very combination.
3.) 27ac0ffeac80 ("locks: break delegations on any attribute
modification") introduced code to handle breaking delegations. This can result in notify_change() being re-called. attr _must_ be explicitly reset to avoid triggering the BUG() established in #2.
4.) The path that that triggers this is via fs/open.c:chmod_common().
The combination of attr flags set here and in the first call to notify_change() along with a later failed break_deleg_wait() results in notify_change() being called again via retry_deleg without resetting attr.
Solution is to move retry_deleg in chmod_common() a bit further up to ensure attr is completely reset.
There are other places where this seemingly could occur, such as fs/utimes.c:utimes_common(), but the attr flags are not initially set in such a way to trigger this.
--- fs/open.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/open.c +1 -1
@@ -539,6 +539,7 @@ static int chown_common(struct path *pat uid =make_kuid (current_user_ns (), user); gid =make_kgid (current_user_ns (), group); +retry_deleg: newattrs.ia_valid =ATTR_CTIME ;if (user != (uid_t) -1 ) {if (!uid_valid (uid))
@@ -555,7 +556,6 @@ static int chown_common(struct path *patif (!S_ISDIR (inode->i_mode)) newattrs.ia_valid |=ATTR_KILL_SUID |ATTR_KILL_SGID |ATTR_KILL_PRIV ; -retry_deleg:mutex_lock (&inode->i_mutex); error =security_path_chown (path, uid, gid);if (!error)
Greg Kroah-Hartman
maintainerPATCH 63/92 ASoC: davinci-evm: drop un-necessary remove function
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manish Badarkhe <[email protected]>
commit a57069e33fbc6625f39e1b09c88ea44629a35206 upstream.
As davinci card gets registered using 'devm_' api there is no need to unregister the card in 'remove' function.
Hence drop the 'remove' function.
--- sound/soc/davinci/davinci-evm.c | 10 ---------- 1 file changed, 10 deletions(-)
sound/soc/davinci/davinci-evm.c +0 -10
@@ -384,18 +384,8 @@ static int davinci_evm_probe(struct platreturn ret; } -static int davinci_evm_remove (struct platform_device *pdev) -{ -struct snd_soc_card *card =platform_get_drvdata (pdev); - -snd_soc_unregister_card (card); - -return 0 ; -} -static struct platform_driver davinci_evm_driver = { .probe = davinci_evm_probe, - .remove = davinci_evm_remove, .driver = { .name ="davinci_evm" , .owner =THIS_MODULE ,
Greg Kroah-Hartman
maintainerPATCH 72/92 clk: qcom: fix RCG M/N counter configuration
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Archit Taneja <[email protected]>
commit 0b21503dbbfa669dbd847b33578d4041513cddb2 upstream.
Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N.
In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1.
Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division.
generators (RCGs))
--- drivers/clk/qcom/clk-rcg2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/clk-rcg2.c +1 -1
@@ -257,7 +257,7 @@ static int __clk_rcg2_set_rate(struct cl mask |=CFG_SRC_SEL_MASK |CFG_MODE_MASK ; cfg = f->pre_div <<CFG_SRC_DIV_SHIFT ; cfg |= rcg->parent_map[f->src] <<CFG_SRC_SEL_SHIFT ; -if (rcg->mnd_width && f->n) +if (rcg->mnd_width && f->n && (f->m != f->n)) cfg |=CFG_MODE_DUAL_EDGE ; ret =regmap_update_bits (rcg->clkr.regmap, rcg->cmd_rcgr +CFG_REG , mask, cfg);
Greg Kroah-Hartman
maintainerPATCH 73/92 dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Collins <[email protected]>
commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream.
I suspect this doesn't show up for most anyone because software algorithms typically don't have a sense of being too busy. However, when working with the Freescale CAAM driver it will return -EBUSY on occasion under heavy -- which resulted in dm-crypt deadlock.
After checking the logic in some other drivers, the scheme for crypt_convert() and it's callback, kcryptd_async_done(), were not correctly laid out to properly handle -EBUSY or -EINPROGRESS.
Fix this by using the completion for both -EBUSY and -EINPROGRESS. Now crypt_convert()'s use of completion is comparable to af_alg_wait_for_completion(). Similarly, kcryptd_async_done() follows the pattern used in af_alg_complete().
Before this fix dm-crypt would lockup within 1-2 minutes running with the CAAM driver. Fix was regression tested against software algorithms on PPC32 and x86_64, and things seem perfectly happy there as well.
--- drivers/md/dm-crypt.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/md/dm-crypt.c +6 -6
@@ -915,11 +915,10 @@ static int crypt_convert(struct crypt_coswitch (r) {/* async */ +case -EINPROGRESS :case -EBUSY :wait_for_completion (&ctx->restart);reinit_completion (&ctx->restart); -/* fall through*/ -case -EINPROGRESS : ctx->req =NULL ; ctx->cc_sector++;continue ;
@@ -1314,10 +1313,8 @@ static void kcryptd_async_done(struct cr struct dm_crypt_io *io = container_of(ctx, struct dm_crypt_io, ctx);struct crypt_config *cc = io->cc; -if (error == -EINPROGRESS ) { -complete (&ctx->restart); +if (error == -EINPROGRESS )return ; - }if (!error && cc->iv_gen_ops && cc->iv_gen_ops->post) error = cc->iv_gen_ops->post (cc,iv_of_dmreq (cc, dmreq), dmreq);
@@ -1328,12 +1325,15 @@ static void kcryptd_async_done(struct crmempool_free (req_of_dmreq (cc, dmreq), cc->req_pool);if (!atomic_dec_and_test (&ctx->cc_pending)) -return ; + goto done;if (bio_data_dir (io->base_bio) ==READ )kcryptd_crypt_read_done (io);else kcryptd_crypt_write_io_submit (io,1 ); +done: +if (!completion_done (&ctx->restart)) +complete (&ctx->restart); }static void kcryptd_crypt (struct work_struct *work)
Greg Kroah-Hartman
maintainerPATCH 74/92 Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "K. Y. Srinivasan" <[email protected]>
commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream.
Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host.
--- drivers/hv/channel.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/hv/channel.c +5 -2
@@ -134,7 +134,7 @@ int vmbus_open(struct vmbus_channel *new GFP_KERNEL);if (!open_info) { err = -ENOMEM ; - goto error0; + goto error_gpadl; }init_completion (&open_info->waitevent);
@@ -150,7 +150,7 @@ int vmbus_open(struct vmbus_channel *newif (userdatalen >MAX_USER_DEFINED_BYTES ) { err = -EINVAL ; - goto error0; + goto error_gpadl; }if (userdatalen)
@@ -194,6 +194,9 @@ error1:list_del (&open_info->msglistentry);spin_unlock_irqrestore (&vmbus_connection.channelmsg_lock, flags); +error_gpadl: +vmbus_teardown_gpadl (newchannel, newchannel->ringbuffer_gpadlhandle); + error0:free_pages ((unsigned long )out,get_order (send_ringbuffer_size + recv_ringbuffer_size));
Greg Kroah-Hartman
maintainerPATCH 75/92 mvsas: fix panic on expander attached SATA devices
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Bottomley <[email protected]>
commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream.
mvsas is giving a General protection fault when it encounters an expander attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is assuming all ATA devices are locally attached and obtaining the phy mask by indexing the local phy table (in the HBA structure) with the phy id. Since expanders have many more phys than the HBA, this is causing the index into the HBA phy table to overflow and returning rubbish as the pointer.
mvs_task_prep_ssp() instead does the phy mask using the port properties. Mirror this in mvs_task_prep_ata() to fix the panic.
--- drivers/scsi/mvsas/mv_sas.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/scsi/mvsas/mv_sas.c +1 -4
@@ -441,14 +441,11 @@ static u32 mvs_get_ncq_tag(struct sas_tastatic int mvs_task_prep_ata (struct mvs_info *mvi,struct mvs_task_exec_info *tei) { -struct sas_ha_struct *sha = mvi->sas;struct sas_task *task = tei->task;struct domain_device *dev = task->dev;struct mvs_device *mvi_dev = dev->lldd_dev;struct mvs_cmd_hdr *hdr = tei->hdr;struct asd_sas_port *sas_port = dev->port; -struct sas_phy *sphy = dev->phy; -struct asd_sas_phy *sas_phy = sha->sas_phy[sphy->number];struct mvs_slot_info *slot;void *buf_prd;u32 tag = tei->tag, hdr_tag;
@@ -468,7 +465,7 @@ static int mvs_task_prep_ata(struct mvs_ slot->tx = mvi->tx_prod; del_q =TXQ_MODE_I | tag | (TXQ_CMD_STP <<TXQ_CMD_SHIFT ) | - (MVS_PHY_ID <<TXQ_PHY_SHIFT ) | + ((sas_port->phy_mask &TXQ_PHY_MASK ) <<TXQ_PHY_SHIFT ) | (mvi_dev->taskfileset <<TXQ_SRS_SHIFT ); mvi->tx[mvi->tx_prod] =cpu_to_le32 (del_q);
Greg Kroah-Hartman
maintainerPATCH 76/92 stk1160: Make sure current buffer is released
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ezequiel Garcia <[email protected]>
commit aeff09276748b66072f2db2e668cec955cf41959 upstream.
The available (i.e. not used) buffers are returned by stk1160_clear_queue(), on the stop_streaming() path. However, this is insufficient and the current buffer must be released as well. Fix it.
--- drivers/media/usb/stk1160/stk1160-v4l.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
drivers/media/usb/stk1160/stk1160-v4l.c +15 -2
@@ -244,6 +244,11 @@ static int stk1160_stop_streaming(structif (mutex_lock_interruptible (&dev->v4l_lock))return -ERESTARTSYS ; +/* +* Once URBs are cancelled, the URB complete handler +* won't be running. This is required to safely release the +* current buffer (dev->isoc_ctl.buf). +*/ stk1160_cancel_isoc (dev);/*
@@ -624,8 +629,16 @@ void stk1160_clear_queue(struct stk1160stk1160_info ("buffer [%p/%d] aborted\n" , buf, buf->vb.v4l2_buf.index); } -/* It's important to clear current buffer */ - dev->isoc_ctl.buf =NULL ; + +/* It's important to release the current buffer */ +if (dev->isoc_ctl.buf) { + buf = dev->isoc_ctl.buf; + dev->isoc_ctl.buf =NULL ; + +vb2_buffer_done (&buf->vb,VB2_BUF_STATE_ERROR ); +stk1160_info ("buffer [%p/%d] aborted\n" , + buf, buf->vb.v4l2_buf.index); + }spin_unlock_irqrestore (&dev->buf_lock, flags); }
Greg Kroah-Hartman
maintainerPATCH 77/92 IB/core: disallow registering 0-sized memory region
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yann Droneaud <[email protected]>
commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream.
If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller.
This should not be allowed: it's not expected for a memory region to have a size equal to 0.
This patch adds a check to explicitly refuse to register a 0-sized region.
--- drivers/infiniband/core/umem.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/infiniband/core/umem.c +3 -0
@@ -94,6 +94,9 @@ struct ib_umem *ib_umem_get(struct ib_ucif (dmasync)dma_set_attr (DMA_ATTR_WRITE_BARRIER , &attrs); +if (!size) +return ERR_PTR (-EINVAL ); +/* * If the combination of the addr and size requested for this memory * region causes an integer overflow, return error.
Greg Kroah-Hartman
maintainerPATCH 79/92 IB/mlx4: Fix WQE LSO segment calculation
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erez Shitrit <[email protected]>
commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream.
The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers.
It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers.
The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages.
An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2*hlen (2*56) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state.
--- drivers/infiniband/hw/mlx4/qp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/infiniband/hw/mlx4/qp.c +1 -2
@@ -2274,8 +2274,7 @@ static int build_lso_seg(struct mlx4_wqememcpy (wqe->header, wr->wr.ud.header, wr->wr.ud.hlen); - *lso_hdr_sz =cpu_to_be32 ((wr->wr.ud.mss - wr->wr.ud.hlen) <<16 | - wr->wr.ud.hlen); + *lso_hdr_sz =cpu_to_be32 (wr->wr.ud.mss <<16 | wr->wr.ud.hlen); *lso_seg_len = halign;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 80/92 i2c: core: Export bus recovery functions
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit c1c21f4e60ed4523292f1a89ff45a208bddd3849 upstream.
Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported:
ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined!
Add exports to fix this.
--- drivers/i2c/i2c-core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/i2c/i2c-core.c +3 -0
@@ -217,6 +217,7 @@ int i2c_generic_scl_recovery(struct i2c_ adap->bus_recovery_info->set_scl (adap,1 );return i2c_generic_recovery (adap); } +EXPORT_SYMBOL_GPL (i2c_generic_scl_recovery);int i2c_generic_gpio_recovery (struct i2c_adapter *adap) {
@@ -231,6 +232,7 @@ int i2c_generic_gpio_recovery(struct i2creturn ret; } +EXPORT_SYMBOL_GPL (i2c_generic_gpio_recovery);int i2c_recover_bus (struct i2c_adapter *adap) {
@@ -240,6 +242,7 @@ int i2c_recover_bus(struct i2c_adapter *dev_dbg (&adap->dev,"Trying i2c bus recovery\n" );return adap->bus_recovery_info->recover_bus (adap); } +EXPORT_SYMBOL_GPL (i2c_recover_bus);static int i2c_device_probe (struct device *dev) {
Greg Kroah-Hartman
maintainerPATCH 81/92 drm/radeon: fix doublescan modes (v2)
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream.
Use the correct flags for atom.
v2: handle DRM_MODE_FLAG_DBLCLK
--- drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/atombios_crtc.c +6 -2
@@ -330,8 +330,10 @@ atombios_set_crtc_dtd_timing(struct drm_ misc |=ATOM_COMPOSITESYNC ;if (mode->flags &DRM_MODE_FLAG_INTERLACE ) misc |=ATOM_INTERLACE ; -if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) +if (mode->flags &DRM_MODE_FLAG_DBLCLK ) misc |=ATOM_DOUBLE_CLOCK_MODE ; +if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) + misc |=ATOM_H_REPLICATIONBY2 |ATOM_V_REPLICATIONBY2 ; args.susModeMiscInfo.usAccess =cpu_to_le16 (misc); args.ucCRTC = radeon_crtc->crtc_id;
@@ -374,8 +376,10 @@ static void atombios_crtc_set_timing(str misc |=ATOM_COMPOSITESYNC ;if (mode->flags &DRM_MODE_FLAG_INTERLACE ) misc |=ATOM_INTERLACE ; -if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) +if (mode->flags &DRM_MODE_FLAG_DBLCLK ) misc |=ATOM_DOUBLE_CLOCK_MODE ; +if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) + misc |=ATOM_H_REPLICATIONBY2 |ATOM_V_REPLICATIONBY2 ; args.susModeMiscInfo.usAccess =cpu_to_le16 (misc); args.ucCRTC = radeon_crtc->crtc_id;
Greg Kroah-Hartman
maintainerPATCH 64/92 ACPICA: Utilities: split IO address types from data type models.
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lv Zheng <[email protected]>
commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream.
ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451
It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below).
This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects.
Internal acpi_physical_address usages in the structures that can be fixed by this change include:
1. struct acpi_object_region:
acpi_physical_address address;
2. struct acpi_address_range:
acpi_physical_address start_address;
acpi_physical_address end_address;
3. struct acpi_mem_space_context;
acpi_physical_address address;
4. struct acpi_table_desc
acpi_physical_address address;See known issues 1 for other usages.
Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly.
For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h.
Known issues:
1. Cleanup of mapped virtual address
In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address:
acpi_physical_address mapped_physical_address;
It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501
--- include/acpi/actypes.h | 20 ++++++++++++++++++++ include/acpi/platform/acenv.h | 1 + 2 files changed, 21 insertions(+)
include/acpi/actypes.h +20 -0
@@ -198,9 +198,29 @@ typedef int INT32;typedef s32 acpi_native_int ;typedef u32 acpi_size ; + +#ifdef ACPI_32BIT_PHYSICAL_ADDRESS + +/* +* OSPMs can define this to shrink the size of the structures for 32-bit +* none PAE environment. ASL compiler may always define this to generate +* 32-bit OSPM compliant tables. +*/ typedef u32 acpi_io_address ;typedef u32 acpi_physical_address ; +#else /* ACPI_32BIT_PHYSICAL_ADDRESS */ + +/* +* It is reported that, after some calculations, the physical addresses can +* wrap over the 32-bit boundary on 32-bit PAE environment. +* https://bugzilla.kernel.org/show_bug.cgi?id=87971 +*/ +typedef u64 acpi_io_address ; +typedef u64 acpi_physical_address ; + +#endif /* ACPI_32BIT_PHYSICAL_ADDRESS */ +#define ACPI_MAX_PTR ACPI_UINT32_MAX#define ACPI_SIZE_MAX ACPI_UINT32_MAX
include/acpi/platform/acenv.h +1 -0
@@ -76,6 +76,7 @@#define ACPI_LARGE_NAMESPACE_NODE #define ACPI_DATA_TABLE_DISASSEMBLY #define ACPI_SINGLE_THREADED +#define ACPI_32BIT_PHYSICAL_ADDRESS #endif /* acpi_exec configuration. Multithreaded with full AML debugger */
Greg Kroah-Hartman
maintainerPATCH 82/92 drm/i915: cope with large i2c transfers
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Torokhov <[email protected]>
commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream.
The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues.
Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction).
--- drivers/gpu/drm/i915/i915_reg.h | 1 drivers/gpu/drm/i915/intel_i2c.c | 66 +++++++++++++++++++++++++++++++++------ 2 files changed, 57 insertions(+), 10 deletions(-)
drivers/gpu/drm/i915/i915_reg.h +1 -0
@@ -1181,6 +1181,7 @@#define GMBUS_CYCLE_INDEX (2<<25)#define GMBUS_CYCLE_STOP (4<<25)#define GMBUS_BYTE_COUNT_SHIFT 16 +#define GMBUS_BYTE_COUNT_MAX 256U#define GMBUS_SLAVE_INDEX_SHIFT 8#define GMBUS_SLAVE_ADDR_SHIFT 1#define GMBUS_SLAVE_READ (1<<0)
drivers/gpu/drm/i915/intel_i2c.c +56 -10
99 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 83/92 RCU pathwalk breakage when running into a symlink overmounting something
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 upstream.
Calling unlazy_walk() in walk_component() and do_last() when we find a symlink that needs to be followed doesn't acquire a reference to vfsmount. That's fine when the symlink is on the same vfsmount as the parent directory (which is almost always the case), but it's not always true - one _can_ manage to bind a symlink on top of something. And in such cases we end up with excessive mntput().
--- fs/namei.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/namei.c +4 -2
@@ -1545,7 +1545,8 @@ static inline int walk_component(structif (should_follow_link (path->dentry, follow)) {if (nd->flags &LOOKUP_RCU ) { -if (unlikely (unlazy_walk (nd, path->dentry))) { +if (unlikely (nd->path.mnt != path->mnt || +unlazy_walk (nd, path->dentry))) { err = -ECHILD ; goto out_err; }
@@ -2992,7 +2993,8 @@ finish_lookup:if (should_follow_link (path->dentry, !symlink_ok)) {if (nd->flags &LOOKUP_RCU ) { -if (unlikely (unlazy_walk (nd, path->dentry))) { +if (unlikely (nd->path.mnt != path->mnt || +unlazy_walk (nd, path->dentry))) { error = -ECHILD ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 84/92 ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Calvin Owens <[email protected]>
commit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream.
While debugging an issue with excessive softirq usage, I encountered the following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread infrastructure"):
[ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]
...but despite this note, the patch still calls RCU with IRQs disabled.
This seemingly innocuous change caused a significant regression in softirq CPU usage on the sending side of a large TCP transfer (~1 GB/s): when introducing 0.01% packet loss, the softirq usage would jump to around 25%, spiking as high as 50%. Before the change, the usage would never exceed 5%.
Moving the call to rcu_note_context_switch() after the cond_sched() call, as it was originally before the hotplug patch, completely eliminated this problem.
--- kernel/softirq.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
kernel/softirq.c +5 -1
@@ -657,9 +657,13 @@ static void run_ksoftirqd(unsigned int c* in the task stack here. */ __do_softirq (); -rcu_note_context_switch (cpu);local_irq_enable ();cond_resched (); + +preempt_disable (); +rcu_note_context_switch (cpu); +preempt_enable (); +return ; }local_irq_enable ();
Greg Kroah-Hartman
maintainerPATCH 85/92 e1000: add dummy allocator to fix race condition between mtu change and netpoll
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.
There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size:
Changing MTU frees all the rx buffers:
e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
e1000_clean_rx_ringThen, close to the end of e1000_change_mtu:
pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_fragAnd when we come back to do the rest of the MTU change:
e1000_up -> e1000_configure -> e1000_configure_rx ->
e1000_alloc_jumbo_rx_buffersalloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state.
This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown):
BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330
[...]
Call Trace: [<ffffffff81195445>] put_page+0x55/0x60 [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200 [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60 [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0 [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840 [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170 [<ffffffff81647050>] dev_set_mtu+0xa0/0x140 [<ffffffff81664218>] do_setlink+0x218/0xac0 [<ffffffff814459e9>] ? nla_parse+0xb9/0x120 [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890 [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40 [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260
By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx.
--- drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/e1000/e1000_main.c +9 -1
@@ -144,6 +144,11 @@ static bool e1000_clean_rx_irq(struct e1static bool e1000_clean_jumbo_rx_irq (struct e1000_adapter *adapter,struct e1000_rx_ring *rx_ring,int *work_done,int work_to_do); +static void e1000_alloc_dummy_rx_buffers (struct e1000_adapter *adapter, +struct e1000_rx_ring *rx_ring, +int cleaned_count) +{ +}static void e1000_alloc_rx_buffers (struct e1000_adapter *adapter,struct e1000_rx_ring *rx_ring,int cleaned_count);
@@ -3531,8 +3536,11 @@ static int e1000_change_mtu(struct net_dmsleep (1 );/* e1000_down has a dependency on max_frame_size */ hw->max_frame_size = max_frame; -if (netif_running (netdev)) +if (netif_running (netdev)) { +/* prevent buffers from being reallocated */ + adapter->alloc_rx_buf = e1000_alloc_dummy_rx_buffers;e1000_down (adapter); + }/* NOTE: netdev_alloc_skb reserves 16 bytes, and typically NET_IP_ALIGN * means we reserve 2 more, this pushes us to allocate from the next
Greg Kroah-Hartman
maintainerPATCH 86/92 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: mancha security <[email protected]>
commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream.
OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization.
For the random driver and crypto drivers, calls are emitted ...
$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function memzero_explicit:
0xffffffff813a18b0 <+0>: push %rbp
0xffffffff813a18b1 <+1>: mov %rsi,%rdx
0xffffffff813a18b4 <+4>: xor %esi,%esi
0xffffffff813a18b6 <+6>: mov %rsp,%rbp
0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 <memset>
0xffffffff813a18be <+14>: pop %rbp
0xffffffff813a18bf <+15>: retq
End of assembler dump. (gdb) disassemble extract_entropy
[...]
0xffffffff814a5009 <+313>: mov %r12,%rdi
0xffffffff814a500c <+316>: mov $0xa,%esi
0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 <memzero_explicit>
0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax[...]
... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead.
Minimal test example when we assume memzero_explicit() would *not* be a call, but would have been *inlined* instead:
static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
<foo>
}
int main(void)
{
char buff[20]; snprintf(buff, sizeof(buff) - 1, "test");
printf("%s", buff);
memzero_explicit(buff, sizeof(buff));
return 0;}
With <foo> := OPTIMIZER_HIDE_VAR():
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x0000000000400464 <+36>: callq 0x400410 <printf@plt> 0x0000000000400469 <+41>: xor %eax,%eax 0x000000000040046b <+43>: add $0x28,%rsp
0x000000000040046f <+47>: retq
End of assembler dump.
With <foo> := barrier():
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x0000000000400464 <+36>: callq 0x400410 <printf@plt> 0x0000000000400469 <+41>: movq $0x0,(%rsp) 0x0000000000400471 <+49>: movq $0x0,0x8(%rsp) 0x000000000040047a <+58>: movl $0x0,0x10(%rsp) 0x0000000000400482 <+66>: xor %eax,%eax 0x0000000000400484 <+68>: add $0x28,%rsp
0x0000000000400488 <+72>: retq
End of assembler dump.
As can be seen, movq, movq, movl are being emitted inlined via memset().
Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/
--- lib/string.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/string.c +1 -1
@@ -598,7 +598,7 @@ EXPORT_SYMBOL(memset);void memzero_explicit (void *s,size_t count) {memset (s,0 , count); -OPTIMIZER_HIDE_VAR (s); +barrier (); }EXPORT_SYMBOL (memzero_explicit);
Greg Kroah-Hartman
maintainerPATCH 87/92 wl18xx: show rx_frames_per_rates as an array as it really is
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Iooss <[email protected]>
commit a3fa71c40f1853d0c27e8f5bc01a722a705d9682 upstream.
In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be used to display this field in debugfs (it would display a pointer, not the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead.
This bug has been found by adding a __printf attribute to wl1271_format_buffer. gcc complained about "format '%u' expects argument of type 'unsigned int', but argument 5 has type 'u32 *'".
--- drivers/net/wireless/ti/wl18xx/debugfs.c | 2 +- drivers/net/wireless/ti/wlcore/debugfs.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/net/wireless/ti/wl18xx/debugfs.c +1 -1
@@ -136,7 +136,7 @@ WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, pWL18XX_DEBUGFS_FWSTATS_FILE (rx_filter, accum_arp_pend_requests,"%u" );WL18XX_DEBUGFS_FWSTATS_FILE (rx_filter, max_arp_queue_dep,"%u" ); -WL18XX_DEBUGFS_FWSTATS_FILE (rx_rate, rx_frames_per_rates,"%u" ); +WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY (rx_rate, rx_frames_per_rates,50 );WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY (aggr_size, tx_agg_vs_rate,AGGR_STATS_TX_AGG *AGGR_STATS_TX_RATE );
drivers/net/wireless/ti/wlcore/debugfs.h +2 -2
@@ -26,8 +26,8 @@#include "wlcore.h" -int wl1271_format_buffer (char __user *userbuf,size_t count, -loff_t *ppos,char *fmt, ...); +__printf(4, 5) int wl1271_format_buffer(char __user *userbuf, size_t count, +loff_t *ppos,char *fmt, ...);int wl1271_debugfs_init (struct wl1271 *wl);void wl1271_debugfs_exit (struct wl1271 *wl);
Greg Kroah-Hartman
maintainerPATCH 88/92 crypto: omap-aes - Fix support for unequal lengths
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Vutla, Lokesh" <[email protected]>
commit 6d7e7e02a044025237b6f62a20521170b794537f upstream.
For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver.
To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths.
--- drivers/crypto/omap-aes.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/crypto/omap-aes.c +11 -3
@@ -554,15 +554,23 @@ static int omap_aes_crypt_dma_stop(strucreturn err; } -static int omap_aes_check_aligned (struct scatterlist *sg) +static int omap_aes_check_aligned (struct scatterlist *sg,int total) { +int len =0 ; +while (sg) {if (!IS_ALIGNED (sg->offset,4 ))return -1 ;if (!IS_ALIGNED (sg->length,AES_BLOCK_SIZE ))return -1 ; + + len += sg->length; sg =sg_next (sg); } + +if (len != total) +return -1 ; +return 0 ; }
@@ -633,8 +641,8 @@ static int omap_aes_handle_queue(struct dd->in_sg = req->src; dd->out_sg = req->dst; -if (omap_aes_check_aligned (dd->in_sg) || -omap_aes_check_aligned (dd->out_sg)) { +if (omap_aes_check_aligned (dd->in_sg, dd->total) || +omap_aes_check_aligned (dd->out_sg, dd->total)) {if (omap_aes_copy_sgs (dd))pr_err ("Failed to copy SGs for unaligned cases\n" ); dd->sgs_copied =1 ;
Greg Kroah-Hartman
maintainerPATCH 90/92 memstick: mspro_block: add missing curly braces
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream.
Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly.
--- drivers/memstick/core/mspro_block.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/memstick/core/mspro_block.c +2 -1
@@ -758,7 +758,7 @@ static int mspro_block_complete_req(struif (error || (card->current_mrq.tpc ==MSPRO_CMD_STOP )) {if (msb->data_dir ==READ ) { -for (cnt =0 ; cnt < msb->current_seg; cnt++) +for (cnt =0 ; cnt < msb->current_seg; cnt++) { t_len += msb->req_sg[cnt].length / msb->page_size;
@@ -766,6 +766,7 @@ static int mspro_block_complete_req(stru t_len += msb->current_page -1 ; t_len *= msb->page_size; + } } }else t_len =blk_rq_bytes (msb->block_req);
Greg Kroah-Hartman
maintainerPATCH 91/92 driver core: bus: Goto appropriate labels on failure in bus_add_device
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junjie Mao <[email protected]>
commit 1c34203a1496d1849ba978021b878b3447d433c8 upstream.
It is not necessary to call device_remove_groups() when device_add_groups() fails.
The group added by device_add_groups() should be removed if sysfs_create_link() fails.
--- drivers/base/bus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/base/bus.c +2 -2
@@ -515,11 +515,11 @@ int bus_add_device(struct device *dev) goto out_put; error =device_add_groups (dev, bus->dev_groups);if (error) - goto out_groups; + goto out_id; error =sysfs_create_link (&bus->p->devices_kset->kobj, &dev->kobj,dev_name (dev));if (error) - goto out_id; + goto out_groups; error =sysfs_create_link (&dev->kobj, &dev->bus->p->subsys.kobj,"subsystem" );if (error)
Greg Kroah-Hartman
maintainerPATCH 65/92 ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
commit 4c533c801d1c9b5c38458a0e7516e0cf50643782 upstream.
acpi_scan_is_offline() may be called under the physical_node_lock lock of the given device object's parent, so prevent lockdep from complaining about that by annotating that instance with SINGLE_DEPTH_NESTING.
--- drivers/acpi/scan.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/acpi/scan.c +5 -1
@@ -192,7 +192,11 @@ bool acpi_scan_is_offline(struct acpi_destruct acpi_device_physical_node *pn;bool offline = true; -mutex_lock (&adev->physical_node_lock); +/* +* acpi_container_offline() calls this for all of the container's +* children under the container's physical_node_lock lock. +*/ +mutex_lock_nested (&adev->physical_node_lock,SINGLE_DEPTH_NESTING );list_for_each_entry (pn, &adev->physical_node_list, node)if (device_supports_offline (pn->dev) && !pn->dev->offline) {
Greg Kroah-Hartman
maintainerPATCH 92/92 fs: take i_mutex during prepare_binprm for set[ug]id executables
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543 upstream.
This prevents a race between chown() and execve(), where chowning a setuid-user binary to root would momentarily make the binary setuid root.
This patch was mostly written by Linus Torvalds.
--- fs/exec.c | 76 +++++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 48 insertions(+), 28 deletions(-)
fs/exec.c +48 -28
@@ -1268,6 +1268,53 @@ static void check_unsafe_exec(struct linspin_unlock (&p->fs->lock); } +static void bprm_fill_uid (struct linux_binprm *bprm) +{ +struct inode *inode; +unsigned int mode; +kuid_t uid; +kgid_t gid; + +/* clear any previous set[ug]id data from a previous binary */ + bprm->cred->euid =current_euid (); + bprm->cred->egid =current_egid (); + +if (bprm->file->f_path.mnt->mnt_flags &MNT_NOSUID ) +return ; + +if (current->no_new_privs) +return ; + + inode =file_inode (bprm->file); + mode =ACCESS_ONCE (inode->i_mode); +if (!(mode & (S_ISUID |S_ISGID ))) +return ; + +/* Be careful if suid/sgid is set */ +mutex_lock (&inode->i_mutex); + +/* reload atomically mode/uid/gid now that lock held */ + mode = inode->i_mode; + uid = inode->i_uid; + gid = inode->i_gid; +mutex_unlock (&inode->i_mutex); + +/* We ignore suid/sgid if there are no mappings for them in the ns */ +if (!kuid_has_mapping (bprm->cred->user_ns, uid) || + !kgid_has_mapping (bprm->cred->user_ns, gid)) +return ; + +if (mode &S_ISUID ) { + bprm->per_clear |=PER_CLEAR_ON_SETID ; + bprm->cred->euid = uid; + } + +if ((mode & (S_ISGID |S_IXGRP )) == (S_ISGID |S_IXGRP )) { + bprm->per_clear |=PER_CLEAR_ON_SETID ; + bprm->cred->egid = gid; + } +} +/* * Fill the binprm structure from the inode. * Check permissions, then read the first 128 (BINPRM_BUF_SIZE) bytes
@@ -1276,36 +1323,9 @@ static void check_unsafe_exec(struct lin*/ int prepare_binprm (struct linux_binprm *bprm) { -struct inode *inode =file_inode (bprm->file); -umode_t mode = inode->i_mode;int retval; - -/* clear any previous set[ug]id data from a previous binary */ - bprm->cred->euid =current_euid (); - bprm->cred->egid =current_egid (); - -if (!(bprm->file->f_path.mnt->mnt_flags &MNT_NOSUID ) && - !current->no_new_privs && -kuid_has_mapping (bprm->cred->user_ns, inode->i_uid) && -kgid_has_mapping (bprm->cred->user_ns, inode->i_gid)) { -/* Set-uid? */ -if (mode &S_ISUID ) { - bprm->per_clear |=PER_CLEAR_ON_SETID ; - bprm->cred->euid = inode->i_uid; - } - -/* Set-gid? */ -/* -* If setgid is set but no group execute bit then this -* is a candidate for mandatory locking, not a setgid -* executable. -*/ -if ((mode & (S_ISGID |S_IXGRP )) == (S_ISGID |S_IXGRP )) { - bprm->per_clear |=PER_CLEAR_ON_SETID ; - bprm->cred->egid = inode->i_gid; - } - } +bprm_fill_uid (bprm);/* fill in binprm security blob */ retval =security_bprm_set_creds (bprm);
Greg Kroah-Hartman
maintainerPATCH 66/92 xtensa: xtfpga: fix hardware lockup caused by LCD driver
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 upstream.
LCD driver is always built for the XTFPGA platform, but its base address is not configurable, and is wrong for ML605/KC705. Its initialization locks up KC705 board hardware.
Make the whole driver optional, and its base address and bus width configurable. Implement 4-bit bus access method.
--- arch/xtensa/Kconfig | 30 ++++++++ arch/xtensa/platforms/xtfpga/Makefile | 3 arch/xtensa/platforms/xtfpga/include/platform/hardware.h | 3 arch/xtensa/platforms/xtfpga/include/platform/lcd.h | 15 ++++ arch/xtensa/platforms/xtfpga/lcd.c | 55 +++++++++------ 5 files changed, 81 insertions(+), 25 deletions(-)
arch/xtensa/Kconfig +30 -0
@@ -336,6 +336,36 @@ menu "Executable file formats" source "fs/Kconfig.binfmt" +config XTFPGA_LCD + bool "Enable XTFPGA LCD driver" + depends on XTENSA_PLATFORM_XTFPGA + default n + help + There's a 2x16 LCD on most of XTFPGA boards, kernel may output + progress messages there during bootup/shutdown. It may be useful + during board bringup. + + If unsure, say N. + +config XTFPGA_LCD_BASE_ADDR + hex "XTFPGA LCD base address" + depends on XTFPGA_LCD + default "0x0d0c0000" + help + Base address of the LCD controller inside KIO region. + Different boards from XTFPGA family have LCD controller at different + addresses. Please consult prototyping user guide for your board for + the correct address. Wrong address here may lead to hardware lockup. + +config XTFPGA_LCD_8BIT_ACCESS + bool "Use 8-bit access to XTFPGA LCD" + depends on XTFPGA_LCD + default n + help + LCD may be connected with 4- or 8-bit interface, 8-bit access may + only be used with 8-bit interface. Please consult prototyping user + guide for your board for the correct interface width. + endmenu source "net/Kconfig"
arch/xtensa/platforms/xtfpga/Makefile +2 -1
@@ -6,4 +6,5 @@ # # Note 2! The CFLAGS definitions are in the main makefile... -obj-y = setup.o lcd.o +obj-y += setup.o +obj-$(CONFIG_XTFPGA_LCD) += lcd.o
arch/xtensa/platforms/xtfpga/include/platform/hardware.h +0 -3
@@ -40,9 +40,6 @@/* UART */ #define DUART16552_PADDR (XCHAL_KIO_PADDR + 0x0D050020) -/* LCD instruction and data addresses. */ -#define LCD_INSTR_ADDR ((char *)IOADDR(0x0D040000)) -#define LCD_DATA_ADDR ((char *)IOADDR(0x0D040004))/* Misc. */ #define XTFPGA_FPGAREGS_VADDR IOADDR(0x0D020000)
arch/xtensa/platforms/xtfpga/include/platform/lcd.h +15 -0
@@ -11,10 +11,25 @@#ifndef __XTENSA_XTAVNET_LCD_H#define __XTENSA_XTAVNET_LCD_H +#ifdef CONFIG_XTFPGA_LCD /* Display string STR at position POS on the LCD. */ void lcd_disp_at_pos (char *str,unsigned char pos);/* Shift the contents of the LCD display left or right. */ void lcd_shiftleft (void );void lcd_shiftright (void ); +#else +static inline void lcd_disp_at_pos (char *str,unsigned char pos) +{ +} + +static inline void lcd_shiftleft (void ) +{ +} + +static inline void lcd_shiftright (void ) +{ +} +#endif +#endif
arch/xtensa/platforms/xtfpga/lcd.c +34 -21
107 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 69/92 gpio: mvebu: Fix mask/unmask managment per irq chip type
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gregory CLEMENT <[email protected]>
commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream.
Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario:
First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm.
The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue.
It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario.
This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov:9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012
--- drivers/gpio/gpio-mvebu.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/gpio/gpio-mvebu.c +16 -8
@@ -304,11 +304,13 @@ static void mvebu_gpio_edge_irq_mask(str {struct irq_chip_generic *gc =irq_data_get_irq_chip_data (d);struct mvebu_gpio_chip *mvchip = gc->private; +struct irq_chip_type *ct =irq_data_get_chip_type (d);u32 mask =1 << (d->irq - gc->irq_base);irq_gc_lock (gc); - gc->mask_cache &= ~mask; -writel_relaxed (gc->mask_cache,mvebu_gpioreg_edge_mask (mvchip)); + ct->mask_cache_priv &= ~mask; + +writel_relaxed (ct->mask_cache_priv,mvebu_gpioreg_edge_mask (mvchip));irq_gc_unlock (gc); }
@@ -316,11 +318,13 @@ static void mvebu_gpio_edge_irq_unmask(s {struct irq_chip_generic *gc =irq_data_get_irq_chip_data (d);struct mvebu_gpio_chip *mvchip = gc->private; +struct irq_chip_type *ct =irq_data_get_chip_type (d); +u32 mask =1 << (d->irq - gc->irq_base);irq_gc_lock (gc); - gc->mask_cache |= mask; -writel_relaxed (gc->mask_cache,mvebu_gpioreg_edge_mask (mvchip)); + ct->mask_cache_priv |= mask; +writel_relaxed (ct->mask_cache_priv,mvebu_gpioreg_edge_mask (mvchip));irq_gc_unlock (gc); }
@@ -328,11 +332,13 @@ static void mvebu_gpio_level_irq_mask(st {struct irq_chip_generic *gc =irq_data_get_irq_chip_data (d);struct mvebu_gpio_chip *mvchip = gc->private; +struct irq_chip_type *ct =irq_data_get_chip_type (d); +u32 mask =1 << (d->irq - gc->irq_base);irq_gc_lock (gc); - gc->mask_cache &= ~mask; -writel_relaxed (gc->mask_cache,mvebu_gpioreg_level_mask (mvchip)); + ct->mask_cache_priv &= ~mask; +writel_relaxed (ct->mask_cache_priv,mvebu_gpioreg_level_mask (mvchip));irq_gc_unlock (gc); }
@@ -340,11 +346,13 @@ static void mvebu_gpio_level_irq_unmask( {struct irq_chip_generic *gc =irq_data_get_irq_chip_data (d);struct mvebu_gpio_chip *mvchip = gc->private; +struct irq_chip_type *ct =irq_data_get_chip_type (d); +u32 mask =1 << (d->irq - gc->irq_base);irq_gc_lock (gc); - gc->mask_cache |= mask; -writel_relaxed (gc->mask_cache,mvebu_gpioreg_level_mask (mvchip)); + ct->mask_cache_priv |= mask; +writel_relaxed (ct->mask_cache_priv,mvebu_gpioreg_level_mask (mvchip));irq_gc_unlock (gc); }
Greg Kroah-Hartman
maintainerPATCH 70/92 gpio: clamp returned values to the boolean range
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Courbot <[email protected]>
commit 23600969ff137cf4c3bc9098f77e381de334e3f7 upstream.
Nothing prevents GPIO drivers from returning values outside the boolean range, and as it turns out a few drivers are actually doing so. These values were passed as-is to unsuspecting consumers and created confusion.
This patch makes the internal _gpiod_get_raw_value() function return a bool, effectively clamping the GPIO value to the boolean range no matter what the driver does.
While we are at it, we also change the value parameter of _gpiod_set_raw_value() to bool type before drivers start doing funny things with it as well.
Another way to fix this would be to change the prototypes of the driver interface to use bool directly, but this would require a huge cross-systems patch so this simpler solution is preferred.
Changes since v1:
- Change local variable type to bool as well, use boolean values in code
- Also change prototype of open drain/open source setting functions since they are only called from _gpiod_set_raw_value()
This probably calls for a larger booleanization of gpiolib, but let's keep that for a latter change - right now we need to address the issue of non-boolean values returned by drivers.
--- drivers/gpio/gpiolib.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/gpio/gpiolib.c +6 -6
@@ -1928,15 +1928,15 @@ EXPORT_SYMBOL_GPL(gpiod_is_active_low);* that the GPIO was actually requested. */ -static int _gpiod_get_raw_value (const struct gpio_desc *desc) +static bool _gpiod_get_raw_value (const struct gpio_desc *desc) {struct gpio_chip *chip; -int value; +bool value;int offset; chip = desc->chip; offset =gpio_chip_hwgpio (desc); - value = chip->get ? chip->get (chip, offset) :0 ; + value = chip->get ? chip->get (chip, offset) : false;trace_gpio_value (desc_to_gpio (desc),1 , value);return value; }
@@ -1992,7 +1992,7 @@ EXPORT_SYMBOL_GPL(gpiod_get_value);* @desc: gpio descriptor whose state need to be set. * @value: Non-zero for setting it HIGH otherise it will set to LOW. */ -static void _gpio_set_open_drain_value (struct gpio_desc *desc,int value) +static void _gpio_set_open_drain_value (struct gpio_desc *desc,bool value) {int err =0 ;struct gpio_chip *chip = desc->chip;
@@ -2019,7 +2019,7 @@ static void _gpio_set_open_drain_value(s* @desc: gpio descriptor whose state need to be set. * @value: Non-zero for setting it HIGH otherise it will set to LOW. */ -static void _gpio_set_open_source_value (struct gpio_desc *desc,int value) +static void _gpio_set_open_source_value (struct gpio_desc *desc,bool value) {int err =0 ;struct gpio_chip *chip = desc->chip;
@@ -2041,7 +2041,7 @@ static void _gpio_set_open_source_value( __func__, err); } -static void _gpiod_set_raw_value (struct gpio_desc *desc,int value) +static void _gpiod_set_raw_value (struct gpio_desc *desc,bool value) {struct gpio_chip *chip;
Greg Kroah-Hartman
maintainerPATCH 71/92 clk: tegra: Register the proper number of resets
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thierry Reding <[email protected]>
commit 5e43e259171e1eee8bc074d9c44be434e685087b upstream.
The number of resets controls is 32 times the number of peripheral register banks rather than 32 times the number of clocks. This reduces (drastically) the number of reset controls registered from 10080 (315 clocks * 32) to 224 (6 peripheral register banks * 32).
This also fixes a potential crash because trying to use any of the excess reset controls (224-10079) would have caused accesses beyond the array bounds of the peripheral register banks definition array.
--- drivers/clk/tegra/clk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/tegra/clk.c +1 -1
@@ -266,7 +266,7 @@ void __init tegra_add_of_provider(structof_clk_add_provider (np, of_clk_src_onecell_get, &clk_data); rst_ctlr.of_node = np; - rst_ctlr.nr_resets = clk_num *32 ; + rst_ctlr.nr_resets = periph_banks *32 ;reset_controller_register (&rst_ctlr); }
Greg Kroah-Hartman
maintainerPATCH 62/92 powerpc/cell: Fix cell iommu after it_page_shift changes
In reply to Greg Kroah-Hartman3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
commit 7261b956b276aa97fbf60d00f1d7717d2ea6ee78 upstream.
The patch to add it_page_shift incorrectly changed the increment of uaddr to use it_page_shift, rather then (1 << it_page_shift).
This broke booting on at least some Cell blades, as the iommu was basically non-functional.
--- arch/powerpc/platforms/cell/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/platforms/cell/iommu.c +1 -1
@@ -197,7 +197,7 @@ static int tce_build_cell(struct iommu_t io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset); -for (i =0 ; i < npages; i++, uaddr += tbl->it_page_shift) +for (i =0 ; i < npages; i++, uaddr += (1 << tbl->it_page_shift)) io_pte[i] = base_pte | (__pa (uaddr) & CBE_IOPTE_RPN_Mask);mb ();
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
Build results:
total: 127 pass: 125 fail: 2 Failed builds: s390:defconfig s390:allmodconfig
Qemu test results:
total: 30 pass: 30 fail: 0
Build error:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':arch/s390/kernel/suspend.c:145:30: error: '_eshared' undeclared (first use in this function) arch/s390/kernel/suspend.c:145:30: note: each undeclared identifier is reported only once for each function it appears in arch/s390/kernel/suspend.c:146:28: error: '_stext' undeclared (first use in this function)
Bisect points to 's390/hibernate: fix save and restore of kernel text section'.
Guenter
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
-- Shuah
Signature · 5 lines
Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) [email protected] | (970) 217-8978
Re: [PATCH 3.14 26/92] ARM: at91/dt: sama5d3 xplained: add phy address for macb1
In reply to Greg Kroah-HartmanQuoted 2 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
This commit was tagged for stable 3.19 so it's probably not relevant for the 3.14 kernel.
Cheers,
--
Lu�s
Quoted 44 lines
------------------
From: Nicolas Ferre <[email protected]>
commit
98b80987c940956da48f0c703f60340128bb8521upstream.After
57a38effa598(net: phy: micrel: disable broadcast for KSZ8081/KSZ8091) the macb1 interface refuses to work properly because it tries
to cling to address 0 which isn't able to communicate in broadcast with the mac anymore. The micrel phy on the board is actually configured to show up at address 1.
Adding the phy node and its real address fixes the issue.Signed-off-by Nicolas Ferre <[email protected]>Cc Johan Hovold <[email protected]>Signed-off-by Olof Johansson <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- arch/arm/boot/dts/at91-sama5d3_xplained.dts | 6 ++++++ 1 file changed, 6 insertions(+)arch/arm/boot/dts/at91-sama5d3_xplained.dts +6
-1@@ -107,7 +107,13 @@ macb1: ethernet@f802c000 { phy-mode = "rmii"; + #address-cells = <1>; + #size-cells = <0>; status = "okay"; + + ethernet-phy@1 { + reg = <0x1>; + }; }; dbgu: serial@ffffee00 { --To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
In reply to Greg Kroah-HartmanQuoted 7 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Collins <[email protected]>
commit
0618764cb25f6fa9fb31152995de42a8a0496475upstream.
The commit in question was recently merged to mainline and is now being sent to various stable kernels. But I think the patch is wrong and the real problem lies in the Freescale CAAM driver which is described as having being tested with.
commit 0618764cb25f6fa9fb31152995de42a8a0496475
Author: Ben Collins <[email protected]>
Date: Fri Apr 3 16:09:46 2015 +0000
dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
I suspect this doesn't show up for most anyone because software algorithms typically don't have a sense of being too busy. However, when working with the Freescale CAAM driver it will return -EBUSY on occasion under heavy -- which resulted in dm-crypt deadlock.
After checking the logic in some other drivers, the scheme for crypt_convert() and it's callback, kcryptd_async_done(), were not correctly laid out to properly handle -EBUSY or -EINPROGRESS.
Fix this by using the completion for both -EBUSY and -EINPROGRESS. Now crypt_convert()'s use of completion is comparable to af_alg_wait_for_completion(). Similarly, kcryptd_async_done() follows the pattern used in af_alg_complete().
Before this fix dm-crypt would lockup within 1-2 minutes running with the CAAM driver. Fix was regression tested against software algorithms on PPC32 and x86_64, and things seem perfectly happy there as well.
dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.
Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example).
dm-crypt (before this patch) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in the commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt.
The problem is that the Freescale CAAM driver, which this problem is described as being seen on, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver.
What this patch does is that it makes dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that this patch will cause a performance regression on all crypto drivers which implement the API correctly.
So, I think this patch should be reverted in mainline and the stable kernels where it has been merged, and correct backlog handling should be implemented in the CAAM driver instead.
Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
Quoted 8 lines · Rabin Vincent
Quoted 4 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 8 lines
Quoted 3 lines
From: Ben Collins <[email protected]>
commit
0618764cb25f6fa9fb31152995de42a8a0496475upstream.The commit in question was recently merged to mainline and is now being sent to various stable kernels. But I think the patch is wrong and the real problem lies in the Freescale CAAM driver which is described as having being tested with.
There may be something quirky with CAAM, yes, but the fact is, the code in the dm-crypt module was very dissimilar to other drivers performing the same loop/logic.
I don’t think that this patch, which was deemed correct, should be held up based on lower level logic “possibly” being partially at fault. On the contrary, I think errors you point out may just be showing the error in dm-crypt more easily, rather than being the complete problem.
Quoted 71 lines
commit
0618764cb25f6fa9fb31152995de42a8a0496475Author: Ben Collins <[email protected]> Date: Fri Apr 3 16:09:46 2015 +0000dm crypt: fix deadlock when async crypto algorithm returns
-EBUSYI suspect this doesn't show up for most anyone because software algorithms typically don't have a sense of being too busy. However, when working with the Freescale CAAM driver it will return
-EBUSYon occasion under heavy -- which resulted in dm-crypt deadlock.After checking the logic in some other drivers, the scheme for
crypt_convert()and it's callback,kcryptd_async_done(), were not correctly laid out to properly handle-EBUSYor-EINPROGRESS.Fix this by using the completion for both
-EBUSYand-EINPROGRESS. Now crypt_convert()'s use of completion is comparable toaf_alg_wait_for_completion(). Similarly,kcryptd_async_done()follows the pattern used inaf_alg_complete().Before this fix dm-crypt would lockup within 1-2 minutes running with the CAAM driver. Fix was regression tested against software algorithms on PPC32 and
x86_64, and things seem perfectly happy there as well.Signed-off-by Ben Collins <[email protected]>Signed-off-by Mike Snitzer <[email protected]>dm-crypt uses
CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns-EINPROGRESS. When the crypto hw's queue if full, the driver returns-EBUSY, and ifCRYPTO_TFM_REQ_MAY_BACKLOGis set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of-EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(),crypto_enqueue_request(),crypto_dequeue_request()andcrypto_get_backlog()helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example).dm-crypt (before this patch) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back
-EINPROGRESSfrom the request function). Then, when it sees at least one backlogged request (gets-EBUSY), it waits till that backlogged request is handled (completion gets called with-EINPROGRESS), and then continues. The references toaf_alg_wait_for_completion()andaf_alg_complete()in the commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt.The problem is that the Freescale CAAM driver, which this problem is described as being seen on, fails to implement the backlogging behaviour correctly. In
cam_jr_enqueue(), if the hardware queue is full, it simply returns-EBUSYwithout backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously thewait_for_completion()incrypto_convert()where dm-crypto would wait for the completion being called with-EINPROGRESSin the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver.What this patch does is that it makes dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see
-EBUSY. This means that this patch will cause a performance regression on all crypto drivers which implement the API correctly.
Quoted 3 lines
So, I think this patch should be reverted in mainline and the stable kernels where it has been merged, and correct backlog handling should be implemented in the CAAM driver instead.
——
Ben Collins
Cyphre Champion
——————————————
VP of Engineering
Servergy, Inc.
Greg Kroah-Hartman
maintainerQuoted 19 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
Build results:
total: 127 pass: 125 fail: 2 Failed builds: s390:defconfig s390:allmodconfigQemu test results:
total: 30 pass: 30 fail: 0
Quoted 8 lines
Build error:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':arch/s390/kernel/suspend.c:145:30: error: '_eshared' undeclared (first use in this function)arch/s390/kernel/suspend.c:145:30: note: each undeclared identifier is reported only once for each function it appears inarch/s390/kernel/suspend.c:146:28: error: '_stext' undeclared (first use in this function)Bisect points to 's390/hibernate: fix save and restore of kernel text section'.
Should now be fixed, thanks.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 13 lines · Shuah Khan
Quoted 12 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gzand the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
Herbert Xu
maintainerRe: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
In reply to Rabin VincentQuoted 5 lines · Rabin Vincent
Quoted 4 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 8 lines
Quoted 3 lines
From: Ben Collins <[email protected]>
commit
0618764cb25f6fa9fb31152995de42a8a0496475upstream.The commit in question was recently merged to mainline and is now being sent to various stable kernels. But I think the patch is wrong and the real problem lies in the Freescale CAAM driver which is described as having being tested with.
I agree. Please revert this patch.
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
In reply to Rabin VincentQuoted 60 lines · Rabin Vincent
Quoted 7 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Collins <[email protected]>
commit
0618764cb25f6fa9fb31152995de42a8a0496475upstream.The commit in question was recently merged to mainline and is now being sent to various stable kernels. But I think the patch is wrong and the real problem lies in the Freescale CAAM driver which is described as having being tested with.
commit
0618764cb25f6fa9fb31152995de42a8a0496475
Author: Ben Collins <[email protected]>
Date: Fri Apr 3 16:09:46 2015 +0000dm crypt: fix deadlock when async crypto algorithm returns
-EBUSYI suspect this doesn't show up for most anyone because software algorithms typically don't have a sense of being too busy. However, when working with the Freescale CAAM driver it will return
-EBUSYon occasion under heavy -- which resulted in dm-crypt deadlock.After checking the logic in some other drivers, the scheme for
crypt_convert()and it's callback,kcryptd_async_done(), were not correctly laid out to properly handle-EBUSYor-EINPROGRESS.Fix this by using the completion for both
-EBUSYand-EINPROGRESS. Now crypt_convert()'s use of completion is comparable toaf_alg_wait_for_completion(). Similarly,kcryptd_async_done()follows the pattern used inaf_alg_complete().Before this fix dm-crypt would lockup within 1-2 minutes running with the CAAM driver. Fix was regression tested against software algorithms on PPC32 and
x86_64, and things seem perfectly happy there as well.Signed-off-by Ben Collins <[email protected]>Signed-off-by Mike Snitzer <[email protected]>dm-crypt uses
CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns-EINPROGRESS. When the crypto hw's queue if full, the driver returns-EBUSY, and ifCRYPTO_TFM_REQ_MAY_BACKLOGis set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of-EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(),crypto_enqueue_request(),crypto_dequeue_request()andcrypto_get_backlog()helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example).
Quoted 8 lines
dm-crypt (before this patch) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back
-EINPROGRESSfrom the request function). Then, when it sees at least one backlogged request (gets-EBUSY), it waits till that backlogged request is handled (completion gets called with-EINPROGRESS), and then continues. The references toaf_alg_wait_for_completion()andaf_alg_complete()in the commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt.
OK, I clearly missed the subtleties of the API. dm-crypt.c definitely needs more documentation related to CRYPTO_TFM_REQ_MAY_BACKLOG and the implications it has on completions, etc.
Any chance you'd be willing to provide in-code comments in the appropriate places in dm-crypt.c (after having reverted this patch in question)?
I'd be happy to take the combination of the revert and documentation in a single patch and get it to Linus for 4.0-rc3.
Quoted 16 lines
The problem is that the Freescale CAAM driver, which this problem is described as being seen on, fails to implement the backlogging behaviour correctly. In
cam_jr_enqueue(), if the hardware queue is full, it simply returns-EBUSYwithout backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously thewait_for_completion()incrypto_convert()where dm-crypto would wait for the completion being called with-EINPROGRESSin the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver.What this patch does is that it makes dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see
-EBUSY. This means that this patch will cause a performance regression on all crypto drivers which implement the API correctly.
Quoted 3 lines
So, I think this patch should be reverted in mainline and the stable kernels where it has been merged, and correct backlog handling should be implemented in the CAAM driver instead.
Hopefully it hasn't been merged, Greg?
If it has been merged to stable@ then we'll have to split the revert patch out from any documentation improvements.
Quoted 19 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
Build results:
total: 127 pass: 125 fail: 2 Failed builds: s390:defconfig s390:allmodconfigQemu test results:
total: 30 pass: 30 fail: 0
Quoted 9 lines
Build error:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':arch/s390/kernel/suspend.c:145:30: error: '_eshared' undeclared (first use in this function)arch/s390/kernel/suspend.c:145:30: note: each undeclared identifier is reported only once for each function it appears inarch/s390/kernel/suspend.c:146:28: error: '_stext' undeclared (first use in this function)Bisect points to 's390/hibernate: fix save and restore of kernel text section'.
Build and qemu test results for v3.14.y are now ok; no more failures.
Guenter
Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
In reply to Mike SnitzerQuoted 16 lines · Mike Snitzer
Quoted 13 lines · Rabin Vincent
Quoted 7 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Collins <[email protected]>
commit
0618764cb25f6fa9fb31152995de42a8a0496475upstream.The commit in question was recently merged to mainline and is now being sent to various stable kernels. But I think the patch is wrong and the real problem lies in the Freescale CAAM driver which is described as having being tested with.
...
Quoted 11 lines
Quoted 11 lines
dm-crypt uses
CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns-EINPROGRESS. When the crypto hw's queue if full, the driver returns-EBUSY, and ifCRYPTO_TFM_REQ_MAY_BACKLOGis set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of-EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.
Mike, I thought there was a discussion with crypto API maintainer before merging this patch, I think there were some comments that the patch seems to be not correct...
This API (EBUSY/EINPROGESS codes) use was there since dmcrypt switched to async crypto API.
There should tests for it (some years ago we tested the async path by forcing to use cryptd, this was able to clearly simulate the BUSY path as well), but not sure if it is still possible so easily.
Quoted 6 lines
Any chance you'd be willing to provide in-code comments in the appropriate places in
dm-crypt.c(after having reverted this patch in question)?I'd be happy to take the combination of the revert and documentation in a single patch and get it to Linus for 4.0-rc3.
Please, do not mix revert patches with additions (even if it is just comment), someone could be even more confused what's going on here.
If nobody volunteers, I'll try to add some comments later to dmcrypt code, but that is definitely not for stable.
Thanks,
Milan
Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
Quoted 32 lines · Milan Broz
Quoted 16 lines · Mike Snitzer
Quoted 13 lines · Rabin Vincent
Quoted 7 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Collins <[email protected]>
commit
0618764cb25f6fa9fb31152995de42a8a0496475upstream.The commit in question was recently merged to mainline and is now being sent to various stable kernels. But I think the patch is wrong and the real problem lies in the Freescale CAAM driver which is described as having being tested with.
...
Quoted 11 lines
Quoted 11 lines
dm-crypt uses
CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns-EINPROGRESS. When the crypto hw's queue if full, the driver returns-EBUSY, and ifCRYPTO_TFM_REQ_MAY_BACKLOGis set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of-EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.
Quoted 3 lines
Mike, I thought there was a discussion with crypto API maintainer before merging this patch, I think there were some comments that the patch seems to be not correct...
I unfortunately didn't cc Herbert on the original v2 patch (but I did later bounce the mail to him IIRC). Regardless, no I didn't see any feedback and I really should've been more active in engaging him.
Quoted 11 lines
This API (EBUSY/EINPROGESS codes) use was there since dmcrypt switched to async crypto API.
There should tests for it (some years ago we tested the async path by forcing to use cryptd, this was able to clearly simulate the BUSY path as well), but not sure if it is still possible so easily.
Quoted 4 lines
Any chance you'd be willing to provide in-code comments in the appropriate places in
dm-crypt.c(after having reverted this patch in question)?
Quoted 5 lines
Quoted 2 lines
I'd be happy to take the combination of the revert and documentation in a single patch and get it to Linus for 4.0-rc3.
Please, do not mix revert patches with additions (even if it is just comment), someone could be even more confused what's going on here.
I was only saying to mix comments and revert if the patch in question didn't get into stable@ at all.
But safer to just do a pure revert. I get it queued up to send to Linus.
Quoted 2 lines
If nobody volunteers, I'll try to add some comments later to dmcrypt code, but that is definitely not for stable.
Yeap, thanks.
PATCH 1/1 Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY"
This reverts commit 0618764cb25f6fa9fb31152995de42a8a0496475.
The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver.
dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.
Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example).
dm-crypt (before this patch) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt.
The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver.
What that commit does is that it makes dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly.
Revert it. Correct backlog handling should be implemented in the CAAM driver instead.
--- drivers/md/dm-crypt.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/md/dm-crypt.c +6 -6
@@ -925,10 +925,11 @@ static int crypt_convert(struct crypt_config *cc,switch (r) {/* async */ -case -EINPROGRESS :case -EBUSY :wait_for_completion (&ctx->restart);reinit_completion (&ctx->restart); +/* fall through*/ +case -EINPROGRESS : ctx->req =NULL ; ctx->cc_sector++;continue ;
@@ -1345,8 +1346,10 @@ static void kcryptd_async_done(struct crypto_async_request *async_req, struct dm_crypt_io *io = container_of(ctx, struct dm_crypt_io, ctx);struct crypt_config *cc = io->cc; -if (error == -EINPROGRESS ) +if (error == -EINPROGRESS ) { +complete (&ctx->restart);return ; + }if (!error && cc->iv_gen_ops && cc->iv_gen_ops->post) error = cc->iv_gen_ops->post (cc,iv_of_dmreq (cc, dmreq), dmreq);
@@ -1357,15 +1360,12 @@ static void kcryptd_async_done(struct crypto_async_request *async_req,crypt_free_req (cc,req_of_dmreq (cc, dmreq), io->base_bio);if (!atomic_dec_and_test (&ctx->cc_pending)) - goto done; +return ;if (bio_data_dir (io->base_bio) ==READ )kcryptd_crypt_read_done (io);else kcryptd_crypt_write_io_submit (io,1 ); -done: -if (!completion_done (&ctx->restart)) -complete (&ctx->restart); }static void kcryptd_crypt (struct work_struct *work)
Signature · 1 line
1.7.10.4
Re: [PATCH] Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY"
Quoted 48 lines · Rabin Vincent
This reverts commit
0618764cb25f6fa9fb31152995de42a8a0496475.The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver.
dm-crypt uses
CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns-EINPROGRESS. When the crypto hw's queue if full, the driver returns-EBUSY, and ifCRYPTO_TFM_REQ_MAY_BACKLOGis set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of-EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done.Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(),crypto_enqueue_request(),crypto_dequeue_request()andcrypto_get_backlog()helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example).dm-crypt (before this patch) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back
-EINPROGRESSfrom the request function). Then, when it sees at least one backlogged request (gets-EBUSY), it waits till that backlogged request is handled (completion gets called with-EINPROGRESS), and then continues. The references toaf_alg_wait_for_completion()andaf_alg_complete()in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt.The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In
cam_jr_enqueue(), if the hardware queue is full, it simply returns-EBUSYwithout backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously thewait_for_completion()incrypto_convert()where dm-crypto would wait for the completion being called with-EINPROGRESSin the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver.What that commit does is that it makes dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see
-EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly.
Quoted 4 lines
Revert it. Correct backlog handling should be implemented in the CAAM driver instead.
Signed-off-by Rabin Vincent <[email protected]>
I confirm CAAM crypto driver currently lacks backlogging support.
Horia
Greg Kroah-Hartman
maintainerRe: [PATCH 3.14 26/92] ARM: at91/dt: sama5d3 xplained: add phy address for macb1
In reply to Luis HenriquesQuoted 6 lines · Luis Henriques
Quoted 2 lines · Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know.
This commit was tagged for stable 3.19 so it's probably not relevant for the 3.14 kernel.
Ah, missed that, thanks, now removed.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gzand the diffstat can be found below.
-rc2 is out that should hopefully be all correct now:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc2.gz
Greg Kroah-Hartman
maintainerQuoted 27 lines · Guenter Roeck
Quoted 26 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
Build results:
total: 127 pass: 125 fail: 2 Failed builds: s390:defconfig s390:allmodconfigQemu test results:
total: 30 pass: 30 fail: 0Build error:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':arch/s390/kernel/suspend.c:145:30: error: '_eshared' undeclared (first use in this function)arch/s390/kernel/suspend.c:145:30: note: each undeclared identifier is reported only once for each function it appears inarch/s390/kernel/suspend.c:146:28: error: '_stext' undeclared (first use in this function)
Quoted 4 lines
Quoted 2 lines
Bisect points to 's390/hibernate: fix save and restore of kernel text section'.
Build and qemu test results for v3.14.y are now ok; no more failures.
Thanks, I've done a -rc2 to be safe.
greg k-h
Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines
Quoted 6 lines
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gzand the diffstat can be found below.
-rc2 is out that should hopefully be all correct now:
Build results:
total: 127 pass: 127 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
Quoted 14 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.41 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon May 4 18:59:41 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gzand the diffstat can be found below.
Review
Quoted 3 lines
(quoted diff) +0
-1-rc2 is out that should hopefully be all correct now: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc2.gz
rc2 is good. Compiled and booted. No dmesg regressions.
-- Shuah
Signature · 5 lines
Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) [email protected] | (970) 217-8978
PATCH 1/1 dm crypt: Add comments to better describe crypto processing logic.
In reply to Rabin VincentA crypto driver can process request synchronously or asynchronously and can use internal driver queue to backlog requests.
Add some comments to clarify internal logic and completion return codes.
--- drivers/md/dm-crypt.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-)
drivers/md/dm-crypt.c +24 -6
@@ -1,7 +1,7 @@/* * Copyright (C) 2003 Jana Saout <[email protected]> * Copyright (C) 2004 Clemens Fruhwirth <[email protected]> -* Copyright (C) 2006-2009 Red Hat, Inc. All rights reserved. +* Copyright (C) 2006-2015 Red Hat, Inc. All rights reserved. * Copyright (C) 2013 Milan Broz <[email protected]> * * This file is released under the GPL.
@@ -891,6 +891,11 @@ static void crypt_alloc_req(struct crypt_config *cc, ctx->req =mempool_alloc (cc->req_pool,GFP_NOIO );ablkcipher_request_set_tfm (ctx->req, cc->tfms[key_index]); + +/* +* Use REQ_MAY_BACKLOG so a cipher driver internally backlogs +* requests if driver request queue is full. +*/ ablkcipher_request_set_callback (ctx->req,CRYPTO_TFM_REQ_MAY_BACKLOG |CRYPTO_TFM_REQ_MAY_SLEEP , kcryptd_async_done,dmreq_of_req (cc, ctx->req));
@@ -924,24 +929,32 @@ static int crypt_convert(struct crypt_config *cc, r =crypt_convert_block (cc, ctx, ctx->req);switch (r) { -/* async */ +/* +* The request was queued by a crypto driver +* but the driver request queue is full, let's wait. +*/ case -EBUSY :wait_for_completion (&ctx->restart);reinit_completion (&ctx->restart); -/* fall through*/ +/* fall through */ +/* +* The request is queued and processed asynchronously, +* completion function kcryptd_async_done() will be called. +*/ case -EINPROGRESS : ctx->req =NULL ; ctx->cc_sector++;continue ; - -/* sync */ +/* +* The request was already processed (synchronously). +*/ case 0 :atomic_dec (&ctx->cc_pending); ctx->cc_sector++;cond_resched ();continue ; -/* error */ +/* There was an error while processing the request. */ default :atomic_dec (&ctx->cc_pending);return r;
@@ -1346,6 +1359,11 @@ static void kcryptd_async_done(struct crypto_async_request *async_req, struct dm_crypt_io *io = container_of(ctx, struct dm_crypt_io, ctx);struct crypt_config *cc = io->cc; +/* +* A request from crypto driver backlog is going to be processed now, +* finish the completion and continue in crypt_convert(). +* (Callback will be called for the second time for this request.) +*/ if (error == -EINPROGRESS ) {complete (&ctx->restart);return ;
Signature · 1 line
2.1.4
Re: dm crypt: Add comments to better describe crypto processing logic.
Quoted 5 lines · Milan Broz
A crypto driver can process request synchronously or asynchronously and can use internal driver queue to backlog requests.
Add some comments to clarify internal logic and completion return codes.Signed-off-by Milan Broz <[email protected]>
Thanks Milan, I picked this up for 4.2.