linux-kernel - Re: linux-next: build failure after merge of the driver-core tree

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Mar 2014 14:56:19 -0700
From:	Greg KH <greg@...ah.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Mark Brown <broonie@...nel.org>,
	Stewart Smith <stewart@...ux.vnet.ibm.com>,
	Tejun Heo <tj@...nel.org>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the driver-core tree

On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
> 
> > There were only 3 (or 4), users of this api, and no new ones had been
> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
> > ever be added again, especially as it was just removed entirely not
> > being needed anymore.  And I'd argue, it's something that you shouldn't
> > have even been doing in the first place, so why a new user of it was
> > added now is quite strange to me.
> 
> Actually that's a good question. Is there a better way for us than to
> use this API ? Essentially we use that because it's our understanding
> that it is what is needed for a sysfs file that can remove its parent
> directory from within a write() op.
> 
> We followed the driver "remove" implementation as an example.
> 
> The reason the opal elog and dump patches use it is that those two
> patches add sysfs interface that represent the error logs (and platform
> dumps but you can treat the latter as some kind of special case of error
> logs) from the service processor in sysfs.
> 
> So for each log we create a dir (kobject) which we populate with a few
> things like the log unique ID, raw data, etc.... and a file that can be
> used to "ack" the log with the service processor.
> 
> The latter has the effect of removing it. This is done by the collection
> daemon after it has confirmed that the error log has been stored to disk
> and properly flushed.
> 
> Is there a better interface ? Can we implement for example unlink() on
> the kobject itself ? IE. Do the ack by essentially having userspace rm
> the directory ? :-)

No you can't, sorry.

And this seems like a huge abuse of sysfs, you better be using binary
sysfs files for your log data...

Do you have a pointer to where you document this sysfs api in
Documentation/ABI/ ?

> Now regarding the practicals of sorting out our trees, Stephen suggested
> that rather than doing anything on my side (heh, I like that !), you
> should revert the last patch of the series, the one removing the old
> API, in your tree.
> 
> It can then be re-applied later around rc1.

I'll look to see if we can do that, let me dig it up out of my tree...

thanks,

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/