* Re: [PATCH iproute2 v3 0/7] ip6/tunnel: Unify tclass, flowlabel and encap_limit output
From: Serhey Popovych @ 2018-01-08 17:07 UTC (permalink / raw)
To: netdev
In-Reply-To: <1515431072-29128-1-git-send-email-serhe.popovych@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 944 bytes --]
Please ignore series: wrong series number (3).
Sorry for noise.
> With this series I want to improve printing of tclass,
> flowlabel and encapsulation limit (encap_limit) options.
>
> Everything within this series is open for your comments,
> suggestions and criticism.
>
> See individual patch description message for details.
>
> Thanks,
> Serhii
>
> Serhey Popovych (7):
> ip6/tunnel: Fix tclass output
> ip6tnl/tunnel: Do not print obscure flowinfo
> ip6/tunnel: Unify tclass printing
> ip6/tunnel: Unify flowlabel printing
> ip6/tunnel: Unify encap_limit printing
> gre6/tunnel: Output flowlabel after tclass
> ip6tnl/tunnel: Output hoplimit before encapsulation limit
>
> ip/link_gre6.c | 54 ++++++++++++++++------------------------------
> ip/link_ip6tnl.c | 63 ++++++++++++++++++------------------------------------
> 2 files changed, 40 insertions(+), 77 deletions(-)
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 02/18] Documentation: document nospec helpers
From: Mark Rutland @ 2018-01-08 17:09 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Dan Williams, linux-kernel, linux-arch, peterz, netdev,
Will Deacon, gregkh, tglx, torvalds, alan
In-Reply-To: <20180108092917.591359aa@lwn.net>
Hi Jon,
On Mon, Jan 08, 2018 at 09:29:17AM -0700, Jonathan Corbet wrote:
> On Fri, 05 Jan 2018 17:10:03 -0800
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > Document the rationale and usage of the new nospec*() helpers.
>
> I have just a couple of overall comments.
>
> - It would be nice if the document were done in RST and placed in the
> core-API manual, perhaps using kerneldoc comments for the macros
> themselves. It's already 99.9% RST now, so the changes required would
> be minimal.
Is there any quickstart guide to RST that you can recommend?
I'm happy to clean up the documentation; I'm just not familiar with RST.
> - More importantly: is there any way at all to give guidance to
> developers wondering *when* they should use these primitives? I think
> it would be easy to create a situation where they don't get used where
> they are really needed; meanwhile, there may well be a flood of
> "helpful" patches adding them where they make no sense at all.
This is on my TODO list.
The unfortunate truth is that it's likely to be a subjective judgement
call in many cases, depending on how likely it is that the user can
influence the code in question, so it's difficult to provide
hard-and-fast rules.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH net-next v5 2/2] net: thunderx: add timestamping support
From: Aleksey Makarov @ 2018-01-08 17:12 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, linux-arm-kernel, linux-kernel, Goutham, Sunil,
Radoslaw Biernacki, Robert Richter, David Daney,
Philippe Ombredanne, Sunil Goutham
In-Reply-To: <20171211233220.d72rys7nci4lqqd5@localhost>
On 12.12.2017 05:32, Richard Cochran wrote:
> On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote:
>> diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
>> index 4a02e618e318..204b234beb9d 100644
>> --- a/drivers/net/ethernet/cavium/thunder/nic.h
>> +++ b/drivers/net/ethernet/cavium/thunder/nic.h
>> @@ -263,6 +263,8 @@ struct nicvf_drv_stats {
>> struct u64_stats_sync syncp;
>> };
>>
>> +struct cavium_ptp;
>> +
>> struct nicvf {
>> struct nicvf *pnicvf;
>> struct net_device *netdev;
>> @@ -312,6 +314,12 @@ struct nicvf {
>> struct tasklet_struct qs_err_task;
>> struct work_struct reset_task;
>>
>> + /* PTP timestamp */
>> + struct cavium_ptp *ptp_clock;
>> + bool hw_rx_tstamp;
>> + struct sk_buff *ptp_skb;
>> + atomic_t tx_ptp_skbs;
>
> It is disturbing that the above two fields are set in different
> places. Shouldn't they be unified into one logical lock?
No, they should not as they are not quite related.
`tx_ptp_skbs` is set when the hardware is sending a packet that requires
timestamping. Cavium hardware can not process more than one
such packet at once so this is set each time the driver submits
a packet that requires timestamping to the send queue and clears
each time it receives the entry on the completion queue saying
that such packet was sent.
So `tx_ptp_skbs` prevents driver from submitting more than one
packet that requires timestamping to the hardware for transmitting.
When that packet is sent, hardware inserts two entries to
the completion queue. First is the regular CQE_TYPE_SEND entry
that signals that the packet was sent. The second is CQE_TYPE_SEND_PTP
that contains the actual timestamp for that packet.
`ptp_skb` is initialized in the handler for the CQE_TYPE_SEND
entry and is used and zeroed in the handler for the CQE_TYPE_SEND_PTP
entry.
So `ptp_skb` is used to hold the pointer to the packet between
the calls to CQE_TYPE_SEND and CQE_TYPE_SEND_PTP handlers.
I am going to add those comments to the sources, fix other issues and
send v6 in short time.
Thank you
Aleksey Makarov
> Here you clear them together:
>
>> +static void nicvf_snd_ptp_handler(struct net_device *netdev,
>> + struct cqe_send_t *cqe_tx)
>> +{
>> + struct nicvf *nic = netdev_priv(netdev);
>> + struct skb_shared_hwtstamps ts;
>> + u64 ns;
>> +
>> + nic = nic->pnicvf;
>> +
>> + /* Sync for 'ptp_skb' */
>> + smp_rmb();
>> +
>> + /* New timestamp request can be queued now */
>> + atomic_set(&nic->tx_ptp_skbs, 0);
>> +
>> + /* Check for timestamp requested skb */
>> + if (!nic->ptp_skb)
>> + return;
>> +
>> + /* Check if timestamping is timedout, which is set to 10us */
>> + if (cqe_tx->send_status == CQ_TX_ERROP_TSTMP_TIMEOUT ||
>> + cqe_tx->send_status == CQ_TX_ERROP_TSTMP_CONFLICT)
>> + goto no_tstamp;
>> +
>> + /* Get the timestamp */
>> + memset(&ts, 0, sizeof(ts));
>> + ns = cavium_ptp_tstamp2time(nic->ptp_clock, cqe_tx->ptp_timestamp);
>> + ts.hwtstamp = ns_to_ktime(ns);
>> + skb_tstamp_tx(nic->ptp_skb, &ts);
>> +
>> +no_tstamp:
>> + /* Free the original skb */
>> + dev_kfree_skb_any(nic->ptp_skb);
>> + nic->ptp_skb = NULL;
>> + /* Sync 'ptp_skb' */
>> + smp_wmb();
>> +}
>> +
>
> but here you set the one:
>
>> @@ -657,7 +697,12 @@ static void nicvf_snd_pkt_handler(struct net_device *netdev,
>> prefetch(skb);
>> (*tx_pkts)++;
>> *tx_bytes += skb->len;
>> - napi_consume_skb(skb, budget);
>> + /* If timestamp is requested for this skb, don't free it */
>> + if (skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS &&
>> + !nic->pnicvf->ptp_skb)
>> + nic->pnicvf->ptp_skb = skb;
>> + else
>> + napi_consume_skb(skb, budget);
>> sq->skbuff[cqe_tx->sqe_ptr] = (u64)NULL;
>> } else {
>> /* In case of SW TSO on 88xx, only last segment will have
>
> here you clear one:
>
>> @@ -1319,12 +1382,28 @@ int nicvf_stop(struct net_device *netdev)
>>
>> nicvf_free_cq_poll(nic);
>>
>> + /* Free any pending SKB saved to receive timestamp */
>> + if (nic->ptp_skb) {
>> + dev_kfree_skb_any(nic->ptp_skb);
>> + nic->ptp_skb = NULL;
>> + }
>> +
>> /* Clear multiqset info */
>> nic->pnicvf = nic;
>>
>> return 0;
>> }
>
> here you clear both:
>
>> @@ -1394,6 +1473,12 @@ int nicvf_open(struct net_device *netdev)
>> if (nic->sqs_mode)
>> nicvf_get_primary_vf_struct(nic);
>>
>> + /* Configure PTP timestamp */
>> + if (nic->ptp_clock)
>> + nicvf_config_hw_rx_tstamp(nic, nic->hw_rx_tstamp);
>> + atomic_set(&nic->tx_ptp_skbs, 0);
>> + nic->ptp_skb = NULL;
>> +
>> /* Configure receive side scaling and MTU */
>> if (!nic->sqs_mode) {
>> nicvf_rss_init(nic);
>
> here you set the other:
>
>> @@ -1385,6 +1388,29 @@ nicvf_sq_add_hdr_subdesc(struct nicvf *nic, struct snd_queue *sq, int qentry,
>> hdr->inner_l3_offset = skb_network_offset(skb) - 2;
>> this_cpu_inc(nic->pnicvf->drv_stats->tx_tso);
>> }
>> +
>> + /* Check if timestamp is requested */
>> + if (!(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
>> + skb_tx_timestamp(skb);
>> + return;
>> + }
>> +
>> + /* Tx timestamping not supported along with TSO, so ignore request */
>> + if (skb_shinfo(skb)->gso_size)
>> + return;
>> +
>> + /* HW supports only a single outstanding packet to timestamp */
>> + if (!atomic_add_unless(&nic->pnicvf->tx_ptp_skbs, 1, 1))
>> + return;
>> +
>> + /* Mark the SKB for later reference */
>> + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
>> +
>> + /* Finally enable timestamp generation
>> + * Since 'post_cqe' is also set, two CQEs will be posted
>> + * for this packet i.e CQE_TYPE_SEND and CQE_TYPE_SEND_PTP.
>> + */
>> + hdr->tstmp = 1;
>> }
>
> and so it is completely non-obvious whether this is race free or not.
>
> Thanks,
> Richard
>
^ permalink raw reply
* Aw: Re: Re: dvb usb issues since kernel 4.9
From: Josef Griebichler @ 2018-01-08 17:15 UTC (permalink / raw)
To: Alan Stern
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb,
Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa,
Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet,
LMML, Peter Zijlstra, David Miller, torvalds
In-Reply-To: <Pine.LNX.4.44L0.1801081130200.1908-100000@iolanthe.rowland.org>
No I can't sorry. There's no sat connection near to my workstation.
Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr
Von: "Alan Stern" <stern@rowland.harvard.edu>
An: "Josef Griebichler" <griebichler.josef@gmx.at>
Cc: "Mauro Carvalho Chehab" <mchehab@s-opensource.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, "Jesper Dangaard Brouer" <jbrouer@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org
Betreff: Re: Aw: Re: dvb usb issues since kernel 4.9
On Mon, 8 Jan 2018, Josef Griebichler wrote: > Hi Maro, > > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi[http://ix.io/DOi] > Errors during recording are still there. > Errors increase if there is additional tcp load on raspberry. > > Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Can you try running the same test on an x86_64 system? Alan Stern
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-08 17:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: Graeme Gregory, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20180108154243.GA30962@lunn.ch>
Hi Andrew,
2018-01-08 16:42 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> w> I am not familiar with MDIO, but if its similar or a specific
>> implementation of a serial bus that does sound sane!
>
Thanks for digging, I will check if and how we can use
GenericSerialBus with MDIO.
Best regards,
Marcin
> It is a two wire serial bus. A good overview can be found here:
>
> https://www.totalphase.com/support/articles/200349206-MDIO-Background
>
^ permalink raw reply
* Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share filter block instances
From: Marcelo Ricardo Leitner @ 2018-01-08 17:20 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, matanb, leonro,
idosch, jakub.kicinski, simon.horman, pieter.jansenvanvuuren,
john.hurley, alexander.h.duyck, ogerlitz, john.fastabend, daniel,
dsahern
In-Reply-To: <20180108154203.GF14494@nanopsycho>
On Mon, Jan 08, 2018 at 04:42:03PM +0100, Jiri Pirko wrote:
> Mon, Jan 08, 2018 at 04:23:06PM CET, marcelo.leitner@gmail.com wrote:
> >On Sat, Jan 06, 2018 at 12:09:18AM +0100, Jiri Pirko wrote:
> >...
> >> Note we cannot use the qdisc for filter manipulations for shared blocks:
> >>
> >> $ tc filter add dev ens8 ingress protocol ip pref 1 flower dst_ip 192.168.100.2 action drop
> >> Error: Cannot work with shared block, please use block index.
> >>
> >>
> >> We will see the same output if we list filters for ingress qdisc of
> >> ens7 and ens8, also for the block 22:
> >>
> >> $ tc filter show block 22
> >> filter block 22 protocol ip pref 25 flower chain 0
> >> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> >> ...
> >>
> >> $ tc filter show dev ens7 ingress
> >> filter block 22 protocol ip pref 25 flower chain 0
> >> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> >> ...
> >>
> >> $ tc filter show dev ens8 ingress
> >> filter block 22 protocol ip pref 25 flower chain 0
> >> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> >> ...
> >
> >If changing a rule on an interface and reflecting it on the other
> >is considered confusing, what about getting the stats including the
> >stats from the other interface? AFAICT that's what would happen in the
> >3 show commands above, they would show the same values.
>
> Yes. Same block, same values.
>
>
> >
> >Seems it can get confusing to the user: to check an interface, see
> >some hits on it, but they actually happened on the other interface.
>
> Okay, what do you suggest?
Only one idea so far: highlight somehow that 'block X' is shared in
there.
> Note that "filter show" uses dumpit.
Yes.
> Also note that each filter listed under qdisc ens7 ingress and
> dev ens8 ingress is very clearly marked with "block 22".
Yes but one listing the rules on ens7 doesn't know that "block 22"
is shared with other interface(s).
>
> Why is it confusing?
Pretty much the same reasoning as changing rules on it IMO, but:
- they may show hits that didn't happen on this interface
- they won't ever amount to the stats reported by the interface
itself, even if the user has some catch-all rule.
^ permalink raw reply
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-01-08 17:21 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: James Morris, LKML, Netdev, Kernel-hardening, Linux API,
Kees Cook, Eric W . Biederman, Eric Dumazet, David Miller,
Mahesh Bandewar
In-Reply-To: <20180108154733.GA29416@mail.hallyn.com>
On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting James Morris (james.l.morris@oracle.com):
>> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>>
>> > > Also, why do we need the concept of a controlled user-ns at all, if the
>> > > default whitelist maintains existing behavior?
>> >
>> > In past discussions two uses have been brought up:
>> >
>> > 1. if an 0-day is discovered which is exacerbated by a specific
>> > privilege in user namespaces, that privilege could be turned off until a
>> > reboot with a fixed kernel is scheduled, without fully disabling all
>> > containers.
>> >
>> > 2. some systems may be specifically designed to run software which
>> > only requires a few capabilities in a userns. In that case all others
>> > could be disabled.
>> >
>>
>> I meant in terms of "marking" a user ns as "controlled" type -- it's
>> unnecessary jargon from an end user point of view.
>
> Ah, yes, that was my point in
>
> http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
> and
> http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
>
>> This may happen internally but don't make it a special case with a
>> different name and don't bother users with internal concepts: simply
>> implement capability whitelists with the default having equivalent
>> behavior of everything allowed. Then, document the semantics of the
>> whitelist in terms of inheritance etc., as a feature of user namespaces,
>> not as a "type" of user namespace.
>
> The problem with making them inheritable is that an adversarial user
> can just create a user namespace at boot that sits and waits for an
> 0day to be published, then log in and attach to that namespace later,
> since it has already inherited the open whitelist.
>
> It feels like there must be some other approach that doesn't feel as...
> band-aid-y as this does, but I'm not sure what.
We had a long discussion thread about this approach in the past and
many of these points have been discussed there. Serge is to the point
in terms of both the points (0-day issue as well as sandbox
environment). At this moment we are exposed to those threats and apart
from this patch-set I'm not aware of anything that handles it. Of
course there are other alternatives that block user-ns creation
altogether but blocking user-ns is not a real solution that works in
every use-case. I'm open other ideas (if any) that do not block
creation of user-ns, but lack of those will keep the 0-day issue
lingering especially for environments where 'user-ns creation' is used
heavily.
'Controlled-user-ns' jargon is within the kernel-space and is not
exposed to the users (we don't have any API to do that), but I used
those terms to explain within the kernel-community what this patch-set
is trying to do. The user-application does not need nor need to know
any of these changes as such. However, this additional knob gives
admin an ability to control their behavior in those two circumstances.
The default behavior that chose in this patch-set is so that it
doesn't cause regression to anyone whatever is their use case is but
now admin can set whatever default behavior they wish in the
boot-scripts to suite their needs.
Thanks,
--mahesh..
^ permalink raw reply
* Re: brcmfmac: Use zeroing memory allocator than allocator/memset
From: Kalle Valo @ 2018-01-08 17:23 UTC (permalink / raw)
To: Himanshu Jha
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, linux-kernel, mcgrof, Himanshu Jha
In-Reply-To: <1514649113-7366-1-git-send-email-himanshujha199640@gmail.com>
Himanshu Jha <himanshujha199640@gmail.com> wrote:
> Use dma_zalloc_coherent for allocating zeroed
> memory and remove unnecessary memset function.
>
> Done using Coccinelle.
> Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
> 0-day tested with no failures.
>
> Suggested-by: Luis R. Rodriguez <mcgrof@kernel.org>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Failed to apply:
fatal: corrupt patch at line 29
error: could not build fake ancestor
Applying: brcmfmac: Use zeroing memory allocator than allocator/memset
Patch failed at 0001 brcmfmac: Use zeroing memory allocator than allocator/memset
The copy of the patch that failed is found in: .git/rebase-apply/patch
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10137819/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC] memdup_user() and friends
From: Andy Shevchenko @ 2018-01-08 17:26 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, Linux Kernel Mailing List, Linux FS Devel, netdev
In-Reply-To: <20180107021651.GB13338@ZenIV.linux.org.uk>
On Sun, Jan 7, 2018 at 4:16 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> What I propose is
> * switch memdup_user() to GFP_USER
> * add vmemdup_user(), using kvmalloc() instead of kmalloc() (also with
> GFP_USER)
Perhaps kvmemdup_user() for sake of consistency?
> * switch open-coded instances of the latter to calling it
> * switch some of the memdup_user() callers to vmemdup_user() - the ones that
> don't need physically contiguous copy and might be larger than a couple of pages.
> * add apriori bounds on size in the call sites that do not have those yet -
> that'll require comments from maintainers of the code in question in some cases.
>
> Objections?
Not at all!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
From: Lorenzo Bianconi @ 2018-01-08 17:27 UTC (permalink / raw)
To: Guillaume Nault; +Cc: James Chapman, David S. Miller, netdev, Hangbin Liu
In-Reply-To: <20180103163525.GF1402@alphalink.fr>
> On Wed, Jan 03, 2018 at 04:06:28PM +0100, Lorenzo Bianconi wrote:
>> I agree to remove offset parameter in this case. What about (as
>> already suggested by James) to take into account possible alignment
>> issues with previous version of L2TPv3 protocol using 'L2 specific
>> sublayer'?
>>
> I think James was refering to the general architecture of L2TPv3, where
> such issues should be handled by pseudo-wire specific headers. I don't
> think he was talking about implementing arbitrary padding using an
> L2 specific sublayer. None of the standardised headers allow arbitrary
> padding. And implementing our own would make us imcompatible with any
> other implementation.
>
>> I guess, on the kernel side (we will need to patch iproute2 on
>> userspace side), we need just to properly initialized the 'l2specific'
>> field to 0 since otherwise we will have the same memleak issue there
>> if assume we can have l2specific_len != {0,4}.
>>
> That would produce the same frame format as what the 'offset' option
> was supposed to produce (if it did properly initialise its padding
> bits). That is, we'd have an arbitrary number of padding bits inserted
> between the l2-specific header and the l2 frame (L2TP's payload). These
> frames are invalid, and doing that brings us nothing compared to
> keeping the offset option.
>
>> Moreover does it worth to add some sanity checks in netlink code to
>> enforce the relation between l2specific_len and l2specific_type?
>>
> Yes, certainly.
>
>> At
>> the moment there are no guarantee that if l2specific_type is set to
>> L2TP_L2SPECTYPE_DEFAULT, l2specific_len will be grater or equal than
>> 4.
>>
> Thanks for pointing this out. That needs to be fixed. We don't support
> anything but the default l2spec layer (or no l2spec layer at all). So
> we should only accept L2TP_L2SPECTYPE_NONE and L2TP_L2SPECTYPE_DEFAULT.
>
> And we shouldn't need to use l2specific_len at all. The default l2spec
> header is always four bytes long, so we don't need to rely on a user
> supplied value. Looking at the code, it seems that invalid usage of
> L2TP_ATTR_L2SPEC_LEN allows leaking memory on the network or sending
> corrupted frames (depending on if its value is too small or too big).
>
> Do you want to take care of this?
Ack, I am working on it.
Regards,
Lorenzo
^ permalink raw reply
* Re: mt76: fix memcpy to potential null pointer on failed allocation
From: Kalle Valo @ 2018-01-08 17:28 UTC (permalink / raw)
To: Colin Ian King
Cc: Matthias Brugger, Lorenzo Bianconi, Felix Fietkau, linux-wireless,
netdev, linux-arm-kernel, linux-mediatek, kernel-janitors,
linux-kernel
In-Reply-To: <20171214101322.10178-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently if the allocation of skb fails and returns NULL then the
> call to skb_put will cause a null pointer dereference. Fix this by
> checking for a null skb and returning NULL. Note that calls to
> function mt76x2_mcu_msg_alloc don't directly check the null return
> but instead pass the NULL pointer to mt76x2_mcu_msg_send which
> checks for the NULL and returns ENOMEM in this case.
>
> Detected by CoverityScan, CID#1462624 ("Dereference null return value")
>
> Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Felix Fietkau <nbd@nbd.name>
Patch applied to wireless-drivers-next.git, thanks.
364bea50dbea mt76: fix memcpy to potential null pointer on failed allocation
--
https://patchwork.kernel.org/patch/10111747/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mt76: fix memcpy to potential null pointer on failed allocation
From: Kalle Valo @ 2018-01-08 17:28 UTC (permalink / raw)
To: Colin Ian King
Cc: kernel-janitors, netdev, linux-wireless, linux-kernel,
Lorenzo Bianconi, linux-mediatek, Matthias Brugger,
linux-arm-kernel, Felix Fietkau
In-Reply-To: <20171214101322.10178-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently if the allocation of skb fails and returns NULL then the
> call to skb_put will cause a null pointer dereference. Fix this by
> checking for a null skb and returning NULL. Note that calls to
> function mt76x2_mcu_msg_alloc don't directly check the null return
> but instead pass the NULL pointer to mt76x2_mcu_msg_send which
> checks for the NULL and returns ENOMEM in this case.
>
> Detected by CoverityScan, CID#1462624 ("Dereference null return value")
>
> Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Felix Fietkau <nbd@nbd.name>
Patch applied to wireless-drivers-next.git, thanks.
364bea50dbea mt76: fix memcpy to potential null pointer on failed allocation
--
https://patchwork.kernel.org/patch/10111747/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix verifier GPF in kmalloc failure path
From: Daniel Borkmann @ 2018-01-08 17:33 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: netdev, kernel-team
In-Reply-To: <20180108155117.2203858-1-ast@kernel.org>
On 01/08/2018 04:51 PM, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@fb.com>
>
> syzbot reported the following panic in the verifier triggered
> by kmalloc error injection:
>
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> RIP: 0010:copy_func_state kernel/bpf/verifier.c:403 [inline]
> RIP: 0010:copy_verifier_state+0x364/0x590 kernel/bpf/verifier.c:431
> Call Trace:
> pop_stack+0x8c/0x270 kernel/bpf/verifier.c:449
> push_stack kernel/bpf/verifier.c:491 [inline]
> check_cond_jmp_op kernel/bpf/verifier.c:3598 [inline]
> do_check+0x4b60/0xa050 kernel/bpf/verifier.c:4731
> bpf_check+0x3296/0x58c0 kernel/bpf/verifier.c:5489
> bpf_prog_load+0xa2a/0x1b00 kernel/bpf/syscall.c:1198
> SYSC_bpf kernel/bpf/syscall.c:1807 [inline]
> SyS_bpf+0x1044/0x4420 kernel/bpf/syscall.c:1769
>
> when copy_verifier_state() aborts in the middle due to kmalloc failure
> some of the frames could have been partially copied while
> current free_verifier_state() loop
> for (i = 0; i <= state->curframe; i++)
> assumed that all frames are non-null.
> Simply fix it by adding 'if (!state)' to free_func_state().
> Also avoid stressing copy frame logic more if kzalloc fails
> in push_stack() free env->cur_state right away.
>
> Reported-by: syzbot+32ac5a3e473f2e01cfc7@syzkaller.appspotmail.com
> Reported-by: syzbot+fa99e24f3c29d269a7d5@syzkaller.appspotmail.com
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Applied to bpf-next with Fixes tags, thanks Alexei!
^ permalink raw reply
* Re: Aw: Re: Re: dvb usb issues since kernel 4.9
From: Alan Stern @ 2018-01-08 17:35 UTC (permalink / raw)
To: Josef Griebichler
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb,
Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa,
Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet,
LMML, Peter Zijlstra, David Miller, torvalds
In-Reply-To: <trinity-d42aadc3-e83a-4e22-9c98-011ab0bffcf3-1515431701061@3c-app-gmx-bs43>
On Mon, 8 Jan 2018, Josef Griebichler wrote:
> No I can't sorry. There's no sat connection near to my workstation.
Can we ask the person who made this post:
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965
to run the test? The post says that the testing was done on an x86_64
machine.
> Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr
> Von: "Alan Stern" <stern@rowland.harvard.edu>
> An: "Josef Griebichler" <griebichler.josef@gmx.at>
> Cc: "Mauro Carvalho Chehab" <mchehab@s-opensource.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, "Jesper Dangaard Brouer" <jbrouer@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org
> Betreff: Re: Aw: Re: dvb usb issues since kernel 4.9
> On Mon, 8 Jan 2018, Josef Griebichler wrote: > Hi Maro, > > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi[http://ix.io/DOi] > Errors during recording are still there. > Errors increase if there is additional tcp load on raspberry. > > Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Can you try running the same test on an x86_64 system? Alan Stern
It appears that you are using a non-standard kernel. The vanilla
kernel does not include any "dwc_otg_hcd" driver.
Alan Stern
^ permalink raw reply
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: David Miller @ 2018-01-08 17:36 UTC (permalink / raw)
To: mpe; +Cc: linux, michael, j, netdev, johannes, linuxppc-dev, johannes.berg
In-Reply-To: <874lnx2fqj.fsf@concordia.ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, 08 Jan 2018 14:26:12 +1100
> I don't see it in rc7, will it get to Linus sometime before the
> release?
I will do what I can to make sure it does, it is in my GIT tree.
^ permalink raw reply
* Re: wl1251: check return from call to wl1251_acx_arp_ip_filter
From: Kalle Valo @ 2018-01-08 17:41 UTC (permalink / raw)
To: Colin Ian King
Cc: Pavel Machek, Cong Wang, Johannes Berg, David S . Miller,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171226173318.5076-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently the less than zero error check on ret is incorrect
> as it is checking a far earlier ret assignment rather than the
> return from the call to wl1251_acx_arp_ip_filter. Fix this by
> adding in the missing assginment.
>
> Detected by CoverityScan, CID#1164835 ("Logically dead code")
>
> Fixes: 204cc5c44fb6 ("wl1251: implement hardware ARP filtering")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
ac1181c60822 wl1251: check return from call to wl1251_acx_arp_ip_filter
--
https://patchwork.kernel.org/patch/10133201/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Ingo Molnar @ 2018-01-08 17:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mauro Carvalho Chehab, Josef Griebichler, Greg Kroah-Hartman,
Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni,
Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel,
netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller
In-Reply-To: <CA+55aFzHPYuxg3LwhqcxwJD2fuKzg6wU5ypfMvrpRoioiQHDFg@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab
> <mchehab@s-opensource.com> wrote:
> >
> > Em Sat, 6 Jan 2018 16:04:16 +0100
> > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu:
> >>
> >> the causing commit has been identified.
> >> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882
> >> its working again.
> >
> > Just replying to me won't magically fix this. The ones that were involved on
> > this patch should also be c/c, plus USB people. Just added them.
>
> Actually, you seem to have added an odd subset of the people involved.
>
> For example, Ingo - who actually committed that patch - wasn't on the cc.
>
> I do think we need to simply revert that patch. It's very simple: it
> has been reported to lead to actual problems for people, and we don't
> fix one problem and then say "well, it fixed something else" when
> something breaks.
>
> When something breaks, we either unbreak it, or we revert the change
> that caused the breakage.
>
> It's really that simple. That's what "no regressions" means. We don't
> accept changes that cause regressions. This one did.
Yeah, absolutely - for the revert:
Acked-by: Ingo Molnar <mingo@kernel.org>
as I doubt we have enough time to root-case this properly.
Thanks,
Ingo
^ permalink raw reply
* [bpf-next PATCH 0/7] sockmap sample updates
From: John Fastabend @ 2018-01-08 18:04 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
The sockmap sample is pretty simple at the moment. All it does is open
a few sockets attach BPF programs/sockmaps and sends a few packets.
However, for testing and debugging I wanted to have more control over
the sendmsg format and data than provided by tools like iperf3/netperf,
etc. The reason is for testing BPF programs and stream parser it is
helpful to be able submit multiple sendmsg calls with different msg
layouts. For example lots of 1B iovs or a single large MB of data, etc.
Additionally, my current test setup requires an entire orchestration
layer (cilium) to run. As well as lighttpd and http traffic generators
or for kafka testing brokers and clients. This makes it a bit more
difficult when doing performance optimizations to incrementally test
small changes and come up with performance delta's and perf numbers.
By adding a few more options and an additional few tests the sockmap
sample program can show a more complete example and do some of the
above. Because the sample program is self contained it doesn't require
additional infrastructure to run either.
This series, although still fairly crude, does provide some nice
additions. They are
- a new sendmsg tests with a sender and recv threads
- a new base tests so we can get metrics/data without BPF
- multiple GBps of throughput on base and sendmsg tests
- automatically set rlimit and common variables
That said the UI is still primitive, more features could be added,
more tests might be useful, the reporting could be better, etc. But,
IMO lets push this now rather than sit on it for weeks until I get
time to do the above improvements.
---
John Fastabend (7):
bpf: refactor sockmap sample program update for arg parsing
bpf: add sendmsg option for testing BPF programs
bpf: sockmap sample, use fork() for send and recv
bpf: sockmap sample, report bytes/sec
bpf: sockmap sample add base test without any BPF for comparison
bpf: sockmap put client sockets in blocking mode
bpf: sockmap set rlimit
samples/sockmap/sockmap_user. | 0
samples/sockmap/sockmap_user.c | 354 +++++++++++++++++++++++++++++++++++-----
2 files changed, 314 insertions(+), 40 deletions(-)
create mode 100644 samples/sockmap/sockmap_user.
^ permalink raw reply
* [bpf-next PATCH 1/7] bpf: refactor sockmap sample program update for arg parsing
From: John Fastabend @ 2018-01-08 18:05 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
sockmap sample program takes arguments from cmd line but it reads them
in using offsets into the array. Because we want to add more arguments
in the future lets do proper argument handling.
Also refactor code to pull apart sock init and ping/pong test. This
allows us to add new tests in the future.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 142 +++++++++++++++++++++++++++++-----------
1 file changed, 103 insertions(+), 39 deletions(-)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 7cc9d22..5cbe7a5 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -35,6 +35,8 @@
#include <assert.h>
#include <libgen.h>
+#include <getopt.h>
+
#include "../bpf/bpf_load.h"
#include "../bpf/bpf_util.h"
#include "../bpf/libbpf.h"
@@ -46,15 +48,39 @@
#define S1_PORT 10000
#define S2_PORT 10001
-static int sockmap_test_sockets(int rate, int dot)
+/* global sockets */
+int s1, s2, c1, c2, p1, p2;
+
+static const struct option long_options[] = {
+ {"help", no_argument, NULL, 'h' },
+ {"cgroup", required_argument, NULL, 'c' },
+ {"rate", required_argument, NULL, 'r' },
+ {"verbose", no_argument, NULL, 'v' },
+ {0, 0, NULL, 0 }
+};
+
+static void usage(char *argv[])
+{
+ int i;
+
+ printf(" Usage: %s --cgroup <cgroup_path>\n", argv[0]);
+ printf(" options:\n");
+ for (i = 0; long_options[i].name != 0; i++) {
+ printf(" --%-12s", long_options[i].name);
+ if (long_options[i].flag != NULL)
+ printf(" flag (internal value:%d)\n",
+ *long_options[i].flag);
+ else
+ printf(" -%c\n", long_options[i].val);
+ }
+ printf("\n");
+}
+
+static int sockmap_init_sockets(void)
{
- int i, sc, err, max_fd, one = 1;
- int s1, s2, c1, c2, p1, p2;
+ int i, err, one = 1;
struct sockaddr_in addr;
- struct timeval timeout;
- char buf[1024] = {0};
int *fds[4] = {&s1, &s2, &c1, &c2};
- fd_set w;
s1 = s2 = p1 = p2 = c1 = c2 = 0;
@@ -134,6 +160,8 @@ static int sockmap_test_sockets(int rate, int dot)
if (err < 0 && errno != EINPROGRESS) {
perror("connect c2 failed()\n");
goto out;
+ } else if (err < 0) {
+ err = 0;
}
/* Accept Connecrtions */
@@ -149,23 +177,32 @@ static int sockmap_test_sockets(int rate, int dot)
goto out;
}
- max_fd = p2;
- timeout.tv_sec = 10;
- timeout.tv_usec = 0;
-
printf("connected sockets: c1 <-> p1, c2 <-> p2\n");
printf("cgroups binding: c1(%i) <-> s1(%i) - - - c2(%i) <-> s2(%i)\n",
c1, s1, c2, s2);
+out:
+ return err;
+}
+
+static int forever_ping_pong(int rate, int verbose)
+{
+ struct timeval timeout;
+ char buf[1024] = {0};
+ int sc;
+
+ timeout.tv_sec = 10;
+ timeout.tv_usec = 0;
/* Ping/Pong data from client to server */
sc = send(c1, buf, sizeof(buf), 0);
if (sc < 0) {
perror("send failed()\n");
- goto out;
+ return sc;
}
do {
- int s, rc, i;
+ int s, rc, i, max_fd = p2;
+ fd_set w;
/* FD sets */
FD_ZERO(&w);
@@ -193,7 +230,7 @@ static int sockmap_test_sockets(int rate, int dot)
if (rc < 0) {
if (errno != EWOULDBLOCK) {
perror("recv failed()\n");
- break;
+ return rc;
}
}
@@ -205,35 +242,60 @@ static int sockmap_test_sockets(int rate, int dot)
sc = send(i, buf, rc, 0);
if (sc < 0) {
perror("send failed()\n");
- break;
+ return sc;
}
}
- sleep(rate);
- if (dot) {
+
+ if (rate)
+ sleep(rate);
+
+ if (verbose) {
printf(".");
fflush(stdout);
}
} while (running);
-out:
- close(s1);
- close(s2);
- close(p1);
- close(p2);
- close(c1);
- close(c2);
- return err;
+ return 0;
}
int main(int argc, char **argv)
{
- int rate = 1, dot = 1;
+ int rate = 1, verbose = 0;
+ int opt, longindex, err, cg_fd = 0;
char filename[256];
- int err, cg_fd;
- char *cg_path;
- cg_path = argv[argc - 1];
+ while ((opt = getopt_long(argc, argv, "hvc:r:",
+ long_options, &longindex)) != -1) {
+ switch (opt) {
+ /* Cgroup configuration */
+ case 'c':
+ cg_fd = open(optarg, O_DIRECTORY, O_RDONLY);
+ if (cg_fd < 0) {
+ fprintf(stderr, "ERROR: (%i) open cg path failed: %s\n",
+ cg_fd, optarg);
+ return cg_fd;
+ }
+ break;
+ case 'r':
+ rate = atoi(optarg);
+ break;
+ case 'v':
+ verbose = 1;
+ break;
+ case 'h':
+ default:
+ usage(argv);
+ return -1;
+ }
+ }
+
+ if (!cg_fd) {
+ fprintf(stderr, "%s requires cgroup option: --cgroup <path>\n",
+ argv[0]);
+ return -1;
+ }
+
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
running = 1;
@@ -247,14 +309,6 @@ int main(int argc, char **argv)
return 1;
}
- /* Cgroup configuration */
- cg_fd = open(cg_path, O_DIRECTORY, O_RDONLY);
- if (cg_fd < 0) {
- fprintf(stderr, "ERROR: (%i) open cg path failed: %s\n",
- cg_fd, cg_path);
- return cg_fd;
- }
-
/* Attach programs to sockmap */
err = bpf_prog_attach(prog_fd[0], map_fd[0],
BPF_SK_SKB_STREAM_PARSER, 0);
@@ -280,15 +334,25 @@ int main(int argc, char **argv)
return err;
}
- err = sockmap_test_sockets(rate, dot);
+ err = sockmap_init_sockets();
if (err) {
fprintf(stderr, "ERROR: test socket failed: %d\n", err);
- return err;
+ goto out;
}
- return 0;
+
+ err = forever_ping_pong(rate, verbose);
+out:
+ close(s1);
+ close(s2);
+ close(p1);
+ close(p2);
+ close(c1);
+ close(c2);
+ return err;
}
void running_handler(int a)
{
running = 0;
+ printf("\n");
}
^ permalink raw reply related
* [bpf-next PATCH 2/7] bpf: add sendmsg option for testing BPF programs
From: John Fastabend @ 2018-01-08 18:05 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
When testing BPF programs using sockmap I often want to have more
control over how sendmsg is exercised. This becomes even more useful
as new sockmap program types are added.
This adds a test type option to select type of test to run. Currently,
only "ping" and "sendmsg" are supported, but more can be added as
needed.
The new help argument gives the following,
Usage: ./sockmap --cgroup <cgroup_path>
options:
--help -h
--cgroup -c
--rate -r
--verbose -v
--iov_count -i
--length -l
--test -t
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 143 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 140 insertions(+), 3 deletions(-)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 5cbe7a5..2d51672 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -56,6 +56,9 @@
{"cgroup", required_argument, NULL, 'c' },
{"rate", required_argument, NULL, 'r' },
{"verbose", no_argument, NULL, 'v' },
+ {"iov_count", required_argument, NULL, 'i' },
+ {"length", required_argument, NULL, 'l' },
+ {"test", required_argument, NULL, 't' },
{0, 0, NULL, 0 }
};
@@ -184,6 +187,113 @@ static int sockmap_init_sockets(void)
return err;
}
+struct msg_stats {
+ size_t bytes_sent;
+ size_t bytes_recvd;
+};
+
+static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
+ struct msg_stats *s, bool tx)
+{
+ struct msghdr msg = {0};
+ struct iovec *iov;
+ int i, flags = 0;
+
+ iov = calloc(iov_count, sizeof(struct iovec));
+ if (!iov)
+ return -ENOMEM;
+
+ for (i = 0; i < iov_count; i++) {
+ char *d = calloc(iov_length, sizeof(char));
+
+ if (!d) {
+ fprintf(stderr, "iov_count %i/%i OOM\n", i, iov_count);
+ free(iov);
+ return -ENOMEM;
+ }
+ iov[i].iov_base = d;
+ iov[i].iov_len = iov_length;
+ }
+
+ msg.msg_iov = iov;
+ msg.msg_iovlen = iov_count;
+
+ if (tx) {
+ for (i = 0; i < cnt; i++) {
+ int sent = sendmsg(fd, &msg, flags);
+
+ if (sent < 0) {
+ perror("send loop error:");
+ return sent;
+ }
+ s->bytes_sent += sent;
+ }
+ } else {
+ int slct, recv, max_fd = fd;
+ struct timeval timeout;
+ float total_bytes;
+ fd_set w;
+
+ total_bytes = (float)iov_count * (float)iov_length * (float)cnt;
+ while (s->bytes_recvd < total_bytes) {
+ timeout.tv_sec = 1;
+ timeout.tv_usec = 0;
+
+ /* FD sets */
+ FD_ZERO(&w);
+ FD_SET(fd, &w);
+
+ slct = select(max_fd + 1, &w, NULL, NULL, &timeout);
+ if (slct == -1) {
+ perror("select()");
+ return slct;
+ } else if (!slct) {
+ fprintf(stderr, "unexpected timeout\n");
+ return slct;
+ }
+
+ recv = recvmsg(fd, &msg, flags);
+ if (recv < 0) {
+ if (errno != EWOULDBLOCK) {
+ perror("recv failed()\n");
+ return errno;
+ }
+ }
+
+ s->bytes_recvd += recv;
+ }
+ }
+
+ for (i = 0; i < iov_count; i++)
+ free(iov[i].iov_base);
+ free(iov);
+ return 0;
+}
+
+static int sendmsg_test(int iov_count, int iov_buf, int cnt, int verbose)
+{
+ struct msg_stats s = {0};
+ int err;
+
+ err = msg_loop(c1, iov_count, iov_buf, cnt, &s, true);
+ if (err) {
+ fprintf(stderr,
+ "msg_loop_tx: iov_count %i iov_buf %i cnt %i err %i\n",
+ iov_count, iov_buf, cnt, err);
+ return err;
+ }
+
+ msg_loop(p2, iov_count, iov_buf, cnt, &s, false);
+ if (err)
+ fprintf(stderr,
+ "msg_loop_rx: iov_count %i iov_buf %i cnt %i err %i\n",
+ iov_count, iov_buf, cnt, err);
+
+ fprintf(stdout, "sendmsg: TX_bytes %zu RX_bytes %zu\n",
+ s.bytes_sent, s.bytes_recvd);
+ return err;
+}
+
static int forever_ping_pong(int rate, int verbose)
{
struct timeval timeout;
@@ -259,13 +369,19 @@ static int forever_ping_pong(int rate, int verbose)
return 0;
}
+enum {
+ PING_PONG,
+ SENDMSG,
+};
+
int main(int argc, char **argv)
{
- int rate = 1, verbose = 0;
+ int iov_count = 1, length = 1024, rate = 1, verbose = 0;
int opt, longindex, err, cg_fd = 0;
+ int test = PING_PONG;
char filename[256];
- while ((opt = getopt_long(argc, argv, "hvc:r:",
+ while ((opt = getopt_long(argc, argv, "hvc:r:i:l:t:",
long_options, &longindex)) != -1) {
switch (opt) {
/* Cgroup configuration */
@@ -283,6 +399,22 @@ int main(int argc, char **argv)
case 'v':
verbose = 1;
break;
+ case 'i':
+ iov_count = atoi(optarg);
+ break;
+ case 'l':
+ length = atoi(optarg);
+ break;
+ case 't':
+ if (memcmp(optarg, "ping", 4) == 0) {
+ test = PING_PONG;
+ } else if (memcmp(optarg, "sendmsg", 7) == 0) {
+ test = SENDMSG;
+ } else {
+ usage(argv);
+ return -1;
+ }
+ break;
case 'h':
default:
usage(argv);
@@ -340,7 +472,12 @@ int main(int argc, char **argv)
goto out;
}
- err = forever_ping_pong(rate, verbose);
+ if (test == PING_PONG)
+ err = forever_ping_pong(rate, verbose);
+ else if (test == SENDMSG)
+ err = sendmsg_test(iov_count, length, rate, verbose);
+ else
+ fprintf(stderr, "unknown test\n");
out:
close(s1);
close(s2);
^ permalink raw reply related
* [bpf-next PATCH 3/7] bpf: sockmap sample, use fork() for send and recv
From: John Fastabend @ 2018-01-08 18:05 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
Currently for SENDMSG tests first send completes then recv runs. This
does not work well for large data sizes and/or many iterations. So
fork the recv and send handler so that we run both send and recv. In
the future we can add a parameter to do more than a single fork of
tx/rx.
With this we can get many GBps of data which helps exercise the
sockmap code.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user. | 0
samples/sockmap/sockmap_user.c | 55 ++++++++++++++++++++++++++++------------
2 files changed, 39 insertions(+), 16 deletions(-)
create mode 100644 samples/sockmap/sockmap_user.
diff --git a/samples/sockmap/sockmap_user. b/samples/sockmap/sockmap_user.
new file mode 100644
index 0000000..e69de29
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 2d51672..4c83a1d 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -23,6 +23,7 @@
#include <stdbool.h>
#include <signal.h>
#include <fcntl.h>
+#include <sys/wait.h>
#include <sys/time.h>
#include <sys/types.h>
@@ -197,7 +198,7 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
{
struct msghdr msg = {0};
struct iovec *iov;
- int i, flags = 0;
+ int i, flags = MSG_NOSIGNAL;
iov = calloc(iov_count, sizeof(struct iovec));
if (!iov)
@@ -272,25 +273,47 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
static int sendmsg_test(int iov_count, int iov_buf, int cnt, int verbose)
{
+ int txpid, rxpid, err = 0;
struct msg_stats s = {0};
- int err;
-
- err = msg_loop(c1, iov_count, iov_buf, cnt, &s, true);
- if (err) {
- fprintf(stderr,
- "msg_loop_tx: iov_count %i iov_buf %i cnt %i err %i\n",
- iov_count, iov_buf, cnt, err);
- return err;
+ int status;
+
+ errno = 0;
+
+ rxpid = fork();
+ if (rxpid == 0) {
+ err = msg_loop(p2, iov_count, iov_buf, cnt, &s, false);
+ if (err)
+ fprintf(stderr,
+ "msg_loop_rx: iov_count %i iov_buf %i cnt %i err %i\n",
+ iov_count, iov_buf, cnt, err);
+ fprintf(stdout, "rx_sendmsg: TX_bytes %zu RX_bytes %zu\n",
+ s.bytes_sent, s.bytes_recvd);
+ exit(1);
+ } else if (rxpid == -1) {
+ perror("msg_loop_rx: ");
+ err = errno;
}
- msg_loop(p2, iov_count, iov_buf, cnt, &s, false);
- if (err)
- fprintf(stderr,
- "msg_loop_rx: iov_count %i iov_buf %i cnt %i err %i\n",
- iov_count, iov_buf, cnt, err);
+ txpid = fork();
+ if (txpid == 0) {
+ err = msg_loop(c1, iov_count, iov_buf, cnt, &s, true);
+ if (err)
+ fprintf(stderr,
+ "msg_loop_tx: iov_count %i iov_buf %i cnt %i err %i\n",
+ iov_count, iov_buf, cnt, err);
+ fprintf(stdout, "tx_sendmsg: TX_bytes %zu RX_bytes %zu\n",
+ s.bytes_sent, s.bytes_recvd);
+ exit(1);
+ } else if (txpid == -1) {
+ perror("msg_loop_tx: ");
+ return errno;
+ }
- fprintf(stdout, "sendmsg: TX_bytes %zu RX_bytes %zu\n",
- s.bytes_sent, s.bytes_recvd);
+ assert(waitpid(rxpid, &status, 0) == rxpid);
+ if (!txpid)
+ goto out;
+ assert(waitpid(txpid, &status, 0) == txpid);
+out:
return err;
}
^ permalink raw reply related
* [bpf-next PATCH 4/7] bpf: sockmap sample, report bytes/sec
From: John Fastabend @ 2018-01-08 18:05 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
Report bytes/sec sent as well as total bytes. Useful to get rough
idea how different configurations and usage patterns perform with
sockmap.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 37 ++++++++++++++++++++++++++++++++-----
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 4c83a1d..8329097 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -24,6 +24,7 @@
#include <signal.h>
#include <fcntl.h>
#include <sys/wait.h>
+#include <time.h>
#include <sys/time.h>
#include <sys/types.h>
@@ -191,14 +192,16 @@ static int sockmap_init_sockets(void)
struct msg_stats {
size_t bytes_sent;
size_t bytes_recvd;
+ struct timespec start;
+ struct timespec end;
};
static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
struct msg_stats *s, bool tx)
{
struct msghdr msg = {0};
+ int err, i, flags = MSG_NOSIGNAL;
struct iovec *iov;
- int i, flags = MSG_NOSIGNAL;
iov = calloc(iov_count, sizeof(struct iovec));
if (!iov)
@@ -220,6 +223,7 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
msg.msg_iovlen = iov_count;
if (tx) {
+ clock_gettime(CLOCK_MONOTONIC, &s->start);
for (i = 0; i < cnt; i++) {
int sent = sendmsg(fd, &msg, flags);
@@ -229,6 +233,7 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
}
s->bytes_sent += sent;
}
+ clock_gettime(CLOCK_MONOTONIC, &s->end);
} else {
int slct, recv, max_fd = fd;
struct timeval timeout;
@@ -236,6 +241,9 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
fd_set w;
total_bytes = (float)iov_count * (float)iov_length * (float)cnt;
+ err = clock_gettime(CLOCK_MONOTONIC, &s->start);
+ if (err < 0)
+ perror("recv start time: ");
while (s->bytes_recvd < total_bytes) {
timeout.tv_sec = 1;
timeout.tv_usec = 0;
@@ -247,15 +255,18 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
slct = select(max_fd + 1, &w, NULL, NULL, &timeout);
if (slct == -1) {
perror("select()");
+ clock_gettime(CLOCK_MONOTONIC, &s->end);
return slct;
} else if (!slct) {
fprintf(stderr, "unexpected timeout\n");
+ clock_gettime(CLOCK_MONOTONIC, &s->end);
return slct;
}
recv = recvmsg(fd, &msg, flags);
if (recv < 0) {
if (errno != EWOULDBLOCK) {
+ clock_gettime(CLOCK_MONOTONIC, &s->end);
perror("recv failed()\n");
return errno;
}
@@ -263,6 +274,7 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
s->bytes_recvd += recv;
}
+ clock_gettime(CLOCK_MONOTONIC, &s->end);
}
for (i = 0; i < iov_count; i++)
@@ -271,11 +283,14 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
return 0;
}
+static float giga = 1000000000;
+
static int sendmsg_test(int iov_count, int iov_buf, int cnt, int verbose)
{
int txpid, rxpid, err = 0;
struct msg_stats s = {0};
int status;
+ float sent_Bps = 0, recvd_Bps = 0;
errno = 0;
@@ -286,8 +301,14 @@ static int sendmsg_test(int iov_count, int iov_buf, int cnt, int verbose)
fprintf(stderr,
"msg_loop_rx: iov_count %i iov_buf %i cnt %i err %i\n",
iov_count, iov_buf, cnt, err);
- fprintf(stdout, "rx_sendmsg: TX_bytes %zu RX_bytes %zu\n",
- s.bytes_sent, s.bytes_recvd);
+ if (s.end.tv_sec - s.start.tv_sec) {
+ sent_Bps = s.bytes_sent / (s.end.tv_sec - s.start.tv_sec);
+ recvd_Bps = s.bytes_recvd / (s.end.tv_sec - s.start.tv_sec);
+ }
+ fprintf(stdout,
+ "rx_sendmsg: TX: %zuB %fB/s %fGB/s RX: %zuB %fB/s %fGB/s\n",
+ s.bytes_sent, sent_Bps, sent_Bps/giga,
+ s.bytes_recvd, recvd_Bps, recvd_Bps/giga);
exit(1);
} else if (rxpid == -1) {
perror("msg_loop_rx: ");
@@ -301,8 +322,14 @@ static int sendmsg_test(int iov_count, int iov_buf, int cnt, int verbose)
fprintf(stderr,
"msg_loop_tx: iov_count %i iov_buf %i cnt %i err %i\n",
iov_count, iov_buf, cnt, err);
- fprintf(stdout, "tx_sendmsg: TX_bytes %zu RX_bytes %zu\n",
- s.bytes_sent, s.bytes_recvd);
+ if (s.end.tv_sec - s.start.tv_sec) {
+ sent_Bps = s.bytes_sent / (s.end.tv_sec - s.start.tv_sec);
+ recvd_Bps = s.bytes_recvd / (s.end.tv_sec - s.start.tv_sec);
+ }
+ fprintf(stdout,
+ "tx_sendmsg: TX: %zuB %fB/s %f GB/s RX: %zuB %fB/s %fGB/s\n",
+ s.bytes_sent, sent_Bps, sent_Bps/giga,
+ s.bytes_recvd, recvd_Bps, recvd_Bps/giga);
exit(1);
} else if (txpid == -1) {
perror("msg_loop_tx: ");
^ permalink raw reply related
* [bpf-next PATCH 5/7] bpf: sockmap sample add base test without any BPF for comparison
From: John Fastabend @ 2018-01-08 18:06 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
Add a base test that does not use BPF hooks to test baseline case.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 8329097..bae85f8 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -285,18 +285,24 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
static float giga = 1000000000;
-static int sendmsg_test(int iov_count, int iov_buf, int cnt, int verbose)
+static int sendmsg_test(int iov_count, int iov_buf, int cnt,
+ int verbose, bool base)
{
- int txpid, rxpid, err = 0;
+ float sent_Bps = 0, recvd_Bps = 0;
+ int rx_fd, txpid, rxpid, err = 0;
struct msg_stats s = {0};
int status;
- float sent_Bps = 0, recvd_Bps = 0;
errno = 0;
+ if (base)
+ rx_fd = p1;
+ else
+ rx_fd = p2;
+
rxpid = fork();
if (rxpid == 0) {
- err = msg_loop(p2, iov_count, iov_buf, cnt, &s, false);
+ err = msg_loop(rx_fd, iov_count, iov_buf, cnt, &s, false);
if (err)
fprintf(stderr,
"msg_loop_rx: iov_count %i iov_buf %i cnt %i err %i\n",
@@ -422,6 +428,7 @@ static int forever_ping_pong(int rate, int verbose)
enum {
PING_PONG,
SENDMSG,
+ BASE,
};
int main(int argc, char **argv)
@@ -460,6 +467,8 @@ int main(int argc, char **argv)
test = PING_PONG;
} else if (memcmp(optarg, "sendmsg", 7) == 0) {
test = SENDMSG;
+ } else if (memcmp(optarg, "base", 4) == 0) {
+ test = BASE;
} else {
usage(argv);
return -1;
@@ -485,6 +494,10 @@ int main(int argc, char **argv)
/* catch SIGINT */
signal(SIGINT, running_handler);
+ /* If base test skip BPF setup */
+ if (test == BASE)
+ goto run;
+
if (load_bpf_file(filename)) {
fprintf(stderr, "load_bpf_file: (%s) %s\n",
filename, strerror(errno));
@@ -516,6 +529,7 @@ int main(int argc, char **argv)
return err;
}
+run:
err = sockmap_init_sockets();
if (err) {
fprintf(stderr, "ERROR: test socket failed: %d\n", err);
@@ -525,7 +539,9 @@ int main(int argc, char **argv)
if (test == PING_PONG)
err = forever_ping_pong(rate, verbose);
else if (test == SENDMSG)
- err = sendmsg_test(iov_count, length, rate, verbose);
+ err = sendmsg_test(iov_count, length, rate, verbose, false);
+ else if (test == BASE)
+ err = sendmsg_test(iov_count, length, rate, verbose, true);
else
fprintf(stderr, "unknown test\n");
out:
^ permalink raw reply related
* [bpf-next PATCH 6/7] bpf: sockmap put client sockets in blocking mode
From: John Fastabend @ 2018-01-08 18:06 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
Put client sockets in blocking mode otherwise with sendmsg tests
its easy to overrun the socket buffers which results in the test
being aborted.
The original non-blocking was added to handle listen/accept with
a single thread the client/accepted sockets do not need to be
non-blocking.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index bae85f8..0d8950f 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -110,7 +110,7 @@ static int sockmap_init_sockets(void)
}
/* Non-blocking sockets */
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < 2; i++) {
err = ioctl(*fds[i], FIONBIO, (char *)&one);
if (err < 0) {
perror("ioctl s1 failed()");
^ permalink raw reply related
* [bpf-next PATCH 7/7] bpf: sockmap set rlimit
From: John Fastabend @ 2018-01-08 18:06 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
Avoid extra step of setting limit from cmdline and do it directly in
the program.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 0d8950f..2afbefd 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -27,6 +27,7 @@
#include <time.h>
#include <sys/time.h>
+#include <sys/resource.h>
#include <sys/types.h>
#include <linux/netlink.h>
@@ -434,6 +435,7 @@ enum {
int main(int argc, char **argv)
{
int iov_count = 1, length = 1024, rate = 1, verbose = 0;
+ struct rlimit r = {10 * 1024 * 1024, RLIM_INFINITY};
int opt, longindex, err, cg_fd = 0;
int test = PING_PONG;
char filename[256];
@@ -487,6 +489,11 @@ int main(int argc, char **argv)
return -1;
}
+ if (setrlimit(RLIMIT_MEMLOCK, &r)) {
+ perror("setrlimit(RLIMIT_MEMLOCK)");
+ return 1;
+ }
+
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
running = 1;
^ 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