* tg3 pxe weirdness
From: Berend De Schouwer @ 2017-09-21 14:23 UTC (permalink / raw)
To: netdev
Hi,
I've got a machine with a Broadcom bcm5762c, using the tg3 driver, that
fails to receive network packets under some very specific conditions.
It works perfectly using a 1Gbps switch. If, however, it first uses
PXE and then loads the Linux tg3 driver, and the switch is 100Mbps, it
no longer receives packets larger than ICMP.
It does do ARP and ping.
If it boots using PXE on a 1Gbps switch, boots into Linux, and then
it's plugged into 100 Mbps it also stops receiving packets.
mii-diag and dmesg confirm auto-negotiated speed and flow control, and
confirm temporary disconnect as the cables are moved.
PXE boots using UNDI, which then transfers a kernel using TFTP, which
transfers correctly. The kernel boots, loads the tg3 driver, connects
the network. Up to this point everything works. Ping will work too.
Any other network traffic fails.
Booting from a harddrive works fine. I assume the UNDI driver
somewhere breaks auto-negotiation. I've tried using mii-tool and
ethtool, but I haven't managed to make it work yet.
Is it possible to get negotiation working after PXE boot? Are there
any tg3 driver flags that might make a difference?
Berend
^ permalink raw reply
* Re: [PATCH net 1/3] net: mvpp2: fix the dma_mask and coherent_dma_mask settings for PPv2.2
From: Antoine Tenart @ 2017-09-21 14:24 UTC (permalink / raw)
To: David Miller
Cc: antoine.tenart, andrew, gregory.clement, thomas.petazzoni,
miquel.raynal, nadavh, linux, linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170918.171858.667084185425779267.davem@davemloft.net>
Hi David,
On Mon, Sep 18, 2017 at 05:18:58PM -0700, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
> Date: Mon, 18 Sep 2017 15:04:06 +0200
>
> > The dev->dma_mask usually points to dev->coherent_dma_mask. This is an
> > issue as setting both of them will override the other. This is
> > problematic here as the PPv2 driver uses a 32-bit-mask for coherent
> > accesses (txq, rxq, bm) and a 40-bit mask for all other accesses due to
> > an hardware limitation.
> >
> > This can lead to a memory remap for all dma_map_single() calls when
> > dealing with memory above 4GB.
> >
> > Fixes: 2067e0a13cfe ("net: mvpp2: set dma mask and coherent dma mask on PPv2.2")
> > Reported-by: Stefan Chulski <stefanc@marvell.com>
> > Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>
> I surrmise that if the platform has made dev->dma_mask point to
> &dev->coherent_dma_mask, it is because it does not allow the two
> settings to be set separately.
That's also the default when the platform does not allocate dma_mask.
You have a point, that could be because it's not supported. But I don't
know what would be a good check then.
> By rearranging the pointer, you are bypassing that, and probably
> breaking things or creating a situation that the DMA mapping
> layer is not expecting.
>
> I want to know more about the situations where dma_mask is set to
> point to &coherent_dma_mask and how that is supposed to work.
>From what I see in other parts of the kernel, dma_mask points to
&coherent_dma_mask by default and having two different values for these
two masks isn't a use case for many drivers.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of unicast traffic
From: Vivien Didelot @ 2017-09-21 14:26 UTC (permalink / raw)
To: Egil Hjelmeland, andrew, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20170921094139.4250-3-privat@egil-hjelmeland.no>
Hi Egil,
Egil Hjelmeland <privat@egil-hjelmeland.no> writes:
> When both user ports are joined to the same bridge, the normal
> HW MAC learning is enabled. This means that unicast traffic is forwarded
> in HW.
>
> If one of the user ports leave the bridge,
> the ports goes back to the initial separated operation.
>
> Port separation relies on disabled HW MAC learning. Hence the condition
> that both ports must join same bridge.
>
> Add brigde methods port_bridge_join, port_bridge_leave and
> port_stp_state_set.
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
Styling nitpicks below, other than that, the patch LGTM:
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> #include <linux/mutex.h>
> #include <linux/mii.h>
> #include <linux/phy.h>
> +#include <linux/if_bridge.h>
It's nice to order header inclusions alphabetically.
>
> #include "lan9303.h"
>
> @@ -146,6 +147,7 @@
> # define LAN9303_SWE_PORT_STATE_FORWARDING_PORT0 (0)
> # define LAN9303_SWE_PORT_STATE_LEARNING_PORT0 BIT(1)
> # define LAN9303_SWE_PORT_STATE_BLOCKING_PORT0 BIT(0)
> +# define LAN9303_SWE_PORT_STATE_DISABLED_PORT0 (3)
> #define LAN9303_SWE_PORT_MIRROR 0x1846
> # define LAN9303_SWE_PORT_MIRROR_SNIFF_ALL BIT(8)
> # define LAN9303_SWE_PORT_MIRROR_SNIFFER_PORT2 BIT(7)
> @@ -431,6 +433,20 @@ static int lan9303_read_switch_reg(struct lan9303 *chip, u16 regnum, u32 *val)
> return ret;
> }
>
> +static int lan9303_write_switch_reg_mask(
> + struct lan9303 *chip, u16 regnum, u32 val, u32 mask)
That is unlikely to respect the Kernel Coding Style. Please fill the
line as much as possible and align with the opening parenthesis:
static int lan9303_write_switch_reg_mask(struct lan9303 *chip, u16 regnum,
u32 val, u32 mask)
> +{
> + int ret;
> + u32 reg;
> +
> + ret = lan9303_read_switch_reg(chip, regnum, ®);
> + if (ret)
> + return ret;
> + reg = (reg & ~mask) | val;
> +
> + return lan9303_write_switch_reg(chip, regnum, reg);
> +}
...
> +
> + portmask = 0x3 << (port * 2);
> + portstate <<= (port * 2);
Unnecessary alignment, please remove the extra space characters.
> + lan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,
> + portstate, portmask);
> +}
> +
> static const struct dsa_switch_ops lan9303_switch_ops = {
> .get_tag_protocol = lan9303_get_tag_protocol,
> .setup = lan9303_setup,
> @@ -855,6 +940,9 @@ static const struct dsa_switch_ops lan9303_switch_ops = {
> .get_sset_count = lan9303_get_sset_count,
> .port_enable = lan9303_port_enable,
> .port_disable = lan9303_port_disable,
> + .port_bridge_join = lan9303_port_bridge_join,
> + .port_bridge_leave = lan9303_port_bridge_leave,
> + .port_stp_state_set = lan9303_port_stp_state_set,
Same here, alignment unnecessary, especially since the rest of the
structure does not do that.
> };
>
> static int lan9303_register_switch(struct lan9303 *chip)
> diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
> index 4d8be555ff4d..5be246f05965 100644
> --- a/drivers/net/dsa/lan9303.h
> +++ b/drivers/net/dsa/lan9303.h
> @@ -21,6 +21,7 @@ struct lan9303 {
> struct dsa_switch *ds;
> struct mutex indirect_mutex; /* protect indexed register access */
> const struct lan9303_phy_ops *ops;
> + bool is_bridged; /* true if port 1 and 2 is bridged */
> };
>
> extern const struct regmap_access_table lan9303_register_set;
Please use the checkpatch.pl script to ensure your patch respects the
kernel conventions before submitting, it can spot nice stuffs!
I use a Git alias(*) to check a commit which does basically this:
git format-patch --stdout -1 | ./scripts/checkpatch.pl -
(*) in details, especially convenient during interactive rebases:
$ git config alias.checkcommit '!f () { git format-patch --stdout -1 ${1:-HEAD} | ./scripts/checkpatch.pl - ; }; f'
$ git checkcommit # i.e. current one
$ git checkcommit HEAD^^
$ git checkcommit d329ac88eb21
...
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net 2/4] net:ethernet:aquantia: Fix Tx queue hangups
From: Igor Russkikh @ 2017-09-21 14:31 UTC (permalink / raw)
To: Yunsheng Lin, David S . Miller
Cc: netdev, David Arcari, Pavel Belous, Nadezhda Krupnina,
Simon Edelhaus
In-Reply-To: <024e7fb3-9b53-f4f2-3901-38a63c47d76c@huawei.com>
Thanks for the comments, Yunsheng,
>>
>> +static int aq_nic_update_link_status(struct aq_nic_s *self)
>> +{
>> + int err = self->aq_hw_ops.hw_get_link_status(self->aq_hw);
>> +
>> + if (err < 0)
>> + return -1;
> why not just return err?
Agreed, that could be improved.
>> + if (self->link_status.mbps != self->aq_hw->aq_link_status.mbps)
>> + pr_info("%s: link change old %d new %d\n",
>> + AQ_CFG_DRV_NAME, self->link_status.mbps,
>> + self->aq_hw->aq_link_status.mbps);
> You has ndev in struct aq_nic_s *self, why not use netdev_*?
We are planning to introduce a generic rework commit separately and use netif_* set of macro's through all the driver's code.
--
BR, Igor
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging
From: Vivien Didelot @ 2017-09-21 14:40 UTC (permalink / raw)
To: Egil Hjelmeland, andrew, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20170921094139.4250-2-privat@egil-hjelmeland.no>
Hi Egil,
Egil Hjelmeland <privat@egil-hjelmeland.no> writes:
> Prepare for next patch:
> Move tag setup from lan9303_separate_ports() to new function
> lan9303_setup_tagging()
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
Minor styling issues, otherwise LGTM:
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> +/* forward special tagged packets from port 0 to port 1 *or* port 2 */
> +static int lan9303_setup_tagging(struct lan9303 *chip)
> +{
> + int ret;
> + /* enable defining the destination port via special VLAN tagging
> + * for port 0
> + */
> + ret = lan9303_write_switch_reg(chip, LAN9303_SWE_INGRESS_PORT_TYPE,
> + LAN9303_SWE_INGRESS_PORT_TYPE_VLAN);
> + if (ret)
> + return ret;
> +
> + /* tag incoming packets at port 1 and 2 on their way to port 0 to be
> + * able to discover their source port
> + */
> + return lan9303_write_switch_reg(
> + chip, LAN9303_BM_EGRSS_PORT_TYPE,
> + LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT0);
Please avoid this kind of alignment as much as possible.
u32 val = LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT0;
would do the trick for the +80 chars issue.
BTW, it'd be great to see sometime soon a cleanup patch which makes use
of such temporary u32 val variable for most of the
lan9303_write_switch_reg and lan9303_write_switch_port calls. ;-)
Thanks,
Vivien
^ permalink raw reply
* Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13
From: Kalle Valo @ 2017-09-21 14:49 UTC (permalink / raw)
To: Larry Finger
Cc: Zwindl, linux-wireless@vger.kernel.org,
chaoming_li@realsil.com.cn, pkshih@realtek.com,
johannes.berg@intel.com, gregkh@linuxfoundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5a6aa431-fdde-a329-4168-44490c37f197@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 09/21/2017 06:37 AM, Zwindl wrote:
>> Hi, I've reported to archlinux's bugzilla, and finally found out the
>> flag which caused that issue, it's the
>> `CONFIG_INTEL_IOMMU_DEFAULT_ON=y` flag, I think may this is a kernel
>> bug, more details at https://bugs.archlinux.org/task/55665
>
> My standard kernel has the following:
>
> CONFIG_INTEL_IOMMU=y
> # CONFIG_INTEL_IOMMU_SVM is not set
> # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
>
> I will do some further testing to see if turning
> CONFIG_INTEL_IOMMU_DEFAULT_ON also breaks my system.
But not all systems have iommu so check from dmesg that iommu is really
enabled.
--
Kalle Valo
^ permalink raw reply
* [PATCH net-next] net: vrf: remove skb_dst_force() after skb_dst_set()
From: Eric Dumazet @ 2017-09-21 14:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Ahern, Shrijeet Mukherjee
From: Eric Dumazet <edumazet@google.com>
skb_dst_set(skb, dst) installs a normal (refcounted) dst, there is no
point using skb_dst_force(skb)
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/vrf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 9b243e6f3008bb5319844412cd49db1cd7bce594..cc18b7b11612d16271a1dbbb2d55c8f61781b9be 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -132,7 +132,6 @@ static int vrf_local_xmit(struct sk_buff *skb, struct net_device *dev,
skb_orphan(skb);
skb_dst_set(skb, dst);
- skb_dst_force(skb);
/* set pkt_type to avoid skb hitting packet taps twice -
* once on Tx and again in Rx processing
^ permalink raw reply related
* Re: [PATCH net-next] net: vrf: remove skb_dst_force() after skb_dst_set()
From: David Ahern @ 2017-09-21 14:52 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Shrijeet Mukherjee
In-Reply-To: <1506005428.29839.129.camel@edumazet-glaptop3.roam.corp.google.com>
On 9/21/17 8:50 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> skb_dst_set(skb, dst) installs a normal (refcounted) dst, there is no
> point using skb_dst_force(skb)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> drivers/net/vrf.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
> index 9b243e6f3008bb5319844412cd49db1cd7bce594..cc18b7b11612d16271a1dbbb2d55c8f61781b9be 100644
> --- a/drivers/net/vrf.c
> +++ b/drivers/net/vrf.c
> @@ -132,7 +132,6 @@ static int vrf_local_xmit(struct sk_buff *skb, struct net_device *dev,
> skb_orphan(skb);
>
> skb_dst_set(skb, dst);
> - skb_dst_force(skb);
>
> /* set pkt_type to avoid skb hitting packet taps twice -
> * once on Tx and again in Rx processing
>
>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
* Re: Latest net-next from GIT panic
From: Eric Dumazet @ 2017-09-21 14:56 UTC (permalink / raw)
To: Paweł Staszewski
Cc: Wei Wang, Cong Wang, Linux Kernel Network Developers,
Eric Dumazet
In-Reply-To: <80e8948e-669b-4139-add6-637c6dd3405f@itcare.pl>
On Thu, 2017-09-21 at 15:18 +0200, Paweł Staszewski wrote:
> ok after adding patch all is working from now for about 1 hour of normal
> traffic witc all bgp sessions connected and about 600k prefixes in kernel.
Great, I am doing to submit an official patch, uniting skb_dst_force()
and skb_dst_force_safe() into a single helper.
Thanks.
^ permalink raw reply
* Re: [net-next 1/2] dummy: add device MTU validation check
From: Eric Dumazet @ 2017-09-21 15:02 UTC (permalink / raw)
To: Zhang Shengju; +Cc: davem, willemb, stephen, netdev
In-Reply-To: <1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>
On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:
> Currently, any mtu value can be assigned when adding a new dummy device:
> [~]# ip link add name dummy1 mtu 100000 type dummy
> [~]# ip link show dummy1
> 15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff
>
> This patch adds device MTU validation check.
What is wrong with big MTU on dummy ?
If this is a generic rule, this check should belong in core network
stack.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> ---
> drivers/net/dummy.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
> index e31ab3b..0276b2b 100644
> --- a/drivers/net/dummy.c
> +++ b/drivers/net/dummy.c
> @@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[],
> if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
> return -EADDRNOTAVAIL;
> }
> +
> + if (tb[IFLA_MTU]) {
> + u32 mtu = nla_get_u32(tb[IFLA_MTU]);
You do not verify/validate nla_len(tb[IFLA_MTU]).
Do not ever trust user space.
> +
> + if (mtu > ETH_MAX_MTU)
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH] ath10: mark PM functions as __maybe_unused
From: Kalle Valo @ 2017-09-21 15:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Govind Singh, Ryan Hsu, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, Rajkumar Manoharan,
ath10k@lists.infradead.org, linux-kernel@vger.kernel.org,
Srinivas Kandagatla, Colin Ian King, Ben Greear,
Ashok Raj Nagarajan, bartosz.markowski@tieto.com
In-Reply-To: <20170906125904.2588620-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> When CONFIG_PM_SLEEP is disabled, we get a compile-time
> warning:
>
> drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume' defined but not used [-Werror=unused-function]
> static int ath10k_pci_pm_resume(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/pci.c:3401:12: error: 'ath10k_pci_pm_suspend' defined but not used [-Werror=unused-function]
> static int ath10k_pci_pm_suspend(struct device *dev)
>
> Rather than fixing the #ifdef, this just marks both functions
> as __maybe_unused, which is a more robust way to do this.
>
> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to ath-current branch in ath.git, thanks.
(Having problems with my patchwork script so sending this manually)
--
Kalle Valo
^ permalink raw reply
* Fw: [Bug 197015] New: Message at boot
From: Stephen Hemminger @ 2017-09-21 15:06 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 21 Sep 2017 11:45:01 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 197015] New: Message at boot
https://bugzilla.kernel.org/show_bug.cgi?id=197015
Bug ID: 197015
Summary: Message at boot
Product: Networking
Version: 2.5
Kernel Version: 4.13.2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: jp.pozzi@izzop.net
Regression: No
Created attachment 258551
--> https://bugzilla.kernel.org/attachment.cgi?id=258551&action=edit
.config file
Hello,
I get a message at boot (the system seems to be fully OK including networking),
here is the "dmesg" output :
[ 43.514245] ------------[ cut here ]------------
[ 43.514249] WARNING: CPU: 5 PID: 40 at net/core/dev.c:5504
net_rx_action+0x213/0x340
[ 43.514250] Modules linked in: fuse ebtable_filter ebtables iptable_filter
bridge stp llc snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
kvm ath10k_pci ath10k_core irqbypass crct10dif_pclmul crc32_pclmul i915
ghash_clmulni_intel pcbc mac80211 i2c_designware_platform i2c_designware_core
aesni_intel snd_hda_intel aes_x86_64 crypto_simd glue_helper snd_hda_codec
cryptd intel_uncore snd_hwdep snd_hda_core ath snd_pcm serio_raw snd_timer
pcspkr snd cfg80211 soundcore idma64 iosf_mbi intel_gtt sg intel_lpss_pci
intel_pch_thermal ucsi_acpi typec_ucsi typec intel_lpss_acpi intel_lpss
acpi_pad evdev rtsx_usb mfd_core mq_deadline kyber_iosched deadline_iosched bfq
ip_tables x_tables autofs4 dm_mod dax hid_logitech_hidpp
[ 43.514274] hid_logitech_dj usbhid sd_mod crc32c_intel xhci_pci i2c_i801
xhci_hcd usbcore ahci libahci fan i2c_hid hid
[ 43.514279] CPU: 5 PID: 40 Comm: ksoftirqd/5 Not tainted 4.13.2 #1
[ 43.514280] Hardware name: Acer Aspire VX5-591G/Wish_KLS, BIOS V1.02
12/28/2016
[ 43.514280] task: ffff8c362c79f000 task.stack: ffffa64a401d4000
[ 43.514281] RIP: 0010:net_rx_action+0x213/0x340
[ 43.514282] RSP: 0018:ffffa64a401d7e18 EFLAGS: 00010297
[ 43.514283] RAX: 0000000000000041 RBX: ffff8c363ed5b040 RCX:
ffff8c362b351eb0
[ 43.514283] RDX: ffff8c31f44ae000 RSI: 00000000fffffe01 RDI:
ffffffffc081f0f6
[ 43.514283] RBP: 000000000000012c R08: 000000046adaad00 R09:
0000000000004ba8
[ 43.514284] R10: 0000000000000000 R11: 0000000000000001 R12:
0000000000000010
[ 43.514284] R13: 0000000000000041 R14: 0000000000000040 R15:
ffff8c362b357b00
[ 43.514285] FS: 0000000000000000(0000) GS:ffff8c363ed40000(0000)
knlGS:0000000000000000
[ 43.514286] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 43.514286] CR2: 000056547ac33000 CR3: 0000000463e66000 CR4:
00000000003406e0
[ 43.514287] Call Trace:
[ 43.514289] ? __do_softirq+0xff/0x287
[ 43.514291] ? run_ksoftirqd+0x19/0x30
[ 43.514293] ? smpboot_thread_fn+0xfe/0x150
[ 43.514294] ? kthread+0xf5/0x130
[ 43.514295] ? sort_range+0x20/0x20
[ 43.514296] ? kthread_park+0x60/0x60
[ 43.514297] ? ret_from_fork+0x22/0x30
[ 43.514297] Code: 00 48 83 c4 30 5b 5d 41 5c 41 5d 41 5e 41 5f c3 44 89 f6
4c 89 ff 41 ff 57 20 41 89 c5 0f 1f 44 00 00 45 39 ee 0f 8d e3 fe ff ff <0f> ff
45 39 ee 0f 8f e1 fe ff ff 49 8b 47 10 a8 04 0f 85 c9 00
[ 43.514311] ---[ end trace 5bb8c0b36979bc7c ]---
[ 128.084356] ntfs: driver 2.1.32 [Flags: R/W MODULE].
--------------------------------------------------------------------------------
I enclose the .config file
Regards
JP P
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: also trigger RTM_NEWLINK when interface is released from bridge
From: Roopa Prabhu @ 2017-09-21 15:09 UTC (permalink / raw)
To: Vincent Bernat
Cc: Stephen Hemminger, David Ahern, David Miller, bridge,
netdev@vger.kernel.org
In-Reply-To: <87h8vw5pwg.fsf@luffy.cx>
On Thu, Sep 21, 2017 at 3:04 AM, Vincent Bernat <vincent@bernat.im> wrote:
> ❦ 20 septembre 2017 16:21 -0700, Stephen Hemminger <stephen@networkplumber.org> :
>
>> The one concern is that ports added or removed through ioctl should
>> cause same events as doing the same thing via netlink. Some users use
>> brctl (ioctl) and others use newer bridge (netlink) API.
>
> I'll make a third iteration to have the same notifications when using
> ioctl() with details in the commit message.
> --
as long as the ioctl path for bridge port removal is generating a:
RTM_DELLINK with AF_BRIDGE and
RTM_NEWLINK with AF_UNSPEC with 'master' removed
we should be good. These are the most important ones.
are there other specific bridge-events missing ?. you might want to
run `bridge monitor link` also. and un-slaving of a port also triggers
fdb events which are visible under `bridge monitor fdb`
^ permalink raw reply
* [PATCH net-next] bpf/verifier: improve disassembly of BPF_END instructions
From: Edward Cree @ 2017-09-21 15:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Daniel Borkmann, Alexei Starovoitov
print_bpf_insn() was treating all BPF_ALU[64] the same, but BPF_END has a
different structure: it has a size in insn->imm (even if it's BPF_X) and
uses the BPF_SRC (X or K) to indicate which endianness to use. So it
needs different code to print it.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
It's not the same format as the new LLVM asm uses, does that matter?
AFAIK the LLVM format doesn't comprehend BPF_TO_LE, just assumes that all
endian ops are necessarily swaps (rather than sometimes nops).
kernel/bpf/verifier.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 799b245..e7657a4 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -331,20 +331,29 @@ static void print_bpf_insn(const struct bpf_verifier_env *env,
u8 class = BPF_CLASS(insn->code);
if (class == BPF_ALU || class == BPF_ALU64) {
- if (BPF_SRC(insn->code) == BPF_X)
+ if (BPF_OP(insn->code) == BPF_END) {
+ if (class == BPF_ALU64)
+ verbose("BUG_alu64_%02x\n", insn->code);
+ else
+ verbose("(%02x) (u%d) r%d %s %s\n",
+ insn->code, insn->imm, insn->dst_reg,
+ bpf_alu_string[BPF_END >> 4],
+ BPF_SRC(insn->code) == BPF_X ? "be" : "le");
+ } else if (BPF_SRC(insn->code) == BPF_X) {
verbose("(%02x) %sr%d %s %sr%d\n",
insn->code, class == BPF_ALU ? "(u32) " : "",
insn->dst_reg,
bpf_alu_string[BPF_OP(insn->code) >> 4],
class == BPF_ALU ? "(u32) " : "",
insn->src_reg);
- else
+ } else {
verbose("(%02x) %sr%d %s %s%d\n",
insn->code, class == BPF_ALU ? "(u32) " : "",
insn->dst_reg,
bpf_alu_string[BPF_OP(insn->code) >> 4],
class == BPF_ALU ? "(u32) " : "",
insn->imm);
+ }
} else if (class == BPF_STX) {
if (BPF_MODE(insn->code) == BPF_MEM)
verbose("(%02x) *(%s *)(r%d %+d) = r%d\n",
^ permalink raw reply related
* Re: [net-next 2/2] ifb: add device MTU validation check
From: Stephen Hemminger @ 2017-09-21 15:10 UTC (permalink / raw)
To: Zhang Shengju; +Cc: davem, willemb, netdev
In-Reply-To: <1506000722-40095-3-git-send-email-zhangshengju@cmss.chinamobile.com>
On Thu, 21 Sep 2017 21:32:02 +0800
Zhang Shengju <zhangshengju@cmss.chinamobile.com> wrote:
> Currently, any mtu value can be assigned when adding a new ifb device:
> [~]# ip link add name ifb2 mtu 100000 type ifb
> [~]# ip link show ifb2
> 18: ifb2: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 32
> link/ether 7a:bf:f4:63:da:d1 brd ff:ff:ff:ff:ff:ff
>
> This patch adds device MTU validation check.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> ---
> drivers/net/ifb.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
> index 8870bd2..ce84ad2 100644
> --- a/drivers/net/ifb.c
> +++ b/drivers/net/ifb.c
> @@ -282,6 +282,14 @@ static int ifb_validate(struct nlattr *tb[], struct nlattr *data[],
> if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
> return -EADDRNOTAVAIL;
> }
> +
> + if (tb[IFLA_MTU]) {
> + u32 mtu = nla_get_u32(tb[IFLA_MTU]);
> +
> + if (mtu < ETH_MIN_MTU || mtu > ETH_DATA_LEN)
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
What about running ifb with packets coming from devices with jumbo frames?
Also since ifb is an input only device, MTU doesn't matter.
^ permalink raw reply
* Re: [net-next v3] bridge: trigger RTM_NEWLINK when interface is modified by bridge ioctl
From: Stephen Hemminger @ 2017-09-21 15:15 UTC (permalink / raw)
To: Vincent Bernat; +Cc: netdev, bridge, David Miller, David Ahern
In-Reply-To: <20170921100525.20395-1-vincent@bernat.im>
On Thu, 21 Sep 2017 12:05:25 +0200
Vincent Bernat <vincent@bernat.im> wrote:
> Currently, there is a difference in netlink events received when an
> interface is modified through bridge ioctl() or through netlink. This
> patch generates additional events when an interface is added to or
> removed from a bridge via ioctl().
>
> When adding then removing an interface from a bridge with netlink, we
> get:
>
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bridge0 state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bridge0 state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
>
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bridge0 state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> Deleted 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
>
> When using ioctl():
>
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bridge0 state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bridge0 state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
>
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bridge0 state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> Deleted 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 9e:da:60:ee:cf:c8
> 5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
> link/ether 9e:da:60:ee:cf:c8 brd ff:ff:ff:ff:ff:ff
>
> Without this patch, the last netlink notification is not sent.
>
> Signed-off-by: Vincent Bernat <vincent@bernat.im>
This makes sense, you should probably add a Fixes: tag to help maintainers
of long term stable kernels.
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] bpf: add helper bpf_perf_event_read_value for perf event array map
From: Alexei Starovoitov @ 2017-09-21 15:15 UTC (permalink / raw)
To: David Miller, peterz; +Cc: yhs, rostedt, daniel, netdev, kernel-team
In-Reply-To: <20170920.160707.932591498085219317.davem@davemloft.net>
On 9/20/17 4:07 PM, David Miller wrote:
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Wed, 20 Sep 2017 19:26:51 +0200
>
>> Dave, could we have this in a topic tree of sorts, because I have a
>> pending series to rework all the timekeeping and it might be nice to not
>> have sfr run into all sorts of conflicts.
>
> If you want to merge it into your tree that's fine.
>
> But it means that any further development done on top of this
> work will need to go via you as well.
can we merge this set of patches into both net-next and tip ?
We did such tricks in the past to avoid merge conflicts and
everything went fine during merge window.
^ permalink raw reply
* Re: [PATCH v3 01/31] usercopy: Prepare for usercopy whitelisting
From: Christopher Lameter @ 2017-09-21 15:21 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, David Windsor, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, linux-mm, linux-xfs, linux-fsdevel,
netdev, kernel-hardening
In-Reply-To: <1505940337-79069-2-git-send-email-keescook@chromium.org>
On Wed, 20 Sep 2017, Kees Cook wrote:
> diff --git a/include/linux/stddef.h b/include/linux/stddef.h
> index 9c61c7cda936..f00355086fb2 100644
> --- a/include/linux/stddef.h
> +++ b/include/linux/stddef.h
> @@ -18,6 +18,8 @@ enum {
> #define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
> #endif
>
> +#define sizeof_field(structure, field) sizeof((((structure *)0)->field))
> +
> /**
> * offsetofend(TYPE, MEMBER)
> *
Hmmm.. Is that really necessary? Code knows the type of field and can
use sizeof type.
Also this is a non slab change hidden in the patchset.
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 904a83be82de..36408f5f2a34 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -272,6 +272,9 @@ int slab_unmergeable(struct kmem_cache *s)
> if (s->ctor)
> return 1;
>
> + if (s->usersize)
> + return 1;
> +
> /*
> * We may have set a slab to be unmergeable during bootstrap.
> */
This will ultimately make all slabs unmergeable at the end of your
patchset? Lots of space will be wasted. Is there any way to make this
feature optional?
#ifdef CONFIG_HARDENED around this?
> @@ -491,6 +509,15 @@ kmem_cache_create(const char *name, size_t size, size_t align,
> }
> return s;
> }
> +EXPORT_SYMBOL(kmem_cache_create_usercopy);
> +
> +struct kmem_cache *
> +kmem_cache_create(const char *name, size_t size, size_t align,
> + unsigned long flags, void (*ctor)(void *))
> +{
> + return kmem_cache_create_usercopy(name, size, align, flags, 0, size,
> + ctor);
> +}
> EXPORT_SYMBOL(kmem_cache_create);
Well this makes the slab created unmergeable.
> @@ -897,7 +927,7 @@ struct kmem_cache *__init create_kmalloc_cache(const char *name, size_t size,
> if (!s)
> panic("Out of memory when creating slab %s\n", name);
>
> - create_boot_cache(s, name, size, flags);
> + create_boot_cache(s, name, size, flags, 0, size);
Ok this makes the kmalloc array unmergeable.
> @@ -5081,6 +5081,12 @@ static ssize_t cache_dma_show(struct kmem_cache *s, char *buf)
> SLAB_ATTR_RO(cache_dma);
> #endif
>
> +static ssize_t usersize_show(struct kmem_cache *s, char *buf)
> +{
> + return sprintf(buf, "%zu\n", s->usersize);
> +}
> +SLAB_ATTR_RO(usersize);
> +
> static ssize_t destroy_by_rcu_show(struct kmem_cache *s, char *buf)
> {
> return sprintf(buf, "%d\n", !!(s->flags & SLAB_TYPESAFE_BY_RCU));
> @@ -5455,6 +5461,7 @@ static struct attribute *slab_attrs[] = {
> #ifdef CONFIG_FAILSLAB
> &failslab_attr.attr,
> #endif
> + &usersize_attr.attr,
So useroffset is not exposed?
^ permalink raw reply
* Re: [PATCH v3 02/31] usercopy: Enforce slab cache usercopy region boundaries
From: Christopher Lameter @ 2017-09-21 15:23 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, David Windsor, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, Laura Abbott, Ingo Molnar,
Mark Rutland, linux-mm, linux-xfs, linux-fsdevel, netdev,
kernel-hardening
In-Reply-To: <1505940337-79069-3-git-send-email-keescook@chromium.org>
On Wed, 20 Sep 2017, Kees Cook wrote:
> diff --git a/mm/slab.c b/mm/slab.c
> index 87b6e5e0cdaf..df268999cf02 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -4408,7 +4408,9 @@ module_init(slab_proc_init);
>
> #ifdef CONFIG_HARDENED_USERCOPY
> /*
> - * Rejects objects that are incorrectly sized.
> + * Rejects incorrectly sized objects and objects that are to be copied
> + * to/from userspace but do not fall entirely within the containing slab
> + * cache's usercopy region.
> *
> * Returns NULL if check passes, otherwise const char * to name of cache
> * to indicate an error.
> @@ -4428,11 +4430,15 @@ const char *__check_heap_object(const void *ptr, unsigned long n,
> /* Find offset within object. */
> offset = ptr - index_to_obj(cachep, page, objnr) - obj_offset(cachep);
>
> - /* Allow address range falling entirely within object size. */
> - if (offset <= cachep->object_size && n <= cachep->object_size - offset)
> - return NULL;
> + /* Make sure object falls entirely within cache's usercopy region. */
> + if (offset < cachep->useroffset)
> + return cachep->name;
> + if (offset - cachep->useroffset > cachep->usersize)
> + return cachep->name;
> + if (n > cachep->useroffset - offset + cachep->usersize)
> + return cachep->name;
>
> - return cachep->name;
> + return NULL;
> }
> #endif /* CONFIG_HARDENED_USERCOPY */
Looks like this is almost the same for all allocators. Can we put this
into mm/slab_common.c?
^ permalink raw reply
* Re: [PATCH net-next 3/4] cxgb4: add support to offload action vlan
From: Kumar Sanghvi @ 2017-09-21 15:23 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Rahul Lakkireddy, netdev, davem, ganeshgr, nirranjan, indranil
In-Reply-To: <20170921085508.GA2028@nanopsycho>
Hi Jiri,
On Thursday, September 09/21/17, 2017 at 10:55:08 +0200, Jiri Pirko wrote:
> Thu, Sep 21, 2017 at 09:33:36AM CEST, rahul.lakkireddy@chelsio.com wrote:
> >From: Kumar Sanghvi <kumaras@chelsio.com>
> >
> >Add support for offloading tc-flower flows having
> >vlan actions: pop, push and modify.
> >
> >Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> >Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> >Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> >---
> > .../net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 43 ++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> >
> >diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>
> [...]
>
>
> >+ switch (vlan_action) {
> >+ case TCA_VLAN_ACT_POP:
> >+ break;
> >+ case TCA_VLAN_ACT_PUSH:
> >+ case TCA_VLAN_ACT_MODIFY:
> >+ if (proto != ETH_P_8021Q) {
> >+ netdev_err(dev,
> >+ "%s: Unsupp. vlan proto\n",
>
> Don't wrap this. Also "Unsupp."vs"Unsupported". Please be consistent.
Thank you for pointing this.
I will take care of this in V2.
>
>
> >+ __func__);
> >+ return -EOPNOTSUPP;
> >+ }
> >+ break;
> >+ default:
> >+ netdev_err(dev, "%s: Unsupported vlan action\n",
> >+ __func__);
> >+ return -EOPNOTSUPP;
> >+ }
> > } else {
> > netdev_err(dev, "%s: Unsupported action\n", __func__);
> > return -EOPNOTSUPP;
> >--
> >2.14.1
> >
^ permalink raw reply
* Re: [patch net-next 07/12] mlxsw: spectrum: Add the multicast routing offloading logic
From: Andrew Lunn @ 2017-09-21 15:26 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, yotamg, idosch, mlxsw
In-Reply-To: <20170921064338.1282-8-jiri@resnulli.us>
> +static void mlxsw_sp_mr_route_stats_update(struct mlxsw_sp *mlxsw_sp,
> + struct mlxsw_sp_mr_route *mr_route)
> +{
> + struct mlxsw_sp_mr *mr = mlxsw_sp->mr;
> + u64 packets, bytes;
> +
> + if (mr_route->route_action == MLXSW_SP_MR_ROUTE_ACTION_TRAP)
> + return;
> +
> + mr->mr_ops->route_stats(mlxsw_sp, mr_route->route_priv, &packets,
> + &bytes);
> +
> + switch (mr_route->mr_table->proto) {
> + case MLXSW_SP_L3_PROTO_IPV4:
> + mr_route->mfc4->mfc_un.res.pkt = packets;
> + mr_route->mfc4->mfc_un.res.bytes = bytes;
What about wrong_if and lastuse?
Is an mfc with iif on the host, not the switch, not offloaded?
Andrew
^ permalink raw reply
* Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
From: Christopher Lameter @ 2017-09-21 15:27 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, David Windsor, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, linux-mm, linux-xfs, linux-fsdevel,
netdev, kernel-hardening
In-Reply-To: <1505940337-79069-4-git-send-email-keescook@chromium.org>
On Wed, 20 Sep 2017, Kees Cook wrote:
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void)
> */
> kmalloc_caches[INDEX_NODE] = create_kmalloc_cache(
> kmalloc_info[INDEX_NODE].name,
> - kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS);
> + kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,
> + 0, kmalloc_size(INDEX_NODE));
> slab_state = PARTIAL_NODE;
> setup_kmalloc_cache_index_table();
Ok this presumes that at some point we will be able to restrict the number
of bytes writeable and thus set the offset and size field to different
values. Is that realistic?
We already whitelist all kmalloc caches (see first patch).
So what is the point of this patch?
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: also trigger RTM_NEWLINK when interface is released from bridge
From: Vincent Bernat @ 2017-09-21 15:31 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Stephen Hemminger, David Ahern, David Miller, bridge,
netdev@vger.kernel.org
In-Reply-To: <CAJieiUgKO-O3YFc3iTQXMmXc287RGgw4FjYhaLn-7+pmA_Fh+g@mail.gmail.com>
❦ 21 septembre 2017 08:09 -0700, Roopa Prabhu <roopa@cumulusnetworks.com> :
>>> The one concern is that ports added or removed through ioctl should
>>> cause same events as doing the same thing via netlink. Some users use
>>> brctl (ioctl) and others use newer bridge (netlink) API.
>>
>> I'll make a third iteration to have the same notifications when using
>> ioctl() with details in the commit message.
>> --
>
> as long as the ioctl path for bridge port removal is generating a:
> RTM_DELLINK with AF_BRIDGE and
> RTM_NEWLINK with AF_UNSPEC with 'master' removed
>
> we should be good. These are the most important ones.
>
> are there other specific bridge-events missing ?. you might want to
> run `bridge monitor link` also. and un-slaving of a port also triggers
> fdb events which are visible under `bridge monitor fdb`
With the patch, bridge monitor link generates the same event with
ioctl() than with netlink (like for ip monitor link, netlink generates
one extra duplicate event when enslaving).
For bridge monitor fdb, there is a difference. With ioctl(), I don't get
the event for VLAN1:
Deleted ca:18:06:bc:f6:11 dev dummy1 vlan 1 master bridge0 permanent
I suppose this is an expected difference due to the inability to manage
VLAN-aware bridges with ioctl().
--
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
^ permalink raw reply
* Re: [PATCH net-next 2/4] cxgb4: add basic tc flower offload support
From: Kumar Sanghvi @ 2017-09-21 15:31 UTC (permalink / raw)
To: Yunsheng Lin
Cc: Rahul Lakkireddy, netdev, davem, ganeshgr, nirranjan, indranil
In-Reply-To: <cf99ae13-6ae1-2a1f-80cb-9390ab9e3af0@huawei.com>
Hi Yunsheng,
On Thursday, September 09/21/17, 2017 at 18:55:26 +0800, Yunsheng Lin wrote:
> Hi, Kumar
>
> On 2017/9/21 15:33, Rahul Lakkireddy wrote:
> > From: Kumar Sanghvi <kumaras@chelsio.com>
> >
> > Add support to add/remove flows for offload. Following match
> > and action are supported for offloading a flow:
> >
> > Match: ether-protocol, IPv4/IPv6 addresses, L4 ports (TCP/UDP)
> > Action: drop, redirect to another port on the device.
> >
> > The qualifying flows can have accompanying mask information.
> >
> > Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> > Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> > Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> > ---
[...]
> > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> > index 45b5853ca2f1..07a4619e2164 100644
> > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> > @@ -148,6 +148,32 @@ static int get_filter_steerq(struct net_device *dev,
> > return iq;
> > }
> >
> > +int cxgb4_get_free_ftid(struct net_device *dev, int family)
> > +{
> > + struct adapter *adap = netdev2adap(dev);
> > + struct tid_info *t = &adap->tids;
> > + int ftid;
> > +
> > + spin_lock_bh(&t->ftid_lock);
> > + if (family == PF_INET) {
> > + ftid = find_first_zero_bit(t->ftid_bmap, t->nftids);
> > + if (ftid >= t->nftids)
> > + ftid = -1;
> > + } else {
> > + ftid = bitmap_find_free_region(t->ftid_bmap, t->nftids, 2);
> > + if (ftid < 0) {
> > + ftid = -1;
>
> ftid = -1 is not needed?
You are right, its not needed. Thank you for pointing this.
I will take care of this in V2.
>
> > + goto out_unlock;
> > + }
> > +
> > + /* this is only a lookup, keep the found region unallocated */
> > + bitmap_release_region(t->ftid_bmap, ftid, 2);
> > + }
> > +out_unlock:
> > + spin_unlock_bh(&t->ftid_lock);
> > + return ftid;
> > +}
[...]
> > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> > index 16dff71e4d02..1af01101faaf 100644
> > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> > @@ -38,16 +38,292 @@
> > #include "cxgb4.h"
> > #include "cxgb4_tc_flower.h"
> >
[...]
> > int cxgb4_tc_flower_replace(struct net_device *dev,
> > struct tc_cls_flower_offload *cls)
> > {
> > - return -EOPNOTSUPP;
> > + struct adapter *adap = netdev2adap(dev);
> > + struct ch_tc_flower_entry *ch_flower;
> > + struct ch_filter_specification *fs;
> > + struct filter_ctx ctx;
> > + int fidx;
> > + int ret;
> > +
> > + if (cxgb4_validate_flow_actions(dev, cls))
> > + return -EOPNOTSUPP;
> > +
> > + if (cxgb4_validate_flow_match(dev, cls))
> > + return -EOPNOTSUPP;
> > +
> > + ch_flower = allocate_flower_entry();
> > + if (!ch_flower) {
> > + netdev_err(dev, "%s: ch_flower alloc failed.\n", __func__);
> > + ret = -ENOMEM;
> > + goto err;
>
> Just return, err label is needed?
Yes, err label is not needed. I will take care of this in V2.
>
> > + }
> > +
> > + fs = &ch_flower->fs;
> > + fs->hitcnts = 1;
> > + cxgb4_process_flow_actions(dev, cls, fs);
> > + cxgb4_process_flow_match(dev, cls, fs);
[...]
> > int cxgb4_tc_flower_destroy(struct net_device *dev,
> > struct tc_cls_flower_offload *cls)
> > {
> > - return -EOPNOTSUPP;
> > + struct adapter *adap = netdev2adap(dev);
> > + struct ch_tc_flower_entry *ch_flower;
> > + int ret;
> > +
> > + ch_flower = ch_flower_lookup(adap, cls->cookie);
> > + if (!ch_flower) {
> > + ret = -ENOENT;
> > + goto err;
>
> Same as above
I will take care of this in V2.
Thank you.
^ permalink raw reply
* [PATCH net-next] test_rhashtable: remove initdata annotation
From: Florian Westphal @ 2017-09-21 15:36 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
kbuild test robot reported a section mismatch warning w. gcc 4.x:
WARNING: lib/test_rhashtable.o(.text+0x139e):
Section mismatch in reference from the function rhltable_insert.clone.3() to the variable .init.data:rhlt
so remove this annotation.
Fixes: cdd4de372ea06 ("test_rhashtable: add test case for rhl_table interface")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
I don't see this warning with same .config and gcc 6.3.x; however
the annotation isn't essential so just remove it.
diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c
index de4d0584631a..8e83cbdc049c 100644
--- a/lib/test_rhashtable.c
+++ b/lib/test_rhashtable.c
@@ -251,7 +251,7 @@ static s64 __init test_rhashtable(struct rhashtable *ht, struct test_obj *array,
}
static struct rhashtable ht;
-static struct rhltable rhlt __initdata;
+static struct rhltable rhlt;
static int __init test_rhltable(unsigned int entries)
{
--
2.13.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox