aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-07-22parport: fix freeing freed memorySudip Mukherjee1-4/+4
After the reference count becomes 0 when put_device() is called, it will execute the release callback where we are freeing all the allocated memory associated with the device. So if we just continue on the error path then we are again freeing devname and trying to dereference par_dev which has already been free-ed in the release callback. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22parport: fix memory leakSudip Mukherjee1-0/+1
After the reference count becomes 0 when put_device() is called, it will execute the release callback where we are freeing all the allocated memory associated with the device. We missed freeing par_dev->state. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22parport: fix error handlingSudip Mukherjee1-1/+2
After registering the device if exclusive access fails for any reason then we need to unregister the device to remove all references. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22mnt: Clarify and correct the disconnect logic in umount_treeEric W. Biederman2-6/+31
rmdir mntpoint will result in an infinite loop when there is a mount locked on the mountpoint in another mount namespace. This is because the logic to test to see if a mount should be disconnected in umount_tree is buggy. Move the logic to decide if a mount should remain connected to it's mountpoint into it's own function disconnect_mount so that clarity of expression instead of terseness of expression becomes a virtue. When the conditions where it is invalid to leave a mount connected are first ruled out, the logic for deciding if a mount should be disconnected becomes much clearer and simpler. Fixes: e0c9c0afd2fc958ffa34b697972721d81df8a56f mnt: Update detach_mounts to leave mounts connected Fixes: ce07d891a0891d3c0d0c2d73d577490486b809e1 mnt: Honor MNT_LOCKED when detaching mounts Cc: [email protected] Signed-off-by: "Eric W. Biederman" <[email protected]>
2015-07-22Btrfs: fix quick exhaustion of the system array in the superblockFilipe Manana1-0/+18
Omar reported that after commit 4fbcdf669454 ("Btrfs: fix -ENOSPC when finishing block group creation"), introduced in 4.2-rc1, the following test was failing due to exhaustion of the system array in the superblock: #!/bin/bash truncate -s 100T big.img mkfs.btrfs big.img mount -o loop big.img /mnt/loop num=5 sz=10T for ((i = 0; i < $num; i++)); do echo fallocate $i $sz fallocate -l $sz /mnt/loop/testfile$i done btrfs filesystem sync /mnt/loop for ((i = 0; i < $num; i++)); do echo rm $i rm /mnt/loop/testfile$i btrfs filesystem sync /mnt/loop done umount /mnt/loop This made btrfs_add_system_chunk() fail with -EFBIG due to excessive allocation of system block groups. This happened because the test creates a large number of data block groups per transaction and when committing the transaction we start the writeout of the block group caches for all the new new (dirty) block groups, which results in pre-allocating space for each block group's free space cache using the same transaction handle. That in turn often leads to creation of more block groups, and all get attached to the new_bgs list of the same transaction handle to the point of getting a list with over 1500 elements, and creation of new block groups leads to the need of reserving space in the chunk block reserve and often creating a new system block group too. So that made us quickly exhaust the chunk block reserve/system space info, because as of the commit mentioned before, we do reserve space for each new block group in the chunk block reserve, unlike before where we would not and would at most allocate one new system block group and therefore would only ensure that there was enough space in the system space info to allocate 1 new block group even if we ended up allocating thousands of new block groups using the same transaction handle. That worked most of the time because the computed required space at check_system_chunk() is very pessimistic (assumes a chunk tree height of BTRFS_MAX_LEVEL/8 and that all nodes/leafs in a path will be COWed and split) and since the updates to the chunk tree all happen at btrfs_create_pending_block_groups it is unlikely that a path needs to be COWed more than once (unless writepages() for the btree inode is called by mm in between) and that compensated for the need of creating any new nodes/leads in the chunk tree. So fix this by ensuring we don't accumulate a too large list of new block groups in a transaction's handles new_bgs list, inserting/updating the chunk tree for all accumulated new block groups and releasing the unused space from the chunk block reserve whenever the list becomes sufficiently large. This is a generic solution even though the problem currently can only happen when starting the writeout of the free space caches for all dirty block groups (btrfs_start_dirty_block_groups()). Reported-by: Omar Sandoval <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Tested-by: Omar Sandoval <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-07-22btrfs: its btrfs_err() instead of btrfs_error()Anand Jain1-1/+1
sorry I indented to use btrfs_err() and I have no idea how btrfs_error() got there. infact I was thinking about these kind of oversights since these two func are too closely named. Signed-off-by: Anand Jain <[email protected]> Reviewed-by: Liu Bo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-07-22btrfs: Avoid NULL pointer dereference of free_extent_buffer when ↵Zhao Lei1-1/+2
read_tree_block() fail When read_tree_block() failed, we can see following dmesg: [ 134.371389] BUG: unable to handle kernel NULL pointer dereference at 0000000000000063 [ 134.372236] IP: [<ffffffff813a4a51>] free_extent_buffer+0x21/0x90 [ 134.372236] PGD 0 [ 134.372236] Oops: 0000 [#1] SMP [ 134.372236] Modules linked in: [ 134.372236] CPU: 0 PID: 2289 Comm: mount Not tainted 4.2.0-rc1_HEAD_c65b99f046843d2455aa231747b5a07a999a9f3d_+ #115 [ 134.372236] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [ 134.372236] task: ffff88003b6e1a00 ti: ffff880011e60000 task.ti: ffff880011e60000 [ 134.372236] RIP: 0010:[<ffffffff813a4a51>] [<ffffffff813a4a51>] free_extent_buffer+0x21/0x90 ... [ 134.372236] Call Trace: [ 134.372236] [<ffffffff81379aa1>] free_root_extent_buffers+0x91/0xb0 [ 134.372236] [<ffffffff81379c3d>] free_root_pointers+0x17d/0x190 [ 134.372236] [<ffffffff813801b0>] open_ctree+0x1ca0/0x25b0 [ 134.372236] [<ffffffff8144d017>] ? disk_name+0x97/0xb0 [ 134.372236] [<ffffffff813558aa>] btrfs_mount+0x8fa/0xab0 ... Reason: read_tree_block() changed to return error number on fail, and this value(not NULL) is set to tree_root->node, then subsequent code will run to: free_root_pointers() ->free_root_extent_buffers() ->free_extent_buffer() ->atomic_read((extent_buffer *)(-E_XXX)->refs); and trigger above error. Fix: Set tree_root->node to NULL on fail to make error_handle code happy. Signed-off-by: Zhao Lei <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-07-22btrfs: Fix lockdep warning of btrfs_run_delayed_iputs()Zhao Lei1-1/+2
Liu Bo <[email protected]> reported a lockdep warning of delayed_iput_sem in xfstests generic/241: [ 2061.345955] ============================================= [ 2061.346027] [ INFO: possible recursive locking detected ] [ 2061.346027] 4.1.0+ #268 Tainted: G W [ 2061.346027] --------------------------------------------- [ 2061.346027] btrfs-cleaner/3045 is trying to acquire lock: [ 2061.346027] (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffff814063ab>] btrfs_run_delayed_iputs+0x6b/0x100 [ 2061.346027] but task is already holding lock: [ 2061.346027] (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffff814063ab>] btrfs_run_delayed_iputs+0x6b/0x100 [ 2061.346027] other info that might help us debug this: [ 2061.346027] Possible unsafe locking scenario: [ 2061.346027] CPU0 [ 2061.346027] ---- [ 2061.346027] lock(&fs_info->delayed_iput_sem); [ 2061.346027] lock(&fs_info->delayed_iput_sem); [ 2061.346027] *** DEADLOCK *** It is rarely happened, about 1/400 in my test env. The reason is recursion of btrfs_run_delayed_iputs(): cleaner_kthread -> btrfs_run_delayed_iputs() *1 -> get delayed_iput_sem lock *2 -> iput() -> ... -> btrfs_commit_transaction() -> btrfs_run_delayed_iputs() *1 -> get delayed_iput_sem lock (dead lock) *2 *1: recursion of btrfs_run_delayed_iputs() *2: warning of lockdep about delayed_iput_sem When fs is in high stress, new iputs may added into fs_info->delayed_iputs list when btrfs_run_delayed_iputs() is running, which cause second btrfs_run_delayed_iputs() run into down_read(&fs_info->delayed_iput_sem) again, and cause above lockdep warning. Actually, it will not cause real problem because both locks are read lock, but to avoid lockdep warning, we can do a fix. Fix: Don't do btrfs_run_delayed_iputs() in btrfs_commit_transaction() for cleaner_kthread thread to break above recursion path. cleaner_kthread is calling btrfs_run_delayed_iputs() explicitly in code, and don't need to call btrfs_run_delayed_iputs() again in btrfs_commit_transaction(), it also give us a bonus to avoid stack overflow. Test: No above lockdep warning after patch in 1200 generic/241 tests. Reported-by: Liu Bo <[email protected]> Signed-off-by: Zhao Lei <[email protected]> Reviewed-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-07-23md: Skip cluster setup for dm-raidGoldwyn Rodrigues1-3/+12
There is a bug that the bitmap superblock isn't initialised properly for dm-raid, so a new field can have garbage in new fields. (dm-raid does initialisation in the kernel - md initialised the superblock in mdadm). This means that for dm-raid we cannot currently trust the new ->nodes field. So: - use __GFP_ZERO to initialise the superblock properly for all new arrays - initialise all fields in bitmap_info in bitmap_new_disk_sb - ignore ->nodes for dm arrays (yes, this is a hack) This bug exposes dm-raid to bug in the (still experimental) md-cluster code, so it is suitable for -stable. It does cause crashes. References: https://bugzilla.kernel.org/show_bug.cgi?id=100491 Cc: [email protected] (v4.1) Signed-off-By: Goldwyn Rodrigues <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2015-07-22blkcg: fix gendisk reference leak in blkg_conf_prep()Tejun Heo1-1/+5
When a blkcg configuration is targeted to a partition rather than a whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it forgets to put the gendisk ref in that case. Fix it. Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]>
2015-07-22USB: OHCI: fix bad #define in ohci-tmio.cAlan Stern1-1/+1
An incorrect definition of CCR_PM_USBPW3 in ohci-tmio.c is a perennial source of invalid diagnoses from static scanners, such as in <http://marc.info/?l=linux-usb&m=143634574527641&w=2>. This patch fixes the definition. Signed-off-by: Alan Stern <[email protected]> Reported-by: David Binderman <[email protected]> CC: Dmitry Eremin-Solenikov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22cdc-acm: Destroy acm_minors IDR on module exitJohannes Thumshirn1-0/+1
Destroy acm_minors IDR on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez <[email protected]>) <SmPL> @ defines_module_init @ declarer name module_init, module_exit; declarer name DEFINE_IDR; identifier init; @@ module_init(init); @ defines_module_exit @ identifier exit; @@ module_exit(exit); @ declares_idr depends on defines_module_init && defines_module_exit @ identifier idr; @@ DEFINE_IDR(idr); @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... idr_destroy(&idr); ... } @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... +idr_destroy(&idr); } </SmPL> Signed-off-by: Johannes Thumshirn <[email protected]> Acked-by: Oliver Neukum <[email protected]> Acked-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22usb-storage: Add ignore-device quirk for gm12u320 based usb mini projectorsHans de Goede1-0/+11
Grain-media GM12U320 based devices are mini video projectors using USB for both power and video data transport. Their usb-storage interface is a virtual windows driver CD. The gm12u320 kms driver needs these interfaces to talk to the device and export it as framebuffer & kms dri device nodes, so make sure that the usb-storage driver does not bind to it. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22usb-storage: ignore ZTE MF 823 card reader in mode 0x1225Oliver Neukum1-0/+12
This device automatically switches itself to another mode (0x1405) unless the specific access pattern of Windows is followed in its initial mode. That makes a dirty unmount of the internal storage devices inevitable if they are mounted. So the card reader of such a device should be ignored, lest an unclean removal become inevitable. This replaces an earlier patch that ignored all LUNs of this device. That patch was overly broad. Signed-off-by: Oliver Neukum <[email protected]> CC: [email protected] Reviewed-by: Lars Melin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22USB: OHCI: Fix race between ED unlink and URB submissionAlan Stern1-6/+1
This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies"). The commit changed ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had been called. The user-visible consequence is that the driver occasionally crashes or locks up when an URB is submitted while another URB for the same endpoint is being unlinked. This patch moves the ED state change later, to the right place. The drawback is that now we may unnecessarily execute some instructions multiple times when a controller dies. Since controllers dying is an exceptional occurrence, a little wasted time won't matter. Signed-off-by: Alan Stern <[email protected]> Reported-by: Heiko Przybyl <[email protected]> Tested-by: Heiko Przybyl <[email protected]> Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e CC: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22usb: core: lpm: set lpm_capable for root hub deviceLu Baolu3-3/+7
Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed root hub. The intention of that change was to avoid touching usb core internal field, a.k.a. lpm_capable, and let usb core to set it by checking U1 and U2 exit latency values in the descriptor. Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately, root hub is a special usb device as it has no parent. Hub_port_init() will never be called for a root hub device. That means lpm_capable will by no means be set for the root hub. As the result, lpm isn't functional at all in Linux kernel. This patch add the code to check and set lpm_capable when registering a root hub device. It could be back-ported to kernels as old as v3.15, that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM."). Cc: [email protected] # 3.15 Reported-by: Kevin Strasser <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds79-811/+714
Pull networking fixes from David Miller: 1) Don't use shared bluetooth antenna in iwlwifi driver for management frames, from Emmanuel Grumbach. 2) Fix device ID check in ath9k driver, from Felix Fietkau. 3) Off by one in xen-netback BUG checks, from Dan Carpenter. 4) Fix IFLA_VF_PORT netlink attribute validation, from Daniel Borkmann. 5) Fix races in setting peeked bit flag in SKBs during datagram receive. If it's shared we have to clone it otherwise the value can easily be corrupted. Fix from Herbert Xu. 6) Revert fec clock handling change, causes regressions. From Fabio Estevam. 7) Fix use after free in fq_codel and sfq packet schedulers, from WANG Cong. 8) ipvlan bug fixes (memory leaks, missing rcu_dereference_bh, etc.) from WANG Cong and Konstantin Khlebnikov. 9) Memory leak in act_bpf packet action, from Alexei Starovoitov. 10) ARM bpf JIT bug fixes from Nicolas Schichan. 11) Fix backwards compat of ANY_LAYOUT in virtio_net driver, from Michael S Tsirkin. 12) Destruction of bond with different ARP header types not handled correctly, fix from Nikolay Aleksandrov. 13) Revert GRO receive support in ipv6 SIT tunnel driver, causes regressions because the GRO packets created cannot be processed properly on the GSO side if we forward the frame. From Herbert Xu. 14) TCCR update race and other fixes to ravb driver from Sergei Shtylyov. 15) Fix SKB leaks in caif_queue_rcv_skb(), from Eric Dumazet. 16) Fix panics on packet scheduler filter replace, from Daniel Borkmann. 17) Make sure AF_PACKET sees properly IP headers in defragmented frames (via PACKET_FANOUT_FLAG_DEFRAG option), from Edward Hyunkoo Jee. 18) AF_NETLINK cannot hold mutex in RCU callback, fix from Florian Westphal. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (84 commits) ravb: fix ring memory allocation net: phy: dp83867: Fix warning check for setting the internal delay openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodes netlink: don't hold mutex in rcu callback when releasing mmapd ring ARM: net: fix vlan access instructions in ARM JIT. ARM: net: handle negative offsets in BPF JIT. ARM: net: fix condition for load_order > 0 when translating load instructions. tcp: suppress a division by zero warning drivers: net: cpsw: remove tx event processing in rx napi poll inet: frags: fix defragmented packet's IP header for af_packet net: mvneta: fix refilling for Rx DMA buffers stmmac: fix setting of driver data in stmmac_dvr_probe sched: cls_flow: fix panic on filter replace sched: cls_flower: fix panic on filter replace sched: cls_bpf: fix panic on filter replace net/mdio: fix mdio_bus_match for c45 PHY net: ratelimit warnings about dst entry refcount underflow or overflow caif: fix leaks and race in caif_queue_rcv_skb() qmi_wwan: add the second QMI/network interface for Sierra Wireless MC7305/MC7355 ravb: fix race updating TCCR ...
2015-07-22Merge tag 'phy-for-4.2-rc' of ↵Greg Kroah-Hartman3-133/+45
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus Kishon writes: phy: for 4.2-rc *) Fix PIPE3 PM so that all its users (PCIe, SATA, USB) can idle and resume *) Fix a compiler error in pxa *) Fix pll divider values in berlin-usb phy driver Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2015-07-22xhci: do not report PLC when link is in internal resume stateZhuang Jin Can1-1/+8
Port link change with port in resume state should not be reported to usbcore, as this is an internal state to be handled by xhci driver. Reporting PLC to usbcore may cause usbcore clearing PLC first and port change event irq won't be generated. Cc: <[email protected]> Signed-off-by: Zhuang Jin Can <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22xhci: prevent bus_suspend if SS port resuming in phase 1Zhuang Jin Can3-3/+7
When the link is just waken, it's in Resume state, and driver sets PLS to U0. This refers to Phase 1. Phase 2 refers to when the link has completed the transition from Resume state to U0. With the fix of xhci: report U3 when link is in resume state, it also exposes an issue that usb3 roothub and controller can suspend right after phase 1, and this causes a hard hang in controller. To fix the issue, we need to prevent usb3 bus suspend if any port is resuming in phase 1. [merge separate USB2 and USB3 port resume checking to one -Mathias] Cc: <[email protected]> Signed-off-by: Zhuang Jin Can <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22xhci: report U3 when link is in resume stateZhuang Jin Can1-2/+5
xhci_hub_report_usb3_link_state() returns pls as U0 when the link is in resume state, and this causes usb core to think the link is in U0 while actually it's in resume state. When usb core transfers control request on the link, it fails with TRB error as the link is not ready for transfer. To fix the issue, report U3 when the link is in resume state, thus usb core knows the link it's not ready for transfer. Cc: <[email protected]> Signed-off-by: Zhuang Jin Can <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22xhci: Calculate old endpoints correctly on device resetBrian Campbell1-0/+3
When resetting a device the number of active TTs may need to be corrected by xhci_update_tt_active_eps, but the number of old active endpoints supplied to it was always zero, so the number of TTs and the bandwidth reserved for them was not updated, and could rise unnecessarily. This affected systems using Intel's Patherpoint chipset, which rely on software bandwidth checking. For example, a Lenovo X230 would lose the ability to use ports on the docking station after enough suspend/resume cycles because the bandwidth calculated would rise with every cycle when a suitable device is attached. The correct number of active endpoints is calculated in the same way as in xhci_reserve_bandwidth. Cc: <[email protected]> Signed-off-by: Brian Campbell <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() functionAMAN DEEP1-1/+1
virt_dev->num_cached_rings counts on freed ring and is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring is added into cache and then num_rings_cache is incremented as below: virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; virt_dev->num_rings_cached++; here, free ring pointer is added to a current index and then index is incremented. So current index always points to empty location in the ring cache. For getting available free ring, current index should be decremented first and then corresponding ring buffer value should be taken from ring cache. But In function xhci_endpoint_init(), the num_rings_cached index is accessed before decrement. virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; virt_dev->num_rings_cached--; This is bug in manipulating the index of ring cache. And it should be as below: virt_dev->num_rings_cached--; virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; Cc: <[email protected]> Signed-off-by: Aman Deep <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22xhci: Workaround to get D3 working in Intel xHCIRajmohan Mani1-3/+37
The xHCI in Intel CherryView / Braswell Platform requires a driver workaround to get xHCI D3 working. Without this workaround, xHCI might not enter D3. Workaround is to configure SSIC PORT as "unused" before D3 entry and "used" after D3 exit. This is done through a vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset 0x883c), in xhci suspend / resume callbacks. Verified xHCI D3 works fine in CherryView / Braswell platform. Signed-off-by: Rajmohan Mani <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22xhci: call BIOS workaround to enable runtime suspend on Intel BraswellMathias Nyman1-0/+17
Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled xhci from going to D3 state in runtime suspend. Driver needs to verify it can deal with the hw by calling an ACPI _DSM method to get D3 enabled. Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-22NFS: nfs_mark_for_revalidate should always set NFS_INO_REVAL_PAGECACHETrond Myklebust1-2/+5
I'm not aware of any existing bugs around this, but the expectation is that nfs_mark_for_revalidate() should always force a revalidation of the cached metadata. Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22NFS: Remove the "NFS_CAP_CHANGE_ATTR" capabilityTrond Myklebust4-7/+4
Setting the change attribute has been mandatory for all NFS versions, since commit 3a1556e8662c ("NFSv2/v3: Simulate the change attribute"). We should therefore not have anything be conditional on it being set/unset. Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22NFS: Set NFS_INO_REVAL_PAGECACHE if the change attribute is uninitialisedTrond Myklebust1-1/+2
We can't allow caching of data until the change attribute has been initialised correctly. Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22NFS: Don't revalidate the mapping if both size and change attr are up to dateTrond Myklebust1-4/+4
If we've ensured that the size and the change attribute are both correct, then there is no point in marking those attributes as needing revalidation again. Only do so if we know the size is incorrect and was not updated. Fixes: f2467b6f64da ("NFS: Clear NFS_INO_REVAL_PAGECACHE when...") Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22NFSv4/pnfs: Ensure we don't miss a file extensionTrond Myklebust1-6/+9
pNFS writes don't return attributes, however that doesn't mean that we should ignore the fact that they may be extending the file. This patch ensures that if a write is seen to extend the file, then we always set an attribute barrier, and update the cached file size. Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22NFSv4: We must set NFS_OPEN_STATE flag in nfs_resync_open_stateid_lockedTrond Myklebust1-0/+3
Otherwise, nfs4_select_rw_stateid() will always return the zero stateid instead of the correct open stateid. Fixes: f95549cf24660 ("NFSv4: More CLOSE/OPEN races") Cc: [email protected] # 4.0+ Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22SUNRPC: xprt_complete_bc_request must also decrement the free slot countTrond Myklebust1-1/+1
Calling xprt_complete_bc_request() effectively causes the slot to be allocated, so it needs to decrement the backchannel free slot count as well. Fixes: 0d2a970d0ae5 ("SUNRPC: Fix a backchannel race") Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22SUNRPC: Fix a backchannel deadlockTrond Myklebust1-2/+2
xprt_alloc_bc_request() cannot call xprt_free_bc_request() without deadlocking, since it already holds the xprt->bc_pa_lock. Reported-by: Chuck Lever <[email protected]> Fixes: 0d2a970d0ae55 ("SUNRPC: Fix a backchannel race") Signed-off-by: Trond Myklebust <[email protected]>
2015-07-22null_blk: fix use-after-free problemMike Krinkin1-9/+9
end_cmd finishes request associated with nullb_cmd struct, so we should save pointer to request_queue in a local variable before calling end_cmd. The problem was causes general protection fault with slab poisoning enabled. Fixes: 8b70f45e2eb2 ("null_blk: restart request processing on completion handler") Tested-by: Akinobu Mita <[email protected]> Signed-off-by: Mike Krinkin <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-07-22Merge tag 'fixes-for-v4.2-rc4' of ↵Greg Kroah-Hartman4-8/+14
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: usb: fixes for v4.2-rc4 Only four fixes this time so I'll describe them all. We have an iomen resource leak fix in mv_udc_core. This bug exists since v3.3. Renesas got a fix for how they use dma_map_single() with IOMMU. The new ulpi bus got an ordering fix, so drivers don't try to probe ahead of the bus. And finally, we have a fix for a really old regression with dwc3, one which could only be exposed by a recent patch from Subbaraya. Basically, we were startving the controller of transfer resources. Signed-off-by: Felipe Balbi <[email protected]>
2015-07-22Merge tag 'arm64-fixes' of ↵Linus Torvalds2-4/+5
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull ARM64 fixes from Catalin Marinas: - arm64 build fix following the move of the thread_struct to the end of task_struct and the asm offsets becoming too large for the AArch64 ISA - preparatory patch for moving irq_data struct members (applied now to reduce dependency for the next merging window) * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: ARM64/irq: Use access helper irq_data_get_affinity_mask() arm64: switch_to: calculate cpu context pointer using separate register
2015-07-22mm: Fix bugs in region_is_ram()Toshi Kani1-3/+3
region_is_ram() looks up the iomem_resource table to check if a target range is in RAM. However, it always returns with -1 due to invalid range checks. It always breaks the loop at the first entry of the table. Another issue is that it compares p->flags and flags, but it always fails. flags is declared as int, which makes it as a negative value with IORESOURCE_BUSY (0x80000000) set while p->flags is unsigned long. Fix the range check and flags so that region_is_ram() works as advertised. Signed-off-by: Toshi Kani <[email protected]> Reviewed-by: Dan Williams <[email protected]> Cc: Mike Travis <[email protected]> Cc: Luis R. Rodriguez <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Roland Dreier <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2015-07-22x86/mm: Remove region_is_ram() call from ioremapToshi Kani1-18/+6
__ioremap_caller() calls region_is_ram() to walk through the iomem_resource table to check if a target range is in RAM, which was added to improve the lookup performance over page_is_ram() (commit 906e36c5c717 "x86: use optimized ioresource lookup in ioremap function"). page_is_ram() was no longer used when this change was added, though. __ioremap_caller() then calls walk_system_ram_range(), which had replaced page_is_ram() to improve the lookup performance (commit c81c8a1eeede "x86, ioremap: Speed up check for RAM pages"). Since both checks walk through the same iomem_resource table for the same purpose, there is no need to call both functions. Aside of that walk_system_ram_range() is the only useful check at the moment because region_is_ram() always returns -1 due to an implementation bug. That bug in region_is_ram() cannot be fixed without breaking existing ioremap callers, which rely on the subtle difference of walk_system_ram_range() versus non page aligned ranges. Once these offending callers are fixed we can use region_is_ram() and remove walk_system_ram_range(). [ tglx: Massaged changelog ] Signed-off-by: Toshi Kani <[email protected]> Reviewed-by: Dan Williams <[email protected]> Cc: Roland Dreier <[email protected]> Cc: Mike Travis <[email protected]> Cc: Luis R. Rodriguez <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2015-07-22x86/mm: Move warning from __ioremap_check_ram() to the call siteToshi Kani1-3/+4
__ioremap_check_ram() has a WARN_ONCE() which is emitted when the given pfn range is not RAM. The warning is bogus in two aspects: - it never triggers since walk_system_ram_range() only calls __ioremap_check_ram() for RAM ranges. - the warning message is wrong as it says: "ioremap on RAM' after it established that the pfn range is not RAM. Move the WARN_ONCE() to __ioremap_caller(), and update the message to include the address range so we get an actual warning when something tries to ioremap system RAM. [ tglx: Massaged changelog ] Signed-off-by: Toshi Kani <[email protected]> Reviewed-by: Dan Williams <[email protected]> Cc: Roland Dreier <[email protected]> Cc: Luis R. Rodriguez <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2015-07-22usb: dwc3: Reset the transfer resource index on SET_INTERFACEJohn Youn1-0/+4
This fixes an issue introduced in commit b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would only use DEPSTARTCFG once per SetConfig. The trick is that we should use one DEPSTARTCFG per SetConfig *OR* SetInterface. SetInterface was completely missed from the original patch. This problem became aparent after commit 76e838c9f776 (usb: dwc3: gadget: return error if command sent to DEPCMD register fails) added checking of the return status of device endpoint commands. 'Set Endpoint Transfer Resource' command was caught failing occasionally. This is because the Transfer Resource Index was not getting reset during a SET_INTERFACE request. Finally, to fix the issue, was we have to do is make sure that our start_config_issued flag gets reset whenever we receive a SetInterface request. To verify the problem (and its fix), all we have to do is run test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'. Tested-by: Huang Rui <[email protected]> Tested-by: Subbaraya Sundeep Bhatta <[email protected]> Fixes: b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) Cc: <[email protected]> # v3.2+ Signed-off-by: John Youn <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2015-07-22drm: Stop resetting connector state to unknownDaniel Vetter1-4/+1
It's causing piles of issues since we've stopped forcing full detect cycles in the sysfs interfaces with commit c484f02d0f02fbbfc6decc945a69aae011041a27 Author: Chris Wilson <[email protected]> Date: Fri Mar 6 12:36:42 2015 +0000 drm: Lighten sysfs connector 'status' The original justification for this was that the hpd handlers could use the unknown state as a hint to force a full detection. But current i915 code isn't doing that any more, and no one else really uses reset on resume. So instead just keep the old state around. References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641 Cc: Rui Matos <[email protected]> Cc: Julien Wajsberg <[email protected]> Cc: [email protected] Cc: Lennart Poettering <[email protected]> Cc: [email protected] Acked-by: Rob Clark <[email protected]> Tested-by: Rui Tiago Cação Matos <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-22ARM64/irq: Use access helper irq_data_get_affinity_mask()Jiang Liu1-2/+2
This is a preparatory patch for moving irq_data struct members. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> Cc: [email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2015-07-22arm64: switch_to: calculate cpu context pointer using separate registerWill Deacon1-2/+3
Commit 0c8c0f03e3a2 ("x86/fpu, sched: Dynamically allocate 'struct fpu'") moved the thread_struct to the bottom of task_struct. As a result, the offset is now too large to be used in an immediate add on arm64 with some kernel configs: arch/arm64/kernel/entry.S: Assembler messages: arch/arm64/kernel/entry.S:588: Error: immediate out of range arch/arm64/kernel/entry.S:597: Error: immediate out of range This patch calculates the offset using an additional register instead of an immediate offset. Fixes: 0c8c0f03e3a2 ("x86/fpu, sched: Dynamically allocate 'struct fpu'") Cc: Dave Hansen <[email protected]> Cc: Olof Johansson <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Will Deacon <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2015-07-22ASoC: ssm4567: Keep TDM_BCLKS in ssm4567_set_dai_fmtBen Zhang1-1/+7
The regmap_write in ssm4567_set_dai_fmt accidentally clears the TDM_BCLKS field which was set earlier by ssm4567_set_tdm_slot. This patch fixes it by using regmap_update_bits with proper mask. Signed-off-by: Ben Zhang <[email protected]> Acked-by: Lars-Peter Clausen <[email protected]> Acked-by: Anatol Pomozov <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected]
2015-07-22ASoC: sgtl5000: Fix up define for SGTL5000_SMALL_POPAxel Lin1-1/+1
Currently, below code actually does not update any bit because SGTL5000_SMALL_POP is 0. snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, SGTL5000_SMALL_POP, 1); The SGTL5000_SMALL_POP should be BIT(0) rather than 0, fix it. Signed-off-by: Axel Lin <[email protected]> Acked-By: Alexander Stein <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-07-22ALSA: hda - Add headset mic pin quirk for a Dell deviceDavid Henningsson1-0/+11
Without this patch, the headset mic will not work on this machine. BugLink: https://bugs.launchpad.net/bugs/1476987 Signed-off-by: David Henningsson <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-07-22ALSA: hda - remove one pin from ALC292_STANDARD_PINSHui Wang1-7/+19
One more Dell laptop with alc293 codec needs ALC293_FIXUP_DELL1_MIC_NO_PRESENCE, but the pin 0x1e does not match the corresponding one in the ALC292_STANDARD_PINS. To use this macro for this machine, we need to remove pin 0x1e from it. BugLink: https://bugs.launchpad.net/bugs/1476888 Cc: <[email protected]> Signed-off-by: Hui Wang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-07-21ravb: fix ring memory allocationSergei Shtylyov1-25/+34
The driver is written as if it can adapt to a low memory situation allocating less RX skbs and TX aligned buffers than the respective RX/TX ring sizes. In reality though the driver would malfunction in this case. Stop being overly smart and just fail in such situation -- this is achieved by moving the memory allocation from ravb_ring_format() to ravb_ring_init(). We leave dma_map_single() calls in place but make their failure non-fatal by marking the corresponding RX descriptors with zero data size which should prevent DMA to an invalid addresses. Signed-off-by: Sergei Shtylyov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-07-21net: phy: dp83867: Fix warning check for setting the internal delayDan Murphy1-1/+1
Fix warning: logical ‘or’ of collectively exhaustive tests is always true Change the internal delay check from an 'or' condition to an 'and' condition. Reported-by: David Binderman <[email protected]> Signed-off-by: Dan Murphy <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-07-21openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodesChris J Arges1-1/+1
Some architectures like POWER can have a NUMA node_possible_map that contains sparse entries. This causes memory corruption with openvswitch since it allocates flow_cache with a multiple of num_possible_nodes() and assumes the node variable returned by for_each_node will index into flow->stats[node]. Use nr_node_ids to allocate a maximal sparse array instead of num_possible_nodes(). The crash was noticed after 3af229f2 was applied as it changed the node_possible_map to match node_online_map on boot. Fixes: 3af229f2071f5b5cb31664be6109561fbe19c861 Signed-off-by: Chris J Arges <[email protected]> Acked-by: Pravin B Shelar <[email protected]> Acked-by: Nishanth Aravamudan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.