- ax25_cb's use refcounting
- the ax25_cb list uses hlists
- Lots of socket locking.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

static unconditionally, to allow multiple built-in modules.

From: Suparna Bhattacharya <suparna@in.ibm.com>

The /proc code's bare atomic_inc(&mm->count) is racy against __exit_mm()'s
mmput() on another CPU: it calls mmput() outside task_lock(tsk), and
task_lock() isn't appropriate locking anyway.

So what happens is:

	CPU0			          CPU1

      mmput()
      ->atomic_dec_and_lock(mm->mm_users)
                                          atomic_inc(mm->mm_users)
      ->list_del(mm->mmlist)
                                          mmput()
                                          ->atomic_dec_and_lock(mm->mm_users)
                                          ->list_del(mm->mmlist)

And the double list_del() of course goes splat.

So we use mmlist_lock to synchronise these steps.

The patch implements a new mmgrab() routine which increments mm_users only if
the mm isn't already going away.  Changes get_task_mm() and proc_pid_stat()
to call mmgrab() instead of a direct atomic_inc(&mm->mm_users).

Hugh, there's some cruft in swapoff which looks like it should be using
mmgrab()...

From: Dave Hansen <haveblue@us.ibm.com>

Hmmm.  This is looking like fallout from the massive wli-bomb.  Here's
the loop that controls the cpu booting, before and after cpumask_t:

-	for (bit = 0; kicked < NR_CPUS && bit < BITS_PER_LONG; bit++)
+	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++)
		apicid = cpu_present_to_apicid(bit);

"kicked" only gets incremented for CPUs that were successfully booted,
so it doesn't help terminate the loop much.  MAX_APICS is 256 on summit,
which is *MUCH* bigger than BITS_PER_LONG.
cpu_2_logical_apicid[NR_CPUS] which is referenced from
cpu_present_to_apicid() is getting referenced up to MAX_APICs, which is
bigger than NR_CPUS.  Overflow.  Bang.  garbage != BAD_APICID :)

From: Emilio Gallego Arias <egallego@telefonica.net>

Apparently a couple of files now need io_apic.h.

apm.c (at least) needs these.

From: chrisl@vmware.com

Fixes the "perl installer weirdness" problem which a few people have been
reporting.

The bug is triggered by creating the index.  Coping out the index we assume
the dirents start with the first entry after "." "..".

It can make the first previous deleted entry reappear.  In the past we set
inode to zero for an empty entry so this is not a problem.  That is not
true any more.

Also, there were a few places where we were altering inode times after
running ext3_mark_inode_dirty().  We should be doing that beforehand.

dmi_dump_system() is only used if CONFIG_ACPI_BOOT.

From: Matthew Wilcox <willy@debian.org>

Here's an update to Documentation/filesystems/Locking.

