aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-03-07powerpc: Align p_dyn, p_rela and p_st symbolsAnton Blanchard1-0/+1
The 64bit relocation code places a few symbols in the text segment. These symbols are only 4 byte aligned where they need to be 8 byte aligned. Add an explicit alignment. Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] Tested-by: Laurent Dufour <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2014-03-07powerpc/tm: Fix crash when forking inside a transactionMichael Neuling1-0/+9
When we fork/clone we currently don't copy any of the TM state to the new thread. This results in a TM bad thing (program check) when the new process is switched in as the kernel does a tmrechkpt with TEXASR FS not set. Also, since R1 is from userspace, we trigger the bad kernel stack pointer detection. So we end up with something like this: Bad kernel stack pointer 0 at c0000000000404fc cpu 0x2: Vector: 700 (Program Check) at [c00000003ffefd40] pc: c0000000000404fc: restore_gprs+0xc0/0x148 lr: 0000000000000000 sp: 0 msr: 9000000100201030 current = 0xc000001dd1417c30 paca = 0xc00000000fe00800 softe: 0 irq_happened: 0x01 pid = 0, comm = swapper/2 WARNING: exception is not recoverable, can't continue The below fixes this by flushing the TM state before we copy the task_struct to the clone. To do this we go through the tmreclaim patch, which removes the checkpointed registers from the CPU and transitions the CPU out of TM suspend mode. Hence we need to call tmrechkpt after to restore the checkpointed state and the TM mode for the current task. To make this fail from userspace is simply: tbegin li r0, 2 sc <boom> Kudos to Adhemerval Zanella Neto for finding this. Signed-off-by: Michael Neuling <[email protected]> cc: Adhemerval Zanella Neto <[email protected]> cc: [email protected] Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2014-03-07Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie1-1/+1
into drm-fixes one more radeon fix. * 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/atom: select the proper number of lanes in transmitter setup
2014-03-06drm/radeon/atom: select the proper number of lanes in transmitter setupAlex Deucher1-1/+1
We need to check for DVI vs. HDMI when setting up duallink since HDMI is single link only. Fixes 4k modes on newer asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75223 Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2014-03-07MAINTAINERS: add maintainer entry for TDA998x driverRussell King1-0/+6
Add a maintainers entry for the TDA998x driver. Rob Clark has handed this driver over to me to look after. Acked-by: Rob Clark <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2014-03-07drm: fix bochs kconfig dependenciesGerd Hoffmann1-0/+1
Signed-off-by: Gerd Hoffmann <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2014-03-07Merge branch 'drm-armada-fixes' of ↵Dave Airlie1-9/+1
git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-fixes fix for kfifo api change. * 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox: DRM: armada: fix use of kfifo_put()
2014-03-07Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie17-26/+22
into drm-fixes a few more radeon fixes. * 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters drm/radeon/cik: fix typo in documentation drm/radeon: silence GCC warning on 32 bit drm/radeon: resume old pm late drm/radeon: TTM must be init with cpu-visible VRAM, v2
2014-03-06ipv6: don't set DST_NOCOUNT for remotely added routesSabrina Dubroca1-1/+1
DST_NOCOUNT should only be used if an authorized user adds routes locally. In case of routes which are added on behalf of router advertisments this flag must not get used as it allows an unlimited number of routes getting added remotely. Signed-off-by: Sabrina Dubroca <[email protected]> Acked-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06net/mlx4_core: mlx4_init_slave() shouldn't access comm channel before PF is ↵Amir Vadai1-0/+11
ready Currently, the PF call to pci_enable_sriov from the PF probe function stalls for 10 seconds times the number of VFs probed on the host. This happens because the way for such VFs to determine of the PF initialization finished, is by attempting to issue reset on the comm-channel and get timeout (after 10s). The PF probe function is called from a kenernel workqueue, and therefore during that time, rcu lock is being held and kernel's workqueue is stalled. This blocks other processes that try to use the workqueue or rcu lock. For example, interface renaming which is calling rcu_synchronize is blocked, and timedout by systemd. Changed mlx4_init_slave() to allow VF probed on the host to immediatly detect that the PF is not ready, and return EPROBE_DEFER instantly. Only when the PF finishes the initialization, allow such VFs to access the comm channel. This issue and fix are relevant only for probed VFs on the hypervisor, there is no way to pass this information to a VM until comm channel is ready, so in a VM, if PF is not ready, the first command will be timedout after 10 seconds and return EPROBE_DEFER. Signed-off-by: Amir Vadai <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06net/mlx4_core: Fix memory access error in mlx4_QUERY_DEV_CAP_wrapper()Amir Vadai1-3/+3
Fix a regression introduced by [1]. outbox was accessed instead of outbox->buf. Typo was copy-pasted to [2] and [3]. [1] - cc1ade9 mlx4_core: Disable memory windows for virtual functions [2] - 4de6580 mlx4_core: Add support for steerable IB UD QPs [3] - 7ffdf72 net/mlx4_core: Add basic support for TCP/IP offloads under tunneling Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Amir Vadai <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06bonding: correctly handle out of range parameters for lp_intervalSasha Levin1-0/+1
We didn't correctly check cases where the value for lp_interval is not within the legal range due to a missing table terminator. This would let userspace trigger a kernel panic by specifying a value out of range: echo -1 > /sys/devices/virtual/net/bond0/bonding/lp_interval Introduced by commit 4325b374f84 ("bonding: convert lp_interval to use the new option API"). Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegistersAlex Deucher1-1/+1
Should be at 0x8 rather than 0. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60523 Noticed by ArtForz on #radeon Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2014-03-06drm/radeon/cik: fix typo in documentationAlex Deucher1-1/+1
Copy-paste typo. Signed-off-by: Alex Deucher <[email protected]>
2014-03-06drm/radeon: silence GCC warning on 32 bitPaul Bolle1-1/+1
Building radeon_ttm.o on 32 bit x86 triggers a warning: In file included from include/asm-generic/bug.h:13:0, from [...]/arch/x86/include/asm/bug.h:38, from include/linux/bug.h:4, from include/drm/drm_mm.h:39, from include/drm/drm_vma_manager.h:26, from include/drm/ttm/ttm_bo_api.h:35, from drivers/gpu/drm/radeon/radeon_ttm.c:32: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read': include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default] (void) (&_min1 == &_min2); \ ^ drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min' ssize_t cur_size = min(size, PAGE_SIZE - off); ^ Silence this warning by using min_t(). Since cur_size will never be negative and its upper bound is PAGE_SIZE, we can change its type to size_t and use min_t(size_t, [...]) here. Signed-off-by: Paul Bolle <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]>
2014-03-06drm/radeon: resume old pm lateAlex Deucher15-23/+16
Moving the pm resume up in the init order to fix dpm seems to have regressed somes cases with the old pm code. Move it back to late resume. Signed-off-by: Alex Deucher <[email protected]>
2014-03-06drm/radeon: TTM must be init with cpu-visible VRAM, v2Lauri Kasanen1-0/+3
Without this, a bo may get created in the cpu-inaccessible vram. Before the CP engines get setup, all copies are done via cpu memcpy. This means that the cpu tries to read from inaccessible memory, fails, and the radeon module proceeds to disable acceleration. Doing this has no downsides, as the real VRAM size gets set as soon as the CP engines get init. This is a candidate for 3.14 fixes. v2: Add comment on why the function is used Signed-off-by: Lauri Kasanen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Cc: [email protected]
2014-03-06ipv6: Fix exthdrs offload registration.Anton Nayshtut1-2/+2
Without this fix, ipv6_exthdrs_offload_init doesn't register IPPROTO_DSTOPTS offload, but returns 0 (as the IPPROTO_ROUTING registration actually succeeds). This then causes the ipv6_gso_segment to drop IPv6 packets with IPPROTO_DSTOPTS header. The issue detected and the fix verified by running MS HCK Offload LSO test on top of QEMU Windows guests, as this test sends IPv6 packets with IPPROTO_DSTOPTS. Signed-off-by: Anton Nayshtut <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06sparc: serial: Clean up the locking for -rtDavid Miller4-39/+25
Signed-off-by: David S. Miller <[email protected]> Tested-by: Allen Pais <[email protected]>
2014-03-06ibmveth: Fix endian issues with MAC addressesAnton Blanchard2-10/+16
The code to load a MAC address into a u64 for passing to the hypervisor via a register is broken on little endian. Create a helper function called ibmveth_encode_mac_addr which does the right thing in both big and little endian. We were storing the MAC address in a long in struct ibmveth_adapter. It's never used so remove it - we don't need another place in the driver where we create endian issues with MAC addresses. Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]>
2014-03-06net: unix socket code abuses csum_partialAnton Blanchard1-2/+1
The unix socket code is using the result of csum_partial to hash into a lookup table: unix_hash_fold(csum_partial(sunaddr, len, 0)); csum_partial is only guaranteed to produce something that can be folded into a checksum, as its prototype explains: * returns a 32-bit number suitable for feeding into itself * or csum_tcpudp_magic The 32bit value should not be used directly. Depending on the alignment, the ppc64 csum_partial will return different 32bit partial checksums that will fold into the same 16bit checksum. This difference causes the following testcase (courtesy of Gustavo) to sometimes fail: #include <sys/socket.h> #include <stdio.h> int main() { int fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0); int i = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &i, 4); struct sockaddr addr; addr.sa_family = AF_LOCAL; bind(fd, &addr, 2); listen(fd, 128); struct sockaddr_storage ss; socklen_t sslen = (socklen_t)sizeof(ss); getsockname(fd, (struct sockaddr*)&ss, &sslen); fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0); if (connect(fd, (struct sockaddr*)&ss, sslen) == -1){ perror(NULL); return 1; } printf("OK\n"); return 0; } As suggested by davem, fix this by using csum_fold to fold the partial 32bit checksum into a 16bit checksum before using it. Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]>
2014-03-06net: Improve SO_TIMESTAMPING documentation and fix a minor code bugAndrew Lutomirski2-21/+32
The original documentation was very unclear. The code fix is presumably related to the formerly unclear documentation: SOCK_TIMESTAMPING_RX_SOFTWARE has no effect on __sock_recv_timestamp's behavior, so calling __sock_recv_ts_and_drops from sock_recv_ts_and_drops if only SOCK_TIMESTAMPING_RX_SOFTWARE is set is pointless. This should have no user-observable effect. Signed-off-by: Andy Lutomirski <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06phy: fix compiler array bounds warning on settings[]Bjorn Helgaas1-5/+6
With -Werror=array-bounds, gcc v4.7.x warns that in phy_find_valid(), the settings[] "array subscript is above array bounds", I think because idx is a signed integer and if the caller supplied idx < 0, we pass the guard but still reference out of bounds. Fix this by making idx unsigned here and elsewhere. Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06firewire: ohci: fix probe failure with Agere/LSI controllersStefan Richter1-13/+2
Since commit bd972688eb24 "firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8", there is a high chance that firewire-ohci fails to initialize LSI née Agere controllers. https://bugzilla.kernel.org/show_bug.cgi?id=65151 Peter Hurley points out the reason: IEEE 1394a:2000 clause 5A.1 (or IEEE 1394:2008 clause 17.2.1) say: "The PHY shall insure that no more than 10 ms elapse from the reassertion of LPS until the interface is reset. The link shall not assert LReq until the reset is complete." In other words, the link needs to give the PHY at least 10 ms to get the interface operational. With just the msleep(1) in bd972688eb24, the first read_phy_reg() during ohci_enable() may happen before the phy-link interface reset was finished, and fail. Due to the high variability of msleep(n) with small n, this failure was not fully reproducible, and not apparent at all with low CONFIG_HZ setting. On the other hand, Peter can no longer reproduce the issue with FW643 rev8. The read phy reg failures that happened back then may have had an unrelated cause. So, just revert bd972688eb24, except for the valid comment on TSB82AA2 cards. Reported-by: Mikhail Gavrilov Reported-by: Jay Fenlason <[email protected]> Reported-by: Clemens Ladisch <[email protected]> Reported-by: Peter Hurley <[email protected]> Cc: [email protected] # v3.10+ Signed-off-by: Stefan Richter <[email protected]>
2014-03-06inet: frag: make sure forced eviction removes all fragsFlorian Westphal1-1/+1
Quoting Alexander Aring: While fragmentation and unloading of 6lowpan module I got this kernel Oops after few seconds: BUG: unable to handle kernel paging request at f88bbc30 [..] Modules linked in: ipv6 [last unloaded: 6lowpan] Call Trace: [<c012af4c>] ? call_timer_fn+0x54/0xb3 [<c012aef8>] ? process_timeout+0xa/0xa [<c012b66b>] run_timer_softirq+0x140/0x15f Problem is that incomplete frags are still around after unload; when their frag expire timer fires, we get crash. When a netns is removed (also done when unloading module), inet_frag calls the evictor with 'force' argument to purge remaining frags. The evictor loop terminates when accounted memory ('work') drops to 0 or the lru-list becomes empty. However, the mem accounting is done via percpu counters and may not be accurate, i.e. loop may terminate prematurely. Alter evictor to only stop once the lru list is empty when force is requested. Reported-by: Phoebe Buckheister <[email protected]> Reported-by: Alexander Aring <[email protected]> Tested-by: Alexander Aring <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06MIPS: APRP: Choose the correct VPE loader by fixing the linkingDeng-Cheng Zhu1-1/+1
Now we have CONFIG_MIPS_VPE_LOADER and CONFIG_MIPS_VPE_LOADER_[CMP|MT]. The latter two are used by the 2 exclusive flavors. The vpe_run in malta-amon.c is for CMP APRP. Without the fix, this vpe_run will be used in MT APRP. Reviewed-by: Steven J. Hill <[email protected]> Signed-off-by: Deng-Cheng Zhu <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6589/ Signed-off-by: Ralf Baechle <[email protected]>
2014-03-06MIPS: APRP: Unregister rtlx interrupt hook at module exitDeng-Cheng Zhu2-0/+6
If the aprp_hook is not assigned back to NULL, it will still be called after module exits. This is not wanted. Reviewed-by: Steven J. Hill <[email protected]> Signed-off-by: Deng-Cheng Zhu <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6590/ Signed-off-by: Ralf Baechle <[email protected]>
2014-03-06MIPS: APRP: Fix the linking of rtlx interrupt hookDeng-Cheng Zhu1-2/+2
There are 2 errors with the existing aprp_hook linking: - The prefix CONFIG_ is missing; - The hook should be linked exclusively in the cases of MT and CMP. Signed-off-by: Deng-Cheng Zhu <[email protected]> Reviewed-by: Steven J. Hill <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6588/ Signed-off-by: Ralf Baechle <[email protected]>
2014-03-06MIPS: bcm47xx: Include missing errno.h for ENXIOMarkos Chandras1-0/+1
Fixes the following build problen on allmodconfig: arch/mips/bcm47xx/board.c: In function 'bcm47xx_board_detect': arch/mips/bcm47xx/board.c:291:14: error: 'ENXIO' undeclared (first use in this function) Signed-off-by: Markos Chandras <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6571/ Signed-off-by: Ralf Baechle <[email protected]>
2014-03-06MIPS: Alchemy: Fix unchecked kstrtoul return valueManuel Lauss2-6/+2
enabled __must_check logic triggers a build error for mtx1 and gpr in the prom init code. Fix by checking the kstrtoul() return value. Signed-off-by: Manuel Lauss <[email protected]> Cc: Linux-MIPS <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/6574/ Signed-off-by: Ralf Baechle <[email protected]>
2014-03-06MIPS: Fix randconfig build error.Ralf Baechle1-0/+3
CC arch/mips/kernel/ptrace.o In file included from arch/mips/kernel/ptrace.c:42:0: arch/mips/kernel/ptrace.c: In function ‘mips_get_syscall_arg’: /home/ralf/src/linux/linux-mips/arch/mips/include/asm/syscall.h:60:1: error: control reaches end of non-void function [-Werror=return-type] cc1: all warnings being treated as errors make[2]: *** [arch/mips/kernel/ptrace.o] Error 1 make[1]: *** [arch/mips/kernel] Error 2 make: *** [arch/mips] Error 2 Fixed by marking the end of mips_get_syscall_arg() as unreachable. Signed-off-by: Ralf Baechle <[email protected]>
2014-03-06Merge branch 'tipc'David S. Miller6-37/+47
Eric Hugne says: ==================== tipc: refcount and memory leak fixes v3: Remove error logging from data path completely. Rebased on top of latest net merge. v2: Drop specific -ENOMEM logging in patch #1 (tipc: allow connection shutdown callback to be invoked in advance) And add a general error message if an internal server tries to send a message on a closed/nonexisting connection. In addition to the fix for refcount leak and memory leak during module removal, we also fix a problem where the topology server listening socket where unexpectedly closed. We also eliminate an unnecessary context switch during accept()/recvmsg() for nonblocking sockets. It might be good to include this patchset in stable aswell. After the v3 rebase on latest merge from net all patches apply cleanly on that tree. ==================== Signed-off-by: David S. Miller <[email protected]>
2014-03-06tipc: don't log disabled tasklet handler errorsErik Hugne1-1/+0
Failure to schedule a TIPC tasklet with tipc_k_signal because the tasklet handler is disabled is not an error. It means TIPC is currently in the process of shutting down. We remove the error logging in this case. Signed-off-by: Erik Hugne <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06tipc: fix memory leak during module removalErik Hugne1-3/+34
When the TIPC module is removed, the tasklet handler is disabled before all other subsystems. This will cause lingering publications in the name table because the node_down tasklets responsible to clean up publications from an unreachable node will never run. When the name table is shut down, these publications are detected and an error message is logged: tipc: nametbl_stop(): orphaned hash chain detected This is actually a memory leak, introduced with commit 993b858e37b3120ee76d9957a901cca22312ffaa ("tipc: correct the order of stopping services at rmmod") Instead of just logging an error and leaking memory, we free the orphaned entries during nametable shutdown. Signed-off-by: Erik Hugne <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06tipc: drop subscriber connection id invalidationErik Hugne1-11/+0
When a topology server subscriber is disconnected, the associated connection id is set to zero. A check vs zero is then done in the subscription timeout function to see if the subscriber have been shut down. This is unnecessary, because all subscription timers will be cancelled when a subscriber terminates. Setting the connection id to zero is actually harmful because id zero is the identity of the topology server listening socket, and can cause a race that leads to this socket being closed instead. Signed-off-by: Erik Hugne <[email protected]> Acked-by: Ying Xue <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06tipc: avoid to unnecessary process switch under non-block modeYing Xue1-2/+2
When messages are received via tipc socket under non-block mode, schedule_timeout() is called in tipc_wait_for_rcvmsg(), that is, the process of receiving messages will be scheduled once although timeout value passed to schedule_timeout() is 0. The same issue exists in accept()/wait_for_accept(). To avoid this unnecessary process switch, we only call schedule_timeout() if the timeout value is non-zero. Signed-off-by: Ying Xue <[email protected]> Reviewed-by: Erik Hugne <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06tipc: fix connection refcount leakYing Xue1-2/+4
When tipc_conn_sendmsg() calls tipc_conn_lookup() to query a connection instance, its reference count value is increased if it's found. But subsequently if it's found that the connection is closed, the work of sending message is not queued into its server send workqueue, and the connection reference count is not decreased. This will cause a reference count leak. To reproduce this problem, an application would need to open and closes topology server connections with high intensity. We fix this by immediately decrementing the connection reference count if a send fails due to the connection being closed. Signed-off-by: Ying Xue <[email protected]> Acked-by: Erik Hugne <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06tipc: allow connection shutdown callback to be invoked in advanceYing Xue3-18/+7
Currently connection shutdown callback function is called when connection instance is released in tipc_conn_kref_release(), and receiving packets and sending packets are running in different threads. Even if connection is closed by the thread of receiving packets, its shutdown callback may not be called immediately as the connection reference count is non-zero at that moment. So, although the connection is shut down by the thread of receiving packets, the thread of sending packets doesn't know it. Before its shutdown callback is invoked to tell the sending thread its connection has been closed, the sending thread may deliver messages by tipc_conn_sendmsg(), this is why the following error information appears: "Sending subscription event failed, no memory" To eliminate it, allow connection shutdown callback function to be called before connection id is removed in tipc_close_conn(), which makes the sending thread know the truth in time that its socket is closed so that it doesn't send message to it. We also remove the "Sending XXX failed..." error reporting for topology and config services. Signed-off-by: Ying Xue <[email protected]> Signed-off-by: Erik Hugne <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06l2tp: fix userspace reception on plain L2TP socketsGuillaume Nault1-5/+7
As pppol2tp_recv() never queues up packets to plain L2TP sockets, pppol2tp_recvmsg() never returns data to userspace, thus making the recv*() system calls unusable. Instead of dropping packets when the L2TP socket isn't bound to a PPP channel, this patch adds them to its reception queue. Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06l2tp: fix manual sequencing (de)activation in L2TPv2Guillaume Nault4-3/+7
Commit e0d4435f "l2tp: Update PPP-over-L2TP driver to work over L2TPv3" broke the PPPOL2TP_SO_SENDSEQ setsockopt. The L2TP header length was previously computed by pppol2tp_l2t_header_len() before each call to l2tp_xmit_skb(). Now that header length is retrieved from the hdr_len session field, this field must be updated every time the L2TP header format is modified, or l2tp_xmit_skb() won't push the right amount of data for the L2TP header. This patch uses l2tp_session_set_header_len() to adjust hdr_len every time sequencing is (de)activated from userspace (either by the PPPOL2TP_SO_SENDSEQ setsockopt or the L2TP_ATTR_SEND_SEQ netlink attribute). Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-03-06dm thin: fix Documentation for held metadata root featureMike Snitzer1-3/+2
The Documentation for the thin provisioning target's held metadata root feature was incorrect. It is now available and the value for the held metadata root is in block units (not 512b sectors). Signed-off-by: Mike Snitzer <[email protected]>
2014-03-06x86, trace: Further robustify CR2 handling vs tracingPeter Zijlstra1-10/+23
Building on commit 0ac09f9f8cd1 ("x86, trace: Fix CR2 corruption when tracing page faults") this patch addresses another few issues: - Now that read_cr2() is lifted into trace_do_page_fault(), we should pass the address to trace_page_fault_entries() to avoid it re-reading a potentially changed cr2. - Put both trace_do_page_fault() and trace_page_fault_entries() under CONFIG_TRACING. - Mark both fault entry functions {,trace_}do_page_fault() as notrace to avoid getting __mcount or other function entry trace callbacks before we've observed CR2. - Mark __do_page_fault() as noinline to guarantee the function tracer does get to see the fault. Cc: <[email protected]> Cc: <[email protected]> Acked-by: Steven Rostedt <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: H. Peter Anvin <[email protected]>
2014-03-06mwifiex: save and copy AP's VHT capability info correctlyAmitkumar Karwar2-6/+5
While preparing association request, intersection of device's VHT capability information and corresponding field advertised by AP is used. This patch fixes a couple errors while saving and copying vht_cap and vht_oper fields from AP's beacon. Cc: <[email protected]> # 3.9+ Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2014-03-06mwifiex: copy AP's HT capability info correctlyAmitkumar Karwar1-2/+1
While preparing association request, intersection of device's HT capability information and corresponding fields advertised by AP is used. This patch fixes an error while copying this field from AP's beacon. Cc: <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2014-03-06Merge branch 'for-john' of ↵John W. Linville4-2/+8
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
2014-03-06ACPI / EC: Clear stale EC events on Samsung systemsKieran Clancy1-0/+64
A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) continue to log events during sleep (lid open/close, AC plug/unplug, battery level change), which accumulate in the EC until a buffer fills. After the buffer is full (tests suggest it holds 8 events), GPEs stop being triggered for new events. This state persists on wake or even on power cycle, and prevents new events from being registered until the EC is manually polled. This is the root cause of a number of bugs, including AC not being detected properly, lid close not triggering suspend, and low ambient light not triggering the keyboard backlight. The bug also seemed to be responsible for performance issues on at least one user's machine. Juan Manuel Cabo found the cause of bug and the workaround of polling the EC manually on wake. The loop which clears the stale events is based on an earlier patch by Lan Tianyu (see referenced attachment). This patch: - Adds a function acpi_ec_clear() which polls the EC for stale _Q events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is logged if this limit is reached. - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI system vendor is Samsung. This check could be replaced by several more specific DMI vendor/product pairs, but it's likely that the bug affects more Samsung products than just the five series mentioned above. Further, it should not be harmful to run acpi_ec_clear() on systems without the bug; it will return immediately after finding no data waiting. - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 References: https://bugzilla.kernel.org/attachment.cgi?id=126801 Suggested-by: Juan Manuel Cabo <[email protected]> Signed-off-by: Kieran Clancy <[email protected]> Reviewed-by: Lan Tianyu <[email protected]> Reviewed-by: Dennis Jansen <[email protected]> Tested-by: Kieran Clancy <[email protected]> Tested-by: Juan Manuel Cabo <[email protected]> Tested-by: Dennis Jansen <[email protected]> Tested-by: Maurizio D'Addona <[email protected]> Tested-by: San Zamoyski <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-03-06cpufreq: Initialize governor for a new policy under policy->rwsemViresh Kumar1-0/+2
policy->rwsem is used to lock access to all parts of code modifying struct cpufreq_policy, but it's not used on a new policy created by __cpufreq_add_dev(). Because of that, if cpufreq_update_policy() is called in a tight loop on one CPU in parallel with offline/online of another CPU, then the following crash can be triggered: Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = c0003000 [00000020] *pgd=80000000004003, *pmd=00000000 Internal error: Oops: 206 [#1] PREEMPT SMP ARM PC is at __cpufreq_governor+0x10/0x1ac LR is at cpufreq_update_policy+0x114/0x150 ---[ end trace f23a8defea6cd706 ]--- Kernel panic - not syncing: Fatal exception CPU0: stopping CPU: 0 PID: 7136 Comm: mpdecision Tainted: G D W 3.10.0-gd727407-00074-g979ede8 #396 [<c0afe180>] (notifier_call_chain+0x40/0x68) from [<c02a23ac>] (__blocking_notifier_call_chain+0x40/0x58) [<c02a23ac>] (__blocking_notifier_call_chain+0x40/0x58) from [<c02a23d8>] (blocking_notifier_call_chain+0x14/0x1c) [<c02a23d8>] (blocking_notifier_call_chain+0x14/0x1c) from [<c0803c68>] (cpufreq_set_policy+0xd4/0x2b8) [<c0803c68>] (cpufreq_set_policy+0xd4/0x2b8) from [<c0803e7c>] (cpufreq_init_policy+0x30/0x98) [<c0803e7c>] (cpufreq_init_policy+0x30/0x98) from [<c0805a18>] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) [<c0805a18>] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) from [<c0805d38>] (cpufreq_cpu_callback+0x58/0x84) [<c0805d38>] (cpufreq_cpu_callback+0x58/0x84) from [<c0afe180>] (notifier_call_chain+0x40/0x68) [<c0afe180>] (notifier_call_chain+0x40/0x68) from [<c02812dc>] (__cpu_notify+0x28/0x44) [<c02812dc>] (__cpu_notify+0x28/0x44) from [<c0aeed90>] (_cpu_up+0xf4/0x1dc) [<c0aeed90>] (_cpu_up+0xf4/0x1dc) from [<c0aeeed4>] (cpu_up+0x5c/0x78) [<c0aeeed4>] (cpu_up+0x5c/0x78) from [<c0aec808>] (store_online+0x44/0x74) [<c0aec808>] (store_online+0x44/0x74) from [<c03a40f4>] (sysfs_write_file+0x108/0x14c) [<c03a40f4>] (sysfs_write_file+0x108/0x14c) from [<c03517d4>] (vfs_write+0xd0/0x180) [<c03517d4>] (vfs_write+0xd0/0x180) from [<c0351ca8>] (SyS_write+0x38/0x68) [<c0351ca8>] (SyS_write+0x38/0x68) from [<c0205de0>] (ret_fast_syscall+0x0/0x30) Fix that by taking locks at appropriate places in __cpufreq_add_dev() as well. Reported-by: Saravana Kannan <[email protected]> Suggested-by: Srivatsa S. Bhat <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-03-06cpufreq: Initialize policy before making it available for others to useViresh Kumar1-14/+14
Policy must be fully initialized before it is being made available for use by others. Otherwise cpufreq_cpu_get() would be able to grab a half initialized policy structure that might not have affected_cpus (for example) populated. Then, anybody accessing those fields will get a wrong value and that will lead to unpredictable results. In order to fix this, do all the necessary initialization before we make the policy structure available via cpufreq_cpu_get(). That will guarantee that any code accessing fields of the policy will get correct data from them. Reported-by: Saravana Kannan <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-03-06cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditionsAaron Plattner1-14/+7
If a module calls cpufreq_get while cpufreq is initializing, it's possible for it to be called after cpufreq_driver is set but before cpufreq_cpu_data is written during subsys_interface_register. This happens because cpufreq_get doesn't take the cpufreq_driver_lock around its use of cpufreq_cpu_data. Fix this by using cpufreq_cpu_get(cpu) to look up the policy rather than reading it out of cpufreq_cpu_data directly. cpufreq_cpu_get() takes the appropriate locks to prevent this race from happening. Since it's possible for policy to be NULL if the caller passes in an invalid CPU number or calls the function before cpufreq is initialized, delete the BUG_ON(!policy) and simply return 0. Don't try to return -ENOENT because that's negative and the function returns an unsigned integer. References: https://bbs.archlinux.org/viewtopic.php?id=177934 Signed-off-by: Aaron Plattner <[email protected]> Cc: 3.13+ <[email protected]> # 3.13+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-03-06drm/i915: Fix PSR programmingBen Widawsky1-1/+1
| has a higher precedence than ?. Therefore, the calculation doesn't do at all what you would expect. Thanks to Ken for convincing me that this was indeed the issue. Send me back to C programmer school, please. I'm sort of surprised PSR was continuing to work for people. It should be broken IMO (and it was broken for me, but I had assumed it never worked). Regression from: commit ed8546ac1f99b850879f07b1e9b06b42fb0a36d9 Author: Ben Widawsky <[email protected]> Date: Mon Nov 4 22:45:05 2013 -0800 drm/i915/bdw: Support eDP PSR Cc: Rodrigo Vivi <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Art Runyan <[email protected]> Reported-by: "Kumar, Kiran S" <[email protected]> Cc: [email protected] [v3.13+] Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.