- 16 Aug, 2011 17 commits
-
-
Tetsuo Handa authored
commit c71d8ebe upstream. The sendmmsg() introduced by commit 228e548e "net: Add sendmmsg socket system call" is capable of sending to multiple different destination addresses. SMACK is using destination's address for checking sendmsg() permission. However, security_socket_sendmsg() is called for only once even if multiple different destination addresses are passed to sendmmsg(). Therefore, we need to call security_socket_sendmsg() for each destination address rather than only the first destination address. Since calling security_socket_sendmsg() every time when only single destination address was passed to sendmmsg() is a waste of time, omit calling security_socket_sendmsg() unless destination address of previous datagram and that of current datagram differs. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Anton Blanchard authored
commit 98382f41 upstream. To limit the amount of time we can spend in sendmmsg, cap the number of elements to UIO_MAXIOV (currently 1024). For error handling an application using sendmmsg needs to retry at the first unsent message, so capping is simpler and requires less application logic than returning EINVAL. Signed-off-by:
-
Anton Blanchard authored
commit 728ffb86 upstream. sendmmsg uses a similar error return strategy as recvmmsg but it turns out to be a confusing way to communicate errors. The current code stores the error code away and returns it on the next sendmmsg call. This means a call with completely valid arguments could get an error from a previous call. Change things so we only return an error if no datagrams could be sent. If less than the requested number of messages were sent, the application must retry starting at the first failed one and if the problem is persistent the error will be returned. This matches the behaviour of other syscalls like read/write - it is not an error if less than the requested number of elements are sent. Signed-off-by:
-
Stanislaw Gruszka authored
commit d4930086 upstream. We receive many bug reports about system hang during suspend/resume when ath9k driver is in use. Adrian Chadd remarked that this problem happens on systems that have ASPM disabled. To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe downstream port device, which ath9k device is connected to, has ASPM disabled. Bug was introduced by: commit 53bc7aa0 Author: Vivek Natarajan <vnatarajan@atheros.com> Date: Mon Apr 5 14:48:04 2010 +0530 ath9k: Add support for newer AR9285 chipsets. Patch should address: https://bugzilla.kernel.org/show_bug.cgi?id=37462 https://bugzilla.kernel.org/show_bug.cgi?id=37082 https://bugzilla.redhat.com/show_bug.cgi?id=697157 however I did not receive confirmation about that, except from Camilo Mesias, whose system stops hang regularly with this patch (but still hangs from time to time, but this is probably some other bug). Tested-by:
Camilo Mesias <camilo@mesias.co.uk> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felix Fietkau authored
commit c1227340 upstream. With an uninitialized chainmask, the per-channel power will only contain the power limits for a single chain instead of the combined tx power. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 17e859a8 upstream. If settings of tx power was deferred during scan or changing channel we have to setup them during commit rxon. Fix problem on 3945 (4965 already has this fix). Optimize code to apply tx settings only when tx power was actually changed. Signed-off-by:
-
Larry Finger authored
commit b6b67df3 upstream. This driver uses information from the self member of the pci_bus struct to get information regarding the bridge to which the PCIe device is attached. Unfortunately, this member is not established on all architectures, which leads to a kernel oops. Skipping the entire block that uses the self member to determine the bridge vendor will only affect RTL8192DE devices as that driver sets the ASPM support flag differently when the bridge vendor is Intel. If the self member is available, there is no functional change. This patch fixes Bugzilla No. 40212. Reported-by:
Hubert Liao <liao.hubertt@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Stanislaw Gruszka authored
commit 00898a47 upstream. We may call rt2x00queue_pause_queue(queue) with queue == NULL. Bug was introduced by commit 62fe7784 "rt2x00: Fix stuck queue in tx failure case" . Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit b52398b6 upstream. We should clear skb->data not skb itself. Bug was introduced by: commit 0b8004aa "rt2x00: Properly reserve room for descriptors in skbs". Signed-off-by:
-
John David Anglin authored
commit 548c210f upstream. The return type of __atomic64_add_return of should be s64 or long, not int. This fixes the atomic64 test failure that I previously reported. Signed-off-by:
John David Anglin <dave.anglin@nrc-cnrc.gc.ca> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Carlos O'Donell authored
commit d9ba5fe7 upstream. Implements futex op support and makes futex cmpxchg atomic. Tested on 64-bit SMP kernel running on 2 x PA8700s. [jejb: checkpatch fixes] Signed-off-by:
Carlos O'Donell <carlos@systemhalted.org> Tested-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
-
James Bottomley authored
commit 205e9a21 upstream. Signed-off-by:
-
Shawn Bohrer authored
commit 9ea71503 upstream. commit 7485d0d3 (futexes: Remove rw parameter from get_futex_key()) in 2.6.33 fixed two problems: First, It prevented a loop when encountering a ZERO_PAGE. Second, it fixed RW MAP_PRIVATE futex operations by forcing the COW to occur by unconditionally performing a write access get_user_pages_fast() to get the page. The commit also introduced a user-mode regression in that it broke futex operations on read-only memory maps. For example, this breaks workloads that have one or more reader processes doing a FUTEX_WAIT on a futex within a read only shared file mapping, and a writer processes that has a writable mapping issuing the FUTEX_WAKE. This fixes the regression for valid futex operations on RO mappings by trying a RO get_user_pages_fast() when the RW get_user_pages_fast() fails. This change makes it necessary to also check for invalid use cases, such as anonymous RO mappings (which can never change) and the ZERO_PAGE which the commit referenced above was written to address. This patch does restore the original behavior with RO MAP_PRIVATE mappings, which have inherent user-mode usage problems and don't really make sense. With this patch performing a FUTEX_WAIT within a RO MAP_PRIVATE mapping will be successfully woken provided another process updates the region of the underlying mapped file. However, the mmap() man page states that for a MAP_PRIVATE mapping: It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region. So user-mode users attempting to use futex operations on RO MAP_PRIVATE mappings are depending on unspecified behavior. Additionally a RO MAP_PRIVATE mapping could fail to wake up in the following case. Thread-A: call futex(FUTEX_WAIT, memory-region-A). get_futex_key() return inode based key. sleep on the key Thread-B: call mprotect(PROT_READ|PROT_WRITE, memory-region-A) Thread-B: write memory-region-A. COW happen. This process's memory-region-A become related to new COWed private (ie PageAnon=1) page. Thread-B: call futex(FUETX_WAKE, memory-region-A). get_futex_key() return mm based key. IOW, we fail to wake up Thread-A. Once again doing something like this is just silly and users who do something like this get what they deserve. While RO MAP_PRIVATE mappings are nonsensical, checking for a private mapping requires walking the vmas and was deemed too costly to avoid a userspace hang. This Patch is based on Peter Zijlstra's initial patch with modifications to only allow RO mappings for futex operations that need VERIFY_READ access. Reported-by:
David Oliver <david@rgmadvisors.com> Signed-off-by:
Shawn Bohrer <sbohrer@rgmadvisors.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: peterz@infradead.org Cc: eric.dumazet@gmail.com Cc: zvonler@rgmadvisors.com Cc: hughd@google.com Link: http://lkml.kernel.org/r/1309450892-30676-1-git-send-email-sbohrer@rgmadvisors.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
WANG Cong authored
commit 1646ec9d upstream. Fix: arch/cris/arch-v10/kernel/irq.c:239: error: implicit declaration of function 'kgdb_init' arch/cris/arch-v10/kernel/irq.c:240: error: implicit declaration of function 'breakpoint' Declare these two functions. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
WANG Cong authored
commit b4bc2812 upstream. Fix: arch/cris/arch-v10/drivers/sync_serial.c:961: error: conflicting types for 'sync_serial_ioctl' Reported-by:
-
WANG Cong authored
commit 4b851d88 upstream. Fix: arch/cris/arch-v10/drivers/sync_serial.c:628: error: 'ret' undeclared (first use in this function) 'ret' should be 'err'. Reported-by:
-
WANG Cong authored
commit d4969213 upstream. Fix this error: kernel/fork.c:267: error: implicit declaration of function 'alloc_thread_info_node' This is due to renaming alloc_thread_info() to alloc_thread_info_node(). [akpm@linux-foundation.org: coding-style fixes] Reported-by:
-
- 05 Aug, 2011 23 commits
-
-
Greg Kroah-Hartman authored
-
Alasdair G Kergon authored
commit d15b774c upstream. Destroy _minor_idr when unloading the core dm module. (Found by kmemleak.) Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit 286f367d upstream. Avoid dereferencing a NULL pointer if the number of feature arguments supplied is fewer than indicated. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 762a80d9 upstream. This patch makes dm-snapshot flush disk cache when writing metadata for merging snapshot. Without cache flushing the disk may reorder metadata write and other data writes and there is a possibility of data corruption in case of power fault. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit bb91bc7b upstream. For normal kernel pages, CPU cache is synchronized by the dma layer. However, this is not done for pages allocated with vmalloc. If we do I/O to/from vmallocated pages, we must synchronize CPU cache explicitly. Prior to doing I/O on vmallocated page we must call flush_kernel_vmap_range to flush dirty cache on the virtual address. After finished read we must call invalidate_kernel_vmap_range to invalidate cache on the virtual address, so that accesses to the virtual address return newly read data and not stale data from CPU cache. This patch fixes metadata corruption on dm-snapshots on PA-RISC and possibly other architectures with caches indexed by virtual address. Signed-off-by:
-
Julia Lawall authored
commit ca9380fd upstream. Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David Engraf authored
commit bea19066 upstream. Fix the usage of mod_timer() and make the driver usable. mod_timer() must be called with an absolute timeout in jiffies. The old implementation used a relative timeout thus the hardware watchdog was never triggered. Signed-off-by:
David Engraf <david.engraf@sysgo.com> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
Wim Van sebroeck <wim@iguana.be> Signed-off-by:
-
Steven Whitehouse authored
commit 19237039 upstream. Depending upon the order of userspace/kernel during the mount process, this can result in a hang without the _all version of the completion. Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Gertjan van Wingerde authored
commit 71e0b38c upstream. Reported-by:
Wim Vander Schelden <wim@fixnum.org> Signed-off-by:
-
Oleg Nesterov authored
commit c027a474 upstream. exit_mm() sets ->mm == NULL then it does mmput()->exit_mmap() which frees the memory. However select_bad_process() checks ->mm != NULL before TIF_MEMDIE, so it continues to kill other tasks even if we have the oom-killed task freeing its memory. Change select_bad_process() to check ->mm after TIF_MEMDIE, but skip the tasks which have already passed exit_notify() to ensure a zombie with TIF_MEMDIE set can't block oom-killer. Alternatively we could probably clear TIF_MEMDIE after exit_mmap(). Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
John Johansen authored
commit 25e75dff upstream. AppArmor is masking the capabilities returned by capget against the capabilities mask in the profile. This is wrong, in complain mode the profile has effectively all capabilities, as the profile restrictions are not being enforced, merely tested against to determine if an access is known by the profile. This can result in the wrong behavior of security conscience applications like sshd which examine their capability set, and change their behavior accordingly. In this case because of the masked capability set being returned sshd fails due to DAC checks, even when the profile is in complain mode. Kernels affected: 2.6.36 - 3.0. Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
John Johansen authored
commit 04fdc099 upstream. The pointer returned from tracehook_tracer_task() is only valid inside the rcu_read_lock. However the tracer pointer obtained is being passed to aa_may_ptrace outside of the rcu_read_lock critical section. Mover the aa_may_ptrace test into the rcu_read_lock critical section, to fix this. Kernels affected: 2.6.36 - 3.0 Reported-by:
-
Manfred Spraul authored
commit d694ad62 upstream. If a semaphore array is removed and in parallel a sleeping task is woken up (signal or timeout, does not matter), then the woken up task does not wait until wake_up_sem_queue_do() is completed. This will cause crashes, because wake_up_sem_queue_do() will read from a stale pointer. The fix is simple: Regardless of anything, always call get_queue_result(). This function waits until wake_up_sem_queue_do() has finished it's task. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=27142Reported-by:
Yuriy Yevtukhov <yuriy@ucoz.com> Reported-by:
Harald Laabs <kernel@dasr.de> Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Hendrik Brueckner authored
commit 8c2381af upstream. Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN. This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation. If a hvc backend returns -EAGAIN, the retry handling differs: - hvc_console_print() spins to write the complete console output. - hvc_push() behaves the same way as for returning 0. Now hvc backends can indirectly control the way how console output is handled through the hvc console layer. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Anton Blanchard authored
commit 51d33021 upstream. Return -EAGAIN when we get H_BUSY back from the hypervisor. This makes the hvc console driver retry, avoiding dropped printks. Signed-off-by:
-
Ralf Baechle authored
commit f2eb3cdf upstream. Kconfig allows enabling console support for the SC26xx driver even when it's configured as a module resulting in a: ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined! modpost error since the driver was merged in eea63e0e [SC26XX: New serial driver for SC2681 uarts] in 2.6.25. Fixed by only allowing console support to be enabled if the driver is builtin. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: linux-serial@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Stephen Warren authored
commit 5568181f upstream. Commit 4539c24f "tty/serial: Add explicit PORT_TEGRA type" introduced separate flags describing the need for IER bits UUE and RTOIE. Both bits are required for the XSCALE port type. While that patch updated uart_config[] as required, the auto-probing code wasn't updated to set the RTOIE flag when an XSCALE port type was detected. This caused such ports to stop working. This patch rectifies that. Reported-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Daisuke Nishimura authored
commit 108b6a78 upstream. Commit 22a668d7 ("memcg: fix behavior under memory.limit equals to memsw.limit") introduced "memsw_is_minimum" flag, which becomes true when mem_limit == memsw_limit. The flag is checked at the beginning of reclaim, and "noswap" is set if the flag is true, because using swap is meaningless in this case. This works well in most cases, but when we try to shrink mem_limit, which is the same as memsw_limit now, we might fail to shrink mem_limit because swap doesn't used. This patch fixes this behavior by: - check MEM_CGROUP_RECLAIM_SHRINK at the begining of reclaim - If it is set, don't set "noswap" flag even if memsw_is_minimum is true. Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: Balbir Singh <bsingharora@gmail.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Ying Han <yinghan@google.com> Signed-off-by:
-
Sven Neumann authored
commit a203c2aa upstream. At the beginning of wiphy_update_regulatory() a check is performed whether the request is to be ignored. Then the request is sent to the driver nevertheless. This happens even if last_request points to NULL, leading to a crash in the driver: [<bf01d864>] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [<c03b714c>] (wiphy_update_regulatory+0x4d0/0x4f4) [<c03b714c>] (wiphy_update_regulatory+0x4d0/0x4f4) from [<c03b4008>] (wiphy_register+0x354/0x420) [<c03b4008>] (wiphy_register+0x354/0x420) from [<bf01b17c>] (lbs_cfg_register+0x80/0x164 [libertas]) [<bf01b17c>] (lbs_cfg_register+0x80/0x164 [libertas]) from [<bf020e64>] (lbs_start_card+0x20/0x88 [libertas]) [<bf020e64>] (lbs_start_card+0x20/0x88 [libertas]) from [<bf02cbd8>] (if_sdio_probe+0x898/0x9c0 [libertas_sdio]) Fix this by returning early. Also remove the out: label as it is not any longer needed. Signed-off-by:
Sven Neumann <s.neumann@raumfeld.com> Cc: linux-wireless@vger.kernel.org Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Daniel Mack <daniel@zonque.org> Signed-off-by:
-
Alan Stern authored
commit e04f5f7e upstream. This patch (as1480) fixes a rather obscure bug in ehci-hcd. The qh_update() routine needs to know the number and direction of the endpoint corresponding to its QH argument. The number can be taken directly from the QH data structure, but the direction isn't stored there. The direction is taken instead from the first qTD linked to the QH. However, it turns out that for interrupt transfers, qh_update() gets called before the qTDs are linked to the QH. As a result, qh_update() computes a bogus direction value, which messes up the endpoint toggle handling. Under the right combination of circumstances this causes usb_reset_endpoint() not to work correctly, which causes packets to be dropped and communications to fail. Now, it's silly for the QH structure not to have direct access to all the descriptor information for the corresponding endpoint. Ultimately it may get a pointer to the usb_host_endpoint structure; for now, adding a copy of the direction flag solves the immediate problem. This allows the Spyder2 color-calibration system (a low-speed USB device that sends all its interrupt data packets with the toggle set to 0 and hance requires constant use of usb_reset_endpoint) to work when connected through a high-speed hub. Thanks to Graeme Gill for supplying the hardware that allowed me to track down this bug. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Graeme Gill <graeme@argyllcms.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 81463c1d upstream. MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by:
-
Du, Alek authored
commit f086ced1 upstream. FCS could be GSM0_SOF, so will break state machine... [This byte isn't quoted in any way so a SOF here doesn't imply an error occurred.] Signed-off-by:
Alek Du <alek.du@intel.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 293eb1e7 upstream. If an inode's mode permits opening /proc/PID/io and the resulting file descriptor is kept across execve() of a setuid or similar binary, the ptrace_may_access() check tries to prevent using this fd against the task with escalated privileges. Unfortunately, there is a race in the check against execve(). If execve() is processed after the ptrace check, but before the actual io information gathering, io statistics will be gathered from the privileged process. At least in theory this might lead to gathering sensible information (like ssh/ftp password length) that wouldn't be available otherwise. Holding task->signal->cred_guard_mutex while gathering the io information should protect against the race. The order of locking is similar to the one inside of ptrace_attach(): first goes cred_guard_mutex, then lock_task_sighand(). Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
