[PATCH] [SCSI] mpt3sas: don't leak 'fw_event' in mpt3sas_send_trigger_data_event()
If we successfully allocate 'fw_event' but subsequently fail to
allocate 'fw_event-event_data' then we'll return from the function
without properly freeing 'fw_event'.
This patch takes care of that leak.
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index a961fe1..e90fbf3 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2518,8 +2518,10 @@ mpt3sas_send_trigger_data_event(struct MPT3SAS_ADAPTER
*ioc,
if (!fw_event)
return;
fw_event-event_data = kzalloc(sizeof(*event_data), GFP_ATOMIC);
- if (!fw_event-event_data)
+ if (!fw_event-event_data) {
+ kfree(fw_event);
return;
+ }
fw_event-event = MPT3SAS_PROCESS_TRIGGER_DIAG;
fw_event-ioc = ioc;
memcpy(fw_event-event_data, event_data, sizeof(*event_data));
--
1.7.1
--
Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [SCSI] mpt3sas: remove pointless version.h include from mpt3sas_trigger_diag.c
The file uses nothing from the header, so remove it. Signed-off-by: Jesper Juhl j...@chaosbits.net --- drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c b/drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c index da6c5f2..6f8d621 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c +++ b/drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c @@ -42,7 +42,6 @@ * USA. */ -#include linux/version.h #include linux/kernel.h #include linux/module.h #include linux/errno.h -- 1.7.1 -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [SCSI] csiostor: Don't leak mem or fail to release firmware in csio_hw_flash_config()
If kzalloc() or csio_hw_check_fwconfig() fail we may leave the
csio_hw_flash_config() function without freeing allocated memory or
firmware. This should take care of the leaks.
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
drivers/scsi/csiostor/csio_hw.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
Note: I'm unable to really test this, so the patch is compile tested
only.
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index 8ecdb94..bdd78fb 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -2131,13 +2131,16 @@ csio_hw_flash_config(struct csio_hw *hw, u32
*fw_cfg_param, char *path)
value_to_add = 4 - (cf-size % 4);
cfg_data = kzalloc(cf-size+value_to_add, GFP_KERNEL);
- if (cfg_data == NULL)
- return -ENOMEM;
+ if (cfg_data == NULL) {
+ ret = -ENOMEM;
+ goto leave;
+ }
memcpy((void *)cfg_data, (const void *)cf-data, cf-size);
-
- if (csio_hw_check_fwconfig(hw, fw_cfg_param) != 0)
- return -EINVAL;
+ if (csio_hw_check_fwconfig(hw, fw_cfg_param) != 0) {
+ ret = -EINVAL;
+ goto leave;
+ }
mtype = FW_PARAMS_PARAM_Y_GET(*fw_cfg_param);
maddr = FW_PARAMS_PARAM_Z_GET(*fw_cfg_param) 16;
@@ -2149,9 +2152,9 @@ csio_hw_flash_config(struct csio_hw *hw, u32
*fw_cfg_param, char *path)
strncpy(path, /lib/firmware/ CSIO_CF_FNAME, 64);
}
+leave:
kfree(cfg_data);
release_firmware(cf);
-
return ret;
}
--
1.7.1
--
Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix problem with size of allocation in libsas
From: Jesper Juhl [EMAIL PROTECTED] in sas_get_phy_change_count(), the line disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); will allocate 56 bytes due to this define: #define DISCOVER_RESP_SIZE 56 But, the struct is actually 60 bytes in size. So change the define to be #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) so we always get the correct size even when people fiddle with the structure. This change also fixes the same problem in sas_get_phy_attached_sas_addr() (Found by the Coverity checker. Compile tested only) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- sas_expander.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c index 8727436..a666cb1 100644 --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -211,7 +211,7 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id, } #define DISCOVER_REQ_SIZE 16 -#define DISCOVER_RESP_SIZE 56 +#define DISCOVER_RESP_SIZE sizeof(struct smp_resp) static int sas_ex_phy_discover_helper(struct domain_device *dev, u8 *disc_req, u8 *disc_resp, int single) - 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] Fix problem with size of allocation in libsas
On 12/11/2007, James Bottomley [EMAIL PROTECTED] wrote: On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: From: Jesper Juhl [EMAIL PROTECTED] in sas_get_phy_change_count(), the line disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); will allocate 56 bytes due to this define: #define DISCOVER_RESP_SIZE 56 But, the struct is actually 60 bytes in size. So change the define to be #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) so we always get the correct size even when people fiddle with the structure. This change also fixes the same problem in sas_get_phy_attached_sas_addr() (Found by the Coverity checker. Compile tested only) Well, your fix is definitely wrong. Could you explain the problem a little more? The discover response SMP frame is 56 bytes as mandated by the standard. I don't see anywhere in the code where we're actually using a value beyond the 56th byte ... where is the problem use? I haven't found any actual problem *use*, I just looked at the size of 'struct smp_resp' and noticed that coverity seemed to be right that 56 bytes are not sufficient to hold the members of the struct. There are 32 bytes in the first members + the union and I don't see how that can ever stay at 56 bytes...? So, we are allocating memory and storing it in a 'struct smp_resp *', but we are allocating less than sizeof(smp_resp) - how is that not a (potential) problem? -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Fix problem with size of allocation in libsas
On 12/11/2007, James Bottomley [EMAIL PROTECTED] wrote: On Mon, 2007-11-12 at 01:13 +0100, Jesper Juhl wrote: On 12/11/2007, James Bottomley [EMAIL PROTECTED] wrote: On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: From: Jesper Juhl [EMAIL PROTECTED] in sas_get_phy_change_count(), the line disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); will allocate 56 bytes due to this define: #define DISCOVER_RESP_SIZE 56 But, the struct is actually 60 bytes in size. So change the define to be #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) so we always get the correct size even when people fiddle with the structure. This change also fixes the same problem in sas_get_phy_attached_sas_addr() (Found by the Coverity checker. Compile tested only) Well, your fix is definitely wrong. Could you explain the problem a little more? The discover response SMP frame is 56 bytes as mandated by the standard. I don't see anywhere in the code where we're actually using a value beyond the 56th byte ... where is the problem use? I haven't found any actual problem *use*, I just looked at the size of 'struct smp_resp' and noticed that coverity seemed to be right that 56 bytes are not sufficient to hold the members of the struct. There are 11 current (well, as of the 1.1 standard) SMP frame responses. Each of them is actually a different length. This driver treats SMP frame response underruns as errors, so the fix you propose would cause the whole discovery process to collapse. There are 32 bytes in the first members + the union and I don't see how that can ever stay at 56 bytes...? So, we are allocating memory and storing it in a 'struct smp_resp *', but we are allocating less than sizeof(smp_resp) - how is that not a (potential) problem? We're not storing anything. We're allocating a byte area for the driver to deposit a response frame, we know we just sent a SMP DISCOVER request, so we'd better get a discover response back (and the driver will error on underrun or overrun, so we know if it returns successfully that's exatly what we have). The struct smp_resp contains the SMP invariant header and then a union of all the other response data types, so as long as we use either the header or the disc piece of the union, there's no possibility of error, is there? No, as long as the driver will err on underrun and overrun (of 56 bytes) and we only use those parts of the structure that lie within the first 56 bytes, then I don't see how it could fail. But it still makes the hairs on the back of my head stand on end to see memory allocated, and pointed to by a struct foo *, that is less than sizeof(struct foo)... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 08/17] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
On 05/10/2007, James Bottomley [EMAIL PROTECTED] wrote: On Tue, 2007-10-02 at 14:38 -0700, [EMAIL PROTECTED] wrote: From: Jesper Juhl [EMAIL PROTECTED] The Coverity checker noticed that we have a potential NULL pointer deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register(). This patch handles it by adding the same test against NULL that is used elsewhere in the same function. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] No. Reasons formerly given here: http://marc.info/?l=linux-scsim=118632919511846w=2 The reasons that patch sticks around was given by Andrew in a mail send to me, you and Justin Gibbs on Aug 8. My reply to that mail (including Andrew's original) is below, but you should be able to also find it in your own archives. Basically Andrew said: That's the sort of patch I keep around to prevent the issue from getting swept under the table. This usually results in me sitting on the sorry thing for literally years :( ---[ quote from old email - start ]--- from Jesper Juhl [EMAIL PROTECTED] to Andrew Morton [EMAIL PROTECTED] cc James Bottomley [EMAIL PROTECTED], Justin T. Gibbs [EMAIL PROTECTED] date8 Aug 2007 00:43 subject Re: + avoid-a-small-unlikely-memory-leak-in-proc_read_escd.patch added to -mm tree mailed-by gmail.com On 08/08/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 8 Aug 2007 00:26:43 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: This reply was meant for The patch titled Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function has been added to the -mm tree. Its filename is fix-a-potential-null-pointer-deref-in-the-aic7xxx-ahc_print_register-function.patch That's the sort of patch I keep around to prevent the issue from getting swept under the table. This usually results in me sitting on the sorry thing for literally years :( Ok, in that case you may want to keep it around in -mm despite James' objections - I'll leave that up to you. But it probably shouldn't move towards mainline... Feel free to send a replacement patch which gets us closer to the real fix. Remove all the NULL tests, maybe. I don't have a good idea on how to solve this better at the moment. But if I come up with something I'll be sure to send it to you and James. ---[ quote from old email - end ]--- -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 -mm] IPS SCSI driver: Check return of scsi_add_host()
On Sunday 02 September 2007 22:13:49 Satyam Sharma wrote: drivers/scsi/ips.c: In function ‘ips_register_scsi’: drivers/scsi/ips.c:6869: warning: ignoring return value of ‘scsi_add_host’, declared with attribute warn_unused_result scsi_add_host() is __must_check, so let's check it's return and cleanup appropriately on errors. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] [snip] Something seems to be wrong either at your end or mine + IPS_PRINTK(KERN_WARNING, ha-pcidev, Unable to add SCSI host¥n); This should end with a newline \n but I'm seeing ¥n ... /Jesper - 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 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
On 24/08/07, Rolf Eike Beer [EMAIL PROTECTED] wrote:
Jesper Juhl wrote:
[kv]alloc() return void *. No need to cast the return value.
@@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
write_lock(os_scsi_tapes_lock);
if (os_scsi_tapes == NULL) {
os_scsi_tapes =
- (struct osst_tape **)kmalloc(osst_max_dev *
sizeof(struct osst_tape *),
+ kmalloc(osst_max_dev * sizeof(struct osst_tape *),
GFP_ATOMIC);
if (os_scsi_tapes == NULL) {
write_unlock(os_scsi_tapes_lock);
Three lines later:
for (i=0; i osst_max_dev; ++i) os_scsi_tapes[i] = NULL;
This wants to be
os_scsi_tapes = kcalloc(osst_max_dev, sizeof(struct osst_tape *), GFP_ATOMIC);
Thank you for pointing that out.
I plan to resend those patches that don't get picked up in about a
week or so. I'll address this issue then (or if it does get picked up
in its current form I'll submit a follow-on patch to address this).
Eike
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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 20/30] scsi: In the Advansys driver, do not cast allocation function return values
On 24/08/07, Matthew Wilcox [EMAIL PROTECTED] wrote: On Fri, Aug 24, 2007 at 02:16:12AM +0200, Jesper Juhl wrote: There's no reason to cast void pointers returned by the generic memory allocation functions. I think I fixed all these already; please check scsi-misc. I just checked out the latest scsi-misc-2.6 tree and it does indeed look like these have already been dealt with. Sorry about the noise. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
[kv]alloc() return void *. No need to cast the return value.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/osst.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index 08060fb..3ad9d49 100644
--- a/drivers/scsi/osst.c
+++ b/drivers/scsi/osst.c
@@ -1404,7 +1404,7 @@ static int osst_read_back_buffer_and_rewrite(struct
osst_tape * STp, struct osst
int dbg = debugging;
#endif
- if ((buffer = (unsigned char *)vmalloc((nframes + 1) * OS_DATA_SIZE))
== NULL)
+ if ((buffer = vmalloc((nframes + 1) * OS_DATA_SIZE)) == NULL)
return (-EIO);
printk(KERN_INFO %s:I: Reading back %d frames from drive buffer%s\n,
@@ -2216,7 +2216,7 @@ static int osst_write_header(struct osst_tape * STp,
struct osst_request ** aSRp
if (STp-raw) return 0;
if (STp-header_cache == NULL) {
- if ((STp-header_cache = (os_header_t
*)vmalloc(sizeof(os_header_t))) == NULL) {
+ if ((STp-header_cache = vmalloc(sizeof(os_header_t))) == NULL)
{
printk(KERN_ERR %s:E: Failed to allocate header
cache\n, name);
return (-ENOMEM);
}
@@ -2404,7 +2404,7 @@ static int __osst_analyze_headers(struct osst_tape * STp,
struct osst_request **
name, ppos, update_frame_cntr);
#endif
if (STp-header_cache == NULL) {
- if ((STp-header_cache = (os_header_t
*)vmalloc(sizeof(os_header_t))) == NULL) {
+ if ((STp-header_cache = vmalloc(sizeof(os_header_t)))
== NULL) {
printk(KERN_ERR %s:E: Failed to allocate
header cache\n, name);
return 0;
}
@@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
write_lock(os_scsi_tapes_lock);
if (os_scsi_tapes == NULL) {
os_scsi_tapes =
- (struct osst_tape **)kmalloc(osst_max_dev *
sizeof(struct osst_tape *),
+ kmalloc(osst_max_dev * sizeof(struct osst_tape *),
GFP_ATOMIC);
if (os_scsi_tapes == NULL) {
write_unlock(os_scsi_tapes_lock);
--
1.5.2.2
-
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 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array
On 13/08/07, James Smart [EMAIL PROTECTED] wrote: NACK The fix is contained in our 8.2.2 sources recently posted and pushed by James as part of his last scsi fixes. I actually did look for it, but couldn't find any lpfc commits with me listed as author, so I assumed it had not been merged. I just looked again, at the source this time, up-to-date mainline git tree, and I still see hbqno = tag 16; if (hbqno LPFC_MAX_HBQS) return NULL; in drivers/scsi/lpfc/lpfc_sli.c ??? -- james s Jesper Juhl wrote: (previously send on 09-Aug-2007 20:47) Hi, The Coverity checker noticed that we may overrun a statically allocated array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find(). ... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array
On 13/08/07, James Smart [EMAIL PROTECTED] wrote: Ok here's what happened, - We changed the define so that it matched what we are using. We never configure more than 4 HBQ, thus the index will never be beyond 0-3. The if-check is actually innoculous. Given that the change wasn't your patch, we didn't include you as the author. And that's not a problem. I only mentioned it to explain how I searched for the patch before I resend it. - Coding-wise, you are right, we still didn't fix the range check. Since this really is just something to keep the tools happy - I'll recind the NACK. I'll worry about simply removing this if-check later... James/Andrew, accept this patch - ACK. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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: Unexpected busfree in Message-in phase
On 13/08/07, Michal Piotrowski [EMAIL PROTECTED] wrote: Hi Jesper, On 11/08/07, Jesper Juhl [EMAIL PROTECTED] wrote: Hi, I just noticed this in dmesg : [ 3216.262987] (scsi0:A:4:0): Unexpected busfree in Message-in phase [ 3216.263058] SEQADDR == 0x16c [ 3216.263724] target0:0:4: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 16) That's all there is in addition to the normal bootup messages, just those 3 lines. The machine is doing fine at the moment, no ill effects so far, but an explanation of what exactely could be causing that and whether or not it is a (fixable) problem would be very nice :-) Some details : $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST Is this a regression? I do not have this commit Hmm, neither do I, it must be from a build from one of my local branches (unfortunately it seems like it's one I don't have around any more). Ok, so I guess I'll have to try and see if it happens again with a new build - although I doubt that it's something that was caused by one of my own patches since I've not been doing anything to the aic7xxx driver lately beyond pretty trivial stuff, but I guess I can't rule it out. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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: Build failure in advansys driver - error: implicit declaration of function 'to_pci_dev'
On 12/08/07, Matthew Wilcox [EMAIL PROTECTED] wrote: On Sun, Aug 12, 2007 at 01:43:16AM +0200, Jesper Juhl wrote: Trying to build current Linus git tree (head at ac07860264bd2b18834d3fa3be47032115524cea) using the attached config file (generated by 'make randconfig') the build fails for me with : ... CC drivers/scsi/advansys.o drivers/scsi/advansys.c:794:2: warning: #warning this driver is still not properly converted to the DMA API drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' I'm sorry that linux-scsi is a write-only list for you, but this error has been reported at least twice already, and a more polite response was received by each of those reporters. I know I should have searched the archives, but it was late at night and I just wanted to get the problem reported so I didn't forget about it, so I didn't. Better it gets reported a few times than not at all... Next time I'll just leave it for the next day to do the archive search and hope I don't forget about it. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array
(previously send on 09-Aug-2007 20:47)
Hi,
The Coverity checker noticed that we may overrun a statically allocated
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
The case is this; In 'struct lpfc_hba' we have
#define LPFC_MAX_HBQS 4
...
struct lpfc_hba {
...
struct hbq_s hbqs[LPFC_MAX_HBQS];
...
};
But then in lpfc_sli_hbqbuf_find() we have this code
hbqno = tag 16;
if (hbqno LPFC_MAX_HBQS)
return NULL;
if 'hbqno' ends up as exactely 4, then we won't return, and then this
list_for_each_entry(d_buf, phba-hbqs[hbqno].hbq_buffer_list, list) {
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno LPFC_MAX_HBQS'
into 'hbqno = LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Acked-by: James Smart [EMAIL PROTECTED]
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
uint32_t hbqno;
hbqno = tag 16;
- if (hbqno LPFC_MAX_HBQS)
+ if (hbqno = LPFC_MAX_HBQS)
return NULL;
list_for_each_entry(d_buf, phba-hbqs[hbqno].hbq_buffer_list, list) {
-
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
Unexpected busfree in Message-in phase
, 66MHz, medium devsel, latency 32, IRQ 11 Memory at febfe000 (32-bit, non-prefetchable) [size=4K] 00:13.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 5237 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 3 Memory at febfd000 (32-bit, non-prefetchable) [size=4K] 00:13.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 5237 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at febfc000 (32-bit, non-prefetchable) [size=4K] 00:13.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: ASRock Incorporation Unknown device 5239 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 Memory at febff800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 03:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3] (rev a3) (prog-if 00 [VGA]) Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 21 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (32-bit, prefetchable) [size=64M] Memory at d7e8 (32-bit, prefetchable) [size=512K] [virtual] Expansion ROM at fe9f [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 04:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) Subsystem: Creative Labs SBLive! 5.1 eMicro 28028 Flags: bus master, medium devsel, latency 32, IRQ 22 I/O ports at d880 [size=32] Capabilities: [dc] Power Management version 1 04:05.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at dc00 [size=8] Capabilities: [dc] Power Management version 1 04:06.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) Subsystem: Adaptec 29160N Ultra160 SCSI Controller Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18 BIST result: 00 I/O ports at d400 [disabled] [size=256] Memory at feaff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at 8800 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 04:07.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42) Subsystem: D-Link System Inc DFE-530TX rev B Flags: bus master, medium devsel, latency 32, IRQ 20 I/O ports at d000 [size=256] Memory at feafec00 (32-bit, non-prefetchable) [size=256] Expansion ROM at 8802 [disabled] [size=64K] Capabilities: [40] Power Management version 2 If you need anything else (like my .config etc), just ask. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
Build failure in advansys driver - error: implicit declaration of function 'to_pci_dev'
Trying to build current Linus git tree (head at ac07860264bd2b18834d3fa3be47032115524cea) using the attached config file (generated by 'make randconfig') the build fails for me with : ... CC drivers/scsi/advansys.o drivers/scsi/advansys.c:794:2: warning: #warning this driver is still not properly converted to the DMA API drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' drivers/scsi/advansys.c:17781: warning: pointer/integer type mismatch in conditional expression drivers/scsi/advansys.c:17788: warning: unused variable 'pci_memory_address' drivers/scsi/advansys.c:17781: warning: unused variable 'pdev' make[2]: *** [drivers/scsi/advansys.o] Error 1 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 This is on a Slackware Linux 12.0 system with the following environment : $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.16 pcmciautils014 quota-tools3.13. PPP2.4.4 Linux C Library2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 111 Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart sg snd_hwdep evdev ehci_hcd via_rhine k8temp I've also attached a complete build log. If you need any further details, just ask. Kind regards, Jesper Juhl config.24.gz Description: GNU Zip compressed data build.log.24.gz Description: GNU Zip compressed data
cciss: warning: right shift count = width of type
Hi,
I've been building some randconfig kernels lately and I've noticed
this in a few builds :
drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type
The code in question is this :
static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk 56) 0xff;//MSB
c-Request.CDB[3]= (start_blk 48) 0xff;
c-Request.CDB[4]= (start_blk 40) 0xff;
...
}
The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...
So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 40 bit shifts, since they are indeed wider than the type
in the !CONFIG_LBD on a 32bit arch case.
I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.
By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea
Kind regards,
Jesper Juhl
-
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: cciss: warning: right shift count = width of type
(whoops, forgot to add maintainer to Cc - now added)
On 12/08/07, Jesper Juhl [EMAIL PROTECTED] wrote:
Hi,
I've been building some randconfig kernels lately and I've noticed
this in a few builds :
drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type
The code in question is this :
static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk 56) 0xff;//MSB
c-Request.CDB[3]= (start_blk 48) 0xff;
c-Request.CDB[4]= (start_blk 40) 0xff;
...
}
The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...
So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 40 bit shifts, since they are indeed wider than the type
in the !CONFIG_LBD on a 32bit arch case.
I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.
By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea
Kind regards,
Jesper Juhl
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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] Emulex FC HBA driver: fix overflow of statically allocated array
Hi,
The Coverity checker noticed that we may overrun a statically allocated
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
The case is this; In 'struct lpfc_hba' we have
#define LPFC_MAX_HBQS 4
...
struct lpfc_hba {
...
struct hbq_s hbqs[LPFC_MAX_HBQS];
...
};
But then in lpfc_sli_hbqbuf_find() we have this code
hbqno = tag 16;
if (hbqno LPFC_MAX_HBQS)
return NULL;
if 'hbqno' ends up as exactely 4, then we won't return, and then this
list_for_each_entry(d_buf, phba-hbqs[hbqno].hbq_buffer_list, list) {
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno LPFC_MAX_HBQS'
into 'hbqno = LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
uint32_t hbqno;
hbqno = tag 16;
- if (hbqno LPFC_MAX_HBQS)
+ if (hbqno = LPFC_MAX_HBQS)
return NULL;
list_for_each_entry(d_buf, phba-hbqs[hbqno].hbq_buffer_list, list) {
-
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][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
On 04/08/07, James Bottomley [EMAIL PROTECTED] wrote:
On Sat, 2007-08-04 at 20:30 +0200, Jesper Juhl wrote:
(resend of patch previously submitted on 28-Jul-2007 23:06)
Ehlo,
The Coverity checker noticed that we have a potential NULL pointer
deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
This patch handles it by adding the same test against NULL that is
used elsewhere in the same function.
It's on my list of things to look at ... but not very high. I suspect
it actually isn't triggerable, but if you can tell me how, it will save
me from looking.
Here's what Coverity reported :
...
6525int
6526ahc_print_register(ahc_reg_parse_entry_t *table, u_int num_entries,
6527 const char *name, u_int address, u_int value,
6528 u_int *cur_column, u_int wrap_point)
6529{
6530int printed;
6531u_int printed_mask;
6532
Event var_compare_op: Added cur_column due to comparison cur_column != 0
Also see events: [var_deref_op]
At conditional (1): cur_column != 0 taking false path
6533if (cur_column != NULL *cur_column = wrap_point) {
6534printf(\n);
6535*cur_column = 0;
6536}
6537printed = printf(%s[0x%x], name, value);
At conditional (2): table == 0 taking true path
6538if (table == NULL) {
6539printed += printf( );
Event var_deref_op: Variable cur_column tracked as NULL was dereferenced.
Also see events: [var_compare_op]
6540*cur_column += printed;
6541return (printed);
6542}
...
So it requires a NULL 'table' and a != NULL 'cur_column' to trigger.
Whether or not that's actually possible I'm not sure, but it seems
safer to guard against it :)
By the way; if this can actually be triggered, then
ahd_print_register() has the same problem.
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
On 02/08/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 2 Aug 2007 01:55:33 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: [snip] +++ b/drivers/message/fusion/mptbase.c @@ -1393,18 +1393,18 @@ mpt_attach(struct pci_dev *pdev, const struct pci_device_id *id) struct proc_dir_entry *dent, *ent; #endif + if (mpt_debug_level) + printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n, mpt_debug_level); + + if (pci_enable_device(pdev)) + return r; + ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC); Why on earth is that using GFP_ATOMIC? This function later goes on to create procfs files and such things. Dunno. But you are right, that does seem a bit odd, but I assumed there was a reason for it. y'know, we could have a debug option which will spit warnings if someone does a !__GFP_WAIT allocation while !in_atomic() (only works if CONFIG_PREEMPT). But please, make it depend on !CONFIG_AKPM. I shudder to think about all the stuff it would pick up. I can try to cook up something like that tonight... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Fix two potential mem leaks in MPT Fusion (mpt_attach())
Greetings Salutations,
The Coverity checker spotted two potential memory leaks in
drivers/message/fusion/mptbase.c::mpt_attach().
There are two returns that may leak the storage allocated for
'ioc' (sizeof(MPT_ADAPTER) bytes).
A simple fix would be to simply add two kfree() calls before
the return statements, but a better fix (that this patch
implements) is to reorder the code so that if we hit the first
return condition we don't have to do the allocation at all and
then just add a kfree() call for the second case.
Please consider applying. Patch has been compile tested only.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/message/fusion/mptbase.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index e866dac..f9bb705 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1393,18 +1393,18 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
struct proc_dir_entry *dent, *ent;
#endif
+ if (mpt_debug_level)
+ printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
+
+ if (pci_enable_device(pdev))
+ return r;
+
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM : ERROR - Insufficient memory to add
adapter!\n);
return -ENOMEM;
}
-
ioc-debug_level = mpt_debug_level;
- if (mpt_debug_level)
- printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
-
- if (pci_enable_device(pdev))
- return r;
dinitprintk(ioc, printk(KERN_WARNING MYNAM : mpt_adapter_install\n));
@@ -1413,6 +1413,7 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED\n));
} else if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
printk(KERN_WARNING MYNAM : 32 BIT PCI BUS DMA ADDRESSING NOT
SUPPORTED\n);
+ kfree(ioc);
return r;
}
-
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][sas] Fix potential NULL pointer dereference bug in sas_smp_handler()
Hi,
The Coverity checker found a problem in
drivers/scsi/libsas/sas_expander.c::sas_smp_handler().
We dereference a pointer before testing if it is NULL. Easily fixed
in this case by simply moving an assignment down a bit.
Please consider for inclusion.
Patch has been compile tested only.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_expander.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index b500f0c..7871406 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1879,7 +1879,7 @@ int sas_smp_handler(struct Scsi_Host *shost, struct
sas_rphy *rphy,
struct request *req)
{
struct domain_device *dev;
- int ret, type = rphy-identify.device_type;
+ int ret, type;
struct request *rsp = req-next_rq;
if (!rsp) {
@@ -1895,6 +1895,8 @@ int sas_smp_handler(struct Scsi_Host *shost, struct
sas_rphy *rphy,
return -EINVAL;
}
+ type = rphy-identify.device_type;
+
if (type != SAS_EDGE_EXPANDER_DEVICE
type != SAS_FANOUT_EXPANDER_DEVICE) {
printk(%s: can we send a smp request to a device?\n,
PS. Please keep me on Cc when replying.
-
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][sas] Fix potential NULL pointer dereference bug in sas_smp_get_phy_events()
Hello,
In sas_smp_get_phy_events() we never test if the call to
alloc_smp_req(RPEL_REQ_SIZE) succeeds or fails. That means we run
the risk of dereferencing a NULL pointer if it does fail. Far
better to test if we got NULL back and in that case return -ENOMEM
just as we already do for the other memory allocation in that
function.
This patch reworks the memory allocation a bit to deal with it
(compile tested only).
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_expander.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index b500f0c..85f5145 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -507,14 +507,21 @@ static int sas_dev_present_in_domain(struct asd_sas_port
*port,
int sas_smp_get_phy_events(struct sas_phy *phy)
{
int res;
+ u8 *req;
+ u8 *resp;
struct sas_rphy *rphy = dev_to_rphy(phy-dev.parent);
struct domain_device *dev = sas_find_dev_by_rphy(rphy);
- u8 *req = alloc_smp_req(RPEL_REQ_SIZE);
- u8 *resp = kzalloc(RPEL_RESP_SIZE, GFP_KERNEL);
+ resp = kzalloc(RPEL_RESP_SIZE, GFP_KERNEL);
if (!resp)
return -ENOMEM;
+ req = alloc_smp_req(RPEL_REQ_SIZE);
+ if (!req) {
+ res = -ENOMEM;
+ goto out;
+ }
+
req[1] = SMP_REPORT_PHY_ERR_LOG;
req[9] = phy-number;
PS. Please keep me on Cc when replying.
-
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][sas] Fix potential NULL pointer dereference bug in sas_smp_get_phy_events()
On 28/07/07, James Bottomley [EMAIL PROTECTED] wrote:
On Fri, 2007-07-27 at 23:27 +0200, Jesper Juhl wrote:
In sas_smp_get_phy_events() we never test if the call to
alloc_smp_req(RPEL_REQ_SIZE) succeeds or fails. That means we run
the risk of dereferencing a NULL pointer if it does fail. Far
better to test if we got NULL back and in that case return -ENOMEM
just as we already do for the other memory allocation in that
function.
This patch reworks the memory allocation a bit to deal with it
(compile tested only).
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_expander.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index b500f0c..85f5145 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -507,14 +507,21 @@ static int sas_dev_present_in_domain(struct
asd_sas_port *port,
int sas_smp_get_phy_events(struct sas_phy *phy)
{
int res;
+ u8 *req;
+ u8 *resp;
struct sas_rphy *rphy = dev_to_rphy(phy-dev.parent);
struct domain_device *dev = sas_find_dev_by_rphy(rphy);
- u8 *req = alloc_smp_req(RPEL_REQ_SIZE);
- u8 *resp = kzalloc(RPEL_RESP_SIZE, GFP_KERNEL);
+ resp = kzalloc(RPEL_RESP_SIZE, GFP_KERNEL);
Actually, this should be alloc_smp_resp(RPEL_RESP_SIZE);
if (!resp)
return -ENOMEM;
+ req = alloc_smp_req(RPEL_REQ_SIZE);
+ if (!req) {
+ res = -ENOMEM;
+ goto out;
+ }
Just for the sake of being the same as all the rest of the code, the
sequence should be
req = alloc_smp_req(xxx_REQ_SIZE);
if (!req)
return -ENOMEM;
resp = alloc_smp_resp(xxx_RESP_SIZE);
if (!resp) {
kfree(req);
return -ENOMEM;
}
(allocate request then response).
Fair enough. It makes the code a bit larger though :
My way, as per the original patch:
textdata bss dec hex filename
13820 0 8 138283604 drivers/scsi/libsas/sas_expander.o
Your way, as per this patch:
textdata bss dec hex filename
13832 0 8 138403610 drivers/scsi/libsas/sas_expander.o
I hope this patch is acceptable :
In sas_smp_get_phy_events() we never test if the call to
alloc_smp_req(RPEL_REQ_SIZE) succeeds or fails. That means we run
the risk of dereferencing a NULL pointer if it does fail. Far
better to test if we got NULL back and in that case return -ENOMEM
just as we already do for the other memory allocation in that
function.
This patch should take care of it (compile tested only).
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_expander.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index b500f0c..e98d2b9 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -507,14 +507,21 @@ static int sas_dev_present_in_domain(struct asd_sas_port
*port,
int sas_smp_get_phy_events(struct sas_phy *phy)
{
int res;
+ u8 *req;
+ u8 *resp;
struct sas_rphy *rphy = dev_to_rphy(phy-dev.parent);
struct domain_device *dev = sas_find_dev_by_rphy(rphy);
- u8 *req = alloc_smp_req(RPEL_REQ_SIZE);
- u8 *resp = kzalloc(RPEL_RESP_SIZE, GFP_KERNEL);
- if (!resp)
+ req = alloc_smp_req(RPEL_REQ_SIZE);
+ if (!req)
return -ENOMEM;
+ resp = alloc_smp_resp(RPEL_RESP_SIZE);
+ if (!resp) {
+ kfree(req);
+ return -ENOMEM;
+ }
+
req[1] = SMP_REPORT_PHY_ERR_LOG;
req[9] = phy-number;
It looks like disc_resp could use a little love too (it's using the req
alloc routines).
I'll take a look at that later.
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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
(resend) scsi0: Unexpected busfree while idle - Adaptec 29160N Ultra160 SCSI adapter
Resending this since all I'm getting is silence and it's quite a problem for this box. I did a few google searches and aparently I'm not the only one having this problem - I see reports going back for years, but no solutions. I've got heaps of dmesg output if wanted/needed, I'll test patches, suggestions etc. Any ideas people? On Sunday 15 July 2007 04:04:50 Jesper Juhl wrote: On 09/07/07, Jesper Juhl [EMAIL PROTECTED] wrote: I just experienced a long hang and a lot of unpleasant messages in dmesg while building randconfig kernels in a loop. It just happened again without me doing anything special, just normal desktop use, surfing the net, reading email etc. This time the kernel version was 2.6.22-g1db6178c This time the start of the messages look like this (slightly different from last time - quoted below): [ 8039.510026] scsi0: Unexpected busfree while idle [ 8039.510036] SEQADDR == 0x18 [ 8069.492318] sr 0:0:4:0: Attempting to queue an ABORT message [ 8069.492324] CDB: 0x0 0x0 0x0 0x0 0x0 0x0 [ 8069.492342] scsi0: At time of recovery, card was not paused [ 8069.492353] Dump Card State Begins [ 8069.492357] scsi0: Dumping Card State while idle, at SEQADDR 0x18 [ 8069.492362] Card was paused [ 8069.492371] ACCUM = 0xa, SINDEX = 0x48, DINDEX = 0xe4, ARG_2 = 0x2 [ 8069.492378] HCNT = 0x0 SCBPTR = 0xb [ 8069.492384] SCSIPHASE[0x0] SCSISIGI[0x0] ERROR[0x0] [ 8069.492406] SCSIBUSL[0x0] LASTPHASE[0x1] SCSISEQ[0x1a] [ 8069.492426] SBLKCTL[0xa] SCSIRATE[0x0] SEQCTL[0x10] [ 8069.492447] SEQ_FLAGS[0xc0] SSTAT0[0x0] SSTAT1[0x0] [ 8069.492467] SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8] [ 8069.492487] SIMODE1[0xa4] SXFRCTL0[0x80] DFCNTRL[0x0] [ 8069.492507] DFSTATUS[0x89] [ 8069.492515] STACK: 0x0 0x164 0x179 0x17 [ 8069.492536] SCB count = 24 [ 8069.492540] Kernel NEXTQSCB = 12 [ 8069.492545] Card NEXTQSCB = 17 [ 8069.492549] QINFIFO entries: 17 18 [ 8069.492561] Waiting Queue entries: 11:10 [ 8069.492573] Disconnected Queue entries: [ 8069.492581] QOUTFIFO entries: [ 8069.492587] Sequencer Free SCB List: 3 1 13 14 5 6 0 17 10 19 4 8 7 2 16 20 18 12 15 9 21 22 23 24 25 26 27 28 29 30 31 [ 8069.492694] Sequencer SCB Info: [ 8069.492698] 0 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492723] SCB_TAG[0xff] [ 8069.492729] 1 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492753] SCB_TAG[0xff] [ 8069.492759] 2 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492784] SCB_TAG[0xff] [ 8069.492791] 3 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492816] SCB_TAG[0xff] [ 8069.492822] 4 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492845] SCB_TAG[0xff] [ 8069.492851] 5 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492875] SCB_TAG[0xff] [ 8069.492880] 6 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492904] SCB_TAG[0xff] [ 8069.492910] 7 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492934] SCB_TAG[0xff] [ 8069.492940] 8 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492964] SCB_TAG[0xff] [ 8069.492969] 9 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.492994] SCB_TAG[0xff] [ 8069.493000] 10 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493024] SCB_TAG[0xff] [ 8069.493030] 11 SCB_CONTROL[0x40] SCB_SCSIID[0x47] SCB_LUN[0x0] [ 8069.493054] SCB_TAG[0xa] [ 8069.493060] 12 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493085] SCB_TAG[0xff] [ 8069.493090] 13 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493114] SCB_TAG[0xff] [ 8069.493120] 14 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493145] SCB_TAG[0xff] [ 8069.493150] 15 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493175] SCB_TAG[0xff] [ 8069.493181] 16 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493206] SCB_TAG[0xff] [ 8069.493212] 17 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493235] SCB_TAG[0xff] [ 8069.493241] 18 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493266] SCB_TAG[0xff] [ 8069.493272] 19 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493296] SCB_TAG[0xff] [ 8069.493302] 20 SCB_CONTROL[0xe0] SCB_SCSIID[0x67] SCB_LUN[0x0] [ 8069.493316] SCB_TAG[0xff] [ 8069.493323] 21 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493348] SCB_TAG[0xff] [ 8069.493354] 22 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493378] SCB_TAG[0xff] [ 8069.493383] 23 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493407] SCB_TAG[0xff] [ 8069.493413] 24 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493437] SCB_TAG[0xff] [ 8069.493443] 25 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493469] SCB_TAG[0xff] [ 8069.493475] 26 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493501] SCB_TAG[0xff] [ 8069.493507] 27 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] [ 8069.493531] SCB_TAG[0xff] [ 8069.493537] 28 SCB_CONTROL[0x0] SCB_SCSIID[0xff
[PATCH][13/37] Clean up duplicate includes in drivers/scsi/
Hi, This patch cleans up duplicate includes in drivers/scsi/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c index 3a80897..e0f1991 100644 --- a/drivers/scsi/NCR_D700.c +++ b/drivers/scsi/NCR_D700.c @@ -97,7 +97,6 @@ #include linux/kernel.h #include linux/module.h #include linux/mca.h -#include linux/interrupt.h #include asm/io.h #include scsi/scsi_host.h #include scsi/scsi_device.h diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c index 673cfe1..039892c 100644 --- a/drivers/scsi/lpfc/lpfc_debugfs.c +++ b/drivers/scsi/lpfc/lpfc_debugfs.c @@ -43,7 +43,6 @@ #include lpfc_crtn.h #include lpfc_vport.h #include lpfc_version.h -#include lpfc_vport.h #include lpfc_debugfs.h #ifdef CONFIG_LPFC_DEBUG_FS diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 07bd0dc..3a51266 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -43,7 +43,6 @@ #include lpfc_crtn.h #include lpfc_vport.h #include lpfc_version.h -#include lpfc_vport.h static int lpfc_parse_vpd(struct lpfc_hba *, uint8_t *, int); static void lpfc_get_hba_model_desc(struct lpfc_hba *, uint8_t *, uint8_t *); - 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] fix compiler warning in aic7770
On 8/30/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, Aug 30, 2005 at 01:15:36AM +0200, Jesper Juhl wrote: Fix compiler warning in drivers/scsi/aic7xxx/aic7770.c : drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l' ... This patch is already in 2.6.13-rc6-mm2 (through the scsi-misc-2.6.git tree). Ok, I only checked 2.6.13. Thank you for the feedback. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] fix compiler warning in aic7770
Fix compiler warning in drivers/scsi/aic7xxx/aic7770.c :
drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l'
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/aic7xxx/aic7770.c |1 -
1 files changed, 1 deletion(-)
--- linux-2.6.13-orig/drivers/scsi/aic7xxx/aic7770.c2005-08-29
01:41:01.0 +0200
+++ linux-2.6.13/drivers/scsi/aic7xxx/aic7770.c 2005-08-30 01:08:22.0
+0200
@@ -126,7 +126,6 @@ aic7770_find_device(uint32_t id)
int
aic7770_config(struct ahc_softc *ahc, struct aic7770_identity *entry, u_int io)
{
- u_long l;
int error;
int have_seeprom;
u_int hostconf;
-
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 1/2] cpqfc: fix for Using too much stach in 2.6 kernel
On 8/4/05, Jesper Juhl [EMAIL PROTECTED] wrote:
On 8/4/05, Saripalli, Venkata Ramanamurthy (STSD) [EMAIL PROTECTED] wrote:
Patch 1 of 2
This patch fixes the #error this is too much stack in 2.6 kernel.
Using kmalloc to allocate memory to ulFibreFrame.
[snip]
if( fchs-pl[0] == ELS_LILP_FRAME)
{
+ kfree(ulFibreFrame);
return 1; // found the LILP frame!
}
else
{
+ kfree(ulFibreFrame);
// keep looking...
}
The first thing you do in either branch is to call
kfree(ulFibreFrame); , so instead of having the call in both branches
you might as well just have one call before the if(). Ohh and this
looks like it could do with a CodingStyle cleanup as well.
kfree(ulFibreFrame);
if (fchs-pl[0] == ELS_LILP_FRAME)
return 1; /* found the LILP frame! */
/* keep looking */
Whoops, as Rolf Eike Beer pointed out to me, I snipped one line too many.
fchs = (TachFCHDR_GCMND*)ulFibreFrame;
So, the kfree inside each branch is correct. Freeing it just before
the if would be wrong.
Sorry about that.
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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 1/2] cpqfc: fix for Using too much stach in 2.6 kernel
On 8/4/05, Saripalli, Venkata Ramanamurthy (STSD) [EMAIL PROTECTED] wrote:
Patch 1 of 2
This patch fixes the #error this is too much stack in 2.6 kernel.
Using kmalloc to allocate memory to ulFibreFrame.
[snip]
if( fchs-pl[0] == ELS_LILP_FRAME)
{
+ kfree(ulFibreFrame);
return 1; // found the LILP frame!
}
else
{
+ kfree(ulFibreFrame);
// keep looking...
}
The first thing you do in either branch is to call
kfree(ulFibreFrame); , so instead of having the call in both branches
you might as well just have one call before the if(). Ohh and this
looks like it could do with a CodingStyle cleanup as well.
kfree(ulFibreFrame);
if (fchs-pl[0] == ELS_LILP_FRAME)
return 1; /* found the LILP frame! */
/* keep looking */
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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: [-mm patch] SCSI_QLA2ABC options must select FW_LOADER
On 7/19/05, Adrian Bunk [EMAIL PROTECTED] wrote: [ The subject was adapted to linux-kernel spam filters... ] On Sat, Jul 16, 2005 at 07:26:44PM +0200, Jindrich Makovicka wrote: Andrew Vasquez wrote: Yes, quite. How about the following to correct the intention. Add correct Kconfig option for ISP24xx support. Signed-off-by: Andrew Vasquez [EMAIL PROTECTED] --- diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig --- a/drivers/scsi/qla2xxx/Kconfig +++ b/drivers/scsi/qla2xxx/Kconfig @@ -39,3 +39,11 @@ config SCSI_QLA6312 ---help--- This driver supports the QLogic 63xx (ISP6312 and ISP6322) host adapter family. + +config SCSI_QLA24XX + tristate QLogic ISP24xx host adapter family support + depends on SCSI_QLA2XXX +select SCSI_FC_ATTRS there should be also select FW_LOADER, as it uses request_firmware release_firmware ... You are right, patch below. Jindrich Makovicka cu Adrian -- snip -- qla_init.c now uses code that requires FW_LOADER. Additionally, this patch removes spaces instead of tabs at the SCSI_FC_ATTRS selects. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.13-rc3-mm1-full/drivers/scsi/qla2xxx/Kconfig.old 2005-07-17 15:44:26.0 +0200 +++ linux-2.6.13-rc3-mm1-full/drivers/scsi/qla2xxx/Kconfig 2005-07-17 15:45:45.0 +0200 @@ -1,49 +1,55 @@ config SCSI_QLA2XXX tristate depends on SCSI PCI default y config SCSI_QLA21XX tristate QLogic ISP2100 host adapter family support depends on SCSI_QLA2XXX -select SCSI_FC_ATTRS + select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 21xx (ISP2100) host adapter family. config SCSI_QLA22XX tristate QLogic ISP2200 host adapter family support depends on SCSI_QLA2XXX -select SCSI_FC_ATTRS + select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 22xx (ISP2200) host adapter family. config SCSI_QLA2300 tristate QLogic ISP2300 host adapter family support depends on SCSI_QLA2XXX -select SCSI_FC_ATTRS + select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 2300 (ISP2300 and ISP2312) host adapter family. config SCSI_QLA2322 tristate QLogic ISP2322 host adapter family support depends on SCSI_QLA2XXX -select SCSI_FC_ATTRS + select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 2322 (ISP2322) host adapter family. config SCSI_QLA6312 tristate QLogic ISP63xx host adapter family support depends on SCSI_QLA2XXX -select SCSI_FC_ATTRS + select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 63xx (ISP6312 and ISP6322) host adapter family. config SCSI_QLA24XX tristate QLogic ISP24xx host adapter family support depends on SCSI_QLA2XXX -select SCSI_FC_ATTRS + select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 24xx (ISP2422 and ISP2432) host adapter family. I send a patch for this yesterday that lets SCSI_QLA2XXX select FW_LOADER. I believe that's a bit better since the other options depend on SCSI_QLA2XXX anyway, there's no point in having them all set FW_LOADER. My patch also fixes another little issue; that you cannot disable SCSI_QLA2XXX if you don't need it. See the patch here: http://lkml.org/lkml/2005/7/19/147 The mail contains 3 patches, but the third one is the best fix IMHO. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
Bug: audio playing broke with my SCSI CD and DVD drives in 2.6.11-rc2-bk7 and beyond.
Hi, I hope I got all relevant info included in the text below, but if you lack something just ask. If you want me to test patches or try and revert patches, then just let me know - I can do all the testing you need me to. [1.] One line summary of the problem: Playing audio CD's in SCSI player seems to be broken in 2.6.11-rc2-bk7 and above. [2.] Full description of the problem/report: When I start up my system I log into KDE and one of the apps that start automatically is kscd (the CD player). A little while ago when I brought up 2.6.11-bk9 I wanted to listen to some music and noticed that for some reason kscd didn't seem to be running (at least its icon was not in my tray). I took a look with 'ps' and saw a kscd process stuck i D state : [EMAIL PROTECTED]:~$ ps aux | grep kscd juhl 2781 3.2 1.9 23128 10060 ? S23:37 0:00 kscd -session 10d3e0616700011072061330027020007_1107206542_214811 juhl 2782 5.2 2.6 24524 13784 ? D23:37 0:00 kscd -session 10d3e0616700011072061330027020007_1107206542_214811 Trying to strace the process in S state to maybe get a clue as to why it was not running properly only gave me this : [EMAIL PROTECTED]:~$ strace -p 2781 Process 2781 attached - interrupt to quit read(3, --- it's just stuck here Then I tried to kill it off : [EMAIL PROTECTED]:~$ killall kscd ; ps aux | grep kscd juhl 2782 0.1 2.6 24524 13784 ? D23:37 0:00 kscd -session 10d3e0616700011072061330027020007_1107206542_214811 [EMAIL PROTECTED]:~$ killall -9 kscd ; ps aux | grep kscd juhl 2782 0.1 2.6 24524 13784 ? D23:37 0:00 kscd -session 10d3e0616700011072061330027020007_1107206542_214811 With no success... I just did a binary search of kernels between the last one I knew worked perfectly (2.6.11-rc2) and the one where I noticed the problem (2.6.11-rc2-bk9) and this is the result: 2.6.11-rc2 works 2.6.11-rc2-bk3 works 2.6.11-rc2-bk5 works 2.6.11-rc2-bk6 works 2.6.11-rc2-bk7 broken 2.6.11-rc2-bk9 broken So, it looks like something in 2.6.11-bk9 broke it. I've been reading the -bk7 changelog to see if I could find some obvious patch to try and revert, but it eludes me. /dev/sr0 (which is what kscd is configured to use) is a SCSI DVD-ROM drive connected to an Adaptec 29160N controller (details on hardware + .config etc can be found below). I also have a Plextor CD writer connected to that controller, but trying to play CD's with that seems to also be broken in the same way. [3.] Keywords (i.e., modules, networking, kernel): SCSI, CD, DVD, Audio, 'D State' [4.] Kernel version (from /proc/version): First broken version: [EMAIL PROTECTED]:~$ cat /proc/version Linux version 2.6.11-rc2-bk7 ([EMAIL PROTECTED]) (gcc version 3.4.2) #1 Sun Jan 30 00:08:33 CET 2005 [5.] Output of Oops.. message (if applicable) Not applicable. [6.] A small shell script or example program which triggers the problem (if possible) See above (2) for a way to trigger the problem. [7.] Environment [7.1.] Software [EMAIL PROTECTED]:~/download/kernel/linux-2.6.11-rc2-bk7$ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dragon 2.6.11-rc2-bk7 #1 Sun Jan 30 00:08:33 CET 2005 i686 unknown unknown GNU/Linux Gnu C 3.4.2 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12p mount 2.12p module-init-tools 3.1 e2fsprogs 1.35 jfsutils 1.1.6 reiserfsprogs 3.6.18 reiser4progs line xfsprogs 2.6.13 pcmcia-cs 3.2.8 quota-tools3.12. PPP2.4.2 nfs-utils 1.0.7 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Linux C++ Library 6.0.2 Procps 3.2.3 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 050 Modules Loaded snd_pcm_oss snd_mixer_oss via_rhine snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep evdev agpgart [7.2.] Processor information (from /proc/cpuinfo): [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 4 cpu MHz : 1400.224 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow bogomips: 2752.51 [7.3.] Module information (from /proc/modules): [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 vendor_id
Re: Bug: audio playing broke with my SCSI CD and DVD drives in 2.6.11-rc2-bk7 and beyond.
On Mon, 31 Jan 2005, James Bottomley wrote: On Tue, 2005-02-01 at 00:22 +0100, Jesper Juhl wrote: audio Could you try the attached? James I applied the patch to 2.6.11-rc2-bk9, rebuild, rebooted and now everything is just fine. Thank you. -- Jesper Juhl - 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
shouldn't irq be module_param_array instead of module_param in scsi/gdth.c ?
This little warning made me take a closer look :
drivers/scsi/gdth.c:645: warning: return from incompatible pointer type
And line 645 looks like this :
module_param(irq, int, 0);
looking a bit up in the file I find :
/* IRQ list for GDT3000/3020 EISA controllers */
static int irq[MAXHA] __initdata =
{0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
That certainly looks like an array to me, so I'm wondering if something
like this patch would be correct? I'm not familliar enough with
module_param* to be completely confident, but this silences the warning.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.11-rc2-bk7-orig/drivers/scsi/gdth.c 2005-01-22
21:59:46.0 +0100
+++ linux-2.6.11-rc2-bk7/drivers/scsi/gdth.c2005-01-30 16:52:45.0
+0100
@@ -642,7 +642,7 @@ static int probe_eisa_isa = 0;
static int force_dma32 = 0;
/* parameters for modprobe/insmod */
-module_param(irq, int, 0);
+module_param_array(irq, int, NULL, 0);
module_param(disable, int, 0);
module_param(reserve_mode, int, 0);
module_param_array(reserve_list, int, NULL, 0);
--
Kind regards,
Jesper Juhl
PS. Please CC me on replies.
-
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: shouldn't irq be module_param_array instead of module_param in scsi/gdth.c ?
On Sun, 30 Jan 2005, Randy.Dunlap wrote:
Jesper Juhl wrote:
This little warning made me take a closer look : drivers/scsi/gdth.c:645:
warning: return from incompatible pointer type
And line 645 looks like this :
module_param(irq, int, 0);
looking a bit up in the file I find :
/* IRQ list for GDT3000/3020 EISA controllers */
static int irq[MAXHA] __initdata =
{0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
That certainly looks like an array to me, so I'm wondering if something like
this patch would be correct? I'm not familliar enough with module_param* to
be completely confident, but this silences the warning.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.11-rc2-bk7-orig/drivers/scsi/gdth.c 2005-01-22
21:59:46.0 +0100
+++ linux-2.6.11-rc2-bk7/drivers/scsi/gdth.c2005-01-30
16:52:45.0
+0100
@@ -642,7 +642,7 @@ static int probe_eisa_isa = 0;
static int force_dma32 = 0;
/* parameters for modprobe/insmod */
-module_param(irq, int, 0);
+module_param_array(irq, int, NULL, 0);
module_param(disable, int, 0);
module_param(reserve_mode, int, 0);
module_param_array(reserve_list, int, NULL, 0);
Yep, same as:
http://marc.theaimsgroup.com/?l=linux-scsim=110540330511653w=2
Ohh, I was not aware of that patch, guess I should have searched the
archives before posting. Thank you for the info.
--
Jesper
-
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
