Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Suzanne Wood]

Thank you very much.

  > From dipankar@in.ibm.com  Mon Mar  6 07:36:50 2006

  > On Sun, Mar 05, 2006 at 08:44:15PM -0800, Suzanne Wood wrote:
  > > > From: Adrian Bunk Fri Mar 03 2006 - 18:40:57 EST 
  > > >
  > > Do kernel coders value the marking of the rcu read-side critical 
  > > section for consistency?  In fs/file_table.c, fcheck_files() 

  > Generally speaking, yes.

  > > is called by fget_light() without rcu_read_lock() in one case, 
  > > but with the apparently necessary rcu_read_lock() in place 
  > > otherwise.  The struct file pointer that fcheck_files() returns 
  > > is rcu_dereference(fdt->fd[fd]) or NULL. Does the _commented_guarantee 
  > > of the current task holding the refcnt assure there's no need to 
  > > check for NULL or to mark the rcu readside section around the first
  > > call to fcheck_files()?
  > > 
  > > This is the code sample:
  > > /*
  > >  * Lightweight file lookup - no refcnt increment if fd table isn't shared.
  > >  * You can use this only if it is guranteed that the current task already
  > >  * holds a refcnt to that file. That check has to be done at fget() only
  > >  * and a flag is returned to be passed to the corresponding fput_light().
  > >  * There must not be a cloning between an fget_light/fput_light pair.
  > >  */
  > > struct file fastcall *fget_light(unsigned int fd, int *fput_needed)
  > > {
  > > 	struct file *file;
  > > 	struct files_struct *files = current->files;
  > > 
  > > 	*fput_needed = 0;
  > > 	if (likely((atomic_read(&files->count) == 1))) {
  > > 		file = fcheck_files(files, fd);
  > > 	} else {

  > This means that the fd table is not shared between threads. So,
  > there can't be any race and no need to protect using
  > rcu_read_lock()/rcu_read_unlock().

Then why call fcheck_files() with the rcu_dereference() which would flag 
an automated check for the need to mark a read-side critical section?
Would it make sense to introduce the function that doesn't?  The goal of
keeping the kernel small is balanced with clarity.  The inconsistency of
how fcheck_files() is used within a single function (fget_light()) was
my opening question.

  > > The attached patch would superficially address the rcu 
  > > discrepancy, but another underlying question is about the 
  > > desired extent of the rcu read-side critical section in that 
  > > fget_light() returns the pointer to the file struct that was 
  > > flagged for rcu protection by rcu_dereference() in 
  > > fcheck_files().  In this application, does it make sense to 
  > > push the rcu_read_lock() into fcheck_files() or add it there
  > > or to extend it to the calling function?

  > I think a comment there explaining why rcu_read_lock/unlock
  > pair is not there should be sufficient. While the are NOP
  > for non-PREEMPT kernels, they do have a cost otherwise.
  > Avoiding them if we can is a good idea, IMO.

  > > Up the call tree, we note that fcheck() uses fcheck_files(), 
  > > but the only call to fcheck() nested in rcu_read_lock() is 
  > > in the disparaged irixioctl.c.
  > > 
  > > Are the other calls to fcheck() under circumstances that give 
  > > reason for the rcu_read_lock elision, like 
  > > spin_lock(&files->file_lock) in fs/fcntl.c, or being in the 
  > > context of applying locks in fs/locks.c, or calls from assembly 
  > > code in arch/sparc/kernel/sunos_ioctl.c & solaris/socksys.c.  
  > > If there is reason to pursue the insertion of the 
  > > rcu_read_lock/unlock() pairs in these circumstances, any 
  > > suggestions would be appreciated in order to dispel the question
  > > altogether or to try to submit a more extensive patch.

  > It depends on whether the fdtable is shared or not and if
  > shared whether we are already holding the ->files_lock or
  > not. The key is that if it is lock-free and if the fdtable
  > is shared, they rcu_read_lock()/unlock() pair must be
  > there, otherwise it is a bug.

  > Thanks
  > Dipankar

Many thanks again.
Suzanne

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Dipankar Sarma]

On Mon, Mar 06, 2006 at 08:13:41AM -0800, Suzanne Wood wrote:
> Thank you very much.
>   > > struct file fastcall *fget_light(unsigned int fd, int *fput_needed)
>   > > {
>   > > 	struct file *file;
>   > > 	struct files_struct *files = current->files;
>   > > 
>   > > 	*fput_needed = 0;
>   > > 	if (likely((atomic_read(&files->count) == 1))) {
>   > > 		file = fcheck_files(files, fd);
>   > > 	} else {
> 
>   > This means that the fd table is not shared between threads. So,
>   > there can't be any race and no need to protect using
>   > rcu_read_lock()/rcu_read_unlock().
> 
> Then why call fcheck_files() with the rcu_dereference() which would flag 
> an automated check for the need to mark a read-side critical section?
> Would it make sense to introduce the function that doesn't?  The goal of
> keeping the kernel small is balanced with clarity.  The inconsistency of
> how fcheck_files() is used within a single function (fget_light()) was
> my opening question.

Because rcu_dereference() hurts only alpha and we don't care about
alpha :-)

Just kidding!

Good point about automated checkers. However, this isn't an
uncommon thing in multi-threaded programs - can't the checker 
rules be written to take into account sharing and non-sharing of 
the object in question ?

Thanks
Dipankar

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Suzanne Wood]

Hello and thank you again.

 > From dipankar@in.ibm.com  Mon Mar  6 08:49:55 2006

 > On Mon, Mar 06, 2006 at 08:13:41AM -0800, Suzanne Wood wrote:
 > > Thank you very much.
 > >   > > struct file fastcall *fget_light(unsigned int fd, int *fput_needed)
 > >   > > {
 > >   > > 	struct file *file;
 > >   > > 	struct files_struct *files = current->files;
 > >   > > 
 > >   > > 	*fput_needed = 0;
 > >   > > 	if (likely((atomic_read(&files->count) == 1))) {
 > >   > > 		file = fcheck_files(files, fd);
 > >   > > 	} else {
 > > 
 > >   > This means that the fd table is not shared between threads. So,
 > >   > there can't be any race and no need to protect using
 > >   > rcu_read_lock()/rcu_read_unlock().
 > > 
 > > Then why call fcheck_files() with the rcu_dereference() which would flag 
 > > an automated check for the need to mark a read-side critical section?
 > > Would it make sense to introduce the function that doesn't?  The goal of
 > > keeping the kernel small is balanced with clarity.  The inconsistency of
 > > how fcheck_files() is used within a single function (fget_light()) was
 > > my opening question.

 > Because rcu_dereference() hurts only alpha and we don't care about
 > alpha :-)

 > Just kidding!

 > Good point about automated checkers. However, this isn't an
 > uncommon thing in multi-threaded programs - can't the checker 
 > rules be written to take into account sharing and non-sharing of 
 > the object in question ?

Henzinger, et al., UC Berkeley, describe race checking on a 
language for networked embedded systems NES-C using the atomic 
keyword to delimit sections.  (The rcu_read_lock() would be 
similar in disallowing interrupts.)  When flow-based analysis 
returned false positives, the programmer could annotate the 
code with "norace" and in practice all shared accesses were 
put in atomic sections even if there were no actual race 
conditions.  To limit the number of atomic sections, the 
UCB group modeled multiple threads, triggered hardware 
interrupts and interleaved tasks and checked for safe access
and did manual corrections to the unsafe code.

In fget_light(), the rcu_dereference() is apparently never 
intended in the "if true" of the conditional where 
(likely((atomic_read(&files->count) == 1), so only one file 
descriptor is open for the current task at that instant.  (A 
child process could share that descriptor, but an unrelated 
process would have its own file descriptor.)

But fget_light() does return the file pointer which _some_ of 
the time does require rcu-protection, so hypothetically, a 
checker flags it as unsafe if no rcu_read_lock() is in place 
in a caller at some level and checking can proceed to other 
locking.

The core premises have been that a path through the code 
that contains rcu_dereference() or rcu_assign_pointer() is 
matched to the assign/deref counterpart with the same struct 
object type and the rcu_dereference() is nested in a read-side 
critical section delimited by rcu_read_lock() and 
rcu_read_unlock() used to determine the extent of the duration 
of the struct at the address.

The pointer to the file struct that fcheck_files() returns is 
rcu_dereference(fdt->fd[fd]) and open.c has fd_install() call 
rcu_assign_pointer(fdt->fd[fd], file).  In file_table.c, 
file_free() calls call_rcu(&f->f_u.fu_rcuhead, file_free_rcu), 
where the fu_rcuhead is a field of the file struct and 
file_free_rcu() calls kmem_cache_free().

Thank you very much for your insights into the reasoning. 
Suzanne

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Suzanne Wood]

> From: Adrian Bunk Fri Mar 03 2006 - 18:40:57 EST 
>
> On Fri, Mar 03, 2006 at 03:22:42PM -0800, Linus Torvalds wrote:
>> 
>> On Sat, 4 Mar 2006, Adrian Bunk wrote:
>> > 
>> > It seems the problem is that in the CONFIG_RMW_INSNS=n 
>> > case, there's no 
>> > cmpxchg #define in include/asm-m68k/system.h required for the 
>> > atomic_add_unless #define in include/asm-m68k/atomic.h.
>> 
>> Hmm. It seems like it never has been there.. Do you know what brought this 
>> on? Was it Nick's RCU changes from "rcuref_dec_and_test()" to 
>> "atomic_dec_and_test()" and friends? 
>
> It was Nick's commit 8426e1f6af0fd7f44d040af7263750c5a52f3cc3 that added 
> atomic_inc_not_zero(), and Nick's patch that changed fs/file_table.c 
> from rcuref_dec_and_test() to atomic_dec_and_test() exposed this 
> problem.

Do kernel coders value the marking of the rcu read-side critical 
section for consistency?  In fs/file_table.c, fcheck_files() 
is called by fget_light() without rcu_read_lock() in one case, 
but with the apparently necessary rcu_read_lock() in place 
otherwise.  The struct file pointer that fcheck_files() returns 
is rcu_dereference(fdt->fd[fd]) or NULL. Does the _commented_guarantee 
of the current task holding the refcnt assure there's no need to 
check for NULL or to mark the rcu readside section around the first
call to fcheck_files()?

This is the code sample:
/*
 * Lightweight file lookup - no refcnt increment if fd table isn't shared.
 * You can use this only if it is guranteed that the current task already
 * holds a refcnt to that file. That check has to be done at fget() only
 * and a flag is returned to be passed to the corresponding fput_light().
 * There must not be a cloning between an fget_light/fput_light pair.
 */
struct file fastcall *fget_light(unsigned int fd, int *fput_needed)
{
	struct file *file;
	struct files_struct *files = current->files;

	*fput_needed = 0;
	if (likely((atomic_read(&files->count) == 1))) {
		file = fcheck_files(files, fd);
	} else {
		rcu_read_lock();
		file = fcheck_files(files, fd);
		if (file) {
			if (atomic_inc_not_zero(&file->f_count))
				*fput_needed = 1;
			else
				/* Didn't get the reference, someone's freed */
				file = NULL;
		}
		rcu_read_unlock();
	}

	return file;
}

The attached patch would superficially address the rcu 
discrepancy, but another underlying question is about the 
desired extent of the rcu read-side critical section in that 
fget_light() returns the pointer to the file struct that was 
flagged for rcu protection by rcu_dereference() in 
fcheck_files().  In this application, does it make sense to 
push the rcu_read_lock() into fcheck_files() or add it there
or to extend it to the calling function?

Up the call tree, we note that fcheck() uses fcheck_files(), 
but the only call to fcheck() nested in rcu_read_lock() is 
in the disparaged irixioctl.c.

Are the other calls to fcheck() under circumstances that give 
reason for the rcu_read_lock elision, like 
spin_lock(&files->file_lock) in fs/fcntl.c, or being in the 
context of applying locks in fs/locks.c, or calls from assembly 
code in arch/sparc/kernel/sunos_ioctl.c & solaris/socksys.c.  
If there is reason to pursue the insertion of the 
rcu_read_lock/unlock() pairs in these circumstances, any 
suggestions would be appreciated in order to dispel the question
altogether or to try to submit a more extensive patch.

Thank you.
Suzanne

-
 file_table.c |    2 ++
 1 files changed, 2 insertions(+)
---------------------------------

--- /testbed2/linux-2.6.16-rc5/fs/file_table.c	2006-02-26 21:09:35.000000000 -0800
+++ /testbed1/linux-2.6.16-rc5/fs/file_table.c	2006-03-05 14:36:46.000000000 -0800
@@ -194,7 +194,9 @@ struct file fastcall *fget_light(unsigne
 
 	*fput_needed = 0;
 	if (likely((atomic_read(&files->count) == 1))) {
+		rcu_read_lock();
 		file = fcheck_files(files, fd);
+		rcu_read_unlock();
 	} else {
 		rcu_read_lock();
 		file = fcheck_files(files, fd);

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Dipankar Sarma]

On Sun, Mar 05, 2006 at 08:44:15PM -0800, Suzanne Wood wrote:
> > From: Adrian Bunk Fri Mar 03 2006 - 18:40:57 EST 
> >
> Do kernel coders value the marking of the rcu read-side critical 
> section for consistency?  In fs/file_table.c, fcheck_files() 

Generally speaking, yes.

> is called by fget_light() without rcu_read_lock() in one case, 
> but with the apparently necessary rcu_read_lock() in place 
> otherwise.  The struct file pointer that fcheck_files() returns 
> is rcu_dereference(fdt->fd[fd]) or NULL. Does the _commented_guarantee 
> of the current task holding the refcnt assure there's no need to 
> check for NULL or to mark the rcu readside section around the first
> call to fcheck_files()?
> 
> This is the code sample:
> /*
>  * Lightweight file lookup - no refcnt increment if fd table isn't shared.
>  * You can use this only if it is guranteed that the current task already
>  * holds a refcnt to that file. That check has to be done at fget() only
>  * and a flag is returned to be passed to the corresponding fput_light().
>  * There must not be a cloning between an fget_light/fput_light pair.
>  */
> struct file fastcall *fget_light(unsigned int fd, int *fput_needed)
> {
> 	struct file *file;
> 	struct files_struct *files = current->files;
> 
> 	*fput_needed = 0;
> 	if (likely((atomic_read(&files->count) == 1))) {
> 		file = fcheck_files(files, fd);
> 	} else {

This means that the fd table is not shared between threads. So,
there can't be any race and no need to protect using
rcu_read_lock()/rcu_read_unlock().

> 
> The attached patch would superficially address the rcu 
> discrepancy, but another underlying question is about the 
> desired extent of the rcu read-side critical section in that 
> fget_light() returns the pointer to the file struct that was 
> flagged for rcu protection by rcu_dereference() in 
> fcheck_files().  In this application, does it make sense to 
> push the rcu_read_lock() into fcheck_files() or add it there
> or to extend it to the calling function?

I think a comment there explaining why rcu_read_lock/unlock
pair is not there should be sufficient. While the are NOP
for non-PREEMPT kernels, they do have a cost otherwise.
Avoiding them if we can is a good idea, IMO.

> Up the call tree, we note that fcheck() uses fcheck_files(), 
> but the only call to fcheck() nested in rcu_read_lock() is 
> in the disparaged irixioctl.c.
> 
> Are the other calls to fcheck() under circumstances that give 
> reason for the rcu_read_lock elision, like 
> spin_lock(&files->file_lock) in fs/fcntl.c, or being in the 
> context of applying locks in fs/locks.c, or calls from assembly 
> code in arch/sparc/kernel/sunos_ioctl.c & solaris/socksys.c.  
> If there is reason to pursue the insertion of the 
> rcu_read_lock/unlock() pairs in these circumstances, any 
> suggestions would be appreciated in order to dispel the question
> altogether or to try to submit a more extensive patch.

It depends on whether the fdtable is shared or not and if
shared whether we are already holding the ->files_lock or
not. The key is that if it is lock-free and if the fdtable
is shared, they rcu_read_lock()/unlock() pair must be
there, otherwise it is a bug.

Thanks
Dipankar

Linux v2.6.16-rc5

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11550 bytes --]


The tar-ball is being uploaded right now, and everything else should 
already be pushed out. Mirroring might take a while, of course.

There's not much to say about this: people have been pretty good, and it's 
just a random collection of fixes in various random areas. The shortlog is 
actually pretty short, and it really describes the updates better than 
anything else.

Have I missed anything? Holler. And please keep reminding about any 
regressions since 2.6.15.

		Linus

---

Adrian Bunk:
      [AGPGART] help text updates
      drivers/net/tlan.c: #ifdef CONFIG_PCI the PCI specific code

Al Viro:
      GFP_KERNEL allocations in atomic (auditsc)
      don't mangle INQUIRY if cmddt or evpd bits are set
      fix handling of st_nlink on procfs root
      m68k: restore disable_irq_nosync()
      missing ntohs() in ip6_tunnel
      m68k: pm_power_off() breakage
      iomap_copy fallout (m68k)
      sd: fix memory corruption with broken mode page headers

Alan Curry:
      powerpc: fix altivec_unavailable_exception Oopses

Alessandro Zummo:
      [ARM] 3342/1: NSLU2: Protect power button init routine with machine_is_nslu2()
      [ARM] 3343/1: NAS100d: Fix incorrect I2C pin assignment
      [ARM] 3344/1: NSLU2: beeper support

Alexey Dobriyan:
      mm/mempolicy.c: fix 'if ();' typo
      drivers/fc4/fc.c: memset correct length

Alexey Korolev:
      cfi_cmdset_0001: fix range for cache invalidation

Andi Kleen:
      x86_64: Don't set CONFIG_DEBUG_INFO in defconfig
      Fix units in mbind check
      x86_64: Only do the clustered systems have unsynchronized TSC assumption on IBM systems
      x86-64/i386: Use common X86_PM_TIMER option and make it EMBEDDED
      x86_64: Disable ACPI blacklist by year for now on x86-64
      x86_64: Fix the additional_cpus=.. option
      x86_64: Move the SMP time selection earlier
      x86_64: Better ATI timer fix
      x86_64: Fix ioctl compat code for /dev/rtc

Andreas Deresch:
      i386: Handle non existing APICs without panicing

Andrew Morton:
      ramfs: update dir mtime and ctime

Andrew Victor:
      [ARM] 3325/2: GPIO function to control multi-drive (open collector) capability
      [ARM] 3348/1: Disable GPIO interrupts

Anton Altaparmakov:
      NTFS: Fix a potential overflow by casting (index + 1) to s64 before doing a
      NTFS: - Cope with attribute list attribute having invalid flags.
      NTFS: Implement support for sector sizes above 512 bytes (up to the maximum
      NTFS: Do more detailed reporting of why we cannot mount read-write by

Anton Blanchard:
      powerpc: Fix runlatch performance issues
      powerpc64: remove broken/bitrotted HMT support

Antonino A. Daplas:
      Fix pseudo_palette setup in asiliantfb_setcolreg()

Atsushi Nemoto:
      [MIPS] Fixes for uaccess.h with gcc >= 4.0.1
      [MIPS] jiffies_to_compat_timeval fix

Benjamin Herrenschmidt:
      powermac: Fix loss of ethernet PHY on sleep

Björn Steinbrink:
      kjournald keeps reference to namespace

Brian Magnuson:
      fix build on x86_64 with !CONFIG_HOTPLUG_CPU

Carl-Daniel Hailfinger:
      radeonfb: resume support for Samsung P35 laptops

Catalin Marinas:
      [ARM] 3340/1: Fix the PCI setup for direct master access to SDRAM

Chris McDermott:
      x86_64: Fix NMI watchdog on x460

Christoph Hellwig:
      [SCSI] esp: fix eh locking

Christoph Lameter:
      Terminate process that fails on a constrained allocation
      page migration: Fix MPOL_INTERLEAVE behavior for migration via mbind()
      vmscan: fix zone_reclaim

Daniel Yeisley:
      i386: need to pass virtual address to smp_read_mpc()

Dave Airlie:
      drm: fixup i915 interrupt on X server exit
      drm: radeon add r300 TX_CNTL and verify bitblt packets
      drm: fix brace placement

Dave Jones:
      [AGPGART] Improve the error message shown when we detect a ServerWorks CNB20HE
      [AGPGART] Add some informational printk to nforce GART failure path.
      x86-64: react to new topology.c location

David S. Miller:
      [SPARC64]: Implement futex_atomic_op_inuser().
      [SPARC64]: Make cpu_present_map available earlier.

Eric Van Hensbergen:
      v9fs: update documentation and fix debug flag

Francois Romieu:
      r8169: fix broken ring index handling in suspend/resume
      r8169: enable wake on lan

Frank Pavlic:
      s390: V=V qdio fixes

Freddy Spierenburg:
      au1100fb: replaced io_remap_page_range() with io_remap_pfn_range()

Greg Kroah-Hartman:
      Revert mount/umount uevent removal

Haren Myneni:
      powerpc: Trivial fix to set the proper timeout value for kdump

Heiko Carstens:
      cpu hotplug documentation fix
      s390: revert dasd eer module

Herbert Xu:
      padlock: Fix typo that broke 256-bit keys
      [XFRM]: Eliminate refcounting confusion by creating __xfrm_state_put().
      [IPSEC]: Use TOS when doing tunnel lookups

Hirokazu Takata:
      m32r: __cmpxchg_u32 fix
      m32r: update sys_tas() routine
      m32r: enable asm code optimization
      m32r: fix and update for gcc-4.0

Hugh Dickins:
      tmpfs: fix mount mpol nodelist parsing
      tmpfs: recommend remount for mpol

Hugo Santos:
      [IPV6] ip6_tunnel: release cached dst on change of tunnel params

Jamal Hadi Salim:
      [NET] ethernet: Fix first packet goes out with MAC 00:00:00:00:00:00

James Bottomley:
      voyager: fix boot panic by adding topology export
      voyager: fix the cpu_possible_map to make voyager boot again
      x86: fix broken SMP boot sequence
      fix voyager after topology.c move

Jan Beulich:
      x86_64: fix USER_PTRS_PER_PGD

Jean Tourrilhes:
      [IRDA]: irda-usb bug fixes

Jon Mason:
      x86_64: no_iommu removal in pci-gart.c

Juergen Kreileder:
      Fix snd-usb-audio in 32-bit compat environment

Jun'ichi Nomura:
      dm: missing bdput/thaw_bdev at removal
      dm: free minor after unlink gendisk

Kaj-Michael Lang:
      gbefb: IP32 gbefb depth change fix

Kelly Daly:
      powerpc: disable OProfile for iSeries

Kumar Gala:
      powerpc: Enable coherency for all pages on 83xx to fix PCI data corruption
      powerpc: Fix mem= cmdline handling on arch/powerpc for !MULTIPLATFORM

Kurt Garloff:
      OOM kill: children accounting

Linus Torvalds:
      Make Kprobes depend on modules
      Linux v2.6.16-rc5

Luke Yang:
      Fix undefined symbols for nommu architecture

Marc Zyngier:
      Fix Specialix SI probing

Martin Michlmayr:
      [MIPS] Add support for TIF_RESTORE_SIGMASK for signal32
      [MIPS] Make do_signal32 return void.
      [MIPS] Fix compiler warnings in arch/mips/sibyte/bcm1480/irq.c
      gbefb: Set default of FB_GBE_MEM to 4 MB

Michael Ellerman:
      powerpc: Don't start secondary CPUs in a UP && KEXEC kernel
      powerpc: Make UP -> SMP kexec work again
      powerpc: Fix bug in spinup of renumbered secondary threads
      powerpc: Initialise hvlpevent_queue.lock correctly
      powerpc: Only calculate htab_size in one place for kexec

Michal Janusz Miroslaw:
      [SERIAL] Trivial comment fix: include/linux/serial_reg.h

Michal Ostrowski:
      Fix race condition in hvc console.

Mårten Wikström:
      [ARM] 3347/1: Bugfix for ixp4xx_set_irq_type()

Olaf Hering:
      powerpc: remove duplicate exports
      ppc: fix adb breakage in xmon

Olof Johansson:
      powerpc: Fix OOPS in lparcfg on G5
      powerpc: Update {g5,pseries,ppc64}_defconfig

Paolo 'Blaisorblade' Giarrusso:
      uml: correct error messages in COW driver
      uml: fix usage of kernel_errno in place of errno
      uml: fix ((unused)) attribute
      uml: os_connect_socket error path fixup
      uml: better error reporting for read_output
      uml: tidying COW code

Patrick McHardy:
      [XFRM]: Fix policy double put
      [NETFILTER]: Fix NAT PMTUD problems
      [NETFILTER]: Fix outgoing redirects to loopback
      [NETFILTER]: Fix bridge netfilter related in xfrm_lookup

Paul Mackerras:
      powerpc: Keep xtime and gettimeofday in sync

Pavel Machek:
      suspend-to-ram: allow video options to be set at runtime

Pekka Enberg:
      NTFS: We have struct kmem_cache now so use it instead of the typedef.

Peter Oberparleiter:
      s390: dasd reference counting

Peter Osterlund:
      pktcdvd: Correctly set rq->cmd_len in pkt_generic_packet()
      pktcdvd: Rename functions and make their return values sane
      pktcdvd: Remove useless printk statements
      pktcdvd: Fix the logic in the pkt_writable_track function
      pktcdvd: Only return -EROFS when appropriate

Prasanna S Panchamukhi:
      Kprobes causes NX protection fault on i686 SMP

R Sharada:
      powerpc64: fix spinlock recursion in native_hpte_clear

Ralf Baechle:
      H8/300: CONFIG_CONFIG_ doesn't fly.
      [MIPS] Make integer overflow exceptions in kernel mode fatal.
      [MIPS] Reformat _sys32_rt_sigsuspend with tabs instead of space for consistency.
      [MIPS] N32: Fix N32 rt_sigtimedwait and rt_sigsuspend breakage.
      [MIPS] N32: Make sure pointer is good before passing it to sys_waitid().
      [MIPS] Sibyte: #if CONFIG_* doesn't fly.
      [MIPS] Sibyte: Config option names shouldn't be prefixed with CONFIG_
      [MIPS] Follow Uli's latest *at syscall changes.
      [MIPS] Yosemite: Fix build damage by dc8f6029cd51af1b148846a32e68d69013a5cc0f.
      [MIPS] Disable CONFIG_ISCSI_TCP; it triggers a gcc 3.4 endless loop.

Rene Herman:
      snd-cs4236 typo fix

Richard Lucassen:
      [NET]: Increase default IFB device count.

Rojhalat Ibrahim:
      [MIPS] Add topology_init.

Russell King:
      [MMC] Fix mmc_cmd_type() mask
      [ARM] Add panic-on-oops support
      [ARM] Update mach-types
      [ARM] CONFIG_CPU_MPCORE -> CONFIG_CPU_32v6K
      [SERIAL] Add comment about early_serial_setup()

Samuel Thibault:
      vgacon: no vertical resizing on EGA

Segher Boessenkool:
      powerpc: Fix some MPIC + HT APIC buglets
      powerpc: Don't re-assign PCI resources on Maple

Simon Vogl:
      cfi: init wait queue in chip struct

Stefan Richter:
      sbp2: fix another deadlock after disconnection
      sbp2: variable status FIFO address (fix login timeout)
      sbp2: update 36byte inquiry workaround (fix compatibility regression)

Stephen Hemminger:
      sky2: yukon-ec-u chipset initialization
      sky2: limit coalescing values to ring size
      sky2: poke coalescing timer to fix hang
      sky2: force early transmit status
      sky2: use device iomem to access PCI config
      sky2: close race on IRQ mask update.
      skge: NAPI/irq race fix
      skge: genesis phy initialzation
      skge: protect interrupt mask

Stephen Rothwell:
      Fix compile for CONFIG_SYSVIPC=n or CONFIG_SYSCTL=n

Stephen Street:
      spi: Fix modular master driver remove and device suspend/remove

Steve French:
      CIFS: CIFSSMBRead was returning an invalid pointer in buf on socket error

Suresh Bhogavilli:
      [IPV4]: Fix garbage collection of multipath route entries

Suresh Siddha:
      x86_64: Check for bad elf entry address.

Takashi Iwai:
      alsa: fix bogus snd_device_free() in opl3-oss.c

Tejun Heo:
      libata: fix WARN_ON() condition in *_fill_sg()
      libata: fix qc->n_elem == 0 case handling in ata_qc_next_sg
      libata: make ata_sg_setup_one() trim zero length sg

Uli Luckas:
      [ARM] 3345/1: Fix interday RTC alarms

Ulrich Drepper:
      flags parameter for linkat

YOSHIFUJI Hideaki:
      [NET]: NETFILTER: remove duplicated lines and fix order in skb_clone().
      [IPV6]: Do not ignore IPV6_MTU socket option.

Zachary Amsden:
      Fix topology.c location

Zhu Yi:
      ipw2200: Suppress warning message

2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Adrian Bunk]

The m68k defconfig does no longer compile in 2.6.16-rc:

<--  snip  -->

...
  CC      fs/file_table.o
fs/file_table.c: In function `fget':
fs/file_table.c:170: warning: implicit declaration of function `cmpxchg'
...
  LD      .tmp_vmlinux1
fs/built-in.o(.text+0x275a): In function `fget':
: undefined reference to `cmpxchg'
fs/built-in.o(.text+0x27da): In function `fget_light':
: undefined reference to `cmpxchg'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


It seems the problem is that in the CONFIG_RMW_INSNS=n case, there's no 
cmpxchg #define in include/asm-m68k/system.h required for the 
atomic_add_unless #define in include/asm-m68k/atomic.h.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Linus Torvalds]

On Sat, 4 Mar 2006, Adrian Bunk wrote:
> 
> It seems the problem is that in the CONFIG_RMW_INSNS=n case, there's no 
> cmpxchg #define in include/asm-m68k/system.h required for the 
> atomic_add_unless #define in include/asm-m68k/atomic.h.

Hmm. It seems like it never has been there.. Do you know what brought this 
on? Was it Nick's RCU changes from "rcuref_dec_and_test()" to 
"atomic_dec_and_test()" and friends? 

Judging by your error messages, I _think_ it's the "atomic_inc_not_zero()" 
that gets expanded to a cmpxchg() that simply doesn't exist on m68k and 
never has.

I guess we've never depended on cmpxchg before. Or am I missing something?

		Linus

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Adrian Bunk]

On Fri, Mar 03, 2006 at 03:22:42PM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 4 Mar 2006, Adrian Bunk wrote:
> > 
> > It seems the problem is that in the CONFIG_RMW_INSNS=n case, there's no 
> > cmpxchg #define in include/asm-m68k/system.h required for the 
> > atomic_add_unless #define in include/asm-m68k/atomic.h.
> 
> Hmm. It seems like it never has been there.. Do you know what brought this 
> on? Was it Nick's RCU changes from "rcuref_dec_and_test()" to 
> "atomic_dec_and_test()" and friends? 

It was Nick's commit 8426e1f6af0fd7f44d040af7263750c5a52f3cc3 that added 
atomic_inc_not_zero(), and Nick's patch that changed fs/file_table.c 
from rcuref_dec_and_test() to atomic_dec_and_test() exposed this 
problem.

> Judging by your error messages, I _think_ it's the "atomic_inc_not_zero()" 
> that gets expanded to a cmpxchg() that simply doesn't exist on m68k and 
> never has.

Exactly, that's what I wanted to say in my report.

> I guess we've never depended on cmpxchg before. Or am I missing something?

It seems this is the case.

And as far as I can see, m68k is the only architecture where cmpxchg 
isn't always available.

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Andrew Morton]

Linus Torvalds <torvalds@osdl.org> wrote:
>
> 
> 
> On Sat, 4 Mar 2006, Adrian Bunk wrote:
> > 
> > It seems the problem is that in the CONFIG_RMW_INSNS=n case, there's no 
> > cmpxchg #define in include/asm-m68k/system.h required for the 
> > atomic_add_unless #define in include/asm-m68k/atomic.h.
> 
> Hmm. It seems like it never has been there.. Do you know what brought this 
> on? Was it Nick's RCU changes from "rcuref_dec_and_test()" to 
> "atomic_dec_and_test()" and friends? 
> 
> Judging by your error messages, I _think_ it's the "atomic_inc_not_zero()" 
> that gets expanded to a cmpxchg() that simply doesn't exist on m68k and 
> never has.
> 
> I guess we've never depended on cmpxchg before. Or am I missing something?
> 

Yes, we now require cmpxchg of all architectures.

It's pretty simple to fix - just use local_irq_save().  We can steal the code
from include/asm-m68knommu/system.h.

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Roman Zippel]

Hi,

On Fri, 3 Mar 2006, Andrew Morton wrote:

> Yes, we now require cmpxchg of all architectures.

Actually I'd prefer if we used atomic_cmpxchg() instead.
The cmpxchg() emulation was never added for a good reason - to keep code 
from assuming it can be used it for userspace synchronisation. Using an 
atomic_t here would probably get at least some attention.

bye, Roman

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Nick Piggin]

Roman Zippel wrote:
> Hi,
> 
> On Fri, 3 Mar 2006, Andrew Morton wrote:
> 
> 
>>Yes, we now require cmpxchg of all architectures.
> 
> 
> Actually I'd prefer if we used atomic_cmpxchg() instead.
> The cmpxchg() emulation was never added for a good reason - to keep code 
> from assuming it can be used it for userspace synchronisation. Using an 
> atomic_t here would probably get at least some attention.
> 

Yes, I guess that's what Andrew meant. The reason we can require
atomic_cmpxchg of all architectures is because it is only guaranteed
to work on atomic_t.

Glad to hear it won't be a problem for you though.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

[Andrew Morton]

Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> Roman Zippel wrote:
> > Hi,
> > 
> > On Fri, 3 Mar 2006, Andrew Morton wrote:
> > 
> > 
> >>Yes, we now require cmpxchg of all architectures.
> > 
> > 
> > Actually I'd prefer if we used atomic_cmpxchg() instead.
> > The cmpxchg() emulation was never added for a good reason - to keep code 
> > from assuming it can be used it for userspace synchronisation. Using an 
> > atomic_t here would probably get at least some attention.
> > 
> 
> Yes, I guess that's what Andrew meant. The reason we can require
> atomic_cmpxchg of all architectures is because it is only guaranteed
> to work on atomic_t.
> 
> Glad to hear it won't be a problem for you though.
> 

Could someone with an m68k compiler please send the patch?