Re: [RFC] must fix lists

Re: [RFC] must fix lists

[Mikael Pettersson]

On Thu, 23 Oct 2003 22:11:35 +0100, Alan Cox wrote:
>On Mer, 2003-10-22 at 03:50, Albert Cahalan wrote:
>> The system in question would also lose time when
>> under heavy load. Note that HZ is now 1000 HZ.
>> If interrupts are kept off for too long or an
>> SMI grabs the CPU...
>
>With a lot of laptops this is a huge problem. Its one of the reasons Red
>Hat went back to 100Hz in the RH 2.4 tree. With many laptops your clock
>becomes junk at 1Khz. It will be interesting to see if the ACPI timers
>help but that wont solve things for older laptops.

Or for really old desktops. My 486 loses time at a rate of about
2 minutes per hour when running 2.5/2.6 and doing lots of disk I/O.
Changing HZ back to 100 solves that problem.

I think we need a CONFIG_HZ.

/Mikael

Re: [RFC] must fix lists

[Alan Cox]

On Gwe, 2003-10-24 at 01:23, Chris Wright wrote:
> > Someone also needs to go fix all the 2.4 security holes still in 2.6
> > last time I checked - things like the execve holes and execve versus
> > proc races.
> 
> I thought these had been fixed, but I'd be happy to take a look.

I got mail from a guy at intel implying the unshare_files stuff wasnt in
2.6 yet

Re: [RFC] must fix lists

[viro]

On Fri, Oct 24, 2003 at 09:46:33AM +1000, Nick Piggin wrote:
>  drivers/tty
>  ~~~~~~~~~~~
>  
> -o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
> -  anyway, hopefully about a week until it's merged) then we can do
> -  tty/misc/upper levels of sound.

Still not completely fixed.
  
>  o 64-bit dev_t.  Seems almost ready, but it's not really known how much
>    work is still to do.  Patches exist in -mm but with the recent rise of the
>    neo-viro I'm not sure where things are at.

32-bit dev_t is done, 64-bit means extra work on nfsd/raid/etc. for those who
are really interested.  Not a mustfix for 2.6.0.
  
>  o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
>    Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff

Mostly done.
  
>  o viro: paride drivers need a big cleanup

Partially done, but ATAPI drivers will need serious work.  There are
real bugs, BTW - it's not just that code is ugly as hell.

Re: [RFC] must fix lists

[Albert Cahalan]

On Thu, 2003-10-23 at 19:46, Nick Piggin wrote:
 
> +o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
> +  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?

Oh, I have an example for you.

Consider the Intel Plumas chipset. There are
some predictable time windows during which the
RTC will return garbage. The BIOS "fix" leads to
SMI/SMM stuff stealing large chunks of CPU time.
On a logic analyser, somebody at work observed
chunks of time as large as 4 ms. That's 3 to 5
clock ticks. Maybe that isn't worst-case even.

To avoid this disaster, Linux must _never_ touch
the RTC registers. The HPET can be used instead.
The TSC is of course also reliable, but Linux
stops using it as soon as a problem hits!

The ignore-the-TSC code really should be doing
just the opposite. Ticks are likely to be lost.
I've never seen an unstable TSC. :-)

>  o 64-bit dev_t.  Seems almost ready, but it's not really known how much
>    work is still to do.  Patches exist in -mm but with the recent rise of the
>    neo-viro I'm not sure where things are at.

Hey, 32-bit dev_t is in already. That's it. Done.

Re: [RFC] must fix lists

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Maw, 2003-10-21 at 06:46, Nick Piggin wrote:
> > The following people have their names in Documentation/must-fix.txt. Lots
> 
> Someone also needs to go fix all the 2.4 security holes still in 2.6
> last time I checked - things like the execve holes and execve versus
> proc races.

I thought these had been fixed, but I'd be happy to take a look.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [RFC] must fix lists

[Nick Piggin]

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



