This one adds another vendor ID to rtl8150 driver.
Signed-off-by: Petko Manolov <petkan@nucleusys.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

I just got a "ZyXEL Prestige USB Adapter" that is actually RTL8150
adapter.  Here is the relevant /proc/bus/usb/devices output (after
adding the vendor/product IDs to the driver):

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=119 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0586 ProdID=401a Rev= 1.00
S:  Manufacturer=ZyXEL
S:  Product=Prestige USB Adapter
S:  SerialNumber=1027
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=120mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=rtl8150
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=1ms

This patch adds the ZyXEL vendor ID to the rtl8150.c driver.  The
device has absolutely no identifying marks on the outside for model
type, just a serial number, and I can't find anything on ZyXEL's
website, so I called the product ID PRODUCT_ID_PRESTIGE to match the
product string.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Add a workaround for dual port PCI-X card that returns status out of
order sometimes because of split transactions.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

This driver uses port 0 to handle receives on both ports. So
the netif_poll_disable call in dev_close would end up stopping the
second port on dual port cards.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

That code doesn't do what its author apparently thought it would do...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

6.5.7(5): The result of E1 >> E2 is E1 right-shifted E2 bit positions.
            ...
    If E1 has a signed type and a negative value, the resulting value
    is implementation defined.

So, cast -1 to unsigned type to make result well-defined.

[ Modified to use ~0U based upon recommendation from Al Viro. -DaveM ]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

gcc emits the following warning:

drivers/atm/firestream.c: In function ‘fs_open’:
drivers/atm/firestream.c:870: warning: ‘tmc0’ may be used uninitialized in this function

This indicates a real bug.  We should check make_rate() return value for
potential errors.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Thanks to Randy Dunlap.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Fix the key serial number collision avoidance code in key_alloc_serial().

This didn't use to be so much of a problem as the key serial numbers were
allocated from a simple incremental counter, and it would have to go through
two billion keys before it could possibly encounter a collision.  However, n
that random numbers are used instead, collisions are much more likely.

This is fixed by finding a hole in the rbtree where the next unused serial
number ought to be and using that by going almost back to the top of the
insertion routine and redoing the insertion with the new serial number rathe
than trying to be clever and attempting to work out the insertion point
pointer directly.

This fixes kernel Bugzilla #7727.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:

static int return_EIO(void)
{
        return -EIO;
}

#define EIO_ERROR ((void *) (return_EIO))

