9 years agoFix sprz319 erratum 2.1
Richard Watts [Mon, 20 Feb 2012 17:58:26 +0000 (17:58 +0000)]
Fix sprz319 erratum 2.1

There is an erratum in DM3730 which results in the
EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
leads to USB PHY clock drift and once the clock has drifted far
enough, the PHY's ULPI interface stops responding and USB
drops out. This is manifested on a Beagle xM by having the attached
SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
or similar.

The fix is to carefully adjust your DPLL5 settings so as to
keep the PHY clock as close as possible to 120MHz over the long
term; TI SPRZ319e gives a table of such settings and this patch
applies that table to systems with a 13MHz or a 26MHz clock,
thus fixing the issue (inasfar as it can be fixed) on Beagle xM
and Overo Firestorm.

Signed-off-by: Richard Watts <>
9 years agoARM: 7670/1: fix the memset fix
Nicolas Pitre [Tue, 12 Mar 2013 12:00:42 +0000 (13:00 +0100)]
ARM: 7670/1: fix the memset fix

Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value.  However the memset itself became broken
by that patch for misaligned pointers.

This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.

Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.

While at it, the entry instructions are slightly reworked to help dual
issue pipelines.

Signed-off-by: Nicolas Pitre <>
Tested-by: Alexander Holler <>
Signed-off-by: Russell King <>
9 years agoARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
Ivan Djelic [Wed, 6 Mar 2013 19:09:27 +0000 (20:09 +0100)]
ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.

For instance in the following function:

void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;

compiled as:

800554d0 <debug_mutex_lock_common>:
800554d0:       e92d4008        push    {r3, lr}
800554d4:       e1a00001        mov     r0, r1
800554d8:       e3a02010        mov     r2, #16 ; 0x10
800554dc:       e3a01011        mov     r1, #17 ; 0x11
800554e0:       eb04426e        bl      80165ea0 <memset>
800554e4:       e1a03000        mov     r3, r0
800554e8:       e583000c        str     r0, [r3, #12]
800554ec:       e5830000        str     r0, [r3]
800554f0:       e5830004        str     r0, [r3, #4]
800554f4:       e8bd8008        pop     {r3, pc}

GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.

This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:

Step 1
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).

Step 2
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:

save r8:
-       str     lr, [sp, #-4]!
+       stmfd   sp!, {r8, lr}

and restore r8 on both exit paths:
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
        tst     r2, #16
        stmneia ip!, {r1, r3, r8, lr}
-       ldr     lr, [sp], #4
+       ldmfd   sp!, {r8, lr}

Step 3
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:

save r8:
-       stmfd   sp!, {r4-r7, lr}
+       stmfd   sp!, {r4-r8, lr}

and restore r8 on both exit paths:
        bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+       ldmeqfd sp!, {r4-r8, pc}
        tst     r2, #16
        stmneia ip!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+       ldmfd   sp!, {r4-r8, lr}

Step 4
Rewrite register list "r4-r7, r8" as "r4-r8".

Signed-off-by: Ivan Djelic <>
Reviewed-by: Nicolas Pitre <>
Signed-off-by: Dirk Behme <>
Signed-off-by: Russell King <>
9 years agoARM: lib: delay: align loop
Grazvydas Ignotas [Thu, 12 Dec 2013 21:08:47 +0000 (23:08 +0200)]
ARM: lib: delay: align loop

Helps with BogoMIPS calculation, see mainline commit 11d4bb1bd067f for
more details.

9 years agoARM: OMAP2+: hwmod: Fix SOFTRESET logic
Roger Quadros [Mon, 9 Dec 2013 01:39:02 +0000 (18:39 -0700)]
ARM: OMAP2+: hwmod: Fix SOFTRESET logic

In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.

This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.

To fix this we clear the SOFTRESET bit and update the sysconfig
register + sysc_cache using write_sysconfig().

Signed-off-by: Roger Quadros <>
Tested-by: Tomi Valkeinen <> # Panda, BeagleXM
[ renamed _clr_softreset() to _clear_softreset()]
Signed-off-by: Paul Walmsley <>
9 years agousb: musb: omap2430: fix occasional musb breakage on boot
Grazvydas Ignotas [Tue, 10 Dec 2013 00:02:38 +0000 (02:02 +0200)]
usb: musb: omap2430: fix occasional musb breakage on boot

This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c "omap2+: save and restore OTG_INTERFSEL",
which introduces save/restore of OTG_INTERFSEL over suspend.

Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.

Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value).

This issue was originally found by Andreas Naumann:

9 years agoMerge branch 'stable-3.2' into pandora-3.2
Grazvydas Ignotas [Mon, 9 Dec 2013 23:54:11 +0000 (01:54 +0200)]
Merge branch 'stable-3.2' into pandora-3.2

9 years agoLinux 3.2.53 v3.2.53
Ben Hutchings [Thu, 28 Nov 2013 14:02:07 +0000 (14:02 +0000)]
Linux 3.2.53

9 years agolib/scatterlist.c: don't flush_kernel_dcache_page on slab page
Ming Lei [Thu, 31 Oct 2013 23:34:17 +0000 (16:34 -0700)]
lib/scatterlist.c: don't flush_kernel_dcache_page on slab page

commit 3d77b50c5874b7e923be946ba793644f82336b75 upstream.

Commit b1adaf65ba03 ("[SCSI] block: add sg buffer copy helper
functions") introduces two sg buffer copy helpers, and calls
flush_kernel_dcache_page() on pages in SG list after these pages are
written to.

Unfortunately, the commit may introduce a potential bug:

 - Before sending some SCSI commands, kmalloc() buffer may be passed to
   block layper, so flush_kernel_dcache_page() can see a slab page

 - According to cachetlb.txt, flush_kernel_dcache_page() is only called
   on "a user page", which surely can't be a slab page.

 - ARCH's implementation of flush_kernel_dcache_page() may use page
   mapping information to do optimization so page_mapping() will see the
   slab page, then VM_BUG_ON() is triggered.

Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
before calling flush_kernel_dcache_page().

Signed-off-by: Ming Lei <>
Reported-by: Aaro Koskinen <>
Tested-by: Simon Baatz <>
Cc: Russell King - ARM Linux <>
Cc: Will Deacon <>
Cc: Aaro Koskinen <>
Acked-by: Catalin Marinas <>
Cc: FUJITA Tomonori <>
Cc: Tejun Heo <>
Cc: "James E.J. Bottomley" <>
Cc: Jens Axboe <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agoStaging: bcm: info leak in ioctl
Dan Carpenter [Tue, 29 Oct 2013 20:01:11 +0000 (23:01 +0300)]
Staging: bcm: info leak in ioctl

commit 8d1e72250c847fa96498ec029891de4dc638a5ba upstream.

The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
information to user space.

Reported-by: Nico Golde <>
Reported-by: Fabian Yamaguchi <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agostaging: wlags49_h2: buffer overflow setting station name
Dan Carpenter [Tue, 29 Oct 2013 20:00:15 +0000 (23:00 +0300)]
staging: wlags49_h2: buffer overflow setting station name

commit b5e2f339865fb443107e5b10603e53bbc92dc054 upstream.

We need to check the length parameter before doing the memcpy().  I've
actually changed it to strlcpy() as well so that it's NUL terminated.

You need CAP_NET_ADMIN to trigger these so it's not the end of the

Reported-by: Nico Golde <>
Reported-by: Fabian Yamaguchi <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoaacraid: missing capable() check in compat ioctl
Dan Carpenter [Tue, 29 Oct 2013 19:11:06 +0000 (22:11 +0300)]
aacraid: missing capable() check in compat ioctl

commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.

In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
check as well.

Signed-off-by: Dan Carpenter <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agouml: check length in exitcode_proc_write()
Dan Carpenter [Tue, 29 Oct 2013 19:06:04 +0000 (22:06 +0300)]
uml: check length in exitcode_proc_write()

commit 201f99f170df14ba52ea4c52847779042b7a623b upstream.

We don't cap the size of buffer from the user so we could write past the
end of the array here.  Only root can write to this file.

Reported-by: Nico Golde <>
Reported-by: Fabian Yamaguchi <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agoASoC: wm_hubs: Add missing break in hp_supply_event()
Takashi Iwai [Wed, 30 Oct 2013 07:35:02 +0000 (08:35 +0100)]
ASoC: wm_hubs: Add missing break in hp_supply_event()

commit 268ff14525edba31da29a12a9dd693cdd6a7872e upstream.

Spotted by coverity CID 115170.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: hda - Add a fixup for ASUS N76VZ
Takashi Iwai [Wed, 30 Oct 2013 11:29:40 +0000 (12:29 +0100)]
ALSA: hda - Add a fixup for ASUS N76VZ

commit 6fc16e58adf50c0f1e4478538983fb5ff6f453d4 upstream.

ASUS N76VZ needs the same fixup as N56VZ for supporting the boost

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoFix a few incorrectly checked [io_]remap_pfn_range() calls
Linus Torvalds [Tue, 29 Oct 2013 17:21:34 +0000 (10:21 -0700)]
Fix a few incorrectly checked [io_]remap_pfn_range() calls

commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1 upstream.

Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
really should use the vm_iomap_memory() helper.  This trivially converts
two of them to the helper, and comments about why the third one really
needs to continue to use remap_pfn_range(), and adds the missing size

Reported-by: Nico Golde <>
Signed-off-by: Linus Torvalds <
[bwh: Backported to 3.2:
 - Adjust context
 - Also remove redundant vm_flags changes, removed separately upstream]
Signed-off-by: Ben Hutchings <>
9 years agoASoC: dapm: Fix source list debugfs outputs
Takashi Iwai [Mon, 28 Oct 2013 13:21:49 +0000 (14:21 +0100)]
ASoC: dapm: Fix source list debugfs outputs

commit ff18620c2157671a8ee21ebb8e6a3520ea209b1f upstream.

... due to a copy & paste error.

Spotted by coverity CID 710923.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
9 years agoparisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM
Helge Deller [Sat, 26 Oct 2013 21:19:25 +0000 (23:19 +0200)]
parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM

commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.

Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
not able to bring up other CPUs than the monarch CPU and instead crashed the
kernel.  The reason was unclear, esp. since it involved various machines (e.g.
J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
when less than 4GB were installed, or if a 32bit Linux kernel was booted.

In the end, the fix for those SMP problems is trivial:
During the early phase of the initialization of the CPUs, including the monarch
CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
It's documented that this firmware function may clobber various registers, and
one one of those possibly clobbered registers is %cr30 which holds the task
thread info pointer.

Now, if %cr30 would always have been clobbered, then this bug would have been
detected much earlier. But lots of testing finally showed, that - at least for
%cr30 - on some machines only the upper 32bits of the 64bit register suddenly
turned zero after the firmware call.

So, after finding the root cause, the explanation for the various crashes
became clear:
- On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
- Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
  thread info pointer was below 4GB.
- Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
  the upper 32bit were zero anyay.
- Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
  info pointer was located above the 4GB boundary.

Finally, the patch to fix this problem is trivial by saving the %cr30 register
before the firmware call and restoring it afterwards.

Signed-off-by: Helge Deller <>
Signed-off-by: John David Anglin <>
Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
9 years agotarget/pscsi: fix return value check
Wei Yongjun [Fri, 25 Oct 2013 13:53:33 +0000 (21:53 +0800)]
target/pscsi: fix return value check

commit 58932e96e438cd78f75e765d7b87ef39d3533d15 upstream.

In case of error, the function scsi_host_lookup() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

Signed-off-by: Wei Yongjun <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: pscsi_configure_device() returns a pointer]
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon/atom: workaround vbios bug in transmitter table on rs780
Alex Deucher [Thu, 10 Oct 2013 20:45:27 +0000 (16:45 -0400)]
drm/radeon/atom: workaround vbios bug in transmitter table on rs780

commit c23632d4e57c0dd20bf50eca08fa0eb8ad3ff680 upstream.

Some rs780 asics seem to be affected as well.



Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agodrm: Pad drm_mode_get_connector to 64-bit boundary
Chris Wilson [Wed, 16 Oct 2013 08:49:02 +0000 (09:49 +0100)]
drm: Pad drm_mode_get_connector to 64-bit boundary

commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.

Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple of u64s.

64-bit kernel:

sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4

32-bit userspace:

sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4

Fortuituously we can insert explicit padding to the tail of our
structures without breaking ABI.

Reported-by: Pavel Roskin <>
Signed-off-by: Chris Wilson <>
Cc: Dave Airlie <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agodrm: Prevent overwriting from userspace underallocating core ioctl structs
Chris Wilson [Wed, 16 Oct 2013 10:22:44 +0000 (11:22 +0100)]
drm: Prevent overwriting from userspace underallocating core ioctl structs

commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.

Apply the protections from

commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie <>
Date:   Sat Aug 14 20:20:34 2010 +1000

    drm: block userspace under allocating buffer and having drivers overwrite it (v2)

to the core ioctl structs as well, for we found one instance where there
is a 32-/64-bit size mismatch and were guilty of writing beyond the end
of the user's buffer.

Signed-off-by: Chris Wilson <>
Cc: Dave Airlie <>
Reviewed-by: Ville Syrjälä <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agoecryptfs: Fix memory leakage in keystore.c
Geyslan G. Bem [Fri, 11 Oct 2013 19:49:16 +0000 (16:49 -0300)]
ecryptfs: Fix memory leakage in keystore.c

commit 3edc8376c06133e3386265a824869cad03a4efd4 upstream.

In 'decrypt_pki_encrypted_session_key' function:

Initializes 'payload' pointer and releases it on exit.

Signed-off-by: Geyslan G. Bem <>
Signed-off-by: Tyler Hicks <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agousb: serial: option: blacklist Olivetti Olicard200
Enrico Mioso [Tue, 15 Oct 2013 13:06:47 +0000 (15:06 +0200)]
usb: serial: option: blacklist Olivetti Olicard200

commit fd8573f5828873343903215f203f14dc82de397c upstream.

Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.

Signed-off-by: Enrico Mioso <>
Signed-off-by: Antonella Pellizzari <>
Tested-by: Dan Williams <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: quirks: add touchscreen that is dazzeled by remote wakeup
Oliver Neukum [Wed, 16 Oct 2013 10:26:07 +0000 (12:26 +0200)]
USB: quirks: add touchscreen that is dazzeled by remote wakeup

commit 614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350 upstream.

The device descriptors are messed up after remote wakeup

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agodm snapshot: fix data corruption
Mikulas Patocka [Wed, 16 Oct 2013 02:17:47 +0000 (03:17 +0100)]
dm snapshot: fix data corruption

commit e9c6a182649f4259db704ae15a91ac820e63b0ca upstream.

This patch fixes a particular type of data corruption that has been
encountered when loading a snapshot's metadata from disk.

When we allocate a new chunk in persistent_prepare, we increment
ps->next_free and we make sure that it doesn't point to a metadata area
by further incrementing it if necessary.

When we load metadata from disk on device activation, ps->next_free is
positioned after the last used data chunk. However, if this last used
data chunk is followed by a metadata area, ps->next_free is positioned
erroneously to the metadata area. A newly-allocated chunk is placed at
the same location as the metadata area, resulting in data or metadata

This patch changes the code so that ps->next_free skips the metadata
area when metadata are loaded in function read_exceptions.

The patch also moves a piece of code from persistent_prepare_exception
to a separate function skip_metadata to avoid code duplication.


Signed-off-by: Mikulas Patocka <>
Cc: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Ben Hutchings <>
9 years agoxtensa: don't use alternate signal stack on threads
Baruch Siach [Mon, 14 Oct 2013 22:22:43 +0000 (02:22 +0400)]
xtensa: don't use alternate signal stack on threads

commit cba9a90053e3b7973eff4f1946f33032e98eeed5 upstream.

According to create_thread(3): "The new thread does not inherit the creating
thread's alternate signal stack". Since commit f9a3879a (Fix sigaltstack
corruption among cloned threads), current->sas_ss_size is set to 0 for cloned
processes sharing VM with their parent. Don't use the (nonexistent) alternate
signal stack in this case. This has been broken since commit 29c4dfd9 ([XTENSA]
Remove non-rt signal handling).

Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc.

Signed-off-by: Baruch Siach <>
Signed-off-by: Max Filippov <>
Signed-off-by: Chris Zankel <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: quirks.c: add one device that cannot deal with suspension
Oliver Neukum [Mon, 14 Oct 2013 14:22:40 +0000 (16:22 +0200)]
USB: quirks.c: add one device that cannot deal with suspension

commit 4294bca7b423d1a5aa24307e3d112a04075e3763 upstream.

The device is not responsive when resumed, unless it is reset.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agowireless: radiotap: fix parsing buffer overrun
Johannes Berg [Fri, 11 Oct 2013 12:47:05 +0000 (14:47 +0200)]
wireless: radiotap: fix parsing buffer overrun

commit f5563318ff1bde15b10e736e97ffce13be08bc1a upstream.

When parsing an invalid radiotap header, the parser can overrun
the buffer that is passed in because it doesn't correctly check
 1) the minimum radiotap header size
 2) the space for extended bitmaps

The first issue doesn't affect any in-kernel user as they all
check the minimum size before calling the radiotap function.
The second issue could potentially affect the kernel if an skb
is passed in that consists only of the radiotap header with a
lot of extended bitmaps that extend past the SKB. In that case
a read-only buffer overrun by at most 4 bytes is possible.

Fix this by adding the appropriate checks to the parser.

Reported-by: Evan Huus <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
9 years agoparisc: fix interruption handler to respect pagefault_disable()
Helge Deller [Tue, 1 Oct 2013 19:54:46 +0000 (21:54 +0200)]
parisc: fix interruption handler to respect pagefault_disable()

commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.

Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel.  The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
    probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
    probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
    probe_kernel_read(name, wq->name, sizeof(name) - 1);

The problem here is, that the first probe_kernel_read(&pwq) might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.

With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0).  Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.

Signed-off-by: Helge Deller <>
Signed-off-by: John David Anglin <>
Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
9 years agovfs: allow O_PATH file descriptors for fstatfs()
Linus Torvalds [Mon, 30 Sep 2013 15:35:10 +0000 (08:35 -0700)]
vfs: allow O_PATH file descriptors for fstatfs()

commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.

Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.

There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()".  See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.

Reported-and-tested-by: ольга крыжановская <>
Acked-by: Al Viro <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: use fget_raw() not fdget_raw()]
Signed-off-by: Ben Hutchings <>
9 years agoext4: fix memory leak in xattr
Dave Jones [Fri, 11 Oct 2013 00:05:35 +0000 (20:05 -0400)]
ext4: fix memory leak in xattr

commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.

If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations.  If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.

Spotted with Coverity.

[ Fixed by tytso to set is and bs to NULL after freeing these
  pointers, in case in the retry loop we later end up triggering an
  error causing a jump to cleanup, at which point we could have a double
  free bug. -- Ted ]

Signed-off-by: Dave Jones <>
Signed-off-by: "Theodore Ts'o" <>
Reviewed-by: Eric Sandeen <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: serial: option: add support for Inovia SEW858 device
Greg Kroah-Hartman [Sun, 6 Oct 2013 01:14:18 +0000 (18:14 -0700)]
USB: serial: option: add support for Inovia SEW858 device

commit f4c19b8e165cff1a6607c21f8809441d61cab7ec upstream.

This patch adds the device id for the Inovia SEW858 device to the option driver.

Reported-by: Pavel Parkhomenko <>
Tested-by: Pavel Parkhomenko <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: support new huawei devices in option.c
Fangxiaozhi (Franko) [Fri, 11 Oct 2013 03:48:21 +0000 (03:48 +0000)]
USB: support new huawei devices in option.c

commit d544db293a44a2a3b09feab7dbd59668b692de71 upstream.

Add new supporting declarations to option.c, to support Huawei new
devices with new bInterfaceSubClass value.

Signed-off-by: fangxiaozhi <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agocompiler/gcc4: Add quirk for 'asm goto' miscompilation bug
Ingo Molnar [Thu, 10 Oct 2013 08:16:30 +0000 (10:16 +0200)]
compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

commit 3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.

Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:

Implement a workaround suggested by Jakub Jelinek.

Reported-and-tested-by: Fengguang Wu <>
Reported-by: Oleg Nesterov <>
Reported-by: Peter Zijlstra <>
Suggested-by: Jakub Jelinek <>
Reviewed-by: Richard Henderson <>
Cc: Linus Torvalds <>
Cc: Andrew Morton <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - Drop inapplicable changes
 - Adjust context]
Signed-off-by: Ben Hutchings <>
9 years agocompiler-gcc.h: Add gcc-recommended GCC_VERSION macro
Daniel Santos [Fri, 22 Feb 2013 00:41:39 +0000 (16:41 -0800)]
compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

commit 3f3f8d2f48acfd8ed3b8e6b7377935da57b27b16 upstream.

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

  #if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
      __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

  #if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:

Signed-off-by: Daniel Santos <>
Acked-by: Borislav Petkov <>
Acked-by: David Rientjes <>
Cc: Andi Kleen <>
Cc: Joe Perches <>
Cc: Josh Triplett <>
Cc: Paul Gortmaker <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: allow architectures to optionally define random_get_entropy()
Theodore Ts'o [Sat, 21 Sep 2013 17:58:22 +0000 (13:58 -0400)]
random: allow architectures to optionally define random_get_entropy()

commit 61875f30daf60305712e25b209ef41ced2635bad upstream.

Allow architectures which have a disabled get_cycles() function to
provide a random_get_entropy() function which provides a fine-grained,
rapidly changing counter that can be used by the /dev/random driver.

For example, an architecture might have a rapidly changing register
used to control random TLB cache eviction, or DRAM refresh that
doesn't meet the requirements of get_cycles(), but which is good
enough for the needs of the random driver.

Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agortlwifi: rtl8192cu: Fix error in pointer arithmetic
Mark Cave-Ayland [Tue, 8 Oct 2013 15:18:20 +0000 (10:18 -0500)]
rtlwifi: rtl8192cu: Fix error in pointer arithmetic

commit 9473ca6e920a3b9ca902753ce52833657f9221cc upstream.

An error in calculating the offset in an skb causes the driver to read
essential device info from the wrong locations. The main effect is that
automatic gain calculations are nonsense.

Signed-off-by: Mark Cave-Ayland <>
Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agoKVM: PPC: Book3S HV: Fix typo in saving DSCR
Paul Mackerras [Fri, 20 Sep 2013 23:53:28 +0000 (09:53 +1000)]
KVM: PPC: Book3S HV: Fix typo in saving DSCR

commit cfc860253abd73e1681696c08ea268d33285a2c4 upstream.

This fixes a typo in the code that saves the guest DSCR (Data Stream
Control Register) into the kvm_vcpu_arch struct on guest exit.  The
effect of the typo was that the DSCR value was saved in the wrong place,
so changes to the DSCR by the guest didn't persist across guest exit
and entry, and some host kernel memory got corrupted.

Signed-off-by: Paul Mackerras <>
Acked-by: Alexander Graf <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
9 years agoxhci: Fix spurious wakeups after S5 on Haswell
Takashi Iwai [Thu, 12 Sep 2013 06:11:06 +0000 (08:11 +0200)]
xhci: Fix spurious wakeups after S5 on Haswell

commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 upstream.

Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
mysterious wakeups after shutdown occasionally.  After discussing with
BIOS engineers, they explained that the new BIOS expects that the
wakeup sources are cleared and set to D3 for all wakeup devices when
the system is going to sleep or power off, but the current xhci driver
doesn't do this properly (partly intentionally).

This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for
fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci
shutdown ops as done in xhci_stop(), and setting the device to PCI D3
at shutdown and remove ops.

The PCI D3 call is based on the initial fix patch by Oliver Neukum.

[Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to
XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names
in them.  Sarah also fixed a collision with a quirk submitted around the
same time, by changing the xhci->quirks bit from 17 to 18.]

This patch should be backported to kernels as old as 3.0, that
contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add
Lynx Point to list of Intel switchable hosts."

Cc: Oliver Neukum <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sarah Sharp <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoxhci: quirk for extra long delay for S4
Oliver Neukum [Mon, 30 Sep 2013 13:50:54 +0000 (15:50 +0200)]
xhci: quirk for extra long delay for S4

commit 455f58925247e8a1a1941e159f3636ad6ee4c90b upstream.

It has been reported that this chipset really cannot
sleep without this extraordinary delay.

This patch should be backported, in order to ensure this host functions
under stable kernels.  The last quirk for Fresco Logic hosts (commit
bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI
quirk.") was backported to stable kernels as old as 2.6.36.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Sarah Sharp <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use xhci_dbg() instead of xhci_dbg_trace()]
Signed-off-by: Ben Hutchings <>
9 years agoxhci: Don't enable/disable RWE on bus suspend/resume.
Sarah Sharp [Mon, 5 Aug 2013 20:36:00 +0000 (13:36 -0700)]
xhci: Don't enable/disable RWE on bus suspend/resume.

commit f217c980ca980e3a645b7485ea5eae9a747f4945 upstream.

The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable
remote wakeup for devices in the lower power link state L1.  It has
nothing to do with the device suspend remote wakeup from L2.  The RWE
bit is designed to be set once (when USB 2.0 LPM is enabled for the
port) and cleared only when USB 2.0 LPM is disabled for the port.

The xHCI bus suspend method was setting the RWE bit erroneously, and the
bus resume method was clearing it.  The xHCI 1.0 specification with
errata up to Aug 12, 2012 says in section "Hardware
Controlled LPM":

"While Hardware USB2 LPM is enabled, software shall not modify the
HIRDBESL or RWE fields of the USB2 PORTPMSC register..."

If we have previously enabled USB 2.0 LPM for a device, that means when
the USB 2.0 bus is resumed, we violate the xHCI specification by
clearing RWE.  It also means that after a bus resume, the host would
think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM
enabled, which is not what we want.

This patch should be backported to kernels as old as 3.2, that
contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set
USB2 hardware LPM".  That was the first kernel that supported USB 2.0
Link PM.

Signed-off-by: Sarah Sharp <>
[bwh: Backported to 3.2: deleted code was cosmetically different]
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: fix hw contexts for SUMO2 asics
wojciech kapuscinski [Tue, 1 Oct 2013 23:54:33 +0000 (19:54 -0400)]
drm/radeon: fix hw contexts for SUMO2 asics

commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream.

They have 4 rather than 8.


Signed-off-by: wojciech kapuscinski <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agohwmon: (applesmc) Always read until end of data
Henrik Rydberg [Wed, 2 Oct 2013 17:15:03 +0000 (19:15 +0200)]
hwmon: (applesmc) Always read until end of data

commit 25f2bd7f5add608c1d1405938f39c96927b275ca upstream.

The crash reported and investigated in commit 5f4513 turned out to be
caused by a change to the read interface on newer (2012) SMCs.

Tests by Chris show that simply reading the data valid line is enough
for the problem to go away. Additional tests show that the newer SMCs
no longer wait for the number of requested bytes, but start sending
data right away.  Apparently the number of bytes to read is no longer
specified as before, but instead found out by reading until end of
data. Failure to read until end of data confuses the state machine,
which eventually causes the crash.

As a remedy, assuming bit0 is the read valid line, make sure there is
nothing more to read before leaving the read function.

Tested to resolve the original problem, and runtested on MBA3,1,
MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
machines before 2012.

Tested-by: Chris Murphy <>
Signed-off-by: Henrik Rydberg <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agomac80211: correctly close cancelled scans
Emmanuel Grumbach [Mon, 16 Sep 2013 08:12:07 +0000 (11:12 +0300)]
mac80211: correctly close cancelled scans

commit a754055a1296fcbe6f32de3a5eaca6efb2fd1865 upstream.

__ieee80211_scan_completed is called from a worker. This
means that the following flow is possible.

 * driver calls ieee80211_scan_completed
 * mac80211 cancels the scan (that is already complete)
 * __ieee80211_scan_completed runs

When scan_work will finally run, it will see that the scan
hasn't been aborted and might even trigger another scan on
another band. This leads to a situation where cfg80211's
scan is not done and no further scan can be issued.

Fix this by setting a new flag when a HW scan is being
cancelled so that no other scan will be triggered.

Signed-off-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: hda - Add fixup for ASUS N56VZ
Takashi Iwai [Tue, 8 Oct 2013 17:57:50 +0000 (19:57 +0200)]
ALSA: hda - Add fixup for ASUS N56VZ

commit c6cc3d58b4042f5cadae653ff8d3df26af1a0169 upstream.

ASUS N56VZ needs a fixup for the bass speaker pin, which was already
provided via model=asus-mode4.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agolibata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures
Gwendal Grignou [Fri, 7 Aug 2009 23:17:49 +0000 (16:17 -0700)]
libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures

commit f13e220161e738c2710b9904dcb3cf8bb0bcce61 upstream.

libata EH decrements scmd->retries when the command failed for reasons
unrelated to the command itself so that, for example, commands aborted
due to suspend / resume cycle don't get penalized; however,
decrementing scmd->retries isn't enough for ATA passthrough commands.

Without this fix, ATA passthrough commands are not resend to the
drive, and no error is signalled to the caller because:

- allowed retry count is 1
- ata_eh_qc_complete fill the sense data, so result is valid
- sense data is filled with untouched ATA registers.

Signed-off-by: Gwendal Grignou <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: snd-usb-usx2y: remove bogus frame checks
Daniel Mack [Wed, 2 Oct 2013 15:49:50 +0000 (17:49 +0200)]
ALSA: snd-usb-usx2y: remove bogus frame checks

commit a9d14bc0b188a822e42787d01e56c06fe9750162 upstream.

The frame check in i_usX2Y_urb_complete() and
i_usX2Y_usbpcm_urb_complete() is bogus and produces false positives as
described in this LAU thread:

This patch removes the check code entirely.

Reported-by: Dr Nicholas J Bailey <>
Suggested-by: Takashi Iwai <>
Signed-off-by: Daniel Mack <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series
Emmanuel Grumbach [Tue, 24 Sep 2013 16:34:26 +0000 (19:34 +0300)]
iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series

commit 08a5dd3842f2ac61c6d69661d2d96022df8ae359 upstream.

Add some new PCI IDs to the table for 6000, 6005 and 6235 series.

Signed-off-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2:
 - Adjust filenames
 - Drop const from struct iwl_cfg]
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: add new pci id for 6x35 series
Shuduo Sang [Sat, 30 Mar 2013 06:26:37 +0000 (14:26 +0800)]
iwlwifi: add new pci id for 6x35 series

