This is confirmed to fix a hang due to PCI resource conflicts with
setting up the Cardbus bridge on old laptops with the 440MX chipsets.
Original report by Alessio Sangalli, lspci debugging help by Pekka
Enberg, and trial patch suggested by Daniel Ritz:

  "From the docs available i would _guess_ this thing is really similar
   to the 82443BX/82371AB combination.  at least the SMBus base address
   register is hidden at the very same place (32bit at 0x90 in function
   3 of the "south" brigde)"

The dang thing is largely undocumented, but the patch was corroborated
by Asit Mallick:

 "I am trying to find the register information. 440MX is an integration of
  440BX north-bridge without AGP and PIIX4E (82371EB).  PIIX4 quirk
  should cover the ACPI and SMBus related I/O registers."

and verified to fix the problem by Alessio.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The nVidia CK804 PCI-E chipset supports the AER extended capability
but sometimes fails to link it (with some BIOS or after a warm reboot).
It makes the AER cap invisible to pci_find_ext_capability().

The patch adds a quirk to set the missing bit that controls the
linking of the capability.
By the way, it removes the corresponding code in the myri10ge driver.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The naming of the constant defined for PCI ID 1022:7450 does not seem
to match the information at http://pciids.sourceforge.net/:

    http://pci-ids.ucw.cz/iii/?i=1022

There 1022:7450 is listed as "AMD-8131 PCI-X Bridge" while 1022:7451
is listed as "AMD-8131 PCI-X IOAPIC".  Yet, the current definition for
0x7450 is PCI_DEVICE_ID_AMD_8131_APIC.      It seems to me like that name
should map to 0x7451, while a name like PCI_DEVICE_ID_AMD_8131_BRIDGE
should map to 0x7450.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

<linux/mempolicy.h> uses struct mm_struct and relies on a definition or
declaration somehow magically being dragged in which may result in a
build:

  CC      mm/mempolicy.o
In file included from mm/mempolicy.c:69:
include/linux/mempolicy.h:150: warning: 'struct mm_struct' declared inside parameter list
include/linux/mempolicy.h:150: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/mempolicy.h:174: warning: 'struct mm_struct' declared inside parameter list
mm/mempolicy.c:673: error: conflicting types for 'do_migrate_pages'
include/linux/mempolicy.h:174: error: previous declaration of 'do_migrate_pages' was here
mm/mempolicy.c:1696: error: conflicting types for 'mpol_rebind_mm'
include/linux/mempolicy.h:150: error: previous declaration of 'mpol_rebind_mm' was here
make[1]: *** [mm/mempolicy.o] Error 1
make: *** [mm] Error 2
$

Including <linux/sched.h> is a step into direction of include hell so
fixed by adding a forward declaration of struct mm_struct instead.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Make sure to properly clamp maxnum to avoid overflow (CVE-2006-5751).
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Stephen Hemminger <shemminger@osdl.org>
Acked-by: David Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

fcntl(F_SETSIG) no longer works on leases because
lease_release_private_callback() gets called as the lease is copied in
order to initialise it.

The problem is that lease_alloc() performs an unnecessary initialisation,
which sets the lease_manager_ops.  Avoid the problem by allocating the
target lease structure using locks_alloc_lock().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

cciss needs to call disk_stat_add() for iostat to work.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

cpqarray needs to call disk_stat_add() for iostat to work.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Configuration bits are not set properly for DMA on some chipset revisions.
It has already been corrected for M5229 (rev c7) but not for M5229 (rev
c8).  This leads to the bug described at
http://bugzilla.kernel.org/show_bug.cgi?id=5786 (lost interrupt + ide bus
hangs).
Signed-off-by: Michael De Backer <micdb@skynet.be>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

There appears to be a typo in the EV56 config option. NORITAKE and PRIMO are
be able to set a variation of either.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

port is dereferenced even if it is NULL.  Dereference it _after_ the
check if (!port)...  Thanks Eric <ef87@yahoo.com> for reporting this.

This fixes

        http://bugzilla.kernel.org/show_bug.cgi?id=7527Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

MX300 does not have an EXTRA_BTN - it is a simple wheel mouse with
an additional task-switcher button, which is reported as side button
(and not task button).
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

An up() is called in kernel/stop_machine.c on failure, and also in the
caller (unconditionally).
Signed-off-by: Zhou Yingchao <yingchao.zhou@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

No need to revisit a chain we'd already finished with during
the check for current hook.  It's either instant loop (which
we'd just detected) or a duplicate work.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

We need that for iterator to work; existing check had been too weak.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

We need to verify that
    a) we are not too close to the end of buffer to dereference
    b) next entry we'll be checking won't be _before_ our

