* Re: [RFC PATCH net-next] net: phy: force phy suspend when calling phy_stop
From: shenjian (K) @ 2019-08-28 1:03 UTC (permalink / raw)
To: Heiner Kallweit, andrew, f.fainelli, davem
Cc: netdev, forest.zhouchang, linuxarm
In-Reply-To: <04fdbe88-8471-c023-4a0d-890667735737@gmail.com>
在 2019/8/28 3:41, Heiner Kallweit 写道:
> On 27.08.2019 10:29, shenjian (K) wrote:
>>
>>
>> 在 2019/8/27 13:51, Heiner Kallweit 写道:
>>> On 27.08.2019 04:47, Jian Shen wrote:
>>>> Some ethernet drivers may call phy_start() and phy_stop() from
>>>> ndo_open and ndo_close() respectively.
>>>>
>>>> When network cable is unconnected, and operate like below:
>>>> step 1: ifconfig ethX up -> ndo_open -> phy_start ->start
>>>> autoneg, and phy is no link.
>>>> step 2: ifconfig ethX down -> ndo_close -> phy_stop -> just stop
>>>> phy state machine.
>>>> step 3: plugin the network cable, and autoneg complete, then
>>>> LED for link status will be on.
>>>> step 4: ethtool ethX --> see the result of "Link detected" is no.
>>>>
>>> Step 3 and 4 seem to be unrelated to the actual issue.
>>> With which MAC + PHY driver did you observe this?
>>>
>> Thanks Heiner,
>>
>> I tested this on HNS3 driver, with two phy, Marvell 88E1512 and RTL8211.
>>
>> Step 3 and Step 4 is just to describe that the LED of link shows link up,
>> but the port information shows no link.
>>
> ethtool refers to the link at MAC level. Therefore default implementation
> ethtool_op_get_link just returns the result of netif_carrier_ok().
> Also using PHY link status if interface is down doesn't really make sense:
> - phylib state machine isn't running, therefore PHY status doesn't get updated
> - often MAC drivers shut down parts of the MAC on ndo_close, this typically
> makes the internal MDIO bus unaccessible
> So just remove steps 3 and 4. The patch itself is fine with me.
>
OK, I will fix the commit log.
Thanks, Heiner.
>>
>>>> This patch forces phy suspend even phydev->link is off.
>>>>
>>>> Signed-off-by: Jian Shen <shenjian15@huawei.com>
>>>> ---
>>>> drivers/net/phy/phy.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>>>> index f3adea9..0acd5b4 100644
>>>> --- a/drivers/net/phy/phy.c
>>>> +++ b/drivers/net/phy/phy.c
>>>> @@ -911,8 +911,8 @@ void phy_state_machine(struct work_struct *work)
>>>> if (phydev->link) {
>>>> phydev->link = 0;
>>>> phy_link_down(phydev, true);
>>>> - do_suspend = true;
>>>> }
>>>> + do_suspend = true;
>>>> break;
>>>> }
>>>>
>>>>
>>> Heiner
>>>
>>>
>>
>>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF
From: Andy Lutomirski @ 2019-08-28 1:12 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andy Lutomirski, Alexei Starovoitov, Kees Cook, LSM List,
James Morris, Jann Horn, Peter Zijlstra, Masami Hiramatsu,
David S. Miller, Daniel Borkmann, Network Development, bpf,
kernel-team, Linux API
In-Reply-To: <20190827204433.3af91faf@gandalf.local.home>
> On Aug 27, 2019, at 5:44 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 27 Aug 2019 16:34:47 -0700
> Andy Lutomirski <luto@kernel.org> wrote:
>
>>>> CAP_TRACING does not override normal permissions on sysfs or debugfs.
>>>> This means that, unless a new interface for programming kprobes and
>>>> such is added, it does not directly allow use of kprobes.
>>>
>>> kprobes can be created in the tracefs filesystem (which is separate from
>>> debugfs, tracefs just gets automatically mounted
>>> in /sys/kernel/debug/tracing when debugfs is mounted) from the
>>> kprobe_events file. /sys/kernel/tracing is just the tracefs
>>> directory without debugfs, and was created specifically to allow
>>> tracing to be access without opening up the can of worms in debugfs.
>>
>> I think that, in principle, CAP_TRACING should allow this, but I'm not
>> sure how to achieve that. I suppose we could set up
>> inode_operations.permission on tracefs, but what exactly would it do?
>> Would it be just like generic_permission() except that it would look
>> at CAP_TRACING instead of CAP_DAC_OVERRIDE? That is, you can use
>> tracefs if you have CAP_TRACING *or* acl access? Or would it be:
>>
>> int tracing_permission(struct inode *inode, int mask)
>> {
>> if (!capable(CAP_TRACING))
>> return -EPERM;
>>
>> return generic_permission(inode, mask);
>> }
>
> Perhaps we should make a group for it?
>
Hmm. That means that you’d need CAP_TRACING and a group. That’s probably not terrible, but it could be annoying.
>>
>> Which would mean that you need ACL *and* CAP_TRACING, so
>> administrators would change the mode to 777. That's a bit scary.
>>
>> And this still doesn't let people even *find* tracefs, since it's
>> hidden in debugfs.
>>
>> So maybe make CAP_TRACING override ACLs but also add /sys/fs/tracing
>> and mount tracefs there, too, so that regular users can at least find
>> the mountpoint.
>
> I think you missed what I said. It's not hidden in /sys/kernel/debug.
> If you enable tracefs, you have /sys/kernel/tracing created, and is
> completely separate from debugfs. I only have it *also* automatically
> mounted to /sys/kernel/debug/tracing for backward compatibility
> reasons, as older versions of trace-cmd will only mount debugfs (as
> root), and expect to find it there.
>
> mount -t tracefs nodev /sys/kernel/tracing
Too many slashes :/
A group could work for v1. Maybe all the tools should get updated to use this path?
>
> -- Steve
>
>>
>>>
>>> Should we allow CAP_TRACING access to /proc/kallsyms? as it is helpful
>>> to convert perf and trace-cmd's function pointers into names. Once you
>>> allow tracing of the kernel, hiding /proc/kallsyms is pretty useless.
>>
>> I think we should.
>
^ permalink raw reply
* [PATCH net-next] net: phy: force phy suspend when calling phy_stop
From: Jian Shen @ 2019-08-28 1:34 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, sergei.shtylyov
Cc: netdev, forest.zhouchang, linuxarm
Some ethernet drivers may call phy_start() and phy_stop() from
ndo_open() and ndo_close() respectively.
When network cable is unconnected, and operate like below:
step 1: ifconfig ethX up -> ndo_open -> phy_start ->start
autoneg, and phy is no link.
step 2: ifconfig ethX down -> ndo_close -> phy_stop -> just stop
phy state machine.
This patch forces phy suspend even phydev->link is off.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f3adea9..0acd5b4 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -911,8 +911,8 @@ void phy_state_machine(struct work_struct *work)
if (phydev->link) {
phydev->link = 0;
phy_link_down(phydev, true);
- do_suspend = true;
}
+ do_suspend = true;
break;
}
--
2.8.1
^ permalink raw reply related
* [PATCH net v3 0/2] r8152: fix side effect
From: Hayes Wang @ 2019-08-28 1:51 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-314-Taiwan-albertk@realtek.com>
v3:
Update the commit message for patch #1.
v2:
Replace patch #2 with "r8152: remove calling netif_napi_del".
v1:
The commit 0ee1f4734967 ("r8152: napi hangup fix after disconnect")
add a check to avoid using napi_disable after netif_napi_del. However,
the commit ffa9fec30ca0 ("r8152: set RTL8152_UNPLUG only for real
disconnection") let the check useless.
Therefore, I revert commit 0ee1f4734967 ("r8152: napi hangup fix
after disconnect") first, and add another patch to fix it.
Hayes Wang (2):
Revert "r8152: napi hangup fix after disconnect"
r8152: remove calling netif_napi_del
drivers/net/usb/r8152.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH net v3 1/2] Revert "r8152: napi hangup fix after disconnect"
From: Hayes Wang @ 2019-08-28 1:51 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-320-Taiwan-albertk@realtek.com>
This reverts commit 0ee1f4734967af8321ecebaf9c74221ace34f2d5.
The commit 0ee1f4734967 ("r8152: napi hangup fix after
disconnect") adds a check about RTL8152_UNPLUG to determine
if calling napi_disable() is invalid in rtl8152_close(),
when rtl8152_disconnect() is called. This avoids to use
napi_disable() after calling netif_napi_del().
Howver, commit ffa9fec30ca0 ("r8152: set RTL8152_UNPLUG
only for real disconnection") causes that RTL8152_UNPLUG
is not always set when calling rtl8152_disconnect().
Therefore, I have to revert commit 0ee1f4734967 ("r8152:
napi hangup fix after disconnect"), first. And submit
another patch to fix it.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index eee0f5007ee3..ad3abe26b51b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4021,8 +4021,7 @@ static int rtl8152_close(struct net_device *netdev)
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- if (!test_bit(RTL8152_UNPLUG, &tp->flags))
- napi_disable(&tp->napi);
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
--
2.21.0
^ permalink raw reply related
* [PATCH net v3 2/2] r8152: remove calling netif_napi_del
From: Hayes Wang @ 2019-08-28 1:51 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-320-Taiwan-albertk@realtek.com>
Remove unnecessary use of netif_napi_del. This also avoids to call
napi_disable() after netif_napi_del().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ad3abe26b51b..04137ac373b0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -5352,7 +5352,6 @@ static int rtl8152_probe(struct usb_interface *intf,
return 0;
out1:
- netif_napi_del(&tp->napi);
usb_set_intfdata(intf, NULL);
out:
free_netdev(netdev);
@@ -5367,7 +5366,6 @@ static void rtl8152_disconnect(struct usb_interface *intf)
if (tp) {
rtl_set_unplug(tp);
- netif_napi_del(&tp->napi);
unregister_netdev(tp->netdev);
cancel_delayed_work_sync(&tp->hw_phy_work);
tp->rtl_ops.unload(tp);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF
From: Andy Lutomirski @ 2019-08-28 2:00 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Alexei Starovoitov, Alexei Starovoitov, Kees Cook, LSM List,
James Morris, Jann Horn, Peter Zijlstra, Masami Hiramatsu,
Steven Rostedt, David S. Miller, Daniel Borkmann,
Network Development, bpf, kernel-team, Linux API
In-Reply-To: <CALCETrVbPPPr=BdPAx=tJKxD3oLXP4OVSgCYrB_E4vb6idELow@mail.gmail.com>
> On Aug 27, 2019, at 5:55 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
> From the previous discussion, you want to make progress toward solving
> a lot of problems with CAP_BPF. One of them was making BPF
> firewalling more generally useful. By making CAP_BPF grant the ability
> to read kernel memory, you will make administrators much more nervous
> to grant CAP_BPF. Similarly, and correct me if I'm wrong, most of
> these capabilities are primarily or only useful for tracing, so I
> don't see why users without CAP_TRACING should get them.
> bpf_trace_printk(), in particular, even has "trace" in its name :)
>
> Also, if a task has CAP_TRACING, it's expected to be able to trace the
> system -- that's the whole point. Why shouldn't it be able to use BPF
> to trace the system better?
Let me put this a bit differently. Part of the point is that
CAP_TRACING should allow a user or program to trace without being able
to corrupt the system. CAP_BPF as you’ve proposed it *can* likely
crash the system. For example, CAP_BPF allows bpf_map_get_fd_by_id()
in your patch. If the system uses a BPF firewall that stores some of
its rules in maps, then bpf_map_get_fd_by_id() can be used to get a
writable fd to the map, which can be used to change the map, thus
preventing network access. This means that no combination of
CAP_TRACING and CAP_BPF ends up allowing tracing without granting the
ability to reconfigure or otherwise corrupt the system.
^ permalink raw reply
* RE: [PATCH] r8152: Add rx_buf_sz field to struct r8152
From: Hayes Wang @ 2019-08-28 2:04 UTC (permalink / raw)
To: Prashant Malani, davem@davemloft.net
Cc: grundler@chromium.org, netdev@vger.kernel.org, nic_swsd
In-Reply-To: <20190827180146.253431-1-pmalani@chromium.org>
Prashant Malani [mailto:pmalani@chromium.org]
> Sent: Wednesday, August 28, 2019 2:02 AM
> To: Hayes Wang; davem@davemloft.net
> Cc: grundler@chromium.org; netdev@vger.kernel.org; nic_swsd; Prashant
> Malani
> Subject: [PATCH] r8152: Add rx_buf_sz field to struct r8152
>
> tp->rx_buf_sz is set according to the specific version of HW being used.
>
> agg_buf_sz was originally added to support LSO (Large Send Offload) and
> then seems to have been co-opted for LRO (Large Receive Offload). But RX
> large buffer size can be larger than TX large buffer size with newer HW.
> Using larger buffers can result in fewer "large RX packets" processed
> by the rest of the networking stack to reduce RX CPU utilization.
>
> This patch is copied from the r8152 driver (v2.12.0) published by
> Realtek (www.realtek.com).
>
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
> Reviewed-by: Grant Grundler <grundler@chromium.org>
> ---
It seems as same as the commit ec5791c202ac ("r8152: separate the rx
buffer size").
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/
commit/?id=ec5791c202aca90c1b3b99dff268a995cf2d6aa1
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF
From: Steven Rostedt @ 2019-08-28 2:22 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Alexei Starovoitov, Kees Cook, LSM List,
James Morris, Jann Horn, Peter Zijlstra, Masami Hiramatsu,
David S. Miller, Daniel Borkmann, Network Development, bpf,
kernel-team, Linux API
In-Reply-To: <A95DA1BC-E2A1-4CC3-B17F-36C494FB7540@amacapital.net>
On Tue, 27 Aug 2019 18:12:59 -0700
Andy Lutomirski <luto@amacapital.net> wrote:
> Too many slashes :/
>
> A group could work for v1. Maybe all the tools should get updated to use this path?
trace-cmd now does. In fact, if run as root, it will first check if
tracefs is mounted, and if not, it will try to mount it at this
location.
-- Steve
^ permalink raw reply
* [PATCH v2] ipv6: Not to probe neighbourless routes
From: Yi Wang @ 2019-08-28 2:19 UTC (permalink / raw)
To: davem
Cc: kuznet, yoshfuji, netdev, linux-kernel, xue.zhihong, wang.yi59,
wang.liang82, Cheng Lin
From: Cheng Lin <cheng.lin130@zte.com.cn>
Originally, Router Reachability Probing require a neighbour entry
existed. Commit 2152caea7196 ("ipv6: Do not depend on rt->n in
rt6_probe().") removed the requirement for a neighbour entry. And
commit f547fac624be ("ipv6: rate-limit probes for neighbourless
routes") adds rate-limiting for neighbourless routes.
And, the Neighbor Discovery for IP version 6 (IPv6)(rfc4861) says,
"
7.2.5. Receipt of Neighbor Advertisements
When a valid Neighbor Advertisement is received (either solicited or
unsolicited), the Neighbor Cache is searched for the target's entry.
If no entry exists, the advertisement SHOULD be silently discarded.
There is no need to create an entry if none exists, since the
recipient has apparently not initiated any communication with the
target.
".
In rt6_probe(), just a Neighbor Solicitation message are transmited.
When receiving a Neighbor Advertisement, the node does nothing in a
Neighborless condition.
Not sure it's needed to create a neighbor entry in Router
Reachability Probing. And the Original way may be the right way.
This patch recover the requirement for a neighbour entry.
Signed-off-by: Cheng Lin <cheng.lin130@zte.com.cn>
---
include/net/ip6_fib.h | 5 -----
net/ipv6/route.c | 6 +-----
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 4b5656c..8c2e022 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -124,11 +124,6 @@ struct rt6_exception {
struct fib6_nh {
struct fib_nh_common nh_common;
-
-#ifdef CONFIG_IPV6_ROUTER_PREF
- unsigned long last_probe;
-#endif
-
struct rt6_info * __percpu *rt6i_pcpu;
struct rt6_exception_bucket __rcu *rt6i_exception_bucket;
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index fd059e0..1839dd7 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -639,12 +639,12 @@ static void rt6_probe(struct fib6_nh *fib6_nh)
nh_gw = &fib6_nh->fib_nh_gw6;
dev = fib6_nh->fib_nh_dev;
rcu_read_lock_bh();
- idev = __in6_dev_get(dev);
neigh = __ipv6_neigh_lookup_noref(dev, nh_gw);
if (neigh) {
if (neigh->nud_state & NUD_VALID)
goto out;
+ idev = __in6_dev_get(dev);
write_lock(&neigh->lock);
if (!(neigh->nud_state & NUD_VALID) &&
time_after(jiffies,
@@ -654,13 +654,9 @@ static void rt6_probe(struct fib6_nh *fib6_nh)
__neigh_set_probe_once(neigh);
}
write_unlock(&neigh->lock);
- } else if (time_after(jiffies, fib6_nh->last_probe +
- idev->cnf.rtr_probe_interval)) {
- work = kmalloc(sizeof(*work), GFP_ATOMIC);
}
if (work) {
- fib6_nh->last_probe = jiffies;
INIT_WORK(&work->work, rt6_probe_deferred);
work->target = *nh_gw;
dev_hold(dev);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] ipv6: Not to probe neighbourless routes
From: David Miller @ 2019-08-28 3:13 UTC (permalink / raw)
To: wang.yi59
Cc: kuznet, yoshfuji, netdev, linux-kernel, xue.zhihong, wang.liang82,
cheng.lin130
In-Reply-To: <1566958765-1686-1-git-send-email-wang.yi59@zte.com.cn>
Because you didn't even compile test the previous patch, I want to
know how you did functional testing on this version on current kernel
versions?
^ permalink raw reply
* Re: [PATCH v5 net-next 02/18] ionic: Add hardware init and device commands
From: Jakub Kicinski @ 2019-08-28 3:16 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev, davem
In-Reply-To: <a2ed5049-14c6-749c-9a9b-f826d9a88cb0@pensando.io>
On Tue, 27 Aug 2019 14:22:55 -0700, Shannon Nelson wrote:
> >> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
> >> index e24ef6971cd5..1ca1e33cca04 100644
> >> --- a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
> >> +++ b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
> >> @@ -11,8 +11,28 @@
> >> static int ionic_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
> >> struct netlink_ext_ack *extack)
> >> {
> >> + struct ionic *ionic = devlink_priv(dl);
> >> + struct ionic_dev *idev = &ionic->idev;
> >> + char buf[16];
> >> +
> >> devlink_info_driver_name_put(req, IONIC_DRV_NAME);
> >>
> >> + devlink_info_version_running_put(req,
> >> + DEVLINK_INFO_VERSION_GENERIC_FW_MGMT,
> >> + idev->dev_info.fw_version);
> > Are you sure this is not the FW that controls the data path?
>
> There is only one FW rev to report, and this covers mgmt and data.
Can you add a key for that? Cause this one clearly says management..
> >
> >> + snprintf(buf, sizeof(buf), "0x%x", idev->dev_info.asic_type);
> >> + devlink_info_version_fixed_put(req,
> >> + DEVLINK_INFO_VERSION_GENERIC_BOARD_ID,
> >> + buf);
> > Board ID is not ASIC. This is for identifying a board version with all
> > its components which surround the main ASIC.
> >
> >> + snprintf(buf, sizeof(buf), "0x%x", idev->dev_info.asic_rev);
> >> + devlink_info_version_fixed_put(req,
> >> + DEVLINK_INFO_VERSION_GENERIC_BOARD_REV,
> >> + buf);
> > ditto
>
> Since I don't have any board info available at this point, shall I use
> my own "asic.id" and "asic.rev" strings, or in this patch shall I add
> something like this to devlink.h and use them here:
>
> /* Part number, identifier of asic design */
> #define DEVLINK_INFO_VERSION_GENERIC_ASIC_ID "asic.id"
> /* Revision of asic design */
> #define DEVLINK_INFO_VERSION_GENERIC_ASIC_REV "asic.rev"
Yes, please add these to the generic items and document appropriately.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: dsa: explicit programmation of VLAN on CPU ports
From: David Miller @ 2019-08-28 3:17 UTC (permalink / raw)
To: olteanv; +Cc: vivien.didelot, netdev, f.fainelli, andrew
In-Reply-To: <CA+h21hqPTqzCPPYqF1zvbGhu=yeqPFQ_X77xtfmt1mzENDQ9Dw@mail.gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Sun, 25 Aug 2019 21:27:23 +0300
> On Sun, 25 Aug 2019 at 20:25, Vivien Didelot <vivien.didelot@gmail.com> wrote:
>>
>> When a VLAN is programmed on a user port, every switch of the fabric also
>> program the CPU ports and the DSA links as part of the VLAN. To do that,
>> DSA makes use of bitmaps to prepare all members of a VLAN.
>>
>> While this is expected for DSA links which are used as conduit between
>> interconnected switches, only the dedicated CPU port of the slave must be
>> programmed, not all CPU ports of the fabric. This may also cause problems in
>> other corners of DSA such as the tag_8021q.c driver, which needs to program
>> its ports manually, CPU port included.
>>
>> We need the dsa_port_vlan_{add,del} functions and its dsa_port_vid_{add,del}
>> variants to simply trigger the VLAN programmation without any logic in them,
>> but they may currently skip the operation based on the bridge device state.
>>
>> This patchset gets rid of the bitmap operations, and moves the bridge device
>> check as well as the explicit programmation of CPU ports where they belong,
>> in the slave code.
>>
>> While at it, clear the VLAN flags before programming a CPU port, as it
>> doesn't make sense to forward the PVID flag for example for such ports.
>>
>> Changes in v2: only clear the PVID flag.
...
> For the whole series:
> Tested-by: Vladimir Oltean <olteanv@gmail.com>
> Thanks!
Series applied.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] net: ethernet: mediatek: convert to PHYLINK
From: David Miller @ 2019-08-28 3:19 UTC (permalink / raw)
To: opensource
Cc: john, sean.wang, nelson.chang, matthias.bgg, netdev,
linux-arm-kernel, linux-mediatek, linux-mips, linux, frank-w, sr
In-Reply-To: <20190825174341.20750-1-opensource@vdorst.com>
From: René van Dorst <opensource@vdorst.com>
Date: Sun, 25 Aug 2019 19:43:38 +0200
> These patches converts mediatek driver to PHYLINK API.
>
> v3->v4:
> * Phylink improvements and clean-ups after review
> v2->v3:
> * Phylink improvements and clean-ups after review
> v1->v2:
> * Rebase for mt76x8 changes
> * Phylink improvements and clean-ups after review
> * SGMII port doesn't support 2.5Gbit in SGMII mode only in BASE-X mode.
> Refactor the code.
Series applied.
^ permalink raw reply
* Re: [PATCH v2 net] Add genphy_c45_config_aneg() function to phy-c45.c
From: David Miller @ 2019-08-28 3:20 UTC (permalink / raw)
To: marco.hartmann
Cc: andrew, f.fainelli, hkallweit1, netdev, linux-kernel,
christian.herber
In-Reply-To: <1566385208-23523-1-git-send-email-marco.hartmann@nxp.com>
From: Marco Hartmann <marco.hartmann@nxp.com>
Date: Wed, 21 Aug 2019 11:00:46 +0000
> Commit 34786005eca3 ("net: phy: prevent PHYs w/o Clause 22 regs from calling
> genphy_config_aneg") introduced a check that aborts phy_config_aneg()
> if the phy is a C45 phy.
> This causes phy_state_machine() to call phy_error() so that the phy
> ends up in PHY_HALTED state.
>
> Instead of returning -EOPNOTSUPP, call genphy_c45_config_aneg()
> (analogous to the C22 case) so that the state machine can run
> correctly.
>
> genphy_c45_config_aneg() closely resembles mv3310_config_aneg()
> in drivers/net/phy/marvell10g.c, excluding vendor specific
> configurations for 1000BaseT.
>
> Fixes: 22b56e827093 ("net: phy: replace genphy_10g_driver with genphy_c45_driver")
>
> Signed-off-by: Marco Hartmann <marco.hartmann@nxp.com>
> ---
> Changes in v2:
> - corrected commit message
> - reordered variables
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v2 net] Add genphy_c45_config_aneg() function to phy-c45.c
From: David Miller @ 2019-08-28 3:22 UTC (permalink / raw)
To: marco.hartmann
Cc: andrew, f.fainelli, hkallweit1, netdev, linux-kernel,
christian.herber
In-Reply-To: <20190827.202043.766506227116086877.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 27 Aug 2019 20:20:43 -0700 (PDT)
> Applied to net-next.
My bad, applied to net and queued up for v5.2 -stable.
^ permalink raw reply
* Re: [PATCH v5 net-next 02/18] ionic: Add hardware init and device commands
From: Shannon Nelson @ 2019-08-28 3:26 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem
In-Reply-To: <20190827201646.2befe6c3@cakuba.netronome.com>
On 8/27/19 8:16 PM, Jakub Kicinski wrote:
> On Tue, 27 Aug 2019 14:22:55 -0700, Shannon Nelson wrote:
>>>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
>>>> index e24ef6971cd5..1ca1e33cca04 100644
>>>> --- a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
>>>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
>>>> @@ -11,8 +11,28 @@
>>>> static int ionic_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
>>>> struct netlink_ext_ack *extack)
>>>> {
>>>> + struct ionic *ionic = devlink_priv(dl);
>>>> + struct ionic_dev *idev = &ionic->idev;
>>>> + char buf[16];
>>>> +
>>>> devlink_info_driver_name_put(req, IONIC_DRV_NAME);
>>>>
>>>> + devlink_info_version_running_put(req,
>>>> + DEVLINK_INFO_VERSION_GENERIC_FW_MGMT,
>>>> + idev->dev_info.fw_version);
>>> Are you sure this is not the FW that controls the data path?
>> There is only one FW rev to report, and this covers mgmt and data.
> Can you add a key for that? Cause this one clearly says management..
Perhaps something like this?
/* Overall FW version */
#define DEVLINK_INFO_VERSION_GENERIC_FW "fw"
>> Since I don't have any board info available at this point, shall I use
>> my own "asic.id" and "asic.rev" strings, or in this patch shall I add
>> something like this to devlink.h and use them here:
>>
>> /* Part number, identifier of asic design */
>> #define DEVLINK_INFO_VERSION_GENERIC_ASIC_ID "asic.id"
>> /* Revision of asic design */
>> #define DEVLINK_INFO_VERSION_GENERIC_ASIC_REV "asic.rev"
> Yes, please add these to the generic items and document appropriately.
Sure. Is there any place besides
Documentation/networking/devlink-info-versions.rst?
sln
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF
From: Masami Hiramatsu @ 2019-08-28 3:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andy Lutomirski, Alexei Starovoitov, Kees Cook, LSM List,
James Morris, Jann Horn, Peter Zijlstra, Masami Hiramatsu,
David S. Miller, Daniel Borkmann, Network Development, bpf,
kernel-team, Linux API
In-Reply-To: <20190827192144.3b38b25a@gandalf.local.home>
On Tue, 27 Aug 2019 19:21:44 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> > Here's my proposal for CAP_TRACING, documentation-style:
> >
> > --- begin ---
> >
> > CAP_TRACING enables a task to use various kernel features to trace
> > running user programs and the kernel itself. CAP_TRACING also enables
> > a task to bypass some speculation attack countermeasures. A task in
> > the init user namespace with CAP_TRACING will be able to tell exactly
> > what kernel code is executed and when, and will be able to read kernel
> > registers and kernel memory. It will, similarly, be able to read the
> > state of other user tasks.
> >
> > Specifically, CAP_TRACING allows the following operations. It may
> > allow more operations in the future:
> >
> > - Full use of perf_event_open(), similarly to the effect of
> > kernel.perf_event_paranoid == -1.
> >
> > - Loading and attaching tracing BPF programs, including use of BPF
> > raw tracepoints.
> >
> > - Use of BPF stack maps.
> >
> > - Use of bpf_probe_read() and bpf_trace_printk().
> >
> > - Use of unsafe pointer-to-integer conversions in BPF.
> >
> > - Bypassing of BPF's speculation attack hardening measures and
> > constant blinding. (Note: other mechanisms might also allow this.)
> >
> > CAP_TRACING does not override normal permissions on sysfs or debugfs.
> > This means that, unless a new interface for programming kprobes and
> > such is added, it does not directly allow use of kprobes.
>
> kprobes can be created in the tracefs filesystem (which is separate from
> debugfs, tracefs just gets automatically mounted
> in /sys/kernel/debug/tracing when debugfs is mounted) from the
> kprobe_events file. /sys/kernel/tracing is just the tracefs
> directory without debugfs, and was created specifically to allow
> tracing to be access without opening up the can of worms in debugfs.
I like the CAP_TRACING for tracefs. Can we make the tracefs itself
check the CAP_TRACING and call file_ops? or each tracefs file-ops
handlers must check it?
> Should we allow CAP_TRACING access to /proc/kallsyms? as it is helpful
> to convert perf and trace-cmd's function pointers into names. Once you
> allow tracing of the kernel, hiding /proc/kallsyms is pretty useless.
Also, there is a blacklist of kprobes under debugfs. If CAP_TRACING
introduced and it allows to access kallsyms, I would like to move the
blacklist under tracefs, or make an alias of blacklist entry on tracefs.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH net] net: dsa: tag_8021q: Future-proof the reserved fields in the custom VID
From: David Miller @ 2019-08-28 3:32 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190825183212.11426-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Sun, 25 Aug 2019 21:32:12 +0300
> After witnessing the discussion in https://lkml.org/lkml/2019/8/14/151
> w.r.t. ioctl extensibility, it became clear that such an issue might
> prevent that the 3 RSV bits inside the DSA 802.1Q tag might also suffer
> the same fate and be useless for further extension.
>
> So clearly specify that the reserved bits should currently be
> transmitted as zero and ignored on receive. The DSA tagger already does
> this (and has always did), and is the only known user so far (no
> Wireshark dissection plugin, etc). So there should be no incompatibility
> to speak of.
>
> Fixes: 0471dd429cea ("net: dsa: tag_8021q: Create a stable binary format")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Applied and queued up for v5.2 -stable.
^ permalink raw reply
* Re: [PATCH v5 net-next 02/18] ionic: Add hardware init and device commands
From: Jakub Kicinski @ 2019-08-28 3:34 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev, davem
In-Reply-To: <93a16cf5-b8a2-8915-4190-b81607058eb2@pensando.io>
On Tue, 27 Aug 2019 20:26:59 -0700, Shannon Nelson wrote:
> On 8/27/19 8:16 PM, Jakub Kicinski wrote:
> > On Tue, 27 Aug 2019 14:22:55 -0700, Shannon Nelson wrote:
> >>>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
> >>>> index e24ef6971cd5..1ca1e33cca04 100644
> >>>> --- a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
> >>>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
> >>>> @@ -11,8 +11,28 @@
> >>>> static int ionic_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
> >>>> struct netlink_ext_ack *extack)
> >>>> {
> >>>> + struct ionic *ionic = devlink_priv(dl);
> >>>> + struct ionic_dev *idev = &ionic->idev;
> >>>> + char buf[16];
> >>>> +
> >>>> devlink_info_driver_name_put(req, IONIC_DRV_NAME);
> >>>>
> >>>> + devlink_info_version_running_put(req,
> >>>> + DEVLINK_INFO_VERSION_GENERIC_FW_MGMT,
> >>>> + idev->dev_info.fw_version);
> >>> Are you sure this is not the FW that controls the data path?
> >> There is only one FW rev to report, and this covers mgmt and data.
> > Can you add a key for that? Cause this one clearly says management..
>
> Perhaps something like this?
>
> /* Overall FW version */
> #define DEVLINK_INFO_VERSION_GENERIC_FW "fw"
Sounds reasonable.
> >> Since I don't have any board info available at this point, shall I use
> >> my own "asic.id" and "asic.rev" strings, or in this patch shall I add
> >> something like this to devlink.h and use them here:
> >>
> >> /* Part number, identifier of asic design */
> >> #define DEVLINK_INFO_VERSION_GENERIC_ASIC_ID "asic.id"
> >> /* Revision of asic design */
> >> #define DEVLINK_INFO_VERSION_GENERIC_ASIC_REV "asic.rev"
> > Yes, please add these to the generic items and document appropriately.
>
> Sure. Is there any place besides
> Documentation/networking/devlink-info-versions.rst?
Nope, that's the one.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Simplify DSA handling of VLAN subinterface offload
From: David Miller @ 2019-08-28 3:46 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190825194630.12404-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Sun, 25 Aug 2019 22:46:28 +0300
> Depends on Vivien Didelot's patchset:
> https://patchwork.ozlabs.org/project/netdev/list/?series=127197&state=*
>
> This patchset removes a few strange-looking guards for -EOPNOTSUPP in
> dsa_slave_vlan_rx_add_vid and dsa_slave_vlan_rx_kill_vid, making that
> code path no longer possible.
>
> It also disables the code path for the sja1105 driver, which does
> support editing the VLAN table, but not hardware-accelerated VLAN
> sub-interfaces, therefore the check in the DSA core would be wrong.
> There was no better DSA callback to do this than .port_enable, i.e.
> at ndo_open time.
Series applied.
^ permalink raw reply
* Re: [PATCH v2 -next] net: mediatek: remove set but not used variable 'status'
From: David Miller @ 2019-08-28 3:48 UTC (permalink / raw)
To: maowenan
Cc: nbd, john, sean.wang, nelson.chang, matthias.bgg, kernel-janitors,
netdev, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20190826013118.22720-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Mon, 26 Aug 2019 09:31:18 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function mtk_handle_irq:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:1951:6: warning: variable status set but not used [-Wunused-but-set-variable]
>
> Fixes: 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v3] net: fix skb use after free in netpoll
From: David Miller @ 2019-08-28 3:52 UTC (permalink / raw)
To: loyou85
Cc: edumazet, dsterba, dbanerje, fw, davej, tglx, matwey,
sakari.ailus, netdev, linux-kernel, xiaojunzhao141
In-Reply-To: <1566801964-14691-1-git-send-email-loyou85@gmail.com>
From: Feng Sun <loyou85@gmail.com>
Date: Mon, 26 Aug 2019 14:46:04 +0800
> After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
> ("tun: return NET_XMIT_DROP for dropped packets"),
> when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
> netpoll_send_skb_on_dev will run into following use after free cases:
> 1. retry netpoll_start_xmit with freed skb;
> 2. queue freed skb in npinfo->txq.
> queue_process will also run into use after free case.
>
> hit netpoll_send_skb_on_dev first case with following kernel log:
...
> Signed-off-by: Feng Sun <loyou85@gmail.com>
> Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 0/3] sctp: add SCTP_ECN_SUPPORTED sockopt
From: David Miller @ 2019-08-28 3:55 UTC (permalink / raw)
To: nhorman; +Cc: lucien.xin, netdev, linux-sctp, marcelo.leitner
In-Reply-To: <20190826110221.GA7831@hmswarspite.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 26 Aug 2019 07:02:21 -0400
> On Mon, Aug 26, 2019 at 04:30:01PM +0800, Xin Long wrote:
>> This patchset is to make ecn flag per netns and endpoint and then
>> add SCTP_ECN_SUPPORTED sockopt, as does for other feature flags.
>>
>> Xin Long (3):
>> sctp: make ecn flag per netns and endpoint
>> sctp: allow users to set netns ecn flag with sysctl
>> sctp: allow users to set ep ecn flag by sockopt
...
> Series
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net] net/rds: Fix info leak in rds6_inc_info_copy()
From: David Miller @ 2019-08-28 4:08 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <1566812352-27332-1-git-send-email-ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Mon, 26 Aug 2019 02:39:12 -0700
> The rds6_inc_info_copy() function has a couple struct members which
> are leaking stack information. The ->tos field should hold actual
> information and the ->flags field needs to be zeroed out.
>
> Fixes: 3eb450367d08 ("rds: add type of service(tos) infrastructure")
> Fixes: b7ff8b1036f0 ("rds: Extend RDS API for IPv6 support")
> Reported-by: 黄ID蝴蝶 <butterflyhuangxx@gmail.com>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Applied and queued up for -stable.
^ 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