Automatic report from sources (radiusd) between 07.11.2005 - 08.11.2005 GMT
CVS log entries from 07.11.2005 (Mon) 09:00:00 - 08.11.2005 (Tue) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/request_list.c; Revisions: 1.69 Author: fcusack File: radiusd/src/modules/rlm_otp/otp_radstate.c; Revisions: 1.4 File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h; Revisions: 1.37, 1.36 File: radiusd/src/modules/rlm_otp/otp_x99.c; Revisions: 1.6 File: radiusd/src/modules/rlm_otp/otp_rlm.c; Revisions: 1.15 File: radiusd/src/modules/rlm_otp/otp_rad.h; Revisions: 1.4 File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revisions: 1.59, 1.58 File: radiusd/src/modules/rlm_otp/otp_util.c; Revisions: 1.11, 1.10 File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revisions: 1.41, 1.40 File: radiusd/src/modules/rlm_otp/otp_state.c; Revisions: 1.22 File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c; Revisions: 1.38, 1.37 File: radiusd/src/modules/rlm_otp/otp_site.c; Revisions: 1.4 File: radiusd/src/modules/rlm_otp/otp.h; Revisions: 1.25, 1.24, 1.23 ===================================================== Combined list of identical log entries ===================================================== Description: s/user_info/card_info/ Modified files: File: radiusd/src/modules/rlm_otp/otp.h; Revision: 1.23; Date: 2005/11/07 09:28:33; Author: fcusack; Lines: (+4 -4) File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revision: 1.58; Date: 2005/11/07 09:28:33; Author: fcusack; Lines: (+30 -30) File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revision: 1.40; Date: 2005/11/07 09:28:33; Author: fcusack; Lines: (+7 -7) File: radiusd/src/modules/rlm_otp/otp_util.c; Revision: 1.10; Date: 2005/11/07 09:28:34; Author: fcusack; Lines: (+26 -26) File: radiusd/src/modules/rlm_otp/otp_x99.c; Revision: 1.6; Date: 2005/11/07 09:28:34; Author: fcusack; Lines: (+3 -3) File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c; Revision: 1.37; Date: 2005/11/07 09:28:34; Author: fcusack; Lines: (+12 -12) File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h; Revision: 1.36; Date: 2005/11/07 09:28:34; Author: fcusack; Lines: (+7 -7) ------------------------------- Description: Change user_state 'challenge' field from string to uchar, which makes more sense for crypto and other manipulation. Unfortunately, it is a huge change for such a small gain (basically avoiding sprintf() and sscanf() conversions.) Notable changes: - otp.h: add 'clen' field to user_state; update it wherever the 'challenge' field is set - otp_cardops.h: add printchallenge() method, OTP_CF_C8 and OTP_CF_C4 Card Feature macros - cardops keystring2keyblock() method and otp_keystring2keyblock() now return keylen (instead of 0) on success - otp_keyblock2keystring() now takes a length arg and returns char * for easy printing - remove [unused] 'card_info' and 'log_prefix' args to cardops updatecsd() method - otp_gen_challenge() noted as cryptocard-specific with quirky behavior - otp_challenge_transform() explicitly returns new challenge length - cryptocard.c:cryptocard_challenge(): Remove hardcoded challenge length of 8. Yes, *sync* challenge length must be 8 but challenge might be a different size due to resync with an async challenge. This worked before but became a bug when we changed the user_state 'challenge' field to be the previous (instead of the next) challenge. Modified files: File: radiusd/src/modules/rlm_otp/otp.h; Revision: 1.25; Date: 2005/11/08 08:56:21; Author: fcusack; Lines: (+10 -7) File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revision: 1.59; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+47 -27) File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revision: 1.41; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+25 -18) File: radiusd/src/modules/rlm_otp/otp_rad.h; Revision: 1.4; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+3 -3) File: radiusd/src/modules/rlm_otp/otp_radstate.c; Revision: 1.4; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+22 -36) File: radiusd/src/modules/rlm_otp/otp_rlm.c; Revision: 1.15; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+10 -11) File: radiusd/src/modules/rlm_otp/otp_site.c; Revision: 1.4; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+11 -7) File: radiusd/src/modules/rlm_otp/otp_state.c; Revision: 1.22; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+18 -6) File: radiusd/src/modules/rlm_otp/otp_util.c; Revision: 1.11; Date: 2005/11/08 08:56:22; Author: fcusack; Lines: (+21 -18) File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c; Revision: 1.38; Date: 2005/11/08 08:56:23; Author: fcusack; Lines: (+27 -31) File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h; Revision: 1.37; Date: 2005/11/08 08:56:23; Author: fcusack; Lines: (+16 -14) ===================================================== Log entries ===================================================== Description: On deleting the request list, kill any live threads that are processing the request, and mark the request has having no child pid. We should fix up the thread pool, too, to catch the case of "disappeared" child threads Modified files: File: radiusd/src/main/request_list.c; Revision: 1.69; Date: 2005/11/07 19:46:30; Author: aland; Lines: (+13 -2) ------------------------------- Description: add sratch3 back to user_state, to hold csd offset Modified files: File: radiusd/src/modules/rlm_otp/otp.h; Revision: 1.24; Date: 2005/11/08 04:02:20; Author: fcusack; Lines: (+2 -1) ===================================================== Summary of modified files ===================================================== File: radiusd/src/main/request_list.c Revisions: 1.69 Authors: aland (+13 -2) ------------------------------- File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c Revisions: 1.38, 1.37 Authors: fcusack (+27 -31), fcusack (+12 -12) ------------------------------- File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h Revisions: 1.37, 1.36 Authors: fcusack (+16 -14), fcusack (+7 -7) ------------------------------- File: radiusd/src/modules/rlm_otp/otp.h Revisions: 1.25, 1.24, 1.23 Authors: fcusack (+10 -7), fcusack (+2 -1), fcusack (+4 -4) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_cardops.c Revisions: 1.59, 1.58 Authors: fcusack (+47 -27), fcusack (+30 -30) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_cardops.h Revisions: 1.41, 1.40 Authors: fcusack (+25 -18), fcusack (+7 -7) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_rad.h Revisions: 1.4 Authors: fcusack (+3 -3) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_radstate.c Revisions: 1.4 Authors: fcusack (+22 -36) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_rlm.c Revisions: 1.15 Authors: fcusack (+10 -11) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_site.c Revisions: 1.4 Authors: fcusack (+11 -7) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_state.c Revisions: 1.22 Authors: fcusack (+18 -6) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_util.c Revisions: 1.11, 1.10 Authors: fcusack (+21 -18), fcusack (+26 -26) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_x99.c Revisions: 1.6 Authors: fcusack (+3 -3) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl
On November 8, 2005 3:02:58 AM -0600 Automatic cvs log generator <cparker@starnetusa.net> wrote:
Author: aland File: radiusd/src/main/request_list.c; Revisions: 1.69 ... Description: On deleting the request list, kill any live threads that are processing the request, and mark the request has having no child pid.
We should fix up the thread pool, too, to catch the case of "disappeared" child threads ...
|> if (request->child_pid != NO_SUCH_CHILD_PID) { |> pthread_kill(request->child_pid, SIGKILL); |> request->child_pid = NO_SUCH_CHILD_PID; |> } Sorry to second guess you, especially when I don't know the code path, but is such a drastic measure needed? My worry would be that a thread processing a request has some resource allocated or open, which would then leak. If the kill is safe, perhaps a comment indicating the circumstance would be appropriate, just for the sake of code browsing. -frank
Frank Cusack <fcusack@fcusack.com> wrote:
Sorry to second guess you, especially when I don't know the code path, but is such a drastic measure needed? My worry would be that a thread processing a request has some resource allocated or open, which would then leak.
... just before the process exits.
If the kill is safe, perhaps a comment indicating the circumstance would be appropriate, just for the sake of code browsing.
The only time rl_deinit() should be called is when the server is exiting. Going forward, we need a separate global list of REQUEST's that are "live", and can't be deleted for a period of time. This will help when threads get blocked, too. Alan DeKok.
participants (3)
-
Alan DeKok -
Automatic cvs log generator -
Frank Cusack