Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

From: Eduardo Otubo Date: Thu, 23 Nov 2017 15:18:35 +0100 > v2: > * Replace busy wait with wait_event()/wake_up_all() > * Cannot garantee that at the time xennet_remove is called, the >xen_netback state will not be XenbusStateClosed, so added a >condition for that >

Re: [Xen-devel] [PATCH] xen-netback: Fix logging message with spurious period after newline

From: Joe Perches Date: Tue, 5 Dec 2017 22:40:25 -0800 > Using a period after a newline causes bad output. > > Signed-off-by: Joe Perches Applied. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH] xen-netfront: enable device after manual module load

From: Eduardo Otubo Date: Fri, 5 Jan 2018 09:42:16 +0100 > When loading the module after unloading it, the network interface would > not be enabled and thus wouldn't have a backend counterpart and unable > to be used by the guest. > > The guest would face errors like: > >

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

From: Ross Lagerwall Date: Thu, 11 Jan 2018 09:36:38 + > When a netfront device is set up it registers a netdev fairly early on, > before it has set up the queues and is actually usable. A userspace tool > like NetworkManager will immediately try to open it and

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

From: Ross Lagerwall Date: Thu, 11 Jan 2018 15:49:07 + > I've now added CC'd netdev on the other two. That doesn't work. If you don't post the originals explicitly to netdev then it won't get properly queued in patchwork.

Re: [Xen-devel] [PATCH net-next v2] xen-netback: make copy batch size configurable

From: Joao Martins Date: Thu, 21 Dec 2017 17:24:28 + > Commit eb1723a29b9a ("xen-netback: refactor guest rx") refactored Rx > handling and as a result decreased max grant copy ops from 4352 to 64. > Before this commit it would drain the rx_queue (while there are >

Re: [Xen-devel] [PATCH 0/2] xen-netfront: Fix issues with commit f599c64fdf7d

From: Ross Lagerwall Date: Thu, 21 Jun 2018 14:00:19 +0100 > Fix a couple of issues with commit f599c64fdf7d ("xen-netfront: Fix race > between device setup and open"). Series applied and queued up for -stable. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH net-next] xen-netback: use true and false for boolean values

From: "Gustavo A. R. Silva" Date: Wed, 1 Aug 2018 19:31:01 -0500 > Return statements in functions returning bool should use true or false > instead of an integer value. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

From: Xiao Liang Date: Fri, 27 Jul 2018 17:56:08 +0800 > When loading module manually, after call xenbus_switch_state to initializes > the state of the netfront device, the driver state did not change so fast > that may lead no dev created in latest kernel. This patch adds wait to make > sure

Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

