Re: Linux 2.6.0-test9

Re: Linux 2.6.0-test9

[Andries.Brouwer]

    From: Linus Torvalds <torvalds@osdl.org>

    > I have run 2.6.0-test6 without any problems. Switched
    > to 2.6.0-test9 today. Something involving job control
    > or so is broken. Several of my remote xterms hang.

    Btw, this one sounds like a known bug in bash.

No - it is a recent kernel bug.
Mikael Pettersson noticed precisely the same thing, and says
 "Reverting 2.6.0-test8-bk3's net/ipv4/tcp.c patch fixes
  these problems."
And so it does.

Andries

Re: Linux 2.6.0-test9

[Andrew Morton]

Andries.Brouwer@cwi.nl wrote:
>
>     From: Linus Torvalds <torvalds@osdl.org>
> 
>     > I have run 2.6.0-test6 without any problems. Switched
>     > to 2.6.0-test9 today. Something involving job control
>     > or so is broken. Several of my remote xterms hang.
> 
>     Btw, this one sounds like a known bug in bash.
> 
> No - it is a recent kernel bug.
> Mikael Pettersson noticed precisely the same thing, and says
>  "Reverting 2.6.0-test8-bk3's net/ipv4/tcp.c patch fixes
>   these problems."
> And so it does.
> 

Can someone show us the diff for this?

Re: Linux 2.6.0-test9

[Linus Torvalds]

On Sun, 26 Oct 2003, Andrew Morton wrote:
> 
> Can someone show us the diff for this?

There's only one change to tcp.c after -test8: it's 

	kuznet@ms2.inr.ac.ru:
	 TCP: do not return -EINTR, when data are available for read()

and I think it should just be reverted: the changeset even removes the 
comment that clearly says:

		/* We need to check signals first, to get correct SIGURG
		 * handling. FIXME: Need to check this doesn't impact 1003.1g
		 * and move it down to the bottom of the loop
		 */

And Alexey apparently tried to do the "FIXME" part, but without thinking 
about the SIGURG part.

We _need_ to stop at urgent data and we _should_ return -EINTR, and let
the SIGURG handler do the URG read. Otherwise we'll lose urgent data (or
we'll just read it inline without realizing that it was urgent data).

I don't know anybody sane who uses urgent data (telnet and rlogin do, I
don't know if they count as sane any more), but it does look like that
patch totally broke it.

I'd revert it myself, but since the networking code is fairly well 
maintained, I'll just wait for David and Alexey to weigh in, and tell me 
that I'm a total moron and I overlooked something. But I don't think I 
missed anything.

Andries, what was the situation that led to a TCP lockup? I don't see 
anything but URG being broken by that patch, so it would be good to verify 
that your breakage really was URG, to see that it's totally understood..

		Linus

Re: Linux 2.6.0-test9

[Linus Torvalds]

On Sun, 26 Oct 2003, Linus Torvalds wrote:
> 
> Andries, what was the situation that led to a TCP lockup? I don't see 
> anything but URG being broken by that patch, so it would be good to verify 
> that your breakage really was URG, to see that it's totally understood..

Btw, final comment: if it really is URG-only breakage, then instead of 
reverting the patch (if it had some other reasons going for it), we could 
change the URG test at the top of the loop from

	if (copied && tp->urg_data && tp->urg_seq == *seq)
		break

to

	if (tp->urg_data && tp->urg_seq == *seq) {
		if (copied)
			break;
		if (signal_pending(current)) {
			copied = timeo ? sock_intr_errno(timeo) : -EAGAIN;
			break;
		}
	}

which gives the right break semantics for URG data.

After that, the only other place where we should check for signal pending 
is probably at the tcp_data_wait() call. All the other signal pending 
checks seem bogus (ie right now a pending signal will mean that we avoid 
doing even TCP-level cleanups, which looks just wrong).

But reverting the change is clearly the "safer" thing to do, I just worry 
that Alexey might have had a real reason for tryign to avoid the EINTR in 
the first place (for non-URG data).

		Linus

Re: Linux 2.6.0-test9

[David S. Miller]

On Sun, 26 Oct 2003 16:28:11 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> But reverting the change is clearly the "safer" thing to do, I just worry 
> that Alexey might have had a real reason for tryign to avoid the EINTR in 
> the first place (for non-URG data).

I'd like to hear something from Alexey first.

The problem we were trying to deal with was that when data
is available to read a lot of people were complaining that
we return -EINTR and no other system does this.

This is heavily inconsistent with how we handle every other
type of socket error.  In all other cases, a read() when data
is available will succeed until the very last byte is sucked
out of the socket, then any subsequent read() call after the
queue is emptied will return the error.

But I am starting to see that URG is different.  It is not like
other socket errors that halt the socket and make no new data
arrive after it happens.  Rather, URG can happen just about anywhere
and more data can continue to flow into the socket buffers.

In fact, this means that our change can result in an application
can never see the error if data continues to arrive faster than
the application can pull it out, see?

Alexey, I think we did not understand this case fully when making this
change.

Re: Linux 2.6.0-test9

[kuznet]

Hello!

> And Alexey apparently tried to do the "FIXME" part, but without thinking 
> about the SIGURG part.

Actually, it was thought a lot for several linux-2.x. :-)


> We _need_ to stop at urgent data and we _should_ return -EINTR, and let
> the SIGURG handler do the URG read. Otherwise we'll lose urgent data (or
> we'll just read it inline without realizing that it was urgent data).

The patch was expected not to break this property. Alas, something
is overlooked yet. I still do not understand what exactly is broken,
I feel I have to find some rlogin to experiment in vivo.

Alexey

Re: Linux 2.6.0-test9

[kuznet]

Hello!


> But I am starting to see that URG is different.  It is not like
> other socket errors that halt the socket and make no new data
> arrive after it happens.  Rather, URG can happen just about anywhere
> and more data can continue to flow into the socket buffers.
> 
> In fact, this means that our change can result in an application
> can never see the error if data continues to arrive faster than
> the application can pull it out, see?
> 
> Alexey, I think we did not understand this case fully when making this
> change.

No doubts taking into account that the things are so badly broken. :-)

But I was aware about this problem and even "proved" to you that the patch
will not change anything. :-) Remember this?


> I found only one more or less essential difference: when we have one oob
> octet in the stream with data following it, read() can return -EINTR/RESTART
> due to pending SIGURG and normal data will be read at the second read(),
> or, alternatively, it can return data following oob octet immediately.
>
> In practice there is no real difference: SIGURG is processed before read()
> returns in any case and even more, with restartable signals it is just
> exactly no difference.


Actually, I considered the same thing:

>--- 1.49/net/ipv4/tcp.c	Mon Oct 20 22:27:42 2003
>+++ edited/net/ipv4/tcp.c	Sun Oct 26 17:59:14 2003
>@@ -1536,9 +1536,15 @@
> 		struct sk_buff *skb;
> 		u32 offset;
> 
>-		/* Are we at urgent data? Stop if we have read anything. */
>-		if (copied && tp->urg_data && tp->urg_seq == *seq)
>-			break;
>+		/* Are we at urgent data? Stop if we have read anything or have SIGURG pending. */
>+		if (tp->urg_data && tp->urg_seq == *seq) {
>+			if (copied)
>+				break;
>+			if (signal_pending(current)) {
>+				copied = timeo ? sock_intr_errno(timeo) : -EAGAIN;
>+				break;
>+			}
>+		}
> 
> 		/* Next get a buffer. */
> 

as a reliable workaround for SIGURG situation, but then "figured out"
that this is not necessary (which was mistake). Though at the moment I still
do not understand what exactly is so wrong with that my argument, the signal
should be processed before read() returns, should not it? Maybe, rlogin
longjmp()s or something like this...

Alexey

Re: Linux 2.6.0-test9

[Tommy Christensen]

kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> 
>>And Alexey apparently tried to do the "FIXME" part, but without thinking 
>>about the SIGURG part.
> 
> 
> Actually, it was thought a lot for several linux-2.x. :-)
> 
> 
> 
>>We _need_ to stop at urgent data and we _should_ return -EINTR, and let
>>the SIGURG handler do the URG read. Otherwise we'll lose urgent data (or
>>we'll just read it inline without realizing that it was urgent data).
> 
> 
> The patch was expected not to break this property. Alas, something
> is overlooked yet. I still do not understand what exactly is broken,
> I feel I have to find some rlogin to experiment in vivo.

Hi Alexey

I think the patch breaks things because it consumes (or rather skips)
the urgent data ( in the code after the label found_ok_skb: ).

Since this happens before the SIGURG handler is run, it won't find
any urgent data.

What do you think?

The patch by Linus seems to be fine though.

-Tommy

Re: Linux 2.6.0-test9

[kuznet]

Hello!

> I think the patch breaks things because it consumes (or rather skips)
> the urgent data ( in the code after the label found_ok_skb: ).
> 
> Since this happens before the SIGURG handler is run, it won't find
> any urgent data.
> 
> What do you think?

Yes, you are absolutely right. I missed exactly this thing.


> The patch by Linus seems to be fine though.

I think the patch suggested by Linus is 100% correct and
in fact it is the only solution.

Alexey

Re: Linux 2.6.0-test9

[John Bradford]

> > > If the idea is to tell people to read the post-Halowe'en doc and a year
> > > of LKML, it is much the same as telling people to wait for a
> > > distribution.
> > 
> > Isn't the purpose of the post-haloween doc to tell people what
> > changed and what needed to be upgraded?  What about the
> > linux/Documentation/Changes file?
> 
> Given that it is a year out of date and general in nature, it's still a
> pretty useful docuement to someone who does a lot of fiddling anyway.
> But what I think would be very useful would be a small (one screen?)
> HTML doc with links to versions which are current today, one page each
> for a few major distros covering tweaks to startup file and the like,
> and a page of things which aren't mentioned in the post Halowe'en doc,
> like the things that aren't available in modules anymore.

Or a filter which takes a 2.4 .config file as input, and outputs the
relevant sections of the post-Haloween document based on that :-).

John.

Re: Linux 2.6.0-test9

[Bill Davidsen]

On Thu, 30 Oct 2003, Russell King wrote:

> On Mon, Oct 27, 2003 at 11:26:44PM +0000, bill davidsen wrote:
> > If the idea is to tell people to read the post-Halowe'en doc and a year
> > of LKML, it is much the same as telling people to wait for a
> > distribution.
> 
> Isn't the purpose of the post-haloween doc to tell people what
> changed and what needed to be upgraded?  What about the
> linux/Documentation/Changes file?

Given that it is a year out of date and general in nature, it's still a
pretty useful docuement to someone who does a lot of fiddling anyway.
But what I think would be very useful would be a small (one screen?)
HTML doc with links to versions which are current today, one page each
for a few major distros covering tweaks to startup file and the like,
and a page of things which aren't mentioned in the post Halowe'en doc,
like the things that aren't available in modules anymore.

Anyway, since I found that even my notes were out of date, and I took
them as I moved machines from 2.5.4x forward to test9, I thought it
would be useful. I'll probably do something for my friends and clients,
but it will definitely be Redhat and Slackware only. I see no enthusiasm
for helping users instead of letting them thrash.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.6.0-test9

[Russell King]

On Mon, Oct 27, 2003 at 11:26:44PM +0000, bill davidsen wrote:
> If the idea is to tell people to read the post-Halowe'en doc and a year
> of LKML, it is much the same as telling people to wait for a
> distribution.

Isn't the purpose of the post-haloween doc to tell people what
changed and what needed to be upgraded?  What about the
linux/Documentation/Changes file?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: Linux 2.6.0-test9

[Bill Davidsen]

On Mon, 27 Oct 2003, Jeff Garzik wrote:

> bill davidsen wrote:
> > In article <20031027182141.GH32168@vic20.blipp.com>,
> > Patrik Wallstrom  <pawal@blipp.com> wrote:
> > 
> > | This patch worked for the Promise-controller:
> > | http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch
> > 
> > If this patch solves the problem, might I hope that it will be
> > considered critical enough a bugfix to get into the mainline? I assume
> > the SATA code added in test9 was intended to work, rather than as a
> > place holder.
> 
> 
> The above patch solves the 'problem' of a particular PCI id not being 
> listed in the driver.
> 
> IOW it _adds_ new hardware support.

Sounds unlikely to be considered a fix for a major problem. Thanks for the
info. Also sounds unlikely to be a fix for any similar problem :-(

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.6.0-test9

[Jeff Garzik]

bill davidsen wrote:
> In article <20031027182141.GH32168@vic20.blipp.com>,
> Patrik Wallstrom  <pawal@blipp.com> wrote:
> 
> | This patch worked for the Promise-controller:
> | http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch
> 
> If this patch solves the problem, might I hope that it will be
> considered critical enough a bugfix to get into the mainline? I assume
> the SATA code added in test9 was intended to work, rather than as a
> place holder.


The above patch solves the 'problem' of a particular PCI id not being 
listed in the driver.

IOW it _adds_ new hardware support.

	Jeff

Re: Linux 2.6.0-test9

[bill davidsen]

In article <UTC200310261059.h9QAxBS13289.aeb@smtp.cwi.nl>,
 <Andries.Brouwer@cwi.nl> wrote:
| > Pls forward.
| 
| Below a keyboard patch I sent to l-k 12 days ago.
| Discussion:
| 
| Petr Vandrovec reported
| 
| > got (twice, but yesterday I rebooted box hard, as I thought that it is dead)
| > strange lockup, where box stopped reacting on keyboard.
| 
| and
| 
| > Oct 14 19:59:18 ppc kernel: i8042.c: e0 <- i8042 (interrupt, kbd, 1) [30115341]
| > Oct 14 19:59:18 ppc kernel: i8042.c: ed -> i8042 (kbd-data) [30115342]
| > Oct 14 19:59:18 ppc kernel: i8042.c: fa <- i8042 (interrupt, kbd, 1) [30115346]
| > Oct 14 19:59:18 ppc kernel: atkbd.c: Unknown key released (translated set 2, code 0x165, data 0xfa, on isa0060/serio0).
| 
| What happens is that the kernel code does an untranslate on the 0xfa
| that is the ACK for 0xed (set LEDs) when 0xe0 preceded. Now the ACK
| is never seen and we hang waiting for it.
| 
| Now 0xfa can be a key scancode or it can be a protocol scancode.
| Only few keyboards use it as a key scancode, and if we always
| interpret it as a protocol scancode then these rare keyboards
| will have a dead key. If we interpret it as a key scancode then
| we have a dead keyboard in case it was protocol.
| 
| The below patch moves the test for ACK and NAK up, so that they
| are always seen as protocol.
| 
| This is just a minimal patch. What I did in 1.1.54 was to keep track of
| commands sent with a flag reply_expected, so that 0xfa could be taken
| as ACK when a reply is expected and as key scancode otherwise.
| That is the better solution, but requires larger surgery.

I would think that knowing when a reply was coming was very desirable, a
keyboard with dead keys is kind of useless if an application uses them
(like any editor which allows function to keystroke binding).

Since you have done the full fix already, is it practical to do it
quickly now? And how does any fix for this map into "really major
bugs?" If the fix is just going to be queued anyway, it might as well
be done really right, assuming that you have the time and inclination,
of course.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.6.0-test9

[bill davidsen]

In article <Pine.LNX.4.44.0310252237510.6370-100000@home.osdl.org>,
Linus Torvalds  <torvalds@osdl.org> wrote:
| 
| On Sun, 26 Oct 2003 Andries.Brouwer@cwi.nl wrote:
| > 
| > I have run 2.6.0-test6 without any problems. Switched
| > to 2.6.0-test9 today. Something involving job control
| > or so is broken. Several of my remote xterms hang.
| 
| Btw, this one sounds like a known bug in bash.
| 
| The bash bug does bad things when setting up pipelines of processes, and
| it assigns the process groups in the wrong order. This causes the tty
| layer to send SIGTTOU if the process touches the tty at just the right
| time, which in turn causes processes to become stuck in STOPPED state.
| It's very timing sensitive, and it apparently became easier to trigger
| within the last month or so, probably because of the scheduler
| interactivity changes.
| 
| You can trigger it under 2.4.x, and in fact it seems to be reasonably easy 
| to see with
| 
| 	while true ; do date | less -E ; done
| 
| which will cause processes to become stuck in stopped state after a while 
| (but because of the timing issues it's not 100% repeatable - you may 
| have to do this for a while).
| 
| You can work around it by building basb without the "PGRP_PIPE" config
| option (which may cause other issues), but Ernie Petrides also had a
| proper fix for it in the bash sources. Last I say (this was end of
| September), Chet Ramey acknowledged the bug but hadn't yet put it in
| standard bash sources.

Suggestion: when the real 2.6.0 comes out, it would be very helpful to
have a document which lists what is needed to upgrade from 2.4 to 2.6
and where to get it. And that the document include information like this
patch you mention, and whatever information is needed to help people
running major distributions.

If the idea is to tell people to read the post-Halowe'en doc and a year
of LKML, it is much the same as telling people to wait for a
distribution. I kept great notes as I built several RH 7.3 and 8.0
machines into 2.6 functionality, and I find that things have moved,
tricks don't work, versions have changed, etc. So a list from the
current Redhat, SuSE, Debian and Slackware at minimum would save people
a lot of problems. Not a major handhold for the clueless, just a list
of issues (emphasis because some people will claim I'm suggesting much
more than I said or meant).

| It's definitely not a kernel bug. I chased it for a while myself, and 
| Ernie proved it quite conclusively.

I found that child-run-first broke some code, not that I wrote but
that I certainly maintained without seeing the subtle issues. There will
be people who claim bugs in forked and threaded cooperating processes.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.6.0-test9

[bill davidsen]

In article <20031027182141.GH32168@vic20.blipp.com>,
Patrik Wallstrom  <pawal@blipp.com> wrote:

| This patch worked for the Promise-controller:
| http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch

If this patch solves the problem, might I hope that it will be
considered critical enough a bugfix to get into the mainline? I assume
the SATA code added in test9 was intended to work, rather than as a
place holder.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.6.0-test9

[Patrik Wallstrom]

On Sun, 26 Oct 2003, Patrik Wallstrom wrote:

> On Sat, 25 Oct 2003, Linus Torvalds wrote:
> 
> > Jeff Garzik:
> >   o [libata] Merge Serial ATA core, and drivers for
> >   o [libata] Integrate Serial ATA driver into kernel tree
> 
> I am happy to see these in the kernel now, but I have yet to get them
> working on my KT6 Delta KT600 motherboard with the VT8237 SATA
> southbridge controller or even the Promise controller.
> 
> These are the devices:
> 
>   Bus  0, device  13, function  0:
>     RAID bus controller: PCI device 105a:3373 (Promise Technology, )
>     (rev 2).
>       IRQ 19.
>       Master Capable.  Latency=96.  Min Gnt=4.Max Lat=18.
>       I/O at 0xec00 [0xec3f].
>       I/O at 0xe800 [0xe80f].
>       I/O at 0xe400 [0xe47f].
>       Non-prefetchable 32 bit memory at 0xdffdb000 [0xdffdbfff].
>       Non-prefetchable 32 bit memory at 0xdffa0000 [0xdffbffff].
> 

This patch worked for the Promise-controller:
http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch

-- 
patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956
                `-> http://www.gnuheter.com/

Re: Linux 2.6.0-test9

[Andries.Brouwer]

> If this is easily repeatable for you, can you test just applying this
> patch on top of plain -test9?

Yes, that works.

Re: Linux 2.6.0-test9

[Mikael Pettersson]

On Sun, 26 Oct 2003 18:10:03 -0800 (PST), Linus Torvalds wrote:
>On Mon, 27 Oct 2003 Andries.Brouwer@cwi.nl wrote:
>> 
>> rlogin followed by "emacs -nw".
>
>Ok. I bet I've never seen it partly because I only use ssh (I don't even
>allow rlogin to any of my machines). But you're right, rlogin certainly
>not only uses OOB data, but uses SIGURG itself. I would actually expect 
>that if we delay the SIGURG until after we've read the URG data, the child 
>process that wants to actually read the URG data will trivially hang, 
>waiting for it.
>
>If this is easily repeatable for you, can you test just applying this
>patch on top of plain -test9? It's not the patch I'd actually do in real 
>life, but it's the minimal patch to verify that it's really SIGURG and 
>urgent data that is the thing you see. Sounds very likely, but it would be 
>good to really verify.

This patch does fix the rlogin + emacs -nw problems.

/Mikael

>--- 1.49/net/ipv4/tcp.c	Mon Oct 20 22:27:42 2003
>+++ edited/net/ipv4/tcp.c	Sun Oct 26 17:59:14 2003
>@@ -1536,9 +1536,15 @@
> 		struct sk_buff *skb;
> 		u32 offset;
> 
>-		/* Are we at urgent data? Stop if we have read anything. */
>-		if (copied && tp->urg_data && tp->urg_seq == *seq)
>-			break;
>+		/* Are we at urgent data? Stop if we have read anything or have SIGURG pending. */
>+		if (tp->urg_data && tp->urg_seq == *seq) {
>+			if (copied)
>+				break;
>+			if (signal_pending(current)) {
>+				copied = timeo ? sock_intr_errno(timeo) : -EAGAIN;
>+				break;
>+			}
>+		}
> 
> 		/* Next get a buffer. */
> 

Re: Linux 2.6.0-test9

[David S. Miller]

I'm going to just revert the changeset in the networking
fixes I send to Linus today.

If we resolve this some other way, that's fine and the
original change is in the revision history for people
to refer to.

Re: Linux 2.6.0-test9

[Andrew Morton]

"P. Christeas" <p_christ@hol.gr> wrote:
>
> One more, (as reported a few weeks ago):
> rmmod aic7xxx 
> will fail, as this module uses some wrong locks. This will also block sleeping 
> (tested w. ACPI) if the module is there.
> IMHO this module is crucial to many systems.

The rmmod works OK for me, in the sense that the module is removed, the
kernel doesn't crash and the module can be reloaded.

But yes, there are several locking problems in there:

- ahc_free() now sleeps, deep down in the kobject layer somewhere (it
  calls /sbin/hotplug).

  This is a likely fix for that:

--- 25/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c~aic7xxx-sleep-in-spinlock-fix	2003-10-26 18:51:45.000000000 -0800
+++ 25-akpm/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c	2003-10-26 18:52:11.000000000 -0800
@@ -100,9 +100,10 @@ ahc_linux_pci_dev_remove(struct pci_dev 
 		ahc_lock(ahc, &s);
 		ahc_intr_enable(ahc, FALSE);
 		ahc_unlock(ahc, &s);
-		ahc_free(ahc);
 	}
 	ahc_list_unlock(&l);
+	if (ahc)
+		ahc_free(ahc);
 }
 #endif /* !LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0) */
 


- ahc_linux_kill_dv_thread() is called under ahc_list_lock(), but it sleeps.



> I'm just repeating this issue, as I cannot see any patch for that. Justin has 
> not replied (I will need to be CC'ed). Andrew, who's the maintainer?

Justin is.

> I wish I 
> could help myself solve that, but fixing SMP-safe locks seems the hardest 
> thing I could do here. Somebody has to help here.


Well we can live with the CONFIG_DEBUG_SPINLOCK_SLEEP warnings I guess. 
But you don't actually say what goes wrong when you run rmmod.  Does the
kernel oops?  Lock up?  What?

Re: Linux 2.6.0-test9

[Linus Torvalds]

On Mon, 27 Oct 2003 Andries.Brouwer@cwi.nl wrote:
> 
> rlogin followed by "emacs -nw".

Ok. I bet I've never seen it partly because I only use ssh (I don't even
allow rlogin to any of my machines). But you're right, rlogin certainly
not only uses OOB data, but uses SIGURG itself. I would actually expect 
that if we delay the SIGURG until after we've read the URG data, the child 
process that wants to actually read the URG data will trivially hang, 
waiting for it.

If this is easily repeatable for you, can you test just applying this
patch on top of plain -test9? It's not the patch I'd actually do in real 
life, but it's the minimal patch to verify that it's really SIGURG and 
urgent data that is the thing you see. Sounds very likely, but it would be 
good to really verify.

I think that this is, btw, the _right_ place for checking that SIGURG
anyway.

The case of being at urgent data really is a special case, and I think it
was a mistake to try to have the signal_pending() check in a common code
sequence - it's really two totally differenct cases when we check for
"should we stop here due to SIGURG handling", or "should we return because
we would have to wait for more data and we have a signal pending".

Yes, both cases test for "signal_pending(current)", but the SIGURG case
really could test for just "do we have SIGURG pending", not just "any
signal".

		Linus

--- 1.49/net/ipv4/tcp.c	Mon Oct 20 22:27:42 2003
+++ edited/net/ipv4/tcp.c	Sun Oct 26 17:59:14 2003
@@ -1536,9 +1536,15 @@
 		struct sk_buff *skb;
 		u32 offset;
 
-		/* Are we at urgent data? Stop if we have read anything. */
-		if (copied && tp->urg_data && tp->urg_seq == *seq)
-			break;
+		/* Are we at urgent data? Stop if we have read anything or have SIGURG pending. */
+		if (tp->urg_data && tp->urg_seq == *seq) {
+			if (copied)
+				break;
+			if (signal_pending(current)) {
+				copied = timeo ? sock_intr_errno(timeo) : -EAGAIN;
+				break;
+			}
+		}
 
 		/* Next get a buffer. */
 

Re: Linux 2.6.0-test9

[Andries.Brouwer]

> Andries, what was the situation that led to a TCP lockup?

rlogin followed by "emacs -nw".

rlogin uses SIGURG for communication.

It is not the TCP protocol that is locked up.
Keystrokes are transmitted and the results are sent back.
But the reader half of rlogin hangs.

Andries

Re: Linux 2.6.0-test9

[P. Christeas]

>From Andries.Brouwer:
> Three things:
> 
> 2.6.0t9 still can leave the user with a dead keyboard
> If Vojtech does not provide a better patch I suppose
> you should apply my patch of a few days ago.
> 
> Within a few days two people have reported that they cannot
> mount a FAT fs that 2.4 and Windows handle fine.
> Probably also that should be fixed, for example with
> my patch from yesterday.

One more, (as reported a few weeks ago):
rmmod aic7xxx 
will fail, as this module uses some wrong locks. This will also block sleeping 
(tested w. ACPI) if the module is there.
IMHO this module is crucial to many systems.

I'm just repeating this issue, as I cannot see any patch for that. Justin has 
not replied (I will need to be CC'ed). Andrew, who's the maintainer? I wish I 
could help myself solve that, but fixing SMP-safe locks seems the hardest 
thing I could do here. Somebody has to help here.

Re: Linux 2.6.0-test9

[Marco Roeland]

On Sunday Oktober 26th 2003 at 10:32 uur Shane Shrybman wrote:

> gcc2.96, from Mandrake 8.2 (I would suspect that Redhat 7.* releases are
> in this boat too) has a bug that prevents the compilation -test9.

Yes, several people have reported this for the gcc 2.96 included in
RedHat 7.[23] as well. It started with 2.6.0-test8.

> fs/proc/array.c: In function `proc_pid_stat':
> fs/proc/array.c:398: Unrecognizable insn:
> (insn/i 1337 1673 1667 (parallel[ 
> ...

> and a little patch that resolves it for me
> 
> diff -ur linux-2.6.0-test9/fs/proc/array.c
> linux-2.6.0-test9-A/fs/proc/array.c
> --- linux-2.6.0-test9/fs/proc/array.c   Sat Oct 25 18:21:46 2003
> +++ linux-2.6.0-test9-A/fs/proc/array.c Sat Oct 25 19:14:15 2003
> @@ -295,7 +295,8 @@
>  {
>         unsigned long vsize, eip, esp, wchan;
>         long priority, nice;
> -       int tty_pgrp = -1, tty_nr = 0;
> +       int tty_pgrp = -1;
> +       volatile int tty_nr = 0;
>         sigset_t sigign, sigcatch;
>         char state;
>         int res;
> 

Here is another patch which solves the same problem in a different way!
There was a thread with some discussion on it several days ago; I objected
against the apparent magic in the use of 'volatile' here. It obviously
solves the compilation for you, but I wonder is there some deeper reason
it's used?

The following different patch (sent earlier in the mentioned thread)
'solves' this compilation issue as well by just simplifying and factoring
out some stuff. It's against 2.6.0-test8 but applies against 2.6.0-test9
and 2.6.0-test8-mm1 as well.

--- linux-2.6.0-test8/fs/proc/array.c.orig	2003-10-21 16:18:40.000000000 +0200
+++ linux-2.6.0-test8/fs/proc/array.c	2003-10-23 09:30:27.000000000 +0200
@@ -302,6 +302,7 @@
 	pid_t ppid;
 	int num_threads = 0;
 	struct mm_struct *mm;
+	unsigned long long starttime;
 
 	state = *get_task_state(task);
 	vsize = eip = esp = 0;
@@ -343,9 +344,7 @@
 	read_lock(&tasklist_lock);
 	ppid = task->pid ? task->real_parent->pid : 0;
 	read_unlock(&tasklist_lock);
-	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
-%lu %lu %lu %lu %lu %ld %ld %ld %ld %d %ld %llu %lu %ld %lu %lu %lu %lu %lu \
-%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
+	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu ",
 		task->pid,
 		task->comm,
 		state,
@@ -355,7 +354,9 @@
 		tty_nr,
 		tty_pgrp,
 		task->flags,
-		task->min_flt,
+		task->min_flt);
+	starttime = jiffies_64_to_clock_t(task->start_time - INITIAL_JIFFIES);
+	res += sprintf(buffer + res,"%lu %lu %lu %lu %lu %ld %ld %ld %ld %d %ld %llu %lu %ld %lu %lu %lu %lu %lu ",
 		task->cmin_flt,
 		task->maj_flt,
 		task->cmaj_flt,
@@ -367,15 +368,15 @@
 		nice,
 		num_threads,
 		jiffies_to_clock_t(task->it_real_value),
-		(unsigned long long)
-		    jiffies_64_to_clock_t(task->start_time - INITIAL_JIFFIES),
+		starttime,
 		vsize,
 		mm ? mm->rss : 0, /* you might want to shift this left 3 */
 		task->rlim[RLIMIT_RSS].rlim_cur,
 		mm ? mm->start_code : 0,
 		mm ? mm->end_code : 0,
 		mm ? mm->start_stack : 0,
-		esp,
+		esp);
+	res += sprintf(buffer + res,"%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
 		eip,
 		/* The signal information here is obsolete.
 		 * It must be decimal for Linux 2.0 compatibility.

Re: Linux 2.6.0-test9

[Shane Shrybman]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

Hi,

gcc2.96, from Mandrake 8.2 (I would suspect that Redhat 7.* releases are
in this boat too) has a bug that prevents the compilation -test9.

fs/proc/array.c: In function `proc_pid_stat':
fs/proc/array.c:398: Unrecognizable insn:
(insn/i 1337 1673 1667 (parallel[ 
            (set (reg:SI 0 eax)
                (asm_operands ("") ("=a") 0[ 
                        (reg:DI 1 edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("include/linux/times.h") 37))
            (set (reg:SI 1 edx)
                (asm_operands ("") ("=d") 1[ 
                        (reg:DI 1 edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("include/linux/times.h") 37))
            (clobber (reg:QI 19 dirflag))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ] ) -1 (insn_list 1331 (nil))
    (nil))
fs/proc/array.c:398: confused by earlier errors, bailing out
make[2]: *** [fs/proc/array.o] Error 1
make[1]: *** [fs/proc] Error 2
make: *** [fs] Error 2

and a little patch that resolves it for me

diff -ur linux-2.6.0-test9/fs/proc/array.c
linux-2.6.0-test9-A/fs/proc/array.c
--- linux-2.6.0-test9/fs/proc/array.c   Sat Oct 25 18:21:46 2003
+++ linux-2.6.0-test9-A/fs/proc/array.c Sat Oct 25 19:14:15 2003
@@ -295,7 +295,8 @@
 {
        unsigned long vsize, eip, esp, wchan;
        long priority, nice;
-       int tty_pgrp = -1, tty_nr = 0;
+       int tty_pgrp = -1;
+       volatile int tty_nr = 0;
        sigset_t sigign, sigcatch;
        char state;
        int res;

Attached as well in case it gets mangled.

Regards,

Shane

[-- Attachment #2: gcc2.96.patch --]
[-- Type: text/x-patch, Size: 428 bytes --]

diff -ur linux-2.6.0-test9/fs/proc/array.c linux-2.6.0-test9-A/fs/proc/array.c
--- linux-2.6.0-test9/fs/proc/array.c	Sat Oct 25 18:21:46 2003
+++ linux-2.6.0-test9-A/fs/proc/array.c	Sat Oct 25 19:14:15 2003
@@ -295,7 +295,8 @@
 {
 	unsigned long vsize, eip, esp, wchan;
 	long priority, nice;
-	int tty_pgrp = -1, tty_nr = 0;
+	int tty_pgrp = -1;
+	volatile int tty_nr = 0;
 	sigset_t sigign, sigcatch;
 	char state;
 	int res;

Re: Linux 2.6.0-test9

[OGAWA Hirofumi]

Andries.Brouwer@cwi.nl writes:

> > Pls forward.
> 
> The first FAT entry should have the media byte (0xf0,0xf8,...,0xff)
> extended with all 1 bits in the first FAT entry.
> Checking this is a good idea, it prevents us from mounting garbage
> as FAT - there is no good magic for FAT.
> Unfortunately, Windows does not enforce this, and 2.4 doesn't either.
> It turns out that there are filesystems around (two reports so far)
> that have a zero first FAT entry, and work under Windows and 2.4 but
> fail to mount under 2.6.
> 
> So, the below weakens the test.

Looks good to me. I have no objection.


However, the following may be a bit useful info.

I tested on win2k and win95 installed at now.

win95's scandisk reported and fixed this problem.
win2k's chkdsk detect problem and fixed. But GUI tool doesn't detect,
and can't fixed.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: Linux 2.6.0-test9

[Patrik Wallstrom]

On Sat, 25 Oct 2003, Linus Torvalds wrote:

> Jeff Garzik:
>   o [libata] Merge Serial ATA core, and drivers for
>   o [libata] Integrate Serial ATA driver into kernel tree

I am happy to see these in the kernel now, but I have yet to get them
working on my KT6 Delta KT600 motherboard with the VT8237 SATA
southbridge controller or even the Promise controller.

These are the devices:

  Bus  0, device  13, function  0:
    RAID bus controller: PCI device 105a:3373 (Promise Technology, )
    (rev 2).
      IRQ 19.
      Master Capable.  Latency=96.  Min Gnt=4.Max Lat=18.
      I/O at 0xec00 [0xec3f].
      I/O at 0xe800 [0xe80f].
      I/O at 0xe400 [0xe47f].
      Non-prefetchable 32 bit memory at 0xdffdb000 [0xdffdbfff].
      Non-prefetchable 32 bit memory at 0xdffa0000 [0xdffbffff].

Bus  0, device  15, function  0:
    RAID bus controller: PCI device 1106:3149 (VIA Technologies, In)
    (rev 128).
      IRQ 16.
      Master Capable.  Latency=32.
      I/O at 0xd800 [0xd807].
      I/O at 0xd400 [0xd403].
      I/O at 0xd000 [0xd007].
      I/O at 0xcc00 [0xcc03].
      I/O at 0xc800 [0xc80f].
      I/O at 0xc400 [0xc4ff].


And I am booting the kernel with these parameters to not let the IDE
drivers catch the SATA-drives:
ide2=noprobe ide3=noprobe hde=noprobe hdg=noprobe apm=power-off

I am booting from a working IDE drive, to see if I can get the
SATA-drives working:

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DPTA-372050, ATA DISK drive
hdb: HL-DT-STDVD-ROM GDR8162B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(33)
 hda: hda1 hda2 hda3
hdb: ATAPI 48X DVD-ROM drive, 256kB Cache, UDMA(33)


And here is the SATA on the Promise chipset (SATA378 TX2plus):
libata version 0.75 loaded.
sata_via version 0.11
ata1: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 16
ata2: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 16
ATA: abnormal status 0x7F on port 0xD807
scsi0 : sata_via
ata1: thread exiting
ATA: abnormal status 0x7F on port 0xD007
ata2: thread exiting
scsi1 : sata_via
(kernel continues)

SATA on the VIA-chipset (VIA Serial ATA RAID):
ata1: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 16
ata2: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 16
ata1: dev 0 ATA, max UDMA/133, 156301488 sectors (lba48)
ata1: dev 0 configured for UDMA/133
scsi0 : sata_via
ata2: dev 0 ATA, max UDMA/133, 156301488 sectors (lba48)
ata2: dev 0 configured for UDMA/133
scsi1 : sata_via
  Vendor: ATA       Model: ST380013AS        Rev: 0.75
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: ST380013AS        Rev: 0.75
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
SCSI device sda: drive cache: write through
 sda:<3>ata1: DMA timeout, stat 0x4
(then hangs the kernel)

What can I do to make either the Promise or the VIA interface work
fine with the SATA disks?

-- 
patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956
                `-> http://www.gnuheter.com/

Re: Linux 2.6.0-test9

[Andries.Brouwer]

> Pls forward.

The first FAT entry should have the media byte (0xf0,0xf8,...,0xff)
extended with all 1 bits in the first FAT entry.
Checking this is a good idea, it prevents us from mounting garbage
as FAT - there is no good magic for FAT.
Unfortunately, Windows does not enforce this, and 2.4 doesn't either.
It turns out that there are filesystems around (two reports so far)
that have a zero first FAT entry, and work under Windows and 2.4 but
fail to mount under 2.6.

So, the below weakens the test.

Andries

[one report was with a SmartMedia card, the other with an
Archos Jukebox Recorder 20]

diff -u --recursive --new-file -X /linux/dontdiff a/fs/fat/inode.c b/fs/fat/inode.c
--- a/fs/fat/inode.c	Wed Oct 22 23:25:26 2003
+++ b/fs/fat/inode.c	Sun Oct 26 02:31:24 2003
@@ -964,13 +964,17 @@
 		error = first;
 		goto out_fail;
 	}
-	if (FAT_FIRST_ENT(sb, media) != first
-	    && (media != 0xf8 || FAT_FIRST_ENT(sb, 0xfe) != first)) {
-		if (!silent) {
+	if (FAT_FIRST_ENT(sb, media) == first) {
+		/* all is as it should be */
+	} else if (media == 0xf8 && FAT_FIRST_ENT(sb, 0xfe) == first) {
+		/* bad, reported on pc9800 */
+	} else if (first == 0) {
+		/* bad, reported with a SmartMedia card */
+	} else {
+		if (!silent)
 			printk(KERN_ERR "FAT: invalid first entry of FAT "
 			       "(0x%x != 0x%x)\n",
 			       FAT_FIRST_ENT(sb, media), first);
-		}
 		goto out_invalid;
 	}
 

Re: Linux 2.6.0-test9

[Andries.Brouwer]

> Pls forward.

Below a keyboard patch I sent to l-k 12 days ago.
Discussion:

Petr Vandrovec reported

> got (twice, but yesterday I rebooted box hard, as I thought that it is dead)
> strange lockup, where box stopped reacting on keyboard.

and

> Oct 14 19:59:18 ppc kernel: i8042.c: e0 <- i8042 (interrupt, kbd, 1) [30115341]
> Oct 14 19:59:18 ppc kernel: i8042.c: ed -> i8042 (kbd-data) [30115342]
> Oct 14 19:59:18 ppc kernel: i8042.c: fa <- i8042 (interrupt, kbd, 1) [30115346]
> Oct 14 19:59:18 ppc kernel: atkbd.c: Unknown key released (translated set 2, code 0x165, data 0xfa, on isa0060/serio0).

What happens is that the kernel code does an untranslate on the 0xfa
that is the ACK for 0xed (set LEDs) when 0xe0 preceded. Now the ACK
is never seen and we hang waiting for it.

Now 0xfa can be a key scancode or it can be a protocol scancode.
Only few keyboards use it as a key scancode, and if we always
interpret it as a protocol scancode then these rare keyboards
will have a dead key. If we interpret it as a key scancode then
we have a dead keyboard in case it was protocol.

The below patch moves the test for ACK and NAK up, so that they
are always seen as protocol.

This is just a minimal patch. What I did in 1.1.54 was to keep track of
commands sent with a flag reply_expected, so that 0xfa could be taken
as ACK when a reply is expected and as key scancode otherwise.
That is the better solution, but requires larger surgery.

Andries


diff -u --recursive --new-file -X /linux/dontdiff a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
--- a/drivers/input/keyboard/atkbd.c	Sun Oct 26 00:00:10 2003
+++ b/drivers/input/keyboard/atkbd.c	Sun Oct 26 02:28:24 2003
@@ -184,11 +184,19 @@
 		atkbd->resend = 0;
 #endif
 
+	switch (code) {
+		case ATKBD_RET_ACK:
+			atkbd->ack = 1;
+			goto out;
+		case ATKBD_RET_NAK:
+			atkbd->ack = -1;
+			goto out;
+	}
+
 	if (atkbd->translated) do {
 
 		if (atkbd->emul != 1) {
-			if (code == ATKBD_RET_EMUL0 || code == ATKBD_RET_EMUL1 ||
-			    code == ATKBD_RET_ACK || code == ATKBD_RET_NAK)
+			if (code == ATKBD_RET_EMUL0 || code == ATKBD_RET_EMUL1)
 				break;
 			if (code == ATKBD_RET_BAT) {
 				if (!atkbd->bat_xl)
@@ -212,15 +220,6 @@
 
 	} while (0);
 
-	switch (code) {
-		case ATKBD_RET_ACK:
-			atkbd->ack = 1;
-			goto out;
-		case ATKBD_RET_NAK:
-			atkbd->ack = -1;
-			goto out;
-	}
-
 	if (atkbd->cmdcnt) {
 		atkbd->cmdbuf[--atkbd->cmdcnt] = code;
 		goto out;

Re: Linux 2.6.0-test9

[Andries.Brouwer]

    From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

    Andries.Brouwer@cwi.nl writes:

    > Within a few days two people have reported that they cannot
    > mount a FAT fs that 2.4 and Windows handle fine.
    > Probably also that should be fixed, for example with
    > my patch from yesterday.

    Was the other report by private email?

Yes. Mark McPherson wrote:

  I have an Archos Jukebox Recorder 20 which has never been
  re-formatted since I purchased it.  It fails to mount under 2.6 with
  the same report as the flash card, and also mounts successfully under 2.4.
  Patching around the code as you suggested allows it to mount without
  complaint under 2.6.
  Win2K thinks this file system is just fine.

Andries

Re: Linux 2.6.0-test9

[Linus Torvalds]

On Sun, 26 Oct 2003 Andries.Brouwer@cwi.nl wrote:
> 
> I have run 2.6.0-test6 without any problems. Switched
> to 2.6.0-test9 today. Something involving job control
> or so is broken. Several of my remote xterms hang.

Btw, this one sounds like a known bug in bash.

The bash bug does bad things when setting up pipelines of processes, and
it assigns the process groups in the wrong order. This causes the tty
layer to send SIGTTOU if the process touches the tty at just the right
time, which in turn causes processes to become stuck in STOPPED state.
It's very timing sensitive, and it apparently became easier to trigger
within the last month or so, probably because of the scheduler
interactivity changes.

You can trigger it under 2.4.x, and in fact it seems to be reasonably easy 
to see with

	while true ; do date | less -E ; done

which will cause processes to become stuck in stopped state after a while 
(but because of the timing issues it's not 100% repeatable - you may 
have to do this for a while).

You can work around it by building basb without the "PGRP_PIPE" config
option (which may cause other issues), but Ernie Petrides also had a
proper fix for it in the bash sources. Last I say (this was end of
September), Chet Ramey acknowledged the bug but hadn't yet put it in
standard bash sources.

It's definitely not a kernel bug. I chased it for a while myself, and 
Ernie proved it quite conclusively.

		Linus

Re: Linux 2.6.0-test9

[OGAWA Hirofumi]

Andries.Brouwer@cwi.nl writes:

> Within a few days two people have reported that they cannot
> mount a FAT fs that 2.4 and Windows handle fine.
> Probably also that should be fixed, for example with
> my patch from yesterday.

Was the another peopel reported by private email?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: Linux 2.6.0-test9

[Andries.Brouwer]

Three things:

2.6.0t9 still can leave the user with a dead keyboard
If Vojtech does not provide a better patch I suppose
you should apply my patch of a few days ago.

Within a few days two people have reported that they cannot
mount a FAT fs that 2.4 and Windows handle fine.
Probably also that should be fixed, for example with
my patch from yesterday.

I have run 2.6.0-test6 without any problems. Switched
to 2.6.0-test9 today. Something involving job control
or so is broken. Several of my remote xterms hang.
Will investigate later.

Andries

Re: Linux 2.6.0-test9

[Jose Luis Domingo Lopez]

On Saturday, 25 October 2003, at 12:09:10 -0700,
Linus Torvalds wrote:

> If it corrupts data, is a security issue, or causes lockups or just basic
> nonworkingness: and this happens on hardware that _normal_ people are
> expected to have, then it's critical.  Otherwise, it's noise and should
> wait.
> 
With respect to security issues, there have been some of them in the past
months, and at least some of them were not fixed back them with the
argument of "development release, will be fixed".

It seems that Alan Cox was the one to keep track of these security
problems, but now that he is on his sabbatical year maybe some of the
fixes are still pending, because nobody remembers there were any ;-)

Are these problems already fixed, and I missed them, or there are still
some to be addressed ?.

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Sid (Linux 2.6.0-test8-mm1)

Re: Linux 2.6.0-test9

[Linus Torvalds]

On Sat, 25 Oct 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> Hmm...  Do you count the stuff like "driver foo dereferences after
> kfree()" as major when fix is to reorder two consequent lines in said
> driver?

The smaller and more obvious the change is, the less critical the bug has 
to be.

If it's a really unlikely bug, and fixing it requires some fundamental 
changes, I consider the fix to be potentially more dangerous than the bug. 
But if the fix is re-ordering two lines in really obvious ways, and the 
bug itself is potentially nasty, the fix obviously goes in.

It's a matter of balancing the potential downside of a fix (which is 
unknown, but tends to be relative to how big the patch is) with the 
benefits (which should be known).

> Proposed rules:
> 	a) all changes must be local and separate.  Anything that affects
> more than one place is either splittable, in which case it's more than
> one change, or doesn't belong there.
> 	b) chunks stay separate until they go into the main tree.  IOW,
> they are fed one by one (when merges are OK) and they become separate
> changesets.
> 	c) all chunks must be mergable into -STABLE.  IOW, the rules are
> the same as for 2.6.1 - as far as merging into that tree is concerned,
> we are not in -RC anymore.

Yes, but at this point I actually want to be _more_ strict that just (c).

There are things that I bet Andrew will be willing to apply to -STABLE:  
things like architecture updates etc that clearly fix stuff. But right now
I want to avoid even that kind of noise: if it doesn't clearly help
_testing_ of stability, I'm just not interested at this point.

So for example, in the last week I just dropped some S390 updates without
even looking at them. It was too late - and even if they fix bugs, I don't
see that applying those patches simply would matter for 2.6.0 any more.  

So for example: I am pretty happy with how the size of the -test8 and 
-test9 patches have been shrinking, but even -test9 was big enough that I 
couldn't say that we're clearly "asymptotically approaching a stable 
kernel". At some point "noise patches" are bad if only because they make 
it less clear what the general status of the tree is.

In particular, if the 2.6.0-test10 patch is just 30kB compressed, and I
can just page through it with "less" and see that every single small part
of the patch was pretty clear and not something really scary, I'll be a
_lot_ happier about passing the thing off to Andrew. In contrast, if the
patch is full of stuff that isn't really obvious, I'm going to be less
happy, and worry more about what the side effects are.

		Linus

Re: Linux 2.6.0-test9

[viro]

On Sat, Oct 25, 2003 at 12:09:10PM -0700, Linus Torvalds wrote:
 
> If it corrupts data, is a security issue, or causes lockups or just basic
> nonworkingness: and this happens on hardware that _normal_ people are
> expected to have, then it's critical.  Otherwise, it's noise and should
> wait.

Hmm...  Do you count the stuff like "driver foo dereferences after kfree()"
as major when fix is to reorder two consequent lines in said driver?  I'm
perfectly happy with sitting on that until 2.6.0 or later, but we might be
better off with a separate tree that would contain *only* such stuff and
would keep track of it for later merges.

Proposed rules:
	a) all changes must be local and separate.  Anything that affects
more than one place is either splittable, in which case it's more than
one change, or doesn't belong there.
	b) chunks stay separate until they go into the main tree.  IOW,
they are fed one by one (when merges are OK) and they become separate
changesets.
	c) all chunks must be mergable into -STABLE.  IOW, the rules are
the same as for 2.6.1 - as far as merging into that tree is concerned,
we are not in -RC anymore.

Hell, I could even start using BK for that...

Re: Linux 2.6.0-test9

[Marcelo Tosatti]

On Sat, 25 Oct 2003, Linus Torvalds wrote:

> If this works out, then I'll submit -test10 to Andrew Morton, and if he 
> takes it we'll probably have a real 2.6.0 after a final shakedown. So try 
> to help, please. We'll all be happier.

So you mean Andrew will take care of the tree as soon as -test10 is out ? 

When you plan to start the next development version ? 

Linux 2.6.0-test9

[Linus Torvalds]

Ok, 2.6.0-test9 is out there in all the normal places..

First off, I have to say that this week has been a lot better than last
week. I've been cursing at some developers a _lot_ less: while a lot of
people wanted to sync up with me after the -test7 "stability freeze"  
announcements with stuff that wasn't really about stability, that dropped
off a lot this week, and I didn't have to be rude to people very much at
all.

There's some XFS and cifs updates here, but even they were pretty benign
and largely just bugfixes. Oh, and the SATA driver got included, which you
either disable or which allows people to use modern hardware. 

Anyway, while I've been happy with the progress from -test7, I want to see
this total stability freeze work even better. The test9 patch is about 
120kB compressed - which is small for a week of work, but is still more 
than I want to see before a stable release.

So guys, let's work on this even more for test10. I'm going to _totally_
ignore patches that aren't for major bugs. Don't send me anything that
_others_ wouldn't consider horribly critical.

In other words, even if you think that something is the most important
piece of software in the world, if you can't make aunt Tilly up the street
say "oh, but that would be a show-stopper", then don't bother sending it 
to me.

If it corrupts data, is a security issue, or causes lockups or just basic
nonworkingness: and this happens on hardware that _normal_ people are
expected to have, then it's critical.  Otherwise, it's noise and should
wait.

If this works out, then I'll submit -test10 to Andrew Morton, and if he 
takes it we'll probably have a real 2.6.0 after a final shakedown. So try 
to help, please. We'll all be happier.

			Linus

----
Summary of changes from v2.6.0-test8 to v2.6.0-test9
============================================

Alan Stern:
  o USB: fix for earlier unusual_devs.h patch

Alex Williamson:
  o ia64: trivial ia64 numa/discontig fixes

Alexander Schulz:
  o [ARM PATCH] 1692/1: Shark: PCIMEM_BASE

Alexander Viro:
  o Fix initrd with devfs enabled
  o fix for do_tty_hangup() access of kfreed memory

