Re: [Fwd: [PATCH] glibc-2.2.5 utmp_file locking and locking question]

[Roland McGrath <roland at frob dot com>]

Since noone has complained in all this time, I am not going to touch the
2.2.x branch for this unless we see a confirmed report of an actual problem
in practice.  

> 	* 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.

This seems like a proper change and I have put it into mainline.

> 	  2. Call LOCK_FILE in setutent_file.

This is pointless.  fcntl locks only affect the file data, not random
peropens or their file positions.

> 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.

The only possible error should be EINTR.  But it does seem reasonable to
check for it.  Hmm, actually ENOLCK and EDEADLK might be possible too.

Does anyone know a reason to ignore the fcntl result?