From: Xiao Liang Date: Fri, 27 Jul 2018 17:56:08 +0800 > @@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_dev(struct > xenbus_device *dev) > netif_carrier_off(netdev); > > xenbus_switch_state(dev, XenbusStateInitialising); > + wait_event(module_load_q, > +

Re: [Xen-devel] [PATCH net-next v3] xen-netfront: fix warn message as irq device name has '/'

From: Xiao Liang Date: Tue, 14 Aug 2018 23:21:28 +0800 > There is a call trace generated after commit > 2d408c0d4574b01b9ed45e02516888bf925e11a9( > xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file > found > under /proc/irq/xx/. > > This patch only picks up device

Re: [Xen-devel] [PATCH] xen/netfront: don't cache skb_shinfo()

From: Juergen Gross Date: Thu, 9 Aug 2018 16:42:16 +0200 > skb_shinfo() can change when calling __pskb_pull_tail(): Don't cache > its return value. > > Cc: sta...@vger.kernel.org > Signed-off-by: Juergen Gross Applied. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2] xen-netfront: fix warn message as irq device name has '/'

From: Xiao Liang Date: Sat, 11 Aug 2018 23:21:37 +0800 > There is a call trace generated after commit > 2d408c0d4574b01b9ed45e02516888bf925e11a9( > xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file > found > under /proc/irq/xx/. > > This patch only picks up device

Re: [Xen-devel] [PATCH net-next] xen-netfront: fix queue name setting

From: Vitaly Kuznetsov Date: Fri, 20 Jul 2018 18:33:59 +0200 > Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and > open") changed the initialization order: xennet_create_queues() now > happens before we do register_netdev() so using netdev->name in > xennet_init_queue() is

Re: [Xen-devel] [PATCH] xen/netfront: fix waiting for xenbus state change

From: Juergen Gross Date: Fri, 7 Sep 2018 14:21:30 +0200 > Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load > module manually") added a new wait queue to wait on for a state change > when the module is loaded manually. Unfortunately there is no wakeup > anywhere to stop

Re: [Xen-devel] [PATCH] net: xenbus: remove redundant condition check before debugfs_remove_recursive

From: zhong jiang Date: Sat, 8 Sep 2018 21:35:06 +0800 > debugfs_remove_recursive has taken the IS_ERR_OR_NULL into account. Just > remove the unnecessary condition check. > > Signed-off-by: zhong jiang Applied to net-next. ___ Xen-devel mailing

Re: [Xen-devel] [PATCH] xen-netback: remove unecessary condition check before debugfs_remove_recursive

From: zhong jiang Date: Sat, 8 Sep 2018 21:53:42 +0800 > debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just > remove the condition check before debugfs_remove_recursive. > > Signed-off-by: zhong jiang Applied to net-next. ___

Re: [Xen-devel] [PATCH 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

From: Dongli Zhang Date: Wed, 28 Mar 2018 07:42:16 +0800 > The "BUG_ON(!frag_iter)" in function xenvif_rx_next_chunk() is triggered if > the received sk_buff is malformed, that is, when the sk_buff has pattern > (skb->data_len && !skb_shinfo(skb)->nr_frags). Below is a

Re: [Xen-devel] [PATCH 4/4] drivers/net: Use octal not symbolic permissions

From: Joe Perches Date: Fri, 23 Mar 2018 15:54:39 -0700 > Prefer the direct use of octal for permissions. > > Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace > and some typing. > > Miscellanea: > > o Whitespace neatening around these conversions. > >

Re: [Xen-devel] [PATCH][next] xen-netback: make function xenvif_rx_skb static

From: Colin King Date: Fri, 23 Feb 2018 17:16:57 + > From: Colin Ian King > > The function xenvif_rx_skb is local to the source and does not need > to be in global scope, so make it static. > > Cleans up sparse warning: >

Re: [Xen-devel] [PATCH] xen/netfront: remove unnecessary wmb

From: Jacob Wen Date: Fri, 9 Nov 2018 14:53:59 +0800 > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY is already able to make sure backend sees > requests before req_prod is updated. > > Signed-off-by: Jacob Wen Applied to net-next. ___ Xen-devel mailing

Re: [Xen-devel] Ping: [PATCH 0/3] xen-netback: hash mapping hanling adjustments

From: "Jan Beulich" Date: Mon, 24 Sep 2018 01:43:50 -0600 On 11.09.18 at 12:16, wrote: >> On Tue, Sep 11, 2018 at 02:12:07AM -0600, Jan Beulich wrote: >>> >>> On 28.08.18 at 16:54, wrote: >>> > First and foremost the fix for XSA-270. On top of that further changes >>> > which looked

Re: [Xen-devel] [PATCH net-next] net: xen-netback: fix return type of ndo_start_xmit function

From: YueHaibing Date: Wed, 26 Sep 2018 17:18:14 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to

Re: [Xen-devel] [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function

From: YueHaibing Date: Thu, 20 Sep 2018 20:32:44 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to

Re: [Xen-devel] [PATCH net 0/3 RESEND] xen-netback: hash mapping handling adjustments

From: "Jan Beulich" Date: Tue, 25 Sep 2018 02:11:33 -0600 > First and foremost the fix for XSA-270. On top of that further changes > which looked desirable to me while investigating that XSA. > > 1: fix input validation in xenvif_set_hash_mapping() > 2: validate queue numbers in

Re: [Xen-devel] [PATCH 15/21] sparc: add checks for the return value of memblock_alloc*()

From: Mike Rapoport Date: Wed, 16 Jan 2019 15:44:15 +0200 > Add panic() calls if memblock_alloc*() returns NULL. > > Most of the changes are simply addition of > > if(!ptr) > panic(); > > statements after the calls to memblock_alloc*() variants. > > Exceptions are

Re: [Xen-devel] [PATCH] net: xenbus: convert to DEFINE_SHOW_ATTRIBUTE

From: Yangtao Li Date: Mon, 10 Dec 2018 10:53:29 -0500 > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li Applied. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

From: Linus Torvalds Date: Wed, 28 Nov 2018 10:00:06 -0800 > Not all memory is accessible even to the kernel. If you have memory > that shows up in the last page of phys_addr_t, you just mark it > reserved at boot-time. It's not the physical memory at the end that needs to be reserved. It's

Re: [Xen-devel] [PATCH] xen/netfront: don't bug in case of too many frags

From: Juergen Gross Date: Tue, 11 Sep 2018 09:04:48 +0200 > Commit 57f230ab04d291 ("xen/netfront: raise max number of slots in > xennet_get_responses()") raised the max number of allowed slots by one. > This seems to be problematic in some configurations with netback using > a larger

Re: [Xen-devel] [PATCH] xen/netfront: tolerate frags with no data

From: Juergen Gross Date: Tue, 18 Dec 2018 16:06:19 +0100 > At least old Xen net backends seem to send frags with no real data > sometimes. In case such a fragment happens to occur with the frag limit > already reached the frontend will BUG currently even if this situation > is easily

Re: [Xen-devel] [PATCH v2] xen-netback: fix occasional leak of grant ref mappings under memory pressure

From: Igor Druzhinin Date: Thu, 28 Feb 2019 12:48:03 + > Zero-copy callback flag is not yet set on frag list skb at the moment > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in > leaking grant ref mappings since xenvif_zerocopy_callback() is never > called for these

Re: [Xen-devel] [PATCH] xen-netback: don't populate the hash cache on XenBus disconnect

From: Igor Druzhinin Date: Thu, 28 Feb 2019 14:11:26 + > Occasionally, during the disconnection procedure on XenBus which > includes hash cache deinitialization there might be some packets > still in-flight on other processors. Handling of these packets includes > hashing and hash cache

Re: [Xen-devel] [PATCH net-next] xen-netback: mark expected switch fall-through

From: "Gustavo A. R. Silva" Date: Fri, 8 Feb 2019 13:58:38 -0600 > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > This patch is part of the ongoing efforts to enabling >

Re: [Xen-devel] [PATCH 1/1] xen-netback: add reference from xenvif to backend_info to facilitate coredump analysis

From: Dongli Zhang Date: Fri, 12 Apr 2019 14:53:24 +0800 > During coredump analysis, it is not easy to obtain the address of > backend_info in xen-netback. > > So far there are two ways to obtain backend_info: > > 1. Do what xenbus_device_find() does for vmcore to find the xenbus_device > and

Re: [Xen-devel] [PATCH net-next] xen-netfront: mark expected switch fall-through

From: "Gustavo A. R. Silva" Date: Mon, 15 Apr 2019 16:11:41 -0500 > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > This patch fixes the following warning: > > drivers/net/xen-netfront.c: In function ‘netback_changed’: >

Re: [Xen-devel] [PATCH] xen-netback: remove redundant assignment to err

From: Colin King Date: Thu, 30 May 2019 20:04:38 +0100 > From: Colin Ian King > > The variable err is assigned with the value -ENOMEM that is never > read and it is re-assigned a new value later on. The assignment is > redundant and can be removed. > > Addresses-Coverity: ("Unused value") >

Re: [Xen-devel] [PATCH] xen-netback: no need to check return value of debugfs_create functions

From: Greg Kroah-Hartman Date: Sat, 10 Aug 2019 12:31:08 +0200 > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Wei Liu > Cc: Paul Durrant > Cc:

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not assume sk_buff_head list is empty in error handling

From: Dongli Zhang Date: Mon, 16 Sep 2019 11:46:59 +0800 > When skb_shinfo(skb) is not able to cache extra fragment (that is, > skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes > the sk_buff_head list is already empty. As a result, cons is increased only > by 1 and

Re: [Xen-devel] [PATCH net-next] MAINTAINERS: xen-netback: update my email address

From: Paul Durrant Date: Fri, 13 Sep 2019 13:47:27 +0100 > My Citrix email address will expire shortly. > > Signed-off-by: Paul Durrant Applied. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH] xen/netback: Reset nr_frags before freeing skb

From: Ross Lagerwall Date: Mon, 5 Aug 2019 16:34:34 +0100 > At this point nr_frags has been incremented but the frag does not yet > have a page assigned so freeing the skb results in a crash. Reset > nr_frags before freeing the skb to prevent this. > > Signed-off-by: Ross Lagerwall Applied

Re: [Xen-devel] [PATCH v2 1/1] xen-netfront: do not use ~0U as error return value for xennet_fill_frags()

From: Dongli Zhang Date: Tue, 1 Oct 2019 21:56:41 +0800 > xennet_fill_frags() uses ~0U as return value when the sk_buff is not able > to cache extra fragments. This is incorrect because the return type of > xennet_fill_frags() is RING_IDX and 0x is an expected value for > ring buffer

Re: [Xen-devel] [PATCH net] xen-netback: avoid race that can lead to NULL pointer dereference

From: Paul Durrant Date: Thu, 12 Dec 2019 12:37:23 + > Commit 2ac061ce97f4 ("xen/netback: cleanup init and deinit code") > introduced a problem. In function xenvif_disconnect_queue(), the value of > queue->rx_irq is zeroed *before* queue->task is stopped. Unfortunately that > task may call

Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old udev related code

From: Paul Durrant Date: Thu, 12 Dec 2019 13:54:06 + > In the past it used to be the case that the Xen toolstack relied upon > udev to execute backend hotplug scripts. However this has not been the > case for many releases now and removal of the associated code in > xen-netback shortens the

Re: [Xen-devel] [PATCH 0/2] xen/netback: bug fix and cleanup

From: Juergen Gross Date: Mon, 14 Oct 2019 11:09:08 +0200 > One bugfix (patch 1) I stumbled over while doing a cleanup (patch 2) > of the xen-netback init/deinit code. Please do not mix cleanups and genuine bug fixes. Submit the bug fix targetting the 'net' GIT tree, and once that eventually

Re: [Xen-devel] [PATCH] xen/netback: fix error path of xenvif_connect_data()

From: Juergen Gross Date: Fri, 18 Oct 2019 09:45:49 +0200 > xenvif_connect_data() calls module_put() in case of error. This is > wrong as there is no related module_get(). > > Remove the superfluous module_put(). > > Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif

Re: [Xen-devel] [PATCH net-next 3/3] xen-netback: remove 'hotplug-status' once it has served its purpose

From: Paul Durrant Date: Tue, 17 Dec 2019 13:32:18 + > Removing the 'hotplug-status' node in netback_remove() is wrong; the script > may not have completed. Only remove the node once the watch has fired and > has been unregistered. > > Signed-off-by: Paul Durrant Applied.

Re: [Xen-devel] [PATCH net-next 1/3] xen-netback: move netback_probe() and netback_remove() to the end...

From: Paul Durrant Date: Tue, 17 Dec 2019 13:32:16 + > ...of xenbus.c > > This is a cosmetic function re-ordering to reduce churn in a subsequent > patch. Some style fix-up was done to make checkpatch.pl happier. > > No functional change. > > Signed-off-by: Paul Durrant Applied.

Re: [Xen-devel] [PATCH net-next 2/3] xen-netback: switch state to InitWait at the end of netback_probe()...

From: Paul Durrant Date: Tue, 17 Dec 2019 13:32:17 + > ...as the comment above the function states. > > The switch to Initialising at the start of the function is somewhat bogus > as the toolstack will have set that initial state anyway. To behave > correctly, a backend should switch to

Re: [Xen-devel] [PATCH v3 4/4] xen/netback: fix grant copy across page boundary

From: Sergey Dyasli Date: Fri, 7 Feb 2020 14:26:52 + > From: Ross Lagerwall > > When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that > non-power-of-two allocations are not aligned to the next power of 2 of > the size. Therefore, handle grant copies that cross page

Re: [Xen-devel] [PATCH] net: xen-netback: hash.c: Use built-in RCU list checking

From: madhuparnabhowmi...@gmail.com Date: Wed, 15 Jan 2020 21:25:53 +0530 > From: Madhuparna Bhowmik > > list_for_each_entry_rcu has built-in RCU and lock checking. > Pass cond argument to list_for_each_entry_rcu. > > Signed-off-by: Madhuparna Bhowmik Applied to net-next.

Re: [Xen-devel] [PATCH net-next] xen-netback: support dynamic unbind/bind

From: Paul Durrant Date: Mon, 23 Dec 2019 09:59:23 + > By re-attaching RX, TX, and CTL rings during connect() rather than > assuming they are freshly allocated (i.e. assuming the counters are zero), > and avoiding forcing state to Closed in netback_remove() it is possible > for vif instances

Re: [PATCH][next] xen-netfront: remove redundant assignment to variable 'act'

From: Colin King Date: Thu, 2 Jul 2020 15:22:23 +0100 > From: Colin Ian King > > The variable act is being initialized with a value that is > never read and it is being updated later with a new value. The > initialization is redundant and can be removed. > > Addresses-Coverity: ("Unused

Re: [PATCH v2] xen-netfront: fix potential deadlock in xennet_remove()

ange, > to avoid getting stuck forever in wait_event(). > > Signed-off-by: Andrea Righi > --- > Changes in v2: > - remove all dev_dbg() calls (as suggested by David Miller) Applied, thank you.

Re: [PATCH] xen-netfront: fix potential deadlock in xennet_remove()

From: Andrea Righi Date: Wed, 22 Jul 2020 08:52:11 +0200 > +static int xennet_remove(struct xenbus_device *dev) > +{ > + struct netfront_info *info = dev_get_drvdata(>dev); > + > + dev_dbg(>dev, "%s\n", dev->nodename); These kinds of debugging messages provide zero context and are so