Alexey Kuznetsov:
  o TCP: do not return -EINTR, when data are available for read()

Andrew Morton:
  o [NET]: Make register_netdevice return correct error when driver
    init function fails
  o fix split_vma vs. invalidate_mmap_range_list race
  o scsi: handle zero-length requests
  o ia32 limit_regions update
  o Fix unmap_vmas() compile warning
  o Time precision, adjtime(x) vs. gettimeofday
  o atp870u oops fix
  o tmpfs 1/7 LTP ENAMETOOLONG fix
  o tmpfs 2/7 LTP S_ISGID on directories fix
  o tmpfs 3/7 swapoff/truncate race fix
  o tmpfs 4/7 getpage/truncate race fix
  o tmpfs 5/7 writepage/truncate race fix
  o tmpfs 6/7 write i_size_write
  o tmpfs 7/7 write mark_page_accessed
  o Quota deadlock fix
  o export system_running to other files
  o Kill early might_sleep warnings
  o digi_acceleport.c has bogus "address of" operator
  o fix microcode.c for older gcc's
  o Fix mtd printk warnings
  o fs/binfmt_elf.c:load_elf_binary() doesn't verify interpreter arch
  o JBD kfree() fix
  o Fix JBD memory leak
  o fix low-memory BUG in slab
  o fix for register_cpu()
  o fix bluetooth broken compilation when PROC_FS=n
  o make printk more robust with "null" pointers
  o kcapi.c CONFIG_MODULES=n build fix
  o DRM modprobe retval fix
  o parport_pc not releasing all ioports
  o Fix oops with CONFIG_MCA=y
  o Fix another CONFIG_MCA=y oops
  o ipc msg race fix
  o io scheduler oops fixes
  o pcm_native locking fix
  o Fix toshiba.c and neofb.c for CONFIG_PROC_FS=n
  o v850: Workaround for tty-driver init-order problem
  o v850: Don't reserve root-filesystem memory twice
  o v850: Use irqreturn_t on rte-me2-cb platform
  o Add needed __devexit_p's to two gameport drivers
  o /dev/mem range checking
  o Kill unneccessary debug printk
  o Fix arlan compilation with CONFIG_PROC_FS=n
  o Altix console driver
  o befs oops fix
  o early_serial_setup array bounds check

