On 9/27/18 3:36 PM, Cong Wang wrote:
> On Thu, Sep 27, 2018 at 2:16 PM Eric Dumazet wrote:
>>
>>
>>
>> On 09/27/2018 01:42 PM, Cong Wang wrote:
>>> It is clearly a copy-n-paste.
>>>
>>> Signed-off-by: Cong Wang
>>> ---
>>> net/sched/cls_api.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/qlogic/qed/qed_ooo.c: In function 'qed_ooo_delete_isles':
drivers/net/ethernet/qlogic/qed/qed_ooo.c:354:30: warning:
variable 'p_archipelago' set but not used [-Wunused-but-set-variable]
Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
However, this is not true for test_bpf. As a result, test_bpf.ko crashes
the system with the following stack trace:
[ 1133.716622] BUG: unable to handle kernel paging request at 1030
[ 1133.716623] PGD
On Thu, Sep 27, 2018 at 1:35 AM, John Johansen
wrote:
> On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
>> On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
>>> Hello, Alexei and Daniel.
>>>
>>> Can you show us how to run testcases you are testing?
>>
>> Sorry for the delay; currently quite backlogged
On 2018年09月14日 12:46, Willem de Bruijn wrote:
I'm not sure I get this. If we don't enable tx napi, we tend to delay TX
interrupt if we found the ring is about to full to avoid interrupt
storm, so we're probably ok in this case.
I'm only concerned about the transition state when converting
On Thu, Sep 27, 2018 at 03:27:37PM +0800, Hangbin Liu wrote:
> Currently when we add geneve with "ttl inherit", we set ttl to 0, which
> is actually use whatever default value instead of inherit the inner
> protocol's ttl value.
>
> To respect compatibility with old behavior and make a difference
Hi Hangbin,
On Thu, Sep 27, 2018 at 03:28:36PM +0800, Hangbin Liu wrote:
> We should only show ttl inherit when IFLA_VXLAN_TTL_INHERIT supplied.
> Otherwise show the ttl number, or auto when it is 0.
>
> Signed-off-by: Hangbin Liu
> ---
> ip/iplink_vxlan.c | 16 ++--
> 1 file
ping.
On 2018/8/29 9:25, YueHaibing wrote:
> Remove duplicated include.
>
> Signed-off-by: YueHaibing
> ---
> drivers/net/can/usb/ucan.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
> index 0678a38..c6f4b41 100644
> ---
ping.
On 2018/8/29 9:46, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/can/usb/ucan.c: In function 'ucan_disconnect':
> drivers/net/can/usb/ucan.c:1578:21: warning:
> variable 'udev' set but not used [-Wunused-but-set-variable]
> struct usb_device *udev;
>
On 08/29/2018 03:46 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/can/usb/ucan.c: In function 'ucan_disconnect':
> drivers/net/can/usb/ucan.c:1578:21: warning:
> variable 'udev' set but not used [-Wunused-but-set-variable]
> struct usb_device *udev;
>
The structure shared between driver and the management FW (mfw) differ in
sizes. This would lead to issues when driver try to access the structure
members which are not-aligned with the mfw copy e.g., data_ptr usage in the
case of mfw_tlv request.
Align the driver structure with mfw copy, add
Hello, Dmirty,
Thank you for the explanation of how syzkaller/syzbot works in this and
other emails. I understand that is it a complicated task to determine
and categorize bugs based on just crash dump and messages, and syzkaller
does a great job of doing so.
> Re __hw_addr_add_ex bug, as Alex
Hi Dave,
Here's another - unfortunately pretty large - set of fixes
for the current cycle. The changes are pretty simple or even
trivial though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 28619527b8a712590c93d0a9e24b4425b9376a8c:
On Thu, Sep 27, 2018 at 1:17 PM, Vladis Dronov wrote:
> Hello, Dmirty,
>
> Thank you for the explanation of how syzkaller/syzbot works in this and
> other emails. I understand that is it a complicated task to determine
> and categorize bugs based on just crash dump and messages, and syzkaller
>
We need to explicitly zero is_sticky when creating a new fdb, otherwise
we might get a stale value for a new entry.
Fixes: 435f2e7cc0b7 ("net: bridge: add support for sticky fdb entries")
Signed-off-by: Nikolay Aleksandrov
---
net/bridge/br_fdb.c | 1 +
1 file changed, 1 insertion(+)
diff
Document RZ/G1N (r8a7744) SoC specific bindings.
Signed-off-by: Biju Das
Reviewed-by: Chris Paterson
---
This patch is tested against linux-next next-20180927
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree
The access of vsock is not protected by vhost_vsock_lock. This may
lead to use after free since vhost_vsock_dev_release() may free the
pointer at the same time.
Fix this by holding the lock during the access.
Reported-by: syzbot+e3e074963495f92a8...@syzkaller.appspotmail.com
Fixes: 16320f363ae1
On 2018年09月27日 17:52, Sergei Shtylyov wrote:
Hello!
On 9/27/2018 11:43 AM, Jason Wang wrote:
Just a couple of typos...
The access of vsock is not protected by vhost_vsock_lock. This may
lead use after free since vhost_vsock_dev_release() may free the
Lead to use.
pointer at the
Something is still broken also after commit b45e300 "libnetlink: don't
return error on success" - when error is returned, the error code is
success..
$ tc filter add dev enp33s0f0 protocol ip parent : flower skip_sw
ip_flags nofirstfrag action drop && echo "success" || echo "failed"
On 09/27/2018 12:15 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
>
> This patch fixes tes_bpf by adding a dummy struct
On Thu, 27 Sep 2018 15:22:41 +0300
Or Gerlitz wrote:
> Something is still broken also after commit b45e300 "libnetlink: don't
> return error on success" - when error is returned, the error code is
> success..
>
> $ tc filter add dev enp33s0f0 protocol ip parent : flower skip_sw
> ip_flags
Wed, Sep 26, 2018 at 01:52:58PM CEST, era...@mellanox.com wrote:
>The exception spec is targeted for Real Time Alerting, in order to know when
>something bad had happened to a PCI device
>- Provide alert debug information
>- Self healing
>- If problem needs vendor support, provide a way to gather
Hi,
On Thu, Sep 27, 2018 at 03:22:41PM +0300, Or Gerlitz wrote:
> Something is still broken also after commit b45e300 "libnetlink: don't
> return error on success" - when error is returned, the error code is
> success..
>
> $ tc filter add dev enp33s0f0 protocol ip parent : flower skip_sw
>
On 09/27/2018 12:15 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
> + dev_net_set(, );
This is yet another fake stuff
On 09/27/2018 01:10 AM, Dmitry Vyukov wrote:
>
> Would a stack trace for call_rcu be helpful here? I have this idea for
> a long time, but never get around to implementing it:
> https://bugzilla.kernel.org/show_bug.cgi?id=198437
>
> Also FWIW I recently used the following hack for another
On Thu, Sep 27, 2018 at 3:00 PM, Eric Dumazet wrote:
>
>
> On 09/27/2018 01:10 AM, Dmitry Vyukov wrote:
>
>>
>> Would a stack trace for call_rcu be helpful here? I have this idea for
>> a long time, but never get around to implementing it:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198437
>>
This is just a drive by guess, but I think this is a driver issue.
Issue 1 seems like a red herring, cat doesn't modify output, nor does ethtool
know if its output is going to a console or a pipe, its all the same. And given
issue 2 (that the output of the thresholds, etc are spurriously
Hi Thomas,
I'm trying to optimize this for crypto performance while still taking
into account preemption concerns. I'm having a bit of trouble figuring
out a way to determine numerically what the upper bounds for this
stuff looks like. I'm sure I could pick a pretty sane number that's
arguably
On Wed, Sep 26, 2018 at 11:58:12PM +0200, Andrew Lunn wrote:
> > When you run ethtool -m on this driver, the kernel calls
> > mlx4_en_get_module_info
> > to determine the length of the eeprom, and that value will be either 256 or
> > 512
> > bytes.
>
> So it sounds like QSFP modules using 8636
On 09/27/2018 06:02 AM, Dmitry Vyukov wrote:
> I am not suggesting to commit this. This is just a hack for debugging.
> It in fact lead to some warnings, but still allowed me to reproduce
> the bug reliably.
>
Had you got more meaningful stack traces ?
(Showing which context was actually
On Thu, Sep 27, 2018 at 07:12:27PM +0800, Yangbo Lu wrote:
> This patch is to move DPAA2 PTP driver out of staging/
> since the dpaa2-eth had been moved out.
>
> Signed-off-by: Yangbo Lu
> ---
> drivers/net/ethernet/freescale/Kconfig |9 +
>
Add support for the new sticky flag that can be set on fdbs and update the
man page.
CC: David Ahern
Signed-off-by: Nikolay Aleksandrov
---
bridge/fdb.c | 9 +++--
man/man8/bridge.8 | 6 +-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
This test adds an fdb entry with the sticky flag and sends traffic from
a different port with the same mac as a source address expecting the entry
to not change ports if the flag is operating correctly.
Signed-off-by: Nikolay Aleksandrov
---
.../selftests/net/forwarding/bridge_sticky_fdb.sh |
> -Original Message-
> From: laurentiu.tu...@nxp.com [mailto:laurentiu.tu...@nxp.com]
> Sent: Wednesday, September 26, 2018 4:22 PM
> To: devicet...@vger.kernel.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Cc: Roy Pledge ;
On Thu, Sep 27, 2018 at 3:24 PM, Eric Dumazet wrote:
> On 09/27/2018 06:02 AM, Dmitry Vyukov wrote:
>
>> I am not suggesting to commit this. This is just a hack for debugging.
>> It in fact lead to some warnings, but still allowed me to reproduce
>> the bug reliably.
>>
>
> Had you got more
Struct sff_diags can be used uninitialized at sff8636_show_dom, this
caused the tool to show unreported fields (supports_alarms) by the lower
level driver.
Fixes: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support")
Signed-off-by: Eran Ben Elisha
---
qsfp.c | 2 +-
1 file
On Thu, Sep 27, 2018 at 4:51 AM Jason Wang wrote:
>
>
>
> On 2018年09月14日 12:46, Willem de Bruijn wrote:
> >> I'm not sure I get this. If we don't enable tx napi, we tend to delay TX
> >> interrupt if we found the ring is about to full to avoid interrupt
> >> storm, so we're probably ok in this
On 9/27/2018 3:47 PM, Jiri Pirko wrote:
Wed, Sep 26, 2018 at 01:52:58PM CEST, era...@mellanox.com wrote:
The exception spec is targeted for Real Time Alerting, in order to know when
something bad had happened to a PCI device
- Provide alert debug information
- Self healing
- If problem needs
On 07/10/15 02:41, Jiri Pirko wrote:
Thu, Jul 09, 2015 at 05:36:55PM CEST, jblu...@infradead.org wrote:
On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko wrote:
Thu, Jul 09, 2015 at 11:58:34AM CEST, jblu...@infradead.org wrote:
The code in net/ipv6/addrconf.c:addrconf_notify() tests for
On Thu, Sep 27, 2018 at 11:27:45AM +0200, Phil Sutter wrote:
> Hi Hangbin,
>
> On Thu, Sep 27, 2018 at 03:28:36PM +0800, Hangbin Liu wrote:
> > We should only show ttl inherit when IFLA_VXLAN_TTL_INHERIT supplied.
> > Otherwise show the ttl number, or auto when it is 0.
> >
> > Signed-off-by:
On Thu, Sep 27, 2018 at 9:00 AM Eric Dumazet wrote:
>
>
>
> On 09/27/2018 12:15 AM, Song Liu wrote:
> > Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> > However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> > the system with the following stack
Wed, Sep 26, 2018 at 01:52:59PM CEST, era...@mellanox.com wrote:
>Add devlink-exception man page. Devlink-exception tool will control device
>exception attributes, conditions, actions and logging.
>
>Signed-off-by: Eran Ben Elisha
>
>---
>Copy
Fixes the following sparse warning:
net/sched/sch_generic.c:944:6: warning:
symbol 'qdisc_free_cb' was not declared. Should it be static?
Fixes: 3a7d0d07a386 ("net: sched: extend Qdisc with rcu")
Signed-off-by: Wei Yongjun
---
net/sched/sch_generic.c | 2 +-
1 file changed, 1 insertion(+), 1
Thu, Sep 27, 2018 at 04:02:48PM CEST, era...@mellanox.com wrote:
>
>
>On 9/27/2018 3:47 PM, Jiri Pirko wrote:
>> Wed, Sep 26, 2018 at 01:52:58PM CEST, era...@mellanox.com wrote:
>> > The exception spec is targeted for Real Time Alerting, in order to know
>> > when
>> > something bad had happened
On Thu, Sep 27, 2018 at 1:47 AM Stephen Hemminger
wrote:
>
> I haven't been doing reviews only but not active development on bridge
> code for several years. Roopa and Nikolay have been doing most of
> the new features and have agreed to take over as new co-maintainers.
>
> Signed-off-by: Stephen
Hello.
On 19/09/2018 16:41, zhong jiang wrote:
> The local variable 'i' is never used after being assigned.
> hence it should be redundant adn can be removed.
>
> Signed-off-by: zhong jiang
> ---
> net/ieee802154/nl802154.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
> Both drivers read up to 256 bytes. 0-127 (from page 0). and 128-256 (from
> page 0). Driver is not capable of reading over 256 bytes currently.
Hi Erin
There should not be any need to read more than 256 bytes. For older
SFP devices, two addresses on the i2c bus are used, each with 256
bytes.
On 9/27/2018 5:34 PM, Jiri Pirko wrote:
Thu, Sep 27, 2018 at 04:02:48PM CEST, era...@mellanox.com wrote:
On 9/27/2018 3:47 PM, Jiri Pirko wrote:
Wed, Sep 26, 2018 at 01:52:58PM CEST, era...@mellanox.com wrote:
The exception spec is targeted for Real Time Alerting, in order to know when
On 27/09/18 11:47, Stephen Hemminger wrote:
> I haven't been doing reviews only but not active development on bridge
> code for several years. Roopa and Nikolay have been doing most of
> the new features and have agreed to take over as new co-maintainers.
>
> Signed-off-by: Stephen Hemminger
>
Hello Zhong.
On 14/09/2018 07:04, zhong jiang wrote:
> debugfs_remove has taken the IS_ERR into account. Just
> remove the unnecessary condition.
>
> Signed-off-by: zhong jiang
> ---
> drivers/net/ieee802154/ca8210.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git
Hey again Thomas,
On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>
> Hi Thomas,
>
> I'm trying to optimize this for crypto performance while still taking
> into account preemption concerns. I'm having a bit of trouble figuring
> out a way to determine numerically what the upper bounds
On 9/27/2018 5:52 PM, Andrew Lunn wrote:
Both drivers read up to 256 bytes. 0-127 (from page 0). and 128-256 (from
page 0). Driver is not capable of reading over 256 bytes currently.
Hi Erin
There should not be any need to read more than 256 bytes. For older
SFP devices, two addresses on
Hi Hangbin,
On Thu, Sep 27, 2018 at 10:07:51PM +0800, Hangbin Liu wrote:
> On Thu, Sep 27, 2018 at 11:27:45AM +0200, Phil Sutter wrote:
> > On Thu, Sep 27, 2018 at 03:28:36PM +0800, Hangbin Liu wrote:
> > > We should only show ttl inherit when IFLA_VXLAN_TTL_INHERIT supplied.
> > > Otherwise show
://github.com/0day-ci/linux/commits/Arnd-Bergmann/mt76-fix-building-without-CONFIG_MT76x0U/20180927-101346
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce
> Driver return 256 bytes (reading it correctly, I verified it, no overruns),
> however the extra bytes are presented due to this bug (expecting to parse
> 640 bytes).
>
> Do you see another bug here? Am I missing something?
Hi Erin
Please could you try ethtool -m raw on so you get a binary
On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
> The access of vsock is not protected by vhost_vsock_lock. This may
> lead to use after free since vhost_vsock_dev_release() may free the
> pointer at the same time.
>
> Fix this by holding the lock during the access.
>
> Reported-by:
On 25.09.18 23:03, Heiner Kallweit wrote:
It seems that all chip versions from 34 (= RTL8168E-VL) with the
exception of version 39 (= RTL8106E, first sub-version) need
bit TXCFG_AUTO_FIFO.
And indeed, due to reordering of calls this bit is overwritten.
Following patch moves setting the bit from
On Thu, Sep 27, 2018 at 04:48:35PM +0300, Eran Ben Elisha wrote:
> Struct sff_diags can be used uninitialized at sff8636_show_dom, this
> caused the tool to show unreported fields (supports_alarms) by the lower
> level driver.
>
> Fixes: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics
Please correct me if I'm wrong, but...
It looks like Eran's proposed fix would remove all warning and
alarm indications from ethtool's output. It's worth mentioning
that for me, the following fields always reported correctly
as Off while no alarm condition was present
and On while alarm
From: Colin Ian King
Trivial fix to spelling mistake struct field name, rename it.
Signed-off-by: Colin Ian King
---
drivers/net/wireless/broadcom/b43/b43.h | 2 +-
drivers/net/wireless/broadcom/b43/main.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
On Wed, Sep 19, 2018 at 12:02 PM Kirill Tkhai wrote:
>
> On 19.09.2018 18:49, Eric Dumazet wrote:
> > On Wed, Sep 19, 2018 at 8:41 AM Kirill Tkhai wrote:
> >>
> >> On 19.09.2018 17:55, Eric Dumazet wrote:
> >>> On Wed, Sep 19, 2018 at 5:29 AM Kirill Tkhai wrote:
>
> Many workloads
From: Anirudh Venkataramanan
Query the Tx scheduler tree node information from FW before adding it to
the driver's software database. This will keep the node information current
in driver.
Signed-off-by: Anirudh Venkataramanan
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
From: Bruce Allan
rx_mini_pending was set to an incorrect value. This was causing EINVAL to
always be returned to 'ethtool -G'. The driver does not support mini or
jumbo rings so the respective settings should be zero.
Also, change the valid range of the number of descriptors in the rings to
From: Jacob Keller
When shutting down the controlqs, we check if they are initialized
before we shut them down and destroy the lock. This is important, as it
prevents attempts to access the lock of an already shutdown queue.
Unfortunately, we checked rq.head and sq.head as the value to
From: Anirudh Venkataramanan
This patch makes a couple of changes in the way the driver uses the
"get capabilities" command.
1. Get device capabilities in addition to function capabilities
2. Align to latest spec by using cap_count to determine size of the
buffer in case of length error.
This series contains fixes to the ice driver only.
Jake fixes a potential crash due to attempting to access the mutex which
is already destroyed. Fix this by using rq.count and sq.count to
determine if the queue was initialized. Fixed the current logic for
checking the firmware version to
From: Brett Creeley
Previously the comment stated that VSI lists should be used when a
second VSI becomes a subscriber to the "VLAN address". VSI lists
are always used for VLAN membership, so replace "VLAN address" with
"MAC address". Also note that VLAN(s) always use VSI list rules.
From: Bruce Allan
Update branding strings and remove device ids 0x1594 and 0x1595.
Signed-off-by: Bruce Allan
Signed-off-by: Anirudh Venkataramanan
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ice/ice_devids.h | 10 +++---
From: Jacob Keller
We have MAX_FW_API_VER_BRANCH, MAX_FW_API_VER_MAJOR, and
MAX_FW_API_VER_MINOR that we use in ice_controlq.h to test when a
firmware version is newer than expected. This is currently tested by
comparing each field separately. Thus, we compare the branch field
against the
From: Bruce Allan
Direct assignment is preferred over a memcpy()
Signed-off-by: Bruce Allan
Signed-off-by: Anirudh Venkataramanan
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ice/ice_controlq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
> On Sep 27, 2018, at 8:19 AM, Jason A. Donenfeld wrote:
>
> Hey again Thomas,
>
>> On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>>
>> Hi Thomas,
>>
>> I'm trying to optimize this for crypto performance while still taking
>> into account preemption concerns. I'm having a bit
On 9/27/18 8:32 AM, Jiri Pirko wrote:
> But still, I need the code so I can play with it, to
> see the outputs etc.
+1
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC).
This capture, showing one ksoftirqd eating all cycles
can last for unlimited amount of time, since
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
Since we do no longer require NAPI drivers to provide
an ndo_poll_controller(), napi_schedule() has not been done
before poll_one_napi() invocation.
So testing NAPI_STATE_SCHED is likely to cause early returns.
While we are at it, remove outdated comment.
Note to future bisections : This change
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC). This capture
can last for unlimited amount of time, since one
cpu is generally not able to drain all
Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
However, this is not true for test_bpf. As a result, test_bpf.ko crashes
the system with the following stack trace:
[ 1133.716622] BUG: unable to handle kernel paging request at 1030
[ 1133.716623] PGD
On Thu, Sep 27, 2018 at 04:08:24PM +, Chris Preimesberger wrote:
> Please correct me if I'm wrong, but...
> It looks like Eran's proposed fix would remove all warning and
> alarm indications from ethtool's output. It's worth mentioning
> that for me, the following fields always reported
On 09/27/2018 09:34 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
> This patch fixes tes_bpf by using init_net in the dummy
On Thu, Sep 27, 2018 at 12:40 PM Eric Dumazet wrote:
>
>
>
> On 09/27/2018 09:34 AM, Song Liu wrote:
> > Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> > However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> > the system with the following stack
On Thu, Sep 27, 2018 at 12:27 PM, Dmitry Vyukov wrote:
> On Thu, Sep 27, 2018 at 1:35 AM, John Johansen
> wrote:
>> On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
>>> On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
Hello, Alexei and Daniel.
Can you show us how to run testcases you are
On Thu, Sep 27, 2018 at 6:47 PM, Dmitry Vyukov wrote:
> On Thu, Sep 27, 2018 at 12:27 PM, Dmitry Vyukov wrote:
>> On Thu, Sep 27, 2018 at 1:35 AM, John Johansen
>> wrote:
>>> On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
> Hello, Alexei and
From: Colin Ian King
Trivial fix to spelling mistake struct field name, rename it.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 12 ++--
drivers/net/ethernet/qlogic/qed/qed_ll2.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
> The access of vsock is not protected by vhost_vsock_lock. This may
> lead to use after free since vhost_vsock_dev_release() may free the
> pointer at the same time.
>
> Fix this by holding the lock during the access.
>
> Reported-by:
On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski wrote:
> I would add another consideration: if you can get better latency with
> negligible overhead (0.1%? 0.05%), then that might make sense too. For
> example, it seems plausible that checking need_resched() every few blocks
> adds basically
> Thanks for the overview. We look forward to your patches; please
> include the same cc list as this series.
> I think it makes sense to have some OEM NCSI handing purely in the
> kenrel. This would allow eg. the MAC address of an interface to be
> correct at boot, without requiring userspace
On Thu, Sep 27, 2018 at 1:11 AM Dmitry Vyukov wrote:
>
> Would a stack trace for call_rcu be helpful here? I have this idea for
> a long time, but never get around to implementing it:
> https://bugzilla.kernel.org/show_bug.cgi?id=198437
Yes. Generally speaking, showing backtrace of call_rcu()
or
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong
1 - 100 of 195 matches
Mail list logo
