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: <87pplkgyij.fsf@river.i-did-not-set--mail-host-address--so-tickle-me>
Date:	Tue, 18 Mar 2014 11:07:32 +1100
From:	Stewart Smith <stewart@...ux.vnet.ibm.com>
To:	Tejun Heo <tj@...nel.org>, Greg KH <greg@...ah.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Mark Brown <broonie@...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

Tejun Heo <tj@...nel.org> writes:
> On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
>> I think this is being blown out of proportion.  It was a rarely used
>> API and converting to the new one is mostly trivial which can be
>
> So, looked at the failed code.  The only necessary change seems to be
> calling device_remove_file_self() in dump_ack_store() and then doing
> kobject_put() directly afterwards, which would have been completely
> fine as a merge fix patch.

I had a quick look too and this seems correct (at least if my reading on
howto use sysfs APIs is correct).

I'm happy to post a patch somewhere - I guess it's easiest if the
removal waits for one linus merge things cycle and then I can get fix
and removal in? I'm not too fussed.

> Just to be clear, I'm not necessarily against reverting the removal of
> the API.  The removal was based on the speculation that this isn't
> likely to cause trouble.  The speculation was perfectly reasonable but
> being a speculation it failed, so we take actions to remedy that and
> we *do* want to do things that way.  Reverting the removal can sure be
> one choice but the way that choice is being made here seems completely
> wrong to me.  There's no technical evaluation whatsoever.  I'd really
> hate to work in an environment where taking active trade off is
> discouraged replaced with blind policy enforcement.

I use an API and it changes/disappears - it's a gift I have :)

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