Herbert Xu [Sat, 31 Jul 2004 16:39:29 +0000 (09:39 -0700)]
[PF_KEY]: spirange should be in host byte order.
I'm looking through the xfrm_alloc_spi stuff and noticed that the
netlink alloc_spi function takes the range in host order while the
PFKEY alloc_spi function takes them in network order.
First I thought that I stuffed up since I was the one who changed
the code in the netlink interface to take them in host order :)
But reading RFC 2367 seems to indicate otherwise. It says that all
fields are host order unless specified otherwise. And the spirange
fields are not specified to be network order at all.
Looking at the existing PFKEY users:
User Space
----------
Openswan - Doesn't use PFKEY for this.
Racoon - Puts zeros in there so it doesn't care. However its test-pfkey
program stores things in host order.
ISAKMPD - Stores things in host order.
So the conclusion is that we can and should change our PFKEY
implementation to use host order for these fields.
This patch does exactly that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
Herbert Xu [Sat, 31 Jul 2004 16:33:16 +0000 (09:33 -0700)]
[IPSEC]: xfrm_alloc_spi always succeeds on non-trivial range
xfrm_alloc_spi will always succeed if minspi < maxspi, even if
minspi + 1 == maxspi. If the range is already occupied this
will obviously lead to breakage.
Of course this is very unlikely to occur in reality due to the
size of the range. Although with IPCOMP it might actually happen
on a very large server.
The fix is obivous.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
Herbert Xu [Sat, 31 Jul 2004 16:30:00 +0000 (09:30 -0700)]
[IPSEC]: Remove redundant check in xfrm_state_add()
This is the patch referred to in the netlink_get_spi thread.
I was actually wrong about the reason for this patch though. Firstly
it's the SPI check that is redundant and not the find_acq() call.
And it's redundant because of the find_acq() patch, not because
of the fact that this is in xfrm_state_add().
Now that find_acq() only returns SAs with SPIs, we don't need to
check this in xfrm_state_add() anymore.
We do still need the call though to clean up leftover larval states.
Another side-effect of the change is that we can move the existence
check above find_acq() since find_acq() will never return any SAs
matching the SPI we're trying to add (It doesn't need to because if
an SA with a matching SPI existed, it would've been returned by
state_lookup() already).
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
Herbert Xu [Sat, 31 Jul 2004 16:28:27 +0000 (09:28 -0700)]
[IPSEC]: Fix SPI generation by netlink_get_spi()
The issue is that two successive calls to netlink_get_spi is returning
the same SA. Since netlink_get_spi is meant to be a creation operation
this is incorrect.
The netlink_get_spi operation is modelled off the PFKEY SADB_GETSPI
command which is specified in RFC 2367. The purpose of SADB_GETSPI
is to create a new larval SA that can then be filled in by SADB_UPDATE.
Its semantics does not allow two SADB_GETSPI calls to return the same
SA, even if there is no SADB_UPDATE call in between.
The reason the second netlink_get_spi is returning the same SA is
because in find_acq(), the code is looking at all larval states as
opposed to only larval states with an SPI of zero.
Since the only other caller of find_acq() -- xfrm_state_add() intentionally
ignores all return values with a non-zero SPI, it is safe to not look at
SAs with non-zero SPIs at all in find_acq().
The following patch does exactly that.
In fact, the find_acq() call in xfrm_state_add() is a remnant from
the days when we had xfrm_state_replace() instead of xfrm_state_add()
and xfrm_state_update(). It can now be safely removed.
I'll post a separate patch for that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
The problem is that after a successful connection between the Windows
Bluetooth stack and the Linux Bluez stack, no packets from the device
ever reach the PC running Windows XP Service Pack 2. That is, a ping
from the PC never receives a response, and a ping from BlueZ never
reaches the PC. Linux packet statistics show that the PC packets are
received, but all return traffic seems to be routed over the loopback
interface.
Immediately after creating the BNEP connection with BlueZ, the Windows
Bluetooth stack sends a BNEP_FILTER_NET_TYPE_SET_MSG with an effective
length of zero. BlueZ interprets this message to mean that no filter
ranges should be allowed. The code zeros the first entry in the filter
list, which is than interpreted as meaning that no ranges of acceptable
packets are available. This interpretation is wrong and leads to all
packets being rejected by BNEP.
The Bluetooth BNEP specification clearly states the following:
The length (in octets) of this message is 4+4*N, where N is the number
of disjoint ranges of Networking protocol types that form the complete
set. Note that N=0 (empty set) denotes a reset to default filters (if
any) supported by the remote device.
Alan Cox [Sat, 31 Jul 2004 11:34:32 +0000 (04:34 -0700)]
[PATCH] PATCH: Fix HPT366 crash and support HPT372N
On a board containing the HPT372N IDE controller the 2.6.x series kernels will
misbehave. If the HPT372N is set up with the newer PCI identifier it is
ignored. If it is set up with the HPT372 identifier then the kernel crashes
on boot.
This patch is a forward port of my 2.4 driver fixes that have been in 2.4
for a year but somehow escaped 2.6. Ronny Buchmann caught a couple
of merge details I missed and those are fixed in this diff too.
As well as adding 372N support this also fixes the unknown revision case
to avoid crashes should any future 37x variants with weird class_rev's appear
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Sat, 31 Jul 2004 07:47:41 +0000 (00:47 -0700)]
[PATCH] slab memory shrinking balancing fix
The logic in shrink_slab tries to balance the proportion of slab which it
scans against the proportion of pagecache which the caller scanned. Problem
is that with a large number of highmem LRU pages and a small number of lowmem
LRU pages, the amount of pagecache scanning appears to be very small, so we
don't push slab hard enough.
The patch changes things so that for, say, a GFP_KERNEL allocation attempt we
only consider ZONE_NORMAL and ZONE_DMA when calculating "what proportion of
the LRU did the caller just scan".
This will have the effect of shrinking slab harder in response to GFP_KERNEL
allocations than for GFP_HIGHMEM allocations.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Tom Rini [Sat, 31 Jul 2004 07:06:38 +0000 (00:06 -0700)]
[PATCH] ppc32: fix compilation with binutils-2.15
Currently, ppc32 will not always compile with binutils-2.15. The issue
is that binutils has become even more strict about which opcodes can be
used with which CPU flags. The problem is that we have a number of
cases where we compile with altivec instructions (with runtime checks to
make sure we can actually run them) in code that's not altivec specific.
The fix for this is to always pass in -maltivec on CONFIG_6xx. To do
this cleanly, we split our AFLAGS definition up into
aflags-$(CONFIG_FOO).
Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Fri, 30 Jul 2004 15:49:36 +0000 (08:49 -0700)]
[PATCH] sparse: misc cleanups
all sorts of minor stuff - basically, all chunks are independent here,
but IMO that one is not worth splitting. Contains:
* pmac_cpufreq.c: declaration in the middle of a block.
* sys_ia32.c: couple of trivial annotations.
* ipmi_si_intf.c: should be using asm/irq.h instead of linux/irq.h
* synclink_cs.c: assignment-in-conditional with nobody ever looking
at the variable we are assigning to afterwards; variable removed.
* sbni.c: s/__volatile/__volatile__
* matroxfb_base.h: got rid of ((u32 *)p)++
* asm-ppc/checksum.h and asm-sparc64/floppy.h: NULL noise removal
* amd64 compat.h: missing L in long constant.
* mtd-abi.h: annotated ioctl structure
* sysctl.c: corrected annotations in extern
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Robin Holt [Fri, 30 Jul 2004 21:11:13 +0000 (21:11 +0000)]
bte_error.c:
bte.c:
After working with the chip designer some more, we have determined one
more hardware register we were supposed to write to ensure the SHUB
chip was ready for future transfers. This patch fixes that. This also
allowed us to eliminate a udelay which was working around the problem.
During retesting, we uncovered a race condition where transfer status
was changed by a different cpu after we were expecting one value which
cascaded to additional problems. This patch uses a local variable to
also eliminate that race.
Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Pat Gefre [Fri, 30 Jul 2004 20:26:30 +0000 (20:26 +0000)]
sn_console.c:
move sn_debug_printf to only compile for DEBUG
early printk needs to handle missing carriage returns Signed-off-by: Pat Gefre <pfg@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Alexander Viro [Thu, 29 Jul 2004 15:48:53 +0000 (08:48 -0700)]
[PATCH] cmap annotations
fb_set_cmap() and fb_copy_cmap() split into kernel and userland versions.
fb_cmap, fb_image and fb_cursor split and annotated.
fixed bug in sbuslib.c that used to call "userland" version of fb_set_cmap()
when kernel one was need (RGB data was already copied into kernel space).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 29 Jul 2004 15:48:06 +0000 (08:48 -0700)]
[PATCH] fbcon_do_set_font() sanitized
fbcon internal cleanup. Instead of passing console_font_op into
fbcon_do_set_font() we pass width/height directly. Amusing (but harmless)
bug fixed there:
if (!w > 32) {
bogus code that fortunately never got triggered
}
Fixed by removal of the junk in question (and yes, it's verifiable junk -
it would not do anything even if we replaced the check with intended
!(w > 32)).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 29 Jul 2004 15:47:55 +0000 (08:47 -0700)]
[PATCH] con_set_font sanitized
con_font_set() sanitized. We are passing console_font and flags into
the method in separate arguments and we are not messing with
console_font_op->data anymore - it's a userland pointer (to be annotated
several patches later in the series, due to another abuse of console_font_op
that needs to be fixed first), while console_font->data is kernel one
and they don't mix anymore.
We also do a sanity check (font width > 0) in the caller instead of
method instances, since we are already checking for width <= 32 and
height <= 32 there; doesn't make sense leaving that one in method
instances.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 29 Jul 2004 15:47:43 +0000 (08:47 -0700)]
[PATCH] con_font_copy sanitized
->con_font_copy() sanitized. We extract the number of console to copy the
font from in the caller (it's taken from the field of console_font_op that
is normally used for font height - messy even for an ioctl, but that animal
used to be passed all the way down into console drivers).
With decoding done in con_font_copy(), we simply pass source console number
into the method.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 29 Jul 2004 15:47:32 +0000 (08:47 -0700)]
[PATCH] con_font_default sanitized
->con_font_default() sanitized. We copy font name (if any) from userland
in the caller and pass it explicitly. We are also beginning to get rid
of console_font_op in method arguments.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 29 Jul 2004 15:47:21 +0000 (08:47 -0700)]
[PATCH] con_font_op split
Preparations for cleanups: con_font_op() is turned into a switch calling
con_font_{get,set,default,copy} depending on the operation required;
method ->con_font_op() also split, with NULL resulting in -ENOSYS on
operation in question.
Code that used to be in con_font_op() got slightly cleaned up after move
into new helpers (we are beginning to untangle the mess; there will be
more cleanups in the next patches).
Methods are currently using exact same arguments as old ->con_font_op().
That will change in subsequent patches, method by method (right now there's
a hell of a scary field reuse between them, making impossible to do any
static checks and practically begging for bugs).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes some possible rare issues with the hash code beeing called
with interrupts enabled from update_mmu_cache, and fixes some races in
the iSeries low level htab code by adding an array of spinlocks
This is actually an old patch already present in SLES kernel and that
got "missed" somewhat in the main tree, adapted to recent changes.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Herbert Xu [Thu, 29 Jul 2004 12:07:16 +0000 (05:07 -0700)]
[AH6]: Rearrange routing headers
This patch rearranges the IPv6 routing header so that the destination
addresses appear in the order as they would on the destination. This
is specified in Appendix A2 of RFC 2402.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
David S. Miller [Thu, 29 Jul 2004 10:34:40 +0000 (03:34 -0700)]
[NET]: Decrease skb->cb[] to 40 bytes.
No control block usage, even on 64-bit, needs
the full current 48 bytes. This brings sk_buff
size down to 256 bytes on 64-bit platforms and
fixes some performance regressions due to the
addition of the input_dev member.
Herbert Xu [Thu, 29 Jul 2004 08:48:49 +0000 (01:48 -0700)]
[NET]: Allow MD5 to be a module
I found that recent 2.6 kernels no longer allowed me to build MD5 as
a module even though everything that used it were modules (including
ipv6 and sctp). It turns out that there were boolean options
selecting MD5 in the Kconfig files. Due to limitations in the current
kconfig implementation, this forces MD5 to be a boolean as well.
The usual workaround in these cases is to move the selection up
to the closest tristate. This is what the following patch does.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
gcc-3.4.1 errors out in 2.6.8-rc1-mm1 at net/sunrpc/xprt.c:
net/sunrpc/xprt.c: In function 'xprt_reserve':
net/sunrpc/xprt.c:84: sorry, unimplemented: inlining failed in call to 'do_xprt_reserve': function body not available
net/sunrpc/xprt.c:1307: sorry, unimplemented: called from here
make[2]: *** [net/sunrpc/xprt.o] Error 1
make[1]: *** [net/sunrpc] Error 2
make: *** [net] Error 2
do_xprt_reserve() is marked inline but used defore its function
body is available. Moving it before its only caller fixes the problem.
Signed-off-by: Mikael Pettersson <mikpe@csd.uu.se> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@redhat.com>
This makes bridge port status reflect both the state of the interface
from software (up/down) and the carrier. It makes STP handle link failure
(cable breakage, etc). The original concept comes from a
Mark Ruijter <bridge@siennax.com> who implemented it differently.
My way is simpler and requires no polling.
Obviously, this link state detection will only work if the network card
handles the events properly.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@redhat.com>
Need to propagate MTU changes that the bridge does to it's pseudo interface
up to others. There ends up being a double call to br_min_mtu() but that's
harmless.
Cleans up the EXPORT_SYMBOLS including dev_change_flags which is used by vlan.
Shouldn't be basing exports on kernel config options like this.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@redhat.com>
Tony Luck [Wed, 28 Jul 2004 17:57:12 +0000 (17:57 +0000)]
# Signed-off-by: Gordon Jin <gordon.jin@intel.com>
# Signed-off-by: Arun Sharma <arun.sharma@intel.com>
# Signed-off-by: Tony Luck <tony.luck@intel.com>
[PATCH] Watchdog driver for Intel IXP2000 Network Processor
Following patch adds support for the watchdog driver embedded in Intel's
IXP2000 family of network processors. The architecture-specific bits of
IXP2000 support will be merged upstream via the ARM tree once all the
various drivers have been merged.
Olaf Hering [Wed, 28 Jul 2004 16:13:40 +0000 (09:13 -0700)]
[PATCH] mark swim3 floppy controller as removable device
Mark the mac floppy controller driver as removable media. This prevents an
entry in /proc/partitions. Several tools will not try to access the floppy
anymore with this change.
Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrea Arcangeli [Wed, 28 Jul 2004 16:13:18 +0000 (09:13 -0700)]
[PATCH] writepages drops bh on not uptodate page
I think I understood why some ext2 fs corruption still happens even after
the last i_size fix.
what happened I believe is that the writepages layer got a not a fully
uptodate page (in turn with bh mapped on top of it), and then right before
unlocking the page and entering the writeback mode, it freed all the bh.
Without bh a not uptodate page will trigger a full readpage from disk, that
overwrites the pagecache before the multi-bio gets submitted, generating fs
corruption.
I believe the below patch should fix it (untested) against kernel CVS.
The testcases developed by Kurt showed the pagecache being overwritten with
on-disk data at block offsets, and Chris as well was wondering about races
between wait_on_page_writeback and readpage. the below fix just explains
everything we've seen since not-fully-uptodate pages must have always bh on
them and the below patch enforces just that invariant, and it should fix
our pagecache-overwritten-by-disk-data problem.
Signed-off-by: Andrea Arcangeli <andrea@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alan Cox [Wed, 28 Jul 2004 16:12:55 +0000 (09:12 -0700)]
[PATCH] Subject: PATCH: fix bogus ioctl return in mtrr
This is fairly self explanatory - ENOIOCTLCMD is an internal code outside
of the -1 to -511 range. The correct return for an unknown ioctl is
-ENOTTY although some Linux devices return the incorrect -EINVAL result.
Patch-By: Alan Cox <alan@redhat.com>
OSDL Developer Certificate of Origin 1.0 included herein by reference
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / history.git / log