Updating working tree with torvalds:master #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add missing header to fix compilation error. drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1575:22: error: undefined identifier 'irq_of_parse_and_map' drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1576:22: error: undefined identifier 'irq_of_parse_and_map' Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Warning log: xilinx_axienet_main.c: In function 'axienet_start_xmit_done': xilinx_axienet_main.c:617:16: warning: operation on 'lp->tx_bd_ci' may be undefined [-Wsequence-point] xilinx_axienet_main.c: In function 'axienet_start_xmit': xilinx_axienet_main.c:703:18: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point] xilinx_axienet_main.c:719:17: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point] xilinx_axienet_main.c: In function 'axienet_recv': xilinx_axienet_main.c:792:16: warning: operation on 'lp->rx_bd_ci' may be undefined [-Wsequence-point] xilinx_axienet_main.c: In function 'axienet_of_probe': xilinx_axienet_main.c:1501:21: warning: unused variable 'rc' [-Wunused-variable] Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
…linux-can/linux-can linux-can-fixes-for-3.14-20140212 Marc Kleine-Budde says: ==================== this is a pull request with one patch for net/master, for the current release cycle. Olivier Sobrie noticed and fixed that the kvaser_usb driver doesn't check the number of channels value from the hardware, which may result in writing over the bounds of an array in the driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a QMI port and a WWAN interface. CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> CC: Christian Schmiedl <christian.schmiedl@gemalto.com> CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com> CC: David McCullough <david.mccullough@accelecon.com> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
It's wrong if the device tree doesn't provide a phy-mode property for the cpsw slaves as it is documented to be required in Documentation/devicetree/bindings/net/cpsw.txt. Anyhow it's nice to catch that problem, still more as it used to work without this property up to commit 388367a (drivers: net: cpsw: use cpsw-phy-sel driver to configure phy mode) which is in v3.13-rc1. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Fix incorrect comment reported by Norbert Kiesel. Edit another comment to add more details. Also add references to algorithm (IETF draft and paper) to top of file. Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com> CC: Mythili Prabhu <mysuryan@cisco.com> CC: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Use %zu for size_t in order to avoid the following build warning in printks. drivers/net/usb/sr9800.c: In function 'sr9800_bind' drivers/net/usb/sr9800.c:826:2: warning: format '%ld' expects argument of type 'long int' but argument 5 has type 'size_t' [-Wformat] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Liu Junliang <liujunliang_ljl@163.com> Signed-off-by: David S. Miller <davem@davemloft.net>
vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing resources. In the end no one initiates freeing resources until the last reference is gone (which is on VM shotdown so might happen after a looooong time). Let's do what we probably should have done straight away: switch from kref to plain atomic, documenting the semantics, return the refcount value atomically after decrement, then use that to avoid the deadlock. Reported-by: Qin Chuanyu <qinchuanyu@huawei.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
vhost_zerocopy_callback accesses VQ right after it drops a ubuf reference. In theory, this could race with device removal which waits on the ubuf kref, and crash on use after free. Do all accesses within rcu read side critical section, and synchronize on release. Since callbacks are always invoked from bh, synchronize_rcu_bh seems enough and will help release complete a bit faster. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 0cd8f9c ("drivers: net: cpsw: enable promiscuous mode support") Enable promiscuous mode support for CPSW. Introduced a crash on an am335x based board (similiar to am335x-evm). Reason is buggy end condition in for loop in cpsw_set_promiscious() for (i = 0; i <= priv->data.slaves; i++) should be for (i = 0; i < priv->data.slaves; i++) Fix this ... Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: David S. Miller <davem@davemloft.net> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Daniel Mack <zonque@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Markus Pargmann <mpa@pengutronix.de> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
phy_init_hw not does a full PHY reset after the driver probe has finished, so any hw initialization done in the probe will be lost. Part of the timestamping functionality of the dp83640 is set up in the probe and with that lost, enabling timestamping will cause a PHY lockup, requiring a hard reset / power cycle to recover. This patch moves all the HW initialization in dp83640_probe to dp83640_config_init. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The ntc thermistor code was doing math whose temporary result might have overflowed 32-bits. We need some casts in there to make it safe. In one example I found: - pullup_uV: 1800000 - result of iio_read_channel_raw: 3226 - 1800000 * 3226 => 0x15a1cbc80 Signed-off-by: Doug Anderson <dianders@chromium.org> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Guenter Roeck <linux@roeck-us.net>
On some architectures (for example, arm), we don't end up indirectly pulling in the declaration of kzalloc() and kfree(), and so building anything that includes <linux/mlx5/driver.h> breaks. Fix this by adding an explicit include to get the declaration. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
Remove Kconfig dependency of mlx5_ib/mlx5_core on X86, since there is no such dependency in reality. Signed-off-by: Eli Cohen <eli@mellanox.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Roland Dreier <roland@purestorage.com>
Even if the 'time_before' macro expand with parentheses, the look is bad. Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver. Else we get the following errors due to missing symbols: drivers/built-in.o: In function `s6e8ax0_probe': :(.text+0x51aec): undefined reference to `lcd_device_register' :(.text+0x51c44): undefined reference to `lcd_device_unregister' Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
…river. Without that patch, a user can't select the imxfb driver when the i.MX25 and/or the i.MX27 device tree board are selected and that no boards that selects IMX_HAVE_PLATFORM_IMX_FB are compiled in. Cc: Eric Bénard <eric@eukrea.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-fbdev@vger.kernel.org Signed-off-by: Denis Carikli <denis@eukrea.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We do not enable the new efi memmap on 32-bit and thus we need to run runtime_code_page_mkexec() unconditionally there. Fix that. Reported-and-tested-by: Lejun Zhu <lejun.zhu@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Sanitize code even more to accept unsigned longs only and to not allow polling intervals below 1 second as this is unnecessary and doesn't make much sense anyway for polling errors. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1391457913-881-1-git-send-email-prarit@redhat.com Cc: Doug Thompson <dougthompson@xmission.com> Cc: <stable@vger.kernel.org>
We're using edac_mc_workq_setup() both on the init path, when we load an edac driver and when we change the polling period (edac_mc_reset_delay_period) through /sys/.../edac_mc_poll_msec. On that second path we don't need to init the workqueue which has been initialized already. Thanks to Tejun for workqueue insights. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1391457913-881-1-git-send-email-prarit@redhat.com Cc: <stable@vger.kernel.org>
Madper reported seeing the following crash, BUG: unable to handle kernel paging request at ffffffffff340003 IP: [<ffffffff81d85ba4>] efi_bgrt_init+0x9d/0x133 Call Trace: [<ffffffff81d8525d>] efi_late_init+0x9/0xb [<ffffffff81d68f59>] start_kernel+0x436/0x450 [<ffffffff81d6892c>] ? repair_env_string+0x5c/0x5c [<ffffffff81d68120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d685de>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81d6871e>] x86_64_start_kernel+0x13e/0x14d This is caused because the layout of the ACPI BGRT header on this system doesn't match the definition from the ACPI spec, and so we get a bogus physical address when dereferencing ->image_address in efi_bgrt_init(). Luckily the status field in the BGRT header clearly marks it as invalid, so we can check that field and skip BGRT initialisation. Reported-by: Madper Xie <cxie@redhat.com> Suggested-by: Toshi Kani <toshi.kani@hp.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
This fixes the build breakage introduced by c07a019 and adds support for the device control API and save/restore of the VGIC state for ARMv8. The defines were simply missing from the arm64 header files and uaccess.h must be implicitly imported from somewhere else on arm. Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tommi noticed a 'funny' lock class name: "%s#5" from a lock acquired in
process_one_work().
Maybe #fmt plus #args could be used as the lock_name to give some more
information for some fmt string like the above.
__builtin_constant_p() check is removed (as there seems no good way to
check all the variables in args list). However, by removing the check,
it only adds two additional "s for those constants.
Some lockdep name examples printed out after the change:
lockdep name wq->name
"events_long" events_long
"%s"("khelper") khelper
"xfs-data/%s"mp->m_fsname xfs-data/dm-3
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Error reported at http://marc.info/?l=linux-rdma&m=138995755801039&w=2 Fix short to int cast for big endian systems. Signed-off-by: Upinder Malhi <umalhi@cisco.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
… iser connection Fix a possible NULL pointer dereference in disconnection flow. This can happen if the target disconnected/rejected the connection request, e.g before the binding stage between iscsi connection to the transport connection. Signed-off-by: Alex Tabachnik <alext@mellanox.com> Signed-off-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
We use "tx_desc" again after we free it. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
Use correct value for obtaining traffic class from device response for Query QP request. Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
We should use rdma_vlan_dev_real_dev() instead of using vlan_dev_real_dev() when building the GID table for a vlan interface. Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
… 'ocrdma', 'qib' and 'usnic' into for-next
sparc_cpu_model isn't in asm/system.h any more, so remove a comment about it. Signed-off-by: David Howells <dhowells@redhat.com> cc: "David S. Miller" <davem@davemloft.net> cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Brian Campbell <brian.campbell@editshare.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
…wski/linux-dma-mapping Pull DMA-mapping fixes from Marek Szyprowski: "This contains fixes for incorrect atomic test in dma-mapping subsystem for ARM and x86 architecture" * 'fixes-for-v3.14' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping: x86: dma-mapping: fix GFP_ATOMIC macro usage ARM: dma-mapping: fix GFP_ATOMIC macro usage
…ernel/git/tj/wq Pull workqueue fixes from Tejun Heo: "Two workqueue fixes. One for an unlikely but possible critical bug during kworker shutdown and the other to make lockdep names a bit more descriptive" * 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: ensure @task is valid across kthread_stop() workqueue: add args to workqueue lockdep name
…ernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "Quite a few fixes this time. Three locking fixes, all marked for -stable. A couple error path fixes and some misc fixes. Hugh found a bug in memcg offlining sequence and we thought we could fix that from cgroup core side but that turned out to be insufficient and got reverted. A different fix has been applied to -mm" * 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: update cgroup_enable_task_cg_lists() to grab siglock Revert "cgroup: use an ordered workqueue for cgroup destruction" cgroup: protect modifications to cgroup_idr with cgroup_mutex cgroup: fix locking in cgroup_cfts_commit() cgroup: fix error return from cgroup_create() cgroup: fix error return value in cgroup_mount() cgroup: use an ordered workqueue for cgroup destruction nfs: include xattr.h from fs/nfs/nfs3proc.c cpuset: update MAINTAINERS entry arm, pm, vmpressure: add missing slab.h includes
…ernel/git/tj/libata Pull libata fixes from Tejun Heo: "Various device specific fixes. Nothing too interesting" * 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: ahci: disable NCQ on Samsung pci-e SSDs on macbooks ata: sata_mv: Cleanup only the initialized ports sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN ata: enable quirk from jmicron JMB350 for JMB394 ATA: SATA_MV: Add missing Kconfig select statememnt ata: pata_imx: Check the return value from clk_prepare_enable()
Fix regression caused by commit b072e53, which breaks loading nouveau driver on optimus laptops. On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0) has special requirements on the fourth parameter, which is different from ACPI specifications. So revert to the private implementation to check availability of _DSM functions instead of using common acpi_check_dsm() interface. Fixes: b072e53 (ACPI / nouveau: replace open-coded _DSM code with helper functions) Reported-and-tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> [rjw: Subject] Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
…ernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas:
"The most interesting thing here is the change to enable INTx (by
clearing PCI_COMMAND_INTX_DISABLE) if the BIOS left INTx disabled.
Apparently the Baytrail BIOS does this, which means EHCI doesn't work.
Also, fix an AHCI MSI regression and other issues with the recent MSI
changes. This also adds pci_enable_msi_exact() and
pci_enable_msix_exact(), which aren't regression fixes, but will keep
us from touching drivers twice (once to stop using the deprecated
pci_enable_msi(), etc., and again to use the *_exact() variants).
There's also a minor MVEBU fix.
Summary:
MSI:
- Fix AHCI single-MSI fallback (Alexander Gordeev)
- Fix populate_msi_sysfs() error paths (Greg Kroah-Hartman)
- Fix htmldocs problem (Masanari Iida)
- Add pci_enable_msi_exact() and pci_enable_msix_exact() (Alexander Gordeev)
- Update documentation (Alexander Gordeev)
Miscellaneous:
- mvebu: expose device ID & revision via lspci (Andrew Lunn)
- Enable INTx if the BIOS left them disabled (Bjorn Helgaas)"
* tag 'pci-v3.14-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
ahci: Fix broken fallback to single MSI mode
PCI: Enable INTx if BIOS left them disabled
PCI/MSI: Add pci_enable_msi_exact() and pci_enable_msix_exact()
PCI/MSI: Fix cut-and-paste errors in documentation
PCI/MSI: Add pci_enable_msi() documentation back
PCI/MSI: Fix pci_msix_vec_count() htmldocs failure
PCI/MSI: Fix leak of msi_attrs
PCI/MSI: Check kmalloc() return value, fix leak of name
PCI: mvebu: Use Device ID and revision from underlying endpoint
LFM (max efficiency ratio) is the max frequency at minimum voltage supported by the processor. Using LFM as the minimum P state increases performmance without affecting power. By not using P states below LFM we avoid using P states that are less power efficient. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A documentation update exposed the existance of the turbo ratio register. Update baytrail support to use the turbo range. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-cleanup: ACPI / SBS: Fix incorrect sscanf() string * acpi-dock: ACPI / dock: Make 'docked' sysfs attribute work as documented * acpi-pci: ACPI / PCI: Fix memory leak in acpi_pci_irq_enable() * acpi-dsm: ACPI / nouveau: fix probing regression related to _DSM
* acpi-pm: ACPI / thermal: fix thermal driver compile error when CONFIG_PM_SLEEP is undefined ACPI / SBS: fix SBS driver compile error when CONFIG_PM_SLEEP is undefined ACPI / fan: fix fan driver compile error when CONFIG_PM_SLEEP is undefined ACPI / button: fix button driver compile error when CONFIG_PM_SLEEP is undefined ACPI / battery: fix battery driver compile error when CONFIG_PM_SLEEP is undefined ACPI / AC: fix AC driver compile error when CONFIG_PM_SLEEP is undefined * acpi-video: Revert "ACPI: Blacklist Win8 OSI for some HP laptop 2013 models" ACPI / video: Add systems that should favour native backlight interface ACPI / video: Filter the _BCL table for duplicate brightness values
* pm-cpufreq: intel_pstate: Add support for Baytrail turbo P states intel_pstate: Use LFM bus ratio as min ratio/P state cpufreq: powernow-k8: Initialize per-cpu data-structures properly cpufreq: remove sysfs link when a cpu != policy->cpu, is removed
…el/git/tiwai/sound Pull sound fixes from Takashi Iwai: "This time we got a slightly higher volume than previous times, but all device-specific good fixes. Noticeable changes are fixes in davinci, and the removal of open-codes in HD-audio ca0132 driver. The rest are all small fixes and/or quirks" * tag 'sound-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Enable front audio jacks on one HP desktop model ALSA: hda/ca0132 - Fix recording from mode id 0x8 ALSA: hda/ca0132 - setup/cleanup streams ALSA: hda - add headset mic detect quirks for two Dell laptops ALSA: usb-audio: work around KEF X300A firmware bug ASoC: max98090: make REVISION_ID readable ASoC: txx9aclc_ac97: Fix kernel crash on probe ASoC: max98090: sync regcache on entering STANDBY ASoC: blackfin: Fix machine driver Kconfig dependencies ASoC: da9055: Fix device registration of PMIC and CODEC devices ASoC: fsl-esai: fix ESAI TDM slot setting ASoC: fsl: fix pm support of machine drivers ASoC: rt5640: Add ACPI ID for Intel Baytrail ASoC: davinci-evm: Add pm callbacks to platform driver ASoC: davinci-mcasp: Consolidate pm_runtime_get/put() use in the driver ASoC: davinci-mcasp: Configure xxTDM, xxFMT and xxFMCT registers synchronously ASoC: davinci-mcasp: Harmonize the sub hw_params function names ASoC: samsung: Fix trivial typo ASoC: samsung: Remove invalid dependencies ASoC: wm8993: drop regulator_bulk_free of devm_ allocated data
…ux/kernel/git/joro/iommu
Pull IOMMU fixes from Joerg Roedel:
"The fixes are only for the ARM-SMMU driver. Here is the summary from
Will Deacon:
- Andreas Herrmann took the driver for a run with a real SATA
controller, which caused the new mutex-based locking to explode
since we require mappings in atomic context
- Yifan fixed an issue with the page table creation, which then
caused breakages with the way in which we flush descriptors out to
the table walker
- I ran the driver on a system where the SMMU is hooked into a
coherent interconnect for table walks, and noticed a shareability
mismatch between the CPU and the SMMU
These issues are all fixed here and have been tested on both arm and
arm64 based systems.
Besides that I put a fix on-top to make the spinlock irq-safe, so that
the code-paths can be used in the DMA-API"
* tag 'iommu-fixes-v3.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
arm/smmu: Use irqsafe spinlock for domain lock
iommu/arm-smmu: fix compilation issue when !CONFIG_ARM_AMBA
iommu/arm-smmu: set CBARn.BPSHCFG to NSH for s1-s2-bypass contexts
iommu/arm-smmu: fix table flushing during initial allocations
iommu/arm-smmu: really fix page table locking
iommu/arm-smmu: fix pud/pmd entry fill sequence
…rnel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These include two fixes for recent regressions related to ACPI, a
cpufreq fix for breakage overlooked by a previous fix commit, two
intel_pstate fixes for stuff added during the 3.13 cycle that need to
go into -stable, three fixes for older bugs that also are -stable
candidates, ACPI video blacklist changes related to BIOSes that behave
in a special way on Windows 8, several build fixes for CONFIG_PM_SLEEP
unset in ACPI drivers and an ACPI driver cleanup.
Specifics:
- Fix for a recent probing regression in the nouveau driver
introduced by an ACPI change related to the handling of _DSM from
Jiang Liu.
- Fix for a dock station sysfs attribute that stopped working
correctly after recent changes in the ACPI core.
- cpufreq fix taking care of broken code related to CPU removal and
overlooked by a previous recent fix in that area. From Viresh
Kumar.
- Two intel_pstate fixes related to Baytrail support added during the
3.13 cycle (candidates for -stable) from Dirk Brandewie.
- ACPI video fix removing duplicate brightness values from the _BCL
table which makes its user space interface behave sanely. From
Hans de Goede.
- Fix for the powernow-k8 cpufreq driver making it initialize its
per-CPU data structures correctly from Srivatsa S Bhat.
- Fix for an obscure memory leak in the ACPI PCI interrupt allocation
code (related to ISA) from Tomasz Nowicki.
- ACPI video blacklist changes moving several systems that should use
the native backlight interface instead of the ACPI one from the
general ACPI _OSI blacklist the the ACPI video driver's blacklist
where they belong. This consists of an ACPI video driver update
from Aaron Lu and a revert of a previous commit adding systems to
the ACPI _OSI blacklist requested by Takashi Iwai.
- Several fixes for build issues in ACPI drivers occuring when
CONFIG_PM_SLEEP is unset from Shuah Khan.
- Fix for an sscanf() format string in the ACPI Smart Battery
Subsystem (SBS) driver from Luis G.F"
* tag 'pm+acpi-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
intel_pstate: Add support for Baytrail turbo P states
intel_pstate: Use LFM bus ratio as min ratio/P state
ACPI / nouveau: fix probing regression related to _DSM
Revert "ACPI: Blacklist Win8 OSI for some HP laptop 2013 models"
ACPI / video: Add systems that should favour native backlight interface
ACPI / video: Filter the _BCL table for duplicate brightness values
cpufreq: powernow-k8: Initialize per-cpu data-structures properly
cpufreq: remove sysfs link when a cpu != policy->cpu, is removed
ACPI / PCI: Fix memory leak in acpi_pci_irq_enable()
ACPI / dock: Make 'docked' sysfs attribute work as documented
ACPI / SBS: Fix incorrect sscanf() string
ACPI / thermal: fix thermal driver compile error when CONFIG_PM_SLEEP is undefined
ACPI / SBS: fix SBS driver compile error when CONFIG_PM_SLEEP is undefined
ACPI / fan: fix fan driver compile error when CONFIG_PM_SLEEP is undefined
ACPI / button: fix button driver compile error when CONFIG_PM_SLEEP is undefined
ACPI / battery: fix battery driver compile error when CONFIG_PM_SLEEP is undefined
ACPI / AC: fix AC driver compile error when CONFIG_PM_SLEEP is undefined
Pull sparc fixes from David Miller: "Three minor fixes from David Howells and Paul Gortmaker" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: Sparc: sparc_cpu_model isn't in asm/system.h any more [ver #2] sparc32: make copy_to/from_user_page() usable from modular code sparc32: fix build failure for arch_jump_label_transform
Most WDT driver modules return ENODEV during modprobe if no valid device was found, but w83697hf_wdt returns EIO. Let w83697hf_wdt return ENODEV. Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Pull watchdog fix from Wim Van Sebroeck: "It corrects the error code when no device was found for w83697hf_wdt" * git://www.linux-watchdog.org/linux-watchdog: watchdog: w83697hf_wdt: return ENODEV if no device was found
Pull devicetree fixes from Grant Likely: "Device tree compatible match order bug fix This branch contains a bug fix for the way devicetree code identifies the type of device. Device drivers can contain a list of of_device_ids, but it more than one entry will match, then the device driver may choose the wrong one. Commit 1053531, "match each node compatible against all given matches first", was queued for v3.14 but ended up causing other bugs. Commit 06b29e7 attempted to fix it but it had other bugs. Merely reverting the fix and waiting until v3.15 isn't a good option because there is code in v3.14 that depends on the revised behaviour to boot. This branch should finally fixes the problem correctly. This time instead of just hoping that the patch is correct, this branch also adds new testcases that validate the behaviour. The changes in this branch are larger than I would like for a -rc pull, but moving the test case data out of out of arch/arm so that it could be validated on other architectures was important" * tag 'dt-for-linus' of git://git.secretlab.ca/git/linux: of: Add self test for of_match_node() of: Move testcase FDT data into drivers/of of: reimplement the matching method for __of_match_node() Revert "of: search the best compatible match first in __of_match_node()"
Pull xfs fixes from Dave Chinner:
"This is the first pull request I've had to do for you, so I'm still
sorting things out. The reason I'm sending this and not Ben should be
obvious from the first commit below - SGI has stepped down from the
XFS maintainership role. As such, I'd like to take another
opportunity to thank them for their many years of effort maintaining
XFS and supporting the XFS community that they developed from the
ground up.
So I haven't had time to work things like signed tags into my
workflows yet, so this is just a repo branch I'm asking you to pull
from. And yes, I named the branch -rc4 because I wanted the fixes in
rc4, not because the branch was for merging into -rc3. Probably not
right, either.
Anyway, I should have everything sorted out by the time the next merge
window comes around. If there's anything that you don't like in the
pull req, feel free to flame me unmercifully.
The changes are fixes for recent regressions and important thinkos in
verification code:
- a log vector buffer alignment issue on ia32
- timestamps on truncate got mangled
- primary superblock CRC validation fixes and error message
sanitisation"
* 'xfs-fixes-for-3.14-rc4' of git://oss.sgi.com/xfs/xfs:
xfs: limit superblock corruption errors to actual corruption
xfs: skip verification on initial "guess" superblock read
MAINTAINERS: SGI no longer maintaining XFS
xfs: xfs_sb_read_verify() doesn't flag bad crcs on primary sb
xfs: ensure correct log item buffer alignment
xfs: ensure correct timestamp updates from truncate
…nel/git/groeck/linux-staging Pull hwmon fix from Guenter Roeck: "Fix writing the minimum temperature in max1668 driver" * tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (max1668) Fix writing the minimum temperature
AshishNamdev
added a commit
that referenced
this pull request
Feb 22, 2014
Updating working tree with torvalds:master
AshishNamdev
pushed a commit
that referenced
this pull request
Mar 23, 2014
vmxnet3's netpoll driver is incorrectly coded. It directly calls vmxnet3_do_poll, which is the driver internal napi poll routine. As the netpoll controller method doesn't block real napi polls in any way, there is a potential for race conditions in which the netpoll controller method and the napi poll method run concurrently. The result is data corruption causing panics such as this one recently observed: PID: 1371 TASK: ffff88023762caa0 CPU: 1 COMMAND: "rs:main Q:Reg" #0 [ffff88023abd5780] machine_kexec at ffffffff81038f3b #1 [ffff88023abd57e0] crash_kexec at ffffffff810c5d92 #2 [ffff88023abd58b0] oops_end at ffffffff8152b570 #3 [ffff88023abd58e0] die at ffffffff81010e0b #4 [ffff88023abd5910] do_trap at ffffffff8152add4 #5 [ffff88023abd5970] do_invalid_op at ffffffff8100cf95 #6 [ffff88023abd5a10] invalid_op at ffffffff8100bf9b [exception RIP: vmxnet3_rq_rx_complete+1968] RIP: ffffffffa00f1e80 RSP: ffff88023abd5ac8 RFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff88023b5dcee0 RCX: 00000000000000c0 RDX: 0000000000000000 RSI: 00000000000005f2 RDI: ffff88023b5dcee0 RBP: ffff88023abd5b48 R8: 0000000000000000 R9: ffff88023a3b6048 R10: 0000000000000000 R11: 0000000000000002 R12: ffff8802398d4cd8 R13: ffff88023af35140 R14: ffff88023b60c890 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff88023abd5b50] vmxnet3_do_poll at ffffffffa00f204a [vmxnet3] #8 [ffff88023abd5b80] vmxnet3_netpoll at ffffffffa00f209c [vmxnet3] torvalds#9 [ffff88023abd5ba0] netpoll_poll_dev at ffffffff81472bb7 The fix is to do as other drivers do, and have the poll controller call the top half interrupt handler, which schedules a napi poll properly to recieve frames Tested by myself, successfully. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Shreyas Bhatewara <sbhatewara@vmware.com> CC: "VMware, Inc." <pv-drivers@vmware.com> CC: "David S. Miller" <davem@davemloft.net> CC: stable@vger.kernel.org Reviewed-by: Shreyas N Bhatewara <sbhatewara@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
AshishNamdev
pushed a commit
that referenced
this pull request
Jul 2, 2014
Fugang Duan says:
====================
net: fec: Enable Software TSO to improve the tx performance
Add SG and software TSO support for FEC.
This feature allows to improve outbound throughput performance.
Tested on imx6dl sabresd board, running iperf tcp tests shows:
* 82% improvement comparing with NO SG & TSO patch
$ ethtool -K eth0 sg on
$ ethtool -K eth0 tso on
[ 3] local 10.192.242.108 port 35388 connected with 10.192.242.167 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 3.0 sec 181 MBytes 506 Mbits/sec
* cpu loading is 30%
$ ethtool -K eth0 sg off
$ ethtool -K eth0 tso off
[ 3] local 10.192.242.108 port 52618 connected with 10.192.242.167 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 3.0 sec 99.5 MBytes 278 Mbits/sec
FEC HW support IP header and TCP/UDP hw checksum, support multi buffer descriptor transfer
one frame, but don't support HW TSO. And imx6q/dl SOC FEC Gbps speed has HW bus Bandwidth
limitation (400Mbps ~ 700Mbps), imx6sx SOC FEC Gbps speed has no HW bandwidth limitation.
The patch set just enable TSO feature, which is done following the mv643xx_eth driver.
Test result analyze:
imx6dl sabresd board: there have 82% improvement, since imx6dl FEC HW has bandwidth limitation,
the performance with SW TSO is a milestone.
Addition test:
imx6sx sdb board:
upstream still don't support imx6sx due to some patches being upstream... they use same FEC IP.
Use the SW TSO patches test imx6sx sdb board in internal kernel tree:
No SW TSO patch: tx bandwidth 840Mbps, cpu loading is 100%.
SW TSO patch: tx bandwidth 942Mbps, cpu loading is 65%.
It means the patch set have great improvement for imx6sx FEC performance.
V2:
* From Frank Li's suggestion:
Change the API "fec_enet_txdesc_entry_free" name to "fec_enet_get_free_txdesc_num".
* Summary David Laight and Eric Dumazet's thoughts:
RX BD entry number change to 256.
* From ezequiel's suggestion:
Follow the latest TSO fixes from his solution to rework the queue stop/wake-up.
Avoid unmapping the TSO header buffers.
* From Eric Dumazet's suggestion:
Avoid more bytes copy, just copying the unaligned part of the payload into first
descriptor. The suggestion will bring more complex for the driver, and imx6dl FEC
DMA need 16 bytes alignment, but cpu loading is not problem that cpu loading is
30%, the current performance is so better. Later chip like imx6sx Gigbit FEC DMA
support byte alignment, so there don't exist memory copy. So, the V2 version drop
the suggestion.
Anyway, thanks for Eric's response and suggestion.
V3:
* From David Laight's feedback:
Decide to drop RX BD entry number change for the SW TSO patch set.
I will generate one separate patch to increase RX BDs entry for interrupt coalescing feature which
will be supported in my later patch set.
V4:
* From David Laight's feedback:
Remove the conditional in .fec_enet_get_bd_index().
V5:
* Patch #4 update:
From David Laight's feedback:
"expect fec_enet_get_free_txdesc_num() to return one less than it does currently."
Change the function:
Return space available, 0..size-1. it always leave one free entry. Which is same as linux circ_buf.
Thanks for Eric and ezequiel's help and idea.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
AshishNamdev
pushed a commit
that referenced
this pull request
Jul 2, 2014
Often when running the qgroups sanity test, a crash or a hang happened. This is because the extent buffer the test uses for the root node doesn't have an header level explicitly set, making it have a random level value. This is a problem when it's not zero for the btrfs_search_slot() calls the test ends up doing, resulting in crashes or hangs such as the following: [ 6454.127192] Btrfs loaded, debug=on, assert=on, integrity-checker=on (...) [ 6454.127760] BTRFS: selftest: Running qgroup tests [ 6454.127964] BTRFS: selftest: Running test_test_no_shared_qgroup [ 6454.127966] BTRFS: selftest: Qgroup basic add [ 6480.152005] BUG: soft lockup - CPU#0 stuck for 23s! [modprobe:5383] [ 6480.152005] Modules linked in: btrfs(+) xor raid6_pq binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc i2c_piix4 i2c_core pcspkr evbug psmouse serio_raw e1000 [last unloaded: btrfs] [ 6480.152005] irq event stamp: 188448 [ 6480.152005] hardirqs last enabled at (188447): [<ffffffff8168ef5c>] restore_args+0x0/0x30 [ 6480.152005] hardirqs last disabled at (188448): [<ffffffff81698e6a>] apic_timer_interrupt+0x6a/0x80 [ 6480.152005] softirqs last enabled at (188446): [<ffffffff810516cf>] __do_softirq+0x1cf/0x450 [ 6480.152005] softirqs last disabled at (188441): [<ffffffff81051c25>] irq_exit+0xb5/0xc0 [ 6480.152005] CPU: 0 PID: 5383 Comm: modprobe Not tainted 3.15.0-rc8-fdm-btrfs-next-33+ #4 [ 6480.152005] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 6480.152005] task: ffff8802146125a0 ti: ffff8800d0d00000 task.ti: ffff8800d0d00000 [ 6480.152005] RIP: 0010:[<ffffffff81349a63>] [<ffffffff81349a63>] __write_lock_failed+0x13/0x20 [ 6480.152005] RSP: 0018:ffff8800d0d038e8 EFLAGS: 00000287 [ 6480.152005] RAX: 0000000000000000 RBX: ffffffff8168ef5c RCX: 000005deb8525852 [ 6480.152005] RDX: 0000000000000000 RSI: 0000000000001d45 RDI: ffff8802105000b8 [ 6480.152005] RBP: ffff8800d0d038e8 R08: fffffe12710f63db R09: ffffffffa03196fb [ 6480.152005] R10: ffff8802146125a0 R11: ffff880214612e28 R12: ffff8800d0d03858 [ 6480.152005] R13: 0000000000000000 R14: ffff8800d0d00000 R15: ffff8802146125a0 [ 6480.152005] FS: 00007f14ff804700(0000) GS:ffff880215e00000(0000) knlGS:0000000000000000 [ 6480.152005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 6480.152005] CR2: 00007fff4df0dac8 CR3: 00000000d1796000 CR4: 00000000000006f0 [ 6480.152005] Stack: [ 6480.152005] ffff8800d0d03908 ffffffff810ae967 0000000000000001 ffff8802105000b8 [ 6480.152005] ffff8800d0d03938 ffffffff8168e57e ffffffffa0319c16 0000000000000007 [ 6480.152005] ffff880210500000 ffff880210500100 ffff8800d0d039b8 ffffffffa0319c16 [ 6480.152005] Call Trace: [ 6480.152005] [<ffffffff810ae967>] do_raw_write_lock+0x47/0xa0 [ 6480.152005] [<ffffffff8168e57e>] _raw_write_lock+0x5e/0x80 [ 6480.152005] [<ffffffffa0319c16>] ? btrfs_tree_lock+0x116/0x270 [btrfs] [ 6480.152005] [<ffffffffa0319c16>] btrfs_tree_lock+0x116/0x270 [btrfs] [ 6480.152005] [<ffffffffa02b2acb>] btrfs_lock_root_node+0x3b/0x50 [btrfs] [ 6480.152005] [<ffffffffa02b81a6>] btrfs_search_slot+0x916/0xa20 [btrfs] [ 6480.152005] [<ffffffff811a727f>] ? create_object+0x23f/0x300 [ 6480.152005] [<ffffffffa02b9958>] btrfs_insert_empty_items+0x78/0xd0 [btrfs] [ 6480.152005] [<ffffffffa036041a>] insert_normal_tree_ref.constprop.4+0xa2/0x19a [btrfs] [ 6480.152005] [<ffffffffa03605c3>] test_no_shared_qgroup+0xb1/0x1ca [btrfs] [ 6480.152005] [<ffffffff8108cad6>] ? local_clock+0x16/0x30 [ 6480.152005] [<ffffffffa035ef8e>] btrfs_test_qgroups+0x1ae/0x1d7 [btrfs] [ 6480.152005] [<ffffffffa03a69d2>] ? ftrace_define_fields_btrfs_space_reservation+0xfd/0xfd [btrfs] [ 6480.152005] [<ffffffffa03a6a86>] init_btrfs_fs+0xb4/0x153 [btrfs] [ 6480.152005] [<ffffffff81000352>] do_one_initcall+0x102/0x150 [ 6480.152005] [<ffffffff8103d223>] ? set_memory_nx+0x43/0x50 [ 6480.152005] [<ffffffff81682668>] ? set_section_ro_nx+0x6d/0x74 [ 6480.152005] [<ffffffff810d91cc>] load_module+0x1cdc/0x2630 (...) Therefore initialize the extent buffer as an empty leaf (level 0). Issue easy to reproduce when btrfs is built as a module via: $ for ((i = 1; i <= 1000000; i++)); do rmmod btrfs; modprobe btrfs; done Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by: Chris Mason <clm@fb.com>
AshishNamdev
pushed a commit
that referenced
this pull request
Jul 2, 2014
cxgb4_netdev maybe lead to dead lock, since it uses a spin lock, and be called in both thread and softirq context, but not disable BH, the lockdep report is below; In fact, cxgb4_netdev only reads adap_rcu_list with RCU protection, so not need to hold spin lock again. ================================= [ INFO: inconsistent lock state ] 3.14.7+ torvalds#24 Tainted: G C O --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. radvd/3794 [HC0[0]:SC1[1]:HE1:SE0] takes: (adap_rcu_lock){+.?...}, at: [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4] {SOFTIRQ-ON-W} state was registered at: [<ffffffff810fca81>] __lock_acquire+0x34a/0xe48 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43 [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4] [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4] [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6] [<ffffffffa01f8df0>] addrconf_add_linklocal+0x5f/0x95 [ipv6] [<ffffffffa01fc3e9>] addrconf_notify+0x632/0x841 [ipv6] [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c [<ffffffff810e09a1>] __raw_notifier_call_chain+0x9/0xb [<ffffffff810e09b2>] raw_notifier_call_chain+0xf/0x11 [<ffffffff8151b3b7>] call_netdevice_notifiers_info+0x4e/0x56 [<ffffffff8151b3d0>] call_netdevice_notifiers+0x11/0x13 [<ffffffff8151c0a6>] netdev_state_change+0x1f/0x38 [<ffffffff8152f004>] linkwatch_do_dev+0x3b/0x49 [<ffffffff8152f184>] __linkwatch_run_queue+0x10b/0x144 [<ffffffff8152f1dd>] linkwatch_event+0x20/0x27 [<ffffffff810d7bc0>] process_one_work+0x1cb/0x2ee [<ffffffff810d7e3b>] worker_thread+0x12e/0x1fc [<ffffffff810dd391>] kthread+0xc4/0xcc [<ffffffff815dc48c>] ret_from_fork+0x7c/0xb0 irq event stamp: 3388 hardirqs last enabled at (3388): [<ffffffff810c6c85>] __local_bh_enable_ip+0xaa/0xd9 hardirqs last disabled at (3387): [<ffffffff810c6c2d>] __local_bh_enable_ip+0x52/0xd9 softirqs last enabled at (3288): [<ffffffffa01f1d5b>] rcu_read_unlock_bh+0x0/0x2f [ipv6] softirqs last disabled at (3289): [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(adap_rcu_lock); <Interrupt> lock(adap_rcu_lock); *** DEADLOCK *** 5 locks held by radvd/3794: #0: (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffffa020b85a>] rawv6_sendmsg+0x74b/0xa4d [ipv6] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff8151ac6b>] rcu_lock_acquire+0x0/0x29 #2: (rcu_read_lock){.+.+..}, at: [<ffffffffa01f4cca>] rcu_lock_acquire.constprop.16+0x0/0x30 [ipv6] #3: (rcu_read_lock){.+.+..}, at: [<ffffffff810e09b4>] rcu_lock_acquire+0x0/0x29 #4: (rcu_read_lock){.+.+..}, at: [<ffffffffa0998782>] rcu_lock_acquire.constprop.40+0x0/0x30 [cxgb4] stack backtrace: CPU: 7 PID: 3794 Comm: radvd Tainted: G C O 3.14.7+ torvalds#24 Hardware name: Supermicro X7DBU/X7DBU, BIOS 6.00 12/03/2007 ffffffff81f15990 ffff88012fdc36a8 ffffffff815d0016 0000000000000006 ffff8800c80dc2a0 ffff88012fdc3708 ffffffff815cc727 0000000000000001 0000000000000001 ffff880100000000 ffffffff81015b02 ffff8800c80dcb58 Call Trace: <IRQ> [<ffffffff815d0016>] dump_stack+0x4e/0x71 [<ffffffff815cc727>] print_usage_bug+0x1ec/0x1fd [<ffffffff81015b02>] ? save_stack_trace+0x27/0x44 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0 [<ffffffff810fc640>] mark_lock+0x11b/0x212 [<ffffffff810fca0b>] __lock_acquire+0x2d4/0xe48 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0 [<ffffffff810fbff6>] ? check_usage_forwards+0x4c/0xa6 [<ffffffff810c6c8a>] ? __local_bh_enable_ip+0xaf/0xd9 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4] [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4] [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4] [<ffffffffa09987b0>] ? rcu_lock_acquire.constprop.40+0x2e/0x30 [cxgb4] [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4] [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4] [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4] [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d [<ffffffff810e09b4>] ? raw_notifier_call_chain+0x11/0x11 [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6] [<ffffffff810fde6a>] ? trace_hardirqs_on+0xd/0xf [<ffffffffa01fb634>] addrconf_prefix_rcv+0x385/0x6ea [ipv6] [<ffffffffa0207950>] ndisc_rcv+0x9d3/0xd76 [ipv6] [<ffffffffa020d536>] icmpv6_rcv+0x592/0x67b [ipv6] [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b [<ffffffffa020df97>] ? rcu_read_unlock+0x21/0x23 [ipv6] [<ffffffff8150df52>] ? rcu_read_unlock+0x23/0x23 [<ffffffffa01f4ede>] ip6_input_finish+0x1e4/0x2fc [ipv6] [<ffffffffa01f540b>] ip6_input+0x33/0x38 [ipv6] [<ffffffffa01f5557>] ip6_mc_input+0x147/0x160 [ipv6] [<ffffffffa01f4ba3>] ip6_rcv_finish+0x7c/0x81 [ipv6] [<ffffffffa01f5397>] ipv6_rcv+0x3a1/0x3e2 [ipv6] [<ffffffff8151ef96>] __netif_receive_skb_core+0x4ab/0x511 [<ffffffff810fdc94>] ? mark_held_locks+0x71/0x99 [<ffffffff8151f0c0>] ? process_backlog+0x69/0x15e [<ffffffff8151f045>] __netif_receive_skb+0x49/0x5b [<ffffffff8151f0cf>] process_backlog+0x78/0x15e [<ffffffff8151f571>] ? net_rx_action+0x1a2/0x1cc [<ffffffff8151f47b>] net_rx_action+0xac/0x1cc [<ffffffff810c69b7>] ? __do_softirq+0xad/0x218 [<ffffffff810c69ff>] __do_softirq+0xf5/0x218 [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30 <EOI> [<ffffffff810c6bb6>] do_softirq+0x38/0x5d [<ffffffffa01f1d5b>] ? ip6_copy_metadata+0x156/0x156 [ipv6] [<ffffffff810c6c78>] __local_bh_enable_ip+0x9d/0xd9 [<ffffffffa01f1d88>] rcu_read_unlock_bh+0x2d/0x2f [ipv6] [<ffffffffa01f28b4>] ip6_finish_output2+0x381/0x3d8 [ipv6] [<ffffffffa01f49ef>] ip6_finish_output+0x6e/0x73 [ipv6] [<ffffffffa01f4a70>] ip6_output+0x7c/0xa8 [ipv6] [<ffffffff815b1bfa>] dst_output+0x18/0x1c [<ffffffff815b1c9e>] ip6_local_out+0x1c/0x21 [<ffffffffa01f2489>] ip6_push_pending_frames+0x37d/0x427 [ipv6] [<ffffffff81558af8>] ? skb_orphan+0x39/0x39 [<ffffffffa020b85a>] ? rawv6_sendmsg+0x74b/0xa4d [ipv6] [<ffffffffa020ba51>] rawv6_sendmsg+0x942/0xa4d [ipv6] [<ffffffff81584cd2>] inet_sendmsg+0x3d/0x66 [<ffffffff81508930>] __sock_sendmsg_nosec+0x25/0x27 [<ffffffff8150b0d7>] sock_sendmsg+0x5a/0x7b [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b [<ffffffff8116d756>] ? might_fault+0x9e/0xa5 [<ffffffff8116d70d>] ? might_fault+0x55/0xa5 [<ffffffff81508cb1>] ? copy_from_user+0x2a/0x2c [<ffffffff8150b70c>] ___sys_sendmsg+0x226/0x2d9 [<ffffffff810fcd25>] ? __lock_acquire+0x5ee/0xe48 [<ffffffff810fde01>] ? trace_hardirqs_on_caller+0x145/0x1a1 [<ffffffff8118efcb>] ? slab_free_hook.isra.71+0x50/0x59 [<ffffffff8115c81f>] ? release_pages+0xbc/0x181 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d [<ffffffff81115e97>] ? read_seqcount_begin.constprop.25+0x73/0x90 [<ffffffff8150c408>] __sys_sendmsg+0x3d/0x5b [<ffffffff8150c433>] SyS_sendmsg+0xd/0x19 [<ffffffff815dc53d>] system_call_fastpath+0x1a/0x1f Reported-by: Ben Greear <greearb@candelatech.com> Cc: Casey Leedom <leedom@chelsio.com> Cc: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Li RongQing <roy.qing.li@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
AshishNamdev
pushed a commit
that referenced
this pull request
Oct 2, 2014
This reverts commit 8b37e1b. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.17-rc1. [1] https://lkml.org/lkml/2014/8/16/128 BUG: sleeping function called from invalid context at kernel/workqueue.c:2650 in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant 5 locks held by wpa_supplicant/2335: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20 #1: (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211] #2: (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211] #3: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211] #4: (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30 ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0 Call Trace: [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff810739a5>] __might_sleep+0xe5/0x120 [<ffffffff8106862f>] flush_work+0x5f/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: authenticated wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: NA wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4 ================================= [ INFO: inconsistent lock state ] 3.17.0-rc3 #1 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270 {SOFTIRQ-ON-W} state was registered at: [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f irq event stamp: 493416 hardirqs last enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100 hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160 softirqs last enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50 softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((&(&led_cdev->blink_work)->work)); <Interrupt> lock((&(&led_cdev->blink_work)->work)); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180 #1: (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0 ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001 ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0 Call Trace: <IRQ> [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205 [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140 [<ffffffff810944d3>] mark_lock+0x223/0x2b0 [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180 [<ffffffff810b4c50>] ? process_timeout+0x10/0x10 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0 [<ffffffff81054805>] __do_softirq+0x115/0x2e0 [<ffffffff81054c75>] irq_exit+0xa5/0xb0 [<ffffffff810049b3>] do_IRQ+0x53/0xf0 [<ffffffff815a74af>] common_interrupt+0x6f/0x6f <EOI> [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180 [<ffffffff8147b732>] cpuidle_enter+0x12/0x20 [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360 [<ffffffff8158fb51>] rest_init+0xc1/0xd0 [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170 [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a [<ffffffff81af399c>] ? set_init_arg+0x53/0x53 [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4 Cc: Vincent Donnefort <vdonnefort@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Bryan Wu <cooloney@gmail.com>
AshishNamdev
pushed a commit
that referenced
this pull request
Oct 2, 2014
The "by8" implementation introduced in commit 22cddcc ("crypto: aes - AES CTR x86_64 "by8" AVX optimization") is failing crypto tests as it handles counter block overflows differently. It only accounts the right most 32 bit as a counter -- not the whole block as all other implementations do. This makes it fail the cryptomgr test #4 that specifically tests this corner case. As we're quite late in the release cycle, just disable the "by8" variant for now. Reported-by: Romain Francoise <romain@orebokech.com> Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.