* Re: [RFC/PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4 version
From: Andre Naujoks @ 2018-08-28 9:36 UTC (permalink / raw)
To: netdev; +Cc: 吉藤英明, David S. Miller, yoshfuji
In-Reply-To: <CAPA1RqCtkYE8is=kbANNGktgoiqKHZy+0wtE-spUwgq4V-_XTw@mail.gmail.com>
On 5/8/18 1:48 PM, 吉藤英明 wrote:
> Hi,
>
> 2018-05-08 15:41 GMT+09:00 Andre Naujoks <nautsch2@gmail.com>:
>> On 08.05.2018 08:31, 吉藤英明 wrote:
>>> Hi,
>>>
>>> 2018-05-08 15:03 GMT+09:00 Andre Naujoks <nautsch2@gmail.com>:
>>>> On 11.04.2018 13:02, Andre Naujoks wrote:
>>>>> Hi.
>>>>
>>>> Hi again.
>>>>
>>>> Since it has been a month now, I'd like to send a little "ping" on this subject.
>>>>
>>>> Is anything wrong with this? Or was it just bad timing?
Hi.
Anything new about this? I still think, this is a very useful addition.
If this is not wanted/needed, then I'll stop pinging this topic.
Regards
Andre
>>>
>>> I'm just curious... What kind of behaviour do you expect?
>>>
>>> Unless you explicitly join the group, you cannot get traffic for the group
>>> because of multicast filtering at device level (multicast fitlering) or at the
>>> switch level (MLD).
>>>
>>> If an application is interested in (several) multicast groups, it should
>>> explicitly join the group. So I cannot find valid (or meaningful) use-case.
>>
>> I expect only to receive the multicast traffic of groups I explicitly joined on that
>> socket. This is was the IPv4 version of this socket option already does. The problem
>> only exists if multiple groups are joined and the socket therefore has to be bound
>> to the "any"-address. Then we get traffic from all multicast groups joined by any(!)
>> process on the system (plus anything else on that IP-port).
>
> Okay I agree that we should be able NOT to get such traffic.
>
> Acked-By: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> --yoshfuji
>
>>
>> Regards
>> Andre
>>
>>>
>>> --yoshfuji
>>>
>>>>
>>>> Regards
>>>> Andre
>>>>
>>>>>
>>>>> I was running into a problem, when trying to join multiple multicast groups
>>>>> on a single socket and thus binding to the any-address on said socket. I
>>>>> received traffic from multicast groups, I did not join on that socket and
>>>>> was at first surprised by that. After reading some old e-mails/threads,
>>>>> which came to the conclusion "It is, as it is."
>>>>> (e.g https://marc.info/?l=linux-kernel&m=115815686626791&w=2), I discovered
>>>>> the IPv4 socketoption IP_MULTICAST_ALL, which, when disabled, does exactly
>>>>> what I would expect from a socket by default.
>>>>>
>>>>> I propose a socket option for IPv6, which does the same and has the same
>>>>> default as the IPv4 version. My first thought was, to just apply
>>>>> IP_MULTICAST_ALL to a ipv6 socket, but that would change the behavior of
>>>>> current applications and would probably be a big no-no.
>>>>>
>>>>> Regards
>>>>> Andre
>>>>>
>>>>>
>>>>> From 473653086c05a3de839c3504885053f6254c7bc5 Mon Sep 17 00:00:00 2001
>>>>> From: Andre Naujoks <nautsch2@gmail.com>
>>>>> Date: Wed, 11 Apr 2018 12:38:28 +0200
>>>>> Subject: [PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4
>>>>> version
>>>>>
>>>>> The socket option will be enabled by default to ensure current behaviour
>>>>> is not changed. This is the same for the IPv4 version.
>>>>>
>>>>> A socket bound to in6addr_any and a specific port will receive all traffic
>>>>> on that port. Analogue to IP_MULTICAST_ALL, disable this behaviour, if
>>>>> one or more multicast groups were joined (using said socket) and only
>>>>> pass on multicast traffic from groups, which were explicitly joined via
>>>>> this socket.
>>>>>
>>>>> Without this option disabled a socket (system even) joined to multiple
>>>>> multicast groups is very hard to get right. Filtering by destination
>>>>> address has to take place in user space to avoid receiving multicast
>>>>> traffic from other multicast groups, which might have traffic on the same
>>>>> port.
>>>>>
>>>>> The extension of the IP_MULTICAST_ALL socketoption to just apply to ipv6,
>>>>> too, is not done to avoid changing the behaviour of current applications.
>>>>>
>>>>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
>>>>> ---
>>>>> include/linux/ipv6.h | 3 ++-
>>>>> include/uapi/linux/in6.h | 1 +
>>>>> net/ipv6/af_inet6.c | 1 +
>>>>> net/ipv6/ipv6_sockglue.c | 11 +++++++++++
>>>>> net/ipv6/mcast.c | 2 +-
>>>>> 5 files changed, 16 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
>>>>> index 8415bf1a9776..495e834c1367 100644
>>>>> --- a/include/linux/ipv6.h
>>>>> +++ b/include/linux/ipv6.h
>>>>> @@ -274,7 +274,8 @@ struct ipv6_pinfo {
>>>>> */
>>>>> dontfrag:1,
>>>>> autoflowlabel:1,
>>>>> - autoflowlabel_set:1;
>>>>> + autoflowlabel_set:1,
>>>>> + mc_all:1;
>>>>> __u8 min_hopcount;
>>>>> __u8 tclass;
>>>>> __be32 rcv_flowinfo;
>>>>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>>>>> index ed291e55f024..71d82fe15b03 100644
>>>>> --- a/include/uapi/linux/in6.h
>>>>> +++ b/include/uapi/linux/in6.h
>>>>> @@ -177,6 +177,7 @@ struct in6_flowlabel_req {
>>>>> #define IPV6_V6ONLY 26
>>>>> #define IPV6_JOIN_ANYCAST 27
>>>>> #define IPV6_LEAVE_ANYCAST 28
>>>>> +#define IPV6_MULTICAST_ALL 29
>>>>>
>>>>> /* IPV6_MTU_DISCOVER values */
>>>>> #define IPV6_PMTUDISC_DONT 0
>>>>> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
>>>>> index 8da0b513f188..7844cd9d2f10 100644
>>>>> --- a/net/ipv6/af_inet6.c
>>>>> +++ b/net/ipv6/af_inet6.c
>>>>> @@ -209,6 +209,7 @@ static int inet6_create(struct net *net, struct socket *sock, int protocol,
>>>>> np->hop_limit = -1;
>>>>> np->mcast_hops = IPV6_DEFAULT_MCASTHOPS;
>>>>> np->mc_loop = 1;
>>>>> + np->mc_all = 1;
>>>>> np->pmtudisc = IPV6_PMTUDISC_WANT;
>>>>> np->repflow = net->ipv6.sysctl.flowlabel_reflect;
>>>>> sk->sk_ipv6only = net->ipv6.sysctl.bindv6only;
>>>>> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
>>>>> index 4d780c7f0130..b2bc1942a2ee 100644
>>>>> --- a/net/ipv6/ipv6_sockglue.c
>>>>> +++ b/net/ipv6/ipv6_sockglue.c
>>>>> @@ -664,6 +664,13 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
>>>>> retv = ipv6_sock_ac_drop(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_acaddr);
>>>>> break;
>>>>> }
>>>>> + case IPV6_MULTICAST_ALL:
>>>>> + if (optlen < sizeof(int))
>>>>> + goto e_inval;
>>>>> + np->mc_all = valbool;
>>>>> + retv = 0;
>>>>> + break;
>>>>> +
>>>>> case MCAST_JOIN_GROUP:
>>>>> case MCAST_LEAVE_GROUP:
>>>>> {
>>>>> @@ -1255,6 +1262,10 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
>>>>> val = np->mcast_oif;
>>>>> break;
>>>>>
>>>>> + case IPV6_MULTICAST_ALL:
>>>>> + val = np->mc_all;
>>>>> + break;
>>>>> +
>>>>> case IPV6_UNICAST_IF:
>>>>> val = (__force int)htonl((__u32) np->ucast_oif);
>>>>> break;
>>>>> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
>>>>> index 793159d77d8a..623ad00eb3c2 100644
>>>>> --- a/net/ipv6/mcast.c
>>>>> +++ b/net/ipv6/mcast.c
>>>>> @@ -622,7 +622,7 @@ bool inet6_mc_check(struct sock *sk, const struct in6_addr *mc_addr,
>>>>> }
>>>>> if (!mc) {
>>>>> rcu_read_unlock();
>>>>> - return true;
>>>>> + return np->mc_all;
>>>>> }
>>>>> read_lock(&mc->sflock);
>>>>> psl = mc->sflist;
>>>>>
>>>>
>>
^ permalink raw reply
* Re: [PATCH 00/15] soc: octeontx2: Add RVU admin function driver
From: Sunil Kovvuri @ 2018-08-28 13:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: LKML, olof, LAKML, linux-soc, Sunil Goutham, Linux Netdev List,
David S. Miller
In-Reply-To: <CAK8P3a1xC6XjwDAmocpE5TZO7j6uVGtvBtWLPVcYwKqN6Z+seQ@mail.gmail.com>
On Tue, Aug 28, 2018 at 5:53 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote:
> >
> > From: Sunil Goutham <sgoutham@marvell.com>
> >
> > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports
> > multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs).
> > PF0 is called administrative / admin function (AF) and has privilege access
> > to registers to provision different RVU functional blocks to each of
> > PF/VF.
> >
> > This admin function (AF) driver acts as a configuration / administrative
> > software which provisions functional blocks to a PF/VF on demand for them
> > to work as one of the following
> > - A basic network controller (i.e NIC).
> > - NIC with packet filtering, shaping and scheduling capabilities.
> > - A crypto device.
> > - A combination of above etc.
> >
> > PF/VFs communicate with admin function via a shared memory region.
> > This patch series adds logic for the following
> > - RVU AF driver with functional blocks provisioning support
> > - Mailbox infrastructure for communication between AF and PFs.
> > - CGX driver which provides information about physcial network
> > interfaces which AF processes and forwards required info to
> > PF/VF drivers.
> >
> > This is the first set of patches out of 70 odd patches.
> >
> > Note: This driver neither receives any data nor processes it i.e no I/O,
> > just does the hardware configuration.
>
> Hi Sunil,
>
> Thanks for posting this first series, I'm glad we're seeing support for this
> chip family making some progress.
Thanks.
>
> My feeling overall is that we need a review from the network driver
> folks more than the arm-soc team etc, and that maybe the driver
> as a whole should go into drivers/net/ethernet.
This driver doesn't handle any network IO and moreever this driver has to handle
configuration requests from crypto driver as well. There will be
separate network and
crypto drivers which will be upstreamed into drivers/net/ethernet and
drivers/crypto.
And in future silicons there will be different types of functional
blocks which will be
added into this resource virtualization unit (RVU). Hence i thought
this driver is not a
right fit in drivers/net/ethernet.
>
> We support some couple of similar hardware already that has
> both support for virtual functions and for crypto offload, including
> the Chelsio cxgb4, Mellanox mlx5, NXP DPAA and probably others,
I agree, but i guess that is done to support inline crypto.
Here this driver has to handle requests from normal crypto driver
(drivers/crypto) as well.
> and we need to ensure that the exposed interfaces are all
> compatible, and that you use the correct subsystems and
> in-kernel abstractions for thing that are common.
>
> Arnd
^ permalink raw reply
* Re: [PATCH 04/15] soc: octeontx2: Add mailbox support infra
From: Sunil Kovvuri @ 2018-08-28 13:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: LKML, olof, LAKML, linux-soc, Aleksey Makarov, Sunil Goutham,
Lukasz Bartosik, Linux Netdev List, David S. Miller
In-Reply-To: <CAK8P3a1CvX1V8h20s_=XUUYfR-zYNwETg5p6dCtpVUqZ89K-tg@mail.gmail.com>
On Tue, Aug 28, 2018 at 6:22 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Aug 28, 2018 at 2:48 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> >
> > On Tue, Aug 28, 2018 at 5:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote:
> > > >
> > > > From: Aleksey Makarov <amakarov@marvell.com>
> > > >
> > > > This patch adds mailbox support infrastructure APIs.
> > > > Each RVU device has a dedicated 64KB mailbox region
> > > > shared with it's peer for communication. RVU AF has
> > > > a separate mailbox region shared with each of RVU PFs
> > > > and a RVU PF has a separate region shared with each of
> > > > it's VF.
> > > >
> > > > These set of APIs are used by this driver (RVU AF) and
> > > > other RVU PF/VF drivers eg netdev, crypto e.t.c.
> > > >
> > > > Signed-off-by: Aleksey Makarov <amakarov@marvell.com>
> > > > Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
> > > > Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com>
> > >
> > > Why does this driver not use the drivers/mailbox/ infrastructure?
> > >
> > This is a common administrative software driver which will be handling requests
> > from kernel drivers and as well as drivers in userspace applications.
> > We had to keep mailbox communication infrastructure same across all usages.
>
> Can you explain more about the usage of userspace applications
> and what interface you plan to use into the kernel?
Any PCI device here irrespective in what domain (kernel or userspace)
they are in
use common mailbox communication. Which is
# Write a mailbox msg (format is agreed between all parties) into
shared (between AF and other PF/VFs)
memory region and trigger a interrupt to admin function.
# Admin function processes the msg and puts reply in the same memory
region and trigger
IRQ to the requesting device. If the device has a driver instance
in kernel then it uses
IRQ and userspace applications does polling on the IRQ status bit.
>
> Do you things like AF_XDP and virtual machines, or something else?
I meant drivers in DPDK which may or may not use AF_XDP.
And yes if a PCI device is attached to a virtual machine then that
also uses the same mailbox communication.
Sunil.
>
> Arnd
^ permalink raw reply
* Re: [PATCH] mac80211: fix to follow standard
From: Sergei Shtylyov @ 2018-08-28 9:23 UTC (permalink / raw)
To: Yuan-Chi Pang, johannes; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1535423074-130862-1-git-send-email-fu3mo6goo@gmail.com>
Hello!
On 8/28/2018 5:24 AM, Yuan-Chi Pang wrote:
> IEEE 802.11-2016 14.10.8.3 HWMP sequence numbering says:
> If it is a target mesh STA, it shall update its own HWMP SN to
> maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1
> immediately before it generates a PREP element in response to a
> PREQ element.
>
> Signed-off-by: Yuan-Chi Pang <fu3mo6goo@gmail.com>
> ---
> net/mac80211/mesh_hwmp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
> index 35ad398..6c21a26 100644
> --- a/net/mac80211/mesh_hwmp.c
> +++ b/net/mac80211/mesh_hwmp.c
> @@ -572,6 +572,11 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
> forward = false;
> reply = true;
> target_metric = 0;
> +
> + if (SN_GT(target_sn, ifmsh->sn)) {
> + ifmsh->sn = target_sn;
> + }
No need for {} enclosing a single statement.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 04/15] soc: octeontx2: Add mailbox support infra
From: Arnd Bergmann @ 2018-08-28 12:52 UTC (permalink / raw)
To: Sunil Kovvuri
Cc: Linux Kernel Mailing List, Olof Johansson, Linux ARM, linux-soc,
amakarov, sgoutham, lbartosik, Networking, David Miller
In-Reply-To: <CA+sq2CeyQ8r7bj3vK=cfriif=HhUu36ZUPWqxXm1e0DktHG+Fg@mail.gmail.com>
On Tue, Aug 28, 2018 at 2:48 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
>
> On Tue, Aug 28, 2018 at 5:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote:
> > >
> > > From: Aleksey Makarov <amakarov@marvell.com>
> > >
> > > This patch adds mailbox support infrastructure APIs.
> > > Each RVU device has a dedicated 64KB mailbox region
> > > shared with it's peer for communication. RVU AF has
> > > a separate mailbox region shared with each of RVU PFs
> > > and a RVU PF has a separate region shared with each of
> > > it's VF.
> > >
> > > These set of APIs are used by this driver (RVU AF) and
> > > other RVU PF/VF drivers eg netdev, crypto e.t.c.
> > >
> > > Signed-off-by: Aleksey Makarov <amakarov@marvell.com>
> > > Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
> > > Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com>
> >
> > Why does this driver not use the drivers/mailbox/ infrastructure?
> >
> This is a common administrative software driver which will be handling requests
> from kernel drivers and as well as drivers in userspace applications.
> We had to keep mailbox communication infrastructure same across all usages.
Can you explain more about the usage of userspace applications
and what interface you plan to use into the kernel?
Do you things like AF_XDP and virtual machines, or something else?
Arnd
^ permalink raw reply
* Re: [PATCH net-next] Implement a rtnetlink device which simulates wifi.
From: Johannes Berg @ 2018-08-28 12:45 UTC (permalink / raw)
To: Cody Schuffelen, Kalle Valo, David S. Miller, linux-kernel,
linux-wireless, netdev, kernel-team
In-Reply-To: <5b5b8e09.1c69fb81.c693c.0acd@mx.google.com>
Hi Cody,
Sorry for the delay in reviewing this.
I think in general there may be some value in this.
I think you'd have a far better experience (and some more real wifi
testing) by adding the ability to route the hwsim virtual air/medium of
the inside of the VM to the outside of the VM, and then you could run
APs there and bridge to ethernet etc. That way, you could have far more
realistic WiFi with multiple APs etc. with not all that much effort.
Regarding the patch itself:
On Tue, 2018-07-24 at 17:10 -0700, Cody Schuffelen wrote:
> The device added here is used through "ip link add ... type virt_wifi"
Can you have a more elaborate example that includes how to specify the
ethernet link to use?
> +static struct ieee80211_channel channel = {
> + .band = NL80211_BAND_5GHZ,
You only have a single 5 GHz channel? That's pretty atypical - there are
no real devices that behave this way. I wouldn't be surprised if some
userspace assumes you have at least one 2.4 GHz channel, so I'd argue
you should have a more regular setup here.
> +static struct ieee80211_rate bitrate = {
> + .flags = IEEE80211_RATE_SHORT_PREAMBLE, /* ieee80211_rate_flags */
> + .bitrate = 1000,
err, well, you can't really have 10Mbps as a rate ... it doesn't exist.
Also, short preamble is irrelevant on 5 GHz.
Again, you should have a more regular setup here.
> +};
> +
> +static struct ieee80211_supported_band band_5ghz = {
> + .channels = &channel,
> + .bitrates = &bitrate,
> + .band = NL80211_BAND_5GHZ,
> + .n_channels = 1,
> + .n_bitrates = 1,
> +};
And probably best to support the normal 8 bitrates supported on 5GHz at
least?
Or perhaps put the whole thing on 2.4GHz since chips actually exist that
only have 2.4 (vs. none that only have 5), and support some HT/VHT even
to make it look like it's not out of the last millenium? :)
> +static struct cfg80211_inform_bss mock_inform_bss = {
> + /* ieee80211_channel* */ .chan = &channel,
> + /* nl80211_bss_scan_width */ .scan_width = NL80211_BSS_CHAN_WIDTH_20,
> + /* s32 */ .signal = 99,
That signal level is questionable ... better limit to something actually
used in practice like -60 dBm?
> +static u8 fake_router_bssid[] = {4, 4, 4, 4, 4, 4};
Well, use a locally assigned address at least if you're going to fake
something?
> + for (i = 0; i < request->n_ssids; i++) {
> + strncpy(request_ssid_copy, request->ssids[i].ssid,
> + request->ssids[i].ssid_len);
> + request_ssid_copy[request->ssids[i].ssid_len] = 0;
> + wiphy_debug(wiphy, "scan: ssid: %s\n",
> + request_ssid_copy);
SSIDs can very well contain NUL bytes, so this is not a valid way to
print them.
Why would you even want to print the request anyway though, if your
stated goal is to make it look to userspace like a wifi link, vs.
debugging?
Plus you can always run "iw event" to see it.
> + }
> + }
> +
> + priv->scan_request = request;
> + schedule_delayed_work(&priv->scan_result, HZ / 100);
That's way too fast, so for any realism you should probably wait 2-3
seconds. Well, you only have one channel, so perhaps only 100-200ms? But
10ms is not realistic.
> + return 0;
> +}
> +
> +static void virt_wifi_scan_result(struct work_struct *work)
> +{
> + struct virt_wifi_priv *priv =
> + container_of(work, struct virt_wifi_priv,
> + scan_result.work);
> + struct wiphy *wiphy = priv_to_wiphy(priv);
> + char ssid[] = "__VirtWifi";
> + struct cfg80211_bss *informed_bss;
> +
> + mock_inform_bss.boottime_ns = ktime_get_boot_ns();
Updating the static variable seems a bit weird, this could be concurrent
for different instances, afaict?
> +
> +static struct ieee80211_mgmt auth_mgmt_frame = {
> + .frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT
> + | IEEE80211_STYPE_AUTH),
more idiomatic kernel coding style would put the | at the end of the
first line
> + .duration = cpu_to_le16(1), /* ??? */
that's not quite a realistic duration, but I guess nobody cares
> + .u = {
> + .auth = {
> + .auth_alg = WLAN_AUTH_OPEN,
> + /* auth request has 1, auth response has 2 */
> + .auth_transaction = cpu_to_le16(2),
> + },
> + },
> +};
> +
> +static int virt_wifi_auth(struct wiphy *wiphy, struct net_device *dev,
> + struct cfg80211_auth_request *req)
> +{
> + wiphy_debug(wiphy, "auth\n");
> + memcpy(auth_mgmt_frame.da, dev->dev_addr, dev->addr_len);
> + memcpy(auth_mgmt_frame.sa, fake_router_bssid,
> + sizeof(fake_router_bssid));
> + memcpy(auth_mgmt_frame.bssid, fake_router_bssid,
> + sizeof(fake_router_bssid));
Well, I guess at the very least you should check you're connecting to
the right AP? Or maybe not, since you only fake one to exist in the
first place.
Same problem with globals being modified though.
> + /* Must call cfg80211_rx_mlme_mgmt to notify about the response to this.
> + * This must hold the mutex for the wedev while calling the function.
typo - wdev
> + * Luckily the nl80211 code invoking this already holds that mutex.
> + */
> + cfg80211_rx_mlme_mgmt(dev, (const u8 *)&auth_mgmt_frame,
> + sizeof(auth_mgmt_frame));
Some delay might be appropriate.
> + return 0;
> +}
> +
> +static struct ieee80211_mgmt assoc_mgmt_frame = {
> + .frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT
> + | IEEE80211_STYPE_ASSOC_RESP),
> + .duration = cpu_to_le16(1), /* ??? */
see above
> +static int virt_wifi_assoc(struct wiphy *wiphy, struct net_device *dev,
> + struct cfg80211_assoc_request *req)
> +{
> + wiphy_debug(wiphy, "assoc\n");
> + memcpy(assoc_mgmt_frame.da, dev->dev_addr, dev->addr_len);
see above
> + memcpy(assoc_mgmt_frame.sa, fake_router_bssid,
> + sizeof(fake_router_bssid));
> + memcpy(assoc_mgmt_frame.bssid, fake_router_bssid,
> + sizeof(fake_router_bssid));
> + /* Must call cfg80211_rx_assoc_resp to notify about the response to
> + * this. This must hold the mutex for the wedev while calling the
see above
> + * function. Luckily the nl80211 code invoking this already holds that
> + * mutex.
> + */
> + cfg80211_rx_assoc_resp(dev, req->bss, (const u8 *)&assoc_mgmt_frame,
> + sizeof(assoc_mgmt_frame), -1);
see above
(and this repeats for deauth and disassoc too)
> +static int virt_wifi_get_station(struct wiphy *wiphy, struct net_device *dev,
> + const u8 *mac, struct station_info *sinfo)
> +{
> + wiphy_debug(wiphy, "get_station\n");
> + /* Only the values used by netlink_utils.cpp. */
What's netlink_utils.cpp? :-)
More seriously though, if you're proposing a general addition, the
hidden Android reference isn't all that helpful.
> + sinfo->filled = BIT(NL80211_STA_INFO_TX_PACKETS) |
> + BIT(NL80211_STA_INFO_TX_FAILED) | BIT(NL80211_STA_INFO_SIGNAL) |
> + BIT(NL80211_STA_INFO_TX_BITRATE);
> + sinfo->tx_packets = 1;
> + sinfo->tx_failed = 0;
> + sinfo->signal = -1; /* -1 is the maximum signal strength, somehow. */
Yeah, well, -1 is like taking a jet engine next to your ear ... not
going to happen. Go with something reasonable instead, maybe -60?
> + sinfo->txrate = (struct rate_info) {
> + .legacy = 10000, /* units are 100kbit/s */
> + };
That's not realistic.
> + return 0;
> +}
> +
> +static const struct cfg80211_ops virt_wifi_cfg80211_ops = {
> + .scan = virt_wifi_scan,
> +
> + .auth = virt_wifi_auth,
> + .assoc = virt_wifi_assoc,
> + .deauth = virt_wifi_deauth,
> + .disassoc = virt_wifi_disassoc,
> +
> + .get_station = virt_wifi_get_station,
That seems a little *too* minimal, and too much at the same time...
Practially no drivers, apart from mac80211 ones, implement auth/assoc -
in particular not most chips used in Android. So connect/disconnect
instead of auth/assoc/deauth/disassoc might be more realistic.
On the other hand, if you have get_station you should probably have
dump_station so people can use tools other than Android.
> + /* 100 SSIDs should be enough for anyone! */
> + wiphy->max_scan_ssids = 101;
Well, typical implementations limit this to 4, or 20, so this is
certainly excessive.
> + /* Don't worry about frequency regulations. */
> + wiphy->regulatory_flags = REGULATORY_WIPHY_SELF_MANAGED;
> + wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> + BIT(NL80211_IFTYPE_AP) |
> + BIT(NL80211_IFTYPE_P2P_CLIENT) |
> + BIT(NL80211_IFTYPE_P2P_GO) |
> + BIT(NL80211_IFTYPE_ADHOC) |
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> + BIT(NL80211_IFTYPE_MONITOR);
You obviously only support NL80211_IFTYPE_STATION - the other modes
require many more ops to be implemented.
> + wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS |
> + WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
> + WIPHY_FLAG_AP_UAPSD |
> + WIPHY_FLAG_HAS_CHANNEL_SWITCH;
Nope, has none of these.
> + wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR |
> + NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE |
> + NL80211_FEATURE_STATIC_SMPS |
> + NL80211_FEATURE_DYNAMIC_SMPS |
> + NL80211_FEATURE_AP_SCAN |
> + NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
None of these either.
> +static netdev_tx_t virt_wifi_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct virt_wifi_netdev_priv *priv = netdev_priv(dev);
> +
> + skb->dev = priv->lowerdev;
> + return dev_queue_xmit(skb);
This really should only work while connected on "wifi".
> +static const struct net_device_ops wifi_vlan_ops = {
vlan?
> +/* Called under rcu_read_lock() from netif_receive_skb */
> +static rx_handler_result_t virt_wifi_rx_handler(struct sk_buff **pskb)
> +{
> + struct sk_buff *skb = *pskb;
> + struct virt_wifi_netdev_priv *priv =
> + rcu_dereference(skb->dev->rx_handler_data);
> +
> + /* macvlan uses GFP_ATOMIC here. */
so?
> + skb = skb_share_check(skb, GFP_ATOMIC);
> + if (!skb) {
> + dev_err(&priv->upperdev->dev, "can't skb_share_check\n");
> + return RX_HANDLER_CONSUMED;
> + }
> +
> + *pskb = skb;
> + skb->dev = priv->upperdev;
> + skb->pkt_type = PACKET_HOST;
> + return RX_HANDLER_ANOTHER;
> +}
I guess this should also only do something while connected.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix to follow standard
From: Kalle Valo @ 2018-08-28 12:44 UTC (permalink / raw)
To: Yuan-Chi Pang; +Cc: johannes, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1535423074-130862-1-git-send-email-fu3mo6goo@gmail.com>
Yuan-Chi Pang <fu3mo6goo@gmail.com> writes:
> IEEE 802.11-2016 14.10.8.3 HWMP sequence numbering says:
> If it is a target mesh STA, it shall update its own HWMP SN to
> maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1
> immediately before it generates a PREP element in response to a
> PREQ element.
>
> Signed-off-by: Yuan-Chi Pang <fu3mo6goo@gmail.com>
The patch title is quite generic, you could make it a bit more
informative and unique. For example:
mac80211: fix HWMP sequence numbering to follow standard
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/15] soc: octeontx2: Add RVU admin function driver
From: Arnd Bergmann @ 2018-08-28 12:23 UTC (permalink / raw)
To: Sunil Kovvuri
Cc: Linux Kernel Mailing List, Olof Johansson, Linux ARM, linux-soc,
sgoutham, Networking, David Miller
In-Reply-To: <1535453838-12154-1-git-send-email-sunil.kovvuri@gmail.com>
On Tue, Aug 28, 2018 at 12:57 PM <sunil.kovvuri@gmail.com> wrote:
>
> From: Sunil Goutham <sgoutham@marvell.com>
>
> Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports
> multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs).
> PF0 is called administrative / admin function (AF) and has privilege access
> to registers to provision different RVU functional blocks to each of
> PF/VF.
>
> This admin function (AF) driver acts as a configuration / administrative
> software which provisions functional blocks to a PF/VF on demand for them
> to work as one of the following
> - A basic network controller (i.e NIC).
> - NIC with packet filtering, shaping and scheduling capabilities.
> - A crypto device.
> - A combination of above etc.
>
> PF/VFs communicate with admin function via a shared memory region.
> This patch series adds logic for the following
> - RVU AF driver with functional blocks provisioning support
> - Mailbox infrastructure for communication between AF and PFs.
> - CGX driver which provides information about physcial network
> interfaces which AF processes and forwards required info to
> PF/VF drivers.
>
> This is the first set of patches out of 70 odd patches.
>
> Note: This driver neither receives any data nor processes it i.e no I/O,
> just does the hardware configuration.
Hi Sunil,
Thanks for posting this first series, I'm glad we're seeing support for this
chip family making some progress.
My feeling overall is that we need a review from the network driver
folks more than the arm-soc team etc, and that maybe the driver
as a whole should go into drivers/net/ethernet.
We support some couple of similar hardware already that has
both support for virtual functions and for crypto offload, including
the Chelsio cxgb4, Mellanox mlx5, NXP DPAA and probably others,
and we need to ensure that the exposed interfaces are all
compatible, and that you use the correct subsystems and
in-kernel abstractions for thing that are common.
Arnd
^ permalink raw reply
* Re: [PATCH] Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit"
From: Jose Abreu @ 2018-08-28 8:12 UTC (permalink / raw)
To: Jerome Brunet, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
netdev
Cc: linux-kernel, linux-amlogic, Joao Pinto, Vitor Soares,
Corentin Labbe
In-Reply-To: <20180824090440.13411-1-jbrunet@baylibre.com>
Hi Jerome,
On 24-08-2018 10:04, Jerome Brunet wrote:
> This reverts commit 4ae0169fd1b3c792b66be58995b7e6b629919ecf.
>
> This change in the handling of the coalesce timer is causing regression on
> (at least) amlogic platforms.
>
> Network will break down very quickly (a few seconds) after starting
> a download. This can easily be reproduced using iperf3 for example.
>
> The problem has been reported on the S805, S905, S912 and A113 SoCs
> (Realtek and Micrel PHYs) and it is likely impacting all Amlogics
> platforms using Gbit ethernet
>
> No problem was seen with the platform using 10/100 only PHYs (GXL internal)
>
> Reverting change brings things back to normal and allows to use network
> again until we better understand the problem with the coalesce timer.
>
>
Apologies for the delayed answer but I was in FTO.
I'm not sure what can be causing this but I have some questions
for you:
- What do you mean by "network will break down"? Do you see
queue timeout?
- What do you see in ethtool/ifconfig stats? Can you send me
the stats before and after network break?
- Is your setup multi-queue/channel?
- Can you point me to the DT bindings of your setup?
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH] specifically mention zero TX queues in error msg
From: Robert P. J. Day @ 2018-08-28 7:31 UTC (permalink / raw)
To: Linux kernel netdev mailing list
To be consistent with subsequent error message specifically mentioning
zero RX queues, add a reference to TX queues to the error message.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 325fc5088370..a5d0c2244fb5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8867,7 +8867,7 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
BUG_ON(strlen(name) >= sizeof(dev->name));
if (txqs < 1) {
- pr_err("alloc_netdev: Unable to allocate device with zero queues\n");
+ pr_err("alloc_netdev: Unable to allocate device with zero TX queues\n");
return NULL;
}
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply related
* [PATCH bpf-next] bpf: remove duplicated include from syscall.c
From: YueHaibing @ 2018-08-28 7:42 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: YueHaibing, netdev, kernel-janitors
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
kernel/bpf/syscall.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 8339d81..3c9636f 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -30,7 +30,6 @@
#include <linux/cred.h>
#include <linux/timekeeping.h>
#include <linux/ctype.h>
-#include <linux/btf.h>
#include <linux/nospec.h>
#define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY || \
^ permalink raw reply related
* Re: [PATCH] net: wireless: ath: Convert to using %pOFn instead of device_node.name
From: Kalle Valo @ 2018-08-28 11:19 UTC (permalink / raw)
To: Rob Herring; +Cc: linux-kernel, David S. Miller, linux-wireless, netdev
In-Reply-To: <20180828015252.28511-36-robh@kernel.org>
Rob Herring <robh@kernel.org> writes:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/net/wireless/ath/ath6kl/init.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
The correct prefix is "ath6kl:" but I can fix that.
--
Kalle Valo
^ permalink raw reply
* bpf-next is OPEN
From: Daniel Borkmann @ 2018-08-28 7:06 UTC (permalink / raw)
To: netdev; +Cc: ast
Merge window is over so new bpf-next development round begins.
Thanks,
Daniel
^ permalink raw reply
* Re: [bpf PATCH] bpf: sockmap, decrement copied count correctly in redirect error case
From: Daniel Borkmann @ 2018-08-28 7:04 UTC (permalink / raw)
To: John Fastabend, alexei.starovoitov; +Cc: netdev
In-Reply-To: <20180825003659.7508.52198.stgit@john-Precision-Tower-5810>
On 08/25/2018 02:37 AM, John Fastabend wrote:
> Currently, when a redirect occurs in sockmap and an error occurs in
> the redirect call we unwind the scatterlist once in the error path
> of bpf_tcp_sendmsg_do_redirect() and then again in sendmsg(). Then
> in the error path of sendmsg we decrement the copied count by the
> send size.
>
> However, its possible we partially sent data before the error was
> generated. This can happen if do_tcp_sendpages() partially sends the
> scatterlist before encountering a memory pressure error. If this
> happens we need to decrement the copied value (the value tracking
> how many bytes were actually sent to TCP stack) by the number of
> remaining bytes _not_ the entire send size. Otherwise we risk
> confusing userspace.
>
> Also we don't need two calls to free the scatterlist one is
> good enough. So remove the one in bpf_tcp_sendmsg_do_redirect() and
> then properly reduce copied by the number of remaining bytes which
> may in fact be the entire send size if no bytes were sent.
>
> To do this use bool to indicate if free_start_sg() should do mem
> accounting or not.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Applied to bpf, thanks John!
^ permalink raw reply
* Re: [PATCH v2 01/29] nvmem: add support for cell lookups
From: Srinivas Kandagatla @ 2018-08-28 10:15 UTC (permalink / raw)
To: Bartosz Golaszewski, Boris Brezillon
Cc: Andrew Lunn, linux-doc, Sekhar Nori, Bartosz Golaszewski,
linux-i2c, Mauro Carvalho Chehab, Rob Herring, Florian Fainelli,
Kevin Hilman, Richard Weinberger, Russell King, Marek Vasut,
Paolo Abeni, Dan Carpenter, Grygorii Strashko, David Lechner,
Arnd Bergmann, Sven Van Asbroeck, open list:MEMORY TECHNOLOGY...
In-Reply-To: <CAMRc=MfpZJUEAhM4OoLbmJcnX3rTJk8fvdiL6=9BjNkVcsf=SA@mail.gmail.com>
On 27/08/18 14:37, Bartosz Golaszewski wrote:
> I didn't notice it before but there's a global list of nvmem cells
Bit of history here.
The global list of nvmem_cell is to assist non device tree based cell
lookups. These cell entries come as part of the non-dt providers
nvmem_config.
All the device tree based cell lookup happen dynamically on
request/demand, and all the cell definition comes from DT.
As of today NVMEM supports both DT and non DT usecase, this is much simpler.
Non dt cases have various consumer usecases.
1> Consumer is aware of provider name and cell details.
This is probably simple usecase where it can just use device based apis.
2> Consumer is not aware of provider name, its just aware of cell name.
This is the case where global list of cells are used.
> with each cell referencing its owner nvmem device. I'm wondering if
> this isn't some kind of inversion of ownership. Shouldn't each nvmem
> device have a separate list of nvmem cells owned by it? What happens
This is mainly done for use case where consumer does not have idea of
provider name or any details.
First thing non dt user should do is use "NVMEM device based consumer APIs"
ex: First get handle to nvmem device using its nvmem provider name by
calling nvmem_device_get(); and use nvmem_device_cell_read/write() apis.
Also am not 100% sure how would maintaining cells list per nvmem
provider would help for the intended purpose of global list?
> if we have two nvmem providers with the same names for cells? I'm
Yes, it would return the first instance.. which is a known issue.
Am not really sure this is a big problem as of today! but am open for
any better suggestions!
> asking because dev_id based lookup doesn't make sense if internally
> nvmem_cell_get_from_list() doesn't care about any device names (takes
> only the cell_id as argument).
As I said this is for non DT usecase where consumers are not aware of
provider details.
>
> This doesn't cause any trouble now since there are no users defining
> cells in nvmem_config - there are only DT users - but this must be
> clarified before I can advance with correctly implementing nvmem
> lookups.
DT users should not be defining this to start with! It's redundant and
does not make sense!
>
> BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell
> instance even if the cell for this node was already added to the nvmem
> device.
I hope you got the reason why of_nvmem_cell_get() always allocates new
instance for every get!!
thanks,
srini
^ permalink raw reply
* Re: [PATCH RFT] net: dsa: Allow configuring CPU port VLANs
From: Ilias Apalodimas @ 2018-08-28 8:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Petr Machata, netdev, jiri, Andrew Lunn, Vivien Didelot,
David S. Miller, open list
In-Reply-To: <9ce291a4-b40d-81d8-1c1a-c4311e5cc113@gmail.com>
On Fri, Aug 10, 2018 at 04:58:10PM -0700, Florian Fainelli wrote:
> On 06/25/2018 02:17 AM, Ilias Apalodimas wrote:
> > On Mon, Jun 25, 2018 at 12:13:10PM +0300, Petr Machata wrote:
> >> Florian Fainelli <f.fainelli@gmail.com> writes:
> >>
> >>> if (netif_is_bridge_master(vlan->obj.orig_dev))
> >>> - return -EOPNOTSUPP;
> >>> + info.port = dp->cpu_dp->index;
> >>
> >> The condition above will trigger also when a VLAN is added on a member
> >> port, and there's no other port with that VLAN. In that case the VLAN
> >> comes without the BRIDGE_VLAN_INFO_BRENTRY flag. In mlxsw we have this
> >> to get the bridge VLANs:
> >>
> >> if (netif_is_bridge_master(orig_dev)) {
> >> [...]
> >> if ((vlan->flags & BRIDGE_VLAN_INFO_BRENTRY) &&
> >> [...]
> >>
> >> This doesn't appear to be done in DSA unless I'm missing something.
> > Petr's right. This will trigger for VLANs added on 'not cpu ports' if the VLAN
> > is not already a member.
> >
> > This command has BRIDGE_VLAN_INFO_BRENTRY set:
> > bridge vlan add dev br0 vid 100 pvid untagged self
> > I had the same issue on my CPSW RFC and solved it
> > exactly the same was as Petr suggested.
>
> Humm, there must be something obvious I am missing, but the following
> don't exactly result in what I would expect after adding a check for
> vlan->flags & BRIDGE_VLAN_INFO_BRENTRY:
>
> brctl addbr br0
> echo 1 > /sys/class/net/br0/bridge/vlan_filtering
> brctl addif br0 lan1
>
> #1 results in lan1 being programmed with VID 1, PVID, untagged, but not
> the CPU port. I would have sort of expected that the bridge layer would
> also push the configuration to br0/CPU port since this is the default VLAN:
>
> bridge vlan show dev br0
> port vlan ids
> br0 1 PVID Egress Untagged
>
> But it does not.
>
> bridge vlan add vid 2 dev lan1
>
> #2 same thing, results in only lan1 being programmed with VID 2, tagged
> but that is expected because we are creating the VLAN only for the
> user-facing port.
>
> bridge vlan add vid 3 dev br0 self
>
> #3 results in the CPU port being programmed with VID 3, tagged, again,
> this is expected because we are only programming the bridge master/CPU
> port here.
>
> Does #1 also happen for cpsw and mlxsw or do you actually get events
> about the bridge's default VLAN configuration? Or does the switch driver
> actually need to obtain that at the time the port is enslaved somehow?
As long as ports are attached you get the events (one event per attached port
iirc)
if the event is checked against BRIDGE_VLAN_INFO_BRENTRY, the only way to add a
VLAN to the cpu port is via 'bridge vlan add vid 3 dev br0 self'
>
> Thanks!
> --
> Florian
/Ilias
^ permalink raw reply
* Re: Oops running iptables -F OUTPUT
From: Nicholas Piggin @ 2018-08-28 4:06 UTC (permalink / raw)
To: Andreas Schwab
Cc: netdev, linuxppc-dev, Ard Biesheuvel, Jessica Yu,
Michael Ellerman, Will Deacon, Ingo Molnar, Andrew Morton,
linux-arch
In-Reply-To: <87bm9n68gq.fsf@igel.home>
On Mon, 27 Aug 2018 19:11:01 +0200
Andreas Schwab <schwab@linux-m68k.org> wrote:
> I'm getting this Oops when running iptables -F OUTPUT:
>
> [ 91.139409] Unable to handle kernel paging request for data at address 0xd0000001fff12f34
> [ 91.139414] Faulting instruction address: 0xd0000000016a5718
> [ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 91.139426] BE SMP NR_CPUS=2 PowerMac
> [ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpfilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_itu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod sata_svw
> [ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #1
> [ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c0000000006f560c
> [ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0-rc1)
> [ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR: 84002484 XER: 20000000
> [ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
> GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000000
> GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d05c8
> GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6fb8
> GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000000
> GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000000
> GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88990
> GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000000
> GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000000
> [ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x140 [ip_tables]
> [ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables]
> [ 91.139638] Call Trace:
> [ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables] (unreliable)
> [ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x110/0x2ec [ip_tables]
> [ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x68/0x88
> [ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xbc/0x128
> [ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x18/0x5c
> [ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getsockopt+0x2c/0x40
> [ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+0xa4/0xd0
> [ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketcall+0x238/0x2b4
> [ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0x70
> [ 91.139716] Instruction dump:
> [ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 419d000c 393e0060
> [ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 41e20010 7c210b78
> [ 91.139752] ---[ end trace f5d1d5431651845d ]---
This is due to 7290d58095 ("module: use relative references for
__ksymtab entries"). This part of kernel/module.c -
/* Divert to percpu allocation if a percpu var. */
if (sym[i].st_shndx == info->index.pcpu)
secbase = (unsigned long)mod_percpu(mod);
else
secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
sym[i].st_value += secbase;
Causes the distance to the target to exceed 32-bits on powerpc, so
it doesn't fit in a rel32 reloc. Not sure how other archs cope.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] tcp: another fix of uncloning packets before mangling them
From: Eric Dumazet @ 2018-08-28 7:36 UTC (permalink / raw)
To: wen.yang99
Cc: David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev, LKML,
jiang.biao2, zhong.weidong, liu.bo9
In-Reply-To: <1535441465-65170-1-git-send-email-wen.yang99@zte.com.cn>
On Tue, Aug 28, 2018 at 12:32 AM Wen Yang <wen.yang99@zte.com.cn> wrote:
>
> The following warning was caught：
>
> [937151.638394] Call Trace:
> [937151.638401] [<ffffffff8163f2f6>] dump_stack+0x19/0x1b
> [937151.638405] [<ffffffff8107dd70>] warn_slowpath_common+0x70/0xb0
> [937151.638407] [<ffffffff8107deba>] warn_slowpath_null+0x1a/0x20
> [937151.638410] [<ffffffff8158bb7b>] tcp_set_skb_tso_segs+0xeb/0x100
> [937151.638412] [<ffffffff8158bbc7>] tcp_init_tso_segs+0x37/0x50
> [937151.638414] [<ffffffff8158d7b9>] tcp_write_xmit+0x1d9/0xce0
> [937151.638417] [<ffffffff8158e53e>] __tcp_push_pending_frames+0x2e/0xc0
> [937151.638419] [<ffffffff8157cf3c>] tcp_push+0xec/0x120
> [937151.638421] [<ffffffff81580728>] tcp_sendmsg+0xc8/0xc20
> [937151.638424] [<ffffffff815aae24>] inet_sendmsg+0x64/0xb0
> [937151.638428] [<ffffffff810b9565>] ? check_preempt_curr+0x75/0xa0
> [937151.638434] [<ffffffff81519917>] sock_aio_write+0x157/0x180
> [937151.638437] [<ffffffff811e267d>] do_sync_write+0x8d/0xd0
> [937151.638440] [<ffffffff811e2f95>] vfs_write+0x1b5/0x1e0
> [937151.638442] [<ffffffff811e393f>] SyS_write+0x7f/0xe0
> [937151.638445] [<ffffffff816513fd>] system_call_fastpath+0x16/0x1b
>
> According commit c52e2421f736 ("tcp: must unclone packets before
> mangling them"), TCP stack should make sure it owns skbs before
> mangling them.
> And there is another place where skb_unclone() is needed. This patch
> fix that.
>
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> Tested-by: Liu Bo <liu.bo9@zte.com.cn>
> Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
> ---
> net/ipv4/tcp_output.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 597dbd7..fbe8140 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1793,6 +1793,9 @@ static int tcp_init_tso_segs(struct sk_buff *skb, unsigned int mss_now)
> int tso_segs = tcp_skb_pcount(skb);
>
Certainly not needed.
TCP stack owns its packets, as long they were never sent (not yet in
retransmit queue)
You probably are using an old kernel, missing some backport...
^ permalink raw reply
* [PATCH] tcp: another fix of uncloning packets before mangling them
From: Wen Yang @ 2018-08-28 7:31 UTC (permalink / raw)
To: edumazet, davem, kuznet, yoshfuji
Cc: netdev, linux-kernel, wen.yang99, jiang.biao2, zhong.weidong,
liu.bo9
The following warning was caught：
[937151.638394] Call Trace:
[937151.638401] [<ffffffff8163f2f6>] dump_stack+0x19/0x1b
[937151.638405] [<ffffffff8107dd70>] warn_slowpath_common+0x70/0xb0
[937151.638407] [<ffffffff8107deba>] warn_slowpath_null+0x1a/0x20
[937151.638410] [<ffffffff8158bb7b>] tcp_set_skb_tso_segs+0xeb/0x100
[937151.638412] [<ffffffff8158bbc7>] tcp_init_tso_segs+0x37/0x50
[937151.638414] [<ffffffff8158d7b9>] tcp_write_xmit+0x1d9/0xce0
[937151.638417] [<ffffffff8158e53e>] __tcp_push_pending_frames+0x2e/0xc0
[937151.638419] [<ffffffff8157cf3c>] tcp_push+0xec/0x120
[937151.638421] [<ffffffff81580728>] tcp_sendmsg+0xc8/0xc20
[937151.638424] [<ffffffff815aae24>] inet_sendmsg+0x64/0xb0
[937151.638428] [<ffffffff810b9565>] ? check_preempt_curr+0x75/0xa0
[937151.638434] [<ffffffff81519917>] sock_aio_write+0x157/0x180
[937151.638437] [<ffffffff811e267d>] do_sync_write+0x8d/0xd0
[937151.638440] [<ffffffff811e2f95>] vfs_write+0x1b5/0x1e0
[937151.638442] [<ffffffff811e393f>] SyS_write+0x7f/0xe0
[937151.638445] [<ffffffff816513fd>] system_call_fastpath+0x16/0x1b
According commit c52e2421f736 ("tcp: must unclone packets before
mangling them"), TCP stack should make sure it owns skbs before
mangling them.
And there is another place where skb_unclone() is needed. This patch
fix that.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Tested-by: Liu Bo <liu.bo9@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
---
net/ipv4/tcp_output.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 597dbd7..fbe8140 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1793,6 +1793,9 @@ static int tcp_init_tso_segs(struct sk_buff *skb, unsigned int mss_now)
int tso_segs = tcp_skb_pcount(skb);
if (!tso_segs || (tso_segs > 1 && tcp_skb_mss(skb) != mss_now)) {
+ if (skb_unclone(skb, GFP_ATOMIC))
+ return -ENOMEM;
+
tcp_set_skb_tso_segs(skb, mss_now);
tso_segs = tcp_skb_pcount(skb);
}
@@ -2045,6 +2048,7 @@ static int tcp_mtu_probe(struct sock *sk)
int copy, len;
int mss_now;
int interval;
+ int err;
/* Not currently probing/verifying,
* not in recovery,
@@ -2151,7 +2155,9 @@ static int tcp_mtu_probe(struct sock *sk)
if (len >= probe_size)
break;
}
- tcp_init_tso_segs(nskb, nskb->len);
+ err = tcp_init_tso_segs(nskb, nskb->len);
+ if (unlikely(err < 0))
+ return err;
/* We're ready to send. If this fails, the probe will
* be resegmented into mss-sized pieces by tcp_write_xmit().
@@ -2309,6 +2315,8 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
tso_segs = tcp_init_tso_segs(skb, mss_now);
BUG_ON(!tso_segs);
+ if (unlikely(tso_segs < 0))
+ break;
if (unlikely(tp->repair) && tp->repair_queue == TCP_SEND_QUEUE) {
/* "skb_mstamp" is used as a start point for the retransmit timer */
--
1.8.3.1
^ permalink raw reply related
* Re: bpfilter causes a leftover kernel process
From: Alexei Starovoitov @ 2018-08-28 3:35 UTC (permalink / raw)
To: Olivier Brunel; +Cc: netdev, daniel
In-Reply-To: <20180827183122.0b4ac65e@jjacky.com>
On Mon, Aug 27, 2018 at 06:31:22PM +0200, Olivier Brunel wrote:
>
> So the process is required, never ends and prevents umouting the
it's not required. It's not doing anything useful at the moment
and defaults to 'n' in kconfig. Please disable it your kernel.
> rootfs on shutdown. Unless I'm missing something, there's definitely a
> bug there?
I'm also running Arch Linux in my VM, but I'm not able to reproduce umount issue.
I'm guessing it's somehow related to non-static build and libc.so being busy
with old systemd.
Typical shutdown should have done:
[ 73.498022] shutdown[1]: Sending SIGTERM to remaining processes...
[ 73.505501] shutdown[1]: Sending SIGKILL to remaining processes...
[ 73.512783] shutdown[1]: Unmounting file systems.
And at the time of umount / no processes are alive other than systemd.
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH net-next v2 0/5] virtio: support packed ring
From: Jens Freimann @ 2018-08-28 5:51 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Tiwei Bie, jasowang, virtualization, linux-kernel, netdev,
virtio-dev, wexu
In-Reply-To: <20180827170005-mutt-send-email-mst@kernel.org>
On Mon, Aug 27, 2018 at 05:00:40PM +0300, Michael S. Tsirkin wrote:
>Are there still plans to test the performance with vost pmd?
>vhost doesn't seem to show a performance gain ...
Yes, I'm having trouble getting it to work with virtio PMD (it works
with Tiweis guest driver though), but I'm getting closer. Should only
be 1-2 more days.
regards,
Jens
^ permalink raw reply
* URGENT MATTER
From: Willmott Chambers @ 2018-08-28 1:05 UTC (permalink / raw)
Greetings,
I wrote to you before, but you did not answer my mail.
How are you today and your family? I hope you are fine! With due
respect, I am Attorney James Willmott, I sent you a letter last month,
but you did not get back to me with response.& I have an important
information about your heritage worth $5.5 million, which has been
entrusted to you by your late cousin, from your country. I seek your
consent to present you as the next of kin for the claim of this fund,
because the bank has mandated me to present to them the next of kin to
enable them start the legal process for the transfer of this fund to
your bank account.
Your prompt response will be appreciated for more details.
Sincerely,
James Willmott
^ permalink raw reply
* Re: BUG: corrupted list in p9_write_work
From: syzbot @ 2018-08-28 4:42 UTC (permalink / raw)
To: asmadeus, davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <0000000000002a2fdf0573107004@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 050cdc6c9501 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1386bce1400000
kernel config: https://syzkaller.appspot.com/x/.config?x=49927b422dcf0b29
dashboard link: https://syzkaller.appspot.com/bug?extid=1788bd5d4e051da6ec08
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1196b7ba400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1022391e400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1788bd5d4e051da6ec08@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
list_add corruption. prev->next should be next (ffff8801c5b17ab0), but was
ffff8801c5b17ac0. (prev=ffff8801a92d1b58).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:28!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 4.19.0-rc1+ #212
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
FS-Cache: Duplicate cookie detected
Workqueue: events p9_write_work
FS-Cache: O-cookie c=000000008e4eb276 [p=000000002fd7b0b4 fl=222 nc=0 na=1]
RIP: 0010:__list_add_valid.cold.0+0x23/0x25 lib/list_debug.c:26
Code: e8 4f 2b 5a fe eb 97 48 89 d9 48 c7 c7 60 b2 3a 87 e8 62 05 02 fe 0f
0b 48 89 f1 48 c7 c7 20 b3 3a 87 48 89 de e8 4e 05 02 fe <0f> 0b 4c 89 e2
48 89 de 48 c7 c7 60 b4 3a 87 e8 3a 05 02 fe 0f 0b
RSP: 0018:ffff8801d9f17590 EFLAGS: 00010282
FS-Cache: O-cookie d=0000000068a887e4 n=00000000257e8f2f
RAX: 0000000000000075 RBX: ffff8801c5b17ab0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8163ac01 RDI: 0000000000000001
RBP: ffff8801d9f175a8 R08: ffff8801d9f06340 R09: ffffed003b605010
FS-Cache: O-key=[10] '
R10: ffffed003b605010 R11: ffff8801db028087 R12: ffff8801a92d1b58
R13: ffff8801a92d1b58 R14: ffff8801c5b17b04 R15: ffff8801a92d1b58
FS: 0000000000000000(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
34
CR2: 00000000006dc138 CR3: 00000001c845c000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
32
Call Trace:
__list_add include/linux/list.h:60 [inline]
list_add_tail include/linux/list.h:93 [inline]
list_move_tail include/linux/list.h:183 [inline]
p9_write_work+0x34e/0xd50 net/9p/trans_fd.c:470
39
34
37
process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
38
31
36
31
39
'
FS-Cache: N-cookie c=00000000da38e585 [p=000000002fd7b0b4 fl=2 nc=0 na=1]
FS-Cache: N-cookie d=0000000068a887e4 n=000000005afa2e39
FS-Cache: N-key=[10] '
34
32
39
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
34
37
38
31
36
31
39
'
kthread+0x35a/0x420 kernel/kthread.c:246
FS-Cache: Duplicate cookie detected
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace c3e56d8d2cc1f8a2 ]---
FS-Cache: O-cookie c=000000008e4eb276 [p=000000002fd7b0b4 fl=222 nc=0 na=1]
RIP: 0010:__list_add_valid.cold.0+0x23/0x25 lib/list_debug.c:26
FS-Cache: O-cookie d=0000000068a887e4 n=00000000257e8f2f
Code: e8 4f 2b 5a fe eb 97 48 89 d9 48 c7 c7 60 b2 3a 87 e8 62 05 02 fe 0f
0b 48 89 f1 48 c7 c7 20 b3 3a 87 48 89 de e8 4e 05 02 fe <0f> 0b 4c 89 e2
48 89 de 48 c7 c7 60 b4 3a 87 e8 3a 05 02 fe 0f 0b
FS-Cache: O-key=[10] '
RSP: 0018:ffff8801d9f17590 EFLAGS: 00010282
34
32
RAX: 0000000000000075 RBX: ffff8801c5b17ab0 RCX: 0000000000000000
39
RDX: 0000000000000000 RSI: ffffffff8163ac01 RDI: 0000000000000001
34
RBP: ffff8801d9f175a8 R08: ffff8801d9f06340 R09: ffffed003b605010
37
R10: ffffed003b605010 R11: ffff8801db028087 R12: ffff8801a92d1b58
38
R13: ffff8801a92d1b58 R14: ffff8801c5b17b04 R15: ffff8801a92d1b58
31
FS: 0000000000000000(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
36
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
3139'
CR2: 00000000006dc138 CR3: 00000001c845c000 CR4: 00000000001406f0
FS-Cache: N-cookie c=00000000c3d88b67 [p=000000002fd7b0b4 fl=2 nc=0 na=1]
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
FS-Cache: N-cookie d=0000000068a887e4 n=00000000c137bf7f
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
FS-Cache: N-key=[10] '
^ permalink raw reply
* Re: WARNING in format_decode (2)
From: Alexei Starovoitov @ 2018-08-28 4:05 UTC (permalink / raw)
To: Steven Rostedt
Cc: syzbot, linux-kernel, mingo, syzkaller-bugs, Daniel Borkmann,
netdev
In-Reply-To: <20180827134626.1b943593@gandalf.local.home>
On Mon, Aug 27, 2018 at 01:46:26PM -0400, Steven Rostedt wrote:
> On Mon, 27 Aug 2018 10:10:04 -0700
> syzbot <syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com> wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 2ad0d5269970 Merge git://git.kernel.org/pub/scm/linux/kern..
> > git tree: net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15b8efba400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=79e695838ce7a210
> > dashboard link: https://syzkaller.appspot.com/bug?extid=1ec5c5ec949c4adaa0c4
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1626f761400000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com
> >
> > ** **
> > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> > **********************************************************
> > ------------[ cut here ]------------
> > Please remove unsupported %WARNING: CPU: 0 PID: 6453 at lib/vsprintf.c:2149 format_decode+0x8fc/0xaf0
> > lib/vsprintf.c:2149
> > Kernel panic - not syncing: panic_on_warn set ...
> >
> > CPU: 0 PID: 6453 Comm: syz-executor7 Not tainted 4.18.0+ #190
> > 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:993
> > RIP: 0010:format_decode+0x8fc/0xaf0 lib/vsprintf.c:2149
> > Code: e8 59 59 c9 fa 41 c6 04 24 12 e9 94 fd ff ff e8 4a 59 c9 fa 0f be f3
> > 48 c7 c7 60 bc 89 87 c6 05 28 aa d2 01 01 e8 e4 e9 93 fa <0f> 0b 4d 8b 7d
> > c0 e9 56 fe ff ff 48 8b bd 68 ff ff ff e8 cd 4f 08
> > RSP: 0018:ffff8801b6b27688 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: ffffffff816422b1 RDI: ffff8801b6b27378
> > RBP: ffff8801b6b27730 R08: ffff8801b69a0040 R09: 0000000000000006
> > R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b6b277a8
> > R13: ffff8801b6b27708 R14: 0000000000000000 R15: ffff8801b6b27b04
> > vsnprintf+0x185/0x1b60 lib/vsprintf.c:2245
> > vscnprintf+0x2d/0x80 lib/vsprintf.c:2396
> > __trace_array_vprintk.part.60+0xc7/0x330 kernel/trace/trace.c:2990
> > __trace_array_vprintk kernel/trace/trace.c:3021 [inline]
> > trace_array_vprintk kernel/trace/trace.c:3021 [inline]
> > trace_vprintk+0x5f/0x90 kernel/trace/trace.c:3059
> > __trace_printk+0xce/0x120 kernel/trace/trace_printk.c:237
> > ____bpf_trace_printk kernel/trace/bpf_trace.c:274 [inline]
>
> Looks like a bug in the bpf trace printk code.
yes. looks like %p% slipped past bpf_trace_printk() runtime checks.
^ permalink raw reply
* Re: GPL compliance issue with liquidio/lio_23xx_vsw.bin firmware
From: Felix Manlunas @ 2018-08-28 0:04 UTC (permalink / raw)
To: Florian Weimer
Cc: linux-firmware, netdev@vger.kernel.org, Derek Chickles,
Satanand Burla, Felix Manlunas, Raghu Vatsavayi, Manish Awasthi,
Manojkumar.Panicker
In-Reply-To: <13e96e81-8794-4d69-3df1-eb07a18655ac@redhat.com>
On Mon, Aug 27, 2018 at 05:01:10PM +0200, Florian Weimer wrote:
> liquidio/lio_23xx_vsw.bin contains a compiled MIPS Linux kernel:
>
> $ tail --bytes=+1313 liquidio/lio_23xx_vsw.bin > elf
> $ readelf -aW elf
> […]
> [ 6] __ksymtab PROGBITS ffffffff80e495f8 64a5f8 00d130
> 00 A 0 0 8
> [ 7] __ksymtab_gpl PROGBITS ffffffff80e56728 657728 008400
> 00 A 0 0 8
> [ 8] __ksymtab_strings PROGBITS ffffffff80e5eb28 65fb28 018868
> 00 A 0 0 1
> […]
> Symbol table '.symtab' contains 1349 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS
> arch/mips/kernel/head.o
> 2: 0000000000000000 0 FILE LOCAL DEFAULT ABS init/main.c
> 3: 0000000000000000 0 FILE LOCAL DEFAULT ABS
> include/linux/types.h
> […]
>
> Yet there is no corresponding source provided, and LICENCE.cavium lacks
> the required notices.
>
> Thanks,
> Florian
Cavium apologizes for the oversight. Cavium has been advertising the
appropriate license terms including the existence of GPL in the firmware
in our outbox releases. We will update the license terms in LICENCE.cavium
in our upstream contribution in collaboration with our legal team.
Felix
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox