On Wed, 5 Feb 2003, Rik van Riel wrote:
> On Tue, 4 Feb 2003, Andy Chou wrote:

Thanks for the checker output.  First patch below...

> > [BUG]
> > u1/acc/linux/2.5.48/drivers/scsi/sr_ioctl.c:188:sr_do_ioctl:
> > ERROR:LEAK:85:188:Memory leak [Allocated from:
> > /u1/acc/linux/2.5.48/drivers/scsi/sr_ioctl.c:85:scsi_allocate_request]
>
> Bug indeed, I've created a patch to fix the possible leak of
> a scsi request, but can't figure out the bounce buffer logic...

The patch below fixes the scsi request leak. I'm not sure
how the bounce buffer thing is supposed to work (Christoph?
James?) so I'm not touching that at the moment.

Linus, could you please apply this patch (against today's
bk tree) ?

thank you,

Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>


===== drivers/scsi/sr_ioctl.c 1.27 vs edited =====

On Tue, Feb 04, 2003 at 12:33:23PM -0600, James Bottomley wrote:
> I agree with this.  It is a guarantee the mid-layer makes to the LLD
> (and there are some LLDs with static issue queues for which this is a
> hard requirement).  I think (once the dust has settled and we've agreed
> which field holds the current queue depth) what's needed is a check in
> the scsi_request_fn() to see if we're over the LLD's current depth for
> the device and plug the queue and exit if we are.  The next returning
> command will unplug and send.
>
> This way of doing things means that we're free to prep as many commands
> as we can, but we guarantee only to have the correct number outstanding
> to the LLD.

Okay, here's a new versin of the patch.  Changes:

* throttel on number of inflight command blocks
* rename scsi_cmnd->new_queue_depth to scsi_cmnd->queue_depth
* remove scsi_do_cmd
* serialize pool handling

now that scsi_add_host accepts a NMULL dev argument we don't need it
anymore.

Linus's current BK tree needs the following build fix:

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

One of the goals of the whole new modversions implementation:
export-objs is gone for good!

into shaggy.austin.ibm.com:/shaggy/bk/jfs-2.5

o Build modules with CONFIG_MODVERSIONS when just saying "make"
o Ignore generated *.ver.c files
o Fix a typo (Sam Ravnborg)
o Fix another typo (Paul Marinceu)

into tp1.ruhr-uni-bochum.de:/scratch/kai/kernel/v2.5/linux-2.5.make

Skip over the first part of __vermagic in modversioning is on: otherwise
you'll have to force it when changing from 2.6.0 to 2.6.1.

Fix the case where no CRCs are supplied (OK, but taints kernel), and
only print one tainted message (otherwise --force gives hundreds of them).

We generated the intermediate files that contain checksums for
unresolved symbols in .tmp_versions, which had the disadvantage
that is obscured what's going on during the build. Just
generate them as .ver.[co] right next to the actual objects in the
object tree.

CONFIG_MODVERSIONING was a temporary name introduced to distinguish
between the old and new module version implementation. Since the
traces of the old implementation are now gone from the build system,
we rename the config option back in order to not confuse users more
than necessary in 2.6.
 
Also, remove some historic modversions cruft throughout the tree.

into hostme.bitkeeper.com:/ua/repos/j/jfs/linux-2.5

After disabling files that wouldn't build, there were 2 (in-kernel)
modules that referenced _init or _exit code sections when they
shouldn't.

This fixes those modules.

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

into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5

into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5

into redhat.com:/garz/repo/net-drivers-2.5

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

Certain support files are shared between various ARM machine classes.
In other to sanely support these, we place the shared files in
arch/arm/common instead of the individual machine class directories.

Patch from Russell King <rmk@arm.linux.org.uk>

show_task() attempts to calculate the amount of free space which hasn't been
written to on the kernel stack by reading from the base of the kernel stack
upwards.

However, it mistakenly uses the task_struct pointer as the base of the stack,
which it isn't, and this can cause an oops.

Here is a patch which uses the task thread pointer instead, which should be
located at the bottom of the kernel stack.  It appears this was missed when
the thread structure was introduced.

The recent exit_mmap() changes broke PPC64 when 64-bit applications exec
32-bit ones.  ia32-on-ia64 was broken as well

What is happening is that load_elf_binary() sets TIF_32BIT (via
SET_PERSONALITY) _before_ running exit_mmap().  So when we're unmapping the
vma's of the old image, we are running under the new image's personality.

This causes PPC64 to pass a 32-bit TASK_SIZE to unmap_vmas(), even when the
execing process had a 64-bit image.  Because unmap_vmas() is not provided
with the correct virtual address span it does not unmap all the old image's
vma's and we go BUG_ON(mm->map_count) in exit_mmap().

The early SET_PERSONALITY() is required before we look up the interpreter
because the lookup of the executable has to happen under the alternate root
which SET_PERSONALITY() may set.

Unfortunately this means that we're running flush_old_exec() under the new
exec's personality.  Hence this bug.

So what the patch does is to simply pass ~0UL into unmap_vmas(), which tells
it to unmap everything regardless of current personality.  Which is what the
old open-coded VMA killer was doing.

There remains the problem that some architectures are sometimes passing the
incorrect TASK_SIZE into tlb_finish_mmu().  They've always been doing that.

We cannot clear VM_MAYWRITE in there - it turns writeable MAP_PRIVATE
mappings into readonly ones.

So change it back to the 2.4 form - disallow a writeable MAP_SHARED mapping
against filesystems which do not implement ->writepage().

Patch from: Petr Vandrovec <vandrove@vc.cvut.cz>

soundcore is trying to perform kernel syscalls to load firmware, but falls
afoul of missing `errno'.  Convert it to use VFS API functions.

redo_fd_request() needs to take the queue lock around the call to
elv_next_request().

Patch from "Andres Salomon" <dilinger@voxel.net>

Fix compilation of atyfb_base.c

__wait_on_buffer() needs to use io_schedule(), so processes in there are
accounted as being in I/O wait.

pcmcia timer initialisation fixes from Anton Blanchard

Patch from William Lee Irwin III <wli@holomorphy.com>

PAE's pte_none() and pte_pfn() evaluate their arguments twice;
analogous fixes have been made to other things; c.f. pgtable.h's long
list of one-line inlines with parentheses still around their args.

Patch from: Rusty Russell <rusty@rustcorp.com.au>

Mikael Pettersson points out that "-s" gets mangled to "_s" on the
kernel command line, even though it turns out not to be a
parameter.

Patch from William Lee Irwin III <wli@holomorphy.com>

pgd_index() doesn't parenthesize its argument.  This is a bad idea for
macros, since it's legitimate to pass expressions to them that will get
misinterpreted given operator precedence and the shift.

Patch from Rusty Russell <rusty@rustcorp.com.au>

Make symbol_get() use undefined weak symbols if !CONFIG_MODULE.
Many thanks to RTH for introducing undef weak symbols to me.

Patch from William Lee Irwin III <wli@holomorphy.com>

BLK_BOUNCE_HIGH and BLK_BOUNCE_ANY are compared against 64-bit quantities.
Cast these unsigned long quantities to avoid overflow.

Patch from Manfred Spraul <manfred@colorfullife.com>

cache_alloc_refill() forgets to disable interrupts again on an error path.
This exposes us to slab corruption and it makes slab debugging go BUG (it
expects local irqs to be disabled).

Patch from William Lee Irwin III <wli@holomorphy.com>

struct thread_info is shared with the stack, not struct task_struct.
False positives have been seen.

Random semicolon makes the whole thing a no-op.

It _did_ work.  I must have broken it between testing and sending :(