linux-toradex.git/drivers/block, branch v2.6.27.62

block: add and use scsi_blk_cmd_ioctl

2012-02-11T14:40:54+00:00

commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backport to 2.6.32 - adjust context]
Signed-off-by: Ben Hutchings 
[wt: slightly changed the interface to match 2.6.27's scsi_cmd_ioctl()
     which still needs the file pointer but has no mode parameter].

Signed-off-by: Willy Tarreau

cciss: fix lost command issue

2011-04-30T14:53:24+00:00

commit 1ddd5049545e0aa1a0ed19bca4d9c9c3ce1ac8a2 upstream.

Under certain workloads a command may seem to get lost. IOW, the Smart Array
thinks all commands have been completed but we still have commands in our
completion queue. This may lead to system instability, filesystems going
read-only, or even panics depending on the affected filesystem. We add an
extra read to force the write to complete.

Testing shows this extra read avoids the problem.

Signed-off-by: Mike Miller 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Fix pktcdvd ioctl dev_minor range check

2011-04-30T14:53:03+00:00

commit 252a52aa4fa22a668f019e55b3aac3ff71ec1c29 upstream.

The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a
pktcdvd_device from the global pkt_devs array.  The index into this
array is provided directly by the user and is a signed integer, so the
comparison to ensure that it falls within the bounds of this array will
fail when provided with a negative index.

This can be used to read arbitrary kernel memory or cause a crash due to
an invalid pointer dereference.  This can be exploited by users with
permission to open /dev/pktcdvd/control (on many distributions, this is
readable by group "cdrom").

Signed-off-by: Dan Rosenberg 
[ Rather than add a cast, just make the function take the right type -Linus ]
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

floppy: fix lock imbalance

2009-07-20T03:45:00+00:00

commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream.

A crappy macro prevents us unlocking on a fail path.

Expand the macro and unlock appropriatelly.

Signed-off-by: Jiri Slaby 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

floppy: request and release only the ports we actually use

2009-07-02T23:31:45+00:00

commit 5a74db06cc8d36a325913aa4968ae169f997a466 upstream.

The floppy driver requests an I/O port it doesn't need, and sometimes this
causes a conflict with a motherboard device reported by PNPBIOS.

This patch makes the floppy driver request and release only the ports it
actually uses.  It also factors out the request/release stuff and the
io-ports list so they're all in one place now.

The current floppy driver uses only these ports:

    0x3f2 (FD_DOR)
    0x3f4 (FD_STATUS)
    0x3f5 (FD_DATA)
    0x3f7 (FD_DCR/FD_DIR)

but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port
0x3f3.

Some BIOSes report 0x3f3 as a motherboard resource.  The PNP system driver
reserves that, which causes a conflict when the floppy driver requests
0x3f2-0x3f5 later.

Philippe reported that this conflict broke the floppy driver between
2.6.11 and 2.6.22.  His PNPBIOS reports these devices:

    $ cat 00:07/id 00:07/resources	# motherboard device
    PNP0c02
    state = active
    io 0x80-0x80
    io 0x10-0x1f
    io 0x22-0x3f
    io 0x44-0x5f
    io 0x90-0x9f
    io 0xa2-0xbf
    io 0x3f0-0x3f1
    io 0x3f3-0x3f3

    $ cat 00:03/id 00:03/resources	# floppy device
    PNP0700
    state = active
    io 0x3f4-0x3f5
    io 0x3f2-0x3f2

Reference:
    http://lkml.org/lkml/2009/1/31/162

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Philippe De Muyter 
Reported-by: Philippe De Muyter 
Tested-by: Philippe De Muyter 
Cc: Adam M Belay 
Cc: Robert Hancock 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

floppy: provide a PNP device table in the module.

2009-07-02T23:31:44+00:00

commit 83f9ef463bcb4ba7b4fee1d6212fac7d277010d3 upstream.

The missing device table means that the floppy module is not auto-loaded,
even when the appropriate PNP device (0700) is found.

We don't actually use the table in the module, since the device doesn't
have a struct pnp_driver, but it's sufficient to cause an alias in the
module that udev/modprobe will use.

Signed-off-by: Scott James Remnant 
Signed-off-by: Tim Gardner 
Cc: Bjorn Helgaas 
Cc: Philippe De Muyter 
Acked-by: Kay Sievers 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xen/blkfront: use blk_rq_map_sg to generate ring entries

2009-03-17T00:53:01+00:00

commit 9e973e64ac6dc504e6447d52193d4fff1a670156 upstream.

On occasion, the request will apparently have more segments than we
fit into the ring. Jens says:

> The second problem is that the block layer then appears to create one
> too many segments, but from the dump it has rq->nr_phys_segments ==
> BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
> xen-blkfront not handling the merging on its own. It should check that
> the new page doesn't form part of the previous page. The
> rq_for_each_segment() iterates all single bits in the request, not dma
> segments. The "easiest" way to do this is to call blk_rq_map_sg() and
> then iterate the mapped sg list. That will give you what you are
> looking for.

> Here's a test patch, compiles but otherwise untested. I spent more
> time figuring out how to enable XEN than to code it up, so YMMV!
> Probably the sg list wants to be put inside the ring and only
> initialized on allocation, then you can get rid of the sg on stack and
> sg_init_table() loop call in the function. I'll leave that, and the
> testing, to you.

[Moved sg array into info structure, and initialize once. -J]

Signed-off-by: Jens Axboe 
Signed-off-by: Jeremy Fitzhardinge 
Cc: Sven Köhler 
Signed-off-by: Greg Kroah-Hartman

aoe: ignore vendor extension AoE responses

2009-03-17T00:52:43+00:00

commit b6d6c5175809934e04a606d9193ef04924a7a7d9 upstream.

The Welland ME-747K-SI AoE target generates unsolicited AoE responses that
are marked as vendor extensions.  Instead of ignoring these packets, the
aoe driver was generating kernel messages for each unrecognized response
received.  This patch corrects the behavior.

Signed-off-by: Ed Cashin 
Reported-by: 
Tested-by: 
Cc: Alex Buell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nbd: fix I/O hang on disconnected nbds

2009-02-17T17:46:15+00:00

commit 4d48a542b42747c36a5937447d9c3de7c897ea50 upstream.

Fix a problem that causes I/O to a disconnected (or partially initialized)
nbd device to hang indefinitely.  To reproduce:

# ioctl NBD_SET_SIZE_BLOCKS /dev/nbd23 514048
# dd if=/dev/nbd23 of=/dev/null bs=4096 count=1

...hangs...

This can also occur when an nbd device loses its nbd-client/server
connection.  Although we clear the queue of any outstanding I/Os after the
client/server connection fails, any additional I/Os that get queued later
will hang.

This bug may also be the problem reported in this bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=12277

Testing would need to be performed to determine if the two issues are the
same.

This problem was introduced by the new request handling thread code ("NBD:
allow nbd to be used locally", 3/2008), which entered into mainline around
2.6.25.

The fix, which is fairly simple, is to restore the check for lo->sock
being NULL in do_nbd_request.  This causes I/O to an uninitialized nbd to
immediately fail with an I/O error, as it did prior to the introduction of
this bug.

Signed-off-by: Paul Clements 
Reported-by: Jon Nelson 
Acked-by: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cciss: fix problem that deleting multiple logical drives could cause a panic

2009-01-14T17:44:06+00:00

commit d8a0be6ab7ba1ffa43e7ea0dcdde3e8b68d4f762 upstream.

Fix problem that deleting multiple logical drives could cause a panic.

It fixes a panic which can be easily reproduced in the following way: Just
create several "arrays," each with multiple logical drives via hpacucli,
then delete the first array, and it will blow up in deregister_disk(), in
the call to get_host() when it tries to dig the hba pointer out of a NULL
queue pointer.

The problem has been present since my code to make rebuild_lun_table
behave better went in.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman