Re: [PATCH net-next] r8169: add module param for control of ASPM disable

2018-02-01 Thread Francois Romieu
net-next is closed anyway. -- Ueimor

Re: [PATCH net-next] r8169: add module param for control of ASPM disable

2018-02-01 Thread Francois Romieu
net-next is closed anyway. -- Ueimor

Re: [PATCH net-next] r8169: add module param for control of ASPM disable

2018-02-01 Thread Francois Romieu
Chunhao Lin : [...] > @@ -5878,6 +5881,20 @@ static void rtl_pcie_state_l2l3_enable(struct > rtl8169_private *tp, bool enable) > RTL_W8(Config3, data); > } > > +static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp, > +

Re: [PATCH net-next] r8169: add module param for control of ASPM disable

2018-02-01 Thread Francois Romieu
Chunhao Lin : [...] > @@ -5878,6 +5881,20 @@ static void rtl_pcie_state_l2l3_enable(struct > rtl8169_private *tp, bool enable) > RTL_W8(Config3, data); > } > > +static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp, > + bool enable) > +{ >

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-19 Thread Francois Romieu
Peter Zijlstra <pet...@infradead.org> : > On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote: > > Peter Zijlstra <pet...@infradead.org> : > > [...] > > > There is only 1 variable afaict. Memory barriers need at least 2 in > > > order to b

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-19 Thread Francois Romieu
Peter Zijlstra : > On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote: > > Peter Zijlstra : > > [...] > > > There is only 1 variable afaict. Memory barriers need at least 2 in > > > order to be able to do _anything_. > > > > I don'

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-19 Thread Francois Romieu
Jia-Ju Bai <baijiaju1...@gmail.com> : > > On 2018/1/19 9:11, Francois Romieu wrote: > > Jia-Ju Bai <baijiaju1...@gmail.com> : > > [...] > > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > > > if (unlikel

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-19 Thread Francois Romieu
Jia-Ju Bai : > > On 2018/1/19 9:11, Francois Romieu wrote: > > Jia-Ju Bai : > > [...] > > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > > > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { >

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Francois Romieu
Jia-Ju Bai : [...] > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { > netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n"); > goto err_stop_0; >

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Francois Romieu
Jia-Ju Bai : [...] > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { > netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n"); > goto err_stop_0; > } > But there is no

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Francois Romieu
Peter Zijlstra : [...] > There is only 1 variable afaict. Memory barriers need at least 2 in > order to be able to do _anything_. I don't get your point: why don't {cur_tx, dirty_tx} qualify as said two variables ? -- Ueimor

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Francois Romieu
Peter Zijlstra : [...] > There is only 1 variable afaict. Memory barriers need at least 2 in > order to be able to do _anything_. I don't get your point: why don't {cur_tx, dirty_tx} qualify as said two variables ? -- Ueimor

Re: [PATCH 1/2] r8169: reinstate ALDPS for power saving

2017-11-15 Thread Francois Romieu
David Miller : [...] > The amount of coverage this change is going to get is very small as > well, meaning an even greater chance of regressions. Yes. > Therefore the only acceptable way to handle this is to have > a white-list, specific chips that have been explicitly

Re: [PATCH 1/2] r8169: reinstate ALDPS for power saving

2017-11-15 Thread Francois Romieu
David Miller : [...] > The amount of coverage this change is going to get is very small as > well, meaning an even greater chance of regressions. Yes. > Therefore the only acceptable way to handle this is to have > a white-list, specific chips that have been explicitly tested > and are known to

Re: linux-next: Signed-off-by missing for commit in the net-next tree

2017-11-01 Thread Francois Romieu
Kirill Smelkov : [...] > I was keeping you in To and Cc all the time but got no reply at all since my > first posting from ~ 1 month ago. I thought it was longer than that. Sorry for the frustrating excess delay. As Eric already said there is no problem and I am perfectly fine

Re: linux-next: Signed-off-by missing for commit in the net-next tree

2017-11-01 Thread Francois Romieu
Kirill Smelkov : [...] > I was keeping you in To and Cc all the time but got no reply at all since my > first posting from ~ 1 month ago. I thought it was longer than that. Sorry for the frustrating excess delay. As Eric already said there is no problem and I am perfectly fine with the current

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

2017-10-05 Thread Francois Romieu
Daniel Drake : [...] > Also, is there a standard behaviour defined for ethernet drivers > regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default > if it believes the hardware is capable of it, If so it isn't its designed behavior. The r8169 driver does not

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

2017-10-05 Thread Francois Romieu
Daniel Drake : [...] > Also, is there a standard behaviour defined for ethernet drivers > regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default > if it believes the hardware is capable of it, If so it isn't its designed behavior. The r8169 driver does not enable specific WoL

Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

2017-08-11 Thread Francois Romieu
David Miller : [...] > Oops, this will need to be sent as a relative fixup as I've applied these > two patches to net-next, sorry Francois. No problem. It works perfectly this way. -- Ueimor

Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

2017-08-11 Thread Francois Romieu
David Miller : [...] > Oops, this will need to be sent as a relative fixup as I've applied these > two patches to net-next, sorry Francois. No problem. It works perfectly this way. -- Ueimor

Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

2017-08-11 Thread Francois Romieu
Alexey Khoroshilov : [...] > diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c > index 8480dbf..a043fb1 100644 > --- a/drivers/net/wan/dscc4.c > +++ b/drivers/net/wan/dscc4.c [...] > @@ -506,8 +506,9 @@ static void dscc4_release_ring(struct dscc4_dev_priv >

Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

2017-08-11 Thread Francois Romieu
Alexey Khoroshilov : [...] > diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c > index 8480dbf..a043fb1 100644 > --- a/drivers/net/wan/dscc4.c > +++ b/drivers/net/wan/dscc4.c [...] > @@ -506,8 +506,9 @@ static void dscc4_release_ring(struct dscc4_dev_priv > *dpriv) > skbuff =

Re: [PATCH net-next v2] wan: dscc4: add checks for dma mapping errors

2017-08-08 Thread Francois Romieu
Alexey Khoroshilov : [...] > diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c > index 799830f..6a9ffac 100644 > --- a/drivers/net/wan/dscc4.c > +++ b/drivers/net/wan/dscc4.c > @@ -518,23 +518,31 @@ static void dscc4_release_ring(struct dscc4_dev_priv >

Re: [PATCH net-next v2] wan: dscc4: add checks for dma mapping errors

2017-08-08 Thread Francois Romieu
Alexey Khoroshilov : [...] > diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c > index 799830f..6a9ffac 100644 > --- a/drivers/net/wan/dscc4.c > +++ b/drivers/net/wan/dscc4.c > @@ -518,23 +518,31 @@ static void dscc4_release_ring(struct dscc4_dev_priv > *dpriv) > static inline int

Re: [PATCH] wan: dscc4: add checks for dma mapping errors

2017-08-07 Thread Francois Romieu
Alexey Khoroshilov : > The driver does not check if mapping dma memory succeed. > The patch adds the checks and failure handling. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Please amend

Re: [PATCH] wan: dscc4: add checks for dma mapping errors

2017-08-07 Thread Francois Romieu
Alexey Khoroshilov : > The driver does not check if mapping dma memory succeed. > The patch adds the checks and failure handling. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Please amend your subject line as: Subject: [PATCH

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

2017-07-25 Thread Francois Romieu
Aviad Krawczyk : [...] > module_pci_driver - is not used in other drivers in the same segments, it > is necessary ? /me checks... Ok, there seems to be some overenthusiastic copy'paste. See drivers/net/ethernet/intel/ixgb/ixgb_main.c: [...] /** * ixgb_init_module -

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

2017-07-25 Thread Francois Romieu
Aviad Krawczyk : [...] > module_pci_driver - is not used in other drivers in the same segments, it > is necessary ? /me checks... Ok, there seems to be some overenthusiastic copy'paste. See drivers/net/ethernet/intel/ixgb/ixgb_main.c: [...] /** * ixgb_init_module - Driver Registration Routine

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

2017-07-24 Thread Francois Romieu
Aviad Krawczyk : [...] > hinic_remove - If insmod failed and someone calls rmmod, we will get a > crash because the resource are already free. Therefore we test if the > device exists, please tell me if you meant to something different The module won't even proceed

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

2017-07-24 Thread Francois Romieu
Aviad Krawczyk : [...] > hinic_remove - If insmod failed and someone calls rmmod, we will get a > crash because the resource are already free. Therefore we test if the > device exists, please tell me if you meant to something different The module won't even proceed through the pci_driver remove

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

2017-07-19 Thread Francois Romieu
Aviad Krawczyk : [...] > diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c > b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c > new file mode 100644 > index 000..fbc9de4 > --- /dev/null > +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c [...] >

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

2017-07-19 Thread Francois Romieu
Aviad Krawczyk : [...] > diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c > b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c > new file mode 100644 > index 000..fbc9de4 > --- /dev/null > +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c [...] > +/** > + * hinic_init_hwdev

Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down

2017-05-25 Thread Francois Romieu
David Miller : > From: Joshua Emele > Date: Wed, 24 May 2017 15:43:18 -0700 [...] > > The sky2_hw_down uses sky2_tx_complete to free pending frames stuck in > > the HW queue. Because sky2_hw_down can be called from a process context, > > the call to

Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down

2017-05-25 Thread Francois Romieu
David Miller : > From: Joshua Emele > Date: Wed, 24 May 2017 15:43:18 -0700 [...] > > The sky2_hw_down uses sky2_tx_complete to free pending frames stuck in > > the HW queue. Because sky2_hw_down can be called from a process context, > > the call to u64_stats_update_begin can result in deadlock.

Re: [PATCH v2] net: natsemi: ns83820: add checks for dma mapping error

2017-04-22 Thread Francois Romieu
Alexey Khoroshilov : [...] > diff --git a/drivers/net/ethernet/natsemi/ns83820.c > b/drivers/net/ethernet/natsemi/ns83820.c > index 729095db3e08..dfc64e1e31f9 100644 > --- a/drivers/net/ethernet/natsemi/ns83820.c > +++ b/drivers/net/ethernet/natsemi/ns83820.c [...] > @@

Re: [PATCH v2] net: natsemi: ns83820: add checks for dma mapping error

2017-04-22 Thread Francois Romieu
Alexey Khoroshilov : [...] > diff --git a/drivers/net/ethernet/natsemi/ns83820.c > b/drivers/net/ethernet/natsemi/ns83820.c > index 729095db3e08..dfc64e1e31f9 100644 > --- a/drivers/net/ethernet/natsemi/ns83820.c > +++ b/drivers/net/ethernet/natsemi/ns83820.c [...] > @@ -1183,6 +1193,32 @@

Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")

2017-04-08 Thread Francois Romieu
David Miller : [...] > One theory is that the interrupt masking isn't working properly > and interrupts are still arriving and hitting the NAPI state even > when we are actively polling NAPI. > > And this problem was masked by the locking done here. Yes. Ville, can you

Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")

2017-04-08 Thread Francois Romieu
David Miller : [...] > One theory is that the interrupt masking isn't working properly > and interrupts are still arriving and hitting the NAPI state even > when we are actively polling NAPI. > > And this problem was masked by the locking done here. Yes. Ville, can you rule out irq sharing

Re: net/atm: warning in alloc_tx/__might_sleep

2017-01-10 Thread Francois Romieu
Eric Dumazet : > On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang wrote: > > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov > > wrote: > > > > The fix should be straight-forward. Mind to try the attached patch? > > > You

Re: net/atm: warning in alloc_tx/__might_sleep

2017-01-10 Thread Francois Romieu
Eric Dumazet : > On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang wrote: > > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov > > wrote: > > > > The fix should be straight-forward. Mind to try the attached patch? > > > You forgot to remove schedule() ? It may be clearer to split alloc_tx in two

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-19 Thread Francois Romieu
Pavel Machek : [...] > Considering the memory barriers... is something like this neccessary > in the via-rhine ? Yes. > AFAICT... we need a barrier after making sure that descriptor is no > longer owned by DMA (to make sure we don't get stale data in rest of > descriptor)... and

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-19 Thread Francois Romieu
Pavel Machek : [...] > Considering the memory barriers... is something like this neccessary > in the via-rhine ? Yes. > AFAICT... we need a barrier after making sure that descriptor is no > longer owned by DMA (to make sure we don't get stale data in rest of > descriptor)... and we need a

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-17 Thread Francois Romieu
Pavel Machek : [...] > Won't this up/down the interface, in a way userspace can observe? It won't up/down the interface as it doesn't exactly mimic what the network code does (there's more than rtnl_lock). For the same reason it's broken if it races with the transmit path: it can

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-17 Thread Francois Romieu
Pavel Machek : [...] > Won't this up/down the interface, in a way userspace can observe? It won't up/down the interface as it doesn't exactly mimic what the network code does (there's more than rtnl_lock). For the same reason it's broken if it races with the transmit path: it can release driver

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-08 Thread Francois Romieu
Lino Sanfilippo : [...] > OTOH Pavel said that he actually could produce a deadlock. Now I wonder if > this is caused by that locking scheme (in a way I have not figured out yet) > or if it is a different issue. stmmac_tx_err races with stmmac_xmit. -- Ueimor

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-08 Thread Francois Romieu
Lino Sanfilippo : [...] > OTOH Pavel said that he actually could produce a deadlock. Now I wonder if > this is caused by that locking scheme (in a way I have not figured out yet) > or if it is a different issue. stmmac_tx_err races with stmmac_xmit. -- Ueimor

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-07 Thread Francois Romieu
Lino Sanfilippo : > The driver uses a private lock for synchronization between the xmit > function and the xmit completion handler, but since the NETIF_F_LLTX flag > is not set, the xmit function is also called with the xmit_lock held. > > On the other hand the xmit

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-07 Thread Francois Romieu
Lino Sanfilippo : > The driver uses a private lock for synchronization between the xmit > function and the xmit completion handler, but since the NETIF_F_LLTX flag > is not set, the xmit function is also called with the xmit_lock held. > > On the other hand the xmit completion handler first

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

2016-11-24 Thread Francois Romieu
Mark Lord : [...] > >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). > > The driver itself NEVER writes

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

2016-11-24 Thread Francois Romieu
Mark Lord : [...] > >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). > > The driver itself NEVER writes anything to that

Re: [PATCH net 2/2] r8152: rx descriptor check

2016-11-14 Thread Francois Romieu
Hayes Wang <hayesw...@realtek.com> : > Francois Romieu [mailto:rom...@fr.zoreil.com] > > Sent: Friday, November 11, 2016 8:13 PM > [...] > > Invalid packet size corrupted receive descriptors in Realtek's device > > reminds of CVE-2009-4537. > > Do you mea

Re: [PATCH net 2/2] r8152: rx descriptor check

2016-11-14 Thread Francois Romieu
Hayes Wang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > > Sent: Friday, November 11, 2016 8:13 PM > [...] > > Invalid packet size corrupted receive descriptors in Realtek's device > > reminds of CVE-2009-4537. > > Do you mean that the driver would get a

Re: [PATCH net 2/2] r8152: rx descriptor check

2016-11-11 Thread Francois Romieu
Hayes Wang : > For some platforms, the data in memory is not the same with the one > from the device. That is, the data of memory is unbelievable. The > check is used to find out this situation. Invalid packet size corrupted receive descriptors in Realtek's device reminds

Re: [PATCH net 2/2] r8152: rx descriptor check

2016-11-11 Thread Francois Romieu
Hayes Wang : > For some platforms, the data in memory is not the same with the one > from the device. That is, the data of memory is unbelievable. The > check is used to find out this situation. Invalid packet size corrupted receive descriptors in Realtek's device reminds of CVE-2009-4537. Is

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

2016-10-14 Thread Francois Romieu
CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35 > Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016 > > on systems without memory that is 32-bit addressable by PCI devices. > > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> Acked-by: Fra

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

2016-10-14 Thread Francois Romieu
d-udevd Not tainted 4.8.0+ #35 > Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016 > > on systems without memory that is 32-bit addressable by PCI devices. > > Signed-off-by: Ard Biesheuvel Acked-by: Francois Romieu Unless someone plans to plug an acenic, a 8382

Re: [PATCH] via-velocity: remove null pointer check on array tdinfo->skb_dma

2016-09-08 Thread Francois Romieu
Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: Francois Romieu <rom...@fr.zoreil.com> -- Ueimor

Re: [PATCH] via-velocity: remove null pointer check on array tdinfo->skb_dma

2016-09-08 Thread Francois Romieu
Colin King : > From: Colin Ian King > > tdinfo->skb_dma is a 7 element array of dma_addr_t hence cannot be > null, so the pull pointer check on tdinfo->skb_dma is redundant. > Remove it. > > Signed-off-by: Colin Ian King Acked-by: Francois Romieu -- Ueimor

Re: [PATCH] Networking: Core: netpoll: Fixed a missing spin_unlock

2016-07-31 Thread Francois Romieu
Salil Kapur : > I was looking at v3.12. Can we submit patches for stable versions? It has already been fixed in 3.12.8 as 56399d8b44beae5b80e1eda0350ab6af72baf4d0 ("netpoll: Fix missing TXQ unlock and and OOPS.") by davem. 3.12.8 dates back to 2014/01. The current 3.12.x

Re: [PATCH] Networking: Core: netpoll: Fixed a missing spin_unlock

2016-07-31 Thread Francois Romieu
Salil Kapur : > I was looking at v3.12. Can we submit patches for stable versions? It has already been fixed in 3.12.8 as 56399d8b44beae5b80e1eda0350ab6af72baf4d0 ("netpoll: Fix missing TXQ unlock and and OOPS.") by davem. 3.12.8 dates back to 2014/01. The current 3.12.x version is 3.12.62. --

Re: [PATCH] Networking: Core: netpoll: Fixed a missing spin_unlock

2016-07-30 Thread Francois Romieu
Salil Kapur : [...] > diff --git a/net/core/netpoll.c b/net/core/netpoll.c > index fc75c9e..9124f76 100644 > --- a/net/core/netpoll.c > +++ b/net/core/netpoll.c > @@ -386,8 +386,10 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct > sk_buff *skb, >

Re: [PATCH] Networking: Core: netpoll: Fixed a missing spin_unlock

2016-07-30 Thread Francois Romieu
Salil Kapur : [...] > diff --git a/net/core/netpoll.c b/net/core/netpoll.c > index fc75c9e..9124f76 100644 > --- a/net/core/netpoll.c > +++ b/net/core/netpoll.c > @@ -386,8 +386,10 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct > sk_buff *skb, >

Re: [Intel-wired-lan] [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

2016-07-28 Thread Francois Romieu
Eric Dumazet : [...] > I would prefer having a definitive advice from Thomas Gleixner and/or > others if disable_irq() is forbidden from IRQ path. > > As I said, about all netpoll() methods in net drivers use disable_irq() > so a lot of patches would be needed. s/about

Re: [Intel-wired-lan] [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

2016-07-28 Thread Francois Romieu
Eric Dumazet : [...] > I would prefer having a definitive advice from Thomas Gleixner and/or > others if disable_irq() is forbidden from IRQ path. > > As I said, about all netpoll() methods in net drivers use disable_irq() > so a lot of patches would be needed. s/about all/many/ There has been

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

2016-07-28 Thread Francois Romieu
Hau : [...] > > Either the driver resumes the device so that it can perform requested > > operation or it signals .set_wol failure when the device is suspended. > > > > If the driver does something else, "spam removal" translates to "silent > > failure". > > Because

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

2016-07-28 Thread Francois Romieu
Hau : [...] > > Either the driver resumes the device so that it can perform requested > > operation or it signals .set_wol failure when the device is suspended. > > > > If the driver does something else, "spam removal" translates to "silent > > failure". > > Because "tp->saved_wolopts" will be

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

2016-07-27 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 0e62d74..f07604f 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -1749,13 +1749,21 @@ static u32

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

2016-07-27 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 0e62d74..f07604f 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -1749,13 +1749,21 @@ static u32 __rtl8169_get_wol(struct

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

2016-07-27 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 0e62d74..f07604f 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > @@ -1852,12 +1863,17 @@ static int

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

2016-07-27 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 0e62d74..f07604f 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > @@ -1852,12 +1863,17 @@ static int

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-20 Thread Francois Romieu
Netanel Belgazal : [...] > > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h > > b/drivers/net/ethernet/amazon/ena/ena_com.h > > new file mode 100644 > > index 000..e49ba43 > > --- /dev/null > > [...] > > +static inline void ena_com_update_intr_reg(struct

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-20 Thread Francois Romieu
Netanel Belgazal : [...] > > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h > > b/drivers/net/ethernet/amazon/ena/ena_com.h > > new file mode 100644 > > index 000..e49ba43 > > --- /dev/null > > [...] > > +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg > >

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-17 Thread Francois Romieu
Netanel Belgazal : [...] More stuff below. > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c > b/drivers/net/ethernet/amazon/ena/ena_com.c > new file mode 100644 > index 000..357e10f > --- /dev/null > +++ b/drivers/net/ethernet/amazon/ena/ena_com.c [...] >

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-17 Thread Francois Romieu
Netanel Belgazal : [...] More stuff below. > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c > b/drivers/net/ethernet/amazon/ena/ena_com.c > new file mode 100644 > index 000..357e10f > --- /dev/null > +++ b/drivers/net/ethernet/amazon/ena/ena_com.c [...] > +static int

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-16 Thread Francois Romieu
Netanel Belgazal : [...] Very limited review below. > diff --git a/Documentation/networking/ena.txt > b/Documentation/networking/ena.txt > new file mode 100644 > index 000..528544f > --- /dev/null > +++ b/Documentation/networking/ena.txt > @@ -0,0 +1,330 @@ >

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-16 Thread Francois Romieu
Netanel Belgazal : [...] Very limited review below. > diff --git a/Documentation/networking/ena.txt > b/Documentation/networking/ena.txt > new file mode 100644 > index 000..528544f > --- /dev/null > +++ b/Documentation/networking/ena.txt > @@ -0,0 +1,330 @@ > +Linux kernel driver for

Re: r8169: Unconditionally disabling ASPM

2016-05-15 Thread Francois Romieu
Paul Menzel : [...] > As over five years have passed now, do you think that is still needed? > I wonder why no module parameter was added back then, where users could > enable ASPM if it works on their systems? Because there is no such > situation and it always

Re: r8169: Unconditionally disabling ASPM

2016-05-15 Thread Francois Romieu
Paul Menzel : [...] > As over five years have passed now, do you think that is still needed? > I wonder why no module parameter was added back then, where users could > enable ASPM if it works on their systems? Because there is no such > situation and it always fails? It was enabled again

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

2016-04-25 Thread Francois Romieu
Florian Westphal <f...@strlen.de> : > Francois Romieu <rom...@fr.zoreil.com> wrote: [...] > > Play it safe and keep the implicit local_irq_{save / restore} call ? > > > > It may not be needed but it will help avoiding any unexpected regression > > report p

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

2016-04-25 Thread Francois Romieu
Florian Westphal : > Francois Romieu wrote: [...] > > Play it safe and keep the implicit local_irq_{save / restore} call ? > > > > It may not be needed but it will help avoiding any unexpected regression > > report pointing at the NETDEV_TX_LOCKED removal c

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

2016-04-25 Thread Francois Romieu
Florian Westphal : [...] > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > index d0084d4..a3200ea 100644 > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > +++

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

2016-04-25 Thread Francois Romieu
Florian Westphal : [...] > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > index d0084d4..a3200ea 100644 > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c [...] > @@

Re: [PATCH] net: sxgbe: fix error paths in sxgbe_platform_probe()

2016-03-27 Thread Francois Romieu
value of i), we'll enter an essentially infinite loop of > out-of-bounds accesses. > > Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> (ok, i is signed) Reviewed-by: Francois Romieu <rom...@fr.zoreil.com> Someone messed with my review on 2014/03/25 and got it wrong

Re: [PATCH] net: sxgbe: fix error paths in sxgbe_platform_probe()

2016-03-27 Thread Francois Romieu
ally infinite loop of > out-of-bounds accesses. > > Signed-off-by: Rasmus Villemoes (ok, i is signed) Reviewed-by: Francois Romieu Someone messed with my review on 2014/03/25 and got it wrong. :o/ Two years after the initial submission, there is zero change regarding use of s

Re: SYN flooding on port 80 + DMAR:[DMA Write] faults

2016-03-12 Thread Francois Romieu
Toralf Förster : > Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack. > I do wonder if the DMAR events points to an issue in the kernel ? Please send a compressed log including all 'fault addr' lines as well as the (module probe time) XID line

Re: SYN flooding on port 80 + DMAR:[DMA Write] faults

2016-03-12 Thread Francois Romieu
Toralf Förster : > Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack. > I do wonder if the DMAR events points to an issue in the kernel ? Please send a compressed log including all 'fault addr' lines as well as the (module probe time) XID line from the r8169 driver.

Re: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.

2016-03-09 Thread Francois Romieu
Hau : [...] > Unless pcie nic has bug, pcie nic does not need to reset phy to let phy link > on. > > There is a counter for phy speed down. If phy is in link down state, this > counter will start to count down. When it count to 0, phy will speed down. > Reset phy will reset

Re: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.

2016-03-09 Thread Francois Romieu
Hau : [...] > Unless pcie nic has bug, pcie nic does not need to reset phy to let phy link > on. > > There is a counter for phy speed down. If phy is in link down state, this > counter will start to count down. When it count to 0, phy will speed down. > Reset phy will reset this counter and

Re: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.

2016-03-08 Thread Francois Romieu
Chunhao Lin : > For pcie nic, after setting link speed and thers is no link driver does not > need > to do phy reset untill link up. > > For some pcie nics, to do this will also reset phy speed down counter and > prevent > phy from auto speed down. > > This patch fix the

Re: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.

2016-03-08 Thread Francois Romieu
Chunhao Lin : > For pcie nic, after setting link speed and thers is no link driver does not > need > to do phy reset untill link up. > > For some pcie nics, to do this will also reset phy speed down counter and > prevent > phy from auto speed down. > > This patch fix the issue reported in

Re: Softirq priority inversion from "softirq: reduce latencies"

2016-02-28 Thread Francois Romieu
Mike Galbraith : [...] > Hrm, relatively new + tasklet woes rings a bell. Ah, that.. > > > What's worse is that at the point where this code was written it was > already well known that tasklets are a steaming pile of crap and > should die. > > > Source thereof

Re: Softirq priority inversion from "softirq: reduce latencies"

2016-02-28 Thread Francois Romieu
Mike Galbraith : [...] > Hrm, relatively new + tasklet woes rings a bell. Ah, that.. > > > What's worse is that at the point where this code was written it was > already well known that tasklets are a steaming pile of crap and > should die. > > > Source thereof

Re: [PATCH net 1/3] r8169:fix nic sometimes doesn't work after changing the mac address.

2016-02-26 Thread Francois Romieu
Chunhao Lin : > When there is no AC power, NIC doesn't work after changing mac address. > Please refer to following link. > http://www.spinics.net/lists/netdev/msg356572.html > > This issue is caused by runtime power management. When there is no AC power, > if we > put NIC

Re: [PATCH net 1/3] r8169:fix nic sometimes doesn't work after changing the mac address.

2016-02-26 Thread Francois Romieu
Chunhao Lin : > When there is no AC power, NIC doesn't work after changing mac address. > Please refer to following link. > http://www.spinics.net/lists/netdev/msg356572.html > > This issue is caused by runtime power management. When there is no AC power, > if we > put NIC down (ifconfig down),

Re: [PATCH net v4] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

2016-02-24 Thread Francois Romieu
Chunhao Lin : [...] Fine with me. Is there any chance for the set of chipset dependent registers that are safe to be read when in D3 state to be documented ? -- Ueimor

Re: [PATCH net v4] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

2016-02-24 Thread Francois Romieu
Chunhao Lin : [...] Fine with me. Is there any chance for the set of chipset dependent registers that are safe to be read when in D3 state to be documented ? -- Ueimor

Re: [PATCH net v3] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

2016-02-23 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 537974c..404be51 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > @@ -7853,6 +7859,11 @@ static int

Re: [PATCH net v3] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

2016-02-23 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 537974c..404be51 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > @@ -7853,6 +7859,11 @@ static int

Re: [PATCH net v2] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

2016-02-22 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 537974c..a645f8d 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -7730,10 +7730,13 @@

Re: [PATCH net v2] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

2016-02-22 Thread Francois Romieu
Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 537974c..a645f8d 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -7730,10 +7730,13 @@ rtl8169_get_stats64(struct

  1   2   3   4   5   6   7   8   9   10   >