On Mon, Jun 26, 2017 at 03:35:25AM +0100, Al Viro wrote: > On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote: > > The series aims at isolating data conversions of time_t based structures: > > struct timespec and struct itimerspec at user space boundaries. > > This helps to later change the underlying types to handle y2038 changes > > to these. > > Nice... A few questions: > > * what about setitimer(2)? Right now that's the only remaining user of > get_compat_itimerval(); similar for getitimer(2) and put_compat_itimerval(). > > * you have two callers of get_compat_itimerspec64(); one is followed by > itimerspec64_valid(), another - by its open-coded analogue. The same > goes for get_itimerspec64(); wouldn't it be better to have both check > the validity immediately and simply fail with -EINVAL? Matter of taste, > but... > > * should __sys_recvmmsg() switch to timespec64? While we are at it - do we need any locking for accesses of ->sk_stamp? * ax25, ipx, netrom, qrtr: sock_get_timestamp() done under lock_sock(). * bluetooth: without (and case next door in the same switch is grabbing/dropping lock_sock, so it's not held by caller either) * ipv4, ipv6, packet, can: without * irda: without, checks for NULL sock->sk for some reason (other cases do not, so if we ever get there with NULL ->sk, we are fucked). Incidentally, TIOCINQ in there looks fishy - what's to prevent us from losing CPU just as skb_peek() returns, with skb getting freed by the time we regain it and go looking at skb->len? Don't we need at least to hold ->lock on queue we are peeking into? * rose: without, and TIOCINQ there looks similar to irda one * x25: without, with the same odd check for NULL sock->sk * atm: without, apparently. Same unprotected skb_peek() on TIOCINQ... * atalk: ditto.
