mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
	Luciano Coelho <luca@coelho.fi>, Kalle Valo <kvalo@adurom.com>,
	dri-devel@lists.freedesktop.org, linux-wireless@vger.kernel.org
Subject: Re: [RFC v2] device coredump: add new device coredump class
Date: Sun, 07 Sep 2014 11:37:03 +0200	[thread overview]
Message-ID: <1410082623.2650.9.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <20140905221314.GA1533@kroah.com>

On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:

> > +MODULE_AUTHOR("Johannes Berg <johannes@sipsolutions.net>");
> > +MODULE_DESCRIPTION("Device Coredump support");
> > +MODULE_LICENSE("GPL");
> 
> As you only allow Y or N as build options, it's not really a "module" :)

Umm, yeah. I went back and forth on whether this should be allowed to be
modular, but then decided it wasn't big enough to be worth it.

> > +	/*
> > +	 * this seems racy, but I don't see a notifier or such on
> > +	 * a struct device to know when it goes away?
> > +	 */
> > +	if (devcd->failing_dev->kobj.sd)
> > +		sysfs_delete_link(&devcd->failing_dev->kobj, &dev->kobj,
> > +				  "dev_coredump");
> 
> What is this link?  It should "just go away" if this:
> 
> > +	put_device(devcd->failing_dev);
> 
> was the last put_device() call on the failing_dev, right?  So you
> shouldn't need to make this call to sysfs_delete_link().

Oh, thanks, I'll try that. I did something slightly different first and
ended up with dead symlinks, but in that case I think I was actually
removing the bus/class of the device while the device was still alive or
something - that was a big mess.

> > +void dev_coredumpm(struct device *dev, struct module *owner,
> > +		   const void *data, size_t datalen, gfp_t gfp,
> > +		   ssize_t (*read)(char *buffer, loff_t offset, size_t count,
> > +				   const void *data, size_t datalen),
> > +		   void (*free)(const void *data))
> > +{
> > +	static atomic_t devcd_count = ATOMIC_INIT(0);
> > +	struct devcd_entry *devcd;
> > +	struct device *existing;
> > +
> > +	existing = class_find_device(&devcd_class, NULL, dev,
> > +				     devcd_match_failing);
> > +	if (existing) {
> > +		put_device(existing);
> > +		return;
> > +	}
> 
> I thought multiple dumps per "device" would throw away the older ones?
> It's fine if you don't, but you might want to document this behavior in
> the kerneldoc for the function.

I ... umm ... Yeah. I need to free the new one here. I actually wanted
to keep the first one because it seems likely that the driver would
attempt some sort of recovery and then if it happens to crash the device
again it's probably not very helpful to see the last crash.

But I definitely need to free the new one and document the behaviour.
Maybe if somebody needs something else we can make it configurable, but
for now I think all potential users have indicated that they'd prefer
keeping the first dump.

> Other than those very minor things, looks good to me, want to resend it
> cleaned up and without the "RFC" in the Subject?

Tomorrow :)

johannes


  reply	other threads:[~2014-09-07  9:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05  8:50 Johannes Berg
2014-09-05  9:40 ` Jonas Gorski
2014-09-05  9:56   ` Johannes Berg
2014-09-05 22:13 ` Greg Kroah-Hartman
2014-09-07  9:37   ` Johannes Berg [this message]
2014-09-08  8:38   ` Johannes Berg
2014-09-12 16:40     ` Greg Kroah-Hartman
2014-09-07  7:42 ` Arik Nemtsov
2014-09-08  8:36 ` Arend van Spriel

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=1410082623.2650.9.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emmanuel.grumbach@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvalo@adurom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luca@coelho.fi \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome