Return-Path: MIME-Version: 1.0 References: <20180829130308.3504560-1-arnd@arndb.de> In-Reply-To: From: Willem de Bruijn Date: Fri, 31 Aug 2018 11:08:09 -0400 Message-ID: Subject: Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling To: Arnd Bergmann Cc: Network Development , David Miller , linux-arch@vger.kernel.org, y2038 Mailman List , Eric Dumazet , Willem de Bruijn , LKML , linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org, linux-x25@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: > > > Looking at it again, it seems that sock_gettstamp() should > > > actually deal with this gracefully: it will return a -EINVAL > > > error condition if the timestamp remains at the > > > SK_DEFAULT_STAMP initial value, which is probably > > > just as appropriate (or better) as the current -ENOTTY > > > default, and if we are actually recording timestamps, we > > > might just as well report them. > > > > Yes, that's a nice solution. There is always some risk in changing > > error codes. But ioctl callers should be able to support newly > > implemented functionality. Even if partially implemented and > > returning ENOENT instead of ENOIOCTLCMD. > > Ok, so do you think we should stay with the current version > for now, and change the two points later, or should I rework > it to integrate the locking and removing the callback? > > I suppose the series actually gets nicer without the > callback, since I can simply add the generic timestamping > implementation first, and then remove the dead ioctl > handlers. Agreed. I would add the locks in a separate patch, if only on the off-chance that lockdep discovers something and it will be easier to bisect and revise independently. I can also follow up with that patch outside this set, of course.