Alex Deucher [Thu, 18 Jul 2013 15:13:53 +0000 (11:13 -0400)]
drm/radeon: fix endian issues with DP handling (v3)
commit
34be8c9af7b8728465963740fc11136ae90dfc36 upstream.
The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.
v2: properly handle non-dw aligned byte counts.
v3: properly handle remainder
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Dong He <hedonghust@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Wed, 10 Jul 2013 22:41:16 +0000 (23:41 +0100)]
dm verity: fix inability to use a few specific devices sizes
commit
b1bf2de07271932326af847a3c6a01fdfd29d4be upstream.
Fix a boundary condition that caused failure for certain device sizes.
The problem is reported at
http://code.google.com/p/cryptsetup/issues/detail?id=160
For certain device sizes the number of hashes at a specific level was
calculated incorrectly.
It happens for example for a device with data and metadata block size 4096
that has 16385 blocks and algorithm sha256.
The user can test if he is affected by this bug by running the
"veritysetup verify" command and also by activating the dm-verity kernel
driver and reading the whole block device. If it passes without an error,
then the user is not affected.
The condition for the bug is:
Split the total number of data blocks (data_block_bits) into bit strings,
each string has hash_per_block_bits bits. hash_per_block_bits is
rounddown(log2(metadata_block_size/hash_digest_size)). Equivalently, you
can say that you convert data_blocks_bits to 2^hash_per_block_bits base.
If there some zero bit string below the most significant bit string and at
least one bit below this zero bit string is set, then the bug happens.
The same bug exists in the userspace veritysetup tool, so you must use
fixed veritysetup too if you want to use devices that are affected by
this boundary condition.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Toshi Kani [Wed, 10 Jul 2013 16:47:13 +0000 (10:47 -0600)]
ACPI / memhotplug: Fix a stale pointer in error path
commit
d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.
device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().
The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory. A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Mon, 15 Jul 2013 04:04:50 +0000 (14:04 +1000)]
powerpc/modules: Module CRC relocation fix causes perf issues
commit
0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that "resolves" the symbols to
the calculated CRC.
Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
that need relocating and relocates them at boot. Commit
d4703aef
(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
added a hook to reverse the bogus relocations. Part of this patch
created a symbol at 0x0:
# head -2 /proc/kallsyms
0000000000000000 T reloc_start
c000000000000000 T .__start
This reloc_start symbol is causing lots of confusion to perf. It
thinks reloc_start is a massive function that stretches from 0x0 to
0xc000000000000000 and we get various cryptic errors out of perf,
including:
problem incrementing symbol count, skipping event
This patch removes the reloc_start linker script label and instead
defines it as PHYSICAL_START. We also need to wrap it with
CONFIG_PPC64 because the ppc32 kernel can set a non zero
PHYSICAL_START at compile time and we wouldn't want to subtract
it from the CRCs in that case.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Mon, 22 Jul 2013 20:53:36 +0000 (16:53 -0400)]
libata: make it clear that sata_inic162x is experimental
commit
bb9696192826a7d9279caf872e95b41bc26c7eff upstream.
sata_inic162x never reached a state where it's reliable enough for
production use and data corruption is a relatively common occurrence.
Make the driver generate warning about the issues and mark the Kconfig
option as experimental.
If the situation doesn't improve, we'd be better off making it depend
on CONFIG_BROKEN. Let's wait for several cycles and see if the kernel
message draws any attention.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Martin Braure de Calignon <braurede@free.fr>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Reported-by: risc4all@yahoo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Youquan Song [Fri, 12 Jul 2013 01:15:57 +0000 (21:15 -0400)]
ata: Fix DVD not dectected at some platform with Wellsburg PCH
commit
eac27f04a71e1f39f196f7e520d16dcefc955d77 upstream.
There is a patch
b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD
not dectected at some Haswell platforms" to fix an issue of DVD not
recognized on Haswell Desktop platform with Lynx Point.
Recently, it is also found the same issue at some platformas with Wellsburg PCH.
So deliver a similar patch to fix it by disables 32bit PIO in IDE mode.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konrad Rzeszutek Wilk [Wed, 16 Jan 2013 16:33:52 +0000 (11:33 -0500)]
xen/blkback: Check device permissions before allowing OP_DISCARD
commit
604c499cbbcc3d5fe5fb8d53306aa0fae1990109 upstream.
We need to make sure that the device is not RO or that
the request is not past the number of sectors we want to
issue the DISCARD operation for.
This fixes CVE-2013-2140.
Acked-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
[v1: Made it pr_warn instead of pr_debug]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Wed, 17 Jul 2013 23:30:20 +0000 (19:30 -0400)]
Btrfs: re-add root to dead root list if we stop dropping it
commit
d29a9f629e009c9b90e5859bce581070fd6247fc upstream.
If we stop dropping a root for whatever reason we need to add it back to the
dead root list so that we will re-start the dropping next transaction commit.
The other case this happens is if we recover a drop because we will add a root
without adding it to the fs radix tree, so we can leak it's root and commit root
extent buffer, adding this to the dead root list makes this cleanup happen.
Thanks,
Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Mon, 15 Jul 2013 16:41:42 +0000 (12:41 -0400)]
Btrfs: fix lock leak when resuming snapshot deletion
commit
fec386ac1428f9c0e672df952cbca5cebd4e4e2f upstream.
We aren't setting path->locks[level] when we resume a snapshot deletion which
means we won't unlock the buffer when we free the path. This causes deadlocks
if we happen to re-allocate the block before we've evicted the extent buffer
from cache. Thanks,
Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 8 Jul 2013 12:36:19 +0000 (13:36 +0100)]
staging: comedi: COMEDI_CANCEL ioctl should wake up read/write
commit
69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream.
Comedi devices can do blocking read() or write() (or poll()) if an
asynchronous command has been set up, blocking for data (for read()) or
buffer space (for write()). Various events associated with the
asynchronous command will wake up the blocked reader or writer (or
poller). It is also possible to force the asynchronous command to
terminate by issuing a `COMEDI_CANCEL` ioctl. That shuts down the
asynchronous command, but does not currently wake up the blocked reader
or writer (or poller). If the blocked task could be woken up, it would
see that the command is no longer active and return. The caller of the
`COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by
sending a signal, but that's a nasty workaround.
Change `do_cancel_ioctl()` to wake up the wait queue after it returns
from `do_cancel()`. `do_cancel()` can propagate an error return value
from the low-level comedi driver's cancel routine, but it always shuts
the command down regardless, so `do_cancel_ioctl()` can wake up he wait
queue regardless of the return value from `do_cancel()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Gulland [Thu, 27 Jun 2013 23:10:20 +0000 (16:10 -0700)]
usb: Clear both buffers when clearing a control transfer TT buffer.
commit
2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland <wgulland@google.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jóhann B. Guðmundsson [Thu, 4 Jul 2013 21:47:52 +0000 (21:47 +0000)]
USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga
commit
58fc90db8261b571c026bb8bf23aad48a7233118 upstream.
Signed-off-by: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 28 Jun 2013 10:24:26 +0000 (12:24 +0200)]
USB: ti_usb_3410_5052: fix dynamic-id matching
commit
1fad56424f5ad3ce4973505a357212b2e2282b3f upstream.
The driver failed to take the dynamic ids into account when determining
the device type and therefore all devices were detected as 2-port
devices when using the dynamic-id interface.
Match on the usb-serial-driver field instead of doing redundant id-table
searches.
Reported-by: Anders Hammarquist <iko@iko.pp.se>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi [Mon, 15 Jul 2013 09:36:35 +0000 (12:36 +0300)]
usb: dwc3: gadget: don't prevent gadget from being probed if we fail
commit
cdcedd6981194e511cc206887db661d016069d68 upstream.
In case we fail our ->udc_start() callback, we
should be ready to accept another modprobe following
the failed one.
We had forgotten to clear dwc->gadget_driver back
to NULL and, because of that, we were preventing
gadget driver modprobe from being retried.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huang Rui [Wed, 26 Jun 2013 17:08:11 +0000 (01:08 +0800)]
usb: dwc3: fix wrong bit mask in dwc3_event_type
commit
1974d494dea05ea227cb42f5e918828801e237aa upstream.
Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
bit is 1, the event is represented Device-Specific Event, then use
[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
and we can see the reserved8_31 variable name which means from 8 to 31
bits marked reserved, actually there are 24 bits not 25 bits between
that. And 1 + 7 + 24 = 32, the event size is 4 byes.
So in dwc3_event_type, the bit mask should be:
is_devspec [0] 1 bit
type [7:1] 7 bits
reserved8_31 [31:8] 24 bits
This patch should be backported to kernels as old as 3.2, that contain
the commit
72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce
DesignWare USB3 DRD Driver".
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Wed, 24 Jul 2013 17:27:13 +0000 (10:27 -0700)]
xhci: Avoid NULL pointer deref when host dies.
commit
203a86613fb3bf2767335659513fa98563a3eb71 upstream.
When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the register write to abort the command
ring, the xHCI driver will assume the host is dead, and call
usb_hc_died().
The USB device's slot_id is still set to zero, and the pointer stored at
xhci->devs[0] will always be NULL. The call to xhci_check_args in
xhci_free_dev should have caught the NULL virt_dev pointer.
However, xhci_free_dev is designed to free the xhci_virt_device
structures, even if the host is dead, so that we don't leak kernel
memory. xhci_free_dev checks the return value from the generic
xhci_check_args function. If the return value is -ENODEV, it carries on
trying to free the virtual device.
The issue is that xhci_check_args looks at the host controller state
before it looks at the xhci_virt_device pointer. It will return -ENIVAL
because the host is dead, and xhci_free_dev will ignore the return
value, and happily dereference the NULL xhci_virt_device pointer.
The fix is to make sure that xhci_check_args checks the xhci_virt_device
pointer before it checks the host state.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
further details. This patch doesn't solve the underlying issue, but
will ensure we don't see any more NULL pointer dereferences because of
the issue.
This patch should be backported to kernels as old as 3.1, that
contain the commit
7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
submit commands or URBs to halted hosts."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Vincent Thiele <vincentthiele@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleksij Rempel [Sun, 21 Jul 2013 13:36:19 +0000 (15:36 +0200)]
xhci: fix null pointer dereference on ring_doorbell_for_active_rings
commit
d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream.
in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.
This patch should be backported to kernels as old as 2.6.35, that
contain the commit
e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
Correct assumptions about number of rings per endpoint"
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
George Cherian [Mon, 1 Jul 2013 05:29:12 +0000 (10:59 +0530)]
usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
commit
07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream.
Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.
Note from Sarah:
The xHCI 1.0 spec changed how hardware handles short packets. The HW
will notify SW of the TRB where the short packet occurred, and it will
also give a successful status for the last TRB in a TD (the one with the
IOC flag set). On the second successful status, that warning will be
triggered in the driver.
Software is now supposed to not assume the TD is not completed until it
gets that last successful status. That means we have a slight race
condition, although it should have little practical impact. This patch
papers over that issue.
It's on my long-term to-do list to fix this race condition, but it is a
much more involved patch that will probably be too big for stable. This
patch is needed for stable to avoid serious log spam.
This patch should be backported to kernels as old as 3.0, that
contain the commit
ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci:
Ignore spurious successful event."
The patch will have to be modified for kernels older than 3.2, since
that kernel added the xhci_gen_setup function for xhci platform devices.
The correct conflict resolution for kernels older than 3.2 is to set
XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zhangwei(Jovi) [Mon, 29 Jul 2013 01:33:58 +0000 (09:33 +0800)]
tracing: Fix irqs-off tag display in syscall tracing
commit
11034ae9c20f4057a6127fc965906417978e69b2 upstream
Initialization of variable irq_flags and pc was missed when backport
11034ae9c to linux-3.0.y and linux-3.4.y, my fault.
Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Saurav Kashyap [Fri, 12 Jul 2013 18:47:51 +0000 (14:47 -0400)]
SCSI: qla2xxx: Properly set the tagging for commands.
commit
c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream.
This fixes a regression where Xyratex controllers and disks were lost by the
driver:
https://bugzilla.kernel.org/show_bug.cgi?id=59601
Reported-by: Jack Hill <jackhill@jackhill.us>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ewan D. Milne [Fri, 2 Nov 2012 13:38:34 +0000 (09:38 -0400)]
SCSI: sd: fix crash when UA received on DIF enabled device
commit
085b513f97d8d799d28491239be4b451bcd8c2c5 upstream.
sd_prep_fn will allocate a larger CDB for the command via mempool_alloc
for devices using DIF type 2 protection. This CDB was being freed
in sd_done, which results in a kernel crash if the command is retried
due to a UNIT ATTENTION. This change moves the code to free the larger
CDB into sd_unprep_fn instead, which is invoked after the request is
complete.
It is no longer necessary to call scsi_print_command separately for
this case as the ->cmnd will no longer be NULL in the normal code path.
Also removed conditional test for DIF type 2 when freeing the larger
CDB because the protection_type could have been changed via sysfs while
the command was executing.
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolin Chen [Fri, 14 Jun 2013 04:34:50 +0000 (12:34 +0800)]
ASoC: wm8962: Remove remaining direct register cache accesses
commit
2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 upstream.
Also fix return values for headphone switch updates.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chih-Chung Chang [Mon, 15 Jul 2013 16:38:46 +0000 (09:38 -0700)]
ASoC: max98088 - fix element type of the register cache.
commit
cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream.
The registers of max98088 are 8 bits, not 16 bits. This bug causes the
contents of registers to be overwritten with bad values when the codec
is suspended and then resumed.
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ren Bigcren [Tue, 2 Jul 2013 11:34:30 +0000 (13:34 +0200)]
USB: storage: Add MicroVault Flash Drive to unusual_devs
commit
e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.
The device report an error capacity when read_capacity_16().
Using read_capacity_10() can get the correct capacity.
Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joern Engel [Wed, 3 Jul 2013 15:35:11 +0000 (11:35 -0400)]
iscsi-target: Fix tfc_tpg_nacl_auth_cit configfs length overflow
commit
0fbfc46fb0b2f543a8b539e94c6c293ebc0b05a6 upstream.
This patch fixes a potential buffer overflow while processing
iscsi_node_auth input for configfs attributes within NodeACL
tfc_tpg_nacl_auth_cit context.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 28 Jul 2013 23:27:25 +0000 (16:27 -0700)]
Linux 3.4.55
Eldad Zack [Fri, 19 Jul 2013 16:26:53 +0000 (18:26 +0200)]
ALSA: usb-audio: 6fire: return correct XRUN indication
commit
be2f93a4c4981b3646b6f98f477154411b8516cb upstream.
Return SNDRV_PCM_POS_XRUN (snd_pcm_uframes_t) instead of
SNDRV_PCM_STATE_XRUN (snd_pcm_state_t) from the pointer
function of 6fire, as expected by snd_pcm_update_hw_ptr0().
Caught by sparse.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Fri, 5 Jul 2013 10:09:18 +0000 (12:09 +0200)]
hrtimers: Move SMP function call to thread context
commit
5ec2481b7b47a4005bb446d176e5d0257400c77d upstream.
smp_call_function_* must not be called from softirq context.
But clock_was_set() which calls on_each_cpu() is called from softirq
context to implement a delayed clock_was_set() for the timer interrupt
handler. Though that almost never gets invoked. A recent change in the
resume code uses the softirq based delayed clock_was_set to support
Xens resume mechanism.
linux-next contains a new warning which warns if smp_call_function_*
is called from softirq context which gets triggered by that Xen
change.
Fix this by moving the delayed clock_was_set() call to a work context.
Reported-and-tested-by: Artem Savkov <artem.savkov@gmail.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>,
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: xen-devel@lists.xen.org
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zhangwei(Jovi) [Wed, 10 Apr 2013 03:26:23 +0000 (11:26 +0800)]
tracing: Fix irqs-off tag display in syscall tracing
commit
11034ae9c20f4057a6127fc965906417978e69b2 upstream.
All syscall tracing irqs-off tags are wrong, the syscall enter entry doesn't
disable irqs.
[root@jovi tracing]#echo "syscalls:sys_enter_open" > set_event
[root@jovi tracing]# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 13/13 #P:2
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
irqbalance-513 [000] d... 56115.496766: sys_open(filename: 804e1a6, flags: 0, mode: 1b6)
irqbalance-513 [000] d... 56115.497008: sys_open(filename: 804e1bb, flags: 0, mode: 1b6)
sendmail-771 [000] d... 56115.827982: sys_open(filename:
b770e6d1, flags: 0, mode: 1b6)
The reason is syscall tracing doesn't record irq_flags into buffer.
The proper display is:
[root@jovi tracing]#echo "syscalls:sys_enter_open" > set_event
[root@jovi tracing]# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 14/14 #P:2
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
irqbalance-514 [001] .... 46.213921: sys_open(filename: 804e1a6, flags: 0, mode: 1b6)
irqbalance-514 [001] .... 46.214160: sys_open(filename: 804e1bb, flags: 0, mode: 1b6)
<...>-920 [001] .... 47.307260: sys_open(filename:
4e82a0c5, flags: 80000, mode: 0)
Link: http://lkml.kernel.org/r/1365564393-10972-3-git-send-email-jovi.zhangwei@huawei.com
Cc: stable@vger.kernel.org # 2.6.35
Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Jeffery [Wed, 10 Jul 2013 17:19:50 +0000 (13:19 -0400)]
lockd: protect nlm_blocked access in nlmsvc_retry_blocked
commit
1c327d962fc420aea046c16215a552710bde8231 upstream.
In nlmsvc_retry_blocked, the check that the list is non-empty and acquiring
the pointer of the first entry is unprotected by any lock. This allows a rare
race condition when there is only one entry on the list. A function such as
nlmsvc_grant_callback() can be called, which will temporarily remove the entry
from the list. Between the list_empty() and list_entry(),the list may become
empty, causing an invalid pointer to be used as an nlm_block, leading to a
possible crash.
This patch adds the nlm_block_lock around these calls to prevent concurrent
use of the nlm_blocked list.
This was a regression introduced by
f904be9cc77f361d37d71468b13ff3d1a1823dea "lockd: Mostly remove BKL from
the server".
Signed-off-by: David Jeffery <djeffery@redhat.com>
Cc: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Barry Grussling [Fri, 19 Jul 2013 21:46:12 +0000 (14:46 -0700)]
usb: cp210x support SEL C662 Vendor/Device
commit
b579fa52f6be0b4157ca9cc5e94d44a2c89a7e95 upstream.
This patch adds support for the Schweitzer Engineering Laboratories
C662 USB cable based off the CP210x driver.
Signed-off-by: Barry Grussling <barry@grussling.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sami Rahman [Mon, 8 Jul 2013 18:28:55 +0000 (14:28 -0400)]
USB: cp210x: add MMB and PI ZigBee USB Device Support
commit
7681156982026ebf7eafd7301eb0374d7648d068 upstream.
Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
devices using customized Silicon Labs' CP210x.c USB to UART bridge
drivers with PIDs: 88A4, 88A5.
Signed-off-by: Sami Rahman <sami.rahman@mmbresearch.com>
Tested-by: Sami Rahman <sami.rahman@mmbresearch.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luiz Angelo Daros de Luca [Tue, 2 Jul 2013 02:56:25 +0000 (23:56 -0300)]
usb: serial: cp210x: Add USB ID for Netgear Switches embedded serial adapter
commit
90625070c4253377025878c4e82feed8b35c7116 upstream.
This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
USB ID (0846:0110) to the cp210x driver. Without this, the serial
adapter is not recognized in Linux. Description was obtained from
an Netgear Eng.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enrico Mioso [Thu, 25 Jul 2013 00:01:39 +0000 (02:01 +0200)]
usb: serial: option: Add ONYX 3G device support
commit
63b5df963f52ccbab6fabedf05b7ac6b465789a4 upstream.
This patch adds support for the ONYX 3G device (version 1) from ALFA
NETWORK.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandr \\\"Sky\\\" Ivanov [Tue, 23 Jul 2013 13:46:40 +0000 (17:46 +0400)]
USB: option: add D-Link DWM-152/C1 and DWM-156/C1
commit
ca24763588844b14f019ffc45c7df6d9e8f932c5 upstream.
Adding support for D-Link DWM-152/C1 and DWM-156/C1 devices.
DWM-152/C1:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=07d1 ProdID=3e01 Rev= 0.00
S: Product=USB Configuration
S: SerialNumber=
1234567890ABCDEF
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
DWM-156/C1:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 8 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=07d1 ProdID=3e02 Rev= 0.00
S: Product=DataCard Device
S: SerialNumber=
1234567890ABCDEF
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Alexandr Ivanov <alexandr.sky@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniil Bolsun [Fri, 19 Jul 2013 07:21:23 +0000 (10:21 +0300)]
USB: option: append Petatel NP10T device to GSM modems list
commit
c38e83b6cc2adf80e3f091fd92cfbeacc9748347 upstream.
This patch was tested on 3.10.1 kernel.
Same models of Petatel NP10T modems have different device IDs.
Unfortunately they have no additional revision information on a board
which may treat them as different devices. Currently I've seen only
two NP10T devices with various IDs. Possibly Petatel NP10T list will
be appended upon devices with new IDs will appear.
Signed-off-by: Daniil Bolsun <dan.bolsun@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enrico Mioso [Sat, 13 Jul 2013 16:54:14 +0000 (18:54 +0200)]
usb: serial: option.c: remove ONDA MT825UP product ID fromdriver
commit
878c69aae986ae97084458c0183a8c0a059865b1 upstream.
Some (very few) early devices like mine, where not exposting a proper CDC
descriptor. This was fixed with an immediate firmware update from the vendor,
and pre-installed on newer devices.
So actual devices can be driven by cdc_acm.c + cdc_ether.c.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Wed, 10 Jul 2013 17:25:02 +0000 (12:25 -0500)]
usb: serial: option: add Olivetti Olicard 200
commit
4cf76df06ecc852633ed927d91e01c83c33bc331 upstream.
Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
interface protocols are unknown.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Fri, 28 Jun 2013 15:15:25 +0000 (17:15 +0200)]
usb: option: add TP-LINK MA260
commit
94190301ffa059c2d127b3a67ec5d161d5c62681 upstream.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enrico Mioso [Sat, 29 Jun 2013 13:33:35 +0000 (15:33 +0200)]
usb: serial: option: blacklist ONDA MT689DC QMI interface
commit
3d1a69e726406ab662ab88fa30a3a05ed404334d upstream.
Prevent the option driver from binding itself to the QMI/WWAN interface, making
it unusable by the proper driver.
Signed-off-by: enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Maier [Fri, 26 Apr 2013 15:33:45 +0000 (17:33 +0200)]
zfcp: block queue limits with data router
commit
5fea4291deacd80188b996d2f555fc6a1940e5d4 upstream.
Commit
86a9668a8d29ea711613e1cb37efa68e7c4db564
"[SCSI] zfcp: support for hardware data router"
reduced the initial block queue limits in the scsi_host_template to the
absolute minimum and adjusted them later on. However, the adjustment was
too late for the BSG devices of Scsi_Host and fc_host.
Therefore, ioctl(..., SG_IO, ...) with request or response size > 4kB to a
BSG device of an fc_host or a Scsi_Host fails with EINVAL. As a result,
users of such ioctl such as HBA_SendCTPassThru() in libzfcphbaapi return
with error HBA_STATUS_ERROR.
Initialize the block queue limits in zfcp_scsi_host_template to the
greatest common denominator (GCD).
While we cannot exploit the slightly enlarged maximum request size with
data router, this should be neglectible. Doing so also avoids running into
trouble after live guest relocation (LGR) / migration from a data router
FCP device to an FCP device that does not support data router. In that
case, zfcp would figure out the new limits on adapter recovery, but the
fc_host and Scsi_Host (plus in fact all sdevs) still exist with the old and
now too large queue limits.
It should also OK, not to use half the size as in the DIX case, because
fc_host and Scsi_Host do not transport FCP requests including SCSI commands
using protection data.
[Backported for 3.4-stable. commit a53c8fa since v3.6-rc1 unified
copyright messages, e.g: revise such messages 'Copyright IBM Corporation'
as 'Copyright IBM Corp', so updated the messages as a53c8fa did. - zliu]
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Zhouping Liu <zliu@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andi Kleen [Mon, 3 Sep 2012 18:50:30 +0000 (20:50 +0200)]
SCSI: Fix incorrect memset in bnx2fc_parse_fcp_rsp
commit
16da05b1158d1bcb31656e636a8736a663b1cf1f upstream.
gcc 4.8 warns because the memset only clears sizeof(char *) bytes, not
the whole buffer. Use the correct buffer size and clear the whole sense
buffer.
/backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c: In
function 'bnx2fc_parse_fcp_rsp':
/backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c:1810:41:
warning: argument to 'sizeof' in 'memset' call is the same expression as
the destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer));
^
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Wed, 21 Nov 2012 08:54:48 +0000 (09:54 +0100)]
SCSI: megaraid_sas: fix memory leak if SGL has zero length entries
commit
7a6a731bd00ca90d0e250867c3b9c05b5ff0fa49 upstream.
commit
98cb7e44 ([SCSI] megaraid_sas: Sanity check user
supplied length before passing it to dma_alloc_coherent())
introduced a memory leak. Memory allocated for entries
following zero length SGL entries will not be freed.
Reference: http://bugs.debian.org/688198
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Fri, 28 Jun 2013 14:04:02 +0000 (16:04 +0200)]
writeback: Fix periodic writeback after fs mount
commit
a5faeaf9109578e65e1a32e2a3e76c8b47e7dcb6 upstream.
Code in blkdev.c moves a device inode to default_backing_dev_info when
the last reference to the device is put and moves the device inode back
to its bdi when the first reference is acquired. This includes moving to
wb.b_dirty list if the device inode is dirty. The code however doesn't
setup timer to wake corresponding flusher thread and while wb.b_dirty
list is non-empty __mark_inode_dirty() will not set it up either. Thus
periodic writeback is effectively disabled until a sync(2) call which can
lead to unexpected data loss in case of crash or power failure.
Fix the problem by setting up a timer for periodic writeback in case we
add the first dirty inode to wb.b_dirty list in bdev_inode_switch_bdi().
Reported-by: Bert De Jonghe <Bert.DeJonghe@amplidata.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 18 Jul 2013 16:35:10 +0000 (09:35 -0700)]
vlan: fix a race in egress prio management
[ Upstream commit
3e3aac497513c669e1c62c71e1d552ea85c1d974 ]
egress_priority_map[] hash table updates are protected by rtnl,
and we never remove elements until device is dismantled.
We have to make sure that before inserting an new element in hash table,
all its fields are committed to memory or else another cpu could
find corrupt values and crash.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Horman [Tue, 16 Jul 2013 14:49:41 +0000 (10:49 -0400)]
atl1e: unmap partially mapped skb on dma error and free skb
[ Upstream commit
584ec4355355ffac43571b02a314d43eb2f7fcbf ]
Ben Hutchings pointed out that my recent update to atl1e
in commit
352900b583b2852152a1e05ea0e8b579292e731e
("atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the event that an error occurs, so we don't leak. Untested, as
I don't have hardware. I think its pretty straightforward, but please
review closely.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Jay Cliburn <jcliburn@gmail.com>
CC: Chris Snook <chris.snook@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Horman [Fri, 12 Jul 2013 14:58:48 +0000 (10:58 -0400)]
atl1e: fix dma mapping warnings
[ Upstream commit
352900b583b2852152a1e05ea0e8b579292e731e ]
Recently had this backtrace reported:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
Hardware name: System Product Name
ATL1E 0000:02:00.0: DMA-API: device driver failed to check map error[device
address=0x00000000cbfd1000] [size=90 bytes] [mapped as single]
Modules linked in: xt_conntrack nf_conntrack ebtable_filter ebtables
ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt
iTCO_vendor_support snd_hda_intel acpi_cpufreq mperf coretemp btrfs zlib_deflate
snd_hda_codec snd_hwdep microcode raid6_pq libcrc32c snd_seq usblp serio_raw xor
snd_seq_device joydev snd_pcm snd_page_alloc snd_timer snd lpc_ich i2c_i801
soundcore mfd_core atl1e asus_atk0110 ata_generic pata_acpi radeon i2c_algo_bit
drm_kms_helper ttm drm i2c_core pata_marvell uinput
Pid: 314, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.3.fc19.x86_64 #1
Call Trace:
<IRQ> [<
ffffffff81069106>] warn_slowpath_common+0x66/0x80
[<
ffffffff8106916c>] warn_slowpath_fmt+0x4c/0x50
[<
ffffffff8138151d>] check_unmap+0x47d/0x930
[<
ffffffff810ad048>] ? sched_clock_cpu+0xa8/0x100
[<
ffffffff81381a2f>] debug_dma_unmap_page+0x5f/0x70
[<
ffffffff8137ce30>] ? unmap_single+0x20/0x30
[<
ffffffffa01569a1>] atl1e_intr+0x3a1/0x5b0 [atl1e]
[<
ffffffff810d53fd>] ? trace_hardirqs_off+0xd/0x10
[<
ffffffff81119636>] handle_irq_event_percpu+0x56/0x390
[<
ffffffff811199ad>] handle_irq_event+0x3d/0x60
[<
ffffffff8111cb6a>] handle_fasteoi_irq+0x5a/0x100
[<
ffffffff8101c36f>] handle_irq+0xbf/0x150
[<
ffffffff811dcb2f>] ? file_sb_list_del+0x3f/0x50
[<
ffffffff81073b10>] ? irq_enter+0x50/0xa0
[<
ffffffff8172738d>] do_IRQ+0x4d/0xc0
[<
ffffffff811dcb2f>] ? file_sb_list_del+0x3f/0x50
[<
ffffffff8171c6b2>] common_interrupt+0x72/0x72
<EOI> [<
ffffffff810db5b2>] ? lock_release+0xc2/0x310
[<
ffffffff8109ea04>] lg_local_unlock_cpu+0x24/0x50
[<
ffffffff811dcb2f>] file_sb_list_del+0x3f/0x50
[<
ffffffff811dcb6d>] fput+0x2d/0xc0
[<
ffffffff811d8ea1>] filp_close+0x61/0x90
[<
ffffffff811fae4d>] __close_fd+0x8d/0x150
[<
ffffffff811d8ef0>] sys_close+0x20/0x50
[<
ffffffff81725699>] system_call_fastpath+0x16/0x1b
The usual straighforward failure to check for dma_mapping_error after a map
operation is completed.
This patch should fix it, the reporter wandered off after filing this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=954170
and I don't have hardware to test, but the fix is pretty straightforward, so I
figured I'd post it for review.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Jay Cliburn <jcliburn@gmail.com>
CC: Chris Snook <chris.snook@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dingtianhong [Thu, 11 Jul 2013 11:04:06 +0000 (19:04 +0800)]
ifb: fix oops when loading the ifb failed
[ Upstream commit
f2966cd5691058b8674a20766525bedeaea9cbcf ]
If __rtnl_link_register() return faild when loading the ifb, it will
take the wrong path and get oops, so fix it just like dummy.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dingtianhong [Thu, 11 Jul 2013 11:04:02 +0000 (19:04 +0800)]
dummy: fix oops when loading the dummy failed
[ Upstream commit
2c8a01894a12665d8059fad8f0a293c98a264121 ]
We rename the dummy in modprobe.conf like this:
install dummy0 /sbin/modprobe -o dummy0 --ignore-install dummy
install dummy1 /sbin/modprobe -o dummy1 --ignore-install dummy
We got oops when we run the command:
modprobe dummy0
modprobe dummy1
------------[ cut here ]------------
[ 3302.187584] BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
[ 3302.195411] IP: [<
ffffffff813fe62a>] __rtnl_link_unregister+0x9a/0xd0
[ 3302.201844] PGD
85c94a067 PUD
8517bd067 PMD 0
[ 3302.206305] Oops: 0002 [#1] SMP
[ 3302.299737] task:
ffff88105ccea300 ti:
ffff880eba4a0000 task.ti:
ffff880eba4a0000
[ 3302.307186] RIP: 0010:[<
ffffffff813fe62a>] [<
ffffffff813fe62a>] __rtnl_link_unregister+0x9a/0xd0
[ 3302.316044] RSP: 0018:
ffff880eba4a1dd8 EFLAGS:
00010246
[ 3302.321332] RAX:
0000000000000000 RBX:
ffffffff81a9d738 RCX:
0000000000000002
[ 3302.328436] RDX:
0000000000000000 RSI:
ffffffffa04d602c RDI:
ffff880eba4a1dd8
[ 3302.335541] RBP:
ffff880eba4a1e18 R08:
dead000000200200 R09:
dead000000100100
[ 3302.342644] R10:
0000000000000080 R11:
0000000000000003 R12:
ffffffff81a9d788
[ 3302.349748] R13:
ffffffffa04d7020 R14:
ffffffff81a9d670 R15:
ffff880eba4a1dd8
[ 3302.364910] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 3302.370630] CR2:
0000000000000008 CR3:
000000085e15e000 CR4:
00000000000427e0
[ 3302.377734] DR0:
0000000000000003 DR1:
00000000000000b0 DR2:
0000000000000001
[ 3302.384838] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 3302.391940] Stack:
[ 3302.393944]
ffff880eba4a1dd8 ffff880eba4a1dd8 ffff880eba4a1e18 ffffffffa04d70c0
[ 3302.401350]
00000000ffffffef ffffffffa01a8000 0000000000000000 ffffffff816111c8
[ 3302.408758]
ffff880eba4a1e48 ffffffffa01a80be ffff880eba4a1e48 ffffffffa04d70c0
[ 3302.416164] Call Trace:
[ 3302.418605] [<
ffffffffa01a8000>] ? 0xffffffffa01a7fff
[ 3302.423727] [<
ffffffffa01a80be>] dummy_init_module+0xbe/0x1000 [dummy0]
[ 3302.430405] [<
ffffffffa01a8000>] ? 0xffffffffa01a7fff
[ 3302.435535] [<
ffffffff81000322>] do_one_initcall+0x152/0x1b0
[ 3302.441263] [<
ffffffff810ab24b>] do_init_module+0x7b/0x200
[ 3302.446824] [<
ffffffff810ad3d2>] load_module+0x4e2/0x530
[ 3302.452215] [<
ffffffff8127ae40>] ? ddebug_dyndbg_boot_param_cb+0x60/0x60
[ 3302.458979] [<
ffffffff810ad5f1>] SyS_init_module+0xd1/0x130
[ 3302.464627] [<
ffffffff814b9652>] system_call_fastpath+0x16/0x1b
[ 3302.490090] RIP [<
ffffffff813fe62a>] __rtnl_link_unregister+0x9a/0xd0
[ 3302.496607] RSP <
ffff880eba4a1dd8>
[ 3302.500084] CR2:
0000000000000008
[ 3302.503466] ---[ end trace
8342d49cd49f78ed ]---
The reason is that when loading dummy, if __rtnl_link_register() return failed,
the init_module should return and avoid take the wrong path.
Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Thu, 11 Jul 2013 17:16:54 +0000 (13:16 -0400)]
9p: fix off by one causing access violations and memory corruption
[ Upstream commit
110ecd69a9feea82a152bbf9b12aba57e6396883 ]
p9_release_pages() would attempt to dereference one value past the end of
pages[]. This would cause the following crashes:
[ 6293.171817] BUG: unable to handle kernel paging request at
ffff8807c96f3000
[ 6293.174146] IP: [<
ffffffff8412793b>] p9_release_pages+0x3b/0x60
[ 6293.176447] PGD 79c5067 PUD
82c1e3067 PMD
82c197067 PTE
80000007c96f3060
[ 6293.180060] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 6293.180060] Modules linked in:
[ 6293.180060] CPU: 62 PID: 174043 Comm: modprobe Tainted: G W 3.10.0-next-
20130710-sasha #3954
[ 6293.180060] task:
ffff8807b803b000 ti:
ffff880787dde000 task.ti:
ffff880787dde000
[ 6293.180060] RIP: 0010:[<
ffffffff8412793b>] [<
ffffffff8412793b>] p9_release_pages+0x3b/0x60
[ 6293.214316] RSP: 0000:
ffff880787ddfc28 EFLAGS:
00010202
[ 6293.214316] RAX:
0000000000000001 RBX:
ffff8807c96f2ff8 RCX:
0000000000000000
[ 6293.222017] RDX:
ffff8807b803b000 RSI:
0000000000000001 RDI:
ffffea001c7e3d40
[ 6293.222017] RBP:
ffff880787ddfc48 R08:
0000000000000000 R09:
0000000000000000
[ 6293.222017] R10:
0000000000000001 R11:
0000000000000000 R12:
0000000000000001
[ 6293.222017] R13:
0000000000000001 R14:
ffff8807cc50c070 R15:
ffff8807cc50c070
[ 6293.222017] FS:
00007f572641d700(0000) GS:
ffff8807f3600000(0000) knlGS:
0000000000000000
[ 6293.256784] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 6293.256784] CR2:
ffff8807c96f3000 CR3:
00000007c8e81000 CR4:
00000000000006e0
[ 6293.256784] Stack:
[ 6293.256784]
ffff880787ddfcc8 ffff880787ddfcc8 0000000000000000 ffff880787ddfcc8
[ 6293.256784]
ffff880787ddfd48 ffffffff84128be8 ffff880700000002 0000000000000001
[ 6293.256784]
ffff8807b803b000 ffff880787ddfce0 0000100000000000 0000000000000000
[ 6293.256784] Call Trace:
[ 6293.256784] [<
ffffffff84128be8>] p9_virtio_zc_request+0x598/0x630
[ 6293.256784] [<
ffffffff8115c610>] ? wake_up_bit+0x40/0x40
[ 6293.256784] [<
ffffffff841209b1>] p9_client_zc_rpc+0x111/0x3a0
[ 6293.256784] [<
ffffffff81174b78>] ? sched_clock_cpu+0x108/0x120
[ 6293.256784] [<
ffffffff84122a21>] p9_client_read+0xe1/0x2c0
[ 6293.256784] [<
ffffffff81708a90>] v9fs_file_read+0x90/0xc0
[ 6293.256784] [<
ffffffff812bd073>] vfs_read+0xc3/0x130
[ 6293.256784] [<
ffffffff811a78bd>] ? trace_hardirqs_on+0xd/0x10
[ 6293.256784] [<
ffffffff812bd5a2>] SyS_read+0x62/0xa0
[ 6293.256784] [<
ffffffff841a1a00>] tracesys+0xdd/0xe2
[ 6293.256784] Code: 66 90 48 89 fb 41 89 f5 48 8b 3f 48 85 ff 74 29 85 f6 74 25 45 31 e4 66 0f 1f 84 00 00 00 00 00 e8 eb 14 12 fd 41 ff c4 49 63 c4 <48> 8b 3c c3 48 85 ff 74 05 45 39 e5 75 e7 48 83 c4 08 5b 41 5c
[ 6293.256784] RIP [<
ffffffff8412793b>] p9_release_pages+0x3b/0x60
[ 6293.256784] RSP <
ffff880787ddfc28>
[ 6293.256784] CR2:
ffff8807c96f3000
[ 6293.256784] ---[ end trace
50822ee72cd360fc ]---
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Frederic Sowa [Wed, 10 Jul 2013 21:00:57 +0000 (23:00 +0200)]
ipv6: in case of link failure remove route directly instead of letting it expire
[ Upstream commit
1eb4f758286884e7566627164bca4c4a16952a83 ]
We could end up expiring a route which is part of an ecmp route set. Doing
so would invalidate the rt->rt6i_nsiblings calculations and could provoke
the following panic:
[ 80.144667] ------------[ cut here ]------------
[ 80.145172] kernel BUG at net/ipv6/ip6_fib.c:733!
[ 80.145172] invalid opcode: 0000 [#1] SMP
[ 80.145172] Modules linked in: 8021q nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables
+snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer virtio_balloon snd soundcore i2c_piix4 i2c_core virtio_net virtio_blk
[ 80.145172] CPU: 1 PID: 786 Comm: ping6 Not tainted 3.10.0+ #118
[ 80.145172] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 80.145172] task:
ffff880117fa0000 ti:
ffff880118770000 task.ti:
ffff880118770000
[ 80.145172] RIP: 0010:[<
ffffffff815f3b5d>] [<
ffffffff815f3b5d>] fib6_add+0x75d/0x830
[ 80.145172] RSP: 0018:
ffff880118771798 EFLAGS:
00010202
[ 80.145172] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
ffff88011350e480
[ 80.145172] RDX:
ffff88011350e238 RSI:
0000000000000004 RDI:
ffff88011350f738
[ 80.145172] RBP:
ffff880118771848 R08:
ffff880117903280 R09:
0000000000000001
[ 80.145172] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88011350f680
[ 80.145172] R13:
ffff880117903280 R14:
ffff880118771890 R15:
ffff88011350ef90
[ 80.145172] FS:
00007f02b5127740(0000) GS:
ffff88011fd00000(0000) knlGS:
0000000000000000
[ 80.145172] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 80.145172] CR2:
00007f981322a000 CR3:
00000001181b1000 CR4:
00000000000006e0
[ 80.145172] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 80.145172] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 80.145172] Stack:
[ 80.145172]
0000000000000001 ffff880100000000 ffff880100000000 ffff880117903280
[ 80.145172]
0000000000000000 ffff880119a4cf00 0000000000000400 00000000000007fa
[ 80.145172]
0000000000000000 0000000000000000 0000000000000000 ffff88011350f680
[ 80.145172] Call Trace:
[ 80.145172] [<
ffffffff815eeceb>] ? rt6_bind_peer+0x4b/0x90
[ 80.145172] [<
ffffffff815ed985>] __ip6_ins_rt+0x45/0x70
[ 80.145172] [<
ffffffff815eee35>] ip6_ins_rt+0x35/0x40
[ 80.145172] [<
ffffffff815ef1e4>] ip6_pol_route.isra.44+0x3a4/0x4b0
[ 80.145172] [<
ffffffff815ef34a>] ip6_pol_route_output+0x2a/0x30
[ 80.145172] [<
ffffffff81616077>] fib6_rule_action+0xd7/0x210
[ 80.145172] [<
ffffffff815ef320>] ? ip6_pol_route_input+0x30/0x30
[ 80.145172] [<
ffffffff81553026>] fib_rules_lookup+0xc6/0x140
[ 80.145172] [<
ffffffff81616374>] fib6_rule_lookup+0x44/0x80
[ 80.145172] [<
ffffffff815ef320>] ? ip6_pol_route_input+0x30/0x30
[ 80.145172] [<
ffffffff815edea3>] ip6_route_output+0x73/0xb0
[ 80.145172] [<
ffffffff815dfdf3>] ip6_dst_lookup_tail+0x2c3/0x2e0
[ 80.145172] [<
ffffffff813007b1>] ? list_del+0x11/0x40
[ 80.145172] [<
ffffffff81082a4c>] ? remove_wait_queue+0x3c/0x50
[ 80.145172] [<
ffffffff815dfe4d>] ip6_dst_lookup_flow+0x3d/0xa0
[ 80.145172] [<
ffffffff815fda77>] rawv6_sendmsg+0x267/0xc20
[ 80.145172] [<
ffffffff815a8a83>] inet_sendmsg+0x63/0xb0
[ 80.145172] [<
ffffffff8128eb93>] ? selinux_socket_sendmsg+0x23/0x30
[ 80.145172] [<
ffffffff815218d6>] sock_sendmsg+0xa6/0xd0
[ 80.145172] [<
ffffffff81524a68>] SYSC_sendto+0x128/0x180
[ 80.145172] [<
ffffffff8109825c>] ? update_curr+0xec/0x170
[ 80.145172] [<
ffffffff81041d09>] ? kvm_clock_get_cycles+0x9/0x10
[ 80.145172] [<
ffffffff810afd1e>] ? __getnstimeofday+0x3e/0xd0
[ 80.145172] [<
ffffffff8152509e>] SyS_sendto+0xe/0x10
[ 80.145172] [<
ffffffff8164efd9>] system_call_fastpath+0x16/0x1b
[ 80.145172] Code: fe ff ff 41 f6 45 2a 06 0f 85 ca fe ff ff 49 8b 7e 08 4c 89 ee e8 94 ef ff ff e9 b9 fe ff ff 48 8b 82 28 05 00 00 e9 01 ff ff ff <0f> 0b 49 8b 54 24 30 0d 00 00 40 00 89 83 14 01 00 00 48 89 53
[ 80.145172] RIP [<
ffffffff815f3b5d>] fib6_add+0x75d/0x830
[ 80.145172] RSP <
ffff880118771798>
[ 80.387413] ---[ end trace
02f20b7a8b81ed95 ]---
[ 80.390154] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Wed, 10 Jul 2013 05:43:28 +0000 (13:43 +0800)]
macvtap: correctly linearize skb when zerocopy is used
[ Upstream commit
61d46bf979d5cd7c164709a80ad5676a35494aae ]
Userspace may produce vectors greater than MAX_SKB_FRAGS. When we try to
linearize parts of the skb to let the rest of iov to be fit in
the frags, we need count copylen into linear when calling macvtap_alloc_skb()
instead of partly counting it into data_len. Since this breaks
zerocopy_sg_from_iovec() since its inner counter assumes nr_frags should
be zero at beginning. This cause nr_frags to be increased wrongly without
setting the correct frags.
This bug were introduced from
b92946e2919134ebe2a4083e4302236295ea2a73
(macvtap: zerocopy: validate vectors before building skb).
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dingtianhong [Wed, 10 Jul 2013 04:04:02 +0000 (12:04 +0800)]
ifb: fix rcu_sched self-detected stalls
[ Upstream commit
440d57bc5ff55ec1efb3efc9cbe9420b4bbdfefa ]
According to the commit
16b0dc29c1af9df341428f4c49ada4f626258082
(dummy: fix rcu_sched self-detected stalls)
Eric Dumazet fix the problem in dummy, but the ifb will occur the
same problem like the dummy modules.
Trying to "modprobe ifb numifbs=30000" triggers :
INFO: rcu_sched self-detected stall on CPU
After this splat, RTNL is locked and reboot is needed.
We must call cond_resched() to avoid this, even holding RTNL.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Kleikamp [Mon, 1 Jul 2013 21:49:22 +0000 (16:49 -0500)]
sunvnet: vnet_port_remove must call unregister_netdev
[ Upstream commit
aabb9875d02559ab9b928cd6f259a5cc4c21a589 ]
The missing call to unregister_netdev() leaves the interface active
after the driver is unloaded by rmmod.
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Frederic Sowa [Tue, 2 Jul 2013 06:04:05 +0000 (08:04 +0200)]
ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size
[ Upstream commit
75a493e60ac4bbe2e977e7129d6d8cbb0dd236be ]
If the socket had an IPV6_MTU value set, ip6_append_data_mtu lost track
of this when appending the second frame on a corked socket. This results
in the following splat:
[37598.993962] ------------[ cut here ]------------
[37598.994008] kernel BUG at net/core/skbuff.c:2064!
[37598.994008] invalid opcode: 0000 [#1] SMP
[37598.994008] Modules linked in: tcp_lp uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media vfat fat usb_storage fuse ebtable_nat xt_CHECKSUM bridge stp llc ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat
+nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi
+scsi_transport_iscsi rfcomm bnep iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant arc4 iwldvm mac80211 snd_hda_intel acpi_cpufreq mperf coretemp snd_hda_codec microcode cdc_wdm cdc_acm
[37598.994008] snd_hwdep cdc_ether snd_seq snd_seq_device usbnet mii joydev btusb snd_pcm bluetooth i2c_i801 e1000e lpc_ich mfd_core ptp iwlwifi pps_core snd_page_alloc mei cfg80211 snd_timer thinkpad_acpi snd tpm_tis soundcore rfkill tpm tpm_bios vhost_net tun macvtap macvlan kvm_intel kvm uinput binfmt_misc
+dm_crypt i915 i2c_algo_bit drm_kms_helper drm i2c_core wmi video
[37598.994008] CPU 0
[37598.994008] Pid: 27320, comm: t2 Not tainted 3.9.6-200.fc18.x86_64 #1 LENOVO 27744PG/27744PG
[37598.994008] RIP: 0010:[<
ffffffff815443a5>] [<
ffffffff815443a5>] skb_copy_and_csum_bits+0x325/0x330
[37598.994008] RSP: 0018:
ffff88003670da18 EFLAGS:
00010202
[37598.994008] RAX:
ffff88018105c018 RBX:
0000000000000004 RCX:
00000000000006c0
[37598.994008] RDX:
ffff88018105a6c0 RSI:
ffff88018105a000 RDI:
ffff8801e1b0aa00
[37598.994008] RBP:
ffff88003670da78 R08:
0000000000000000 R09:
ffff88018105c040
[37598.994008] R10:
ffff8801e1b0aa00 R11:
0000000000000000 R12:
000000000000fff8
[37598.994008] R13:
00000000000004fc R14:
00000000ffff0504 R15:
0000000000000000
[37598.994008] FS:
00007f28eea59740(0000) GS:
ffff88023bc00000(0000) knlGS:
0000000000000000
[37598.994008] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[37598.994008] CR2:
0000003d935789e0 CR3:
00000000365cb000 CR4:
00000000000407f0
[37598.994008] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[37598.994008] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[37598.994008] Process t2 (pid: 27320, threadinfo
ffff88003670c000, task
ffff88022c162ee0)
[37598.994008] Stack:
[37598.994008]
ffff88022e098a00 ffff88020f973fc0 0000000000000008 00000000000004c8
[37598.994008]
ffff88020f973fc0 00000000000004c4 ffff88003670da78 ffff8801e1b0a200
[37598.994008]
0000000000000018 00000000000004c8 ffff88020f973fc0 00000000000004c4
[37598.994008] Call Trace:
[37598.994008] [<
ffffffff815fc21f>] ip6_append_data+0xccf/0xfe0
[37598.994008] [<
ffffffff8158d9f0>] ? ip_copy_metadata+0x1a0/0x1a0
[37598.994008] [<
ffffffff81661f66>] ? _raw_spin_lock_bh+0x16/0x40
[37598.994008] [<
ffffffff8161548d>] udpv6_sendmsg+0x1ed/0xc10
[37598.994008] [<
ffffffff812a2845>] ? sock_has_perm+0x75/0x90
[37598.994008] [<
ffffffff815c3693>] inet_sendmsg+0x63/0xb0
[37598.994008] [<
ffffffff812a2973>] ? selinux_socket_sendmsg+0x23/0x30
[37598.994008] [<
ffffffff8153a450>] sock_sendmsg+0xb0/0xe0
[37598.994008] [<
ffffffff810135d1>] ? __switch_to+0x181/0x4a0
[37598.994008] [<
ffffffff8153d97d>] sys_sendto+0x12d/0x180
[37598.994008] [<
ffffffff810dfb64>] ? __audit_syscall_entry+0x94/0xf0
[37598.994008] [<
ffffffff81020ed1>] ? syscall_trace_enter+0x231/0x240
[37598.994008] [<
ffffffff8166a7e7>] tracesys+0xdd/0xe2
[37598.994008] Code: fe 07 00 00 48 c7 c7 04 28 a6 81 89 45 a0 4c 89 4d b8 44 89 5d a8 e8 1b ac b1 ff 44 8b 5d a8 4c 8b 4d b8 8b 45 a0 e9 cf fe ff ff <0f> 0b 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 48
[37598.994008] RIP [<
ffffffff815443a5>] skb_copy_and_csum_bits+0x325/0x330
[37598.994008] RSP <
ffff88003670da18>
[37599.007323] ---[ end trace
d69f6a17f8ac8eee ]---
While there, also check if path mtu discovery is activated for this
socket. The logic was adapted from ip6_append_data when first writing
on the corked socket.
This bug was introduced with commit
0c1833797a5a6ec23ea9261d979aa18078720b74 ("ipv6: fix incorrect ipsec
fragment").
v2:
a) Replace IPV6_PMTU_DISC_DO with IPV6_PMTUDISC_PROBE.
b) Don't pass ipv6_pinfo to ip6_append_data_mtu (suggestion by Gao
feng, thanks!).
c) Change mtu to unsigned int, else we get a warning about
non-matching types because of the min()-macro type-check.
Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Frederic Sowa [Mon, 1 Jul 2013 18:21:30 +0000 (20:21 +0200)]
ipv6: call udp_push_pending_frames when uncorking a socket with AF_INET pending data
[ Upstream commit
8822b64a0fa64a5dd1dfcf837c5b0be83f8c05d1 ]
We accidentally call down to ip6_push_pending_frames when uncorking
pending AF_INET data on a ipv6 socket. This results in the following
splat (from Dave Jones):
skbuff: skb_under_panic: text:
ffffffff816765f6 len:48 put:40 head:
ffff88013deb6df0 data:
ffff88013deb6dec tail:0x2c end:0xc0 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:126!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: dccp_ipv4 dccp 8021q garp bridge stp dlci mpoa snd_seq_dummy sctp fuse hidp tun bnep nfnetlink scsi_transport_iscsi rfcomm can_raw can_bcm af_802154 appletalk caif_socket can caif ipt_ULOG x25 rose af_key pppoe pppox ipx phonet irda llc2 ppp_generic slhc p8023 psnap p8022 llc crc_ccitt atm bluetooth
+netrom ax25 nfc rfkill rds af_rxrpc coretemp hwmon kvm_intel kvm crc32c_intel snd_hda_codec_realtek ghash_clmulni_intel microcode pcspkr snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep usb_debug snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd pps_core soundcore xfs libcrc32c
CPU: 2 PID: 8095 Comm: trinity-child2 Not tainted 3.10.0-rc7+ #37
task:
ffff8801f52c2520 ti:
ffff8801e6430000 task.ti:
ffff8801e6430000
RIP: 0010:[<
ffffffff816e759c>] [<
ffffffff816e759c>] skb_panic+0x63/0x65
RSP: 0018:
ffff8801e6431de8 EFLAGS:
00010282
RAX:
0000000000000086 RBX:
ffff8802353d3cc0 RCX:
0000000000000006
RDX:
0000000000003b90 RSI:
ffff8801f52c2ca0 RDI:
ffff8801f52c2520
RBP:
ffff8801e6431e08 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000001 R11:
0000000000000001 R12:
ffff88022ea0c800
R13:
ffff88022ea0cdf8 R14:
ffff8802353ecb40 R15:
ffffffff81cc7800
FS:
00007f5720a10740(0000) GS:
ffff880244c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000005862000 CR3:
000000022843c000 CR4:
00000000001407e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000600
Stack:
ffff88013deb6dec 000000000000002c 00000000000000c0 ffffffff81a3f6e4
ffff8801e6431e18 ffffffff8159a9aa ffff8801e6431e90 ffffffff816765f6
ffffffff810b756b 0000000700000002 ffff8801e6431e40 0000fea9292aa8c0
Call Trace:
[<
ffffffff8159a9aa>] skb_push+0x3a/0x40
[<
ffffffff816765f6>] ip6_push_pending_frames+0x1f6/0x4d0
[<
ffffffff810b756b>] ? mark_held_locks+0xbb/0x140
[<
ffffffff81694919>] udp_v6_push_pending_frames+0x2b9/0x3d0
[<
ffffffff81694660>] ? udplite_getfrag+0x20/0x20
[<
ffffffff8162092a>] udp_lib_setsockopt+0x1aa/0x1f0
[<
ffffffff811cc5e7>] ? fget_light+0x387/0x4f0
[<
ffffffff816958a4>] udpv6_setsockopt+0x34/0x40
[<
ffffffff815949f4>] sock_common_setsockopt+0x14/0x20
[<
ffffffff81593c31>] SyS_setsockopt+0x71/0xd0
[<
ffffffff816f5d54>] tracesys+0xdd/0xe2
Code: 00 00 48 89 44 24 10 8b 87 d8 00 00 00 48 89 44 24 08 48 8b 87 e8 00 00 00 48 c7 c7 c0 04 aa 81 48 89 04 24 31 c0 e8 e1 7e ff ff <0f> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55
RIP [<
ffffffff816e759c>] skb_panic+0x63/0x65
RSP <
ffff8801e6431de8>
This patch adds a check if the pending data is of address family AF_INET
and directly calls udp_push_ending_frames from udp_v6_push_pending_frames
if that is the case.
This bug was found by Dave Jones with trinity.
(Also move the initialization of fl6 below the AF_INET check, even if
not strictly necessary.)
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Dave Jones <davej@redhat.com>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Yongjun [Tue, 2 Jul 2013 01:02:07 +0000 (09:02 +0800)]
l2tp: add missing .owner to struct pppox_proto
[ Upstream commit
e1558a93b61962710733dc8c11a2bc765607f1cd ]
Add missing .owner of struct pppox_proto. This prevents the
module from being removed from underneath its users.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amerigo Wang [Sat, 29 Jun 2013 13:30:49 +0000 (21:30 +0800)]
ipv6,mcast: always hold idev->lock before mca_lock
[ Upstream commit
8965779d2c0e6ab246c82a405236b1fb2adae6b2, with
some bits from commit
b7b1bfce0bb68bd8f6e62a28295922785cc63781
("ipv6: split duplicate address detection and router solicitation timer")
to get the __ipv6_get_lladdr() used by this patch. ]
dingtianhong reported the following deadlock detected by lockdep:
======================================================
[ INFO: possible circular locking dependency detected ]
3.4.24.05-0.1-default #1 Not tainted
-------------------------------------------------------
ksoftirqd/0/3 is trying to acquire lock:
(&ndev->lock){+.+...}, at: [<
ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
but task is already holding lock:
(&mc->mca_lock){+.+...}, at: [<
ffffffff8149d130>] mld_send_report+0x40/0x150
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&mc->mca_lock){+.+...}:
[<
ffffffff810a8027>] validate_chain+0x637/0x730
[<
ffffffff810a8417>] __lock_acquire+0x2f7/0x500
[<
ffffffff810a8734>] lock_acquire+0x114/0x150
[<
ffffffff814f691a>] rt_spin_lock+0x4a/0x60
[<
ffffffff8149e4bb>] igmp6_group_added+0x3b/0x120
[<
ffffffff8149e5d8>] ipv6_mc_up+0x38/0x60
[<
ffffffff81480a4d>] ipv6_find_idev+0x3d/0x80
[<
ffffffff81483175>] addrconf_notify+0x3d5/0x4b0
[<
ffffffff814fae3f>] notifier_call_chain+0x3f/0x80
[<
ffffffff81073471>] raw_notifier_call_chain+0x11/0x20
[<
ffffffff813d8722>] call_netdevice_notifiers+0x32/0x60
[<
ffffffff813d92d4>] __dev_notify_flags+0x34/0x80
[<
ffffffff813d9360>] dev_change_flags+0x40/0x70
[<
ffffffff813ea627>] do_setlink+0x237/0x8a0
[<
ffffffff813ebb6c>] rtnl_newlink+0x3ec/0x600
[<
ffffffff813eb4d0>] rtnetlink_rcv_msg+0x160/0x310
[<
ffffffff814040b9>] netlink_rcv_skb+0x89/0xb0
[<
ffffffff813eb357>] rtnetlink_rcv+0x27/0x40
[<
ffffffff81403e20>] netlink_unicast+0x140/0x180
[<
ffffffff81404a9e>] netlink_sendmsg+0x33e/0x380
[<
ffffffff813c4252>] sock_sendmsg+0x112/0x130
[<
ffffffff813c537e>] __sys_sendmsg+0x44e/0x460
[<
ffffffff813c5544>] sys_sendmsg+0x44/0x70
[<
ffffffff814feab9>] system_call_fastpath+0x16/0x1b
-> #0 (&ndev->lock){+.+...}:
[<
ffffffff810a798e>] check_prev_add+0x3de/0x440
[<
ffffffff810a8027>] validate_chain+0x637/0x730
[<
ffffffff810a8417>] __lock_acquire+0x2f7/0x500
[<
ffffffff810a8734>] lock_acquire+0x114/0x150
[<
ffffffff814f6c82>] rt_read_lock+0x42/0x60
[<
ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
[<
ffffffff8149b036>] mld_newpack+0xb6/0x160
[<
ffffffff8149b18b>] add_grhead+0xab/0xc0
[<
ffffffff8149d03b>] add_grec+0x3ab/0x460
[<
ffffffff8149d14a>] mld_send_report+0x5a/0x150
[<
ffffffff8149f99e>] igmp6_timer_handler+0x4e/0xb0
[<
ffffffff8105705a>] call_timer_fn+0xca/0x1d0
[<
ffffffff81057b9f>] run_timer_softirq+0x1df/0x2e0
[<
ffffffff8104e8c7>] handle_pending_softirqs+0xf7/0x1f0
[<
ffffffff8104ea3b>] __do_softirq_common+0x7b/0xf0
[<
ffffffff8104f07f>] __thread_do_softirq+0x1af/0x210
[<
ffffffff8104f1c1>] run_ksoftirqd+0xe1/0x1f0
[<
ffffffff8106c7de>] kthread+0xae/0xc0
[<
ffffffff814fff74>] kernel_thread_helper+0x4/0x10
actually we can just hold idev->lock before taking pmc->mca_lock,
and avoid taking idev->lock again when iterating idev->addr_list,
since the upper callers of mld_newpack() already take
read_lock_bh(&idev->lock).
Reported-by: dingtianhong <dingtianhong@huawei.com>
Cc: dingtianhong <dingtianhong@huawei.com>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Tested-by: Ding Tianhong <dingtianhong@huawei.com>
Tested-by: Chen Weilong <chenweilong@huawei.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Changli Gao [Fri, 28 Jun 2013 16:15:51 +0000 (00:15 +0800)]
net: Swap ver and type in pppoe_hdr
[ Upstream commit
b1a5a34bd0b8767ea689e68f8ea513e9710b671e ]
Ver and type in pppoe_hdr should be swapped as defined by RFC2516
section-4.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Jones [Fri, 28 Jun 2013 16:13:52 +0000 (12:13 -0400)]
x25: Fix broken locking in ioctl error paths.
[ Upstream commit
4ccb93ce7439b63c31bc7597bfffd13567fa483d ]
Two of the x25 ioctl cases have error paths that break out of the function without
unlocking the socket, leading to this warning:
================================================
[ BUG: lock held when returning to user space! ]
3.10.0-rc7+ #36 Not tainted
------------------------------------------------
trinity-child2/31407 is leaving the kernel with locks still held!
1 lock held by trinity-child2/31407:
#0: (sk_lock-AF_X25){+.+.+.}, at: [<
ffffffffa024b6da>] x25_ioctl+0x8a/0x740 [x25]
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 28 Jun 2013 09:37:42 +0000 (02:37 -0700)]
neighbour: fix a race in neigh_destroy()
[ Upstream commit
c9ab4d85de222f3390c67aedc9c18a50e767531e ]
There is a race in neighbour code, because neigh_destroy() uses
skb_queue_purge(&neigh->arp_queue) without holding neighbour lock,
while other parts of the code assume neighbour rwlock is what
protects arp_queue
Convert all skb_queue_purge() calls to the __skb_queue_purge() variant
Use __skb_queue_head_init() instead of skb_queue_head_init()
to make clear we do not use arp_queue.lock
And hold neigh->lock in neigh_destroy() to close the race.
Reported-by: Joe Jin <joe.jin@oracle.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Shtylyov [Thu, 20 Jun 2013 21:12:21 +0000 (01:12 +0400)]
sh_eth: fix unhandled RFE interrupt
[ Upstream commit
ca8c35852138ee0585eaffe6b9f10a5261ea7771 ]
EESR.RFE (receive FIFO overflow) interrupt is enabled by the driver on all SoCs
and sh_eth_error() handles it but it's not present in any initializer/assignment
of the 'eesr_err_check' field of 'struct sh_eth_cpu_data'. This leads to that
interrupt not being handled and cleared, and finally to disabling IRQ and the
driver being non-functional.
Modify DEFAULT_EESR_ERR_CHECK macro and all explicit initializers of the above
mentioned field to contain the EESR.RFE bit. Remove useless backslashes from the
initializers, while at it.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Wed, 26 Jun 2013 21:52:30 +0000 (23:52 +0200)]
af_key: fix info leaks in notify messages
[ Upstream commit
a5cc68f3d63306d0d288f31edfc2ae6ef8ecd887 ]
key_notify_sa_flush() and key_notify_policy_flush() miss to initialize
the sadb_msg_reserved member of the broadcasted message and thereby
leak 2 bytes of heap memory to listeners. Fix that.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 26 Jun 2013 11:15:07 +0000 (04:15 -0700)]
ipv6: ip6_sk_dst_check() must not assume ipv6 dst
[ Upstream commit
a963a37d384d71ad43b3e9e79d68d42fbe0901f3 ]
It's possible to use AF_INET6 sockets and to connect to an IPv4
destination. After this, socket dst cache is a pointer to a rtable,
not rt6_info.
ip6_sk_dst_check() should check the socket dst cache is IPv6, or else
various corruptions/crashes can happen.
Dave Jones can reproduce immediate crash with
trinity -q -l off -n -c sendmsg -c connect
With help from Hannes Frederic Sowa
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael S. Tsirkin [Sun, 23 Jun 2013 14:26:58 +0000 (17:26 +0300)]
macvtap: fix recovery from gup errors
[ Upstream commit
4c7ab054ab4f5d63625508ed6f8a607184cae7c2 ]
get user pages might fail partially in macvtap zero copy
mode. To recover we need to put all pages that we got,
but code used a wrong index resulting in double-free
errors.
Reported-by: Brad Hubbard <bhubbard@redhat.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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gao feng [Sun, 16 Jun 2013 03:14:30 +0000 (11:14 +0800)]
ipv6: don't call addrconf_dst_alloc again when enable lo
[ Upstream commit
a881ae1f625c599b460cc8f8a7fcb1c438f699ad ]
If we disable all of the net interfaces, and enable
un-lo interface before lo interface, we already allocated
the addrconf dst in ipv6_add_addr. So we shouldn't allocate
it again when we enable lo interface.
Otherwise the message below will be triggered.
unregister_netdevice: waiting for sit1 to become free. Usage count = 1
This problem is introduced by commit
25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aydin Arik [Fri, 14 Jun 2013 06:56:31 +0000 (18:56 +1200)]
ipv4: Fixed MD5 key lookups when adding/ removing MD5 to/ from TCP sockets.
[ Upstream commit
c0353c7b5da4cbd2ab8227e84bbc9c79890f24ce ]
MD5 key lookups on a given TCP socket were being performed
incorrectly. This fix alters parameter inputs to the MD5
lookup function tcp_md5_do_lookup, which is called by functions
tcp_md5_do_add and tcp_md5_do_del. Specifically, the change now
inputs the correct address and address family required to make
a proper lookup.
Signed-off-by: Aydin Arik <aydin.arik@alliedtelesis.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Lüssing [Sun, 16 Jun 2013 21:20:34 +0000 (23:20 +0200)]
bridge: fix switched interval for MLD Query types
[ Upstream commit
32de868cbc6bee010d2cee95b5071b25ecbec8c3 ]
General Queries (the one with the Multicast Address field
set to zero / '::') are supposed to have a Maximum Response Delay
of [Query Response Interval], while for Multicast-Address-Specific
Queries it is [Last Listener Query Interval] - not the other way
round. (see RFC2710, section 7.3+7.8)
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Kleikamp [Tue, 18 Jun 2013 14:05:36 +0000 (09:05 -0500)]
sparc: tsb must be flushed before tlb
Upstream commit
23a01138efe216f8084cfaa74b0b90dd4b097441
This fixes a race where a cpu may re-load a tlb from a stale tsb right
after it has been flushed by a remote function call.
I still see some instability when stressing the system with parallel
kernel builds while creating memory pressure by writing to
/proc/sys/vm/nr_hugepages, but this patch improves the stability
significantly.
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: Bob Picco <bob.picco@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bob picco [Tue, 11 Jun 2013 18:54:51 +0000 (14:54 -0400)]
sparc64 address-congruence property
Upstream commit
771a37ff4d80b80db3b0df3e7696f14b298c67b7
The Machine Description (MD) property "address-congruence-offset" is
optional. According to the MD specification the value is assumed 0UL when
not present. This caused early boot failure on T5.
Signed-off-by: Bob Picco <bob.picco@oracle.com>
CC: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Olivier DANET [Wed, 10 Jul 2013 20:56:10 +0000 (13:56 -0700)]
sparc32: vm_area_struct access for old Sun SPARCs.
Upstream commit
961246b4ed8da3bcf4ee1eb9147f341013553e3c
Commit
e4c6bfd2d79d063017ab19a18915f0bc759f32d9 ("mm: rearrange
vm_area_struct for fewer cache misses") changed the layout of the
vm_area_struct structure, it broke several SPARC32 assembly routines
which used numerical constants for accessing the vm_mm field.
This patch defines the VMA_VM_MM constant to replace the immediate values.
Signed-off-by: Olivier DANET <odanet@caramail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Fri, 12 Jul 2013 09:08:33 +0000 (11:08 +0200)]
perf: Fix perf_lock_task_context() vs RCU
commit
058ebd0eba3aff16b144eabf4510ed9510e1416e upstream.
Jiri managed to trigger this warning:
[] ======================================================
[] [ INFO: possible circular locking dependency detected ]
[] 3.10.0+ #228 Tainted: G W
[] -------------------------------------------------------
[] p/6613 is trying to acquire lock:
[] (rcu_node_0){..-...}, at: [<
ffffffff810ca797>] rcu_read_unlock_special+0xa7/0x250
[]
[] but task is already holding lock:
[] (&ctx->lock){-.-...}, at: [<
ffffffff810f2879>] perf_lock_task_context+0xd9/0x2c0
[]
[] which lock already depends on the new lock.
[]
[] the existing dependency chain (in reverse order) is:
[]
[] -> #4 (&ctx->lock){-.-...}:
[] -> #3 (&rq->lock){-.-.-.}:
[] -> #2 (&p->pi_lock){-.-.-.}:
[] -> #1 (&rnp->nocb_gp_wq[1]){......}:
[] -> #0 (rcu_node_0){..-...}:
Paul was quick to explain that due to preemptible RCU we cannot call
rcu_read_unlock() while holding scheduler (or nested) locks when part
of the read side critical section was preemptible.
Therefore solve it by making the entire RCU read side non-preemptible.
Also pull out the retry from under the non-preempt to play nice with RT.
Reported-by: Jiri Olsa <jolsa@redhat.com>
Helped-out-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Olsa [Tue, 9 Jul 2013 15:44:11 +0000 (17:44 +0200)]
perf: Remove WARN_ON_ONCE() check in __perf_event_enable() for valid scenario
commit
06f417968beac6e6b614e17b37d347aa6a6b1d30 upstream.
The '!ctx->is_active' check has a valid scenario, so
there's no need for the warning.
The reason is that there's a time window between the
'ctx->is_active' check in the perf_event_enable() function
and the __perf_event_enable() function having:
- IRQs on
- ctx->lock unlocked
where the task could be killed and 'ctx' deactivated by
perf_event_exit_task(), ending up with the warning below.
So remove the WARN_ON_ONCE() check and add comments to
explain it all.
This addresses the following warning reported by Vince Weaver:
[ 324.983534] ------------[ cut here ]------------
[ 324.984420] WARNING: at kernel/events/core.c:1953 __perf_event_enable+0x187/0x190()
[ 324.984420] Modules linked in:
[ 324.984420] CPU: 19 PID: 2715 Comm: nmi_bug_snb Not tainted 3.10.0+ #246
[ 324.984420] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010
[ 324.984420]
0000000000000009 ffff88043fce3ec8 ffffffff8160ea0b ffff88043fce3f00
[ 324.984420]
ffffffff81080ff0 ffff8802314fdc00 ffff880231a8f800 ffff88043fcf7860
[ 324.984420]
0000000000000286 ffff880231a8f800 ffff88043fce3f10 ffffffff8108103a
[ 324.984420] Call Trace:
[ 324.984420] <IRQ> [<
ffffffff8160ea0b>] dump_stack+0x19/0x1b
[ 324.984420] [<
ffffffff81080ff0>] warn_slowpath_common+0x70/0xa0
[ 324.984420] [<
ffffffff8108103a>] warn_slowpath_null+0x1a/0x20
[ 324.984420] [<
ffffffff81134437>] __perf_event_enable+0x187/0x190
[ 324.984420] [<
ffffffff81130030>] remote_function+0x40/0x50
[ 324.984420] [<
ffffffff810e51de>] generic_smp_call_function_single_interrupt+0xbe/0x130
[ 324.984420] [<
ffffffff81066a47>] smp_call_function_single_interrupt+0x27/0x40
[ 324.984420] [<
ffffffff8161fd2f>] call_function_single_interrupt+0x6f/0x80
[ 324.984420] <EOI> [<
ffffffff816161a1>] ? _raw_spin_unlock_irqrestore+0x41/0x70
[ 324.984420] [<
ffffffff8113799d>] perf_event_exit_task+0x14d/0x210
[ 324.984420] [<
ffffffff810acd04>] ? switch_task_namespaces+0x24/0x60
[ 324.984420] [<
ffffffff81086946>] do_exit+0x2b6/0xa40
[ 324.984420] [<
ffffffff8161615c>] ? _raw_spin_unlock_irq+0x2c/0x30
[ 324.984420] [<
ffffffff81087279>] do_group_exit+0x49/0xc0
[ 324.984420] [<
ffffffff81096854>] get_signal_to_deliver+0x254/0x620
[ 324.984420] [<
ffffffff81043057>] do_signal+0x57/0x5a0
[ 324.984420] [<
ffffffff8161a164>] ? __do_page_fault+0x2a4/0x4e0
[ 324.984420] [<
ffffffff8161665c>] ? retint_restore_args+0xe/0xe
[ 324.984420] [<
ffffffff816166cd>] ? retint_signal+0x11/0x84
[ 324.984420] [<
ffffffff81043605>] do_notify_resume+0x65/0x80
[ 324.984420] [<
ffffffff81616702>] retint_signal+0x46/0x84
[ 324.984420] ---[ end trace
442ec2f04db3771a ]---
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Suggested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1373384651-6109-2-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Olsa [Tue, 9 Jul 2013 15:44:10 +0000 (17:44 +0200)]
perf: Clone child context from parent context pmu
commit
734df5ab549ca44f40de0f07af1c8803856dfb18 upstream.
Currently when the child context for inherited events is
created, it's based on the pmu object of the first event
of the parent context.
This is wrong for the following scenario:
- HW context having HW and SW event
- HW event got removed (closed)
- SW event stays in HW context as the only event
and its pmu is used to clone the child context
The issue starts when the cpu context object is touched
based on the pmu context object (__get_cpu_context). In
this case the HW context will work with SW cpu context
ending up with following WARN below.
Fixing this by using parent context pmu object to clone
from child context.
Addresses the following warning reported by Vince Weaver:
[ 2716.472065] ------------[ cut here ]------------
[ 2716.476035] WARNING: at kernel/events/core.c:2122 task_ctx_sched_out+0x3c/0x)
[ 2716.476035] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs locn
[ 2716.476035] CPU: 0 PID: 3164 Comm: perf_fuzzer Not tainted 3.10.0-rc4 #2
[ 2716.476035] Hardware name: AOpen DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BI2
[ 2716.476035]
0000000000000000 ffffffff8102e215 0000000000000000 ffff88011fc18
[ 2716.476035]
ffff8801175557f0 0000000000000000 ffff880119fda88c ffffffff810ad
[ 2716.476035]
ffff880119fda880 ffffffff810af02a 0000000000000009 ffff880117550
[ 2716.476035] Call Trace:
[ 2716.476035] [<
ffffffff8102e215>] ? warn_slowpath_common+0x5b/0x70
[ 2716.476035] [<
ffffffff810ab2bd>] ? task_ctx_sched_out+0x3c/0x5f
[ 2716.476035] [<
ffffffff810af02a>] ? perf_event_exit_task+0xbf/0x194
[ 2716.476035] [<
ffffffff81032a37>] ? do_exit+0x3e7/0x90c
[ 2716.476035] [<
ffffffff810cd5ab>] ? __do_fault+0x359/0x394
[ 2716.476035] [<
ffffffff81032fe6>] ? do_group_exit+0x66/0x98
[ 2716.476035] [<
ffffffff8103dbcd>] ? get_signal_to_deliver+0x479/0x4ad
[ 2716.476035] [<
ffffffff810ac05c>] ? __perf_event_task_sched_out+0x230/0x2d1
[ 2716.476035] [<
ffffffff8100205d>] ? do_signal+0x3c/0x432
[ 2716.476035] [<
ffffffff810abbf9>] ? ctx_sched_in+0x43/0x141
[ 2716.476035] [<
ffffffff810ac2ca>] ? perf_event_context_sched_in+0x7a/0x90
[ 2716.476035] [<
ffffffff810ac311>] ? __perf_event_task_sched_in+0x31/0x118
[ 2716.476035] [<
ffffffff81050dd9>] ? mmdrop+0xd/0x1c
[ 2716.476035] [<
ffffffff81051a39>] ? finish_task_switch+0x7d/0xa6
[ 2716.476035] [<
ffffffff81002473>] ? do_notify_resume+0x20/0x5d
[ 2716.476035] [<
ffffffff813654f5>] ? retint_signal+0x3d/0x78
[ 2716.476035] ---[ end trace
827178d8a5966c3d ]---
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1373384651-6109-1-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Williamson [Fri, 21 Jun 2013 20:33:19 +0000 (14:33 -0600)]
iommu/amd: Only unmap large pages from the first pte
commit
60d0ca3cfd199b6612bbbbf4999a3470dad38bb1 upstream.
If we use a large mapping, the expectation is that only unmaps from
the first pte in the superpage are supported. Unmaps from offsets
into the superpage should fail (ie. return zero sized unmap). In the
current code, unmapping from an offset clears the size of the full
mapping starting from an offset. For instance, if we map a 16k
physically contiguous range at IOVA 0x0 with a large page, then
attempt to unmap 4k at offset 12k, 4 ptes are cleared (12k - 28k) and
the unmap returns 16k unmapped. This potentially incorrectly clears
valid mappings and confuses drivers like VFIO that use the unmap size
to release pinned pages.
Fix by refusing to unmap from offsets into the page.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (Red Hat) [Fri, 31 May 2013 01:10:37 +0000 (21:10 -0400)]
tracing: Use current_uid() for critical time tracing
commit
f17a5194859a82afe4164e938b92035b86c55794 upstream.
The irqsoff tracer records the max time that interrupts are disabled.
There are hooks in the assembly code that calls back into the tracer when
interrupts are disabled or enabled.
When they are enabled, the tracer checks if the amount of time they
were disabled is larger than the previous recorded max interrupts off
time. If it is, it creates a snapshot of the currently running trace
to store where the last largest interrupts off time was held and how
it happened.
During testing, this RCU lockdep dump appeared:
[ 1257.829021] ===============================
[ 1257.829021] [ INFO: suspicious RCU usage. ]
[ 1257.829021] 3.10.0-rc1-test+ #171 Tainted: G W
[ 1257.829021] -------------------------------
[ 1257.829021] /home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:780 rcu_read_lock() used illegally while idle!
[ 1257.829021]
[ 1257.829021] other info that might help us debug this:
[ 1257.829021]
[ 1257.829021]
[ 1257.829021] RCU used illegally from idle CPU!
[ 1257.829021] rcu_scheduler_active = 1, debug_locks = 0
[ 1257.829021] RCU used illegally from extended quiescent state!
[ 1257.829021] 2 locks held by trace-cmd/4831:
[ 1257.829021] #0: (max_trace_lock){......}, at: [<
ffffffff810e2b77>] stop_critical_timing+0x1a3/0x209
[ 1257.829021] #1: (rcu_read_lock){.+.+..}, at: [<
ffffffff810dae5a>] __update_max_tr+0x88/0x1ee
[ 1257.829021]
[ 1257.829021] stack backtrace:
[ 1257.829021] CPU: 3 PID: 4831 Comm: trace-cmd Tainted: G W 3.10.0-rc1-test+ #171
[ 1257.829021] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
[ 1257.829021]
0000000000000001 ffff880065f49da8 ffffffff8153dd2b ffff880065f49dd8
[ 1257.829021]
ffffffff81092a00 ffff88006bd78680 ffff88007add7500 0000000000000003
[ 1257.829021]
ffff88006bd78680 ffff880065f49e18 ffffffff810daebf ffffffff810dae5a
[ 1257.829021] Call Trace:
[ 1257.829021] [<
ffffffff8153dd2b>] dump_stack+0x19/0x1b
[ 1257.829021] [<
ffffffff81092a00>] lockdep_rcu_suspicious+0x109/0x112
[ 1257.829021] [<
ffffffff810daebf>] __update_max_tr+0xed/0x1ee
[ 1257.829021] [<
ffffffff810dae5a>] ? __update_max_tr+0x88/0x1ee
[ 1257.829021] [<
ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021] [<
ffffffff810dbf85>] update_max_tr_single+0x11d/0x12d
[ 1257.829021] [<
ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021] [<
ffffffff810e2b15>] stop_critical_timing+0x141/0x209
[ 1257.829021] [<
ffffffff8109569a>] ? trace_hardirqs_on+0xd/0xf
[ 1257.829021] [<
ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021] [<
ffffffff810e3057>] time_hardirqs_on+0x2a/0x2f
[ 1257.829021] [<
ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021] [<
ffffffff8109550c>] trace_hardirqs_on_caller+0x16/0x197
[ 1257.829021] [<
ffffffff8109569a>] trace_hardirqs_on+0xd/0xf
[ 1257.829021] [<
ffffffff811002b9>] user_enter+0xfd/0x107
[ 1257.829021] [<
ffffffff810029b4>] do_notify_resume+0x92/0x97
[ 1257.829021] [<
ffffffff8154bdca>] int_signal+0x12/0x17
What happened was entering into the user code, the interrupts were enabled
and a max interrupts off was recorded. The trace buffer was saved along with
various information about the task: comm, pid, uid, priority, etc.
The uid is recorded with task_uid(tsk). But this is a macro that uses rcu_read_lock()
to retrieve the data, and this happened to happen where RCU is blind (user_enter).
As only the preempt and irqs off tracers can have this happen, and they both
only have the tsk == current, if tsk == current, use current_uid() instead of
task_uid(), as current_uid() does not use RCU as only current can change its uid.
This fixes the RCU suspicious splat.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sreekanth Reddy [Fri, 1 Feb 2013 19:28:20 +0000 (00:58 +0530)]
SCSI: mpt2sas: fix firmware failure with wrong task attribute
commit
48ba2efc382f94fae16ca8ca011e5961a81ad1ea upstream.
When SCSI command is received with task attribute not set, set it to SIMPLE.
Previously it is set to untagged. This causes the firmware to fail the commands.
Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Hansel [Fri, 26 Apr 2013 15:32:14 +0000 (17:32 +0200)]
SCSI: zfcp: fix adapter (re)open recovery while link to SAN is down
commit
f76ccaac4f82c463a037aa4a1e4ccb85c7011814 upstream.
FCP device remains in status ERP_FAILED when device is switched online
or adapter recovery is triggered while link to SAN is down.
When Exchange Configuration Data command returns the FSF status
FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE it aborts the exchange process.
The only retries are done during the common error recovery procedure
(i.e. max. 3 retries with 8sec sleep between) and remains in status
ERP_FAILED with QDIO down.
This commit reverts the commit
0df138476c8306478d6e726f044868b4bccf411c
(zfcp: Fix adapter activation on link down).
When FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE is received the
adapter recovery will be finished without any retries. QDIO will be
up now and status changes such as LINK UP will be received now.
Signed-off-by: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sujith Manoharan [Mon, 10 Jun 2013 08:19:40 +0000 (13:49 +0530)]
ath9k: Do not assign noise for NULL caldata
commit
d3bcb7b24bbf09fde8405770e676fe0c11c79662 upstream.
ah->noise is maintained globally and not per-channel. This
is updated in the reset() routine after the NF history has been
filled for the *current channel*, just before switching to
the new channel. There is no need to do it inside getnf(), since
ah->noise must contain a value for the new channel.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gabor Juhos [Sat, 22 Jun 2013 11:13:25 +0000 (13:13 +0200)]
rt2x00: read 5GHz TX power values from the correct offset
commit
0a6f3a8ebaf13407523c2c7d575b4ca2debd23ba upstream.
The current code uses the same index value both
for the channel information array and for the TX
power table. The index starts from 14, however the
index of the TX power table must start from zero.
Fix it, in order to get the correct TX power value
for a given channel.
The changes in rt61pci.c and rt73usb.c are compile
tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Mon, 1 Jul 2013 20:14:10 +0000 (22:14 +0200)]
tick: Prevent uncontrolled switch to oneshot mode
commit
1f73a9806bdd07a5106409bbcab3884078bd34fe upstream.
When the system switches from periodic to oneshot mode, the broadcast
logic causes a possibility that a CPU which has not yet switched to
oneshot mode puts its own clock event device into oneshot mode without
updating the state and the timer handler.
CPU0 CPU1
per cpu tickdev is in periodic mode
and switched to broadcast
Switch to oneshot mode
tick_broadcast_switch_to_oneshot()
cpumask_copy(tick_oneshot_broacast_mask,
tick_broadcast_mask);
broadcast device mode = oneshot
Timer interrupt
irq_enter()
tick_check_oneshot_broadcast()
dev->set_mode(ONESHOT);
tick_handle_periodic()
if (dev->mode == ONESHOT)
dev->next_event += period;
FAIL.
We fail, because dev->next_event contains KTIME_MAX, if the device was
in periodic mode before the uncontrolled switch to oneshot happened.
We must copy the broadcast bits over to the oneshot mask, because
otherwise a CPU which relies on the broadcast would not been woken up
anymore after the broadcast device switched to oneshot mode.
So we need to verify in tick_check_oneshot_broadcast() whether the CPU
has already switched to oneshot mode. If not, leave the device
untouched and let the CPU switch controlled into oneshot mode.
This is a long standing bug, which was never noticed, because the main
user of the broadcast x86 cannot run into that scenario, AFAICT. The
nonarchitected timer mess of ARM creates a gazillion of differently
broken abominations which trigger the shortcomings of that broadcast
code, which better had never been necessary in the first place.
Reported-and-tested-by: Stehle Vincent-B46079 <B46079@freescale.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>,
Cc: Mark Rutland <mark.rutland@arm.com>
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabio Estevam [Thu, 4 Jul 2013 23:01:03 +0000 (20:01 -0300)]
ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK
commit
5c78dfe87ea04b501ee000a7f03b9432ac9d008c upstream.
SGTL5000_PLL_FRAC_DIV_MASK is used to mask bits 0-10 (11 bits in total) of
register CHIP_PLL_CTRL, so fix the mask to accomodate all this bit range.
Reported-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seth Heasley [Wed, 19 Jun 2013 23:25:37 +0000 (16:25 -0700)]
ata_piix: IDE-mode SATA patch for Intel Coleto Creek DeviceIDs
commit
c7e8695bfa0611b39493a9dfe8bab9f63f9809bd upstream.
This patch adds the IDE-mode SATA DeviceIDs for the Intel Coleto Creek PCH.
Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Tue, 11 Jun 2013 07:11:36 +0000 (00:11 -0700)]
libata: skip SRST for all SIMG [34]7x port-multipliers
commit
7a87718d92760fc688628ad6a430643dafa16f1f upstream.
For some reason, a lot of port-multipliers have issues with softreset.
SIMG [34]7x series port-multipliers have been quite erratic in this
regard. I recall that it was better with some firmware revisions and
the current list of quirks worked fine for a while. I think it got
worse with later firmwares or maybe my test coverage wasn't good
enough. Anyways, HPA is reporting that his 3726 setup suffers SRST
failures and then the PMP gets confused and fails to probe the last
port.
The hope was that we try to stick to the standard as much as possible
and soonish the PMPs and their firmwares will improve in quality, so
the quirk list was kept to minimum. Well, it seems like that's never
gonna happen.
Let's set NO_SRST for all [34]7x PMPs so that whatever remaining
userbase of the device suffer the least. Maybe we should do the same
for 57xx's but unfortunately I don't have any device left to test and
I'm not even sure 57xx's have ever been made widely available, so
let's leave those alone for now.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 20 Mar 2013 13:39:05 +0000 (14:39 +0100)]
ext3: fix data=journal fast mount/umount hang
commit
e643692138cfa33528f054b071ba2583509bb217 upstream.
In data=journal mode, if we unmount the file system before a
transaction has a chance to complete, when the journal inode is being
evicted, we can end up calling into log_wait_commit() for the
last transaction, after the journalling machinery has been shut down.
That triggers the WARN_ONCE in __log_start_commit().
Arguably we should adjust ext3_should_journal_data() to return FALSE
for the journal inode, but the only place it matters is
ext3_evict_inode(), and so it's to save a bit of CPU time, and to make
the patch much more obviously correct by inspection(tm), we'll fix it
by explicitly not trying to waiting for a journal commit when we are
evicting the journal inode, since it's guaranteed to never succeed in
this case.
This can be easily replicated via:
mount -t ext3 -o data=journal /dev/vdb /vdb ; umount /vdb
This is a port of ext4 fix from Ted Ts'o.
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 22 Jul 2013 01:19:12 +0000 (18:19 -0700)]
Linux 3.4.54
Steve French [Tue, 25 Jun 2013 19:03:16 +0000 (14:03 -0500)]
Handle big endianness in NTLM (ntlmv2) authentication
commit
fdf96a907c1fbb93c633e2b7ede3b8df26d6a4c0 upstream.
This is RH bug 970891
Uppercasing of username during calculation of ntlmv2 hash fails
because UniStrupr function does not handle big endian wchars.
Also fix a comment in the same code to reflect its correct usage.
[To make it easier for stable (rather than require 2nd patch) fixed
this patch of Shirish's to remove endian warning generated
by sparse -- steve f.]
Reported-by: steve <sanpatr1@in.ibm.com>
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bartlomiej Zolnierkiewicz [Wed, 3 Jul 2013 22:00:43 +0000 (15:00 -0700)]
drivers/dma/pl330.c: fix locking in pl330_free_chan_resources()
commit
da331ba8e9c5de72a27e50f71105395bba6eebe0 upstream.
tasklet_kill() may sleep so call it before taking pch->lock.
Fixes following lockup:
BUG: scheduling while atomic: cat/2383/0x00000002
Modules linked in:
unwind_backtrace+0x0/0xfc
__schedule_bug+0x4c/0x58
__schedule+0x690/0x6e0
sys_sched_yield+0x70/0x78
tasklet_kill+0x34/0x8c
pl330_free_chan_resources+0x24/0x88
dma_chan_put+0x4c/0x50
[...]
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
lock: 0xe52aa04c, .magic:
dead4ead, .owner: cat/2383, .owner_cpu: 1
unwind_backtrace+0x0/0xfc
do_raw_spin_lock+0x194/0x204
_raw_spin_lock_irqsave+0x20/0x28
pl330_tasklet+0x2c/0x5a8
tasklet_action+0xfc/0x114
__do_softirq+0xe4/0x19c
irq_exit+0x98/0x9c
handle_IPI+0x124/0x16c
gic_handle_irq+0x64/0x68
__irq_svc+0x40/0x70
cpuidle_wrap_enter+0x4c/0xa0
cpuidle_enter_state+0x18/0x68
cpuidle_idle_call+0xac/0xe0
cpu_idle+0xac/0xf0
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jed Davis [Thu, 20 Jun 2013 09:16:29 +0000 (10:16 +0100)]
ARM: 7765/1: perf: Record the user-mode PC in the call chain.
commit
c5f927a6f62196226915f12194c9d0df4e2210d7 upstream.
With this change, we no longer lose the innermost entry in the user-mode
part of the call chain. See also the x86 port, which includes the ip.
It's possible to partially work around this problem by post-processing
the data to use the PERF_SAMPLE_IP value, but this works only if the CPU
wasn't in the kernel when the sample was taken.
Signed-off-by: Jed Davis <jld@mozilla.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Sat, 13 Jul 2013 04:40:35 +0000 (00:40 -0400)]
ext4: don't allow ext4_free_blocks() to fail due to ENOMEM
commit
e7676a704ee0a1ef71a6b23760b5a8f6896cb1a1 upstream.
The filesystem should not be marked inconsistent if ext4_free_blocks()
is not able to allocate memory. Unfortunately some callers (most
notably ext4_truncate) don't have a way to reflect an error back up to
the VFS. And even if we did, most userspace applications won't deal
with most system calls returning ENOMEM anyway.
Reported-by: Nagachandra P <nagachandra@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Fri, 31 May 2013 23:39:56 +0000 (19:39 -0400)]
ext4: fix overflow when counting used blocks on 32-bit architectures
commit
8af8eecc1331dbf5e8c662022272cf667e213da5 upstream.
The arithmetics adding delalloc blocks to the number of used blocks in
ext4_getattr() can easily overflow on 32-bit archs as we first multiply
number of blocks by blocksize and then divide back by 512. Make the
arithmetics more clever and also use proper type (unsigned long long
instead of unsigned long).
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Fri, 31 May 2013 23:38:56 +0000 (19:38 -0400)]
ext4: fix data offset overflow in ext4_xattr_fiemap() on 32-bit archs
commit
a60697f411eb365fb09e639e6f183fe33d1eb796 upstream.
On 32-bit architectures with 32-bit sector_t computation of data offset
in ext4_xattr_fiemap() can overflow resulting in reporting bogus data
location. Fix the problem by typing block number to proper type before
shifting.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Tue, 21 May 2013 18:43:50 +0000 (20:43 +0200)]
timer: Fix jiffies wrap behavior of round_jiffies_common()
commit
9e04d3804d3ac97d8c03a41d78d0f0674b5d01e1 upstream.
Direct compare of jiffies related values does not work in the wrap
around case. Replace it with time_is_after_jiffies().
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Link: http://lkml.kernel.org/r/519BC066.5080600@acm.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shane Huang [Sat, 8 Jun 2013 08:00:16 +0000 (16:00 +0800)]
ahci: remove pmp link online check in FBS EH
commit
912b9ac683b112615d5605686f1dc086402ce9f7 upstream.
ata_link_online() check in ahci_error_intr() is unnecessary, it should
be removed otherwise may lead to lockup with FBS enabled PMP.
http://marc.info/?l=linux-ide&m=
137050421603272&w=2
Reported-by: Yu Liu <liuyu.ac@gmail.com>
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shane Huang [Mon, 3 Jun 2013 10:24:10 +0000 (18:24 +0800)]
ahci: Add AMD CZ SATA device ID
commit
fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream.
To add AMD CZ SATA controller device ID of IDE mode.
[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Junxiao Bi [Wed, 3 Jul 2013 22:01:03 +0000 (15:01 -0700)]
ocfs2: xattr: fix inlined xattr reflink
commit
ef962df057aaafd714f5c22ba3de1be459571fdf upstream.
Inlined xattr shared free space of inode block with inlined data or data
extent record, so the size of the later two should be adjusted when
inlined xattr is enabled. See ocfs2_xattr_ibody_init(). But this isn't
done well when reflink. For inode with inlined data, its max inlined
data size is adjusted in ocfs2_duplicate_inline_data(), no problem. But
for inode with data extent record, its record count isn't adjusted. Fix
it, or data extent record and inlined xattr may overwrite each other,
then cause data corruption or xattr failure.
One panic caused by this bug in our test environment is the following:
kernel BUG at fs/ocfs2/xattr.c:1435!
invalid opcode: 0000 [#1] SMP
Pid: 10871, comm: multi_reflink_t Not tainted 2.6.39-300.17.1.el5uek #1
RIP: ocfs2_xa_offset_pointer+0x17/0x20 [ocfs2]
RSP: e02b:
ffff88007a587948 EFLAGS:
00010283
RAX:
0000000000000000 RBX:
0000000000000010 RCX:
00000000000051e4
RDX:
ffff880057092060 RSI:
0000000000000f80 RDI:
ffff88007a587a68
RBP:
ffff88007a587948 R08:
00000000000062f4 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000000010
R13:
ffff88007a587a68 R14:
0000000000000001 R15:
ffff88007a587c68
FS:
00007fccff7f06e0(0000) GS:
ffff88007fc00000(0000) knlGS:
0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
00000000015cf000 CR3:
000000007aa76000 CR4:
0000000000000660
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process multi_reflink_t
Call Trace:
ocfs2_xa_reuse_entry+0x60/0x280 [ocfs2]
ocfs2_xa_prepare_entry+0x17e/0x2a0 [ocfs2]
ocfs2_xa_set+0xcc/0x250 [ocfs2]
ocfs2_xattr_ibody_set+0x98/0x230 [ocfs2]
__ocfs2_xattr_set_handle+0x4f/0x700 [ocfs2]
ocfs2_xattr_set+0x6c6/0x890 [ocfs2]
ocfs2_xattr_user_set+0x46/0x50 [ocfs2]
generic_setxattr+0x70/0x90
__vfs_setxattr_noperm+0x80/0x1a0
vfs_setxattr+0xa9/0xb0
setxattr+0xc3/0x120
sys_fsetxattr+0xa8/0xd0
system_call_fastpath+0x16/0x1b
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Acked-by: Joel Becker <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Sunil Mushran <sunil.mushran@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lan Tianyu [Wed, 5 Jun 2013 02:27:51 +0000 (02:27 +0000)]
ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
commit
eff9a4b62b14cf0d9913e3caf1f26f8b7a6105c9 upstream.
HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's
_REG method will access that region. To allow the CMOS RTC region
handler to be installed before the EC _REG method is first invoked,
add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table.
References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Wed, 3 Jul 2013 22:06:45 +0000 (15:06 -0700)]
drivers/rtc/rtc-rv3029c2.c: fix disabling AIE irq
commit
29ecd78c0fd6ee05f2c6b07b23823a6ae43c13ff upstream.
In the disable AIE irq code path, current code passes "1" to enable
parameter of rv3029c2_rtc_i2c_alarm_set_irq(). Thus it does not disable
AIE irq.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Fri, 28 Jun 2013 01:40:30 +0000 (02:40 +0100)]
genirq: Fix can_request_irq() for IRQs without an action
commit
2779db8d37d4b542d9ca2575f5f178dbeaca6c86 upstream.
Commit
02725e7471b8 ('genirq: Use irq_get/put functions'),
inadvertently changed can_request_irq() to return 0 for IRQs that have
no action. This causes pcibios_lookup_irq() to select only IRQs that
already have an action with IRQF_SHARED set, or to fail if there are
none. Change can_request_irq() to return 1 for IRQs that have no
action (if the first two conditions are met).
Reported-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Tested-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is> (against 3.2)
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: 709647@bugs.debian.org
Link: http://bugs.debian.org/709647
Link: http://lkml.kernel.org/r/1372383630.23847.40.camel@deadeye.wl.decadent.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laszlo Ersek [Tue, 18 Oct 2011 20:42:59 +0000 (22:42 +0200)]
xen/time: remove blocked time accounting from xen "clockchip"
commit
0b0c002c340e78173789f8afaa508070d838cf3d upstream.
... because the "clock_event_device framework" already accounts for idle
time through the "event_handler" function pointer in
xen_timer_interrupt().
The patch is intended as the completion of [1]. It should fix the double
idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to
stolen time accounting (the removed code seems to be isolated).
The approach may be completely misguided.
[1] https://lkml.org/lkml/2011/10/6/10
[2] http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01068.html
John took the time to retest this patch on top of v3.10 and reported:
"idle time is correctly incremented for pv and hvm for the normal
case, nohz=off and nohz=idle." so lets put this patch in.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: John Haxby <john.haxby@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>