<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/xen-netback/interface.c, branch linux-5.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.14.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.14.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-06-07T13:13:15Z</updated>
<entry>
<title>xen-netback: take a reference to the RX task thread</title>
<updated>2021-06-07T13:13:15Z</updated>
<author>
<name>Roger Pau Monne</name>
</author>
<published>2021-06-07T13:13:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=107866a8eb0b664675a260f1ba0655010fac1e08'/>
<id>urn:sha1:107866a8eb0b664675a260f1ba0655010fac1e08</id>
<content type='text'>
Do this in order to prevent the task from being freed if the thread
returns (which can be triggered by the frontend) before the call to
kthread_stop done as part of the backend tear down. Not taking the
reference will lead to a use-after-free in that scenario. Such
reference was taken before but dropped as part of the rework done in
2ac061ce97f4.

Reintroduce the reference taking and add a comment this time
explaining why it's needed.

This is XSA-374 / CVE-2021-28691.

Fixes: 2ac061ce97f4 ('xen/netback: cleanup init and deinit code')
Signed-off-by: Roger Pau Monné &lt;roger.pau@citrix.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
</entry>
<entry>
<title>xen/events: link interdomain events to associated xenbus device</title>
<updated>2021-02-11T22:47:00Z</updated>
<author>
<name>Juergen Gross</name>
</author>
<published>2021-02-11T10:16:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f2fa0e5e9f31dd90741f1151043ca1eaa4086690'/>
<id>urn:sha1:f2fa0e5e9f31dd90741f1151043ca1eaa4086690</id>
<content type='text'>
In order to support the possibility of per-device event channel
settings (e.g. lateeoi spurious event thresholds) add a xenbus device
pointer to struct irq_info() and modify the related event channel
binding interfaces to take the pointer to the xenbus device as a
parameter instead of the domain id of the other side.

While at it remove the stale prototype of bind_evtchn_to_irq_lateeoi().

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Reviewed-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Reviewed-by: Paul Durrant &lt;paul@xen.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>xen/netback: fix spurious event detection for common event case</title>
<updated>2021-02-11T22:47:00Z</updated>
<author>
<name>Juergen Gross</name>
</author>
<published>2021-02-11T10:16:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a3daf3d39132b405781be8d9ede0c449b244b64e'/>
<id>urn:sha1:a3daf3d39132b405781be8d9ede0c449b244b64e</id>
<content type='text'>
In case of a common event for rx and tx queue the event should be
regarded to be spurious if no rx and no tx requests are pending.

Unfortunately the condition for testing that is wrong causing to
decide a event being spurious if no rx OR no tx requests are
pending.

Fix that plus using local variables for rx/tx pending indicators in
order to split function calls and if condition.

Fixes: 23025393dbeb3b ("xen/netback: use lateeoi irq binding")
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Reviewed-by: Paul Durrant &lt;paul@xen.org&gt;
Reviewed-by: Wei Liu &lt;wl@xen.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: group skb_shinfo zerocopy related bits together.</title>
<updated>2021-01-08T00:08:37Z</updated>
<author>
<name>Jonathan Lemon</name>
</author>
<published>2021-01-06T22:18:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=06b4feb37e64e543714c971a4162a75e2e4024d4'/>
<id>urn:sha1:06b4feb37e64e543714c971a4162a75e2e4024d4</id>
<content type='text'>
In preparation for expanded zerocopy (TX and RX), move
the zerocopy related bits out of tx_flags into their own
flag word.

Signed-off-by: Jonathan Lemon &lt;jonathan.lemon@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>xen/netback: use lateeoi irq binding</title>
<updated>2020-10-20T08:22:03Z</updated>
<author>
<name>Juergen Gross</name>
</author>
<published>2020-09-07T13:47:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=23025393dbeb3b8b3b60ebfa724cdae384992e27'/>
<id>urn:sha1:23025393dbeb3b8b3b60ebfa724cdae384992e27</id>
<content type='text'>
In order to reduce the chance for the system becoming unresponsive due
to event storms triggered by a misbehaving netfront use the lateeoi
irq binding for netback and unmask the event channel only just before
going to sleep waiting for new events.

Make sure not to issue an EOI when none is pending by introducing an
eoi_pending element to struct xenvif_queue.

When no request has been consumed set the spurious flag when sending
the EOI for an interrupt.

This is part of XSA-332.