While we are at it, don't subtract unrelated pointers...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The tc actions increased the size of struct tc_police, which broke
compatibility with old iproute binaries since both the act_police
and the old NET_CLS_POLICE code check for an exact size match.

Since the new members are not even used, the simple fix is to also
accept the size of the old structure. Dumping is not affected since
old userspace will receive a bigger structure, which is handled fine.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Not returning -EINVAL, because someone might want to use the value
zero in some future gact_prob algorithm?
Signed-off-by: Kim Nordlund <kim.nordlund@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

diRead and diWrite are representing the page number as an unsigned int.
This causes file system corruption on volumes larger than 16TB.
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

TCP and RAW do not have this issue.  Closes Bug #7432.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Spotted by Thomas Voegtle.
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Commit 7b2fd697427e73c81d5fa659efd91bd07d303b0e in the historical GIT tree
stopped calling the readdir member of a file_operations struct with the big
kernel lock held, and fixed up all the readdir functions to do their own
locking.  However, that change added calls to unlock_kernel() in
vxfs_readdir, but no call to lock_kernel().  Fix this by adding a call to
lock_kernel().
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

This patch removes a module_exit function that sgiioc4 should not have had.

It seems that the IDE layer doesn't support submodule unloading. sgiioc4
was the only driver in drivers/ide/pci that had an exit function.
After an unload, the devices would stay around and the next attempt to
reference would crash...
Signed-off-by: Jeremy Higdon <jeremy@sgi.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Convert various spin_lock_irqsave() callers to correctly use `unsigned long'
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Backported from a patch by Mariusz Kozlowski <m.kozlowski@tuxland.pl>
in 2.6.19.
Signed-off-by: Adrian Bunk <bunk@stusta.de>

elv_iosched_show function iterates other elv_list,
hence elv_list_lock should be got.

Also the question is: in elv_iosched_show, elv_iosched_store
q->elevator->elevator_type construction is used without locking q->queue_lock.
Is it expected?..
Signed-off-by: Vasily Tarasov <vtaras@openvz.org>
Acked-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Contrary to what the name misleads you to believe, SG_DXFER_TO_FROM_DEV
is really just a normal read seen from the device side.

This patch fixes http://lkml.org/lkml/2006/10/13/100Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

if urb submission fails due to a transient error here eg. ENOMEM,
the driver is dead. This fixes it.
Signed-off-by: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Fix binary/logical operator typo which leads to unreachable code.  Noticed
while looking at other issues; I don't have the relevant hardware to test
this.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The following patch resolves the divide by zero error I encountered on my
system:

        http://marc.10east.com/?l=linux-fbdev-devel&m=116058257024413&w=2

I accomplished this by merging what I thought was appropriate from:

        http://webcvs.freedesktop.org/xorg/driver/xf86-video-nv/src/Signed-off-by: Adrian Bunk <bunk@stusta.de>

Both MMC and SD specifications specify (although a bit unclearly in the MMC
case) that a sector size of 512 bytes must always be supported by the card.

Cards can report larger "native" size than this, and cards >= 2 GB even
must do so. Most other readers use 512 bytes even for these cards. We should
do the same to be compatible.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

I was looking at a RHEL5 bug report involving Xen and SCTP
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550).
It turns out that SCTP wasn't written to handle skb fragments at
all.  The absence of any calls to skb_may_pull is testament to
that.

It just so happens that Xen creates fragmented packets more often
than other scenarios (header & data split when going from domU to
dom0).  That's what caused this bug to show up.

Until someone has the time sits down and audits the entire net/sctp
directory, here is a conservative and safe solution that simply
linearises all packets on input.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

sbi->s_group_desc is an array of pointers to buffer_head.  memcpy() of
buffer size from address of buffer_head is a bad idea - it will generate
junk in any case, may oops if buffer_head is close to the end of slab
page and next page is not mapped and isn't what was intended there.
IOW, ->b_data is missing in that call.  Fortunately, result doesn't go
into the primary on-disk data structures, so only backup ones get crap
written to them; that had allowed this bug to remain unnoticed until
now.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Looks like a broken masking to me, binary not is used where bitwise
not was intended.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Make udp_encap_rcv use pskb_may_pull

IPsec with NAT-T breaks on some notebooks using the latest e1000 chipset,
when header split is enabled. When receiving sufficiently large packets, the
driver puts everything up to and including the UDP header into the header
portion of the skb, and the rest goes into the paged part. udp_encap_rcv
forgets to use pskb_may_pull, and fails to decapsulate it. Instead, it
passes it up it to the IKE daemon.
Signed-off-by: Olaf Kirch <okir@suse.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>