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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
