This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
[PATCH] glibc-2.2.5 utmp_file locking and locking question
- From: "Amit D. Chaudhary" <amitc at brocade dot com>
- To: libc-alpha at sources dot redhat dot com
- Cc: kettenis at phys dot uva dot nl
- Date: Wed, 14 Aug 2002 15:55:16 -0700
- Subject: [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. */