- 26 Sep, 2007 19 commits
-
-
Wolfgang Walter authored
commit 9db619e6 in mainline. we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since then we get the message lockd: too many open TCP sockets, consider increasing the number of nfsd threads lockd: last TCP connect from ^\\236^\É^D These random characters in the second line are caused by a bug in svc_tcp_accept. (Note: there are two previous __svc_print_addr(sin, buf, sizeof(buf)) calls in this function, either of which would initialize buf correctly; but both are inside "if"'s and are not necessarily executed. This is less obvious in the second case, which is inside a dprintk(), which is a macro which expands to an if statement.) Signed-off-by:
Wolfgang Walter <wolfgang.walter@studentenwerk.mhn.de> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jens Axboe authored
This is a splice patch for 2.6.22 and 2.6.21 (and earlier, I did not check. Let me know if you still maintain older stable trees!). It fixes an infinite loop in do_splice_direct(), when there's either nothing to read or nothing to write and blocking doesn't help. It could be things like running out of disk space. We need to exit both for failure and zero return, or we could be going around forever. This got fixed in 2.6.23-git with commit 51a92c0f Herbert Poetzl <herbert@13thfloor.at> noticed this bug in 2.6.22, and has verified that this minimal fix works. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jean Delvare authored
Commit 85237f20 introduced the following warning: drivers/media/video/pwc/pwc-if.c: In function "pwc_video_close": drivers/media/video/pwc/pwc-if.c:1211: warning: "i" may be used uninitialized in this function This is true, and can cause a broken debug message to be logged. Here's a fix. Fix is already in Linus' tree for 2.6.23: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7b9fbc3e30f785412a26819aa4daf0b6c27f6c53Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
Fix an off-by-one error in the I/O region declaration of two hardware monitoring drivers (lm78 and w83781d.) We were requesting one extra port at the end of the region. This is a regression in 2.6.22 and could prevent other drivers from loading properly. Already applied to Linus' tree for 2.6.23: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=15bde2f1a8e819213f54314505a5a0509673109bSigned-off-by:
Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by:
-
Steven Toth authored
(cherry picked from commit 48200bae) [PATCH] V4L: cx88: Avoid a NULL pointer dereference during mpeg_open() Bug: With a hardware encoder board installed as cx88[1] and a non-encoder boards installed as cx88[0], an OOPS is generated during cx8802_get_device() called from mpeg_open(). Signed-off-by:
Steven Toth <stoth@hauppauge.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Jason Lunz authored
Changeset fc0e0197 from mainline. I've bisected the deadlock when many small appends are done on jffs2 down to this commit: commit 6fe6900e Author: Nick Piggin <npiggin@suse.de> Date: Sun May 6 14:49:04 2007 -0700 mm: make read_cache_page synchronous Ensure pages are uptodate after returning from read_cache_page, which allows us to cut out most of the filesystem-internal PageUptodate calls. I didn't have a great look down the call chains, but this appears to fixes 7 possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd. All depending on whether the filler is async and/or can return with a !uptodate page. It introduced a wait to read_cache_page, as well as a read_cache_page_async function equivalent to the old read_cache_page without any callers. Switching jffs2_gc_fetch_page to read_cache_page_async for the old behavior makes the deadlocks go away, but maybe reintroduces the use-before-uptodate problem? I don't understand the mm/fs interaction well enough to say. [It's fine. dwmw2.] Signed-off-by:
Jason Lunz <lunz@falooley.org> Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Howells authored
changeset 48440e89 from mainline. Initialise s_flags in get_sb_mtd_aux() from the flags parameter. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Adam Radford authored
[SCSI] 3w-9xxx: Fix dma mask setting Extracted from commit 0e78d158 The attached patch updates the 3ware 9000 driver: - Fix dma mask setting to fallback to 32-bit if 64-bit fails. Signed-off-by:
Adam Radford <linuxraid@amcc.com> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Kumar Gala authored
commit 0ee6c15e in mainline. When we flush register state for FP, Altivec, or SPE in flush_*_to_thread we need to respect the task_struct that the caller has passed to us. Most cases we are called with current, however sometimes (ptrace) we may be passed a different task_struct. This showed up when using gdbserver debugging a simple program that used floating point. When gdb tried to show the FP regs they all showed up as 0, because the child's FP registers were never properly flushed to memory. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
-
Zhao Yakui authored
commit 9f3119b7 in mainline. ACPI 1.0 used an RSDT with 32-bit physical addresses. ACPI 2.0 adds an XSDT with 32-bit physical addresses. An ACPI 2.0 aware OS is supposed to use the XSDT (when present) instead of the RSDT. However, several systems have failed because the XSDT contains NULL entries -- while it is missing pointers to needed tables, such as SSDTs. When we find an XSDT with NULL entries, discard it and use the ACPI 1.0 RSDT instead. http://bugzilla.kernel.org/show_bug.cgi?id=8630Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Cc: Vincet Fortier <Vincent.Fortier1@EC.GC.CA> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Nathael Pajani authored
commit e5dd0115 in mainline. This patch fixes the order of list_add_tail() arguments in usb_store_new_id() so the list can have more than one single element. Signed-off-by:
Nathael Pajani <nathael.pajani@cpe.fr> Signed-off-by:
-
Satyam Sharma authored
commit bec49477 in mainline. We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked into the same mtd.ko module. Fix the Makefile to ensure this, and remove duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them. Signed-off-by:
Satyam Sharma <satyam@infradead.org> Signed-off-by:
-
Roman Zippel authored
commit f82f3f94 in mainline. Avoid setting the value if the symbol doesn't need to be changed or can't be changed. Later choices may change the dependencies and thus the possible input range. make oldconfig from a 2.6.22 .config with CONFIG_HOTPLUG_CPU not set was in some configurations setting CONFIG_HOTPLUG_CPU=y without asking, even when there was no actual requirement for CONFIG_HOTPLUG_CPU. This was triggered by SUSPEND_SMP that does a select HOTPLUG_CPU. Signed-off-by:
Roman Zippel <zippel@linux-m68k.org> Tested-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Oleg Nesterov authored
commit 60187d27 in mainline. Spotted by taoyue <yue.tao@windriver.com> and Jeremy Katz <jeremy.katz@windriver.com>. collect_signal: sigqueue_free: list_del_init(&first->list); if (!list_empty(&q->list)) { // not taken } q->flags &= ~SIGQUEUE_PREALLOC; __sigqueue_free(first); __sigqueue_free(q); Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the obviously bad implications. In particular, this double free breaks the array_cache->avail logic, so the same sigqueue could be "allocated" twice, and the bug can manifest itself via the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue. Hopefully this can explain these mysterious bug-reports, see http://marc.info/?t=118766926500003 http://marc.info/?t=118466273000005 Alexey Dobriyan reports this patch makes the difference for the testcase, but nobody has an access to the application which opened the problems originally. Also, this patch removes tasklist lock/unlock, ->siglock is enough. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: taoyue <yue.tao@windriver.com> Cc: Jeremy Katz <jeremy.katz@windriver.com> Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Alexey Dobriyan <adobriyan@sw.ru> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Oleg Nesterov authored
commit b07e35f9 in mainline tree Spotted by Marcin Kowalczyk <qrczak@knm.org.pl>. sys_setpgid(child) fails if the child was forked by sub-thread. Fix the "is it our child" check. The previous commit ee0acf90 was not complete. (this patch asks for the new same_thread_group() helper, but mainline doesn't have it yet). Signed-off-by:
Roland McGrath <roland@redhat.com> Tested-by:
"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> Signed-off-by:
-
Trent Piepho authored
cherry picked from commit 6175e487 b2c2-flexcop: fix Airstar HD5000 tuning regression Git changeset 6bdcc6e6 dropped the stand-alone lgh06xf module, whose functionality was absorbed into the dvb-pll module. However, there was a minor difference between the code in lgh06xf and dvb-pll, which caused a regression in b2c2-flexcop devices using the LG-H06xF NIM. dvb-pll will probe for the presence of an i2c pll chip by performing a single byte read, the lgh06xf driver did not do this. Unfortunately, the code in flexcop-i2c.c does not currently support 1 byte or 0 byte reads as a probe. Such probes with the current code will always fail. In order to work around this problem, and restore proper functionality of the Airstar HD5000 device, this hack was created to make the probe appear to succeed. The single byte read in dvb_pll_attach is the only place where such a probe would ever occur, so this change is safe, and will not affect any other devices. Of course, if one knew how to actually perform the read operation, it would be better to go that route. In the meantime, however, we must apply this workaround, in order to prevent the regression that causes tuning to fail on the Airstar HD5000 ATSC device. Thanks to Jarod Wilson, who had originally reported this regression, and to Geoffrey Hausheer, whose original workaround patch led us to find the actual cause of the problem. Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Cc: Geoffrey Hausheer <inli3epy93n@phracturedblue.com> Acked-by:
Jarod Wilson <jwilson@redhat.com> Signed-off-by:
-
Andreas Arens authored
cherry picked from commit c545d6ad Update get_dvb_firmware script for the new location of the tda10046 firmware. The old location doesn't work anymore. Signed-off-by:
Andreas Arens <ari@goron.de> Signed-off-by:
-
Michael Krufky authored
cherry picked from commit 302170a4 get_dvb_firmware: update script for new location of sp8870 firmware This url is no longer valid: http://www.technotrend.de/new/217g/tt_Premium_217g.zip Replace with: http://www.softwarepatch.pl/9999ccd06a4813cb827dbb0005071c71/tt_Premium_217g.zip Thanks-to: Tobias Stoeber <tobi@to-st.de> Signed-off-by:
-
Hans Verkuil authored
cherry picked from commit c3624f99 ivtv: fix VIDIOC_S_FBUF support: new OSD values were never actually set. The values set with VIDIOC_S_FBUF were not actually used until the next VIDIOC_S_FMT. Fixed. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
- 25 Sep, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Takashi Iwai authored
changeset ccec6e2c in mainline. Use seq_file for the proc file read/write of snd-page-alloc module. This automatically fixes bugs in the old proc code. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- 21 Sep, 2007 2 commits
-
-
Chris Wright authored
-
Andi Kleen authored
Strictly it's only needed for eax. It actually does a little more than strictly needed -- the other registers are already zero extended. Also remove the now unnecessary and non functional compat task check in ptrace. This is CVE-2007-4573 Found by Wojciech Purczynski Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
- 31 Aug, 2007 17 commits
-
-
Greg Kroah-Hartman authored
-
Kay Sievers authored
This fixes a regression for userspace programs that were relying on these events. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Cc: Andreas Jellinghaus <aj@ciphirelabs.com> Signed-off-by:
-
Oliver Neukum authored
the pwc driver has a disconnect method that waits for user space to close the device. This opens up an opportunity for a DoS attack, blocking the USB subsystem and making khubd's task busy wait in kernel space. This patch shifts freeing resources to close if an opened device is disconnected. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Alan Stern authored
This patch (as964) was suggested by Steffen Koepf. It makes usb_get_descriptor() retry on all errors other than ETIMEDOUT, instead of only on EPIPE. This helps with some devices. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Tejun Heo authored
RX790 can't do MSI like its predecessors. Disable MSI on RX790. Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
-
Tejun Heo authored
RD580 can't do MSI like its predecessors. Disable MSI on RD580. Signed-off-by:
Tejun Heo <teheo@suse.de> Signed-off-by:
-
Tejun Heo authored
RS690 can't do MSI like its predecessors. Disable MSI on RS690. Signed-off-by:
-
Bernhard Kaindl authored
Adrian Bunk wrote: > Alois Nešpor wrote >> PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses') >> Please report the result to linux-kernel to fix this permanently" >> >> dmesg: >> "Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e" >> without pci=assign-busses and nothing with pci=assign-busses. > > Bernhard? Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by Yenta, so PCI does not have to warn about it. PCI could still warn about it if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have not seen a report where this would have been the case so I think we can spare the kernel of that check (removes ~300 lines of asm) unless debugging is done. History: The whole check was added in the days before we had the fixup for this in Yenta and pci=assign-busses was the only way to get CardBus cards detected on many (not all) of the machines which give this warning. In theory, there could be cases when this warning would be triggered and it's not cardbus, then the warning should still apply, but I think this should only be the case when working on a completely broken PCI setup, but one may have already enabled the debug code in drivers/pci and the patched check would then trigger. I do not sign this off yet because it's completely untested so far, but everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and pr_debug( changed to printk(. We may also dump the whole check (remove everything within the #ifdef from the source) if that's perferred. On Alois Nešpor's machine this would then (only when debugging) this message: "PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)" "partially" should be in the message on his machine because #0b of #0b-#0e is reachable behind #0a-#0b, but not #0c-#0e. But that differentiation is now moot anyway because the fixup in Yenta takes care of it as far as I could see so far, which means that unless somebody is debugging a totally broken PCI setup, this message is not needed anymore, not even for debugging PCI. Ok, here the patch with the following changes: * Refined to say that the bus is only partially hidden when the parent bus numbers are not totally way off (outside of) the child bus range * remove the reference to pci=assign-busses and the plea to report it We could add a pure source code-only comment to keep a reference to pci=assign-busses the in case when this is triggered by someone who is debugging the cause of this message and looking the way to solve it. From: Bernhard Kaindl <bk@suse.de> Signed-off-by: -
Konstantin Sharlaimov authored
This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine. -------------------- As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that. -------------------- Signed-off-by:
Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ilpo Järvinen authored
It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too). I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-) Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Ilpo Järvinen authored
Actually, the ratehalving seems to work too well, as cwnd is reduced on every second ACK even though the packets in flight remains unchanged. Recoveries in a bidirectional flows suffer quite badly because of this, both NewReno and SACK are affected. After this patch, rate halving is performed for ACK only if packets in flight was supposedly changed too. Signed-off-by:
-
David Miller authored
[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg(). As discovered by Evegniy Polyakov, if we try to sendmsg after a connection reset, we can do incredibly stupid things. The core issue is that inet_sendmsg() tries to autobind the socket, but we should never do that for TCP. Instead we should just go straight into TCP's sendmsg() code which will do all of the necessary state and pending socket error checks. TCP's sendpage already directly vectors to tcp_sendpage(), so this merely brings sendmsg() in line with that. Signed-off-by:
-
David Miller authored
[SPARC64]: Fix sun4u PCI config space accesses on sun4u. Don't provide fake PCI config space for sun4u. Also, put back the funny host controller space handling that at least Sabre needs. You have to read PCI host controller registers at their nature size otherwise you get zeros instead of correct values. Signed-off-by:
-
David Miller authored
It didn't handle that case at all, and now dump_stack() can be implemented directly as show_stack(current, NULL) Signed-off-by:
-
Herbert Xu authored
[NET]: Fix unbalanced rcu_read_unlock in __sock_create The recent RCU work created an unbalanced rcu_read_unlock in __sock_create. This patch fixes that. Reported by oleg 123. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
The snap_rcv code reads 5 bytes so we should make sure that we have 5 bytes in the head before proceeding. Based on diagnosis and fix by Evgeniy Polyakov, reported by Alan J. Wylie. Patch also kills the skb->sk assignment before kfree_skb since it's redundant. Signed-off-by:
-
Chuck Ebbert authored
Author: Chuck Ebbert <cebbert@redhat.com> Add xt_statistic.h to the list of headers to install. Apparently needed to build newer versions of iptables. Signed-off-by:
-
