All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Yinghai Lu <yinghai@kernel.org>, Gary Hade <garyhade@us.ibm.com>,
	Matthew Wilcox <matthew@wil.cx>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-pci@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/pci: don't use crs for root if we only have one root bus
Date: Thu, 25 Jun 2009 12:58:26 +0530	[thread overview]
Message-ID: <1245914906.3116.66.camel@localhost.localdomain> (raw)
In-Reply-To: <20090625070347.GB2676@elte.hu>

On Thu, 2009-06-25 at 09:03 +0200, Ingo Molnar wrote:
> * Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > > [ There's a difference between "we're supposed to find and fix bugs
> > > in the -rc series", and "I release known-buggy -rc1's since we're
> > > supposed to fix it later". For similar reasons, I hate pulling
> > > known-buggy stuff during the merge window - it's ok if it shows
> > > itself to be buggy _later_, but if people send me stuff that they
> > > know is buggy as they send it to me, then that's a problem. ]
> > 
> > Yeah, 100% agreed.  I didn't hear any reports until after people 
> > started using your tree, so I think this case was handled 
> > correctly: push something that *seems* ok upstream, but with eyes 
> > wide open for the possibility we'd need to revert.
> 
> There's only one small gripe i have with the handling of it: the 
> timing. "9e9f46c: PCI: use ACPI _CRS data by default" was written 
> and committed on June 11th, two days _after_ the merge window 
> opened.
> 
> That's way too late for maybe-broken changes to x86 lowlevel details 
> (especially if it touches hw-environmental interaction - which is 
> very hard to test with meaningful coverage), and it's also pretty 
> much the worst moment to solicit testing from people who are busy 
> getting their stuff to Linus and who are busy testing out any of the 
> unexpected interactions and bugs.
> 
> So this was, to a certain degree, a predictable outcome. Trees in 
> the Linux "critical path" of testing (core kernel, x86, core 
> networking, very common drivers, PCI, driver core, VFS, etc.) should 
> generally try to cool down 1-2 weeks before the merge window - 
> because breakage there can do a lot of knock-on cascading damage. 
> Two weeks is not a lot of time and the effects of showstopper bugs 
> get magnified disproportionately.
> 

Yes, I was also thinking about this when I checked the commit date. And
totally agree with Ingo's suggestions.

Thanks,
--
JSR


  reply	other threads:[~2009-06-25  7:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090624122433.GA24781@elte.hu>
     [not found] ` <20090624145119.GA12664@elte.hu>
2009-06-24 21:46   ` [PATCH] x86: fix _CRS resources return handling Yinghai Lu
2009-06-24 21:48     ` [PATCH] x86/pci: get root CRS before scan child -v2 Yinghai Lu
2009-06-24 22:37       ` Jesse Barnes
2009-06-25  0:03         ` Yinghai
2009-06-24 22:58     ` [PATCH] x86/pci: don't use crs for root if we only have one root bus Yinghai Lu
2009-06-24 23:09       ` Linus Torvalds
2009-06-24 23:21         ` Linus Torvalds
2009-06-24 23:37           ` Jesse Barnes
2009-06-24 23:54             ` Linus Torvalds
2009-06-25  0:01               ` Jesse Barnes
2009-06-25  7:03                 ` Ingo Molnar
2009-06-25  7:28                   ` Jaswinder Singh Rajput [this message]
2009-06-25 16:28                   ` Jesse Barnes
2009-06-25  0:00         ` Gary Hade
2009-06-25  2:01     ` [PATCH 1/3] x86/pci: fix boundary checking when using root CRS Yinghai Lu
2009-06-25  2:02       ` [PATCH 2/3] x86/pci: get root CRS before scan childs -v3 Yinghai Lu
2009-06-25  3:00         ` [PATCH 2/3] x86/pci: get root CRS before scan childs -v4 Yinghai Lu
2009-06-30  1:16       ` [PATCH 1/3] x86/pci: fix boundary checking when using root CRS Jesse Barnes
2009-06-30 18:04         ` Gary Hade
2009-06-30 21:00           ` Jesse Barnes

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=1245914906.3116.66.camel@localhost.localdomain \
    --to=jaswinder@kernel.org \
    --cc=Larry.Finger@lwfinger.net \
    --cc=akpm@linux-foundation.org \
    --cc=garyhade@us.ibm.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.