Skip to main content

Browse the archive

Revision dc59250c6ebed099a9bc0a11298e2281dd896657 authored by Chuck Lever on 18 August 2005, 18:24:12 UTC, committed by Linus Torvalds on 18 August 2005, 19:53:57 UTC 
[PATCH] NFS: Introduce the use of inode->i_lock to protect fields in nfsi
 
Down the road we want to eliminate the use of the global kernel lock entirely
from the NFS client.  To do this, we need to protect the fields in the
nfs_inode structure adequately.  Start by serializing updates to the
"cache_validity" field.

Note this change addresses an SMP hang found by njw@osdl.org, where processes
deadlock because nfs_end_data_update and nfs_revalidate_mapping update the
"cache_validity" field without proper serialization.

Test plan:
 Millions of fsx ops on SMP clients.  Run Nick Wilson's breaknfs program on
 large SMP clients.

Signed-off-by: Chuck Lever <cel@netapp.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
1 parent 412d582
Raw File
i2c-stub 
MODULE: i2c-stub

DESCRIPTION:

This module is a very simple fake I2C/SMBus driver.  It implements four
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
(r/w) word data.

No hardware is needed nor associated with this module.  It will accept write
quick commands to all addresses; it will respond to the other commands (also
to all addresses) by reading from or writing to an array in memory.  It will
also spam the kernel logs for every command it handles.

A pointer register with auto-increment is implemented for all byte
operations.  This allows for continuous byte reads like those supported by
EEPROMs, among others.

The typical use-case is like this:
	1. load this module
	2. use i2cset (from lm_sensors project) to pre-load some data
	3. load the target sensors chip driver module
	4. observe its behavior in the kernel log

CAVEATS:

There are independent arrays for byte/data and word/data commands.  Depending
on if/how a target driver mixes them, you'll need to be careful.

If your target driver polls some byte or word waiting for it to change, the
stub could lock it up.  Use i2cset to unlock it.

If the hardware for your driver has banked registers (e.g. Winbond sensors
chips) this module will not work well - although it could be extended to
support that pretty easily.

If you spam it hard enough, printk can be lossy.  This module really wants
something like relayfs.
back to top