- 09 Jan, 2015 2 commits
-
-
Larry Finger authored
Proper operation with the rewritten PCI mini driver requires that a flag be set when interrupts are enabled. This flag was missed. This patch is one of three needed to fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-by:
Catalin Iacob <iacobcatalin@gmail.com> Tested-by:
John W. Linville <linville@tuxdriver.com> (cherry picked from commit 87141db0) Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Larry Finger authored
In the major update of the rtlwifi-family of drivers, one of the callback entries was missed, which leads to memory corruption. Unfortunately, this corruption never caused a kernel oops, but showed up in other parts of the system. This patch is one of three needed to fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951. Signed-off-by:
-
- 22 Dec, 2014 38 commits
-
-
Sasha Levin authored
Signed-off-by: -
Ben Hutchings authored
Upstream commit 58f09e00 was applied to the wrong function when cherry-picked for 2.6.32.61. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Willy Tarreau <w@1wt.eu> (cherry picked from commit a99c4d9b) (cherry picked from commit HEAD) Signed-off-by:
-
Matthew Leach authored
When copying in a struct msghdr from the user, if the user has set the msg_namelen parameter to a negative value it gets clamped to a valid size due to a comparison between signed and unsigned values. Ensure the syscall errors when the user passes in a negative value. Signed-off-by:
Matthew Leach <matthew.leach@arm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit dbb490b9) Signed-off-by:
-
Dan Carpenter authored
If kmsg->msg_namelen > sizeof(struct sockaddr_storage) then in the original code that would lead to memory corruption in the kernel if you had audit configured. If you didn't have audit configured it was harmless. There are some programs such as beta versions of Ruby which use too large of a buffer and returning an error code breaks them. We should clamp the ->msg_namelen value instead. Fixes: 1661bf36 ("net: heap overflow in __audit_sockaddr()") Reported-by:
Eric Wong <normalperson@yhbt.net> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Tested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Nikola Pajkovsky authored
crypto_larval_lookup should only return a larval if it created one. Any larval created by another entity must be processed through crypto_larval_wait before being returned. Otherwise this will lead to a larval being killed twice, which will most likely lead to a crash. Cc: stable@vger.kernel.org Reported-by:
Kees Cook <keescook@chromium.org> Tested-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 77dbd7a9) Signed-off-by:
-
James Bottomley authored
USB surprise removal of sr is triggering an oops in scsi_dispatch_command(). What seems to be happening is that USB is hanging on to a queue reference until the last close of the upper device, so the crash is caused by surprise remove of a mounted CD followed by attempted unmount. The problem is that USB doesn't issue its final commands as part of the SCSI teardown path, but on last close when the block queue is long gone. The long term fix is probably to make sr do the teardown in the same way as sd (so remove all the lower bits on ejection, but keep the upper disk alive until last close of user space). However, the current oops can be simply fixed by not allowing any commands to be sent to a dead queue. Cc: stable@kernel.org Signed-off-by:
James Bottomley <JBottomley@Parallels.com> (cherry picked from commit bfe159a5) Signed-off-by:
-
Ben Hutchings authored
This reverts commit 2af3af56, which was commit 6c4088ac upstream. This broke compilation of the driver in 2.6.32.y as the early_io{remap,unmap}() functions are not defined for ia64. The driver can *only* be built for ia64 (even in current mainline), so a fix for x86_64 is pointless. Signed-off-by:
-
Linus Torvalds authored
Add a new interface, add_device_randomness() for adding data to the random pool that is likely to differ between two devices (or possibly even per boot). This would be things like MAC addresses or serial numbers, or the read-out of the RTC. This does *not* add any actual entropy to the pool, but it initializes the pool to different values for devices that might otherwise be identical and have very little entropy available to them (particularly common in the embedded world). [ Modified by tytso to mix in a timestamp, since there may be some variability caused by the time needed to detect/configure the hardware in question. ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org (cherry picked from commit a2080a67) Signed-off-by:
-
bjschuma@gmail.com authored
This allows distros to remove the line from their modprobe configuration. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Cc: stable@vger.kernel.org Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> (cherry picked from commit 425e776d) Signed-off-by:
-
Greg Pearson authored
efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP EFI system table and setup an early console for printk output. The routine uses ioremap/iounmap to setup access to the HCDP/PCDP table information. The call to ioremap is happening early in the boot process which leads to a panic on x86_64 systems: panic+0x01ca do_exit+0x043c oops_end+0x00a7 no_context+0x0119 __bad_area_nosemaphore+0x0138 bad_area_nosemaphore+0x000e do_page_fault+0x0321 page_fault+0x0020 reserve_memtype+0x02a1 __ioremap_caller+0x0123 ioremap_nocache+0x0012 efi_setup_pcdp_console+0x002b setup_arch+0x03a9 start_kernel+0x00d4 x86_64_start_reservations+0x012c x86_64_start_kernel+0x00fe This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console() with calls to early_ioremap/early_iounmap which can be called during early boot. This patch was tested on an x86_64 prototype system which uses the HCDP/PCDP table for early console setup. Signed-off-by:Greg Pearson <greg.pearson@hp.com> Acked-by:
Khalid Aziz <khalid.aziz@hp.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Thomas Jarosch authored
Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-. These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts. Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug. Tested on the following boards: - Intel DH61CR: Affected - Intel DH67BL: Affected - Intel S1200KP server board: Affected - Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed. According to reports on the net, the Intel DH61WW board is also affected. Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation. Signed-off-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by:
Charlie Suffin <charlie.suffin@stratus.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> (cherry picked from commit f67fd55f) Signed-off-by:
-
OGAWA Hirofumi authored
ratelimit_state initialization of printk_ratelimited() seems broken. This fixes it by using DEFINE_RATELIMIT_STATE() to initialize spinlock properly. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Yong Zhang authored
When __ratelimit() returns 1 this means that we can go ahead. Signed-off-by:
Yong Zhang <yong.zhang@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
This reverts commit c8cdf3f9, applied on linux 2.6.32.53 stable release, as it can introduce the following build error while building 2.6.32.y on armel: linux-2.6.32/drivers/mmc/host/mmci.c: In function 'mmci_cmd_irq': linux-2.6.32/drivers/mmc/host/mmci.c:237: error: implicit declaration of function 'dma_inprogress' linux-2.6.32/drivers/mmc/host/mmci.c:238: error: implicit declaration of function 'mmci_dma_data_error' Aparently the commit was wrongly pushed into 2.6.32, since it depends on commit c8ebae37 ("ARM: mmci: add dmaengine-based DMA support"), not present on 2.6.32. Signed-off-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 80375fc4) (cherry picked from commit HEAD) Signed-off-by:
-
Tyler Hicks authored
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a page, zeroes out the appropriate portions, and then encrypts the page before writing it to the lower filesystem. It was unkillable and due to the lack of sparse file support could result in tying up a large portion of system resources, while encrypting pages of zeros, with no way for the truncate operation to be stopped from userspace. This patch adds the ability for ecryptfs_write() to detect a pending fatal signal and return as gracefully as possible. The intent is to leave the lower file in a useable state, while still allowing a user to break out of the encryption loop. If a pending fatal signal is detected, the eCryptfs inode size is updated to reflect the modified inode size and then -EINTR is returned. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Cc: <stable@vger.kernel.org> (cherry picked from commit 5e6f0d76) Signed-off-by:
-
Joe Perches authored
Add a printk_ratelimited statement expression macro that uses a per-call ratelimit_state so that multiple subsystems output messages are not suppressed by a global __ratelimit state. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: s/_rl/_ratelimited/g] Signed-off-by:
Joe Perches <joe@perches.com> Cc: Naohiro Ooiwa <nooiwa@miraclelinux.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
don't do aggregation related stuff for 'AP mode client power save handling' if aggregation is not enabled in the driver, otherwise it will lead to panic because those data structures won't be never intialized in 'ath_tx_node_init' if aggregation is disabled EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k] EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000 ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860 task.ti=f40dc000) Stack: 0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac f40e1cb0 f8186741 f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001 c0b4ba43 00000000 0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac f2a30000 00010020 Call Trace: [<f8186741>] ath9k_sta_notify+0x41/0x50 [ath9k] [<f8186700>] ? ath9k_get_survey+0x110/0x110 [ath9k] [<f922988d>] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350 [mac80211] [<c018dc75>] ? __module_address+0x95/0xb0 [<f92465b3>] ap_sta_ps_end+0x63/0xa0 [mac80211] [<f9246746>] ieee80211_rx_h_sta_process+0x156/0x2b0 [mac80211] [<f9247d1e>] ieee80211_rx_handlers+0xce/0x510 [mac80211] [<c018440b>] ? trace_hardirqs_on+0xb/0x10 [<c056936e>] ? skb_queue_tail+0x3e/0x50 [<f9248271>] ieee80211_prepare_and_rx_handle+0x111/0x750 [mac80211] [<f9248bf9>] ieee80211_rx+0x349/0xb20 [mac80211] [<f9248949>] ? ieee80211_rx+0x99/0xb20 [mac80211] [<f818b0b8>] ath_rx_tasklet+0x818/0x1d00 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187b33>] ath9k_tasklet+0xf3/0x1c0 [ath9k] [<c0151b7e>] tasklet_action+0xbe/0x180 Cc: stable@kernel.org Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Reported-by:
Ashwin Mendonca <ashwinloyal@gmail.com> Tested-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Ulf Hansson authored
When getting a cmd irq during an ongoing data transfer with dma, the dma job were never terminated. This is now corrected. Cc: <stable@vger.kernel.org> Tested-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Per Forlin <per.forlin@stericsson.com> Signed-off-by:
Ulf Hansson <ulf.hansson@stericsson.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> (cherry picked from commit 3b6e3c73) Signed-off-by:
-
Linus Torvalds authored
This reverts commit de28f25e. It results in resume problems for various people. See for example http://thread.gmane.org/gmane.linux.kernel/1233033 http://thread.gmane.org/gmane.linux.kernel/1233389 http://thread.gmane.org/gmane.linux.kernel/1233159 http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877 and the fedora and ubuntu bug reports https://bugzilla.redhat.com/show_bug.cgi?id=767248 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569 which got bisected down to the stable version of this commit. Reported-by:
Jonathan Nieder <jrnieder@gmail.com> Reported-by:
Phil Miller <mille121@illinois.edu> Reported-by:
Philip Langdale <philipl@overt.org> Reported-by:
Tim Gardner <tim.gardner@canonical.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg KH <gregkh@suse.de> Cc: stable@kernel.org # for stable kernels that applied the original Signed-off-by:
-
Thomas Gleixner authored
commit de28f25e upstream. If a device is shutdown, then there might be a pending interrupt, which will be processed after we reenable interrupts, which causes the original handler to be run. If the old handler is the (broadcast) periodic handler the shutdown state might hang the kernel completely. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> (cherry picked from commit d88048a3)
-
J. Bruce Fields authored
This fixes a regression from 68a33961 "nfsd4: shut down more of delegation earlier". After that commit, nfs4_set_delegation() failures result in nfs4_put_delegation being called, but nfs4_put_delegation doesn't free the nfs4_file that has already been set by alloc_init_deleg(). This can result in an oops on later unmounting the exported filesystem. Note also delaying the fi_had_conflict check we're able to return a better error (hence give 4.1 clients a better idea why the delegation failed; though note CONFLICT isn't an exact match here, as that's supposed to indicate a current conflict, but all we know here is that there was one recently). Reported-by:
Toralf Förster <toralf.foerster@gmx.de> Tested-by:
J. Bruce Fields <bfields@redhat.com> (cherry picked from commit bf7bd3e9) Signed-off-by:
-
Benjamin Herrenschmidt authored
This can be set by quirks/drivers to be used by the architecture code that assigns the MSI addresses. We additionally add verification in the core MSI code that the values assigned by the architecture do satisfy the limitation in order to fail gracefully if they don't (ie. the arch hasn't been updated to deal with that quirk yet). Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> (cherry picked from commit f144d149) Signed-off-by:
-
Johannes Weiner authored
Commit 3812c8c8 ("mm: memcg: do not trap chargers with full callstack on OOM") assumed that only a few places that can trigger a memcg OOM situation do not return VM_FAULT_OOM, like optional page cache readahead. But there are many more and it's impractical to annotate them all. First of all, we don't want to invoke the OOM killer when the failed allocation is gracefully handled, so defer the actual kill to the end of the fault handling as well. This simplifies the code quite a bit for added bonus. Second, since a failed allocation might not be the abrupt end of the fault, the memcg OOM handler needs to be re-entrant until the fault finishes for subsequent allocation attempts. If an allocation is attempted after the task already OOMed, allow it to bypass the limit so that it can quickly finish the fault and invoke the OOM killer. Reported-by:
azurIt <azurit@pobox.sk> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: <stable@kernel.org> Signed-off-by:
-
Takashi Iwai authored
DPCM can update the FE/BE connection states totally asynchronously from the FE's PCM state. Most of FE/BE state changes are protected by mutex, so that they won't race, but there are still some actions that are uncovered. For example, suppose to switch a BE while a FE's stream is running. This would call soc_dpcm_runtime_update(), which sets FE's runtime_update flag, then sets up and starts BEs, and clears FE's runtime_update flag again. When a device emits XRUN during this operation, the PCM core triggers snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this isn't blocked by the mutex, thus it kicks off DPCM's trigger action. It eventually updates and clears FE's runtime_update flag while soc_dpcm_runtime_update() is running concurrently, and it results in confusion. Usually, for avoiding such a race, we take a lock. There is a PCM stream lock for that purpose. However, as already mentioned, the trigger action is atomic, and we can't take the lock for the whole soc_dpcm_runtime_update() or other operations that include the lengthy jobs like hw_params or prepare. This patch provides an alternative solution. This adds a way to defer the conflicting trigger callback to be executed at the end of FE/BE state changes. For doing it, two things are introduced: - Each runtime_update state change of FEs is protected via PCM stream lock. - The FE's trigger callback checks the runtime_update flag. If it's not set, the trigger action is executed there. If set, mark the pending trigger action and returns immediately. - At the exit of runtime_update state change, it checks whether the pending trigger is present. If yes, it executes the trigger action at this point. Reported-and-tested-by:
Qiao Zhou <zhouqiao@marvell.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org (cherry picked from commit ea9d0d77) Signed-off-by:
-
Kuninori Morimoto authored
FSI doesn't support PAUSE. Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Alexander Gordeev authored
If populate_msi_sysfs() function failed msix_capability_init() must return the error code, but it returns the success instead. This update fixes the described misbehaviour. Signed-off-by:
Alexander Gordeev <agordeev@redhat.com> Signed-off-by:
Tejun Heo <tj@kernel.org> (cherry picked from commit 2adc7907) Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for simplifying the min/max quirk table. Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit e2f61102) Signed-off-by:
-
Hans de Goede authored
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas. Signed-off-by:
-
Hans de Goede authored
On some newer laptops with a trackpoint the physical buttons for the trackpoint have been removed to allow for a larger touchpad. On these laptops the buttonpad has clearly marked areas on the top which are to be used as trackpad buttons. Users of the event device-node need to know about this, so that they can properly interpret BTN_LEFT events as being a left / right / middle click depending on where on the button pad the clicking finger is. This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers for such buttonpads will use to signal to the user that this buttonpad not only has the normal bottom button area, but also a top button area. Signed-off-by:
-
Hans de Goede authored
Fill in the new serio firmware_id sysfs attribute for pnp instantiated 8042 serio ports. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
-
Hans de Goede authored
serio devices exposed via platform firmware interfaces such as ACPI may provide additional identifying information of use to userspace. We don't associate the serio devices with the firmware device (we don't set it as parent), so there's no way for userspace to make use of this information. We cannot change the parent for serio devices instantiated though a firmware interface as that would break suspend / resume ordering. Therefore this patch adds a new firmware_id sysfs attribute so that userspace can get a string from there with any additional identifying information the firmware interface may provide. Signed-off-by:
-
Cong Wang authored
Since f660daac (oom: thaw threads if oom killed thread is frozen before deferring) OOM killer relies on being able to thaw a frozen task to handle OOM situation but a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) has reorganized the code and stopped clearing freeze flag in __thaw_task. This means that the target task only wakes up and goes into the fridge again because the freezing condition hasn't changed for it. This reintroduces the bug fixed by f660daac. Fix the issue by checking for TIF_MEMDIE thread flag in freezing_slow_path and exclude the task from freezing completely. If a task was already frozen it would get woken by __thaw_task from OOM killer and get out of freezer after rechecking freezing(). Changes since v1 - put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator as per Oleg - return __thaw_task into oom_scan_process_thread because oom_kill_process will not wake task in the fridge because it is sleeping uninterruptible [mhocko@suse.cz: rewrote the changelog] Fixes: a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) Cc: 3.3+ <stable@vger.kernel.org> # 3.3+ Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 51fae6da) Signed-off-by:
-
Anton Blanchard authored
I used some 64 bit instructions when adding the 32 bit getcpu VDSO function. Fix it. Fixes: 18ad51dd ("powerpc: Add VDSO version of getcpu") Cc: stable@vger.kernel.org Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 152d44a8) Signed-off-by:
-
Todd Fujinaka authored
Call igb_setup_link() when the PHY is powered up. Signed-off-by:
Todd Fujinaka <todd.fujinaka@intel.com> Reported-by:
Jeff Westfahl <jeff.westfahl@ni.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit aec653c4) Signed-off-by:
-
Eric Dumazet authored
mvneta_tx() dereferences skb to get skb->len too late, as hardware might have completed the transmit and TX completion could have freed the skb from another cpu. Fixes: 71f6d1b3 ("net: mvneta: replace Tx timer with a real interrupt") Signed-off-by:
-
Cong Wang authored
batman tries to search dev->iflink to check if it's a batman interface, but ->iflink could be 0, which is not a valid ifindex. It should just avoid iflink == 0 case. Reported-by:
Jet Chen <jet.chen@intel.com> Tested-by:
Cong Wang <cwang@twopensource.com> Signed-off-by:
-
Jeff Layton authored
A leftover lock on the list is surely a sign of a problem of some sort, but it's not necessarily a reason to panic the box. Instead, just log a warning with some info about the lock, and then delete it like we would any other lock. In the event that the filesystem declares a ->lock f_op, we may end up leaking something, but that's generally preferable to an immediate panic. Acked-by:
J. Bruce Fields <bfields@fieldses.org> Signed-off-by:
Jeff Layton <jlayton@redhat.com> (cherry picked from commit 8c3cac5e) Signed-off-by:
-
Benjamin Herrenschmidt authored
This can be set by quirks/drivers to be used by the architecture code that assigns the MSI addresses. We additionally add verification in the core MSI code that the values assigned by the architecture do satisfy the limitation in order to fail gracefully if they don't (ie. the arch hasn't been updated to deal with that quirk yet). Signed-off-by:
-
