* 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
* (unknown),
From: J Walker @ 2017-05-17 13:39 UTC (permalink / raw)
To: netdev
^ 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
* 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: [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 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: 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] 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 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 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
* [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 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
* 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 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
* [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 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
* 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 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 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 07/10] net: sched: push chain dump to a separate function
From: Jamal Hadi Salim @ 2017-05-17 12:19 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-8-jiri@resnulli.us>
On 17-05-17 05:08 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Since there will be multiple chains to dump, push chain dumping code to
> a separate function.
>
> 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 06/10] net: sched: introduce helpers to work with filter chains
From: Jamal Hadi Salim @ 2017-05-17 12:18 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-7-jiri@resnulli.us>
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 ..
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 05/10] net: sched: move TC_H_MAJ macro call into tcf_auto_prio
From: Jamal Hadi Salim @ 2017-05-17 12:14 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-6-jiri@resnulli.us>
On 17-05-17 05:07 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Call the helper from the function rather than to always adjust the
> return value of the function.
>
> 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 04/10] net: sched: replace nprio by a bool to make the function more readable
From: Jamal Hadi Salim @ 2017-05-17 12:13 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-5-jiri@resnulli.us>
On 17-05-17 05:07 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> The use of "nprio" variable in tc_ctl_tfilter is a bit cryptic and makes
> a reader wonder what is going on for a while. So help him to understand
> this priority allocation dance a litte bit better.
>
> 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 03/10] net: sched: rename tcf_destroy_chain helper
From: Jamal Hadi Salim @ 2017-05-17 12:12 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-4-jiri@resnulli.us>
On 17-05-17 05:07 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Make the name consistent with the rest of the helpers around.
>
> 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 02/10] net: sched: introduce tcf block infractructure
From: Jamal Hadi Salim @ 2017-05-17 12:12 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-3-jiri@resnulli.us>
On 17-05-17 05:07 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Currently, the filter chains are direcly put into the private structures
> of qdiscs. In order to be able to have multiple chains per qdisc and to
> allow filter chains sharing among qdiscs, there is a need for common
> object that would hold the chains. This introduces such object and calls
> it "tcf_block".
>
> Helpers to get and put the blocks are provided to be called from
> individual qdisc code. Also, the original filter_list pointers are left
> in qdisc privs to allow the entry into tcf_block processing without any
> added overhead of possible multiple pointer dereference on fast path.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ 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