[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5277D4AD.10308@enst-bretagne.fr>
Date: Mon, 04 Nov 2013 18:09:01 +0100
From: Florent Fourcot <florent.fourcot@...t-bretagne.fr>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH RFC] ipv6: enable IPV6_FLOWLABEL_MGR for getsockopt
> We should take ip6_fl_lock here, otherwise expires extraction races with
> the garbage collector (which can update it). There seem to be some other
> unsafe places, e.g. fl6_renew.
>
I will fix it, and for fl6_renew too.
>> + freq->flr_label = sfl->fl->label;
>> + freq->flr_dst = sfl->fl->dst;
>> + freq->flr_share = sfl->fl->share;
>> + freq->flr_expires = (sfl->fl->expires - jiffies) / HZ;
>> + freq->flr_linger = sfl->fl->linger / HZ;
>> +
>> + rcu_read_unlock_bh();
>> + return 0;
>> + }
>> + }
>> + rcu_read_unlock_bh();
>> +
>> + return 0;
>
> Maybe return -EINVAL for not found?
>
I don't like -EINVAL for this case, since the user can not know if there
are no label or if the request has bad parameters. Could -ENOMSG be OK?
>> + case IPV6_FLOWLABEL_MGR:
>> + {
>> + struct in6_flowlabel_req freq;
>> +
>
> Can you think about other actions one might do with this getsockopt? Maybe
> we should copy_from_user freq and check if action specifies a GET
> request. So a further extension to this API won't break users which did
> pass uninitialized memory to this getsockopt.
>
Very good idea.
Regards,
--
Florent.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists