On Sun, Jul 9, 2017 at 7:07 PM, Jason A. Donenfeld wrote:
> On Sat, Jul 8, 2017 at 12:39 AM, Cong Wang wrote:
>> On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld wrote:
>>> list_add(&priv->list, &list_of_things);
>>>
>>> ret = register_netdevice(); // if ret is < 0, then destru
On Sat, Jul 8, 2017 at 12:39 AM, Cong Wang wrote:
> On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld wrote:
>> list_add(&priv->list, &list_of_things);
>>
>> ret = register_netdevice(); // if ret is < 0, then destruct above is
>> automatically called
>>
>> // RACE WITH L
On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld wrote:
> list_add(&priv->list, &list_of_things);
>
> ret = register_netdevice(); // if ret is < 0, then destruct above is
> automatically called
>
> // RACE WITH LIST_ADD/LIST_DEL!! It's impossible to call list_add
> only
On Thu, Jul 6, 2017 at 4:24 PM, Jason A. Donenfeld wrote:
>
> if (!ret)
> pr_info("Yay it worked!\n");
>
> return 0;
This is supposed to be `return ret;`. See, even in psuedocode it's
hard to get right.
Hey guys,
I see why this priv_destructor patch is an acceptable bandaid for
certain drivers, but I'm not exactly sure on the cleanest way of using
it in new drivers. Check out the following psuedocode.
Here's how error handling in newlink used to work before this patch:
static void destruct(stru
