From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: tytso@mit.edu
Cc: linux-kernel@vger.kernel.org, p_gortmaker@yahoo.com,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
viro@math.psu.edu
Subject: Re: Linux 2.4 Status/TODO page (test11-pre3)
Date: Sun, 12 Nov 2000 22:09:39 -0500 [thread overview]
Message-ID: <3A0F5B73.E613050B@mandrakesoft.com> (raw)
In-Reply-To: <200011121939.eACJd9D01319@trampoline.thunk.org>
tytso@mit.edu wrote:
> 4. Boot Time Failures
> * Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are
> not configured correctly Michal Jaegermann; Richard Henderson may
> have an idea what's failing.)
Move to patch-exists-but-not-merged. rth has patches, co-developed with
Ivan Kokshaysky
> 8. Fix Exists But Isnt Merged
> * Many network device drivers don't call MOD_INC_USE_COUNT in
> dev->open. (Paul Gortmaker has patches)
Update: net drivers can now set an owner member as of test11-pre3, to
completely eliminate any race. Net drivers that don't call MOD_xxx at
all should just be updated to use the new stuff.
> * using ramfs with highmem enabled can yield a kernel NULL pointer
> dereference. (wollny at cns.mpg.de has a patch)
fixed as of test11-pre2.
> 9. To Do
> * Fix mount failures due to copy_* user mishandling
Details?
> * Misc locking problems
> + Power management locking (Alan Cox)
A patch from Alan for this made it into test10 or test11-pre1.
> * Copying between two encrypting loop devices causes an immediate
> deadlock in the request queue (Andi Kleen)
Loopback block device has serious problems, not just this.. I am gonna
look at it this week...
> * 2.4.0-test10 pcmcia fails to detect IRQ's correctly, and will
> sometimes kill all software interrupts on card insertion on a NEC
> Versa LX (David Ford)
Still does this with test11-pre-latest?
> * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
> (Keith Owens)
move to "should already be fixed, confirmation wanted." I think Keith
said he doesn't exercise that particular code path anymore, so he didn't
test James' patch.
> * drivers/input/mousedev.c dereferences userspace pointers directly
> (prumpf)
yum :)
> 10. To Do But Non Showstopper
>
> * Go through as 2.4pre kicks in and figure what we should mark
> obsolete for the final 2.4 (i.e. XT hard disk support?)
* Go through as 2.4pre kicks in and figure out what FOO_DEBUG options
need to be turned off. __iovirt_debug is a notable one that will hurt
performance (IMHO), because every write[bwl] gets routed to a function
call that checks stuff before performing the I/O.
> * Union mount (Al Viro)
I think this is complete? Isn't this mount --bind?
> * Loop device can still hang (William Stearns has script that will
> hang 2.4.0-test7, Peter Enderborg has a short sequence that will
> hang 2.4.0test9)
Maybe combine this entry and the loopback crypto one above into a more
general "loopback works for some cases, deadlocks for others"
> 11. To Check
> * NFS bugs are fixed
Is this worthy of an entry? I think that every bug fix applied should
have a listing here, then. :) check that parport bugs are fixed.
check that serial bugs are fixed. etc. ...
> * List of potential problems found by Stanford students using g++
> hacks:
> + Andy Chou's list of mismatched spinlocks and interrupts/bh
> enable/disable.
> + Seth Andrew Hallem's list potentially sleeping functions
> called with interrupts off or spinlocks held.
> + Dawson Engler's list of potential kmalloc/kfree bugs
A few people are hanging onto these lists, and going through them. This
could be an 'in progress' item.
> * Potential races in file locking code (Christian Ehrhardt -- patch
> which may fix some of these posted by trond, at
> http://boudicca.tux.org/hypermail/linux-kernel/2000week45/0404.htm
> l)
I think trond's patch was applied.
> * many drivers are not hot-plugging safe (__devinit/__devexit)
> (Barklomiej Zolnierkiewicz)
Many drivers are not supposed to be hotplug safe!
If the hardware is not known to be hotpluggable, then the driver should
not use __devinit/exit. Doing so needlessly avoids the __init code
drop, wasting memory.
> 12. Probably Post 2.4
> * module remove race bugs (ipchains modules -- Rusty; won't fix for
> 2.4)
Is this an ipchains bug, or a more general module subsystem bug?
> * NCR5380 isnt smp safe (Frank Davis --- belives the driver should
> be rewritten)
hehe I personally believe many of the current kernel drivers should be
rewritten ;-)
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-13 3:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-12 19:39 Linux 2.4 Status/TODO page (test11-pre3) tytso
2000-11-12 19:51 ` adrian
2000-11-12 20:21 ` adrian
2000-11-12 20:38 ` adrian
2000-11-12 22:31 ` Erik Mouw
2000-11-13 22:58 ` Roger Larsson
2000-11-13 23:19 ` Erik Mouw
2000-11-13 2:26 ` Keith Owens
2000-11-13 17:33 ` James Simmons
2000-11-13 3:09 ` Jeff Garzik [this message]
2000-11-13 3:36 ` David Ford
2000-11-14 1:32 ` Michal Jaegermann
2000-11-14 4:07 ` Rusty Russell
2000-11-13 3:26 ` David Ford
2000-11-13 8:32 ` Matti Aarnio
2000-11-13 13:14 ` David Ford
2000-11-13 5:14 ` Greg KH
2000-11-13 17:46 ` Tim Waugh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A0F5B73.E613050B@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=p_gortmaker@yahoo.com \
--cc=tytso@mit.edu \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox