From: Christoph Hellwig <hch@lst.de>

the maintainer doesn't response unfortauntely, but removing these from
net_devices unconditionally is the 2.6 way to go, there's no more module
refcounting on net devices.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

sound/oss/wavfront.c: At top level:
sound/oss/wavfront.c:2498: warning: `errno' defined but not used

From: Christoph Hellwig <hch@lst.de>

Kill magic ide/sound makedev scripts in scripts/.  The userland MAKEDEV is
the proper place and already has support for them.

From: Martin Schwidefsky <schwidefsky@de.ibm.com>

Just found an small bug in pgalloc for s390*.  Comparing notes with other
architectures I found that pte_alloc_one is sick for alpha and sparc64 as
well.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch fixes the type of the ssec pointer in the sk_free_security
function.  This has no current impact as the magic element is the top of each
structure.  Thanks to Chad Hanson of TCS for discovering the bug and
submitting the patch.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

drivers/media/dvb/frontends/stv0299.c:356: warning: unused variable `i'

From: "Nguyen, Tom L" <tom.l.nguyen@intel.com>

Adds MSI support for ia64.

- Modified existing code in drivers/pci/msi.c and drivers/pci/msi.h to
  include MSI support on IA64 platform.

- Based on the comments received from Zwane Mwaikambo and David Mosberger,
  this patch consolidates the vector allocators as
  assign_irq_vector(AUTO_ASSIGN) has the same semantics as
  ia64_alloc_vector() by converting the existing uses of ia64_alloc_vector()
  to assign_irq_vector(AUTO_ASSIGN).

- Based on the comments received from Zwane Mwaikambo, this patch
  consolidates the semantics of vector allocator assign_irq_vector() in
  drivers/pci/msi.c into the relevant architecture's vector allocator
  assign_irq_vector() in arch/i386/kernel/io_apic.c.

- Regarding vector allocation, this patch modifies the existing function
  assign_irq_vector() to maximize the number of allocated vectors to 188
  before going -ENOSPC.

- Based on your comments, this patch creates <asm-i386/msi.h>,
  <asm-ia64/msi.h> and <asm-x86_64/msi.h>, includes <asm/msi.h> from within
  drivers/pci/msi.h and then places all the code which is currently under
  ifdef in msi.h into the relevant architecture's <asm/msi.h> file.

- Based on your comments, this patch places pci_vector_resources() in
  existing drivers/pci/msi.c in the relevant architecture implementations
  such as into arch/.../pci/irq.c.

From: James Cleverdon <jamesclv@us.ibm.com>

Bump up MAX_MP_BUSSES for summit/generic subarch to cope with big IBM x440
systems.

From: James Cleverdon <jamesclv@us.ibm.com>

Break out the definition of NR_IRQ_VECTORS, etc from irq_vectors.h into
irq_vectors_limits.h, so we can change it per subarch without having code
duplication for the rest of the file.  Stick the same values back for
mach-default, and override them for mach-summit/generic which needs bigger
limits.

From: Rusty Russell <rusty@rustcorp.com.au>

Agustin Martin <agmartin@debian.org> pointed out that this doesn't work:

	options ide-mod options="ide=nodma hdc=cdrom"

The quotes are understood by kernel/params.c (ie.  it skips over spaces
inside them), but are not stripped before handing to the underlying
function.  They should be.

From: Hugh Dickins <hugh@veritas.com>

Kevin P.  Fleming pointed out that the 2.6 tmpfs does not allow writing huge
sparse files.  This is an unintended side-effect of the strict memory commit
changes: which should make no difference.

The solution is to treat the tmpfs files (of variable size) and the shmem
objects (of fixed size) differently: sounds nasty but works out well.  The
shmem objects follow the VM preallocation convention as before, but the tmpfs
files revert to allocation on demand as a filesystem would.  If there's not
enough memory to write to a tmpfs hole, it is reported as -ENOSPC rather than
-ENOMEM, so the mmap writer gets SIGBUS rather than everyone else getting
OOM-killed.

From: William Lee Irwin III <wli@holomorphy.com>

Chang bitmap_shift_left()/bitmap_shift_right() to have O(1) stackspace
requirements.

Given zeroed tail preconditions these implementations satisfy zeroed tail
postconditions, which makes them compatible with whatever changes from Paul
Jackson one may want to merge in the future.  No particular effort was
required to ensure this.