commit 20ecf9fd3bebc4147e2996c08a75d6f0229b90df upstream.

some new thinkpad laptops use intel chip with new pci id need be added
lspci -vnn output:
 Network controller [0280]: Intel Corporation Centrino Advanced-N 6235
 [8086:088f] (rev 24)
 Subsystem: Intel Corporation Device [8086:5260]

Signed-off-by: Shuduo Sang <>
Reviewed-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: one more sku added to 6x35 series
Wey-Yi Guy [Wed, 22 Feb 2012 16:18:55 +0000 (08:18 -0800)]
iwlwifi: one more sku added to 6x35 series

commit 259653d86b80ed01c70d47b7307140ae0ba19420 upstream.

Add new sku to 6x35 series

Signed-off-by: Wey-Yi Guy <>
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: update pci subsystem id
Wey-Yi Guy [Wed, 22 Feb 2012 18:21:09 +0000 (10:21 -0800)]
iwlwifi: update pci subsystem id

commit 378911233f424d7a1bf4a579587ae71c7d887166 upstream.

Update the pci subsystem id and product name for 6005 series devices

Signed-off-by: Wey-Yi Guy <>
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: remove un-supported SKUs
Wey-Yi Guy [Thu, 10 Nov 2011 14:55:06 +0000 (06:55 -0800)]
iwlwifi: remove un-supported SKUs

commit b6cb406a023184733bffc7762a75a2e204fff6b9 upstream.

BG only SKUs are no longer supported by 2000 and 1x5 series. Remove it

Signed-off-by: Wey-Yi Guy <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: two more SKUs for 6x05 series
Wey-Yi Guy [Thu, 10 Nov 2011 14:55:03 +0000 (06:55 -0800)]
iwlwifi: two more SKUs for 6x05 series

commit 75a56eccb01fcc3c1ae8000130f3c9b3c8ec68d9 upstream.

Add two more SKUs for 6x05 series of device.
First SKU has low 5GHz channels actives, the other SKU has high 5GHz channels actives.

Signed-off-by: Wey-Yi Guy <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agotile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT
Chris Metcalf [Thu, 26 Sep 2013 17:24:53 +0000 (13:24 -0400)]
tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT

commit f862eefec0b68e099a9fa58d3761ffb10bad97e1 upstream.

It turns out the kernel relies on barrier() to force a reload of the
percpu offset value.  Since we can't easily modify the definition of
barrier() to include "tp" as an output register, we instead provide a
definition of __my_cpu_offset as extended assembly that includes a fake
stack read to hazard against barrier(), forcing gcc to know that it
must reread "tp" and recompute anything based on "tp" after a barrier.

This fixes observed hangs in the slub allocator when we are looping
on a percpu cmpxchg_double.

A similar fix for ARMv7 was made in June in change 509eb76ebf97.

Signed-off-by: Chris Metcalf <>
Signed-off-by: Ben Hutchings <>
9 years agomac80211: update sta->last_rx on acked tx frames
Felix Fietkau [Sun, 29 Sep 2013 19:39:34 +0000 (21:39 +0200)]
mac80211: update sta->last_rx on acked tx frames

commit 0c5b93290b2f3c7a376567c03ae8d385b0e99851 upstream.

When clients are idle for too long, hostapd sends nullfunc frames for
probing. When those are acked by the client, the idle time needs to be

To make this work (and to avoid unnecessary probing), update sta->last_rx
whenever an ACK was received for a tx packet. Only do this if the flag

Signed-off-by: Felix Fietkau <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
9 years agomac80211: drop spoofed packets in ad-hoc mode
Felix Fietkau [Tue, 17 Sep 2013 09:15:43 +0000 (11:15 +0200)]
mac80211: drop spoofed packets in ad-hoc mode

commit 6329b8d917adc077caa60c2447385554130853a3 upstream.

If an Ad-Hoc node receives packets with the Cell ID or its own MAC
address as source address, it hits a WARN_ON in sta_info_insert_check()
With many packets, this can massively spam the logs. One way that this
can easily happen is through having Cisco APs in the area with rouge AP
detection and countermeasures enabled.
Such Cisco APs will regularly send fake beacons, disassoc and deauth
packets that trigger these warnings.

To fix this issue, drop such spoofed packets early in the rx path.

Reported-by: Thomas Huehn <>
Signed-off-by: Felix Fietkau <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: use compare_ether_addr() instead of ether_addr_equal()]
Signed-off-by: Ben Hutchings <>
9 years agorandom: run random_int_secret_init() run after all late_initcalls
Theodore Ts'o [Tue, 10 Sep 2013 14:52:35 +0000 (10:52 -0400)]
random: run random_int_secret_init() run after all late_initcalls

commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.

The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason.  So make sure
random_int_secret_init() is run after all of the late_initcalls are

Signed-off-by: "Theodore Ts'o" <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agojfs: fix error path in ialloc
Dave Kleikamp [Sat, 7 Sep 2013 02:49:56 +0000 (21:49 -0500)]
jfs: fix error path in ialloc

commit 8660998608cfa1077e560034db81885af8e1e885 upstream.

If insert_inode_locked() fails, we shouldn't be calling

Signed-off-by: Dave Kleikamp <>
Tested-by: Michael L. Semon <>
Signed-off-by: Ben Hutchings <>
9 years agoinclude/linux/fs.h: disable preempt when acquire i_size_seqcount write lock
Fan Du [Tue, 30 Apr 2013 22:27:27 +0000 (15:27 -0700)]
include/linux/fs.h: disable preempt when acquire i_size_seqcount write lock

commit 74e3d1e17b2e11d175970b85acd44f5927000ba2 upstream.

Two rt tasks bind to one CPU core.

The higher priority rt task A preempts a lower priority rt task B which
has already taken the write seq lock, and then the higher priority rt
task A try to acquire read seq lock, it's doomed to lockup.

rt task A with lower priority: call write
i_size_write                                        rt task B with higher priority: call sync, and preempt task A
  write_seqcount_begin(&inode->i_size_seqcount);    i_size_read
  inode->i_size = i_size;                             read_seqcount_begin <-- lockup here...

So disable preempt when acquiring every i_size_seqcount *write* lock will
cure the problem.

Signed-off-by: Fan Du <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agotracing: Fix potential out-of-bounds in trace_get_user()
Steven Rostedt [Thu, 10 Oct 2013 02:23:23 +0000 (22:23 -0400)]
tracing: Fix potential out-of-bounds in trace_get_user()

commit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream.

Andrey reported the following report:

ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3
ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900ffff8800359c99f3)
Accessed by thread T13003:
  #0 ffffffff810dd2da (asan_report_error+0x32a/0x440)
  #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)
  #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
  #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
  #4 ffffffff812a1065 (__fput+0x155/0x360)
  #5 ffffffff812a12de (____fput+0x1e/0x30)
  #6 ffffffff8111708d (task_work_run+0x10d/0x140)
  #7 ffffffff810ea043 (do_exit+0x433/0x11f0)
  #8 ffffffff810eaee4 (do_group_exit+0x84/0x130)
  #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
  #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)

Allocated by thread T5167:
  #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
  #1 ffffffff8128337c (__kmalloc+0xbc/0x500)
  #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
  #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
  #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
  #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
  #6 ffffffff8129b668 (finish_open+0x68/0xa0)
  #7 ffffffff812b66ac (do_last+0xb8c/0x1710)
  #8 ffffffff812b7350 (path_openat+0x120/0xb50)
  #9 ffffffff812b8884 (do_filp_open+0x54/0xb0)
  #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
  #11 ffffffff8129d4b7 (SyS_open+0x37/0x50)
  #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)

Shadow bytes around the buggy address:
  ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
  ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap redzone:          fa
  Heap kmalloc redzone:  fb
  Freed heap region:     fd
  Shadow gap:            fe

The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'

Although the crash happened in ftrace_regex_open() the real bug
occurred in trace_get_user() where there's an incrementation to
parser->idx without a check against the size. The way it is triggered
is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
that reads the last character stores it and then breaks out because
there is no more characters. Then the last character is read to determine
what to do next, and the index is incremented without checking size.

Then the caller of trace_get_user() usually nulls out the last character
with a zero, but since the index is equal to the size, it writes a nul
character after the allocated space, which can corrupt memory.

Luckily, only root user has write access to this file.

Reported-by: Andrey Konovalov <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
9 years agonetfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet
Patrick McHardy [Fri, 5 Apr 2013 08:13:30 +0000 (08:13 +0000)]
netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet

commit 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471 upstream.

Some Cisco phones create huge messages that are spread over multiple packets.
After calculating the offset of the SIP body, it is validated to be within
the packet and the packet is dropped otherwise. This breaks operation of
these phones. Since connection tracking is supposed to be passive, just let
those packets pass unmodified and untracked.

Signed-off-by: Patrick McHardy <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: there is no log message to delete]
Signed-off-by: Ben Hutchings <>
9 years ago8139cp: re-enable interrupts after tx timeout
David Woodhouse [Sat, 24 Nov 2012 12:11:21 +0000 (12:11 +0000)]
8139cp: re-enable interrupts after tx timeout