static struct inode_operations bad_inode_ops =
{
        .create         = bad_inode_create
...etc...

The problem here is that the void cast causes return types to not be
promoted, and for ops such as listxattr which expect more than 32 bits of
return value, the 32-bit -EIO is interpreted as a large positive 64-bit
number, i.e. 0x00000000fffffffa instead of 0xfffffffa.

This goes particularly badly when the return value is taken as a number of
bytes to copy into, say, a user's buffer for example...

I originally had coded up the fix by creating a return_EIO_<TYPE> macro
for each return type, like this:

static int return_EIO_int(void)
{
    return -EIO;
}
#define EIO_ERROR_INT ((void *) (return_EIO_int))

static struct inode_operations bad_inode_ops =
{
    .create         = EIO_ERROR_INT,
...etc...

but Al felt that it was probably better to create an EIO-returner for each
actual op signature.  Since so few ops share a signature, I just went ahead
& created an EIO function for each individual file & inode op that returns
a value.

Adrian Bunk:
backported to 2.6.16
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The PSM values below 0x1001 of L2CAP are reserved for well known
services. Restrict the possibility to bind them to privileged
users.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The PSM value in the L2CAP socket list must be converted to host
order before printing it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Due to type confusion, when an nfsacl verison 2 'ACCESS' request
finishes and tries to clean up, it calls fh_put on entiredly the
wrong thing and this can cause an oops.
Signed-off-by: Adrian Bunk <bunk@stusta.de>

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>

Use the same signal frame alignment calculations as the underlying
architecture.  x86_64 appeared to do this, but the "- 8" was really
subtracting 8 * sizeof(struct rt_sigframe) rather than 8 bytes.

UML/i386 might have been OK, but I changed the calculation to match
i386 just to be sure.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Despite being under linux/, linux/irq.h shouldn't be #include'd by arch
independent code.
Signed-off-by: Adrian Bunk <bunk@stusta.de>

This reverts commit ac4d63da.

Does not work in 2.6.16.

Some of the instances of tcp_sack_block are host-endian, some - net-endian.
Define struct tcp_sack_block_wire identical to struct tcp_sack_block
with u32 replaced with __be32; annotate uses of tcp_sack_block replacing
net-endian ones with tcp_sack_block_wire.  Change is obviously safe since
for cc(1) __be32 is typedefed to u32.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Fixes a null pointer dereference when unloading the ipx module.

On initialization of the ipx module, registering certain packet
types can fail. When this happens, unloading the module later
dereferences NULL pointers.  This patch fixes that. Please apply.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The TCP reset packet is copied from the original.  This
includes all the GSO bits which do not apply to the new
packet.  So we should clear those bits.

Spotted by Patrick McHardy.
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>

Signed-off-by: John Heffner <jheffner@psc.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

This was reported by Ingo Molnar here,

http://lkml.org/lkml/2006/12/18/119

The problem is that adummy_init() depends on atm_init() , but adummy_init()
is called first.

So I put atm_init() into subsys_initcall which seems appropriate, and it
will still get module_init() if it becomes a module.

Interesting to note that you could crash your system here if you just load
the modules in the wrong order.
Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

I encountered a kernel panic with my test program, which is a very
simple IPv6 client-server program.

The server side sets IPV6_RECVPKTINFO on a listening socket, and the
client side just sends a message to the server.  Then the kernel panic
occurs on the server.  (If you need the test program, please let me
know. I can provide it.)

This problem happens because a skb is forcibly freed in
tcp_rcv_state_process().

When a socket in listening state(TCP_LISTEN) receives a syn packet,
then tcp_v6_conn_request() will be called from
tcp_rcv_state_process().  If the tcp_v6_conn_request() successfully
returns, the skb would be discarded by __kfree_skb().

However, in case of a listening socket which was already set
IPV6_RECVPKTINFO, an address of the skb will be stored in
treq->pktopts and a ref count of the skb will be incremented in
tcp_v6_conn_request().  But, even if the skb is still in use, the skb
will be freed.  Then someone still using the freed skb will cause the
kernel panic.

I suggest to use kfree_skb() instead of __kfree_skb().
Signed-off-by: Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The sorting of SACK blocks actually munges them rather than sort,
causing the TCP stack to ignore some SACK information and breaking the
assumption of ordered SACK blocks after sorting.

The sort takes the data from a second buffer which isn't moved causing
subsequent data moves to occur from the wrong location. The fix is to
use a temporary buffer as a normal sort does.
Signed-off-By: Baruch Even <baruch@ev-en.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

If the device is down, invoking the device hard header callbacks
is not legal, so check it early.

Based upon a shaper OOPS report from Frederik Deweerdt.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

In some cases such as:
        iph->check = 0;
        iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
GCC may optimize out the previous store.

Observed as a failure of NFS over udp (bad checksums on ip fragments)
when compiled with GCC 3.4.2.
Signed-off-by: Bob Breuer <breuerr@mc.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong.  So handle the
failure.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

This also adds he required page "writeback" flag handling, that cifs
hasn't been doing and that the page dirty flag changes made obvious.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Acked-by: Steve French <smfltc@us.ibm.com>

Fix insecure default behaviour reported by Tigran Aivazian: if an
ext2 or ext3 filesystem is tuned to mount with "acl", but mounted by
a kernel built without ACL support, then umask was ignored when creating
inodes - though root or user has umask 022, touch creates files as 0666,
and mkdir creates directories as 0777.

This appears to have worked right until 2.6.11, when a fix to the default
mode on symlinks (always 0777) assumed VFS applies umask: which it does,
unless the mount is marked for ACLs; but ext[23] set MS_POSIXACL in
s_flags according to s_mount_opt set according to def_mount_opts.

We could revert to the 2.6.10 ext[23]_init_acl (adding an S_ISLNK test);
but other filesystems only set MS_POSIXACL when ACLs are configured.  We
could fix this at another level; but it seems most robust to avoid setting
the s_mount_opt flag in the first place (at the expense of more ifdefs).

Likewise don't set the XATTR_USER flag when built without XATTR support.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

This patch fixes a confusion reiserfs has for a long time.

On release file operation reiserfs used to try to pack file data stored in
last incomplete page of some files into metadata blocks.  After packing the
page got cleared with clear_page_dirty.  It did not take into account that
the page may be mmaped into other process's address space.  Recent
replacement for clear_page_dirty cancel_dirty_page found the confusion with
sanity check that page has to be not mapped.

The patch fixes the confusion by making reiserfs avoid tail packing if an
inode was ever mmapped.  reiserfs_mmap and reiserfs_file_release are
serialized with mutex in reiserfs specific inode.  reiserfs_mmap locks the
mutex and sets a bit in reiserfs specific inode flags.
reiserfs_file_release checks the bit having the mutex locked.  If bit is
set - tail packing is avoided.  This eliminates a possibility that mmapped
page gets cancel_page_dirty-ed.
Signed-off-by: Vladimir Saveliev <vs@namesys.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

We are inside spin_lock_irqsave().  quoth akpm's debug facility:

 [  231.948000] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
 [  232.232000] ata1.00: configured for UDMA/33
 [  232.404000] WARNING (1) at arch/i386/mm/highmem.c:47 kmap_atomic()
 [  232.404000]  [<c01162e6>] kmap_atomic+0xa9/0x1ab
 [  232.404000]  [<c0242c81>] ata_scsi_rbuf_get+0x1c/0x30
 [  232.404000]  [<c0242caf>] ata_scsi_rbuf_fill+0x1a/0x87
 [  232.404000]  [<c0243ab2>] ata_scsiop_mode_sense+0x0/0x309
 [  232.404000]  [<c01729d5>] end_bio_bh_io_sync+0x0/0x37
 [  232.404000]  [<c02311c6>] scsi_done+0x0/0x16
 [  232.404000]  [<c02311c6>] scsi_done+0x0/0x16
 [  232.404000]  [<c0242dcc>] ata_scsi_simulate+0xb0/0x13f
[...]
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Add pci_get_legacy_ide_irq() identical to the one used by i386/x86_64.
Fixes amd74xx driver build on ia64 (bugzilla bug #6644).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

The Silicon Hill club is not what it used to be.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>