Out of curiosity, is it preferred that if bugs/patches get found, that they
be posted here, to the Bugzilla database, or both? I've been putting them
at both places, so there's discussion here and a history there...
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
On Tue, Dec 03, 2002 at 02:24:04AM -0500, [email protected] wrote:
> Out of curiosity, is it preferred that if bugs/patches get found, that they
> be posted here, to the Bugzilla database, or both? I've been putting them
> at both places, so there's discussion here and a history there...
- simple things like compile errors
here. no need to clog up bugzilla with lots of trivial things.
- architecture xxx doesn't compile
there's a few of these now in bugzilla, and personally I don't think
they belong there. Any arch other than i386 is always going to be
playing catchup, and is nearly always out of date in mainline.
- trivial patches
send to rusty, cc here.
- anything else
here. if you don't get a quick-fix, bugzilla it too.
this way important bugs won't get lost amongst the archives.
(as long as bugzilla remains usable)
whilst on the subject of bugzilla:
a few people (myself included) go through the bug database once a week
or so pruning out-of-date/fixed entries. So far the ones I've closed have
been quite sensible, but there are a few there of the form..
"xxx doesn't work in 2.5.47", then Rusty's module rewrite happened,
and the tester didn't (or couldn't) see if it got fixed in subsequent
kernels. I'll send out pings to such reports when they get to something
like 5 kernels old. If the problem then doesn't get re-ACKed, I'll
close it. Any objections?
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
In article <[email protected]>,
Dave Jones <[email protected]> wrote:
| "xxx doesn't work in 2.5.47", then Rusty's module rewrite happened,
| and the tester didn't (or couldn't) see if it got fixed in subsequent
| kernels. I'll send out pings to such reports when they get to something
| like 5 kernels old. If the problem then doesn't get re-ACKed, I'll
| close it. Any objections?
Since you are doing the work, you should set your own policy. I might
suggest that if we revert the module stuff to something working in
fewer than five versions you might ping then, and you might wait to
drop stuff of the "xxx fails in 2.5.47 as a module" until modules work
again or we officially go to a monolythic kernel.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
The bugzillla Dave Jones wrote:
>whilst on the subject of bugzilla:
>a few people (myself included) go through the bug database once a week
>or so pruning out-of-date/fixed entries. So far the ones I've closed have
>been quite sensible, but there are a few there of the form..
>
>"xxx doesn't work in 2.5.47", then Rusty's module rewrite happened,
>and the tester didn't (or couldn't) see if it got fixed in subsequent
>kernels. I'll send out pings to such reports when they get to something
>like 5 kernels old. If the problem then doesn't get re-ACKed, I'll
>close it. Any objections?
>
> Dave
>
Thankfully osdl has been set up with very useful fields for such things.
It sounds like cases that you are describing should be rejected with a
status of either "UNREPRODUCIBLE" if the bug report was decently done,
but you can't reproduce it, or "INSUFFICIENT_DATA" if the bug report was
filed inadequately. This can serve as a prompt to the original filer to
re-open it with better data.
I don't think you should hesitate to do that at least once for a bug
fits either of those cases.
-Tupshin
> Out of curiosity, is it preferred that if bugs/patches get found, that
> they be posted here, to the Bugzilla database, or both? I've been
> putting them at both places, so there's discussion here and a history
> there...
I'd say both. Be careful not to file duplicates in Bugzilla though.
People attatching patches to existing bugs in Bugzilla are especially
welcome ;-)
Bugs will get closed out once they're fixed in the next full release
of mainline, so Bugzilla shouldn't get too cluttered. We need to have
a better (more searchable) version field, but that needs some more
complex Bugzilla rework ... we're thinking about how best to do it.
M.
* Dave Jones ([email protected]) wrote:
> - architecture xxx doesn't compile
> there's a few of these now in bugzilla, and personally I don't think
> they belong there. Any arch other than i386 is always going to be
> playing catchup, and is nearly always out of date in mainline.
Quite a few of those are from me. It is a real pity that we keep the
view of everything other than i386 is playing catch up - that really
deminishes the usefulness of Linux in a lot of fields.
Don't forget that ia64, x86-64 and s390 are all potentially growing
users of Linux. Linux on ARM, MIPS and PPC also has a healthy band of
productive (commercial and home) users.
The problem for a lot of the users of some of these architectures is that they
have to have a long hard fight to get a kernel to work on their system;
and every one of the systems has to have a different kernel version with
different oddities. The stability of these systems isn't just harmed by
the fact that less people are testing the architecture specific code but
also that they tend to be based on older original kernel trees.
In addition porting to another architecture is a great way to shake out
pointer bugs and random bugs in any code - so being able to run the main
kernel on a few architectures should help make life more stable for
everyone.
I don't expect that all the other architectures will be as well tested
as x86; but at least we should know the state of each architecture and
preferably have 2.6.x (or whatever it gets called) to basically work on
as many architectures as possible.
When Linux does work accross lots of architectures it is very, very
useful - how many other OS's can give you the same operating environment
on totally different pieces of hardware? It makes porting code very
simple and pleasent when you only have to worry about the architectural
differences and not battling between different OS.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Wed, Dec 04, 2002 at 11:58:19AM +0000, Dr. David Alan Gilbert wrote:
> Don't forget that ia64, x86-64 and s390 are all potentially growing
> users of Linux. Linux on ARM, MIPS and PPC also has a healthy band of
> productive (commercial and home) users.
ARM Linux still has rather a large patch, but it is gradually getting
smaller again as things get merged.
As far as keeping the bits that are in Linus' kernel buildable (and
working), it is easier with the various BK cset patches or BK itself
because you can always be on top of Linus' tree. However, there are
costs here:
1. An incompatible change can be merged at any time into Linus' tree,
so frequent testing is required - might need a build system that
automatically builds Linus' kernels for an architecture nightly.
2. As a result of (1), even if it built at the last test, that's no
guarantee that the patch Linus releases will work - changes have
appeared around the time of the release which break architecture
code.
I would like to setup an automatic nightly ARM kernel build of the
current BK tree for multiple ARM machine types to get as much code
build-tested as possible.
However, this currently isn't feasible for me since most of the machines
here (except server + firewall) get powered off at night, and the remote
x86 boxen I've used in the past for occasional build testing are now under
a relatively heavy FTP (vsftp), rsync and web load and would severely
suffer from BK's consistency checks (l/a 0.91 1.32 1.76, blocks
in: ~2500 blocks/sec average.)
On bugme stuff, if you've submitted any ARM related bugs, I haven't had
any notifications from bugzilla about them (so I've not looked at bugme
since talking to Manfred. Maybe Manfred missed settings things up.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Wed, Dec 04, 2002 at 11:58:19AM +0000, Dr. David Alan Gilbert wrote:
> > - architecture xxx doesn't compile
> > there's a few of these now in bugzilla, and personally I don't think
> > they belong there. Any arch other than i386 is always going to be
> > playing catchup, and is nearly always out of date in mainline.
>
> Quite a few of those are from me. It is a real pity that we keep the
> view of everything other than i386 is playing catch up - that really
> deminishes the usefulness of Linux in a lot of fields.
This was something that was brought up in a discussion at the kernel
summit by (I think) Paul Mackerras. The question was how to make
sure we get all arch's in sync before doing a release.
It should be fairly straightforward thing to do for 2.6.x releases,
but during 2.5.x when stuff is changing so rapidly, it doesn't make
sense to hold up the majority of users just so the other archs can
play catch up.
> Don't forget that ia64, x86-64 and s390 are all potentially growing
> users of Linux.
ia64 and x86-64 maybe, but s390 is way out of the pricerange of most
Linux users. Those who can afford it will likely use distro kernels anyway
due to the added support they paid for.
x86-64 usually isn't that far from mainline (though there was a period
a while ago, where Linus hadn't merged for a while). As most of that
is shared with i386 or very similar, I think when these become more
mainstream, we'll start seeing a lot more people contributing to this,
so it should remain current in mainline also, as long as Andi scales 8-)
> Linux on ARM, MIPS and PPC also has a healthy band of
> productive (commercial and home) users.
Russell has done a great job at keeping ARM up to date in 2.5,
as have the PPC folks. For the most part, the archs aren't that
out of sync. (Insert comedy remark here about m68k being more
up to date than alpha).
> I don't expect that all the other architectures will be as well tested
> as x86; but at least we should know the state of each architecture and
> preferably have 2.6.x (or whatever it gets called) to basically work on
> as many architectures as possible.
indeed. this should be addressed by the time we get to stable releases.
One possibility someone came up with at the summit was just a slightly
different take on the existing pre/rc release model.
The initial pre's remain as they are now, later pres are for strict
bug-fixes and arch resyncs, then the release candidates roll out.
It doesn't sound that impossible a plan, as long as whoever ends up
doing it is strict enough not to include 'just one more feature'
during the arch-merge pre's.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
* Dave Jones ([email protected]) wrote in reply to my reply:
>
> This was something that was brought up in a discussion at the kernel
> summit by (I think) Paul Mackerras. The question was how to make
> sure we get all arch's in sync before doing a release.
> It should be fairly straightforward thing to do for 2.6.x releases,
> but during 2.5.x when stuff is changing so rapidly, it doesn't make
> sense to hold up the majority of users just so the other archs can
> play catch up.
True; thats why I only started submitting these now we are feature
chilled. I reckoned it was important not to get into the misconception
we didn't have many bugs left because things were starting to chug along
nicely on x86.
> > Don't forget that ia64, x86-64 and s390 are all potentially growing
> > users of Linux.
>
> ia64 and x86-64 maybe, but s390 is way out of the pricerange of most
> Linux users. Those who can afford it will likely use distro kernels anyway
> due to the added support they paid for.
True; but sometimes people have desires to run the same/similar kernel
versions on all their systems and/or use some patches without having to
have versions for all systems.
> > Linux on ARM, MIPS and PPC also has a healthy band of
> > productive (commercial and home) users.
>
> Russell has done a great job at keeping ARM up to date in 2.5,
> as have the PPC folks. For the most part, the archs aren't that
> out of sync. (Insert comedy remark here about m68k being more
> up to date than alpha).
Indeed - (Alpha is actually one of the few non-x86 architectures
that actually built fully for me in a recent 2.5.x - and made a passable
attempt at booting)
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Wed, Dec 04, 2002 at 06:32:35PM +0000, Dr. David Alan Gilbert wrote:
> Indeed - (Alpha is actually one of the few non-x86 architectures
> that actually built fully for me in a recent 2.5.x - and made a passable
> attempt at booting)
One of the ARM machine types which I consider being closest to being
completely buildable in Linus tree was this -><- close to being buildable
between 2.5.49 to 2.5.50.
In 2.5.49, it failed because we had a couple of references in ide.c to
functions previously removed. In 2.5.50, the IDE DMA stuff changed and
made icside.c unbuildable. I'm not going to get a chance to look at this
for a while, so don't expect it to change.
Not only that, but the ARM module stuff needs changes in mm/vmalloc.c so
we don't have to have a _third_ ruddy implementation of the same code.
(which currently causes a link error.) mm/vmalloc.c needs to become more
general - basically "allocate a region of size A alignment B between
address C and address D". Oh, not to mention the inherently racy code
found within mm/vmalloc.c
I'll now step off my soap box. 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
[email protected] said:
> Oh, not to mention the inherently racy code found within mm/vmalloc.c
A fix for that was sent to Linus months ago. Akpm says it breaks, nobody
else can reproduce the breakage and I can't see a problem with it...
--
dwmw2
[email protected] said:
>> Oh, not to mention the inherently racy code found within mm/vmalloc.c
On Thu, Dec 05, 2002 at 09:15:18AM +0000, David Woodhouse wrote:
> A fix for that was sent to Linus months ago. Akpm says it breaks, nobody
> else can reproduce the breakage and I can't see a problem with it...
Is there any chance you can send a testcase my way? I've got some
testboxen that are good at bringing out races (NUMA stuff is beautiful
for that -- I don't consider anything racetested until it passes there.)
No guarantees, of course, but I do like to make my testing services
available when I can. Recently it helped with some of kai's makefiles.
Thanks,
Bill
[email protected] said:
> Is there any chance you can send a testcase my way? I've got some
> testboxen that are good at bringing out races (NUMA stuff is beautiful
> for that -- I don't consider anything racetested until it passes
> there.)
The race in vmalloc is purely theoretical but blatantly obvious -- I don't
think anyone's actually triggered it though. You have already tried the fix
and reported it works fine. Apparently for akpm ioremap() returns a
bogus value to the aic7xxx driver and the box locks up. I can't see why it
could do that -- more eyes welcome...
===== include/linux/vmalloc.h 1.8 vs edited =====
--- 1.8/include/linux/vmalloc.h Fri Nov 8 07:47:15 2002
+++ edited/include/linux/vmalloc.h Wed Nov 20 14:27:09 2002
@@ -2,12 +2,14 @@
#define _LINUX_VMALLOC_H
#include <linux/spinlock.h>
+#include <linux/list.h>
#include <asm/page.h> /* pgprot_t */
/* bits in vm_struct->flags */
#define VM_IOREMAP 0x00000001 /* ioremap() and friends */
#define VM_ALLOC 0x00000002 /* vmalloc() */
#define VM_MAP 0x00000004 /* vmap()ed pages */
+#define VM_DELETING 0x00000008 /* Being removed */
struct vm_struct {
void *addr;
@@ -16,7 +18,7 @@
struct page **pages;
unsigned int nr_pages;
unsigned long phys_addr;
- struct vm_struct *next;
+ struct list_head list;
};
/*
@@ -40,9 +42,9 @@
extern void unmap_vm_area(struct vm_struct *area);
/*
- * Internals. Dont't use..
+ * Internals. Don't use.
*/
extern rwlock_t vmlist_lock;
-extern struct vm_struct *vmlist;
+extern struct list_head vmlist;
#endif /* _LINUX_VMALLOC_H */
===== mm/vmalloc.c 1.23 vs edited =====
--- 1.23/mm/vmalloc.c Thu Oct 31 15:28:17 2002
+++ edited/mm/vmalloc.c Wed Nov 20 14:27:09 2002
@@ -21,7 +21,7 @@
rwlock_t vmlist_lock = RW_LOCK_UNLOCKED;
-struct vm_struct *vmlist;
+LIST_HEAD(vmlist);
static void unmap_area_pte(pmd_t *pmd, unsigned long address,
unsigned long size)
@@ -192,7 +192,7 @@
*/
struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
{
- struct vm_struct **p, *tmp, *area;
+ struct vm_struct *tmp, *area;
unsigned long addr = VMALLOC_START;
area = kmalloc(sizeof(*area), GFP_KERNEL);
@@ -209,7 +209,7 @@
}
write_lock(&vmlist_lock);
- for (p = &vmlist; (tmp = *p) ;p = &tmp->next) {
+ list_for_each_entry(tmp, &vmlist, list) {
if ((size + addr) < addr)
goto out;
if (size + addr <= (unsigned long)tmp->addr)
@@ -220,8 +220,7 @@
}
found:
- area->next = *p;
- *p = area;
+ list_add_tail(&area->list, &tmp->list);
area->flags = flags;
area->addr = (void *)addr;
@@ -250,18 +249,23 @@
*/
struct vm_struct *remove_vm_area(void *addr)
{
- struct vm_struct **p, *tmp;
+ struct vm_struct *tmp;
write_lock(&vmlist_lock);
- for (p = &vmlist ; (tmp = *p) ;p = &tmp->next) {
+ list_for_each_entry(tmp, &vmlist, list) {
if (tmp->addr == addr)
goto found;
}
write_unlock(&vmlist_lock);
return NULL;
-found:
- *p = tmp->next;
+ found:
+ if (tmp->flags & VM_DELETING) {
+ printk(KERN_ERR "Trying to vfree() region being freed (%p)\n", addr);
+ tmp = NULL;
+ }
+ else
+ tmp->flags |= VM_DELETING;
write_unlock(&vmlist_lock);
return tmp;
}
@@ -299,6 +303,10 @@
kfree(area->pages);
}
+ write_lock(&vmlist_lock);
+ list_del(&area->list);
+ write_unlock(&vmlist_lock);
+
kfree(area);
return;
}
@@ -308,7 +316,7 @@
*
* @addr: memory base address
*
- * Free the virtually continguos memory area starting at @addr, as
+ * Free the virtually contiguous memory area starting at @addr, as
* obtained from vmalloc(), vmalloc_32() or __vmalloc().
*
* May not be called in interrupt context.
@@ -324,7 +332,7 @@
*
* @addr: memory base address
*
- * Free the virtually continguos memory area starting at @addr,
+ * Free the virtually contiguous memory area starting at @addr,
* which was created from the page array passed to vmap().
*
* May not be called in interrupt context.
@@ -336,12 +344,12 @@
}
/**
- * vmap - map an array of pages into virtually continguos space
+ * vmap - map an array of pages into virtually contiguous space
*
* @pages: array of page pointers
* @count: number of pages to map
*
- * Maps @count pages from @pages into continguos kernel virtual
+ * Maps @count pages from @pages into contiguous kernel virtual
* space.
*/
void *vmap(struct page **pages, unsigned int count)
@@ -363,14 +371,14 @@
}
/**
- * __vmalloc - allocate virtually continguos memory
+ * __vmalloc - allocate virtually contiguous memory
*
* @size: allocation size
* @gfp_mask: flags for the page level allocator
* @prot: protection mask for the allocated pages
*
* Allocate enough pages to cover @size from the page level
- * allocator with @gfp_mask flags. Map them into continguos
+ * allocator with @gfp_mask flags. Map them into contiguous
* kernel virtual space, using a pagetable protection of @prot.
*/
void *__vmalloc(unsigned long size, int gfp_mask, pgprot_t prot)
@@ -418,12 +426,12 @@
}
/**
- * vmalloc - allocate virtually continguos memory
+ * vmalloc - allocate virtually contiguous memory
*
* @size: allocation size
*
* Allocate enough pages to cover @size from the page level
- * allocator and map them into continguos kernel virtual space.
+ * allocator and map them into contiguous kernel virtual space.
*
* For tight cotrol over page level allocator and protection flags
* use __vmalloc() instead.
@@ -434,12 +442,12 @@
}
/**
- * vmalloc_32 - allocate virtually continguos memory (32bit addressable)
+ * vmalloc_32 - allocate virtually contiguous memory (32bit addressable)
*
* @size: allocation size
*
* Allocate enough 32bit PA addressable pages to cover @size from the
- * page level allocator and map them into continguos kernel virtual space.
+ * page level allocator and map them into contiguous kernel virtual space.
*/
void *vmalloc_32(unsigned long size)
{
@@ -457,7 +465,7 @@
count = -(unsigned long) addr;
read_lock(&vmlist_lock);
- for (tmp = vmlist; tmp; tmp = tmp->next) {
+ list_for_each_entry(tmp, &vmlist, list) {
vaddr = (char *) tmp->addr;
if (addr >= vaddr + tmp->size - PAGE_SIZE)
continue;
@@ -495,7 +503,7 @@
count = -(unsigned long) addr;
read_lock(&vmlist_lock);
- for (tmp = vmlist; tmp; tmp = tmp->next) {
+ list_for_each_entry(tmp, &vmlist, list) {
vaddr = (char *) tmp->addr;
if (addr >= vaddr + tmp->size - PAGE_SIZE)
continue;
===== fs/proc/kcore.c 1.7 vs edited =====
--- 1.7/fs/proc/kcore.c Tue Oct 29 00:51:13 2002
+++ edited/fs/proc/kcore.c Wed Nov 20 14:27:09 2002
@@ -121,12 +121,12 @@
*num_vma = 0;
size = ((size_t)high_memory - KCORE_BASE + PAGE_SIZE);
- if (!vmlist) {
+ if (list_empty(&vmlist)) {
*elf_buflen = PAGE_SIZE;
return (size);
}
- for (m=vmlist; m; m=m->next) {
+ list_for_each_entry(m, &vmlist, list) {
try = (size_t)m->addr + m->size;
if (try > KCORE_BASE + size)
size = try - KCORE_BASE;
@@ -246,7 +246,7 @@
phdr->p_align = PAGE_SIZE;
/* setup ELF PT_LOAD program header for every vmalloc'd area */
- for (m=vmlist; m; m=m->next) {
+ list_for_each_entry(m, &vmlist, list) {
if (m->flags & VM_IOREMAP) /* don't dump ioremap'd stuff! (TA) */
continue;
@@ -406,11 +406,15 @@
memset(elf_buf, 0, tsz);
read_lock(&vmlist_lock);
- for (m=vmlist; m && cursize; m=m->next) {
+ list_for_each_entry(m, &vmlist, list) {
unsigned long vmstart;
unsigned long vmsize;
- unsigned long msize = m->size - PAGE_SIZE;
+ unsigned long msize;
+ if (!cursize)
+ break;
+
+ msize = m->size - PAGE_SIZE;
if (((unsigned long)m->addr + msize) <
curstart)
continue;
--
dwmw2
[email protected] said:
>> Is there any chance you can send a testcase my way? I've got some
>> testboxen that are good at bringing out races (NUMA stuff is beautiful
>> for that -- I don't consider anything racetested until it passes
>> there.)
On Thu, Dec 05, 2002 at 09:34:22AM +0000, David Woodhouse wrote:
> The race in vmalloc is purely theoretical but blatantly obvious -- I don't
> think anyone's actually triggered it though. You have already tried the fix
> and reported it works fine. Apparently for akpm ioremap() returns a
> bogus value to the aic7xxx driver and the box locks up. I can't see why it
> could do that -- more eyes welcome...
I'm sorry, that's already so; acked as it stands from prior testing, and
excellent auditwork on your part to boot.
Thanks,
Bill
In article <[email protected]>,
Dave Jones <[email protected]> wrote:
| indeed. this should be addressed by the time we get to stable releases.
| One possibility someone came up with at the summit was just a slightly
| different take on the existing pre/rc release model.
| The initial pre's remain as they are now, later pres are for strict
| bug-fixes and arch resyncs, then the release candidates roll out.
| It doesn't sound that impossible a plan, as long as whoever ends up
| doing it is strict enough not to include 'just one more feature'
| during the arch-merge pre's.
This should fall out in the early rc versions I would think. Once new
features are stopped and only bugfixes are allowed, I'm not sure that
fixes to make an arch work are different from any other bugfix.
Otherwise you can get a "fix-lock" where a kernel get ported to most
archs, then a real bug is found and fixed which breaks some arch, then
we go round again.
In practice, if new features are strictly kept out, the rc releases
should asymptotically approach stable.
I'm not against having a "port-stable" stage, I just think it isn't
going to speed development. The maintainer would have to decide if a bug
fix could wait if it broke a port, but they do a lot of "is it a fix or
a feature" now, if you call a patch "fix missed detection of foo123
chip" it's a fix, and if you say "add detection of foo123" it becomes an
enhancement.
Release maintainers have a really hard job, that's why we pay them the
big bucks;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.