LinuxLists.cc - Linux 2.6.28-rc8

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <[email protected]> wrote:

> On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> > Nothing overly exciting here. Lots of small things, mostly in drivers
> > (with some defconfig updates for m68k and mips making the diffs bigger).
> >
> > There's some uncomfortably big changes to the intel DRI code, but most of
> > that is all about fixes to the new i916 "GEM" code that is only used by
> > development X servers, and is a new feature, so it shouldn't be able to
> > cause regressions.
> >
> > Perhaps more interesting is simply the release scheduling issue. I'm
> > getting slowly ready to do a real 2.6.28, but I don't think anybody really
> > wants the merge window to be around the holidays. So the question is
> > really whether to
> >
> > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> > I like this, because alledgely people are debugging things, and we'd
> > get a more stable 2.6.28.
>
> I still have one fix for a reported regression (softlink code doesn't
> honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> ago, but it didn't get anywhere.

I don't have a clue what you're talking about.

<greps the tree>

./fs/affs/inode.c: case ST_SOFTLINK:
./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry, ST_SOFTLINK);
./include/linux/amigaffs.h:#define ST_SOFTLINK 3

really?

2008-12-11 08:41:17

by Joerg Roedel

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>

I'll vote for a. An open merge window over the holidays possible results
in needless stresses for the developers at a time which some of them
want to use otherwise. Or if any merge introduces bad bugs and the
developers that can fix it are on xmax vacation we may end up with an
unusable upstream tree for a week or so. Same with merge conflicts.
So, I'd suggest to wait until everybody is back to work until opening
the merge window.

Joerg

2008-12-11 08:46:19

by Nick Piggin

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thursday 11 December 2008 19:07, Andrew Morton wrote:
> On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <[email protected]>
wrote:
> > On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> > > Nothing overly exciting here. Lots of small things, mostly in drivers
> > > (with some defconfig updates for m68k and mips making the diffs
> > > bigger).
> > >
> > > There's some uncomfortably big changes to the intel DRI code, but most
> > > of that is all about fixes to the new i916 "GEM" code that is only used
> > > by development X servers, and is a new feature, so it shouldn't be able
> > > to cause regressions.
> > >
> > > Perhaps more interesting is simply the release scheduling issue. I'm
> > > getting slowly ready to do a real 2.6.28, but I don't think anybody
> > > really wants the merge window to be around the holidays. So the
> > > question is really whether to
> > >
> > > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after
> > > xmas
> > >
> > > I like this, because alledgely people are debugging things, and
> > > we'd get a more stable 2.6.28.
> >
> > I still have one fix for a reported regression (softlink code doesn't
> > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > ago, but it didn't get anywhere.
>
> I don't have a clue what you're talking about.
>
> <greps the tree>
>
> ./fs/affs/inode.c: case ST_SOFTLINK:
> ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
>
> really?

Oh, I thought I cc'ed you...

http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2

2008-12-11 09:26:29

by Jean Delvare

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

Hi Linus,

On Wed, 10 Dec 2008 17:04:39 -0800 (PST), Linus Torvalds wrote:
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.

I vote for option (a).

>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.
>
> or
>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.
>
> So I haven't quite decided on that thing yet, but I'm open to suggestions.

--
Jean Delvare

2008-12-11 10:38:21

by Frederik Deweerdt

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>
> Nothing overly exciting here.

-rc8 could be made even less exciting, it seems, by adding this crutially
boring fix:
http://lkml.org/lkml/2008/12/1/345

It sits in -mm and fixes a regression in mainline (Bugzilla #12047).

Regards,
Frederik

2008-12-11 12:59:12

by Sam Ravnborg

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.

Release before xmas but postpone start of merge window until 5th of January.
So we get the wider testing during xmas and we avoid to stress during xmas holiday.

Or maybe I should go back and drink more gl?gg..

Sam

2008-12-11 13:23:17

by Paolo Ciarrocchi

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, Dec 11, 2008 at 2:00 PM, Sam Ravnborg <[email protected]> wrote:
>>
>> (c) some other crazy scheme that somebody comes up with in a drug-induced
>> stupor.
>
> Release before xmas but postpone start of merge window until 5th of January.
> So we get the wider testing during xmas and we avoid to stress during xmas holiday.

d) Release before xmas, postpone start of merge window until 7th of January.

Use the period of time between the release and the opening of the
merge window to collect bug fixes and release a stable version.

> Or maybe I should go back and drink more gl?gg..

Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/

2008-12-11 13:44:38

by Alexey Zaytsev

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, Dec 11, 2008 at 04:04, Linus Torvalds
<[email protected]> wrote:
>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.

Open the .29 merge window in a separate branch before making the 28 release
and merge the late-rc patches there as they come. ;)

