linux-kernel - Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

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: <20150319154141.GJ25365@htj.duckdns.org>
Date:	Thu, 19 Mar 2015 11:41:41 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@...e.com>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

Hello, Dmitry.

On Wed, Mar 18, 2015 at 05:26:19PM -0700, Dmitry Torokhov wrote:
> Why would they get decoupled? For example, if we are talking about input
> devices, they can be connected to platform bus or one of i2c buses or
> HID (via USB). If we want to ensure ordering we'd have to synchronize
> all of them somehow and I do not have even sure what the rule should be.
> I mean I am probing platform devices simultaneously and I come to an
> i2c controller and gpio input device. So I wait till both done probing
> before posting new devices to the driver core? What if one returns
> -EPROBE_DEFER? Do I stop and wait for the deferral to complete? What if
> deferral is satisfied by a 3rd device on platform bus? If I am waiting
> for all devices to probe I won't be able to resolve the deferral. And
> even without deferral in old world we'd probe i2c and i2c will lead to
> discovery of another input device which would be registered before
> registering the platform input device. So with async we'd have to pause
> platform probing until all children of i2c are done probing, which
> pretty much kills all async gains as far as I can see.
...
> I think the logic is pretty much the same even with async probing,
> especially if you take into account -EPROBE_DEFER handling that we
> already have. You may not run into it that often on x86 but it is pretty
> common on arm devices and it does change the probe order.

I see, so, if ordering has never been reliable for a given platform or
class of devices, there's nothing to worry about.  Or even if ordering
has been reliable but change of ordering wouldn't be noticable from
userland, that'd be fine too.  The thing is that for certain classes
of devices, we've been guaranteeing probe ordering during boot and
there are non-insignificant number of use cases which depend on that
and we should be able to accomodate them.

I don't think this'd be a huge burden.  e.g. even something like
synchronizing once for all async pci probes can be enough.  That
should be enough for most traditional storage devices and that's the
biggest item.

> I do not think this flag is useful for end users but rather for
> distributions. Either their userspace is ready to handle fully async
> probe or not quite yet.

I think we should be able to enable all-async probing by default and
that'd be far beneficial and simpler for everybody.

Thanks.

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