Alan Cox wrote:

>On Maw, 2003-10-21 at 06:46, Nick Piggin wrote:
>
>>The following people have their names in Documentation/must-fix.txt. Lots
>>
>
>Someone also needs to go fix all the 2.4 security holes still in 2.6
>last time I checked - things like the execve holes and execve versus
>proc races.
>
>

I put your name down for that entry Alan. I don't know who else is
aware of all the problems.

OK, a new patch. Includes everyone's suggestions. If anyone wants to
be removed from the CC list please email me privately.


[-- Attachment #2: mustfix.patch --]
[-- Type: text/plain, Size: 4759 bytes --]

 linux-2.6-npiggin/Documentation/must-fix.txt   |   37 ++++---------------------
 linux-2.6-npiggin/Documentation/should-fix.txt |   23 ---------------
 2 files changed, 7 insertions(+), 53 deletions(-)

diff -puN Documentation/must-fix.txt~mustfix Documentation/must-fix.txt
--- linux-2.6/Documentation/must-fix.txt~mustfix	2003-10-24 09:28:12.000000000 +1000
+++ linux-2.6-npiggin/Documentation/must-fix.txt	2003-10-24 09:38:22.000000000 +1000
@@ -13,17 +13,9 @@ o TTY locking is broken.
 
   o somebody will have to document the tty driver and ldisc API
 
-o Lack of test cases and/or stress tests is a problem.  Contributions and
-  suggestions are sought.
-
-o Lots of drivers are using cli/sti and are broken.
-
 drivers/tty
 ~~~~~~~~~~~
 
-o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
-  anyway, hopefully about a week until it's merged) then we can do
-  tty/misc/upper levels of sound.
 
 drivers/block/
 ~~~~~~~~~~~~~~
@@ -33,16 +25,6 @@ o ideraid hasn't been ported to 2.5 at a
   We need to understand whether the proposed BIO split code will suffice
   for this.
 
-o CD burning.  There are still a few quirks to solve wrt SG_IO and ide-cd.
-
-  Jens: The basic hang has been solved (double fault in ide-cd), there still
-  seems to be some cases that don't work too well.  Don't really have a
-  handle on those :/
-
-o lmb: Last time I looked at the multipath code (2.5.50 or so) it also
-  looked pretty broken; I plan to port forward the changes we did on 2.4
-  before KS.
-
 drivers/input/
 ~~~~~~~~~~~~~~
 
@@ -84,14 +66,6 @@ o viro: actually, misc.c has a good chan
 drivers/net/
 ~~~~~~~~~~~~
 
-o rmk: network drivers.  ARM people like to add tonnes of #ifdefs into
-  these to customise them to their hardware platform (eg, chip access
-  methods, addresses, etc.) I cope with this by not integrating them into my
-  tree.  The result is that many ARM platforms can't be built from even my
-  tree without extra patches.  This isn't sane, and has bred a culture of
-  network drivers not being submitted.  I don't see this changing for 2.6
-  though.
-
 drivers/net/irda/
 ~~~~~~~~~~~~~~~~~
 
@@ -333,11 +307,16 @@ o rmk: need to complete ALSA-ification o
 global
 ~~~~~~
 
+o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
+  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?
+
 o 64-bit dev_t.  Seems almost ready, but it's not really known how much
   work is still to do.  Patches exist in -mm but with the recent rise of the
   neo-viro I'm not sure where things are at.
 
-o Lots of 2.4 fixes including some security are not in 2.5
+o alan: Forward port 2.4 fixes
+  - Security fixes including execve holes, execve vs proc races
+  - SiS IRQ routing for newer SiS and older Intel
 
 o There are about 60 or 70 security related checks that need doing
   (copy_user etc) from Stanford tools.  (badari is looking into this, and
@@ -348,7 +327,3 @@ o A couple of hundred real looking bugzi
 o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
   Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff
 
-o Athlon prefetch oopses sometimes.  It is currently disabled, and needs to
-  be fixed.
-
-
diff -puN Documentation/should-fix.txt~mustfix Documentation/should-fix.txt
--- linux-2.6/Documentation/should-fix.txt~mustfix	2003-10-24 09:28:12.000000000 +1000
+++ linux-2.6-npiggin/Documentation/should-fix.txt	2003-10-24 09:29:55.000000000 +1000
@@ -10,12 +10,6 @@ PRI3:	Not very important
 drivers/block/
 ~~~~~~~~~~~~~~
 
-o Framework for selecting IO schedulers.  This is the main one really. 
-  Once this is in place we can drop in new schedulers any old time, no risk.
-  Nick Piggin has code for this.
-
-  PRI1
-
 o viro: paride drivers need a big cleanup
 
   PRI2
@@ -145,15 +139,7 @@ o (Trond:) Yes: I'm still working on an 
 
    PRI2 (?)
 
-o (Chuck Lever <cel@citi.umich.edu>): NFS O_DIRECT support must be
-  completed.  The best approach is to fall back to something like the 2.4 NFS
-  O_DIRECT support, which issues RPCs synchronously and uses the RPC
-  completion mechanism to wait for I/O completion.
-
-  PRI2
-
-o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
-  porting).
+o viro: convert more filesystems to use lib/parser.c for options.
 
   PRI2
 
@@ -200,9 +186,6 @@ o klibc merge?
 mm/
 ~~~
 
-o objrmap: concerns over page reclaim performance at high sharing levels,
-  and interoperation with nonlinear mappings is hairy.
-
 o oxymoron's async write-error-handling patch
 
   PRI1
@@ -514,10 +497,6 @@ o NMI watchdog seems to tick too fast
 
   PRI2
 
-o not very well tested. probably more bugs lurking.
-
-  PRI1
-
 o need to coredump 64bit vsyscall code with dwarf2
 
   PRI2

_

Re: [RFC] must fix lists

[Alan Cox]

On Mer, 2003-10-22 at 03:50, Albert Cahalan wrote:
> The system in question would also lose time when
> under heavy load. Note that HZ is now 1000 HZ.
> If interrupts are kept off for too long or an
> SMI grabs the CPU...

With a lot of laptops this is a huge problem. Its one of the reasons Red
Hat went back to 100Hz in the RH 2.4 tree. With many laptops your clock
becomes junk at 1Khz. It will be interesting to see if the ACPI timers
help but that wont solve things for older laptops.

BTW another one for the list might be the SiS IRQ routing fixes from 2.4
if not merged otherwise newer sis and some older intel wont work
properly.

Re: [RFC] must fix lists

[Alan Cox]

On Maw, 2003-10-21 at 06:46, Nick Piggin wrote:
> The following people have their names in Documentation/must-fix.txt. Lots

Someone also needs to go fix all the 2.4 security holes still in 2.6
last time I checked - things like the execve holes and execve versus
proc races.

Re: [RFC] must fix lists

[Albert Cahalan]

On Tue, 2003-10-21 at 01:46, Nick Piggin wrote:

> -o (Albert Cahalan) Lots of people (check Google) get this message from the
> -  kernel:
> -
> -  psmouse.c: Lost synchronization, throwing 2 bytes away.
> -
> -  (the number of bytes will be 1, 2, or 3)
> -
> -  At work, I get it when there is heavy NFS traffic.  The mouse goes crazy,
> -  jumping around and doing random cut-and-paste all over everything.  This
> -  is with a decently fast and modern PC.

I'm pretty sure this problem is NOT fixed and is NOT
related to the problems with support for some oddball
touchpad thing.

The system in question would also lose time when
under heavy load. Note that HZ is now 1000 HZ.
If interrupts are kept off for too long or an
SMI grabs the CPU...

Another infuriating symptom is that, when Linux
detects that the TSC doesn't match jiffies, the
TSC usage is turned off. There goes the only GOOD
time source, tossed aside in favor of a bad one.
Fix for that: if jiffies fall behind the TSC,
trust the TSC -- you've lost some clock ticks.

Re: [RFC] must fix lists

[Nick Piggin]

Lars Marowsky-Bree wrote:

>On 2003-10-21T15:46:27,
>   Nick Piggin <piggin@cyberone.com.au> said:
>
>The multipath module will be (outcome of KS) implemented as a
>device-mapper personality, which Sistina / Joe are developing. So,
>luckily, I'm sort of out of the loop of the "must fix" list, but I'll
>hopefully have some of the issues on my "will fix" list anyway ;-)
>

OK so that means it can go in any time really, right? So it can
be removed from the list. Thanks.

Re: [RFC] must fix lists

[Randy.Dunlap]

On Tue, 21 Oct 2003 15:46:27 +1000 Nick Piggin <piggin@cyberone.com.au> wrote:

| The following people have their names in Documentation/must-fix.txt. Lots
| of others in should-fix.txt in 2.6.0-test8-mm1. Please review your entries.
| Also, please add any other substantial changes you need before 2.6. Thanks.


In the should-fix.txt file:

o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
  porting).

The parser lib functions are merged and approx. 15 filesystems
have been converted to use it, so this could be changed to:

o viro: convert more filesystems to use lib/parser.c for parsing options
(still PRI2 I suppose)

--
~Randy

Re: [RFC] must fix lists

[Lars Marowsky-Bree]

On 2003-10-21T15:46:27,
   Nick Piggin <piggin@cyberone.com.au> said:

The multipath module will be (outcome of KS) implemented as a
device-mapper personality, which Sistina / Joe are developing. So,
luckily, I'm sort of out of the loop of the "must fix" list, but I'll
hopefully have some of the issues on my "will fix" list anyway ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

[RFC] must fix lists

[Nick Piggin]

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

The following people have their names in Documentation/must-fix.txt. Lots
of others in should-fix.txt in 2.6.0-test8-mm1. Please review your entries.
Also, please add any other substantial changes you need before 2.6. Thanks.

