Skip to contentSkip to conversation

udevadm settle (udev 146) & pam-mount (1.32) via mount (util-linux-ng

PATCH Christian P. Schmidt 2 participants 4 messages Oct 29, 2009 – Nov 2, 2009

lore
Share & tools
lore
#0 lore raw

Hi there,

I'm trying to figure out some interaction between pam-mount and udev which, for some time now, fail to log me in.

First of, the invocation:

+-login---mount---mount.crypto_LUKS---cryptsetup---udevadm

After the getty replaces itself with login the pam module pam_mount calls mount. This in turn determines that the partition to be mounted is LUKS encrypted, and calls cryptsetup. Cryptsetup receives the password, unlocks the partition, and calls udevadm settle in order to avoid some problems in interaction with LVM.

udevadm settle never returns.

strace reveals why:

rt_sigaction(SIGALRM, {0x40cf10, [], SA_RESTORER, 0x7f03082606d0}, NULL,
8) = 0
rt_sigaction(SIGUSR1, {0x40cf10, [], SA_RESTORER, 0x7f03082606d0}, NULL,
8) = 0

alarm(180)                              = 0
getuid()                                = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 4

rt_sigprocmask(SIG_BLOCK, [USR1 ALRM], ~[TRAP KILL SEGV STOP RTMIN RT_1], 8) = 0
sendto(4, "udev-146\0\0\0\0\0\0\0\0\352\35\255\336\10\0\0\0\0\0\0\0\0\0\0\0\0"..., 280, 0, {sa_family=AF_FILE, path=@"/org/kernel/udev/udevd"...}, 25) = 280 rt_sigsuspend(~[TRAP KILL SEGV STOP RTMIN RT_1] <unfinished ...>

and the code:

        /* guarantee that the udev daemon isn't pre-processing */
        if (getuid() == 0) {
                struct udev_ctrl *uctrl;

                uctrl = udev_ctrl_new_from_socket(udev,
UDEV_CTRL_SOCK_PATH);
                if (uctrl != NULL) {
                        sigset_t mask, oldmask;

                        sigemptyset(&mask);
                        sigaddset(&mask, SIGUSR1);
                        sigaddset(&mask, SIGALRM);
                        sigprocmask(SIG_BLOCK, &mask, &oldmask);
                        if (udev_ctrl_send_settle(uctrl) > 0)
                                sigsuspend(&oldmask);
                        sigprocmask(SIG_SETMASK, &oldmask, NULL);
                        udev_ctrl_unref(uctrl);
                }
        }

The problem here is that SIGUSR1 and SIGALRM are both blocked in oldmask already, and never reach udevadm. No care is ever taken to ensure those signals are not blocked.

The attached patch is one of the many possible ways to rectify the solution.

Regards,
Christian

udev/udevadm-settle.c +2 -0
diff -ur udev-146/udev/udevadm-settle.c udev-146.new/udev/udevadm-settle.c
@@ -171,6 +171,8 @@
 			sigaddset(&mask, SIGUSR1);
 			sigaddset(&mask, SIGALRM);
 			sigprocmask(SIG_BLOCK, &mask, &oldmask);
+			sigdelset(&oldmask, SIGUSR1);
+			sigdelset(&oldmask, SIGALRM);
 			if (udev_ctrl_send_settle(uctrl) > 0)
 				sigsuspend(&oldmask);
 			sigprocmask(SIG_SETMASK, &oldmask, NULL);
#1 lore raw

Re: udevadm settle (udev 146) & pam-mount (1.32) via mount

Quoted 5 lines · Christian P. Schmidt

The problem here is that SIGUSR1 and SIGALRM are both blocked in oldmask already, and never reach udevadm. No care is ever taken to ensure those signals are not blocked.

The attached patch is one of the many possible ways to rectify the solution.

Oh, I see. I guess, we should just unblock these both signals right at the time we install the signal handler?

Thanks,
Kay

#2 lore raw
In reply to Christian P. Schmidt
Quoted 10 lines · Kay Sievers
Quoted 5 lines · Christian P. Schmidt

The problem here is that SIGUSR1 and SIGALRM are both blocked in oldmask already, and never reach udevadm. No care is ever taken to ensure those signals are not blocked.

The attached patch is one of the many possible ways to rectify the solution.

Oh, I see. I guess, we should just unblock these both signals right at the time we install the signal handler?

That would probably be the most correct solution, indeed.

Regards,
Christian

Quoted 2 lines

Thanks,
Kay

#3 lore raw

Re: udevadm settle (udev 146) & pam-mount (1.32) via mount

In reply to Christian P. Schmidt
Quoted 7 lines · Christian Schmidt
Quoted 6 lines · Kay Sievers
Quoted 4 lines · Christian P. Schmidt

The problem here is that SIGUSR1 and SIGALRM are both blocked in oldmask already, and never reach udevadm. No care is ever taken to ensure those signals are not blocked.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

The attached patch is one of the many possible ways to rectify the solution.

Oh, I see. I guess, we should just unblock these both signals right at the time we install the signal handler?

That would probably be the most correct solution, indeed.

I've added this now:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h¼3ec7bd45814a75845529fd0aca5c5a9d9f0c14

Thanks,
Kay