* Re: [v3, net-next, 02/12] net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit
From: Jerome Brunet @ 2018-08-17 7:32 UTC (permalink / raw)
To: Jose Abreu, netdev, open list:ARM/Amlogic Meson..., Kevin Hilman
Cc: David S. Miller, Joao Pinto, Vitor Soares, Giuseppe Cavallaro,
Alexandre Torgue, Bartosz Gołaszewski
In-Reply-To: <9d0be5db11478d00a9194065abcf137b4d537c0a.1526651009.git.joabreu@synopsys.com>
On Fri, 2018-05-18 at 14:55 +0100, Jose Abreu wrote:
> This is cutting down performance. Once the timer is armed it should run
> after the time expires for the first packet sent and not the last one.
>
> After this change, running iperf, the performance gain is +/- 24%.
Hi Guys,
Since v4.18, we are getting a serious regression on Amlogic based SoCs.
I have tested this on amlogic's:
* gxbb S905 p200 (Micrel KSZ9031 - 1GBps)
* axg A113 s400 (Realtek RTL8211F - 1GBps)
Both SoCs use the synopsys gmac with stmmac driver.
I first noticed that running NFS root filesystem became unstable but I could not
understand why. Then, running a download as simple test with iperf3 (from an
initramfs) will break the 'network' in matter of seconds.
I don't know exactly what breaks but bisect clearly assign the blame to this
change. Reverting the change solve this problem.
I'll be happy to make more tests to help understand what is happening here.
In the meantime, should we consider reverting this patch ?
Best Regards
Jerome
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: Vitor Soares <soares@synopsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 42fc76e..4d425b1 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -105,6 +105,7 @@ struct stmmac_priv {
> u32 tx_count_frames;
> u32 tx_coal_frames;
> u32 tx_coal_timer;
> + bool tx_timer_armed;
>
> int tx_coalesce;
> int hwts_tx_en;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d9dbe13..789bc22 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3158,13 +3158,16 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> * element in case of no SG.
> */
> priv->tx_count_frames += nfrags + 1;
> - if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
> + if (likely(priv->tx_coal_frames > priv->tx_count_frames) &&
> + !priv->tx_timer_armed) {
> mod_timer(&priv->txtimer,
> STMMAC_COAL_TIMER(priv->tx_coal_timer));
> + priv->tx_timer_armed = true;
> } else {
> priv->tx_count_frames = 0;
> stmmac_set_tx_ic(priv, desc);
> priv->xstats.tx_set_ic_bit++;
> + priv->tx_timer_armed = false;
> }
>
> skb_tx_timestamp(skb);
^ permalink raw reply
* Dear intended recipient
From: Malik Sanfo @ 2018-08-17 9:24 UTC (permalink / raw)
--
Good-Day!,
Can you assist me to handle this transaction? I will forward you the
full details about the transaction if you are ready.
Yours faithfully
Mr. Malik Sanfo
^ permalink raw reply
* [PATCH] datapath.c: fix missing return value check of nla_nest_start()
From: Jiecheng Wu @ 2018-08-17 8:15 UTC (permalink / raw)
To: netdev
Function queue_userspace_packet() defined in net/openvswitch/datapath.c calls nla_nest_start() to allocate memory for struct nlattr which is dereferenced immediately. As nla_nest_start() may return NULL on failure, this code piece may cause NULL pointer dereference bug.
---
net/openvswitch/datapath.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 0f5ce77..ff4457d 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -460,6 +460,8 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
if (upcall_info->egress_tun_info) {
nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_EGRESS_TUN_KEY);
+ if (!nla)
+ return -EMSGSIZE;
err = ovs_nla_put_tunnel_info(user_skb,
upcall_info->egress_tun_info);
BUG_ON(err);
@@ -468,6 +470,8 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
if (upcall_info->actions_len) {
nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_ACTIONS);
+ if (!nla)
+ return -EMSGSIZE;
err = ovs_nla_put_actions(upcall_info->actions,
upcall_info->actions_len,
user_skb);
--
2.6.4
^ permalink raw reply related
* [PATCH 1/1] tap: RCU usage and comment fixes
From: Wang Jian @ 2018-08-17 8:22 UTC (permalink / raw)
To: davem, jasowang, mst, willemb, viro, wexu, netdev; +Cc: Wang Jian
The tap_queue and the 'tap_dev' are loosely coupled, not 'macvlan_dev'.
Taking rcu_read_lock a little later seems can slightly reduce rcu read critical section.
Signed-off-by: Wang Jian <jianjian.wang1@gmail.com>
---
drivers/net/tap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index f0f7cd977667..e5e5a8e4a60d 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -125,7 +125,7 @@ static struct tap_dev *tap_dev_get_rcu(const struct net_device *dev)
/*
* RCU usage:
- * The tap_queue and the macvlan_dev are loosely coupled, the
+ * The tap_queue and the tap_dev are loosely coupled, the
* pointers from one to the other can only be read while rcu_read_lock
* or rtnl is held.
*
@@ -720,8 +720,6 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m,
__vlan_get_protocol(skb, skb->protocol, &depth) != 0)
skb_set_network_header(skb, depth);
- rcu_read_lock();
- tap = rcu_dereference(q->tap);
/* copy skb_ubuf_info for callback when skb has no error */
if (zerocopy) {
skb_shinfo(skb)->destructor_arg = m->msg_control;
@@ -732,6 +730,8 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m,
uarg->callback(uarg, false);
}
+ rcu_read_lock();
+ tap = rcu_dereference(q->tap);
if (tap) {
skb->dev = tap->dev;
dev_queue_xmit(skb);
--
2.17.1
^ permalink raw reply related
* [regression] r8169 without realtek_phy
From: Jouni Mettälä @ 2018-08-17 8:33 UTC (permalink / raw)
To: netdev
There is network regression for me. 4.18 was good. 4.18+ is bad. There
was some phy changes in r8169 driver. Fortunately adding
CONFIG_REALTEK_PHY=m to kernel config fixed the regression.
Should r8169 depend on realtek_phy? Does that breaks something else?
Network doesn't work with Generic PHY (output of dmesg)
Generic PHY r8169-300:00: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
When realtek_phy is compiled, r8169 automatically uses it.
RTL8211B Gigabit Ethernet r8169-300:00: attached PHY driver [RTL8211B
Gigabit Ethernet] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
Here is Ethernet controller's lspci for reference:
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168]
(rev 01)
Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [147b:1078]
Flags: bus master, fast devsel, latency 0, IRQ 27
I/O ports at ce00 [size=256]
Memory at fddff000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at fdd00000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [60] Express Endpoint, MSI 00
Capabilities: [84] Vendor Specific Information: Len=4c <?>
Capabilities: [100] Advanced Error Reporting
Capabilities: [12c] Virtual Channel
Capabilities: [148] Device Serial Number 28-00-00-00-00-00-00-
00
Capabilities: [154] Power Budgeting <?>
Kernel driver in use: r8169
Kernel modules: r8169
^ permalink raw reply
* mv88e6xxx: question: can switch irq be shared?
From: Marek Behún @ 2018-08-17 9:30 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Marek Behún
Hello, I am wondering if the main device irq in
dsa/mv88e6xxx/chip.c can be requested as shared (see patch below).
The reason is that our board is wired so that irqs from all switches
come to the same gpio.
Marek
---
drivers/net/dsa/mv88e6xxx/chip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index d90656e415b0..1caaa09e391e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -424,7 +424,8 @@ static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
err = request_threaded_irq(chip->irq, NULL,
mv88e6xxx_g1_irq_thread_fn,
- IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
+ IRQF_ONESHOT | IRQF_TRIGGER_FALLING
+ | IRQF_SHARED,
dev_name(chip->dev), chip);
if (err)
mv88e6xxx_g1_irq_free_common(chip);
^ permalink raw reply related
* Re: virtio_net failover and initramfs (was: Re: [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework)
From: Harald Hoyer @ 2018-08-17 9:51 UTC (permalink / raw)
To: Siwei Liu, Samudrala, Sridhar
Cc: Jiri Pirko, initramfs, Michael S. Tsirkin, Netdev,
vijay.balakrishna, si-wei liu, liran.alon
In-Reply-To: <CADGSJ206hwO_3RbB8C5875updN1e=LZqw1kwNJgne_-c4=9GoQ@mail.gmail.com>
On 16.08.2018 00:17, Siwei Liu wrote:
> On Wed, Aug 15, 2018 at 12:05 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>> On 8/14/2018 5:03 PM, Siwei Liu wrote:
>>>
>>> Are we sure all userspace apps skip and ignore slave interfaces by
>>> just looking at "IFLA_MASTER" attribute?
>>>
>>> When STANDBY is enabled on virtio-net, a failover master interface
>>> will appear, which automatically enslaves the virtio device. But it is
>>> found out that iSCSI (or any network boot) cannot boot strap over the
>>> new failover interface together with a standby virtio (without any VF
>>> or PT device in place).
>>>
>>> Dracut (initramfs) ends up with timeout and dropping into emergency shell:
>>>
>>> [ 228.170425] dracut-initqueue[377]: Warning: dracut-initqueue
>>> timeout - starting timeout scripts
>>> [ 228.171788] dracut-initqueue[377]: Warning: Could not boot.
>>> Starting Dracut Emergency Shell...
>>> Generating "/run/initramfs/rdsosreport.txt"
>>> Entering emergency mode. Exit the shell to continue.
>>> Type "journalctl" to view system logs.
>>> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
>>> /boot
>>> after mounting them and attach it to a bug report.
>>> dracut:/# ip l sh
>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>>> mode DEFAULT group default qlen 1000
>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>> state UP mode DEFAULT group default qlen 1000
>>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff\
>>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>> master eth0 state UP mode DEFAULT group default qlen 1000
>>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff
>>> dracut:/#
>>>
>>> If changing dracut code to ignore eth1 (with IFLA_MASTER attr),
>>> network boot starts to work.
>>
>>
>> Does dracut by default tries to use all the interfaces that are UP?
>>
> Yes. The specific dracut cmdline of our case is "ip=dhcp
> netroot=iscsi:... ", but it's not specific to iscsi boot. And because
> of same MAC address for failover and standby, while dracut tries to
> run DHCP on all interfaces that are up it eventually gets same route
> for each interface. Those conflict route entries kill off the network
> connection.
>
>>
>>>
>>> The reason is that dracut has its own means to differentiate virtual
>>> interfaces for network boot: it does not look at IFLA_MASTER and
>>> ignores slave interfaces. Instead, users have to provide explicit
>>> option e.g. bond=eth0,eth1 in the boot line, then dracut would know
>>> the config and ignore the slave interfaces.
>>
>>
>> Isn't it possible to specify the interface that should be used for network
>> boot?
> As I understand it, one can only specify interface name for running
> DHCP but not select interface for network boot. We want DHCP to run
> on every NIC that is up (excluding the enslaved interfaces), and only
> one of them can get a route entry to the network boot server (ie.g.
> iSCSI target).
>
>>
>>
>>>
>>> However, with automatic creation of failover interface that assumption
>>> is no longer true. Can we change dracut to ignore all slave interface
>>> by checking IFLA_MASTER? I don't think so. It has a large impact to
>>> existing configs.
>>
>>
>> What is the issue with checking for IFLA_MASTER? I guess this is used with
>> team/bonding setups.
> That should be discussed within and determined by the dracut
> community. But the current dracut code doesn't check IFLA_MASTER for
> team or bonding specifically. I guess this change might have broader
> impact to existing userspace that might be already relying on the
> current behaviour.
>
> Thanks,
> -Siwei
Is there a sysfs flag for IFF_SLAVE? Or any "ip" output I can use to detect, that it is a IFF_SLAVE?
^ permalink raw reply
* Re: virtio_net failover and initramfs (was: Re: [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework)
From: Harald Hoyer @ 2018-08-17 9:56 UTC (permalink / raw)
To: Siwei Liu, Samudrala, Sridhar
Cc: Jiri Pirko, initramfs, Michael S. Tsirkin, Netdev,
vijay.balakrishna, si-wei liu, liran.alon
In-Reply-To: <85bf8fce-8cdf-597c-3b50-a1ff2eb5c5c4@redhat.com>
On 17.08.2018 11:51, Harald Hoyer wrote:
> On 16.08.2018 00:17, Siwei Liu wrote:
>> On Wed, Aug 15, 2018 at 12:05 PM, Samudrala, Sridhar
>> <sridhar.samudrala@intel.com> wrote:
>>> On 8/14/2018 5:03 PM, Siwei Liu wrote:
>>>>
>>>> Are we sure all userspace apps skip and ignore slave interfaces by
>>>> just looking at "IFLA_MASTER" attribute?
>>>>
>>>> When STANDBY is enabled on virtio-net, a failover master interface
>>>> will appear, which automatically enslaves the virtio device. But it is
>>>> found out that iSCSI (or any network boot) cannot boot strap over the
>>>> new failover interface together with a standby virtio (without any VF
>>>> or PT device in place).
>>>>
>>>> Dracut (initramfs) ends up with timeout and dropping into emergency shell:
>>>>
>>>> [ 228.170425] dracut-initqueue[377]: Warning: dracut-initqueue
>>>> timeout - starting timeout scripts
>>>> [ 228.171788] dracut-initqueue[377]: Warning: Could not boot.
>>>> Starting Dracut Emergency Shell...
>>>> Generating "/run/initramfs/rdsosreport.txt"
>>>> Entering emergency mode. Exit the shell to continue.
>>>> Type "journalctl" to view system logs.
>>>> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
>>>> /boot
>>>> after mounting them and attach it to a bug report.
>>>> dracut:/# ip l sh
>>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>>>> mode DEFAULT group default qlen 1000
>>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>> state UP mode DEFAULT group default qlen 1000
>>>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff\
>>>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>>> master eth0 state UP mode DEFAULT group default qlen 1000
>>>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff
>>>> dracut:/#
>>>>
>>>> If changing dracut code to ignore eth1 (with IFLA_MASTER attr),
>>>> network boot starts to work.
>>>
>>>
>>> Does dracut by default tries to use all the interfaces that are UP?
>>>
>> Yes. The specific dracut cmdline of our case is "ip=dhcp
>> netroot=iscsi:... ", but it's not specific to iscsi boot. And because
>> of same MAC address for failover and standby, while dracut tries to
>> run DHCP on all interfaces that are up it eventually gets same route
>> for each interface. Those conflict route entries kill off the network
>> connection.
>>
>>>
>>>>
>>>> The reason is that dracut has its own means to differentiate virtual
>>>> interfaces for network boot: it does not look at IFLA_MASTER and
>>>> ignores slave interfaces. Instead, users have to provide explicit
>>>> option e.g. bond=eth0,eth1 in the boot line, then dracut would know
>>>> the config and ignore the slave interfaces.
>>>
>>>
>>> Isn't it possible to specify the interface that should be used for network
>>> boot?
>> As I understand it, one can only specify interface name for running
>> DHCP but not select interface for network boot. We want DHCP to run
>> on every NIC that is up (excluding the enslaved interfaces), and only
>> one of them can get a route entry to the network boot server (ie.g.
>> iSCSI target).
>>
>>>
>>>
>>>>
>>>> However, with automatic creation of failover interface that assumption
>>>> is no longer true. Can we change dracut to ignore all slave interface
>>>> by checking IFLA_MASTER? I don't think so. It has a large impact to
>>>> existing configs.
>>>
>>>
>>> What is the issue with checking for IFLA_MASTER? I guess this is used with
>>> team/bonding setups.
>> That should be discussed within and determined by the dracut
>> community. But the current dracut code doesn't check IFLA_MASTER for
>> team or bonding specifically. I guess this change might have broader
>> impact to existing userspace that might be already relying on the
>> current behaviour.
>>
>> Thanks,
>> -Siwei
>
> Is there a sysfs flag for IFF_SLAVE? Or any "ip" output I can use to detect, that it is a IFF_SLAVE?
>
Oh, it's the other way around.. dracut should ignore "master" (eth1).
Can the master enslave the "eth0", if it is already "UP" and busy later on?
^ permalink raw reply
* [PATCH net-next] net: dsa: mv88e6xxx: Share main switch IRQ
From: Marek Behún @ 2018-08-17 10:09 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Marek Behún
In-Reply-To: <20180817093055.3107-1-marek.behun@nic.cz>
On some boards the interrupt can be shared between multiple devices.
For example on Turris Mox the interrupt is shared between all switches.
Signed-off-by: Marek Behun <marek.behun@nic.cz>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 8da3d39e3218..b57f5403982a 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -434,7 +434,7 @@ static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
err = request_threaded_irq(chip->irq, NULL,
mv88e6xxx_g1_irq_thread_fn,
- IRQF_ONESHOT,
+ IRQF_ONESHOT | IRQF_SHARED,
dev_name(chip->dev), chip);
if (err)
mv88e6xxx_g1_irq_free_common(chip);
--
2.16.4
^ permalink raw reply related
* [PATCH 0/2] ethernet: Use NULL to compare with pointer-typed value rather than 0
From: zhong jiang @ 2018-08-17 13:18 UTC (permalink / raw)
To: davem; +Cc: vz, slemieux.tyco, keescook, netdev, linux-kernel
zhong jiang (2):
ethernet: declance: Use NULL to compare with pointer-typed value
rather than 0
ethernet: lpc_eth: Use NULL to compare with pointer-typed value
rather than 0
drivers/net/ethernet/amd/declance.c | 2 +-
drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH 1/2] ethernet: declance: Use NULL to compare with pointer-typed value rather than 0
From: zhong jiang @ 2018-08-17 13:18 UTC (permalink / raw)
To: davem; +Cc: vz, slemieux.tyco, keescook, netdev, linux-kernel
In-Reply-To: <1534511933-39236-1-git-send-email-zhongjiang@huawei.com>
We should use NULL to compare with pointer-typed value rather than
0. The issue is detected with the help of Coccinelle.
---
drivers/net/ethernet/amd/declance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/declance.c b/drivers/net/ethernet/amd/declance.c
index 116997a..6e035df 100644
--- a/drivers/net/ethernet/amd/declance.c
+++ b/drivers/net/ethernet/amd/declance.c
@@ -607,7 +607,7 @@ static int lance_rx(struct net_device *dev)
len = (*rds_ptr(rd, mblength, lp->type) & 0xfff) - 4;
skb = netdev_alloc_skb(dev, len + 2);
- if (skb == 0) {
+ if (skb == NULL) {
dev->stats.rx_dropped++;
*rds_ptr(rd, mblength, lp->type) = 0;
*rds_ptr(rd, rmd1, lp->type) =
--
1.7.12.4
^ permalink raw reply related
* [PATCH 2/2] ethernet: lpc_eth: Use NULL to compare with pointer-typed value rather than 0
From: zhong jiang @ 2018-08-17 13:18 UTC (permalink / raw)
To: davem; +Cc: vz, slemieux.tyco, keescook, netdev, linux-kernel
In-Reply-To: <1534511933-39236-1-git-send-email-zhongjiang@huawei.com>
We should use NULL to compare with pointer-typed value rather than 0.
The issue is detected with the help of Coccinelle.
---
drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 08381ef..04d9e62 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1350,7 +1350,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
"IRAM not big enough for net buffers, using SDRAM instead.\n");
}
- if (pldat->dma_buff_base_v == 0) {
+ if (pldat->dma_buff_base_v == NULL) {
ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
goto err_out_free_irq;
--
1.7.12.4
^ permalink raw reply related
* Re: [iproute PATCH 07/10] ip: Add missing -M flag to help text
From: Phil Sutter @ 2018-08-17 11:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20180816102802.31782-8-phil@nwl.cc>
Hi Stephen,
On Thu, Aug 16, 2018 at 12:27:59PM +0200, Phil Sutter wrote:
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> ip/ip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Seems like this patch wasn't applied. Did you perhaps drop it by
accident?
Cheers, Phil
^ permalink raw reply
* Re: [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Jakub Kicinski @ 2018-08-17 11:27 UTC (permalink / raw)
To: Eelco Chaudron
Cc: David Miller, netdev, jhs, xiyou.wangcong, jiri, simon.horman,
Marcelo Ricardo Leitner
In-Reply-To: <4E288F34-0559-4C8A-8B3B-4410364791AA@redhat.com>
On Thu, 16 Aug 2018 14:02:44 +0200, Eelco Chaudron wrote:
> On 11 Aug 2018, at 21:06, David Miller wrote:
>
> > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Date: Thu, 9 Aug 2018 20:26:08 -0700
> >
> >> It is not immediately clear why this is needed. The memory and
> >> updating two sets of counters won't come for free, so perhaps a
> >> stronger justification than troubleshooting is due? :S
> >>
> >> Netdev has counters for fallback vs forwarded traffic, so you'd know
> >> that traffic hits the SW datapath, plus the rules which are in_hw
> >> will
> >> most likely not match as of today for flower (assuming correctness).
>
> I strongly believe that these counters are a requirement for a mixed
> software/hardware (flow) based forwarding environment. The global
> counters will not help much here as you might have chosen to have
> certain traffic forwarded by software.
>
> These counters are probably the only option you have to figure out why
> forwarding is not as fast as expected, and you want to blame the TC
> offload NIC.
The suggested debugging flow would be:
(1) check the global counter for fallback are incrementing;
(2) find a flow with high stats but no in_hw flag set.
The in_hw indication should be sufficient in most cases (unless there
are shared blocks between netdevs of different ASICs...).
> >> I'm slightly concerned about potential performance impact, would you
> >> be able to share some numbers for non-trivial number of flows (100k
> >> active?)?
> >
> > Agreed, features used for diagnostics cannot have a harmful penalty
> > for fast path performance.
>
> Fast path performance is not affected as these counters are not
> incremented there. They are only incremented by the nic driver when they
> gather their statistics from hardware.
Not by much, you are adding state to performance-critical structures,
though, for what is effectively debugging purposes.
I was mostly talking about the HW offload stat updates (sorry for not
being clear).
We can have some hundreds of thousands active offloaded flows, each of
them can have multiple actions, and stats have to be updated multiple
times per second and dumped probably around once a second, too. On a
busy system the stats will get evicted from cache between each round.
But I'm speculating let's see if I can get some numbers on it (if you
could get some too, that would be great!).
> However, the flow creation is effected, as this is where the extra
> memory gets allocated. I had done some 40K flow tests before and did not
> see any noticeable change in flow insertion performance. As requested by
> Jakub I did it again for 100K (and threw a Netronome blade in the mix
> ;). I used Marcelo’s test tool,
> https://github.com/marceloleitner/perf-flower.git.
>
> Here are the numbers (time in seconds) for 10 runs in sorted order:
>
> +-------------+----------------+
> | Base_kernel | Change_applied |
> +-------------+----------------+
> | 5.684019 | 5.656388 |
> | 5.699658 | 5.674974 |
> | 5.725220 | 5.722107 |
> | 5.739285 | 5.839855 |
> | 5.748088 | 5.865238 |
> | 5.766231 | 5.873913 |
> | 5.842264 | 5.909259 |
> | 5.902202 | 5.912685 |
> | 5.905391 | 5.947138 |
> | 6.032997 | 5.997779 |
> +-------------+----------------+
>
> I guess the deviation is in the userspace part, which is where in real
> life flows get added anyway.
>
> Let me know if more is unclear.
^ permalink raw reply
* [PATCH] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Fabrizio Castro @ 2018-08-17 14:38 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, David S. Miller, linux-can, netdev, devicetree,
Simon Horman, Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc, linux-kernel
Document RZ/G2M (r8a774a1) SoC bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
This patch applies on top of next-20180817
Documentation/devicetree/bindings/net/can/rcar_can.txt | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33..84afc78 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings
Required properties:
- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
+ "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC.
"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
"renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
@@ -16,7 +17,8 @@ Required properties:
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
compatible device.
- "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
+ "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2
+ compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
followed by the generic version.
@@ -24,7 +26,9 @@ Required properties:
- reg: physical base address and size of the R-Car CAN register map.
- interrupts: interrupt specifier for the sole interrupt.
- clocks: phandles and clock specifiers for 3 CAN clock inputs.
-- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk".
+- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk", and
+ 3 clock input name strings for every other SoC: "clkp1", "clkp2",
+ "can_clk".
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
--
2.7.4
^ permalink raw reply related
* Re: ANNOUNCE: pahole v1.12 (BTF edition)
From: Arnaldo Carvalho de Melo @ 2018-08-17 14:38 UTC (permalink / raw)
To: Jan Engelhardt
Cc: dwarves, Dodji Seketeli,
Linux Networking Development Mailing List,
Linux Kernel Mailing List
In-Reply-To: <nycvar.YFH.7.76.1808162328040.2839@n3.vanv.qr>
Em Thu, Aug 16, 2018 at 11:49:38PM +0200, Jan Engelhardt escreveu:
> On Thursday 2018-08-16 22:09, Arnaldo Carvalho de Melo wrote:
>
> > After a long time without announces, here is pahole 1.12,
> >available at:
> >
> > https://fedorapeople.org/~acme/dwarves/dwarves-1.12.tar.bz2
> >
> > git://git.kernel.org/pub/scm/devel/pahole/pahole.git
> >
> > Some distros haven't picked 1.11, that comes with several
> >goodies, my bad for not having announced it at that time more widely,
>
> Missing announcements can be forgiven. But there are automatic tools
> that scrape the web for updates (usually something tries to scan
> the enclosing directory of the last known URL), so uploads are
> essential.
> Since 1.11 was never uploaded, it did not find its way..
> (One had to grab a tarball gitweb generated from the tag,
> but had to know there was a 1.11, too).
>
>
> Can we have signatures for the release tarballs?
> (Only if you think it's worth having.)
Yeah, I think I can create a file with sha256 for the tarball and sign
it, just like I signed the v1.12 tag:
https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tag/?h=v1.12
> >Please report any problems to me, I'll try and get problems fixed.
>
> Here's one (or six):
Yeah, C++ has been a second class citizen for all pahole's life, with
progress being made mostly when I collaborate with folks at the ATLAS
project at CERN that had tons of C++ code being ported from 32-bit based
clusters to 64-bit ones.
I'll try to work some time on the reports below to see if we get a bit
more progress there.
> $ cat x.cpp
> #include <utility>
> struct F {
> template<typename T, typename... A> F(T &, T &&, A &&...x) { }
> F clone() const && { int q; return F(q, 3, 4); }
> int xpub() { return xprot(); }
> protected:
> int xprot() { return xpriv(); }
> private:
> int xpriv() { return 0; }
> };
> int z;
> F f(z,2,3,4);
> int main()
> {
> f.xpub();
> std::move(f).clone();
> }
>
>
> $ g++-7 x.cpp -c -ggdb3 -Wall && pahole x.o
> die__process_function: tag not supported 0x2f (template_type_parameter)!
> //expected: handle type
> die__process_function: tag not supported 0x4107 (GNU_template_parameter_pack)!
> //expected: handle type
> die__process_function: tag not supported 0x4108 (GNU_formal_parameter_pack)!
> //expected: handle type
> ftype__recode_dwarf_types: couldn't find 0x321 abstract_origin for 0x397 (formal_parameter)!
> //expected: handle type
> ftype__recode_dwarf_types: couldn't find 0x326 abstract_origin for 0x39f (formal_parameter)!
> ftype__recode_dwarf_types: couldn't find 0x3e0 abstract_origin for 0x447 (formal_parameter)!
> struct F {
> class F clone(const class F *);
> //expected: "struct F clone(const struct F *&&);"
>
> int xpub(class F *);
>
> protected:
>
> int xprot(class F *);
>
> private:
>
> int xpriv(class F *);
>
> //expected: "public:"
>
> void F<int, int, int>(class F *, int &, , , );
> //expected: "void F<int, int, int>(struct F *, int &, int &&, int &&, int &&);
>
> void F<int, int>(class F *, int &, , );
> //expected: "void F<int, int, int>(struct F *, int &, int &&, int &&);
>
> /* size: 1, cachelines: 0, members: 0 */
> /* last cacheline: 1 bytes */
> };
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Dan Carpenter @ 2018-08-17 14:47 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Kees Cook, Security Officers, Kevin Deus, Samuel Ortiz,
David S. Miller, Allen Pais, linux-wireless, Network Development,
LKML
In-Reply-To: <20180817120650.6mx6icxif2o52qyx@mwanda>
Never mind. This code is a bit subtle for static analysis so those
warnings are false positives. Thanks for taking a look at this, Suren.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Dan Carpenter @ 2018-08-17 12:06 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Kees Cook, Security Officers, Kevin Deus, Samuel Ortiz,
David S. Miller, Allen Pais, linux-wireless, Network Development,
LKML
In-Reply-To: <CAJuCfpH9n2vVjBF7RoMNng3T=URY1eusKfbVGyq44LWcjwNTPw@mail.gmail.com>
On Wed, Aug 15, 2018 at 09:40:13AM -0700, Suren Baghdasaryan wrote:
> On Wed, Aug 15, 2018 at 1:29 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Tue, Aug 14, 2018 at 03:38:14PM -0700, Suren Baghdasaryan wrote:
> >> The separate fix for the size of pipes[] array is posted here:
> >> https://lkml.org/lkml/2018/8/14/1034
> >> Thanks!
> >>
> >
> > That's great! Let's add some bounds checking to nfc_hci_msg_rx_work()
> > and nfc_hci_recv_from_llc() as well and then we can close the chapter on
> > these bugs.
>
> Dan, I don't think we need additional checks there. Here are the
> relevant parts of the code in nfc_hci_recv_from_llc():
>
Sorry, I meant after that at the end of the function:
net/nfc/hci/core.c
902 /* if this is a response, dispatch immediately to
903 * unblock waiting cmd context. Otherwise, enqueue to dispatch
904 * in separate context where handler can also execute command.
905 */
906 packet = (struct hcp_packet *)hcp_skb->data;
907 type = HCP_MSG_GET_TYPE(packet->message.header);
908 if (type == NFC_HCI_HCP_RESPONSE) {
909 pipe = packet->header;
^^^^^^^^^^^^^^^^^^^^^
Pipe can go up to 255.
910 instruction = HCP_MSG_GET_CMD(packet->message.header);
911 skb_pull(hcp_skb, NFC_HCI_HCP_PACKET_HEADER_LEN +
912 NFC_HCI_HCP_MESSAGE_HEADER_LEN);
913 nfc_hci_hcp_message_rx(hdev, pipe, type, instruction, hcp_skb);
^^^^
Then inside the nfc_hci_hcp_message_rx() function we call
nfc_hci_cmd_received() and nfc_hci_event_received() which use it as an
array index.
914 } else {
915 skb_queue_tail(&hdev->msg_rx_queue, hcp_skb);
916 schedule_work(&hdev->msg_rx_work);
917 }
918 }
It's the same thing when nfc_hci_hcp_message_rx() is called from
nfc_hci_msg_rx_work():
138 static void nfc_hci_msg_rx_work(struct work_struct *work)
139 {
140 struct nfc_hci_dev *hdev = container_of(work, struct nfc_hci_dev,
141 msg_rx_work);
142 struct sk_buff *skb;
143 struct hcp_message *message;
144 u8 pipe;
145 u8 type;
146 u8 instruction;
147
148 while ((skb = skb_dequeue(&hdev->msg_rx_queue)) != NULL) {
149 pipe = skb->data[0];
^^^^^^^^^^^^^^^^^^^
150 skb_pull(skb, NFC_HCI_HCP_PACKET_HEADER_LEN);
151 message = (struct hcp_message *)skb->data;
152 type = HCP_MSG_GET_TYPE(message->header);
153 instruction = HCP_MSG_GET_CMD(message->header);
154 skb_pull(skb, NFC_HCI_HCP_MESSAGE_HEADER_LEN);
155
156 nfc_hci_hcp_message_rx(hdev, pipe, type, instruction, skb);
^^^^
157 }
158 }
regards,
dan carpenter
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Peter Robinson @ 2018-08-17 12:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Marc Haber, linux-arm-kernel, netdev, labbott, Eric Dumazet,
Daniel Borkmann
In-Reply-To: <20180816225844.GW30658@n2100.armlinux.org.uk>
On Thu, Aug 16, 2018 at 11:58 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Aug 16, 2018 at 10:35:16PM +0200, Marc Haber wrote:
>> On Mon, Jun 25, 2018 at 05:41:27PM +0100, Peter Robinson wrote:
>> > So with that and the other fix there was no improvement, with those
>> > and the BPF JIT disabled it works, I'm not sure if the two patches
>> > have any effect with the JIT disabled though.
>>
>> I can confirm the crash with the released 4.18.1 on Banana Pi, and I can
>> also confirm that disabling BPF JIT makes the Banana Pi work again.,
>
> Hi,
>
> I'm afraid that the information in the crash dumps is insufficient
> to be able to work very much out about these crashes.
>
> We need a recipe (kernel configuration and what userspace is doing)
> so that it's possible to recreate the crash, or we need responses
> to requests for information - I requested the disassembly of
> sk_filter_trim_cap and the BPF code dump via setting a sysctl back
> in early July. Without this, as I say, I don't see how this problem
> can be progressed.
I can provide a kernel config [1] but I've not had enough time to sit
down and get the rest of the stuff and debug it due to a combination
of travel and other priorities.
> If the problem is at boot, one way to set the sysctl would be to
> hack the kernel and explicitly initialise the sysctl to '2', or
> boot with init=/bin/sh, then manually mount /proc, set the sysctl,
> and then "exec /sbin/init" from that shell. (Remember there's no
> job control in that shell, so ^z, ^c, etc do not work.)
It starts to happen in the early kernel boot long before we get to any
userspace across a number of ARMv7 devices (RPi2/3, BeagleBone and
AllWinner H3 based devices at least).
[1] https://pbrobinson.fedorapeople.org/kernel-armv7hl.config
^ permalink raw reply
* Re: [PATCH 2/2] ethernet: lpc_eth: Use NULL to compare with pointer-typed value rather than 0
From: Vladimir Zapolskiy @ 2018-08-17 15:29 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: slemieux.tyco, keescook, netdev, linux-kernel
In-Reply-To: <1534511933-39236-3-git-send-email-zhongjiang@huawei.com>
Hi zhong jiang,
On 08/17/2018 04:18 PM, zhong jiang wrote:
> We should use NULL to compare with pointer-typed value rather than 0.
> The issue is detected with the help of Coccinelle.
> ---
> drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> index 08381ef..04d9e62 100644
> --- a/drivers/net/ethernet/nxp/lpc_eth.c
> +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> @@ -1350,7 +1350,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
> "IRAM not big enough for net buffers, using SDRAM instead.\n");
> }
>
> - if (pldat->dma_buff_base_v == 0) {
> + if (pldat->dma_buff_base_v == NULL) {
That's a valid finding, but please use a common 0 and NULL comparison in form of
if (!pldat->dma_buff_base_v)
To the change above please feel free to add my
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
> ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (ret)
> goto err_out_free_irq;
>
^ permalink raw reply
* [PATCH]ipv6: multicast: In mld_send_cr function moving read lock to second for loop
From: Guruswamy Basavaiah @ 2018-08-17 12:31 UTC (permalink / raw)
To: netdev, davem, Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <CAHSpA58KdjMLnnGdbyDbASJLFuf2BHLsADBuO1jeT_1uFp9GUA@mail.gmail.com>
In function mld_send_cr, the first loop is already protected by
idev->mc_lock, it dont need idev->lock read lock, hence moving it
only to second for loop.
Signed-off-by: Guruswamy Basavaiah <guru2018@gmail.com>
---
net/ipv6/mcast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index d64ee7e..d8e7e15 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1860,7 +1860,6 @@ static void mld_send_cr(struct inet6_dev *idev)
struct sk_buff *skb = NULL;
int type, dtype;
- read_lock_bh(&idev->lock);
spin_lock(&idev->mc_lock);
/* deleted MCA's */
@@ -1897,6 +1896,7 @@ static void mld_send_cr(struct inet6_dev *idev)
}
spin_unlock(&idev->mc_lock);
+ read_lock_bh(&idev->lock);
/* change recs */
for (pmc = idev->mc_list; pmc; pmc = pmc->next) {
spin_lock_bh(&pmc->mca_lock);
--
2.9.5
^ permalink raw reply related
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Daniel Borkmann @ 2018-08-17 12:40 UTC (permalink / raw)
To: Peter Robinson, Russell King - ARM Linux
Cc: Marc Haber, linux-arm-kernel, netdev, labbott, Eric Dumazet
In-Reply-To: <CALeDE9Pm7nsqDFL0m0ZsNdnEti6YAbEPhtfbNMPe=UZCUyyHMA@mail.gmail.com>
On 08/17/2018 02:25 PM, Peter Robinson wrote:
> On Thu, Aug 16, 2018 at 11:58 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>> On Thu, Aug 16, 2018 at 10:35:16PM +0200, Marc Haber wrote:
>>> On Mon, Jun 25, 2018 at 05:41:27PM +0100, Peter Robinson wrote:
>>>> So with that and the other fix there was no improvement, with those
>>>> and the BPF JIT disabled it works, I'm not sure if the two patches
>>>> have any effect with the JIT disabled though.
>>>
>>> I can confirm the crash with the released 4.18.1 on Banana Pi, and I can
>>> also confirm that disabling BPF JIT makes the Banana Pi work again.,
>>
>> I'm afraid that the information in the crash dumps is insufficient
>> to be able to work very much out about these crashes.
>>
>> We need a recipe (kernel configuration and what userspace is doing)
>> so that it's possible to recreate the crash, or we need responses
>> to requests for information - I requested the disassembly of
>> sk_filter_trim_cap and the BPF code dump via setting a sysctl back
>> in early July. Without this, as I say, I don't see how this problem
>> can be progressed.
>
> I can provide a kernel config [1] but I've not had enough time to sit
> down and get the rest of the stuff and debug it due to a combination
> of travel and other priorities.
Did you get a chance to try latest kernel from Linus' tree [1] from last
few days to see whether the issue is still persistent? There have been
a number of improvements, bit strange why e.g. Russell didn't run into
it while others have, hmm. Perhaps due to EABI vs non EABI.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> If the problem is at boot, one way to set the sysctl would be to
>> hack the kernel and explicitly initialise the sysctl to '2', or
>> boot with init=/bin/sh, then manually mount /proc, set the sysctl,
>> and then "exec /sbin/init" from that shell. (Remember there's no
>> job control in that shell, so ^z, ^c, etc do not work.)
>
> It starts to happen in the early kernel boot long before we get to any
> userspace across a number of ARMv7 devices (RPi2/3, BeagleBone and
> AllWinner H3 based devices at least).
>
> [1] https://pbrobinson.fedorapeople.org/kernel-armv7hl.config
I'd have one potential bug suspicion, for the 4.18 one you were trying,
could you run with the below patch to see whether it would help?
Thanks,
Daniel
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index f6a62ae..c864f6b 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -238,7 +238,7 @@ static void jit_fill_hole(void *area, unsigned int size)
#define STACK_SIZE ALIGN(_STACK_SIZE, STACK_ALIGNMENT)
/* Get the offset of eBPF REGISTERs stored on scratch space. */
-#define STACK_VAR(off) (STACK_SIZE - off)
+#define STACK_VAR(off) (STACK_SIZE - off - 4)
#if __LINUX_ARM_ARCH__ < 7
^ permalink raw reply related
* Re: [endianness bug] cxgb4: mk_act_open_req() buggers ->{local,peer}_ip on big-endian hosts
From: Ganesh Goudar @ 2018-08-17 13:05 UTC (permalink / raw)
To: Al Viro; +Cc: Rahul Lakkireddy, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180814212524.GT6515@ZenIV.linux.org.uk>
Thanks, Al. The patch looks good to me but it does not seem
to be showing up in patchwork, should I resend the patch on
your behalf to net tree ?
Ganesh
^ permalink raw reply
* [PATCH ethtool] ethtool: document WoL filters option also in help message
From: Michal Kubecek @ 2018-08-17 13:21 UTC (permalink / raw)
To: John W. Linville; +Cc: Florian Fainelli, netdev
Commit eff0bb337223 ("ethtool: Add support for WAKE_FILTER (WoL using
filters)") added option "f" for wake on lan and documented it in man page
but not in the output of "ethtool --help".
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ethtool.c b/ethtool.c
index aa2bbe9e4c65..e8b7703293d2 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -5069,7 +5069,7 @@ static const struct option {
" [ advertise %x ]\n"
" [ phyad %d ]\n"
" [ xcvr internal|external ]\n"
- " [ wol p|u|m|b|a|g|s|d... ]\n"
+ " [ wol p|u|m|b|a|g|s|f|d... ]\n"
" [ sopass %x:%x:%x:%x:%x:%x ]\n"
" [ msglvl %d | msglvl type on|off ... ]\n" },
{ "-a|--show-pause", 1, do_gpause, "Show pause options" },
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Richard Cochran @ 2018-08-17 16:25 UTC (permalink / raw)
To: Bryan.Whitehead
Cc: arnd, UNGLinuxDriver, davem, yuehaibing, netdev, linux-kernel
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D2644073EA3B@CHN-SV-EXMX02.mchp-main.com>
On Wed, Aug 15, 2018 at 08:50:03PM +0000, Bryan.Whitehead@microchip.com wrote:
> Sounds reasonable to me. I will yield to Richard's insight.
> But it would be nice if requirements like these were documented.
I think the only reason for initializing to the system UTC (as most
drivers do) is historical. The first Intel driver was simply copied.
I've been thinking recently that we should standardize this. I'm open
for suggestions on how to do this. Remember that the system time is
likely wrong at driver initialization time.
Thanks,
Richard
^ 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