From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florent Fourcot Subject: Re: [PATCH RFC] ipv6: enable IPV6_FLOWLABEL_MGR for getsockopt Date: Mon, 04 Nov 2013 18:09:01 +0100 Message-ID: <5277D4AD.10308@enst-bretagne.fr> References: <1383411524-16743-1-git-send-email-florent.fourcot@enst-bretagne.fr> <20131104000425.GB8832@order.stressinduktion.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit To: Hannes Frederic Sowa , netdev@vger.kernel.org Return-path: Received: from fourcot.fr ([217.70.191.14]:46546 "EHLO olfflo.fourcot.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753050Ab3KDRJE (ORCPT ); Mon, 4 Nov 2013 12:09:04 -0500 In-Reply-To: <20131104000425.GB8832@order.stressinduktion.org> Sender: netdev-owner@vger.kernel.org List-ID: > 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.