* Re: [PATCH net] udp: fix rx queue len reported by diag and proc interface
From: David Miller @ 2018-06-08 23:56 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet, trevor.francis
In-Reply-To: <6189b60449cb3ab524db8e91acd6be8d01ba887c.1528450183.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 8 Jun 2018 11:35:40 +0200
> After commit 6b229cf77d68 ("udp: add batching to udp_rmem_release()")
> the sk_rmem_alloc field does not measure exactly anymore the
> receive queue length, because we batch the rmem release. The issue
> is really apparent only after commit 0d4a6608f68c ("udp: do rmem bulk
> free even if the rx sk queue is empty"): the user space can easily
> check for an empty socket with not-0 queue length reported by the 'ss'
> tool or the procfs interface.
>
> We need to use a custom UDP helper to report the correct queue length,
> taking into account the forward allocation deficit.
>
> Reported-by: trevor.francis@46labs.com
> Fixes: 6b229cf77d68 ("UDP: add batching to udp_rmem_release()")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net v2] net: bridge: Fix locking in br_fdb_find_port()
From: David Miller @ 2018-06-09 0:00 UTC (permalink / raw)
To: petrm; +Cc: bridge, netdev, stephen
In-Reply-To: <c41fffa00abb9a123039e5509886a0de85274291.1528450455.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Fri, 08 Jun 2018 15:11:47 +0200
> Callers of br_fdb_find() need to hold the hash lock, which
> br_fdb_find_port() doesn't do. However, since br_fdb_find_port() is not
> doing any actual FDB manipulation, the hash lock is not really needed at
> all. So convert to br_fdb_find_rcu(), surrounded by rcu_read_lock() /
> _unlock() pair.
>
> The device pointer copied from inside the FDB entry is then kept alive
> by the RTNL lock, which br_fdb_find_port() asserts.
>
> Fixes: 4d4fd36126d6 ("net: bridge: Publish bridge accessor functions")
> Signed-off-by: Petr Machata <petrm@mellanox.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Stephen Hemminger @ 2018-06-09 0:02 UTC (permalink / raw)
To: Siwei Liu
Cc: Michael S. Tsirkin, Jiri Pirko, kys, haiyangz, David Miller,
Samudrala, Sridhar, Netdev, Stephen Hemminger
In-Reply-To: <CADGSJ20sq8AmW34Z7w0JrTg6=YnKaM3Hq5R3TfhAH5BkuR2pqA@mail.gmail.com>
On Fri, 8 Jun 2018 16:44:12 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Fri, Jun 8, 2018 at 4:18 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Fri, 8 Jun 2018 15:25:59 -0700
> > Siwei Liu <loseweigh@gmail.com> wrote:
> >
> >> On Wed, Jun 6, 2018 at 2:24 PM, Stephen Hemminger
> >> <stephen@networkplumber.org> wrote:
> >> > On Wed, 6 Jun 2018 15:30:27 +0300
> >> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >
> >> >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> >> >> > Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> >> >> > >The net failover should be a simple library, not a virtual
> >> >> > >object with function callbacks (see callback hell).
> >> >> >
> >> >> > Why just a library? It should do a common things. I think it should be a
> >> >> > virtual object. Looks like your patch again splits the common
> >> >> > functionality into multiple drivers. That is kind of backwards attitude.
> >> >> > I don't get it. We should rather focus on fixing the mess the
> >> >> > introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> >> >> > model.
> >> >>
> >> >> So it seems that at least one benefit for netvsc would be better
> >> >> handling of renames.
> >> >>
> >> >> Question is how can this change to 3-netdev happen? Stephen is
> >> >> concerned about risk of breaking some userspace.
> >> >>
> >> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> >> >> address, and you said then "why not use existing network namespaces
> >> >> rather than inventing a new abstraction". So how about it then? Do you
> >> >> want to find a way to use namespaces to hide the PV device for netvsc
> >> >> compatibility?
> >> >>
> >> >
> >> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> >> > startups that all demand eth0 always be present. And VF may come and go.
> >> > After this history, there is a strong motivation not to change how kernel
> >> > behaves. Switching to 3 device model would be perceived as breaking
> >> > existing userspace.
> >> >
> >> > With virtio you can work it out with the distro's yourself.
> >> > There is no pre-existing semantics to deal with.
> >> >
> >> > For the virtio, I don't see the need for IFF_HIDDEN.
> >>
> >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of
> >> that flag, as well as the 1-netdev model, is to have a means to
> >> inherit the interface name from the VF, and to eliminate playing hacks
> >> around renaming devices, customizing udev rules and et al. Why
> >> inheriting VF's name important? To allow existing config/setup around
> >> VF continues to work across kernel feature upgrade. Most of network
> >> config files in all distros are based on interface names. Few are MAC
> >> address based but making lower slaves hidden would cover the rest. And
> >> most importantly, preserving the same level of user experience as
> >> using raw VF interface once getting all ndo_ops and ethtool_ops
> >> exposed. This is essential to realize transparent live migration that
> >> users dont have to learn and be aware of the undertaken.
> >
> > Inheriting the VF name will fail in the migration scenario.
> > It is perfectly reasonable to migrate a guest to another machine where
> > the VF PCI address is different. And since current udev/systemd model
> > is to base network device name off of PCI address, the device will change
> > name when guest is migrated.
> >
> The scenario of having VF on a different PCI address on post migration
> is essentially equal to plugging in a new NIC. Why it has to pair with
> the original PV? A sepearte PV device should be in place to pair the
> new VF.
The host only guarantees that the PV device will be on the same network.
It does not make any PCI guarantees. The way Windows works is to find
the device based on "serial number" which is an Hyper-V specific attribute
of PCI devices.
I considered naming off of serial number but that won't work for the
case where PV device is present first and VF arrives later. The serial
number is attribute of VF, not the PV which is there first.
Your ideas about having the PCI information of the VF form the name
of the failover device have the same problem. The PV device may
be the only one present on boot.
> > On Azure, the VF maybe removed (by host) at any time and then later
> > reattached. There is no guarantee that VF will show back up at
> > the same synthetic PCI address. It will likely have a different
> > PCI domain value.
>
> This is something QEMU can do and make sure the PCI address is
> consistent after migration.
>
> -Siwei
^ permalink raw reply
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Schmitz @ 2018-06-09 0:28 UTC (permalink / raw)
To: Michael Karcher
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher
In-Reply-To: <56235.87.122.27.167.1528450090.webmail@webmail.zedat.fu-berlin.de>
Hi Michael,
Am 08.06.2018 um 21:28 schrieb Michael Karcher:
> Let me add my 2 cents as main author of that code:
...
>
> actually, the the block_input / block_output functions were the reason I
> included the lib8390.c file. Except for xs100_write / xs100_read, they are
> a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
> anymore, but did not get around to improve it. I added a customization
> point to ax88796 for a custom block_input / block_output, because the 8390
> core already provides that customization point. What I really need is a
> customization point just for the 8390-remote-DMA-via-MMIO functions (i.e.
> xs100_write, xs100_read) instead of the whole block transfer core that
> also sets up the remote DMA engine and tries to re-initialize the card in
> case of unexplained problems.
OK, so essentially change
if (ei_local->word16) {
ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
if (count & 0x01)
buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
} else {
ioread8_rep(nic_base + NE_DATAPORT, buf, count);
}
to something like
if (ax->block_read) {
ax->block_read(dev, buf, count);
} else if (ei_local->word16) {
ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
if (count & 0x01)
buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
} else {
ioread8_rep(nic_base + NE_DATAPORT, buf, count);
}
and populate ax->block_read() and ax_block_write() from platform data,
instead of substituting ax_block_input() / ax_block_output() wholesale?
I must be missing something here.
> This should get rid of
> - xs100_block_output
> - xs100_block_input (which has the calls to ax_reset_8390 and
> ax_NS8390_init)
> - ax_reset_8390
> - and thus the include of lib8390.c (which should be included only by
> ax88796.c, not by xsurf100.c)
I've got an (untested) patch that just exports ax_NS8390_init() via the
ax_device struct, and gets rid of the lib8390.c include that way, but
the above solution would be a lot cleaner. Adds one test for
ax->block_read on the critical path but we already have the test for
ei_local->word16 there. May need rearranging the tests so the majority
of ax88796 users isn't impacted.
Anyway, your code, your call.
Cheers,
Michael
>
> Regards,
> Michael Karcher
>
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on RAWIP devices
From: Subash Abhinov Kasiviswanathan @ 2018-06-09 0:34 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: YOSHIFUJI Hideaki, David Miller, netdev, YOSHIFUJI Hideaki
In-Reply-To: <CAKD1Yr0uFPS5poYVPJe_LqFh1EVmepWoeEXyhuubSAU_VMBFuQ@mail.gmail.com>
> Actually, I think this is fine. RFC 7136 clarified this, and says:
>
> ======
> Thus, we can conclude that the value of the "u" bit in IIDs has no
> particular meaning. In the case of an IID created from a MAC
> address
> according to RFC 4291, its value is determined by the MAC address,
> but that is all.
> [...]
> Specifications of other forms of 64-bit IIDs MUST specify how all 64
> bits are set, but a generic semantic meaning for the "u" and "g"
> bits
> MUST NOT be defined. However, the method of generating IIDs for
> specific link types MAY define some local significance for certain
> bits.
>
> In all cases, the bits in an IID have no generic semantics; in other
> words, they have opaque values. In fact, the whole IID value MUST
> be
> viewed as an opaque bit string by third parties, except possibly in
> the local context.
> ======
>
> That said - we already have a way to form all-random IIDs:
> IN6_ADDR_GEN_MODE_RANDOM. Can't you just ensure that links of type
> ARPHRD_RAWIP always use IN6_ADDR_GEN_MODE_RANDOM? That might lead to
> less special-casing.
Hi Lorenzo
In v2 of this patchset, I used addrconf_ifid_ip6tnl() similar to
IP6 Tunnels / VTI6, so I didnt need that way of generating the IID.
addrconf_ifid_ip6tnl() also provides fixed IIDs during the lifetime of
the
net device while IN6_ADDR_GEN_MODE_RANDOM generates different addresses.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Siwei Liu @ 2018-06-09 0:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Michael S. Tsirkin, Jiri Pirko, kys, haiyangz, David Miller,
Samudrala, Sridhar, Netdev, Stephen Hemminger
In-Reply-To: <20180608170235.7f345b58@xeon-e3>
On Fri, Jun 8, 2018 at 5:02 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Fri, 8 Jun 2018 16:44:12 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
>> On Fri, Jun 8, 2018 at 4:18 PM, Stephen Hemminger
>> <stephen@networkplumber.org> wrote:
>> > On Fri, 8 Jun 2018 15:25:59 -0700
>> > Siwei Liu <loseweigh@gmail.com> wrote:
>> >
>> >> On Wed, Jun 6, 2018 at 2:24 PM, Stephen Hemminger
>> >> <stephen@networkplumber.org> wrote:
>> >> > On Wed, 6 Jun 2018 15:30:27 +0300
>> >> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >
>> >> >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
>> >> >> > Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
>> >> >> > >The net failover should be a simple library, not a virtual
>> >> >> > >object with function callbacks (see callback hell).
>> >> >> >
>> >> >> > Why just a library? It should do a common things. I think it should be a
>> >> >> > virtual object. Looks like your patch again splits the common
>> >> >> > functionality into multiple drivers. That is kind of backwards attitude.
>> >> >> > I don't get it. We should rather focus on fixing the mess the
>> >> >> > introduction of netvsc-bonding caused and switch netvsc to 3-netdev
>> >> >> > model.
>> >> >>
>> >> >> So it seems that at least one benefit for netvsc would be better
>> >> >> handling of renames.
>> >> >>
>> >> >> Question is how can this change to 3-netdev happen? Stephen is
>> >> >> concerned about risk of breaking some userspace.
>> >> >>
>> >> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
>> >> >> address, and you said then "why not use existing network namespaces
>> >> >> rather than inventing a new abstraction". So how about it then? Do you
>> >> >> want to find a way to use namespaces to hide the PV device for netvsc
>> >> >> compatibility?
>> >> >>
>> >> >
>> >> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
>> >> > startups that all demand eth0 always be present. And VF may come and go.
>> >> > After this history, there is a strong motivation not to change how kernel
>> >> > behaves. Switching to 3 device model would be perceived as breaking
>> >> > existing userspace.
>> >> >
>> >> > With virtio you can work it out with the distro's yourself.
>> >> > There is no pre-existing semantics to deal with.
>> >> >
>> >> > For the virtio, I don't see the need for IFF_HIDDEN.
>> >>
>> >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of
>> >> that flag, as well as the 1-netdev model, is to have a means to
>> >> inherit the interface name from the VF, and to eliminate playing hacks
>> >> around renaming devices, customizing udev rules and et al. Why
>> >> inheriting VF's name important? To allow existing config/setup around
>> >> VF continues to work across kernel feature upgrade. Most of network
>> >> config files in all distros are based on interface names. Few are MAC
>> >> address based but making lower slaves hidden would cover the rest. And
>> >> most importantly, preserving the same level of user experience as
>> >> using raw VF interface once getting all ndo_ops and ethtool_ops
>> >> exposed. This is essential to realize transparent live migration that
>> >> users dont have to learn and be aware of the undertaken.
>> >
>> > Inheriting the VF name will fail in the migration scenario.
>> > It is perfectly reasonable to migrate a guest to another machine where
>> > the VF PCI address is different. And since current udev/systemd model
>> > is to base network device name off of PCI address, the device will change
>> > name when guest is migrated.
>> >
>> The scenario of having VF on a different PCI address on post migration
>> is essentially equal to plugging in a new NIC. Why it has to pair with
>> the original PV? A sepearte PV device should be in place to pair the
>> new VF.
>
> The host only guarantees that the PV device will be on the same network.
> It does not make any PCI guarantees. The way Windows works is to find
> the device based on "serial number" which is an Hyper-V specific attribute
> of PCI devices.
>
> I considered naming off of serial number but that won't work for the
> case where PV device is present first and VF arrives later. The serial
> number is attribute of VF, not the PV which is there first.
I assume the PV can get that information ahead of time before VF
arrives? Without it how do you match the device when you see a VF
coming with some serial number? Is it possible for PV to get the
matching SN even earlier during probe time? Or it has to depend on the
presence of vPCI bridge to generate this SN?
>
> Your ideas about having the PCI information of the VF form the name
> of the failover device have the same problem. The PV device may
> be the only one present on boot.
Yeah, this is a chicken-egg problem indeed, and that was the reason
why I supply the BDF info for PV to name the master interface.
However, the ACPI PCI slot needs to depend on the PCI bus enumeration
so that can't be predictable. Would it make sense to only rename when
the first time a matching VF appears and PV interface isn't brought
up, then the failover master would always stick to the name
afterwards? I think it should cover most scenarios as it's usually
during boot time (dracut) the VF first appears and the PV interface at
the time then shouldn't have been configured yet.
-Siwei
>
>
>> > On Azure, the VF maybe removed (by host) at any time and then later
>> > reattached. There is no guarantee that VF will show back up at
>> > the same synthetic PCI address. It will likely have a different
>> > PCI domain value.
>>
>> This is something QEMU can do and make sure the PCI address is
>> consistent after migration.
>>
>> -Siwei
>
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Jakub Kicinski @ 2018-06-09 1:29 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Michael S. Tsirkin, Jiri Pirko, kys, haiyangz,
David Miller, Samudrala, Sridhar, Netdev, Stephen Hemminger
In-Reply-To: <CADGSJ20sq8AmW34Z7w0JrTg6=YnKaM3Hq5R3TfhAH5BkuR2pqA@mail.gmail.com>
On Fri, 8 Jun 2018 16:44:12 -0700, Siwei Liu wrote:
> >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of
> >> that flag, as well as the 1-netdev model, is to have a means to
> >> inherit the interface name from the VF, and to eliminate playing hacks
> >> around renaming devices, customizing udev rules and et al. Why
> >> inheriting VF's name important? To allow existing config/setup around
> >> VF continues to work across kernel feature upgrade. Most of network
> >> config files in all distros are based on interface names. Few are MAC
> >> address based but making lower slaves hidden would cover the rest. And
> >> most importantly, preserving the same level of user experience as
> >> using raw VF interface once getting all ndo_ops and ethtool_ops
> >> exposed. This is essential to realize transparent live migration that
> >> users dont have to learn and be aware of the undertaken.
> >
> > Inheriting the VF name will fail in the migration scenario.
> > It is perfectly reasonable to migrate a guest to another machine where
> > the VF PCI address is different. And since current udev/systemd model
> > is to base network device name off of PCI address, the device will change
> > name when guest is migrated.
> >
> The scenario of having VF on a different PCI address on post migration
> is essentially equal to plugging in a new NIC. Why it has to pair with
> the original PV? A sepearte PV device should be in place to pair the
> new VF.
IMHO it may be a better idea to look at the VF as acceleration for the
PV rather than PV a migration vehicle from the VF. Hence we should
continue to follow the naming of PV, like the current implementation
does implicitly by linking to PV's struct device.
^ permalink raw reply
* Re: Qualcomm rmnet driver and qmi_wwan
From: Subash Abhinov Kasiviswanathan @ 2018-06-09 2:19 UTC (permalink / raw)
To: Bjørn Mork, Daniele Palmas; +Cc: Dan Williams, netdev
In-Reply-To: <87k1r914df.fsf@miraculix.mork.no>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
> This sounds like a good idea. I probably won't have any time to look at
> this in the near future, though. Sorry about that. Extremely
> overloaded
> both at work and private right now...
>
> But I trust that you and Daniele can work out something. Please keep me
> CCed, but don't expect timely replies.
>
Hi Daniele
Can you try out the attached patch.
I have added a new sysfs attribute pass_through to be used in raw_ip
mode
only. Once you attach rmnet devices on it, the rx_handler will be setup
and the packet will be processed by rmnet.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-qmi_wwan-Add-pass-through-mode.patch --]
[-- Type: text/x-diff; name=0001-net-qmi_wwan-Add-pass-through-mode.patch, Size: 3444 bytes --]
From bccfae3707af1be671fe55ea63123438f2dc38a8 Mon Sep 17 00:00:00 2001
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Fri, 8 Jun 2018 19:53:08 -0600
Subject: [PATCH] net: qmi_wwan: Add pass through mode
Pass through mode is to allow packets in MAP format to be passed
on to the stack. rmnet driver can be used to process and demultiplex
these packets. Note that pass through mode can be enabled when the
device is in raw ip mode only.
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/usb/qmi_wwan.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8e8b51f..f52a9be 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -59,6 +59,7 @@ struct qmi_wwan_state {
enum qmi_wwan_flags {
QMI_WWAN_FLAG_RAWIP = 1 << 0,
QMI_WWAN_FLAG_MUX = 1 << 1,
+ QMI_WWAN_FLAG_PASS_THROUGH = 1 << 2,
};
enum qmi_wwan_quirks {
@@ -425,14 +426,80 @@ static ssize_t del_mux_store(struct device *d, struct device_attribute *attr, c
return ret;
}
+static ssize_t pass_through_show(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usbnet *dev = netdev_priv(to_net_dev(d));
+ struct qmi_wwan_state *info;
+
+ info = (void *)&dev->data;
+ return sprintf(buf, "%c\n",
+ info->flags & QMI_WWAN_FLAG_PASS_THROUGH ? 'Y' : 'N');
+}
+
+static ssize_t pass_through_store(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct usbnet *dev = netdev_priv(to_net_dev(d));
+ struct qmi_wwan_state *info;
+ bool enable;
+ int ret;
+
+ if (strtobool(buf, &enable))
+ return -EINVAL;
+
+ info = (void *)&dev->data;
+
+ /* no change? */
+ if (enable == (info->flags & QMI_WWAN_FLAG_PASS_THROUGH))
+ return len;
+
+ /* pass through mode can be set for raw ip devices only */
+ if (!(info->flags & QMI_WWAN_FLAG_RAWIP))
+ return -EINVAL;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ /* we don't want to modify a running netdev */
+ if (netif_running(dev->net)) {
+ netdev_err(dev->net, "Cannot change a running device\n");
+ ret = -EBUSY;
+ goto err;
+ }
+
+ /* let other drivers deny the change */
+ ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE, dev->net);
+ ret = notifier_to_errno(ret);
+ if (ret) {
+ netdev_err(dev->net, "Type change was refused\n");
+ goto err;
+ }
+
+ if (enable)
+ info->flags |= QMI_WWAN_FLAG_PASS_THROUGH;
+ else
+ info->flags &= ~QMI_WWAN_FLAG_PASS_THROUGH;
+ qmi_wwan_netdev_setup(dev->net);
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev->net);
+ ret = len;
+err:
+ rtnl_unlock();
+ return ret;
+}
+
static DEVICE_ATTR_RW(raw_ip);
static DEVICE_ATTR_RW(add_mux);
static DEVICE_ATTR_RW(del_mux);
+static DEVICE_ATTR_RW(pass_through);
static struct attribute *qmi_wwan_sysfs_attrs[] = {
&dev_attr_raw_ip.attr,
&dev_attr_add_mux.attr,
&dev_attr_del_mux.attr,
+ &dev_attr_pass_through.attr,
NULL,
};
@@ -479,6 +546,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
if (info->flags & QMI_WWAN_FLAG_MUX)
return qmimux_rx_fixup(dev, skb);
+ if (rawip && (info->flags & QMI_WWAN_FLAG_PASS_THROUGH)) {
+ skb->protocol = htons(ETH_P_MAP);
+ return (netif_rx(skb) == NET_RX_SUCCESS);
+ }
+
switch (skb->data[0] & 0xf0) {
case 0x40:
proto = htons(ETH_P_IP);
--
1.9.1
^ permalink raw reply related
* [PATCH net] tcp: limit sk_rcvlowat by the maximum receive buffer
From: Soheil Hassas Yeganeh @ 2018-06-09 2:47 UTC (permalink / raw)
To: davem, netdev; +Cc: ycheng, ncardwell, edumazet, willemb, Soheil Hassas Yeganeh
From: Soheil Hassas Yeganeh <soheil@google.com>
The user-provided value to setsockopt(SO_RCVLOWAT) can be
larger than the maximum possible receive buffer. Such values
mute POLLIN signals on the socket which can stall progress
on the socket.
Limit the user-provided value to half of the maximum receive
buffer, i.e., half of sk_rcvbuf when the receive buffer size
is set by the user, or otherwise half of sysctl_tcp_rmem[2].
Fixes: d1361840f8c5 ("tcp: fix SO_RCVLOWAT and RCVBUF autotuning")
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/tcp.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 2741953adaba2..141acd92e58ae 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1694,6 +1694,13 @@ EXPORT_SYMBOL(tcp_peek_len);
/* Make sure sk_rcvbuf is big enough to satisfy SO_RCVLOWAT hint */
int tcp_set_rcvlowat(struct sock *sk, int val)
{
+ int cap;
+
+ if (sk->sk_userlocks & SOCK_RCVBUF_LOCK)
+ cap = sk->sk_rcvbuf >> 1;
+ else
+ cap = sock_net(sk)->ipv4.sysctl_tcp_rmem[2] >> 1;
+ val = min(val, cap);
sk->sk_rcvlowat = val ? : 1;
/* Check if we need to signal EPOLLIN right now */
@@ -1702,12 +1709,7 @@ int tcp_set_rcvlowat(struct sock *sk, int val)
if (sk->sk_userlocks & SOCK_RCVBUF_LOCK)
return 0;
- /* val comes from user space and might be close to INT_MAX */
val <<= 1;
- if (val < 0)
- val = INT_MAX;
-
- val = min(val, sock_net(sk)->ipv4.sysctl_tcp_rmem[2]);
if (val > sk->sk_rcvbuf) {
sk->sk_rcvbuf = val;
tcp_sk(sk)->window_clamp = tcp_win_from_space(sk, val);
--
2.18.0.rc1.242.g61856ae69a-goog
^ permalink raw reply related
* Re: next-20180605 - BUG in ipv6_add_addr
From: Dexuan-Linux Cui @ 2018-06-09 2:54 UTC (permalink / raw)
To: David Ahern
Cc: valdis.kletnieks, netdev, Linux Kernel Mailing List, Dexuan Cui
In-Reply-To: <6471e14e-2872-3ba4-7336-7c5840d28c12@gmail.com>
On Thu, Jun 7, 2018 at 5:51 PM, David Ahern <dsahern@gmail.com> wrote:
>
> ...
> I know you don't have a reliable reproducer, but I did find one spot
> where I was too clever and did not initialize a new cfg variable:
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 89019bf59f46..59c22a25e654 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1324,6 +1324,7 @@ static int ipv6_create_tempaddr(struct
> inet6_ifaddr *ifp,
> }
> }
>
> + memset(&cfg, 0, sizeof(cfg));
> cfg.valid_lft = min_t(__u32, ifp->valid_lft,
> idev->cnf.temp_valid_lft + age);
> cfg.preferred_lft = cnf_temp_preferred_lft + age -
> idev->desync_factor;
This works for me. Great!
Thanks,
-- Dexuan
^ permalink raw reply
* [RFC PATCH 0/2] net-next: cleanup use of lib8390.c code in xsurf100.c
From: Michael Schmitz @ 2018-06-09 5:57 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain
In-Reply-To: <CAMuHMdWsibY4h5zwBC4qs8ZLq_1-627qjpeDLGzVjaGjG_A4PA@mail.gmail.com>
As suggested by Geert, xsurf100.c really does not need to duplicate code
from lib8390.c which is already part of ax88796.c, by including that file.
All we need from lib8390.c in the xsurf100 block output function is one
single function: ax_NS8390_init(). Export this symbol in ax88796.c so
the xsurf100 driver can use it.
This is rather a quick band-aid fix to deal with the ugliest code duplication
(including lib8390.c where it really isn't needed). The xsurf100 block_input
and block_output functiond are almost exact duplicated of the generic ax88796
functions, and changing those to make use of platform-specific block MMIO
transfer functions might be a better way to fix this issue.
Tested on Amiga hardware (elgar).
Cheers,
Michael
^ permalink raw reply
* [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Michael Schmitz @ 2018-06-09 5:57 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, Michael Schmitz
In-Reply-To: <CAMuHMdWsibY4h5zwBC4qs8ZLq_1-627qjpeDLGzVjaGjG_A4PA@mail.gmail.com>
Now that ax88796.c exports the ax_NS8390_init() symbol, we can
include 8390.h instead of lib8390.c, avoiding duplication of that
function and killing a few compile warnings in the bargain.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/xsurf100.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/8390/xsurf100.c b/drivers/net/ethernet/8390/xsurf100.c
index 4c6f9cb..32caa5e 100644
--- a/drivers/net/ethernet/8390/xsurf100.c
+++ b/drivers/net/ethernet/8390/xsurf100.c
@@ -33,8 +33,6 @@
#define HW_CHIPID 0x70
#define HW_SCRATCH 0x78
-#define __NS8390_init ax_NS8390_init
-
/* force unsigned long back to 'void __iomem *' */
#define ax_convert_addr(_a) ((void __force __iomem *)(_a))
@@ -80,12 +78,10 @@ static void reg_write16(void __iomem *base, u16 reg, u16 val)
writew(val, base + reg*4);
}
+#define NS8390_CORE
+#include "8390.h"
-
-static unsigned char version[] =
- "ax88796.c: Copyright 2005,2007 Simtec Electronics\n";
-
-#include "lib8390.c"
+extern void ax_NS8390_init(struct net_device *dev, int startp);
/* from ne.c */
#define NE_CMD EI_SHIFT(0x00)
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Michael Schmitz @ 2018-06-09 5:57 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, Michael Schmitz
In-Reply-To: <CAMuHMdWsibY4h5zwBC4qs8ZLq_1-627qjpeDLGzVjaGjG_A4PA@mail.gmail.com>
The block I/O code for the new X-Surf 100 ax88796 driver needs
ax_NS8390_init() for error fixup in its block_output function.
Export this function so we can lose the lib8380.c include in the
X-Surf 100 driver.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/ax88796.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 2a0ddec..470142f 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -62,6 +62,8 @@
#include "lib8390.c"
+EXPORT_SYMBOL_GPL(ax_NS8390_init);
+
#define DRV_NAME "ax88796"
#define DRV_VERSION "1.00"
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-09 7:08 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, davem, netdev
In-Reply-To: <20180608155529.GA19702@lunn.ch>
Hi Andrew.
Thanks for your comments. I will update the patch a bit later.
>
> Does 100Base-T1/cause 96 define a way to identify a PHY which
> implements this? I'm just wondering if we can do this in the generic
> code, for devices which correctly implement the standard?
>
Well, I did research IEEE 802.3 standards before implementing the
Patch. Initially I
wanted to update generic phy driver. I did not find a way to identify
100Base-T1 PHY
using Clause 22 MDIO. This section is completely missing at IEEE 802.3bw, which
describe 100Base-T1.
There are some updates to Clause 45 registers at IEEE 802.3bw. They add
"BASE-T1 PMA/PMD extended ability" to PMA/PMD registers.
At Clause 96 they state following: "The MDIO capability described in Clause 45
defines several variables that provide control and status information for and
about the PMA and PCS."
In the same time I have played with a two different 100Base-T1 PHYs. Both
use different Clause 22 registers to advertise their abilities, both
are incompatible.
None use Clause 45 for this purpose.
It seems that this is going to be 100Base-T1 mess while IEEE 802.3bw
miss Clause 22 updates. Clause 45 is rarely used from my experience. Probably
IEEE expected 100Base-T1 PHYs to go for Clause 45 MDIO and this did not work
so far.
>
> This is the second T1 driver we have had recently. It might make sense to add a
> PHY_T1_FEATURES macro the include/linux/phy.h
>
This seems reasonable, indeed.
>
> Don't you also want SUPPORTED_TP?
>
True, I will add SUPPORTED_TP in next revision of the Patch.
Kirill
^ permalink raw reply
* Re: Qualcomm rmnet driver and qmi_wwan
From: Daniele Palmas @ 2018-06-09 7:22 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan; +Cc: Bjørn Mork, Dan Williams, netdev
In-Reply-To: <8ad179b53c866ef67823570d055071a3@codeaurora.org>
Hi Subash,
2018-06-09 4:19 GMT+02:00 Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org>:
>> This sounds like a good idea. I probably won't have any time to look at
>> this in the near future, though. Sorry about that. Extremely overloaded
>> both at work and private right now...
>>
>> But I trust that you and Daniele can work out something. Please keep me
>> CCed, but don't expect timely replies.
>>
>
> Hi Daniele
>
> Can you try out the attached patch.
> I have added a new sysfs attribute pass_through to be used in raw_ip mode
> only. Once you attach rmnet devices on it, the rx_handler will be setup
> and the packet will be processed by rmnet.
>
thanks, I will test it on Monday.
Just a question for my knowledge: is the new sysfs attribute really
needed? I mean, is there not any other way to understand from qmi_wwan
without user intervention that there is the rmnet device attached?
Regards,
Daniele
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next V3] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-09 8:48 UTC (permalink / raw)
To: andrew, f.fainelli, davem, netdev; +Cc: Kirill Kranke
Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
properly. TJA1100 does not have any standard ability enabled at MII_BMSR
register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
is not handled by generic driver yet. Therefore generic driver is unable to
guess required link speed, duplex etc. Device is started up with 10Mbps
halfduplex which is incorrect.
BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
did not add BroadR-REACH able flag support at generic driver. Once
BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
support it in the generic PHY driver.
Signed-off-by: Kirill Kranke <kranke.kirill@gmail.com>
---
Notes:
Second edition of the patch miss changes list and V2 flag. Changes are
included here.
Changes from V1 to V2:
- Remove unused #define from tja1100.c
- Do not touch phydev->supported and phydev->advertising
at tja1100_phy_config_init
- Use proper error codes at tja1100_phy_config_aneg
- Use phydev_err instead of pr_err
- Do not specify read_status and soft_reset while they
are default to required value
- Correct wrong Signed-off-by email address
Changes from V2 to V3:
- Add 'net-next' tree
- Add this notes
- Rename config option from TJA1100_PHY to NXP_TJA1100_PHY
- Minor update to config help message: specify that able flag
is TJA1100's custom
- Add SUPPORTED_TP feature
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 343989f..ec30de4 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -387,6 +387,15 @@ config NATIONAL_PHY
---help---
Currently supports the DP83865 PHY.
+config NXP_TJA1100_PHY
+ tristate "NXP TJA1100 PHY"
+ help
+ Support of NXP TJA1100 BroadR-REACH ethernet PHY.
+ Generic driver is not suitable for TJA1100 PHY while the PHY does not
+ advertise any standard IEEE capabilities. It uses custom BroadR-REACH
+ able flag instead. This driver configures capabilities of the PHY
+ properly.
+
config QSEMI_PHY
tristate "Quality Semiconductor PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b..c1bc14d4 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
obj-$(CONFIG_MICROCHIP_T1_PHY) += microchip_t1.o
obj-$(CONFIG_MICROSEMI_PHY) += mscc.o
obj-$(CONFIG_NATIONAL_PHY) += national.o
+obj-$(CONFIG_NXP_TJA1100_PHY) += tja1100.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
obj-$(CONFIG_REALTEK_PHY) += realtek.o
obj-$(CONFIG_RENESAS_PHY) += uPD60620.o
diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
new file mode 100644
index 0000000..2b03057
--- /dev/null
+++ b/drivers/net/phy/tja1100.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: GPL-2.0
+/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
+ *
+ * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
+ * Author: Kirill Kranke <kirill.kranke@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+
+static int tja1100_phy_config_init(struct phy_device *phydev)
+{
+ phydev->autoneg = AUTONEG_DISABLE;
+ phydev->speed = SPEED_100;
+ phydev->duplex = DUPLEX_FULL;
+
+ return 0;
+}
+
+static int tja1100_phy_config_aneg(struct phy_device *phydev)
+{
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ phydev_err(phydev, "autonegotiation is not supported\n");
+ return -EINVAL;
+ }
+
+ if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
+ phydev_err(phydev, "only 100MBps Full Duplex allowed\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct phy_driver tja1100_phy_driver[] = {
+ {
+ .phy_id = 0x0180dc48,
+ .phy_id_mask = 0xfffffff0,
+ .name = "NXP TJA1100",
+
+ /* TJA1100 has only 100BASE-BroadR-REACH ability specified
+ * at MII_ESTATUS register. Standard modes are not
+ * supported. Therefore BroadR-REACH allow only 100Mbps
+ * full duplex without autoneg.
+ */
+ .features = SUPPORTED_100baseT_Full | SUPPORTED_MII
+ | SUPPORTED_TP,
+
+ .config_aneg = tja1100_phy_config_aneg,
+ .config_init = tja1100_phy_config_init,
+
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ }
+};
+
+module_phy_driver(tja1100_phy_driver);
+
+MODULE_DESCRIPTION("NXP TJA1100 driver");
+MODULE_AUTHOR("Kirill Kranke <kkranke@topcon.com>");
+MODULE_LICENSE("GPL");
+
+static struct mdio_device_id __maybe_unused nxp_tbl[] = {
+ { 0x0180dc48, 0xfffffff0 },
+ {}
+};
+
+MODULE_DEVICE_TABLE(mdio, nxp_tbl);
^ permalink raw reply related
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Karcher @ 2018-06-09 9:15 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher
In-Reply-To: <8144eec6-7bc1-95e0-e762-8b5af1c18583@gmail.com>
Michael Schmitz schrieb:
> Hi Michael,
>> actually, the the block_input / block_output functions were the reason I
>> included the lib8390.c file. Except for xs100_write / xs100_read, they
>> are
>> a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
>> anymore, but did not get around to improve it. I added a customization
>> point to ax88796 for a custom block_input / block_output, because the
>> 8390
>> core already provides that customization point. What I really need is a
>> customization point just for the 8390-remote-DMA-via-MMIO functions
>> (i.e.
>> xs100_write, xs100_read) instead of the whole block transfer core that
>> also sets up the remote DMA engine and tries to re-initialize the card
>> in
>> case of unexplained problems.
>
> OK, so essentially change
>
> if (ei_local->word16) {
> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
> if (count & 0x01)
> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>
> } else {
> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
> }
>
> to something like
>
> if (ax->block_read) {
> ax->block_read(dev, buf, count);
> } else if (ei_local->word16) {
> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
> if (count & 0x01)
> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>
> } else {
> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
> }
>
> and populate ax->block_read() and ax_block_write() from platform data,
> instead of substituting ax_block_input() / ax_block_output() wholesale?
That's basically how I think the whole lib8390.c story should in fact be
tackled. Less code duplication, no second include of lib8390 and constrain
xsurf100.c to the pieces that make this piece of hardware unique.
> I must be missing something here.
I don't think so.
> Adds one test for
> ax->block_read on the critical path but we already have the test for
> ei_local->word16 there. May need rearranging the tests so the majority
> of ax88796 users isn't impacted.
Rearranging sounds like a good idea. As I understand, the only valid
rearrangement is putting it inside the 16-bit branch, because the xs100
uses 16-bit transfers and needs the extra byte for odd counts. The code
checks word16 at the beginning of xs100_block_output for that. This has
the advantage of not hurting users of the 8 bit interface, which might be
the slowest users of the ax88796, but comes at the cost of not being able
to customize the block_input/block_output for 8-bit users. As this "cost"
is not a problem now (no one can customize block_input/block_output
currently), lets put the block_read check into the word16 block. You might
want to name the member block_read16 instead of just block_read to convey
the information, that it is only used if word16 is set.
> Anyway, your code, your call.
On the other hand: Your polishing, your call. Thank you for your work on
gettting the code in good shape for merging.
Kind regards,
Michael Karcher
^ permalink raw reply
* Re: Donation-
From: M. M. Fridman @ 2018-06-09 4:19 UTC (permalink / raw)
To: Recipients
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.
Check the link below for confirmation:
http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604
Reply as soon as possible with further directives.
Best Regards,
Mikhail Fridman.
^ permalink raw reply
* Dear Talented
From: Lisa Clement @ 2018-06-09 10:56 UTC (permalink / raw)
To: Recipients
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Spies in Disguise (Spies in Disguise 2019) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: bluesky.filmstudio@usa.com
All Reply to: bluesky.filmstudio@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.
Talent Scout
Lisa Clement
^ permalink raw reply
* Re: [PATCH 2/3] bpfilter: include bpfilter_umh in assembly instead of using objcopy
From: Masahiro Yamada @ 2018-06-09 12:45 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, Alexei Starovoitov, David S . Miller, Arnd Bergmann,
Geert Uytterhoeven, Linux Kernel Mailing List, YueHaibing
In-Reply-To: <20180608204727.jggtai5iro7ao34v@ast-mbp.dhcp.thefacebook.com>
2018-06-09 5:47 GMT+09:00 Alexei Starovoitov <alexei.starovoitov@gmail.com>:
> On Sat, Jun 09, 2018 at 02:12:09AM +0900, Masahiro Yamada wrote:
>> Do not use the troublesome ELF magic. What is happening here is to
>> embed a user-space program into the kernel. Simply wrap it in the
>> assembly with the '.incbin' directive.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> net/bpfilter/Makefile | 15 ++-------------
>> net/bpfilter/bpfilter_kern.c | 11 +++++------
>> net/bpfilter/bpfilter_umh_blob.S | 7 +++++++
>> 3 files changed, 14 insertions(+), 19 deletions(-)
>> create mode 100644 net/bpfilter/bpfilter_umh_blob.S
>>
>> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
>> index aafa720..39c6980 100644
>> --- a/net/bpfilter/Makefile
>> +++ b/net/bpfilter/Makefile
>> @@ -15,18 +15,7 @@ ifeq ($(CONFIG_BPFILTER_UMH), y)
>> HOSTLDFLAGS += -static
>> endif
>>
>> -# a bit of elf magic to convert bpfilter_umh binary into a binary blob
>> -# inside bpfilter_umh.o elf file referenced by
>> -# _binary_net_bpfilter_bpfilter_umh_start symbol
>> -# which bpfilter_kern.c passes further into umh blob loader at run-time
>> -quiet_cmd_copy_umh = GEN $@
>> - cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
>> - $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT) \
>> - -B `$(OBJDUMP) -f $<|grep architecture|cut -d, -f1|cut -d' ' -f2` \
>> - --rename-section .data=.init.rodata $< $@
>> -
>> -$(obj)/bpfilter_umh.o: $(obj)/bpfilter_umh
>> - $(call cmd,copy_umh)
>> +$(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
>>
>> obj-$(CONFIG_BPFILTER_UMH) += bpfilter.o
>> -bpfilter-objs += bpfilter_kern.o bpfilter_umh.o
>> +bpfilter-objs += bpfilter_kern.o bpfilter_umh_blob.o
>> diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c
>> index b13d058..fcc1a7c 100644
>> --- a/net/bpfilter/bpfilter_kern.c
>> +++ b/net/bpfilter/bpfilter_kern.c
>> @@ -10,11 +10,8 @@
>> #include <linux/file.h>
>> #include "msgfmt.h"
>>
>> -#define UMH_start _binary_net_bpfilter_bpfilter_umh_start
>> -#define UMH_end _binary_net_bpfilter_bpfilter_umh_end
>> -
>> -extern char UMH_start;
>> -extern char UMH_end;
>> +extern char bpfilter_umh_start;
>> +extern char bpfilter_umh_end;
>>
>> static struct umh_info info;
>> /* since ip_getsockopt() can run in parallel, serialize access to umh */
>> @@ -89,7 +86,9 @@ static int __init load_umh(void)
>> int err;
>>
>> /* fork usermode process */
>> - err = fork_usermode_blob(&UMH_start, &UMH_end - &UMH_start, &info);
>> + err = fork_usermode_blob(&bpfilter_umh_end,
>> + &bpfilter_umh_end - &bpfilter_umh_start,
>> + &info);
>> if (err)
>> return err;
>> pr_info("Loaded bpfilter_umh pid %d\n", info.pid);
>> diff --git a/net/bpfilter/bpfilter_umh_blob.S b/net/bpfilter/bpfilter_umh_blob.S
>> new file mode 100644
>> index 0000000..40311d1
>> --- /dev/null
>> +++ b/net/bpfilter/bpfilter_umh_blob.S
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> + .section .init.rodata, "a"
>> + .global bpfilter_umh_start
>> +bpfilter_umh_start:
>> + .incbin "net/bpfilter/bpfilter_umh"
>
> Interesting. I think this is good idea. Looks cleaner than objcopy magic.
> btw CONFIG_OUTPUT_FORMAT already fixed by
> commit 8d97ca6b6755 ("bpfilter: fix OUTPUT_FORMAT") in net tree.
> Could you please rebase on top of that tree?
>
OK, I will rebase it.
BTW, I only compile-tested this patch.
Could you check if it really works?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Andrew Lunn @ 2018-06-09 14:07 UTC (permalink / raw)
To: Kirill Kranke; +Cc: Florian Fainelli, davem, netdev
In-Reply-To: <CAJAJcrHLhjEPoQ--6kenb9HSnv_V7p2wbDf6J=fnsokZ2jWv4g@mail.gmail.com>
> It seems that this is going to be 100Base-T1 mess while IEEE 802.3bw
> miss Clause 22 updates. Clause 45 is rarely used from my experience. Probably
> IEEE expected 100Base-T1 PHYs to go for Clause 45 MDIO and this did not work
> so far.
Hi Kirill
Thanks for this information. So lets forget generic support for the
moment.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Geert Uytterhoeven @ 2018-06-09 14:31 UTC (permalink / raw)
To: Michael Schmitz; +Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain
In-Reply-To: <1528523869-3403-2-git-send-email-schmitzmic@gmail.com>
Hi Michael,
On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> The block I/O code for the new X-Surf 100 ax88796 driver needs
> ax_NS8390_init() for error fixup in its block_output function.
>
> Export this function so we can lose the lib8380.c include in the
> X-Surf 100 driver.
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Thanks for your patch!
> --- a/drivers/net/ethernet/8390/ax88796.c
> +++ b/drivers/net/ethernet/8390/ax88796.c
> @@ -62,6 +62,8 @@
>
> #include "lib8390.c"
>
> +EXPORT_SYMBOL_GPL(ax_NS8390_init);
While that works for the modular case, it doesn't work for the builtin case,
as the function is static.
You can fix that by adding a non-static wrapper, and exporting that one instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Geert Uytterhoeven @ 2018-06-09 14:33 UTC (permalink / raw)
To: Michael Schmitz; +Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain
In-Reply-To: <1528523869-3403-3-git-send-email-schmitzmic@gmail.com>
Hi Michael,
On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>
> Now that ax88796.c exports the ax_NS8390_init() symbol, we can
> include 8390.h instead of lib8390.c, avoiding duplication of that
> function and killing a few compile warnings in the bargain.
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Thanks for your patch!
> --- a/drivers/net/ethernet/8390/xsurf100.c
> +++ b/drivers/net/ethernet/8390/xsurf100.c
> @@ -33,8 +33,6 @@
> #define HW_CHIPID 0x70
> #define HW_SCRATCH 0x78
>
> -#define __NS8390_init ax_NS8390_init
> -
> /* force unsigned long back to 'void __iomem *' */
> #define ax_convert_addr(_a) ((void __force __iomem *)(_a))
>
> @@ -80,12 +78,10 @@ static void reg_write16(void __iomem *base, u16 reg, u16 val)
This doesn't apply against net-next, which doesn't have reg_write16() (yet?).
Apart from that, your patch looks fine to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] bpfilter: do not (ab)use host-program build rule
From: Masahiro Yamada @ 2018-06-09 15:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, Alexei Starovoitov, David S . Miller, Arnd Bergmann,
Geert Uytterhoeven, Linux Kernel Mailing List, YueHaibing,
Daniel Borkmann
In-Reply-To: <20180608205256.cpniquglftmie5vl@ast-mbp.dhcp.thefacebook.com>
2018-06-09 5:52 GMT+09:00 Alexei Starovoitov <alexei.starovoitov@gmail.com>:
> On Sat, Jun 09, 2018 at 02:12:10AM +0900, Masahiro Yamada wrote:
>> It is an ugly hack to overwrite $(HOSTCC) with $(CC) to reuse the
>> build rules from scripts/Makefile.host. It should not be tedious
>> to write a build rule for its own.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> net/bpfilter/Makefile | 17 +++++++++++------
>> net/bpfilter/{main.c => bpfilter_umh.c} | 0
>> 2 files changed, 11 insertions(+), 6 deletions(-)
>> rename net/bpfilter/{main.c => bpfilter_umh.c} (100%)
>>
>> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
>> index 39c6980..6571b30 100644
>> --- a/net/bpfilter/Makefile
>> +++ b/net/bpfilter/Makefile
>> @@ -3,18 +3,23 @@
>> # Makefile for the Linux BPFILTER layer.
>> #
>>
>> -hostprogs-y := bpfilter_umh
>> -bpfilter_umh-objs := main.o
>> -HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
>> -HOSTCC := $(CC)
>
> that is a hack indeed. I don't like it either, but see below.
>
>> -
>> ifeq ($(CONFIG_BPFILTER_UMH), y)
>> # builtin bpfilter_umh should be compiled with -static
>> # since rootfs isn't mounted at the time of __init
>> # function is called and do_execv won't find elf interpreter
>> -HOSTLDFLAGS += -static
>> +STATIC := -static
>> endif
>>
>> +quiet_cmd_cc_user = CC $@
>> + cmd_cc_user = $(CC) -Wall -Wmissing-prototypes -O2 -std=gnu89 \
>> + -I$(srctree) -I$(srctree)/tools/include/ \
>> + -I$(srctree)/tools/include/uapi $(STATIC) -o $@ $<
>> +
>> +$(obj)/bpfilter_umh: $(src)/bpfilter_umh.c FORCE
>> + $(call if_changed,cc_user)
>
> Does this scale?
> Please see two top patches here:
> https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/log/?h=ipt_bpf
> that add more meat to bpfilter and a lot more files.
Oh, I just thought main.c was the only user-program file.
> Recompiling all of them at once isn't nice either.
Indeed.
It should be able to compile .c -> .o separately.
> This Makefile needs different .c -> .o rules for bpfilter_kern.c files
> that get compiled into kernel module and for the rest of umh files:
> main.c ctor.c init.c gen.c etc
> that need to be compiled .c -> .o differently.
> I don't see how to do it without ugly hacks in Makefile.
> In that sense HOSTCC = CC hack looked the least ugly to me that's
> why I went with it.
> Better ideas?
I will think about it after your patches land.
I will drop this for now.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: netdevice notifier and device private data
From: Alexander Aring @ 2018-06-09 15:29 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <32763.1528486664@localhost>
Hi,
On Fri, Jun 08, 2018 at 03:37:44PM -0400, Michael Richardson wrote:
>
> Alexander Aring <aring@mojatatu.com> wrote:
> Alex> I already see code outside who changed tun netdevice to the
> Alex> ARPHRD_6LOWPAN type and I suppose they running into this
> Alex> issue. (Btw: I don't know why somebody wants to changed that
> Alex> type to ARPHRD_6LOWPAN on tun).
>
> so that they can have the kernel do 6lowpan processing, emitting 6lowPAN
> packets into userspace to be transfered into a radio via some proprietary
> interface (including, for instance SLIP over USB cable to Contiki or OpenWSN stack,
> set up to act as radio only)
>
No, the datapath doesn't change. If the user space evaluate the
dev->type (there exists some ioctl() for it) it will assume it has a
6LoWPAN type interface.
A lot of user space software outside will doing interface specific
handling after detect the type. E.g. wireshark will select some dissector
handling.
On a tun interface and switch to 6LoWPAN it will not change much the
dissector view, because both raw IPv6 packets on datapath. For me as
6LoWPAN maintainer it makes no sense to switch to it. Currently
some netdevice notifier will crash (if you a lucky it will not).
Futhermore user space programs e.g. radvd will do 6lowpan specific
handling on 6lowpan dev->type, it will not work either on tun devices.
I know that wpantund from NestLabs do this switch, I am very curious
about the reason but I think they do it because the name is 6LoWPAN. But
wpantund is just a SLIP like protocol with additional radio/foo commands.
---
According to the people who say "I like to have a 6LoWPAN tun device,
that would be nice" - I don't know how this will ever work since 6LoWPAN
header highly depends on MAC header information. Tun devices works
because IP architecture allows a separation from MAC layer. I already
saw protocols at IETF where MAC header information are needed on top of
UDP payload in case of 6LoWPAN. (I talked about that at last netdev in
Montreal).
Bluetooth wanted to add a tun 6lowpan interface and I was curious how
this works. At the end it was a "Bluetooth mapping to ethernet header"
(not as tunnel, as propagated). I was not acking it, because if there
are protocols who needs more information than just what you can map to
ethernet... it will not work. At least it will also not work with IEEE
802.15.4 at all. They was just lucky that Bluetooth and ethernet use the
same mac address length (And I had some questions to the multicast bit
as well).
Tunnel might work to get mac information. But so far 6loWPAN works it is
that you have a L2 underlaying interface and on top (ip link set master)
a raw IPv6 interface which do the adaptation automatically as a protocol
translation (That's why I cannot understand Bluetooth 6LoWPAN use tx
queues on their 6LoWPAN interface, they need to fix the queue in the
underlaying L2 interface).
As an alternative solution I think it should be something done like TAP
like interface per subsystem. I mean NO ETHERTNET, but the ethernet in
TAP interfaces out and replace it with Bluetooth or IEEE 802.15.4.
I might can easily create a simple TAP IEEE 802.15.4 to show what I
mean.
With an IEEE 802.15.4 TAP device and a 6lowpan interface on top you can
realize your use case and pass 802.15.4 L2 frames to device node -> pops
up at 6LoPWAN interface and send IPv6 stuff and you can read on device
node.
I am still in the opinion the L2 TAP like interface is the way to go to
offer such feature.
- Alex
^ 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