A `cat /dev/kmem' oopses the kernel.  This is because new Intel
copy_to_user() doesn't handle segfaults against the kernel-side source
address of the copy.

It is not obvious how to fix read_kmem(), and handling faults on either
source or dest is traditional behaviour, so fix it in the copy function by
adding exception table entries for the reads as well as the writes.

From: Francois Romieu <romieu@fr.zoreil.com>

Recent MOD_{INC/DEC}_USE_COUNT removal missed a MOD_DEC_USE_COUNT.

From: Francois Romieu <romieu@fr.zoreil.com>

- silly indentation;
- let's be more user-friendly with manufacturer specific (mis)feature:
  + s/CONFIG_DSCC4_CLOCK_ON_TWO_PORTS_ONLY/CONFIG_DSCC4_PCISYNC/
  + KConfig adequate entry
- broken warning message.

From: Francois Romieu <romieu@fr.zoreil.com>

CCR1 register voodoo: asic handles itself the flow control.

From: Francois Romieu <romieu@fr.zoreil.com>

Workaround for lack of true reset:
- devices/ports are put in silent mode at ifconfig down time but some
  state is kept around to allow 'ifconfig up' issuing at a later time.
  Device specific structures are allocated when the pci asic is
  probed: dscc4_init_ring() moves from dscc4_open() to dscc4_found1().
- try to use reset related board-specific feature at module removal
  time if available. Comments in the code explain the whole story.
  Not a complicated feature but it is unavailable on the cards I own
  and no user gave me feedback -> currently untested.
  It shouldn't harm anyway.

From: Francois Romieu <romieu@fr.zoreil.com>

- more #define for specific bits;
- more scc_patchl use;
- just say no to bozo programming:
  + SCC core _really_ disabled at startup;
  + Interrupts Mask Register setup and SCC core activation are
    done as late as possible (i.e. in dscc4_open());
  + they are reverted if dscc4_open() fails;
  + as well as unconditionnaly in dscc4_close();
- more or less paranoid quirk in Xpr handler.

From: Francois Romieu <romieu@fr.zoreil.com>

More conditional debug messages.

From: Francois Romieu <romieu@fr.zoreil.com>

Clock modes on dscc4 are feature-rich enough to deserve some explanation.

From: Francois Romieu <romieu@fr.zoreil.com>

Short comments so I can figure why things are done this way.

opl3sa2 forgot to initialise the spinlock.

From: NeilBrown <neilb@cse.unsw.edu.au>

The blockdev layer has a concept of 'claiming' a device, so for example it
can be claimed when a filesystem is mounted or when it is included into a
raid array.  Only one subsystem can claim it at a time.

This patch matches this functionality available to user-space via the
O_EXCL flag to open.

This allows user-space programs to easily test if a device is currently
mounted etc, and to prevent a device from being mounted or otherwise
claimed.

From: NeilBrown <neilb@cse.unsw.edu.au>

Current devices can be 'claimed' by filesystems (when mounting) or
md/raid (when being included in an array) or 'raw' or ....
This stop concurrent access by these systems.

However it is still possible for one system to claim the whole device
and a second system to claim one partition, which is not good.

With this patch, when a partition is claimed, the whole device is 
claimed for partitioning.  So you cannot have a partition and the
whole devices claimed at the same time (except if the whole device
is claimed for partitioning).

In a further attempt to prevent dirty pages from being written out from the
LRU, don't write them if they were referenced.  This gives those pages
another trip around the inactive list.  So more of them are written via
balance_dirty_pages().

It speeds up an untar-of-five-kernel trees by 5% on a 256M box, presumably
because balance_dirty_pages() has better IO patterns.

It largely fixes the problem which Gerrit talked about at the kernel summit:
the individual writepage()s of dirty pages coming off the tail of the LRU are
reduced by 83% in their database workload.

I'm a bit worried that it increases scanning and OOM possibilities under
nutty VM stress cases, but nothing untoward has been noted during its four
weeks in -mm, so...

This just reorganizes some ghastly goto-and-retry-spaghetti in the core of
the ext3 block allocator.

I wrote this ages ago in preparation for fixing the find_next_usable_block()
CPU pigginess problem, but that proved to be quite nontrivial.

The patch has been in -mm for a long time and Martin has recently confirmed
that it introduces no performance regression in SDET and kernbench.

- nmi_watchdog documentation typo ("Randy.Dunlap" <rddunlap@osdl.org>)

- ikconfig proc requires CONFIG_PROC_FS ("Randy.Dunlap" <rddunlap@osdl.org>)

- visws build fix (Andrey Panin <pazke@donpac.ru>)

- VM lock ranking comment update

This one snuck in...

 - debugging message for ACPI

 - Intel guys removed it from their 2.4 tree (at my request)

 - it's point-in-time specific (message becomes nearly useless after
   ACPI bug fixes)

 - b/c of the point-in-time issue, it's IMO much more appropriate for a
   vendor kernel (where the message, I agree, may be helpful)

 - can potentially mislead users to the correct cause of root mount failure

 - overall, I disagree with adding messages like this.  The number one
   bug report, by far, for networking drivers is ACPI-related (no
   interrupts delivered).  You don't see me adding "boot with acpi=off"
   messages to the net subsystem.

it was the same as the old request_region(). Not so.