Alternate workaround for blocking usage of select() by UDP applications.
The problem is Linux optimizes the UDP receive checksum path so that checksum
validation is not performed until the application read. This is a performance win
but can cause applications that do select with blocking file descriptors to get false
positives if the received message has a checksum error.
There is a long running thread about this on LKML.
This patch makes these applications work, but keeps the one-pass performance gain
for those applications smart enough to use non-blocking file descriptors with
select/poll. There is still a possibility to get a false positive if application does
select on non-blocking fd then makes it blocking before doing the receive, but that
is unlikely.
Tested by injecting bad packets with SOCK_RAW.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
While looking at the SCM passing code in net/core/scm.c I noticed that there's
a 32-bit compat implementation of scm_detach_fds()'s called
scm_detach_fds_compat() living in net/compat.c. While these two functions
are mostly the same the latter does not include the call to the
security_file_receive() hook which is almost certainly a bug.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com> Signed-off-by: James Morris <jmorris@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Rusty Russell [Mon, 29 Nov 2004 12:24:39 +0000 (04:24 -0800)]
[PATCH] Remove Futex Warning
If we're waiting on a futex and we are woken up, it's either because
someone did FUTEX_WAKE, we timed out, or have been signalled. However, the
WARN_ON(!signal_pending(current)) test is overzealous: with threads (a
common use of futexes), we share the signal handler and the other
thread might get to the signal before us. In addition, exit_notify()
can do a recalc_sigpending_tsk() on us, which will then clear our
TIF_SIGPENDING bit, making signal_pending(current) return false.
Returning EINTR is a little strange in this case, since this thread
hasn't handled a signal. However, with threads it's the best we can
do: there's always a race where another thread could have been the
actual one to handle the signal.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ben Dooks [Mon, 29 Nov 2004 15:23:14 +0000 (15:23 +0000)]
[ARM PATCH] 2285/1: S3C2410 - regs-sdi.h fixes
Patch from Ben Dooks
Fixes from Koen Martens to update the
register definitions for the MMC/SD/SDIO interface,
tidied up for release with extra notes on what has
been depreceated in later silicon.
Signed-off-by: Koen Martens Signed-off-by: Ben Dooks Signed-off-by: Russell King
Andrew Patterson [Mon, 29 Nov 2004 05:39:34 +0000 (21:39 -0800)]
[PATCH] cciss: Off-by-one error causing oops in CCISS_GETLUNIFO ioctl
This patch fixes an an "off-by-one" error found in the CCISS_GETLUNIFO
ioctl in the cciss driver. It is cycling through the part table of the
gendisk structure which is a zero-based array, not a one-based array. This
often causes an oops when referencing the out-of-bounds element.
Signed-off by: Andrew Patterson <andrew.patterson@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Antonino Daplas [Mon, 29 Nov 2004 05:39:21 +0000 (21:39 -0800)]
[PATCH] fbdev: Fix crash if fb_set_var() called before register_framebuffer()
The field info->modelist is initialized during register_framebuffer. This
field is also referred to in fb_set_var(). Thus a call to fb_set_var()
before register_framebuffer() will cause a crash. A few drivers do this,
notably controlfb. (This might fix reports of controlfb crashing in
powermacs).
Andi Kleen [Mon, 29 Nov 2004 05:39:09 +0000 (21:39 -0800)]
[PATCH] x86_64: Fix lost edge triggered irqs on UP kernel
Patch from Petr Vandrovec <vandrove@vc.cvut.cz>
Recently I've observed problems with IDE disks while running UP kernel on
x86-64 - it complained a lot about lost irq from hda/hdc. I tracked
problem down to the problem that at enable_irq() code calls
hw_resend_irq(), but on x86-64 hw_resend_irq() does something useful only
when CONFIG_SMP is defined, on UP systems it does nothing.
Due to this IRQ is lost - and when IDE retries command, it can again happen
that IRQ is delivered before IDE code does enable_irq(), and again and
again, unless due to drive being lazy finally once kernel does enable_irq()
before drive prepares its answer, and things move forward ... to next lost
IRQ.
Michael Kerrisk [Mon, 29 Nov 2004 05:38:43 +0000 (21:38 -0800)]
[PATCH] RLIMIT_MEMLOCK accounting of shmctl() SHM_LOCK is broken
The accounting of shmctl() SHM_LOCK memory locks against the user
structure is broken. The check of the size of the to-be-locked region
is based on the size of the segment as specified when it was created by
shmget() (this size is *not* rounded up to a page boundary).
Fix it by rounding the size properlt. Also, tune up the spinlock
coverage in there a little.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Holger Freyther [Sun, 28 Nov 2004 16:07:53 +0000 (16:07 +0000)]
[ARM PATCH] 2280/1: [PATCH] SIMpad: Change maintainer to me
Patch from Holger Hans Peter Freyther
Line numbers could depend on 2279/1
Change the maintainer of the SIMpad board to me. This change was discussed on the simpad linux mailinglist and was supported by the former maintainer of SIMpad. I'll subscribe and introduce myself shortly on the arm linux mailinglist and ask for SIMpad not to be removed.
Signed-off-by: Holger Hans Peter Freyther Signed-off-by: Russell King
Holger Freyther [Sun, 28 Nov 2004 16:02:29 +0000 (16:02 +0000)]
[ARM PATCH] 2279/1: [PATCH] SIMpad: Add a mq200 device to the platform bus
Patch from Holger Hans Peter Freyther
The SIMpad uses the MediaQ 200 framebuffer device. There is no driver in the vanilla kernel for that device. But adding the device to the platform bus makes it possible to just drop the mq200 driver into the kernel and the display will work.
Please consider applying the patch.
Signed-off-by: Holger Hans Peter Freyther Signed-off-by: Russell King
Alexander Viro [Sun, 28 Nov 2004 07:08:13 +0000 (23:08 -0800)]
[PATCH] iomem annotations and fixes + isa_-ectomy in msnd
* switched to ioremap() + normal operations
* split msnd_fifo_write() (and msnd_fifo_read()) into iomem and normal
versions (original was even worse - it used to do __user and __iomem
versions in the same code and in atomic context; when that bogosity
got fixed, the difference between these cases (now normal memory and
iomem) had been lost).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Sun, 28 Nov 2004 07:07:22 +0000 (23:07 -0800)]
[PATCH] seagate iomem annotations, cleanup and isa_-ectomy
* switched to ioremap()
* switched to normal iomem operations
* killed a bunch of phys_to_virt()
* killed open-coded (and inferior) instances of memcpy_toio()/memcpy_fromio().
* fixed a dumb typo introduced in "kill off isa_check_signature()"
patch (sorry - missed the fact that it was not covered by
allmodconfig and didn't verify until after sending the patch in
question ;-/).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Sat, 27 Nov 2004 06:48:17 +0000 (22:48 -0800)]
[PATCH] tpam annotations and cleanups
annotated, sanitized casts between pointers and numbers, switched the
functions that took offsets in card memory to unsigned long (from the
void *, which was absolutely wrong and lead to bogus casts from hell all
over the place).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Sat, 27 Nov 2004 06:47:26 +0000 (22:47 -0800)]
[PATCH] more sparc64 io.h annotations
Prototypes annotated the same way they are on other platforms. I'm not
too fond of readb() taking const volatile void * (sic), but AFAICS
that's the only way to tell cc(1) that both volatile and const pointers
are acceptable here ;-/
memcpy_toio/memcpy_fromio/memset_io made void - same as they are
elsewhere. And no, nobody had been insane enough to use the return
values...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
CLOCK_TICK_RATE is 12MHz on at least 2 s3c2410 based
machines, or close to it. Although this doesn't seem
to have any effect on loops_per_jiffie, it is best
to try and be accurate.
Signed-off-by: Ben Dooks Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:52:31 +0000 (20:52 +0000)]
[ARM PATCH] 2261/1: Cleanup use of ixp_reg_write in arch/arm/mach-ixp2000
Patch from Lennert Buytenhek
Several files in this directory directly dereference pointers
to on-chip I/O instead of using ixp_reg_write, making them
susceptible to IXP2400 erratum #66. This changset fixes those.
We do not touch any files that will only be built for IXP2800
systems as the 2800 does not have this issue.
Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:47:14 +0000 (20:47 +0000)]
[ARM PATCH] 2260/1: Rename IXP2000_IRQ_SWI to reduce user confusion
Patch from Lennert Buytenhek
IXP2000 interrupt source zero is a software-generated interrupt source,
but it is not an SWI in the ARM sense of the word. Rename the interrupt
source to reduce any confusion.
Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:42:00 +0000 (20:42 +0000)]
[ARM PATCH] 2259/1: Rip out ixp2000 IRQ_ERR_STATUS demultiplexing
Patch from Lennert Buytenhek
There are thirteen different IRQs chained off IRQ_ERR_STATUS, one for
each possible error class that the IXP can signal an interrupt for, but
there are no in-tree users of these interrupts, and it doesn't make much
sense to treat them as separate interrupts if we can just have one
handler checking each of the thirteen errors in one go instead.
Besides that, the error interrupt handling can't even have been working
properly in the first place as the chained handler was testing the wrong
bits in the IRQ_ERR_STATUS register.
So this patch rips it all out.
Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Deepak Saxena [Fri, 26 Nov 2004 20:30:27 +0000 (20:30 +0000)]
[ARM PATCH] 2255/1: Add IXDPG425 platform support
Patch from Deepak Saxena
New IXP425 based platform from Intel. This machine is similar to
an ADI Coyote except for the addition of an on-board NEC ECHI
controller. Patch also fixes issue with board setup for Coyote
(and IXDPG425) that would cause the MTD driver to fail.
Signed-off-by: Deepak Saxena Signed-off-by: Russell King
Ingo Molnar [Fri, 26 Nov 2004 01:08:19 +0000 (17:08 -0800)]
[PATCH] floppy boot-time detection fix
When the FDC hardware is initialized, it sometimes generates a floppy
interrupt right away - without being told to. This interrupt can hit
the detection code that executes right after the initialization code, in
particular it can get intermixed with user_reset_fdc() that the
detection code uses. The fd driver is fundamentally single-threaded
when it comes to handling events: an unexpected irq that arrives in the
wrong moment can confuse the reset_fdc() code, which, with softirq and
hardirq threading on, executes in keventd.
In the stock kernel this stale irq doesnt seem to hit the detection code
in the wrong moment, but i think under certain circumstances it may
still happen. One of the typical incarnations of the race was the
following message:
and googling for "reset set in interrupt, calling" does turn up a fair
number of bootlogs (most of them 2.4 ones) that show such a detection
failure, so i think upstream wants to have the fix too.
the fix is simple: delay a bit after initialization, to make sure the
stale irq does not interfere with the detection code. It will be safely
ignored, since do_floppy is still NULL. It might look sloppy that i went
for a delay, but delay i think it is better than waiting for the irq to
occur, because i dont think there's a guarantee that fdc initialization
triggers an interrupt, so waiting for it could hang the boot process. A
delay OTOH is totally harmless.
The attached patch implements this fix, which resolves the detection
problem on my testbox.
here's again how a failure looks like:
Floppy drive(s): fd0 is 1.44M
reset set in interrupt, calling c0258400
floppy0: no floppy controllers found
and this is how it works with the fix:
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
There is a stupid error in cfq-iosched that spews a warning on
(typically) SMP systems because cfqq->allocated[rw] goes below zero. The
error is that the increment on alloc happens outside of the queue lock.
Paul Mackerras [Fri, 26 Nov 2004 00:45:43 +0000 (16:45 -0800)]
[PATCH] ppc64: fix hang on legacy iSeries
Recently we have uncovered a bug in the kernel exception exit path
which can cause iSeries machines to hang with interrupts disabled,
typically when unloading a module. This patch fixes the bug and
should go in 2.6.10. Here is the detailed explanation:
There are a couple of places in the exception exit path in entry.S
where we disable interrupts and then later reenable them. We
hard-disable interrupts even on legacy iSeries (rather than
soft-disabling them) because the final part of the exception exit path
needs interrupts hard-disabled (even on legacy iSeries), because
otherwise an incoming interrupt could trash SRR0 and SRR1 and cause us
to lose state.
The intention was that each path that hard-disabled interrupts would
hard-enable them again, either explicitly or by executing an rfid
instruction (return from interrupt, doubleword). However there was
one path where we didn't correctly hard-enable interrupts. This meant
we could end up calling schedule() with interrupts hard-disabled and
then switch to the stopmachine thread (used in removing a module),
which spins polling a variable until another cpu changes it. Since
local_irq_enable() etc. on legacy iSeries only soft-enable interrupts,
we got into the stopmachine thread with interrupts hard-disabled, and
the machine hung at that point.
This patch fixes it by making sure that when we go to re-enable
interrupts, the MSR value we are loading up actually does have the
MSR.EE (external interrupt enable) bit set. Stephen Rothwell has
verified that this actually does fix the bug on iSeries. The bug
also potentially exists on pSeries (and this patch fixes it), but
there it doesn't really matter, because schedule() will enable
interrupts (and on pSeries that means hard-enabling them), and because
the hypervisor doesn't mind you having interrupts hard-disabled for
extended periods on pSeries. Note that all these comments about
pSeries also apply to POWER5 iSeries (i5) machines.
While I was there I noticed that we were jumping to ret_from_except
after calling do_IRQ on iSeries, rather than ret_from_except_lite,
meaning that we will restore registers 14-31 twice, unnecessarily. I
changed it to jump to ret_from_except_lite instead, and Stephen
checked that this change doesn't cause any breakage.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Zou Nanhai [Thu, 25 Nov 2004 08:00:28 +0000 (00:00 -0800)]
[PATCH] ia64/x86_64/s390 overlapping vma fix
IA64 is also vulnerable to the huge-vma-in-executable bug in 64 bit elf
support, it just insert a vma of zero page without checking overlap, so user
can construct a elf with section begin from 0x0 to trigger this BUGON().
However, I think it's safe to check overlap before we actually insert a vma
into vma list. And I also feel check vma overlap everywhere is unnecessary,
because invert_vm_struct will check it again, so the check is duplicated.
It's better to have invert_vm_struct return a value then let caller check if
it successes. Here is a patch against 2.6.10.rc2-mm3 I have tested it on
i386, x86_64 and ia64 machines.
Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Zou Nan hai <Nanhai.zou@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ppc32 PowerMac cpufreq code, when using the PMU to switch the
frequency, would eventually lose interrupts. The solution is to raise the
CPU priority at the controller level. It's also unnecessary to call the
full PIC suspend/resume code in this case as the IO chip isn't reset,
unlike the sleep code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Tom Rini [Thu, 25 Nov 2004 07:59:48 +0000 (23:59 -0800)]
[PATCH] ppc32: Have the 8260 board-hook happen a bit later
Borut Lukic <borutlukic@email.si> brought to my attention that in
platform_init() on 8260 the board hook was being called too early to allow for
overrides (e.g. different memory sizings functions or rtc, or anything else).
This moves the call to the end of platform_init() and I suspect fixes some
unnoticed yet bugs in a number of 8260 platforms.
Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Olof Johansson [Thu, 25 Nov 2004 07:59:21 +0000 (23:59 -0800)]
[PATCH] ppc64: Make early processor spinup based on physical ids
This changes the early CPU spinup code to be based on physical CPU ID
instead of logical. This will make it possible to kexec off of a
different cpu than 0, for example after it's been hot-unplugged.
The booted cpu will still be mapped as logical cpu 0, since there's various
stuff in the early boot that assumes logical boot cpuid is 0.
Also, it expands the kexec boot param structure to allow the booted physical
cpuid to be passed in. This includes bumping the version number to 2 for
backwards compat.
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Anton Blanchard [Thu, 25 Nov 2004 07:59:08 +0000 (23:59 -0800)]
[PATCH] ppc64: linux,tce* changes
Remove linux,has-tce-table since we can just look for linux,tce-base and
linux,tce-size. Make linux,tce-base store real addresses instead of virtual
ones, the wrapper may not know the translation the kernel will use.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Thu, 25 Nov 2004 07:58:26 +0000 (23:58 -0800)]
[PATCH] dont deprecate MODULE_PARM
Let's revert this for now so all those warnings do not soil our 2.6.10
release. We'll get Rusty's kernel-wide-sweep fixup patches in for 2.6.11, and
then we can put this warning back.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Mackerras [Thu, 25 Nov 2004 07:58:00 +0000 (23:58 -0800)]
[PATCH] ppc64: fix compilation with recent toolchains
The ppc64 toolchains don't create dot symbols (i.e. a globally
visible ".foo" symbol for the text of function foo) any more.
This breaks the kernel compile because we refer to function text
addresses in the system call table.
Fortunately there is an option, -mcall-aixdesc, which restores the
previous behaviour, and even more fortunately, old ppc64 toolchains
understand the option as well as new ones.
This patch adds -mcall-aixdesc to CFLAGS in arch/ppc64/Makefile.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / history.git / log