lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140912164045.GA27663@kroah.com>
Date:	Fri, 12 Sep 2014 09:40:45 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
	Luciano Coelho <luca@...lho.fi>, Kalle Valo <kvalo@...rom.com>,
	dri-devel@...ts.freedesktop.org, linux-wireless@...r.kernel.org
Subject: Re: [RFC v2] device coredump: add new device coredump class

On Mon, Sep 08, 2014 at 10:38:07AM +0200, Johannes Berg wrote:
> On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> 
> > > +	/*
> > > +	 * 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().
> 
> I looked at this again, and it's the other way around. This is the link
> that Daniel requested, from the original device to the one that's being
> freed. For whatever reason though, symlinks don't automatically go away
> when freed:
> 
> (with a test patch that makes "mac80211-hwsim" crash whenever we have
> radar)
> 
> # echo 1 > /sys/kernel/debug/ieee80211/phy0/hwsim/dfs_simulate_radar
> # ls /sys/class/devcoredump/
> devcd1
> # ls /sys/class/devcoredump/devcd1/
> data            failing_device/ power/          subsystem/      uevent
> # ls -l /sys/class/mac80211_hwsim/hwsim0/dev_coredump
> lrwxrwxrwx 1 root root 0 Sep  8 08:34 /sys/class/mac80211_hwsim/hwsim0/dev_coredump -> ../../devcoredump/devcd1
> # echo > /sys/class/devcoredump/devcd1/data
> # ls /sys/class/devcoredump/
> # ls -l /sys/class/mac80211_hwsim/hwsim0/dev_coredump
> lrwxrwxrwx 1 root root 0 Sep  8 08:34 /sys/class/mac80211_hwsim/hwsim0/dev_coredump -> ../../devcoredump/devcd1
> 
> (but the link is now dead)
> 
> Maybe I'm creating the links in the wrong way so they don't
> automatically get removed when the struct device is released?

No, you are correct, sorry for the noise, I thought the symlink was the
other way around for some reason.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