[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20060930013349.1f12e0ee.akpm@osdl.org>
Date: Sat, 30 Sep 2006 01:33:49 -0700
From: Andrew Morton <akpm@...l.org>
To: Valdis.Kletnieks@...edu
Cc: jt@....hp.com, "John W. Linville" <linville@...driver.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: 2.6.18-mm2 - oops in cache_alloc_refill()
On Sat, 30 Sep 2006 03:50:43 -0400
Valdis.Kletnieks@...edu wrote:
> On Fri, 29 Sep 2006 23:31:07 EDT, Valdis.Kletnieks@...edu said:
> > Fair enough, I'm going to try reverting the 2 commits and see if things
> > behave better.
>
> OK, it's definitely something in those 2 commits - I reverted them and the
> resulting 2.6.18-mm2 kernel has been up and stable for 4 hours, even with
> the problem gkrellm updating once a second the whole time.
>
> I'm not *seeing* how those changes can cause trouble - unless it's this:
>
> diff --git a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c
> index 1840b69..9e19a96 100644
> --- a/drivers/net/wireless/orinoco.c
> +++ b/drivers/net/wireless/orinoco.c
> @@ -3037,7 +3037,7 @@ static int orinoco_ioctl_getessid(struct
> }
>
> erq->flags = 1;
> - erq->length = strlen(essidbuf) + 1;
> + erq->length = strlen(essidbuf);
You know what the next question is ;)
Did reverting just that line fix it?
> Does some other code go batshit if length ==0? My current config doesn't
> try to actually ifup the wireless if I also have connectivity via copper (in
> order to avoid chewing up a DHCP lease in crowded address space if not needed).
>
> % iwconfig eth5
> eth5 IEEE 802.11b ESSID:"" Nickname:"HERMES I"
> Mode:Managed Frequency:2.457 GHz Access Point: Not-Associated
> Bit Rate:11 Mb/s Sensitivity:1/3
> Retry limit:4 RTS thr:off Fragment thr:off
> Power Management:off
> Link Quality=0/92 Signal level=134/153 Noise level=134/153
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> That ESSID the source of the trouble?
>
Might be. I can't immediately spot a problem with it, but perhaps
length==0 causes the driver to not allocate a buffer and to then write to
the not-allocated buffer. Not sure..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists