From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert Rappaport" Subject: Problem with getting signals delivered to a Samba server Date: Tue, 26 Jun 2007 16:48:42 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: linux-fsdevel@vger.kernel.org Return-path: Received: from ug-out-1314.google.com ([66.249.92.171]:64909 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757748AbXFZUso (ORCPT ); Tue, 26 Jun 2007 16:48:44 -0400 Received: by ug-out-1314.google.com with SMTP id j3so178913ugf for ; Tue, 26 Jun 2007 13:48:43 -0700 (PDT) Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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