Okay, we're finally at the point where ->detect has become entirely
superflous.  In sd, sr and st it does nothing but return different
values that are ignored anyway, in sg it increments a variable
that is never read (and thus removed in this patch aswell), only
in osst it increments a variable that is actually checked for beeing
non-zero.  But if it was zero we'd never reached that place anyway
(same check in the beginning of osst_detect and osst_attach).

This make the upper layer interface a lot nicer and avoids the
race condition where a device is remove between detect and attach
(which currently wouldn't matter anyway as we aren't doing anything
in detect anymore)

This patch adds request prep functions to the mid-layer.  At the moment, its a single request prep function for all of SCSI.  I've altered the logic in scsi_request_fn so that we now do early preparation (this should improve throughput slightly in the untagged case with only a single command block).

The prep function also cannot drop the queue lock, so the calling assumptions for scsi_init_io and the upper layer driver init_commands have changed to be that the lock is now held and they cannot drop it.  I think this means that we have no callers of scsi_init_io that aren't atomic, so perhaps I can just take the if out.

I've hammered this in my usual set up, but other testers would be welcome.

James

On Wed, Nov 06, 2002 at 01:50:00PM -0500, J.E.J. Bottomley wrote:
> I'm OK with that, since the drivers can be audited as they're moved over to 
> slave attach.  It also works for drivers that use older hardware (like the 
> 53c700) which don't call adjust_queue_depth from slave attach, but slightly 
> later on when they've really verified the device will accept tags.  In this 
> case, I don't want the mid layer to call adjust_queue_depth for me even if I 
> leave slave_attach with only one command allocated.

OK, here it is again, as discussed, plus it calls scsi_release_commandblocks
on slave_attach failure.

This patch fixes queue depth setting of scsi devices.

This is done by pairing shost->slave_attach() calls with
a scsi_build_commandblocks in the new scsi_slave_attach.

This is a patch aginst linux-scsi.bkbits.net/scsi-for-linus-2.5 after
applying the last posted hch version of the "Eliminate scsi_host_tmpl_list"
patch, it still applies with offset to the current scsi-for-linus-2.5.

It also:

Will properly call shost->slave_attach after a scsi_unregister_device()
followed by a scsi_register_device() - as could happen if you were able to
rmmod all upper level drivers and then insmod any of them back (only
possible when not booted on scsi).

Checks for scsi_build_commandblocks() allocation failures.

Sets queue depth even if shost->slave_attach() does not call
scsi_adjust_queue_depth.

Removes the use of revoke (no drivers are setting it, it was only
call via the proc scsi remove-single-device interface).

There are at least two problems with sysfs and scsi (one in sysfs, one in
scsi, I'll try and post more soon ...) so I could not completey test rmmod
of an adapter or upper level driver without leading to an oops or shutdown
hang.

 hosts.c              |    5 --
 hosts.h              |    6 --
 osst.c               |    9 ++-
 scsi.c               |  118 +++++++++++++++++++++++++++++++--------------------
 scsi.h               |    2
 scsi_mid_low_api.txt |   24 ----------
 scsi_scan.c          |    9 ---
 sd.c                 |   10 +++-
 sg.c                 |   10 ++--
 sr.c                 |    7 ++-
 st.c                 |   11 +++-
 11 files changed, 106 insertions(+), 105 deletions(-)

===== drivers/scsi/hosts.c 1.23 vs edited =====

There's only the one, in XFS.

  - Add the library function read_cache_pages(), which is used in a
    similar fashion to the single page 'read_cache_page()'. It hides
    the details of the LRU cache etc. from a filesystem that wants to
    to populate an address space with a list of pages.

  - Fix NFS so that readahead uses the ->readpages() interface. Means
    that we can immediately schedule an RPC call in order to complete
    the I/O, rather than relying on somebody later triggering it by
    calling lock_page() (and hence sync_page()). The sync_page()
    method is race-prone, since the waiting page may try to call it
    before we've finished initializing the 'struct nfs_page'.

  - Clear out nfs_sync_page(), the nfs_inode->read list, and
    friends. When the I/O completion gets scheduled in ->readpage(),
    ->readpages(), they have no reason to exist.

The following patch makes the ->readpages() address_space_operation
take a struct file argument just like ->readpage().

This is the second iteration of thread-aware coredumps.

Changes:

- Ulrich Drepper has reviewed the data structures and checked actual
  coredumps via readelf - everything looks fine and according to the spec.

- a serious bug has been fixed in the thread-state dumping code - it was
  still based on the 2.4 assumption that the task struct points to the
  kernel stack - it's task->thread_info in 2.5. This bug caused bogus
  register info to be filled in for threads.

- properly wait for all threads that share the same MM to serialize with
  the coredumping thread. This is CLONE_VM based, not tied to
  CLONE_THREAD and/or signal semantics, ie. old-style (or different-style)
  threaded apps will be properly stopped as well.

  The locking might look a bit complex, but i wanted to keep the
  __exit_mm() overhead as low as possible. It's not quite trivial to get
  these bits right, because 'sharing the MM' is detached from signals
  semantics, so we cannot rely on broadcast-kill catching all threads. So
  zap_threads() iterates through every thread and zaps those which were
  left out. (There's a minimal race left in where a newly forked child
  might escape the attention of zap_threads() - this race is fixed by the
  OOM fixes in the mmap-speedup patch.)

- fill_psinfo() is now called with the thread group leader, for the
  coredump to get 'process' state.

 - initialize the elf_thread_status structure with zeroes.

the IA64 ELF bits are not included, yet, to reduce complexity of the
patch. The patch has been tested on x86 UP and SMP.

drivers/ide/legacy/ide-cs.c:
 o Added MODULE_{AUTHOR,DESCRIPTION}, fixed MODULE_LICENSE
 o Added support for (Panasonic) KME KXLC005 cards
 o Better errno for failed module initialization

drivers/parport/parport_cs.c
 o Fixed it so it actually works
 o Removed cruft for old kernels
 o Better errno for failed module initialization

include/pcmcia/ciscode.h
o added product ID's for a few more cards

drivers/net/pcmcia/fmvj18x_cs.c
o Added MODULE_DESCRIPTION
o Added support for RATOC cards
o Added support for Nextcom NC5310B cards
o Added support for SSi 78Q8370 chipset
o Added support for TDK GN3410 multifunction cards
o Better errno for failed module initialization
o Cleaned up whitespace

drivers/net/pcmcia/smc91c92_cs.c
o Added full duplex support for smc91c100 based cards
o Better errno for failed module initialization
o Synced up naming of stuff to match pcmcia-cs version
o Cleaned up whitespace

drivers/pcmcia/cardbus.c
drivers/pcmcia/cistpl.c
drivers/pcmcia/cs_internal.c
o Fixed card identification bug triggered by invoking certain PCMCIA
  tools when cardmgr is not running.

This brings several PCMCIA network drivers into sync with 2.4 and the
pcmcia-cs package.  The axnet_cs driver gets a major cleanup.

This cleans up some obsolete email addresses.

into home.transmeta.com:/home/torvalds/v2.5/linux

  
In order to conserve CPU, the read(2) syscall would schedule_timeout
unconditionally.  This also crippled speed, and was a bad design
decision.  This cset merges the updated read(2) logic of the sister
driver amd768_rng from Alan, which schedules only when it needs to.
  
On my test system, by one microbenmark, read(2) output jumped
from 0.08 kbit/s to "what Intel expects" of 20 kbit/s.
  
End users may notice a significant decrease in idle time after
this change (and a correspondingly large increase in /dev/hwrng user
speed), if /dev/hwrng is used to its maximum capacity.

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

Now that .init isn't implement anymore we can get rid of it and
do some more cleanup in the scsi device template:

* remove .blk - unused since 2.5.46
* remove .dev_noticed, only midlayer user is gone together with
  .init.  remaining instance now driver-private
* remove .nr_dev and .dev_max - they're purely driver internal
  and at least in sd and sr they'll be completly gone very soon.

Yes, this is the patch every maintainer of a modern HBA waited for the
last years </shameless plug>.

With all my recent changes there's no more reason to call scsi_register_host
except for the intialization it performs to every host found in
scsi_register.  But a driver can aswell do that at the end of it's
per-HBA detection routine (i.e. in ->probe for a modern PCI driver), so
export that code as scsi_add_host to drivers.  Do the same for the
release path (scsi_remove_host).  Such a new-style driver needs neither
->detect or ->release and is in theory hotplug-capable (well, once all
the races in the scsi midlayer are fixed..)

into mulgrave.(none):/home/jejb/BK/scsi-for-linus-2.5

into mulgrave.(none):/home/jejb/BK/scsi-for-linus-2.5

into kroah.com:/home/greg/linux/BK/pci_hp-2.5

into kroah.com:/home/greg/linux/BK/gregkh-2.5

Dereferencing hcd.pdev will always oops with SA-1111.  It has to be
treated as a cookie, not a pointer in any common OHCI HCD code.

Apparently we need a clean way to go from struct device * to struct
ohci_hcd *.  I added dev_to_ohci that does the obvious thing and added
separate implementations for PCI and SA-1111.  Two implementations is
ugly but I didn't think it wise (for me) to hack on the PCI/driverfs
interface, so I just cut & paste the old code.

Two patches.  The first is a diff from linux-2.5.44 and
linux-2.5.44-rmk1.  It is from rmk and adds a struct device pointer to
ohci_hcd.  The second depends on the first and contains my changes to
clean up to the pdev oops problems.  (Some fuzz may occur as I have
ohci-1024 applied.)

With these changes, SA111 OHCI-HC/HCD is showing some signs of life on
linux-2.5.44-rmk1.  usb-storage is currentl blowing chunks, but I think
I saw some patches go by against 2.5.44 that I haven't yet tried.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

(from Alan Cox)

This adds support for 68328, 68360, MCF and NB85E serial drivers.

into flint.arm.linux.org.uk:/usr/src/linux-bk-2.5/linux-2.5-rmk

- Add LDFLAGS_BLOB definitions
- Tweak kernel_thread for better code
- Fix vmlinux-armv.lds.in to prevent ld complaining about the
  architecture private flags.
(I'm not certain that the last item isn't a hole in some bug fix in
ld - this fix appears to work with every binutils I've found thus
far.  However, if this suspected bug gets fixed, we're going to have
to rethink how we combine binary objects into ELF objects.)

2.5.46 appears to require drivers/scsi/scsi.h to be included before
drivers/scsi/hosts.h.  Make this happen in the Acorn SCSI drivers.

This completes the kernel-wide audit.

handling (it's "current_text_addr()", not the home-brew
gcc label magic)

Ahm.

No. It must be i_version = 1

Otherwise there is a trivial bug:
    mkdir("dir");
    <force the directory out of dcache>
    dir = open("dir");
    lseek(dir,1,SEEK_SET);
    readdir();

lseek sets f_version to 0, and readdir() trusts f_pos, because i_version
is 0, too. This applies to all filesystems.

The ext2 patch already sets i_version to 1.

The result of a timer audit in sound/*

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux