Linux v2.5.52

Linux v2.5.52

[Linus Torvalds]

Various things here. Most noticeably more merges with Andrew, with a 
lot of various small fixes.

XFS, JFS, ACPI and USB updates. KConfig update, and Rusty's module
parameter implementation. And fix the stupid nanosleep() thing that broke 
some programs.

I'm pushing this out, as I've tried to sync up the stuff I got while I was 
away this week (hint hint: if it ain't here, it's not in my in-queue, and 
you should re-send).

		Linus

---

Summary of changes from v2.5.51 to v2.5.52
============================================

Dario Ballabio <ballabio_dario@emc.com>:
  o eata driver update

Peter Braam <braam@clusterfs.com>:
  o intermezzo update

James Simmons <jsimmons@infradead.org>:
  o VT scrolling fix

<khaho@koti.soon.fi>:
  o USB: start to remove static minor based arrays in drivers

<marekm@amelek.gda.pl>:
  o Datafab KECF-USB / Sagatek DCS-CF / Simpletech UCF-100

<nobita@t-online.de>:
  o support for Sony Cybershot F717 digital camera / usb-storage

<romieu@fr.zoreil.com>:
  o missing piece of Iphase atm driver update

Stelian Pop <stelian@popies.net>:
  o sonypi driver update

Andrew Morton <akpm@digeo.com>:
  o Avoid recursion in the page allocator
  o deprecate use of bdflush()
  o create /proc/kmsg, remove sys_syslog()-based
  o speed up read_zero() for !CONFIG_MMU
  o Fix rmap locking for CONFIG_SWAP=n
  o semtimedop - semop() with a timeout
  o skip memory-backed filesystems in writeback
  o Remove fail_writepage, redux
  o show_free_areas extensions
  o make sure all PMDs are allocated under PAE mode
  o handle overflows in radix_tree_gang_lookup()
  o Add a sync_fs super_block operation
  o implement ext3_sync_fs
  o copy_user checks in filldir()
  o vm accounting fixes and addition
  o hugetlb fixes
  o fs-writeback rework
  o Add /proc/sys/vm/lower_zone_protection
  o Set a minimum hash table size for wait_on_page()
  o Reserve an additional transaction block in
  o remove PF_SYNC
  o Don't inherit mm->def_flags across forks
  o bootmem allocator merging fix
  o ext2/ext3_free_blocks() extra check
  o don't apply file size rlimits to blockdevs
  o limit pinned memory due to readahead
  o remove a vm debug check
  o madvise_willneed() maximum readahead checking
  o provide a default super_block_operations
  o tidier atomic check in mempool_alloc()
  o Fix off-by-one in the page allocator
  o pad pte_chains out to a cacheline
  o ext2 synchronous mount fix
  o Add prefetching to get_page_state()
  o ext3: fix error-path bh leak
  o remove vm_area_struct.vm_raend

Andy Grover <agrover@groveronline.com>:
  o ACPI: Get rid of progress dots if not in debug mode
  o ACPI: update to 20021212
  o ACPI: Fix write-related /proc entry functionality

Anton Blanchard <anton@samba.org>:
  o 2.5 fix for > 25 disks

Art Haas <ahaas@airmail.net>:
  o C99 initializers

Ben Collins <bcollins@debian.org>:
  o IEEE-1394/Firewire update

Brian Gerst <bgerst@didntduck.org>:
  o Remove Rules.make from Makefiles

Christoph Hellwig <hch@sgi.com>:
  o [XFS] final sendfile bits
  o [XFS] fix small typo in rtdev mount code
  o [XFS] don't include root_dev.h
  o [XFS] remove linvfs_put_inode
  o [XFS] rationalize pagebuf_iomove
  o [XFS] add a new xfs_mount parameter to xfs_blkdev_get
  o [XFS] get rid of pb_daemon/pagebuf_daemon_t
  o [XFS] merge page_buf_private_t into page_buf_t
  o [XFS] remove some dead code from pagebuf
  o share some code between get_sb_bdev and xfs log/rtdev handling
  o CREDITS update

Dave Kleikamp <shaggy@shaggy.austin.ibm.com>:
  o JFS: Fix off-by one error when symlink size == 256 bytes
  o Add more statistics to /prod/fs/jfs/ to help performance tuning
  o JFS: Move index table out of directory inode's address space
  o JFS: Avoid writing partial log pages for lazy transactions
  o jfs_truncate needs to call block_truncate_page
  o JFS: Fix accounting of active allocation groups
  o JFS: Remove COMMIT_Holdlock

Davide Libenzi <davidel@xmailserver.org>:
  o epoll bits forgot a nasty printk()

Dominik Brodowski <linux@brodo.de>:
  o cpufreq: clean up CPU information
  o cpufreq: move x86 configuration to "Power Management"

Greg Kroah-Hartman <greg@kroah.com>:
  o USB: Added usb-serial driver core bus support
  o Driver core: Fix class leak in class_hotplug
  o USB: Moved usb-serial bus specific code to a separate file
  o usbaudio.c: fix for urb callback function change
  o USB: Fix compile errors with usb-skeleton driver
  o USB: usb-skeleton: removed static array of devices

Greg Ungerer <gerg@snapgear.com>:
  o m68knommu fix kstat_cpu usage int ints.c
  o m68knommu add missing do_fork arg
  o m68knommu spinlocks around signal api calls
  o m68knommu remove sys_security
  o m68knommu fix ELF_CORE_COPY_REGS macro
  o m68knommu current include thread_info.h
  o m68knommu hardirq.h include cache.h
  o m68knommu definition of TASK_UNMAPPED_BASE
  o m68knommu support restart_block

Ingo Molnar <mingo@elte.hu>:
  o threaded coredumps, tcore-fixes-2.5.51-A0
  o ptrace-sigfix-2.5.51-A1

Jeff Garzik <jgarzik@redhat.com>:
  o [NET] support IPv6 over token ring (from lkml)
  o [netdrvr tg3] a fix, a cleanup, and an optimization

Kai Makisara <kai.makisara@kolumbus.fi>:
  o SCSI tape driver fixes for 2.5.51

Linus Torvalds <torvalds@home.transmeta.com>:
  o Fix nanosleep() behaviour with NULL "remaining" argument
  o Move intermezzo header files to its own private directory
  o Remove bogus checkin file from xfs

Marcel Holtmann <marcel@holtmann.org>:
  o Disable bluetty.o if Bluetooth subsystem is used

Martin Schwidefsky <schwidefsky@de.ibm.com>:
  o s390: Makefiles
  o s390: nanosleep restarting
  o s390: io fixes
  o s390: uaccess bug
  o s390: old tape file
  o s390: staticification
  o s390: warnings
  o s390: export sys_wait4

Matthew Dobson <colpatch@us.ibm.com>:
  o NUMA topology sysfs panic fix

Matthew Wilcox <willy@debian.org>:
  o Remove test/set_bit from dl2k

Oleg Drokin <green@angband.namesys.com>:
  o reiserfs: Take into account file information even when not doing
    preallocation. Fixes a bug with displacing_large_files option
  o reiserfs: Fix a problem with delayed unlinks and remounting RW
    filesystem RW
  o reiserfs: lock_kernel is replaced with its reiserfs variant
  o reiserfs: C99 designated initializers, by Art Haas
  o reiserfs: Fixed annoying warnings in fs/reiserfs/procfs.c

Pavel Machek <pavel@ucw.cz>:
  o ACPI/S3: fix gcc3.2 compatibility
  o ACPI/S3: simplify assembly code a bit

Pete Zaitcev <zaitcev@redhat.com>:
  o Patch for debounce in 2.5

Petko Manolov <petkan@users.sourceforge.net>:
  o USB: pegasus kmalloc/kfree stuff

Randy Dunlap <rddunlap@osdl.org>:
  o move console_loglevel scalars to array (resend)

Richard Henderson <rth@are.twiddle.net>:
  o Revert bogus include workaround

Richard Henderson <rth@twiddle.net>:
  o sr_ioctl fix

Robert Love <rml@tech9.net>:
  o remove error message on illegal ioctl
  o printks in drivers/scsi/hosts.c missing return

Roman Zippel <zippel@linux-m68k.org>:
  o kconfig: qt installation workaround
  o kconfig: off-by-one error
  o kconfig: config file parse update
  o kconfig: dependencies for choices
  o kconfig: symbol change notification
  o kconfig: geometry defaults
  o kconfig: updates
  o kconfig: fix T_STRING usage

Rusty Russell <rusty@rustcorp.com.au>:
  o Revert depmod and hierarchy changes
  o Module init reentry fix
  o Module Parameter Core Patch
  o Parameter implementation for modules
  o MODULE_PARM support for older modules

Stephen Rothwell <sfr@canb.auug.org.au>:
  o nanosleep compatibility layer fix
  o consolidate sys32_times - architecture independent
  o mips64 compatibility syscall layer
  o consolidate sys32_new[lf]stat - architecture independent

Trond Myklebust <trond.myklebust@fys.uio.no>:
  o Fix buffer reservations in nfs4xdr.c
  o NFSv4 cleanups
  o Add helper routines for fixing up page alignment on xdr_buf

Zwane Mwaikambo <zwane@holomorphy.com>:
  o OSS ad1848 initialisation order

Re: Linux v2.5.52

[ALESSANDRO.SUARDI]

Linus Torvalds wrote:

> Various things here. Most noticeably more merges with Andrew, with a 
> lot of various small fixes.

Using it, with the addition of Valdis' fix for the Xircom Cardbus PCI
 allocation problem. So far so good, except for IrDA irport that is
 colliding with the serial driver as Jean told me. Not sure why the
 irport-serial problem doesn't bite me in 2.4.x nor did it bite in
 earlier 2.5.x though.

--alessandro

Re: Linux v2.5.52

[Christoph Hellwig]

On Sun, Dec 15, 2002 at 07:34:09PM -0800, Linus Torvalds wrote:
> Ben Collins <bcollins@debian.org>:
>   o IEEE-1394/Firewire update

This merge looks fishy.  It seems to be yet another let's throw my CVS
repo in merge and backs out Al's work yo get rid of lots of devfs crap.

It also contains strange changes like:

-	ch = kmalloc(sizeof *ch, SLAB_KERNEL);
+	ch = kmalloc(sizeof *ch, in_interrupt() ? SLAB_ATOMIC : SLAB_KERNEL);

that really want proper fixing.

Re: Linux v2.5.52

[James H. Cloos Jr.]

>>>>> "CH" == Christoph Hellwig <hch@infradead.org> writes:

Linus> Ben Collins <bcollins@debian.org>: o IEEE-1394/Firewire update

CH> This merge looks fishy.  It seems to be yet another let's throw my CVS
CH> repo in merge and backs out Al's work yo get rid of lots of devfs crap.

FWIW (which may be little) the ieee1394 code in 2.5.51 simply does not
work and the svn tree (same code as in 2.5.52) does.  For those of us
who depend on sbp2 for day-to-day functionality it makes current 2.5
possible....

That said, less divergence between Linus' bk tree and linux1394.org's
svn tree would be welcome.

-JimC

Re: Linux v2.5.52

[Gerd Knorr]

Linus Torvalds <torvalds@transmeta.com> writes:

> XFS, JFS, ACPI and USB updates. KConfig update, and Rusty's module
> parameter implementation. And fix the stupid nanosleep() thing that broke 
> some programs.

Something broke the init= kernel cmd line option, I suspect Rusty's
parameter stuff ...

I boot my box via initrd + pivot_root, with "ramdisk_size=16384
root=/dev/ram0 init=/linuxrc rw" on the kernel command line.  When
booting 2.5.52 I get a shell prompt at the point where usually linxrc
starts.  Just typing "exec /linuxrc" at this point invokes the usual
boot sequence ...

  Gerd

-- 
Weil die späten Diskussionen nicht mal mehr den Rotwein lohnen.
				-- Wacholder in "Melanie"

Re: Linux v2.5.52

[Ben Collins]

On Mon, Dec 16, 2002 at 10:26:40AM +0000, Christoph Hellwig wrote:
> On Sun, Dec 15, 2002 at 07:34:09PM -0800, Linus Torvalds wrote:
> > Ben Collins <bcollins@debian.org>:
> >   o IEEE-1394/Firewire update
> 
> This merge looks fishy.  It seems to be yet another let's throw my CVS
> repo in merge and backs out Al's work yo get rid of lots of devfs crap.

Quit talking shit. I go through a lot of effort to merge in changes sent
to Linus' tree into the Linux1394 repo. I don't just dump changes for no
good reason.

How about pointing out some specifics? Maybe make my job easier by
getting me some patches directly. Trying to track two seperate source
tree's isn't as easy as you might think.


-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: Linux v2.5.52

[Christoph Hellwig]

On Mon, Dec 16, 2002 at 10:16:39AM -0500, Ben Collins wrote:
> > This merge looks fishy.  It seems to be yet another let's throw my CVS
> > repo in merge and backs out Al's work yo get rid of lots of devfs crap.
> 
> Quit talking shit. I go through a lot of effort to merge in changes sent
> to Linus' tree into the Linux1394 repo. I don't just dump changes for no
> good reason.
> 
> How about pointing out some specifics?

Take a look at the changeset at
http://linus.bkbits.net:8080/linux-2.5/diffs/drivers/ieee1394/dv1394.c@1.15?nav=index.html|src/|src/drivers|src/drivers/ieee1394|hist/drivers/ieee1394/dv1394.c.

Your big BLOB merge basically undoes everything in there.

> Maybe make my job easier by getting me some patches directly.

It was Al's patch, not mine.

> Trying to track two seperate source tree's isn't as easy as you might think.

In fact it's not difficult at all with a proper SCM, a bit of care and the
right attitude.  I merge the changes from XFS (and about half a donzend
XFS-related repositories inside SGI that all need proper merging / keeping
in sync) to Linus all the time.  And by keeping the changesets (or atomic
commits in SVN terminlogoy) as one patch each, hand-editing as needed when
merge conflicts arrive that works very well, even if I had been away and
the changes for four weeks need merging or as now we're five patchlevels
away from Linus tree (at 2.5.47).  I've not lost a single upstream change
with that merge policy yet.

And no, that's no BK advertisment, SGI uses a RCS-based SCM internally and
I use unfied diffs to get it into a staging repository for Linus to pull.

Re: Linux v2.5.52

[Ben Collins]

> > Trying to track two seperate source tree's isn't as easy as you might think.
> 
> In fact it's not difficult at all with a proper SCM, a bit of care and the
> right attitude.  I merge the changes from XFS (and about half a donzend
> XFS-related repositories inside SGI that all need proper merging / keeping
> in sync) to Linus all the time.  And by keeping the changesets (or atomic
> commits in SVN terminlogoy) as one patch each, hand-editing as needed when
> merge conflicts arrive that works very well, even if I had been away and
> the changes for four weeks need merging or as now we're five patchlevels
> away from Linus tree (at 2.5.47).  I've not lost a single upstream change
> with that merge policy yet.
> 
> And no, that's no BK advertisment, SGI uses a RCS-based SCM internally and
> I use unfied diffs to get it into a staging repository for Linus to pull.

