All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: Remi Pommarel <repk@triplefau.lt>
Cc: Antonio Quartulli <a@unstable.cc>,
	b.a.t.m.a.n@lists.open-mesh.org,
	Marek Lindner <mareklindner@neomailbox.ch>,
	Simon Wunderlich <sw@simonwunderlich.de>
Subject: Re: [PATCH v3 1/5] batman-adv: Do not send uninitialized TT changes
Date: Fri, 22 Nov 2024 09:16:37 +0100	[thread overview]
Message-ID: <2227327.C4sosBPzcN@ripper> (raw)
In-Reply-To: <Zz-W_3A9diBFXz79@pilgrim>

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Thursday, 21 November 2024 21:24:31 CET Remi Pommarel wrote:
> >
> > And then you can also move this before "tt_diff_entries_num = ..." and 
> > save the corresponding bat_priv->tt.local_changes for the spliced list to the 
> > inside the lock also in a local variable. And then operate on this variable 
> > for the other decisions. Of course, you must still clean the local list in 
> > case of an error. Which of course would slightly change the behavior in case 
> > of an allocation error in batadv_tt_prepare_tvlv_local_data (which would 
> > previously kept the list as it was).
> >
> > But if it would be done like this then we could also remove the READ_ONCE and 
> > not introduce the WRITE_ONCE - just because local_changes is only touched
> > inside a locked area (see changes_list_lock).
> >
> > Please double check these statements - this was just a simple brain dump.
> 
> Yes that would be a much more elegant way to handle it. Unfortunately,
> if I don't miss anything, the WRITE_ONCE/READ_ONCE would still be
> needed because batadv_tt_local_commit_changes_nolock() has to load
> tt.local_changes out of the lock to check if it needs to purge client
> and recompute CRCs.

Ah, you are right. I've missed this one.

Btw. just to make it clear: These changes wouldn't be for this patch/fix 
anyway. Just for a potential refactoring/cleanup patch for net-next.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2024-11-22  8:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-20 17:47 [PATCH v3 0/5] batman-adv: TT change events fixes and improvements Remi Pommarel
2024-11-20 17:47 ` [PATCH v3 1/5] batman-adv: Do not send uninitialized TT changes Remi Pommarel
2024-11-21 13:05   ` Antonio Quartulli
2024-11-21 13:56     ` Remi Pommarel
2024-11-21 15:07       ` Remi Pommarel
2024-11-21 18:02         ` Sven Eckelmann
2024-11-21 20:24           ` Remi Pommarel
2024-11-21 21:07             ` Antonio Quartulli
2024-11-22  8:16             ` Sven Eckelmann [this message]
2024-11-20 17:47 ` [PATCH v3 2/5] batman-adv: Remove uninitialized data in full table TT response Remi Pommarel
2024-11-21 13:14   ` Antonio Quartulli
2024-11-21 18:20     ` Sven Eckelmann
2024-11-21 20:55       ` Antonio Quartulli
2024-11-20 17:47 ` [PATCH v3 3/5] batman-adv: Do not let TT changes list grows indefinitely Remi Pommarel
2024-11-21 13:50   ` Antonio Quartulli
2024-11-21 14:18     ` Remi Pommarel
2024-11-20 17:47 ` [PATCH v3 4/5] batman-adv: Remove atomic usage for tt.local_changes Remi Pommarel
2024-11-21  9:04   ` Sven Eckelmann
2024-11-21  9:28     ` Remi Pommarel
2024-11-21  9:34       ` Sven Eckelmann
2024-11-20 17:47 ` [PATCH v3 5/5] batman-adv: Don't keep redundant TT change events Remi Pommarel
2024-11-21  8:43   ` Sven Eckelmann
2024-11-21  9:13     ` Remi Pommarel
2024-11-21  9:23       ` Sven Eckelmann
2024-11-21  9:30         ` Sven Eckelmann
2024-11-21  9:35           ` Remi Pommarel
2024-11-20 19:46 ` [PATCH v3 0/5] batman-adv: TT change events fixes and improvements Sven Eckelmann
2024-11-20 19:54   ` Remi Pommarel
2024-11-20 20:29     ` Antonio Quartulli
2024-11-20 21:04     ` Sven Eckelmann

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=2227327.C4sosBPzcN@ripper \
    --to=sven@narfation.org \
    --cc=a@unstable.cc \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=mareklindner@neomailbox.ch \
    --cc=repk@triplefau.lt \
    --cc=sw@simonwunderlich.de \
    /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.