Re: [PATCH] backports: backport drvdata = NULL core driver fixes

[Luis R. Rodriguez]

On Fri, Jul 19, 2013 at 8:36 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 19 Jul 2013, Luis R. Rodriguez wrote:
>
>> Thanks Julia. In that case I'm going to just leave this in place given
>> that if there's a bug upstream we'll get it fixed as soon as a
>> respective patch gets upstream as well. That is, we are not using old
>> drivers, we use the same upstream drivers so if a regression was found
>> in backports the fix must go upstream s well. This is one of the
>> benefits of backporting -- the range of users and testers increases
>> and we still benefit from the upstream bandwagon.
>
> I don't understand.  If you're not using old drivers, and you
> incorporate all the upstream patches, then what's the difference
> between a backport and the current kernel?

The difference is that in older kernels driver_probe_device() and
device_release_driver() wouldn't do the setting to NULL in case of
probe fail or release, that's what the patch does. Given that the new
drivers have the superfluous setting removed we'd need a way to get
older kernels to clear it as well and there were two ways to do it --
revert the changes for all drivers this was cleared from or hack up
the same callback used driver_probe_device() and
device_release_driver() to do the appropriate clearing prior to
calling the old kernel's routines.

> In fact, if you're
> incorporating all the upstream driver patches, then why haven't you
> already got the drvdata change?

Because older kernel's driver_probe_device() and
device_release_driver() would be used.

> As one example of the sort of subtle problem exposed by the drvdata
> change, take a look at commit b2ca69907657.

Understood.

> For more examples, see commits bf90ff5f3b8f, 638b9e15233c,
> 51ef847df746, 289b076f89c2, 53636555b919, 99a6f73c495c, 003615302a16,
> 94ab71ce2889, 3124d1d71d3d, c27f3efc5608, 95940a04bfe8, 5c1a0f418d8d,
> db5c8b524444, 8bf769eb5f6e, 4295fe7791a1, fa919751a2d2, a9556040119a,
> 7bdce71822f4, and a1028f0abfb3.  Admittedly, these are all related
> problems in a single subsystem, but it gives you a little idea of how
> far this goes.

Sure, I understand. By pushing the newer drivers as-is *and* by
providing the driver_probe_device() and device_release_driver()
respective changes for older kernels it should get us similar behavior
on older kernels. Mind you, there is a small race in the way I
implemented this on device_release_driver() but that seems like a
reasonable tradeoff against all other alternatives I could come up
with.

As it is now, unless my port is incorrect, the newer drivers used on
older systems should trigger a similar bug as if using the upstream
kernel with the same drivers.

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