I have been working for a while on making a distributed file system
that runs on Linux to become "lease aware".  I have been using
advanced versions of proposed Linux modifications that allow a file
system to have a "setlease" file operations method.  My primary focus
in this work was to allow Samba OpLocks to function properly with my
file system.

 I have been using a version of Linux-2.6.19 that I modified to add
the lease support.

 In the course of this work I have run up against what appears to be a
Linux problem that prevents the delivery of a signal to the Samba
server.

 A Samba server running on Linux, supporting Oplocks for its clients,
will establish a lease for each OpLock that it grants to a client.
Then when some other activity in the file system occurs, such as
another application opening a file with an OpLock (and therefore a
lease), a call is made to Linux routine, __break_lease() and this is
supposed to result in a signal being delivered to the process which
established the lease.  Receipt of such a signal should cause the
process to release the lease.

 What I see is that the delivery of such signals appears to be
unreliable.  The problem occurs in routine, sigio_perm(), which often
returns a value which then leads to the signal not being delivered.
The entire sequence of calls leading to this failure is as follows:

    __break_lease() => lease_break_callback() => kill_fasync() =>
__kill_fasync() => send_sigio() => send_sigio_to_task() =>
sigio_perm()

  Routine, sigio_perm() is very simple:

  static inline int sigio_perm(struct task_struct *p,
                              struct fown_struct *fown, int sig)
  {
          return (((fown->euid == 0) ||
                   (fown->euid == p->suid) || (fown->euid == p->uid) ||
                   (fown->uid == p->suid) || (fown->uid == p->uid)) &&
                  !security_file_send_sigiotask(p, fown, sig));
 }

 And the reason that this is failing to send the signal is that the
values for fown->euid and fown->uid are both 500, consistent with a
user mode client, and the values of p->uid and p->suid are both zero,
consistent with a root process, i.e. the smbd.

 Being a relative neophyte in these questions, I am not sure what the
above code is trying to prevent.  However for my purposes I achieved
behavior that I could live with by modifying the above in the
following way:

  static inline int sigio_perm(struct task_struct *p,
                              struct fown_struct *fown, int sig)
   {
           return (((fown->euid == 0) || (p->suid == 0) || (p->uid == 0) ||
                    (fown->euid == p->suid) || (fown->euid == p->uid) ||
                    (fown->uid == p->suid) || (fown->uid == p->uid)) &&
                   !security_file_send_sigiotask(p, fown, sig));
 }

 That is, I added  "(p->suid == 0) || (p->uid == 0) ||" to the set of
conditions to be tested.  I am not sure of the side-effects that this
might cause, but for me at least, this resolved my immediate problem.

 I would appreciate it if someone more knowledgeable could comment on
this and possibly look into what apears to be a problem.

 - Robert Rappaport
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html