the attached patch (against BK-curr) fixes a sys_wait4() bug noticed by
Ulrich Drepper. The kernel would not block properly if there are eligible
children delayed due to the new delayed thread-group-leader logic. The
solution is to introduce a new type of 'eligible child' type - and skip
over delayed children but set the wait4 flag nevertheless.

The libpthreads testcase that failed due to it now it works fine.

 - HT CPU's can share the MTRR state between cores
 - the code uses static variables that are shared

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

I fixed up the 'remove thread group inferiors from the tasklist' patch. I
think i managed to find a reasonably good construct to iterate over all
threads:

	do_each_thread(g, p) {
		...
	} while_each_thread(g, p);

the only caveat with this is that the construct suggests a single-loop -
while it's two loops internally - and 'break' will not work. I added a
comment to sched.h that warns about this, but perhaps it would help more
to have naming that suggests two loops:

	for_each_process_do_each_thread(g, p) {
		...
	} while_each_thread(g, p);

but this looks a bit too long. I dont know. We might as well use it all
unrolled and no helper macros - although with the above construct it's
pretty straightforward to iterate over all threads in the system.

This fixes endless loop without schedule which happens as soon as smbd
invokes fcntl64(7, F_SETLK64, ...).  fcntl_setlk64 gets cmd F_SETLK64,
not F_SETLK tested in the loop;

Maybe return value from posix_lock_file should be changed to -EINPROGRESS
or -EJUKEBOX instead of testing passed cmd in callers, but this oneliner
works too. If you preffer changing posix_lock_file return value to clearly
distinugish between -EAGAIN and lock request queued, I'll do that.

On 13 Sep 2002, Paul Larson wrote:
>
> The nightly LTP test against the 2.5 kernel bk tree last night turned up
> some test failures we don't normally see.  These failures did not show
> up in the run from the previous night.

[...]
> I found what was breaking this, looks like it was this change from your
> shared thread signals patch:
> -	if (sig < 1 || sig > _NSIG ||
> -	    (act && (sig == SIGKILL || sig == SIGSTOP)))
> +	if (sig < 1 || sig > _NSIG || (act && sig_kernel_only(sig)))

This fixes this bug and a number of others in the same class - the
signal behavior bitmasks should never be consulted before making sure
that the signal is in the word range.

This fixes the Mozilla SMP lockup in the exit path.

The partition changes shifted a lot of indexes down one, but this one
shouldn't have been shifted...

. No need for the timer_running member on llc_timer,
  we only need it in one place, and timer_pending is
  equivalent. One more procom OS generalisation killed.
. Move the skb->protocol assignment in llc_build_and_send_pkt
  routines and llc_ui_send_data to the caller, this is the common
  practice in Linux networking code (think netif_rx) and required
  to keep the request functions in psnap and p8022 simple.
. Remove the rpt_status (report status) ev members, not
  used at all, not even in the original procom code.
. Convert psnap and p8022 request functions to use
  llc_ui_build_and_send_ui_pkt, removing all the prim cruft.

This adds support for synchronous iocbs and converts generic_file_read
to use a sync iocb to call into generic_file_aio_read.

The tests I've run with lmbench on a piii-866 showed no difference in
file re-read speed when forced to use a completion path via aio_complete
and an -EIOCBQUEUED return from generic_file_aio_read -- people with
slower machines might want to test this to see if we can tune it any
better.  Also, a bug fix to correct a missing call into the aio code
from the fork code is present.  This patch sets things up for making
generic_file_aio_read actually asynchronous.

This is Janet Morgan's patch which converts the readv/writev code
to submit all segments for IO before waiting on them, rather than
submitting each segment separately.

This is a critical performance fix for O_DIRECT reads and writes.
Prior to this change, O_DIRECT vectored IO was forced to wait for
completion against each segment of the iovec rather than submitting all
segments and waiting on the lot.  ie: for ten segments, this code will
be ten times faster.

There will also be moderate improvements for buffered IO - smaller code
paths, plus writev() only takes i_sem once.

The patch ended up quite large unfortunately - turned out that the only
sane way to implement this without duplicating significant amounts of
code (the generic_file_write() bounds checking, all the O_DIRECT
handling, etc) was to redo generic_file_read() and generic_file_write()
to take an iovec/nr_segs pair rather than `buf, count'.

New exported functions generic_file_readv() and generic_file_writev()
have been added:

ssize_t generic_file_readv(struct file *filp, const struct iovec *iov,
                          unsigned long nr_segs, loff_t *ppos);
ssize_t generic_file_writev(struct file *file, const struct iovec *iov,
                          unsigned long nr_segs, loff_t * ppos);

If a driver does not use these in their file_operations then they will
continue to use the old readv/writev code, which sits in a loop calling
calls fops->read() or fops->write().

ext2, ext3, JFS and the blockdev driver are currently using this
capability.

Some coding cleanups were made in fs/read_write.c.  Mainly:

- pass "READ" or "WRITE" around to indicate the diretion of the
  operation, rather than the (confusing, inverted)
  VERIFY_READ/VERIFY_WRITE.

- Use the identifier `nr_segs' everywhere to indicate the iovec
  length rather than `count', which is often used to indicate the
  number of bytes in the syscall.  It was confusing the heck out of me.

- Some cleanups to the raw driver.

- Some additional generality in fs/direct_io.c: the core `struct dio'
  used to be a "populate-and-go" thing.  Janet has broken that up so
  you can initialise a struct dio once, then loop around feeding it
  more file segments, then wait on completion against everything.

- In a couple of places we needed to handle the situation where we
  knew, a-priori, that the user was going to get a short read or write.
  File size limit exceeded, read past i_size, etc.  We handled that by
  shortening the iovec in-place with iov_shorten().  Which is not
  particularly pretty, but neither were the alternatives.

This makes NMIs work - otherwise they go to CPU 0 only and any hard
lockup on the other CPUs will not be detected by the nmi_watchdog.

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

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

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

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

Intermediate patch for the PF_LLC SOCK_DGRAM prim clean-up, now
PF_LLC is prims in the sending side, now to hack the core to
not use prims to send to PF_LLC.

This also fixes a skb leak on llc_sap_state_process.

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

- Jens needs to seperate out the IN/OUT macros to seperate what accesses
are to the IDE_DATA register and the rest.  On big-endian platforms
the IDE_DATA register should be accessed in big-endian for it to all
work out correctly or at least be compatible with the behavior existing
before the IDE platform macro interface changes in 2.5.x

This implements the 'keep the initial thread around until every thread
in the group exits' concept in a different, less intrusive way, along
your suggestions.  There is no exit_done completion handling anymore,
freeing of the task is still done by wait4().  This has the following
side-effect: detached threads/processes can only be started within a
thread group, not in a standalone way.

(This also fixes the bugs introduced by the ->exit_done code, which made
it possible for a zombie task to be reactivated.)

I've introduced the p->group_leader pointer, which can/will be used for
other purposes in the future as well - since from now on the thread
group leader is always existent.  Right now it's used to notify the
parent of the thread group leader from the last non-leader thread that
exits [if the thread group leader is a zombie already].

I distilled the attached fix-patch from Daniel's bigger patch - it
includes all fixes for all currently known ptrace related breakages,
which include things like bad behavior (crash) if the tracer process
dies unexpectedly.

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