From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> To: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com> Cc: "Network Development" <netdev@vger.kernel.org>, "Jamal Hadi Salim" <jhs@mojatatu.com>, "Cong Wang" <xiyou.wangcong@gmail.com>, "Jiří Pírko" <jiri@resnulli.us>, "Vinicius Gomes" <vinicius.gomes@intel.com>, "Richard Cochran" <richardcochran@gmail.com>, intel-wired-lan@lists.osuosl.org, anna-maria@linutronix.de, "Henrik Austad" <henrik@austad.us>, "Thomas Gleixner" <tglx@linutronix.de>, "John Stultz" <john.stultz@linaro.org>, andre.guedes@intel.com, "Ivan Briano" <ivan.briano@intel.com>, "Levi Pearson" <levi.pearson@harman.com>, "Richard Cochran" <rcochran@linutronix.de> Subject: Re: [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time. Date: Tue, 23 Jan 2018 21:02:48 +0100 [thread overview] Message-ID: <CAF=yD-LZeYijHi3bJmo06B0cicqH-+eBMW_+LUs4+85ZM0KcZA@mail.gmail.com> (raw) In-Reply-To: <f9f79333-e8d3-ea6f-ba04-356b1761a0b9@intel.com> >> If using ns_capable, skb->tstamp must continue to be scrubbed when traversing >> network namespaces. > > > I was planning to follow Eric's suggestion and move the tstamp scrubbing out of > skb_scrub_packet() into ____dev_forward_skb() instead. Would that break when > traversing namespaces? That implies namespace traversal, so sounds perfect for this purpose. >> >>> @@ -2130,6 +2137,15 @@ int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg, >>> sockc->tsflags &= ~SOF_TIMESTAMPING_TX_RECORD_MASK; >>> sockc->tsflags |= tsflags; >>> break; >>> + case SO_TXTIME: >>> + if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)) >>> + return -EPERM; >>> + if (!sock_flag(sk, SOCK_TXTIME)) >>> + return -EINVAL; >> >> No need for ns_capable check on each packet when already required to >> toggle socket option. > > > Ok. SO_MARK is doing the same so it might have "mis-inspired" me. I should > probably fix both. The SO_MARK cmsg does need a check on each invocation, because it is not conditional on a sock_flag like SO_TXTIME.
WARNING: multiple messages have this Message-ID (diff)
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time. Date: Tue, 23 Jan 2018 21:02:48 +0100 [thread overview] Message-ID: <CAF=yD-LZeYijHi3bJmo06B0cicqH-+eBMW_+LUs4+85ZM0KcZA@mail.gmail.com> (raw) In-Reply-To: <f9f79333-e8d3-ea6f-ba04-356b1761a0b9@intel.com> >> If using ns_capable, skb->tstamp must continue to be scrubbed when traversing >> network namespaces. > > > I was planning to follow Eric's suggestion and move the tstamp scrubbing out of > skb_scrub_packet() into ____dev_forward_skb() instead. Would that break when > traversing namespaces? That implies namespace traversal, so sounds perfect for this purpose. >> >>> @@ -2130,6 +2137,15 @@ int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg, >>> sockc->tsflags &= ~SOF_TIMESTAMPING_TX_RECORD_MASK; >>> sockc->tsflags |= tsflags; >>> break; >>> + case SO_TXTIME: >>> + if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)) >>> + return -EPERM; >>> + if (!sock_flag(sk, SOCK_TXTIME)) >>> + return -EINVAL; >> >> No need for ns_capable check on each packet when already required to >> toggle socket option. > > > Ok. SO_MARK is doing the same so it might have "mis-inspired" me. I should > probably fix both. The SO_MARK cmsg does need a check on each invocation, because it is not conditional on a sock_flag like SO_TXTIME.
next prev parent reply other threads:[~2018-01-23 20:03 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-17 23:06 [RFC v2 net-next 00/10] Time based packet transmission Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-18 8:42 ` Miroslav Lichvar 2018-01-18 8:42 ` Miroslav Lichvar 2018-01-18 17:13 ` Richard Cochran 2018-01-18 17:13 ` Richard Cochran 2018-02-01 0:49 ` Jesus Sanchez-Palencia 2018-02-01 0:49 ` Jesus Sanchez-Palencia 2018-02-01 4:16 ` Richard Cochran 2018-02-01 4:16 ` Richard Cochran 2018-02-01 9:27 ` Miroslav Lichvar 2018-02-01 9:27 ` Miroslav Lichvar 2018-02-01 20:55 ` Jesus Sanchez-Palencia 2018-02-01 20:55 ` Jesus Sanchez-Palencia 2018-01-23 21:22 ` Vinicius Costa Gomes 2018-01-23 21:22 ` Vinicius Costa Gomes 2018-01-24 3:04 ` Richard Cochran 2018-01-24 3:04 ` Richard Cochran 2018-01-24 22:46 ` Vinicius Costa Gomes 2018-01-24 22:46 ` Vinicius Costa Gomes 2018-01-26 2:12 ` Richard Cochran 2018-01-26 2:12 ` Richard Cochran 2018-02-12 22:39 ` Jesus Sanchez-Palencia 2018-02-12 22:39 ` Jesus Sanchez-Palencia 2018-02-13 9:56 ` Miroslav Lichvar 2018-02-13 9:56 ` Miroslav Lichvar 2018-01-18 17:11 ` Richard Cochran 2018-01-18 17:11 ` [Intel-wired-lan] " Richard Cochran 2018-01-23 18:12 ` Jesus Sanchez-Palencia 2018-01-23 18:12 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-19 21:15 ` Willem de Bruijn 2018-01-19 21:15 ` [Intel-wired-lan] " Willem de Bruijn 2018-01-20 2:09 ` Richard Cochran 2018-01-20 2:09 ` [Intel-wired-lan] " Richard Cochran 2018-01-25 9:12 ` Miroslav Lichvar 2018-01-25 9:12 ` Miroslav Lichvar 2018-01-25 16:52 ` Richard Cochran 2018-01-25 16:52 ` Richard Cochran 2018-01-23 18:24 ` Jesus Sanchez-Palencia 2018-01-23 18:24 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-23 20:02 ` Willem de Bruijn [this message] 2018-01-23 20:02 ` Willem de Bruijn 2018-01-17 23:06 ` [RFC v2 net-next 02/10] net: ipv4: raw: Hook into time based transmission Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-18 0:28 ` Eric Dumazet 2018-01-18 0:28 ` [Intel-wired-lan] " Eric Dumazet 2018-01-17 23:06 ` [RFC v2 net-next 03/10] net: ipv4: udp: " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 04/10] net: packet: " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 05/10] net/sched: Allow creating a Qdisc watchdog with other clocks Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 06/10] net/sched: Introduce the TBS Qdisc Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-18 13:35 ` Jamal Hadi Salim 2018-01-18 13:35 ` [Intel-wired-lan] " Jamal Hadi Salim 2018-01-18 13:44 ` Jamal Hadi Salim 2018-01-18 13:44 ` [Intel-wired-lan] " Jamal Hadi Salim 2018-01-23 21:45 ` Jesus Sanchez-Palencia 2018-01-23 21:45 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-18 17:18 ` Richard Cochran 2018-01-18 17:18 ` [Intel-wired-lan] " Richard Cochran 2018-01-23 22:01 ` Jesus Sanchez-Palencia 2018-01-23 22:01 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-19 21:18 ` Willem de Bruijn 2018-01-19 21:18 ` [Intel-wired-lan] " Willem de Bruijn 2018-01-17 23:06 ` [RFC v2 net-next 07/10] igb: Refactor igb_configure_cbs() Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 08/10] igb: Only change Tx arbitration when CBS is on Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 09/10] igb: Refactor igb_offload_cbs() Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-17 23:06 ` [RFC v2 net-next 10/10] igb: Add support for TBS offload Jesus Sanchez-Palencia 2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-23 5:23 ` [RFC v2 net-next 00/10] Time based packet transmission Richard Cochran 2018-01-23 5:23 ` [Intel-wired-lan] " Richard Cochran 2018-01-23 5:26 ` Richard Cochran 2018-01-23 5:26 ` [Intel-wired-lan] " Richard Cochran 2018-01-23 18:07 ` Jesus Sanchez-Palencia 2018-01-23 18:07 ` [Intel-wired-lan] " Jesus Sanchez-Palencia 2018-01-24 1:43 ` Levi Pearson 2018-01-24 1:43 ` [Intel-wired-lan] " Levi Pearson 2018-01-27 0:04 ` Jesus Sanchez-Palencia 2018-01-27 0:04 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAF=yD-LZeYijHi3bJmo06B0cicqH-+eBMW_+LUs4+85ZM0KcZA@mail.gmail.com' \ --to=willemdebruijn.kernel@gmail.com \ --cc=andre.guedes@intel.com \ --cc=anna-maria@linutronix.de \ --cc=henrik@austad.us \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=ivan.briano@intel.com \ --cc=jesus.sanchez-palencia@intel.com \ --cc=jhs@mojatatu.com \ --cc=jiri@resnulli.us \ --cc=john.stultz@linaro.org \ --cc=levi.pearson@harman.com \ --cc=netdev@vger.kernel.org \ --cc=rcochran@linutronix.de \ --cc=richardcochran@gmail.com \ --cc=tglx@linutronix.de \ --cc=vinicius.gomes@intel.com \ --cc=xiyou.wangcong@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.