Michel Dänzer
2018-Feb-14 14:43 UTC
[Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
On 2018-02-14 03:08 PM, Sean Paul wrote:> On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote: >> Op 14-02-18 om 09:46 schreef Lukas Wunner: >>> Dear drm-misc maintainers, >>> >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013: >>> This series has been reviewed, consent has been expressed by the most >>> interested parties, patch [1/5] which touches files outside drivers/gpu >>> has been acked and I've just out a v2 addressing the only objection >>> raised. My plan is thus to wait another two days for comments and, >>> barring further objections, push to drm-misc this weekend. >>> >>> However I'm struggling with the decision whether to push to next or >>> fixes. The series is marked for stable, however the number of >>> affected machines is limited and for an issue that's been present >>> for 5 years it probably doesn't matter if it soaks another two months >>> in linux-next befor it gets backported. Hence I tend to err on the >>> side of caution and push to next, however a case could be made that >>> fixes is more appropriate. >>> >>> I'm lacking experience making such decisions and would be interested >>> to learn how you'd handle this. >>> >>> Thanks, >>> >>> Lukas >> >> I would say fixes, it doesn't look particularly scary. :) > > Agreed. If it's good enough for stable, it's good enough for -fixes!It's not that simple, is it? Fast-tracking patches (some of which appear to be untested) to stable without an immediate cause for urgency seems risky to me. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Sean Paul
2018-Feb-14 14:58 UTC
[Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:> On 2018-02-14 03:08 PM, Sean Paul wrote: > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote: > >> Op 14-02-18 om 09:46 schreef Lukas Wunner: > >>> Dear drm-misc maintainers, > >>> > >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: > >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013: > >>> This series has been reviewed, consent has been expressed by the most > >>> interested parties, patch [1/5] which touches files outside drivers/gpu > >>> has been acked and I've just out a v2 addressing the only objection > >>> raised. My plan is thus to wait another two days for comments and, > >>> barring further objections, push to drm-misc this weekend. > >>> > >>> However I'm struggling with the decision whether to push to next or > >>> fixes. The series is marked for stable, however the number of > >>> affected machines is limited and for an issue that's been present > >>> for 5 years it probably doesn't matter if it soaks another two months > >>> in linux-next befor it gets backported. Hence I tend to err on the > >>> side of caution and push to next, however a case could be made that > >>> fixes is more appropriate. > >>> > >>> I'm lacking experience making such decisions and would be interested > >>> to learn how you'd handle this. > >>> > >>> Thanks, > >>> > >>> Lukas > >> > >> I would say fixes, it doesn't look particularly scary. :) > > > > Agreed. If it's good enough for stable, it's good enough for -fixes! > > It's not that simple, is it? Fast-tracking patches (some of which appear > to be untested) to stable without an immediate cause for urgency seems > risky to me. >/me should be more careful what he says Given where we are in the release cycle, it's barely a fast track. If these go in -fixes, they'll get in -rc2 and will have plenty of time to bake. If we were at rc5, it might be a different story. Sean> > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer-- Sean Paul, Software Engineer, Google / Chromium OS
Lukas Wunner
2018-Feb-15 05:38 UTC
[Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:> On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote: > > On 2018-02-14 03:08 PM, Sean Paul wrote: > > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote: > > >> Op 14-02-18 om 09:46 schreef Lukas Wunner: > > >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: > > >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013: > > >>> This series has been reviewed, consent has been expressed by the most > > >>> interested parties, patch [1/5] which touches files outside drivers/gpu > > >>> has been acked and I've just out a v2 addressing the only objection > > >>> raised. My plan is thus to wait another two days for comments and, > > >>> barring further objections, push to drm-misc this weekend. > > >>> > > >>> However I'm struggling with the decision whether to push to next or > > >>> fixes. The series is marked for stable, however the number of > > >>> affected machines is limited and for an issue that's been present > > >>> for 5 years it probably doesn't matter if it soaks another two months > > >>> in linux-next befor it gets backported. Hence I tend to err on the > > >>> side of caution and push to next, however a case could be made that > > >>> fixes is more appropriate. > > >>> > > >>> I'm lacking experience making such decisions and would be interested > > >>> to learn how you'd handle this. > > >> > > >> I would say fixes, it doesn't look particularly scary. :) > > > > > > Agreed. If it's good enough for stable, it's good enough for -fixes! > > > > It's not that simple, is it? Fast-tracking patches (some of which appear > > to be untested) to stable without an immediate cause for urgency seems > > risky to me. > > /me should be more careful what he says > > Given where we are in the release cycle, it's barely a fast track. > If these go in -fixes, they'll get in -rc2 and will have plenty of > time to bake. If we were at rc5, it might be a different story.The patches are marked for stable though, so if they go in through drm-misc-fixes, they may appear in stable kernels before 4.16-final is out. Greg picks up patches once they're in Linus' tree, though often with a delay of a few days or weeks. If they go in through drm-misc-next, they're guaranteed not to appear in *any* release before 4.16-final is out. This allows for differentiation between no-brainer stable fixes that can be sent immediately and scarier, but similarly important stable fixes that should soak for a while. I'm not sure which category this series belongs to, though it's true what Maarten says, it's not *that* grave a change. Thanks, Lukas
Seemingly Similar Threads
- [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
- [Intel-gfx] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
- [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
- [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
- [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers