Hi,
Here goes the second release candidate. It contains an ACPI update,
networking updates, IDE updates, XFS update, etc.
Detailed changelog follows
Summary of changes from v2.4.26-rc1 to v2.4.26-rc2
============================================
<uaca:alumni.uv.es>:
o [AF_PACKET]: Fix packet_set_ring memleak and remove num frame limit
o [AF_PACKET]: Add PACKET_MMAP documentation
Andi Kleen:
o Use correct optimization flag for Nocona on x86-64
Bartlomiej Zolnierkiewicz:
o ATI IXP IDE support
o hpt366.c: DMA timeout fix for HPT374
Chas Williams:
o [ATM]: mpoa_proc warning cleanup (from Willy TARREAU <[email protected]>)
Christoph Hellwig:
o [XFS] fix for read/write buffers larger than 2GB on 64 bit platforms
o [XFS] Fix r/o check in xfs_ioc_space, fix checks on xfs_swapext validity
David S. Miller:
o [IPV6]: Fix ipv6_skip_exthdr prototype in net/ipv6.h
David Stevens:
o [IPV4]: Fix IGMPv3 timer initialization when device not 'upped'
Glen Overby:
o [XFS] Add space for inode and allocation btrees to ITRUNCATE log reservation
Harald Welte:
o [NETFILTER]: Fix DEBUG compile in ipt_MASQUERADE
o [NETFILTER]: Fix DELETE_LIST oopses
o [NETFILTER]: Fix circular conntrack header file dependency
Hideaki Yoshifuji:
o [CREDITS]: Update my affiliation
Ivan Kokshaysky:
o Workaround Alpha "gcc3 < 3.3.3" raid1 miscompilation problem
Len Brown:
o [ACPI] allow building ACPI w/ CMPXCHG when CONFIG_M386=y http://bugzilla.kernel.org/show_bug.cgi?id=2391
o [ACPI] delete extraneous IRQ->pin mappings below IRQ 16 http://bugzilla.kernel.org/show_bug.cgi?id=2408
o [ACPI] PCI bridge interrupt fix (David Shaohua Li) http://bugzilla.kernel.org/show_bug.cgi?id=2409
o [ACPI] Restore PIC-mode SCI default to Level Trigger (David Shaohua Li) http://bugme.osdl.org/show_bug.cgi?id=2382
Marcelo Tosatti:
o Changed EXTRAVERSION to -rc2
Matt Porter:
o PPC32: PPC44x updates (fixes and 440GX machine check support)
o PPC32: Add new PPC44x PVRs
Meelis Roos:
o SanDisk is flash
Mike Miller:
o cciss update: support the new MSA30 storage enclosure
o cciss update: If no device attached we return -ENXIO instead of some bogus numbers
Nathan Scott:
o [XFS] Remove dup fdatasync/fdatawait call on fsync. Means we no longer take the iolock here, and readers no longer conflict with concurrent fsync activity. Kudos to Steve!
o [XFS] Reinstate some accidentally dropped log IO error injection code
o [XFS] Fix shortform attr flags botch affecting listxattr - from Andreas Gruenbacher
o [XFS] Disallow logbufs=0 unless correct config options used, else we panic
o [XFS] Ensure sb not flushed async on a SYNC_WAIT sync. Fixed by Bart Samwel
Nathan Straz:
o [XFS] Fix signed offset overflow when checking writes at end of file
Nivedita Singhvi:
o [TCP]: Use tcp_tw_put on time-wait sockets
o [TCP]: IPV6, do not use sock_put() on timewait sockets
Paul Mackerras:
o [PPC64] Fix && vs. & error noticed by Julie DeWandel
Russell Cattelan:
o [XFS] Use refile_buffer to not leave clean buffers on the dirty list
Sridhar Samudrala:
o [SCTP]: Fix xconfig, from Vladislav Yasevich
Timothy Shimmin:
o [XFS] Modify xfs_iaccess() for CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH
o [XFS] Be explicit in adding in the non-transactional data to the reservation estimate. We must add in for the worst case of a log stripe taking us the full distance for a log stripe boundary.
Urban Widmark:
o smbfs transact2 with win9x
Willy Tarreau:
o [IPV6]: Make skb arg to ipv6_skip_exthdr const
Marcelo,
Any chance of getting this patch in before 2.4.26 final?
This patch is needed for compiling 2.4 with recent versions of gcc,
such as the gcc 3.3.3 hammer branch or gcc 3.4. The gcc developers
changed the name of the attribute that indicates that something is
actually needed, even though gcc can't see why, from "__unused__" to
"__used__". This patch copes with that.
The patch is from Stephen Rothwell. He discovered the problem on
ppc64, but in fact it would exist on any architecture.
Thanks,
Paul.
diff -ruN ppc64-linux-2.4/include/linux/compiler.h ppc64-linux-2.4.used/include/linux/compiler.h
--- ppc64-linux-2.4/include/linux/compiler.h 2003-08-22 12:30:56.000000000 +1000
+++ ppc64-linux-2.4.used/include/linux/compiler.h 2004-03-30 15:15:18.000000000 +1000
@@ -13,4 +13,18 @@
#define likely(x) __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
+#if __GNUC__ > 3
+#define __attribute_used__ __attribute((__used__))
+#elif __GNUC__ == 3
+#if __GNUC_MINOR__ >= 3
+# define __attribute_used__ __attribute__((__used__))
+#else
+# define __attribute_used__ __attribute__((__unused__))
+#endif /* __GNUC_MINOR__ >= 3 */
+#elif __GNUC__ == 2
+#define __attribute_used__ __attribute__((__unused__))
+#else
+#define __attribute_used__ /* not implemented */
+#endif /* __GNUC__ */
+
#endif /* __LINUX_COMPILER_H */
diff -ruN ppc64-linux-2.4/include/linux/init.h ppc64-linux-2.4.used/include/linux/init.h
--- ppc64-linux-2.4/include/linux/init.h 2003-08-22 12:30:56.000000000 +1000
+++ ppc64-linux-2.4.used/include/linux/init.h 2004-03-30 15:22:50.000000000 +1000
@@ -2,6 +2,7 @@
#define _LINUX_INIT_H
#include <linux/config.h>
+#include <linux/compiler.h>
/* These macros are used to mark some functions or
* initialized data (doesn't apply to uninitialized data)
@@ -51,7 +52,7 @@
extern initcall_t __initcall_start, __initcall_end;
#define __initcall(fn) \
- static initcall_t __initcall_##fn __init_call = fn
+ static initcall_t __initcall_##fn __attribute_used__ __init_call = fn
#define __exitcall(fn) \
static exitcall_t __exitcall_##fn __exit_call = fn
@@ -67,7 +68,7 @@
#define __setup(str, fn) \
static char __setup_str_##fn[] __initdata = str; \
- static struct kernel_param __setup_##fn __attribute__((unused)) __initsetup = { __setup_str_##fn, fn }
+ static struct kernel_param __setup_##fn __attribute_used__ __initsetup = { __setup_str_##fn, fn }
#endif /* __ASSEMBLY__ */
@@ -76,12 +77,12 @@
* or exit time.
*/
#define __init __attribute__ ((__section__ (".text.init")))
-#define __exit __attribute__ ((unused, __section__(".text.exit")))
+#define __exit __attribute_used__ __attribute__ (( __section__(".text.exit")))
#define __initdata __attribute__ ((__section__ (".data.init")))
-#define __exitdata __attribute__ ((unused, __section__ (".data.exit")))
-#define __initsetup __attribute__ ((unused,__section__ (".setup.init")))
-#define __init_call __attribute__ ((unused,__section__ (".initcall.init")))
-#define __exit_call __attribute__ ((unused,__section__ (".exitcall.exit")))
+#define __exitdata __attribute_used__ __attribute__ ((__section__ (".data.exit")))
+#define __initsetup __attribute_used__ __attribute__ ((__section__ (".setup.init")))
+#define __init_call __attribute_used__ __attribute__ ((__section__ (".initcall.init")))
+#define __exit_call __attribute_used__ __attribute__ ((__section__ (".exitcall.exit")))
/* For assembly routines */
#define __INIT .section ".text.init","ax"
diff -ruN ppc64-linux-2.4/include/linux/module.h ppc64-linux-2.4.used/include/linux/module.h
--- ppc64-linux-2.4/include/linux/module.h 2003-08-22 12:30:56.000000000 +1000
+++ ppc64-linux-2.4.used/include/linux/module.h 2004-03-30 15:24:25.000000000 +1000
@@ -254,9 +254,9 @@
*/
#define MODULE_GENERIC_TABLE(gtype,name) \
static const unsigned long __module_##gtype##_size \
- __attribute__ ((unused)) = sizeof(struct gtype##_id); \
+ __attribute_used__ = sizeof(struct gtype##_id); \
static const struct gtype##_id * __module_##gtype##_table \
- __attribute__ ((unused)) = name
+ __attribute_used__ = name
/*
* The following license idents are currently accepted as indicating free
@@ -319,7 +319,7 @@
*/
#define MODULE_GENERIC_TABLE(gtype,name) \
static const struct gtype##_id * __module_##gtype##_table \
- __attribute__ ((unused, __section__(".data.exit"))) = name
+ __attribute_used__ __attribute__ ((__section__(".data.exit"))) = name
#ifndef __GENKSYMS__
On Tue, Apr 06, 2004 at 11:57:12AM +1000, Paul Mackerras wrote:
> Marcelo,
>
> Any chance of getting this patch in before 2.4.26 final?
>
> This patch is needed for compiling 2.4 with recent versions of gcc,
> such as the gcc 3.3.3 hammer branch or gcc 3.4. The gcc developers
> changed the name of the attribute that indicates that something is
> actually needed, even though gcc can't see why, from "__unused__" to
> "__used__". This patch copes with that.
>
> The patch is from Stephen Rothwell. He discovered the problem on
> ppc64, but in fact it would exist on any architecture.
Applied,
thanks!
Marcelo Tosatti wrote:
> Hi,
>
> Here goes the second release candidate. It contains an ACPI update,
> networking updates, IDE updates, XFS update, etc.
Building the (binary) nvidia driver I got this warning:
In file included from /lib/modules/2.4.26-rc2/build/include/linux/vmalloc.h:8,
from nv-linux.h:62,
from os-interface.c:26:
/lib/modules/2.4.26-rc2/build/include/linux/highmem.h: In function `bh_kmap':
/lib/modules/2.4.26-rc2/build/include/linux/highmem.h:20: warning: pointer of type `void *' used in arithmetic
Looking there I see:
static inline char *bh_kmap(struct buffer_head *bh)
{
return kmap(bh->b_page) + bh_offset(bh);
}
And in /usr/include/linux/highmem.h I see:
static inline void *kmap(struct page *page) { return page_address(page); }
So we really are doing 'void *' math, which is not right. Maybe a cast is
called for in bh_kmap(), like:
return (char *)kmap(bh->b_page) + bh_offset(bh);
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
Marcelo Tosatti wrote:
> The void pointer case in here its being done math on without any problem. What is the
> problem with void pointer math
There is a problem regarding the C standard. The semantics of 'void *' are well defined
and only allow for limited use. Basically, you can cast any pointer to and from 'void *',
but nothing else.
Pointer math says that 'p+n' means "add to 'p' the value 'n*s' where 's' is the size
on the element that 'p' points to". A 'void *' does not have a defined element size
until it is cast. So, ANSI specifically does not allow any arithmetics on 'void *'.
Some compilers are forgiving and will invent an element size of '1' and allow the
math. We should not rely on such improper usage.
>> Maybe a cast is
>>called for in bh_kmap(), like:
>> return (char *)kmap(bh->b_page) + bh_offset(bh);
>
>
> Hum, that would fix the warning but I dont see much reasoning behind it.
It will not simply 'fix' the problem, this is one case where a cast is not
a bad thing (i.e. a cheat) but the correct thing to do.
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
Eyal Lebedinsky wrote:
> Marcelo Tosatti wrote:
>
>> The void pointer case in here its being done math on without any
>> problem. What is the
>> problem with void pointer math
>
>
> There is a problem regarding the C standard. The semantics of 'void *'
> are well defined
> and only allow for limited use. Basically, you can cast any pointer to
> and from 'void *',
> but nothing else.
>
> Pointer math says that 'p+n' means "add to 'p' the value 'n*s' where 's'
> is the size
> on the element that 'p' points to". A 'void *' does not have a defined
> element size
> until it is cast. So, ANSI specifically does not allow any arithmetics
> on 'void *'.
>
> Some compilers are forgiving and will invent an element size of '1' and
> allow the
> math. We should not rely on such improper usage.
Void pointer arithmatic is an explicit gcc extension, and used
extensively throughout the kernel.
Jeff