[PATCH 3/6][RESEND] Reduce size of the xterm-linux.xpm image by 12 bytes.

[PATCH 3/6][RESEND] Reduce size of the xterm-linux.xpm image by 12 bytes.

[Jesper Juhl]

(previously send on 04-Aug-2007 20:31)

Ok, this is a bit silly (but also a little fun) :-)

In Documentation/ we have the xterm-linux.xpm image.
Now an XPM image is more or less C code, so I thought it would 
be fun to look at it like that and put on the CodingStyle and 
space use glasses.

I made two changes, none of which change the actual image.
 1) I removed two lines that just had empty comments.
 2) I brought the 'image_name' declaration into line with how 
    we commonly write arrays and pointers.

This saves us an astonishing 12 bytes on the file size ;-)
That's a little less data for every future Linux kernel source 
user to download - that can't be bad.

Ok, ok, so it does have the drawback of being 99,999% churn and 
you could argue that it'll clutter the git history. So if you 
don't apply it I won't hate you (too much) ;-)


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

diff --git a/Documentation/xterm-linux.xpm b/Documentation/xterm-linux.xpm
index f469c1a..93cb180 100644
--- a/Documentation/xterm-linux.xpm
+++ b/Documentation/xterm-linux.xpm
@@ -9,10 +9,8 @@
 /**       Swiss Federal Institute of Technology                             **/
 /**       Central Computing Service                                         **/
 /*****************************************************************************/
-static char * image_name [] = {
-/**/
+static char *image_name[] = {
 "64 38 8 1",
-/**/
 " 	s mask	c none",
 ".	c gray70",
 "X	c gray85",

[PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[Jesper Juhl]

(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 <jesper.juhl@gmail.com>
Acked-by: James Smart <james.smart@emulex.com>
---

 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) {

[PATCH 5/6][RESEND] fix tiny spelling error in comment in cfi_cmdset_0001.c

[Jesper Juhl]

(previously send on 05-Jul-2007 02:18, 04-Aug-2007 20:31)

Trivial fix of a spelling error in a comment in cfi_cmdset_0001.c
s/ships/chips/

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 2f19fa7..c266ebc 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -526,7 +526,7 @@ static int cfi_intelext_partition_fixup(struct mtd_info *mtd,
 	struct cfi_pri_intelext *extp = cfi->cmdset_priv;
 
 	/*
-	 * Probing of multi-partition flash ships.
+	 * Probing of multi-partition flash chips.
 	 *
 	 * To support multiple partitions when available, we simply arrange
 	 * for each of them to have their own flchip structure even if they

[PATCH 6/6][RESEND] Avoid possible NULL pointer deref in 3c359 driver

[Jesper Juhl]

(Resending old patch originally submitted at 1/7-2007 02:19, 04-Aug-2007 20:31)

In xl_freemem(), if dev_if is NULL, the line
  struct xl_private *xl_priv =(struct xl_private *)dev->priv;
will cause a NULL pointer dereference. However, if we move
that assignment below the 'if' statement that tests for a NULL
'dev', then that NULL deref can never happen.
It never hurts to be safe :-)


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index e22a3f5..671f4da 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -1044,15 +1044,17 @@ static void xl_freemem(struct net_device *dev)
 static irqreturn_t xl_interrupt(int irq, void *dev_id) 
 {
 	struct net_device *dev = (struct net_device *)dev_id;
- 	struct xl_private *xl_priv =(struct xl_private *)dev->priv;
-	u8 __iomem * xl_mmio = xl_priv->xl_mmio ; 
-	u16 intstatus, macstatus  ;
+ 	struct xl_private *xl_priv;
+	u8 __iomem * xl_mmio; 
+	u16 intstatus, macstatus;
 
 	if (!dev) { 
-		printk(KERN_WARNING "Device structure dead, aaahhhh !\n") ;
+		printk(KERN_WARNING "3c359: Device structure dead, aaahhhh!\n");
 		return IRQ_NONE; 
 	}
 
+	xl_priv = (struct xl_private *)dev->priv;
+	xl_mmio = xl_priv->xl_mmio;
 	intstatus = readw(xl_mmio + MMIO_INTSTATUS) ;  
 
 	if (!(intstatus & 1)) /* We didn't generate the interrupt */

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[James Smart]

NACK

The fix is contained in our 8.2.2 sources recently posted and pushed by James
as part of his last scsi fixes.

-- 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().
> 
> 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 <jesper.juhl@gmail.com>
> Acked-by: James Smart <james.smart@emulex.com>
> ---
> 
>  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) {
> 
> 
> 
> 

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[Jesper Juhl]

On 13/08/07, James Smart <James.Smart@emulex.com> 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 <jesper.juhl@gmail.com>
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

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[James Smart]

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.

- 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.

-- james s

Jesper Juhl wrote:
> On 13/08/07, James Smart <James.Smart@emulex.com> 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().
> ...
> 

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[Jesper Juhl]

On 13/08/07, James Smart <James.Smart@emulex.com> 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 <jesper.juhl@gmail.com>
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