A small (but hopefully forgiveable) cleanup is a spelling correction:
s/bitmap_shift_write/bitmap_shift_right/ in one of the kerneldoc comments.

The primary effect of the patch is to remove the MAX_BITMAP_BITS
limitation, so restoring the NR_CPUS to be limited only by stackspace and
slab allocator maximums.  They also look vaguely more efficient than the
current code, though as this was not done for performance reasons, no
performance testing was done.

From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

From: Alain Knaff <alain.knaff@lll.lu>

This patch adds support for floppy disks whose sectors are numbered
starting at 0 rather than 1 as usual disks would be.  This format is used
for some CP/M disks, and also for certain music samplers (such as Ensoniq
Ensoniq EPS 16plus).

In order to use it, you need an fdutils with the current patch from
http://fdutils.linux.lu as well, and then do setfdrpm /dev/fd0 dd zerobased
sect=10 or setfdprm /dev/fd0 hd zerobased sect.

In addtion, the patch also fixes my email addresses.  I no longer use
pobox.com.

From: Rusty Russell <rusty@rustcorp.com.au>

Brian Gerst's patch which moved __this_module out from module.h into the
module post-processing had a side effect.  genksyms didn't see the
undefined symbols for modules without a module_init (or module_exit), and
hence didn't generate a version for them, causing the kernel to be tainted.

The simple solution is to always include the versions for these functions. 
Also includes two cleanups:

1) alloc_symbol is easier to use if it populates ->next for us.

2) add_exported_symbol should set owner to module, not head of module
   list (we don't use this field in entries in that list, fortunately).

From: Brian Gerst <bgerst@didntduck.org>

Move the __this_module structure to the modpost code where it really
belongs.

Eric Dumazet <dada1@cosmosbay.com>

We can avoid evaluating `current' in a few places.

From: Heiko Ronsdorf <hero@persua.de>

- Remvoe a volatile which causes a warning via module_param()

- Remove an unused variable.

From: David Mosberger <davidm@napali.hpl.hp.com>

Somebody recently pointed out a performance-anomaly to me where an unusual
amount of time was being spent reading from /dev/urandom.  The problem
isn't really surprising as it happened only on >= 4-way machines and the
random driver isn't terribly scalable the way it is written today.  If
scalability _really_ mattered, I suppose per-CPU data structures would be
the way to go.  However, I found that at least for 4-way machines,
performance can be improved considerably with the attached patch.  In
particular, I saw the following performance on a 4-way ia64 machine:

Test: 3 tasks running "dd if=/dev/urandom of=/dev/null bs=1024":

			throughput:
			

From: Mike Waychison <Michael.Waychison@Sun.COM>

Export complete_all for module use.

From: Arjan van de Ven <arjanv@redhat.com>

The patch below adds a few missing put_user()'s to the i810/i830 drm
modules.  Users reported oopses with 4g/4g split in action, and sparse
annotations indeed found the offender in the function in question.  I've
kept the sparse __user annotations since those are generally useful anyway.
 I can't test it myself but a few people reported that the oopses went away
so far.

From: Trivial Patch Monkey <trivial@rustcorp.com.au>

From:  Thomas Molina <tmolina@cablespeed.com>

From: Rusty Russell <rusty@rustcorp.com.au>

These macros are redefined here.  Previously definitions are in
asm-ppc(64)/io.h

From: Rusty Russell <rusty@rustcorp.com.au>

From: maximilian attems <janitor@sternwelten.at>

Add the Monkey to SubmittingPatches.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  colpatch@us.ibm.com

The cpu_2_node[] array for i386 is initialized to all 0's, meaning that
until modified at CPU bring-up, all CPUs are mapped to node 0.

When CPUs are brought online, they are mapped to the appropriate node by
various mechanisms, depending on the underlying hardware.

When we unmap CPUs (hotplug time), we should return the mapping for the CPU
that is going away to its original state, ie: 0.

When this code was initially submitted, the misguided poster (me) made the
mistake of putting a -1 in the cpu_2_node[] array for the CPU going away.

This patch fixes this mistake, and allows code to get a valid node number
for all valid CPU numbers.  This is important, because most (if not all)
callers do not error check the value returned by the cpu_to_node() macro,
and they should not have to.  The API specifies that a valid node number be
returned for any valid CPU number.

From: Rusty Russell <rusty@rustcorp.com.au>

include/linux/device.h includes include/linux/ioport.h twice.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Thomas Molina <tmolina@cablespeed.com>

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Stewart Smith <stewart@linux.org.au>

A better explanation of the X86_GENERIC config option follows.

From: Rusty Russell <rusty@rustcorp.com.au>

From: Andreas Schwab <schwab@suse.de> I'm getting a warning when building
for ia64 with MODVERSIONS enabled.  This is a bug in genksyms, it can't
cope with some arguments of __typeof__.

The following patch will fix that.  Actually the argument of __typeof__ is
an abstract declarator, but the genksyms parser has no production for that;
decl_specifier_seq also matches some invalid constructs, but I don't think
this is a problem in practice, since the compiler will reject them.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Petri Koistinen <petri.koistinen@iki.fi>

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Pavel Machek <pavel@ucw.cz>

sysfs should be mounted on /sys these days.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Josef 'Jeff' Sipek <jeffpc@optonline.net>

I just noticed the nested ifdefs, and made it little more readable.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  John Levon <levon@movementarian.org>

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Hans Ulrich Niedermann <linux-kernel@n-dimensional.de>

doc patch: close tag with ">"

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Hans Ulrich Niedermann <linux-kernel@n-dimensional.de>

doc patch: Consistently use quotes for SGML attributes This makes it
possible to process the SGML files without SHORTTAG YES.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Ed L Cashin <ecashin@uga.edu>

This small patch documents that bits 9, 10, and 11 are unused by the Linux
kernel.  The IA-32 Intel Architecture Software Developer's Manual says that
these bits are available for programmer use.

From: Trivial Patch Monkey <trivial@rustcorp.com.au>

From:  Ben Greear <greearb@candelatech.com>

Depending on one's default emacs settings, the suggestion in the
CodingStyle may or may not work.  This patch adds a few more commands to
ensure it works in more cases.

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Adrian Bunk <bunk@fs.tum.de>

Some versions of ps print non-version lines when ps --version is invoked.
grep them out.

From: Joe Korty <joe.korty@ccur.com>

This patch replaces the call to bitmap_shift_right() in bitmap_parse() with
bitmap_shift_left().

I also prepended comments to the bitmap_shift_* functions defining what
'left' and 'right' means.  This is under the theory that if I and all the
reviewers were bamboozled, others in the future occasionally might be too.

From: "La Monte H.P. Yarroll" <piggy@timesys.com>

This is a Scott Wood patch against 2.6.3.


Use gettimeofday() rather than xtime.tv_sec in sys_time(), since
sys_stime() uses settimeofday() and thus subtracts the subtick correction
from the new xtime.

stime() used settimeofday(), but time() did not use gettimeofday().  Since
settimeofday() subtracts out the current intra-tick correction, and nsec
was 0 (since stime() only allows seconds), this resulted in xtime being
slightly earlier than the time that was set.

If time() had used gettimeofday(), the correction would have been applied,
and everything would be fine.  However, instead time just reads the current
xtime.tv_sec, so if time() is called immediately after stime(), you'll
usually get a value one second earlier.

From: Chuck Lever <cel@citi.umich.edu>

O_DIRECT|O_APPEND cannot possibly work on NFS, so NFS needs some way of
preventing the user from setting this combination.  We felt that the best
way of implementing this restriction is to allow the filesytem to implement
its own fcntl() handler.

This patch does, that, and provide the appropriate handler for NFS.

Additional details from Chuck:

Forgetting O_DIRECT for a moment, O_APPEND writes on NFS don't work in any
case when multiple clients are writing to a file, since an NFS client can
never guarantee it knows where the true end of file is 100% of the time.
it works as expected iff only one client writes to an O_APPEND file at a
time.

Multi-client O_APPEND writing doesn't seem to be a problem for any
application I'm aware of.  Since it can be made to behave in the
multi-client case with careful application logic or by using file locking,
I don't think we should disallow it.

I want to drop the inode semaphore when doing NFS direct I/O because it is
synchronous; holding the i_sem means we reduce direct I/O concurrency to
one I/O per file at a time.  the important thing sct was worried about was
the case where a single client is writing with O_APPEND and O_DIRECT, and
we don't hold the i_sem during the write.

We must at least hold the i_sem when determining where the end of file is
to do the O_APPEND write.  In 2.6, I believe that is handled correctly in
the VFS layer, so this is not an issue for 2.6, right?