Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
On Fri, Mar 27, 2015 at 08:46:57AM +0100, Daniel Vetter wrote: > On Thu, Mar 26, 2015 at 11:05:45PM +0200, Imre Deak wrote: > > On Thu, 2015-03-26 at 22:01 +0100, Greg Kroah-Hartman wrote: > > > On Thu, Mar 26, 2015 at 12:59:05PM -0700, Jesse Barnes wrote: > > > > On 12/16/2014 09:42 AM, Daniel Vetter wrote: > > > > > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley > > > > > wrote: > > > > >> On 12/16/2014 11:22 AM, Imre Deak wrote: > > > > >>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote: > > > > Fine. Just another expedient fix piled on top of other expedient > > > > fixes > > > > that go back past 3.9 with no end in sight. > > > > >>> > > > > >>> I'm also happy to look into narrowing down the scope of > > > > >>> console_lock in > > > > >>> fbdev/fbcon as was suggested. But doing that as a follow-up to this > > > > >>> change still makes sense to me since it will take more time and > > > > >>> have the > > > > >>> risk of regressions that are not related to what this change fixes. > > > > >> > > > > >> I apologize for my tone. I'm not blaming you for the current > > > > >> situation, > > > > >> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack > > > > >> inversion. I'm just trying to bring some awareness of the larger > > > > >> scope, > > > > >> so that collectively we take action and resolve the underlying > > > > >> problems. > > > > > > > > > > Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too. > > > > > We have a lot of nonoptimal solutions at hand here :( > > > > > > > > So where does that leave us with this fix? Should we wait for someone > > > > to come along and do all the rework? Imre said he'd be willing to do > > > > it, but still feels this fix makes sense > > > > > > > > Or we could just abandon the fb layer altogether (my preference). In > > > > that case fixing this is fine, since we'll be able to ignore it for > > > > configs that switch over to using !fbdev and kmscon. > > > > > > I think I already merged the patches a while ago :) > > > > Yes, but only the first two patches. This third one is not merged > > AFAICS. > > Yeah there was a big discussion in that one which eventualy resulted in my > grumpy ack and my nack retracted. So fwiw > > Reviewed-by: Daniel Vetter Can someone resend this patch? It's long-gone from my patch queue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
On Thu, Mar 26, 2015 at 11:05:45PM +0200, Imre Deak wrote: > On Thu, 2015-03-26 at 22:01 +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 26, 2015 at 12:59:05PM -0700, Jesse Barnes wrote: > > > On 12/16/2014 09:42 AM, Daniel Vetter wrote: > > > > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley > > > > wrote: > > > >> On 12/16/2014 11:22 AM, Imre Deak wrote: > > > >>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote: > > > Fine. Just another expedient fix piled on top of other expedient > > > fixes > > > that go back past 3.9 with no end in sight. > > > >>> > > > >>> I'm also happy to look into narrowing down the scope of console_lock > > > >>> in > > > >>> fbdev/fbcon as was suggested. But doing that as a follow-up to this > > > >>> change still makes sense to me since it will take more time and have > > > >>> the > > > >>> risk of regressions that are not related to what this change fixes. > > > >> > > > >> I apologize for my tone. I'm not blaming you for the current situation, > > > >> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack > > > >> inversion. I'm just trying to bring some awareness of the larger scope, > > > >> so that collectively we take action and resolve the underlying > > > >> problems. > > > > > > > > Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too. > > > > We have a lot of nonoptimal solutions at hand here :( > > > > > > So where does that leave us with this fix? Should we wait for someone > > > to come along and do all the rework? Imre said he'd be willing to do > > > it, but still feels this fix makes sense > > > > > > Or we could just abandon the fb layer altogether (my preference). In > > > that case fixing this is fine, since we'll be able to ignore it for > > > configs that switch over to using !fbdev and kmscon. > > > > I think I already merged the patches a while ago :) > > Yes, but only the first two patches. This third one is not merged > AFAICS. Yeah there was a big discussion in that one which eventualy resulted in my grumpy ack and my nack retracted. So fwiw Reviewed-by: Daniel Vetter on 3/3. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
On Thu, 2015-03-26 at 22:01 +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 26, 2015 at 12:59:05PM -0700, Jesse Barnes wrote: > > On 12/16/2014 09:42 AM, Daniel Vetter wrote: > > > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley > > > wrote: > > >> On 12/16/2014 11:22 AM, Imre Deak wrote: > > >>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote: > > Fine. Just another expedient fix piled on top of other expedient fixes > > that go back past 3.9 with no end in sight. > > >>> > > >>> I'm also happy to look into narrowing down the scope of console_lock in > > >>> fbdev/fbcon as was suggested. But doing that as a follow-up to this > > >>> change still makes sense to me since it will take more time and have the > > >>> risk of regressions that are not related to what this change fixes. > > >> > > >> I apologize for my tone. I'm not blaming you for the current situation, > > >> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack > > >> inversion. I'm just trying to bring some awareness of the larger scope, > > >> so that collectively we take action and resolve the underlying problems. > > > > > > Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too. > > > We have a lot of nonoptimal solutions at hand here :( > > > > So where does that leave us with this fix? Should we wait for someone > > to come along and do all the rework? Imre said he'd be willing to do > > it, but still feels this fix makes sense > > > > Or we could just abandon the fb layer altogether (my preference). In > > that case fixing this is fine, since we'll be able to ignore it for > > configs that switch over to using !fbdev and kmscon. > > I think I already merged the patches a while ago :) Yes, but only the first two patches. This third one is not merged AFAICS. --Imre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
On Thu, Mar 26, 2015 at 12:59:05PM -0700, Jesse Barnes wrote: > On 12/16/2014 09:42 AM, Daniel Vetter wrote: > > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley > > wrote: > >> On 12/16/2014 11:22 AM, Imre Deak wrote: > >>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote: > Fine. Just another expedient fix piled on top of other expedient fixes > that go back past 3.9 with no end in sight. > >>> > >>> I'm also happy to look into narrowing down the scope of console_lock in > >>> fbdev/fbcon as was suggested. But doing that as a follow-up to this > >>> change still makes sense to me since it will take more time and have the > >>> risk of regressions that are not related to what this change fixes. > >> > >> I apologize for my tone. I'm not blaming you for the current situation, > >> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack > >> inversion. I'm just trying to bring some awareness of the larger scope, > >> so that collectively we take action and resolve the underlying problems. > > > > Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too. > > We have a lot of nonoptimal solutions at hand here :( > > So where does that leave us with this fix? Should we wait for someone > to come along and do all the rework? Imre said he'd be willing to do > it, but still feels this fix makes sense. > > Or we could just abandon the fb layer altogether (my preference). In > that case fixing this is fine, since we'll be able to ignore it for > configs that switch over to using !fbdev and kmscon. I think I already merged the patches a while ago :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
On 12/16/2014 09:42 AM, Daniel Vetter wrote: > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley > wrote: >> On 12/16/2014 11:22 AM, Imre Deak wrote: >>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote: Fine. Just another expedient fix piled on top of other expedient fixes that go back past 3.9 with no end in sight. >>> >>> I'm also happy to look into narrowing down the scope of console_lock in >>> fbdev/fbcon as was suggested. But doing that as a follow-up to this >>> change still makes sense to me since it will take more time and have the >>> risk of regressions that are not related to what this change fixes. >> >> I apologize for my tone. I'm not blaming you for the current situation, >> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack >> inversion. I'm just trying to bring some awareness of the larger scope, >> so that collectively we take action and resolve the underlying problems. > > Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too. > We have a lot of nonoptimal solutions at hand here :( So where does that leave us with this fix? Should we wait for someone to come along and do all the rework? Imre said he'd be willing to do it, but still feels this fix makes sense. Or we could just abandon the fb layer altogether (my preference). In that case fixing this is fine, since we'll be able to ignore it for configs that switch over to using !fbdev and kmscon. Thanks, Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
