Hi,
Here goes the second release candidate for v2.4.30.
It contains a bunch of security updates (ext2 mkdir leak, af_bluetooth range
checking, isofs corrupt media, load_elf_library DoS), an ia64 update, another
round of networking fixes, amongst others.
If nothing terrible shows up, this will become v2.4.30.
Please help with testing!
Summary of changes from v2.4.30-rc1 to v2.4.30-rc2
============================================
<davem:sunset.davemloft.net>:
o [TG3]: Add missing CHIPREV_5750_{A,B}X defines
o [TG3]: Missing counter bump in tigon3_4gb_hwbug_workaround()
o [TG3]: Update driver version and reldate
<magnus.damm:gmail.com>:
o eepro100: fix module parameter description typo
<mlafon:arkoon.net>:
o CAN-2005-0400: ext2 mkdir() directory entry random kernel memory leak
<relf:os2.ru>:
o fs/hpfs/*: fix HPFS support under 64-bit kernel
<sj-netfilter:cookinglinux.org>:
o [NETFILTER]: Fix another DECLARE_MUTEX in header file
Bjorn Helgaas:
o ia64: force all kernel sections into one and the same segment
o ia64: round iommu allocations to power-of-two sizes
o ia64: fix perfmon typo in /proc/pal/CPU*/processor_info w.r.t. BERR
o ia64: add missing syscall-slot
o ia64: Update defconfigs
Chris Wright:
o isofs: Some more defensive checks to keep corrupt isofs images from corrupting memory/oopsing
Dave Kleikamp:
o JFS: remove aops from directory inodes
David Mosberger:
o Fix pte_modify() bug which allowed mprotect() to change too many bits
o ia64: Fix _PAGE_CHG_MASK so PROT_NONE works again. Caught by Linus
Greg Banks:
o link_path_walk refcount problem allows umount of active filesystem
Herbert Xu:
o [CRYPTO]: Mark myself as co-maintainer
o [NETLINK]: Fix multicast bind/autobind race
o CAN-2005-0794: Potential DOS in load_elf_library
Keith Owens:
o [IA64] Sanity check unw_unwind_to_user
o [IA64] Tighten up unw_unwind_to_user check
Linus Torvalds:
o isofs: Handle corupted rock-ridge info slightly better
o isofs: more "corrupted iso image" error cases
Marcel Holtmann:
o CAN-2005-0750: Fix af_bluetooth range checking bug, discovered by Ilja van Sprundel <[email protected]>
Marcelo Tosatti:
o Change VERSION to 2.4.30-rc2
Michael Chan:
o [TG3]: Add 5705_plus flag
o [TG3]: Flush status block in tg3_interrupt()
o [TG3]: Add unstable PLL workaround for 5750
o [TG3]: Fix jumbo frames phy settings
o [TG3]: Fix ethtool set functions
o [TG3]: Add Broadcom copyright
Neil Brown:
o nlm: fix f_count leak
o [PATCH md: allow degraded raid1 array to resync after an unclean shutdown
Pablo Neira:
o [NETFILTER]: Fix DECLARE_MUTEX in header file
Patrick McHardy:
o [NETFILTER]: fix return values of ipt_recent checkentry
o [NETFILTER]: Fix ip_ct_selective_cleanup(), and rename ip_ct_iterate_cleanup()
o [NETFILTER]: Fix cleanup in ipt_recent
o [NETFILTER]: Fix ip6tables ESP matching with "-p all"
o [NETFILTER]: Fix refreshing of overlapping expectations
o [NETFILTER]: Fix IP/TCP option logging
o [TUN]: Fix check for underflow
Pete Zaitcev:
o USB: fix oops in serial_write
o USB: Fix baud selection in mct_u232
Simon Horman:
o [IPVS]: Fix comment typos
o Backport v2.6 ATM copy-to-user signedness fix
o earlyquirk.o is needed for CONFIG_ACPI_BOOT
Stephen Hemminger:
o [TCP]: BIC not binary searching correctly
Wensong Zhang:
o [IPVS]: Update mark->cw in the WRR scheduler while service is updated
Yanmin Zhang:
o [IA64] clean up ptrace corner cases
Hi Marcelo, Hi Michael,
ok, it runs fine on athlon-smp and pentium-M notebook.
I still have my negociation trouble on the notebook with the tg3, but as
I have not yet reported them, this is normal ;-)
Basically, when the nic is connected to a 100 Mbps, forced-full duplex
switch (eg: cisco), the NIC negociates 100-half. If I set duplex to auto
on the switch, tg3 goes to 100-full. Now, as soon as I set autoneg to off
on the tg3 with ethtool (v3), the link goes down, whatever the speed and
duplex, or the config on the switch. Setting the interface down then up
does not change anything. So I have no solution to connect this notebook
to a forced 100-full switch (very common in enterprise networks and hosting
rooms), and honnestly, changing the configuration on the switch is not
often an option when I come with my notebook for network troubleshooting ;-)
This is not critical at all as I always have my cardbus 3c575 with me, so
I don't consider this a show-stopper for 2.4.30 at all. But if Michael has
any ideas about the problem or a trivial patch to test, I can do some
testings in a short timeframe as I can reproduce the problem right here,
and the fix could interest other people with similar chips.
For reference, the chip is identified as Broadcom NetXtreme BCM5705M_2 rev3
(id 14e4:165e, subsystem 103c:088c). It's in an hp compaq nc8000.
Regards,
Willy
On Fri, Mar 25, 2005 at 09:46:31PM -0300, Marcelo Tosatti wrote:
> Hi,
>
> Here goes the second release candidate for v2.4.30.
>
> It contains a bunch of security updates (ext2 mkdir leak, af_bluetooth range
> checking, isofs corrupt media, load_elf_library DoS), an ia64 update, another
> round of networking fixes, amongst others.
>
> If nothing terrible shows up, this will become v2.4.30.
>
> Please help with testing!
>
> Summary of changes from v2.4.30-rc1 to v2.4.30-rc2
> ============================================
>
> <davem:sunset.davemloft.net>:
> o [TG3]: Add missing CHIPREV_5750_{A,B}X defines
> o [TG3]: Missing counter bump in tigon3_4gb_hwbug_workaround()
> o [TG3]: Update driver version and reldate
>
> <magnus.damm:gmail.com>:
> o eepro100: fix module parameter description typo
>
> <mlafon:arkoon.net>:
> o CAN-2005-0400: ext2 mkdir() directory entry random kernel memory leak
>
> <relf:os2.ru>:
> o fs/hpfs/*: fix HPFS support under 64-bit kernel
>
> <sj-netfilter:cookinglinux.org>:
> o [NETFILTER]: Fix another DECLARE_MUTEX in header file
>
> Bjorn Helgaas:
> o ia64: force all kernel sections into one and the same segment
> o ia64: round iommu allocations to power-of-two sizes
> o ia64: fix perfmon typo in /proc/pal/CPU*/processor_info w.r.t. BERR
> o ia64: add missing syscall-slot
> o ia64: Update defconfigs
>
> Chris Wright:
> o isofs: Some more defensive checks to keep corrupt isofs images from corrupting memory/oopsing
>
> Dave Kleikamp:
> o JFS: remove aops from directory inodes
>
> David Mosberger:
> o Fix pte_modify() bug which allowed mprotect() to change too many bits
> o ia64: Fix _PAGE_CHG_MASK so PROT_NONE works again. Caught by Linus
>
> Greg Banks:
> o link_path_walk refcount problem allows umount of active filesystem
>
> Herbert Xu:
> o [CRYPTO]: Mark myself as co-maintainer
> o [NETLINK]: Fix multicast bind/autobind race
> o CAN-2005-0794: Potential DOS in load_elf_library
>
> Keith Owens:
> o [IA64] Sanity check unw_unwind_to_user
> o [IA64] Tighten up unw_unwind_to_user check
>
> Linus Torvalds:
> o isofs: Handle corupted rock-ridge info slightly better
> o isofs: more "corrupted iso image" error cases
>
> Marcel Holtmann:
> o CAN-2005-0750: Fix af_bluetooth range checking bug, discovered by Ilja van Sprundel <[email protected]>
>
> Marcelo Tosatti:
> o Change VERSION to 2.4.30-rc2
>
> Michael Chan:
> o [TG3]: Add 5705_plus flag
> o [TG3]: Flush status block in tg3_interrupt()
> o [TG3]: Add unstable PLL workaround for 5750
> o [TG3]: Fix jumbo frames phy settings
> o [TG3]: Fix ethtool set functions
> o [TG3]: Add Broadcom copyright
>
> Neil Brown:
> o nlm: fix f_count leak
> o [PATCH md: allow degraded raid1 array to resync after an unclean shutdown
>
> Pablo Neira:
> o [NETFILTER]: Fix DECLARE_MUTEX in header file
>
> Patrick McHardy:
> o [NETFILTER]: fix return values of ipt_recent checkentry
> o [NETFILTER]: Fix ip_ct_selective_cleanup(), and rename ip_ct_iterate_cleanup()
> o [NETFILTER]: Fix cleanup in ipt_recent
> o [NETFILTER]: Fix ip6tables ESP matching with "-p all"
> o [NETFILTER]: Fix refreshing of overlapping expectations
> o [NETFILTER]: Fix IP/TCP option logging
> o [TUN]: Fix check for underflow
>
> Pete Zaitcev:
> o USB: fix oops in serial_write
> o USB: Fix baud selection in mct_u232
>
> Simon Horman:
> o [IPVS]: Fix comment typos
> o Backport v2.6 ATM copy-to-user signedness fix
> o earlyquirk.o is needed for CONFIG_ACPI_BOOT
>
> Stephen Hemminger:
> o [TCP]: BIC not binary searching correctly
>
> Wensong Zhang:
> o [IPVS]: Update mark->cw in the WRR scheduler while service is updated
>
> Yanmin Zhang:
> o [IA64] clean up ptrace corner cases
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Marcelo,
just in case you release an -rc3, would you please include this typo fix
from Jurgen Quade. I have it in my tree since 2.4.23, it's a pure copy-paste
typo which causes the driver either to print an incomplete message or a
seconde unexpected one. BTW, it's fixed in 2.6.
Thanks,
Willy
--- ./drivers/block/floppy.old.c 2003-12-22 11:42:42.000000000 +0100
+++ ./drivers/block/floppy.c 2003-12-22 11:44:00.000000000 +0100
@@ -2563,7 +2563,7 @@
current_count_sectors);
if (CT(COMMAND) == FD_READ)
printk("read\n");
- if (CT(COMMAND) == FD_READ)
+ if (CT(COMMAND) == FD_WRITE)
printk("write\n");
break;
}
@@ -2894,7 +2894,7 @@
current_count_sectors);
if (CT(COMMAND) == FD_READ)
printk("read\n");
- if (CT(COMMAND) == FD_READ)
+ if (CT(COMMAND) == FD_WRITE)
printk("write\n");
return 0;
}
Marcelo, David,
could we merge this patch from Mitch Williams in 2.4.30 ? It fixes a
stack dump when unloading the bonding module in 802.3ad mode if spinlock
debugging is turned on.
Thanks in advance,
Willy
diff -urN linux-2.4.29/drivers/net/bonding/bond_main.c linux-2.4.29-bond-2.6.1/drivers/net/bonding/bond_main.c
--- linux-2.4.29/drivers/net/bonding/bond_main.c Sun Dec 12 12:06:28 2004
+++ linux-2.4.29-bond-2.6.1/drivers/net/bonding/bond_main.c Sun Feb 6 20:32:49 2005
@@ -469,6 +469,13 @@
* * Add support for VLAN hardware acceleration capable slaves.
* * Add capability to tag self generated packets in ALB/TLB modes.
* Set version to 2.6.0.
+ * 2004/10/29 - Mitch Williams <mitch.a.williams at intel dot com>
+ * - Fixed bug when unloading module while using 802.3ad. If
+ * spinlock debugging is turned on, this causes a stack dump.
+ * Solution is to move call to dev_remove_pack outside of the
+ * spinlock.
+ * Set version to 2.6.1.
+ *
*/
//#define BONDING_DEBUG 1
@@ -3565,14 +3572,14 @@
{
struct bonding *bond = bond_dev->priv;
- write_lock_bh(&bond->lock);
-
- bond_mc_list_destroy(bond);
-
if (bond->params.mode == BOND_MODE_8023AD) {
/* Unregister the receive of LACPDUs */
bond_unregister_lacpdu(bond);
}
+
+ write_lock_bh(&bond->lock);
+
+ bond_mc_list_destroy(bond);
/* signal timers not to re-arm */
bond->kill_timers = 1;
Marcelo,
here's a patch from Dave Jones, which is already in 2.6 and which I've
used in my local tree for 6 months now. It removes a useless NULL check
in zlib_inflateInit2_(), since 'z' is already dereferenced one line
before the test. Can in go in 2.4.30 please ?
Thanks,
Willy
--- ./lib/zlib_inflate/inflate.c.orig Tue Jan 7 15:50:49 2003
+++ ./lib/zlib_inflate/inflate.c Sat Sep 18 17:30:59 2004
@@ -50,8 +50,6 @@
return Z_VERSION_ERROR;
/* initialize state */
- if (z == Z_NULL)
- return Z_STREAM_ERROR;
z->msg = Z_NULL;
z->state = &WS(z)->internal_state;
z->state->blocks = Z_NULL;
Marcelo,
just another one and that's all. Zachary Amsden found an unconditional
write to a debug register in the signal delivery path which is only
needed when we use a breakpoint. This is a very expensive operation on
x86, and doing it conditionnaly enhanced signal delivery speed by 33%
for him.
His patch got merged in 2.6.10, and I've merged it a month ago in my
local tree. Could we get it in 2.4.30, please ?
Thanks in advance,
Willy
--
I noticed an unneeded write to dr7 in the signal handling path for x86.
We only need to write to dr7 if there is a breakpoint to re-enable, and
MOVDR is a serializing instruction, which is expensive. Getting rid of
it gets a 33% faster signal delivery path (at least on Xeon - I didn't
test other CPUs, so your gain may vary).
Cheers,
Zachary Amsden
[email protected]
--------------070400020104010700090602
Content-Type: text/plain;
name="README.i386-fast-signal"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="README.i386-fast-signal"
Optimize away the unconditional write to debug registers on signal delivery
path. This is already done on x86_64. Measured delta TSC for three paths
on a 2.4GHz Xeon.
1) With unconditional write to dr7 : 800-1000 cycles
2) With conditional write to dr7 : 84-112 cycles
3) With unlikely write to dr7 : 84 cycles
Performance test using divzero microbenchmark (3 million divide by zeros):
With unconditional write:
7.445 real / 6.136 system
7.529 real / 6.482 system
7.541 real / 5.974 system
7.546 real / 6.217 system
7.445 real / 6.167 system
With unlikely write:
5.779 real / 4.518 system
5.783 real / 4.591 system
5.552 real / 4.569 system
5.790 real / 4.528 system
5.554 real / 4.382 system
That's about a 33% speedup - more than I expected; apparently getting rid
of the serializing instruction makes the do_signal path much faster.
Zachary Amsden ([email protected])
--------------070400020104010700090602
Content-Type: text/plain;
name="i386-fast-signal.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="i386-fast-signal.patch"
[hand-edited line numbers to match 2.4]
--- linux-2.6.10-rc1/arch/i386/kernel/signal.c 2004-10-25 11:15:43.000000000 -0700
+++ linux-2.6.10-rc1-nsz/arch/i386/kernel/signal.c 2004-10-26 14:30:54.000000000 -0700
@@ -600,7 +600,9 @@
* have been cleared if the watchpoint triggered
* inside the kernel.
*/
- __asm__("movl %0,%%db7" : : "r" (current->thread.debugreg[7]));
+ if (unlikely(current->thread.debugreg[7])) {
+ __asm__("movl %0,%%db7" : : "r" (current->thread.debugreg[7]));
+ }
/* Whee! Actually deliver the signal. */
handle_signal(signr, &info, &ka, oldset, regs);
On Sat, 2005-03-26 at 12:22 +0100, Willy Tarreau wrote:
> Marcelo,
>
> here's a patch from Dave Jones, which is already in 2.6 and which I've
> used in my local tree for 6 months now. It removes a useless NULL check
> in zlib_inflateInit2_(), since 'z' is already dereferenced one line
> before the test. Can in go in 2.4.30 please ?
I don't see how such a cleanup-only patch would be a candidate for 2.4
at all, let alone to go into a -rc3 or a 2.4.30 final at this stage...
Can you explain why this one is so important that it has to go in so
late?
On Sat, 2005-03-26 at 12:34 +0100, Willy Tarreau wrote:
> Marcelo,
>
> just another one and that's all. Zachary Amsden found an unconditional
> write to a debug register in the signal delivery path which is only
> needed when we use a breakpoint. This is a very expensive operation on
> x86, and doing it conditionnaly enhanced signal delivery speed by 33%
> for him.
this sounds rather risky for this late in the game; heck it sounds risky
in 2.4 period. This code changed a lot in 2.6 so just a plain backport
is by no means risk free, while the effect of a wrong debug register can
even have security impact.
On Sat, Mar 26, 2005 at 12:44:53PM +0100, Arjan van de Ven wrote:
> On Sat, 2005-03-26 at 12:22 +0100, Willy Tarreau wrote:
> > Marcelo,
> >
> > here's a patch from Dave Jones, which is already in 2.6 and which I've
> > used in my local tree for 6 months now. It removes a useless NULL check
> > in zlib_inflateInit2_(), since 'z' is already dereferenced one line
> > before the test. Can in go in 2.4.30 please ?
>
> I don't see how such a cleanup-only patch would be a candidate for 2.4
> at all, let alone to go into a -rc3 or a 2.4.30 final at this stage...
>
> Can you explain why this one is so important that it has to go in so
> late?
On the contrary, it's just because it's not important at all that I
thought it could go in, the same way as other parts of unused code
got removed in rc2 (eg: jfs aops). As to the fact that it's late,
well, I would have prefered sending it sooner, but I simply don't
decide when I have spare time for this.
I have no problem at all with all these patches not merged, I simply
think that it makes maintainers' work easier to support homogeneous
code across versions with the least possible dead code, especially
when it comes to simple patches like this one. If you think it's better
to keep unused code because it makes debugging funnier, OK, that's fine.
Anyway, I'm just proposing, maintainers decide.
Willy
On Sat, Mar 26, 2005 at 12:46:19PM +0100, Arjan van de Ven wrote:
> On Sat, 2005-03-26 at 12:34 +0100, Willy Tarreau wrote:
> > Marcelo,
> >
> > just another one and that's all. Zachary Amsden found an unconditional
> > write to a debug register in the signal delivery path which is only
> > needed when we use a breakpoint. This is a very expensive operation on
> > x86, and doing it conditionnaly enhanced signal delivery speed by 33%
> > for him.
>
> this sounds rather risky for this late in the game; heck it sounds risky
> in 2.4 period. This code changed a lot in 2.6 so just a plain backport
> is by no means risk free, while the effect of a wrong debug register can
> even have security impact.
ok, that's a good reason.
Willy
On Sat, Mar 26, 2005 at 12:44:53PM +0100, Arjan van de Ven wrote:
> On Sat, 2005-03-26 at 12:22 +0100, Willy Tarreau wrote:
> > Marcelo,
> >
> > here's a patch from Dave Jones, which is already in 2.6 and which I've
> > used in my local tree for 6 months now. It removes a useless NULL check
> > in zlib_inflateInit2_(), since 'z' is already dereferenced one line
> > before the test. Can in go in 2.4.30 please ?
>
> I don't see how such a cleanup-only patch would be a candidate for 2.4
> at all, let alone to go into a -rc3 or a 2.4.30 final at this stage...
>
> Can you explain why this one is so important that it has to go in so
> late?
I second.
Willy, please resend the other ones for 2.4.31-pre ok?
Should have held the JFS one also.
This should go through Jeff Garzik, at least let him review and look
over it.
Willy Tarreau <[email protected]> writes:
> Marcelo,
>
> just another one and that's all. Zachary Amsden found an unconditional
> write to a debug register in the signal delivery path which is only
> needed when we use a breakpoint. This is a very expensive operation on
> x86, and doing it conditionnaly enhanced signal delivery speed by 33%
> for him.
>
> His patch got merged in 2.6.10, and I've merged it a month ago in my
> local tree. Could we get it in 2.4.30, please ?
I dont think it belongs in 2.4.x. It is not a critical bug fix.
-Andi