This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] glibc-2.2.5 utmp_file locking and locking question


Hi,

Please find attached a patch to glibc-2.2.5, utmp handling. The description is as follows

* sysdeps/generic/utmp_file.c: Two changes to utmp locking
1. In UNLOCK_FILE, set the alarm to 0, to avoid the case where the alarm by LOCK_FILE can occur after resetting the original signal handler and before resetting the original alarm. Without this change sometimes unsuspecting process can receive a SIGALRM.
2. Call LOCK_FILE in setutent_file.

This fixes the spurious SIGALRMs which would be delivered in recent cases to our multi-threaded process.

I also have a further question:
I am considering adding another fix which checks the return value of fcntl in LOCK_FILE and on error, returns instead of ignoring it like it is currently done.

Is the ignoring delibrate due to the __libc_utmp_lock lock in login/getutent_r.c, in which case checking the fcntl return value might not be needed. The __libc_utmp_lock is more appropriate though it serializes access, it protects all static\global variables including last_entry, file_offset and file_fd in sysdeps/generic/utmp_file.c from multiple thread access.

I also plan to add a note to the getutent manpage noting that they are not thread-safe and send it to the maintainer and this list.

Thanks and Regards
Amit



diff -ubBrNp glibc-2.2.5/ChangeLog glibc-2.2.5-utmp/ChangeLog
--- glibc-2.2.5/ChangeLog	Sun Jan 20 19:20:18 2002
+++ glibc-2.2.5-utmp/ChangeLog	Tue Aug 13 17:51:51 2002
@@ -1,3 +1,12 @@
+2002-08-13	Amit D. Chaudhary	<amitc@brocade.com>
+
+	* sysdeps/generic/utmp_file.c: Two changes to utmp locking
+	  1. In UNLOCK_FILE, set the alarm to 0, to avoid the case where the 
+	  alarm by LOCK_FILE can occur after resetting the original signal 
+	  handler and before resetting the original alarm. Without this change
+	  sometimes unsuspecting process can receive a SIGALRM.
+	  2. Call LOCK_FILE in setutent_file.
+	
 2002-01-18  Andreas Schwab  <schwab@suse.de>
 
 	* sysdeps/unix/sysv/linux/configure.in
diff -ubBrNp glibc-2.2.5/sysdeps/generic/utmp_file.c glibc-2.2.5-utmp/sysdeps/generic/utmp_file.c
--- glibc-2.2.5/sysdeps/generic/utmp_file.c	Thu Jul  5 21:55:50 2001
+++ glibc-2.2.5-utmp/sysdeps/generic/utmp_file.c	Tue Aug 13 17:52:45 2002
@@ -75,6 +75,7 @@ static void timeout_handler (int signum)
   __fcntl ((fd), F_SETLKW, &fl);                                        \
                                                                         \
   /* Reset the signal handler and alarm.  */                            \
+  alarm(0);                                                             \
   __sigaction (SIGALRM, &old_action, NULL);                             \
   alarm (old_timeout);                                                  \
 } while (0)
@@ -138,8 +139,12 @@ setutent_file (void)
 	}
     }
 
+  LOCK_FILE (file_fd, F_WRLCK);
+
   __lseek64 (file_fd, 0, SEEK_SET);
   file_offset = 0;
+
+  UNLOCK_FILE (file_fd);
 
 #if _HAVE_UT_TYPE - 0
   /* Make sure the entry won't match.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]