* [PATCH] xfbbd: Fix issue with xfbbd and AX25 radio connections
@ 2010-11-14 18:58 Bernard Pidoux
2013-07-05 21:20 ` [PATCH] xfbbd: Run the same data files on 64-bit Cathryn Mataga
0 siblings, 1 reply; 6+ messages in thread
From: Bernard Pidoux @ 2010-11-14 18:58 UTC (permalink / raw)
To: Cathryn Mataga, linux-hams
Hi Cathryn,
Many thanks for the patches.
I had noticed the SIGPIPE bug when in GDB session.
However xfbbd did not fail usually when not under GDB.
Anyway, its nice you cured the problem.
Other bugs were also very annoying and I am gratefull that
your perspicacy found the reasons I did not discovered.
I applied your patch into new FBB pre release xd704r12.
http://f6bvp.free.fr/logiciels/BBS-f6fbb/xd704r12-src.tar.bz2
See CHANGES file for important notices about the use of xfbbd
on 64 bits and SMP systems.
73s de Bernard, f6bvp
>Patch versus version xfbbd version r11
>
>Same patch file, Except I changed the email subject.
>
>
>
>1. SOCK_MAXCHAN (drv_sock.c) now set to (MAXVOIES) This was set to 50, which was less than MAXVOIES, and the code was
>accessing data off the end of this table. This was causing strange problems. After I made this change the gateway
>function started working again. If anyone was having trouble with xfbbd and RF radio connections, this change may
>possibly fix their problem.
>2. Several minor changes designed to eliminate "Bad file descriptor" error messages. These occurred at the time
>of housekeeping due to a minor bug. The messages actually turned out to be harmless, as far as I can tell.
>3. Only use the signal handler for signals that have functionality in the code. This is a simplification
>to prevent bugs. Other signals are set to SIG_IGN.
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH] xfbbd: Run the same data files on 64-bit 2010-11-14 18:58 [PATCH] xfbbd: Fix issue with xfbbd and AX25 radio connections Bernard Pidoux @ 2013-07-05 21:20 ` Cathryn Mataga 2013-07-06 21:24 ` Pidoux 0 siblings, 1 reply; 6+ messages in thread From: Cathryn Mataga @ 2013-07-05 21:20 UTC (permalink / raw) To: Bernard Pidoux; +Cc: linux-hams [-- Attachment #1: Type: text/plain, Size: 523 bytes --] I'm moving my ham radio server up to 64-bit Fedora 18. So I'm fixing issues as I hit them. This is against fbbsrc.705e. When compiled for 64 bits, the code was corrupting all my 32-bit data files. I think this is right, that the binary data files should be the same between 32 and 64 bit compiles. After applying this patch, I see my user names and messages correctly after copying data from my old 32-bit install to a new 64-bit install. I haven't made any patches in awhile so if anything is wrong let me know. [-- Attachment #2: fbbsrc.705e.sixtyfour.patch --] [-- Type: text/plain, Size: 3024 bytes --] --- /home/cathryn/fbbsrc.705e/include/fbb_serv.h 2013-03-16 10:00:56.000000000 -0400 +++ /home/cathryn/fbbsrc.705e.sixtyfour/include/fbb_serv.h 2013-07-05 16:26:01.814157699 -0400 @@ -31,7 +31,7 @@ #ifndef _fbb_serv #define _fbb_serv - +#define fbb_long int /* #define FORTIFY */ #ifdef __LINUX__ @@ -655,8 +655,8 @@ uchar free; uchar changed; ushort seen; - long last_modif __a2__; - long last_seen __a2__; + fbb_long last_modif __a2__; + fbb_long last_seen __a2__; char first_homebbs[41]; char secnd_homebbs[41]; char first_zip[9]; @@ -669,7 +669,6 @@ /* * Structures et blocs de messages */ - typedef struct { long nmess; @@ -733,7 +732,7 @@ char indcnx[6]; uchar port; uchar voie; - long datcnx __a2__; + fbb_long datcnx __a2__; short tpscnx; } statis; @@ -767,17 +766,17 @@ indicat indic; /* 8 Callsign */ indicat relai[8]; /* 64 Digis path */ - long lastmes __a2__; /* 4 Last L number */ - long nbcon __a2__; /* 4 Number of connexions */ - long hcon __a2__; /* 4 Last connexion date */ - long lastyap __a2__; /* 4 Last YN date */ + fbb_long lastmes __a2__; /* 4 Last L number */ + fbb_long nbcon __a2__; /* 4 Number of connexions */ + fbb_long hcon __a2__; /* 4 Last connexion date */ + fbb_long lastyap __a2__; /* 4 Last YN date */ ushort flags; /* 2 Flags */ ushort on_base; /* 2 ON Base number */ uchar nbl; /* 1 Lines paging */ uchar lang; /* 1 Language */ - long newbanner __a2__; /* 4 Last Banner date */ + fbb_long newbanner __a2__; /* 4 Last Banner date */ ushort download; /* 2 download size (KB) = 100 */ char free[20]; /* 20 Reserved */ char theme; /* 1 Current topic */ @@ -802,7 +801,7 @@ { char mode; char fbid[13]; - long numero __a2__; + fbb_long numero __a2__; } bidfwd; @@ -850,9 +849,9 @@ { /* Longueur = 194 octets */ char type; char status; - long numero __a2__; - long taille __a2__; - long date __a2__; + fbb_long numero __a2__; + fbb_long taille __a2__; + fbb_long date __a2__; char bbsf[7]; char bbsv[41]; char exped[7]; @@ -861,11 +860,11 @@ char titre[61]; char bin; char free[5]; - long grpnum __a2__; + fbb_long grpnum __a2__; ushort nblu; - long theme __a2__; - long datesd __a2__; - long datech __a2__; + fbb_long theme __a2__; + fbb_long datesd __a2__; + fbb_long datech __a2__; char fbbs[NBMASK]; char forw[NBMASK]; } @@ -921,12 +920,12 @@ double a0 __a2__; double n0 __a2__; double q3 __a2__; - long k0 __a2__; + fbb_long k0 __a2__; double f1 __a2__; double v1 __a2__; short pas; - long maj __a2__; - long cat __a2__; /* Catalog Number - anciennement vide */ + fbb_long maj __a2__; + fbb_long cat __a2__; /* Catalog Number - anciennement vide */ short libre[4]; } satel; @@ -1230,8 +1229,8 @@ char nomfic[LABEL_FIC]; char label[LABEL_NOM]; char owner[LABEL_OWN]; - long index; - long date_creation; + fbb_long index; + fbb_long date_creation; char free[24]; } Rlabel; /* 160 bytes */ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfbbd: Run the same data files on 64-bit 2013-07-05 21:20 ` [PATCH] xfbbd: Run the same data files on 64-bit Cathryn Mataga @ 2013-07-06 21:24 ` Pidoux 2013-07-07 0:15 ` Cathryn Mataga 2013-07-16 3:09 ` Cathryn Mataga 0 siblings, 2 replies; 6+ messages in thread From: Pidoux @ 2013-07-06 21:24 UTC (permalink / raw) To: Cathryn Mataga; +Cc: linux-hams Hi Cathryn, Thank you for your message. I have been using FBB 7.05e on a 64 bits machine for a while with Mandriva and somce lat year with Mageia Linux distro without problem. However I never tried to import any data from a previous 32 bits install for I do not see any necessity to do that. What kind of data do you want to import ? However, would you mind providing a patch created with diff -pruN options. This is the one I am used to read. I will consider it and let you know the results of my tests. 73 de Bernard Pidoux f6bvp Sent from my iPhone Le 5 juil. 2013 à 23:20, Cathryn Mataga <cathryn@junglevision.com> a écrit : > I'm moving my ham radio server up to 64-bit Fedora 18. So I'm fixing issues as I hit them. > > This is against fbbsrc.705e. When compiled for 64 bits, the code was corrupting all my 32-bit data files. > I think this is right, that the binary data files should be the same between 32 and 64 bit compiles. > > After applying this patch, I see my user names and messages correctly after copying data from my old 32-bit install to a new 64-bit install. > > I haven't made any patches in awhile so if anything is wrong let me know. > > <fbbsrc.705e.sixtyfour.patch> -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfbbd: Run the same data files on 64-bit 2013-07-06 21:24 ` Pidoux @ 2013-07-07 0:15 ` Cathryn Mataga 2013-07-16 3:09 ` Cathryn Mataga 1 sibling, 0 replies; 6+ messages in thread From: Cathryn Mataga @ 2013-07-07 0:15 UTC (permalink / raw) To: Pidoux; +Cc: linux-hams On 7/6/2013 2:24 PM, Pidoux wrote: > Hi Cathryn, > > Thank you for your message. > I have been using FBB 7.05e on a 64 bits machine for a while with Mandriva and somce lat year with Mageia Linux distro without problem. >However I never tried to import any data from a previous 32 bits install for I do not see any necessity to do that. Yeah, what happened to me was I upgraded and then all my messages/users went away because the 64/32 bit issue. Basically the structures for files suck as inf.sys (which contain the user list) use 'long' which is 64-bits on 64 bit systems and 32-bits on 32-bit systems. So when you upgrade from 32 to 64 bits all the data is lost. However, this change would cause issues for anyone now who has been 64-bit since the change. I can send again in the correct format but with an #ifdef so that it can only be turned on only for people who need it. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfbbd: Run the same data files on 64-bit 2013-07-06 21:24 ` Pidoux 2013-07-07 0:15 ` Cathryn Mataga @ 2013-07-16 3:09 ` Cathryn Mataga 1 sibling, 0 replies; 6+ messages in thread From: Cathryn Mataga @ 2013-07-16 3:09 UTC (permalink / raw) To: Pidoux; +Cc: linux-hams [-- Attachment #1: Type: text/plain, Size: 1992 bytes --] On 7/6/2013 2:24 PM, Pidoux wrote: Alright, let's try this again. This is in -pruN format. if THIRTYTWOBITDATA is defined then the data will be created in a way that's compatible with the 32-bit versions of the program, and compatible with the documentation on the f6fbb.org website. I also fixed some compile warnings that were created by the last patch. The default is set to 64-bit data. Note: That the 64-bit data and 32-bit data are not compatible with each other, so back up your data files first before you experiment with this. > Hi Cathryn, > > Thank you for your message. > I have been using FBB 7.05e on a 64 bits machine for a while with Mandriva and somce lat year with Mageia Linux distro without problem. > However I never tried to import any data from a previous 32 bits install for I do not see any necessity to do that. > What kind of data do you want to import ? > > However, would you mind providing a patch created with diff -pruN options. This is the one I am used to read. > > I will consider it and let you know the results of my tests. > > 73 de Bernard Pidoux f6bvp > > Sent from my iPhone > > Le 5 juil. 2013 à 23:20, Cathryn Mataga <cathryn@junglevision.com> a écrit : > >> I'm moving my ham radio server up to 64-bit Fedora 18. So I'm fixing issues as I hit them. >> >> This is against fbbsrc.705e. When compiled for 64 bits, the code was corrupting all my 32-bit data files. >> I think this is right, that the binary data files should be the same between 32 and 64 bit compiles. >> >> After applying this patch, I see my user names and messages correctly after copying data from my old 32-bit install to a new 64-bit install. >> >> I haven't made any patches in awhile so if anything is wrong let me know. >> >> <fbbsrc.705e.sixtyfour.patch> > -- > To unsubscribe from this list: send the line "unsubscribe linux-hams" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: patch.fbbsrc.705e.32data --] [-- Type: text/plain, Size: 8855 bytes --] diff -pruN /home/cathryn/fbbsrc.705e/include/diff.txt /home/cathryn/fbbsrc.705e.sixtyfour/include/diff.txt --- /home/cathryn/fbbsrc.705e/include/diff.txt 1969-12-31 19:00:00.000000000 -0500 +++ /home/cathryn/fbbsrc.705e.sixtyfour/include/diff.txt 2013-07-05 17:09:12.111823509 -0400 @@ -0,0 +1,127 @@ +--- /home/cathryn/fbb_serv.h 2013-07-05 17:03:09.150055265 -0400 ++++ fbb_serv.h 2013-07-05 16:26:01.814157699 -0400 +@@ -31,7 +31,7 @@ + + #ifndef _fbb_serv + #define _fbb_serv +- ++#define fbb_long int + /* #define FORTIFY */ + + #ifdef __LINUX__ +@@ -655,8 +655,8 @@ + uchar free; + uchar changed; + ushort seen; +- long last_modif __a2__; +- long last_seen __a2__; ++ fbb_long last_modif __a2__; ++ fbb_long last_seen __a2__; + char first_homebbs[41]; + char secnd_homebbs[41]; + char first_zip[9]; +@@ -669,7 +669,6 @@ + /* + * Structures et blocs de messages + */ +- + typedef struct + { + long nmess; +@@ -733,7 +732,7 @@ + char indcnx[6]; + uchar port; + uchar voie; +- long datcnx __a2__; ++ fbb_long datcnx __a2__; + short tpscnx; + } + statis; +@@ -767,17 +766,17 @@ + + indicat indic; /* 8 Callsign */ + indicat relai[8]; /* 64 Digis path */ +- long lastmes __a2__; /* 4 Last L number */ +- long nbcon __a2__; /* 4 Number of connexions */ +- long hcon __a2__; /* 4 Last connexion date */ +- long lastyap __a2__; /* 4 Last YN date */ ++ fbb_long lastmes __a2__; /* 4 Last L number */ ++ fbb_long nbcon __a2__; /* 4 Number of connexions */ ++ fbb_long hcon __a2__; /* 4 Last connexion date */ ++ fbb_long lastyap __a2__; /* 4 Last YN date */ + ushort flags; /* 2 Flags */ + ushort on_base; /* 2 ON Base number */ + + uchar nbl; /* 1 Lines paging */ + uchar lang; /* 1 Language */ + +- long newbanner __a2__; /* 4 Last Banner date */ ++ fbb_long newbanner __a2__; /* 4 Last Banner date */ + ushort download; /* 2 download size (KB) = 100 */ + char free[20]; /* 20 Reserved */ + char theme; /* 1 Current topic */ +@@ -802,7 +801,7 @@ + { + char mode; + char fbid[13]; +- long numero __a2__; ++ fbb_long numero __a2__; + } + bidfwd; + +@@ -850,9 +849,9 @@ + { /* Longueur = 194 octets */ + char type; + char status; +- long numero __a2__; +- long taille __a2__; +- long date __a2__; ++ fbb_long numero __a2__; ++ fbb_long taille __a2__; ++ fbb_long date __a2__; + char bbsf[7]; + char bbsv[41]; + char exped[7]; +@@ -861,11 +860,11 @@ + char titre[61]; + char bin; + char free[5]; +- long grpnum __a2__; ++ fbb_long grpnum __a2__; + ushort nblu; +- long theme __a2__; +- long datesd __a2__; +- long datech __a2__; ++ fbb_long theme __a2__; ++ fbb_long datesd __a2__; ++ fbb_long datech __a2__; + char fbbs[NBMASK]; + char forw[NBMASK]; + } +@@ -921,12 +920,12 @@ + double a0 __a2__; + double n0 __a2__; + double q3 __a2__; +- long k0 __a2__; ++ fbb_long k0 __a2__; + double f1 __a2__; + double v1 __a2__; + short pas; +- long maj __a2__; +- long cat __a2__; /* Catalog Number - anciennement vide */ ++ fbb_long maj __a2__; ++ fbb_long cat __a2__; /* Catalog Number - anciennement vide */ + short libre[4]; + } + satel; +@@ -1230,8 +1229,8 @@ + char nomfic[LABEL_FIC]; + char label[LABEL_NOM]; + char owner[LABEL_OWN]; +- long index; +- long date_creation; ++ fbb_long index; ++ fbb_long date_creation; + char free[24]; + } + Rlabel; /* 160 bytes */ diff -pruN /home/cathryn/fbbsrc.705e/include/fbb_serv.h /home/cathryn/fbbsrc.705e.sixtyfour/include/fbb_serv.h --- /home/cathryn/fbbsrc.705e/include/fbb_serv.h 2013-03-16 10:00:56.000000000 -0400 +++ /home/cathryn/fbbsrc.705e.sixtyfour/include/fbb_serv.h 2013-07-15 23:00:33.975359320 -0400 @@ -32,6 +32,15 @@ #ifndef _fbb_serv #define _fbb_serv +/* Define THIRTYTWOBITDATA if you are bringing in data from 32-bit versions. + This creates datafiles that match the origin documentation for FBB. + They are not compatible with files created with 64-bit versions. */ +/* #define THIRTYTWOBITDATA 1 */ +#ifdef THIRTYTWOBITDATA +#define fbb_long int +#else +#define fbb_long long +#endif /* #define FORTIFY */ #ifdef __LINUX__ @@ -655,8 +664,8 @@ typedef struct uchar free; uchar changed; ushort seen; - long last_modif __a2__; - long last_seen __a2__; + fbb_long last_modif __a2__; + fbb_long last_seen __a2__; char first_homebbs[41]; char secnd_homebbs[41]; char first_zip[9]; @@ -669,7 +678,6 @@ Wps; /* * Structures et blocs de messages */ - typedef struct { long nmess; @@ -733,7 +741,7 @@ typedef struct typstat char indcnx[6]; uchar port; uchar voie; - long datcnx __a2__; + fbb_long datcnx __a2__; short tpscnx; } statis; @@ -767,17 +775,17 @@ typedef struct indicat indic; /* 8 Callsign */ indicat relai[8]; /* 64 Digis path */ - long lastmes __a2__; /* 4 Last L number */ - long nbcon __a2__; /* 4 Number of connexions */ - long hcon __a2__; /* 4 Last connexion date */ - long lastyap __a2__; /* 4 Last YN date */ + fbb_long lastmes __a2__; /* 4 Last L number */ + fbb_long nbcon __a2__; /* 4 Number of connexions */ + fbb_long hcon __a2__; /* 4 Last connexion date */ + fbb_long lastyap __a2__; /* 4 Last YN date */ ushort flags; /* 2 Flags */ ushort on_base; /* 2 ON Base number */ uchar nbl; /* 1 Lines paging */ uchar lang; /* 1 Language */ - long newbanner __a2__; /* 4 Last Banner date */ + fbb_long newbanner __a2__; /* 4 Last Banner date */ ushort download; /* 2 download size (KB) = 100 */ char free[20]; /* 20 Reserved */ char theme; /* 1 Current topic */ @@ -802,7 +810,7 @@ typedef struct { char mode; char fbid[13]; - long numero __a2__; + fbb_long numero __a2__; } bidfwd; @@ -850,9 +858,9 @@ typedef struct { /* Longueur = 194 octets */ char type; char status; - long numero __a2__; - long taille __a2__; - long date __a2__; + fbb_long numero __a2__; + fbb_long taille __a2__; + fbb_long date __a2__; char bbsf[7]; char bbsv[41]; char exped[7]; @@ -861,11 +869,11 @@ typedef struct char titre[61]; char bin; char free[5]; - long grpnum __a2__; + fbb_long grpnum __a2__; ushort nblu; - long theme __a2__; - long datesd __a2__; - long datech __a2__; + fbb_long theme __a2__; + fbb_long datesd __a2__; + fbb_long datech __a2__; char fbbs[NBMASK]; char forw[NBMASK]; } @@ -921,12 +929,12 @@ typedef struct typ_satel double a0 __a2__; double n0 __a2__; double q3 __a2__; - long k0 __a2__; + fbb_long k0 __a2__; double f1 __a2__; double v1 __a2__; short pas; - long maj __a2__; - long cat __a2__; /* Catalog Number - anciennement vide */ + fbb_long maj __a2__; + fbb_long cat __a2__; /* Catalog Number - anciennement vide */ short libre[4]; } satel; @@ -1230,8 +1238,8 @@ typedef struct char nomfic[LABEL_FIC]; char label[LABEL_NOM]; char owner[LABEL_OWN]; - long index; - long date_creation; + fbb_long index; + fbb_long date_creation; char free[24]; } Rlabel; /* 160 bytes */ diff -pruN /home/cathryn/fbbsrc.705e/src/ERROR.SYS /home/cathryn/fbbsrc.705e.sixtyfour/src/ERROR.SYS --- /home/cathryn/fbbsrc.705e/src/ERROR.SYS 1969-12-31 19:00:00.000000000 -0500 +++ /home/cathryn/fbbsrc.705e.sixtyfour/src/ERROR.SYS 2013-07-05 01:46:14.970761411 -0400 @@ -0,0 +1,4 @@ +> EXCEPTION : Station , Ch:0 (0-0-0) 04/07/13 22:46 + Version 7.05e (Jul 5 2013) + /usr/local/var/ax25/fbb/sat/satel.dat 0, errno 13=Permission denied Cannot create file + diff -pruN /home/cathryn/fbbsrc.705e/src/statis.c /home/cathryn/fbbsrc.705e.sixtyfour/src/statis.c --- /home/cathryn/fbbsrc.705e/src/statis.c 2013-03-16 10:00:56.000000000 -0400 +++ /home/cathryn/fbbsrc.705e.sixtyfour/src/statis.c 2013-07-15 22:57:43.488768628 -0400 @@ -30,6 +30,20 @@ #include <serv.h> +#ifdef THIRTYTWOBITDATA + +static struct tm *fbb_localtime(int *time) +{ +long ltime = *time; +return localtime(<ime); +} + + +#else +#define fbb_localtime localtime +#endif + + static void menu_statistiques (void); static void histo_jour (void) @@ -72,7 +86,7 @@ static void histo_jour (void) n_cpy (6, cal, buffstat.indcnx); if (strmatch (cal, pvoie->ch_temp)) { - sdate = localtime (&buffstat.datcnx); + sdate = fbb_localtime (&buffstat.datcnx); hist[(sdate->tm_wday + 6) % 7] += buffstat.tpscnx; } } @@ -145,7 +159,7 @@ static void histo_heure (void) n_cpy (6, cal, buffstat.indcnx); if (strmatch (cal, pvoie->ch_temp)) { - sdate = localtime (&buffstat.datcnx); + sdate = fbb_localtime (&buffstat.datcnx); hist[sdate->tm_hour] += buffstat.tpscnx; } } @@ -212,7 +226,7 @@ static void generalites (void) depart = time (NULL) - (long) nbjour *86400L; } - sdate = localtime (&buffstat.datcnx); + sdate = fbb_localtime (&buffstat.datcnx); if (buffstat.datcnx > depart) { hist[sdate->tm_hour] += (long) buffstat.tpscnx; ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 4/11] drivers/net/hamradio: Eliminate a NULL pointer dereference
@ 2010-05-27 12:33 Julia Lawall
2010-05-27 23:29 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Julia Lawall @ 2010-05-27 12:33 UTC (permalink / raw)
To: Jean-Paul Roubelat, linux-hams, netdev, linux-kernel,
kernel-janitors
From: Julia Lawall <julia@diku.dk>
At the point of the print, dev is NULL.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression E,E1;
identifier f;
statement S1,S2,S3;
@@
if ((E == NULL && ...) || ...)
{
... when != if (...) S1 else S2
when != E = E1
* E->f
... when any
return ...;
}
else S3
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/hamradio/yam.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 694132e..4e7d1d0 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -1151,8 +1151,7 @@ static int __init yam_init_driver(void)
dev = alloc_netdev(sizeof(struct yam_port), name,
yam_setup);
if (!dev) {
- printk(KERN_ERR "yam: cannot allocate net device %s\n",
- dev->name);
+ pr_err("yam: cannot allocate net device\n");
err = -ENOMEM;
goto error;
}
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 4/11] drivers/net/hamradio: Eliminate a NULL pointer dereference 2010-05-27 12:33 [PATCH 4/11] drivers/net/hamradio: Eliminate a NULL pointer dereference Julia Lawall @ 2010-05-27 23:29 ` David Miller 2010-11-09 19:09 ` xfbbd oddness Cathryn Mataga 0 siblings, 1 reply; 6+ messages in thread From: David Miller @ 2010-05-27 23:29 UTC (permalink / raw) To: julia; +Cc: jpr, linux-hams, netdev, linux-kernel, kernel-janitors From: Julia Lawall <julia@diku.dk> Date: Thu, 27 May 2010 14:33:00 +0200 (CEST) > At the point of the print, dev is NULL. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) ... > Signed-off-by: Julia Lawall <julia@diku.dk> Applied. ^ permalink raw reply [flat|nested] 6+ messages in thread
* xfbbd oddness. 2010-05-27 23:29 ` David Miller @ 2010-11-09 19:09 ` Cathryn Mataga 2010-11-10 2:54 ` Cathryn Mataga 0 siblings, 1 reply; 6+ messages in thread From: Cathryn Mataga @ 2010-11-09 19:09 UTC (permalink / raw) To: linux-hams; +Cc: Gary Mitchell, bernard.pidoux well, I'm running xfbbd, and it's forwarding via internet no problem. But I have an actual RF connection over AX25 that I'm trying to make work and I'm getting a fault here. I haven't really spent any time on this, but I'm just posting my backtrace here in case anyone else has been this way before. This is the version R11 off the website with no changes by me. The older version did the same thing, so this isn't a new issue. uname -v shows 2.6.32.21-i68.fc12.i686.PAE This is an SMP kernel, maybe this is still a problem? It's dying in sig_fct, which doesn't actually do anything with SIGPIPE. "SIGPIPE is the signal sent to a process when it attempts to write to a pipe without a process connected to the other end." Could this be an attempt by FBB to write a packet, after the connection has been closed? (This is just me thinking out loud here.) Time out 200 mn Timeout voie 73 depasse Program received signal SIGPIPE, Broken pipe. 0x0016c416 in __kernel_vsyscall () (gdb) down #0 0x0804da80 in sig_fct () (gdb) backtrace #0 0x0804da80 in sig_fct () #1 <signal handler called> #2 0x0016c416 in __kernel_vsyscall () #3 0x00a85f73 in __write_nocancel () from /lib/libc.so.6 #4 0x0806cec4 in snd_sck () #5 0x0805c18c in snd_drv () #6 0x080bc909 in send_buf () #7 0x0808eff8 in traite_voie () #8 0x080908e8 in user_time_out () #9 0x08091899 in kernel () #10 0x0804dcf2 in process () #11 0x080507d2 in fbb_orb () #12 0x0804e05e in main () (gdb) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfbbd oddness. 2010-11-09 19:09 ` xfbbd oddness Cathryn Mataga @ 2010-11-10 2:54 ` Cathryn Mataga 2010-11-12 21:23 ` Cathryn Mataga 0 siblings, 1 reply; 6+ messages in thread From: Cathryn Mataga @ 2010-11-10 2:54 UTC (permalink / raw) To: linux-hams; +Cc: bernard.pidoux You know, I'm not an expert on signal programming in Unix. But, wouldn't another signal coming in during the wait cause a the system to halt? for (i = 1; i < NSIG; i++) { if (i == SIGBUS || i == SIGSEGV || i == SIGALRM) continue; signal (i, sig_fct); } static void sig_fct (int sig) { int pid, pstatus; sig &= 0xff; pid = wait (&pstatus); signal (sig, sig_fct); switch (sig) { ... stuff } } This handler does nothing useful anyway except for SIGHUP, SIGTERM, SIGBUS and SIGSEGV. I don't see any reason not to just ignore all signals except for the few that do have a function here. I'm going to let it run like this, and see if it fixes the bug. for (i = 1; i < NSIG; i++) { if (i == SIGBUS || i == SIGSEGV || i == SIGALRM) continue; if (i == SIGHUP || i == SIGTERM) signal (i, sig_fct); else signal(i, SIG_IGN); } ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfbbd oddness. 2010-11-10 2:54 ` Cathryn Mataga @ 2010-11-12 21:23 ` Cathryn Mataga 2010-11-14 6:52 ` Cathryn Mataga 0 siblings, 1 reply; 6+ messages in thread From: Cathryn Mataga @ 2010-11-12 21:23 UTC (permalink / raw) To: linux-hams; +Cc: bernard.pidoux Actually, I think ignoring the SIGPIPE and other signals does fix a real problem. I changed this, and I ran about a day with no SIGPIPE faults -- that is with frequent connects from an actual RF-based AX25 connection. No functionality is lost by ignore these signals, so I think I will send in a patch for this at some point. With this one patch, I think xfbbd is basically usable for me on RF connections. There still is a bug. After awhile, I start seeing... select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor and then the system bugs out. The script normally restarts it, though I'm running from gdb myself so for me it just dies. Via google, I see someone reported this bug back in 2004. That was 6 years ago, so it is obviously a very old bug. At least it's consistent, I suppose. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfbbd oddness. 2010-11-12 21:23 ` Cathryn Mataga @ 2010-11-14 6:52 ` Cathryn Mataga 2010-11-14 6:58 ` [PATCH] xfbbd: Fix issue with xfbbd and AX25 radio connections Cathryn Mataga 0 siblings, 1 reply; 6+ messages in thread From: Cathryn Mataga @ 2010-11-14 6:52 UTC (permalink / raw) To: linux-hams; +Cc: bernard.pidoux [-- Attachment #1: Type: text/plain, Size: 790 bytes --] Patch versus version r11 1. SOCK_MAXCHAN (drv_sock.c) now set to (MAXVOIES) This was set to 50, which was less than MAXVOIES, and the code was accessing data off the end of this table. This was causing strange problems. After I made this change the gateway function started working again. If anyone was having trouble with xfbbd and RF radio connections, this change may possibly fix their problem. 2. Several minor changes designed to eliminate "Bad file descriptor" error messages. These occurred at the time of housekeeping due to a minor bug. The messages actually turned out to be harmless, as far as I can tell. 3. Only use the signal handler for signals that have functionality in the code. This is a simplification to prevent bugs. Other signals are set to SIG_IGN. [-- Attachment #2: diff.patch --] [-- Type: text/plain, Size: 2189 bytes --] diff -ruN fbbsrc.704r11/src/drv_sock.c fbbsrc.704r11cathryn/src/drv_sock.c --- fbbsrc.704r11/src/drv_sock.c 2010-06-22 13:03:01.000000000 -0700 +++ fbbsrc.704r11cathryn/src/drv_sock.c 2010-11-13 22:43:56.284120401 -0800 @@ -74,7 +74,8 @@ #define RETR_EVENT 3 #define BUSY_EVENT 4 -#define SOCK_MAXCAN 50 +#define SOCK_MAXCAN (MAXVOIES) /* was 50 -- this was causing bad problems. + This table was being accessed beyond the array */ #define CAN_AX25 0 #define CAN_NETROM 1 @@ -104,7 +105,7 @@ } scan_t; -scan_t scan[SOCK_MAXCAN]; +scan_t scan[SOCK_MAXCAN] = {{0}}; /* I think this is necessary (Though not 100% sure. */ static int last_can = 1; static int msocket = -1; @@ -692,8 +693,11 @@ static int stop_cnx (int port) { - close(p_port[port].fd); - p_port[port].fd = 0; + if (p_port[port].fd) /* Prevent closing of 0 */ + { + close(p_port[port].fd); + p_port[port].fd = 0; + } return 1; } diff -ruN fbbsrc.704r11/src/drv_tcp.c fbbsrc.704r11cathryn/src/drv_tcp.c --- fbbsrc.704r11/src/drv_tcp.c 2009-11-27 08:50:44.000000000 -0800 +++ fbbsrc.704r11cathryn/src/drv_tcp.c 2010-11-13 16:55:53.363119445 -0800 @@ -950,8 +950,11 @@ static int stop_cnx (int port) { - close(p_port[port].fd); - p_port[port].fd = 0; + if (p_port[port].fd) /* Prevent closing of 0 */ + { + close(p_port[port].fd); + p_port[port].fd = 0; + } return 1; } @@ -1439,7 +1442,7 @@ fd_set tcp_excep; struct timeval to; - if (can->sock == -1) + if (can->sock <= 0) /* Was -1. Sock=0 during housekeeping. Cause of select errors */ return (0); if ((can->timeout) && (can->timeout < time (NULL))) diff -ruN fbbsrc.704r11/src/xfbbd.c fbbsrc.704r11cathryn/src/xfbbd.c --- fbbsrc.704r11/src/xfbbd.c 2009-11-27 08:50:44.000000000 -0800 +++ fbbsrc.704r11cathryn/src/xfbbd.c 2010-11-13 17:10:40.879123108 -0800 @@ -195,7 +195,10 @@ { if (i == SIGBUS || i == SIGSEGV || i == SIGALRM) continue; - signal (i, sig_fct); + else if (i == SIGHUP || i == SIGTERM || i == SIGBUS || i == SIGSEGV) + signal (i, sig_fct); /* Use sig_fct only for signals that do something */ + else + signal (i, SIG_IGN); /* Otherwise ignore */ } for (ng = 1; ng < ac; ng++) ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] xfbbd: Fix issue with xfbbd and AX25 radio connections 2010-11-14 6:52 ` Cathryn Mataga @ 2010-11-14 6:58 ` Cathryn Mataga 0 siblings, 0 replies; 6+ messages in thread From: Cathryn Mataga @ 2010-11-14 6:58 UTC (permalink / raw) To: linux-hams; +Cc: bernard.pidoux [-- Attachment #1: Type: text/plain, Size: 857 bytes --] Patch versus version xfbbd version r11 Same patch file, Except I changed the email subject. 1. SOCK_MAXCHAN (drv_sock.c) now set to (MAXVOIES) This was set to 50, which was less than MAXVOIES, and the code was accessing data off the end of this table. This was causing strange problems. After I made this change the gateway function started working again. If anyone was having trouble with xfbbd and RF radio connections, this change may possibly fix their problem. 2. Several minor changes designed to eliminate "Bad file descriptor" error messages. These occurred at the time of housekeeping due to a minor bug. The messages actually turned out to be harmless, as far as I can tell. 3. Only use the signal handler for signals that have functionality in the code. This is a simplification to prevent bugs. Other signals are set to SIG_IGN. [-- Attachment #2: diff.patch --] [-- Type: text/plain, Size: 2189 bytes --] diff -ruN fbbsrc.704r11/src/drv_sock.c fbbsrc.704r11cathryn/src/drv_sock.c --- fbbsrc.704r11/src/drv_sock.c 2010-06-22 13:03:01.000000000 -0700 +++ fbbsrc.704r11cathryn/src/drv_sock.c 2010-11-13 22:43:56.284120401 -0800 @@ -74,7 +74,8 @@ #define RETR_EVENT 3 #define BUSY_EVENT 4 -#define SOCK_MAXCAN 50 +#define SOCK_MAXCAN (MAXVOIES) /* was 50 -- this was causing bad problems. + This table was being accessed beyond the array */ #define CAN_AX25 0 #define CAN_NETROM 1 @@ -104,7 +105,7 @@ } scan_t; -scan_t scan[SOCK_MAXCAN]; +scan_t scan[SOCK_MAXCAN] = {{0}}; /* I think this is necessary (Though not 100% sure. */ static int last_can = 1; static int msocket = -1; @@ -692,8 +693,11 @@ static int stop_cnx (int port) { - close(p_port[port].fd); - p_port[port].fd = 0; + if (p_port[port].fd) /* Prevent closing of 0 */ + { + close(p_port[port].fd); + p_port[port].fd = 0; + } return 1; } diff -ruN fbbsrc.704r11/src/drv_tcp.c fbbsrc.704r11cathryn/src/drv_tcp.c --- fbbsrc.704r11/src/drv_tcp.c 2009-11-27 08:50:44.000000000 -0800 +++ fbbsrc.704r11cathryn/src/drv_tcp.c 2010-11-13 16:55:53.363119445 -0800 @@ -950,8 +950,11 @@ static int stop_cnx (int port) { - close(p_port[port].fd); - p_port[port].fd = 0; + if (p_port[port].fd) /* Prevent closing of 0 */ + { + close(p_port[port].fd); + p_port[port].fd = 0; + } return 1; } @@ -1439,7 +1442,7 @@ fd_set tcp_excep; struct timeval to; - if (can->sock == -1) + if (can->sock <= 0) /* Was -1. Sock=0 during housekeeping. Cause of select errors */ return (0); if ((can->timeout) && (can->timeout < time (NULL))) diff -ruN fbbsrc.704r11/src/xfbbd.c fbbsrc.704r11cathryn/src/xfbbd.c --- fbbsrc.704r11/src/xfbbd.c 2009-11-27 08:50:44.000000000 -0800 +++ fbbsrc.704r11cathryn/src/xfbbd.c 2010-11-13 17:10:40.879123108 -0800 @@ -195,7 +195,10 @@ { if (i == SIGBUS || i == SIGSEGV || i == SIGALRM) continue; - signal (i, sig_fct); + else if (i == SIGHUP || i == SIGTERM || i == SIGBUS || i == SIGSEGV) + signal (i, sig_fct); /* Use sig_fct only for signals that do something */ + else + signal (i, SIG_IGN); /* Otherwise ignore */ } for (ng = 1; ng < ac; ng++) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-07-16 3:09 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-14 18:58 [PATCH] xfbbd: Fix issue with xfbbd and AX25 radio connections Bernard Pidoux 2013-07-05 21:20 ` [PATCH] xfbbd: Run the same data files on 64-bit Cathryn Mataga 2013-07-06 21:24 ` Pidoux 2013-07-07 0:15 ` Cathryn Mataga 2013-07-16 3:09 ` Cathryn Mataga -- strict thread matches above, loose matches on Subject: below -- 2010-05-27 12:33 [PATCH 4/11] drivers/net/hamradio: Eliminate a NULL pointer dereference Julia Lawall 2010-05-27 23:29 ` David Miller 2010-11-09 19:09 ` xfbbd oddness Cathryn Mataga 2010-11-10 2:54 ` Cathryn Mataga 2010-11-12 21:23 ` Cathryn Mataga 2010-11-14 6:52 ` Cathryn Mataga 2010-11-14 6:58 ` [PATCH] xfbbd: Fix issue with xfbbd and AX25 radio connections Cathryn Mataga
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox