On Fri, 18 Jul 2025 09:19:17 +0200 Jürgen Groß wrote:
> On 17.07.25 16:29, Jakub Kicinski wrote:
> > On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
> >> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
> >> storms")
On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
> storms")
Not entirely sure who you expect to apply this patch, but if networking
then I wouldn't classify this is a fix. The "regression" happened 4
years ago
On Tue, 10 Dec 2024 18:50:40 -0800 Andrew Morton wrote:
> > > Very unlikely, and any such conflict will be trivial.
> >
> > Agreed, mainly I don't understand why we'd make an exception
> > and take the patchset via a special tree.
>
> It saves work for everyone?
>
> The patches are super-sim
On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > I'll just grab everything and see if anyone complains ;)
> >
> > I may, if this leads to a conflict :(
>
> Very unlikely, and any such conflict will be trivial.
Agreed, mainly I don't understand why we'd make an exception
and take
On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > I have the same question as before: How do you expect these to land?
> > Do you now have a maintainer who will take all of them?
> > Or do you want individual maintainers to take the ones applicable to them?
>
> I'll just grab everythin
On Wed, 28 Aug 2024 21:52:12 +0900 Jeongjun Park wrote:
> > The loop runs with irq disabled, the RCU critical section extends over
> > it, uninterrupted.
>
> Basically, list_for_each_entry_rcu is specified to be used under the
> protection
> of rcu_read_lock(), but this is not the case with xen
On Tue, 27 Aug 2024 13:19:59 +0200 Paolo Abeni wrote:
> On 8/22/24 20:11, Jeongjun Park wrote:
> > During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
> > kfree_rcu does not exist inside the rcu read critical section, so if
>
> The above wording is confusing, do you mean "kfr
On Mon, 15 Jul 2024 22:24:39 +0200 Christophe JAILLET wrote:
> Most of the time, this kind of modification is useless because it is
> already done by the compiler, see [1].
GTK, thanks!
On Sat, 13 Jul 2024 15:18:42 +0200 Markus Elfring wrote:
> Single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function “seq_putc”.
>
> This issue was transformed by using the Coccinelle software.
I prefer to only merge trivial changes like this if maintain
On Mon, 29 Jan 2024 14:03:08 +0100 Jan Beulich wrote:
> Invoking the make_tx_response() / push_tx_responses() pair with no lock
> held would be acceptable only if all such invocations happened from the
> same context (NAPI instance or dealloc thread). Since this isn't the
> case, and since the inte
On Thu, 5 Oct 2023 18:39:51 +0300 David Kahurani wrote:
> > MAX_SKB_FRAGS can now be set via Kconfig, this allows us to create
> > larger super-packets. Can XEN_NETBK_LEGACY_SLOTS_MAX be made relative
> > to MAX_SKB_FRAGS, or does the number have to match between guest and
> > host?
>
> Historic
On Wed, 27 Sep 2023 11:29:18 +0300 David Kahurani wrote:
> If XEN_NETBK_LEGACY_SLOTS_MAX and MAX_SKB_FRAGS have a difference of
> more than 1, with MAX_SKB_FRAGS being the lesser value, it opens up a
> path for null-dereference. It was also noted that some distributions
> were modifying upstream be
On Wed, 24 May 2023 22:11:47 -0700 Jakub Kicinski wrote:
> On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote:
> > virt_to_page() takes a virtual address as argument but
> > the driver passes an unsigned long, which works because
> > the target platform(s) uses polymorphi
On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote:
> virt_to_page() takes a virtual address as argument but
> the driver passes an unsigned long, which works because
> the target platform(s) uses polymorphic macros to calculate
> the page.
>
> Since many architectures implement virt_to_pfn()
On Mon, 27 Feb 2023 09:29:30 +0100 Juergen Gross wrote:
> On 26.02.23 17:34, Tom Rix wrote:
> > building with gcc and W=1 reports
> > drivers/net/xen-netback/netback.c:886:21: error: variable
> >‘pending_idx’ set but not used [-Werror=unused-but-set-variable]
> >886 | u16 pe
On Tue, 29 Nov 2022 06:17:02 + Lin Liu wrote:
> A NAPI is setup for each network sring to poll data to kernel
> The sring with source host is destroyed before live migration and
> new sring with target host is setup after live migration.
> The NAPI for the old sring is not deleted until setup n
On Tue, 7 Jun 2022 07:28:38 +0200 Juergen Gross wrote:
> Remove some unused macros and functions, make local functions static.
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -486,7 +486,7 @@ static void xenvif_rx_skb(struct xenvif_queue *queue)
>#define RX_BATCH
On Mon, 30 May 2022 13:41:03 +0200 Juergen Gross wrote:
> Remove some unused macros and functions, make local functions static.
>
> Signed-off-by: Juergen Gross
# Form letter - net-next is closed
We have already sent the networking pull request for 5.19
and therefore net-next is closed for new
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Drop the special defines in a bunch of drivers where the
removal is relatively simple so grouping into one patch
does not impact reviewability.
Signed-off-by: Jakub Kicinski
---
CC
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Drop the special defines in a bunch of drivers where the
removal is relatively simple so grouping into one patch
does not impact reviewability.
Signed-off-by: Jakub Kicinski
---
CC
On Tue, 22 Feb 2022 01:18:16 +0100 Marek Marczykowski-Górecki wrote:
> This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
>
> The 'hotplug-status' node should not be removed as long as the vif
> device remains configured. Otherwise the xen-netback would wait for
> re-running the network
On Mon, 21 Feb 2022 07:27:32 +0100 Juergen Gross wrote:
> On 20.02.22 14:42, Marek Marczykowski-Górecki wrote:
> > xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
> > delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
> > ("net-sysfs: update the queue counts in the
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Signed-off-by: Jakub Kicinski
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Signed-off-by: Jakub Kicinski
On Thu, 4 Feb 2021 06:32:32 +0100 Jürgen Groß wrote:
> On 04.02.21 00:48, Jakub Kicinski wrote:
> > On Tue, 2 Feb 2021 08:09:38 +0100 Juergen Gross wrote:
> >> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> >> xenvif_rx_ring_slots
On Tue, 2 Feb 2021 08:09:38 +0100 Juergen Gross wrote:
> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> xenvif_rx_ring_slots_available() is no longer called only from the rx
> queue kernel thread, so it needs to access the rx queue with the
> associated queue held.
>
>
On Fri, 15 Jan 2021 13:38:48 + Lee Jones wrote:
> Okay, so what would you like me to do? Would you like me to re-submit
> the set based only on net-next
Yes, rebase your patches on net-next, recheck everything builds okay
and resubmit. You should always develop against the tree that will
merg
On Thu, 14 Jan 2021 08:33:49 + Lee Jones wrote:
> On Wed, 13 Jan 2021, Jakub Kicinski wrote:
>
> > On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> > > Resending
On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> Resending the stragglers again.
>
>
> This set is part of a larger effort attempting to clean-up W=1
>
> kern
On Thu, 26 Nov 2020 13:38:45 + Lee Jones wrote:
> Resending the stragglers.
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
This set doesn't apply to net-next, please rebase.
On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > This series aims to fix almost all remaining fall-through warnings in
> > >
On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallt
On Fri, 13 Dec 2019 13:20:40 +, Paul Durrant wrote:
> In function xenvif_disconnect_queue(), the value of queue->rx_irq is
> zeroed *before* queue->task is stopped. Unfortunately that task may call
> notify_remote_via_irq(queue->rx_irq) and calling that function with a
> zero value results in a
On Mon, 21 Oct 2019 07:30:52 +0200, Juergen Gross wrote:
> 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 al
34 matches
Mail list logo
