- 31 Oct, 2014 8 commits
-
-
Daniel Hellstrom authored
[ Upstream commit d1105287 ] dma_zalloc_coherent() calls dma_alloc_coherent(__GFP_ZERO) but the sparc32 implementations sbus_alloc_coherent() and pci32_alloc_coherent() doesn't take the gfp flags into account. Tested on the SPARC32/LEON GRETH Ethernet driver which fails due to dma_alloc_coherent(__GFP_ZERO) returns non zeroed pages. Signed-off-by:
Daniel Hellstrom <daniel@gaisler.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
[ Upstream commit 8bccf5b3 ] Christopher reports that perf_event_print_debug() can crash in uniprocessor builds. The crash is due to pcr_ops being NULL. This happens because pcr_arch_init() is only invoked by smp_cpus_done() which only executes in SMP builds. init_hw_perf_events() is closely intertwined with pcr_ops being setup properly, therefore: 1) Call pcr_arch_init() early on from init_hw_perf_events(), instead of from smp_cpus_done(). 2) Do not hook up a PMU type if pcr_ops is NULL after pcr_arch_init(). 3) Move init_hw_perf_events to a later initcall so that it we will be sure to invoke pcr_arch_init() after all cpus are brought up. Finally, guard the one naked sequence of pcr_ops dereferences in __global_pmu_self() with an appropriate NULL check. Reported-by:
Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 58556104 ] nmi_cpu_busy() is a SMP function call that just makes sure that all of the cpus are spinning using cpu cycles while the NMI test runs. It does not need to disable IRQs because we just care about NMIs executing which will even with 'normal' IRQs disabled. It is not legal to enable hard IRQs in a SMP cross call, in fact this bug triggers the BUG check in irq_work_run_list(): BUG_ON(!irqs_disabled()); Because now irq_work_run() is invoked from the tail of generic_smp_call_function_single_interrupt(). Signed-off-by:
-
Arjun Sreedharan authored
commit 2c4e3dbf upstream. When __usb_find_phy_dev() does not return error and try_module_get() fails, return -ENODEV. Signed-off-by:
Arjun Sreedharan <arjun024@gmail.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Michal Kubeček authored
commit db115037 upstream. This is follow-up to da08143b ("vlan: more careful checksum features handling") which introduced more careful feature intersection in vlan code, taking into account that HW_CSUM should be considered superset of IP_CSUM/IPV6_CSUM. The same is needed in netif_skb_features() in order to avoid offloading mismatch warning when vlan is created on top of a bond consisting of slaves supporting IP/IPv6 checksumming but not vlan Tx offloading. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Slava Pestov authored
commit bf0c55c9 upstream. Change-Id: I6abde52afe917633480caaf4e2518f42a816d886 Signed-off-by:
-
Slava Pestov authored
commit c9a78332 upstream. If register_cache_set() failed, we would touch ca->set after it had already been freed. Also, fix an assertion to catch this. Change-Id: I748e5f5b223e2d9b2602075dec2f997cced2394d Signed-off-by:
-
Surbhi Palande authored
commit 5b25abad upstream. time_stats::btree_gc_max_duration_mc is not bit shifted by 8 Fixes BUG #138 Change-Id: I44fc6e1d0579674016acc533f1a546b080e5371a Signed-off-by:
Surbhi Palande <sap@daterainc.com> Signed-off-by:
-
- 30 Oct, 2014 23 commits
-
-
Al Viro authored
commit c2338f2d upstream. Dentry that had been through (or into) __dentry_kill() might be seen by shrink_dentry_list(); that's normal, it'll be taken off the shrink list and freed if __dentry_kill() has already finished. The problem is, its ->d_parent might be pointing to already freed dentry, so lock_parent() needs to be careful. We need to check that dentry hasn't already gone into __dentry_kill() *and* grab rcu_read_lock() before dropping ->d_lock - the latter makes sure that whatever we see in ->d_parent after dropping ->d_lock it won't be freed until we drop rcu_read_lock(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Linus Torvalds authored
commit 9f12600f upstream. lock_parent() very much on purpose does nested locking of dentries, and is careful to maintain the right order (lock parent first). But because it didn't annotate the nested locking order, lockdep thought it might be a deadlock on d_lock, and complained. Add the proper annotation for the inner locking of the child dentry to make lockdep happy. Introduced by commit 046b961b ("shrink_dentry_list(): take parent's ->d_lock earlier"). Reported-and-tested-by:
Josh Boyer <jwboyer@fedoraproject.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Al Viro authored
commit 8cbf74da upstream. it's 1 in the only remaining caller. Signed-off-by:
-
Al Viro authored
commit b2b80195 upstream. We have the same problem with ->d_lock order in the inner loop, where we are dropping references to ancestors. Same solution, basically - instead of using dentry_kill() we use lock_parent() (introduced in the previous commit) to get that lock in a safe way, recheck ->d_count (in case if lock_parent() has ended up dropping and retaking ->d_lock and somebody managed to grab a reference during that window), trylock the inode->i_lock and use __dentry_kill() to do the rest. Signed-off-by:
-
Al Viro authored
commit 046b961b upstream. The cause of livelocks there is that we are taking ->d_lock on dentry and its parent in the wrong order, forcing us to use trylock on the parent's one. d_walk() takes them in the right order, and unfortunately it's not hard to create a situation when shrink_dentry_list() can't make progress since trylock keeps failing, and shrink_dcache_parent() or check_submounts_and_drop() keeps calling d_walk() disrupting the very shrink_dentry_list() it's waiting for. Solution is straightforward - if that trylock fails, let's unlock the dentry itself and take locks in the right order. We need to stabilize ->d_parent without holding ->d_lock, but that's doable using RCU. And we'd better do that in the very beginning of the loop in shrink_dentry_list(), since the checks on refcount, etc. would need to be redone anyway. That deals with a half of the problem - killing dentries on the shrink list itself. Another one (dropping their parents) is in the next commit. locking parent is interesting - it would be easy to do rcu_read_lock(), lock whatever we think is a parent, lock dentry itself and check if the parent is still the right one. Except that we need to check that *before* locking the dentry, or we are risking taking ->d_lock out of order. Fortunately, once the D1 is locked, we can check if D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent can start or stop pointing to D1 only under D1->d_lock, so taking D1->d_lock is enough. In other words, the right solution is rcu_read_lock/lock what looks like parent right now/check if it's still our parent/rcu_read_unlock/lock the child. Signed-off-by:
-
Al Viro authored
commit ff2fde99 upstream. Result will be massaged to saner shape in the next commits. It is ugly, no questions - the point of that one is to be a provably equivalent transformation (and it might be worth splitting a bit more). Signed-off-by:
-
Al Viro authored
commit e55fd011 upstream. ... into trylocks and everything else. The latter (actual killing) is __dentry_kill(). Signed-off-by:
-
Al Viro authored
commit 64fd72e0 upstream. It can happen only when dentry_kill() is called with unlock_on_failure equal to 0 - other callers had dentry pinned until the moment they've got ->d_lock and DCACHE_DENTRY_KILLED is set only after lockref_mark_dead(). IOW, only one of three call sites of dentry_kill() might end up reaching that code. Just move it there. Signed-off-by:
-
Miklos Szeredi authored
commit 60942f2f upstream. Since now the shrink list is private and nobody can free the dentry while it is on the shrink list, we can remove RCU protection from this. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Al Viro authored
commit 9c8c10e2 upstream. Start with shrink_dcache_parent(), then scan what remains. First of all, BUG() is very much an overkill here; we are holding ->s_umount, and hitting BUG() means that a lot of interesting stuff will be hanging after that point (sync(2), for example). Moreover, in cases when there had been more than one leak, we'll be better off reporting all of them. And more than just the last component of pathname - %pd is there for just such uses... That was the last user of dentry_lru_del(), so kill it off... Signed-off-by:
-
Al Viro authored
commit fe91522a upstream. If we find something already on a shrink list, just increment data->found and do nothing else. Loops in shrink_dcache_parent() and check_submounts_and_drop() will do the right thing - everything we did put into our list will be evicted and if there had been nothing, but data->found got non-zero, well, we have somebody else shrinking those guys; just try again. Signed-off-by:
-
Al Viro authored
commit 41edf278 upstream. If the victim in on the shrink list, don't remove it from there. If shrink_dentry_list() manages to remove it from the list before we are done - fine, we'll just free it as usual. If not - mark it with new flag (DCACHE_MAY_FREE) and leave it there. Eventually, shrink_dentry_list() will get to it, remove the sucker from shrink list and call dentry_kill(dentry, 0). Which is where we'll deal with freeing. Since now dentry_kill(dentry, 0) may happen after or during dentry_kill(dentry, 1), we need to recognize that (by seeing DCACHE_DENTRY_KILLED already set), unlock everything and either free the sucker (in case DCACHE_MAY_FREE has been set) or leave it for ongoing dentry_kill(dentry, 1) to deal with. Signed-off-by:
-
Al Viro authored
commit 01b60351 upstream. Signed-off-by:
-
Al Viro authored
commit b4f0354e upstream. The part of old d_free() that dealt with actual freeing of dentry. Taken out of dentry_kill() into a separate function. Signed-off-by:
-
Al Viro authored
commit 5c47e6d0 upstream. Signed-off-by:
-
Al Viro authored
commit 03b3b889 upstream. Signed-off-by:
-
Al Viro authored
commit 31dec132 upstream. There used to be a bunch of tree-walkers in dcache.c, all alike. try_to_ascend() had been introduced to abstract a piece of logics duplicated in all of them. These days all these tree-walkers are implemented via the same iterator (d_walk()), which is the only remaining caller of try_to_ascend(), so let's fold it back... Signed-off-by:
-
Al Viro authored
commit b61625d2 upstream. Signed-off-by:
-
Al Viro authored
commit 42c32608 upstream. we have too many iterators in fs/dcache.c... Signed-off-by:
-
Sanjeev Sharma authored
commit ab945eff upstream. on some architecture spin_is_locked() always return false in uniprocessor configuration and therefore it would be advise to replace with lockdep_assert_held(). Signed-off-by:
Sanjeev Sharma <Sanjeev_Sharma@mentor.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mark Knibbs authored
commit 57cde01a upstream. Castlewood Systems supplied various models of USB-SCSI converter with their ORB external removable-media drive. The ORB Windows and Macintosh drivers support six USB IDs: 084B:A001 [VID 084B is Castlewood Systems] 04E6:0002 (*) ORB USB Smart Cable P/N 88205-001 (generic SCM ID) 2027:A001 Double-H Technology DH-2000SC 1822:0001 (*) Ariston iConnect/iSCSI 07AF:0004 (*) Microtech XpressSCSI (25-pin) 07AF:0005 (*) Microtech XpressSCSI (50-pin) *: quirk already in unusual-devs.h [Apparently the official VID for Double-H Technology is 0x07EB = 2027 decimal. That's another hex/decimal mix-up with these SCM-based products (in addition to the Ariston and Entrega ones). Perhaps the USB-IF informed companies of their allocated VID in decimal, but they assumed it was hex? It seems all Entrega products used VID 0x1645, not just the USB-SCSI converter.] Double-H Technology Co., Ltd. produced a USB-SCSI converter, model DH-2000SC, which is probably the one supported by the ORB drivers. Perhaps the Castlewood-bundled product had a different label or PID though? Castlewood mentioned Conmate as being one type of USB-SCSI converter. Conmate and Double-H seem related somehow; both company addresses in the same road, and at one point the Conmate web site mentioned DH-2000H4, DH-200D4/DH-2000C4 as models of USB hub (DH short for Double-H presumably). Conmate did show a USB-SCSI converter model CM-660 on their web site at one point. My guess is that was identical to the DH-2000SC. Mention of the Double-H product: http://web.archive.org/web/20010221010141/http://www.doubleh.com.tw/dh-2000sc.htm The only picture I could find is at http://jp.acesuppliers.com/catalog/j64/component/page03.html The casing design looks the same as my ORB USB Smart Cable which has ID 04E6:0002. Anyway, that's enough rambling. Here's the patch. storage: Add quirks for Castlewood and Double-H USB-SCSI converters Add quirks for two SCM-based USB-SCSI converters which were bundled with some Castlewood ORB removable drives. Without the quirk only the (single) drive with SCSI ID 0 can be accessed. Signed-off-by:
Mark Knibbs <markk@clara.co.uk> Signed-off-by:
-
Mark Knibbs authored
commit 3512e7bf upstream. There is apparently another SCM USB-SCSI converter with ID 04E6:000F. It is listed along with 04E6:000B in the Windows INF file for the Startech ICUSBSCSI2 as "eUSB SCSI Adapter (Bus Powered)". The quirk allows devices with SCSI ID other than 0 to be accessed. Also make a couple of existing SCM product IDs lower case to be consistent with other entries. Signed-off-by:
-
Lu Baolu authored
commit ddbe1fca upstream. This full-speed USB device generates spurious remote wakeup event as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result, Linux can't enter system suspend and S0ix power saving modes once this keyboard is used. This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk. With this quirk set, wakeup capability will be ignored during device configure. This patch could be back-ported to kernels as old as 2.6.39. Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
- 29 Oct, 2014 1 commit
-
-
Eliad Peller authored
Upstream commit a5fe8e76 (regulatory: add NUL to alpha2) contained a hunk that was supposed to be applied to struct ieee80211_reg_rule. However in stable 3.12 (3.12.31 in particular), it ended up in struct regulatory_request. Fix that now. Signed-off-by:
-
- 17 Oct, 2014 8 commits
-
-
Pali Rohár authored
commit a666b6ff upstream. Without this patch, dell-wmi is trying to access elements of dynamically allocated array without checking the array size. This can lead to memory corruption or a kernel panic. This patch adds the missing checks for array size. Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Andy Lutomirski authored
commit a1480dcc upstream. Accessing do_remount_sb should require global CAP_SYS_ADMIN, but only one of the two call sites was appropriately protected. Fixes CVE-2014-7975. Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
-
Jiri Slaby authored
-
Bryan O'Donoghue authored
commit 1ede7dcc upstream. Quark X1000 contains two designware derived 8250 serial ports. Each port has a unique PCI configuration space consisting of BAR0:UART BAR1:DMA respectively. Unlike the standard 8250 the register width is 32 bits for RHR,IER etc The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a bitrate of up to about 2.76 megabits per second. This patch enables standard 8250 mode Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Andreas Bomholtz authored
commit dee80ad1 upstream. Added the Seluxit ApS USB Serial Dongle to cp210x driver. Signed-off-by:
Andreas Bomholtz <andreas@seluxit.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Joe Savage authored
commit bfc2d7df upstream. Added support for Ketra N1 wireless interface, which uses the Silicon Labs' CP2104 USB to UART bridge with customized PID 8946. Signed-off-by:
Joe Savage <joe.savage@goketra.com> Signed-off-by:
-
Lu Baolu authored
commit ddbe1fca upstream. This full-speed USB device generates spurious remote wakeup event as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result, Linux can't enter system suspend and S0ix power saving modes once this keyboard is used. This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk. With this quirk set, wakeup capability will be ignored during device configure. This patch could be back-ported to kernels as old as 2.6.39. Signed-off-by:
-
Per Hurtig authored
[ Upstream commit bef1909e ] Fix to a problem observed when losing a FIN segment that does not contain data. In such situations, TLP is unable to recover from *any* tail loss and instead adds at least PTO ms to the retransmission process, i.e., RTO = RTO + PTO. Signed-off-by:
Per Hurtig <per.hurtig@kau.se> Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Nandita Dukkipati <nanditad@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
