* Re: [patch net-next v4 06/10] net: sched: introduce helpers to work with filter chains
From: Jiri Pirko @ 2017-05-17 12:25 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <ae02e4e8-3047-cd42-9c53-a2a38f8c28df@mojatatu.com>
Wed, May 17, 2017 at 02:18:00PM CEST, jhs@mojatatu.com wrote:
>On 17-05-17 05:07 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Introduce struct tcf_chain object and set of helpers around it. Wraps up
>> insertion, deletion and search in the filter chain.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>
>[..]
>> +
>> +static void
>> +tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
>> + struct tcf_proto __rcu **p_filter_chain)
>> +
>
>What are the rules for this? Common coding style is:
>static void tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
> struct tcf_proto ..
When this would not fit 80 cols (this case), you need to wrap the
text in front of the function name. That is exacly what I did.
>
>I am sure that struct tcf_proto __rcu **p_filter_chain would
>probably hit boundary of 80 chars - but it would look cleaner
>to be consistent.
>
>Otherwise:
>Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
>cheers,
>jamal
>
^ permalink raw reply
* Re: [patch net-next v4 08/10] net: sched: introduce multichain support for filters
From: Jamal Hadi Salim @ 2017-05-17 12:27 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170517090803.4461-9-jiri@resnulli.us>
On 17-05-17 05:08 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Instead of having only one filter per block, introduce a list of chains
> for every block. Create chain 0 by default. UAPI is extended so the user
> can specify which chain he wants to change. If the new attribute is not
> specified, chain 0 is used. That allows to maintain backward
> compatibility. If chain does not exist and user wants to manipulate with
> it, new chain is created with specified index. Also, when last filter is
> removed from the chain, the chain is destroyed.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 09/10] net: sched: push tp down to action init
From: Jamal Hadi Salim @ 2017-05-17 12:30 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170517090803.4461-10-jiri@resnulli.us>
On 17-05-17 05:08 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Tp pointer will be needed by the next patch in order to get the chain.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 10/10] net: sched: add termination action to allow goto chain
From: Jamal Hadi Salim @ 2017-05-17 12:31 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170517090803.4461-11-jiri@resnulli.us>
On 17-05-17 05:08 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Introduce new type of termination action called "goto_chain". This allows
> user to specify a chain to be processed. This action type is
> then processed as a return value in tcf_classify loop in similar
> way as "reclassify" is, only it does not reset to the first filter
> in chain but rather reset to the first filter of the desired chain.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH] hdlcdrv: fix divide error bug if bitrate is 0
From: Firo Yang @ 2017-05-17 12:35 UTC (permalink / raw)
To: t.sailer; +Cc: davem, gregkh, linux-hams, netdev, dvyukov, syzkaller, Firo Yang
The divisor s->par.bitrate will always be 0 until initialized by
ndo_open() and hdlcdrv_open().
In order to fix this divide zero error, check whether the netdevice
was opened by ndo_open() before performing divide.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Firo Yang <firogm@gmail.com>
---
drivers/net/hamradio/hdlcdrv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
index 8c3633c..3c783fd 100644
--- a/drivers/net/hamradio/hdlcdrv.c
+++ b/drivers/net/hamradio/hdlcdrv.c
@@ -574,7 +574,7 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
break;
case HDLCDRVCTL_CALIBRATE:
- if(!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) || !netif_running(dev))
return -EPERM;
if (bi.data.calibrate > INT_MAX / s->par.bitrate)
return -EINVAL;
--
2.9.4
^ permalink raw reply related
* Re: [patch net-next v4 06/10] net: sched: introduce helpers to work with filter chains
From: Jamal Hadi Salim @ 2017-05-17 12:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw, joe
In-Reply-To: <20170517122528.GA9557@nanopsycho>
On 17-05-17 08:25 AM, Jiri Pirko wrote:
> Wed, May 17, 2017 at 02:18:00PM CEST, jhs@mojatatu.com wrote:
>> On 17-05-17 05:07 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> Introduce struct tcf_chain object and set of helpers around it. Wraps up
>>> insertion, deletion and search in the filter chain.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>> ---
>>
>> [..]
>>> +
>>> +static void
>>> +tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
>>> + struct tcf_proto __rcu **p_filter_chain)
>>> +
>>
>> What are the rules for this? Common coding style is:
>> static void tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
>> struct tcf_proto ..
>
> When this would not fit 80 cols (this case), you need to wrap the
> text in front of the function name. That is exacly what I did.
>
That i understand.
The question is: what does scripture dictate on conflict?
Should a function signature always follow coding style and
allow for exceeding 80 chars or the 80 chars rules trumps?
cheers,
jamal
>>
>> I am sure that struct tcf_proto __rcu **p_filter_chain would
>> probably hit boundary of 80 chars - but it would look cleaner
>> to be consistent.
>>
>> Otherwise:
>> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>> cheers,
>> jamal
>>
^ permalink raw reply
* Re: [patch net-next v4 06/10] net: sched: introduce helpers to work with filter chains
From: Jiri Pirko @ 2017-05-17 12:44 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw, joe
In-Reply-To: <5270a876-6362-6c80-9911-8f929634edd1@mojatatu.com>
Wed, May 17, 2017 at 02:39:05PM CEST, jhs@mojatatu.com wrote:
>On 17-05-17 08:25 AM, Jiri Pirko wrote:
>> Wed, May 17, 2017 at 02:18:00PM CEST, jhs@mojatatu.com wrote:
>> > On 17-05-17 05:07 AM, Jiri Pirko wrote:
>> > > From: Jiri Pirko <jiri@mellanox.com>
>> > >
>> > > Introduce struct tcf_chain object and set of helpers around it. Wraps up
>> > > insertion, deletion and search in the filter chain.
>> > >
>> > > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> > > ---
>> >
>> > [..]
>> > > +
>> > > +static void
>> > > +tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
>> > > + struct tcf_proto __rcu **p_filter_chain)
>> > > +
>> >
>> > What are the rules for this? Common coding style is:
>> > static void tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
>> > struct tcf_proto ..
>>
>> When this would not fit 80 cols (this case), you need to wrap the
>> text in front of the function name. That is exacly what I did.
>>
>
>That i understand.
>The question is: what does scripture dictate on conflict?
>Should a function signature always follow coding style and
>allow for exceeding 80 chars or the 80 chars rules trumps?
Definitelly 80 chars rules trumps here.
^ permalink raw reply
* Re: [patch net-next v3 05/10] net: sched: move TC_H_MAJ macro call into tcf_auto_prio
From: Jamal Hadi Salim @ 2017-05-17 12:47 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang
Cc: Linux Kernel Network Developers, David Miller, David Ahern,
Eric Dumazet, Stephen Hemminger, Daniel Borkmann, Alexander Duyck,
Simon Horman, mlxsw
In-Reply-To: <20170517054752.GB1832@nanopsycho>
On 17-05-17 01:47 AM, Jiri Pirko wrote:
> Wed, May 17, 2017 at 12:38:08AM CEST, xiyou.wangcong@gmail.com wrote:
[..]
>>
>> tcf_auto_major_prio()?
>
> That makes no sense. prio is passed from user in upper 2 bytes (god
> knows why but that is how it is).
I am not sure it is any god's decision ;-> Unless you think the creator
of this semantic is a god which in some circles is blasphemy ;->
16 bits for prio: 16 bits for proto - what is the problem?
cheers,
jamal
^ permalink raw reply
* [PATCH net] udp: make *udp*_queue_rcv_skb() functions static
From: Paolo Abeni @ 2017-05-17 12:52 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
Since the udp memory accounting refactor, we don't need any more
to export the *udp*_queue_rcv_skb(). Make them static and fix
a couple of sparse warnings:
net/ipv4/udp.c:1615:5: warning: symbol 'udp_queue_rcv_skb' was not
declared. Should it be static?
net/ipv6/udp.c:572:5: warning: symbol 'udpv6_queue_rcv_skb' was not
declared. Should it be static?
Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema")
Fixes: c915fe13cbaa ("udplite: fix NULL pointer dereference")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/udp.c | 4 ++--
net/ipv4/udp_impl.h | 1 -
net/ipv6/udp.c | 4 ++--
net/ipv6/udp_impl.h | 1 -
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ea6e4cf..1d6219b 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1612,7 +1612,7 @@ static void udp_v4_rehash(struct sock *sk)
udp_lib_rehash(sk, new_hash);
}
-int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
int rc;
@@ -1657,7 +1657,7 @@ EXPORT_SYMBOL(udp_encap_enable);
* Note that in the success and error cases, the skb is assumed to
* have either been requeued or freed.
*/
-int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
struct udp_sock *up = udp_sk(sk);
int is_udplite = IS_UDPLITE(sk);
diff --git a/net/ipv4/udp_impl.h b/net/ipv4/udp_impl.h
index feb50a1..a8cf8c6 100644
--- a/net/ipv4/udp_impl.h
+++ b/net/ipv4/udp_impl.h
@@ -25,7 +25,6 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
int flags, int *addr_len);
int udp_sendpage(struct sock *sk, struct page *page, int offset, size_t size,
int flags);
-int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
void udp_destroy_sock(struct sock *sk);
#ifdef CONFIG_PROC_FS
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 04862ab..06ec39b 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -526,7 +526,7 @@ void __udp6_lib_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
return;
}
-int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
int rc;
@@ -569,7 +569,7 @@ void udpv6_encap_enable(void)
}
EXPORT_SYMBOL(udpv6_encap_enable);
-int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
struct udp_sock *up = udp_sk(sk);
int is_udplite = IS_UDPLITE(sk);
diff --git a/net/ipv6/udp_impl.h b/net/ipv6/udp_impl.h
index e78bdc7..f180b3d 100644
--- a/net/ipv6/udp_impl.h
+++ b/net/ipv6/udp_impl.h
@@ -26,7 +26,6 @@ int compat_udpv6_getsockopt(struct sock *sk, int level, int optname,
int udpv6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len);
int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
int flags, int *addr_len);
-int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
void udpv6_destroy_sock(struct sock *sk);
#ifdef CONFIG_PROC_FS
--
2.9.4
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-05-17 12:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, Arend Van Spriel, Pavel Machek, Daniel Wagner,
Tom Gundersen, Greg Kroah-Hartman, Kalle Valo, David Gnedt,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Takashi Iwai, AKASHI Takahiro, David Woodhouse, Bjorn Andersson,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1495022766.2442.1.camel@sipsolutions.net>
On Wednesday 17 May 2017 14:06:06 Johannes Berg wrote:
> On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > > Now for N900 case there is a similar scenario
> > > > alhtough it has additional requirement to go to user-space due to
> > > > need to use a proprietary library to obtain the NVS calibration
> > > > data. My thought: Why should firmware_class care?
> >
> > Agreed.
>
> In fact, why should the *driver* care either? IOW - why should
> "request_firmware_prefer_user()" even exist?
There are default/example NVS data, which are stored in /lib/firmware
and installed by linux-firmware package. Those example calibration data
should not be used for real usage, but Pavel told us that on N900 they
are enough for working WIFI connection. They does not contain valid MAC
address, so kernel should generate some (random?).
So kernel driver should get NVS calibration data from userspace (which
know how where to get or how to prepare them) and in case userspace do
not have it, then we can try fallback to those example data (as people
reported us they can be useful instead of non-working WIFI).
And that fallback is working by direct firmware loading from kernel.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [patch net-next v3 05/10] net: sched: move TC_H_MAJ macro call into tcf_auto_prio
From: Jiri Pirko @ 2017-05-17 12:53 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Cong Wang, Linux Kernel Network Developers, David Miller,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <e4614c93-16c9-427c-838d-4e752276cbe0@mojatatu.com>
Wed, May 17, 2017 at 02:47:47PM CEST, jhs@mojatatu.com wrote:
>On 17-05-17 01:47 AM, Jiri Pirko wrote:
>> Wed, May 17, 2017 at 12:38:08AM CEST, xiyou.wangcong@gmail.com wrote:
>
>[..]
>> >
>> > tcf_auto_major_prio()?
>>
>> That makes no sense. prio is passed from user in upper 2 bytes (god
>> knows why but that is how it is).
>
>I am not sure it is any god's decision ;-> Unless you think the creator
>of this semantic is a god which in some circles is blasphemy ;->
>
>16 bits for prio: 16 bits for proto - what is the problem?
Should have been a struct, at least. But as you know, I always prefer
a Netlink attr :)
^ permalink raw reply
* Re: [PATCH] hdlcdrv: fix divide error bug if bitrate is 0
From: walter harms @ 2017-05-17 12:59 UTC (permalink / raw)
To: Firo Yang; +Cc: t.sailer, davem, gregkh, linux-hams, netdev, dvyukov, syzkaller
In-Reply-To: <20170517123549.22659-1-firogm@gmail.com>
Am 17.05.2017 14:35, schrieb Firo Yang:
> The divisor s->par.bitrate will always be 0 until initialized by
> ndo_open() and hdlcdrv_open().
>
> In order to fix this divide zero error, check whether the netdevice
> was opened by ndo_open() before performing divide.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Firo Yang <firogm@gmail.com>
> ---
> drivers/net/hamradio/hdlcdrv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
> index 8c3633c..3c783fd 100644
> --- a/drivers/net/hamradio/hdlcdrv.c
> +++ b/drivers/net/hamradio/hdlcdrv.c
> @@ -574,7 +574,7 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> break;
>
> case HDLCDRVCTL_CALIBRATE:
> - if(!capable(CAP_SYS_RAWIO))
> + if (!capable(CAP_SYS_RAWIO) || !netif_running(dev))
> return -EPERM;
> if (bi.data.calibrate > INT_MAX / s->par.bitrate)
> return -EINVAL;
I would still check for s->par.bitrate > 0 later changes may affect the setting of it
and it is much more obvious.
Also perhaps !netif_running(dev) should better return ENODEV.
just my 2 cents,
re,
wh
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Johannes Berg @ 2017-05-17 13:04 UTC (permalink / raw)
To: Pali Rohár
Cc: Luis R. Rodriguez, Arend Van Spriel, Pavel Machek, Daniel Wagner,
Tom Gundersen, Greg Kroah-Hartman, Kalle Valo, David Gnedt,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Takashi Iwai, AKASHI Takahiro, David Woodhouse, Bjorn Andersson,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170517125335.GG10015@pali>
On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> > In fact, why should the *driver* care either? IOW - why should
> > "request_firmware_prefer_user()" even exist?
>
> There are default/example NVS data, which are stored in /lib/firmware
> and installed by linux-firmware package.
[...]
Oh, so you're saying you want this to invert the order ... Ok, that
makes some sense.
I still hope that all other requests will eventually fall back to user
loading though, I think that's important to system integration in
general.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
From: Johannes Berg @ 2017-05-17 13:14 UTC (permalink / raw)
To: Kalle Valo, Bjorn Andersson
Cc: k.eugene.e@gmail.com, Andy Gross, David Brown,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-soc@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, wcn36xx@lists.infradead.org,
nicolas.dechesne@linaro.org
In-Reply-To: <87fugkrchl.fsf@kamboji.qca.qualcomm.com>
On Thu, 2017-05-04 at 13:13 +0000, Kalle Valo wrote:
>
> > > This code intentionally checked if TX status was requested, and
> > > if not then it doesn't go to the effort of building it.
> > >
> >
> > What I'm finding puzzling is the fact that the only caller of
> > ieee80211_led_tx() is ieee80211_tx_status() and it seems like
> > drivers, such as ath10k, call this for each packet handled - but
> > I'm likely missing something.
Yes, many drivers do call it for each packet, and as such, this
deficiency was never noted.
> > > As it is with your patch, it'll go and report the TX status
> > > without any
> > > TX status information - which is handled in
> > > wcn36xx_dxe_tx_ack_ind()
> > > for those frames needing it.
> > >
> >
> > Right, it doesn't sound desired. However, during normal operation
> > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> > ieee80211_led_tx() is never called.
>
> So what's the conclusion? How do we get leds working?
Well, frankly, I never thought the TX LED was a super good idea - but
it had been supported by the original code IIRC, so never removed. Some
people like frantic blinking I guess ;-)
But I think the problem also applies to the throughput trigger thing,
so perhaps we need to stick some LED feedback calls into other places,
like _noskb() or provide an extra way to do it?
johannes
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-05-17 13:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, Arend Van Spriel, Pavel Machek, Daniel Wagner,
Tom Gundersen, Greg Kroah-Hartman, Kalle Valo, David Gnedt,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Takashi Iwai, AKASHI Takahiro, David Woodhouse, Bjorn Andersson,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1495026290.2442.6.camel@sipsolutions.net>
On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
>
> > > In fact, why should the *driver* care either? IOW - why should
> > > "request_firmware_prefer_user()" even exist?
> >
> > There are default/example NVS data, which are stored in /lib/firmware
> > and installed by linux-firmware package.
> [...]
>
> Oh, so you're saying you want this to invert the order ... Ok, that
> makes some sense.
Yes! I thought that this fact can be understood from commit message. If
not, I can change it, but provide how to improve it.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Johannes Berg @ 2017-05-17 13:22 UTC (permalink / raw)
To: Pali Rohár
Cc: Luis R. Rodriguez, Arend Van Spriel, Pavel Machek, Daniel Wagner,
Tom Gundersen, Greg Kroah-Hartman, Kalle Valo, David Gnedt,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Takashi Iwai, AKASHI Takahiro, David Woodhouse, Bjorn Andersson,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170517132131.GH10015@pali>
On Wed, 2017-05-17 at 15:21 +0200, Pali Rohár wrote:
> On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> > On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> >
> > > > In fact, why should the *driver* care either? IOW - why should
> > > > "request_firmware_prefer_user()" even exist?
> > >
> > > There are default/example NVS data, which are stored in
> > > /lib/firmware
> > > and installed by linux-firmware package.
> >
> > [...]
> >
> > Oh, so you're saying you want this to invert the order ... Ok, that
> > makes some sense.
>
> Yes! I thought that this fact can be understood from commit message.
> If not, I can change it, but provide how to improve it.
It probably can, I was only Cc'ed later :)
Sorry for the noise.
johannes
^ permalink raw reply
* Re: 'iw events' stops receiving events after a while on 4.9 + hacks
From: Johannes Berg @ 2017-05-17 13:30 UTC (permalink / raw)
To: Bastian Bittorf, Ben Greear; +Cc: netdev, linux-wireless@vger.kernel.org
In-Reply-To: <20170517100844.GC2849@medion.lan>
On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
> * Ben Greear <greearb@candelatech.com> [17.05.2017 11:51]:
> > I have been keeping an 'iw events' program running with a perl
> > script gathering its
> > output and post-processing it. This has been working for several
> > years on 4.7 and earlier
> > kernels, but when testing on 4.9 overnight, I notice that 'iw
> > events' is not showing any input. 'strace' shows
> > that it is waiting on recvmsg. If I start a second 'iw events'
> > then it will get
> > wifi events as expected.
>
> me too, also seen on 4.4 - i'am happy for debug ideas.
I've never seen this.
Does it happen when it's very long-running? Or when there are lots of
events?
Perhaps something in the socket buffer accounting is going wrong, so
that it's slowly decreasing to 0?
johannes
^ permalink raw reply
* (unknown),
From: J Walker @ 2017-05-17 13:39 UTC (permalink / raw)
To: netdev
^ permalink raw reply
* Re: [PATCH] hdlcdrv: fix divide error bug if bitrate is 0
From: Firo Yang @ 2017-05-17 13:42 UTC (permalink / raw)
To: walter harms
Cc: t.sailer, davem, gregkh, linux-hams, netdev, dvyukov, syzkaller
In-Reply-To: <591C493B.6060908@bfs.de>
On Wed, May 17, 2017 at 02:59:39PM +0200, walter harms wrote:
>
>
>Am 17.05.2017 14:35, schrieb Firo Yang:
>> The divisor s->par.bitrate will always be 0 until initialized by
>> ndo_open() and hdlcdrv_open().
>>
>> In order to fix this divide zero error, check whether the netdevice
>> was opened by ndo_open() before performing divide.
>>
>> Reported-by: Dmitry Vyukov <dvyukov@google.com>
>> Signed-off-by: Firo Yang <firogm@gmail.com>
>> ---
>> drivers/net/hamradio/hdlcdrv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
>> index 8c3633c..3c783fd 100644
>> --- a/drivers/net/hamradio/hdlcdrv.c
>> +++ b/drivers/net/hamradio/hdlcdrv.c
>> @@ -574,7 +574,7 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
>> break;
>>
>> case HDLCDRVCTL_CALIBRATE:
>> - if(!capable(CAP_SYS_RAWIO))
>> + if (!capable(CAP_SYS_RAWIO) || !netif_running(dev))
>> return -EPERM;
>> if (bi.data.calibrate > INT_MAX / s->par.bitrate)
>> return -EINVAL;
>
>I would still check for s->par.bitrate > 0 later changes may affect the setting of it
>and it is much more obvious.
I think 0 is not valid value for bitrate, so we should check it in
other places, like what ser12_open() did:
429 if (bc->baud < 300 || bc->baud > 4800) {
430 printk(KERN_INFO "baycom_ser_fdx: invalid baudrate "
431 "(300...4800)\n");
432 return -EINVAL;
433 }
...
440 bc->hdrv.par.bitrate = bc->baud;
>
>Also perhaps !netif_running(dev) should better return ENODEV.
However, the 'dev' truly exists in this circumstance.
Thanks,
Firo
>
>
>just my 2 cents,
>re,
> wh
>
^ permalink raw reply
* Re: [PATCH net-next 01/15] tcp: use tp->tcp_mstamp in output path
From: Soheil Hassas Yeganeh @ 2017-05-17 13:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Neal Cardwell, Yuchung Cheng, Wei Wang, netdev,
Eric Dumazet
In-Reply-To: <20170516210014.31176-2-edumazet@google.com>
On Tue, May 16, 2017 at 5:00 PM, Eric Dumazet <edumazet@google.com> wrote:
> Idea is to later convert tp->tcp_mstamp to a full u64 counter
> using usec resolution, so that we can later have fine
> grained TCP TS clock (RFC 7323), regardless of HZ value.
>
> We try to refresh tp->tcp_mstamp only when necessary.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> net/ipv4/tcp_ipv4.c | 1 +
> net/ipv4/tcp_output.c | 21 +++++++++++----------
> net/ipv4/tcp_recovery.c | 1 -
> net/ipv4/tcp_timer.c | 3 ++-
> 4 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 5ab2aac5ca191075383fc75214da816873bb222c..d8fe25db79f223e3fde85882effd2ac6ec15f8ca 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -483,6 +483,7 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
> skb = tcp_write_queue_head(sk);
> BUG_ON(!skb);
>
> + skb_mstamp_get(&tp->tcp_mstamp);
> remaining = icsk->icsk_rto -
> min(icsk->icsk_rto,
> tcp_time_stamp - tcp_skb_timestamp(skb));
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index a32172d69a03cbe76b45ec3094222f6c3a73e27d..4c8a6eaba6b39a2aea061dd6857ed8df954c5ca2 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -997,8 +997,8 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
> BUG_ON(!skb || !tcp_skb_pcount(skb));
> tp = tcp_sk(sk);
>
> + skb->skb_mstamp = tp->tcp_mstamp;
> if (clone_it) {
> - skb_mstamp_get(&skb->skb_mstamp);
> TCP_SKB_CB(skb)->tx.in_flight = TCP_SKB_CB(skb)->end_seq
> - tp->snd_una;
> tcp_rate_skb_sent(sk, skb);
> @@ -1906,7 +1906,6 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
> const struct inet_connection_sock *icsk = inet_csk(sk);
> u32 age, send_win, cong_win, limit, in_flight;
> struct tcp_sock *tp = tcp_sk(sk);
> - struct skb_mstamp now;
> struct sk_buff *head;
> int win_divisor;
>
> @@ -1962,8 +1961,8 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
> }
>
> head = tcp_write_queue_head(sk);
> - skb_mstamp_get(&now);
> - age = skb_mstamp_us_delta(&now, &head->skb_mstamp);
> +
> + age = skb_mstamp_us_delta(&tp->tcp_mstamp, &head->skb_mstamp);
> /* If next ACK is likely to come too late (half srtt), do not defer */
> if (age < (tp->srtt_us >> 4))
> goto send_now;
> @@ -2280,6 +2279,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> }
>
> max_segs = tcp_tso_segs(sk, mss_now);
> + skb_mstamp_get(&tp->tcp_mstamp);
> while ((skb = tcp_send_head(sk))) {
> unsigned int limit;
>
> @@ -2291,7 +2291,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
>
> if (unlikely(tp->repair) && tp->repair_queue == TCP_SEND_QUEUE) {
> /* "skb_mstamp" is used as a start point for the retransmit timer */
> - skb_mstamp_get(&skb->skb_mstamp);
> + skb->skb_mstamp = tp->tcp_mstamp;
> goto repair; /* Skip network transmission */
> }
>
> @@ -2879,7 +2879,7 @@ int __tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb, int segs)
> skb_headroom(skb) >= 0xFFFF)) {
> struct sk_buff *nskb;
>
> - skb_mstamp_get(&skb->skb_mstamp);
> + skb->skb_mstamp = tp->tcp_mstamp;
> nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
> err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
> -ENOBUFS;
> @@ -3095,7 +3095,7 @@ void tcp_send_active_reset(struct sock *sk, gfp_t priority)
> skb_reserve(skb, MAX_TCP_HEADER);
> tcp_init_nondata_skb(skb, tcp_acceptable_seq(sk),
> TCPHDR_ACK | TCPHDR_RST);
> - skb_mstamp_get(&skb->skb_mstamp);
> + skb_mstamp_get(&tcp_sk(sk)->tcp_mstamp);
> /* Send it off. */
> if (tcp_transmit_skb(sk, skb, 0, priority))
> NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);
> @@ -3453,7 +3453,8 @@ int tcp_connect(struct sock *sk)
> return -ENOBUFS;
>
> tcp_init_nondata_skb(buff, tp->write_seq++, TCPHDR_SYN);
> - tp->retrans_stamp = tcp_time_stamp;
> + skb_mstamp_get(&tp->tcp_mstamp);
> + tp->retrans_stamp = tp->tcp_mstamp.stamp_jiffies;
> tcp_connect_queue_skb(sk, buff);
> tcp_ecn_send_syn(sk, buff);
>
> @@ -3572,7 +3573,6 @@ void tcp_send_ack(struct sock *sk)
> skb_set_tcp_pure_ack(buff);
>
> /* Send it off, this clears delayed acks for us. */
> - skb_mstamp_get(&buff->skb_mstamp);
> tcp_transmit_skb(sk, buff, 0, (__force gfp_t)0);
> }
> EXPORT_SYMBOL_GPL(tcp_send_ack);
> @@ -3606,15 +3606,16 @@ static int tcp_xmit_probe_skb(struct sock *sk, int urgent, int mib)
> * send it.
> */
> tcp_init_nondata_skb(skb, tp->snd_una - !urgent, TCPHDR_ACK);
> - skb_mstamp_get(&skb->skb_mstamp);
> NET_INC_STATS(sock_net(sk), mib);
> return tcp_transmit_skb(sk, skb, 0, (__force gfp_t)0);
> }
>
> +/* Called from setsockopt( ... TCP_REPAIR ) */
> void tcp_send_window_probe(struct sock *sk)
> {
> if (sk->sk_state == TCP_ESTABLISHED) {
> tcp_sk(sk)->snd_wl1 = tcp_sk(sk)->rcv_nxt - 1;
> + skb_mstamp_get(&tcp_sk(sk)->tcp_mstamp);
> tcp_xmit_probe_skb(sk, 0, LINUX_MIB_TCPWINPROBE);
> }
> }
> diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
> index 362b8c75bfab44cf87c2a01398a146a271bc1119..cd72b3d3879e88181c8a4639f0334a24e4cda852 100644
> --- a/net/ipv4/tcp_recovery.c
> +++ b/net/ipv4/tcp_recovery.c
> @@ -166,7 +166,6 @@ void tcp_rack_reo_timeout(struct sock *sk)
> u32 timeout, prior_inflight;
>
> prior_inflight = tcp_packets_in_flight(tp);
> - skb_mstamp_get(&tp->tcp_mstamp);
> tcp_rack_detect_loss(sk, &timeout);
> if (prior_inflight != tcp_packets_in_flight(tp)) {
> if (inet_csk(sk)->icsk_ca_state != TCP_CA_Recovery) {
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index 86934bcf685a65ec3af3d22f1801ffa33eea76e2..ec7c5473c788d77ae459b38492f2f2606d00d1ba 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -339,7 +339,7 @@ static void tcp_probe_timer(struct sock *sk)
> */
> start_ts = tcp_skb_timestamp(tcp_send_head(sk));
> if (!start_ts)
> - skb_mstamp_get(&tcp_send_head(sk)->skb_mstamp);
> + tcp_send_head(sk)->skb_mstamp = tp->tcp_mstamp;
> else if (icsk->icsk_user_timeout &&
> (s32)(tcp_time_stamp - start_ts) > icsk->icsk_user_timeout)
> goto abort;
> @@ -561,6 +561,7 @@ void tcp_write_timer_handler(struct sock *sk)
> goto out;
> }
>
> + skb_mstamp_get(&tcp_sk(sk)->tcp_mstamp);
> event = icsk->icsk_pending;
>
> switch (event) {
> --
> 2.13.0.303.g4ebf302169-goog
>
^ permalink raw reply
* Re: [PATCH net-next 02/15] tcp: introduce tcp_jiffies32
From: Soheil Hassas Yeganeh @ 2017-05-17 13:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Neal Cardwell, Yuchung Cheng, Wei Wang, netdev,
Eric Dumazet
In-Reply-To: <20170516210014.31176-3-edumazet@google.com>
On Tue, May 16, 2017 at 5:00 PM, Eric Dumazet <edumazet@google.com> wrote:
> We abuse tcp_time_stamp for two different cases :
>
> 1) base to generate TCP Timestamp options (RFC 7323)
>
> 2) A 32bit version of jiffies since some TCP fields
> are 32bit wide to save memory.
>
> Since we want in the future to have 1ms TCP TS clock,
> regardless of HZ value, we want to cleanup things.
>
> tcp_jiffies32 is the truncated jiffies value,
> which will be used only in places where we want a 'host'
> timestamp.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> include/net/tcp.h | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index b4dc93dae98c2d175ccadce150083705d237555e..4b45be5708215bae4551a5430b63ab2777baf447 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -700,11 +700,14 @@ u32 __tcp_select_window(struct sock *sk);
>
> void tcp_send_window_probe(struct sock *sk);
>
> -/* TCP timestamps are only 32-bits, this causes a slight
> - * complication on 64-bit systems since we store a snapshot
> - * of jiffies in the buffer control blocks below. We decided
> - * to use only the low 32-bits of jiffies and hide the ugly
> - * casts with the following macro.
> +/* TCP uses 32bit jiffies to save some space.
> + * Note that this is different from tcp_time_stamp, which
> + * historically has been the same until linux-4.13.
> + */
> +#define tcp_jiffies32 ((u32)jiffies)
> +
> +/* Generator for TCP TS option (RFC 7323)
> + * Currently tied to 'jiffies' but will soon be driven by 1 ms clock.
> */
> #define tcp_time_stamp ((__u32)(jiffies))
>
> --
> 2.13.0.303.g4ebf302169-goog
>
^ permalink raw reply
* Re: [PATCH net-next 03/15] dccp: do not use tcp_time_stamp
From: Soheil Hassas Yeganeh @ 2017-05-17 13:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Neal Cardwell, Yuchung Cheng, Wei Wang, netdev,
Eric Dumazet
In-Reply-To: <20170516210014.31176-4-edumazet@google.com>
On Tue, May 16, 2017 at 5:00 PM, Eric Dumazet <edumazet@google.com> wrote:
> Use our own macro instead of abusing tcp_time_stamp
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> net/dccp/ccids/ccid2.c | 8 ++++----
> net/dccp/ccids/ccid2.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
> index 5e3a7302f7747e4c4f3134eacab2f2c65b13402f..e1295d5f2c562e8785f59a0f5bd7064f471e85ab 100644
> --- a/net/dccp/ccids/ccid2.c
> +++ b/net/dccp/ccids/ccid2.c
> @@ -233,7 +233,7 @@ static void ccid2_hc_tx_packet_sent(struct sock *sk, unsigned int len)
> {
> struct dccp_sock *dp = dccp_sk(sk);
> struct ccid2_hc_tx_sock *hc = ccid2_hc_tx_sk(sk);
> - const u32 now = ccid2_time_stamp;
> + const u32 now = ccid2_jiffies32;
> struct ccid2_seq *next;
>
> /* slow-start after idle periods (RFC 2581, RFC 2861) */
> @@ -466,7 +466,7 @@ static void ccid2_new_ack(struct sock *sk, struct ccid2_seq *seqp,
> * The cleanest solution is to not use the ccid2s_sent field at all
> * and instead use DCCP timestamps: requires changes in other places.
> */
> - ccid2_rtt_estimator(sk, ccid2_time_stamp - seqp->ccid2s_sent);
> + ccid2_rtt_estimator(sk, ccid2_jiffies32 - seqp->ccid2s_sent);
> }
>
> static void ccid2_congestion_event(struct sock *sk, struct ccid2_seq *seqp)
> @@ -478,7 +478,7 @@ static void ccid2_congestion_event(struct sock *sk, struct ccid2_seq *seqp)
> return;
> }
>
> - hc->tx_last_cong = ccid2_time_stamp;
> + hc->tx_last_cong = ccid2_jiffies32;
>
> hc->tx_cwnd = hc->tx_cwnd / 2 ? : 1U;
> hc->tx_ssthresh = max(hc->tx_cwnd, 2U);
> @@ -731,7 +731,7 @@ static int ccid2_hc_tx_init(struct ccid *ccid, struct sock *sk)
>
> hc->tx_rto = DCCP_TIMEOUT_INIT;
> hc->tx_rpdupack = -1;
> - hc->tx_last_cong = hc->tx_lsndtime = hc->tx_cwnd_stamp = ccid2_time_stamp;
> + hc->tx_last_cong = hc->tx_lsndtime = hc->tx_cwnd_stamp = ccid2_jiffies32;
> hc->tx_cwnd_used = 0;
> setup_timer(&hc->tx_rtotimer, ccid2_hc_tx_rto_expire,
> (unsigned long)sk);
> diff --git a/net/dccp/ccids/ccid2.h b/net/dccp/ccids/ccid2.h
> index 18c97543e522a6b9a5c8a3c817d4b40224adde48..6e50ef2898fb9dd9080217cc167defea6a2e9021 100644
> --- a/net/dccp/ccids/ccid2.h
> +++ b/net/dccp/ccids/ccid2.h
> @@ -27,7 +27,7 @@
> * CCID-2 timestamping faces the same issues as TCP timestamping.
> * Hence we reuse/share as much of the code as possible.
> */
> -#define ccid2_time_stamp tcp_time_stamp
> +#define ccid2_jiffies32 ((u32)jiffies)
>
> /* NUMDUPACK parameter from RFC 4341, p. 6 */
> #define NUMDUPACK 3
> --
> 2.13.0.303.g4ebf302169-goog
>
^ permalink raw reply
* Re: [PATCH net-next 04/15] tcp: use tcp_jiffies32 to feed tp->lsndtime
From: Soheil Hassas Yeganeh @ 2017-05-17 13:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Neal Cardwell, Yuchung Cheng, Wei Wang, netdev,
Eric Dumazet
In-Reply-To: <20170516210014.31176-5-edumazet@google.com>
On Tue, May 16, 2017 at 5:00 PM, Eric Dumazet <edumazet@google.com> wrote:
> Use tcp_jiffies32 instead of tcp_time_stamp to feed
> tp->lsndtime.
>
> tcp_time_stamp will soon be a litle bit more expensive
> than simply reading 'jiffies'.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> include/net/tcp.h | 2 +-
> net/ipv4/tcp.c | 2 +-
> net/ipv4/tcp_cubic.c | 2 +-
> net/ipv4/tcp_input.c | 4 ++--
> net/ipv4/tcp_output.c | 4 ++--
> net/ipv4/tcp_timer.c | 4 ++--
> 6 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 4b45be5708215bae4551a5430b63ab2777baf447..feba4c0406e551d7e57da3411476735731b4d817 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1245,7 +1245,7 @@ static inline void tcp_slow_start_after_idle_check(struct sock *sk)
> if (!sysctl_tcp_slow_start_after_idle || tp->packets_out ||
> ca_ops->cong_control)
> return;
> - delta = tcp_time_stamp - tp->lsndtime;
> + delta = tcp_jiffies32 - tp->lsndtime;
> if (delta > inet_csk(sk)->icsk_rto)
> tcp_cwnd_restart(sk, delta);
> }
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 1e4c76d2b8278ba71d6cc2cf7ebfe483e241f76e..d0bb61ee28bbceff8f2e27416ce87fec94935973 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2841,7 +2841,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
> info->tcpi_retrans = tp->retrans_out;
> info->tcpi_fackets = tp->fackets_out;
>
> - now = tcp_time_stamp;
> + now = tcp_jiffies32;
> info->tcpi_last_data_sent = jiffies_to_msecs(now - tp->lsndtime);
> info->tcpi_last_data_recv = jiffies_to_msecs(now - icsk->icsk_ack.lrcvtime);
> info->tcpi_last_ack_recv = jiffies_to_msecs(now - tp->rcv_tstamp);
> diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> index 0683ba447d775b6101a929a6aca3eb255cff8932..2052ca740916d0872a41125ab61b769b334a314b 100644
> --- a/net/ipv4/tcp_cubic.c
> +++ b/net/ipv4/tcp_cubic.c
> @@ -155,7 +155,7 @@ static void bictcp_cwnd_event(struct sock *sk, enum tcp_ca_event event)
> {
> if (event == CA_EVENT_TX_START) {
> struct bictcp *ca = inet_csk_ca(sk);
> - u32 now = tcp_time_stamp;
> + u32 now = tcp_jiffies32;
> s32 delta;
>
> delta = now - tcp_sk(sk)->lsndtime;
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 06e2dbc2b4a212a054fd88e57bb902c55a171b11..c0b3f909df394214785749704f2760171fe9d160 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5571,7 +5571,7 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff *skb)
> /* Prevent spurious tcp_cwnd_restart() on first data
> * packet.
> */
> - tp->lsndtime = tcp_time_stamp;
> + tp->lsndtime = tcp_jiffies32;
>
> tcp_init_buffer_space(sk);
>
> @@ -6008,7 +6008,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
> tcp_update_pacing_rate(sk);
>
> /* Prevent spurious tcp_cwnd_restart() on first data packet */
> - tp->lsndtime = tcp_time_stamp;
> + tp->lsndtime = tcp_jiffies32;
>
> tcp_initialize_rcv_mss(sk);
> tcp_fast_path_on(tp);
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 4c8a6eaba6b39a2aea061dd6857ed8df954c5ca2..be9f8f483e21bdbb4d944fcdae8560f3ae11ee64 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -160,7 +160,7 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
> struct sock *sk)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
> - const u32 now = tcp_time_stamp;
> + const u32 now = tcp_jiffies32;
>
> if (tcp_packets_in_flight(tp) == 0)
> tcp_ca_event(sk, CA_EVENT_TX_START);
> @@ -1918,7 +1918,7 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
> /* Avoid bursty behavior by allowing defer
> * only if the last write was recent.
> */
> - if ((s32)(tcp_time_stamp - tp->lsndtime) > 0)
> + if ((s32)(tcp_jiffies32 - tp->lsndtime) > 0)
> goto send_now;
>
> in_flight = tcp_packets_in_flight(tp);
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index ec7c5473c788d77ae459b38492f2f2606d00d1ba..5f6f219a431e41a90b3c5d667a1a22b50f4464cf 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -63,7 +63,7 @@ static int tcp_out_of_resources(struct sock *sk, bool do_reset)
>
> /* If peer does not open window for long time, or did not transmit
> * anything for long time, penalize it. */
> - if ((s32)(tcp_time_stamp - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset)
> + if ((s32)(tcp_jiffies32 - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset)
> shift++;
>
> /* If some dubious ICMP arrived, penalize even more. */
> @@ -73,7 +73,7 @@ static int tcp_out_of_resources(struct sock *sk, bool do_reset)
> if (tcp_check_oom(sk, shift)) {
> /* Catch exceptional cases, when connection requires reset.
> * 1. Last segment was sent recently. */
> - if ((s32)(tcp_time_stamp - tp->lsndtime) <= TCP_TIMEWAIT_LEN ||
> + if ((s32)(tcp_jiffies32 - tp->lsndtime) <= TCP_TIMEWAIT_LEN ||
> /* 2. Window is closed. */
> (!tp->snd_wnd && !tp->packets_out))
> do_reset = true;
> --
> 2.13.0.303.g4ebf302169-goog
>
^ permalink raw reply
* Re: [PATCH net-next 05/15] tcp: use tcp_jiffies32 to feed tp->snd_cwnd_stamp
From: Soheil Hassas Yeganeh @ 2017-05-17 13:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Neal Cardwell, Yuchung Cheng, Wei Wang, netdev,
Eric Dumazet
In-Reply-To: <20170516210014.31176-6-edumazet@google.com>
On Tue, May 16, 2017 at 5:00 PM, Eric Dumazet <edumazet@google.com> wrote:
> Use tcp_jiffies32 instead of tcp_time_stamp to feed
> tp->snd_cwnd_stamp.
>
> tcp_time_stamp will soon be a litle bit more expensive
> than simply reading 'jiffies'.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> net/ipv4/tcp_input.c | 14 +++++++-------
> net/ipv4/tcp_metrics.c | 2 +-
> net/ipv4/tcp_output.c | 8 ++++----
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index c0b3f909df394214785749704f2760171fe9d160..6a15c9b80b09829799dc37d89ecdbf11ec9ff904 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -463,7 +463,7 @@ void tcp_init_buffer_space(struct sock *sk)
> tp->window_clamp = max(2 * tp->advmss, maxwin - tp->advmss);
>
> tp->rcv_ssthresh = min(tp->rcv_ssthresh, tp->window_clamp);
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> }
>
> /* 5. Recalculate window clamp after socket hit its memory bounds. */
> @@ -1954,7 +1954,7 @@ void tcp_enter_loss(struct sock *sk)
> }
> tp->snd_cwnd = 1;
> tp->snd_cwnd_cnt = 0;
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
>
> tp->retrans_out = 0;
> tp->lost_out = 0;
> @@ -2383,7 +2383,7 @@ static void tcp_undo_cwnd_reduction(struct sock *sk, bool unmark_loss)
> tcp_ecn_withdraw_cwr(tp);
> }
> }
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> tp->undo_marker = 0;
> }
>
> @@ -2520,7 +2520,7 @@ static inline void tcp_end_cwnd_reduction(struct sock *sk)
> if (inet_csk(sk)->icsk_ca_state == TCP_CA_CWR ||
> (tp->undo_marker && tp->snd_ssthresh < TCP_INFINITE_SSTHRESH)) {
> tp->snd_cwnd = tp->snd_ssthresh;
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> }
> tcp_ca_event(sk, CA_EVENT_COMPLETE_CWR);
> }
> @@ -2590,7 +2590,7 @@ static void tcp_mtup_probe_success(struct sock *sk)
> tcp_mss_to_mtu(sk, tp->mss_cache) /
> icsk->icsk_mtup.probe_size;
> tp->snd_cwnd_cnt = 0;
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> tp->snd_ssthresh = tcp_current_ssthresh(sk);
>
> icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
> @@ -2976,7 +2976,7 @@ static void tcp_cong_avoid(struct sock *sk, u32 ack, u32 acked)
> const struct inet_connection_sock *icsk = inet_csk(sk);
>
> icsk->icsk_ca_ops->cong_avoid(sk, ack, acked);
> - tcp_sk(sk)->snd_cwnd_stamp = tcp_time_stamp;
> + tcp_sk(sk)->snd_cwnd_stamp = tcp_jiffies32;
> }
>
> /* Restart timer after forward progress on connection.
> @@ -5019,7 +5019,7 @@ static void tcp_new_space(struct sock *sk)
>
> if (tcp_should_expand_sndbuf(sk)) {
> tcp_sndbuf_expand(sk);
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> }
>
> sk->sk_write_space(sk);
> diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
> index 653bbd67e3a39b68d27d26d17571c00ce2854bfd..102b2c90bb807d3a88d31b59324baf72cf901cdf 100644
> --- a/net/ipv4/tcp_metrics.c
> +++ b/net/ipv4/tcp_metrics.c
> @@ -524,7 +524,7 @@ void tcp_init_metrics(struct sock *sk)
> tp->snd_cwnd = 1;
> else
> tp->snd_cwnd = tcp_init_cwnd(tp, dst);
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> }
>
> bool tcp_peer_is_proven(struct request_sock *req, struct dst_entry *dst)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index be9f8f483e21bdbb4d944fcdae8560f3ae11ee64..4bd50f0b236ba23fe521a76dd9d35ee16acb061f 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -151,7 +151,7 @@ void tcp_cwnd_restart(struct sock *sk, s32 delta)
> while ((delta -= inet_csk(sk)->icsk_rto) > 0 && cwnd > restart_cwnd)
> cwnd >>= 1;
> tp->snd_cwnd = max(cwnd, restart_cwnd);
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> tp->snd_cwnd_used = 0;
> }
>
> @@ -1576,7 +1576,7 @@ static void tcp_cwnd_application_limited(struct sock *sk)
> }
> tp->snd_cwnd_used = 0;
> }
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> }
>
> static void tcp_cwnd_validate(struct sock *sk, bool is_cwnd_limited)
> @@ -1597,14 +1597,14 @@ static void tcp_cwnd_validate(struct sock *sk, bool is_cwnd_limited)
> if (tcp_is_cwnd_limited(sk)) {
> /* Network is feed fully. */
> tp->snd_cwnd_used = 0;
> - tp->snd_cwnd_stamp = tcp_time_stamp;
> + tp->snd_cwnd_stamp = tcp_jiffies32;
> } else {
> /* Network starves. */
> if (tp->packets_out > tp->snd_cwnd_used)
> tp->snd_cwnd_used = tp->packets_out;
>
> if (sysctl_tcp_slow_start_after_idle &&
> - (s32)(tcp_time_stamp - tp->snd_cwnd_stamp) >= inet_csk(sk)->icsk_rto &&
> + (s32)(tcp_jiffies32 - tp->snd_cwnd_stamp) >= inet_csk(sk)->icsk_rto &&
> !ca_ops->cong_control)
> tcp_cwnd_application_limited(sk);
>
> --
> 2.13.0.303.g4ebf302169-goog
>
^ permalink raw reply
* Re: [PATCH net-next 06/15] tcp_bbr: use tcp_jiffies32 instead of tcp_time_stamp
From: Soheil Hassas Yeganeh @ 2017-05-17 13:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Neal Cardwell, Yuchung Cheng, Wei Wang, netdev,
Eric Dumazet
In-Reply-To: <20170516210014.31176-7-edumazet@google.com>
On Tue, May 16, 2017 at 5:00 PM, Eric Dumazet <edumazet@google.com> wrote:
> Use tcp_jiffies32 instead of tcp_time_stamp, since
> tcp_time_stamp will soon be only used for TCP TS option.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> net/ipv4/tcp_bbr.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c
> index 92b045c72163def1c1d6aa0f2002760186aa5dc3..40dc4fc5f6acba91634290e1cacde69a3584248f 100644
> --- a/net/ipv4/tcp_bbr.c
> +++ b/net/ipv4/tcp_bbr.c
> @@ -730,12 +730,12 @@ static void bbr_update_min_rtt(struct sock *sk, const struct rate_sample *rs)
> bool filter_expired;
>
> /* Track min RTT seen in the min_rtt_win_sec filter window: */
> - filter_expired = after(tcp_time_stamp,
> + filter_expired = after(tcp_jiffies32,
> bbr->min_rtt_stamp + bbr_min_rtt_win_sec * HZ);
> if (rs->rtt_us >= 0 &&
> (rs->rtt_us <= bbr->min_rtt_us || filter_expired)) {
> bbr->min_rtt_us = rs->rtt_us;
> - bbr->min_rtt_stamp = tcp_time_stamp;
> + bbr->min_rtt_stamp = tcp_jiffies32;
> }
>
> if (bbr_probe_rtt_mode_ms > 0 && filter_expired &&
> @@ -754,7 +754,7 @@ static void bbr_update_min_rtt(struct sock *sk, const struct rate_sample *rs)
> /* Maintain min packets in flight for max(200 ms, 1 round). */
> if (!bbr->probe_rtt_done_stamp &&
> tcp_packets_in_flight(tp) <= bbr_cwnd_min_target) {
> - bbr->probe_rtt_done_stamp = tcp_time_stamp +
> + bbr->probe_rtt_done_stamp = tcp_jiffies32 +
> msecs_to_jiffies(bbr_probe_rtt_mode_ms);
> bbr->probe_rtt_round_done = 0;
> bbr->next_rtt_delivered = tp->delivered;
> @@ -762,8 +762,8 @@ static void bbr_update_min_rtt(struct sock *sk, const struct rate_sample *rs)
> if (bbr->round_start)
> bbr->probe_rtt_round_done = 1;
> if (bbr->probe_rtt_round_done &&
> - after(tcp_time_stamp, bbr->probe_rtt_done_stamp)) {
> - bbr->min_rtt_stamp = tcp_time_stamp;
> + after(tcp_jiffies32, bbr->probe_rtt_done_stamp)) {
> + bbr->min_rtt_stamp = tcp_jiffies32;
> bbr->restore_cwnd = 1; /* snap to prior_cwnd */
> bbr_reset_mode(sk);
> }
> @@ -810,7 +810,7 @@ static void bbr_init(struct sock *sk)
> bbr->probe_rtt_done_stamp = 0;
> bbr->probe_rtt_round_done = 0;
> bbr->min_rtt_us = tcp_min_rtt(tp);
> - bbr->min_rtt_stamp = tcp_time_stamp;
> + bbr->min_rtt_stamp = tcp_jiffies32;
>
> minmax_reset(&bbr->bw, bbr->rtt_cnt, 0); /* init max bw to 0 */
>
> --
> 2.13.0.303.g4ebf302169-goog
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox