[PATCH] ps2esdi: typo may cause premature timeout

The stop condition in the following statement causes an immediate
break out of the loop because ESDI_TIMEOUT=0xf000 and the result
of the !(inb()) expression can only be either 0 or 1, which means
that i never gets counted down.

   for (i = ESDI_TIMEOUT;
        i & !(inb(ESDI_STATUS) & STATUS_STAT_AVAIL);
        i--);

The obvious cause is the use of "i & !" instead of "i && !". This
was already fixed in 2.6.

Signed-off-by: Willy Tarreau <w@1wt.eu>

[PATCH] e100: incorrect use of "&&" instead of "&"

In e100_do_ethtool_ioctl(), bdp->flags is a bitfield and is
checked for some bits but the AND operation is performed with
&& instead of &. Obvious fix is to use "&" as in all other
places. 2.6 does not seem affected.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: David Miller <davem@davemloft.net>

[PATCH] arm: incorrect use of "&&" instead of "&"

In integrator_init_irq(), the use of "&&" in the following
statement causes all interrupts to be marked valid regardless
of INTEGRATOR_SC_VALID_INT, as long as it's non-zero :

     if (((1 << i) && INTEGRATOR_SC_VALID_INT) != 0)

Obvious fix is to replace it with "&". This was already fixed
in 2.6.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: Russell King <rmk+lkml@arm.linux.org.uk>

[PATCH] jfs: incorrect use of "&&" instead of "&"

in jfs_txnmgr, the use of "tblk->flag && COMMIT_DELETE" in a
if() condition is obviously wrong. This bug has already been
fixed in 2.6.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>

[PATCH] flashpoint: use '!' instead of '~' with EE_SYNC_MASK

Trivial typo found by grep in 2.4 code, already fixed in 2.6.
The complement mask was computed with '!' instead of '~' while
the mask was not 1 :

  #define  EE_SYNC_MASK      (BIT(0)+BIT(1))
  currTar_Info->TarEEValue = (currTar_Info->TarEEValue & !EE_SYNC_MASK)
  temp2.tempb[0] = (temp2.tempb[0] & !EE_SYNC_MASK) | syncVal;
  temp2.tempb[1] = (temp2.tempb[1] & !EE_SYNC_MASK) | syncVal;

[PATCH] rio: typo in bitwise AND expression.

The line :

    hp->Mode &= !RIO_PCI_INT_ENABLE;

is obviously wrong as RIO_PCI_INT_ENABLE=0x04 and is used as a bitmask
2 lines before. Getting no IRQ would not disable RIO_PCI_INT_ENABLE
but rather RIO_PCI_BOOT_FROM_RAM which equals 0x01.

Obvious fix is to change ! for ~.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Patrick vd Lageweg <patrick@BitWizard.nl>

[PATCH] Masking bug in 6pack driver

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>

Change VERSION to 2.4.34-pre6

    - [I2C] update web site address and contacts
    - [I2C] do not ignore error when returning from i2c_add_adapter()
    - [I2C] i2c-matroxfb: Struct init conversion
    - [I2C] Fix copy-n-paste error in i2c Config.in.
    - [I2C] remove non-existing functions declarations.
    - knfsd: Fix race that can disable NFS server.
    - i2c-elv: fix erroneous '&&' operator
    - fix "&& 0xffff" typo in gdth.c
    - fix obvious "&& 0xFFFFFF" typo in cpqfcTSworker
    - fix "&& 0xff" typo in qeth_qdio_input_handler
    - fix two "&& 0x03" in usbnet
    - EXT3: avoid crashing by not dividing by zero.
    - EXT2: avoid crashing by not dividing by zero.
    - [GCC4] fix build error in arch/alpha/kernel/osf_sys.c
    - [GCC4] fix build error in arch/alpha/kernel/irq.c
    - [GCC4] fix build error in arch/alpha/lib/io.c
    - [GCC4] fix build error in arch/alpha/math-emu/math.c

[PATCH][I2C] remove non-existing functions declarations.

Drop the function declarations for slave mode support of i2c adapters.
This was never implemented.

Partial backport of:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6d3aae9d74221b00e2cbf50a353527e5a71a58ba

Signed-off-by: Jean Delvare <khali@linux-fr.org>

[PATCH][I2C] Fix copy-n-paste error in i2c Config.in.

Backport from a Linux 2.6 patch by Arthur Othieno:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=be53f9b2a08e647396ceaa004199ae4b032a9bd2

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Arthur Othieno <apgo@patchbomb.org>

[PATCH][I2C] i2c-matroxfb: Struct init conversion

Convert the struct i2c_algo_bit_data initialization to proper C99
style.

Backport from:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8241cb1401873e18bba746fd3f6c56ce4252a61f

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>

[PATCH][I2C] do not ignore error when returning from i2c_add_adapter()

i2c_add_adapter may fail. Most i2c algorithm drivers ignore this
fact, fix them. This is a backport from a patch from Mark M. Hoffman
to Linux 2.6.

Signed-off-by: Jean Delvare <khali@linux-fr.org>

[PATCH][I2C] update web site address and contacts

We have a new mailing list dedicated to linux i2c:
http://lists.lm-sensors.org/mailman/listinfo/i2c

The lm-sensors website moved to http://www.lm-sensors.org/.

Signed-off-by: Jean Delvare <khali@linux-fr.org>

[GCC4] fix build error in arch/alpha/math-emu/math.c

This patch fixes this error with gcc 4 on alpha :

gcc-4.1 -D__KERNEL__ -I/data/git/public/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 -Wa,-mev6   -nostdinc -iwithprefix include -DKBUILD_BASENAME=math  -c -o math.o math.c
math.c: In function 'alpha_fp_emul':
math.c:204: warning: right shift count is negative
math.c:204: warning: left shift count >= width of type
math.c:220: warning: left shift count is negative
math.c:238: warning: statement with no effect
math.c:258: error: invalid lvalue in assignment
math.c:258: warning: right shift count >= width of type
math.c:258: warning: right shift count >= width of type
math.c:262: error: invalid lvalue in assignment
math.c:262: warning: right shift count >= width of type
math.c:262: warning: right shift count >= width of type
math.c:270: warning: statement with no effect
math.c:270: warning: statement with no effect
math.c:270: warning: statement with no effect
math.c:277: warning: statement with no effect
math.c:277: warning: statement with no effect
math.c:277: warning: statement with no effect

[GCC4] fix build error in arch/alpha/lib/io.c

This patch fixes this error with gcc 4 on alpha :

gcc-4.1 -D__KERNEL__ -I/data/git/public/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 -Wa,-mev6   -nostdinc -iwithprefix include -DKBUILD_BASENAME=io  -c -o io.o io.c
io.c: In function 'insb':
io.c:146: error: invalid lvalue in increment
io.c:157: error: invalid lvalue in increment
io.c:163: error: invalid lvalue in increment
io.c: In function 'insw':
io.c:185: error: invalid lvalue in increment
io.c:194: error: invalid lvalue in increment
io.c: In function 'insl':
io.c:222: error: invalid lvalue in increment
io.c:233: error: invalid lvalue in increment
io.c:239: error: invalid lvalue in increment
io.c:249: error: invalid lvalue in increment
io.c:251: error: invalid lvalue in increment
io.c:256: error: invalid lvalue in increment
io.c:266: error: invalid lvalue in increment
io.c:271: error: invalid lvalue in increment
io.c:275: error: invalid lvalue in increment
io.c: In function 'outsb':
io.c:293: error: invalid lvalue in increment
io.c: In function 'outsw':
io.c:310: error: invalid lvalue in increment
io.c:318: error: invalid lvalue in increment
io.c: In function 'outsl':
io.c:348: error: invalid lvalue in increment
io.c:358: error: invalid lvalue in increment
io.c:363: error: invalid lvalue in increment
io.c:374: error: invalid lvalue in increment
io.c:376: error: invalid lvalue in increment
io.c:380: error: invalid lvalue in increment
io.c:391: error: invalid lvalue in increment
io.c:395: error: invalid lvalue in increment
io.c:400: error: invalid lvalue in increment

[GCC4] fix build error in arch/alpha/kernel/irq.c

This patch fixes this error with gcc 4 on alpha :

gcc-4.1 -D__KERNEL__ -I/data/git/public/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 -Wa,-mev6   -nostdinc -iwithprefix include -DKBUILD_BASENAME=irq  -c -o irq.o irq.c
irq.c: In function 'handle_irq':
irq.c:619: error: invalid lvalue in increment

[GCC4] fix build error in arch/alpha/kernel/osf_sys.c

This patches fixes this error with gcc 4 on alpha :

gcc-4.1 -D__KERNEL__ -I/data/git/public/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 -Wa,-mev6   -nostdinc -iwithprefix include -DKBUILD_BASENAME=osf_sys  -c -o osf_sys.o osf_sys.c
osf_sys.c: In function 'osf_filldir':
osf_sys.c:128: error: invalid lvalue in assignment

[PATCH] EXT2: avoid crashing by not dividing by zero.

backport a few checks from 2.6 to avoid dividing by zero on invalid
superblocks.

[PATCH] EXT3: avoid crashing by not dividing by zero.

backport a few checks from 2.6 to avoid dividing by zero on invalid
superblocks.

[PATCH] fix two "&& 0x03" in usbnet

just another obvious typo.

[PATCH] fix "&& 0xff" typo in qeth_qdio_input_handler

this one is already OK in 2.6.

[PATCH] fix obvious "&& 0xFFFFFF" typo in cpqfcTSworker

[PATCH] fix "&& 0xffff" typo in gdth.c

same as 2.6 patch.

[PATCH-2.4] i2c-elv: fix erroneous '&&' operator

There was clearly a typo in i2c-elv.c.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

[PATCH] knfsd: Fix race that can disable NFS server.

This is a long standing bug that seems to have only recently become
apparent, presumably due to increasing use of NFS over TCP - many
distros seem to be making it the default.

The SK_CONN bit gets set when a listening socket may be ready
for an accept, just as SK_DATA is set when data may be available.

It is entirely possible for svc_tcp_accept to be called with neither
of these set.  It doesn't happen often but there is a small race in
svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the
spin_lock.  They could be cleared immediately after the test and
before the lock is gained.

This normally shouldn't be a problem.  The sockets are non-blocking so
trying to read() or accept() when ther is nothing to do is not a problem.

However: svc_tcp_recvfrom makes the decision "Should I accept() or
should I read()" based on whether SK_CONN is set or not.  This usually
works but is not safe.  The decision should be based on whether it is
a TCP_LISTEN socket or a TCP_CONNECTED socket.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Change VERSION to 2.4.34-pre5
    - WATCHDOG: sc1200wdt.c pnp unregister fix.
    - incorrect timeout in mtd AMD driver of 2.4 kernel
    - SCTP: Always linearise packet on input
    - ISDN: fix drivers, by handling errors thrown by ->readstat()
    - copy_from_user information leak on s390.
    - s390 : fix typo in recent copy_from_user fix
    - [S390] user readable uninitialised kernel memory (3rd version)
    - [NETFILTER]: Fix deadlock on NAT helper unload
    - [BRIDGE]: netfilter deadlock
    - i386: remove unsigned long long cast in __pte() macro.
    - 2.4.x: i386/x86_64 bitops clobberings

[PATCH] WATCHDOG: sc1200wdt.c pnp unregister fix.

(backport from 2.6-stable)

If no devices found or invalid parameter is specified,
scl200wdt_pnp_driver is left unregistered.
It breaks global list of pnp drivers.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
For 2.4 backport :
Acked-by: Wim Van Sebroeck <wim@iguana.be>

[PATCH] ISDN: fix drivers, by handling errors thrown by ->readstat()

(backport from 2.6-stable)

This is a particularly ugly on-failure bug, possibly security, since the
lack of error handling here is covering up another class of bug: failure to
handle copy_to_user() return values.

The I4L API function ->readstat() returns an integer, and by looking at
several existing driver implementations, it is clear that a negative return
value was meant to indicate an error.

Given that several drivers already return a negative value indicating an
errno-style error, the current code would blindly accept that [negative]
value as a valid amount of bytes read.  Obvious damage ensues.

Correcting ->readstat() handling to properly notice errors fixes the
existing code to work correctly on error, and enables future patches to
more easily indicate errors during operation.

Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Karsten Keil <kkeil@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
For 2.4 backport :
Acked-by: Karsten Keil <kkeil@suse.de>

[PATCH] SCTP: Always linearise packet on input

(backported from 2.6-stable)

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: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
For 2.4 backport :
Acked-by: David S. Miller <davem@davemloft.net>

