2004-03-06 19:22:16

by Marcelo Tosatti

[permalink] [raw]
Subject: Linux 2.4.26-pre2



Hi,

Here goes -pre2 -- it contains networking updates, network drivers
updates, an XFS update, amongst others.

Detailed changelog follows

Summary of changes from v2.4.26-pre1 to v2.4.26-pre2
============================================

<dolbeau:irisa.fr>:
o Small fix to pm3fb & MAINTAINERS

<i.palsenberg:jdirmedia.nl>:
o [QLOGIC]: Mark mbox_param[] as static to avoid namespace pollution

<jon:focalhost.com>:
o [CRYPTO]: Add ARC4 module

<jpk:sgi.com>:
o [XFS] Merge missing mount stripe-unit/width-alignment check over from IRIX

<mlord:pobox.com>:
o Fix vmalloc() error handling

Chas Williams:
o [ATM]: [lec] timer cleanup
o [ATM]: [lec] send queued packets immediately after path switch

Christoph Hellwig:
o [XFS] Simplify pagebuf_rele / pagebuf_free
o [XFS] Stop using sleep_on
o [XFS] Plug a pagebuf race that got bigger with the recent cleanup
o [XFS] Fix gcc 3.5 compilation for real
o [XFS] Fix buffer teardown on _pagebuf_lookup_pages failure
o [XFS] Remove the lockable/not lockable buffer distinction. All metada buffers are lockable these days.
o [XFS] Remove PBF_MAPPABLE
o [XFS] plug a pagebuf leak
o [XFS] "backport" d_alloc_anon (this time for real)
o [XFS] Avoid NULL returns from pagebuf_get
o [XFS] use generic XFS stats and sysctl infrastructure in pagebuf
o [XFS] Fix up daemon names
o [XFS] only lock pagecache pages
o [XFS] plug race in pagebuf freeing
o [XFS] kill some dead constants from pagebuf

David S. Miller:
o [SUNGEM]: At end of RX completion chain, double check OWN bit with completion register
o [IPV4]: Do not return -EAGAIN on blocking UDP socket, noticed by Olaf Kirch
o [NET]: Set default socket rmem/wmem values more sanely and consistently
o [IPV6]: UDPv6 needs recvmsg csum error path fix too, thanks Olaf
o [SCTP]: Ranem MSECS_TO_JIFFIES to avoid conflict with IRDA
o [SCTP]: Comment out buggy ipv6 debugging printk
o [SPARC64]: Update defconfig
o [SPARC]: Pass a real page into do_mount() a final arg
o [SPARC]: Update defconfig

David Stevens:
o [IGMP/MLD]: Verify MSFILTER option length
o [IGMP/MLD]: Check for numsrc overflow, plus temp buffer tweaks

David Woodhouse:
o [IPV6]: Init ipv6 before ipv4 if built statically into kernel

Dean Roehrich:
o [XFS] Change DM_SEM_FLAG to DM_SEM_FLAG_RD

Don Fry:
o 2.4.25 pcnet32.c SLAB_DEBUG length error fix
o 2.4.25 pcnet32.c transmit hang fix
o 2.4.25 pcnet32.c wrong vendor ID fix
o 2.4.25 pcnet32.c oops in rmmod
o 2.4.25 pcnet32.c bus master arbitration failure fix
o 2.4.25 pcnet32.c convert to use netif_msg_*
o 2.4.25 pcnet32.c change to use ethtool_ops
o pcnet32.c handle failures in open
o pcnet32.c another diff error fix
o pcnet32.c non-mii errors with ethtool
o pcnet32.c add .remove to pci_driver
o pcnet32.c adds loopback test
o pcnet32.c avoid transmit hang for 79C791
o pcnet32 non-mii link state fix

Eric Sandeen:
o [XFS] Add switches to make xfs compile when the nptl patch is present
o [XFS] Remove some dead debug code
o [XFS] Make more xfs errors trappable with panic_mask
o [XFS] zero log buffer during initialization at mount time

François Romieu:
o [netdrvr r8169] fix TX descriptor overflow

Geert Uytterhoeven:
o [netdrvr tulip] fix up 21041 media selection

Harald Welte:
o [NETFILTER]: Kill bogus const in list helpers
o [NETFILTER]: Fix ECN target cloned skb problem
o [NETFILTER]: Remove unused structure member in NAT, from Patrick McHardy

James Morris:
o [CRYPTO]: Backport Christophe Saout's 2.6.x scatterlist code extraction

Jean Delvare:
o Identify Radeon Ya and Yd in radeonfb

Len Brown:
o ACPI URL update
o [ACPI] interrupt over-ride for nforce from Maciej W. Rozycki
o [ACPI] delete unnecessary dmesg lines, fix spelling
o [ACPI] include CONFIG_ACPI_RELAXED_AML code always add acpi=strict option to disable platform workarounds
o [ACPI] ACPICA 20040220 from Bob Moore
o [ACPI] fix ia64 build error (Bjorn Helgaas)

Marcelo Tosatti:
o devfs: Fix truncation of mount data as 2.6
o Changed EXTRAVERSION to -pre2

Matthias Andree:
o [NET]: Export sysctl_optmem_max to modules

Nathan Scott:
o [XFS] Fix a trivial compiler warning, remove some no-longer-used macros
o [XFS] Use list_move for moving pagebufs between lists, not list_add/list_del
o [XFS] Fix compile warning, ensure _pagebuf_lookup_pages return value is inited
o [XFS] Fix data loss when writing into unwritten extents while memory is being reclaimed
o [XFS] Remove bogus assert I added during testing of previous unwritten fix
o [XFS] Add I/O path tracing code, twas useful in diagnosing that last unwritten extent problem
o [XFS] Use a naming convention here thats more consistent with everything else
o [XFS] Fix BUG in debug trace code, it was plain wrong for the unmapped page case
o [XFS] Fix the by-handle attr list interface (used by xfsdump) for security attrs
o [XFS] Fix length of mount argument path strings, off by one
o [XFS] release i_sem before going into dmapi queues
o [XFS] Remove PBF_SYNC buffer flag, unused for some time now
o [XFS] Sort out some minor differences between trees
o [XFS] Fix a compiler warning from a redefined symbol

Shmulik Hen:
o bonding: Add support for HW accel. slaves
o bonding: Add VLAN support in TLB mode
o bonding: Add VLAN support in ALB mode

Simon Barber:
o [NET]: Capture skb->protocol after invoking bridge

Simon Horman:
o [JHASH]: Make key arg const in jhash()

Sridhar Samudrala:
o [SCTP] Fix packed attribute usage
o [SCTP] Fix NIP6 macro to take a ptr to struct in6_addr
o [SCTP] Fix incorrect INIT process termination with sinit_max_init_timeo

Timothy Shimmin:
o [XFS] Add XFS_FS_GOINGDOWN interface to xfs
o [XFS] Fix log recovery case when have v2 log with size >32K and we have a Log Record wrapping around the physical log end. Need to reset the pb size back to what we were using and NOT just 32K.
o [XFS] Version 2 log fixes - remove l_stripemask and add v2 log stripe padding to ic_roundoff to cater for pad in reservation cursor updates.
o [XFS] fix up some log debug code for when XFS_LOUD_RECOVERY is turned on

Xose Vazquez Perez:
o more RTL-8139 clone boards
o more ne2k-pci clone boards

Yasuyuki Kozakai:
o [IPV6]: Fix frag hdr parsing in ipv6_skip_exthdr()
o [IPV6]: Fix ip6_tables TCP/UDP matching when ipv6 ext hdr exists



2004-03-07 05:44:48

by Eyal Lebedinsky

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

