- 10 Nov, 2009 40 commits
-
-
Reinette Chatre authored
commit f82a924c upstream. Replenishment of receive buffers is done in the tasklet handling received frames as well as in a workqueue. When we are in the tasklet we cannot sleep and thus attempt atomic skb allocations. It is generally not a big problem if this fails since iwl_rx_allocate is always followed by a call to iwl_rx_queue_restock which will queue the work to replenish the buffers at a time when sleeping is allowed. We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to reduce the noise if such an allocation fails while we still have enough buffers. We do maintain the warning and the error message when we are low on buffers to communicate to the user that there is a potential problem with memory availability on system This addresses issue reported upstream in thread "iwlagn: order 2 page allocation failures" in http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Acked-by:
Mel Gorman <mel@csn.ul.ie> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Reinette Chatre authored
commit de0bd508 upstream. RX handling maintains a few lists that keep track of the RX buffers. Buffers move from one list to the other as they are used, replenished, and again made available for usage. In one such instance, when a buffer is used it enters the "rx_used" list. When buffers are replenished an skb is attached to the buffer and it is moved to the "rx_free" list. The problem here is that the buffer is first removed from the "rx_used" list _before_ the skb is allocated. Thus, if the skb allocation fails this buffer remains removed from the "rx_used" list and is thus lost for future usage. Fix this by first allocating the skb before trying to attach it to a list. We add an additional check to not do this unnecessarily. Reported-by:
Rick Farrington <rickdic@hotmail.com> Signed-off-by:
-
Ingo Molnar authored
commit b417c9fd upstream. If a system switches back and forth between hot and cold mode, the MCE code will print a stream of critical kernel messages. Extend the throttling code to properly notice this, by only printing the first hot + cold transition and omitting the rest up to CHECK_INTERVAL (5 minutes). This way we'll only get a single incident of: [ 102.356584] CPU0: Temperature above threshold, cpu clock throttled (total events = 1) [ 102.357000] Disabling lock debugging due to kernel taint [ 102.369223] CPU0: Temperature/speed normal Every 5 minutes. The 'total events' count tells the number of cold/hot transitions detected, should overheating occur after 5 minutes again: [ 402.357580] CPU0: Temperature above threshold, cpu clock throttled (total events = 24891) [ 402.358001] CPU0: Temperature/speed normal [ 450.704142] Machine check events logged Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Andi Kleen <ak@linux.intel.com> LKML-Reference: <new-submission> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ingo Molnar authored
commit 39676840 upstream. Instead of a mess of three separate percpu variables, consolidate the state into a single structure. Also clean up therm_throt_process(), use cleaner and more understandable variable names and a clearer logic. This, without changing the logic, makes the code more streamlined, more readable and smaller as well: text data bss dec hex filename 1487 169 4 1660 67c therm_throt.o.before 1432 176 4 1612 64c therm_throt.o.after Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Andi Kleen <ak@linux.intel.com> LKML-Reference: <new-submission> Signed-off-by:
-
Wu Fengguang authored
commit 41e20983 upstream. It is possible to have !Anon but SwapBacked pages, and some apps could create huge number of such pages with MAP_SHARED|MAP_ANONYMOUS. These pages go into the ANON lru list, and hence shall not be protected: we only care mapped executable files. Failing to do so may trigger OOM. Tested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Bastian Blank authored
commit 6fdc31a2 upstream. On Thu, Aug 13, 2009 at 04:14:58PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2009-08-11 at 11:39 +0200, Bastian Blank wrote: > > This patch just disables this driver on SMP kernels, as it is obviously > > not supported. > Why not remove the #error instead ? :-) I don't think it's still > meaningful, especially since we use the timebase for delays nowadays > which doesn't depend on the CPU frequency... Your call. Take this one: The build of a PowerMac 32bit kernel currently fails with error: #warning "WARNING, CPUFREQ not recommended on SMP kernels" Thie patch removes the not longer applicable SMP warning from the PowerMac cpufreq code. Signed-off-by:
Bastian Blank <waldi@debian.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Trond Myklebust authored
commit 9a3936aa upstream. Otherwise, we have to wait for the server to recall it. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 3050141b upstream. The NFSv4 renew daemon is shared between all active super blocks that refer to a particular NFS server, so it is wrong to be shutting it down in nfs4_kill_super every time a super block is destroyed. This patch therefore kills nfs4_renewd_prepare_shutdown altogether, and leaves it up to nfs4_shutdown_client() to also shut down the renew daemon by means of the existing call to nfs4_kill_renewd(). Signed-off-by:
-
Trond Myklebust authored
commit 141aeb9f upstream. Commits 29fba38b (nfs41: lease renewal) and fc01cea9 (nfs41: sequence operation) introduce a couple of put_rpccred() calls on credentials for which there is no corresponding get_rpccred(). See http://bugzilla.kernel.org/show_bug.cgi?id=14249Signed-off-by:
-
Trond Myklebust authored
commit 52567b03 upstream. RFC 3530 states that when we recieve the error NFS4ERR_RESOURCE, we are not supposed to bump the sequence number on OPEN, LOCK, LOCKU, CLOSE, etc operations. The problem is that we map that error into EREMOTEIO in the XDR layer, and so the NFSv4 middle-layer routines like seqid_mutating_err(), and nfs_increment_seqid() don't recognise it. The fix is to defer the mapping until after the middle layers have processed the error. Signed-off-by:
-
Terry Loftin authored
commit a8b40bc7 upstream. Actually pass the NFS_FILE_SYNC option to the server to avoid a Panic in nfs_direct_write_complete() when a commit fails. At the end of an nfs write, if the nfs commit fails, all the writes will be rescheduled. They are supposed to be rescheduled as NFS_FILE_SYNC writes, but the rpc_task structure is not completely intialized and so the option is not passed. When the rescheduled writes complete, the return indicates that they are NFS_UNSTABLE and we try to do another commit. This leads to a Panic because the commit data structure pointer was set to null in the initial (failed) commit attempt. Signed-off-by:
Terry Loftin <terry.loftin@hp.com> Signed-off-by:
-
Ben Hutchings authored
commit f4373bf9 upstream. As seen in <http://bugs.debian.org/549002>, nfs4_init_client() can overrun the source string when copying the client IP address from nfs_parsed_mount_data::client_address to nfs_client::cl_ipaddr. Since these are both treated as null-terminated strings elsewhere, the copy should be done with strlcpy() not memcpy(). Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Jiri Pirko authored
commit ad61df91 upstream. Commit 9ef1d4c7 ("[NETLINK]: Missing initializations in dumped data") introduced a typo in initialization. This patch fixes this. Signed-off-by:
Jiri Pirko <jpirko@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Jean Delvare authored
commit 371dc4a6 upstream. Comparing apples to bananas doesn't seem right. Consistently use the chips enum for chip type comparisons, to avoid such bugs in the future. The bug has been there since support for the IT8718F was added, so VID never worked for this chip nor for the similar IT8720F. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jiri Bohac authored
commit d9d52832 upstream. In mii monitor mode, bond_check_dev_link() calls the the ioctl handler of slave devices. It stores the ndo_do_ioctl function pointer to a static (!) ioctl variable and later uses it to call the handler with the IOCTL macro. If another thread executes bond_check_dev_link() at the same time (even with a different bond, which none of the locks prevent), a race condition occurs. If the two racing slaves have different drivers, this may result in one driver's ioctl handler being called with a pointer to a net_device controlled with a different driver, resulting in unpredictable breakage. Unless I am overlooking something, the "static" must be a copy'n'paste error (?). Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Signed-off-by:
-
David Henningsson authored
commit bd3c200e upstream. If two streams are started immediately after one another (such as a playback and a recording stream), the call to set hw params fails with EBUSY. This patch makes the call succeed, so playback and recording will work properly. Signed-off-by:
David Henningsson <launchpad.web@epost.diwic.se> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Tomoki Sekiyama authored
commit 77238f2b upstream. I found a deadlock bug in UNIX domain socket, which makes able to DoS attack against the local machine by non-root users. How to reproduce: 1. Make a listening AF_UNIX/SOCK_STREAM socket with an abstruct namespace(*), and shutdown(2) it. 2. Repeat connect(2)ing to the listening socket from the other sockets until the connection backlog is full-filled. 3. connect(2) takes the CPU forever. If every core is taken, the system hangs. PoC code: (Run as many times as cores on SMP machines.) int main(void) { int ret; int csd; int lsd; struct sockaddr_un sun; /* make an abstruct name address (*) */ memset(&sun, 0, sizeof(sun)); sun.sun_family = PF_UNIX; sprintf(&sun.sun_path[1], "%d", getpid()); /* create the listening socket and shutdown */ lsd = socket(AF_UNIX, SOCK_STREAM, 0); bind(lsd, (struct sockaddr *)&sun, sizeof(sun)); listen(lsd, 1); shutdown(lsd, SHUT_RDWR); /* connect loop */ alarm(15); /* forcely exit the loop after 15 sec */ for (;;) { csd = socket(AF_UNIX, SOCK_STREAM, 0); ret = connect(csd, (struct sockaddr *)&sun, sizeof(sun)); if (-1 == ret) { perror("connect()"); break; } puts("Connection OK"); } return 0; } (*) Make sun_path[0] = 0 to use the abstruct namespace. If a file-based socket is used, the system doesn't deadlock because of context switches in the file system layer. Why this happens: Error checks between unix_socket_connect() and unix_wait_for_peer() are inconsistent. The former calls the latter to wait until the backlog is processed. Despite the latter returns without doing anything when the socket is shutdown, the former doesn't check the shutdown state and just retries calling the latter forever. Patch: The patch below adds shutdown check into unix_socket_connect(), so connect(2) to the shutdown socket will return -ECONREFUSED. Signed-off-by:
Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com> Signed-off-by:
Masanori Yoshida <masanori.yoshida.tv@hitachi.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Alan Cox authored
commit 6d4f950e upstream. The SC1200 needs a NULL terminator or it may cause a crash on boot. Bug #14227 Also correct a bogus comment as the driver had serializing added so can run dual port. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Larry Finger authored
commit d50bae33 upstream. "b43: Fix PPC crash in rfkill polling on unload" fixed the bug reported in Bugzilla No. 14181; however, it introduced a new bug. Whenever the radio switch was turned off, it was necessary to unload and reload the driver for it to recognize the switch again. This patch fixes both the original bug in #14181 and the bug introduced by the previous patch. It must be stated, however, that if there is a BCM4306/3 with an rfkill switch (not yet proven), then the driver will need an unload/reload cycle to turn the device back on. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
David Howells authored
commit 21279cfa upstream. The destination keyring specified to request_key() and co. is made available to the process that instantiates the key (the slave process started by /sbin/request-key typically). This is passed in the request_key_auth struct as the dest_keyring member. keyctl_instantiate_key and keyctl_negate_key() call get_instantiation_keyring() to get the keyring to attach the newly constructed key to at the end of instantiation. This may be given a specific keyring into which a link will be made later, or it may be asked to find the keyring passed to request_key(). In the former case, it returns a keyring with the refcount incremented by lookup_user_key(); in the latter case, it returns the keyring from the request_key_auth struct - and does _not_ increment the refcount. The latter case will eventually result in an oops when the keyring prematurely runs out of references and gets destroyed. The effect may take some time to show up as the key is destroyed lazily. To fix this, the keyring returned by get_instantiation_keyring() must always have its refcount incremented, no matter where it comes from. This can be tested by setting /etc/request-key.conf to: #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ... #====== ======= =============== =============== =============================== create * test:* * |/bin/false %u %g %d %{user:_display} negate * * * /bin/keyctl negate %k 10 @u and then doing: keyctl add user _display aaaaaaaa @u while keyctl request2 user test:x test:x @u && keyctl list @u; do keyctl request2 user test:x test:x @u; sleep 31; keyctl list @u; done which will oops eventually. Changing the negate line to have @u rather than %S at the end is important as that forces the latter case by passing a special keyring ID rather than an actual keyring ID. Reported-by:
Alexander Zangerl <az@bond.edu.au> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
-
Len Brown authored
commit f61f9258 upstream. This reverts commit eab4b645. http://bugzilla.kernel.org/show_bug.cgi?id=13002Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 497fb54f upstream. acpi_get_pci_dev() may be called for a non-PCI device, in which case it should return NULL. However, it assumes that every handle it finds in the ACPI CA name space, between given device handle and the PCI root bridge handle, corresponds to a PCI-to-PCI bridge with an existing secondary bus. For this reason, when it finds a struct pci_dev object corresponding to one of them, it doesn't check if its 'subordinate' field is a valid pointer. This obviously leads to a NULL pointer dereference if acpi_get_pci_dev() is called for a non-PCI device with a PCI parent which is not a bridge. To fix this issue make acpi_get_pci_dev() check if pdev->subordinate is not NULL for every device it finds on the path between the root bridge and the device it's supposed to get to and return NULL if the "target" device cannot be found. http://bugzilla.kernel.org/show_bug.cgi?id=14129 (worked in 2.6.30, regression in 2.6.31) Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Reported-by:
Danny Feng <dfeng@redhat.com> Reviewed-by:
Alex Chiang <achiang@hp.com> Tested-by:
chepioq <chepioq@gmail.com> Signed-off-by:
-
Sam Ravnborg authored
commit de078ef5 upstream. Add include to get missing THREAD_SIZE definition Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Tim Abbott <tabbott@ksplice.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by:
-
Manuel Lauss authored
commit d71789b6 upstream. Commit 51b563fc ("arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0") removed a few CPPFLAGS with vital include paths necessary to build vmlinux.lds on MIPS, and moved the calculation of the 'jiffies' symbol directly to vmlinux.lds.S but forgot to change make ifdef/... to cpp macros. Signed-off-by:
Manuel Lauss <manuel.lauss@gmail.com> [sam: moved assignment of CPPFLAGS arch/mips/kernel/Makefile] Signed-off-by:
Dmitri Vorobiev <dmitri.vorobiev@movial.com> Signed-off-by:
-
Eric Paris authored
commit 9f0d793b upstream. fsnotify_add_mark is supposed to add a mark to the g_list and i_list and to set the group and inode for the mark. fsnotify_destroy_mark_by_entry uses the fact that ->group != NULL to know if this group should be destroyed or if it's already been done. But fsnotify_add_mark sets the group and inode before it actually adds the mark to the i_list and g_list. This can result in a race in inotify, it requires 3 threads. sys_inotify_add_watch("file") sys_inotify_add_watch("file") sys_inotify_rm_watch([a]) inotify_update_watch() inotify_new_watch() inotify_add_to_idr() ^--- returns wd = [a] inotfiy_update_watch() inotify_new_watch() inotify_add_to_idr() fsnotify_add_mark() ^--- returns wd = [b] returns to userspace; inotify_idr_find([a]) ^--- gives us the pointer from task 1 fsnotify_add_mark() ^--- this is going to set the mark->group and mark->inode fields, but will return -EEXIST because of the race with [b]. fsnotify_destroy_mark() ^--- since ->group != NULL we call back into inotify_freeing_mark() which calls inotify_remove_from_idr([a]) since fsnotify_add_mark() failed we call: inotify_remove_from_idr([a]) <------WHOOPS it's not in the idr, this could have been any entry added later! The fix is to make sure we don't set mark->group until we are sure the mark is on the inode and fsnotify_add_mark will return success. Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Joerg Roedel authored
commit c5cca146 upstream. There is an erratum for IOMMU hardware which documents undefined behavior when forwarding SMI requests from peripherals and the DTE of that peripheral has a sysmgt value of 01b. This problem caused weird IO_PAGE_FAULTS in my case. This patch implements the suggested workaround for that erratum into the AMD IOMMU driver. The erratum is documented with number 63. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Jens Axboe authored
commit 0bd87182 upstream. Looks like another victim of the confusing kmap() vs kmap_atomic() API differences. Reported-by:
Todor Gyumyushev <yodor1@gmail.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
-
Anand V. Avati authored
commit f60311d5 upstream. fuse_direct_io() has a loop where requests are allocated in each iteration. if allocation fails, the loop is broken out and follows into an unconditional fuse_put_request() on that invalid pointer. Signed-off-by:
Anand V. Avati <avati@gluster.com> Signed-off-by:
-
Gleb Natapov authored
commit abb39119 upstream. If TSS we are switching to resides in high memory task switch will fail since address will be truncated. Windows2k3 does this sometimes when running with more then 4G Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Linus Torvalds authored
commit d39b7dd1 upstream. Not a single line of actual code in the function was really fundamentally correct. Problems ranged from lack of proper range checking, to removing the last character written (which admittedly is usually '\n'), to not accepting hex numbers even though the 'show' routine would show the data in that format. This tries to do better. Acked-by:
Michael Buesch <mb@bu3sch.de> Tested-and-acked-by:
Jack Steiner <steiner@sgi.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Michael Gilbert <michael.s.gilbert@gmail.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 82d64699 upstream. A Xen guest never needs to know about extended topology, and knowing would just confuse it. This patch just zeros ebx in leaf 0xb which indicates no topology info, preventing a crash under Xen on cpus which support this leaf. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
Jeremy Fitzhardinge authored
commit 7825cf10 upstream. We never want to rely on the hvc workqueue to emit output, because the most interesting output is when the kernel is broken. This will improve oops/crash/console message for better debugging. Instead, we force-poll until all output is emitted. Signed-off-by:
-
Fabian Henze authored
commit 7839c5d5 upstream. Signed-off-by:
Fabian Henze <hoacha@quantentunnel.de> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Fabian Henze authored
commit 38d8a956 upstream. Signed-off-by:
-
Zhenyu Wang authored
commit b1f60b70 upstream. Must set filter selection as hardcoded coefficients for medium 3x3 filtering, which matches vbios setting for Ironlake. This fixes display corrupt issue on HP arrandale with new vbios. Signed-off-by:
-
Zhenyu Wang authored
commit c038e51e upstream. For new stepping of PCH, the display reference clock is fully under driver's control. This one trys to setup all needed reference clock for different outputs. Older stepping of PCH chipset should be ignoring this. This fixes output failure issue on newer PCH which requires driver to take control of reference clock enabling. Signed-off-by:
-
Zhenyu Wang authored
commit 58a27471 upstream. FDI M/N calculation hasn't taken the current pipe color depth into account, but always set as 24bpp. This one checks current pipe color depth setting, and change FDI M/N calculation a little to use bits_per_pixel first, then convert to bytes_per_pixel later. This fixes display corrupt issue on Arrandle LVDS with 1600x900 panel in 18bpp dual-channel mode. Signed-off-by:
-
Ryusuke Konishi authored
commit b1e19e56 upstream. Bruno Prémont and Dunphy, Bill noticed me that NILFS will certainly hang on ARM-based targets. I found this was caused by an underflow of dirty pages counter. A b-tree cache routine was marking page dirty without adjusting page account information. This fixes the dirty page accounting leak and resolves the hang on arm-based targets. Reported-by:
Bruno Prémont <bonbons@linux-vserver.org> Reported-by:
Dunphy, Bill <WDunphy@tandbergdata.com> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
-
Jan Beulich authored
commit 81766741 upstream. Restoring %ebp after the call to audit_syscall_exit() is not only unnecessary (because the register didn't get clobbered), but in the sysenter case wasn't even doing the right thing: It loaded %ebp from a location below the top of stack (RBP < ARGOFFSET), i.e. arbitrary kernel data got passed back to user mode in the register. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Roland McGrath <roland@redhat.com> LKML-Reference: <4AE5CC4D020000780001BD13@vpn.id2.novell.com> Signed-off-by:
-
Bo Liu authored
commit 32c5fc10 upstream. In try_to_unuse(), swcount is a local copy of *swap_map, including the SWAP_HAS_CACHE bit; but a wrong comparison against swap_count(*swap_map), which masks off the SWAP_HAS_CACHE bit, succeeded where it should fail. That had the effect of resetting the mm from which to start searching for the next swap page, to an irrelevant mm instead of to an mm in which this swap page had been found: which may increase search time by ~20%. But we're used to swapoff being slow, so never noticed the slowdown. Remove that one spurious use of swap_count(): Bo Liu thought it merely redundant, Hugh rewrote the description since it was measurably wrong. Signed-off-by:
Bo Liu <bo-liu@hotmail.com> Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