[BRIDGE]: netfilter deadlock

A deadlock was found in bridge netfilter code (2.4 only), when a
device is removed.  The device removal path causes a BPDU to be
generated and ends up self deadlocking on the BR lock.

Simple fix would be to avoid generating config bpdu's immediately when
becoming root bridge, and just let the first hello timer tick do that.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] incorrect timeout in mtd AMD driver of 2.4 kernel

I found a problem in the MTD driver for AMD flash chips that caused
occasional write errors on my WiFi router running OpenWrt. The driver
uses (HZ/1000) to calculate a timeout value of at least 1 msec, but
since HZ is 100, the timeout is effectively zero. The fix is to
increment the timeout by 1 jiffie, which is also done in the 2.6 kernel.
The patch also fixes two missing newlines.

[PATCH] 2.4.x: i386/x86_64 bitops clobberings

Problem reported by Jan Kiszka <jan.kiszka@web.de> :
 "After going through debugging hell with some out-of-tree code,
  I realised that this patch :

  http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=92934bcbf96bc9dc931c40ca5f1a57685b7b813b

  makes a difference: current 2.6 works with the following code
  sequence as expected (printk is executed), 2.4 fails. I used
  gcc 3.3.6-13 (Debian).

  unsigned long a = 1;

  int module_init(void)
  {
        unsigned long b = 0;
        int x;

        x = __test_and_set_bit(0, &b);
        if (__test_and_set_bit(0, &a))
                printk("x = %d\n", x);

        return -1;
  }

  I ported the x86 part back to 2.4.33 and my problem disappeared. "

The problem with this patch is that the use of "+m" in asm statements
triggers bugs in gcc 2.95 which is supported by kernel 2.4. For
instance, cyclades.c does not build anymore :

$ gcc -O2 -pipe -c cyclades-c.c
cyclades.c: In function `cyy_interrupt':
/usr/src/git/linux-2.4/include/asm/bitops.h:134: inconsistent operand constraints in an `asm'
cyclades.c: In function `cyz_handle_rx':
/usr/src/git/linux-2.4/include/asm/bitops.h:134: inconsistent operand constraints in an `asm'

As explained by Richard Henderson here, the equivalent construct
"=m"(x) : "m"(x) works on any version of gcc :

  http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D107475162200773&w=3D2

I successfully verified on the example code above and on cyclades.c
that the exact same code is produced on x86 with this construct with
gcc 2.95.3, 3.3.6, 3.4.4, and 4.1.1, and Jan confirmed it also fixed
his problem, so it looks fine.

Just like in the former patch for 2.6, this one was applied to both
i386 and x86_64.

Signed-Off-By: Willy Tarreau <w@1wt.eu>
Acked-By: Jan Kiszka <jan.kiszka@web.de>

[S390] user readable uninitialised kernel memory (3rd version)

Fixed a label and a few comments.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

[PATCH] s390 : fix typo in recent copy_from_user fix

unfortunatly a bug crept into the bug fix for 2.4: the arguments of the
mvcle that is supposed to clear the kernel buffer have been swapped for
64 bit (the code is fine for 31 bit :-/).

[PATCH] i386: remove unsigned long long cast in __pte() macro.

From PaX Team :
"I've just seen the commit of the __pte() macro fixes and i'm not
 sure that a blind unsigned long long cast is the proper way to
 handle the warnings. the thing is, if there's a warning as Ralf
 said, then it means that the user of the macro is not passing the
 proper argument to the macro, hence there's a likelyhood that the
 caller itself may not be doing what it intended to do."

"I don't know about MIPS, but under i386/PAE the higher 32 bits do
 carry 'interesting' bits (not only physical page number bits but
 on NX capable CPUs the NX bit itself as well), so they can't be
 blindly made 0 by doing an unsigned long long cast, it should be
 decided by the user of the macro instead."

"So my suggestion would be to fix the callers instead of doing the
 cast, that is, have gcc point out everyone not passing a properly
 set up argument, figure out if a cast is proper (as i said, at
 least on PAE it will loose important bits) and fix the caller."

Also, the only user seems to be drm-40/ffb_drv.c, which is only
enabled for sparc64. So the warning would never appear anyway.

Acked-By: Willy Tarreau <w@1wt.eu>

[NETFILTER]: Fix deadlock on NAT helper unload

When a NAT helper is unlocked conntrack/NAT may deadlock because of
the following lock sequence:

.. ip_nat_helper_unregister
-> ip_ct_selective_cleanup
-> get_next_corpse              (ip_conntrack_lock)
-> kill_helper                  (ip_nat_lock)

.. ip_nat_fn                    (ip_nat_lock)
-> ip_nat_setup_info
-> ip_conntrack_alter_reply     (ip_conntrack_lock)

Taking ip_nat_lock in kill_helper() is unnecessary since the helper assigned
to a connection is immutable and new connections can't have the helper that
is beeing unloaded assigned since it is already removed from the global list.

Reported by <doublefacer007@gmail.com>.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] copy_from_user information leak on s390.

There is/has been a bug with copy_from_user on s390. The problem is that
it does not pad the kernel buffer with zeroes in case of a fault on the
user address. That allows a malicious user to read uninitialized kernel
memory. The bug is already fixed upstream:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=52149ba6b0ddf3e9d965257cc0513193650b3ea8

The uaccess code for s390 has changed recently, for older 2.6 versions
you need a different patch, and for 2.4 yet another one.

Description: kernel: user readable uninitialised kernel memory.
Symptom:     None.
Problem:     A user space program can read uninitialised kernel memory
             by appending to a file from a bad address and then reading
             the result back. The cause is the copy_from_user function
             that does not clear the remaining bytes of the kernel
             buffer after it got a fault on the user space address.
Solution:    Fix the copy_from_user function to clear the remaining bytes
             of the kernel buffer after a user space fault.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

Change VERSION to 2.4.34-pre4

- Backport fix for CVE-2006-4997 to 2.4 tree
- fbdev: correct buffer size limit in fbmem_read_proc()
- really fix size display for sun partitions larger than 1TByte
- i386: fix overflow in vmap on an x86 system which has more than 4GB memory.
- Advertise PPPoE MTU
- MIPS & i386: fix long long cast in pte macro
- block: fix negative bias of ios_in_flight (CONFIG_BLK_STATS) because of unbalanced I/O accounting
- x86_64: Fix missing delay when the TSC counter just overflowed
- fix Configure.help concerning rp_filter

