Pull libata fixlet from Tejun Heo:
"I merged the two blaclist entries into 'Crucial_CT???M500SSD*'"
* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata: use wider match for blacklisting Crucial M500
John W. Linville says:
====================
Please pull this batch of fixes intende for the 3.14 stream...
For the mac80211 bits, Johannes says:
"Here I have a fix from Eliad for the minimal channel width calculation
in the mac80211 code which lead to monitor mode not working at all for
drivers using that. One of my fixes is for an issue noticed by Michal,
we clear an already cleared value but do it without locking, so just
remove that. The other is for a data leak - we leak two bytes of kernel
memory out over the air in QoS NULL frames because those don't get a
sequence number assigned in the TX path."
For the iwlwifi bits, Emmanuel says:
"One more fix and an update for device IDs.
There is a bugzilla reported for the fix which is mentioned in the commit message."
Along with those...
Amitkumar Karwar provides two mwifiex fixes, both correcting some
data transcription problems.
Ivaylo Dimitrov uses skb_trim in the wl1251 driver to avoid
HAVE_EFFICIENT_UNALIGNED_ACCESS problems.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We're now blacklisting "Crucial_CT???M500SSD1" and
"Crucial_CT???M500SSD3". Also, "Micron_M500*" is blacklisted which is
about the same devices as the crucial branded ones. Let's merge the
two Crucial M500 entries and widen the match to
"Crucial_CT???M500SSD*" so that we don't have to fiddle with new
entries for similar devices.
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
In the first place, the loop 'for' in the macro 'for_each_isci_host'
(drivers/scsi/isci/host.h:314) is incorrect, because it accesses
the 3rd element of 2 element array. After the 2nd iteration it executes
the instruction:
ihost = to_pci_info(pdev)->hosts[2]
(while the size of the 'hosts' array equals 2) and reads an
out of range element.
In the second place, this loop is incorrectly optimized by GCC v4.8
(see http://marc.info/?l=linux-kernel&m=138998871911336&w=2).
As a result, on platforms with two SCU controllers,
the loop is executed more times than it can be (for i=0,1 and 2).
It causes kernel panic during entering the S3 state
and the following oops after 'rmmod isci':
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff8131360b>] __list_add+0x1b/0xc0
Oops: 0000 [#1] SMP
RIP: 0010:[<ffffffff8131360b>] [<ffffffff8131360b>] __list_add+0x1b/0xc0
Call Trace:
[<ffffffff81661b84>] __mutex_lock_slowpath+0x114/0x1b0
[<ffffffff81661c3f>] mutex_lock+0x1f/0x30
[<ffffffffa03e97cb>] sas_disable_events+0x1b/0x50 [libsas]
[<ffffffffa03e9818>] sas_unregister_ha+0x18/0x60 [libsas]
[<ffffffffa040316e>] isci_unregister+0x1e/0x40 [isci]
[<ffffffffa0403efd>] isci_pci_remove+0x5d/0x100 [isci]
[<ffffffff813391cb>] pci_device_remove+0x3b/0xb0
[<ffffffff813fbf7f>] __device_release_driver+0x7f/0xf0
[<ffffffff813fc8f8>] driver_detach+0xa8/0xb0
[<ffffffff813fbb8b>] bus_remove_driver+0x9b/0x120
[<ffffffff813fcf2c>] driver_unregister+0x2c/0x50
[<ffffffff813381f3>] pci_unregister_driver+0x23/0x80
[<ffffffffa04152f8>] isci_exit+0x10/0x1e [isci]
[<ffffffff810d199b>] SyS_delete_module+0x16b/0x2d0
[<ffffffff81012a21>] ? do_notify_resume+0x61/0xa0
[<ffffffff8166ce29>] system_call_fastpath+0x16/0x1b
The loop has been corrected.
This patch fixes kernel panic during entering the S3 state
and the above oops.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Tested-by: Lukasz Dorau <lukasz.dorau@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Remove an erroneous BUG_ON() in the case of a hard reset timeout. The
reset timeout handler puts the port into the "awaiting link-up" state.
The timeout causes the device to be disconnected and we need to be in
the awaiting link-up state to re-connect the port. The BUG_ON() made
the incorrect assumption that resets never timeout and we always
complete the reset in the "resetting" state.
Testing this patch also uncovered that libata continues to attempt to
reset the port long after the driver has torn down the context. Once
the driver has committed to abandoning the link it must indicate to
libata that recovery ends by returning -ENODEV from
->lldd_I_T_nexus_reset().
Cc: <stable@vger.kernel.org>
Acked-by: Lukasz Dorau <lukasz.dorau@intel.com>
Reported-by: David Milburn <dmilburn@redhat.com>
Reported-by: Xun Ni <xun.ni@intel.com>
Tested-by: Xun Ni <xun.ni@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
This fixes requesting of the MSI-X vectors for the base response queue.
The iteration in the for loop in qla24xx_enable_msix() was incorrect.
We should only iterate of the first two MSI-X vectors and not the total
number of MSI-X vectors that have given to the driver for this device
from pci_enable_msix() in this function.
Cc: <stable@vger.kernel.org>
Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Pull ARM SoC fixes from from Olof Johansson:
"A collection of fixes for ARM platforms. A little large due to us
missing to do one last week, but there's nothing in particular here
that is in itself large and scary.
Mostly a handful of smaller fixes all over the place. The majority is
made up of fixes for OMAP, but there are a few for others as well. In
particular, there was a decision to rename a binding for the Broadcom
pinctrl block that we need to go in before the final release since we
then treat it as ABI"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting
ARM: tegra: add LED options back into tegra_defconfig
ARM: dts: omap3-igep: fix boot fail due wrong compatible match
ARM: OMAP3: Fix pinctrl interrupts for core2
pinctrl: Rename Broadcom Capri pinctrl binding
pinctrl: refer to updated dt binding string.
Update dtsi with new pinctrl compatible string
ARM: OMAP: Kill warning in CPUIDLE code with !CONFIG_SMP
ARM: OMAP2+: Add support for thumb mode on DT booted N900
ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
ARM: DRA7: hwmod data: correct the sysc data for spinlock
ARM: OMAP5: PRM: Fix reboot handling
ARM: sunxi: dt: Change the touchscreen compatibles
ARM: sun7i: dt: Fix interrupt trigger types
Pull USB fixes from Greg KH:
"Here are 4 USB fixes for your current tree.
Two of them are reverts to hopefully resolve the nasty XHCI
regressions we have been having on some types of devices. The other
two are quirks for some Logitech video devices"
* tag 'usb-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."
usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
Pull staging driver tree fix from Greg KH:
"Here is a single staging driver fix for your tree.
It resolves an issue with arbritary writes to memory if a specific
driver is loaded"
* tag 'staging-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()
The pci shutdown handler added in:
bnx2: Add pci shutdown handler
commit 25bfb1dd4b
created a shutdown down sequence without chip reset if the device was
never brought up. This can cause the firmware to shutdown the PHY
prematurely and cause MMIO read cycles to be unresponsive. On some
systems, it may generate NMI in the bnx2's pci shutdown handler.
The fix is to tell the firmware not to shutdown the PHY if there was
no prior chip reset.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull thermal fixes from Zhang Rui:
"Specifics:
- Update the help text of INT3403 Thermal driver, which was not
friendly to users. From Zhang Rui.
- The "type" sysfs attribute of x86_pkg_temp_thermal registered
thermal zones includes an instance number, which makes the
thermal-to-hwmon bridge fails to group them all in a single hwmon
device. Fixed by Jean Delvare.
- The hwmon device registered by x86_pkg_temp_thermal driver is
redundant because the temperature value reported by
x86_pkg_temp_thermal is already reported by the coretemp driver.
Fixed by Jean Delvare.
- Fix a problem that the cooling device can not be updated properly
if it is initialized at max cooling state. From Ni Wade.
- Fix a problem that OF registered thermal zones are running without
thermal governors. From Zhang Rui.
- Commit beeb5a1e0e ("thermal: rcar-thermal: Enable driver
compilation with COMPILE_TEST") broke build on archs wihout io
memory. Thus make it depend on HAS_IOMEM to bypass build failures.
Fixed by Richard Weinberger"
* 'for-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
Thermal: thermal zone governor fix
Thermal: Allow first update of cooling device state
thermal,rcar_thermal: Add dependency on HAS_IOMEM
x86_pkg_temp_thermal: Fix the thermal zone type
x86_pkg_temp_thermal: Do not expose as a hwmon device
Thermal: update INT3404 thermal driver help text
Pull spi fixes from Mark Brown:
"A scattering of driver specific fixes here.
The fixes from Axel cover bitrot in apparently unmaintained drivers,
the at79 bug is fixing a glitch on /CS during initialisation of some
devices which could break some slaves and the remainder are fixes for
recently introduced bugs from the past release cycle or so"
* tag 'spi-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: atmel: add missing spi_master_{resume,suspend} calls to PM callbacks
spi: coldfire-qspi: Fix getting correct address for *mcfqspi
spi: fsl-dspi: Fix getting correct address for master
spi: spi-ath79: fix initial GPIO CS line setup
spi: spi-imx: spi_imx_remove: do not disable disabled clocks
spi-topcliff-pch: Fix probing when DMA mode is used
spi/topcliff-pch: Fix DMA channel
Pull SCSI target fixes from Nicholas Bellinger:
"This series addresses a number of outstanding issues wrt to active I/O
shutdown using iser-target. This includes:
- Fix a long standing tpg_state bug where a tpg could be referenced
during explicit shutdown (v3.1+ stable)
- Use list_del_init for iscsi_cmd->i_conn_node so list_empty checks
work as expected (v3.10+ stable)
- Fix a isert_conn->state related hung task bug + ensure outstanding
I/O completes during session shutdown. (v3.10+ stable)
- Fix isert_conn->post_send_buf_count accounting for RDMA READ/WRITEs
(v3.10+ stable)
- Ignore FRWR completions during active I/O shutdown (v3.12+ stable)
- Fix command leakage for interrupt coalescing during active I/O
shutdown (v3.13+ stable)
Also included is another DIF emulation fix from Sagi specific to
v3.14-rc code"
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
Target/sbc: Fix sbc_copy_prot for offset scatters
iser-target: Fix command leak for tx_desc->comp_llnode_batch
iser-target: Ignore completions for FRWRs in isert_cq_tx_work
iser-target: Fix post_send_buf_count for RDMA READ/WRITE
iscsi/iser-target: Fix isert_conn->state hung shutdown issues
iscsi/iser-target: Use list_del_init for ->i_conn_node
iscsi-target: Fix iscsit_get_tpg_from_np tpg_state bug
Revert commit 3130497f5b ("ACPI / sleep: pm_power_off needs more
sanity checks to be installed") that breaks power ACPI power off on a
lot of systems, because it checks wrong registers.
Fixes: 3130497f5b ("ACPI / sleep: pm_power_off needs more sanity checks to be installed")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull workqueue fix from Tejun Heo:
"This pull request contains a workqueue usage fix for firewire.
For quite a long time now, workqueue only treats two work items
identical iff both their addresses and callbacks match. This is to
avoid introducing false dependency through the work item being
recycled while being executed. This changes non-reentrancy guarantee
for the users of PREPARE[_DELAYED]_WORK() - if the function changes,
reentrancy isn't guaranteed against the previous instance. Firewire
depended on such nonreentrancy guarantee.
This is fixed by doing the work item multiplexing from firewire proper
while keeping the work function unchanged"
* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
firewire: don't use PREPARE_DELAYED_WORK
Pull firewire fixes from Stefan Richter:
"Fix a use-after-free regression since v3.4 and an initialization
regression since v3.10"
* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix probe failure with Agere/LSI controllers
firewire: net: fix use after free
Pull clk driver fix from Mike Turquette:
"Single fix for a clock driver merged in 3.14-rc1. Without this fix
the CPU frequency cannot be scaled"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: shmobile: rcar-gen2: Use kick bit to allow Z clock frequency change
Pull ACPI and power management fixes from Rafael Wysocki:
- ACPI tables in some BIOSes list device resources with size equal to
0, which doesn't make sense, so we should ignore them, but instead we
try to use them and mangle things completely. Fix from Zhang Rui.
- Several models of Samsung laptops accumulate EC events when they are
in sleep states which leads to EC buffer overflows that prevent new
events from being signaled after system resume or reboot. This has
been affecting many users for quite a while and may be addressed by
clearing the EC buffer during system resume and system startup on
those machines. From Kieran Clancy.
- If the ACPI sleep control and status registers are not present (which
happens if the Hardware Reduced ACPI mode bit is set in the ACPI
tables, but also may result from BIOS bugs), we should not try to use
ACPI to power off the system and ACPI S5 should not be listed as
supported. Fix from Aubrey Li.
- There's a race condition in cpufreq_get() that leads to a kernel
crash if that function is called at a wrong time. Fix from Aaron
Plattner.
- cpufreq policy objects have to be initialized entirely before they
are first accessed by their users which isn't the case currently and
that potentially leads to various kinds of breakage that is difficult
to debug. Fix from Viresh Kumar.
- Locking is missing in __cpufreq_add_dev() which leads to a race
condition that may trigger a kernel crash. Fix from Viresh Kumar.
* tag 'pm+acpi-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / EC: Clear stale EC events on Samsung systems
cpufreq: Initialize governor for a new policy under policy->rwsem
cpufreq: Initialize policy before making it available for others to use
cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions
ACPI / sleep: pm_power_off needs more sanity checks to be installed
ACPI / resources: ignore invalid ACPI device resources
* pm-cpufreq:
cpufreq: Initialize governor for a new policy under policy->rwsem
cpufreq: Initialize policy before making it available for others to use
cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions
Pull device mapper fixes from Mike Snitzer:
- dm-cache memory allocation failure fix
- fix DM's Kconfig identation
- dm-snapshot metadata corruption fix for bug introduced in 3.14-rc1
- important refcount < 0 fix for the DM persistent data library's space
map metadata interface which fixes corruption reported by a few
dm-thinp users
and last but not least:
- more extensive fixes than ideal for dm-thinp's data resize capability
(which has had growing pain much like we've seen from -ENOSPC
handling of filesystems that mature).
The end result is dm-thinp now handles metadata operation failure and
no data space error conditions much better than before.
* tag 'dm-3.14-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm space map metadata: fix refcount decrement below 0 which caused corruption
dm thin: fix Documentation for held metadata root feature
dm thin: fix noflush suspend IO queueing
dm thin: fix deadlock in __requeue_bio_list
dm thin: fix out of data space handling
dm thin: ensure user takes action to validate data and metadata consistency
dm thin: synchronize the pool mode during suspend
dm snapshot: fix metadata corruption
dm: fix Kconfig indentation
dm cache mq: fix memory allocation failure for large cache devices
This reverts commit 3804fad454.
This commit, together with commit 247bf55727
"xhci 1.0: Limit arbitrarily-aligned scatter gather." were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.
USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
The proper soluition is to implement the TD fragment rules for xHCI 1.0 hosts,
but for now, revert this patch until scatter gather can be properly supported.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 247bf55727.
This commit, together with commit 3804fad454
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.
USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull drm fixes from Dave Airlie:
"Mostly intel and radeon fixes, one tda998x, one kconfig dep fix and
two more MAINTAINERS updates,
All pretty run of the mill for this stage"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon/atom: select the proper number of lanes in transmitter setup
MAINTAINERS: add maintainer entry for TDA998x driver
drm: fix bochs kconfig dependencies
drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters
drm/radeon/cik: fix typo in documentation
drm/radeon: silence GCC warning on 32 bit
drm/radeon: resume old pm late
drm/radeon: TTM must be init with cpu-visible VRAM, v2
DRM: armada: fix use of kfifo_put()
drm/i915: Reject >165MHz modes w/ DVI monitors
drm/i915: fix assert_cursor on BDW
drm/i915: vlv: reserve GT power context early
drm/i915: fix pch pci device enumeration
drm/i915: Resolving the memory region conflict for Stolen area
drm/i915: use backlight legacy combination mode also for i915gm/i945gm
MAINTAINERS: update AGP tree to point at drm tree
Pull block fixes from Jens Axboe:
"Small collection of fixes for 3.14-rc. It contains:
- Three minor update to blk-mq from Christoph.
- Reduce number of unaligned (< 4kb) in-flight writes on mtip32xx to
two. From Micron.
- Make the blk-mq CPU notify spinlock raw, since it can't be a
sleeper spinlock on RT. From Mike Galbraith.
- Drop now bogus BUG_ON() for bio iteration with blk integrity. From
Nic Bellinger.
- Properly propagate the SYNC flag on requests. From Shaohua"
* 'for-linus' of git://git.kernel.dk/linux-block:
blk-mq: add REQ_SYNC early
rt,blk,mq: Make blk_mq_cpu_notify_lock a raw spinlock
bio-integrity: Drop bio_integrity_verify BUG_ON in post bip->bip_iter world
blk-mq: support partial I/O completions
blk-mq: merge blk_mq_insert_request and blk_mq_run_request
blk-mq: remove blk_mq_alloc_rq
mtip32xx: Reduce the number of unaligned writes to 2
Pull pin control fixes from Linus Walleij:
"This is a set of pin control fixes I have collected over the last few
days. Some have rotated more than others in linux-next, but they were
rebased on v3.14-rc5 due to sloppy commit messages. I am quite
convinced that they are all good fixes that only hit this or that
individual driver and not the entire subsystem.
- Fix chained interrupts, interrupt masking and register offset
calculation for the sunxi driver
- Make MSM a bool rather than a tristate to stop build problems to
happen - chained interrupt controllers cannot currently be defined
in modules
- Fix a clock in the PFC driver
- Fix a kernel panic in the sirf driver"
* tag 'pinctrl-v3.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: sirf: fix kernel panic in gpio_lock_as_irq
pinctrl: sh-pfc: r8a7791: SD1_CLK fix
pinctrl: msm: make PINCTRL_MSM bool instead of tristate
pinctrl: sunxi: Fix interrupt register offset calculation
pinctrl: sunxi: Fix masking when setting irq type
pinctrl: sunxi: use chained_irq_{enter, exit} for GIC compatibility
This has been a relatively long-standing issue that wasn't nailed down
until Teng-Feng Yang's meticulous bug report to dm-devel on 3/7/2014,
see: http://www.redhat.com/archives/dm-devel/2014-March/msg00021.html
From that report:
"When decreasing the reference count of a metadata block with its
reference count equals 3, we will call dm_btree_remove() to remove
this enrty from the B+tree which keeps the reference count info in
metadata device.
The B+tree will try to rebalance the entry of the child nodes in each
node it traversed, and the rebalance process contains the following
steps.
(1) Finding the corresponding children in current node (shadow_current(s))
(2) Shadow the children block (issue BOP_INC)
(3) redistribute keys among children, and free children if necessary (issue BOP_DEC)
Since the update of a metadata block's reference count could be
recursive, we will stash these reference count update operations in
smm->uncommitted and then process them in a FILO fashion.
The problem is that step(3) could free the children which is created
in step(2), so the BOP_DEC issued in step(3) will be carried out
before the BOP_INC issued in step(2) since these BOPs will be
processed in FILO fashion. Once the BOP_DEC from step(3) tries to
decrease the reference count of newly shadow block, it will report
failure for its reference equals 0 before decreasing. It looks like we
can solve this issue by processing these BOPs in a FIFO fashion
instead of FILO."
Commit 5b564d80 ("dm space map: disallow decrementing a reference count
below zero") changed the code to report an error for this temporary
refcount decrement below zero. So what was previously a harmless
invalid refcount became a hard failure due to the new error path:
device-mapper: space map common: unable to decrement a reference count below 0
device-mapper: thin: 253:6: dm_thin_insert_block() failed: error = -22
device-mapper: thin: 253:6: switching pool to read-only mode
This bug is in dm persistent-data code that is common to the DM thin and
cache targets. So any users of those targets should apply this fix.
Fix this by applying recursive space map operations in FIFO order rather
than FILO.
Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=68801
Reported-by: Apollon Oikonomopoulos <apoikos@debian.org>
Reported-by: edwillam1007@gmail.com
Reported-by: Teng-Feng Yang <shinrairis@gmail.com>
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.13+
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.
firewire core-device and sbp2 have been been multiplexing work items
with multiple work functions. Introduce fw_device_workfn() and
sbp2_lu_workfn() which invoke fw_device->workfn and
sbp2_logical_unit->workfn respectively and always use the two
functions as the work functions and update the users to set the
->workfn fields instead of overriding work functions using
PREPARE_DELAYED_WORK().
This fixes a variety of possible regressions since a2c1c57be8
"workqueue: consider work function when searching for busy work items"
due to which fw_workqueue lost its required non-reentrancy property.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net
Cc: stable@vger.kernel.org # v3.9+
Cc: stable@vger.kernel.org # v3.8.2+
Cc: stable@vger.kernel.org # v3.4.60+
Cc: stable@vger.kernel.org # v3.2.40+
When copying between device and command protection scatters
we must take into account that device scatters might be offset
and we might copy outside scatter range. Thus for each cmd prot
scatter we must take the min between cmd prot scatter, dev prot
scatter, and whats left (and loop in case we havn't copied enough
from/to cmd prot scatter).
Example (single t_prot_sg of len 2048):
kernel: sbc_dif_copy_prot: se_cmd=ffff880380aaf970, left=2048, len=2048, dev_prot_sg_offset=3072, dev_prot_sg_len=4096
kernel: isert: se_cmd=ffff880380aaf970 PI error found type 0 at sector 0x2600 expected 0x0 vs actual 0x725f, lba=2580
Instead of copying 2048 from offset 3072 (copying junk outside sg
limit 4096), we must to copy 1024 and continue to next sg until
we complete cmd prot scatter.
This issue was found using iSER T10-PI offload over rd_mcp (wasn't
discovered with fileio since file_dev prot sglists are never offset).
Changes from v1:
- Fix sbc_copy_prot copy length miss-calculation
Changes from v0:
- Removed psg->offset consideration for psg_len computation
- Removed sg->offset consideration for offset condition
- Added copied consideraiton for len computation
- Added copied offset to paddr when doing memcpy
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
one more radeon fix.
* 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/atom: select the proper number of lanes in transmitter setup
Currently, the PF call to pci_enable_sriov from the PF probe function
stalls for 10 seconds times the number of VFs probed on the host. This
happens because the way for such VFs to determine of the PF
initialization finished, is by attempting to issue reset on the
comm-channel and get timeout (after 10s).
The PF probe function is called from a kenernel workqueue, and therefore
during that time, rcu lock is being held and kernel's workqueue is
stalled. This blocks other processes that try to use the workqueue
or rcu lock. For example, interface renaming which is calling
rcu_synchronize is blocked, and timedout by systemd.
Changed mlx4_init_slave() to allow VF probed on the host to immediatly
detect that the PF is not ready, and return EPROBE_DEFER instantly.
Only when the PF finishes the initialization, allow such VFs to
access the comm channel.
This issue and fix are relevant only for probed VFs on the hypervisor,
there is no way to pass this information to a VM until comm channel is
ready, so in a VM, if PF is not ready, the first command will be timedout
after 10 seconds and return EPROBE_DEFER.
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a regression introduced by [1]. outbox was accessed instead of
outbox->buf. Typo was copy-pasted to [2] and [3].
[1] - cc1ade9 mlx4_core: Disable memory windows for virtual functions
[2] - 4de6580 mlx4_core: Add support for steerable IB UD QPs
[3] - 7ffdf72 net/mlx4_core: Add basic support for TCP/IP offloads under
tunneling
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We didn't correctly check cases where the value for lp_interval is not
within the legal range due to a missing table terminator.
This would let userspace trigger a kernel panic by specifying a value out
of range:
echo -1 > /sys/devices/virtual/net/bond0/bonding/lp_interval
Introduced by commit 4325b374f8 ("bonding: convert lp_interval to use
the new option API").
Acked-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Building radeon_ttm.o on 32 bit x86 triggers a warning:
In file included from include/asm-generic/bug.h:13:0,
from [...]/arch/x86/include/asm/bug.h:38,
from include/linux/bug.h:4,
from include/drm/drm_mm.h:39,
from include/drm/drm_vma_manager.h:26,
from include/drm/ttm/ttm_bo_api.h:35,
from drivers/gpu/drm/radeon/radeon_ttm.c:32:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
(void) (&_min1 == &_min2); \
^
drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min'
ssize_t cur_size = min(size, PAGE_SIZE - off);
^
Silence this warning by using min_t(). Since cur_size will never be
negative and its upper bound is PAGE_SIZE, we can change its type to
size_t and use min_t(size_t, [...]) here.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Moving the pm resume up in the init order to fix
dpm seems to have regressed somes cases with the old
pm code. Move it back to late resume.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Without this, a bo may get created in the cpu-inaccessible vram.
Before the CP engines get setup, all copies are done via cpu memcpy.
This means that the cpu tries to read from inaccessible memory, fails,
and the radeon module proceeds to disable acceleration.
Doing this has no downsides, as the real VRAM size gets set as soon as the
CP engines get init.
This is a candidate for 3.14 fixes.
v2: Add comment on why the function is used
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
The code to load a MAC address into a u64 for passing to the
hypervisor via a register is broken on little endian.
Create a helper function called ibmveth_encode_mac_addr
which does the right thing in both big and little endian.
We were storing the MAC address in a long in struct ibmveth_adapter.
It's never used so remove it - we don't need another place in the
driver where we create endian issues with MAC addresses.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