When someone pays me to work fulltime on Linux1394, I'll give it that
much time. Until then I have to make due with what time I have. If I
miss things because people would rather send patches to Linus than me,
it isn't my fault, but I'll do my best to fix it up.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: Linux v2.5.52

[Linus Torvalds]

On Mon, 16 Dec 2002, Ben Collins wrote:
>
> How about pointing out some specifics? Maybe make my job easier by
> getting me some patches directly. Trying to track two seperate source
> tree's isn't as easy as you might think.

It's a lot easier if you track them _often_ instead of just occasionally.
That's the main problem I have with other peoples CVS trees - CVS has very
little support for tracking any outside sources, and that coupled with the
fact that people don't track it in a timely manner always generates
problems.

With CVS, a simple script like

 (a) get current version
 (b) diff against the last version you did the merge against
 (c) apply the diff to your new tree
 (d) _then_ do the diff against the current version
 (e) delete "last version merged", make current version that.

will work pretty easily most of the time for subsystems that don't get a
lot of input from outside the "maintainer". Especially if you do it
reasonably often (you can do the back-merge even when you're _not_ ready
to actually send me your stuff), the diff from my tree is often quite
small and thus easily mergible.

If you think that "maintainer" means that nobody else can touch the tree
and that you thus don't need to care, you're WRONG.

Alternatively, never EVER make a patch against the "current kernel
version". Only make a patch against the _last_ kernel that you merged
with, and if I cannot apply it I will tell you so. Making a patch just
between your tree and mine will _always_ end up losing fixes.

			Linus

Re: Linux v2.5.52

[Ben Collins]

> If you think that "maintainer" means that nobody else can touch the tree
> and that you thus don't need to care, you're WRONG.

I never said that. What I said was that because I can't spend lots of
time tracking changes, _sometimes_ I miss them. You will see in the SVN
repo logs a lot of places where I merge in changes from your tree. It's
a fact that people make mistakes. I've already rectified this one by
adding in the patch to the linux1394 repo.

I wasn't pushing off blame, just noting that it's not possible to never
make mistakes. You make them too.


-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: Linux v2.5.52

[Larry McVoy]

> Alternatively, never EVER make a patch against the "current kernel
> version". Only make a patch against the _last_ kernel that you merged
> with, and if I cannot apply it I will tell you so. Making a patch just
> between your tree and mine will _always_ end up losing fixes.

I think this is a good approach.  If people sent Linus patches with some
indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
header of the patch,  I'd be willing to go make bk import -temail do 
the right thing, which would probably be to try and patch it in in the
working tree, but if that didn't work, it would do

	bk clone -l -r$BASELINE tree tree.$BASELINE
	cd tree.$BASLINE
	bk import -temail ....
	cd ../tree
	bk pull ../tree.$BASELINE  && rm -rf ../tree.$BASELINE

and you'd get BK to merge most of the work.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Linux v2.5.52

[Linus Torvalds]

On Mon, 16 Dec 2002, Larry McVoy wrote:
>
> > Alternatively, never EVER make a patch against the "current kernel
> > version". Only make a patch against the _last_ kernel that you merged
> > with, and if I cannot apply it I will tell you so. Making a patch just
> > between your tree and mine will _always_ end up losing fixes.
> 
> I think this is a good approach.  If people sent Linus patches with some
> indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
> header of the patch,

The problem here is that I often cannot do a sane merge. 

I have no problem at all merging stuff that is a week old or so (major 
clashes happen sometimes, and I ask for help, but it's rare). However, if 
somebody really uses a major external CVS tree and does big patches, 
eventually the likelihood of a problem grows big enough that the patch 
sender might as well merge _first_ anyway, since otherwise I'll just ask 
for his help.

HOWEVER, even if I end up having to ask for help, this is probably 
preferable to the "just install my tree" approach, since at least we don't 
lose bugfixes and other updates silently.

		Linus