[PATCH] i386: fix long long cast in pte macro

From PaX Team :
the current idiom used for initializing a structure of two unsigned longs
from unsigned long long is wrong, it effectively loses the upper 32 bits
which in this particular case could turn a non-executable PTE into an
executable one on NX capable i386 (i.e., it's a potential security bug).
fortunately the in-tree users in 2.4 (drivers/char/drm-4.0/ffb_drv.c
and arch/mips/baget/baget.c) are not affected.

Added the (unsigned long long) cast as suggested by Ralf Baechle to
silent gcc when shifting right 32-bit arguments.

Acked-by: Willy Tarreau <w@1wt.eu>

[PATCH] MIPS: fix long long cast in pte macro

From PaX Team :
the current idiom used for initializing a structure of two unsigned longs
from unsigned long long is wrong, it effectively loses the upper 32 bits
which in this particular case could turn a non-executable PTE into an
executable one on NX capable i386 (i.e., it's a potential security bug).
fortunately the in-tree users in 2.4 (drivers/char/drm-4.0/ffb_drv.c
and arch/mips/baget/baget.c) are not affected.

From Ralf Baechle :
I need a slight change to get this to build without warning for MIPS.
The argument passed to __pte() might be just a 32-bit int, so >> 32 will
upset gcc big time.  I believe the same problem exists for i386, so
here's the patch with the necessary cast for both architectures.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Revert "[PATCH] MIPS: fix long long cast in pte macro"

The commit was bogus, it contained both the MIPS and the i386
fixes.

This reverts 5f81c2baacdb36638446d1356beb4ce4e13baedb commit.

[PATCH] MIPS: fix long long cast in pte macro

From PaX Team :
the current idiom used for initializing a structure of two unsigned longs
from unsigned long long is wrong, it effectively loses the upper 32 bits
which in this particular case could turn a non-executable PTE into an
executable one on NX capable i386 (i.e., it's a potential security bug).
fortunately the in-tree users in 2.4 (drivers/char/drm-4.0/ffb_drv.c
and arch/mips/baget/baget.c) are not affected.

From Ralf Baechle :
I need a slight change to get this to build without warning for MIPS.
The argument passed to __pte() might be just a 32-bit int, so >> 32 will
upset gcc big time.  I believe the same problem exists for i386, so
here's the patch with the necessary cast for both architectures.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

[PATCH] really fix size display for sun partitions larger than 1TByte

Problem: the last fix introduced by Jeff Mahoney for kernel 2.6 was not
complete for kernel 2.4 (as applied). I found out that add_gd_partition
is called by any type of partition (2.4).  add_gd_partition is defined
as add_gd_partition (int, int), what makes no sense to me as negative
numbers should never occur here.  As long as add_gd_partition is not
changed to add_gd_partition (unsigned, unsigned), /proc/partitions will
keep showing negative numbers.

If ever someone could look into this, within the different partition
type files in linux/fs/partitions the parameters to add_gd_partitions
seem to be chosen arbitrarily between int, unsigned and unsigned long,
whatever seemed to be appropriate, I think it would make sense to get
consistent parameters to add_gd_partition from all partition types here.
Especially if one takes into account that sizeof (long) and sizeof (int)
may differ significantly i. e. on sparc.

Signed-off-by: Dieter Jurzitza <DJurzitza@HarmanBecker.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>

[PATCH] fix Configure.help concerning rp_filter

Adrian Buciuman reported that Configure.help is wrong regarding
rp_filter, while ip_sysctl.txt is right. rp_filter is OFF by
default.

[PATCH] Backport fix for CVE-2006-4997 to 2.4 tree

Backport fix for CVE-2006-4997 to 2.4 tree, compile tested.
Original commit message follows.

[ATM] CLIP: Do not refer freed skbuff in clip_mkip().

In clip_mkip(), skb->dev is dereferenced after clip_push(),
which frees up skb.

Advisory: AD_LAB-06009 (<adlab@venustech.com.cn>).

Original patch by YOSHIFUJI Hideaki.

Signed-off-by: dann frazier <dannf@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] fbdev: correct buffer size limit in fbmem_read_proc()

Address http://bugzilla.kernel.org/show_bug.cgi?id=7189

It should check `clen', not `len'.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: <jurij@wooyd.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: <stable@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Andrew Morton <akpm@osdl.org>

[PATCH] Advertise PPPoE MTU

PPPoE must advertise the underlying device's MTU via the ppp channel
descriptor structure, as multilink functionality depends on it.

Signed-off-by: Michal Ostrowski <mostrows@earthlink.net>
Acked-by: Paul Mackerras <paulus@samba.org>

[PATCH] x86_64: Fix missing delay when the TSC counter just overflowed

I'd seen a problem that *delay functions return in too short delay.
It happens when the lower 32bit of TSC counter is overflowed.
This patch fixes the problem. This is back-port of Andi Kleen's
2.6 fix.

http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commit;h=6c51e28ffbbebf49437ec63ac4f9e385d60827e5

Signed-off-by: Toyo Abe <toyoa@mvista.com>

[PATCH] i386: fix overflow in vmap on an x86 system which has more than 4GB memory.

(max_mapnr << PAGE_SHIFT) would overflow on a system which has
4GB memory or more, and so could cause vmap to fail every time.

Signed-off-by: Michael Chen <micche@ati.com>
Signed-off-by: Hugh Dickins <hugh@veritas.com>

[PATCH] block: fix negative bias of ios_in_flight (CONFIG_BLK_STATS) because of unbalanced I/O accounting

Fix for unbalanced I/O accounting, that caused ios_in_flight
(CONFIG_BLK_STATS) to become and stay negative, as suggested by Jens
Axboe.

An added boolean field "io_account" in struct request is assumed to be
initialized to false on new requests. On starting I/O accounting, true is
assigned to the field. On ending I/O accounting, accounting is only
executed if the field has already been assigned true previously. Thus,
this fixes unbalanced cases where requests such as non-data get enqueued
without starting to account (ide_do_drive_cmd?) but the end of accounting
gets executed on finishing the same requests (ide_end_drive_cmd,
end_that_request_last, req_finished_io).

The precondition of io_account being initialized to false is ensured by

1) ide_init_drive_taskfile / ide_init_drive_cmd memset'ing the whole
request to zero, for requests that were potentially accounted unbalanced,
and

2) get_request assigning zero to io_account on allocating a request from
the free list cache (or slab cache initially), for the majority of
requests such as those involving data.

