All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Tobias Böhm" <tobias@aibor.de>, xdp-newbies@vger.kernel.org
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Subject: Re: cpumap infinite loop
Date: Tue, 05 Mar 2024 18:08:06 +0100	[thread overview]
Message-ID: <871q8od2tl.fsf@toke.dk> (raw)
In-Reply-To: <xgct6vpbwh6c5zjljdc6ypa5hbmcw4bapebdh4eetxwjama3so@iq3xdtavnq4g>

Tobias Böhm <tobias@aibor.de> writes:

> Hello,
>
> I was playing around a bit with cpumaps and wondered what happens when
> the attached program just does another CPU redirect to itself.
>
> I ended up having an infinite loop. The working example can be found
> here: https://github.com/aibor/cpumap-loop
>
> Now, I wonder if there is a way to detect and break this loop. I took a
> look at the xdp_md->rx_queue_index values. When executed by a NIC event,
> the value is the NIC ID, so a fairly low number. After CPU redirection
> the values I saw were far above the range of NIC queue IDs. I couldn't
> figure out if it is just a random memory value or if this value still 
> has a (maybe different) meaning after CPU redirection. Maybe somehow
> related to the CPU queue?

It's random. The rxq data structure is not initialised on the stack, so
it's basically whatever was in that memory. Interestingly, there's a
TODO comment in there to fix this:

https://elixir.bootlin.com/linux/latest/source/kernel/bpf/cpumap.c#L195

Not sure what the intention was here. +Lorenzo, who wrote that code.
Returning the contents of a random uninitialised stack variable is
probably not a good idea, though, we should zero out the data structure.
I'll send a patch for that.

> If the field is set to a meaningful value I can make assumptions about
> it and would be able to detect previous CPU redirection, I guess.
>
> I'd appreciate any pointers and tips how I could detect such a loop. Or
> maybe there is a way to prevent it in the first place other than "just
> being careful"?

Well, you kinda have to go out of your way to construct a loop like
this. How are you envisioning this would happen accidentally? :)

-Toke


  reply	other threads:[~2024-03-05 17:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 23:04 cpumap infinite loop Tobias Böhm
2024-03-05 17:08 ` Toke Høiland-Jørgensen [this message]
2024-03-06  9:09   ` Tobias Böhm
2024-03-06 10:20     ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871q8od2tl.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=tobias@aibor.de \
    --cc=xdp-newbies@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.