Arnaldo Carvalho de Melo:
  o leaking info on drivers/usb

Arun Sharma:
  o ia64: make strace of ia32 processes work again
  o ia64: don't touch IA-32 segment descriptors too early
  o ia64: fix broken __emul_prefix

Bart De Schuymer:
  o [EBTABLES]: Adjust skb->pkt_type when necessary

Bartlomiej Zolnierkiewicz:
  o fix drivers/ide/pci/siimage.c for PROC_FS=n
  o fix drivers/ide/pci/cmd640.c for CONFIG_PCI=n

Bjorn Helgaas:
  o ia64: fix EFI memory map trimming
  o ia64: prevent "dd if=/dev/mem" crash

Carsten Busse:
  o USB: one more digicam for unusual_devs.h

Dan Aloni:
  o [NET]: Fix sysctl breakage during network device renaming

Dave Jiang:
  o [ARM PATCH] 1691/1: Fix IOP321 platform booting in 2.6

David Brownell:
  o USB: ACM USB modem fixes
  o USB: fix usb-storage self-deadlock
  o USB: usb enumeration clears full speed ep0 state

David Mosberger:
  o ia64: Add missing exports to modules build again
  o ia64: Fix printk format error
  o ia64: Don't mix code and declarations (not C90-compliant)
  o ia64: Sync with i386 irq.c (deadlock avoidance for certain
    disable_irq()/ enable_irq() sequences).
  o ia64: Based on patch by Arun Sharma: fix IA-32 subsystem to support
    NPTL
  o ia64: Fix IA-32 NPTL fixes so things compile again
  o ia64: Fix efi_mem_type() and efi_mem_attributes() to avoid
    potential underflows.  In my case, the underflows occurred with the
    first memory descriptor which got trimmed down to a size of 0.
  o ia64: Patch by Arun Sharma: fix allocation/handling of GDT shared
    page (the old code was inconsistent and in places still assumed
    there is both a GDT and a TSS shared page, but the latter was
    removed a long time ago).
  o ia64: Sync with Linus' i386 patch: Revert bogus IRQ_INPROGRESS
    clear
  o ia64: Fix/finish kernel module table support so it actually works

David S. Miller:
  o [NET]: Undo deprecation of init_etherdev, we will add it back once
    all in-tree drivers are fixed
  o [LLC]: Make LLC2 compile with PROC_FS=n
  o [NET]: sysctl_net_core.c needs linux/module.h
  o [IPV6]: Set fl->proto in _decode_sesseion6
  o [TG3]: Disable/enable timer in suspend/resume
  o [NET COMPAT]: Fix hangs caused by bugs in do_netfilter_replace()
  o [SPARC]: Fix do_gettimeofday() as per cset 1.1347.1.17
  o [SPARC64]: Get hugetlb support back into working shape

David T. Hollis:
  o USB: ax8817x fixes in usbnet.c

Douglas Gilbert:
  o SCSI constants.c

Gerd Knorr:
  o Fix bttv BUG() at video-buf.c:378

Glen Overby:
  o [XFS] Fix problem with the debug code in xlog_state_do_callback
  o [XFS] remove xfs_dir2_node_addname_int remnants of an old block
    placement algorithm

Greg Kroah-Hartman:
  o USB: gadget fixes for 64bit processor warnings

Herbert Xu:
  o [NET]: More build fixes for CONFIG_XFRM disabled

Ian Abbott:
  o USB: ftdi_sio - Perle UltraPort new ids

Ian Wienand:
  o ia64: fix gate-data.S build for binutils 2.14

James Cleverdon:
  o Allow more APIC irq sources

Jeff Garzik:
  o [libata] Merge Serial ATA core, and drivers for
  o [libata] Integrate Serial ATA driver into kernel tree

Jesse Barnes:
  o ia64: fix topology init
  o ia64: zero out topology related sysfs nodes

Knut Petersen:
  o input / keyboard / Scancode Set 3 support broken
  o setkeycode ioctl fix

Len Brown:
  o [ACPI] speed up reads from /proc/acpi/ (Shaohua David Li)
    http://bugme.osdl.org/show_bug.cgi?id=726
  o [ACPI] fix object reference count bug for battery status (Shaohua
    David Li) http://bugme.osdl.org/show_bug.cgi?id=1038
  o [ACPI] acpi_ec_gpe_query(ec) fix for T40 crash (Shaohua David Li)
    http://bugme.osdl.org/show_bug.cgi?id=1171
  o [ACPI] fix acpi_ev_gpe_dispatch() parameter (Bob Moore)
  o [ACPI] fix !CONFIG_PCI build use X86 ACPI specific version of
    eisa_set_level_irq()
    http://bugzilla.kernel.org/show_bug.cgi?id=1390
  o [ACPI] Broken fan detection prevents booting (Shaohua David Li)
    http://bugme.osdl.org/show_bug.cgi?id=1185

Linus Torvalds:
  o bcopy() doesn't return anything
  o Make the pc9800, visws and voyager sub-architectures tell us their
    NR_IRQ_VECTORS.
  o Revert bogus IRQ_INPROGRESS clear
  o Make yenta allocate IO resource windows in same range as in 2.4.x
  o Add a quirk for the Intel ICH-[45] to add special ACPI regions

Mark Haverkamp:
  o Work around aacraid FW problem

Michael Hunold:
  o Fix bugs in various DVB drivers
  o Fix bug in saa7146 analog tv i2c-handling
  o Fix bugs in analog tv i2c-helper chipset drivers

Mike Anderson:
  o Add release function to sd for scsi_disk structure

Mike Christie:
  o fix oops caused when writing to the rescan attribute

Nathan Scott:
  o [XFS] Fix inode btree lookup code precision problem with large
    allocation groups
  o [XFS] final round of code cleanup, now using 3-clause-bsd in these
    headers
  o [XFS] Use an xfs_ino_t to hold the result of inode extraction from
    a handle, not a possibly 32-bit number

Neil Brown:
  o md -  Use sector rather than block numbers when splitting raid0
    requests
  o kNFSd -  In READDIRPLUS reply, don't return a file handle for a
    mounted directory

Pat LaVarre:
  o SG_SET_RESERVED_SIZE negative oops

Patrick Mansfield:
  o SCSI: limit mode sense usage

Russell King:
  o [NET]: Prevent 'eth0: driver changed get_stats after register' from
    lying
  o [ARM] Correct acornfb arguments for fb_set_var()

Stephen Lord:
  o [XFS] Change XFS maintainer

Steve French:
  o check return code on failed kmalloc.  list management bugs.  fix
    xid going negative
  o Fix spinlock usage for SMP safety
  o Fix various SMP/locking problems pointed out by Shoobhit Dayal and
    Arjan van de Ven
  o Remove illegal kunmap
  o Missing spin_unlock in error path and extraneous kunmap in
    cifs_writepages
  o missing cifs mount options
  o add missing mount option iocharset to cifs vfs
  o list processing fixes in cifs reopen_files
  o Fix case where server hung but tcpip session still good.  Fix
    double request of same spinlock
  o don't kill demultiplex thread on ERESTARTSYS
  o missing check for eagain on sock ops
  o fix loop on mount failure of session setup
  o fixes to not prematurely exit demultiplex captive thread

Stéphane Eranian:
  o ia64: two perfmon fixes
  o ia64: fix critical perfmon2 bugs

Zwane Mwaikambo:
  o [IPV6]: Fix sit.c compilation w/o CONFIG_XFRM