Jens preferred this to other discussed solutions and it should fix all
those unbalanced cases at once without touching each of them individually.

For more details, please see previous posts of this thread
http://www.uwsg.iu.edu/hypermail/linux/kernel/0608.2/0776.html.

I tested the patch with 2.4.24 and 2.4.33.3 successfully on an UP ia32
machine with one /dev/hda.

Signed-off-by: Steffen Maier <smaier@users.sourceforge.net>

Change VERSION to 2.4.34-pre3

This pre-version only includes GCC4 fixes and nothing else.
Build should work at least on i386, x86_64, PPC and sparc64.

Merge branch 'gcc4'

Change VERSION to 2.4.34-pre2

     - drivers/scsi/sg.c : fix CVE-2006-1528
     - [SCTP] Fix sctp_primitive_ABORT() call in sctp_close()
     - Fix possible UDF deadlock and memory corruption (CVE-2006-4145)
     - binfmt_elf.c : fix checks for bad address
     - [DISKLABEL] SUN: Fix signed int usage for sector count
     - cciss: do not mark cciss_scsi_detect __init
     - i386 : fix exception processing in early boot
     - crypto : prevent cryptoloop from oopsing on stupid ciphers
     - loop.c: kernel_thread() retval check
     - [SCTP] Local privilege elevation - CVE-2006-3745
     - powerpc: Clear HID0 attention enable on PPC970 at boot time
     - Revert "export memchr() which is used by smbfs and lp driver."
     - [SPARC] export memchr() which is used by smbfs and lp driver.

[PATCH] i386 : fix exception processing in early boot

fix the longest existing kernel bug ever (since 0.01 ;-). basically,
the dummy interrupt handler installed for the early boot period does
not work for exceptions that push an error code as well, effectively
making the iret at the end of the handler to trigger another exception,
ad infinitum, or rather, until the kernel stack runs over, trashes all
memory below and eventually causes a CPU reset or a hang. without this
fix the early printk facility in 2.6 is also rather useless.

[PATCH] Fix possible UDF deadlock and memory corruption (CVE-2006-4145)

Here is a backport of the fix for CVE-2006-4145 fix from 2.6[1]
I've compile-tested it.

[1] http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.17.y.git;a=commit;h=7127be29378b1230eb8dd8b84f18d6b69c56e959

Description in the original patch follows :

UDF code is not really ready to handle extents larger that 1GB. This
is the easy way to forbid creating those. Also truncation code did not
count with the case when there are no extents in the file and we are
extending the file.

Signed-off-by: dann frazier <dannf@debian.org>

[PATCH] [SCTP] Fix sctp_primitive_ABORT() call in sctp_close()

Here is a 2.4 backport of David's fix for a problem with the recent
embargoed patch for CVE-2006-3745. Compile-tested, original
description follows:

[SCTP]: Fix sctp_primitive_ABORT() call in sctp_close().

With the recent fix, the callers of sctp_primitive_ABORT()
need to create an ABORT chunk and pass it as an argument rather
than msghdr that was passed earlier.

Signed-off-by: dann frazier <dannf@debian.org>

[PATCH] cciss: do not mark cciss_scsi_detect __init

if the cciss driver is compiled in then later discovery requests
initiated from userland will result in calling free'd memory since
the detect method is marked as __init. suggested fix is to simply
not mark it as __init, 2.6 has done it as well.

[PATCH] loop.c: kernel_thread() retval check

Patch extracted from 2.4.33-ow1. It has also been ported to 2.6 by
Julio Auto.

Basically, the code in drivers/block/loop.c did not check the return
value from kernel_thread().  If kernel_thread() would fail, the code
would misbehave (IIRC, the invoking process would become unkillable).

An easy way to trigger the bug was to run losetup under strace (as
root), and this is also how I tested the error path added with this
patch.

This change has been a part of publicly released -ow patches for 8+
months.

There are more instances of kernel_thread() calls that do not check the
return value; some of the remaining ones might need to be fixed, too.

Acked-by: Alan Cox <alan@redhat.com>

[DISKLABEL] SUN: Fix signed int usage for sector count

The current sun disklabel code uses a signed int for the sector count.
When partitions larger than 1 TB are used, the cast to a sector_t causes
the partition sizes to be invalid:

 # cat /proc/paritions | grep sdan
   66   112 2146435072 sdan
   66   115 9223372036853660736 sdan3
   66   120 9223372036853660736 sdan8

This patch switches the sector count to an unsigned int to fix this.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] crypto : prevent cryptoloop from oopsing on stupid ciphers

With the cryptoloop patch applied, it's possible to request
ECB mode encryption, which will result in a Oops because of
uninitialized function pointers. Initializing them to the
nocrypt_iv() function does not completely solve the problem
because cryptoloop does not check the return code, and kernel
memory will leak uninitialized through cryptoloop.

Proposed solution :
  Can we maybe define working but IV-ignoring functions for ECB (like I
  did), but use memory-clearing nocrypt*() for CFB and CTR (as long as
  these are not supported)?  Of course, all of these will return -ENOSYS.

Response from Herbert Xu :
  In cryptodev-2.6, with block ciphers you can no longer select CFB/CTR
  until someone writes support for them so this is no longer an issue.
  For 2.4, I don't really mind either way what nocrypt does.

Final solution :
  OK, I've merged Willy's suggestion for the memset()s into the patch
  that I had submitted previously.  The resulting patch is attached.

[PATCH] [SCTP] Local privilege elevation - CVE-2006-3745

Avoid the use of buggy get_user_iov_size(). sctp_make_abort_user()
now takes the msg_len along with the msg so that we don't have to
recalculate the bytes in iovec. It also uses memcpy_fromiovec()
so that we don't go beyond the length of the allocated buffer.

Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>

[PATCH] binfmt_elf.c : fix checks for bad address

Fix check for bad address; use macro instead of open-coding two checks.

Explanation from Ernie Petries in 2.6 commit :

  For background, the BAD_ADDR() macro should return TRUE if the address is
  TASK_SIZE, because that's the lowest address that is *not* valid for
  user-space mappings.  The macro was correct in binfmt_aout.c but was wrong
  for the "equal to" case in binfmt_elf.c.  There were two in-line validations
  of user-space addresses in binfmt_elf.c, which have been appropriately
  converted to use the corrected BAD_ADDR() macro in the patch you posted
  yesterday.  Note that the size checks against TASK_SIZE are okay as coded.

