aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2005-09-30[PATCH] uml: remove empty hostfs_truncate methodPaolo 'Blaisorblade' Giarrusso
Calling truncate() on hostfs spits a kernel warning "Something isn't implemented here", but it still works fine. Indeed, hostfs i_op->truncate doesn't do anything. But hostfs_setattr() -> set_attr() correctly detects ATTR_SIZE and calls truncate() on the host. So we should be safe (using ftruncate() may be better, in case the file is unlinked on the host, but we aren't sure to have the file open for writing, and reopening it would cause the same races; plus nobody should expect UML to be so careful). So, the warning is wrong, because the current implementation is working. Al, am I correct, and can the warning be therefore dropped? CC: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] uml: revert "run mconsole "sysrq" in process context"Paolo 'Blaisorblade' Giarrusso
Revert commit 12ebcd73e40e09f0dfddf89e465cc0541e0ff8b1, i.e. [PATCH] uml: run mconsole "sysrq" in process context on request from Jeff Dike. a) sysrq may be run when the scheduler is non-functioning b) the warning I wanted to fix actually came from the fault handler run in atomic context. But I fixed that not to take the semaphore in a separate patch. c) the fault handler is run because of a fault, and that fault was unaffected by this patch. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] uml: clear SKAS0/3 flags when running in TT modePaolo 'Blaisorblade' Giarrusso
SEGV_MAYBE_FIXABLE tests ptrace_faultinfo, and depends on it being 1 only in SKAS3 mode, while currently when running with mode=tt it will be 1 anyway. Fix this, and do the same for proc_mm. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] uml: fix page faults in SKAS3 mode.Paolo 'Blaisorblade' Giarrusso
I hadn't been running a SKAS3 host when testing the "uml: fix hang in TT mode on fault" patch (commit 546fe1cbf91d4d62e3849517c31a2327c992e5c5), and I didn't think enough to the missing trap_no in SKAS3 mode. In fact, the resulting kernel doesn't work at all in SKAS3 mode. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] v4l: DViCO FusionHDTV5 Lite GPIO FixMichael Krufky
GPIO fix for the composite and tv mute states of bt8xx card #135: DViCO FusionHDTV5 Lite. Without this patch, selecting one of these states could produce unexpected behavior. Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] x86: hw_irq.h warning fixAndrew Morton
include/asm/hw_irq.h:70: warning: `struct hw_interrupt_type' declared inside parameter list include/asm/hw_irq.h:70: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] aio: avoid extra aio_{read,write} call when ki_left == 0Zach Brown
Recently aio_p{read,write} changed to perform retries internally rather than returning -EIOCBRETRY. This inadvertantly resulted in always calling aio_{read,write} with ki_left at 0 which would in turn immediately return 0. Harmless, but we can avoid this call by checking in the caller. Signed-off-by: Zach Brown <zach.brown@oracle.com> Signed-off-by: Benjamin LaHaise <bcrl@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] aio: remove unlocked task_list test and resulting raceZach Brown
Only one of the run or kick path is supposed to put an iocb on the run list. If both of them do it than one of them can end up referencing a freed iocb. The kick path could delete the task_list item from the wait queue before getting the ctx_lock and putting the iocb on the run list. The run path was testing the task_list item outside the lock so that it could catch ki_retry methods that return -EIOCBRETRY *without* putting the iocb on a wait queue and promising to call kick_iocb. This unlocked check could then race with the kick path to cause both to try and put the iocb on the run list. The patch stops the run path from testing task_list by requring that any ki_retry that returns -EIOCBRETRY *must* guarantee that kick_iocb() will be called in the future. aio_p{read,write}, the only in-tree -EIOCBRETRY users, are updated. Signed-off-by: Zach Brown <zach.brown@oracle.com> Signed-off-by: Benjamin LaHaise <bcrl@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] aio: lock around kiocbTryKick()Zach Brown
Only one of the run or kick path is supposed to put an iocb on the run list. If both of them do it than one of them can end up referencing a freed iocb. The kick patch could set the Kicked bit before acquiring the ctx_lock and putting the iocb on the run list. The run path, while holding the ctx_lock, could see this partial kick and mistake it for a kick that was deferred while it was doing work with the run_list NULLed out. It would then race with the kick thread to add the iocb to the run list. This patch moves the kick setting under the ctx_lock so that only one of the kick or run path queues the iocb on the run list, as intended. Signed-off-by: Zach Brown <zach.brown@oracle.com> Signed-off-by: Benjamin LaHaise <bcrl@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30Revert "x86-64: Reverse order of bootmem lists"Linus Torvalds
As requested by Thomas Gleixner <tglx@linutronix.de>: "5d3d0f7704ed0bc7eaca0501eeae3e5da1ea6c87 breaks a couple of ARM boards, which depend on the historical bootmem allocation order. There is a cleaner solution around to remove the pgdat list completely, but this is a topic for post 2.6.14 Andi signalled ACK already." Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] SELinux - fix SCTP socket bug and general IP protocol handlingJames Morris
The following patch updates the way SELinux classifies and handles IP based protocols. Currently, IP sockets are classified by SELinux as being either TCP, UDP or 'Raw', the latter being a default for IP socket that is not TCP or UDP. The classification code is out of date and uses only the socket type parameter to socket(2) to determine the class of IP socket. So, any socket created with SOCK_STREAM will be classified by SELinux as TCP, and SOCK_DGRAM as UDP. Also, other socket types such as SOCK_SEQPACKET and SOCK_DCCP are currently ignored by SELinux, which classifies them as generic sockets, which means they don't even get basic IP level checking. This patch changes the SELinux IP socket classification logic, so that only an IPPROTO_IP protocol value passed to socket(2) classify the socket as TCP or UDP. The patch also drops the check for SOCK_RAW and converts it into a default, so that socket types like SOCK_DCCP and SOCK_SEQPACKET are classified as SECCLASS_RAWIP_SOCKET (instead of generic sockets). Note that protocol-specific support for SCTP, DCCP etc. is not addressed here, we're just getting these protocols checked at the IP layer. This fixes a reported problem where SCTP sockets were being recognized as generic SELinux sockets yet still being passed in one case to an IP level check, which then fails for generic sockets. It will also fix bugs where any SOCK_STREAM socket is classified as TCP or any SOCK_DGRAM socket is classified as UDP. This patch also unifies the way IP sockets classes are determined in selinux_socket_bind(), so we use the already calculated value instead of trying to recalculate it. Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] i386: include linux/irq.h rather than asm/hw_irq.hNick Piggin
I need the following patch to compile -git8 here, otherwise these files fail to compile (asm/hw_irq.h needs definitions from linux/irq.h and that file provides the required include ordering). I did not do a full audit, though there looks to be many other places that should get the same treatment, if this is the right way to do it. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] usb/core/hcd-pci.c: don't free_irq() on suspendDaniel Ritz
the free_irq() in USB suspend breaks resume on some setups where USB (ohci/ehci) shares the interrupt with an other device. Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] x86_64: Add missing () around arguments of pte_index macroKirill Korotaev
x86-64: Add missing () around arguments of pte_index macro Signed-Off-By: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-Off-By: Kirill Korotaev <dev@sw.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] useless includes of linux/irq.h (arch/ppc)Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds
2005-09-30Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds
2005-09-30[PATCH] missing qualifiers in readb() et.al. on ppcAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] volatile unsigned short f(...) doesn't make senseAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] bogus BUILD_BUG_ON() in bpa_iommuAl Viro
BUILD_BUG_ON(1) is asking for trouble (and getting it) when used in that manner - dead code elimination happens after we parse it and invalid type is invalid type, dead code or not. It might be version-dependent, but at least 4.0.1 refuses to accept that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] uml get_user() NULL noise removalAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] cpuset crapectomyAl Viro
Switched cpuset_common_file_read() to simple_read_from_buffer(), killed a bunch of useless (and not quite correct - e.g. min(size_t,ssize_t)) code. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] cassini annotations and fixesAl Viro
- __user annotations - NULL noise removal - C99 initializers - s/u32/pm_message_t/ in ->suspend() - removal of bogus casts in iounmap() arguments - if_mii() instead of open-coded variant Remains to be done: ethtool conversion. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] useless linux/irq.h includes (arch/um)Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30[PATCH] missing ERR_PTR in 9fsAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-30Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds
2005-09-30Merge master.kernel.org:/pub/scm/linux/kernel/git/chrisw/lsm-2.6Linus Torvalds
2005-09-30[ARM] 2940/1: Fix BTB entry flush in arch/arm/mm/cache-v6.SGen FUKATSU
Patch from Gen FUKATSU Invalidate BTB entry instruction flushes two instruction at a time. Therefore this instruction should be done four times after invalidate instruction cache line. Signed-off-by: Gen Fukatsu Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-30[ARM] 2942/1: Fix the warning in arch/arm/common/gic.cCatalin Marinas
Patch from Catalin Marinas The warning is caused by the gic_set_cpu() function being defined but not used if CONFIG_SMP is not defined. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-30[ARM] 2939/1: Fix compilation error in arch/arm/mm/flush.cCatalin Marinas
Patch from Catalin Marinas When CONFIG_CPU_CACHE_VIPT is defined, the flush_pfn_alias() function is implicitely declared and it later conflicts with its actual definition. This patch moves the function definition to the beginning of the file. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-29[CASSINI]: sparse annotations and fixesAl Viro
- __user annotations - NULL noise removal - C99 initializers - s/u32/pm_message_t/ in ->suspend() - removal of bogus casts in iounmap() arguments - if_mii() instead of open-coded variant Remains to be done: ethtool conversion. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[IPVS]: Add netdev and me as maintainer contactsHorms
Signed-off-by: Horms <horms@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[RADEON]: Fix unaligned I/O port access during probe.David S. Miller
The driver does a readl() on DEVICE_ID which is 2-byte aligned and 2-bytes in size. It's doing this read just to flush write buffers. Create IN16() and OUT16() macros, and use the former to do this I/O load. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[SPARC64]: Fix several bugs in flush_ptrace_access().David S. Miller
1) Use cpudata cache line sizes, not magic constants. 2) Align start address in cheetah case so we do not get unaligned address traps. (pgrep was good at triggering this, via /proc/${pid}/cmdline accesses) Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[SPARC64]: Kill arch/sparc64/prom/memory.cDavid S. Miller
No longer used. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[SPARC64]: Rewrite convoluted physical memory probing.David S. Miller
Delete all of the code working with sp_banks[] and replace with clean acquisition and sorting of physical memory parameters from the firmware. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[ATM]: [lec] reset retry counter when new arp issuedScott Talbert
From: Scott Talbert <scott.talbert@lmco.com> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[ATM]: [lec] attempt to support cisco failoverScott Talbert
From: Scott Talbert <scott.talbert@lmco.com> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[TCP]: Don't over-clamp window in tcp_clamp_window()Alexey Kuznetsov
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Handle better the case where the sender sends full sized frames initially, then moves to a mode where it trickles out small amounts of data at a time. This known problem is even mentioned in the comments above tcp_grow_window() in tcp_input.c, specifically: ... * The scheme does not work when sender sends good segments opening * window and then starts to feed us spagetti. But it should work * in common situations. Otherwise, we have to rely on queue collapsing. ... When the sender gives full sized frames, the "struct sk_buff" overhead from each packet is small. So we'll advertize a larger window. If the sender moves to a mode where small segments are sent, this ratio becomes tilted to the other extreme and we start overrunning the socket buffer space. tcp_clamp_window() tries to address this, but it's clamping of tp->window_clamp is a wee bit too aggressive for this particular case. Fix confirmed by Ion Badulescu. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29[TCP]: Revert 6b251858d377196b8cea20e65cae60f584a42735David S. Miller
But retain the comment fix. Alexey Kuznetsov has explained the situation as follows: -------------------- I think the fix is incorrect. Look, the RFC function init_cwnd(mss) is not continuous: f.e. for mss=1095 it needs initial window 1095*4, but for mss=1096 it is 1096*3. We do not know exactly what mss sender used for calculations. If we advertised 1096 (and calculate initial window 3*1096), the sender could limit it to some value < 1096 and then it will need window his_mss*4 > 3*1096 to send initial burst. See? So, the honest function for inital rcv_wnd derived from tcp_init_cwnd() is: init_rcv_wnd(mss)= min { init_cwnd(mss1)*mss1 for mss1 <= mss } It is something sort of: if (mss < 1096) return mss*4; if (mss < 1096*2) return 1096*4; return mss*2; (I just scrablled a graph of piece of paper, it is difficult to see or to explain without this) I selected it differently giving more window than it is strictly required. Initial receive window must be large enough to allow sender following to the rfc (or just setting initial cwnd to 2) to send initial burst. But besides that it is arbitrary, so I decided to give slack space of one segment. Actually, the logic was: If mss is low/normal (<=ethernet), set window to receive more than initial burst allowed by rfc under the worst conditions i.e. mss*4. This gives slack space of 1 segment for ethernet frames. For msses slighlty more than ethernet frame, take 3. Try to give slack space of 1 frame again. If mss is huge, force 2*mss. No slack space. Value 1460*3 is really confusing. Minimal one is 1096*2, but besides that it is an arbitrary value. It was meant to be ~4096. 1460*3 is just the magic number from RFC, 1460*3 = 1095*4 is the magic :-), so that I guess hands typed this themselves. -------------------- Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-30[ARM] 2941/1: Fix running legacy binaries from a soft-float root filesystem ↵Daniel Jacobowitz
with CONFIG_IWMMXT. Patch from Daniel Jacobowitz Thread flags are inherited on fork(). In order for a binary which has the iWMMXt coprocessor enabled to run a binary which needs the FPA emulation, we need to explicitly clear TIF_USING_IWMMXT if we are not going to set it. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-29[PATCH] Fix ppc64 smu driver lockingBenjamin Herrenschmidt
The SMU driver has a small mistake in the locking of the interrupt code, if polled access and interrupt access race, interrupt may take a lock and return without releasing it. This fixes it. With that patch, the driver is rock solid with my experimental thermal control (which bangs it pretty hard) racing with real time clock and cpufreq handling. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-29[PATCH] readv/writev syscalls are not checked by lsmKostik Belousov
it seems that readv(2)/writev(2) syscalls do not call file_permission callback. Looks like this is overlook. I have filled the issue into redhat bugzilla as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169433 and got the recommendation to post this on lsm mailing list. The following trivial patch solves the problem. Signed-off-by: Kostik Belousov <kostikbel@gmail.com> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-29[PATCH] x86_64: Fix mce_logMike Waychison
The attempt to fixup the lockless mce log buffer introduced an infinite loop when trying to find a free entry. And: Using rcu_dereference() to load mcelog.next doesn't seem to be sufficient enough to ensure that mcelog.next is loaded each time around the loop in mce_log(). Instead, use an explicit rmb() to ensure that the compiler gets it right. AK: turned the smp_wmbs into true wmbs to make sure they are not reordered by the compiler on UP. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-29[PATCH] Fix up TLB flush filter disablingAndi Kleen
I checked with AMD and they requested to only disable it for family 15. Also disable it for i386 too. And some style fixes. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-29[PATCH] Fix task state testing properly in do_signal_stop()Roland McGrath
Any tests using < TASK_STOPPED or the like are left over from the time when the TASK_ZOMBIE and TASK_DEAD bits were in the same word, and it served to check for "stopped or dead". I think this one in do_signal_stop is the only such case. It has been buggy ever since exit_state was separated, and isn't testing the exit_state value. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-29Revert task flag re-ordering, add commentsLinus Torvalds
Roland points out that the flags end up having non-obvious dependencies elsewhere, so revert aa55a08687059aa169d10a313c41f238c2070488 and add some comments about why things are as they are. We'll just have to fix up the broken comparisons. Roland has a patch. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-29[PATCH] fix TASK_STOPPED vs TASK_NONINTERACTIVE interactionOleg Nesterov
do_signal_stop: for_each_thread(t) { if (t->state < TASK_STOPPED) ++sig->group_stop_count; } However, TASK_NONINTERACTIVE > TASK_STOPPED, so this loop will not count TASK_INTERRUPTIBLE | TASK_NONINTERACTIVE threads. See also wait_task_stopped(), which checks ->state > TASK_STOPPED. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> [ We really probably should always use the appropriate bitmasks to test task states, not do it like this. Using something like #define TASK_RUNNABLE (TASK_RUNNING | TASK_INTERRUPTIBLE | \ TASK_UNINTERRUPTIBLE | TASK_NONINTERACTIVE) and then doing "if (task->state & TASK_RUNNABLE)" or similar. But the ordering of the task states is historical, and keeping the ordering does make sense regardless. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-29Merge master.kernel.org:/home/rmk/linux-2.6-serialLinus Torvalds
2005-09-29[PATCH] Fix thinko in previous ARM 2917/1 patchDeepak Saxena
Previous patch accidently add IXDP425 mach entry when IXDP465 is configured. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>