--- linux/crypto/arc4.c.orig Sun Mar 7 16:33:11 2004
+++ linux/crypto/arc4.c Sun Mar 7 16:35:12 2004
@@ -55,14 +55,14 @@
static void arc4_crypt(void *ctx_arg, u8 *out, const u8 *in)
{
struct arc4_ctx *ctx = ctx_arg;
+ u8 *const S, x, y, a, b;

- u8 *const S = ctx->S;
- u8 x = ctx->x;
- u8 y = ctx->y;
-
- u8 a = S[x];
+ S = ctx->S;
+ x = ctx->x;
+ y = ctx->y;
+ a = S[x];
y = (y + a) & 0xff;
- u8 b = S[y];
+ b = S[y];
S[x] = b;
S[y] = a;
x = (x + 1) & 0xff;


Attachments:
2.4.26-pre2-arc4.patch (475.00 B)

2004-03-07 17:27:34

by Horst H. von Brand

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

Eyal Lebedinsky <[email protected]> said:
> Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > Here goes -pre2 -- it contains networking updates, network drivers
> > updates, an XFS update, amongst others.
> >
> > <jon:focalhost.com>:
> > o [CRYPTO]: Add ARC4 module
>
> In standard C we declare all variables at the top of a function. While
> some compilers allow extension, it is not a good idea to get used to
> them if we want portable code.

Oh, come on. This is _kernel_ code, it won't ever be compiled with anything
not GCC-compatible.

> If fails for me on Debian/stable.

What compiler is in use there?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

2004-03-07 18:49:15

by Roland Dreier

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

Eyal> In standard C we declare all variables at the top of a
Eyal> function. While some compilers allow extension, it is not a
Eyal> good idea to get used to them if we want portable code.

Horst> Oh, come on. This is _kernel_ code, it won't ever be
Horst> compiled with anything not GCC-compatible.

gcc 2.95 rejects declarations after code. The kernel, especially
kernel 2.4, shouldn't use this particular extension, even if gcc 3
accepts it.

- R.

2004-03-07 19:25:11

by David Weinehall

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

On Sun, Mar 07, 2004 at 01:19:46PM -0300, Horst von Brand wrote:
> Eyal Lebedinsky <[email protected]> said:
> > Marcelo Tosatti wrote:
> > >
> > > Hi,
> > >
> > > Here goes -pre2 -- it contains networking updates, network drivers
> > > updates, an XFS update, amongst others.
> > >
> > > <jon:focalhost.com>:
> > > o [CRYPTO]: Add ARC4 module
> >
> > In standard C we declare all variables at the top of a function. While
> > some compilers allow extension, it is not a good idea to get used to
> > them if we want portable code.
>
> Oh, come on. This is _kernel_ code, it won't ever be compiled with anything
> not GCC-compatible.

Ugly warts don't become any less ugly just because gcc accepts them...


Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/

2004-03-07 19:43:36

by Michael Frank

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

On 07 Mar 2004 10:49:05 -0800, Roland Dreier <[email protected]> wrote:

> Eyal> In standard C we declare all variables at the top of a
> Eyal> function. While some compilers allow extension, it is not a
> Eyal> good idea to get used to them if we want portable code.
>
> Horst> Oh, come on. This is _kernel_ code, it won't ever be
> Horst> compiled with anything not GCC-compatible.
>
> gcc 2.95 rejects declarations after code. The kernel, especially
> kernel 2.4, shouldn't use this particular extension, even if gcc 3
> accepts it.
>

I also use gcc 2.95 and have no intention to change compilers
for 2.4 at all as this compiler is most dependable and never
screwed up unlike 3.1.x and 3.2.2.

Documentation/Codingstyle also refers to K&R who historically
declare variables at the top of a function.

Excerpt:
"all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right"

Regards
Michael

2004-03-07 19:53:27

by Rene Herman

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

David Weinehall wrote:

>>>In standard C we declare all variables at the top of a function. While
>>>some compilers allow extension, it is not a good idea to get used to
>>>them if we want portable code.
>>
>>Oh, come on. This is _kernel_ code, it won't ever be compiled with anything
>>not GCC-compatible.
>
> Ugly warts don't become any less ugly just because gcc accepts them...

Mixing code and declarations is also c99. For (a sane) gcc specifically,
you have to tell it -std=c89 -pedantic to have it even complain.

Rene.

2004-03-07 19:59:14

by Jeff Garzik

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

Rene Herman wrote:
> David Weinehall wrote:
>
>>>> In standard C we declare all variables at the top of a function. While
>>>> some compilers allow extension, it is not a good idea to get used to
>>>> them if we want portable code.
>>>
>>>
>>> Oh, come on. This is _kernel_ code, it won't ever be compiled with
>>> anything
>>> not GCC-compatible.
>>
>>
>> Ugly warts don't become any less ugly just because gcc accepts them...
>
>
> Mixing code and declarations is also c99. For (a sane) gcc specifically,
> you have to tell it -std=c89 -pedantic to have it even complain.

Agreed, with the proviso s/sane/new/

We want to support older gccs that do not support the C99/C++ syntax,
for now.

Jeff




2004-03-07 20:05:17

by David Weinehall

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

On Sun, Mar 07, 2004 at 08:52:45PM +0100, Rene Herman wrote:
> David Weinehall wrote:
>
> >>>In standard C we declare all variables at the top of a function. While
> >>>some compilers allow extension, it is not a good idea to get used to
> >>>them if we want portable code.
> >>
> >>Oh, come on. This is _kernel_ code, it won't ever be compiled with
> >>anything
> >>not GCC-compatible.
> >
> >Ugly warts don't become any less ugly just because gcc accepts them...
>
> Mixing code and declarations is also c99. For (a sane) gcc specifically,
> you have to tell it -std=c89 -pedantic to have it even complain.

Ok, didn't know that. Still doesn't make it any less ugly, though.
There are quite a lot of things that a valid in C. That doesn't mean
they should be used...


Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/

2004-03-07 20:08:33

by Michal Schmidt

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

Hello,

> <mlord:pobox.com>:
> o Fix vmalloc() error handling
>

This change has a problem. In __vmalloc_area_pages when pmd_alloc fails,
the spinlock will not be released. Maybe the following patch is needed?
(only compile tested, I don't have SMP)

Michal Schmidt


--- linux-2.4.26-pre2/mm/vmalloc.c Sun Mar 7 20:44:27 2004
+++ linux-2.4.26-pre2.mich/mm/vmalloc.c Sun Mar 7 20:54:02 2004
@@ -183,6 +183,7 @@ static inline int __vmalloc_area_pages (
err:
if (address > start)
vmfree_area_pages((address - start), address - start);
+ spin_unlock(&init_mm.page_table_lock);
return -ENOMEM;
}

2004-03-07 20:59:36

by Michael Frank

[permalink] [raw]
Subject: Re: Linux 2.4.26-pre2

On Sun, 7 Mar 2004 21:05:09 +0100, David Weinehall <[email protected]> wrote:

> On Sun, Mar 07, 2004 at 08:52:45PM +0100, Rene Herman wrote:
>> David Weinehall wrote:
>>
>> >>>In standard C we declare all variables at the top of a function. While
>> >>>some compilers allow extension, it is not a good idea to get used to
>> >>>them if we want portable code.
>> >>
>> >>Oh, come on. This is _kernel_ code, it won't ever be compiled with
>> >>anything
>> >>not GCC-compatible.
>> >
>> >Ugly warts don't become any less ugly just because gcc accepts them...
>>
>> Mixing code and declarations is also c99. For (a sane) gcc specifically,
>> you have to tell it -std=c89 -pedantic to have it even complain.
>
> Ok, didn't know that. Still doesn't make it any less ugly, though.
> There are quite a lot of things that a valid in C. That doesn't mean
> they should be used...

C99 is C++ish. I have my experience with these methods after following
the PopularCppWays for some time. HellIsThisCrap which I wrote a pain
to maintain...

When a function is short and concise, there is no need to worry about
the few variables at the top.

Regards
Michael