Note that this patch slightly differs from Ernie's in that the printk()
only got commented out instead of being removed, since a rate limited call
is expected soon.

[PATCH] [SPARC] export memchr() which is used by smbfs and lp driver.

Previous attempt at fixing smbfs build on sparc broke at least x86_64.
This patch is less intrusive and exports memchr() only on sparc and
sparc64.

Signed-off-by: Willy Tarreau <w@1wt.eu>

[PATCH] Revert "[PATCH] export memchr() which is used by smbfs and lp driver."

This reverts aa8eb4b22e6ecd3aa24e824c55239ddedf4dedad commit.

This patch broke x86_64 build and probably others. Better export
memchr() on architectures which need it.

[GCC4] SPARC64: fix UP build error in arch/sparc64/mm/init.c

This patch fixes an invalid-lvalue error when compiling a
2.4.34-pre1 kernel on sparc64 with gcc-4.1.1. The kernel
must be configured with CONFIG_SMP=n for the error to trigger.
(I didn't save the error message, sorry.)

A kernel compiled with gcc-4.1.1 boots fine on my Ultra5
and can rebuild itself, and generally seems no less solid
than the 2.4.33 I compiled with gcc-3.4.6.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>

[PATCH] drivers/scsi/sg.c : fix CVE-2006-1528

Here is a 2.4 backport of Douglas Gilbert's 2.6 fix for
CVE-2006-1528.

 (GIT: 1c8e71d72026ed4c6ba0fdfd7eebd865f4fd1415)

Signed-off-by: dann frazier <dannf@debian.org>

[PATCH] powerpc: Clear HID0 attention enable on PPC970 at boot time

Clear HID0[en_attn] at CPU init time on PPC970.  Closes CVE-2006-4093.
Back-ported from 2.6 after notification from Adrian Bunk and Greg KH.

Original 2.6 patch Signed-off-by: Olof Johansson <olof@lixom.net>
below :

  http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.17.y.git;a=commit;h=35a472de81cfdb37f3cfb49fde4987d99b81f996

Change VERSION to 2.4.34-pre1

[GCC4] SPARC: fix build error in drivers/fc4/soc.c

This patch fixes this error with gcc 4 on sparc :

soc.h: In function 'xram_copy_from':
soc.h:121: error: invalid lvalue in increment
soc.h: In function 'xram_copy_to':
soc.h:128: error: invalid lvalue in increment

[GCC4] SPARC: fix build error in arch/sparc/kernel/time.c

This patch fixes this error with gcc 4 (encountered on sparc) :

time.c:49: error: static declaration of 'mstk48t08_regs' follows non-static declaration
/usr/src/linux-2.4.33-gcc4-sparc/include/asm/mostek.h:130: error: previous declaration of 'mstk48t08_regs' was here

[GCC4] SPARC: fix build error in arch/sparc/kernel/signal.c

This patch fixes this error with gcc 4 (encountered on sparc) :

signal.c: In function 'do_sys_sigstack':
signal.c:1339: error: invalid lvalue in assignment

[GCC4] SPARC64: fix build error in drivers/sbus/char/pcikbd.c

This patch fixes this error with gcc 4 (encountered on sparc64) :

pcikbd.c:61: error: static declaration of 'pcikbd_iobase' follows non-static declaration
pcikbd.h:34: error: previous declaration of 'pcikbd_iobase' was here
pcikbd.c:62: error: static declaration of 'pcikbd_irq' follows non-static declaration
pcikbd.h:35: error: previous declaration of 'pcikbd_irq' was here

[GCC4] SPARC64: fix build error in arch/sparc64/kernel/time.c

This patch fixes this error with gcc 4 (encountered on sparc64) :

time.c:50: error: static declaration of 'mstk48t08_regs' follows non-static declaration
/usr/src/linux-2.4.33-gcc4-u60/include/asm/mostek.h:137: error: previous declaration of 'mstk48t08_regs' was here
time.c:51: error: static declaration of 'mstk48t59_regs' follows non-static declaration
/usr/src/linux-2.4.33-gcc4-u60/include/asm/mostek.h:144: error: previous declaration of 'mstk48t59_regs' was here

[GCC4] SPARC64: fix build error in arch/sparc64/kernel/smp.c

This patch fixes this error with gcc 4 (encountered on sparc64) :

smp.c:50: error: static declaration of 'boot_cpu_id' follows non-static declaration
/usr/src/linux-2.4.33-gcc4-u60/include/asm/smp.h:63: error: previous declaration of 'boot_cpu_id' was here

[GCC4] fix build error in drivers/net/rrunner.c

This patch fixes this error with gcc 4 (encountered on PPC) :

rrunner.c: In function 'rr_hippi_probe':
rrunner.c:237: error: 'regs' undeclared (first use in this function)
rrunner.c:237: error: (Each undeclared identifier is reported only once
rrunner.c:237: error: for each function it appears in.)

[GCC4] fix build in drivers/atm/horizon.c

This patches fixes this error with gcc 4 (encountered on PPC) :

horizon.c:484: error: conflicting types for 'dump_regs'
/tmp/linux-2.4.33/include/asm/system.h:96: error: previous declaration of 'dump_regs' was here

[GCC4] fix warnings in drivers/isdn/hisax/hisax.h

This patch fixes these warnings with gcc 4 :

hisax.h:403: warning: 'packed' attribute ignored for field of type 'u_char'
hisax.h:404: warning: 'packed' attribute ignored for field of type 'u_char'
hisax.h:405: warning: 'packed' attribute ignored for field of type 'u_char'
hisax.h:406: warning: 'packed' attribute ignored for field of type 'u_char'

[GCC4] fix warnings in drivers/isdn/eicon/eicon*.h

This patch fixes these warnings with gcc 4 :

In file included from eicon_mod.c:34:
eicon.h:157: warning: 'packed' attribute ignored for field of type '__u8'
eicon.h:158: warning: 'packed' attribute ignored for field of type '__u8'
eicon.h:159: warning: 'packed' attribute ignored for field of type '__u8'
...
In file included from eicon.h:345,
                 from eicon_mod.c:34:
eicon_idi.h:61: warning: 'packed' attribute ignored for field of type '__u8'
eicon_idi.h:62: warning: 'packed' attribute ignored for field of type '__u8'
eicon_idi.h:63: warning: 'packed' attribute ignored for field of type '__u8'
...

[GCC4] fix warnings in drivers/net/de4x5,depca,arcnet

This patch fixes this warning with gcc 4 :

de4x5.c: In function 'mii_get_phy':
de4x5.c:5112: warning: operation on 'i' may be undefined
depca.c: In function 'load_packet':
depca.c:1749: warning: operation on 'i' may be undefined
arcnet.c: In function 'release_arcbuf':
arcnet.c:280: warning: operation on 'i' may be undefined
arcnet.c: In function 'get_arcbuf':
arcnet.c:313: warning: operation on 'i' may be undefined

[GCC4] fix warning in drivers/char/ip2/i2lib.c

This patch fixes this warning with gcc 4 :

In file included from ip2main.c:409:
./ip2/i2lib.c: In function 'i2RetryFlushOutput':
./ip2/i2lib.c:1265: warning: comparisons like X<=Y<=Z do not have their mathematical meaning

[GCC4] fix warnings in drivers/char/sx.c

This patch fixes this warning with gcc 4 :

sx.c: In function 'sx_busy_wait_eq':
sx.c:525: warning: comparisons like X<=Y<=Z do not have their mathematical meaning
sx.c:531: warning: comparisons like X<=Y<=Z do not have their mathematical meaning
sx.c: In function 'sx_busy_wait_neq':
sx.c:551: warning: comparisons like X<=Y<=Z do not have their mathematical meaning
sx.c:557: warning: comparisons like X<=Y<=Z do not have their mathematical meaning

[GCC4] fix warnings in include/linux/wanpipe.h

This patch fixes these warnings with gcc 4 :

In file included from sdlamain.c:59:
/usr/src/git/linux-2.4/include/linux/wanpipe.h:230: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/wanpipe.h:231: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/wanpipe.h:235: warning: 'packed' attribute ignored for field of type 'unsigned char'
(...)

[GCC4] fix warnings in sdla_x25.c and sdla_x25.h

Removes most of these warnings with gcc 4 :

In file included from sdla_x25.c:107:
/usr/src/git/linux-2.4/include/linux/sdla_x25.h:59: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/sdla_x25.h:61: warning: 'packed' attribute ignored for field of type 'unsigned char'
(...)
/usr/src/git/linux-2.4/include/linux/sdla_chdlc.h:65: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/sdla_chdlc.h:67: warning: 'packed' attribute ignored for field of type 'unsigned char'
(...)
sdla_x25.c:321: warning: 'packed' attribute ignored for field of type 'char[15u]'
sdla_x25.c:322: warning: 'packed' attribute ignored for field of type 'char[15u]'
(...)

[GCC4] fix warnings in sdla.h and if_frad.h

This patch fixes these warnings with gcc 4 :

In file included from sdla.c:61:
/usr/src/git/linux-2.4/include/linux/if_frad.h:134: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/if_frad.h:137: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/if_frad.h:139: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/linux/if_frad.h:140: warning: 'packed' attribute ignored for field of type 'unsigned char[2u]'
In file included from sdla.c:63:
/usr/src/git/linux-2.4/include/linux/sdla.h:296: warning: 'packed' attribute ignored for field of type 'char'
/usr/src/git/linux-2.4/include/linux/sdla.h:297: warning: 'packed' attribute ignored for field of type 'char'
/usr/src/git/linux-2.4/include/linux/sdla.h:299: warning: 'packed' attribute ignored for field of type 'char'
/usr/src/git/linux-2.4/include/linux/sdla.h:301: warning: 'packed' attribute ignored for field of type 'char'
(...)

[GCC4] fix warnings in include/net/dn_nsp.h

This patch fixes these warnings with gcc 4 :

In file included from dn_route.c:81:
/usr/src/git/linux-2.4/include/net/dn_nsp.h:75: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/net/dn_nsp.h:97: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/net/dn_nsp.h:106: warning: 'packed' attribute ignored for field of type 'unsigned char'
(...)

[GCC4] fix warnings in include/net/dn_dev.h

This patch fixes these warnings with gcc 4 :

In file included from dn_neigh.c:44:
/usr/src/git/linux-2.4/include/net/dn_dev.h:102: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/net/dn_dev.h:105: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/net/dn_dev.h:110: warning: 'packed' attribute ignored for field of type 'unsigned char'
/usr/src/git/linux-2.4/include/net/dn_dev.h:111: warning: 'packed' attribute ignored for field of type 'unsigned char'

[GCC4] fix warnings in include/linux/isdnif.h

This patch fixes these warnings with gcc 4 :

In file included from /usr/src/git/linux-2.4/include/linux/isdn.h:211,
                 from isdn_ppp.c:13:
/usr/src/git/linux-2.4/include/linux/isdnif.h:285: warning: 'packed' attribute ignored for field of type '__u8'
/usr/src/git/linux-2.4/include/linux/isdnif.h:286: warning: 'packed' attribute ignored for field of type '__u8'
/usr/src/git/linux-2.4/include/linux/isdnif.h:287: warning: 'packed' attribute ignored for field of type '__u8'
/usr/src/git/linux-2.4/include/linux/isdnif.h:288: warning: 'packed' attribute ignored for field of type '__u8'
...
/usr/src/git/linux-2.4/include/linux/isdnif.h:319: warning: 'packed' attribute ignored for field of type '__u8[20u]'
/usr/src/git/linux-2.4/include/linux/isdnif.h:320: warning: 'packed' attribute ignored for field of type '__u8'

[GCC4] fix warning in include/linux/atalk.h

This patch fixes this warning with gcc 4 :

In file included from /usr/src/git/linux-2.4/include/net/sock.h:90,
                 from /usr/src/git/linux-2.4/include/net/ip.h:39,
                 from /usr/src/git/linux-2.4/include/net/checksum.h:31,
                 from /usr/src/git/linux-2.4/include/linux/raid/md.h:35,
                 from check.c:21:

/usr/src/git/linux-2.4/include/linux/atalk.h:140: warning: 'packed' attribute ignored for field of type '__u8[5u]'
/usr/src/git/linux-2.4/include/linux/atalk.h:141: warning: 'packed' attribute ignored for field of type '__u8'
/usr/src/git/linux-2.4/include/linux/atalk.h:143: warning: 'packed' attribute ignored for field of type '__u8'
/usr/src/git/linux-2.4/include/linux/atalk.h:144: warning: 'packed' attribute ignored for field of type '__u8[5u]'
/usr/src/git/linux-2.4/include/linux/atalk.h:145: warning: 'packed' attribute ignored for field of type '__u8'
/usr/src/git/linux-2.4/include/linux/atalk.h:147: warning: 'packed' attribute ignored for field of type '__u8'

[GCC4] fix build error in drivers/sound/wavfront.c

This patch fixes this error with gcc 4 :

wavfront.c:2490: error: static declaration of 'errno' follows non-static declaration
/usr/src/git/linux-2.4/include/linux/unistd.h:4: error: previous declaration of 'errno' was here

The solution is to workaround errno the same way as in sound_firmware :

[GCC4] fix build error in drivers/media/video/bttvp.h

This patch fixes this error with gcc 4 :

In file included from bttv-driver.c:49:
bttvp.h:61: error: array type has incomplete element type

[GCC4] fix build error in drivers/ieee1394/highlevel.c

This patch fixes these errors with gcc 4 :

highlevel.c: In function 'highlevel_read':
highlevel.c:503: error: invalid lvalue in assignment
highlevel.c: In function 'highlevel_write':
highlevel.c:549: error: invalid lvalue in assignment

[GCC4] fix build error in drivers/usb/audio.c

This patch fixes this error with gcc 4 :

audio.c:466: error: static declaration of 'abs' follows non-static declaration
make[2]: *** [audio.o] Error 1
make[2]: Leaving directory `/usr/src/git/linux-2.4/drivers/usb'
make[1]: *** [_modsubdir_usb] Error 2
make[1]: Leaving directory `/usr/src/git/linux-2.4/drivers'
make: *** [_mod_drivers] Error 2

[GCC4] fix build error in drivers/media/video/videodev.c

This patch fixes this error :
videodev.c:636: error: static declaration of 'video_fops' follows non-static declaration
videodev.c:492: error: previous declaration of 'video_fops' was here
make[4]: *** [videodev.o] Error 1
make[4]: Leaving directory `/usr/src/git/linux-2.4/drivers/media/video'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory `/usr/src/git/linux-2.4/drivers/media/video'
make[2]: *** [_subdir_video] Error 2
make[2]: Leaving directory `/usr/src/git/linux-2.4/drivers/media'
make[1]: *** [_subdir_media] Error 2
make[1]: Leaving directory `/usr/src/git/linux-2.4/drivers'
make: *** [_dir_drivers] Error 2

[GCC4] fix build error in drivers/i2c/i2c-proc.c

This patch fixes this error with gcc 4 :

i2c-proc.c: In function 'i2c_deregister_entry':
i2c-proc.c:208: error: invalid lvalue in assignment
i2c-proc.c: In function 'i2c_proc_chips':
i2c-proc.c:290: error: invalid lvalue in assignment
i2c-proc.c: In function 'i2c_sysctl_chips':
i2c-proc.c:322: error: invalid lvalue in assignment
i2c-proc.c: In function 'i2c_parse_reals':
i2c-proc.c:476: error: invalid lvalue in increment
i2c-proc.c:495: error: invalid lvalue in increment
i2c-proc.c:506: error: invalid lvalue in increment
i2c-proc.c:520: error: invalid lvalue in increment
i2c-proc.c:529: error: invalid lvalue in increment
i2c-proc.c:545: error: invalid lvalue in increment
i2c-proc.c: In function 'i2c_write_reals':
i2c-proc.c:577: error: invalid lvalue in increment
i2c-proc.c:618: error: invalid lvalue in assignment

[GCC4] fix build error in drivers/i2c/i2c-core.c

This patch fixes this error :
In file included from i2c-core.c:32:
/usr/src/git/linux-2.4/include/linux/i2c.h:73: error: array type has incomplete element type
/usr/src/git/linux-2.4/include/linux/i2c.h:200: error: array type has incomplete element type
i2c-core.c: In function 'i2c_transfer':
i2c-core.c:732: error: type of formal parameter 2 is incomplete
i2c-core.c: In function 'i2c_master_send':
i2c-core.c:753: error: invalid lvalue in assignment
i2c-core.c:759: error: type of formal parameter 2 is incomplete
i2c-core.c: In function 'i2c_master_recv':
i2c-core.c:789: error: type of formal parameter 2 is incomplete

[GCC4] fix build error in drivers/isdn/hisax/hfc_pci.c

This patch fixes this error with gcc 4 :

hfc_pci.c: In function 'setup_hfcpci':
hfc_pci.c:1745: error: invalid lvalue in assignment

[GCC4] fix build error in drivers/isdn/eicon/eicon.h

This patch fixes this error with gcc 4 :

eicon_mod.c:44: error: static declaration of 'cards' follows non-static declaration
eicon.h:347: error: previous declaration of 'cards' was here

[GCC4] fix build error in drivers/atm/fore200e.c

This patch fixes this error with gcc 4 :

fore200e.c:3175: error: static declaration of 'fore200e_ops' follows non-static declaration
fore200e.c:115: error: previous declaration of 'fore200e_ops' was here
fore200e.c:3198: error: static declaration of 'fore200e_bus' follows non-static declaration
fore200e.c:116: error: previous declaration of 'fore200e_bus' was here

[GCC4] fix build error in drivers/atm/iphase.c

This patch fixes these errors with gcc 4 :

iphase.c:89: error: static declaration of 'IADebugFlag' follows non-static declaration
iphase.h:71: error: previous declaration of 'IADebugFlag' was here
iphase.c: In function 'ia_que_tx':
iphase.c:630: error: invalid storage class for function 'ia_pkt_tx'
iphase.c:644: warning: implicit declaration of function 'ia_pkt_tx'
iphase.c: At top level:
iphase.c:2934: error: static declaration of 'ia_pkt_tx' follows non-static declaration
iphase.c:644: error: previous implicit declaration of 'ia_pkt_tx' was here

[GCC4] fix build error in drivers/md/lvm-internal.h

This patch fixes this error with gcc 4 :

lvm.c:397: error: static declaration of 'vg_count' follows non-static declaration
lvm-internal.h:48: error: previous declaration of 'vg_count' was here