Cc: stable@vger.kernel.org
Reported-by: Julien Grall &lt;julien@xen.org&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Reviewed-by: Wei Liu &lt;wl@xen.org&gt;
</content>
</entry>
<entry>
<title>xen networking: add XDP offset adjustment to xen-netback</title>
<updated>2020-07-01T22:25:14Z</updated>
<author>
<name>Denis Kirjanov</name>
</author>
<published>2020-06-29T13:13:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1c9535c701fb287c2f292bc7fb39a07c5f8a25fd'/>
<id>urn:sha1:1c9535c701fb287c2f292bc7fb39a07c5f8a25fd</id>
<content type='text'>
the patch basically adds the offset adjustment and netfront
state reading to make XDP work on netfront side.

Reviewed-by: Paul Durrant &lt;paul@xen.org&gt;
Signed-off-by: Denis Kirjanov &lt;kda@linux-powerpc.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>xen-netback: support dynamic unbind/bind</title>
<updated>2019-12-26T23:16:26Z</updated>
<author>
<name>Paul Durrant</name>
</author>
<published>2019-12-23T09:59:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9476654bd5e8ad42abe8ee9f9e90069ff8e60c17'/>
<id>urn:sha1:9476654bd5e8ad42abe8ee9f9e90069ff8e60c17</id>
<content type='text'>
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 to be unbound and re-bound from and to (respectively) a
running guest.

Dynamic unbind/bind is a highly useful feature for a backend module as it
allows it to be unloaded and re-loaded (i.e. updated) without requiring
domUs to be halted.

This has been tested by running iperf as a server in the test VM and
then running a client against it in a continuous loop, whilst also
running:

while true;
  do echo vif-$DOMID-$VIF &gt;unbind;
  echo down;
  rmmod xen-netback;
  echo unloaded;
  modprobe xen-netback;
  cd $(pwd);
  brctl addif xenbr0 vif$DOMID.$VIF;
  ip link set vif$DOMID.$VIF up;
  echo up;
  sleep 5;
  done

in dom0 from /sys/bus/xen-backend/drivers/vif to continuously unbind,
unload, re-load, re-bind and re-plumb the backend.

Clearly a performance drop was seen but no TCP connection resets were
observed during this test and moreover a parallel SSH connection into the
guest remained perfectly usable throughout.

Signed-off-by: Paul Durrant &lt;pdurrant@amazon.com&gt;
Reviewed-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>xen-netback: avoid race that can lead to NULL pointer dereference</title>
<updated>2019-12-15T19:40:15Z</updated>
<author>
<name>Paul Durrant</name>
</author>
<published>2019-12-13T13:20:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fd42bfd1bb31f9a521be6b4f1bd89b85abc08d20'/>
<id>urn:sha1:fd42bfd1bb31f9a521be6b4f1bd89b85abc08d20</id>
<content type='text'>
In function xenvif_disconnect_queue(), the value of queue-&gt;rx_irq is
zeroed *before* queue-&gt;task is stopped. Unfortunately that task may call
notify_remote_via_irq(queue-&gt;rx_irq) and calling that function with a
zero value results in a NULL pointer dereference in evtchn_from_irq().

This patch simply re-orders things, stopping all tasks before zero-ing the
irq values, thereby avoiding the possibility of the race.

Fixes: 2ac061ce97f4 ("xen/netback: cleanup init and deinit code")
Signed-off-by: Paul Durrant &lt;pdurrant@amazon.com&gt;
Acked-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
</content>
</entry>
<entry>
<title>xen/netback: cleanup init and deinit code</title>
<updated>2019-10-22T16:52:04Z</updated>
<author>
<name>Juergen Gross</name>
</author>
<published>2019-10-21T05:30:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2ac061ce97f413bfbbdd768f7d2e0fda2e8170df'/>
<id>urn:sha1:2ac061ce97f413bfbbdd768f7d2e0fda2e8170df</id>
<content type='text'>
Do some cleanup of the netback init and deinit code:

- add an omnipotent queue deinit function usable from
  xenvif_disconnect_data() and the error path of xenvif_connect_data()
- only install the irq handlers after initializing all relevant items
  (especially the kthreads related to the queue)
- there is no need to use get_task_struct() after creating a kthread
  and using put_task_struct() again after having stopped it.
- use kthread_run() instead of kthread_create() to spare the call of
  wake_up_process().

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Paul Durrant &lt;pdurrant@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
</content>
</entry>
<entry>
<title>xen/netback: fix error path of xenvif_connect_data()</title>
<updated>2019-10-19T18:43:29Z</updated>
<author>
<name>Juergen Gross</name>
</author>
<published>2019-10-18T07:45:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3d5c1a037d37392a6859afbde49be5ba6a70a6b3'/>
<id>urn:sha1:3d5c1a037d37392a6859afbde49be5ba6a70a6b3</id>
<content type='text'>
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 is shut down")
Cc: &lt;stable@vger.kernel.org&gt; # 3.12
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Paul Durrant &lt;paul@xen.org&gt;
Reviewed-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
