1) We send out a normal sized packet with TSO on to start off.
2) ICMP is received indicating a smaller MTU.
3) We send the current sk_send_head which needs to be fragmented
since it was created before the ICMP event. The first fragment
is then sent out.
At this point the remaining fragment is allocated by tcp_fragment.
However, its size is padded to fit the L1 cache-line size therefore
creating tail-room up to 124 bytes long.
This fragment will also be sitting at sk_send_head.
4) tcp_sendmsg is called again and it stores data in the tail-room of
of the fragment.
5) tcp_push_one is called by tcp_sendmsg which then calls tso_fragment
since the packet as a whole exceeds the MTU.
At this point we have a packet that has data in the head area being
fed to tso_fragment which bombs out.
My take on this is that we shouldn't ever call tcp_fragment on a TSO
socket for a packet that is yet to be transmitted since this creates
a packet on sk_send_head that cannot be extended.
So here is a patch to change it so that tso_fragment is always used
in this case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
When packets hit raw sockets the csum update isn't done yet, do it manually.
Packets can also reach rawv6_rcv on the output path through
ip6_call_ra_chain, in this case skb->ip_summed is CHECKSUM_NONE and this
codepath isn't executed.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Patch from Dimitry Andric
This patch removes the initial UART I/O mapping from s3c2410_iodesc,
since the same mapping is already done in the function s3c24xx_init_io
in the file arch/arm/mach-s3c2410/cpu.c, through the s3c_iodesc array.
I'm not sure if duplicate mappings do any harm, but it's simply
redundant. Also, in s3c2440.c the UART I/O mapping is NOT done.
Additionally, I put a comma behind the last mapping, to ease
copy/pasting stuff around, and make the style consistent with
s3c2440.c and other files.
Signed-off-by: Dimitry Andric <dimitry@andric.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Sean Lee
In the arch/arm/mm/Kconfig file, the CPU_DCACHE_WRITETHROUGH
option is depend on the CPU_DISABLE_DCACHE, but the "Disable
D-Cache" option is configured as CPU_DCACHE_DISABLE.
The CPU_DISABLE_DCACHE should be CPU_DCACHE_DISABLE
Signed-off-by: Sean Lee <beginner2arm@eyou.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Paulus suggested that we put xLparMap in its own .c file so that we can
generate a .s file to be included into head.S. This doesn't get around
the problem of having it at a fixed address, but it makes it more
palatable.
It would be good if this could be included in 2.6.13 as it solves our
build problems with various versions of binutils and gcc. In
particular, it allows us to build an iSeries kernel on Debian unstable
using their biarch compiler.
This has been built and booted on iSeries and built for pSeries and g5.
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>
This removes very old functions from pci docs, which are no longer in
the kernel.
Signed-off-by: Jiri Slaby <xslaby@fi.muni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together.
This patch will prevent MSI from being enabled for the SHPC as part of
an early pci quirk, as well as on any pci device which sets the no_msi
bit.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This moves the code to free devt_attr from class_device_del() to
class_dev_release() which is called after the last reference to the
corresponding kobject() is gone.
This allows us to keep the devt_attr alive while the corresponding
sysfs file is open.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Changing it to how ip_input handles should fix it.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
1) We send out a normal sized packet with TSO on to start off.
2) ICMP is received indicating a smaller MTU.
3) We send the current sk_send_head which needs to be fragmented
since it was created before the ICMP event. The first fragment
is then sent out.
At this point the remaining fragment is allocated by tcp_fragment.
However, its size is padded to fit the L1 cache-line size therefore
creating tail-room up to 124 bytes long.
This fragment will also be sitting at sk_send_head.
4) tcp_sendmsg is called again and it stores data in the tail-room of
of the fragment.
5) tcp_push_one is called by tcp_sendmsg which then calls tso_fragment
since the packet as a whole exceeds the MTU.
At this point we have a packet that has data in the head area being
fed to tso_fragment which bombs out.
My take on this is that we shouldn't ever call tcp_fragment on a TSO
socket for a packet that is yet to be transmitted since this creates
a packet on sk_send_head that cannot be extended.
So here is a patch to change it so that tso_fragment is always used
in this case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
When packets hit raw sockets the csum update isn't done yet, do it manually.
Packets can also reach rawv6_rcv on the output path through
ip6_call_ra_chain, in this case skb->ip_summed is CHECKSUM_NONE and this
codepath isn't executed.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Just `make oldconfig' doesn't help for the zx1 defconfig ---
because we need the MPT Fusion drivers, which are picked up as not
selected.
Tested on HP ZX2000 and ZX2600.
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Tony Luck <tony.luck@intel.com>
The main issue is that bus_fixup calls may potentially call
functions that require a valid bus->sysdata pointer. Since
this is the case, we must set the bus->sysdata pointer before
calling the bus_fixup functions. The remaining changes are
simple fixes to make sure memory is cleaned up in the function.
Signed-off-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Chuck Ebbert noticed that the desc_empty macro is incorrect. Fix it.
Thankfully, this is not used as a security check, but it can falsely
overwrite TLS segments with carefully chosen base / limits. I do not
believe this is an issue in practice, but it is a kernel bug.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
[ x86-64 had the same problem, and the same fix. Linus ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When the client performs an exclusive create and opens the file for writing,
a Netapp filer will first create the file using the mode 01777. It does this
since an NFSv3/v4 exclusive create cannot immediately set the mode bits.
The 01777 mode then gets put into the inode->i_mode. After the file creation
is successful, we then do a setattr to change the mode to the correct value
(as per the NFS spec).
The problem is that nfs_refresh_inode() no longer updates inode->i_mode, so
the latter retains the 01777 mode. A bit later, the VFS notices this, and calls
remove_suid(). This of course now resets the file mode to inode->i_mode & 0777.
Hey presto, the file mode on the server is now magically changed to 0777. Duh...
Fixes http://bugzilla.linux-nfs.org/show_bug.cgi?id=32
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
the buffers when mapping them after the VM had discarded them.
Thanks to Martin MOKREJŠ for the bug report.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
The current one doesn't even make sense anymore on i386 where it
apparently came from.
Follow-up wordsmithing by Matthew Wilcox and Tony Luck.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
When both platform-specific and generic drivers exist,
enable generic over-ride with "acpi_generic_hotkey".
http://bugzilla.kernel.org/show_bug.cgi?id=4953
Signed-off-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Patch from Richard Purdie
The exception handling code fails to compile if the extended
precision mode is enabled. This patch fixes those compile errors and
also stops _quiet functions from incorrectly raising exceptions.
Reported-by: Ralph Siemsen <ralphs@netwinder.org>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reported by: Pavel Kysilka (Bugzilla Bug 5059)
The intelfb driver does not keep resolution set with fbset after
switching to anot console and back.
Steps to reproduce:
initial options: tty1,tty2 - 1024x768-60
1) tty1 - fbset after booting (1024x768-60)
2) tty1 - fbset 800x600-100
tty1: 800x600-100
3) swith to tty2, swith to tty1
tty1: 1024x768-60 (the same resolution as default from kernel booting)
This bug is caused by intelfb unintentionally destroying info->flags in
set_par(). Therefore the flag, FBINFO_MISC_USEREVENT used to notify
fbcon of a mode change was cleared causing the above problem. This bug
though is not intelfb specific, as other drivers may also be affected.
The fix is to save info->flags in a local variable before calling any
of the driver hooks. A more definitive fix (for post 2.6.13) is to
separate info->flags into one that is set by the driver and another that
is set by core fbdev/fbcon.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Pavel Kysilka (Bugzilla Bug 4738)
modprobe of intelfb results in the following error message:
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chi
intelfb: Version 0.9.2
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
allocation failed: out of vmalloc space - use vmalloc=<size> to increase siz
intelfb: Cannot remap FB region.
This will fail if the graphics aperture size is greater than 128 MB.
Fix is to ioremap only from the beginning of graphics aperture to the
end of the used framebuffer memory.
Signed-off-by: Sylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds a MOVE_SELF event to inotify. It is sent whenever the inode
you are watching is moved. We need this event so that we can catch
something like this:
- app1:
watch /etc/mtab
- app2:
cp /etc/mtab /tmp/mtab-work
mv /etc/mtab /etc/mtab~
mv /tmp/mtab-work /etc/mtab
app1 still thinks it's watching /etc/mtab but it's actually watching
/etc/mtab~.
Signed-off-by: John McCutchan <ttb@tentacle.dhs.org>
Signed-off-by: Robert Love <rml@novell.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We are saving the wrong thing in ->last_wd. We want the wd, not the
return value.
Signed-off-by: Robert Love <rml@novell.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
IEEE 802.11 has a capability field flag called ESS, but ieee80211 had
renamed this to BSS for some reason. hostap has been using
WLAN_CAPABILITY_ESS and since that matches with the standard, lets use
it as the name for this define. Add WLAN_CAPABILITY_BSS as a backwards
compatibility name for the same bit since ieee80211 and ipw2200 are
using this and there are versions outside kernel tree that expect to
find this define name.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
IEEE 802.11 frame control has two bits reserved for protocol
version. IEEE80211_FCTL_VERS was not used anywhere, but I would assume
it was supposed to be a mask for the protocol field and as such, it
should be 0x0003, not 0x0002. This matches with WLAN_FC_PVER
definition in hostap.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
This reverts commits
71db63acff
[PATCH] increase PCIBIOS_MIN_IO on x86
and
0b2bfb4e7f
ACPI: increase PCIBIOS_MIN_IO on x86
since Lukas Sandströ<lukass@etek.chalmers.se> reports that this breaks
his on-board nvidia audio.
We should re-visit this later. For now we revert the change
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It introduces a repeatable oops in the driver, which is a bigger problem
than the patch tries to solve. From the original description:
Author: Jamie Lenehan <lenehan@twibble.org>
Date: Thu Mar 3 14:41:40 2005 +0200
[PATCH] dc395x: Fix support for highmem
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Removes the page_to_virt and maps sg lists dynamically.
This makes the driver work with highmem pages.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Jamie Lenehan <lenehan@twibble.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix path name conversion for long filenames when mapchars mount option
was specified at mount time.
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
