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]

Message-ID: <1395088410.15098.175.camel@pasglop>
Date:	Tue, 18 Mar 2014 07:33:30 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Greg KH <greg@...ah.com>
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 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 ? :-)

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.

Cheers,
Ben.

--
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/