17 Jan, 2015
3 commits
-
Pull arm64 fixes from Will Deacon:
- Wire up compat_sys_execveat for compat (AArch32) tasks
- Revert 421520ba9829, as this breaks our side of the boot protocol* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned"
arm64: compat: wire up compat_sys_execveat -
Pull NFS client bugfixes from Trond Myklebust:
"Highlights include:- Stable fix for a NFSv3/lockd race
- Fixes for several NFSv4.1 client id trunking bugs
- Remove an incorrect test when checking for delegated opens"* tag 'nfs-for-3.19-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
NFSv4: Remove incorrect check in can_open_delegated()
NFS: Ignore transport protocol when detecting server trunking
NFSv4/v4.1: Verify the client owner id during trunking detection
NFSv4: Cache the NFSv4/v4.1 client owner_id in the struct nfs_client
NFSv4.1: Fix client id trunking on Linux
LOCKD: Fix a race when initialising nlmsvc_timeout -
…it/rostedt/linux-trace
Pull ftrace fixes from Steven Rostedt:
"This holds a few fixes to the ftrace infrastructure as well as the
mixture of function graph tracing and kprobes.When jprobes and function graph tracing is enabled at the same time it
will crash the system:# modprobe jprobe_example
# echo function_graph > /sys/kernel/debug/tracing/current_tracerAfter the first fork (jprobe_example probes it), the system will
crash.This is due to the way jprobes copies the stack frame and does not do
a normal function return. This messes up with the function graph
tracing accounting which hijacks the return address from the stack and
replaces it with a hook function. It saves the return addresses in a
separate stack to put back the correct return address when done. But
because the jprobe functions do not do a normal return, their stack
addresses are not put back until the function they probe is called,
which means that the probed function will get the return address of
the jprobe handler instead of its own.The simple fix here was to disable function graph tracing while the
jprobe handler is being called.While debugging this I found two minor bugs with the function graph
tracing.The first was about the function graph tracer sharing its function
hash with the function tracer (they both get filtered by the same
input). The changing of the set_ftrace_filter would not sync the
function recording records after a change if the function tracer was
disabled but the function graph tracer was enabled. This was due to
the update only checking one of the ops instead of the shared ops to
see if they were enabled and should perform the sync. This caused the
ftrace accounting to break and a ftrace_bug() would be triggered,
disabling ftrace until a reboot.The second was that the check to update records only checked one of
the filter hashes. It needs to test both the "filter" and "notrace"
hashes. The "filter" hash determines what functions to trace where as
the "notrace" hash determines what functions not to trace (trace all
but these). Both hashes need to be passed to the update code to find
out what change is being done during the update. This also broke the
ftrace record accounting and triggered a ftrace_bug().This patch set also include two more fixes that were reported
separately from the kprobe issue.One was that init_ftrace_syscalls() was called twice at boot up. This
is not a major bug, but that call performed a rather large kmalloc
(NR_syscalls * sizeof(*syscalls_metadata)). The second call made the
first one a memory leak, and wastes memory.The other fix is a regression caused by an update in the v3.19 merge
window. The moving to enable events early, moved the enabling before
PID 1 was created. The syscall events require setting the
TIF_SYSCALL_TRACEPOINT for all tasks. But for_each_process_thread()
does not include the swapper task (PID 0), and ended up being a nop.A suggested fix was to add the init_task() to have its flag set, but I
didn't really want to mess with PID 0 for this minor bug. Instead I
disable and re-enable events again at early_initcall() where it use to
be enabled. This also handles any other event that might have its own
reg function that could break at early boot up"* tag 'trace-fixes-v3.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix enabling of syscall events on the command line
tracing: Remove extra call to init_ftrace_syscalls()
ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing
ftrace: Check both notrace and filter for old hash
ftrace: Fix updating of filters for shared global_ops filters
16 Jan, 2015
6 commits
-
This patch partially reverts commit 421520ba98290a73b35b7644e877a48f18e06004
(only the arm64 part). There is no guarantee that the boot-loader places other
images like dtb in a different page than initrd start/end, especially when the
kernel is built with 64KB pages. When this happens, such pages must not be
freed. The free_reserved_area() already takes care of rounding up "start" and
rounding down "end" to avoid freeing partially used pages.Cc: # 3.17+
Reported-by: Peter Maydell
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon -
Pull fuse fixes from Miklos Szeredi:
"This fixes a regression in the latest fuse update plus a fix for a
rather theoretical memory ordering issue"* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
fuse: add memory barrier to INIT
fuse: fix LOOKUP vs INIT compat handling -
Pull fbdev fixes from Tomi Valkeinen:
- broadsheetfb: fix memory leak
- simplefb: fix build failure on sparc* tag 'fbdev-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
fbdev/broadsheetfb: fix memory leak
simplefb: Fix build failure on Sparc -
Pull MMC bugfix from Ulf Hansson:
"Fix sdhci regulator regression for Qualcomm and Nvidia boards"* tag 'mmc-v3.19-4' of git://git.linaro.org/people/ulf.hansson/mmc:
mmc: sdhci: Set SDHCI_POWER_ON with external vmmc -
Pull m68k fixlet from Geert Uytterhoeven.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Wire up execveat -
Pull powerpc fixes from Michael Ellerman:
"A few powerpc fixes"* tag 'powerpc-3.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux:
powerpc: Work around gcc bug in current_thread_info()
cxl: Fix issues when unmapping contexts
powernv: Fix OPAL tracepoint code
15 Jan, 2015
21 commits
-
Commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after
rcu_init()" broke the enabling of system call events from the command
line. The reason was that the enabling of command line trace events
was moved before PID 1 started, and the syscall tracepoints require
that all tasks have the TIF_SYSCALL_TRACEPOINT flag set. But the
swapper task (pid 0) is not part of that. Since the swapper task is the
only task that is running at this early in boot, no task gets the
flag set, and the tracepoint never gets reached.Instead of setting the swapper task flag (there should be no reason to
do that), re-enabled trace events again after the init thread (PID 1)
has been started. It requires disabling all command line events and
re-enabling them, as just enabling them again will not reset the logic
to set the TIF_SYSCALL_TRACEPOINT flag, as the syscall tracepoint will
be fooled into thinking that it was already set, and wont try setting
it again. For this reason, we must first disable it and re-enable it.Link: http://lkml.kernel.org/r/1421188517-18312-1-git-send-email-mpe@ellerman.id.au
Link: http://lkml.kernel.org/r/20150115040506.216066449@goodmis.orgReported-by: Michael Ellerman
Signed-off-by: Steven Rostedt -
trace_init() calls init_ftrace_syscalls() and then calls trace_event_init()
which also calls init_ftrace_syscalls(). It makes more sense to only
call it from trace_event_init().Calling it twice wastes memory, as it allocates the syscall events twice,
and loses the first copy of it.Link: http://lkml.kernel.org/r/54AF53BD.5070303@huawei.com
Link: http://lkml.kernel.org/r/20150115040505.930398632@goodmis.orgReported-by: Wang Nan
Signed-off-by: Steven Rostedt -
If the function graph tracer traces a jprobe callback, the system will
crash. This can easily be demonstrated by compiling the jprobe
sample module that is in the kernel tree, loading it and running the
function graph tracer.# modprobe jprobe_example.ko
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# lsThe first two commands end up in a nice crash after the first fork.
(do_fork has a jprobe attached to it, so "ls" just triggers that fork)The problem is caused by the jprobe_return() that all jprobe callbacks
must end with. The way jprobes works is that the function a jprobe
is attached to has a breakpoint placed at the start of it (or it uses
ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
will copy the stack frame and change the ip address to return to the
jprobe handler instead of the function. The jprobe handler must end
with jprobe_return() which swaps the stack and does an int3 (breakpoint).
This breakpoint handler will then put back the saved stack frame,
simulate the instruction at the beginning of the function it added
a breakpoint to, and then continue on.For function tracing to work, it hijakes the return address from the
stack frame, and replaces it with a hook function that will trace
the end of the call. This hook function will restore the return
address of the function call.If the function tracer traces the jprobe handler, the hook function
for that handler will not be called, and its saved return address
will be used for the next function. This will result in a kernel crash.To solve this, pause function tracing before the jprobe handler is called
and unpause it before it returns back to the function it probed.Some other updates:
Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
code look a bit cleaner and easier to understand (various tries to fix
this bug required this change).Note, if fentry is being used, jprobes will change the ip address before
the function graph tracer runs and it will not be able to trace the
function that the jprobe is probing.Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.org
Cc: stable@vger.kernel.org # 2.6.30+
Acked-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt -
Using just the filter for checking for trampolines or regs is not enough
when updating the code against the records that represent all functions.
Both the filter hash and the notrace hash need to be checked.To trigger this bug (using trace-cmd and perf):
# perf probe -a do_fork
# trace-cmd start -B foo -e probe
# trace-cmd record -p function_graph -n do_fork sleep 1The trace-cmd record at the end clears the filter before it disables
function_graph tracing and then that causes the accounting of the
ftrace function records to become incorrect and causes ftrace to bug.Link: http://lkml.kernel.org/r/20150114154329.358378039@goodmis.org
Cc: stable@vger.kernel.org
[ still need to switch old_hash_ops to old_ops_hash ]
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt -
As the set_ftrace_filter affects both the function tracer as well as the
function graph tracer, the ops that represent each have a shared
ftrace_ops_hash structure. This allows both to be updated when the filter
files are updated.But if function graph is enabled and the global_ops (function tracing) ops
is not, then it is possible that the filter could be changed without the
update happening for the function graph ops. This will cause the changes
to not take place and may even cause a ftrace_bug to occur as it could mess
with the trampoline accounting.The solution is to check if the ops uses the shared global_ops filter and
if the ops itself is not enabled, to check if there's another ops that is
enabled and also shares the global_ops filter. In that case, the
modification still needs to be executed.Link: http://lkml.kernel.org/r/20150114154329.055980438@goodmis.org
Cc: stable@vger.kernel.org # 3.17+
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt -
Pull thermal fixes from Zhang Rui:
"Specifics:- bogus type qualifier fix in OF thermal code.
- Minor fixes on imx and rcar thermal drivers.
- Update TI SoC thermal maintainer entry.
- Updated documentation of OF cpufreq cooling register"* 'thermal-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
thermal: rcar: Spelling/grammar: s/drier use .../driver uses ...s/
thermal: rcar: change type of ctemp in rcar_thermal_update_temp()
thermal: rcar: fix ENR register value
Documentation: thermal: document of_cpufreq_cooling_register()
Thermal: imx: add clk disable/enable for suspend/resume
MAINTAINERS: update ti-soc-thermal status
MAINTAINERS: Add linux-omap to list of reviewers for TI Thermal
thermal: of: Remove bogus type qualifier for of_thermal_get_trip_points() -
Pull networking fixes from David Miller:
1) Don't use uninitialized data in IPVS, from Dan Carpenter.
2) conntrack race fixes from Pablo Neira Ayuso.
3) Fix TX hangs with i40e, from Jesse Brandeburg.
4) Fix budget return from poll calls in dnet and alx, from Eric
Dumazet.5) Fix bugus "if (unlikely(x) < 0)" test in AF_PACKET, from Christoph
Jaeger.6) Fix bug introduced by conversion to list_head in TIPC retransmit
code, from Jon Paul Maloy.7) Don't use GFP_NOIO under spinlock in USB kaweth driver, from Alexey
Khoroshilov.8) Fix bridge build with INET disabled, from Arnd Bergmann.
9) Fix netlink array overrun for PROBE attributes in openvswitch, from
Thomas Graf.10) Don't hold spinlock across synchronize_irq() in tg3 driver, from
Prashant Sreedharan.* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (44 commits)
tg3: Release tp->lock before invoking synchronize_irq()
tg3: tg3_reset_task() needs to use rtnl_lock to synchronize
tg3: tg3_timer() should grab tp->lock before checking for tp->irq_sync
team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin
openvswitch: packet messages need their own probe attribtue
i40e: adds FCoE configure option
cxgb4vf: Fix queue allocation for 40G adapter
netdevice: Add missing parentheses in macro
bridge: only provide proxy ARP when CONFIG_INET is enabled
neighbour: fix base_reachable_time(_ms) not effective immediatly when changed
net: fec: fix MDIO bus assignement for dual fec SoC's
xen-netfront: use different locks for Rx and Tx stats
drivers: net: cpsw: fix multicast flush in dual emac mode
cxgb4vf: Initialize mdio_addr before using it
net: Corrected the comment describing the ndo operations to reflect the actual prototype for couple of operations
usb/kaweth: use GFP_ATOMIC under spin_lock in usb_start_wait_urb()
MAINTAINERS: add me as ibmveth maintainer
tipc: fix bug in broadcast retransmit code
update ip-sysctl.txt documentation (v2)
net/at91_ether: prepare and unprepare clock
... -
Prashant Sreedharan says:
====================
tg3: synchronize_irq() should be called without taking locksv2: Added Reported-by, Tested-by fields and reference to the thread that
reported the problemThis series addresses the problem reported by Peter Hurley in mail thread
https://lkml.org/lkml/2015/1/12/1082
====================Signed-off-by: David S. Miller
-
synchronize_irq() can sleep waiting, for pending IRQ handlers so driver
should release the tp->lock spin lock before invoking synchronize_irq()Reported-by: Peter Hurley
Tested-by: Peter Hurley
Signed-off-by: Prashant Sreedharan
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller -
Currently tg3_reset_task() uses only tp->lock for synchronizing with code
paths like tg3_open() etc. But since tp->lock is released before doing
synchronize_irq(), rtnl_lock should be taken in tg3_reset_task() to
synchronize it with other code paths.Reported-by: Peter Hurley
Tested-by: Peter Hurley
Signed-off-by: Prashant Sreedharan
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller -
This is to avoid the race between tg3_timer() and the execution paths
which does not invoke tg3_timer_stop() and releases tp->lock before
calling synchronize_irq()Reported-by: Peter Hurley
Tested-by: Peter Hurley
Signed-off-by: Prashant Sreedharan
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller -
Pull kvm fixes from Paolo Bonzini:
"Two bugfixes for arm64. I will have another pull request next week,
but otherwise things are calm"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
arm64: KVM: Fix HCR setting for 32bit guests
arm64: KVM: Fix TLB invalidation by IPA/VMID -
This patch is fixing a race condition that may cause setting
count_pending to -1, which results in unwanted big bulk of arp messages
(in case of "notify peers").Consider following scenario:
count_pending == 2
CPU0 CPU1
team_notify_peers_work
atomic_dec_and_test (dec count_pending to 1)
schedule_delayed_work
team_notify_peers
atomic_add (adding 1 to count_pending)
team_notify_peers_work
atomic_dec_and_test (dec count_pending to 1)
schedule_delayed_work
team_notify_peers_work
atomic_dec_and_test (dec count_pending to 0)
schedule_delayed_work
team_notify_peers_work
atomic_dec_and_test (dec count_pending to -1)Fix this race by using atomic_dec_if_positive - that will prevent
count_pending running under 0.Fixes: fc423ff00df3a1955441 ("team: add peer notification")
Fixes: 492b200efdd20b8fcfd ("team: add support for sending multicast rejoins")
Signed-off-by: Jiri Pirko
Signed-off-by: Jiri Benc
Signed-off-by: David S. Miller -
Pull s390 fixes from Martin Schwidefsky:
"Two small performance tweaks, the plumbing for the execveat system
call and a couple of bug fixes"* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/uprobes: fix user space PER events
s390/bpf: Fix JMP_JGE_X (A > X) and JMP_JGT_X (A >= X)
s390/bpf: Fix ALU_NEG (A = -A)
s390/mm: avoid using pmd_to_page for !USE_SPLIT_PMD_PTLOCKS
s390/timex: fix get_tod_clock_ext() inline assembly
s390: wire up execveat syscall
s390/kernel: use stnsm 255 instead of stosm 0
s390/vtime: Get rid of redundant WARN_ON
s390/zcrypt: kernel oops at insmod of the z90crypt device driver -
User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
and packet messages. This leads to an out-of-bounds access in
ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
OVS_PACKET_ATTR_MAX.Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
while maintaining to be binary compatible with existing OVS binaries.Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
Reported-by: Sander Eikelenboom
Tracked-down-by: Florian Westphal
Signed-off-by: Thomas Graf
Reviewed-by: Jesse Gross
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller -
Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
as needed but otherwise have it disabled by default.This also eliminate multiple FCoE config checks, instead now just
one config check for CONFIG_I40E_FCOE.The I40E FCoE was added with 3.17 kernel and therefore this patch
shall be applied to stable 3.17 kernel also.CC:
Signed-off-by: Vasu Dev
Tested-by: Jim Young
Signed-off-by: Jeff Kirsher
Signed-off-by: David S. Miller -
Signed-off-by: Hariprasad Shenai
Signed-off-by: David S. Miller -
Pull file locking fix from Jeff Layton:
"Just a simple bugfix for a regression that I introduced into v3.18
with the internal lease API overhaul -- mea culpa. Kudos to Linda and
Neil for tracking this down and fixing it"* tag 'locks-v3.19-1' of git://git.samba.org/jlayton/linux:
locks: fix NULL-deref in generic_delete_lease -
For example, one could conceivably call
for_each_netdev_in_bond_rcu(condition ? bond1 : bond2, slave)
and get an unexpected result.Signed-off-by: Benjamin Poirier
Signed-off-by: David S. Miller -
Pull block layer fixes from Jens Axboe:
"The major part is an update to the NVMe driver, fixing various issues
around surprise removal and hung controllers. Most of that is from
Keith, and parts are simple blk-mq fixes or exports/additions of minor
functions to aid this effort, and parts are changes directly to the
NVMe driver.Apart from the above, this contains:
- Small blk-mq change from me, killing an unused member of the
hardware queue structure.- Small fix from Ming Lei, fixing up a few drivers that didn't
properly check for ERR_PTR() returns from blk_mq_init_queue()"* 'for-linus' of git://git.kernel.dk/linux-block:
NVMe: Fix locking on abort handling
NVMe: Start and stop h/w queues on reset
NVMe: Command abort handling fixes
NVMe: Admin queue removal handling
NVMe: Reference count admin queue usage
NVMe: Start all requests
blk-mq: End unstarted requests on a dying queue
blk-mq: Allow requests to never expire
blk-mq: Add helper to abort requeued requests
blk-mq: Let drivers cancel requeue_work
blk-mq: Export if requests were started
blk-mq: Wake tasks entering queue on dying
blk-mq: get rid of ->cmd_size in the hardware queue
block: fix checking return value of blk_mq_init_queue
block: wake up waiters when a queue is marked dying
NVMe: Fix double free irq
blk-mq: Export freeze/unfreeze functions
blk-mq: Exit queue on alloc failure -
When IPV4 support is disabled, we cannot call arp_send from
the bridge code, which would result in a kernel link error:net/built-in.o: In function `br_handle_frame_finish':
:(.text+0x59914): undefined reference to `arp_send'
:(.text+0x59a50): undefined reference to `arp_tbl'This makes the newly added proxy ARP support in the bridge
code depend on the CONFIG_INET symbol and lets the compiler
optimize the code out to avoid the link error.Signed-off-by: Arnd Bergmann
Fixes: 958501163ddd ("bridge: Add support for IEEE 802.11 Proxy ARP")
Cc: Kyeyoon Park
Signed-off-by: David S. Miller
14 Jan, 2015
10 commits
-
Host controllers lacking the required internal vmmc regulator may still
follow the spec with regard to the LSB of SDHCI_POWER_CONTROL. Set the
SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to
to drive CMD, DAT, SDCLK.This fixes a regression observed on some Qualcomm and Nvidia boards
caused by 5222161 mmc: sdhci: Improve external VDD regulator support.Fixes: 52221610dd84 (mmc: sdhci: Improve external VDD regulator support)
Signed-off-by: Tim Kryger
Tested-by: Bjorn Andersson
Signed-off-by: Ulf Hansson -
…inux-soc-thermal into thermal-soc
-
When setting base_reachable_time or base_reachable_time_ms on a
specific interface through sysctl or netlink, the reachable_time
value is not updated.This means that neighbour entries will continue to be updated using the
old value until it is recomputed in neigh_period_work (which
recomputes the value every 300*HZ).
On systems with HZ equal to 1000 for instance, it means 5mins before
the change is effective.This patch changes this behavior by recomputing reachable_time after
each set on base_reachable_time or base_reachable_time_ms.
The new value will become effective the next time the neighbour's timer
is triggered.Changes are made in two places: the netlink code for set and the sysctl
handling code. For sysctl, I use a proc_handler. The ipv6 network
code does provide its own handler but it already refreshes
reachable_time correctly so it's not an issue.
Any other user of neighbour which provide its own handlers must
refresh reachable_time.Signed-off-by: Jean-Francois Remy
Signed-off-by: David S. Miller -
On i.MX28, the MDIO bus is shared between the two FEC instances.
The driver makes sure that the second FEC uses the MDIO bus of the
first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
is not an option since other logic, triggered by this quirk, is
still needed.Furthermore, there are board designs which use the same MDIO bus
for both PHY's even though the second bus would be available on the
SoC side. Such layout are popular since it saves pins on SoC side.
Due to the above quirk, those boards currently do work fine. The
boards in the mainline tree with such a layout are:
- Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
- Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
makes sure that the MDIO bus of the first FEC is used in any case.However, the boards above do have a SoC with a MDIO bus for each FEC
instance. But the PHY's are not connected in a 1:1 configuration. A
proper device tree description is needed to allow the driver to
figure out where to find its PHY. This patch fixes that shortcoming
by adding a MDIO bus child node to the first FEC instance, along
with the two PHY's on that bus, and making use of the phy-handle
property to add a reference to the PHY's.Acked-by: Sascha Hauer
Signed-off-by: Stefan Agner
Signed-off-by: David S. Miller -
…git/cooloney/linux-leds
Pull LED fix from Bryan Wu.
* 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: netxbig: fix oops at probe time -
Pull WRITE_ONCE argument order change from Christian Borntraeger:
"As discussed on LKML[1] it was agreed that WRITE_ONCE(x, val) is
better than ASSIGN_ONCE(val, x)Lets change that for 3.19 as 3.19 has no user yet, but the first users
will hit linux-next soon"[1] http://marc.info/?l=linux-kernel&m=142081181707596
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux:
kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val) -
In netfront the Rx and Tx path are independent and use different
locks. The Tx lock is held with hard irqs disabled, but Rx lock is
held with only BH disabled. Since both sides use the same stats lock,
a deadlock may occur.[ INFO: possible irq lock inversion dependency detected ]
3.16.2 #16 Not tainted
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
(&(&queue->tx_lock)->rlock){-.....}, at: []
xennet_tx_interrupt+0x14/0x34
but this lock took another, HARDIRQ-unsafe lock in the past:
(&stat->syncp.seq#2){+.-...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:CPU0 CPU1
---- ----
lock(&stat->syncp.seq#2);
local_irq_disable();
lock(&(&queue->tx_lock)->rlock);
lock(&stat->syncp.seq#2);
lock(&(&queue->tx_lock)->rlock);Using separate locks for the Rx and Tx stats fixes this deadlock.
Reported-by: Dmitry Piotrovsky
Signed-off-by: David Vrabel
Signed-off-by: David S. Miller -
Since ALE table is a common resource for both the interfaces in Dual EMAC
mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
all the multicast entries added by the first interface is flushed out and
only second interface multicast addresses are added. Fixing this by
flushing multicast addresses based on dual EMAC port vlans which will not
affect the other emac port multicast addresses.Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface implementation)
Cc: # v3.9+
Signed-off-by: Mugunthan V N
Signed-off-by: David S. Miller -
This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to
this bug, a kernel oops can be observed at probe time on the LaCie 2Big
and 5Big v2 boards:Unable to handle kernel NULL pointer dereference at virtual address 00000008
[...]
[] (netxbig_led_probe) from [] (platform_drv_probe+0x4c/0x9c)
[] (platform_drv_probe) from [] (driver_probe_device+0x98/0x25c)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x68/0x94)
[] (bus_for_each_dev) from [] (bus_add_driver+0x124/0x1dc)
[] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[] (driver_register) from [] (do_one_initcall+0x80/0x1cc)
[] (do_one_initcall) from [] (kernel_init_freeable+0xe4/0x1b4)
[] (kernel_init_freeable) from [] (kernel_init+0xc/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
[...]This bug was introduced by commit 588a6a99286ae30afb1339d8bc2163517b1b7dd1
("leds: netxbig: fix attribute-creation race").Signed-off-by: Simon Guinot
Cc: # 3.17+
Acked-by: Johan Hovold
Signed-off-by: Bryan Wu -
In commit 5ad24def21b205a8 ("cxgb4vf: Fix ethtool get_settings for VF driver")
mdio_addr of port_info structure was used unininitialzed. Fixing it.Signed-off-by: Hariprasad Shenai
Signed-off-by: David S. Miller
