All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Liu, Chuansheng" <chuansheng.liu@intel.com>
Cc: "tj@kernel.org" <tj@kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] devres: Freeing the drs after all release() are called
Date: Wed, 6 Nov 2013 17:56:46 -0800	[thread overview]
Message-ID: <20131107015646.GA5942@kroah.com> (raw)
In-Reply-To: <27240C0AC20F114CBF8149A2696CBE4A01B867B8@SHSMSX101.ccr.corp.intel.com>

On Thu, Nov 07, 2013 at 01:18:54AM +0000, Liu, Chuansheng wrote:
> Hello,
> 
> > -----Original Message-----
> > From: Tejun Heo [mailto:htejun@gmail.com] On Behalf Of tj@kernel.org
> > Sent: Thursday, November 07, 2013 8:52 AM
> > To: Liu, Chuansheng
> > Cc: Greg KH; dmitry.torokhov@gmail.com; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] devres: Freeing the drs after all release() are called
> > 
> > Hello,
> > 
> > On Thu, Nov 07, 2013 at 12:36:56AM +0000, Liu, Chuansheng wrote:
> > > Yes, I knew I can put the code always like below:
> > > A = devm_kzalloc();
> > > C = devm_kzalloc();
> > > ...
> > > B= devm_request_threaded_irq(isr_handler);
> > >
> > > But, the above is just one simple coding prototype, if there are many calling:
> > > E -- > F -- > D -- >... then to devm_kzalloc().
> > >
> > > To be honest, it will make code too hard to always adapt the rule?
> > > And I trying to find out every potential devm_kzalloc() before irq requesting.
> > 
> > It isn't a good idea to paper over existing bugs from upper layer.
> > You realize that the above code sequence is already buggy during init
> > unless there's something explicitly blocking generation of irqs until
> > init is complete, right?  The right thing to do would be either
> > reordering the operations or wrapping the operation which unblocks irq
> > at the end of init with devres so that irq gets blocked before the
> > rest of release proceeds.
> > 
> > What we must *NOT* do is working around existing bugs in a half-assed
> > way from midlayer.  
> 
> Yes, doing the right order initialization is always right thing.
> But normally when we hit the panic during shutdown/reboot like below:
> PAGE FAULT XXX 0x12345678
> 
> It is really difficult to debug.
> So at least, could we have method to expose these hidden issues?

Have you enabled timer debugging?  I think there's an irq debugging
option as well.

We aren't going to paper over driver bugs by changing the kernel core,
sorry.  Consider this patch dropped.

greg k-h

      reply	other threads:[~2013-11-07  1:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06  6:40 [PATCH] devres: Freeing the drs after all release() are called Chuansheng Liu
2013-11-06  8:58 ` Greg KH
2013-11-07  0:27   ` Liu, Chuansheng
2013-11-07  0:29     ` tj
2013-11-07  0:36       ` Liu, Chuansheng
2013-11-07  0:46         ` Dmitry Torokhov
2013-11-07  0:53           ` Liu, Chuansheng
2013-11-07  0:51         ` tj
2013-11-07  1:18           ` Liu, Chuansheng
2013-11-07  1:56             ` Greg KH [this message]

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=20131107015646.GA5942@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=chuansheng.liu@intel.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@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.