Re: [PATCH] unexport sg v3 helper functions
On Mon, Jul 23 2007, Douglas Gilbert wrote: > Jens Axboe wrote: > > On Sun, Jul 22 2007, FUJITA Tomonori wrote: > >> blk_fill_sghdr_rq, blk_unmap_sghdr_rq, and blk_complete_sghdr_rq were > >> exported for bsg, however bsg was changed to support only sg v4. > >> > >> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> > > > > Acked-by: Jens Axboe <[EMAIL PROTECTED]> > > Why? The reasoning is right there, a few lines up - bsg doesn't support sg v3 commands. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
From: "Moore, Eric" <[EMAIL PROTECTED]>
Subject: RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
Date: Mon, 23 Jul 2007 18:11:34 -0600
> Tomo - do you have any documentation on how to specify a bsg device?
Sorry, I don't. But it's not difficult.
With 2.6.23-rc1 + mptsas smp patch, you get directories /sys/class/bsg
like:
[EMAIL PROTECTED]:/sys/class/bsg$ ls
0:0:0:0 0:0:1:0 end_device-0:0 end_device-0:1 sas_host0
I don't have any expanders but if you have, you have a directory like
expander-0:1 under /sys/class/bsg.
I can run smp_rep_manufacturer against "invisible" SMP target in my
LSI SAS HBA like this:
nice:/home/fujita# ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/sas_host0
SAS-1.1 format: 0
vendor identification: LSI
product identification: Virtual SMP Port
product revision level:
Hopefully, you can do against expanders:
# ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/expander-0:1
I think that James tested this with aic94xx, however, I guess that
nobody has tested this with mptsas.
> I was trying to run the smp_rep_manufacture from sgv4_tools, and I
> got that error. Due to that, I have not able to test this patch.
What is the error message?
> However, here are some feedback with regards to the patch:
Thanks.
>
> On Sunday, July 08, 2007 9:52 PM, FUJITA Tomonori wrote:
>
> > +
> > +smpreq->RequestDataLength = req->data_len - 4;
>
> Our firmware formats the data in little endian, so you'll need to
> convert this inorder for it work under other endian formats, like sparc
> and ppc. So this code should be:
>
> smpreq->RequestDataLength = cpu_to_le16(req->data_len - 4);
I see. I'll fix it.
> > +smpreq->Function = MPI_FUNCTION_SMP_PASSTHROUGH;
> > +
> > + if (rphy)
> > + memcpy(&smpreq->SASAddress, &rphy->identify.sas_address,
> > + sizeof(smpreq->SASAddress));
>
> should be using cpu_to_le64 before the data is put into
> smpreq->SASAddress
Thanks, I will fix it.
> > + else {
> > + struct mptsas_portinfo *port_info;
> > +
> > + mutex_lock(&ioc->sas_topology_mutex);
> > + port_info = mptsas_find_portinfo_by_handle(ioc,
> > ioc->handle);
> > + if (port_info && port_info->phy_info)
> > + memcpy(&smpreq->SASAddress,
> > +
> > &(port_info->phy_info[0].phy->identify.sas_address),
> > + sizeof(smpreq->SASAddress));
> > + mutex_unlock(&ioc->sas_topology_mutex);
> > + }
>
> I'm not sure what the intent of this else case.
This code is for an "invisible" SMP target in LSI SAS HBAs. There are
better ways to get the target's address, I think. Any suggestions?
> I think it should be
> deleted, and replaced with a return of ENXIO.The sas_topology is a
> flat model, with the first object the intiatiator, and the other objects
> in the list are expanders.What your your attempting to obtain is the
> first port object connected to the initiator, which could be anything,
> for instance it could be an end device, instead of expander.So I
> think if your rphy object is not returning a valid sas_address, then
> return instead of attempting to find something from the sas_topology.
> I hope the API is making sure this is an expander before mptsas is even
> called, is that handled?
> > + /* a reply frame is expected */
> > + if (!(ioc->sas_mgmt.status & MPT_IOCTL_STATUS_RF_VALID)) {
> > + printk("%s: the smp response invalid!\n", __FUNCTION__);
> > + ret = -ENXIO;
> > + }
> > +
>
> I think in addition to having a valid reply, I think you should look at
> the iocstatus to insure the reply itself was successfull, and that there
> were no data underruns.
>
> ioc_status = le16_to_cpu(smpReply->IOCStatus) & MPI_IOCSTATUS_MASK;
> if ((ioc_status != MPI_IOCSTATUS_SUCCESS) &&
> (ioc_status != MPI_IOCSTATUS_SCSI_DATA_UNDERRUN)) {
> return -ENXIO;
> }
Yeah, I guess that it would be better to send mpt's smpReply to user
space then user-space tools can examine it. You know, That's what mpt
ioctl and Doug' smp_utils do. But we can't use the in-buffer for this
since it's used for the smp response. We could use sense buffer for
this.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unexport sg v3 helper functions
Jens Axboe wrote: > On Sun, Jul 22 2007, FUJITA Tomonori wrote: >> blk_fill_sghdr_rq, blk_unmap_sghdr_rq, and blk_complete_sghdr_rq were >> exported for bsg, however bsg was changed to support only sg v4. >> >> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> > > Acked-by: Jens Axboe <[EMAIL PROTECTED]> Why? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
From: James Bottomley <[EMAIL PROTECTED]>
Date: Mon, 23 Jul 2007 19:50:23 -0500
> On Mon, 2007-07-23 at 23:41 +0100, Mark Fortescue wrote:
> > For targets with a disk connected, I get scan responses of:
> > scsi scan: INQUIRY failed with code 0x802
> > after app 170ms.
>
> Thats SCSI status 0x02 (which is CHECK_CONDITION) and driver byte of
> 0x08, which is DRIVER_SENSE (as in the device returned a sense code).
> This is really strange, because the INQUIRY command isn't supposed to be
> allowed to return a sense code for precisely this initial scan reason.
> This tends to point to a device failure.
Devices return CHECK_CONDITION and give SENSE (usually a
UNIT_ATTENTION) when they are given an INQUIRY command too soon after
a scsi bus reset, I saw it all the time when bringing up the new ESP
driver.
There is even special case code in the SCSI bus scan that accepts
certain special cases of UNIT_ATTENTION check conditions as valid:
if (result) {
/*
* not-ready to ready transition [asc/ascq=0x28/0x0]
* or power-on, reset [asc/ascq=0x29/0x0], continue.
* INQUIRY should not yield UNIT_ATTENTION
* but many buggy devices do so anyway.
*/
if ((driver_byte(result) & DRIVER_SENSE) &&
scsi_sense_valid(&sshdr)) {
if ((sshdr.sense_key == UNIT_ATTENTION) &&
((sshdr.asc == 0x28) ||
(sshdr.asc == 0x29)) &&
(sshdr.ascq == 0))
continue;
}
}
asc/ascq values that do not pass this test are what Mark is seeing.
And again this is almost always because the device is being sent
the INQUIRY too soon after a scsi bus reset.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
On Mon, 2007-07-23 at 23:41 +0100, Mark Fortescue wrote: > Hi James, > > Can you point me in the direction of any documentation to aid me in > identifing what debugging I need to work out what is going on? they're all in include/scsi/scsi.h The code is divided into four bytes (from LSB): status, message, host and driver. The status is what the SCSI command actually returned (if anything) the message is what the transport said (least used of the status codes). The host byte signals an error condition with the card and the driver byte with the driver (plus an optional suggestion of what to do about it). > For targets without any connected disk, I get scan responses of: > scsi scan: INQUIRY failed with code 0x4 > after app 417ms. That's host byte 0x04 which is DID_BAD_TARGET. > For targets with a disk connected, I get scan responses of: > scsi scan: INQUIRY failed with code 0x802 > after app 170ms. Thats SCSI status 0x02 (which is CHECK_CONDITION) and driver byte of 0x08, which is DRIVER_SENSE (as in the device returned a sense code). This is really strange, because the INQUIRY command isn't supposed to be allowed to return a sense code for precisely this initial scan reason. This tends to point to a device failure. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
From: Mark Fortescue <[EMAIL PROTECTED]> Date: Mon, 23 Jul 2007 23:41:34 +0100 (BST) > I can also get the ESP driver to fail to find disks with the same error > codes if I build it as a module driver however if I build the ESP driver > into the kernel, it does not fail (ESP BUS_TIMEOUT=275). That's truly strange. For the qlogicpti.c driver case, try increasing qpti->host_param.bus_reset_delay. For the ESP failure as a module case, record and report the time that passes around the msleep() calls. If it's less than it's trying to delay, that's the bug. Your identify results are what I've seen when a device has recently reset and is not fully ready yet, indicating that the post-reset delay is not sufficient. I'm %99 sure it's yet another sparc32 specific kernel bug of some sort in both of these cases, especially since the qlogicpti.c driver hasn't changed substantially in many many years. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
Tomo - do you have any documentation on how to specify a bsg device? I
was trying to run the smp_rep_manufacture from sgv4_tools, and I got
that error. Due to that, I have not able to test this patch. However,
here are some feedback with regards to the patch:
On Sunday, July 08, 2007 9:52 PM, FUJITA Tomonori wrote:
> +
> +smpreq->RequestDataLength = req->data_len - 4;
Our firmware formats the data in little endian, so you'll need to
convert this inorder for it work under other endian formats, like sparc
and ppc. So this code should be:
smpreq->RequestDataLength = cpu_to_le16(req->data_len - 4);
> +smpreq->Function = MPI_FUNCTION_SMP_PASSTHROUGH;
> +
> + if (rphy)
> + memcpy(&smpreq->SASAddress, &rphy->identify.sas_address,
> +sizeof(smpreq->SASAddress));
should be using cpu_to_le64 before the data is put into
smpreq->SASAddress
> + else {
> + struct mptsas_portinfo *port_info;
> +
> + mutex_lock(&ioc->sas_topology_mutex);
> + port_info = mptsas_find_portinfo_by_handle(ioc,
> ioc->handle);
> + if (port_info && port_info->phy_info)
> + memcpy(&smpreq->SASAddress,
> +
> &(port_info->phy_info[0].phy->identify.sas_address),
> +sizeof(smpreq->SASAddress));
> + mutex_unlock(&ioc->sas_topology_mutex);
> + }
I'm not sure what the intent of this else case. I think it should be
deleted, and replaced with a return of ENXIO.The sas_topology is a
flat model, with the first object the intiatiator, and the other objects
in the list are expanders.What your your attempting to obtain is the
first port object connected to the initiator, which could be anything,
for instance it could be an end device, instead of expander.So I
think if your rphy object is not returning a valid sas_address, then
return instead of attempting to find something from the sas_topology.
I hope the API is making sure this is an expander before mptsas is even
called, is that handled?
> + /* a reply frame is expected */
> + if (!(ioc->sas_mgmt.status & MPT_IOCTL_STATUS_RF_VALID)) {
> + printk("%s: the smp response invalid!\n", __FUNCTION__);
> + ret = -ENXIO;
> + }
> +
I think in addition to having a valid reply, I think you should look at
the iocstatus to insure the reply itself was successfull, and that there
were no data underruns.
ioc_status = le16_to_cpu(smpReply->IOCStatus) & MPI_IOCSTATUS_MASK;
if ((ioc_status != MPI_IOCSTATUS_SUCCESS) &&
(ioc_status != MPI_IOCSTATUS_SCSI_DATA_UNDERRUN)) {
return -ENXIO;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
QLGC,ISP SCSI driver not finding attached devices
Hi James, Can you point me in the direction of any documentation to aid me in identifing what debugging I need to work out what is going on? For targets without any connected disk, I get scan responses of: scsi scan: INQUIRY failed with code 0x4 after app 417ms. For targets with a disk connected, I get scan responses of: scsi scan: INQUIRY failed with code 0x802 after app 170ms. Can you tell me how to decode the error codes? (The times are from the sun4c 1us counter14) I did get the driver to work on one occasion but I have not been able to repeat the achivement. I can also get the ESP driver to fail to find disks with the same error codes if I build it as a module driver however if I build the ESP driver into the kernel, it does not fail (ESP BUS_TIMEOUT=275). Regards Mark Fortescue. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC: 2.6 patch] nsp32_restart_autoscsi(): remove error check
The Coverity checker noted that we'll anyway Oops later when we ran into
this condition - and the error check didn't prevent that.
Considering that the error condition shouldn't be possible, and we are
not able to handle it easily, this patch simply removes the pointless
error check.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/nsp32.c |4
1 file changed, 4 deletions(-)
--- linux-2.6.22-rc6-mm1/drivers/scsi/nsp32.c.old 2007-07-23
19:38:58.0 +0200
+++ linux-2.6.22-rc6-mm1/drivers/scsi/nsp32.c 2007-07-23 20:17:14.0
+0200
@@ -1888,44 +1888,40 @@ static void nsp32_msgout_occur(struct sc
data->msgout_len = 0;
nsp32_dbg(NSP32_DEBUG_MSGOUTOCCUR, "exit");
}
/*
* Restart AutoSCSI
*
* Note: Restarting AutoSCSI needs set:
* SYNC_REG, ACK_WIDTH, SGT_ADR, TRANSFER_CONTROL
*/
static void nsp32_restart_autoscsi(struct scsi_cmnd *SCpnt, unsigned short
command)
{
nsp32_hw_data *data = (nsp32_hw_data *)SCpnt->device->host->hostdata;
unsigned int base = data->BaseAddress;
unsigned short transfer = 0;
nsp32_dbg(NSP32_DEBUG_RESTART, "enter");
- if (data->cur_target == NULL || data->cur_lunt == NULL) {
- nsp32_msg(KERN_ERR, "Target or Lun is invalid");
- }
-
/*
* set SYNC_REG
* Don't set BM_START_ADR before setting this register.
*/
nsp32_write1(base, SYNC_REG, data->cur_target->syncreg);
/*
* set ACKWIDTH
*/
nsp32_write1(base, ACK_WIDTH, data->cur_target->ackwidth);
/*
* set SREQ hazard killer sampling rate
*/
nsp32_write1(base, SREQ_SMPL_RATE, data->cur_target->sample_reg);
/*
* set SGT ADDR (physical address)
*/
nsp32_write4(base, SGT_ADR, data->cur_lunt->sglun_paddr);
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] drivers/scsi/scsi_sysfs.c:718: warning: unused variable `rq'
On Mon, 2007-07-23 at 16:36 +0200, Frederik Deweerdt wrote:
> - struct request_queue *rq = sdev->request_queue;
>
> if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
> return error;
> @@ -736,7 +735,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
>* released by the sdev_class .release */
> get_device(&sdev->sdev_gendev);
>
> - error = bsg_register_queue(rq, &sdev->sdev_gendev, NULL);
> + error = bsg_register_queue(sdev->request_queue,
> +&sdev->sdev_gendev, NULL);
Actually, that's not really a good fix because the same problem will
reoccur elsewhere. This is a more correct fix:
James
diff --git a/include/linux/bsg.h b/include/linux/bsg.h
index f415f89..2344dab 100644
--- a/include/linux/bsg.h
+++ b/include/linux/bsg.h
@@ -60,8 +60,13 @@ struct bsg_class_device {
extern int bsg_register_queue(struct request_queue *, struct device *, const
char *);
extern void bsg_unregister_queue(struct request_queue *);
#else
-#define bsg_register_queue(disk, dev, name)(0)
-#define bsg_unregister_queue(disk) do { } while (0)
+static inline int bsg_register_queue(struct request_queue * rq, struct device
*dev, const char *name)
+{
+ return 0;
+}
+static inline void bsg_unregister_queue(struct request_queue *rq)
+{
+}
#endif
#endif /* __KERNEL__ */
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] aacraid: sysfs adapter reset/status format change.
We need to newline terminate responses from nodes within the sysfs tree, the Adapter status value reported by the reset adapter node is adjusted. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/linit.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Sincerely -- Mark Salyzyn aacraid_adapter_status_format_change.patch Description: aacraid_adapter_status_format_change.patch
[PATCH] sgtable over sglist (Re: [RFC 4/8] scsi-ml: scsi_sgtable implementation)
From: Jens Axboe <[EMAIL PROTECTED]>
Subject: Re: [RFC 4/8] scsi-ml: scsi_sgtable implementation
Date: Wed, 18 Jul 2007 22:17:10 +0200
> On Wed, Jul 18 2007, Benny Halevy wrote:
> > Jens Axboe wrote:
> > > On Wed, Jul 18 2007, Boaz Harrosh wrote:
> > >> Jens Axboe wrote:
> > >>> On Wed, Jul 18 2007, Boaz Harrosh wrote:
> > FUJITA Tomonori wrote:
> > > From: Mike Christie <[EMAIL PROTECTED]>
> > > Subject: Re: [RFC 4/8] scsi-ml: scsi_sgtable implementation
> > > Date: Thu, 12 Jul 2007 14:09:44 -0500
> > >
> > >> Boaz Harrosh wrote:
> > >>> +/*
> > >>> + * Should fit within a single page.
> > >>> + */
> > >>> +enum { SCSI_MAX_SG_SEGMENTS =
> > >>> + ((PAGE_SIZE - sizeof(struct scsi_sgtable)) /
> > >>> + sizeof(struct scatterlist)) };
> > >>> +
> > >>> +enum { SG_MEMPOOL_NR =
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 7) +
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 15) +
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 31) +
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 63) +
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 127) +
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 255) +
> > >>> + (SCSI_MAX_SG_SEGMENTS >= 511)
> > >>> +};
> > >>>
> > >> What does SCSI_MAX_SG_SEGMENTS end up being on x86 now? On x86_64 or
> > >> some other arch, we were going over a page when doing
> > >> SCSI_MAX_PHYS_SEGMENTS of 256 right?
> > > Seems that 170 with x86 and 127 with x86_64.
> > >
> > with scsi_sgtable we get one less than now
> >
> > Arch | SCSI_MAX_SG_SEGMENTS = | sizeof(struct
> > scatterlist)
> > --|-|---
> > x86_64| 127 |32
> > i386 CONFIG_HIGHMEM64G=y | 204 |20
> > i386 other| 255 |16
> >
> > What's nice about this code is that now finally it is
> > automatically calculated in compile time. Arch people
> > don't have the headache "did I break SCSI-ml?".
> > For example observe the current bug with i386
> > CONFIG_HIGHMEM64G=y.
> >
> > The same should be done with BIO's. Than ARCHs with big
> > pages can gain even more.
> >
> > >> What happened to Jens's scatter list chaining and how does this
> > >> relate
> > >> to it then?
> > > With Jens' sglist, we can set SCSI_MAX_SG_SEGMENTS to whatever we
> > > want. We can remove the above code.
> > >
> > > We need to push this and Jens' sglist together in one merge window, I
> > > think.
> > No Tomo the above does not go away. What goes away is maybe:
> > >>> It does go away, since we can just set it to some safe value and use
> > >>> chaining to get us where we want.
> > >> In my patches SCSI_MAX_PHYS_SEGMENTS has went away it does not exist
> > >> anymore.
> > >
> > > Sure, I could just kill it as well. The point is that it's a parallel
> > > development, there's nothing in your patch that helps the sg chaining
> > > whatsoever. The only "complex" thing in the SCSI layer for sg chaining,
> > > is chaining when allocating and walking that chain on freeing. That's
> > > it!
> >
> > It seems like having the pool index in the sgtable structure simplifies
> > the implementation a bit for allocation and freeing of linked sgtables.
> > Boaz will send an example tomorrow (hopefully) showing how the merged
> > code looks like.
>
> The index stuff isn't complex, so I don't think you can call that a real
> simplification. It's not for free either, there's a size cost to pay.
I think that the main issue of integrating sgtable and sglist is how
to put scatterlist to scsi_sgtable structure.
If we allocate a scsi_sgtable structure and sglists separately, the
code is pretty simple. But probably it's not the best way from the
perspective of performance.
If we put sglists into the scsi_sgtable structure (like Boaz's patch
does) and allocate and chain sglists only for large I/Os, we would
have the better performance (especially for small I/Os). But we will
have more complicated code.
I wrote my sgtable patch over Jens' sglist with the former way:
master.kernel.org:/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git sgtable
I also put Boaz's scsi_error, sd, and sr sgtable patches into the tree
so you can try it. I've tested this with only normal size I/Os (not
tested sglist code). I don't touch the sglist code much, so hopefully
it works.
I've attached the sgtable patch for review. It's against the
sglist-arch branch in Jens' tree.
---
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] move all the I/O descriptors to a new scsi_sgtable structure
based on Boaz Harrosh <[EMAIL PROTECTED]> scsi_sgtable patch.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c | 92 +++--
include/scsi/scsi_cmnd.h | 39 +
RE: [PATCH] aacraid: Resend, Fix security hole
ACK.
Unit tested with Adaptec RAID management applications with apparently no
issue. Will push this into matrix testing in the coming week.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Cox
> Sent: Monday, July 23, 2007 9:51 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> linux-scsi@vger.kernel.org
> Subject: [PATCH] aacraid: Resend, Fix security hole
>
> On the SCSI layer ioctl path there is no implicit permissions
> check for
> ioctls (and indeed other drivers implement unprivileged
> ioctls). aacraid
> however allows all sorts of very admin only things to be done
> so should
> check.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> diff -u --new-file --recursive --exclude-from
> /usr/src/exclude
> linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c
> linux-2.6.23rc1/drivers/scsi/aacraid/linit.c
> --- linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c
> 2007-07-23 12:56:12.0 +0100
> +++ linux-2.6.23rc1/drivers/scsi/aacraid/linit.c
> 2007-07-23 12:57:45.0 +0100
> @@ -636,6 +636,8 @@
> static int aac_cfg_ioctl(struct inode *inode, struct file *file,
> unsigned int cmd, unsigned long arg)
> {
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> return aac_do_ioctl(file->private_data, cmd, (void
> __user *)arg);
> }
>
> @@ -689,6 +691,8 @@
>
> static long aac_compat_cfg_ioctl(struct file *file, unsigned
> cmd, unsigned long arg)
> {
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> return aac_compat_do_ioctl((struct aac_dev
> *)file->private_data, cmd, arg);
> }
> #endif
> -
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] aacraid: Resend, Fix security hole
On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c
linux-2.6.23rc1/drivers/scsi/aacraid/linit.c
--- linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c2007-07-23
12:56:12.0 +0100
+++ linux-2.6.23rc1/drivers/scsi/aacraid/linit.c2007-07-23
12:57:45.0 +0100
@@ -636,6 +636,8 @@
static int aac_cfg_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
return aac_do_ioctl(file->private_data, cmd, (void __user *)arg);
}
@@ -689,6 +691,8 @@
static long aac_compat_cfg_ioctl(struct file *file, unsigned cmd, unsigned
long arg)
{
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
return aac_compat_do_ioctl((struct aac_dev *)file->private_data, cmd,
arg);
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/message/fusion/mptscsih.c: inconsequent NULL checking
The Coverity checker spotted the following inconsequent NULL checking in
drivers/message/fusion/mptscsih.c:
<-- snip -->
...
int
mptscsih_qcmd(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_cmnd *))
{
...
if (vdev
&& (vdev->vtarget->tflags & MPT_TARGET_FLAGS_Q_YES)
&& (SCpnt->device->tagged_supported)) {
scsictl = scsidir | MPI_SCSIIO_CONTROL_SIMPLEQ;
} else {
scsictl = scsidir | MPI_SCSIIO_CONTROL_UNTAGGED;
}
/* Use the above information to set up the message frame
*/
pScsiReq->TargetID = (u8) vdev->vtarget->id;
...
<-- snip -->
"vdev" is first checked but later dereferenced unconditionally.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unexport sg v3 helper functions
On Sun, Jul 22 2007, FUJITA Tomonori wrote: > blk_fill_sghdr_rq, blk_unmap_sghdr_rq, and blk_complete_sghdr_rq were > exported for bsg, however bsg was changed to support only sg v4. > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> Acked-by: Jens Axboe <[EMAIL PROTECTED]> -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/2] 2.6.23-rc1: known regressions
Hi all, Here is a list of some known regressions in 2.6.23-rc1. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Andi Kleen 4 Linus Torvalds 4 Adrian Bunk3 Andrew Morton 3 Jens Axboe 3 Al Viro2 David Woodhouse2 Hugh Dickins 2 Tejun Heo 2 SCSI Subject : lpfc_sli.c: off-by-10 References : http://lkml.org/lkml/2007/7/22/284 Last known good : ? Submitter : Adrian Bunk <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown Virtualization Subject : 2.6.22-git17 boot failure (XEN) References : http://lkml.org/lkml/2007/7/22/266 Last known good : ? Submitter : Tilman Schmidt <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown Subject : drivers/net/xen-netfront.c: bogus code References : http://lkml.org/lkml/2007/7/22/256 Last known good : ? Submitter : Adrian Bunk <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Jeremy Fitzhardinge <[EMAIL PROTECTED]> Status : unknown IA64 Subject : Regression in serial console on ia64 after 2.6.22 References : http://marc.info/?l=linux-ia64&m=118483645914066&w=2 Last known good : ? Submitter : Horms <[EMAIL PROTECTED]> Caused-By : Yinghai Lu <[EMAIL PROTECTED]> commit 18a8bd949d6adb311ea816125ff65050df1f3f6e Handled-By : ? Status : unknown Sparc64 Subject : "build-id" changes break sparc64 References : http://lkml.org/lkml/2007/7/22/38 Last known good : ? Submitter : David Miller <[EMAIL PROTECTED]> Caused-By : Roland McGrath <[EMAIL PROTECTED]> commit 18991197b4b588255ccabf472ebc84db7b66a19c Handled-By : ? Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable 16-bit CDBs for aic7xxx/aic79xxx
Hannes Reinecke wrote: > Hi James, > > this patch enables 16-bit CDBs for aic7xxx and aic79xx. aic7xxx actuallys > supports up to 32-bit CDBs, so it might be that aic79xx does that, too. > But this would include some more hacking, so this is way easier. > Yeah, grand. That should read '16-byte CDBs', of course. But at least I've been consistent :-) New patch attached. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) Enable 16-byte CDBs for aic7xxx/aix79xx The patch enables support for 16-byte CDBs in aic7xxx and aic79xx. aic7xxx can actually support up to 32-byte CDBs, should they ever see the light of day. Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 286ab83..8502085 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -1089,6 +1089,7 @@ ahd_linux_register_host(struct ahd_softc *ahd, struct scsi_host_template *templa host->max_id = (ahd->features & AHD_WIDE) ? 16 : 8; host->max_lun = AHD_NUM_LUNS; host->max_channel = 0; + host->max_cmd_len = MAX_CDB_LEN; host->sg_tablesize = AHD_NSEG; ahd_lock(ahd, &s); ahd_set_unit(ahd, ahd_linux_unit++); diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c index 1803ab6..a6b3071 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_osm.c +++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c @@ -1047,6 +1047,7 @@ ahc_linux_register_host(struct ahc_softc *ahc, struct scsi_host_template *templa host->max_id = (ahc->features & AHC_WIDE) ? 16 : 8; host->max_lun = AHC_NUM_LUNS; host->max_channel = (ahc->features & AHC_TWIN) ? 1 : 0; + host->max_cmd_len = 32; host->sg_tablesize = AHC_NSEG; ahc_lock(ahc, &s); ahc_set_unit(ahc, ahc_linux_unit++);
[PATCH] Enable 16-bit CDBs for aic7xxx/aic79xxx
Hi James, this patch enables 16-bit CDBs for aic7xxx and aic79xx. aic7xxx actuallys supports up to 32-bit CDBs, so it might be that aic79xx does that, too. But this would include some more hacking, so this is way easier. Please apply. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) Enable 16-bit CDBs for aic7xxx/aix79xx The patch enables support for 16-bit CDBs in aic7xxx and aic79xx. aic7xxx can actually support up to 32-bit CDBs, should they ever see the light of day. Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 286ab83..8502085 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -1089,6 +1089,7 @@ ahd_linux_register_host(struct ahd_softc *ahd, struct scsi_host_template *templa host->max_id = (ahd->features & AHD_WIDE) ? 16 : 8; host->max_lun = AHD_NUM_LUNS; host->max_channel = 0; + host->max_cmd_len = MAX_CDB_LEN; host->sg_tablesize = AHD_NSEG; ahd_lock(ahd, &s); ahd_set_unit(ahd, ahd_linux_unit++); diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c index 1803ab6..a6b3071 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_osm.c +++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c @@ -1047,6 +1047,7 @@ ahc_linux_register_host(struct ahc_softc *ahc, struct scsi_host_template *templa host->max_id = (ahc->features & AHC_WIDE) ? 16 : 8; host->max_lun = AHC_NUM_LUNS; host->max_channel = (ahc->features & AHC_TWIN) ? 1 : 0; + host->max_cmd_len = 32; host->sg_tablesize = AHC_NSEG; ahc_lock(ahc, &s); ahc_set_unit(ahc, ahc_linux_unit++);
