- 10 Jun, 2014 9 commits
-
-
Krzysztof Kozlowski authored
commit d0a588a5 upstream. During probe the driver allocates dummy I2C devices (i2c_new_dummy()) but they aren't unregistered during driver remove or probe failure. Additionally driver does not check the return value of i2c_new_dummy(). In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later dereferenced by i2c_smbus_{read,write}_data() functions. Fix issues by properly checking for i2c_new_dummy() return value and unregistering I2C devices on driver remove or probe failure. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by:
Beomho Seo <beomho.seo@samsung.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Alec Berg authored
commit 2076a20f upstream. Ensure that querying the IIO buffer scan_mask returns a value of 0 or 1. Currently querying the scan mask has the value returned by test_bit(), which returns either true or false. For some architectures test_bit() may return -1 for true, which will appear to return an error when returning from iio_scan_mask_query(). Additionally, it's important for the sysfs interface to consistently return the same thing when querying the scan_mask. Signed-off-by:
Alec Berg <alecaberg@chromium.org> Signed-off-by:
-
Alexandre Belloni authored
commit 467a44b0 upstream. Trying to use the at91_adc driver while not using device tree is ending up in a kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 00000004 [...] [<c01f3510>] (at91_adc_probe) from [<c0183828>] (platform_drv_probe+0x18/0x48) [<c0183828>] (platform_drv_probe) from [<c01824a4>] (driver_probe_device+0x100/0x218) [<c01824a4>] (driver_probe_device) from [<c0182648>] (__driver_attach+0x8c/0x90) [<c0182648>] (__driver_attach) from [<c0180de4>] (bus_for_each_dev+0x58/0x88) [<c0180de4>] (bus_for_each_dev) from [<c0181c7c>] (bus_add_driver+0xd4/0x1d4) [<c0181c7c>] (bus_add_driver) from [<c0182c40>] (driver_register+0x78/0xf4) [<c0182c40>] (driver_register) from [<c0008998>] (do_one_initcall+0xe8/0x14c) [<c0008998>] (do_one_initcall) from [<c02f0b50>] (kernel_init_freeable+0xec/0x1b4) [<c02f0b50>] (kernel_init_freeable) from [<c022acdc>] (kernel_init+0x8/0xe4) [<c022acdc>] (kernel_init) from [<c0009670>] (ret_from_fork+0x14/0x24) This is because the at91_adc_caps structure is mandatory but is not filled when using platform_data. Correct that by using an id_table. It ensues that the driver will not match "at91_adc" anymore but it was crashing anyway. Fixes: c4601666 (iio: at91: ADC start-up time calculation changed since at91sam9x5) Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Tested-by:
Josh Wu <josh.wu@atmel.com> Acked-by:
-
Denis Turischev authored
commit c09ec25d upstream. The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all. One example is Compulab's mini-desktop, the Intense-PC2. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. This patch should be backported to stable kernels as old as 3.12, that contain the commit 638298dc "xhci: Fix spurious wakeups after S5 on Haswell" Signed-off-by:
Denis Turischev <denis@compulab.co.il> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Helmut Schaa authored
commit 5998be87 upstream. Since commit 558ff225 (ath9k: fix ps-poll responses under a-mpdu sessions) non-data frames would have gotten a sequence number from a TIDs sequence counter instead of using the global sequence counter. This can lead to instable connections. To fix this only select the correct TID if we are processing a data frame. Furthermore, prevent non-data frames to get a sequence number from a TID sequence counter by adding a check to ath_tx_setup_buffer. Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Fejes József <jozsef.fejes@gmail.com> Signed-off-by:
-
Kieran Clancy authored
commit 3eba563e upstream. Address a regression caused by commit ad332c8a: (ACPI / EC: Clear stale EC events on Samsung systems) After the earlier patch, there was found to be a race condition on some earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was sometimes discarding a new EC event before its GPE was triggered by the system. In the case of these systems, this meant that the "lid open" event was not registered on resume if that was the cause of the wake, leading to problems when attempting to close the lid to suspend again. After testing on a number of Samsung systems, both those affected by the previous EC bug and those affected by the race condition, it seemed that the best course of action was to process rather than discard the events. On Samsung systems which accumulate stale EC events, there does not seem to be any adverse side-effects of running the associated _Q methods. This patch adds an argument to the static function acpi_ec_sync_query so that it may be used within the acpi_ec_clear loop in place of acpi_ec_query_unlocked which was used previously. With thanks to Stefan Biereigel for reporting the issue, and for all the people who helped test the new patch on affected systems. Fixes: ad332c8a (ACPI / EC: Clear stale EC events on Samsung systems) References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173Reported-by:
Stefan Biereigel <stefan@biereigel.de> Signed-off-by:
Kieran Clancy <clancy.kieran@gmail.com> Tested-by:
Dennis Jansen <dennis.jansen@web.de> Tested-by:
Nicolas Porcel <nicolasporcel06@gmail.com> Tested-by:
Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by:
Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by:
Giannis Koutsou <giannis.koutsou@gmail.com> Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Michael Neuling authored
commit e6b8fd02 upstream. We can't take an IRQ when we're about to do a trechkpt as our GPR state is set to user GPR values. We've hit this when running some IBM Java stress tests in the lab resulting in the following dump: cpu 0x3f: Vector: 700 (Program Check) at [c000000007eb3d40] pc: c000000000050074: restore_gprs+0xc0/0x148 lr: 00000000b52a8184 sp: ac57d360 msr: 8000000100201030 current = 0xc00000002c500000 paca = 0xc000000007dbfc00 softe: 0 irq_happened: 0x00 pid = 34535, comm = Pooled Thread # R00 = 00000000b52a8184 R16 = 00000000b3e48fda R01 = 00000000ac57d360 R17 = 00000000ade79bd8 R02 = 00000000ac586930 R18 = 000000000fac9bcc R03 = 00000000ade60000 R19 = 00000000ac57f930 R04 = 00000000f6624918 R20 = 00000000ade79be8 R05 = 00000000f663f238 R21 = 00000000ac218a54 R06 = 0000000000000002 R22 = 000000000f956280 R07 = 0000000000000008 R23 = 000000000000007e R08 = 000000000000000a R24 = 000000000000000c R09 = 00000000b6e69160 R25 = 00000000b424cf00 R10 = 0000000000000181 R26 = 00000000f66256d4 R11 = 000000000f365ec0 R27 = 00000000b6fdcdd0 R12 = 00000000f66400f0 R28 = 0000000000000001 R13 = 00000000ada71900 R29 = 00000000ade5a300 R14 = 00000000ac2185a8 R30 = 00000000f663f238 R15 = 0000000000000004 R31 = 00000000f6624918 pc = c000000000050074 restore_gprs+0xc0/0x148 cfar= c00000000004fe28 dont_restore_vec+0x1c/0x1a4 lr = 00000000b52a8184 msr = 8000000100201030 cr = 24804888 ctr = 0000000000000000 xer = 0000000000000000 trap = 700 This moves tm_recheckpoint to a C function and moves the tm_restore_sprs into that function. It then adds IRQ disabling over the trechkpt critical section. It also sets the TEXASR FS in the signals code to ensure this is never set now that we explictly write the TM sprs in tm_recheckpoint. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> [ luis: backported to 3.11: used mikey's backport to 3.10, which picks the definition of TEXASR_FS from commit e4e38121 ("KVM: PPC: Book3S HV: Add transactional memory support") ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 7bacc782 upstream. This feature has been causing trouble - disable it for now. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Rik van Riel authored
commit 107437fe upstream. Changing PTEs and PMDs to pte_numa & pmd_numa is done with the mmap_sem held for reading, which means a pmd can be instantiated and turned into a numa one while __handle_mm_fault() is examining the value of old_pmd. If that happens, __handle_mm_fault() should just return and let the page fault retry, instead of throwing an oops. This is handled by the test for pmd_trans_huge(*pmd) below. Signed-off-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Reported-by:
Sunil Pandey <sunil.k.pandey@intel.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de> Cc: linux-mm@kvack.org Cc: lwoodman@redhat.com Cc: dave.hansen@intel.com Link: http://lkml.kernel.org/r/20140429153615.2d72098e@annuminas.surriel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
- 09 Jun, 2014 31 commits
-
-
Eric Dumazet authored
commit 404ca80e upstream. A va_list needs to be copied in case it needs to be used twice. Thanks to Hugh for debugging this issue, leading to various panics. Tested: lpq84:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h" >/proc/sys/kernel/core_pattern 'produce_core' is simply : main() { *(int *)0 = 1;} lpq84:~# ./produce_core Segmentation fault (core dumped) lpq84:~# dmesg | tail -1 [ 614.352947] Core dump to |/foobar12345 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 (null) pipe failed Notice the last argument was replaced by a NULL (we were lucky enough to not crash, but do not try this on your production machine !) After fix : lpq83:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h" >/proc/sys/kernel/core_pattern lpq83:~# ./produce_core Segmentation fault lpq83:~# dmesg | tail -1 [ 740.800441] Core dump to |/foobar12345 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 pipe failed Fixes: 5fe9d8ca ("coredump: cn_vprintf() has no reason to call vsnprintf() twice") Signed-off-by:
Eric Dumazet <edumazet@google.com> Diagnosed-by:
Hugh Dickins <hughd@google.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Kirill A. Shutemov authored
commit b5a8cad3 upstream. Sasha Levin has reported two THP BUGs[1][2]. I believe both of them have the same root cause. Let's look to them one by one. The first bug[1] is "kernel BUG at mm/huge_memory.c:1829!". It's BUG_ON(mapcount != page_mapcount(page)) in __split_huge_page(). From my testing I see that page_mapcount() is higher than mapcount here. I think it happens due to race between zap_huge_pmd() and page_check_address_pmd(). page_check_address_pmd() misses PMD which is under zap: CPU0 CPU1 zap_huge_pmd() pmdp_get_and_clear() __split_huge_page() anon_vma_interval_tree_foreach() __split_huge_page_splitting() page_check_address_pmd() mm_find_pmd() /* * We check if PMD present without taking ptl: no * serialization against zap_huge_pmd(). We miss this PMD, * it's not accounted to 'mapcount' in __split_huge_page(). */ pmd_present(pmd) == 0 BUG_ON(mapcount != page_mapcount(page)) // CRASH!!! page_remove_rmap(page) atomic_add_negative(-1, &page->_mapcount) The second bug[2] is "kernel BUG at mm/huge_memory.c:1371!". It's VM_BUG_ON_PAGE(!PageHead(page), page) in zap_huge_pmd(). This happens in similar way: CPU0 CPU1 zap_huge_pmd() pmdp_get_and_clear() page_remove_rmap(page) atomic_add_negative(-1, &page->_mapcount) __split_huge_page() anon_vma_interval_tree_foreach() __split_huge_page_splitting() page_check_address_pmd() mm_find_pmd() pmd_present(pmd) == 0 /* The same comment as above */ /* * No crash this time since we already decremented page->_mapcount in * zap_huge_pmd(). */ BUG_ON(mapcount != page_mapcount(page)) /* * We split the compound page here into small pages without * serialization against zap_huge_pmd() */ __split_huge_page_refcount() VM_BUG_ON_PAGE(!PageHead(page), page); // CRASH!!! So my understanding the problem is pmd_present() check in mm_find_pmd() without taking page table lock. The bug was introduced by me commit with commit 117b0791. Sorry for that. :( Let's open code mm_find_pmd() in page_check_address_pmd() and do the check under page table lock. Note that __page_check_address() does the same for PTE entires if sync != 0. I've stress tested split and zap code paths for 36+ hours by now and don't see crashes with the patch applied. Before it took <20 min to trigger the first bug and few hours for second one (if we ignore first). [1] https://lkml.kernel.org/g/<53440991.9090001@oracle.com> [2] https://lkml.kernel.org/g/<5310C56C.60709@oracle.com> Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Mizuma, Masayoshi authored
commit 7848a4bf upstream. soft lockup in freeing gigantic hugepage fixed in commit 55f67141 "mm: hugetlb: fix softlockup when a large number of hugepages are freed." can happen in return_unused_surplus_pages(), so let's fix it. Signed-off-by:
Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Signed-off-by:
-
Peter Foley authored
commit 82c04ff8 upstream. The SYSTEM_TRUSTED_KEYRING config option is not in any menu, causing it to show up in the toplevel of the kernel configuration. Fix this by moving it under the General Setup menu. Signed-off-by:
Peter Foley <pefoley2@pefoley.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit bcddee29 upstream. Avoid a possible segfault. Noticed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 8c79bae6 upstream. Avoid a possible segfault. Noticed-by:
-
Quentin Casasnovas authored
commit 74073c9d upstream. On bo reservation failure, we end up leaking fpriv. v2 (chk): rebased and added missing free on vm failure as well Fixes: 5e386b57 ("drm/radeon: fix missing bo reservation") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Quentin Casasnovas <quentin.casasnovas@oracle.com> Signed-off-by:
Christian König <christian.koenig@amd.com> [ kamal: backport to 3.13-stable: omit radeon_vm_init() return check ] Signed-off-by:
-
Alex Deucher authored
commit 7e1858f9 upstream. If the new mc ucode is available. Signed-off-by:
-
Alex Deucher authored
commit 277babc3 upstream. Fixes mclk stability on certain asics. v2: print out mc firmware version used and size bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992Signed-off-by:
-
Alex Deucher authored
commit 1ebe9280 upstream. May fix stability issues with some newer cards. v2: print out mc firmware version used and size Signed-off-by:
-
Alex Deucher authored
commit 90c4cde9 upstream. Don't try and runtime suspend the APU in PX systems. We only want to power down the dGPU. v2: fix harder v3: fix stupid typo v4: consolidate runpm enablement to a single flag bugs: https://bugs.freedesktop.org/show_bug.cgi?id=75127 https://bugzilla.kernel.org/show_bug.cgi?id=72701Signed-off-by:
-
Alex Deucher authored
commit 57700ad1 upstream. Setting higher mclks seems to cause stability issues on some R7 260X boards. Disable it for now for stability until we find a proper fix. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992Signed-off-by:
-
Tony Lindgren authored
commit d758c9c1 upstream. The lack of pm_runtime_resume handling for the device state leads into device wake-up interrupts not working after a while for runtime PM. Also, serial-omap is confused about the use of device_may_wakeup. The checks for device_may_wakeup should only be done for suspend and resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up events for PM runtime should always be enabled. The lack of pm_runtime_resume handling leads into device wake-up interrupts not working after a while for runtime PM. Rather than try to patch over the issue of adding complex tests to the pm_runtime_resume, let's fix the issues properly: 1. Make serial_omap_enable_wakeup deal with all internal PM state handling so we don't need to test for up->wakeups_enabled elsewhere. Later on once omap3 boots in device tree only mode we can also remove the up->wakeups_enabled flag and rely on the wake-up interrupt enable/disable state alone. 2. Do the device_may_wakeup checks in suspend and resume only, for runtime PM the wake-up events need to be always enabled. 3. Finally just call serial_omap_enable_wakeup and make sure we call it also in pm_runtime_resume. 4. Note that we also have to use disable_irq_nosync as serial_omap_irq calls pm_runtime_get_sync. Fixes: 2a0b965c (serial: omap: Add support for optional wake-up) Signed-off-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit 03367ef5 upstream. Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This functionality is needed by kexec in Linux. To use this functionality we need to negotiate version 3.0 of the VMBUS protocol. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Michael Ulbricht authored
commit 895d240d upstream. By specifying NO_UNION_NORMAL the ACM driver does only use the first two USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA interfaces are left to the USB serial driver. Signed-off-by:
Michael Ulbricht <michael.ulbricht@systec-electronic.com> Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Alan Stern authored
commit a2ff864b upstream. The code in hcd-pci.c that matches up EHCI controllers with their companion UHCI or OHCI controllers assumes that the private drvdata fields don't get set too early. However, it turns out that this field gets set by usb_create_hcd(), before hcd-pci expects it, and this can result in a crash when two controllers are probed in parallel (as can happen when a new controller card is hotplugged). The companions_rwsem lock was supposed to prevent this sort of thing, but usb_create_hcd() is called outside the scope of the rwsem. A simple solution is to check that the root-hub pointer has been initialized as well as the drvdata field. This doesn't happen until usb_add_hcd() is called; that call and the check are both protected by the rwsem. This patch should be applied to stable kernels from 3.10 onward. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Stefani Seibold <stefani@seibold.net> Tested-by:
-
Johan Hovold authored
commit bd73bd88 upstream. Fix regression introduced by commit 8e493ca1 ("USB: usb_wwan: fix bulk-urb allocation") by making sure to require both bulk-in and out endpoints during port probe. The original option driver (which usb_wwan is based on) was written under the assumption that either endpoint could be missing, but evidently this cannot have been tested properly. Specifically, it would handle opening a device without bulk-in (but would blow up during resume which was implemented later), but not a missing bulk-out in write() (although it is handled in some places such as write_room()). Fortunately (?), the driver also got the test for missing endpoints wrong so the urbs were in fact always allocated, although they would be initialised using the wrong endpoint address (0) and any submission of such an urb would fail. The commit mentioned above fixed the test for missing endpoints but thereby exposed the other bugs which would now generate null-pointer exceptions rather than failed urb submissions. The regression was introduced in v3.7, but the offending commit was also marked for stable. Reported-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Tested-by:
-
Aaron Sanders authored
commit b16c02fb upstream. Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays: LD960: 03f0:0B39 LCM220: 03f0:3139 LCM960: 03f0:3239 [ Johan: fix indentation and sort PIDs numerically ] Signed-off-by:
Aaron Sanders <aaron.sanders@hp.com> Signed-off-by:
-
Tristan Bruns authored
commit 72b30079 upstream. Signed-off-by:
Tristan Bruns <tristan@tristanbruns.de> Signed-off-by:
-
Daniele Palmas authored
commit d6de486b upstream. option driver, added VID/PID for Telit UE910v2 modem Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 2e01280d upstream. This reverts commit 1ebca9da. This device was erroneously added to the sierra driver even though it's not a Sierra device and was already handled by the option driver. Cc: Richard Farina <sidhayn@gmail.com> Signed-off-by:
-
Michele Baldessari authored
commit efe26e16 upstream. Custom VID/PIDs for Brainboxes cards as reported in https://bugzilla.redhat.com/show_bug.cgi?id=1071914Signed-off-by:
Michele Baldessari <michele@acksyn.org> Signed-off-by:
-
Larry Finger authored
commit 33c84bc1 upstream. Zero-initializing ether_type masked that the ether type would never be obtained for 8021x packets and the comparison against eapol_type would always fail. Reported-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
commit f764cd68 upstream. Zero-initializing ether_type masked that the ether type would never be obtained for 8021x packets and the comparison against eapol_type would always fail. Reported-by:
-
Alexander Usyskin authored
commit 34ec4366 upstream. Ignore client writing state during cb completion to fix a memory leak. When moving cbs to the completion list we should not look at writing_state as this state can be already overwritten by next write, the fact that a cb is on the write waiting list means that it was already written to the HW and we can safely complete it. Same pays for wait in poll handler, we do not have to check the state wake is done after completion list processing. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Tomas Winkler authored
commit 5e6533a6 upstream. NM and SPS FW types that may run on ME device on server platforms do not have valid MEI/HECI interface and driver should not be bound to it as this might lead to system hung. In practice not all BIOSes effectively hide such devices from the OS and in some cases it is not possible. We determine FW type by examining Host FW status registers in order to unbind the driver. In this patch we are adding check for ME on Cougar Point, Lynx Point Devices Signed-off-by:
Nikola Ciprich <nikola.ciprich@linuxbox.cz> Signed-off-by:
-
Chris Mason authored
commit c98235cb upstream. The mlx4 driver is triggering schedules while atomic inside mlx4_en_netpoll: spin_lock_irqsave(&cq->lock, flags); napi_synchronize(&cq->napi); ^^^^^ msleep here mlx4_en_process_rx_cq(dev, cq, 0); spin_unlock_irqrestore(&cq->lock, flags); This was part of a patch by Alexander Guller from Mellanox in 2011, but it still isn't upstream. Signed-off-by:
Chris Mason <clm@fb.com> Acked-By:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sachin Prabhu authored
commit c11f1df5 upstream. Problem reported in Red Hat bz 1040329 for strict writes where we cache only when we hold oplock and write direct to the server when we don't. When we receive an oplock break, we first change the oplock value for the inode in cifsInodeInfo->oplock to indicate that we no longer hold the oplock before we enqueue a task to flush changes to the backing device. Once we have completed flushing the changes, we return the oplock to the server. There are 2 ways here where we can have data corruption 1) While we flush changes to the backing device as part of the oplock break, we can have processes write to the file. These writes check for the oplock, find none and attempt to write directly to the server. These direct writes made while we are flushing from cache could be overwritten by data being flushed from the cache causing data corruption. 2) While a thread runs in cifs_strict_writev, the machine could receive and process an oplock break after the thread has checked the oplock and found that it allows us to cache and before we have made changes to the cache. In that case, we end up with a dirty page in cache when we shouldn't have any. This will be flushed later and will overwrite all subsequent writes to the part of the file represented by this page. Before making any writes to the server, we need to confirm that we are not in the process of flushing data to the server and if we are, we should wait until the process is complete before we attempt the write. We should also wait for existing writes to complete before we process an oplock break request which changes oplock values. We add a version specific downgrade_oplock() operation to allow for differences in the oplock values set for the different smb versions. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Reviewed-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Larry Finger authored
commit 9452bf56 upstream. This makes the follow-on check for psta != NULL pointless and makes the whole exercise rather pointless. This is another case of why blindly zero-initializing variables when they are declared is bad. Reported-by:
-
Kailang Yang authored
commit 8dc9abb9 upstream. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
commit 67807ce5 upstream. When we plug a 3-ring headset on the Dell machine (VID: 0x10ec0255, SID: 0x1028067f), the headset mic can't be detected, after apply this patch, the headset mic can work well. BugLink: https://bugs.launchpad.net/bugs/1297581 Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
