* Re: [PATCH net-next] tcp: expose both send and receive intervals for rate sample
From: Neal Cardwell @ 2018-07-09 18:09 UTC (permalink / raw)
To: deeptir; +Cc: David Miller, Netdev
In-Reply-To: <1531158819-7901-1-git-send-email-deeptir@mit.edu>
On Mon, Jul 9, 2018 at 1:58 PM Deepti Raghavan <deeptir@mit.edu> wrote:
>
> Congestion control algorithms, which access the rate sample
> through the tcp_cong_control function, only have access to the maximum
> of the send and receive interval, for cases where the acknowledgment
> rate may be inaccurate due to ACK compression or decimation. Algorithms
> may want to use send rates and receive rates as separate signals.
>
> Signed-off-by: Deepti Raghavan <deeptir@mit.edu>
> ---
> include/net/tcp.h | 2 ++
> net/ipv4/tcp_rate.c | 4 ++++
> 2 files changed, 6 insertions(+)
Thanks for re-sending. It does seem to be showing up in patchwork now:
https://patchwork.ozlabs.org/patch/941532/
And I can confirm I'm able to apply it to net-next.
Acked-by: Neal Cardwell <ncardwell@google.com>
thanks,
neal
^ permalink raw reply
* Re: [PATCH net-next] tcp: expose both send and receive intervals for rate sample
From: Eric Dumazet @ 2018-07-09 18:11 UTC (permalink / raw)
To: Deepti Raghavan, David Miller; +Cc: netdev
In-Reply-To: <1531158819-7901-1-git-send-email-deeptir@mit.edu>
On 07/09/2018 10:53 AM, Deepti Raghavan wrote:
> Congestion control algorithms, which access the rate sample
> through the tcp_cong_control function, only have access to the maximum
> of the send and receive interval, for cases where the acknowledgment
> rate may be inaccurate due to ACK compression or decimation. Algorithms
> may want to use send rates and receive rates as separate signals.
>
> Signed-off-by: Deepti Raghavan <deeptir@mit.edu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
(Assuming another CC is coming soon, using this...)
Thanks
^ permalink raw reply
* Re: [PATCH net] hv_netvsc: Fix napi reschedule while receive completion is busy
From: Stephen Hemminger @ 2018-07-09 18:15 UTC (permalink / raw)
To: Haiyang Zhang
Cc: olaf, sthemmin, netdev, haiyangz, linux-kernel, devel, vkuznets,
davem
In-Reply-To: <20180709164319.5058-1-haiyangz@linuxonhyperv.com>
On Mon, 9 Jul 2018 16:43:19 +0000
Haiyang Zhang <haiyangz@linuxonhyperv.com> wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> If out ring is full temporarily and receive completion cannot go out,
> we may still need to reschedule napi if other conditions are met.
> Otherwise the napi poll might be stopped forever, and cause network
> disconnect.
>
> Fixes: 7426b1a51803 ("netvsc: optimize receive completions")
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/net/hyperv/netvsc.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 8e9d0ee1572b..caaf5054f446 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -1285,14 +1285,14 @@ int netvsc_poll(struct napi_struct *napi, int budget)
> nvchan->desc = hv_pkt_iter_next(channel, nvchan->desc);
> }
>
> - /* If send of pending receive completions suceeded
> - * and did not exhaust NAPI budget this time
> + send_recv_completions(ndev, net_device, nvchan);
> +
> + /* If it did not exhaust NAPI budget this time
> * and not doing busy poll
> * then re-enable host interrupts
> * and reschedule if ring is not empty.
> */
> - if (send_recv_completions(ndev, net_device, nvchan) == 0 &&
> - work_done < budget &&
> + if (work_done < budget &&
> napi_complete_done(napi, work_done) &&
> hv_end_read(&channel->inbound) &&
> napi_schedule_prep(napi)) {
This patch doesn't look right. I think the existing code works
as written.
If send_receive_completions is unable to send because ring is full
then vmbus_sendpacket will return -EBUSY which gets returns
from send_receive_completions. Because the return is non-zero,
the driver will not call napi_complete_done.
Since napi_complete_done was not called, NAPI will reschedule
the napi poll routine.
^ permalink raw reply
* Re: [PATCH v2 00/14] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers
From: David Miller @ 2018-07-09 18:16 UTC (permalink / raw)
To: sergei.shtylyov
Cc: vladimir_zapolskiy, andrew, geert, netdev, linux-renesas-soc
In-Reply-To: <efa424b3-1cf8-3eac-aea4-eaaef9df1b66@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Mon, 9 Jul 2018 02:24:45 +0300
> Hello!
>
> On 7/8/2018 2:58 AM, David Miller wrote:
>
>>> So you applied the whole series to net.git... that was somewhat
>>> unexpected, at least by me. Care to share your reasoning?
>> It's fixes a sleep in atomic which is a serious bug.
>
> Do you realize that only patches 0, 1, 8, and 9 were real fixes,
> others were just follow-up cleanups? (Although the wording of the
> cover letter could have made people think that the whole series is the
> fixes...)
> OK, I understand what's done is done and it's not me that would have
> to justify the cleanups in a middle of the 4.18-rc's. But still, it
> was not a pleasant surprise (and I told Vladimir he shouldn't mix the
> real fixes and
> cleanups in reply to his cover letter, IIRC).
I was disappointed the series was so large as well.
Let's try to work together to handle this better next time, ok?
^ permalink raw reply
* Re: [PATCH v3 net-next] net/sched: add skbprio scheduler
From: Michel Machado @ 2018-07-09 18:18 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, Nishanth Devarajan
Cc: xiyou.wangcong, jhs, jiri, davem, netdev, doucette
In-Reply-To: <20180709154409.GC8880@localhost.localdomain>
On 07/09/2018 11:44 AM, Marcelo Ricardo Leitner wrote:
> On Sat, Jul 07, 2018 at 03:43:55PM +0530, Nishanth Devarajan wrote:
>> net/sched: add skbprio scheduer
>>
>> Skbprio (SKB Priority Queue) is a queueing discipline that prioritizes packets
>> according to their skb->priority field. Under congestion, already-enqueued lower
>> priority packets will be dropped to make space available for higher priority
>> packets. Skbprio was conceived as a solution for denial-of-service defenses that
>> need to route packets with different priorities as a means to overcome DoS
>> attacks.
>
> Why can't we implement this as a new flag for sch_prio.c?
>
> I don't see why this duplication is needed, especially because it will
> only be "slower" (as in, it will do more work) when qdisc is already
> full and dropping packets anyway.
sch_prio.c and skbprio diverge on a number of aspects:
1. sch_prio.c supports up to 16 priorities whereas skbprio 64. This
is not just a matter of changing a constant since sch_prio.c doesn't use
skb->priority.
2. sch_prio.c does not have a global limit on the number of packets
on all its queues, only a limit per queue.
3. The queues of sch_prio.c are struct Qdisc, which don't have a
method to drop at its tail.
Given the divergences, adding flags to sch_prio.c will essentially
keep both implementations together instead of being isolated as being
proposed.
On the speed point, there may not be noticeable difference between
both qdiscs because the enqueueing and dequeueing costs of both qdics
are O(1). Notice that the "extra work" (i.e. dropping lower priority
packets) is a key aspect of skbprio since it gives routers a cheap way
to choose which packets to drop during a DoS.
[ ]'s
Michel Machado
^ permalink raw reply
* Re: [PATCH bpf 1/1] bpf: btf: Fix bitfield extraction for big endian
From: Martin KaFai Lau @ 2018-07-09 18:32 UTC (permalink / raw)
To: Okash Khawaja
Cc: Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Jakub Kicinski, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180709004002.440153594@fb.com>
On Sun, Jul 08, 2018 at 05:22:03PM -0700, Okash Khawaja wrote:
> When extracting bitfield from a number, btf_int_bits_seq_show() builds
> a mask and accesses least significant byte of the number in a way
> specific to little-endian. This patch fixes that by checking endianness
> of the machine and then shifting left and right the unneeded bits.
>
> Thanks to Martin Lau for the help in navigating potential pitfalls when
> dealing with endianess and for the final solution.
>
> Fixes: b00b8daec828 ("bpf: btf: Add pretty print capability for data with BTF type info")
> Signed-off-by: Okash Khawaja <osk@fb.com>
>
> ---
> kernel/bpf/btf.c | 32 +++++++++++++++-----------------
> 1 file changed, 15 insertions(+), 17 deletions(-)
>
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -162,6 +162,8 @@
> #define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
> #define BITS_ROUNDUP_BYTES(bits) \
> (BITS_ROUNDDOWN_BYTES(bits) + !!BITS_PER_BYTE_MASKED(bits))
> +const int one = 1;
> +#define is_big_endian() ((*(char *)&one) == 0)
>
> #define BTF_INFO_MASK 0x0f00ffff
> #define BTF_INT_MASK 0x0fffffff
> @@ -991,16 +993,13 @@ static void btf_int_bits_seq_show(const
> void *data, u8 bits_offset,
> struct seq_file *m)
> {
> + u8 left_shift_bits, right_shift_bits;
Nit.
Although only max 64 bit int is allowed now (ensured by btf_int_check_meta),
it is better to use u16 such that it will be consistent to BTF_INT_BITS.
> u32 int_data = btf_type_int(t);
> u16 nr_bits = BTF_INT_BITS(int_data);
> u16 total_bits_offset;
> u16 nr_copy_bytes;
> u16 nr_copy_bits;
> - u8 nr_upper_bits;
> - union {
> - u64 u64_num;
> - u8 u8_nums[8];
> - } print_num;
> + u64 print_num;
>
> total_bits_offset = bits_offset + BTF_INT_OFFSET(int_data);
> data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
> @@ -1008,21 +1007,20 @@ static void btf_int_bits_seq_show(const
> nr_copy_bits = nr_bits + bits_offset;
> nr_copy_bytes = BITS_ROUNDUP_BYTES(nr_copy_bits);
>
> - print_num.u64_num = 0;
> - memcpy(&print_num.u64_num, data, nr_copy_bytes);
> -
> - /* Ditch the higher order bits */
> - nr_upper_bits = BITS_PER_BYTE_MASKED(nr_copy_bits);
> - if (nr_upper_bits) {
> - /* We need to mask out some bits of the upper byte. */
> - u8 mask = (1 << nr_upper_bits) - 1;
> -
> - print_num.u8_nums[nr_copy_bytes - 1] &= mask;
> + print_num = 0;
> + memcpy(&print_num, data, nr_copy_bytes);
> + if (is_big_endian()) {
> + left_shift_bits = bits_offset;
> + right_shift_bits = BITS_PER_U64 - nr_bits;
> + } else {
> + left_shift_bits = BITS_PER_U64 - nr_copy_bits;
> + right_shift_bits = BITS_PER_U64 - nr_bits;
Nit.
right_shift_bits is the same for both cases. Lets simplify it.
> }
>
> - print_num.u64_num >>= bits_offset;
> + print_num <<= left_shift_bits;
> + print_num >>= right_shift_bits;
>
> - seq_printf(m, "0x%llx", print_num.u64_num);
> + seq_printf(m, "0x%llx", print_num);
> }
>
> static void btf_int_seq_show(const struct btf *btf, const struct btf_type *t,
>
^ permalink raw reply
* RE: [PATCH net] hv_netvsc: Fix napi reschedule while receive completion is busy
From: Haiyang Zhang @ 2018-07-09 18:33 UTC (permalink / raw)
To: Stephen Hemminger, Haiyang Zhang
Cc: olaf@aepfle.de, Stephen Hemminger, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
vkuznets@redhat.com, davem@davemloft.net
In-Reply-To: <20180709111527.70ab354c@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Monday, July 9, 2018 2:15 PM
> To: Haiyang Zhang <haiyangz@linuxonhyperv.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>; davem@davemloft.net;
> netdev@vger.kernel.org; olaf@aepfle.de; Stephen Hemminger
> <sthemmin@microsoft.com>; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; vkuznets@redhat.com
> Subject: Re: [PATCH net] hv_netvsc: Fix napi reschedule while receive
> completion is busy
>
> On Mon, 9 Jul 2018 16:43:19 +0000
> Haiyang Zhang <haiyangz@linuxonhyperv.com> wrote:
>
> > From: Haiyang Zhang <haiyangz@microsoft.com>
> >
> > If out ring is full temporarily and receive completion cannot go out,
> > we may still need to reschedule napi if other conditions are met.
> > Otherwise the napi poll might be stopped forever, and cause network
> > disconnect.
> >
> > Fixes: 7426b1a51803 ("netvsc: optimize receive completions")
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > drivers/net/hyperv/netvsc.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> > index 8e9d0ee1572b..caaf5054f446 100644
> > --- a/drivers/net/hyperv/netvsc.c
> > +++ b/drivers/net/hyperv/netvsc.c
> > @@ -1285,14 +1285,14 @@ int netvsc_poll(struct napi_struct *napi, int
> budget)
> > nvchan->desc = hv_pkt_iter_next(channel, nvchan->desc);
> > }
> >
> > - /* If send of pending receive completions suceeded
> > - * and did not exhaust NAPI budget this time
> > + send_recv_completions(ndev, net_device, nvchan);
> > +
> > + /* If it did not exhaust NAPI budget this time
> > * and not doing busy poll
> > * then re-enable host interrupts
> > * and reschedule if ring is not empty.
> > */
> > - if (send_recv_completions(ndev, net_device, nvchan) == 0 &&
> > - work_done < budget &&
> > + if (work_done < budget &&
> > napi_complete_done(napi, work_done) &&
> > hv_end_read(&channel->inbound) &&
> > napi_schedule_prep(napi)) {
>
> This patch doesn't look right. I think the existing code works as written.
>
> If send_receive_completions is unable to send because ring is full then
> vmbus_sendpacket will return -EBUSY which gets returns from
> send_receive_completions. Because the return is non-zero, the driver will not
> call napi_complete_done.
> Since napi_complete_done was not called, NAPI will reschedule the napi poll
> routine.
With the existing code, we found in test, the rx_comp_busy counter increased,
one of the in-ring mask is 1, but guest is not reading it... With this patch, the
pending receive completion will stay in the buffer (no loss), and be sent next time.
It solves the disconnection problem when high number of connections.
If not calling napi_complete_done(), upper layer should guarantee napi_schedule,
then seems the upper NAPI code may have a bug -- the auto scheduling did not
happen in this case. I will check it further.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] tcp: fix high tail latencies in DCTCP
From: Lawrence Brakmo @ 2018-07-09 18:47 UTC (permalink / raw)
To: Yuchung Cheng, Neal Cardwell
Cc: David Miller, Netdev, Kernel Team, Blake Matheny,
Alexei Starovoitov, Steve Ibanez, Eric Dumazet, Yousuk Seung
In-Reply-To: <CAK6E8=cBPjWafA0fvrzwh84Jz4xE47CRjK0LvUimD5Ui590Nng@mail.gmail.com>
On 7/9/18, 12:32 PM, "Yuchung Cheng" <ycheng@google.com> wrote:
On Sat, Jul 7, 2018 at 7:07 AM, Neal Cardwell <ncardwell@google.com> wrote:
> On Sat, Jul 7, 2018 at 7:15 AM David Miller <davem@davemloft.net> wrote:
>>
>> From: Lawrence Brakmo <brakmo@fb.com>
>> Date: Tue, 3 Jul 2018 09:26:13 -0700
>>
>> > When have observed high tail latencies when using DCTCP for RPCs as
>> > compared to using Cubic. For example, in one setup there are 2 hosts
>> > sending to a 3rd one, with each sender having 3 flows (1 stream,
>> > 1 1MB back-to-back RPCs and 1 10KB back-to-back RPCs). The following
>> > table shows the 99% and 99.9% latencies for both Cubic and dctcp:
>> >
>> > Cubic 99% Cubic 99.9% dctcp 99% dctcp 99.9%
>> > 1MB RPCs 2.6ms 5.5ms 43ms 208ms
>> > 10KB RPCs 1.1ms 1.3ms 53ms 212ms
>> ...
>> > v2: Removed call to tcp_ca_event from tcp_send_ack since I added one in
>> > tcp_event_ack_sent. Based on Neal Cardwell <ncardwell@google.com>
>> > feedback.
>> > Modified tcp_ecn_check_ce (and renamed it tcp_ecn_check) instead of modifying
>> > tcp_ack_send_check to insure an ACK when cwr is received.
>> > v3: Handling cwr in tcp_ecn_accept_cwr instead of in tcp_ecn_check.
>> >
>> > [PATCH net-next v3 1/2] tcp: notify when a delayed ack is sent
>> > [PATCH net-next v3 2/2] tcp: ack immediately when a cwr packet
>>
>> Neal and co., what are your thoughts right now about this patch series?
>>
>> Thank you.
>
> IMHO these patches are a definite improvement over what we have now.
>
> That said, in chatting with Yuchung before the July 4th break, I think
> Yuchung and I agreed that we would ideally like to see something like
> the following:
>
> (1) refactor the DCTCP code to check for pending delayed ACKs directly
> using existing state (inet_csk(sk)->icsk_ack.pending &
> ICSK_ACK_TIMER), and remove the ca->delayed_ack_reserved DCTCP field
> and the CA_EVENT_DELAYED_ACK and CA_EVENT_NON_DELAYED_ACK callbacks
> added for DCTCP (which Larry determined had at least one bug).
I agree that getting rid of the callbacks would be an improvement, but that is more about optimizing the code. This could be done after we fix the current bugs. My concern is that it may be more complicated that we think and the current bug would continue to exist. Yes, I realize that it has been there for a while; but not because no one found it before, but because it was hard to pinpoint.
> (2) fix the bug with the DCTCP call to tcp_send_ack(sk) causing
> delayed ACKs to be incorrectly dropped/forgotten (not yet addressed by
> this patch series)
Good idea, but as I mentioned earlier, I would rather fix the really bad bugs first and then deal with this one. As far as I can see from my testing of DC-TCP, I have not seen any bad consequences from this bug so far.
> (3) then with fixes (1) and (2) in place, re-run tests and see if we
> still need Larry's heuristic (in patch 2) to fire an ACK immediately
> if a receiver receives a CWR packet (I suspect this is still very
> useful, but I think Yuchung is reluctant to add this complexity unless
> we have verified it's still needed after (1) and (2))
I fail to understand how (1) and (2) have anything to do with ACKing immediately when we receive a CWR packet. It has nothing to do with a current delayed ACK, it has to do with the cwnd closing to 1 when an TCP ECE marked packet is received at the end of an RPC and the current TCP delay ACK logic choosing to delay the ACK. The issue happens right after the receiver has sent its reply to the RPC, so at that stage there are no active delayed ACKs (the first patch fixed the issue where DC-TCP thought there was an active delayed ACK).
>
> Our team may be able to help out with some proposed patches for (1) and (2).
>
> In any case, I would love to have Yuchung and Eric weigh in (perhaps
> Monday) before we merge this patch series.
Thanks Neal. Sorry for not reflecting these timely before I took off
for July 4 holidays. I was going to post the same comment - Larry: I
could provide draft patches if that helps.
Yuchung: go ahead and send me the drafts. But as I already mentioned, I would like to fix the bad bug first and then make it pretty.
>
> Thanks,
> neal
^ permalink raw reply
* Re: [PATCH v2 bpf-next 02/14] bpf: introduce cgroup storage maps
From: Roman Gushchin @ 2018-07-09 18:53 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, kbuild-all, linux-kernel, kernel-team,
tj, Alexei Starovoitov, Sean Young
In-Reply-To: <54d9f3b6-a449-b5ee-a55b-c2cd983c11d0@iogearbox.net>
On Mon, Jul 09, 2018 at 10:37:45AM +0200, Daniel Borkmann wrote:
> On 07/08/2018 12:35 AM, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 02:52:32PM -0700, Roman Gushchin wrote:
> >> On Fri, Jul 06, 2018 at 10:42:39PM +0800, kbuild test robot wrote:
> >>> Hi Roman,
> >>>
> >>> Thank you for the patch! Yet something to improve:
> >>>
> >>> [auto build test ERROR on bpf-next/master]
> >>>
> >>> url: https://github.com/0day-ci/linux/commits/Roman-Gushchin/bpf-cgroup-local-storage/20180706-055938
> >>> base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
> >>> config: s390-performance_defconfig (attached as .config)
> >>> compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> >>> reproduce:
> >>> wget https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_intel_lkp-2Dtests_master_sbin_make.cross&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=ImwiAAR6DVyf5JEcIc5VLF9xY4lfFxVuk8_4BN6I03g&s=r0S7gFQPOZVZagshsK0pL3eU8_GRpD1ywrvYfXJ4yBQ&e= -O ~/bin/make.cross
> >>> chmod +x ~/bin/make.cross
> >>> # save the attached .config to linux build tree
> >>> GCC_VERSION=7.2.0 make.cross ARCH=s390
> >>>
> >>> All errors (new ones prefixed by >>):
> >>>
> >>> In file included from kernel//bpf/local_storage.c:2:0:
> >>> include/linux/bpf-cgroup.h: In function 'cgroup_bpf_prog_attach':
> >>>>> include/linux/bpf-cgroup.h:237:10: error: 'EINVAL' undeclared (first use in this function)
> >>> return -EINVAL;
> >>> ^~~~~~
> >>> include/linux/bpf-cgroup.h:237:10: note: each undeclared identifier is reported only once for each function it appears in
> >>> include/linux/bpf-cgroup.h: In function 'cgroup_bpf_prog_detach':
> >>> include/linux/bpf-cgroup.h:243:10: error: 'EINVAL' undeclared (first use in this function)
> >>> return -EINVAL;
> >>> ^~~~~~
> >>> include/linux/bpf-cgroup.h: In function 'cgroup_bpf_prog_query':
> >>> include/linux/bpf-cgroup.h:249:10: error: 'EINVAL' undeclared (first use in this function)
> >>> return -EINVAL;
> >>> ^~~~~~
> >>>
> >>> vim +/EINVAL +237 include/linux/bpf-cgroup.h
> >>>
> >>> 30070984 Daniel Mack 2016-11-23 232
> >>> fdb5c453 Sean Young 2018-06-19 233 static inline int cgroup_bpf_prog_attach(const union bpf_attr *attr,
> >>> fdb5c453 Sean Young 2018-06-19 234 enum bpf_prog_type ptype,
> >>> fdb5c453 Sean Young 2018-06-19 235 struct bpf_prog *prog)
> >>> fdb5c453 Sean Young 2018-06-19 236 {
> >>> fdb5c453 Sean Young 2018-06-19 @237 return -EINVAL;
> >>> fdb5c453 Sean Young 2018-06-19 238 }
> >>> fdb5c453 Sean Young 2018-06-19 239
> >>>
> >>> :::::: The code at line 237 was first introduced by commit
> >>> :::::: fdb5c4531c1e0e50e609df83f736b6f3a02896e2 bpf: fix attach type BPF_LIRC_MODE2 dependency wrt CONFIG_CGROUP_BPF
> >>>
> >>> :::::: TO: Sean Young <sean@mess.org>
> >>> :::::: CC: Daniel Borkmann <daniel@iogearbox.net>
> >>
> >> These errors have nothing to do with the cgroup local storage patchset.
> >> They do exist in the current bpf-next tree.
> >> Here is the fix.
> >>
> >> Thanks!
> >>
> >> --
> >>
> >> From c0cd59b969e060765514224e31595763213e40f9 Mon Sep 17 00:00:00 2001
> >> From: Roman Gushchin <guro@fb.com>
> >> Date: Fri, 6 Jul 2018 14:34:29 -0700
> >> Subject: [PATCH bpf-next] bpf: include errno.h from bpf-cgroup.h
> >>
> >> Commit fdb5c4531c1e ("bpf: fix attach type BPF_LIRC_MODE2 dependency
> >> wrt CONFIG_CGROUP_BPF") caused some build issues, detected by 0-DAY
> >> kernel test infrastructure.
> >>
> >> The problem is that cgroup_bpf_prog_attach/detach/query() functions
> >> can return -EINVAL error code, which is not defined. Fix this adding
> >> errno.h to includes.
> >>
> >> Fixes: fdb5c4531c1e ("bpf: fix attach type BPF_LIRC_MODE2 dependency
> >> wrt CONFIG_CGROUP_BPF")
> >> Signed-off-by: Roman Gushchin <guro@fb.com>
> >> Cc: Sean Young <sean@mess.org>
> >> Cc: Daniel Borkmann <daniel@iogearbox.net>
> >> Cc: Alexei Starovoitov <ast@kernel.org>
> >> ---
> >> include/linux/bpf-cgroup.h | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> >> index 79795c5fa7c3..d50c2f0a655a 100644
> >> --- a/include/linux/bpf-cgroup.h
> >> +++ b/include/linux/bpf-cgroup.h
> >> @@ -2,6 +2,7 @@
> >> #ifndef _BPF_CGROUP_H
> >> #define _BPF_CGROUP_H
> >>
> >> +#include <linux/errno.h>
> >> #include <linux/jump_label.h>
> >> #include <uapi/linux/bpf.h>
> >
> > good catch, but please resend it as a proper patch,
> > since patchwork didn't pick it up.
> > Also the subj should say 'bpf' instead of 'bpf-next', right?
>
> Yes, this needs to go to bpf tree, since the affected commit went
> there as well.
>
> I just applied the above fix into bpf tree, thanks.
Thanks, Daniel!
^ permalink raw reply
* Re: [PATCH v2] samples/bpf: Fix tc and ip paths in xdp2skb_meta.sh
From: Jesper Dangaard Brouer @ 2018-07-09 19:16 UTC (permalink / raw)
To: Taeung Song
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-kernel, brouer
In-Reply-To: <20180709175121.3355-1-treeze.taeung@gmail.com>
On Tue, 10 Jul 2018 02:51:21 +0900
Taeung Song <treeze.taeung@gmail.com> wrote:
> The below path error can occur:
>
> # ./xdp2skb_meta.sh --dev eth0 --list
> ./xdp2skb_meta.sh: line 61: /usr/sbin/tc: No such file or directory
>
> So just use command names instead of absolute paths of tc and ip.
> In addition, it allow callers to redefine $TC and $IP paths
>
> Fixes: 36e04a2d78d9 ("samples/bpf: xdp2skb_meta shows transferring info from XDP to SKB")
> Reviewed-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] can: mpc5xxx_can: check of_iomap return before use
From: Nicholas Mc Guire @ 2018-07-09 19:16 UTC (permalink / raw)
To: Wolfram Sang
Cc: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
linux-can, netdev, linux-kernel, Nicholas Mc Guire
of_iompa() can return NULL so that return needs to be checked and NULL
treated as failure. While at it also take care of the missing
of_node_put() in the error path.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: commit afa17a500a36 ("net/can: add driver for mscan family & mpc52xx_mscan")
---
Problem was found by an experimental coccinelle script
Patch was compiletested with: mpc5200_defconfig + CONFIG_CAN=y,
CONFIG_CAN_MSCAN=y, CONFIG_CAN_MPC5XXX=y
(with a number of sparse warnings not related to the proposed change)
Patch is against 4.18-rc3 (localversion-next is next-20180706)
drivers/net/can/mscan/mpc5xxx_can.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index c7427bd..2949a38 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -86,6 +86,11 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
return 0;
}
cdm = of_iomap(np_cdm, 0);
+ if (!cdm) {
+ of_node_put(np_cdm);
+ dev_err(&ofdev->dev, "can't map clock node!\n");
+ return 0;
+ }
if (in_8(&cdm->ipb_clk_sel) & 0x1)
freq *= 2;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] samples/bpf: Fix tc and ip path in xdp2skb_meta.sh
From: Jesper Dangaard Brouer @ 2018-07-09 19:20 UTC (permalink / raw)
To: Taeung Song
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-kernel, brouer
In-Reply-To: <30be797e-e247-1b34-6607-0f0fd3b898fd@gmail.com>
On Tue, 10 Jul 2018 02:44:06 +0900
Taeung Song <treeze.taeung@gmail.com> wrote:
> Hi Jesper Dangaard Brouer,
>
> On 07/10/2018 12:40 AM, Jesper Dangaard Brouer wrote:
> > On Tue, 10 Jul 2018 00:04:18 +0900
> > Taeung Song <treeze.taeung@gmail.com> wrote:
> >
> >> The below path error can occur:
> >>
> >> # ./xdp2skb_meta.sh --dev eth0 --list
> >> ./xdp2skb_meta.sh: line 61: /usr/sbin/tc: No such file or directory
> >>
> >> # which tc
> >> /sbin/tc
> >>
> >> So use 'which' command instead of absolute path of tc and ip
> >>
> >> Fixes: 36e04a2d78d9 ("samples/bpf: xdp2skb_meta shows transferring info from XDP to SKB")
> >> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> >> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
> >> ---
> >> samples/bpf/xdp2skb_meta.sh | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/samples/bpf/xdp2skb_meta.sh b/samples/bpf/xdp2skb_meta.sh
> >> index b9c9549c4c27..67cf7b5f336d 100755
> >> --- a/samples/bpf/xdp2skb_meta.sh
> >> +++ b/samples/bpf/xdp2skb_meta.sh
> >> @@ -16,8 +16,8 @@
> >> BPF_FILE=xdp2skb_meta_kern.o
> >> DIR=$(dirname $0)
> >>
> >> -export TC=/usr/sbin/tc
> >> -export IP=/usr/sbin/ip
> >> +export TC=`which tc`
> >> +export IP=`which ip`
> >
> > This is not a good solution, as 'which' can return something else.
> > E.g. on my system I've aliased 'tc' to 'sudo tc', and `which tc` returns:
> >
> > $ which tc
> > alias tc='sudo tc'
> > /usr/bin/sudo
> >
> > The easiest solution is to simply do:
> >
> > export TC=tc
> > export IP=ip
> >
> > The more fancy solution is to allow callers to redefine $IP and $TC:
> >
> > [ -z "$TC" ] && TC=tc
> > [ -z "$IP" ] && IP=ip
> >
>
> Yep, you are right, I'll change it.
>
> > And then you should also fix the use of 'basename', see below patch...
> >
>
> I thought it'd be fine to leave 'basename' as it is,
> because if callers redefine TC=/home/taeung/tc and give
> the options --verbose or --dry-run, 'basename' can more tidily show outputs.
The 'basename' does not work correctly if e.g. TC='sudo tc'.
Below output is with 'basename' removed, else it would say "sudo qdisc del ..."
TC='sudo tc' IP='sudo ip' ./xdp2skb_meta.sh -v --dev mlx5p1 --dry-run
# Device set to: DEV=mlx5p1
# Dry-run mode: enable VERBOSE and don't call TC+IP
sudo tc qdisc del dev mlx5p1 clsact
sudo tc qdisc add dev mlx5p1 clsact
sudo tc filter add dev mlx5p1 ingress prio 1 handle 1 bpf da obj ./xdp2skb_meta_kern.o sec tc_mark
# Flush XDP on device: mlx5p1
sudo ip link set dev mlx5p1 xdp off
sudo ip link set dev mlx5p1 xdp obj ./xdp2skb_meta_kern.o sec xdp_mark
> But it seems to be trivial, I'll resend this patch as v2 based on your
> comment !
Thx, already ACKed it :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [V9fs-developer] [PATCH] Integer underflow in pdu_read()
From: Tomas Bortoli @ 2018-07-09 19:26 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: davem, v9fs-developer, netdev, linux-kernel, syzkaller,
Tomas Bortoli
The pdu_read() function suffers from an integer underflow.
When pdu->offset is greater than pdu->size, the length calculation will have
a wrong result, resulting in an out-of-bound read.
This patch modifies also pdu_write() in the same way to prevent the same
issue from happening there and for consistency.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
---
net/9p/protocol.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/9p/protocol.c b/net/9p/protocol.c
index 931ea00c4fed..f1e2425f920b 100644
--- a/net/9p/protocol.c
+++ b/net/9p/protocol.c
@@ -55,16 +55,20 @@ EXPORT_SYMBOL(p9stat_free);
size_t pdu_read(struct p9_fcall *pdu, void *data, size_t size)
{
- size_t len = min(pdu->size - pdu->offset, size);
- memcpy(data, &pdu->sdata[pdu->offset], len);
+ size_t len = pdu->offset > pdu->size ? 0 :
+ min(pdu->size - pdu->offset, size);
+ if (len != 0)
+ memcpy(data, &pdu->sdata[pdu->offset], len);
pdu->offset += len;
return size - len;
}
static size_t pdu_write(struct p9_fcall *pdu, const void *data, size_t size)
{
- size_t len = min(pdu->capacity - pdu->size, size);
- memcpy(&pdu->sdata[pdu->size], data, len);
+ size_t len = pdu->size > pdu->capacity ? 0 :
+ min(pdu->capacity - pdu->size, size);
+ if (len != 0)
+ memcpy(&pdu->sdata[pdu->size], data, len);
pdu->size += len;
return size - len;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] can: mpc5xxx_can: check of_iomap return before use
From: Fabio Estevam @ 2018-07-09 19:28 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Wolfram Sang, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, linux-can, netdev, linux-kernel
In-Reply-To: <1531163800-12111-1-git-send-email-hofrat@osadl.org>
On Mon, Jul 9, 2018 at 4:16 PM, Nicholas Mc Guire <hofrat@osadl.org> wrote:
> of_iompa() can return NULL so that return needs to be checked and NULL
s/of_iompa/of_iomap/
> treated as failure. While at it also take care of the missing
> of_node_put() in the error path.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Fixes: commit afa17a500a36 ("net/can: add driver for mscan family & mpc52xx_mscan")
> ---
>
> Problem was found by an experimental coccinelle script
>
> Patch was compiletested with: mpc5200_defconfig + CONFIG_CAN=y,
> CONFIG_CAN_MSCAN=y, CONFIG_CAN_MPC5XXX=y
> (with a number of sparse warnings not related to the proposed change)
>
> Patch is against 4.18-rc3 (localversion-next is next-20180706)
>
> drivers/net/can/mscan/mpc5xxx_can.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> index c7427bd..2949a38 100644
> --- a/drivers/net/can/mscan/mpc5xxx_can.c
> +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> @@ -86,6 +86,11 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
> return 0;
> }
> cdm = of_iomap(np_cdm, 0);
> + if (!cdm) {
> + of_node_put(np_cdm);
> + dev_err(&ofdev->dev, "can't map clock node!\n");
> + return 0;
I think you should return an error code here. -ENOMEM maybe?
^ permalink raw reply
* Re: WARNING: ODEBUG bug in p9_fd_close
From: syzbot @ 2018-07-09 19:31 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <00000000000024f01405708aab83@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 1e4b044d2251 Linux 4.18-rc4
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=100ff170400000
kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=d702a81aadeedd565723
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17fa550c400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1214c2c2400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d702a81aadeedd565723@syzkaller.appspotmail.com
------------[ cut here ]------------
ODEBUG: free active (active state 0) object type: work_struct hint:
p9_read_work+0x0/0x1060 net/9p/trans_fd.c:208
WARNING: CPU: 1 PID: 4559 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 4559 Comm: syz-executor938 Not tainted 4.18.0-rc4+ #138
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Code: 1a 88 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 92 00 00 00 48 8b 14 dd
a0 71 1a 88 4c 89 f6 48 c7 c7 40 67 1a 88 e8 c6 94 e6 fd <0f> 0b 83 05 d9
66 3e 06 01 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f
RSP: 0018:ffff8801ce7172d8 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff81631821 RDI: 0000000000000001
RBP: ffff8801ce717318 R08: ffff8801b1ad0040 R09: ffffed003b5e3ec2
R10: ffffed003b5e3ec2 R11: ffff8801daf1f617 R12: 0000000000000001
R13: ffffffff88f63820 R14: ffffffff881a6be0 R15: ffffffff814ea9c0
__debug_check_no_obj_freed lib/debugobjects.c:783 [inline]
debug_check_no_obj_freed+0x3b2/0x595 lib/debugobjects.c:815
kfree+0xc7/0x260 mm/slab.c:3812
p9_fd_close+0x416/0x5b0 net/9p/trans_fd.c:893
p9_client_create+0xac2/0x16c9 net/9p/client.c:1076
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44aa59
Code: e8 4c c2 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b cd fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f86c9470da8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00000000006f0024 RCX: 000000000044aa59
RDX: 0000000020000100 RSI: 0000000020000340 RDI: 0000000000000000
RBP: 00000000006f0020 R08: 00000000200001c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 6f72746e6f632f2e
R13: 7363762f7665642f R14: 64663d736e617274 R15: 0000000000000001
======================================================
WARNING: possible circular locking dependency detected
4.18.0-rc4+ #138 Not tainted
------------------------------------------------------
syz-executor938/4559 is trying to acquire lock:
000000002f789677 ((console_sem).lock){-...}, at: down_trylock+0x13/0x70
kernel/locking/semaphore.c:136
but task is already holding lock:
00000000d059bb19 (&obj_hash[i].lock){-.-.}, at: __debug_check_no_obj_freed
lib/debugobjects.c:774 [inline]
00000000d059bb19 (&obj_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0x16c/0x595 lib/debugobjects.c:815
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&obj_hash[i].lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
__debug_object_init+0x127/0x12e0 lib/debugobjects.c:381
debug_object_init+0x16/0x20 lib/debugobjects.c:429
debug_hrtimer_init kernel/time/hrtimer.c:410 [inline]
debug_init kernel/time/hrtimer.c:458 [inline]
hrtimer_init+0x97/0x480 kernel/time/hrtimer.c:1308
init_dl_task_timer+0x1b/0x50 kernel/sched/deadline.c:1056
__sched_fork+0x2ae/0x590 kernel/sched/core.c:2185
init_idle+0x75/0x7a0 kernel/sched/core.c:5405
sched_init+0xbf3/0xd2c kernel/sched/core.c:6103
start_kernel+0x47d/0x949 init/main.c:602
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #2 (&rq->lock){-.-.}:
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
rq_lock kernel/sched/sched.h:1812 [inline]
task_fork_fair+0x93/0x680 kernel/sched/fair.c:9952
sched_fork+0x446/0xb40 kernel/sched/core.c:2381
copy_process.part.39+0x1c09/0x7220 kernel/fork.c:1773
copy_process kernel/fork.c:1616 [inline]
_do_fork+0x291/0x12a0 kernel/fork.c:2099
kernel_thread+0x34/0x40 kernel/fork.c:2158
rest_init+0x22/0xe4 init/main.c:408
start_kernel+0x90e/0x949 init/main.c:738
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #1 (&p->pi_lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
try_to_wake_up+0xd2/0x12b0 kernel/sched/core.c:1985
wake_up_process+0x10/0x20 kernel/sched/core.c:2148
__up.isra.1+0x1c0/0x2a0 kernel/locking/semaphore.c:262
up+0x13c/0x1c0 kernel/locking/semaphore.c:187
__up_console_sem+0xbe/0x1b0 kernel/printk/printk.c:242
console_unlock+0x7a2/0x10b0 kernel/printk/printk.c:2411
vprintk_emit+0x6c6/0xdf0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1948
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:382
printk+0xa7/0xcf kernel/printk/printk.c:1981
load_umh+0x51/0xbd net/bpfilter/bpfilter_kern.c:98
do_one_initcall+0x127/0x913 init/main.c:884
do_initcall_level init/main.c:952 [inline]
do_initcalls init/main.c:960 [inline]
do_basic_setup init/main.c:978 [inline]
kernel_init_freeable+0x49b/0x58e init/main.c:1135
kernel_init+0x11/0x1b3 init/main.c:1061
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
-> #0 ((console_sem).lock){-...}:
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
__down_trylock_console_sem+0xae/0x200 kernel/printk/printk.c:225
console_trylock+0x15/0xa0 kernel/printk/printk.c:2230
console_trylock_spinning kernel/printk/printk.c:1643 [inline]
vprintk_emit+0x6ad/0xdf0 kernel/printk/printk.c:1906
vprintk_default+0x28/0x30 kernel/printk/printk.c:1948
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:382
printk+0xa7/0xcf kernel/printk/printk.c:1981
__warn_printk+0x8c/0xe0 kernel/panic.c:590
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
__debug_check_no_obj_freed lib/debugobjects.c:783 [inline]
debug_check_no_obj_freed+0x3b2/0x595 lib/debugobjects.c:815
kfree+0xc7/0x260 mm/slab.c:3812
p9_fd_close+0x416/0x5b0 net/9p/trans_fd.c:893
p9_client_create+0xac2/0x16c9 net/9p/client.c:1076
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
(console_sem).lock --> &rq->lock --> &obj_hash[i].lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&obj_hash[i].lock);
lock(&rq->lock);
lock(&obj_hash[i].lock);
lock((console_sem).lock);
*** DEADLOCK ***
1 lock held by syz-executor938/4559:
#0: 00000000d059bb19 (&obj_hash[i].lock){-.-.}, at:
__debug_check_no_obj_freed lib/debugobjects.c:774 [inline]
#0: 00000000d059bb19 (&obj_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0x16c/0x595 lib/debugobjects.c:815
stack backtrace:
CPU: 1 PID: 4559 Comm: syz-executor938 Not tainted 4.18.0-rc4+ #138
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_circular_bug.isra.36.cold.57+0x1bd/0x27d
kernel/locking/lockdep.c:1227
check_prev_add kernel/locking/lockdep.c:1867 [inline]
check_prevs_add kernel/locking/lockdep.c:1980 [inline]
validate_chain kernel/locking/lockdep.c:2421 [inline]
__lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
__down_trylock_console_sem+0xae/0x200 kernel/printk/printk.c:225
console_trylock+0x15/0xa0 kernel/printk/printk.c:2230
console_trylock_spinning kernel/printk/printk.c:1643 [inline]
vprintk_emit+0x6ad/0xdf0 kernel/printk/printk.c:1906
vprintk_default+0x28/0x30 kernel/printk/printk.c:1948
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:382
printk+0xa7/0xcf kernel/printk/printk.c:1981
__warn_printk+0x8c/0xe0 kernel/panic.c:590
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
__debug_check_no_obj_freed lib/debugobjects.c:783 [inline]
debug_check_no_obj_freed+0x3b2/0x595 lib/debugobjects.c:815
kfree+0xc7/0x260 mm/slab.c:3812
p9_fd_close+0x416/0x5b0 net/9p/trans_fd.c:893
p9_client_create+0xac2/0x16c9 net/9p/client.c:1076
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44aa59
Code: e8 4c c2 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b cd fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f86c9470da8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00000000006f0024 RCX: 000000000044aa59
RDX: 0000000020000100 RSI: 0000000020000340 RDI: 0000000000000000
RBP: 00000000006f0020 R08: 00000000200001c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 6f72746e6f632f2e
R13: 7363762f7665642f R14: 64663d736e617274 R15: 0000000000000001
Shutting down cpus with NMI
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [V9fs-developer] [PATCH] Integer underflow in pdu_read()
From: Al Viro @ 2018-07-09 19:31 UTC (permalink / raw)
To: Tomas Bortoli
Cc: ericvh, rminnich, lucho, davem, v9fs-developer, netdev,
linux-kernel, syzkaller
In-Reply-To: <20180709192651.28095-1-tomasbortoli@gmail.com>
On Mon, Jul 09, 2018 at 09:26:51PM +0200, Tomas Bortoli wrote:
> The pdu_read() function suffers from an integer underflow.
> When pdu->offset is greater than pdu->size, the length calculation will have
> a wrong result, resulting in an out-of-bound read.
> This patch modifies also pdu_write() in the same way to prevent the same
> issue from happening there and for consistency.
What does cause the calls of pdu_read() in such conditions and shouldn't *that*
be dealt with?
^ permalink raw reply
* Re: [PATCH] can: mpc5xxx_can: check of_iomap return before use
From: Nicholas Mc Guire @ 2018-07-09 19:31 UTC (permalink / raw)
To: Fabio Estevam
Cc: Nicholas Mc Guire, Wolfram Sang, Wolfgang Grandegger,
Marc Kleine-Budde, David S. Miller, linux-can, netdev,
linux-kernel
In-Reply-To: <CAOMZO5CPVx_3kj5xKaoNbYP14cgPk9aSniyu44oWF-0jbSx91g@mail.gmail.com>
On Mon, Jul 09, 2018 at 04:28:41PM -0300, Fabio Estevam wrote:
> On Mon, Jul 9, 2018 at 4:16 PM, Nicholas Mc Guire <hofrat@osadl.org> wrote:
> > of_iompa() can return NULL so that return needs to be checked and NULL
>
> s/of_iompa/of_iomap/
sorry - thats a stupid one.
>
> > treated as failure. While at it also take care of the missing
> > of_node_put() in the error path.
> >
> > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> > Fixes: commit afa17a500a36 ("net/can: add driver for mscan family & mpc52xx_mscan")
> > ---
> >
> > Problem was found by an experimental coccinelle script
> >
> > Patch was compiletested with: mpc5200_defconfig + CONFIG_CAN=y,
> > CONFIG_CAN_MSCAN=y, CONFIG_CAN_MPC5XXX=y
> > (with a number of sparse warnings not related to the proposed change)
> >
> > Patch is against 4.18-rc3 (localversion-next is next-20180706)
> >
> > drivers/net/can/mscan/mpc5xxx_can.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> > index c7427bd..2949a38 100644
> > --- a/drivers/net/can/mscan/mpc5xxx_can.c
> > +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> > @@ -86,6 +86,11 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
> > return 0;
> > }
> > cdm = of_iomap(np_cdm, 0);
> > + if (!cdm) {
> > + of_node_put(np_cdm);
> > + dev_err(&ofdev->dev, "can't map clock node!\n");
> > + return 0;
>
> I think you should return an error code here. -ENOMEM maybe?
I don´t think so the code above this part return 0 on error and a
valid frequency on success so returning -ENOMEM would probably be
mistaken as a frequency !
thx!
hofrat
^ permalink raw reply
* Re: [PATCH] can: mpc5xxx_can: check of_iomap return before use
From: Fabio Estevam @ 2018-07-09 19:35 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Nicholas Mc Guire, Wolfram Sang, Wolfgang Grandegger,
Marc Kleine-Budde, David S. Miller, linux-can, netdev,
linux-kernel
In-Reply-To: <20180709193157.GB17865@osadl.at>
On Mon, Jul 9, 2018 at 4:31 PM, Nicholas Mc Guire <der.herr@hofr.at> wrote:
> I don´t think so the code above this part return 0 on error and a
> valid frequency on success so returning -ENOMEM would probably be
> mistaken as a frequency !
Now that I looked closely in the function context I see it makes sense
to return 0 :-)
Thanks
^ permalink raw reply
* Re: [PATCH bpf-next v2 09/12] tools: bpftool: reimplement bpf_prog_load() for prog load
From: Alexei Starovoitov @ 2018-07-09 19:40 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: daniel, oss-drivers, netdev
In-Reply-To: <20180709175944.32265-10-jakub.kicinski@netronome.com>
On Mon, Jul 09, 2018 at 10:59:41AM -0700, Jakub Kicinski wrote:
> bpf_prog_load() is a very useful helper but it doesn't give us full
> flexibility of modifying the BPF objects before loading. Open code
> bpf_prog_load() in bpftool so we can add extra logic in following
> commits.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH bpf-next v2 12/12] tools: bpftool: allow reuse of maps with bpftool prog load
From: Alexei Starovoitov @ 2018-07-09 19:48 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: daniel, oss-drivers, netdev
In-Reply-To: <20180709175944.32265-13-jakub.kicinski@netronome.com>
On Mon, Jul 09, 2018 at 10:59:44AM -0700, Jakub Kicinski wrote:
> Add map parameter to prog load which will allow reuse of existing
> maps instead of creating new ones.
>
> We need feature detection and compat code for reallocarray, since
> it's not available in many libc versions.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
cmdline interface feels a bit awkward to use, but it's a nice improvement.
Acked-by: Alexei Starovoitov <ast@kernel.org>
any plans to extend bpf_map_def similar to iproute2 ?
so things like pinned file name and map reuse can be specified in .c file
instead of cmdline?
^ permalink raw reply
* [PATCH iproute2-next 0/9] TC more JSON support
From: Stephen Hemminger @ 2018-07-09 19:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
From: Stephen Hemminger <sthemmin@microsoft.com>
Update core of TC command and library to do more JSON.
Most of this patch set is about getting tc utility functions
to be more friendly to the json_print infrastructure.
Stephen Hemminger (9):
tc: use JSON in error handling
tc: use const char in util
tc: convert stats print to json
tc/cbq: use sprint_rate
tc/util: remove print_rate
tc/util: remove unused print_size
tc/util: remove unused print_time
tc/util: add print helpers for JSON
tc/sfq: add json support
tc/q_cbq.c | 15 ++++-----
tc/q_sfq.c | 65 +++++++++++++++++++++---------------
tc/tc.c | 19 ++++++-----
tc/tc_util.c | 94 +++++++++++++++++++++++++++-------------------------
tc/tc_util.h | 11 +++---
5 files changed, 109 insertions(+), 95 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH iproute2-next 1/9] tc: use JSON in error handling
From: Stephen Hemminger @ 2018-07-09 19:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20180709194856.18922-1-stephen@networkplumber.org>
From: Stephen Hemminger <sthemmin@microsoft.com>
If option or qdisc is unknown, still output in JSON.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
tc/tc.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tc/tc.c b/tc/tc.c
index 0d223281ba25..b6d2a6151793 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -56,9 +56,11 @@ static struct filter_util *filter_list;
static int print_noqopt(struct qdisc_util *qu, FILE *f,
struct rtattr *opt)
{
- if (opt && RTA_PAYLOAD(opt))
- fprintf(f, "[Unknown qdisc, optlen=%u] ",
- (unsigned int) RTA_PAYLOAD(opt));
+ if (opt && RTA_PAYLOAD(opt)) {
+ print_string(PRINT_JSON, "qdisc", NULL, "UNKNOWN");
+ print_uint(PRINT_ANY, "optlen", "[Unknown qdisc, optlen=%u] ",
+ RTA_PAYLOAD(opt));
+ }
return 0;
}
@@ -76,11 +78,12 @@ static int parse_noqopt(struct qdisc_util *qu, int argc, char **argv,
static int print_nofopt(struct filter_util *qu, FILE *f, struct rtattr *opt, __u32 fhandle)
{
- if (opt && RTA_PAYLOAD(opt))
- fprintf(f, "fh %08x [Unknown filter, optlen=%u] ",
- fhandle, (unsigned int) RTA_PAYLOAD(opt));
- else if (fhandle)
- fprintf(f, "fh %08x ", fhandle);
+ if (opt && RTA_PAYLOAD(opt)) {
+ print_0xhex(PRINT_ANY, "handle", "fh %08x ", fhandle);
+ print_uint(PRINT_ANY, "optlen", "[Unknown filter, optlen=%u] ",
+ RTA_PAYLOAD(opt));
+ } else if (fhandle)
+ print_0xhex(PRINT_ANY, "handle", "fh %08x ", fhandle);
return 0;
}
--
2.18.0
^ permalink raw reply related
* [PATCH iproute2-next 2/9] tc: use const char in util
From: Stephen Hemminger @ 2018-07-09 19:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20180709194856.18922-1-stephen@networkplumber.org>
From: Stephen Hemminger <sthemmin@microsoft.com>
For prefix and path, can use const char.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
tc/tc_util.c | 8 +++++---
tc/tc_util.h | 6 +++---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index e0c96291ade0..e8e1241d083d 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -35,7 +35,7 @@ static struct db_names *cls_names;
#define NAMES_DB "/etc/iproute2/tc_cls"
-int cls_names_init(char *path)
+int cls_names_init(const char *path)
{
int ret;
@@ -800,7 +800,8 @@ void print_tm(FILE *f, const struct tcf_t *tm)
}
}
-void print_tcstats2_attr(FILE *fp, struct rtattr *rta, char *prefix, struct rtattr **xstats)
+void print_tcstats2_attr(FILE *fp, struct rtattr *rta,
+ const char *prefix, struct rtattr **xstats)
{
SPRINT_BUF(b1);
struct rtattr *tbs[TCA_STATS_MAX + 1];
@@ -868,7 +869,8 @@ void print_tcstats2_attr(FILE *fp, struct rtattr *rta, char *prefix, struct rtat
*xstats = tbs[TCA_STATS_APP] ? : NULL;
}
-void print_tcstats_attr(FILE *fp, struct rtattr *tb[], char *prefix, struct rtattr **xstats)
+void print_tcstats_attr(FILE *fp, struct rtattr *tb[],
+ const char *prefix, struct rtattr **xstats)
{
SPRINT_BUF(b1);
diff --git a/tc/tc_util.h b/tc/tc_util.h
index 6632c4f9c528..64b309903c69 100644
--- a/tc/tc_util.h
+++ b/tc/tc_util.h
@@ -100,9 +100,9 @@ char *sprint_ticks(__u32 ticks, char *buf);
char *sprint_linklayer(unsigned int linklayer, char *buf);
void print_tcstats_attr(FILE *fp, struct rtattr *tb[],
- char *prefix, struct rtattr **xstats);
+ const char *prefix, struct rtattr **xstats);
void print_tcstats2_attr(FILE *fp, struct rtattr *rta,
- char *prefix, struct rtattr **xstats);
+ const char *prefix, struct rtattr **xstats);
int get_tc_classid(__u32 *h, const char *str);
int print_tc_classid(char *buf, int len, __u32 h);
@@ -130,7 +130,7 @@ int parse_action(int *argc_p, char ***argv_p, int tca_id, struct nlmsghdr *n);
void print_tm(FILE *f, const struct tcf_t *tm);
int prio_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt);
-int cls_names_init(char *path);
+int cls_names_init(const char *path);
void cls_names_uninit(void);
int action_a2n(char *arg, int *result, bool allow_num);
--
2.18.0
^ permalink raw reply related
* [PATCH iproute2-next 3/9] tc: convert stats print to json
From: Stephen Hemminger @ 2018-07-09 19:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20180709194856.18922-1-stephen@networkplumber.org>
From: Stephen Hemminger <sthemmin@microsoft.com>
Convert compatiablity statistics to print in JSON.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
tc/tc_util.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index e8e1241d083d..05b6c97563b3 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -887,25 +887,37 @@ void print_tcstats_attr(FILE *fp, struct rtattr *tb[],
/* handle case where kernel returns more/less than we know about */
memcpy(&st, RTA_DATA(tb[TCA_STATS]), MIN(RTA_PAYLOAD(tb[TCA_STATS]), sizeof(st)));
- fprintf(fp, "%sSent %llu bytes %u pkts (dropped %u, overlimits %u) ",
- prefix, (unsigned long long)st.bytes, st.packets, st.drops,
- st.overlimits);
+ print_string(PRINT_FP, NULL, "%sSent ", prefix);
+ print_u64(PRINT_ANY, "bytes", "%llu bytes ", (unsigned long long)st.bytes);
+ print_uint(PRINT_ANY, "packets", "%u pkts ", st.packets);
+ print_uint(PRINT_ANY, "dropped", "(dropped %u, ", st.drops);
+ print_uint(PRINT_ANY, "overlimits", "overlimits %u) ", st.overlimits);
if (st.bps || st.pps || st.qlen || st.backlog) {
- fprintf(fp, "\n%s", prefix);
+ print_string(PRINT_FP, "%s%s", _SL_, prefix);
+
if (st.bps || st.pps) {
- fprintf(fp, "rate ");
+ print_string(PRINT_FP, NULL, "%s", "rate ");
+ print_uint(PRINT_JSON, "rate", NULL, st.bps);
if (st.bps)
- fprintf(fp, "%s ", sprint_rate(st.bps, b1));
+ print_string(PRINT_FP, NULL, "%s ",
+ sprint_rate(st.bps, b1));
+
+ print_uint(PRINT_JSON, "pps", NULL, st.pps);
if (st.pps)
- fprintf(fp, "%upps ", st.pps);
+ print_uint(PRINT_FP, NULL, "%upps ", st.pps);
}
if (st.qlen || st.backlog) {
- fprintf(fp, "backlog ");
+ print_string(PRINT_FP, NULL, "%s", "backlog ");
+
+ print_uint(PRINT_JSON, "backlog", NULL, st.backlog);
+ print_uint(PRINT_JSON, "qlen", NULL, st.qlen);
if (st.backlog)
- fprintf(fp, "%s ", sprint_size(st.backlog, b1));
+ print_string(PRINT_FP, NULL,
+ "%s ", sprint_size(st.backlog, b1));
if (st.qlen)
- fprintf(fp, "%up ", st.qlen);
+ print_uint(PRINT_FP, NULL,
+ "%up ", st.qlen);
}
}
}
--
2.18.0
^ permalink raw reply related
* [PATCH iproute2-next 4/9] tc/cbq: use sprint_rate
From: Stephen Hemminger @ 2018-07-09 19:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20180709194856.18922-1-stephen@networkplumber.org>
From: Stephen Hemminger <sthemmin@microsoft.com>
All other places in tc use sprint_rate.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
tc/q_cbq.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/tc/q_cbq.c b/tc/q_cbq.c
index e7f1a3bfaf5d..ad0170c41858 100644
--- a/tc/q_cbq.c
+++ b/tc/q_cbq.c
@@ -495,10 +495,9 @@ static int cbq_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
}
if (r) {
- char buf[64];
- print_rate(buf, sizeof(buf), r->rate);
- fprintf(f, "rate %s ", buf);
+ fprintf(f, "rate %s ",
+ sprint_rate(r->rate, b1));
linklayer = (r->linklayer & TC_LINKLAYER_MASK);
if (linklayer > TC_LINKLAYER_ETHERNET || show_details)
fprintf(f, "linklayer %s ", sprint_linklayer(linklayer, b2));
@@ -530,14 +529,12 @@ static int cbq_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
fprintf(f, "prio %u", wrr->priority);
else
fprintf(f, "prio no-transmit");
- if (show_details) {
- char buf[64];
+ if (show_details) {
fprintf(f, "/%u ", wrr->cpriority);
- if (wrr->weight != 1) {
- print_rate(buf, sizeof(buf), wrr->weight);
- fprintf(f, "weight %s ", buf);
- }
+ if (wrr->weight != 1)
+ fprintf(f, "weight %s ",
+ sprint_rate(wrr->weight, b1));
if (wrr->allot)
fprintf(f, "allot %ub ", wrr->allot);
}
--
2.18.0
^ permalink raw reply related
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