summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-09-21net: moxa: Fix module autoload for OF platform driverLuis de Bethencourt
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-21net: gianfar_ptp: Fix module autoload for OF platform driverLuis de Bethencourt
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-21net: bcmgenet: Fix module autoload for OF platform driverLuis de Bethencourt
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt <luis@osg.samsung.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-21net: systemport: Fix module autoload for OF platform driverLuis de Bethencourt
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-21net: arc: Fix module autoload for OF platform driverLuis de Bethencourt
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-21Merge remote-tracking branches 'regulator/fix/anatop', 'regulator/fix/gpio', ↵Mark Brown
'regulator/fix/pbias', 'regulator/fix/tpx65218' and 'regulator/fix/vexpress' into regulator-linus
2015-09-21Merge remote-tracking branch 'regulator/fix/core' into regulator-linusMark Brown
2015-09-21Btrfs: Direct I/O: Fix space accountingchandan
The following call trace is seen when generic/095 test is executed, WARNING: CPU: 3 PID: 2769 at /home/chandan/code/repos/linux/fs/btrfs/inode.c:8967 btrfs_destroy_inode+0x284/0x2a0() Modules linked in: CPU: 3 PID: 2769 Comm: umount Not tainted 4.2.0-rc5+ #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20150306_163512-brownie 04/01/2014 ffffffff81c08150 ffff8802ec9cbce8 ffffffff81984058 ffff8802ffd8feb0 0000000000000000 ffff8802ec9cbd28 ffffffff81050385 ffff8802ec9cbd38 ffff8802d12f8588 ffff8802d12f8588 ffff8802f15ab000 ffff8800bb96c0b0 Call Trace: [<ffffffff81984058>] dump_stack+0x45/0x57 [<ffffffff81050385>] warn_slowpath_common+0x85/0xc0 [<ffffffff81050465>] warn_slowpath_null+0x15/0x20 [<ffffffff81340294>] btrfs_destroy_inode+0x284/0x2a0 [<ffffffff8117ce07>] destroy_inode+0x37/0x60 [<ffffffff8117cf39>] evict+0x109/0x170 [<ffffffff8117cfd5>] dispose_list+0x35/0x50 [<ffffffff8117dd3a>] evict_inodes+0xaa/0x100 [<ffffffff81165667>] generic_shutdown_super+0x47/0xf0 [<ffffffff81165951>] kill_anon_super+0x11/0x20 [<ffffffff81302093>] btrfs_kill_super+0x13/0x110 [<ffffffff81165c99>] deactivate_locked_super+0x39/0x70 [<ffffffff811660cf>] deactivate_super+0x5f/0x70 [<ffffffff81180e1e>] cleanup_mnt+0x3e/0x90 [<ffffffff81180ebd>] __cleanup_mnt+0xd/0x10 [<ffffffff81069c06>] task_work_run+0x96/0xb0 [<ffffffff81003a3d>] do_notify_resume+0x3d/0x50 [<ffffffff8198cbc2>] int_signal+0x12/0x17 This means that the inode had non-zero "outstanding extents" during eviction. This occurs because, during direct I/O a task which successfully used up its reserved data space would set BTRFS_INODE_DIO_READY bit and does not clear the bit after finishing the DIO write. A future DIO write could actually fail and the unused reserve space won't be freed because of the previously set BTRFS_INODE_DIO_READY bit. Clearing the BTRFS_INODE_DIO_READY bit in btrfs_direct_IO() caused the following issue, |-----------------------------------+-------------------------------------| | Task A | Task B | |-----------------------------------+-------------------------------------| | Start direct i/o write on inode X.| | | reserve space | | | Allocate ordered extent | | | release reserved space | | | Set BTRFS_INODE_DIO_READY bit. | | | | splice() | | | Transfer data from pipe buffer to | | | destination file. | | | - kmap(pipe buffer page) | | | - Start direct i/o write on | | | inode X. | | | - reserve space | | | - dio_refill_pages() | | | - sdio->blocks_available == 0 | | | - Since a kernel address is | | | being passed instead of a | | | user space address, | | | iov_iter_get_pages() returns | | | -EFAULT. | | | - Since BTRFS_INODE_DIO_READY is | | | set, we don't release reserved | | | space. | | | - Clear BTRFS_INODE_DIO_READY bit.| | -EIOCBQUEUED is returned. | | |-----------------------------------+-------------------------------------| Hence this commit introduces "struct btrfs_dio_data" to track the usage of reserved data space. The remaining unused "reserve space" can now be freed reliably. Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com> Reviewed-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Chris Mason <clm@fb.com>
2015-09-21usb: dwc3: gadget: Fix BUG in RT configRoger Quadros
Using spin_lock() in hard irq handler is pointless and causes a BUG() in RT (real-time) configuration so get rid of it. The reason it's pointless is because the driver is basically accessing register which is, anyways, atomic. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: musb: fix cppi channel teardown for isoch transferBin Liu
After a few iterations of start/stop UVC camera streaming, the streaming stops. This patch adds 250us delay in the cppi channel abort path to let cppi drain properly. Using 50us delay seems to be too aggressive, some webcams are still broken. 250us is the original value used in TI 3.2 kernel. Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: phy: isp1301: Export I2C module alias informationJavier Martinez Canillas
The I2C core always reports the MODALIAS uevent as "i2c:<client name" regardless if the device was registered using OF or platform code so So the driver needs to export the I2C table and this be built into the module or udev won't have the necessary information to auto load the module when the device is added. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: gadget: drop null test before destroy functionsJulia Lawall
Remove unneeded NULL test. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x; @@ -if (x != NULL) \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: gadget: dummy_hcd: in transfer(), return data sent, not limitIgor Kotrasinski
dummy_timer uses transfer() to update transfer limit. However, limit passed to dummy_timer changes depending on transfer type, so the actual limit is overwritten. This can cause unpredictably slow / fast bulk transfers when coupled with control / interrupt transfers. Fix by returning actual amount of data sent in transfer() and substracting from total. Signed-off-by: Igor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: gadget: dummy_hcd: fix rescan logic for transferIgor Kotrasinski
transfer() schedules a rescan for transfers larger than maxpacket, which is wrong for transfers that are multiples of maxpacket. Rewrite to fix and clarify packet multiple / remainder transfer logic. Signed-off-by: Igor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: gadget: dummy_hcd: fix unneeded else-if conditionIgor Kotrasinski
We already know at this point that to_host is false. Signed-off-by: Igor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: gadget: dummy_hcd: emulate sending zlp in packet logicIgor Kotrasinski
currently, when a zlp flag is set and an urb/usb_request buffer is filled without a short packet, transfer() leaves its status at -EINPROGRESS and does not rescan for short packet. In a scenario where ep.maxpacket bytes are copied, URB_ZERO_PACKET is set, urb buffer is filled and usb_request buffer is not, transfer() returns with an urb with -EINPROGRESS status, which dummy_hcd treats as incomplete transfer. Check for zlp and rescan appropriately. Signed-off-by: Igor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: musb: dsps: fix polling in device-only modeBin Liu
Fix the regression caused by commit ad78c918602 ("usb: musb: dsps: just start polling already") which causes polling the ID pin status even in device-only mode. Fixes: ad78c918602c ("usb: musb: dsps: just start polling already") Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21usb: gadget: atmel_usba_udc: add ep capabilities support on device tree bindingSylvain Rochet
The recently added endpoint capabilities flags verification breaks Atmel USBA because the endpoint configuration was only added when the driver is bound using the legacy pdata interface. Convert endpoint configuration to new capabilities model when driver is bound to a device tree as well. Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com> Fixes: 47bef3865115 ("usb: gadget: atmel_usba_udc: add ep capabilities support") Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21Merge tag 'renesas-sh-drivers-for-v4.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas Pull SH drivers updates from Simon Horman: "I am sending this change after v4.3-rc1 has been released as it depends on SoC changes which are present in that rc release. Summary: - disable PM runtime for multi-platform ARM with genpd - disable legacy default PM Domain on emev2" * tag 'renesas-sh-drivers-for-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: drivers: sh: Disable PM runtime for multi-platform ARM with genpd drivers: sh: Disable legacy default PM Domain on emev2
2015-09-21Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "A couple of system call updates. The two new system calls userfaultfd and membarrier have been added, as well as the 17 direct calls for the multiplexed socket system calls. In addition the system call compat wrappers have been flagged as notrace functions and a few wrappers could be removed. And bug fixes for the vector register handling, cpu_mf, suspend/resume, compat signals, SMT cputime accounting and the zfcp dumper" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: wire up separate socketcalls system calls s390/compat: remove superfluous compat wrappers s390/compat: do not trace compat wrapper functions s390/s390x: allocate sys_membarrier system call number s390/configs//zfcpdump_defconfig: Remove CONFIG_MEMSTICK s390: wire up userfaultfd system call s390/vtime: correct scaled cputime for SMT s390/cpum_cf: Corrected return code for unauthorized counter sets s390/compat: correct uc_sigmask of the compat signal frame s390: fix floating point register corruption s390/hibernate: fix save and restore of vector registers
2015-09-21hwrng: xgene - fix handling platform_get_irqAndrzej Hajda
The function can return negative value. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-09-21crypto: qat - VF should never trigger SBR on PHConor McLoughlin
Don't allow to trigger SBR from a VF running in VMM context. Cc: stable@vger.kernel.org Signed-off-by: Conor McLoughlin <conor.mcloughlin@intel.com> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-09-21crypto: marvell - properly handle CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requestsThomas Petazzoni
The mv_cesa_queue_req() function calls crypto_enqueue_request() to enqueue a request. In the normal case (i.e the queue isn't full), this function returns -EINPROGRESS. The current Marvell CESA crypto driver takes this into account and cleans up the request only if an error occured, i.e if the return value is not -EINPROGRESS. Unfortunately this causes problems with CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests. When such a request is passed to crypto_enqueue_request() and the queue is full, crypto_enqueue_request() will return -EBUSY, but will keep the request enqueued nonetheless. This situation was not properly handled by the Marvell CESA driver, which was anyway cleaning up the request in such a situation. When later on the request was taken out of the backlog and actually processed, a kernel crash occured due to the internal driver data structures for this structure having been cleaned up. To avoid this situation, this commit adds a mv_cesa_req_needs_cleanup() helper function which indicates if the request needs to be cleaned up or not after a call to crypto_enqueue_request(). This helper allows to do the cleanup only in the appropriate cases, and all call sites of mv_cesa_queue_req() are fixed to use this new helper function. Reported-by: Vincent Donnefort <vdonnefort@gmail.com> Fixes: db509a45339fd ("crypto: marvell/cesa - add TDMA support") Cc: <stable@vger.kernel.org> # v4.2+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Tested-by: Vincent Donnefort <vdonnefort@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-09-21powerpc: Wire up sys_membarrier()Michael Ellerman
The selftest passes on 64-bit LE & BE, and 32-bit. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-09-21drm/i915: fix kernel-doc warnings in intel_audio.cGeliang Tang
Fix the following 'make htmldocs' warnings: .//drivers/gpu/drm/i915/intel_audio.c:439: warning: No description found for parameter 'intel_encoder' .//drivers/gpu/drm/i915/intel_audio.c:439: warning: Excess function parameter 'encoder' description in 'intel_audio_codec_disable' .//drivers/gpu/drm/i915/intel_audio.c:439: warning: No description found for parameter 'intel_encoder' .//drivers/gpu/drm/i915/intel_audio.c:439: warning: Excess function parameter 'encoder' description in 'intel_audio_codec_disable' Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-21extcon: Fix attached value returned by is_extcon_changedHans de Goede
is_extcon_changed should only check the idx-th bit of new, not the entirety of new when setting attached. This fixes extcon sending notifications that a cable was inserted when it gets removed while another cable is still connected. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2015-09-20netlink: Fix autobind race condition that leads to zero port IDHerbert Xu
The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink: Reset portid after netlink_insert failure") introduced a race condition where if two threads try to autobind the same socket one of them may end up with a zero port ID. This led to kernel deadlocks that were observed by multiple people. This patch reverts that commit and instead fixes it by introducing a separte rhash_portid variable so that the real portid is only set after the socket has been successfully hashed. Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure") Reported-by: Tejun Heo <tj@kernel.org> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20Drivers: hv: vmbus: fix init_vp_index() for reloading hv_netvscDexuan Cui
This fixes the recent commit 3b71107d73b16074afa7658f3f0fcf837aabfe24: Drivers: hv: vmbus: Further improve CPU affiliation logic Without the fix, reloading hv_netvsc hangs the guest. Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-20mei: fix debugfs files leak on error pathTomas Winkler
if dbgfs_dir is not set then debugfs_remove_recursive is not called on the error path Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-20macvtap: fix TUNSETSNDBUF values > 64kMichael S. Tsirkin
Upon TUNSETSNDBUF, macvtap reads the requested sndbuf size into a local variable u. commit 39ec7de7092b ("macvtap: fix uninitialized access on TUNSETIFF") changed its type to u16 (which is the right thing to do for all other macvtap ioctls), breaking all values > 64k. The value of TUNSETSNDBUF is actually a signed 32 bit integer, so the right thing to do is to read it into an int. Cc: David S. Miller <davem@davemloft.net> Fixes: 39ec7de7092b ("macvtap: fix uninitialized access on TUNSETIFF") Reported-by: Mark A. Peloquin Bisected-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-21KVM: x86: trap AMD MSRs for the TSeg base and maskPaolo Bonzini
These have roughly the same purpose as the SMRR, which we do not need to implement in KVM. However, Linux accesses MSR_K8_TSEG_ADDR at boot, which causes problems when running a Xen dom0 under KVM. Just return 0, meaning that processor protection of SMRAM is not in effect. Reported-by: M A Young <m.a.young@durham.ac.uk> Cc: stable@vger.kernel.org Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-09-20ip6tunnel: make rx/tx bytes counters consistentNicolas Dichtel
Like the previous patch, which fixes ipv4 tunnels, here is the ipv6 part. Before the patch, the external ipv6 header + gre header were included on tx. After the patch: $ ping -c1 192.168.6.121 ; ip -s l ls dev ip6gre1 PING 192.168.6.121 (192.168.6.121) 56(84) bytes of data. 64 bytes from 192.168.6.121: icmp_req=1 ttl=64 time=1.92 ms --- 192.168.6.121 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.923/1.923/1.923/0.000 ms 7: ip6gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN mode DEFAULT group default link/gre6 20:01:06:60:30:08:c1:c3:00:00:00:00:00:00:01:23 peer 20:01:06:60:30:08:c1:c3:00:00:00:00:00:00:01:21 RX: bytes packets errors dropped overrun mcast 84 1 0 0 0 0 TX: bytes packets errors dropped carrier collsns 84 1 0 0 0 0 $ ping -c1 192.168.1.121 ; ip -s l ls dev ip6tnl1 PING 192.168.1.121 (192.168.1.121) 56(84) bytes of data. 64 bytes from 192.168.1.121: icmp_req=1 ttl=64 time=2.28 ms --- 192.168.1.121 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.288/2.288/2.288/0.000 ms 8: ip6tnl1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN mode DEFAULT group default link/tunnel6 2001:660:3008:c1c3::123 peer 2001:660:3008:c1c3::121 RX: bytes packets errors dropped overrun mcast 84 1 0 0 0 0 TX: bytes packets errors dropped carrier collsns 84 1 0 0 0 0 Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20iptunnel: make rx/tx bytes counters consistentNicolas Dichtel
This was already done a long time ago in commit 64194c31a0b6 ("inet: Make tunnel RX/TX byte counters more consistent") but tx path was broken (at least since 3.10). Before the patch the gre header was included on tx. After the patch: $ ping -c1 192.168.0.121 ; ip -s l ls dev gre1 PING 192.168.0.121 (192.168.0.121) 56(84) bytes of data. 64 bytes from 192.168.0.121: icmp_req=1 ttl=64 time=2.95 ms --- 192.168.0.121 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.955/2.955/2.955/0.000 ms 7: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1468 qdisc noqueue state UNKNOWN mode DEFAULT group default link/gre 10.16.0.249 peer 10.16.0.121 RX: bytes packets errors dropped overrun mcast 84 1 0 0 0 0 TX: bytes packets errors dropped carrier collsns 84 1 0 0 0 0 Reported-by: Julien Meunier <julien.meunier@6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patch contains Netfilter fixes for your net tree, they are: 1) nf_log_unregister() should only set to NULL the logger that is being unregistered, instead of everything else. Patch from Florian Westphal. 2) Fix a crash when accessing physoutdev from PREROUTING in br_netfilter. This is partially reverting the patch to shrink nf_bridge_info to 32 bytes. Also from Florian. 3) Use existing match/target extensions in the internal nft_compat extension lists when the extension is family unspecific (ie. NFPROTO_UNSPEC). 4) Wait for rcu grace period before leaving nf_log_unregister(). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20tipc: reinitialize pointer after skb linearizeErik Hugne
The msg pointer into header may change after skb linearization. We must reinitialize it after calling skb_linearize to prevent operating on a freed or invalid pointer. Signed-off-by: Erik Hugne <erik.hugne@ericsson.com> Reported-by: Tamás Végh <tamas.vegh@ericsson.com> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20Revert "net/phy: Add Vitesse 8641 phy ID"Kevin Hao
This reverts commit 1298267b548a78840bd4b3e030993ff8747ca5e6. That commit claim that the Vitesse VSC8641 is compatible with Vitesse 82xx. But this is not true. It seems that all the registers used in Vitesse phy driver are not compatible between 8641 and 82xx. It does cause malfunction of the Ethernet on p1010rdb-pa board. So we definitely need a rework in order to support the 8641 phy in this driver. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-208139cp: Call __cp_set_rx_mode() from cp_tx_timeout()David Woodhouse
Unless we reset the RX config, on real hardware I don't seem to receive any packets after a TX timeout. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-208139cp: Use dev_kfree_skb_any() instead of dev_kfree_skb() in cp_clean_rings()David Woodhouse
This can be called from cp_tx_timeout() with interrupts disabled. Spotted by Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20net: Fix behaviour of unreachable, blackhole and prohibit routesNikola Forró
Man page of ip-route(8) says following about route types: unreachable - these destinations are unreachable. Packets are dis‐ carded and the ICMP message host unreachable is generated. The local senders get an EHOSTUNREACH error. blackhole - these destinations are unreachable. Packets are dis‐ carded silently. The local senders get an EINVAL error. prohibit - these destinations are unreachable. Packets are discarded and the ICMP message communication administratively prohibited is generated. The local senders get an EACCES error. In the inet6 address family, this was correct, except the local senders got ENETUNREACH error instead of EHOSTUNREACH in case of unreachable route. In the inet address family, all three route types generated ICMP message net unreachable, and the local senders got ENETUNREACH error. In both address families all three route types now behave consistently with documentation. Signed-off-by: Nikola Forró <nforro@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20bna: check for dma mapping errorsIvan Vecera
Check for DMA mapping errors, recover from them and register them in ethtool stats like other errors. Cc: Rasesh Mody <rasesh.mody@qlogic.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Rasesh Mody <rasesh.mody@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-20NFSv4.x/pnfs: Don't try to recover stateids twice in layoutgetTrond Myklebust
If the current open or layout stateid doesn't match the stateid used in the layoutget RPC call, then don't try to recover it. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-09-20NFSv4: Recovery of recalled read delegations is brokenTrond Myklebust
When a read delegation is being recalled, and we're reclaiming the cached opens, we need to make sure that we only reclaim read-only modes. A previous attempt to do this, relied on retrieving the delegation type from the nfs4_opendata structure. Unfortunately, as Kinglong pointed out, this field can only be set when performing reboot recovery. Furthermore, if we call nfs4_open_recover(), then we end up clobbering the state->flags for all modes that we're not recovering... The fix is to have the delegation recall code pass this information to the recovery call, and then refactor the recovery code so that nfs4_open_delegation_recall() does not need to call nfs4_open_recover(). Reported-by: Kinglong Mee <kinglongmee@gmail.com> Fixes: 39f897fdbd46 ("NFSv4: When returning a delegation, don't...") Tested-by: Kinglong Mee <kinglongmee@gmail.com> Cc: NeilBrown <neilb@suse.com> Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-09-20security: fix typo in security_task_prctlJann Horn
Signed-off-by: Jann Horn <jann@thejh.net> Reviewed-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-09-21KVM: PPC: Book3S: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()Thomas Huth
Access to the kvm->buses (like with the kvm_io_bus_read() and -write() functions) has to be protected via the kvm->srcu lock. The kvmppc_h_logical_ci_load() and -store() functions are missing this lock so far, so let's add it there, too. This fixes the problem that the kernel reports "suspicious RCU usage" when lock debugging is enabled. Cc: stable@vger.kernel.org # v4.1+ Fixes: 99342cf8044420eebdf9297ca03a14cb6a7085a1 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2015-09-21KVM: PPC: Book3S HV: Pass the correct trap argument to kvmhv_commence_exitGautham R. Shenoy
In guest_exit_cont we call kvmhv_commence_exit which expects the trap number as the argument. However r3 doesn't contain the trap number at this point and as a result we would be calling the function with a spurious trap number. Fix this by copying r12 into r3 before calling kvmhv_commence_exit as r12 contains the trap number. Cc: stable@vger.kernel.org # v4.1+ Fixes: eddb60fb1443 Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2015-09-21KVM: PPC: Book3S HV: Fix handling of interrupted VCPUsPaul Mackerras
This fixes a bug which results in stale vcore pointers being left in the per-cpu preempted vcore lists when a VM is destroyed. The result of the stale vcore pointers is usually either a crash or a lockup inside collect_piggybacks() when another VM is run. A typical lockup message looks like: [ 472.161074] NMI watchdog: BUG: soft lockup - CPU#24 stuck for 22s! [qemu-system-ppc:7039] [ 472.161204] Modules linked in: kvm_hv kvm_pr kvm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ses enclosure shpchp rtc_opal i2c_opal powernv_rng binfmt_misc dm_service_time scsi_dh_alua radeon i2c_algo_bit drm_kms_helper ttm drm tg3 ptp pps_core cxgb3 ipr i2c_core mdio dm_multipath [last unloaded: kvm_hv] [ 472.162111] CPU: 24 PID: 7039 Comm: qemu-system-ppc Not tainted 4.2.0-kvm+ #49 [ 472.162187] task: c000001e38512750 ti: c000001e41bfc000 task.ti: c000001e41bfc000 [ 472.162262] NIP: c00000000096b094 LR: c00000000096b08c CTR: c000000000111130 [ 472.162337] REGS: c000001e41bff520 TRAP: 0901 Not tainted (4.2.0-kvm+) [ 472.162399] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24848844 XER: 00000000 [ 472.162588] CFAR: c00000000096b0ac SOFTE: 1 GPR00: c000000000111170 c000001e41bff7a0 c00000000127df00 0000000000000001 GPR04: 0000000000000003 0000000000000001 0000000000000000 0000000000874821 GPR08: c000001e41bff8e0 0000000000000001 0000000000000000 d00000000efde740 GPR12: c000000000111130 c00000000fdae400 [ 472.163053] NIP [c00000000096b094] _raw_spin_lock_irqsave+0xa4/0x130 [ 472.163117] LR [c00000000096b08c] _raw_spin_lock_irqsave+0x9c/0x130 [ 472.163179] Call Trace: [ 472.163206] [c000001e41bff7a0] [c000001e41bff7f0] 0xc000001e41bff7f0 (unreliable) [ 472.163295] [c000001e41bff7e0] [c000000000111170] __wake_up+0x40/0x90 [ 472.163375] [c000001e41bff830] [d00000000efd6fc0] kvmppc_run_core+0x1240/0x1950 [kvm_hv] [ 472.163465] [c000001e41bffa30] [d00000000efd8510] kvmppc_vcpu_run_hv+0x5a0/0xd90 [kvm_hv] [ 472.163559] [c000001e41bffb70] [d00000000e9318a4] kvmppc_vcpu_run+0x44/0x60 [kvm] [ 472.163653] [c000001e41bffba0] [d00000000e92e674] kvm_arch_vcpu_ioctl_run+0x64/0x170 [kvm] [ 472.163745] [c000001e41bffbe0] [d00000000e9263a8] kvm_vcpu_ioctl+0x538/0x7b0 [kvm] [ 472.163834] [c000001e41bffd40] [c0000000002d0f50] do_vfs_ioctl+0x480/0x7c0 [ 472.163910] [c000001e41bffde0] [c0000000002d1364] SyS_ioctl+0xd4/0xf0 [ 472.163986] [c000001e41bffe30] [c000000000009260] system_call+0x38/0xd0 [ 472.164060] Instruction dump: [ 472.164098] ebc1fff0 ebe1fff8 7c0803a6 4e800020 60000000 60000000 60420000 8bad02e2 [ 472.164224] 7fc3f378 4b6a57c1 60000000 7c210b78 <e92d0000> 89290009 792affe3 40820070 The bug is that kvmppc_run_vcpu does not correctly handle the case where a vcpu task receives a signal while its guest vcpu is executing in the guest as a result of being piggy-backed onto the execution of another vcore. In that case we need to wait for the vcpu to finish executing inside the guest, and then remove this vcore from the preempted vcores list. That way, we avoid leaving this vcpu's vcore on the preempted vcores list when the vcpu gets interrupted. Fixes: ec2571650826 Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2015-09-20thunderbolt: Allow loading of module on recent Apple MacBooks with ↵Knuth Posern
thunderbolt 2 controller The pci device ids listed in the thunderbolt driver are to restrictive, which prevents the driver from being loaded on recent Apple MacBooks using a thunderbolt 2 controller. In particular this prevented any hot-plugging functionality for thunderbolt based ethernet dongles (i.e. Apples thunderbolt gigabit ethernet broadcom tg3 based dongle Model A1433 EMC 2590). Changing the subvendor and subdevice to PCI_ANY_ID the thunderbolt driver loads and binds to the pci device 07:00.0 System peripheral: Intel Corporation Device 156c which is the thunderbolt 2 controller on the MacBookPro12,1. Successfully tested on MacBookPro12,1. With the patch the thunderbolt module gets now loaded on boot. And it provides hot-plugging support both for a cold-plugged and a warm-plugged ethernet dongle. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Acked-by: Knuth Posern <knuth@posern.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-20Linux 4.3-rc2v4.3-rc2Linus Torvalds
2015-09-20NFS: Fix an infinite loop when layoutget fail with BAD_STATEIDKinglong Mee
If layouget fail with BAD_STATEID, restart should not using the old stateid. But, nfs client choose the layout stateid at first, and then the open stateid. To avoid the infinite loop of using bad stateid for layoutget, this patch sets the layout flag'ss NFS_LAYOUT_INVALID_STID bit to skip choosing the bad layout stateid. Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-09-20NFS: Do cleanup before resetting pageio read/write to mdsKinglong Mee
There is a reference leak of layout segment after resetting pageio read/write to mds. Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
generated by cgit (git 2.34.1) at 2025-09-12 14:56:44 +0000