aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-02-18mm/hugetlb.c: fix incorrect proc nr_hugepages valueVaishali Thakkar1-2/+4
Currently incorrect default hugepage pool size is reported by proc nr_hugepages when number of pages for the default huge page size is specified twice. When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages indicates the current number of pre-allocated huge pages of the default size. Basically /proc/sys/vm/nr_hugepages displays default_hstate-> max_huge_pages and after boot time pre-allocation, max_huge_pages should equal the number of pre-allocated pages (nr_hugepages). Test case: Note that this is specific to x86 architecture. Boot the kernel with command line option 'default_hugepagesz=1G hugepages=X hugepagesz=2M hugepages=Y hugepagesz=1G hugepages=Z'. After boot, 'cat /proc/sys/vm/nr_hugepages' and 'sysctl -a | grep hugepages' returns the value X. However, dmesg output shows that Z huge pages were pre-allocated. So, the root cause of the problem here is that the global variable default_hstate_max_huge_pages is set if a default huge page size is specified (directly or indirectly) on the command line. After the command line processing in hugetlb_init, if default_hstate_max_huge_pages is set, the value is assigned to default_hstae.max_huge_pages. However, default_hstate.max_huge_pages may have already been set based on the number of pre-allocated huge pages of default_hstate size. The solution to this problem is if hstate->max_huge_pages is already set then it should not set as a result of global max_huge_pages value. Basically if the value of the variable hugepages is set multiple times on a command line for a specific supported hugepagesize then proc layer should consider the last specified value. Signed-off-by: Vaishali Thakkar <[email protected]> Reviewed-by: Naoya Horiguchi <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Paul Gortmaker <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-02-18mm, x86: fix pte_page() crash in gup_pte_range()Hugh Dickins1-1/+1
Commit 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") has moved up the pte_page(pte) in x86's fast gup_pte_range(), for no discernible reason: put it back where it belongs, after the pte_flags check and the pfn_valid cross-check. That may be the cause of the NULL pointer dereference in gup_pte_range(), seen when vfio called vaddr_get_pfn() when starting a qemu-kvm based VM. Signed-off-by: Hugh Dickins <[email protected]> Reported-by: Michael Long <[email protected]> Tested-by: Michael Long <[email protected]> Acked-by: Dan Williams <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-02-18fsnotify: turn fsnotify reaper thread into a workqueue jobJeff Layton1-31/+18
We don't require a dedicated thread for fsnotify cleanup. Switch it over to a workqueue job instead that runs on the system_unbound_wq. In the interest of not thrashing the queued job too often when there are a lot of marks being removed, we delay the reaper job slightly when queueing it, to allow several to gather on the list. Signed-off-by: Jeff Layton <[email protected]> Tested-by: Eryu Guan <[email protected]> Reviewed-by: Jan Kara <[email protected]> Cc: Eric Paris <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-02-18Revert "fsnotify: destroy marks with call_srcu instead of dedicated thread"Jeff Layton2-18/+53
This reverts commit c510eff6beba ("fsnotify: destroy marks with call_srcu instead of dedicated thread"). Eryu reported that he was seeing some OOM kills kick in when running a testcase that adds and removes inotify marks on a file in a tight loop. The above commit changed the code to use call_srcu to clean up the marks. While that does (in principle) work, the srcu callback job is limited to cleaning up entries in small batches and only once per jiffy. It's easily possible to overwhelm that machinery with too many call_srcu callbacks, and Eryu's reproduer did just that. There's also another potential problem with using call_srcu here. While you can obviously sleep while holding the srcu_read_lock, the callbacks run under local_bh_disable, so you can't sleep there. It's possible when putting the last reference to the fsnotify_mark that we'll end up putting a chain of references including the fsnotify_group, uid, and associated keys. While I don't see any obvious ways that that could occurs, it's probably still best to avoid using call_srcu here after all. This patch reverts the above patch. A later patch will take a different approach to eliminated the dedicated thread here. Signed-off-by: Jeff Layton <[email protected]> Reported-by: Eryu Guan <[email protected]> Tested-by: Eryu Guan <[email protected]> Cc: Jan Kara <[email protected]> Cc: Eric Paris <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-02-18mm: fix regression in remap_file_pages() emulationKirill A. Shutemov1-5/+29
Grazvydas Ignotas has reported a regression in remap_file_pages() emulation. Testcase: #define _GNU_SOURCE #include <assert.h> #include <stdlib.h> #include <stdio.h> #include <sys/mman.h> #define SIZE (4096 * 3) int main(int argc, char **argv) { unsigned long *p; long i; p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) { perror("mmap"); return -1; } for (i = 0; i < SIZE / 4096; i++) p[i * 4096 / sizeof(*p)] = i; if (remap_file_pages(p, 4096, 0, 1, 0)) { perror("remap_file_pages"); return -1; } if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) { perror("remap_file_pages"); return -1; } assert(p[0] == 1); munmap(p, SIZE); return 0; } The second remap_file_pages() fails with -EINVAL. The reason is that remap_file_pages() emulation assumes that the target vma covers whole area we want to over map. That assumption is broken by first remap_file_pages() call: it split the area into two vma. The solution is to check next adjacent vmas, if they map the same file with the same flags. Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation") Signed-off-by: Kirill A. Shutemov <[email protected]> Reported-by: Grazvydas Ignotas <[email protected]> Tested-by: Grazvydas Ignotas <[email protected]> Cc: <[email protected]> [4.0+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-02-18thp, dax: do not try to withdraw pgtable from non-anon VMAKirill A. Shutemov1-1/+2
DAX doesn't deposit pgtables when it maps huge pages: nothing to withdraw. It can lead to crash. Signed-off-by: Kirill A. Shutemov <[email protected]> Cc: Dan Williams <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Ross Zwisler <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-02-18USB: cdc_subset: only build when one driver is enabledArnd Bergmann2-1/+11
This avoids a harmless randconfig warning I get when USB_NET_CDC_SUBSET is enabled, but all of the more specific drivers are not: drivers/net/usb/cdc_subset.c:241:2: #warning You need to configure some hardware for this driver The current behavior is clearly intentional, giving a warning when a user picks a configuration that won't do anything good. The only reason for even addressing this is that I'm getting close to eliminating all 'randconfig' warnings on ARM, and this came up a couple of times. My workaround is to not even build the module when none of the configurations are enable. Alternatively we could simply remove the #warning (nothing wrong for compile-testing), turn it into a runtime warning, or change the Kconfig options into a menu to hide CONFIG_USB_NET_CDC_SUBSET. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18vxlan: do not use fdb in metadata modeJiri Benc1-3/+5
In metadata mode, the vxlan interface is not supposed to use the fdb control plane but an external one (openvswitch or static routes). With the current code, packets may leak into the fdb handling code which usually causes them to be dropped anyway but may have strange side effects. Just drop the packets directly when in metadata mode if the destination data are not correctly provided on egress. Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18mISDN: prevent possible NULL pointer dereferenceAnton Protopopov1-1/+1
A return value of the bchannel_get_rxbuf() function is compared with the positive ENOMEM value instead of the negative -ENOMEM value to detect a memory allocation problem. Thus, after a possible memory allocation failure the bc->bch.rx_skb will be NULL which will lead to a NULL pointer dereference. Signed-off-by: Anton Protopopov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18net: caif: fix erroneous return valueAnton Protopopov1-1/+1
The cfrfml_receive() function might return positive value EPROTO Signed-off-by: Anton Protopopov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18appletalk: fix erroneous return valueAnton Protopopov1-1/+1
The atalk_sendmsg() function might return wrong value ENETUNREACH instead of -ENETUNREACH. Signed-off-by: Anton Protopopov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18lance: Return correct error codeAmitoj Kaur Chawla1-2/+2
Failure of kzalloc should cause the enclosing function to return -ENOMEM, not -ENODEV. Additionally, removed the following checkpatch warnings: ERROR: spaces required around that '==' (ctx:VxV) ERROR: space required before the open parenthesis '(' CHECK: Comparison to NULL could be written "!lp" Signed-off-by: Amitoj Kaur Chawla <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18IFF_NO_QUEUE: Fix for drivers not calling ether_setup()Phil Sutter1-1/+3
My implementation around IFF_NO_QUEUE driver flag assumed that leaving tx_queue_len untouched (specifically: not setting it to zero) by drivers would make it possible to assign a regular qdisc to them without having to worry about setting tx_queue_len to a useful value. This was only partially true: I overlooked that some drivers don't call ether_setup() and therefore not initialize tx_queue_len to the default value of 1000. Consequently, removing the workarounds in place for that case in qdisc implementations which cared about it (namely, pfifo, bfifo, gred, htb, plug and sfb) leads to problems with these specific interface types and qdiscs. Luckily, there's already a sanitization point for drivers setting tx_queue_len to zero, which can be reused to assign the fallback value most qdisc implementations used, which is 1. Fixes: 348e3435cbefa ("net: sched: drop all special handling of tx_queue_len == 0") Tested-by: Mathieu Desnoyers <[email protected]> Signed-off-by: Phil Sutter <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18gre: clear IFF_TX_SKB_SHARINGJiri Benc2-2/+4
ether_setup sets IFF_TX_SKB_SHARING but this is not supported by gre as it modifies the skb on xmit. Also, clean up whitespace in ipgre_tap_setup when we're already touching it. Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18geneve: clear IFF_TX_SKB_SHARINGJiri Benc1-0/+1
ether_setup sets IFF_TX_SKB_SHARING but this is not supported by geneve as it modifies the skb on xmit. Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18vxlan: clear IFF_TX_SKB_SHARINGJiri Benc1-0/+1
ether_setup sets IFF_TX_SKB_SHARING but this is not supported by vxlan as it modifies the skb on xmit. Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18irqchip/gic-v3: Add missing barrier to 32bit version of gic_read_iar()Marc Zyngier1-0/+1
Commit 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor") fixed the missing barrier on arm64, but forgot to update the 32bit counterpart, which has the same requirements. Let's fix it. Fixes: 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor") Signed-off-by: Marc Zyngier <[email protected]>
2016-02-18geneve: Refine MTU limitDavid Wragg1-5/+22
Calculate the maximum MTU taking into account the size of headers involved in GENEVE encapsulation, as for other tunnel types. Changes in v3: - Correct comment style Changes in v2: - Conform more closely to ip_tunnel_change_mtu - Exclude GENEVE options from max MTU calculation Signed-off-by: David Wragg <[email protected]> Acked-by: Jesse Gross <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18tcp/dccp: fix another race at listener dismantleEric Dumazet6-37/+38
Ilya reported following lockdep splat: kernel: ========================= kernel: [ BUG: held lock freed! ] kernel: 4.5.0-rc1-ceph-00026-g5e0a311 #1 Not tainted kernel: ------------------------- kernel: swapper/5/0 is freeing memory ffff880035c9d200-ffff880035c9dbff, with a lock still held there! kernel: (&(&queue->rskq_lock)->rlock){+.-...}, at: [<ffffffff816f6a88>] inet_csk_reqsk_queue_add+0x28/0xa0 kernel: 4 locks held by swapper/5/0: kernel: #0: (rcu_read_lock){......}, at: [<ffffffff8169ef6b>] netif_receive_skb_internal+0x4b/0x1f0 kernel: #1: (rcu_read_lock){......}, at: [<ffffffff816e977f>] ip_local_deliver_finish+0x3f/0x380 kernel: #2: (slock-AF_INET){+.-...}, at: [<ffffffff81685ffb>] sk_clone_lock+0x19b/0x440 kernel: #3: (&(&queue->rskq_lock)->rlock){+.-...}, at: [<ffffffff816f6a88>] inet_csk_reqsk_queue_add+0x28/0xa0 To properly fix this issue, inet_csk_reqsk_queue_add() needs to return to its callers if the child as been queued into accept queue. We also need to make sure listener is still there before calling sk->sk_data_ready(), by holding a reference on it, since the reference carried by the child can disappear as soon as the child is put on accept queue. Reported-by: Ilya Dryomov <[email protected]> Fixes: ebb516af60e1 ("tcp/dccp: fix race at listener dismantle phase") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18route: check and remove route cache when we get routeXin Long2-14/+64
Since the gc of ipv4 route was removed, the route cached would has no chance to be removed, and even it has been timeout, it still could be used, cause no code to check it's expires. Fix this issue by checking and removing route cache when we get route. Signed-off-by: Xin Long <[email protected]> Acked-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18Adding Intel Lewisburg device IDs for SATAAlexandra Yates1-0/+6
This patch complements the list of device IDs previously added for lewisburg sata. Signed-off-by: Alexandra Yates <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected]
2016-02-18pata-rb532-cf: get rid of the irq_to_gpio() callGabor Juhos1-1/+10
The RB532 platform specific irq_to_gpio() implementation has been removed with commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h"). Now the platform uses the generic stub which causes the following error: pata-rb532-cf pata-rb532-cf: no GPIO found for irq149 pata-rb532-cf: probe of pata-rb532-cf failed with error -2 Drop the irq_to_gpio() call and get the GPIO number from platform data instead. After this change, the driver works again: scsi host0: pata-rb532-cf ata1: PATA max PIO4 irq 149 ata1.00: CFA: CF 1GB, 20080820, max MWDMA4 ata1.00: 1989792 sectors, multi 0: LBA ata1.00: configured for PIO4 scsi 0:0:0:0: Direct-Access ATA CF 1GB 0820 PQ: 0\ ANSI: 5 sd 0:0:0:0: [sda] 1989792 512-byte logical blocks: (1.01 GB/971 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't\ support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") Cc: Alban Bedel <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: <[email protected]> #v4.3+ Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2016-02-18net_sched fix: reclassification needs to consider ether protocol changesJamal Hadi Salim1-0/+1
actions could change the etherproto in particular with ethernet tunnelled data. Typically such actions, after peeling the outer header, will ask for the packet to be reclassified. We then need to restart the classification with the new proto header. Example setup used to catch this: sudo tc qdisc add dev $ETH ingress sudo $TC filter add dev $ETH parent ffff: pref 1 protocol 802.1Q \ u32 match u32 0 0 flowid 1:1 \ action vlan pop reclassify Fixes: 3b3ae880266d ("net: sched: consolidate tc_classify{,_compat}") Signed-off-by: Jamal Hadi Salim <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18Merge branch 'mlxsw-fixes'David S. Miller4-9/+121
Jiri Pirko says: ==================== mlxsw fixes Another bulk of fixes from Ido. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-02-18mlxsw: spectrum: Allow for PVID deletionIdo Schimmel3-9/+63
When PVID is toggled off on a port member in a VLAN filtering bridge or the PVID VLAN is deleted, make the port drop untagged packets. Reverse the operation when PVID is toggled back on. Set the PVID back to the default (1), when leaving the bridge so that untagged traffic will be directed to the CPU. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18mlxsw: reg: Add the Switch Port Acceptable Frame Types registerIdo Schimmel1-0/+58
When VLAN filtering is enabled on a bridge and PVID is deleted from a bridge port, then untagged frames are not allowed to ingress into the bridge from this port. Add the Switch Port Acceptable Frame Types (SPAFT) register, which configures the frame admittance of the port. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18i2c: i801: Adding Intel Lewisburg support for iTCOAlexandra Yates1-0/+2
Starting from Intel Sunrisepoint (Skylake PCH) the iTCO watchdog resources have been moved to reside under the i801 SMBus host controller whereas previously they were under the LPC device. This patch adds Intel lewisburg SMBus support for iTCO device. It allows to load watchdog dynamically when the hardware is present. Fixes: cdc5a3110e7c ("i2c: i801: add Intel Lewisburg device IDs") Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Alexandra Yates <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2016-02-18USB: option: add "4G LTE usb-modem U901"Bjørn Mork1-0/+2
Thomas reports: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05c6 ProdID=6001 Rev=00.00 S: Manufacturer=USB Modem S: Product=USB Modem S: SerialNumber=1234567890ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Cc: <[email protected]> Reported-by: Thomas Schäfer <[email protected]> Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2016-02-18ARCv2: boot report CCMs (Closely Coupled Memories)Vineet Gupta2-40/+70
- ARCv2 uses a seperate BCR for {I,D}CCM base address: ARCompact encoded both base/size in same BCR - Size encoding in common BCR is different for ARCompact/ARCv2 Signed-off-by: Vineet Gupta <[email protected]>
2016-02-18ARCv2: boot print Low Latency MemoryVineet Gupta1-1/+2
Signed-off-by: Vineet Gupta <[email protected]>
2016-02-18ARC: Assume multiplier is always presentVineet Gupta3-14/+0
It is unlikely that designs running Linux will not have multiplier. Further the current support is not complete as tool don't generate a multilib w/o multiplier. Signed-off-by: Vineet Gupta <[email protected]>
2016-02-18USB: cp210x: add IDs for GE B650V3 and B850V3 boardsKen Lin1-0/+2
Add USB ID for cp2104/5 devices on GE B650v3 and B850v3 boards. Signed-off-by: Ken Lin <[email protected]> Signed-off-by: Akshay Bhat <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2016-02-18USB: option: add support for SIM7100EAndrey Skvortsov1-0/+7
$ lsusb: Bus 001 Device 101: ID 1e0e:9001 Qualcomm / Option $ usb-devices: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=101 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 P: Vendor=1e0e ProdID=9001 Rev= 2.32 S: Manufacturer=SimTech, Incorporated S: Product=SimTech, Incorporated S: SerialNumber=0123456789ABCDEF C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) The last interface (6) is used for Android Composite ADB interface. Serial port layout: 0: QCDM/DIAG 1: NMEA 2: AT 3: AT/PPP 4: audio Signed-off-by: Andrey Skvortsov <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2016-02-18ALSA: pcm: Fix rwsem deadlock for non-atomic PCM streamTakashi Iwai1-2/+14
A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice in the same code path, e.g. one in snd_pcm_action_nonatomic() and another in snd_pcm_stream_lock(). Usually this is OK, but when a write lock is issued between these two read locks, the problem happens: the write lock is blocked due to the first reade lock, and the second read lock is also blocked by the write lock. This eventually deadlocks. The reason is the way rwsem manages waiters; it's queued like FIFO, so even if the writer itself doesn't take the lock yet, it blocks all the waiters (including reads) queued after it. As a workaround, in this patch, we replace the standard down_write() with an spinning loop. This is far from optimal, but it's good enough, as the spinning time is supposed to be relatively short for normal PCM operations, and the code paths requiring the write lock aren't called so often. Reported-by: Vinod Koul <[email protected]> Tested-by: Ramesh Babu <[email protected]> Cc: <[email protected]> # v3.18+ Signed-off-by: Takashi Iwai <[email protected]>
2016-02-18x86/mm: Fix vmalloc_fault() to handle large pages properlyToshi Kani1-4/+11
A kernel page fault oops with the callstack below was observed when a read syscall was made to a pmem device after a huge amount (>512GB) of vmalloc ranges was allocated by ioremap() on a x86_64 system: BUG: unable to handle kernel paging request at ffff880840000ff8 IP: vmalloc_fault+0x1be/0x300 PGD c7f03a067 PUD 0 Oops: 0000 [#1] SM Call Trace: __do_page_fault+0x285/0x3e0 do_page_fault+0x2f/0x80 ? put_prev_entity+0x35/0x7a0 page_fault+0x28/0x30 ? memcpy_erms+0x6/0x10 ? schedule+0x35/0x80 ? pmem_rw_bytes+0x6a/0x190 [nd_pmem] ? schedule_timeout+0x183/0x240 btt_log_read+0x63/0x140 [nd_btt] : ? __symbol_put+0x60/0x60 ? kernel_read+0x50/0x80 SyS_finit_module+0xb9/0xf0 entry_SYSCALL_64_fastpath+0x1a/0xa4 Since v4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 and PAE. vmalloc_fault() however assumes that the vmalloc range is limited to pte mappings. vmalloc faults do not normally happen in ioremap'd ranges since ioremap() sets up the kernel page tables, which are shared by user processes. pgd_ctor() sets the kernel's PGD entries to user's during fork(). When allocation of the vmalloc ranges crosses a 512GB boundary, ioremap() allocates a new pud table and updates the kernel PGD entry to point it. If user process's PGD entry does not have this update yet, a read/write syscall to the range will cause a vmalloc fault, which hits the Oops above as it does not handle a large page properly. Following changes are made to vmalloc_fault(). 64-bit: - No change for the PGD sync operation as it handles large pages already. - Add pud_huge() and pmd_huge() to the validation code to handle large pages. - Change pud_page_vaddr() to pud_pfn() since an ioremap range is not directly mapped (while the if-statement still works with a bogus addr). - Change pmd_page() to pmd_pfn() since an ioremap range is not backed by struct page (while the if-statement still works with a bogus addr). 32-bit: - No change for the sync operation since the index3 PGD entry covers the entire vmalloc range, which is always valid. (A separate change to sync PGD entry is necessary if this memory layout is changed regardless of the page size.) - Add pmd_huge() to the validation code to handle large pages. This is for completeness since vmalloc_fault() won't happen in ioremap'd ranges as its PGD entry is always valid. Reported-by: Henning Schild <[email protected]> Signed-off-by: Toshi Kani <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: <[email protected]> # 4.1+ Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Luis R. Rodriguez <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Toshi Kani <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-02-17et131x: check return value of dma_alloc_coherentInsu Yun1-1/+1
For error handling, dma_alloc_coherent's return value needs to be checked, not argument. Signed-off-by: Insu Yun <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-17Merge branch 'thunderx-fixes'David S. Miller3-17/+12
Sunil Goutham says: ==================== net: thunderx: Miscellaneous fixes This patch series fixes couple of issues w.r.t multiqset mode and receive packet statastics. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-02-17net: thunderx: Fix receive packet statsSunil Goutham3-13/+9
Counting rx packets for every CQE_RX in CQ irq handler is incorrect. Synchronization is missing when multiple queues are receiving packets simultaneously. Like transmit packet stats use HW stats here. Also removed unused 'cqe_type' parameter in nicvf_rcv_pkt_handler(). Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-17net: thunderx: Fix for HW TSO not enabled for secondary qsetsSunil Goutham1-3/+3
For secondary Qsets 'hw_tso' is not getting set as probe() returns much earlier. Fixed it by moving silicon revision check. Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-17net: thunderx: Fix for multiqset not configured upon interface toggleSunil Goutham1-1/+0
When a interface is assigned morethan 8 queues and the logical interface is toggled i.e down & up, additional queues or qsets are not initialized as secondary qset count is being set to zero while tearing down. Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-17tcp: correctly crypto_alloc_hash return checkInsu Yun1-1/+1
crypto_alloc_hash never returns NULL Signed-off-by: Insu Yun <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-17net: dsa: Unregister slave_dev in error pathFlorian Fainelli1-0/+1
With commit 0071f56e46da ("dsa: Register netdev before phy"), we are now trying to free a network device that has been previously registered, and in case of errors, this will make us hit the BUG_ON(dev->reg_state != NETREG_UNREGISTERED) condition. Fix this by adding a missing unregister_netdev() before free_netdev(). Fixes: 0071f56e46da ("dsa: Register netdev before phy") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-18irqchip/ts4800: Make ts4800_ic_ops static constAxel Lin1-1/+1
ts4800_ic_ops is only referenced in this driver, so make it static. In additional, it's never get modified thus also make it const. Signed-off-by: Axel Lin <[email protected]> Reviewed-by: Damien Riegel <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]>
2016-02-18irqchip/bcm2836: Drop extra memory barrier in SMP boot.Eric Anholt1-1/+0
The writel() immediately after this has a barrier, anyway. Signed-off-by: Eric Anholt <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]>
2016-02-18irqchip/ts4800: Add hardware dependencyJean Delvare1-0/+1
The Technologic Systems TS-4800 is an i.MX515 board, so its drivers are useless unless building a SOC_IMX51 kernel, except for build testing purposes. Signed-off-by: Jean Delvare <[email protected]> Cc: Damien Riegel <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Marc Zyngier <[email protected]> Link: https://lkml.kernel.org/r/20160209111920.1ec318bd@endymion Signed-off-by: Jason Cooper <[email protected]>
2016-02-18irqchip/tango: Add support for Sigma Designs SMP86xx/SMP87xx interrupt ↵Mans Rullgard3-0/+238
controller This adds support for the secondary interrupt controller used in Sigma Designs SMP86xx and SMP87xx chips. Signed-off-by: Mans Rullgard <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]>
2016-02-18devicetree: Add binding for Sigma Designs SMP86xx interrupt controllerMans Rullgard1-0/+49
This adds a binding for the secondary interrupt controller in Sigma Designs SMP86xx and SMP87xx chips. Signed-off-by: Mans Rullgard <[email protected]> [ jac: use 'interrupt-controller@XXX' notation in binding doc ] Acked-by: Rob Herring <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]>
2016-02-17Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"Bjorn Helgaas4-27/+14
Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"). This is part of reverting 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it introduced. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> CC: Jiang Liu <[email protected]>
2016-02-17irqchip/mxs: Add missing set_handle_irq()Oleksij Rempel1-0/+1
The rework of the driver missed to move the call to set_handle_irq() into asm9260_of_init(). As a consequence no interrupt entry point is installed and no interrupts are delivered Solution is: Install the interrupt entry handler. Fixes: 7e4ac676ee ("irqchip/mxs: Add Alphascale ASM9260 support") Signed-off-by: Oleksij Rempel <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jason Cooper <[email protected]>
2016-02-17phy: marvell: Fix and unify reg-init behaviorClemens Gruber1-2/+13
For the Marvell 88E1510, marvell_of_reg_init was called too late, in the config_aneg function. Since commit 113c74d83eef ("net: phy: turn carrier off on phy attach"), this lead to the link not coming up at boot anymore, due to the phy state machine being stuck at waiting for interrupts (off by default on the 88E1510). For seven other Marvell PHYs, marvell_of_reg_init was not called at all. Add a generic marvell_config_init function, which in turn calls marvell_of_reg_init. PHYs, which already have a specific config_init function with a call to marvell_of_reg_init, are left untouched. The generic marvell_config_init function is called for all the others, to get consistent behavior across all Marvell PHYs. Fixes: 113c74d83eef ("net: phy: turn carrier off on phy attach") Signed-off-by: Clemens Gruber <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.