commit 01ffc0a7f1c1801a2354719dedbc32aff45b987d upstream.

Recovery doesn't work too well if we leave interrupts disabled...

Signed-off-by: David Woodhouse <>
Acked-by: Francois Romieu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoinet: fix possible memory corruption with UDP_CORK and UFO
Hannes Frederic Sowa [Mon, 21 Oct 2013 22:07:47 +0000 (00:07 +0200)]
inet: fix possible memory corruption with UDP_CORK and UFO

[ This is a simplified -stable version of a set of upstream commits. ]

This is a replacement patch only for stable which does fix the problems
handled by the following two commits in -net:

"ip_output: do skb ufo init for peeked non ufo skb as well" (e93b7d748be887cd7639b113ba7d7ef792a7efb9)
"ip6_output: do skb ufo init for peeked non ufo skb as well" (c547dbf55d5f8cf615ccc0e7265e98db27d3fb8b)

Three frames are written on a corked udp socket for which the output
netdevice has UFO enabled.  If the first and third frame are smaller than
the mtu and the second one is bigger, we enqueue the second frame with
skb_append_datato_frags without initializing the gso fields. This leads
to the third frame appended regulary and thus constructing an invalid skb.

This fixes the problem by always using skb_append_datato_frags as soon
as the first frag got enqueued to the skb without marking the packet

The problem with only two frames for ipv6 was fixed by "ipv6: udp
packets following an UFO enqueued packet need also be handled by UFO"

Cc: Jiri Pirko <>
Cc: Eric Dumazet <>
Cc: David Miller <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoperf tools: Fix getrusage() related build failure on glibc trunk
Markus Trippelsdorf [Wed, 4 Apr 2012 08:45:27 +0000 (10:45 +0200)]
perf tools: Fix getrusage() related build failure on glibc trunk

commit 7b78f13603c6fcb64e020a0bbe31a651ea2b657b upstream.

On a system running glibc trunk perf doesn't build:

    CC builtin-sched.o
builtin-sched.c: In function ‘get_cpu_usage_nsec_parent’: builtin-sched.c:399:16: error: storage size of ‘ru’ isn’t known builtin-sched.c:403:2: error: implicit declaration of function ‘getrusage’ [-Werror=implicit-function-declaration]

Fix it by including sys/resource.h.

Signed-off-by: Markus Trippelsdorf <>
Cc: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: use jiffies_64 value to calculate credit timeout
Wei Liu [Mon, 28 Oct 2013 12:07:57 +0000 (12:07 +0000)]
xen-netback: use jiffies_64 value to calculate credit timeout

[ Upstream commit 059dfa6a93b779516321e5112db9d7621b1367ba ]

time_after_eq() only works if the delta is < MAX_ULONG/2.

For a 32bit Dom0, if netfront sends packets at a very low rate, the time
between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
and the test for timer_after_eq() will be incorrect. Credit will not be
replenished and the guest may become unable to send packets (e.g., if
prior to the long gap, all credit was exhausted).

Use jiffies_64 variant to mitigate this problem for 32bit Dom0.

Suggested-by: Jan Beulich <>
Signed-off-by: Wei Liu <>
Reviewed-by: David Vrabel <>
Cc: Ian Campbell <>
Cc: Jason Luan <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoperf: Fix perf ring buffer memory ordering
Peter Zijlstra [Mon, 28 Oct 2013 12:55:29 +0000 (13:55 +0100)]
perf: Fix perf ring buffer memory ordering

commit bf378d341e4873ed928dc3c636252e6895a21f50 upstream.

The PPC64 people noticed a missing memory barrier and crufty old
comments in the perf ring buffer code. So update all the comments and
add the missing barrier.

When the architecture implements local_t using atomic_long_t there
will be double barriers issued; but short of introducing more
conditional barrier primitives this is the best we can do.

Reported-by: Victor Kaplansky <>
Tested-by: Victor Kaplansky <>
Signed-off-by: Peter Zijlstra <>
Cc: Mathieu Desnoyers <>
Cc: Paul McKenney <>
Cc: Michael Neuling <>
Cc: Frederic Weisbecker <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agozram: allow request end to coincide with disksize
Sergey Senozhatsky [Sat, 22 Jun 2013 14:21:00 +0000 (17:21 +0300)]
zram: allow request end to coincide with disksize

commit 75c7caf5a052ffd8db3312fa7864ee2d142890c4 upstream.

Pass valid_io_request() checks if request end coincides with disksize
(end equals bound), only fail if we attempt to read beyond the bound.

mkfs.ext2 produces numerous errors:
[ 2164.632747] quiet_error: 1 callbacks suppressed
[ 2164.633260] Buffer I/O error on device zram0, logical block 153599
[ 2164.633265] lost page write due to I/O error on zram0

Signed-off-by: Sergey Senozhatsky <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoext3: return 32/64-bit dir name hash according to usage type
Eric Sandeen [Thu, 26 Apr 2012 18:10:39 +0000 (13:10 -0500)]
ext3: return 32/64-bit dir name hash according to usage type

commit d7dab39b6e16d5eea78ed3c705d2a2d0772b4f06 upstream.

This is based on commit d1f5273e9adb40724a85272f248f210dc4ce919a
ext4: return 32/64-bit dir name hash according to usage type
by Fan Yong <>

Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
and telldir().  However, this causes problems if there are 32-bit hash
collisions, since the NFSv2 server can get stuck resending the same
entries from the directory repeatedly.

Allow ext3 to return a full 64-bit hash (both major and minor) for
telldir to decrease the chance of hash collisions.

This patch does implement a new ext3_dir_llseek op, because with 64-bit
hashes, nfs will attempt to seek to a hash "offset" which is much
larger than ext3's s_maxbytes.  So for dx dirs, we call
generic_file_llseek_size() with the appropriate max hash value as the
maximum seekable size.  Otherwise we just pass through to

Patch-updated-by: Bernd Schubert <>
Patch-updated-by: Eric Sandeen <>
(blame us if something is not correct)

Signed-off-by: Eric Sandeen <>
Signed-off-by: Jan Kara <>
Signed-off-by: Jonathan Nieder <>
Signed-off-by: Ben Hutchings <>
9 years agonfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)
Bernd Schubert [Mon, 19 Mar 2012 02:44:50 +0000 (22:44 -0400)]
nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)

commit 06effdbb49af5f6c7d20affaec74603914acc768 upstream.

Use 32-bit or 64-bit llseek() hashes for directory offsets depending on
the NFS version. NFSv2 gets 32-bit hashes only.

NOTE: This patch got rather complex as Christoph asked to set the
filp->f_mode flag in the open call or immediatly after dentry_open()
in nfsd_open() to avoid races.
Personally I still do not see a reason for that and in my opinion
FMODE_32BITHASH/FMODE_64BITHASH flags could be set nfsd_readdir(), as it
follows directly after nfsd_open() without a chance of races.

Signed-off-by: Bernd Schubert <>
Signed-off-by: "Theodore Ts'o" <>
Acked-by: J. Bruce Fields <>
Signed-off-by: Jonathan Nieder <>
Signed-off-by: Ben Hutchings <>
9 years agonfsd: rename 'int access' to 'int may_flags' in nfsd_open()
Bernd Schubert [Mon, 19 Mar 2012 02:44:49 +0000 (22:44 -0400)]
nfsd: rename 'int access' to 'int may_flags' in nfsd_open()

commit 999448a8c0202d8c41711c92385323520644527b upstream.

Just rename this variable, as the next patch will add a flag and
'access' as variable name would not be correct any more.

Signed-off-by: Bernd Schubert <>
Signed-off-by: "Theodore Ts'o" <>
Acked-by: J. Bruce Fields <>
Signed-off-by: Jonathan Nieder <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: return 32/64-bit dir name hash according to usage type
Fan Yong [Mon, 19 Mar 2012 02:44:40 +0000 (22:44 -0400)]
ext4: return 32/64-bit dir name hash according to usage type

commit d1f5273e9adb40724a85272f248f210dc4ce919a upstream.

Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
and telldir().  However, this causes problems if there are 32-bit hash
collisions, since the NFSv2 server can get stuck resending the same
entries from the directory repeatedly.

Allow ext4 to return a full 64-bit hash (both major and minor) for
telldir to decrease the chance of hash collisions.  This still needs
integration on the NFS side.

Patch-updated-by: Bernd Schubert <>
(blame me if something is not correct)

Signed-off-by: Fan Yong <>
Signed-off-by: Andreas Dilger <>
Signed-off-by: Bernd Schubert <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Jonathan Nieder <>
Signed-off-by: Ben Hutchings <>
9 years agofs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash
Bernd Schubert [Wed, 14 Mar 2012 02:51:38 +0000 (22:51 -0400)]
fs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash

commit 6a8a13e03861c0ab83ab07d573ca793cff0e5d00 upstream.

Those flags are supposed to be set by NFS readdir() to tell ext3/ext4
to 32bit (NFSv2) or 64bit hash values (offsets) in seekdir().

Signed-off-by: Bernd Schubert <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Jonathan Nieder <>
Signed-off-by: Ben Hutchings <>
9 years agoPCI: fix truncation of resource size to 32 bits
Nikhil P Rao [Wed, 20 Jun 2012 19:56:00 +0000 (12:56 -0700)]
PCI: fix truncation of resource size to 32 bits

commit d6776e6d5c2f8db0252f447b09736075e1bbe387 upstream.

_pci_assign_resource() took an int "size" argument, which meant that
sizes larger than 4GB were truncated.  Change type to resource_size_t.

[bhelgaas: changelog]
Signed-off-by: Nikhil P Rao <>
Signed-off-by: Bjorn Helgaas <>
Signed-off-by: Ben Hutchings <>
9 years agodavinci_emac.c: Fix IFF_ALLMULTI setup
Mariusz Ceier [Mon, 21 Oct 2013 17:45:04 +0000 (19:45 +0200)]
davinci_emac.c: Fix IFF_ALLMULTI setup

[ Upstream commit d69e0f7ea95fef8059251325a79c004bac01f018 ]

When IFF_ALLMULTI flag is set on interface and IFF_PROMISC isn't,
emac_dev_mcast_set should only enable RX of multicasts and reset
MACHASH registers.

It does this, but afterwards it either sets up multicast MACs
filtering or disables RX of multicasts and resets MACHASH registers
again, rendering IFF_ALLMULTI flag useless.

This patch fixes emac_dev_mcast_set, so that multicast MACs filtering and
disabling of RX of multicasts are skipped when IFF_ALLMULTI flag is set.

Tested with kernel 2.6.37.

Signed-off-by: Mariusz Ceier <>
Acked-by: Mugunthan V N <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: fix cipso packet validation when !NETLABEL
Seif Mazareeb [Fri, 18 Oct 2013 03:33:21 +0000 (20:33 -0700)]
net: fix cipso packet validation when !NETLABEL

[ Upstream commit f2e5ddcc0d12f9c4c7b254358ad245c9dddce13b ]

When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could loop
forever in the main loop if opt[opt_iter +1] == 0, this will causing a kernel
crash in an SMP system, since the CPU executing this function will
stall /not respond to IPIs.

This problem can be reproduced by running the IP Stack Integrity Checker
( using the following command on a Linux machine
connected to DUT:

"icmpsic -s rand -d <DUT IP address> -r 123456"
wait (1-2 min)

Signed-off-by: Seif Mazareeb <>
Acked-by: Paul Moore <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: unix: inherit SOCK_PASS{CRED, SEC} flags from socket to fix race
Daniel Borkmann [Thu, 17 Oct 2013 20:51:31 +0000 (22:51 +0200)]
net: unix: inherit SOCK_PASS{CRED, SEC} flags from socket to fix race

[ Upstream commit 90c6bd34f884cd9cee21f1d152baf6c18bcac949 ]

In the case of credentials passing in unix stream sockets (dgram
sockets seem not affected), we get a rather sparse race after
commit 16e5726 ("af_unix: dont send SCM_CREDENTIALS by default").

We have a stream server on receiver side that requests credential
passing from senders (e.g. nc -U). Since we need to set SO_PASSCRED
on each spawned/accepted socket on server side to 1 first (as it's
not inherited), it can happen that in the time between accept() and
setsockopt() we get interrupted, the sender is being scheduled and
continues with passing data to our receiver. At that time SO_PASSCRED
is neither set on sender nor receiver side, hence in cmsg's
SCM_CREDENTIALS we get eventually pid:0, uid:65534, gid:65534
(== overflow{u,g}id) instead of what we actually would like to see.

On the sender side, here nc -U, the tests in maybe_add_creds()
invoked through unix_stream_sendmsg() would fail, as at that exact
time, as mentioned, the sender has neither SO_PASSCRED on his side
nor sees it on the server side, and we have a valid 'other' socket
in place. Thus, sender believes it would just look like a normal
connection, not needing/requesting SO_PASSCRED at that time.

As reverting 16e5726 would not be an option due to the significant
performance regression reported when having creds always passed,
one way/trade-off to prevent that would be to set SO_PASSCRED on
the listener socket and allow inheriting these flags to the spawned
socket on server side in accept(). It seems also logical to do so
if we'd tell the listener socket to pass those flags onwards, and
would fix the race.

Before, strace:

recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
        msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
        cmsg_type=SCM_CREDENTIALS{pid=0, uid=65534, gid=65534}},
        msg_flags=0}, 0) = 5

After, strace:

recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
        msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
        cmsg_type=SCM_CREDENTIALS{pid=11580, uid=1000, gid=1000}},
        msg_flags=0}, 0) = 5

Signed-off-by: Daniel Borkmann <>
Cc: Eric Dumazet <>
Cc: Eric W. Biederman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agowanxl: fix info leak in ioctl
Salva Peiró [Wed, 16 Oct 2013 10:46:50 +0000 (12:46 +0200)]
wanxl: fix info leak in ioctl

[ Upstream commit 2b13d06c9584b4eb773f1e80bbaedab9a1c344e1 ]

The wanxl_ioctl() code fails to initialize the two padding bytes of
struct sync_serial_settings after the ->loopback member. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Salva Peiró <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agosctp: Perform software checksum if packet has to be fragmented.
Vlad Yasevich [Wed, 16 Oct 2013 02:01:31 +0000 (22:01 -0400)]
sctp: Perform software checksum if packet has to be fragmented.

[ Upstream commit d2dbbba77e95dff4b4f901fee236fef6d9552072 ]

IP/IPv6 fragmentation knows how to compute only TCP/UDP checksum.
This causes problems if SCTP packets has to be fragmented and
ipsummed has been set to PARTIAL due to checksum offload support.
This condition can happen when retransmitting after MTU discover,
or when INIT or other control chunks are larger then MTU.
Check for the rare fragmentation condition in SCTP and use software
checksum calculation in this case.

CC: Fan Du <>
Signed-off-by: Vlad Yasevich <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agosctp: Use software crc32 checksum when xfrm transform will happen.
Fan Du [Wed, 16 Oct 2013 02:01:30 +0000 (22:01 -0400)]
sctp: Use software crc32 checksum when xfrm transform will happen.

[ Upstream commit 27127a82561a2a3ed955ce207048e1b066a80a2a ]

igb/ixgbe have hardware sctp checksum support, when this feature is enabled
and also IPsec is armed to protect sctp traffic, ugly things happened as
xfrm_output checks CHECKSUM_PARTIAL to do checksum operation(sum every thing
up and pack the 16bits result in the checksum field). The result is fail
establishment of sctp communication.

Cc: Neil Horman <>
Cc: Steffen Klassert <>
Signed-off-by: Fan Du <>
Signed-off-by: Vlad Yasevich <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: dst: provide accessor function to dst->xfrm
Vlad Yasevich [Wed, 16 Oct 2013 02:01:29 +0000 (22:01 -0400)]
net: dst: provide accessor function to dst->xfrm

[ Upstream commit e87b3998d795123b4139bc3f25490dd236f68212 ]

dst->xfrm is conditionally defined.  Provide accessor funtion that
is always available.

Signed-off-by: Vlad Yasevich <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agobnx2x: record rx queue for LRO packets
Eric Dumazet [Sat, 12 Oct 2013 21:08:34 +0000 (14:08 -0700)]
bnx2x: record rx queue for LRO packets

[ Upstream commit 60e66fee56b2256dcb1dc2ea1b2ddcb6e273857d ]

RPS support is kind of broken on bnx2x, because only non LRO packets
get proper rx queue information. This triggers reorders, as it seems
bnx2x like to generate a non LRO packet for segment including TCP PUSH
flag : (this might be pure coincidence, but all the reorders I've
seen involve segments with a PUSH)

11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985797>
11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>

We must call skb_record_rx_queue() to properly give to RPS (and more
generally for TX queue selection on forward path) the receive queue

Similar fix is needed for skb_mark_napi_id(), but will be handled
in a separate patch to ease stable backports.

Signed-off-by: Eric Dumazet <>
Cc: Willem de Bruijn <>
Cc: Eilon Greenstein <>
Acked-by: Dmitry Kravkov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoconnector: use nlmsg_len() to check message length
Mathias Krause [Mon, 30 Sep 2013 20:03:07 +0000 (22:03 +0200)]
connector: use nlmsg_len() to check message length

[ Upstream commit 162b2bedc084d2d908a04c93383ba02348b648b0 ]

The current code tests the length of the whole netlink message to be
at least as long to fit a cn_msg. This is wrong as nlmsg_len includes
the length of the netlink message header. Use nlmsg_len() instead to
fix this "off-by-NLMSG_HDRLEN" size check.

Cc: # v2.6.14+
Signed-off-by: Mathias Krause <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agofarsync: fix info leak in ioctl
Salva Peiró [Fri, 11 Oct 2013 09:50:03 +0000 (12:50 +0300)]
farsync: fix info leak in ioctl

[ Upstream commit 96b340406724d87e4621284ebac5e059d67b2194 ]

The fst_get_iface() code fails to initialize the two padding bytes of
struct sync_serial_settings after the ->loopback member. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agol2tp: must disable bh before calling l2tp_xmit_skb()
Eric Dumazet [Thu, 10 Oct 2013 13:30:09 +0000 (06:30 -0700)]
l2tp: must disable bh before calling l2tp_xmit_skb()

[ Upstream commit 455cc32bf128e114455d11ad919321ab89a2c312 ]

François Cachereul made a very nice bug report and suspected
the bh_lock_sock() / bh_unlok_sock() pair used in l2tp_xmit_skb() from
process context was not good.

This problem was added by commit 6af88da14ee284aaad6e4326da09a89191ab6165
("l2tp: Fix locking in l2tp_core.c").

l2tp_eth_dev_xmit() runs from BH context, so we must disable BH
from other l2tp_xmit_skb() users.

[  452.060011] BUG: soft lockup - CPU#1 stuck for 23s! [accel-pppd:6662]
[  452.061757] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppoe pppox
ppp_generic slhc ipv6 ext3 mbcache jbd virtio_balloon xfs exportfs dm_mod
virtio_blk ata_generic virtio_net floppy ata_piix libata virtio_pci virtio_ring virtio [last unloaded: scsi_wait_scan]
[  452.064012] CPU 1
[  452.080015] BUG: soft lockup - CPU#2 stuck for 23s! [accel-pppd:6643]
[  452.080015] CPU 2
[  452.080015]
[  452.080015] Pid: 6643, comm: accel-pppd Not tainted #1 Bochs Bochs
[  452.080015] RIP: 0010:[<ffffffff81059f6c>]  [<ffffffff81059f6c>] do_raw_spin_lock+0x17/0x1f
[  452.080015] RSP: 0018:ffff88007125fc18  EFLAGS: 00000293
[  452.080015] RAX: 000000000000aba9 RBX: ffffffff811d0703 RCX: 0000000000000000
[  452.080015] RDX: 00000000000000ab RSI: ffff8800711f6896 RDI: ffff8800745c8110
[  452.080015] RBP: ffff88007125fc18 R08: 0000000000000020 R09: 0000000000000000
[  452.080015] R10: 0000000000000000 R11: 0000000000000280 R12: 0000000000000286
[  452.080015] R13: 0000000000000020 R14: 0000000000000240 R15: 0000000000000000
[  452.080015] FS:  00007fdc0cc24700(0000) GS:ffff8800b6f00000(0000) knlGS:0000000000000000
[  452.080015] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  452.080015] CR2: 00007fdb054899b8 CR3: 0000000074404000 CR4: 00000000000006a0
[  452.080015] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  452.080015] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  452.080015] Process accel-pppd (pid: 6643, threadinfo ffff88007125e000, task ffff8800b27e6dd0)
[  452.080015] Stack:
[  452.080015]  ffff88007125fc28 ffffffff81256559 ffff88007125fc98 ffffffffa01b2bd1
[  452.080015]  ffff88007125fc58 000000000000000c 00000000029490d0 0000009c71dbe25e
[  452.080015]  000000000000005c 000000080000000e 0000000000000000 ffff880071170600
[  452.080015] Call Trace:
[  452.080015]  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
[  452.080015]  [<ffffffffa01b2bd1>] l2tp_xmit_skb+0x189/0x4ac [l2tp_core]
[  452.080015]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[  452.080015]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[  452.080015]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[  452.080015]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
[  452.080015]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[  452.080015]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
[  452.080015]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[  452.080015]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[  452.080015]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
[  452.080015] Code: 81 48 89 e5 72 0c 31 c0 48 81 ff 45 66 25 81 0f 92 c0 5d c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 0f b6 d4 38 d0 74 06 f3 90 <8a> 07 eb f6 5d c3 90 90 55 48 89 e5 9c 58 0f 1f 44 00 00 5d c3
[  452.080015] Call Trace:
[  452.080015]  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
[  452.080015]  [<ffffffffa01b2bd1>] l2tp_xmit_skb+0x189/0x4ac [l2tp_core]
[  452.080015]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[  452.080015]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[  452.080015]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[  452.080015]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
[  452.080015]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[  452.080015]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
[  452.080015]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[  452.080015]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[  452.080015]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
[  452.064012]
[  452.064012] Pid: 6662, comm: accel-pppd Not tainted #1 Bochs Bochs
[  452.064012] RIP: 0010:[<ffffffff81059f6e>]  [<ffffffff81059f6e>] do_raw_spin_lock+0x19/0x1f
[  452.064012] RSP: 0018:ffff8800b6e83ba0  EFLAGS: 00000297
[  452.064012] RAX: 000000000000aaa9 RBX: ffff8800b6e83b40 RCX: 0000000000000002
[  452.064012] RDX: 00000000000000aa RSI: 000000000000000a RDI: ffff8800745c8110
[  452.064012] RBP: ffff8800b6e83ba0 R08: 000000000000c802 R09: 000000000000001c
[  452.064012] R10: ffff880071096c4e R11: 0000000000000006 R12: ffff8800b6e83b18
[  452.064012] R13: ffffffff8125d51e R14: ffff8800b6e83ba0 R15: ffff880072a589c0
[  452.064012] FS:  00007fdc0b81e700(0000) GS:ffff8800b6e80000(0000) knlGS:0000000000000000
[  452.064012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  452.064012] CR2: 0000000000625208 CR3: 0000000074404000 CR4: 00000000000006a0
[  452.064012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  452.064012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  452.064012] Process accel-pppd (pid: 6662, threadinfo ffff88007129a000, task ffff8800744f7410)
[  452.064012] Stack:
[  452.064012]  ffff8800b6e83bb0 ffffffff81256559 ffff8800b6e83bc0 ffffffff8121c64a
[  452.064012]  ffff8800b6e83bf0 ffffffff8121ec7a ffff880072a589c0 ffff880071096c62
[  452.064012]  0000000000000011 ffffffff81430024 ffff8800b6e83c80 ffffffff8121f276
[  452.064012] Call Trace:
[  452.064012]  <IRQ>
[  452.064012]  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
[  452.064012]  [<ffffffff8121c64a>] spin_lock+0x9/0xb
[  452.064012]  [<ffffffff8121ec7a>] udp_queue_rcv_skb+0x186/0x269
[  452.064012]  [<ffffffff8121f276>] __udp4_lib_rcv+0x297/0x4ae
[  452.064012]  [<ffffffff8121c178>] ? raw_rcv+0xe9/0xf0
[  452.064012]  [<ffffffff8121f4a7>] udp_rcv+0x1a/0x1c
[  452.064012]  [<ffffffff811fe385>] ip_local_deliver_finish+0x12b/0x1a5
[  452.064012]  [<ffffffff811fe54e>] ip_local_deliver+0x53/0x84
[  452.064012]  [<ffffffff811fe1d0>] ip_rcv_finish+0x2bc/0x2f3
[  452.064012]  [<ffffffff811fe78f>] ip_rcv+0x210/0x269
[  452.064012]  [<ffffffff8101911e>] ? kvm_clock_get_cycles+0x9/0xb
[  452.064012]  [<ffffffff811d88cd>] __netif_receive_skb+0x3a5/0x3f7
[  452.064012]  [<ffffffff811d8eba>] netif_receive_skb+0x57/0x5e
[  452.064012]  [<ffffffff811cf30f>] ? __netdev_alloc_skb+0x1f/0x3b
[  452.064012]  [<ffffffffa0049126>] virtnet_poll+0x4ba/0x5a4 [virtio_net]
[  452.064012]  [<ffffffff811d9417>] net_rx_action+0x73/0x184
[  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[  452.064012]  [<ffffffff810343b9>] __do_softirq+0xc3/0x1a8
[  452.064012]  [<ffffffff81013b56>] ? ack_APIC_irq+0x10/0x12
[  452.064012]  [<ffffffff81256559>] ? _raw_spin_lock+0xe/0x10
[  452.064012]  [<ffffffff8125e0ac>] call_softirq+0x1c/0x26
[  452.064012]  [<ffffffff81003587>] do_softirq+0x45/0x82
[  452.064012]  [<ffffffff81034667>] irq_exit+0x42/0x9c
[  452.064012]  [<ffffffff8125e146>] do_IRQ+0x8e/0xa5
[  452.064012]  [<ffffffff8125676e>] common_interrupt+0x6e/0x6e
[  452.064012]  <EOI>
[  452.064012]  [<ffffffff810b82a1>] ? kfree+0x8a/0xa3
[  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[  452.064012]  [<ffffffffa01b2c25>] ? l2tp_xmit_skb+0x1dd/0x4ac [l2tp_core]
[  452.064012]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[  452.064012]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[  452.064012]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[  452.064012]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
[  452.064012]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[  452.064012]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
[  452.064012]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[  452.064012]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[  452.064012]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
[  452.064012] Code: 89 e5 72 0c 31 c0 48 81 ff 45 66 25 81 0f 92 c0 5d c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 0f b6 d4 38 d0 74 06 f3 90 8a 07 <eb> f6 5d c3 90 90 55 48 89 e5 9c 58 0f 1f 44 00 00 5d c3 55 48
[  452.064012] Call Trace:
[  452.064012]  <IRQ>  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
[  452.064012]  [<ffffffff8121c64a>] spin_lock+0x9/0xb
[  452.064012]  [<ffffffff8121ec7a>] udp_queue_rcv_skb+0x186/0x269
[  452.064012]  [<ffffffff8121f276>] __udp4_lib_rcv+0x297/0x4ae
[  452.064012]  [<ffffffff8121c178>] ? raw_rcv+0xe9/0xf0
[  452.064012]  [<ffffffff8121f4a7>] udp_rcv+0x1a/0x1c
[  452.064012]  [<ffffffff811fe385>] ip_local_deliver_finish+0x12b/0x1a5
[  452.064012]  [<ffffffff811fe54e>] ip_local_deliver+0x53/0x84
[  452.064012]  [<ffffffff811fe1d0>] ip_rcv_finish+0x2bc/0x2f3
[  452.064012]  [<ffffffff811fe78f>] ip_rcv+0x210/0x269
[  452.064012]  [<ffffffff8101911e>] ? kvm_clock_get_cycles+0x9/0xb
[  452.064012]  [<ffffffff811d88cd>] __netif_receive_skb+0x3a5/0x3f7
[  452.064012]  [<ffffffff811d8eba>] netif_receive_skb+0x57/0x5e
[  452.064012]  [<ffffffff811cf30f>] ? __netdev_alloc_skb+0x1f/0x3b
[  452.064012]  [<ffffffffa0049126>] virtnet_poll+0x4ba/0x5a4 [virtio_net]
[  452.064012]  [<ffffffff811d9417>] net_rx_action+0x73/0x184
[  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[  452.064012]  [<ffffffff810343b9>] __do_softirq+0xc3/0x1a8
[  452.064012]  [<ffffffff81013b56>] ? ack_APIC_irq+0x10/0x12
[  452.064012]  [<ffffffff81256559>] ? _raw_spin_lock+0xe/0x10
[  452.064012]  [<ffffffff8125e0ac>] call_softirq+0x1c/0x26
[  452.064012]  [<ffffffff81003587>] do_softirq+0x45/0x82
[  452.064012]  [<ffffffff81034667>] irq_exit+0x42/0x9c
[  452.064012]  [<ffffffff8125e146>] do_IRQ+0x8e/0xa5
[  452.064012]  [<ffffffff8125676e>] common_interrupt+0x6e/0x6e
[  452.064012]  <EOI>  [<ffffffff810b82a1>] ? kfree+0x8a/0xa3
[  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[  452.064012]  [<ffffffffa01b2c25>] ? l2tp_xmit_skb+0x1dd/0x4ac [l2tp_core]
[  452.064012]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[  452.064012]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[  452.064012]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[  452.064012]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
[  452.064012]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[  452.064012]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
[  452.064012]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[  452.064012]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[  452.064012]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b

Reported-by: François Cachereul <>
Tested-by: François Cachereul <>
Signed-off-by: Eric Dumazet <>
Cc: James Chapman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: vlan: fix nlmsg size calculation in vlan_get_size()
Marc Kleine-Budde [Mon, 7 Oct 2013 21:19:58 +0000 (23:19 +0200)]
net: vlan: fix nlmsg size calculation in vlan_get_size()

[ Upstream commit c33a39c575068c2ea9bffb22fd6de2df19c74b89 ]

This patch fixes the calculation of the nlmsg size, by adding the missing

Cc: Patrick McHardy <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv6: restrict neighbor entry creation to output flow
Marcelo Ricardo Leitner [Tue, 8 Oct 2013 14:41:13 +0000 (16:41 +0200)]
ipv6: restrict neighbor entry creation to output flow

This patch is based on 3.2.y branch, the one used by reporter. Please let me
know if it should be different. Thanks.

The patch which introduced the regression was applied on stables:
3.0.64 3.4.31 3.7.8 3.2.39

The patch which introduced the regression was for stable trees only.


Commit 0d6a77079c475033cb622c07c5a880b392ef664e "ipv6: do not create
neighbor entries for local delivery" introduced a regression on
which routes to local delivery would not work anymore. Like this:

    $ ip -6 route add local 2001::/64 dev lo
    $ ping6 -c1 2001::9
    PING 2001::9(2001::9) 56 data bytes
    ping: sendmsg: Invalid argument

As this is a local delivery, that commit would not allow the creation of a
neighbor entry and thus the packet cannot be sent.

But as TPROXY scenario actually needs to avoid the neighbor entry creation only
for input flow, this patch now limits previous patch to input flow, keeping
output as before that patch.

Reported-by: Debabrata Banerjee <>
Signed-off-by: Marcelo Ricardo Leitner <>
Signed-off-by: Jiri Pirko <>
Acked-by: Hannes Frederic Sowa <>
CC: Hannes Frederic Sowa <>
Signed-off-by: Ben Hutchings <>
9 years agocan: dev: fix nlmsg size calculation in can_get_size()
Marc Kleine-Budde [Sat, 5 Oct 2013 19:25:17 +0000 (21:25 +0200)]
can: dev: fix nlmsg size calculation in can_get_size()

[ Upstream commit fe119a05f8ca481623a8d02efcc984332e612528 ]

This patch fixes the calculation of the nlmsg size, by adding the missing

Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv4: fix ineffective source address selection
Jiri Benc [Fri, 4 Oct 2013 15:04:48 +0000 (17:04 +0200)]
ipv4: fix ineffective source address selection

[ Upstream commit 0a7e22609067ff524fc7bbd45c6951dd08561667 ]

When sending out multicast messages, the source address in inet->mc_addr is
ignored and rewritten by an autoselected one. This is caused by a typo in
commit 813b3b5db831 ("ipv4: Use caller's on-stack flowi as-is in output
route lookups").

Signed-off-by: Jiri Benc <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoproc connector: fix info leaks
Mathias Krause [Mon, 30 Sep 2013 20:03:06 +0000 (22:03 +0200)]
proc connector: fix info leaks

[ Upstream commit e727ca82e0e9616ab4844301e6bae60ca7327682 ]

Initialize event_data for all possible message types to prevent leaking
kernel stack contents to userland (up to 20 bytes). Also set the flags
member of the connector message to 0 to prevent leaking two more stack
bytes this way.

Cc: # v2.6.15+
Signed-off-by: Mathias Krause <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: heap overflow in __audit_sockaddr()
Dan Carpenter [Wed, 2 Oct 2013 21:27:20 +0000 (00:27 +0300)]
net: heap overflow in __audit_sockaddr()

[ Upstream commit 1661bf364ae9c506bc8795fef70d1532931be1e8 ]

We need to cap ->msg_namelen or it leads to a buffer overflow when we
to the memcpy() in __audit_sockaddr().  It requires CAP_AUDIT_CONTROL to
exploit this bug.

The call tree is:

Reported-by: Jüri Aedla <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: do not call sock_put() on TIMEWAIT sockets
Eric Dumazet [Wed, 2 Oct 2013 04:04:11 +0000 (21:04 -0700)]
net: do not call sock_put() on TIMEWAIT sockets

[ Upstream commit 80ad1d61e72d626e30ebe8529a0455e660ca4693 ]

commit 3ab5aee7fe84 ("net: Convert TCP & DCCP hash tables to use RCU /
hlist_nulls") incorrectly used sock_put() on TIMEWAIT sockets.

We should instead use inet_twsk_put()

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agotcp: do not forget FIN in tcp_shifted_skb()
Eric Dumazet [Fri, 4 Oct 2013 17:31:41 +0000 (10:31 -0700)]
tcp: do not forget FIN in tcp_shifted_skb()

[ Upstream commit 5e8a402f831dbe7ee831340a91439e46f0d38acd ]

Yuchung found following problem :

 There are bugs in the SACK processing code, merging part in
 tcp_shift_skb_data(), that incorrectly resets or ignores the sacked
 skbs FIN flag. When a receiver first SACK the FIN sequence, and later
 throw away ofo queue (e.g., sack-reneging), the sender will stop
 retransmitting the FIN flag, and hangs forever.

Following packetdrill test can be used to reproduce the bug.

$ cat sack-merge-bug.pkt
`sysctl -q net.ipv4.tcp_fack=0`

// Establish a connection and send 10 MSS.
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+.000 bind(3, ..., ...) = 0
+.000 listen(3, 1) = 0

+.050 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+.000 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>
+.001 < . 1:1(0) ack 1 win 1024
+.000 accept(3, ..., ...) = 4

+.100 write(4, ..., 12000) = 12000
+.000 shutdown(4, SHUT_WR) = 0
+.000 > . 1:10001(10000) ack 1
+.050 < . 1:1(0) ack 2001 win 257
+.000 > FP. 10001:12001(2000) ack 1
+.050 < . 1:1(0) ack 2001 win 257 <sack 10001:11001,nop,nop>
+.050 < . 1:1(0) ack 2001 win 257 <sack 10001:12002,nop,nop>
// SACK reneg
+.050 < . 1:1(0) ack 12001 win 257
+0 %{ print "unacked: ",tcpi_unacked }%
+5 %{ print "" }%

First, a typo inverted left/right of one OR operation, then
code forgot to advance end_seq if the merged skb carried FIN.

Bug was added in 2.6.29 by commit 832d11c5cd076ab
("tcp: Try to restore large SKBs while SACK processing")

Signed-off-by: Eric Dumazet <>
Signed-off-by: Yuchung Cheng <>
Acked-by: Neal Cardwell <>
Cc: Ilpo Järvinen <>
Acked-by: Ilpo Järvinen <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agotcp: must unclone packets before mangling them
Eric Dumazet [Tue, 15 Oct 2013 18:54:30 +0000 (11:54 -0700)]
tcp: must unclone packets before mangling them

[ Upstream commit c52e2421f7368fd36cbe330d2cf41b10452e39a9 ]

TCP stack should make sure it owns skbs before mangling them.

We had various crashes using bnx2x, and it turned out gso_size
was cleared right before bnx2x driver was populating TC descriptor
of the _previous_ packet send. TCP stack can sometime retransmit
packets that are still in Qdisc.

Of course we could make bnx2x driver more robust (using
ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack.

We have identified two points where skb_unclone() was needed.

This patch adds a WARN_ON_ONCE() to warn us if we missed another
fix of this kind.

Kudos to Neal for finding the root cause of this bug. Its visible
using small MSS.

Signed-off-by: Eric Dumazet <>
Signed-off-by: Neal Cardwell <>
Cc: Yuchung Cheng <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: avoid alignment related control reg writeouts
Grazvydas Ignotas [Sun, 3 Nov 2013 21:19:41 +0000 (23:19 +0200)]
ARM: avoid alignment related control reg writeouts

Always writing out the same value on ARMv7, no need to..

9 years agoARM: cacheflush: don't round address range up to nearest page
Will Deacon [Tue, 21 Aug 2012 14:33:19 +0000 (15:33 +0100)]
ARM: cacheflush: don't round address range up to nearest page

The flush_cache_user_range macro takes a pair of addresses describing
the start and end of the virtual address range to flush. Due to an
accidental oversight when flush_cache_range_user was introduced, the
address range was rounded up so that the start and end addresses were

For historical reference, the interesting commits in history.git are:

10eacf1775e1 ("[ARM] Clean up ARM cache handling interfaces (part 1)")
71432e79b76b ("[ARM] Add flush_cache_user_page() for sys_cacheflush()")

This patch removes the alignment code, reducing the amount of flushing
required for ranges that are not an exact multiple of PAGE_SIZE.

Reviewed-by: Catalin Marinas <>
Reported-by: Jonathan Austin <>
Signed-off-by: Will Deacon <>
9 years agoomap_overclocking: add support for IVA (DSP) overclocking
Grazvydas Ignotas [Fri, 1 Nov 2013 22:51:00 +0000 (00:51 +0200)]
omap_overclocking: add support for IVA (DSP) overclocking

9 years agocpufreq: OMAP: always use max clock for regulator
Grazvydas Ignotas [Fri, 1 Nov 2013 22:37:46 +0000 (00:37 +0200)]
cpufreq: OMAP: always use max clock for regulator

this allows IVA (the other regulator user) to specify different voltage
range if it needs to. Regulator framework selects lower voltage for the
range intersection automatically.

9 years agoarm: omap3: twl: add iva to vdd1 supplies
Grazvydas Ignotas [Fri, 1 Nov 2013 22:34:15 +0000 (00:34 +0200)]
arm: omap3: twl: add iva to vdd1 supplies

9 years agoOMAP: l3: print out status reg on app errors
Grazvydas Ignotas [Fri, 1 Nov 2013 22:32:22 +0000 (00:32 +0200)]
OMAP: l3: print out status reg on app errors

at least we can know a bit more then