Hi Netdev,
Any help, much appreciated.
-Roobesh G M
From: Mohandass, Roobesh
Sent: Monday, December 31, 2018 1:13 PM
To: netdev@vger.kernel.org
Cc: Willy Tarreau
Subject: RE: [NETDEV]: getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is
in fact sometimes returning the source IP instead the
syzbot has found a reproducer for the following crash on:
HEAD commit:11587f6ee534 kmsan: remove pr_err
git tree: kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=114c539b40
kernel config: https://syzkaller.appspot.com/x/.config?x=c8a62a4eb8ea3e9f
dashboard link: htt
On Sun, Jan 06, 2019 at 04:23:50PM -0800, David Ahern wrote:
> From: David Ahern
>
> The bridge command 'vlan show' calls rtnl_linkdump_req_filter for
> family AF_BRIDGE. Update rtnl_linkdump_req_filter to send the filter
> for that family as well.
>
> Fixes: d97b16b2c906 ("libnetlink: linkdump_
On Sun, Jan 6, 2019 at 8:17 PM Michael S. Tsirkin wrote:
>
> On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote:
> >
> > On 2019/1/7 上午11:28, Michael S. Tsirkin wrote:
> > > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote:
> > > > On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:
>
On 2019-01-07 1:46 a.m., Kai Heng Feng wrote:
>
> Do you happen to use a Dell system? We can do some test here.
Yes. It is a Dell XPS 13 9360 i7-8550U notebook,
with the Dell WD15 USB-C dock.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 2019/1/5 上午8:33, Sean Christopherson wrote:
On Fri, Jan 04, 2019 at 04:29:34PM -0500, Michael S. Tsirkin wrote:
On Sat, Dec 29, 2018 at 08:46:52PM +0800, Jason Wang wrote:
Use one generic vhost_copy_to_user() instead of two dedicated
accessor. This will simplify the conversion to fine grai
On 2019/1/5 上午5:41, Michael S. Tsirkin wrote:
On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote:
This series tries to access virtqueue metadata through kernel virtual
address instead of copy_user() friends since they had too much
overheads like checks, spec barriers or even hardware f
On 2019/1/7 下午1:42, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 12:26:51PM +0800, Jason Wang wrote:
On 2019/1/5 上午5:25, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:25:14AM +0800, Jason Wang wrote:
On 2018/12/31 上午2:40, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 05:55:5
On 2019/1/7 下午12:23, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for
On 2019/1/7 下午12:17, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote:
On 2019/1/7 上午11:28, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote:
On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:
On Sat, Dec 29, 2018 at 08:46:5
> On Jan 7, 2019, at 12:13, Mark Lord wrote:
>
> On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>>
>>
>>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>>
>>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
PM, Mar
On 2019/1/7 下午12:01, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 11:51:55AM +0800, Jason Wang wrote:
On 2019/1/7 上午11:17, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:28:4
XPS settings based on CPU(s) map . we can use __netdev_pick_tx
to select the transmit queue,then we can improve performance
Cc: Yisen Zhuang
Cc: Salil Mehta
Cc: "David S. Miller"
Signed-off-by: yuqi jin
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 30 +
1 file
Hi tg3 folks,
Any idea how to solve the bug?
Kai-Heng
> On Dec 7, 2018, at 17:27, Kai Heng Feng wrote:
>
> Hi tg3 maintainers,
>
> I’ve encountered network freeze when using tg3 in gigabits net.
>
> The issue can be easily reproduced when using scp to transfer files in local
> network.
>
>
On Mon, Jan 07, 2019 at 12:26:51PM +0800, Jason Wang wrote:
>
> On 2019/1/5 上午5:25, Michael S. Tsirkin wrote:
> > On Wed, Jan 02, 2019 at 11:25:14AM +0800, Jason Wang wrote:
> > > On 2018/12/31 上午2:40, Michael S. Tsirkin wrote:
> > > > On Thu, Dec 27, 2018 at 05:55:52PM +0800, Jason Wang wrote:
>
On 2019/1/5 上午5:25, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:25:14AM +0800, Jason Wang wrote:
On 2018/12/31 上午2:40, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 05:55:52PM +0800, Jason Wang wrote:
On 2018/12/26 下午11:06, Michael S. Tsirkin wrote:
On Wed, Dec 26, 2018 at 12:0
On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
>
> On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
> > It's not uncommon to have two access two unrelated memory locations in a
> > specific order. At the moment one has to use a memory barrier for this.
> >
> > However, if the first acc
On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote:
>
> On 2019/1/7 上午11:28, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote:
> > > On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:
> > > > On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote:
> >
On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>
>
>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>
>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
>>> PM, Mark Lord
>>> wrote:
>>> ..
> There is even now a special ha
> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>
> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
>> Mark Lord
>> wrote:
>> ..
There is even now a special hack in the upstream r8152.c to attempt to
detect
>>>
On Mon, Jan 07, 2019 at 11:51:55AM +0800, Jason Wang wrote:
>
> On 2019/1/7 上午11:17, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
> > > On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
> > > > On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
> >
On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for this.
However, if the first access was a read and the second used an address
depending on the first one we w
Monday, January 07, 2019 5:17 AM
[...]
>> This is probably an xHC bug. A similar issue is fixed by commit 9da5a1092b13
>> ("xhci: Bad Ethernet performance plugged in ASM1042A host”).
>>
>>> I just got that exact message above, with the r8152 in my 1-day old WD15
>>> dock,
>>> with the TB16 "worka
On 2019/1/7 上午11:28, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote:
On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:
On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote:
This series tries to access virtqueue metadata through kernel virtual
address i
On 2019/1/7 上午11:17, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 06:00:
On Mon, 7 Jan 2019 at 01:55, David Miller wrote:
>
> From: Taehee Yoo
> Date: Sun, 6 Jan 2019 14:34:52 +0900
>
> > How about adding a new PF_UMH flag for task_struct->flags to identify
> > UMH process?
> > By using this flag, the exit_umh() can avoid unnecessary lookups.
>
> Yes, that might be mo
On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote:
>
> On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:
> > On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote:
> > > This series tries to access virtqueue metadata through kernel virtual
> > > address instead of copy_user() friends sin
On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
>
> On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
> > On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
> > > On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
> > > > On Thu, Dec 27, 2018 at 06:00:36PM +0800, Jason Wang wrote:
>
Recently we run a network test over ipcomp virtual tunnel.We find that
if a ipv4 packet needs fragment, then the peer can't receive
it.
We deep into the code and find that when packet need fragment the smaller
fragment will be encapsulated by ipip not ipcomp. So when the ipip packet
goes into xfrm
On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:
On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote:
This series tries to access virtqueue metadata through kernel virtual
address instead of copy_user() friends since they had too much
overheads like checks, spec barriers or even hardware f
On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 06:00:36PM +0800, Jason Wang wrote:
On 2018/12/26 下午11:19, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 04:1
Yes indeed, DIV_ROUND_UP is in kernel.h.
Signed-off-by: Jacob Wen
---
v1
- git rebase
---
net/rds/ib_send.c | 4 ++--
net/rds/message.c | 4 ++--
net/rds/rds.h | 4
net/rds/send.c| 2 +-
4 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/rds/ib_send.c b/net/rds/ib_s
From: David Ahern
The bridge command 'vlan show' calls rtnl_linkdump_req_filter for
family AF_BRIDGE. Update rtnl_linkdump_req_filter to send the filter
for that family as well.
Fixes: d97b16b2c906 ("libnetlink: linkdump_req: Only AF_UNSPEC family expects
an ext_filter_mask")
Reported-by: Ido S
[Sorry for the repost, screwed up the netdev address...]
Hi,
Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.
Since 4.2
syzbot has found a reproducer for the following crash on:
HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=165dec0740
kernel config: https://syzkaller.appspot.com/x/.config?x=b03c58
On 2019-01-06 4:13 p.m., Mark Lord wrote:
> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
> Mark Lord
> wrote:
> ..
>>> There is even now a special hack in the upstream r8152.c to attempt to
>>> detect
>>> a Dell TB16 dock and disable RX Aggregation in the driver t
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
Mark Lord
wrote:
..
>> There is even now a special hack in the upstream r8152.c to attempt to detect
>> a Dell TB16 dock and disable RX Aggregation in the driver to prevent such
>> issues.
>>
>> Well.. I have a WD15 doc
Avoid log spam caused by trying to read counters from the chip whilst
it is in a PCI power-save state.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=107421
Fixes: 1ef7286e7f36 ("r8169: Dereference MMIO address immediately before use")
Signed-off-by: Heiner Kallweit
---
drivers/net/ethe
> On Jan 5, 2019, at 10:14 PM, Mark Lord wrote:
>
> A couple of years back, I reported data corruption resulting from
> a change in kernel 3.16 which enabled hardware checksums in the r8152 driver.
> This was happening on an embedded system that was using a r8152 USB dongle.
>
> At the time,
On Wed, Jan 02, 2019 at 06:41:59PM -0200, Mauricio Faria de Oliveira wrote:
From: Ubuntu
[changelog]
- v2: include patch 5/5 (a very recent fix to patch 4/5) which is
not yet in Linus's tree but it's in nf.git + linux-next.git,
thus should make it shortly. Test results still consis
From: Taehee Yoo
Date: Sun, 6 Jan 2019 14:34:52 +0900
> How about adding a new PF_UMH flag for task_struct->flags to identify
> UMH process?
> By using this flag, the exit_umh() can avoid unnecessary lookups.
Yes, that might be more efficient and eliminate the high cost for
non-UMH tasks.
On 29.12.2018 17:59, Norbert Jurkeit wrote:
> Am 29.12.18 um 16:44 schrieb Heiner Kallweit:
>>
>> I don't think this patch can have any impact on the issue. Maybe WoL is
>> still active from previous test?
>> Manual WoL settings may survive a reboot, you can disable WoL by "ethtool -s
>> wol d".
On 7/1/18 1:08 PM, Andreas Färber wrote:
> The IMST WiMOD uses a SLIP based binary UART protocol. Two separate
> firmwares are available. By default it ships with a LoRaWAN firmware.
> The alternative firmware is a custom P2P addressing mode based on LoRa.
>
> Cc: Jon Ortego
> Signed-off-by: Andr
On 2019-01-05 12:03 a.m., Cong Wang wrote:
(Cc'ing Jamal)
On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois wrote:
Basically my current scenario looks like this:
- router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
- around 1000-2000 ip addresses in differnets subnets behind router (on
the L
On Tue, 2019-01-01 at 09:53 -0800, David Miller wrote:
> From: Radu Rendec Date: Sat, 29 Dec 2018 13:26:34 -0500
>
> > I'm working on some application-specific NIC driver. On the TX path, it
> > must remove a custom tag that sits between the Ethernet type field and
> > the actual Ethernet payload
On 2019/01/06 22:24, Dmitry Vyukov wrote:
>> A report at 2019/01/05 10:08 from "no output from test machine (2)"
>> ( https://syzkaller.appspot.com/text?tag=CrashLog&x=1700726f40 )
>> says that there are flood of memory allocation failure messages.
>> Since continuous memory allocation failure
On Sat, Jan 5, 2019 at 11:49 AM Tetsuo Handa
wrote:
>
> On 2019/01/03 2:06, Tetsuo Handa wrote:
> > On 2018/12/31 17:24, Dmitry Vyukov wrote:
> Since this involves OOMs and looks like a one-off induced memory
> corruption:
>
> #syz dup: kernel panic: corrupted stack end in wb_
On 06.01.2019 01:12, Florian Fainelli wrote:
>
>
> On January 5, 2019 5:21:03 AM PST, Heiner Kallweit
> wrote:
>> During a bug analysis we came across the fact that there's no guarantee
>> that reading from the ID registers returns a valid value if PHY is
>> powered down. When reading invalid v
On Sat, Jan 5, 2019 at 8:35 PM Nikola Ciprich
wrote:
>
> Hi Saeed,
>
>
> > Most likely the same issue, we are finalizing the patch initially
> > proposed by Cong, you can find it here, I plan to submit it next week,
> > after all the regression tests.
> >
> > https://git.kernel.org/pub/scm/linux/k
Hello,
This series fixes a number of issues that stood in the way of enabling the
regmap cache for SX130x. It goes on to enable REGCACHE_RBTREE.
1) Soft reset needs special treatment.
2) More registers need to be treated as volatile.
3) Some register field writes need to be forced.
This compleme
This helps detect issues such as the concentrator being in reset.
Enhance error output while at it.
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx125x.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/lora/sx125x.c b/drivers/net/lora/sx125x.c
index 90
Ben's regmap field conversion patch silently dropped my sx1301_soft_reset()
helper.
Soft reset is a special operation, so restore this function as
sx130x_soft_reset().
To be squashed.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 7 ++-
1 file changed, 6 i
Ensure that the F_FORCE_HOST_RADIO_CTRL field gets written before we read
the AGC status register. Otherwise it returns status 01 instead of 87.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
The soft reset bit is volatile. As it lives in the frequently accessed
page register, refrain from marking the register as volatile and
instead bypass the cache for this one write.
Mark the cache as dirty afterwards. This does not appear to clear it,
so manually drop the whole cache. If we don't h
Use of -ENXIO results in a misleading error message from ip command:
RTNETLINK answers: No such device or address
Switch to -EIO for more accurate description:
RTNETLINK answers: Input/output error
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 10 +-
1 file changed
AGC status register reads should not be cached.
Sort the volatile registers by number while at it.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/lora/sx130x.c b/drivers/net/lora/
Ensure timing is as expected by forcing a register write before waiting on
its outcome.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/lora/sx130x.c b/drivers/net/lora/sx130x.c
index 457
As a cautionary step, force writing out registers before calling helpers
or returning.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/lora/sx130x.c b/drivers/net/lora/sx130x.c
When toggling the value of a regmap field, such as for F_RADIO_RST or
F_EMERGENCY_FORCE_HOST_CTRL, we need to ensure it gets written out.
Sadly the timing of the writes got lost in the regmap field conversion.
Introduce an sx130x_field_force_write() helper for this.
While at it, make trivial sx13
To fix performance penalties compared to pre-regmap field code,
enable caching.
Note: This has been tested to not regress on spi-gpio, with no
improvement on spi-sun6i for clk_prepare() locking issue.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 2 +-
1 file ch
For reasons as of yet unknown, this is necessary to unbreak ARB firmware
version check.
Cc: Ben Whitten
Signed-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/lora/sx130x.c b/drivers/net/lora/sx130x.c
index 8bdd343a273f..76c
On 1/3/2019 7:23 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This patch solves a crash at the time of mlx4 driver unload or system
> shutdown. The crash occurs because dma_alloc_coherent() returns one
> value in mlx4_alloc_icm_coherent(), but a different value is passed to
> dma_free_c
On 1/3/2019 7:23 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> pci_{,un}map_sg are deprecated and replaced by dma_{,un}map_sg. This is
> especially relevant since the rest of the driver uses the DMA API. Fix
> the driver to use the replacement APIs.
>
> Signed-off-by: Stephen Warren
>
On 1/4/2019 11:42 PM, David Miller wrote:
>
> Mellanox folks, these two patches could use some review.
>
> Thank you.
>
Sure. They were sent on our weekend. Reviewing now.
64 matches
Mail list logo
