[PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[Neil Brown]

I have a situation where rpc.gssd appears to not be working.
Mount attempts which need to communicate with it block.

I've narrowed down the problem to that fact that all realtime signals
have been blocked.  This means that DNOTIFY_SIGNAL (which is a
realtime signal) is never delivered, so gssd never rescans the
rpc_pipe/nfs directory.

I haven't figured out why the signals are blocked yet, but having
rpc.gssd fail mysteriously in that situation isn't pleasant.

So I wonder what people think of the following patch.  It simply
unblocks the signal.  Alternately we can check if it is blocked and
warn - I'm not really sure of the significance of blocking all these
signals.  Maybe it's wrong to just unblock them.


As an aside, maybe we could change gssd_run to use "ppoll" rather than
"poll".  Then it would not have to wake up every 500msec to see if it
missed a signal. We would probably have to check kernel version was at
least 2.6.16....

NeilBrown



diff --git a/utils/gssd/gssd_main_loop.c b/utils/gssd/gssd_main_loop.c
index 84f04e9..b9f3a06 100644
--- a/utils/gssd/gssd_main_loop.c
+++ b/utils/gssd/gssd_main_loop.c
@@ -99,6 +99,7 @@ gssd_run()
 	int			ret;
 	struct sigaction	dn_act;
 	int			fd;
+	sigset_t		set;
 
 	/* Taken from linux/Documentation/dnotify.txt: */
 	dn_act.sa_sigaction = dir_notify_handler;
@@ -106,6 +107,11 @@ gssd_run()
 	dn_act.sa_flags = SA_SIGINFO;
 	sigaction(DNOTIFY_SIGNAL, &dn_act, NULL);
 
+	/* just in case the signal is blocked... */
+	sigemptyset(&set);
+	sigaddset(&set, DNOTIFY_SIGNAL);
+	sigprocmask(SIG_UNBLOCK, &set, NULL);
+
 	if ((fd = open(pipefs_nfsdir, O_RDONLY)) == -1) {
 		printerr(0, "ERROR: failed to open %s: %s\n",
 			 pipefs_nfsdir, strerror(errno));

Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[Kevin Coffman]

Hi Neil,
I inherited the signal stuff, so my understanding probably isn't any
better than yours.  I won't be able to look closer at this until
Wednesday.  Meanwhile, maybe someone else has a better understanding.

K.C.

On Mon, Nov 10, 2008 at 5:29 PM, Neil Brown <neilb@suse.de> wrote:
>
> I have a situation where rpc.gssd appears to not be working.
> Mount attempts which need to communicate with it block.
>
> I've narrowed down the problem to that fact that all realtime signals
> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
> realtime signal) is never delivered, so gssd never rescans the
> rpc_pipe/nfs directory.
>
> I haven't figured out why the signals are blocked yet, but having
> rpc.gssd fail mysteriously in that situation isn't pleasant.
>
> So I wonder what people think of the following patch.  It simply
> unblocks the signal.  Alternately we can check if it is blocked and
> warn - I'm not really sure of the significance of blocking all these
> signals.  Maybe it's wrong to just unblock them.
>
>
> As an aside, maybe we could change gssd_run to use "ppoll" rather than
> "poll".  Then it would not have to wake up every 500msec to see if it
> missed a signal. We would probably have to check kernel version was at
> least 2.6.16....
>
> NeilBrown
>
>
>
> diff --git a/utils/gssd/gssd_main_loop.c b/utils/gssd/gssd_main_loop.c
> index 84f04e9..b9f3a06 100644
> --- a/utils/gssd/gssd_main_loop.c
> +++ b/utils/gssd/gssd_main_loop.c
> @@ -99,6 +99,7 @@ gssd_run()
>        int                     ret;
>        struct sigaction        dn_act;
>        int                     fd;
> +       sigset_t                set;
>
>        /* Taken from linux/Documentation/dnotify.txt: */
>        dn_act.sa_sigaction = dir_notify_handler;
> @@ -106,6 +107,11 @@ gssd_run()
>        dn_act.sa_flags = SA_SIGINFO;
>        sigaction(DNOTIFY_SIGNAL, &dn_act, NULL);
>
> +       /* just in case the signal is blocked... */
> +       sigemptyset(&set);
> +       sigaddset(&set, DNOTIFY_SIGNAL);
> +       sigprocmask(SIG_UNBLOCK, &set, NULL);
> +
>        if ((fd = open(pipefs_nfsdir, O_RDONLY)) == -1) {
>                printerr(0, "ERROR: failed to open %s: %s\n",
>                         pipefs_nfsdir, strerror(errno));
>
>

Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[J. Bruce Fields]

On Tue, Nov 11, 2008 at 09:29:29AM +1100, Neil Brown wrote:
> 
> I have a situation where rpc.gssd appears to not be working.
> Mount attempts which need to communicate with it block.
> 
> I've narrowed down the problem to that fact that all realtime signals
> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
> realtime signal) is never delivered, so gssd never rescans the
> rpc_pipe/nfs directory.
> 
> I haven't figured out why the signals are blocked yet, but having
> rpc.gssd fail mysteriously in that situation isn't pleasant.
> 
> So I wonder what people think of the following patch.  It simply
> unblocks the signal.  Alternately we can check if it is blocked and
> warn - I'm not really sure of the significance of blocking all these
> signals.  Maybe it's wrong to just unblock them.

So we don't know what it is that's doing the blocking?

> As an aside, maybe we could change gssd_run to use "ppoll" rather than
> "poll".  Then it would not have to wake up every 500msec to see if it
> missed a signal. We would probably have to check kernel version was at
> least 2.6.16....

Yes. (What does glibc itself do in the ppoll library call if the kernel
doesn't support it?)

--b.

> diff --git a/utils/gssd/gssd_main_loop.c b/utils/gssd/gssd_main_loop.c
> index 84f04e9..b9f3a06 100644
> --- a/utils/gssd/gssd_main_loop.c
> +++ b/utils/gssd/gssd_main_loop.c
> @@ -99,6 +99,7 @@ gssd_run()
>  	int			ret;
>  	struct sigaction	dn_act;
>  	int			fd;
> +	sigset_t		set;
>  
>  	/* Taken from linux/Documentation/dnotify.txt: */
>  	dn_act.sa_sigaction = dir_notify_handler;
> @@ -106,6 +107,11 @@ gssd_run()
>  	dn_act.sa_flags = SA_SIGINFO;
>  	sigaction(DNOTIFY_SIGNAL, &dn_act, NULL);
>  
> +	/* just in case the signal is blocked... */
> +	sigemptyset(&set);
> +	sigaddset(&set, DNOTIFY_SIGNAL);
> +	sigprocmask(SIG_UNBLOCK, &set, NULL);
> +
>  	if ((fd = open(pipefs_nfsdir, O_RDONLY)) == -1) {
>  		printerr(0, "ERROR: failed to open %s: %s\n",
>  			 pipefs_nfsdir, strerror(errno));
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[NeilBrown]

On Wed, November 12, 2008 6:09 am, J. Bruce Fields wrote:
> On Tue, Nov 11, 2008 at 09:29:29AM +1100, Neil Brown wrote:
>>
>> I have a situation where rpc.gssd appears to not be working.
>> Mount attempts which need to communicate with it block.
>>
>> I've narrowed down the problem to that fact that all realtime signals
>> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
>> realtime signal) is never delivered, so gssd never rescans the
>> rpc_pipe/nfs directory.
>>
>> I haven't figured out why the signals are blocked yet, but having
>> rpc.gssd fail mysteriously in that situation isn't pleasant.
>>
>> So I wonder what people think of the following patch.  It simply
>> unblocks the signal.  Alternately we can check if it is blocked and
>> warn - I'm not really sure of the significance of blocking all these
>> signals.  Maybe it's wrong to just unblock them.
>
> So we don't know what it is that's doing the blocking?

That information has just come to hand.  It seems to be kde.
start_kde (or whatever it is called) and all descendants have these
signals blocked.  xfce seems to do the same thing.  gnome doesn't.

So if you start rpc.gssd from a terminal window while logged in via
KDE, it doesn't behave as expected.

>
>> As an aside, maybe we could change gssd_run to use "ppoll" rather than
>> "poll".  Then it would not have to wake up every 500msec to see if it
>> missed a signal. We would probably have to check kernel version was at
>> least 2.6.16....
>
> Yes. (What does glibc itself do in the ppoll library call if the kernel
> doesn't support it?)

Probably tries to fake it and ends up with a racy implementation.  That
is what it does with pselect.

An alternate would be to not use signals at all (generally a very good
idea) by use inotify instead of dnotify.  But that hasn't always worked
either.

Here is a question:  On which kernel did GSS support first become a really
usable option?  If that is sufficiently recent that it includes either
ppoll or inotify-on-rpc_pipe, then we could just use the modern technology
and tell people that rpc.gssd isn't supported on older kernels because
it doesn't really work anyway.  Would that get us anywhere?

Another alternate.  rpc.gssd currently wakes up every 500msec to check
a global variable that might have been set by a signal arriving.
There would be little extra cost if doing a 'stat' of the rpc_pipe/nfs
directory to see if it had changed (is the timestamp updated when a
change happens?).  This would just be one quick syscall.  Then we could
be much less dependent on correct delivery of the signal.  We could even
not use dnotify at all.


NeilBrown

Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[J. Bruce Fields]

On Wed, Nov 12, 2008 at 09:20:20AM +1100, NeilBrown wrote:
> On Wed, November 12, 2008 6:09 am, J. Bruce Fields wrote:
> > On Tue, Nov 11, 2008 at 09:29:29AM +1100, Neil Brown wrote:
> >>
> >> I have a situation where rpc.gssd appears to not be working.
> >> Mount attempts which need to communicate with it block.
> >>
> >> I've narrowed down the problem to that fact that all realtime signals
> >> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
> >> realtime signal) is never delivered, so gssd never rescans the
> >> rpc_pipe/nfs directory.
> >>
> >> I haven't figured out why the signals are blocked yet, but having
> >> rpc.gssd fail mysteriously in that situation isn't pleasant.
> >>
> >> So I wonder what people think of the following patch.  It simply
> >> unblocks the signal.  Alternately we can check if it is blocked and
> >> warn - I'm not really sure of the significance of blocking all these
> >> signals.  Maybe it's wrong to just unblock them.
> >
> > So we don't know what it is that's doing the blocking?
> 
> That information has just come to hand.  It seems to be kde.
> start_kde (or whatever it is called) and all descendants have these
> signals blocked.  xfce seems to do the same thing.  gnome doesn't.
> 
> So if you start rpc.gssd from a terminal window while logged in via
> KDE, it doesn't behave as expected.

Whoops.  I guess I (stupidly?) didn't realize signal masks where
inherited across fork.  So we just need to clear the signal mask at the
very start and we're done?

> >> As an aside, maybe we could change gssd_run to use "ppoll" rather than
> >> "poll".  Then it would not have to wake up every 500msec to see if it
> >> missed a signal. We would probably have to check kernel version was at
> >> least 2.6.16....
> >
> > Yes. (What does glibc itself do in the ppoll library call if the kernel
> > doesn't support it?)
> 
> Probably tries to fake it and ends up with a racy implementation.  That
> is what it does with pselect.
> 
> An alternate would be to not use signals at all (generally a very good
> idea) by use inotify instead of dnotify.  But that hasn't always worked
> either.
> 
> Here is a question:  On which kernel did GSS support first become a really
> usable option?  If that is sufficiently recent that it includes either
> ppoll or inotify-on-rpc_pipe, then we could just use the modern technology
> and tell people that rpc.gssd isn't supported on older kernels because
> it doesn't really work anyway.  Would that get us anywhere?

It looks to me like gss has been usable to some degree since the
beginning of git history (2.6.12-rc2), while the ppoll man page says it
was added in 2.6.16.

> Another alternate.  rpc.gssd currently wakes up every 500msec to check
> a global variable that might have been set by a signal arriving.
> There would be little extra cost if doing a 'stat' of the rpc_pipe/nfs
> directory to see if it had changed (is the timestamp updated when a
> change happens?).  This would just be one quick syscall.  Then we could
> be much less dependent on correct delivery of the signal.  We could even
> not use dnotify at all.

I'd rather just get rid of the 500msec wakeup (if nothing else it's
annoying when you're trying to debug with strace!).  So a wrapper around
ppoll that falls back on polling with poll might be the way to go.

--b.

Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[Steve Dickson]

J. Bruce Fields wrote:
> On Wed, Nov 12, 2008 at 09:20:20AM +1100, NeilBrown wrote:
>> On Wed, November 12, 2008 6:09 am, J. Bruce Fields wrote:
>>> On Tue, Nov 11, 2008 at 09:29:29AM +1100, Neil Brown wrote:
>>>> I have a situation where rpc.gssd appears to not be working.
>>>> Mount attempts which need to communicate with it block.
>>>>
>>>> I've narrowed down the problem to that fact that all realtime signals
>>>> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
>>>> realtime signal) is never delivered, so gssd never rescans the
>>>> rpc_pipe/nfs directory.
>>>>
>>>> I haven't figured out why the signals are blocked yet, but having
>>>> rpc.gssd fail mysteriously in that situation isn't pleasant.
>>>>
>>>> So I wonder what people think of the following patch.  It simply
>>>> unblocks the signal.  Alternately we can check if it is blocked and
>>>> warn - I'm not really sure of the significance of blocking all these
>>>> signals.  Maybe it's wrong to just unblock them.
>>> So we don't know what it is that's doing the blocking?
>> That information has just come to hand.  It seems to be kde.
>> start_kde (or whatever it is called) and all descendants have these
>> signals blocked.  xfce seems to do the same thing.  gnome doesn't.
>>
>> So if you start rpc.gssd from a terminal window while logged in via
>> KDE, it doesn't behave as expected.
> 
> Whoops.  I guess I (stupidly?) didn't realize signal masks where
> inherited across fork.  So we just need to clear the signal mask at the
> very start and we're done?
Neil? Will this work as well? 

This approach seems a bit more straightforward to me... 

steved.

Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[Steve Dickson]

Neil Brown wrote:
> I have a situation where rpc.gssd appears to not be working.
> Mount attempts which need to communicate with it block.
> 
> I've narrowed down the problem to that fact that all realtime signals
> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
> realtime signal) is never delivered, so gssd never rescans the
> rpc_pipe/nfs directory.
> 
> I haven't figured out why the signals are blocked yet, but having
> rpc.gssd fail mysteriously in that situation isn't pleasant.
> 
> So I wonder what people think of the following patch.  It simply
> unblocks the signal.  Alternately we can check if it is blocked and
> warn - I'm not really sure of the significance of blocking all these
> signals.  Maybe it's wrong to just unblock them.
> 
> 
> As an aside, maybe we could change gssd_run to use "ppoll" rather than
> "poll".  Then it would not have to wake up every 500msec to see if it
> missed a signal. We would probably have to check kernel version was at
> least 2.6.16....
> 
Committed...

steved.