batman-adv: atomic variable for vis-srv activation
PATCH 1/3 batman-adv: atomic variable for vis-srv activation
This fixes the bug discovered by Marek which did not allow turning on the vis-server before an interface has been added. This is now being done in a similar way as for (de)activating the aggregation mode with an atomic variable.
--- main.c | 2 ++ main.h | 1 + proc.c | 43 ++++++++++++++++++++++++------------------- send.c | 2 +- vis.c | 41 +++-------------------------------------- vis.h | 2 -- 6 files changed, 31 insertions(+), 60 deletions(-)
main.c +2 -0
@@ -44,6 +44,7 @@ DEFINE_SPINLOCK(forw_bcast_list_lock);atomic_t originator_interval;atomic_t vis_interval; +atomic_t vis_srv_enabled;atomic_t aggregation_enabled;int16_t num_hna;int16_t num_ifs;
@@ -84,6 +85,7 @@ int init_module(void)atomic_set (&originator_interval,1000 );atomic_set (&vis_interval,1000 );/* TODO: raise this later, this is only * for debugging now. */ +atomic_set (&vis_srv_enabled,0 );atomic_set (&aggregation_enabled,1 );/* the name should not be longer than 10 chars - see
main.h +1 -0
@@ -130,6 +130,7 @@ extern spinlock_t forw_bcast_list_lock;extern atomic_t originator_interval;extern atomic_t vis_interval; +extern atomic_t vis_srv_enabled;extern atomic_t aggregation_enabled;extern int16_t num_hna;extern int16_t num_ifs;
proc.c +24 -19
67 lines not on this page · raw message
send.c +1 -1
@@ -279,7 +279,7 @@ void schedule_own_packet(struct batman_if *batman_if)/* change sequence number to network order */ batman_packet->seqno =htons ((uint16_t )atomic_read (&batman_if->seqno)); -if (is_vis_server ()) +if (atomic_read (&vis_srv_enabled)) batman_packet->flags =VIS_SERVER ;else batman_packet->flags =0 ;
vis.c +3 -38
65 lines not on this page · raw message
vis.h +0 -2
@@ -48,8 +48,6 @@ struct recvlist_node {extern struct hashtable_t *vis_hash;extern spinlock_t vis_hash_lock; -void vis_set_mode (int mode); -int is_vis_server (void ); void proc_vis_read_entry(struct seq_file *seq, struct vis_info_entry *entry, struct hlist_head *if_list,
Signature · 1 line
1.6.5.7
Hi,
Quoted 4 lines
This fixes the bug discovered by Marek which did not allow turning on the vis-server before an interface has been added. This is now being done in a similar way as for (de)activating the aggregation mode with an atomic variable.
great that you work on this! :)
I'm no expert on the vis code but here my 2 cents:
* You hard-coded integer values instead of using the existing defines. Any reason for that ?
* my_vis_info->packet.vis_type never gets updated ?
* This patch removes functionality from the /proc parsing function although this is not related to the patch-topic.
* checkpatch reports 8 errors & 8 warnings
Regards,
Marek
Quoted 8 lines · Marek Lindner
Hi,
Quoted 4 lines
This fixes the bug discovered by Marek which did not allow turning on the vis-server before an interface has been added. This is now being done in a similar way as for (de)activating the aggregation mode with an atomic variable.
Quoted 5 lines
great that you work on this! :)
I'm no expert on the vis code but here my 2 cents:
* You hard-coded integer values instead of using the existing defines. Any reason for that ?
Hmm, so far we are having too modes only, vis server being enabled or disabled. But in those packet functions we are talking about types (two ones only so far again) instead. In the second one I found it ok to use the defines, but for the proc.c switching, I found a simple 0 or 1 more intuitive, as you already know that this function is for enabling/disabling the vis server and you don't have to wonder about a certain vis-types field in the vis-packet format. Hmm, I'm also wondering, are there any plans for introducing other vis_types? (What would you think about changing the 8 bits vis_type field to flags instead?)
Quoted 1 line
*
my_vis_info->packet.vis_typenever gets updated ?
Damn it, you are right :). I assume, that it'd be ok to remove the default value being set in vis_init and explicitly setting this field every time a new vis packet gets generated in generate_vis_packet() (instead of updating this variable from proc.c too)?
Quoted 2 lines
* This patch removes functionality from the /proc parsing function although this is not related to the patch-topic.
Yes, sorry, you're right I'd removed the server/client/enabled/disabled things and added just 0/1 as input values for proc to make the syntax similar to the aggregation stuff and simple in general for the kernel module. I'm going to put that in a seperate patch.
Quoted 1 line
* checkpatch reports 8 errors & 8 warnings
Ehm, just got 1 error at the else part... (sorry, never used checkpatch before, hope that I'm not handling it wrong in any way...)
Quoted 8 lines
Regards,
Marek
_______________________________________________
B.A.T.M.A.N mailing list
[email protected]
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Quoted 4 lines
Quoted 1 line
* checkpatch reports 8 errors & 8 warnings
Ehm, just got 1 error at the else part... (sorry, never used checkpatch before, hope that I'm not handling it wrong in any way...)
The number of errors will vary depending on which version of checkpatch you use. I tend to use the one from the current -rc kernel, or when sending patches to GregKH, checkpatch from linux-next.
I suggest you don't use anything older than 2.6.32.
Andrew
Quoted 10 lines · On Tuesday 05 January 2010 12:20:58 Linus Lüssing wrote:
Hmm, so far we are having too modes only, vis server being enabled or disabled. But in those packet functions we are talking about types (two ones only so far again) instead. In the second one I found it ok to use the defines, but for the
proc.cswitching, I found a simple 0 or 1 more intuitive, as you already know that this function is for enabling/disabling the vis server and you don't have to wonder about a certain vis-types field in the vis-packet format. Hmm, I'm also wondering, are there any plans for introducing othervis_types? (What would you think about changing the 8 bitsvis_typefield to flags instead?)
I think using defines instead of hard-coded values always is the better choice. Even if it is more intuitive for you now you never know when this code is going to be extended. In addition, you still want to understand the code in 6 months and/or make it easier of others to understand.
Whether it makes sense to rename more variables / defines is another discussion and belongs into another patch. :)
Quoted 4 lines
Damn it, you are right :). I assume, that it'd be ok to remove the default value being set in
vis_initand explicitly setting this field every time a new vis packet gets generated ingenerate_vis_packet()(instead of updating this variable fromproc.ctoo)?
I think a default value is good to have. ;-) generate_vis_packet() looks like a good place to update the packet's variable.
Quoted 5 lines
Yes, sorry, you're right I'd removed the server/client/enabled/disabled things and added just 0/1 as input values for proc to make the syntax similar to the aggregation stuff and simple in general for the kernel module. I'm going to put that in a seperate patch.
Great.
Regards,
Marek
PATCH 1/1 batman-adv: atomic variable for vis-srv activation
In reply to =?UTF-8?q?Linus=20L=C3=BCssing?=This fixes the bug discovered by Marek Lindner which did not allow turning on the vis-server before an interface has been added. With this patch we are using a global atomic variable for activating and deactiating the vis-server-mode instead, which can be used before inserting an interface.
--- batman-adv-kernelland/main.c | 2 + batman-adv-kernelland/main.h | 1 + batman-adv-kernelland/proc.c | 13 ++++++----- batman-adv-kernelland/send.c | 3 +- batman-adv-kernelland/vis.c | 45 +++++------------------------------------ batman-adv-kernelland/vis.h | 2 - 6 files changed, 18 insertions(+), 48 deletions(-)
batman-adv-kernelland/main.c +2 -0
@@ -46,6 +46,7 @@ DEFINE_SPINLOCK(forw_bcast_list_lock);atomic_t originator_interval;atomic_t vis_interval; +atomic_t vis_mode;atomic_t aggregation_enabled;int16_t num_hna;int16_t num_ifs;
@@ -86,6 +87,7 @@ int init_module(void)atomic_set (&originator_interval,1000 );atomic_set (&vis_interval,1000 );/* TODO: raise this later, this is only * for debugging now. */ +atomic_set (&vis_mode,VIS_TYPE_CLIENT_UPDATE );atomic_set (&aggregation_enabled,1 );atomic_set (&gw_mode,GW_MODE_OFF );atomic_set (&gw_srv_class,0 );
batman-adv-kernelland/main.h +1 -0
@@ -130,6 +130,7 @@ extern spinlock_t forw_bcast_list_lock;extern atomic_t originator_interval;extern atomic_t vis_interval; +extern atomic_t vis_mode;extern atomic_t aggregation_enabled;extern int16_t num_hna;extern int16_t num_ifs;
batman-adv-kernelland/proc.c +7 -6
@@ -342,11 +342,11 @@ static ssize_t proc_vis_srv_write(struct file *file, const char __user * buffer,if ((strcmp (vis_mode_string,"client" ) ==0 ) || (strcmp (vis_mode_string,"disabled" ) ==0 )) {printk (KERN_INFO "batman-adv:Setting VIS mode to client (disabling vis server)\n" ); -vis_set_mode (VIS_TYPE_CLIENT_UPDATE ); +atomic_set (&vis_mode,VIS_TYPE_CLIENT_UPDATE ); }else if ((strcmp (vis_mode_string,"server" ) ==0 ) || (strcmp (vis_mode_string,"enabled" ) ==0 )) {printk (KERN_INFO "batman-adv:Setting VIS mode to server (enabling vis server)\n" ); -vis_set_mode (VIS_TYPE_SERVER_SYNC ); +atomic_set (&vis_mode,VIS_TYPE_SERVER_SYNC ); }else printk (KERN_ERR "batman-adv:Unknown VIS mode: %s\n" , vis_mode_string);
@@ -357,12 +357,12 @@ static ssize_t proc_vis_srv_write(struct file *file, const char __user * buffer,static int proc_vis_srv_read (struct seq_file *seq,void *offset) { -int vis_server =is_vis_server (); +int vis_server =atomic_read (&vis_mode);seq_printf (seq,"[%c] client mode (server disabled) \n" , - (!vis_server) ?'x' :' ' ); + (vis_server ==VIS_TYPE_CLIENT_UPDATE ) ?'x' :' ' );seq_printf (seq,"[%c] server mode (server enabled) \n" , - (vis_server) ?'x' :' ' ); + (vis_server ==VIS_TYPE_SERVER_SYNC ) ?'x' :' ' );return 0 ; }
@@ -381,9 +381,10 @@ static int proc_vis_data_read(struct seq_file *seq, void *offset)int i;char tmp_addr_str[ETH_STR_LEN ];unsigned long flags; +int vis_server =atomic_read (&vis_mode);rcu_read_lock (); -if (list_empty (&if_list) || (!is_vis_server ())) { +if (list_empty (&if_list) || (vis_server ==VIS_TYPE_CLIENT_UPDATE )) {rcu_read_unlock (); goto end; }
batman-adv-kernelland/send.c +2 -1
@@ -251,6 +251,7 @@ void schedule_own_packet(struct batman_if *batman_if) {unsigned long send_time;struct batman_packet *batman_packet; +int vis_server =atomic_read (&vis_mode);/** * the interface gets activated here to avoid race conditions between
@@ -275,7 +276,7 @@ void schedule_own_packet(struct batman_if *batman_if)/* change sequence number to network order */ batman_packet->seqno =htons ((uint16_t )atomic_read (&batman_if->seqno)); -if (is_vis_server ()) +if (vis_server ==VIS_TYPE_SERVER_SYNC ) batman_packet->flags =VIS_SERVER ;else batman_packet->flags =0 ;
batman-adv-kernelland/vis.c +6 -39
93 lines not on this page · raw message
batman-adv-kernelland/vis.h +0 -2
@@ -48,8 +48,6 @@ struct recvlist_node {extern struct hashtable_t *vis_hash;extern spinlock_t vis_hash_lock; -void vis_set_mode (int mode); -int is_vis_server (void ); void proc_vis_read_entry(struct seq_file *seq, struct vis_info_entry *entry, struct hlist_head *if_list,
Signature · 1 line
1.6.6
I now decided to use a more general variable name and as Marek suggested the checks against the given define-values. This should keep the structure of several "vis-modes" in general, as it had been done before by Simon, instead of just "on" and "off".
The checkpatch-script from the batman-adv linux git branch showed me 0 errors/warnings for this one.
- So far, just had the time to test this patch with my laptop and home-server only. But switching as well as receiving/displaying the vis-stuff worked fine for those (didn't have a closer look with tcpdump/wireshark for this vis-type part though).
Cheers, Linus
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Marek Lindner
Quoted 5 lines · On Monday 11 January 2010 12:57:56 you wrote:
This fixes the bug discovered by Marek Lindner which did not allow turning on the vis-server before an interface has been added. With this patch we are using a global atomic variable for activating and deactiating the vis-server-mode instead, which can be used before inserting an interface.
Quoted 5 lines
Off-list:
Wollte mir grad deinen Patch reinziehen, aber trotz "git send-email" ist
auch diese Mail is base64 encoded ?? Im Header sehe ich jedenfalls "X-Mailer: git- send-email 1.6.6". Evtl. hängt das mit charset (utf8) zusammen ?
Aaaalso. Ich habe ersteinmal keine Ahnung woher es kommt. git-format-patch produziert sowas jedenfalls nicht. git-send-email eigentlich auch nicht (der bleibt immer bei "Content-Type: text/plain; ...". Wenn ich jetzt im Git Quellcode suche, dann finde ich auch nur funktionen um base64 in Mails zu dekodieren.
Quoted 1 line
@Sven: Hast du eine Idee, woran das liegen könnte ?
Vielleicht macht der Mailman sowas oder irgendwas anderes auf open-mesh.org? Ich habe jetzt einfach mal an meine Adresse auf open-mesh.net die Mail geschickt. Die sieht aber vollkommen in Ordnung aus.
Wenn ich in die mbox von mailman schauen /var/lib/mailman/archives/private/b.a.t.m.a.n.mbox/b.a.t.m.a.n.mbox , dann sieht die Mail so aus wie ich sie von git-send-email erwarten wuerde. Kann es also sein, dass es beim wieder raussenden passiert? Also nicht das raussenden ueber sendmail, sondern das Vorbereiten von mailman.
NEWS fuer 2.1.8 (15-Apr-2006)
{{{
- Updated email library to 2.5.7 which will encode payload into qp/base64 upon setting. This enabled backing out the scrubber related patches including 'X-Mailman-Scrubbed' header in 2.1.7.
}}}
Wieso es das macht ist vielleicht(tm) das "Content-Transfer-Encoding: 8bit" in der Mail von Linus + Decorating. Wenn wir das rausnehmen, sollte es eigentlich gehen.
Siehe dazu auch Mailman/Handlers/Decorate.py process(..)
Ich habe ersteinmal in
https://lists.open-mesh.org/mm/admin/b.a.t.m.a.n/?VARHELP=nondigest/msg_footer
den Footer
{{{
_______________________________________________
%(real_name)s mailing list %(real_name)s@%(host_name)s %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
}}}
entfernt. Vielleicht kann Linus nocheinmal exakt genauso seinen Patch an die Mailingliste senden.
....das waere jedenfalls bis jetzt meine Vermutung. Leider weiss ich gerade nicht wie ich das am einfachsten Testen koennte (bis auf das Linus den Patch einfach nochmal sendet).
Gruesse,
Sven
Sorry for the german mail. This was intended to be off the list. I must accidentally brought that mail back to the mailinglist while playing with mailman.
Best regards,
Sven
Quoted 14 lines · Sven Eckelmann
Quoted 7 lines · Marek Lindner
Quoted 5 lines · On Monday 11 January 2010 12:57:56 you wrote:
This fixes the bug discovered by Marek Lindner which did not allow turning on the vis-server before an interface has been added. With this patch we are using a global atomic variable for activating and deactiating the vis-server-mode instead, which can be used before inserting an interface.
Quoted 5 lines
Off-list:
Wollte mir grad deinen Patch reinziehen, aber trotz "git send-email" ist
auch diese Mail is base64 encoded ?? Im Header sehe ich jedenfalls "X-Mailer: git- send-email 1.6.6". Evtl. h?ngt das mit charset (utf8) zusammen ?
Quoted 5 lines
Aaaalso. Ich habe ersteinmal keine Ahnung woher es kommt. git-format-patch produziert sowas jedenfalls nicht. git-send-email eigentlich auch nicht (der bleibt immer bei "Content-Type: text/plain; ...". Wenn ich jetzt im Git Quellcode suche, dann finde ich auch nur funktionen um base64 in Mails zu dekodieren.
All the patches i've generated so far from git have been plain old ASCII, even though some contain extended characters, because of umlauts in names. So i agree with Sven, it is more likely to be a problem with the mail system somewhere, not git.
Andrew
PATCH 1/1 batman-adv: atomic variable for vis-srv activation
In reply to Sven EckelmannThis fixes the bug discovered by Marek Lindner which did not allow turning on the vis-server before an interface has been added. With this patch we are using a global atomic variable for activating and deactiating the vis-server-mode instead, which can be used before inserting an interface.
--- batman-adv-kernelland/main.c | 2 + batman-adv-kernelland/main.h | 1 + batman-adv-kernelland/proc.c | 13 ++++++----- batman-adv-kernelland/send.c | 3 +- batman-adv-kernelland/vis.c | 45 +++++------------------------------------ batman-adv-kernelland/vis.h | 2 - 6 files changed, 18 insertions(+), 48 deletions(-)
batman-adv-kernelland/main.c +2 -0
@@ -46,6 +46,7 @@ DEFINE_SPINLOCK(forw_bcast_list_lock);atomic_t originator_interval;atomic_t vis_interval; +atomic_t vis_mode;atomic_t aggregation_enabled;int16_t num_hna;int16_t num_ifs;
@@ -86,6 +87,7 @@ int init_module(void)atomic_set (&originator_interval,1000 );atomic_set (&vis_interval,1000 );/* TODO: raise this later, this is only * for debugging now. */ +atomic_set (&vis_mode,VIS_TYPE_CLIENT_UPDATE );atomic_set (&aggregation_enabled,1 );atomic_set (&gw_mode,GW_MODE_OFF );atomic_set (&gw_srv_class,0 );
batman-adv-kernelland/main.h +1 -0
@@ -130,6 +130,7 @@ extern spinlock_t forw_bcast_list_lock;extern atomic_t originator_interval;extern atomic_t vis_interval; +extern atomic_t vis_mode;extern atomic_t aggregation_enabled;extern int16_t num_hna;extern int16_t num_ifs;
batman-adv-kernelland/proc.c +7 -6
@@ -342,11 +342,11 @@ static ssize_t proc_vis_srv_write(struct file *file, const char __user * buffer,if ((strcmp (vis_mode_string,"client" ) ==0 ) || (strcmp (vis_mode_string,"disabled" ) ==0 )) {printk (KERN_INFO "batman-adv:Setting VIS mode to client (disabling vis server)\n" ); -vis_set_mode (VIS_TYPE_CLIENT_UPDATE ); +atomic_set (&vis_mode,VIS_TYPE_CLIENT_UPDATE ); }else if ((strcmp (vis_mode_string,"server" ) ==0 ) || (strcmp (vis_mode_string,"enabled" ) ==0 )) {printk (KERN_INFO "batman-adv:Setting VIS mode to server (enabling vis server)\n" ); -vis_set_mode (VIS_TYPE_SERVER_SYNC ); +atomic_set (&vis_mode,VIS_TYPE_SERVER_SYNC ); }else printk (KERN_ERR "batman-adv:Unknown VIS mode: %s\n" , vis_mode_string);
@@ -357,12 +357,12 @@ static ssize_t proc_vis_srv_write(struct file *file, const char __user * buffer,static int proc_vis_srv_read (struct seq_file *seq,void *offset) { -int vis_server =is_vis_server (); +int vis_server =atomic_read (&vis_mode);seq_printf (seq,"[%c] client mode (server disabled) \n" , - (!vis_server) ?'x' :' ' ); + (vis_server ==VIS_TYPE_CLIENT_UPDATE ) ?'x' :' ' );seq_printf (seq,"[%c] server mode (server enabled) \n" , - (vis_server) ?'x' :' ' ); + (vis_server ==VIS_TYPE_SERVER_SYNC ) ?'x' :' ' );return 0 ; }
@@ -381,9 +381,10 @@ static int proc_vis_data_read(struct seq_file *seq, void *offset)int i;char tmp_addr_str[ETH_STR_LEN ];unsigned long flags; +int vis_server =atomic_read (&vis_mode);rcu_read_lock (); -if (list_empty (&if_list) || (!is_vis_server ())) { +if (list_empty (&if_list) || (vis_server ==VIS_TYPE_CLIENT_UPDATE )) {rcu_read_unlock (); goto end; }
batman-adv-kernelland/send.c +2 -1
@@ -251,6 +251,7 @@ void schedule_own_packet(struct batman_if *batman_if) {unsigned long send_time;struct batman_packet *batman_packet; +int vis_server =atomic_read (&vis_mode);/** * the interface gets activated here to avoid race conditions between
@@ -275,7 +276,7 @@ void schedule_own_packet(struct batman_if *batman_if)/* change sequence number to network order */ batman_packet->seqno =htons ((uint16_t )atomic_read (&batman_if->seqno)); -if (is_vis_server ()) +if (vis_server ==VIS_TYPE_SERVER_SYNC ) batman_packet->flags =VIS_SERVER ;else batman_packet->flags =0 ;
batman-adv-kernelland/vis.c +6 -39
93 lines not on this page · raw message
batman-adv-kernelland/vis.h +0 -2
@@ -48,8 +48,6 @@ struct recvlist_node {extern struct hashtable_t *vis_hash;extern spinlock_t vis_hash_lock; -void vis_set_mode (int mode); -int is_vis_server (void ); void proc_vis_read_entry(struct seq_file *seq, struct vis_info_entry *entry, struct hlist_head *if_list,
Signature · 1 line
1.6.6
Marek Lindner
AppliedQuoted 5 lines · On Tuesday 19 January 2010 04:42:29 Linus Lüssing wrote:
This fixes the bug discovered by Marek Lindner which did not allow turning on the vis-server before an interface has been added. With this patch we are using a global atomic variable for activating and deactiating the vis-server-mode instead, which can be used before inserting an interface.
Thanks! Applied in revision 1557.
Regards,
Marek