2008-12-11 13:48:40

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

* Linus Torvalds <[email protected]> wrote:

> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs
> bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most
> of that is all about fixes to the new i916 "GEM" code that is only used
> by development X servers, and is a new feature, so it shouldn't be able
> to cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody
> really wants the merge window to be around the holidays. So the
> question is really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.

i'd really vote for a) because there's nothing worse to overlap xmas with
than with merge window stress. A couple of key developers wont be around
either in that timeframe (whose stuff is pending) - making early reaction
to breakage in the merge window rather laggy and awkward.

A Dec 31 release would be perfect [ 84 days will have passed by then
since v2.6.27 which was released on Oct 9 ] and we would start 2009
exactly on point on the planned 3-months / 90 days schedule.

Here's our release cycle track record, and how much it deviates from the
max-90-days target:

2.6.28: 64 days [today]
on 31th: 84 days -6 days

2.6.27: 88 -2 days
2.6.26: 87 -3 days
2.6.25: 83 -7 days
2.6.24: 107 +17 days
2.6.23: 92 +2 days
2.6.22: 73 -17 days
2.6.21: 80 -10 days
2.6.20: 66 -26 days
2.6.19: 70 -20 days
2.6.18: 94 +4 days
2.6.17: 89 -1 day
2.6.16: 76 -14 days
2.6.15: 67 -23 days
2.6.14: 60 -30 days
2.6.13: 72 -18 days

We lost two and a half weeks with 2.6.24 that was released belatedly on
Jan 24 - we've made up all the ground for that already.

And the killer argument: there's nothing better to mask a nasty Jan 1
hangover with than with some merge window stress ;-)

Ingo

2008-12-11 15:21:06

by Pavel Machek

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Wed 2008-12-10 17:04:39, Linus Torvalds wrote:
>
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.

I like (b)... to have some more interesrting holidays :-).

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2008-12-11 15:29:22

by David Howells

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

Linus Torvalds <[email protected]> wrote:

> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.

Which would perhaps mean that the merge window is open during LCA, which will
be inconvenient for some people. On the other hand, it might put the culprits
where you can lay your hands on them.

David

2008-12-11 16:07:33

by Frans Pop

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

Eric Anholt wrote:
> My recommended solution, of course, is to remove vesafb.

How is taking away useful functionality from users a better option than
just fixing the bug?

Cheers,
FJP

2008-12-11 16:22:57

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008, Frans Pop wrote:

> Eric Anholt wrote:
> > My recommended solution, of course, is to remove vesafb.
>
> How is taking away useful functionality from users a better option than
> just fixing the bug?

Well, just to clarify: it's not a _bug_. It's a benign warnign that two
subsystems are trying to map the same memory differently.

In this case, we have:

resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb

and what it means is that the caller (which is i915_gem_entervt_ioctl) is
trying to apparently ioremap the _whole_ graphics card MMIO resource
(0xd0000000-0xdfffffff), but the vesafb driver has already registered the
fact that it uses _part_ of that resource (0xd0000000-0xd07effff).

There's no bug there. It's a warning. It's usually a very odd situation
when somebody tries to ioremap something that crosses resource reservation
boundaries, but the thing is, in this case it's not really a problem.

It's triggered by a couple of oddities:

- fbcon (vesafb) is odd and only requests a partial resource, because it
only uses part of the MMIO window.

- the interaction between fbcon and X is odd to begin with, since they
both use the same physical resource.

so it's a generic warning that triggers because these things _shouldn't_
happen, but it's not actually an error in this case. We could just remove
the warning. Or leave it in, in case it finds other (real) issues, and
just ignore it.