Al Viro
Alan
Albert Cahalan
Andi
Badari Pulavarty
brodo
Dave M
Dipankar
hch
hollisb
Ingo
James B
Jens
lmb
Mike Anderson
Patrick Mansfield
rmk
Rusty
Trond

(Maybe missed a couple)


[-- Attachment #2: mustfix.patch --]
[-- Type: text/plain, Size: 4606 bytes --]

 linux-2.6-npiggin/Documentation/must-fix.txt   |   44 -------------------------
 linux-2.6-npiggin/Documentation/should-fix.txt |   20 -----------
 2 files changed, 64 deletions(-)

diff -puN Documentation/must-fix.txt~mustfix Documentation/must-fix.txt
--- linux-2.6/Documentation/must-fix.txt~mustfix	2003-10-20 19:37:24.000000000 +1000
+++ linux-2.6-npiggin/Documentation/must-fix.txt	2003-10-20 20:06:26.000000000 +1000
@@ -13,17 +13,9 @@ o TTY locking is broken.
 
   o somebody will have to document the tty driver and ldisc API
 
-o Lack of test cases and/or stress tests is a problem.  Contributions and
-  suggestions are sought.
-
-o Lots of drivers are using cli/sti and are broken.
-
 drivers/tty
 ~~~~~~~~~~~
 
-o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
-  anyway, hopefully about a week until it's merged) then we can do
-  tty/misc/upper levels of sound.
 
 drivers/block/
 ~~~~~~~~~~~~~~
@@ -33,16 +25,6 @@ o ideraid hasn't been ported to 2.5 at a
   We need to understand whether the proposed BIO split code will suffice
   for this.
 
-o CD burning.  There are still a few quirks to solve wrt SG_IO and ide-cd.
-
-  Jens: The basic hang has been solved (double fault in ide-cd), there still
-  seems to be some cases that don't work too well.  Don't really have a
-  handle on those :/
-
-o lmb: Last time I looked at the multipath code (2.5.50 or so) it also
-  looked pretty broken; I plan to port forward the changes we did on 2.4
-  before KS.
-
 drivers/input/
 ~~~~~~~~~~~~~~
 
@@ -55,20 +37,6 @@ o viro: parport is nearly as bad as that
   IMO parport is more of "figure out what API changes are needed for its
   users, get them done ASAP, then fix generic layer at leisure"
 
-o (Albert Cahalan) Lots of people (check Google) get this message from the
-  kernel:
-
-  psmouse.c: Lost synchronization, throwing 2 bytes away.
-
-  (the number of bytes will be 1, 2, or 3)
-
-  At work, I get it when there is heavy NFS traffic.  The mouse goes crazy,
-  jumping around and doing random cut-and-paste all over everything.  This
-  is with a decently fast and modern PC.
-
-o There seem to be too many reports of keyboards and mice failing or acting
-  strangely.
-
 
 drivers/misc/
 ~~~~~~~~~~~~~
@@ -84,14 +52,6 @@ o viro: actually, misc.c has a good chan
 drivers/net/
 ~~~~~~~~~~~~
 
-o rmk: network drivers.  ARM people like to add tonnes of #ifdefs into
-  these to customise them to their hardware platform (eg, chip access
-  methods, addresses, etc.) I cope with this by not integrating them into my
-  tree.  The result is that many ARM platforms can't be built from even my
-  tree without extra patches.  This isn't sane, and has bred a culture of
-  network drivers not being submitted.  I don't see this changing for 2.6
-  though.
-
 drivers/net/irda/
 ~~~~~~~~~~~~~~~~~
 
@@ -348,7 +308,3 @@ o A couple of hundred real looking bugzi
 o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
   Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff
 
-o Athlon prefetch oopses sometimes.  It is currently disabled, and needs to
-  be fixed.
-
-
diff -puN Documentation/should-fix.txt~mustfix Documentation/should-fix.txt
--- linux-2.6/Documentation/should-fix.txt~mustfix	2003-10-20 19:37:27.000000000 +1000
+++ linux-2.6-npiggin/Documentation/should-fix.txt	2003-10-20 20:21:24.000000000 +1000
@@ -10,12 +10,6 @@ PRI3:	Not very important
 drivers/block/
 ~~~~~~~~~~~~~~
 
-o Framework for selecting IO schedulers.  This is the main one really. 
-  Once this is in place we can drop in new schedulers any old time, no risk.
-  Nick Piggin has code for this.
-
-  PRI1
-
 o viro: paride drivers need a big cleanup
 
   PRI2
@@ -145,13 +139,6 @@ o (Trond:) Yes: I'm still working on an 
 
    PRI2 (?)
 
-o (Chuck Lever <cel@citi.umich.edu>): NFS O_DIRECT support must be
-  completed.  The best approach is to fall back to something like the 2.4 NFS
-  O_DIRECT support, which issues RPCs synchronously and uses the RPC
-  completion mechanism to wait for I/O completion.
-
-  PRI2
-
 o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
   porting).
 
@@ -200,9 +187,6 @@ o klibc merge?
 mm/
 ~~~
 
-o objrmap: concerns over page reclaim performance at high sharing levels,
-  and interoperation with nonlinear mappings is hairy.
-
 o oxymoron's async write-error-handling patch
 
   PRI1
@@ -514,10 +498,6 @@ o NMI watchdog seems to tick too fast
 
   PRI2
 
-o not very well tested. probably more bugs lurking.
-
-  PRI1
-
 o need to coredump 64bit vsyscall code with dwarf2
 
   PRI2

_