Fix segfault when interrupting fapolicyd startup

[rmetrich]

In non-daemon mode, hitting Ctrl-C while fapolicyd initializes leads to getting 2 segfaults:
- first one in term_handler() because q is not initialized yet
- then one in coredump_handler() because m is not initialized yet

Reproducer:

# fapolicyd --debug
[...]
01/22/26 10:48:37 [ INFO ]: Loading rpmdb backend
^CSegmentation fault (core dumped)

GDB shows:

   (gdb) bt
    #0  mlist_first (m=m@entry=0x0) at daemon/mounts.c:86  <<<<< SECOND SEGFAULT
    #1  0x00005627e02de9ec in unmark_fanotify (m=0x0) at daemon/notify.c:258
    #2  0x00005627e02dda13 in coredump_handler (sig=11) at daemon/fapolicyd.c:336
    #3  coredump_handler (sig=11) at daemon/fapolicyd.c:333
    #4  <signal handler called>
    #5  __new_sem_post (sem=0x20) at sem_post.c:36         <<<<< FIRST SEGFAULT
    #6  <signal handler called>
    #7  __recvmsg_syscall (flags=0, msg=0x7ffe93e00350, fd=6) at ../sysdeps/unix/sysv/linux/recvmsg.c:27
    #8  __libc_recvmsg (fd=6, msg=msg@entry=0x7ffe93e00350, flags=flags@entry=0)
        at ../sysdeps/unix/sysv/linux/recvmsg.c:41
    #9  0x00005627e02eef82 in rpm_load_list (conf=<optimized out>) at library/rpm-backend.c:260
    #10 0x00005627e02ecc02 in backend_load (conf=conf@entry=0x5627e02fa0e0 <config>) at library/backend-manager.c:152
    #11 0x00005627e02e21c0 in init_database (config=config@entry=0x5627e02fa0e0 <config>) at library/database.c:1440
    #12 0x00005627e02db599 in main (argc=<optimized out>, argv=<optimized out>) at daemon/fapolicyd.c:1053
   ~~~

[stevegrubb]

This looks like it contains another patch already merged.

In general, I would fix this in the function that crashes and not the call of the function. Typically at the beginning of a function you would test for NULL and return.

[rmetrich]

This looks like it contains another patch already merged.

In general, I would fix this in the function that crashes and not the call of the function. Typically at the beginning of a function you would test for NULL and return.

Yes we could but since it's a rare condition I think it's better to not check constantly q or m in the functions using it. It's better for performances of fapolicyd.

[stevegrubb]

Neither of these are on the hot path. Just check the value on entry and we're good to go.

[rmetrich]

Neither of these are on the hot path. Just check the value on entry and we're good to go.

OK, done.

[stevegrubb]

Thanks!