Linus

2008-12-11 16:36:30

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

* Linus Torvalds <[email protected]> wrote:

>
>
> On Thu, 11 Dec 2008, Frans Pop wrote:
>
> > Eric Anholt wrote:
> > > My recommended solution, of course, is to remove vesafb.
> >
> > How is taking away useful functionality from users a better option than
> > just fixing the bug?
>
> Well, just to clarify: it's not a _bug_. It's a benign warnign that two
> subsystems are trying to map the same memory differently.
>
> In this case, we have:
>
> resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
>
> and what it means is that the caller (which is i915_gem_entervt_ioctl) is
> trying to apparently ioremap the _whole_ graphics card MMIO resource
> (0xd0000000-0xdfffffff), but the vesafb driver has already registered the
> fact that it uses _part_ of that resource (0xd0000000-0xd07effff).
>
> There's no bug there. It's a warning. It's usually a very odd situation
> when somebody tries to ioremap something that crosses resource reservation
> boundaries, but the thing is, in this case it's not really a problem.
>
> It's triggered by a couple of oddities:
>
> - fbcon (vesafb) is odd and only requests a partial resource, because it
> only uses part of the MMIO window.
>
> - the interaction between fbcon and X is odd to begin with, since they
> both use the same physical resource.
>
> so it's a generic warning that triggers because these things
> _shouldn't_ happen, but it's not actually an error in this case. We
> could just remove the warning. Or leave it in, in case it finds other
> (real) issues, and just ignore it.

hm, the warning caught a couple of real bugs already. (one in some cpq
driver, another was in some networking driver iirc)

Ingo

2008-12-11 16:59:42

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008 11:38:00 +0100 Frederik Deweerdt <[email protected]> wrote:

> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> >
> > Nothing overly exciting here.
>
> -rc8 could be made even less exciting, it seems, by adding this crutially
> boring fix:
> http://lkml.org/lkml/2008/12/1/345
>
> It sits in -mm and fixes a regression in mainline (Bugzilla #12047).
>

I actually have two acpi patches which look like 2.6.28 material. I shall
resend them to Len.

2008-12-11 17:06:24

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008, Ingo Molnar wrote:
>
> hm, the warning caught a couple of real bugs already. (one in some cpq
> driver, another was in some networking driver iirc)

Well, one thing that does irritate me is that it scares people who can't
do anything about it, and probably _shouldn't_ do anything about it.

I wonder if we should just change the "Warning" message to "Informational"
or something. Yes, they are often real bugs. But no, they're not
_automatically_ bugs. Almost all the time when a warning triggers, it's
really just a developer who wants to know about it, it's not something
that a user should really care/worry about.

Linus

2008-12-11 20:12:56

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thursday, 11 of December 2008, Linus Torvalds wrote:
>
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.

FWIW, I vote for this one.

Thanks,
Rafael

2008-12-11 20:36:53

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

* Linus Torvalds <[email protected]> wrote:

> On Thu, 11 Dec 2008, Ingo Molnar wrote:
> >
> > hm, the warning caught a couple of real bugs already. (one in some
> > cpq driver, another was in some networking driver iirc)
>
> Well, one thing that does irritate me is that it scares people who
> can't do anything about it, and probably _shouldn't_ do anything about
> it.

yeah - and false positives also tend to create apathy and resistence
against kernel warnings - thus drawing tester resources away from more
important bugs.

> I wonder if we should just change the "Warning" message to
> "Informational" or something. Yes, they are often real bugs. But no,
> they're not _automatically_ bugs. Almost all the time when a warning
> triggers, it's really just a developer who wants to know about it, it's
> not something that a user should really care/worry about.

ok. In this case i'd suggest we should just remove the warning. People do
get scared by needless kernel stack dumps - no matter whether it's marked
informational or not.

So how about the patch below, queued up in tip/x86/debug? Arjan, what do
you think?

Ingo

--------------->
>From 2dcae81e819fa5cc0e9310ef8b0c079940df3bf3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 11 Dec 2008 21:29:51 +0100
Subject: [PATCH] IO resources, x86: remove multi-BAR mapping sanity check

Impact: remove a debug warning

The ioremap() time multi-BAR map warning has been causing false positives:

http://lkml.org/lkml/2008/12/10/432
http://lkml.org/lkml/2008/12/11/136

So remove it for now.

Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/mm/ioremap.c | 6 ------
include/linux/ioport.h | 1 -
kernel/resource.c | 38 --------------------------------------
3 files changed, 0 insertions(+), 45 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..421b92d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -220,12 +220,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
return (__force void __iomem *)phys_to_virt(phys_addr);

/*
- * Check if the request spans more than any BAR in the iomem resource
- * tree.
- */
- WARN_ON(iomem_map_sanity_check(phys_addr, size));
-
- /*
* Don't allow anybody to remap normal RAM that we're using..
*/
for (pfn = phys_addr >> PAGE_SHIFT;
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 041e95a..0dde772 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -174,7 +174,6 @@ extern struct resource * __devm_request_region(struct device *dev,

extern void __devm_release_region(struct device *dev, struct resource *parent,
resource_size_t start, resource_size_t n);
-extern int iomem_map_sanity_check(resource_size_t addr, unsigned long size);

#endif /* __ASSEMBLY__ */
#endif /* _LINUX_IOPORT_H */
diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..4b0bc70 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -829,41 +829,3 @@ static int __init reserve_setup(char *str)
}

__setup("reserve=", reserve_setup);
-
-/*
- * Check if the requested addr and size spans more than any slot in the
- * iomem resource tree.
- */
-int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
-{
- struct resource *p = &iomem_resource;
- int err = 0;
- loff_t l;
-
- read_lock(&resource_lock);
- for (p = p->child; p ; p = r_next(NULL, p, &l)) {
- /*
- * We can probably skip the resources without
- * IORESOURCE_IO attribute?
- */
- if (p->start >= addr + size)
- continue;
- if (p->end < addr)
- continue;
- if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
- PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
- continue;
- printk(KERN_WARNING "resource map sanity check conflict: "
- "0x%llx 0x%llx 0x%llx 0x%llx %s\n",
- (unsigned long long)addr,
- (unsigned long long)(addr + size - 1),
- (unsigned long long)p->start,
- (unsigned long long)p->end,
- p->name);
- err = -1;
- break;
- }
- read_unlock(&resource_lock);
-
- return err;
-}

2008-12-11 20:46:45

by Pekka Enberg

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

Hi Ingo,

On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> wrote:
> ok. In this case i'd suggest we should just remove the warning. People do
> get scared by needless kernel stack dumps - no matter whether it's marked
> informational or not.
>
> So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> you think?

How come we don't put it under CONFIG_X86_DEBUG or something and hide
somewhere in the "Kernel debugging" menu?

Pekka

2008-12-11 21:34:49

by Suresh Siddha

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, Dec 11, 2008 at 12:46:33PM -0800, Pekka Enberg wrote:
> Hi Ingo,
>
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> wrote:
> > ok. In this case i'd suggest we should just remove the warning. People do
> > get scared by needless kernel stack dumps - no matter whether it's marked
> > informational or not.
> >
> > So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> > you think?
>
> How come we don't put it under CONFIG_X86_DEBUG or something and hide
> somewhere in the "Kernel debugging" menu?

On the same lines, can we enable this check with a debug boot option?

thanks,
suresh

2008-12-11 22:57:45

by Theodore Ts'o

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, Dec 11, 2008 at 09:40:58AM +0100, Joerg Roedel wrote:
> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> >
> > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> > I like this, because alledgely people are debugging things, and we'd
> > get a more stable 2.6.28.
> >
>
> I'll vote for a. An open merge window over the holidays possible results
> in needless stresses for the developers at a time which some of them
> want to use otherwise. Or if any merge introduces bad bugs and the
> developers that can fix it are on xmax vacation we may end up with an
> unusable upstream tree for a week or so. Same with merge conflicts.
> So, I'd suggest to wait until everybody is back to work until opening
> the merge window.

I'd vote for (a) as well, and hopefully folks who are really
conscientious can do some integration testing of linux-next and can
report problems there to make the merge window go more smoothly after
the New Year's.

- Ted

2008-12-11 23:13:00

by Mike Travis

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

Theodore Tso wrote:
> On Thu, Dec 11, 2008 at 09:40:58AM +0100, Joerg Roedel wrote:
>> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>>> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>>>
>>> I like this, because alledgely people are debugging things, and we'd
>>> get a more stable 2.6.28.
>>>
>> I'll vote for a. An open merge window over the holidays possible results
>> in needless stresses for the developers at a time which some of them
>> want to use otherwise. Or if any merge introduces bad bugs and the
>> developers that can fix it are on xmax vacation we may end up with an
>> unusable upstream tree for a week or so. Same with merge conflicts.
>> So, I'd suggest to wait until everybody is back to work until opening
>> the merge window.
>
> I'd vote for (a) as well, and hopefully folks who are really
> conscientious can do some integration testing of linux-next and can
> report problems there to make the merge window go more smoothly after
> the New Year's.
>
> - Ted

I'll second (or third?) this motion... ;-)

Thanks,
Mike

2008-12-12 03:02:38

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <[email protected]> wrote:

> > > I still have one fix for a reported regression (softlink code doesn't
> > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > ago, but it didn't get anywhere.
> >
> > I don't have a clue what you're talking about.
> >
> > <greps the tree>
> >
> > ./fs/affs/inode.c: case ST_SOFTLINK:
> > ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
> >
> > really?
>
> Oh, I thought I cc'ed you...
>
> http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2

yes, but that stuff went round and round in circles and ended up all in
the air.

2008-12-12 03:07:23

by Nick Piggin

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Friday 12 December 2008 14:02, Andrew Morton wrote:
> On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <[email protected]>
wrote:
> > > > I still have one fix for a reported regression (softlink code doesn't
> > > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > > ago, but it didn't get anywhere.
> > >
> > > I don't have a clue what you're talking about.
> > >
> > > <greps the tree>
> > >
> > > ./fs/affs/inode.c: case ST_SOFTLINK:
> > > ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> > > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
> > >
> > > really?
> >
> > Oh, I thought I cc'ed you...
> >
> > http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> > http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
>
> yes, but that stuff went round and round in circles and ended up all in
> the air.

Hmm, OK. I think we ended up agreeing after some review and things
fixed since my original posting.

But it was an honest question -- is this too late to go in 2.6.28,
given that it has been present in earlier releases too? Maybe if the
release date is pushed to after Christmas, then there is enough time.
Otherwise, perhaps it should go upstream afterwards, then filter into
-stable?

Anyway, I'll repost them, in case you'd care to put them in -mm in
the meantime.

2008-12-12 03:19:58

by David Miller

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

From: David Howells <[email protected]>
Date: Thu, 11 Dec 2008 15:29:06 +0000

> Linus Torvalds <[email protected]> wrote:
>
> > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> > I like this, because alledgely people are debugging things, and we'd
> > get a more stable 2.6.28.
>
> Which would perhaps mean that the merge window is open during LCA, which will
> be inconvenient for some people. On the other hand, it might put the culprits
> where you can lay your hands on them.

That happened in Melbourne and it wasn't pleasant. Instead
of enjoying talks at the conference some of us were stressing
out on our laptops dealing with our merges instead.

2008-12-12 03:40:08

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Fri, 12 Dec 2008 13:07:02 +1000 Nick Piggin <[email protected]> wrote:

> On Friday 12 December 2008 14:02, Andrew Morton wrote:
> > On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <[email protected]>
> wrote:
> > > > > I still have one fix for a reported regression (softlink code doesn't
> > > > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > > > ago, but it didn't get anywhere.
> > > >
> > > > I don't have a clue what you're talking about.
> > > >
> > > > <greps the tree>
> > > >
> > > > ./fs/affs/inode.c: case ST_SOFTLINK:
> > > > ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> > > > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
> > > >
> > > > really?
> > >
> > > Oh, I thought I cc'ed you...
> > >
> > > http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> > > http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
> >
> > yes, but that stuff went round and round in circles and ended up all in
> > the air.
>
> Hmm, OK. I think we ended up agreeing after some review and things
> fixed since my original posting.
>
> But it was an honest question -- is this too late to go in 2.6.28,
> given that it has been present in earlier releases too? Maybe if the
> release date is pushed to after Christmas, then there is enough time.
> Otherwise, perhaps it should go upstream afterwards, then filter into
> -stable?

Well we could do either.

But it's not completely obvious what the actual bug is. Deadlock?
Suboptimal memory allocation mode? Arbitrary stack windup? Other?

> Anyway, I'll repost them, in case you'd care to put them in -mm in
> the meantime.

Sure..

2008-12-12 05:41:53

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008, David Miller wrote:

> From: David Howells <[email protected]>
> Date: Thu, 11 Dec 2008 15:29:06 +0000
>
> > Linus Torvalds <[email protected]> wrote:
> >
> > > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > >
> > > I like this, because alledgely people are debugging things, and we'd
> > > get a more stable 2.6.28.
> >
> > Which would perhaps mean that the merge window is open during LCA, which will
> > be inconvenient for some people. On the other hand, it might put the culprits
> > where you can lay your hands on them.
>
> That happened in Melbourne and it wasn't pleasant. Instead
> of enjoying talks at the conference some of us were stressing
> out on our laptops dealing with our merges instead.

Yes. I definitely want to close the 29 merge window before LCA. In fact, I
want to close it far enough before that we can fix up any worst issues.

Which does argue for opening it up during the holidays, I guess.

Linus

2008-12-12 07:54:26

by Joerg Roedel

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Thu, Dec 11, 2008 at 09:40:21PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 11 Dec 2008, David Miller wrote:
>
> > From: David Howells <[email protected]>
> > Date: Thu, 11 Dec 2008 15:29:06 +0000
> >
> > > Linus Torvalds <[email protected]> wrote:
> > >
> > > > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > > >
> > > > I like this, because alledgely people are debugging things, and we'd
> > > > get a more stable 2.6.28.
> > >
> > > Which would perhaps mean that the merge window is open during LCA, which will
> > > be inconvenient for some people. On the other hand, it might put the culprits
> > > where you can lay your hands on them.
> >
> > That happened in Melbourne and it wasn't pleasant. Instead
> > of enjoying talks at the conference some of us were stressing
> > out on our laptops dealing with our merges instead.
>
> Yes. I definitely want to close the 29 merge window before LCA. In fact, I
> want to close it far enough before that we can fix up any worst issues.
>
> Which does argue for opening it up during the holidays, I guess.

You can do a release around 29th/30th December. This gives the people
who are on vacation until the new year still a week for merging stuff
and the merge window closes 4-5 days before people are leaving for
LCA.

Joerg

2008-12-12 08:25:32

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

* Pekka Enberg <[email protected]> wrote:

> Hi Ingo,
>
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> wrote:
> > ok. In this case i'd suggest we should just remove the warning. People do
> > get scared by needless kernel stack dumps - no matter whether it's marked
> > informational or not.
> >
> > So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> > you think?
>
> How come we don't put it under CONFIG_X86_DEBUG or something and hide
> somewhere in the "Kernel debugging" menu?

okay - how about the following then instead - we still keep the warning,
but do various things to make it appear less scary.

Ingo

----------------->
>From 8808500f26a61757cb414da76b271bbd09d5958c Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Fri, 12 Dec 2008 09:20:12 +0100
Subject: [PATCH] x86: soften multi-BAR mapping sanity check warning message

Impact: make debug warning less scary

The ioremap() time multi-BAR map warning has been causing false
positives:

http://lkml.org/lkml/2008/12/10/432
http://lkml.org/lkml/2008/12/11/136

So make it less scary by making it once-per-boot, by making it KERN_INFO
and by adding this text:

"Info: mapping multiple BARs. Your kernel is fine."

Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/mm/ioremap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..bd85d42 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -223,7 +223,8 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
* Check if the request spans more than any BAR in the iomem resource
* tree.
*/
- WARN_ON(iomem_map_sanity_check(phys_addr, size));
+ WARN_ONCE(iomem_map_sanity_check(phys_addr, size),
+ KERN_INFO "Info: mapping multiple BARs. Your kernel is fine.");

/*
* Don't allow anybody to remap normal RAM that we're using..

2008-12-12 15:49:27

by Alan

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

> That happened in Melbourne and it wasn't pleasant. Instead
> of enjoying talks at the conference some of us were stressing
> out on our laptops dealing with our merges instead.

That argues for doing the merges before LCA so only the fallout is after
(when people are easily located).

But is there *ever* a good time ?

Alan

2008-12-12 15:56:45

by Arjan van de Ven

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Fri, 12 Dec 2008 09:24:56 +0100
Ingo Molnar <[email protected]> wrote:

>
> * Pekka Enberg <[email protected]> wrote:
>
> > Hi Ingo,
> >
> > On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> wrote:
> > > ok. In this case i'd suggest we should just remove the warning.
> > > People do get scared by needless kernel stack dumps - no matter
> > > whether it's marked informational or not.
> > >
> > > So how about the patch below, queued up in tip/x86/debug? Arjan,
> > > what do you think?
> >
> > How come we don't put it under CONFIG_X86_DEBUG or something and
> > hide somewhere in the "Kernel debugging" menu?
>
> okay - how about the following then instead - we still keep the
> warning, but do various things to make it appear less scary.

another thing we could do is try to only warn if you cross bar
boundaries but not if you cross other user-of-the-resource boundaries.

2008-12-12 16:12:34

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Fri, 12 Dec 2008, Arjan van de Ven wrote:
>
> another thing we could do is try to only warn if you cross bar
> boundaries but not if you cross other user-of-the-resource boundaries.

Hmm. We could use the res->flags for this. But I'm not sure non-PCI
resources fill those in correctly.

A pure "busy" allocation (ie a driver marker) would generally have just
the IORESOURCE_BUSY bit set, while a real PCI hardware resource will have
other bits set (ie the IORESOURCE_IO/MEM bits) and not be marked BUSY.

Maybe just ignoring resources with BUSY set, as they are driver markers
rather than actual HW resources.

Linus

2008-12-13 17:14:20

by Arjan van de Ven

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc8

On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
Linus Torvalds <[email protected]> wrote:

>
>
> On Fri, 12 Dec 2008, Arjan van de Ven wrote:
> >
> > another thing we could do is try to only warn if you cross bar
> > boundaries but not if you cross other user-of-the-resource
> > boundaries.
>
> Hmm. We could use the res->flags for this. But I'm not sure non-PCI
> resources fill those in correctly.
>
> A pure "busy" allocation (ie a driver marker) would generally have
> just the IORESOURCE_BUSY bit set, while a real PCI hardware resource
> will have other bits set (ie the IORESOURCE_IO/MEM bits) and not be
> marked BUSY.
>
> Maybe just ignoring resources with BUSY set, as they are driver
> markers rather than actual HW resources.

something like this: ?

From: Arjan van de Ven <[email protected]>
Date: Sat, 13 Dec 2008 09:12:18 -0800
Subject: [PATCH] resource: Don't warn for driver originated resource structures

Some drivers (vesafb) only map/reserve a portion of a resource.
If then some other driver comes in and maps the whole resource,
the current code WARN_ON's. This is not the intent of the checks
in iomem_map_sanity_check(); rather these checks want to
warn when crossing *hardware* resources only.

This patch skips BUSY resources as suggested by Linus.

Note: having two drivers talk to the same hardware at the same
time is obviously not optimal behavior, but that's a separate story.

Signed-off-by: Arjan van de Ven <[email protected]>
---
kernel/resource.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..e633106 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -853,6 +853,15 @@ int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
continue;
+ /*
+ * if a resource is "BUSY", it's not a hardware resource
+ * but a driver mapping of such a resource; we don't want
+ * to warn for those; some drivers legitimately map only
+ * partial hardware resources. (example: vesafb)
+ */
+ if (p->flags & IORESOURCE_BUSY)
+ continue;
+
printk(KERN_WARNING "resource map sanity check conflict: "
"0x%llx 0x%llx 0x%llx 0x%llx %s\n",
(unsigned long long)addr,
--
1.6.0.4

--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org

2008-12-16 22:35:16