Paul Bolle [Tue, 5 Mar 2013 13:59:23 +0000 (14:59 +0100)]
Change "select DMAR" to "select INTEL_IOMMU"
Commit d3f138106b ("iommu: Rename the DMAR and INTR_REMAP config
options") changed all references to DMAR in Kconfig files to INTEL_IOMMU
(and, likewise, changed the references to CONFIG_DMAR everywhere else
to CONFIG_INTEL_IOMMU). That commit missed one "select DMAR" statement
in ia64's Kconfig file. Change that one too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Tony Luck <tony.luck@intel.com>
The list of output registers is
: "=r"(ret) : "r"(iha), "r"(pte):"memory");
The constraint "=r" means that the GCC has to maintain that these vars
are in registers and contain valid info when the program flow leaves
the assembly block (output registers).
But "=r" also means that GCC can put them in registers that are used
as input registers. Input registers are iha, pte on the example.
If the predicate p7 is true, the 8th assembly instruction
"(p7) mov %0=r0;"
is the first one which writes to a register which is maintained by the
register constraints; it sets %0. %0 means the first register operand;
it is ret here.
This instruction might overwrite the %2 register (pte) which is needed
by the next instruction:
"(p7) st8 [%2]=r9;;"
Whether it really happens depends on how GCC decides what registers it
uses and how it optimizes the code.
The attached patch fixes the register operand constraints in
arch/ia64/kvm/vtlb.c.
The register constraints should be
: "=&r"(ret) : "r"(iha), "r"(pte):"memory");
The & means that GCC must not use any of the input registers to place
this output register in.
This is Debian bug#702639
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702639).
The patch is applicable on Kernel 3.9-rc1, 3.2.35 and many other versions.
Signed-off-by: Stephan Schreiber <info@fs-driver.org> Cc: stable@vger.kernel.org Signed-off-by: Tony Luck <tony.luck@intel.com>
The list of output registers is
: "=r" (r8), "=r" (prev)
The constraint "=r" means that the GCC has to maintain that these vars
are in registers and contain valid info when the program flow leaves
the assembly block (output registers).
But "=r" also means that GCC can put them in registers that are used
as input registers. Input registers are uaddr, newval, oldval on the
example.
The second assembly instruction
" mov %0=r0 \n"
is the first one which writes to a register; it sets %0 to 0. %0 means
the first register operand; it is r8 here. (The r0 is read-only and
always 0 on the Itanium; it can be used if an immediate zero value is
needed.)
This instruction might overwrite one of the other registers which are
still needed.
Whether it really happens depends on how GCC decides what registers it
uses and how it optimizes the code.
The objdump utility can give us disassembly.
The futex_atomic_cmpxchg_inatomic() function is inline, so we have to
look for a module that uses the funtion. This is the
cmpxchg_futex_value_locked() function in
kernel/futex.c:
static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
u32 uval, u32 newval)
{
int ret;
pagefault_disable();
ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval);
pagefault_enable();
return ret;
}
Now the disassembly. At first from the Kernel package 3.2.23 which has
been compiled with GCC 4.4, remeber this Kernel seemed to work:
objdump -d linux-3.2.23/debian/build/build_ia64_none_mckinley/kernel/futex.o
The lines
2b0: 0a 00 00 00 22 00 [MMI] mf;;
2b6: 80 00 00 00 42 00 mov r8=r0
2bc: 00 00 04 00 nop.i 0x0
2c0: 0b 00 20 40 2a 04 [MMI] mov.m ar.ccv=r8;;
2c6: 10 1a 85 22 20 00 cmpxchg4.acq r33=[r33],r35,ar.ccv
2cc: 00 00 04 00 nop.i 0x0;;
are the instructions of the assembly block.
The line
2b6: 80 00 00 00 42 00 mov r8=r0
sets the r8 register to 0 and after that
2c0: 0b 00 20 40 2a 04 [MMI] mov.m ar.ccv=r8;;
prepares the 'oldvalue' for the cmpxchg but it takes it from r8. This
is wrong.
What happened here is what I explained above: An input register is
overwritten which is still needed.
The register operand constraints in futex.h are wrong.
(The problem doesn't occur when the Kernel is compiled with GCC 4.6.)
The attached patch fixes the register operand constraints in futex.h.
The code after patching of it:
static inline int
futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
u32 oldval, u32 newval)
{
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
I also initialized the 'r8' var with the C programming language.
The _asm qualifier on the definition of the 'r8' var forces GCC to use
the r8 processor register for it.
I don't believe that we should use inline assembly for zeroing out a
local variable.
The constraint is
"+r" (r8)
what means that it is both an input register and an output register.
Note that the page fault handler will modify the r8 register which
will be the return value of the function.
The real fix is
"=&r" (prev)
The & means that GCC must not use any of the input registers to place
this output register in.
Patched the Kernel 3.2.23 and compiled it with GCC4.4:
Much better.
There is a
270: 05 40 00 00 00 e1 [MLX] mov r8=r0
which was generated by C code r8 = 0. Below
2b6: 00 10 81 54 08 00 mov.m ar.ccv=r34
what means that oldval is no longer overwritten.
This is Debian bug#702641
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702641).
The patch is applicable on Kernel 3.9-rc1, 3.2.23 and many other versions.
Signed-off-by: Stephan Schreiber <info@fs-driver.org> Cc: stable@vger.kernel.org Signed-off-by: Tony Luck <tony.luck@intel.com>
Hanjun Guo [Fri, 8 Mar 2013 04:33:35 +0000 (12:33 +0800)]
Fix kexec oops when iosapic was removed
Iosapic hotplug was supported in IA64 code, but will lead to kexec oops
when iosapic was removed. here is the code logic:
iosapic_remove
iosapic_free
memset(&iosapic_lists[index], 0, sizeof(iosapic_lists[0]))
iosapic_lists[index].addr was set to 0;
and then kexec a new kernel
kexec_disable_iosapic
iosapic_write(rte->iosapic,..)
__iosapic_write(iosapic->addr, reg, val);
addr was set to 0 when iosapic_remove, and oops happened
Li, Zhen-Hua [Mon, 18 Mar 2013 02:45:43 +0000 (10:45 +0800)]
Add WB/UC check for early_ioremap
On ia64 system, the function early_ioremap returned an uncached memory
reference without checking whether this was consistent with existing
mappings. This causes efi error and the kernel failed during boot. Add a
check to test whether memory has EFI_MEMORY_WB set. Use the function
kern_mem_attribute() in early_iomap() function to provide appropriate
cacheable or uncacheable mapped address.
See the document Documentation/ia64/aliasing.txt for more details.
Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
In particular fsys_getppid always returns the ppid in the initial pid
namespace so it does not work for a process in a pid namespace.
Fix from Eric Biederman just removes the fast system call path.
While it is a little bit sad to see another one of these bite
the dust ... I can't imagine that getppid() is really on any
real applications critical path.
Linus Torvalds [Tue, 19 Mar 2013 22:17:40 +0000 (15:17 -0700)]
Merge tag 'for-linus-v3.9-rc4' of git://oss.sgi.com/xfs/xfs
Pull XFS fixes from Ben Myers:
- Fix for a potential infinite loop which was introduced in commit 4d559a3bcb73 ("xfs: limit speculative prealloc near ENOSPC
thresholds")
- Fix for the return type of xfs_iomap_eof_prealloc_initial_size from
commit a1e16c26660b ("xfs: limit speculative prealloc size on sparse
files")
- Fix for a failed buffer readahead causing subsequent callers to fail
incorrectly
* tag 'for-linus-v3.9-rc4' of git://oss.sgi.com/xfs/xfs:
xfs: ensure we capture IO errors correctly
xfs: fix xfs_iomap_eof_prealloc_initial_size type
xfs: fix potential infinite loop in xfs_iomap_prealloc_size()
Matthew Garrett [Tue, 19 Mar 2013 21:26:57 +0000 (17:26 -0400)]
PCI: Use ROM images from firmware only if no other ROM source available
Mantas Mikulėnas reported that his graphics hardware failed to
initialise after commit f9a37be0f02a ("x86: Use PCI setup data").
The aim of this commit was to ensure that ROM images were available on
some Apple systems that don't expose the GPU ROM via any other source.
In this case, UEFI appears to have provided a broken ROM image that we
were using even though there was a perfectly valid ROM available via
other sources. The simplest way to handle this seems to be to just
re-order pci_map_rom() and leave any firmare-supplied ROM to last.
Linus Torvalds [Tue, 19 Mar 2013 20:56:18 +0000 (13:56 -0700)]
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64
Pull arm64 fixes from Catalin Marinas:
- Fix !SMP build error.
- Fix padding computation in struct ucontext (no ABI change).
- Minor clean-up after the signal patches (unused var).
- Two old Kconfig options clean-up.
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
arm64: Kconfig.debug: Remove unused CONFIG_DEBUG_ERRORS
arm64: Do not select GENERIC_HARDIRQS_NO_DEPRECATED
arm64: fix padding computation in struct ucontext
arm64: Fix build error with !SMP
arm64: Removed unused variable in compat_setup_rt_frame()
Paul Bolle [Tue, 19 Mar 2013 05:58:47 +0000 (05:58 +0000)]
sparc: remove unused "config BITS"
sparc's asm/module.h got removed in commit 786d35d45cc40b2a51a18f73e14e135d47fdced7 ("Make most arch asm/module.h
files use asm-generic/module.h"). That removed the only two uses of this
Kconfig symbol. So we can remove its entry too.
> >From arch/sparc/Makefile:
> ifeq ($(CONFIG_SPARC32),y)
> [...]
>
> [...]
> export BITS := 32
> [...]
>
> else
> [...]
>
> [...]
> export BITS := 64
> [...]
>
> So $(BITS) is set depending on whether CONFIG_SPARC32 is set or not.
> Using $(BITS) in sparc's Makefiles is not using CONFIG_BITS. That
> doesn't count as usage of "config BITS".
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
1) Fix ARM BPF JIT handling of negative 'k' values, from Chen Gang.
2) Insufficient space reserved for bridge netlink values, fix from
Stephen Hemminger.
3) Some dst_neigh_lookup*() callers don't interpret error pointer
correctly, fix from Zhouyi Zhou.
4) Fix transport match in SCTP active_path loops, from Xugeng Zhang.
5) Fix qeth driver handling of multi-order SKB frags, from Frank
Blaschka.
6) fec driver is missing napi_disable() call, resulting in crashes on
unload, from Georg Hofmann.
7) Don't try to handle PMTU events on a listening socket, fix from Eric
Dumazet.
8) Fix timestamp location calculations in IP option processing, from
David Ward.
9) FIB_TABLE_HASHSZ setting is not controlled by the correct kconfig
tests, from Denis V Lunev.
10) Fix TX descriptor push handling in SFC driver, from Ben Hutchings.
11) Fix isdn/hisax and tulip/de4x5 kconfig dependencies, from Arnd
Bergmann.
12) bnx2x statistics don't handle 4GB rollover correctly, fix from
Maciej Żenczykowski.
13) Openvswitch bug fixes for vport del/new error reporting, missing
genlmsg_end() call in netlink processing, and mis-parsing of
LLC/SNAP ethernet types. From Rich Lane.
14) SKB pfmemalloc state should only be propagated from the head page of
a compound page, fix from Pavel Emelyanov.
15) Fix link handling in tg3 driver for 5715 chips when autonegotation
is disabled. From Nithin Sujir.
16) Fix inverted test of cpdma_check_free_tx_desc return value in
davinci_emac driver, from Mugunthan V N.
17) vlan_depth is incorrectly calculated in skb_network_protocol(), from
Li RongQing.
18) Fix probing of Gobi 1K devices in qmi_wwan driver, and fix NCM
device mode backwards compat in cdc_ncm driver. From Bjørn Mork.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (52 commits)
inet: limit length of fragment queue hash table bucket lists
qeth: Fix scatter-gather regression
qeth: Fix invalid router settings handling
qeth: delay feature trace
tcp: dont handle MTU reduction on LISTEN socket
bnx2x: fix occasional statistics off-by-4GB error
vhost/net: fix heads usage of ubuf_info
bridge: Add support for setting BR_ROOT_BLOCK flag.
bnx2x: add missing napi deletion in error path
drivers: net: ethernet: ti: davinci_emac: fix usage of cpdma_check_free_tx_desc()
ethernet/tulip: DE4x5 needs VIRT_TO_BUS
isdn: hisax: netjet requires VIRT_TO_BUS
net: cdc_ncm, cdc_mbim: allow user to prefer NCM for backwards compatibility
rtnetlink: Mask the rta_type when range checking
Revert "ip_gre: make ipgre_tunnel_xmit() not parse network header as IP unconditionally"
Fix dst_neigh_lookup/dst_neigh_lookup_skb return value handling bug
smsc75xx: configuration help incorrectly mentions smsc95xx
net: fec: fix missing napi_disable call
net: fec: restart the FEC when PHY speed changes
skb: Propagate pfmemalloc on skb from head page only
...
Paul Bolle [Tue, 12 Mar 2013 20:35:19 +0000 (21:35 +0100)]
sparc: delete "if !ULTRA_HAS_POPULATION_COUNT"
Commit 2d78d4beb64eb07d50665432867971c481192ebf ("[PATCH] bitops:
sparc64: use generic bitops") made the default of GENERIC_HWEIGHT depend
on !ULTRA_HAS_POPULATION_COUNT. But since there's no Kconfig symbol with
that name, this always evaluates to true. Delete this dependency.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Jonas Gorski [Tue, 19 Mar 2013 13:20:19 +0000 (13:20 +0000)]
Revert "MIPS: BCM63XX: Call board_register_device from device_initcall()"
This commit causes a race between PCI scan and SSB fallback SPROM handler
registration, causing the wifi to not work on slower systems. The only
subsystem touched from board_register_devices is platform device
registration, which is safe as an arch init call.
Florian Fainelli [Mon, 18 Mar 2013 15:56:10 +0000 (15:56 +0000)]
MIPS: Fix code generation for non-DSP capable CPUs
Commit 32a7ede (MIPS: dsp: Add assembler support for DSP ASEs) has
enabled the use of DSP ASE specific instructions such as rddsp and wrdsp
under the idea that all code path that will make use of these two
instructions are properly checking for cpu_has_dsp to ensure that the
particular CPU we are running on *actually* supports DSP ASE.
This commit actually causes the following oops on QEMU Malta emulating a
MIPS 24Kc without the DSP ASE implemented:
The specific line that leads a different assembly being produced is:
unsigned long thread_saved_pc(struct task_struct *tsk)
...
return ((unsigned long *)t->reg29)[schedule_mfi.pc_offset]; <---
The problem here is that the compiler was given the right to use DSP
instructions with the -mdsp / -mdspr2 command-line switches and
performed some optimization for us and used DSP ASE instructions where
we are not checking that the running CPU actually supports DSP ASE.
This patch fixes the issue by partially reverting commit 32a7ede for
arch/mips/kernel/Makefile in order to remove the -mdsp / -mdspr2
compiler command-line switches such that we are now guaranteed that the
compiler will not optimize using DSP ASE reserved instructions. We also
need to fixup the rddsp/wrdsp and m{t,h}{hi,lo}{0,1,2,3} macros in
arch/mips/include/asm/mipsregs.h to tell the assembler that we are going
to explicitely use DSP ASE reserved instructions. The comment in
arch/mips/kernel/Makefile is also updated to reflect that.
Signed-off-by: Florian Fainelli <florian@openwrt.org> Acked-by: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: blogic@openwrt.org Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The Kconfig entry for DEBUG_ERRORS is a verbatim copy of the former arm
entry for that symbol. It got removed in v2.6.39 because it wasn't
actually used anywhere. There are still no users of DEBUG_ERRORS so
remove this entry too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
[catalin.marinas@arm.com: removed option from defconfig] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
inet: limit length of fragment queue hash table bucket lists
This patch introduces a constant limit of the fragment queue hash
table bucket list lengths. Currently the limit 128 is choosen somewhat
arbitrary and just ensures that we can fill up the fragment cache with
empty packets up to the default ip_frag_high_thresh limits. It should
just protect from list iteration eating considerable amounts of cpu.
If we reach the maximum length in one hash bucket a warning is printed.
This is implemented on the caller side of inet_frag_find to distinguish
between the different users of inet_fragment.c.
I dropped the out of memory warning in the ipv4 fragment lookup path,
because we already get a warning by the slab allocator.
Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jesper Dangaard Brouer <jbrouer@redhat.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Raspl [Mon, 18 Mar 2013 20:04:43 +0000 (20:04 +0000)]
qeth: Fix invalid router settings handling
Give a bad return code when specifying a router setting that is either
invalid or not support on the respective device type. In addition, fall back
the previous setting instead of silently switching back to 'no routing'.
Signed-off-by: Stefan Raspl <raspl@linux.vnet.ibm.com> Signed-off-by: Frank Blaschka <blaschka@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Raspl [Mon, 18 Mar 2013 20:04:42 +0000 (20:04 +0000)]
qeth: delay feature trace
Delay tracing of the card features until the optional commands have been
enabled.
Signed-off-by: Stefan Raspl <raspl@linux.vnet.ibm.com> Signed-off-by: Frank Blaschka <blaschka@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Keun-O Park [Mon, 18 Mar 2013 06:32:53 +0000 (07:32 +0100)]
ARM: 7676/1: fix a wrong value returned from CALLER_ADDRn
This makes return_address() return a correct value for CALLER_ADDRn.
To have a correct value from CALLER_ADDRn, we need to fix three points.
* The unwind_frame() does not update frame->lr but frame->pc for backtrace.
So frame->pc is meaningful for backtrace.
* data.level should be adjusted by adding 2 additional iteration levels.
With the current +1 level adjustment, the result of CALLER_ADDR1 will
be the same return address with CALLER_ADDR0.
* The initialization of data.addr to NULL is needed.
When unwind_fame() fails right after data.level reaches zero,
the routine returns data.addr which has uninitialized garbage value.
Signed-off-by: Sahara <keun-o.park@windriver.com> Reviewed-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Heiko Carstens [Thu, 14 Mar 2013 15:46:05 +0000 (16:46 +0100)]
s390/mm: speedup storage key initialization
Use sske with multiple block control to initialize storage keys within
a 1 MB frame at once.
It turned out that the sske with mb=1 is an order of magnitude faster
than pfmf. This is only an issue for very large systems (several 100GB)
where storage key initialization could last more than a minute.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Thu, 14 Mar 2013 12:44:25 +0000 (13:44 +0100)]
s390/dumpstack: fix call chain walking
dumpstack() did not always print a sane callchain when being called.
The reason is that show_trace() accessed register 15 directly to get
the current stack pointer and passed that pointer to __show_trace()
which expects a valid stack frame pointer as argument.
However due to tail call optimization the stack frame may not exist
anymore when __show_trace() gets called and therefore an invalid
stack frame pointer gets passed.
To prevent that disable tail call optimization for call chain walking
functions.
So move all the show_* functions to a dumpstack.c file like other
architectures have it already and add a -fno-optimize-sibling-calls
compile flag to both dumpstack.c and stacktrace.c to prevent tail
call optimization.
s390/cio: make use of newly added format 1 channel-path data
Make use of the stored copy of format 1 channel-path data instead
of querying the information every time the corresponding function
is called.
Reviewed-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/cio: collect format 1 channel-path description data
Collect format 1 channel-path description data for each CHPID
and update the information in one place.
Reviewed-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
To avoid cache synonyms on System zEC12 32 independent zero pages are
required, one for each combination for bits 2**12 to 2**16 of the virtual
address. To avoid wasting too much memory on small virtual systems the
number of zero pages is limited to 4 if the memory size is less or equal
to 64MB.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Jean Delvare [Mon, 18 Mar 2013 20:19:49 +0000 (21:19 +0100)]
hwmon: (lm75.h) Update header inclusion
File lm75.h used to include <linux/hwmon.h> for SENSORS_LIMIT() but
this function is gone by now. Instead we call clamp_val() so we should
include <linux/kernel.h>, where this function is declared.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Jean Delvare [Mon, 18 Mar 2013 20:19:49 +0000 (21:19 +0100)]
MAINTAINERS: Remove Mark M. Hoffman
Mark M. Hoffman stopped working on the Linux kernel several years
ago, so he should no longer be listed as a driver maintainer. I'm not
even sure if his e-mail address still works.
I can take over 3 drivers he was responsible for, the 4th one will
fall down to the subsystem maintainer.
Also give Mark credit for all the good work he did.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: "Mark M. Hoffman" <mhoffman@lightlink.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Cc: Wolfram Sang <wolfram@the-dreams.de>
Jussi Kivilinna [Sun, 17 Mar 2013 09:54:04 +0000 (11:54 +0200)]
rtlwifi: usb: add missing freeing of skbuff
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bing Zhao [Sat, 16 Mar 2013 01:47:07 +0000 (18:47 -0700)]
mwifiex: cancel cmd timer and free curr_cmd in shutdown process
curr_cmd points to the command that is in processing or waiting
for its command response from firmware. If the function shutdown
happens to occur at this time we should cancel the cmd timer and
put the command back to free queue.
Cc: <stable@vger.kernel.org> # 3.8 Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mwifiex_send_cmd_async() is called for sync as well as async
commands. (mwifiex_send_cmd_sync() internally calls it for
sync command.)
"adapter->cmd_queued" gets filled inside mwifiex_send_cmd_async()
routine for both types of commands. But it is used only for sync
commands in mwifiex_wait_queue_complete(). This could lead to a
race when two threads try to queue a sync command with another
sync/async command simultaneously.
Get rid of global variable and pass command node as a parameter
to mwifiex_wait_queue_complete() to fix the problem.
Cc: <stable@vger.kernel.org> # 3.8 Reported-by: Daniel Drake <dsd@laptop.org> Tested-by: Daniel Drake <dsd@laptop.org> Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Fri, 15 Mar 2013 15:18:44 +0000 (16:18 +0100)]
ath9k: limit tx path hang check to normal data queues
The beacon and multicast-buffer queues are managed by the beacon
tasklet, and the generic tx path hang check does not help in any way
here. Running it on those queues anyway can introduce some race
conditions leading to unnecessary chip resets.
Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Fri, 15 Mar 2013 13:53:31 +0000 (14:53 +0100)]
ath9k_hw: revert chainmask to user configuration after calibration
The commit 'ath9k_hw: fix calibration issues on chainmask that don't
include chain 0' changed the hardware chainmask to the chip chainmask
for the duration of the calibration, but the revert to user
configuration in the reset path runs too early.
That causes some issues with limiting the number of antennas (including
spurious failure in hardware-generated packets).
Fix this by reverting the chainmask after the essential parts of the
calibration that need the workaround, and before NF calibration is run.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Reported-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Tested-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Zdenek Kabelac <zkabelac@redhat.com> Reported-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dave Chinner [Tue, 12 Mar 2013 12:30:34 +0000 (23:30 +1100)]
xfs: ensure we capture IO errors correctly
Failed buffer readahead can leave the buffer in the cache marked
with an error. Most callers that then issue a subsequent read on the
buffer do not zero the b_error field out, and so we may incorectly
detect an error during IO completion due to the stale error value
left on the buffer.
Avoid this problem by zeroing the error before IO submission. This
ensures that the only IO errors that are detected those captured
from are those captured from bio submission or completion.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Mark Tinguely <tinguely@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
(cherry picked from commit c163f9a1760229a95d04e37b332de7d5c1c225cd)
Mark Tinguely [Sun, 24 Feb 2013 19:04:37 +0000 (13:04 -0600)]
xfs: fix xfs_iomap_eof_prealloc_initial_size type
Fix the return type of xfs_iomap_eof_prealloc_initial_size() to
xfs_fsblock_t to reflect the fact that the return value may be an
unsigned 64 bits if XFS_BIG_BLKNOS is defined.
Signed-off-by: Mark Tinguely <tinguely@sgi.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Ben Myers <bpm@sgi.com>
(cherry picked from commit e8108cedb1c5d1dc359690d18ca997e97a0061d2)
Brian Foster [Fri, 22 Feb 2013 18:32:56 +0000 (13:32 -0500)]
xfs: fix potential infinite loop in xfs_iomap_prealloc_size()
If freesp == 0, we could end up in an infinite loop while squashing
the preallocation. Break the loop when we've killed the prealloc
entirely.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Ben Myers <bpm@sgi.com>
(cherry picked from commit e78c420bfc2608bb5f9a0b9165b1071c1e31166a)
Eric Dumazet [Mon, 18 Mar 2013 07:01:28 +0000 (07:01 +0000)]
tcp: dont handle MTU reduction on LISTEN socket
When an ICMP ICMP_FRAG_NEEDED (or ICMPV6_PKT_TOOBIG) message finds a
LISTEN socket, and this socket is currently owned by the user, we
set TCP_MTU_REDUCED_DEFERRED flag in listener tsq_flags.
This is bad because if we clone the parent before it had a chance to
clear the flag, the child inherits the tsq_flags value, and next
tcp_release_cb() on the child will decrement sk_refcnt.
Result is that we might free a live TCP socket, as reported by
Dormando.
IPv4: Attempt to release TCP socket in state 1
Fix this issue by testing sk_state against TCP_LISTEN early, so that we
set TCP_MTU_REDUCED_DEFERRED on appropriate sockets (not a LISTEN one)
This bug was introduced in commit 563d34d05786
(tcp: dont drop MTU reduction indications)
Reported-by: dormando <dormando@rydia.net> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The UPDATE_QSTAT function introduced on February 15, 2012
in commit 1355b704b9ba "bnx2x: consistent statistics after
internal driver reload" incorrectly fails to handle overflow
during addition of the lower 32-bit field of a stat.
This bug is present since 3.4-rc1 and should thus be considered
a candidate for stable 3.4+ releases.
Google-Bug-Id: 8374428 Signed-off-by: Maciej Żenczykowski <maze@google.com> Cc: Mintz Yuval <yuvalmin@broadcom.com> Acked-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Mon, 18 Mar 2013 15:27:41 +0000 (08:27 -0700)]
Merge tag 'for-linus-20130318' of git://git.infradead.org/linux-mtd
Pull MTD fixes from David Woodhouse:
"This fixes a couple of problems. Firstly, some people are actually
still using old small-page flash and we broke it by removing the ready
check.
Secondly. fix the handling of partitions on Broadcom 47xx devices.
Recent changes had made it misdetect the location of the NVRAM and
scribble over the bootloader when it tried to update the variables
there. With predictably sad results."
* tag 'for-linus-20130318' of git://git.infradead.org/linux-mtd:
mtd: nand: reintroduce NAND_NO_READRDY as NAND_NEED_READRDY
mtd: bcm47xxpart: look for NVRAM at the end of device
Revert "mtd: bcm47xxpart: improve probing of nvram partition"
Dmitry Torokhov [Mon, 25 Feb 2013 18:56:01 +0000 (10:56 -0800)]
USB: xhci - fix bit definitions for IMAN register
According to XHCI specification (5.5.2.1) the IP is bit 0 and IE is bit 1
of IMAN register. Previously their definitions were reversed.
Even though there are no ill effects being observed from the swapped
definitions (because IMAN_IP is RW1C and in legacy PCI case we come in
with it already set to 1 so it was clearing itself even though we were
setting IMAN_IE instead of IMAN_IP), we should still correct the values.
This patch should be backported to kernels as old as 2.6.36, that
contain the commit 4e833c0b87a30798e67f06120cecebef6ee9644c "xhci: don't
re-enable IE constantly".
Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Linus Torvalds [Mon, 18 Mar 2013 15:19:13 +0000 (08:19 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"A couple of bug fixes, the most hairy on is the flush_tlb_kernel_range
fix. Another case of "how could this ever have worked?"."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/kdump: Do not add standby memory for kdump
drivers/i2c: remove !S390 dependency, add missing GENERIC_HARDIRQS dependencies
s390/scm: process availability
s390/scm_blk: suspend writes
s390/scm_drv: extend notify callback
s390/scm_blk: fix request number accounting
s390/mm: fix flush_tlb_kernel_range()
s390/mm: fix vmemmap size calculation
s390: critical section cleanup vs. machine checks
Linus Torvalds [Mon, 18 Mar 2013 15:17:14 +0000 (08:17 -0700)]
Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC bug fixes from Arnd Bergmann:
"Things are calming down for arm-soc as well. This set of bug fixes is
dominated in size by the at91 platform bug fixes. Some of them were
meant to go through the framebuffer tree during the merge window, but
since the framebuffer maintainer could not be reached, I offered to
take them here. The other notable at91 change is the addition of
pinctrl definitions to fix the NAND controller.
The rest are mostly simple regression fixes:
- Our removal of VIRT_TO_BUS conflicted with Stephen Rothwell's
renaming of the Kconfig symbol. You will get a trivial merge
conflict here, we still want to remove it.
- missing bits for clocks on imx and s5pv210
- missing header inclusions in mmp and shmobile
- typos in s5pv210 camera and vt8500 clock support code
and three trivial fixes for pre-3.8 bugs:
- an old bogus build warning in the joystick driver
- a misleading Kconfig description
- a NULL pointer check on davinci"
* tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: fix CONFIG_VIRT_TO_BUS handling
ARM: i.MX35: enable MAX clock
ARM: Scorpion is a v7 architecture, not v6
ARM: mmp: add platform_device head file in gplugd
input/joystick: use get_cycles on ARM
[media] s5p-fimc: fix s5pv210 build
clk: vt8500: Fix "fix device clock divisor calculations"
ARM: i.MX25: Fix DT compilation
ARM: at91: fix infinite loop in at91_irq_suspend/resume
ARM: at91: add gpio suspend/resume support when using pinctrl
ARM: at91: fix LCD-wiring mode
atmel_lcdfb: fix 16-bpp modes on older SOCs
ARM: at91: dt: at91sam9x5: complete NAND pinctrl
ARM: at91: dt: at91sam9x5: correct NAND pins comments
ARM: davinci: edma: fix dmaengine induced null pointer dereference on da830
ARM: shmobile: marzen: Include mmc/host.h
ARM: EXYNOS: Add #dma-cells for generic dma binding support for PL330
ARM: S5PV210: Fix PL330 DMA controller clkdev entries
Linus Torvalds [Mon, 18 Mar 2013 15:12:41 +0000 (08:12 -0700)]
Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc fixes from Ben Herrenschmidt:
"Here's a few powerpc fixes for 3.9, mostly regressions (though not all
from 3.9 merge window) that we've been hammering into shape over the
last couple of weeks. They fix booting on Cell and G5 among other
things (yes, we've been a bit sloppy with older machines this time
around)."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Rename USER_ESID_BITS* to ESID_BITS*
powerpc: Update kernel VSID range
powerpc: Make VSID_BITS* dependency explicit
powerpc: Make sure that we alays include CONFIG_BINFMT_ELF
powerpc/ptrace: Fix brk.len used uninitialised
powerpc: Fix -mcmodel=medium breakage in prom_init.c
powerpc: Remove last traces of POWER4_ONLY
powerpc: Fix cputable entry for 970MP rev 1.0
powerpc: Fix STAB initialization
Linus Torvalds [Mon, 18 Mar 2013 15:11:53 +0000 (08:11 -0700)]
Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm
Pull ARM fixes from Russell King:
"Just three fixes this time - a fix for a fix for our memset function,
fixing the dummy clockevent so that it doesn't interfere with real
hardware clockevents, and fixing a build error for Tegra."
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7675/1: amba: tegra-ahb: Fix build error w/ PM_SLEEP w/o PM_RUNTIME
ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event
ARM: 7670/1: fix the memset fix
Arnd Bergmann [Wed, 13 Mar 2013 16:36:37 +0000 (17:36 +0100)]
ARM: fix CONFIG_VIRT_TO_BUS handling
887cbce0 "arch Kconfig: centralise CONFIG_ARCH_NO_VIRT_TO_BUS"
and 4febd95a8 "Select VIRT_TO_BUS directly where needed" from
Stephen Rothwell changed globally how CONFIG_VIRT_TO_BUS is
selected, while my own a5d533ee0 "ARM: disable virt_to_bus/
virt_to_bus almost everywhere" was merged at the same time and
changed which platforms select it on ARM.
The result of this conflict was that we again see CONFIG_VIRT_TO_BUS
on all ARM systems. This patch fixes up the problem and removes
CONFIG_ARCH_NO_VIRT_TO_BUS again on ARM.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
projects / karo-tx-linux.git / log