[SCM] Samba Shared Repository - branch v3-5-test updated - release-4-0-0alpha8-1366-g55288bb
Jeremy Allison
jra at samba.org
Thu Sep 3 09:09:39 MDT 2009
The branch, v3-5-test has been updated
via 55288bb0b4468b66ecd07e5bd2440d37be7b3c59 (commit)
via 5dd5c5854a8081b9266ede8c29966151885d9d1e (commit)
from 38995d7cbb0c3143eb1fea0215863321349c7bbe (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=v3-5-test
- Log -----------------------------------------------------------------
commit 55288bb0b4468b66ecd07e5bd2440d37be7b3c59
Author: Jeremy Allison <jra at samba.org>
Date: Thu Sep 3 07:40:48 2009 -0700
Hopefully last part of the fix for bug 6651 - smbd SIGSEGV when breaking oplocks.
This one is subtle. There is a race condition where a signal can be
queued for oplock break, and then the file can be closed by the client
before the signal can be processed. Currently if this occurs we panic
(we can't match an incoming signal fd with a fsp pointer). Simply log
the error (at debug level 10 right now, might be too much) and then
return without processing the break request. It looks like there is
another race condition with this fix, but here's why it won't happen.
If the signal was pending (caused by a kernel oplock break from a
local file open), and the client closed the file and then re-opened
another file which happened to use the same file descriptor as the
file just closed, then theoretically the oplock break requests could
be processed on the wrong fd. Here's why this should be very rare..
Processing a pending signal always take precedence over an incoming
network request, so as long as the client close request is non-chained
then the break signal should always be harmlessly processed *before*
the open can be called. If the open is chained onto the close, and
the fd on the new open is the same as the old closed fd, then it's
possible this race will occur. However, all that will happen is that
we'll lose the oplock on this file. A shame, but not a fatal event.
Jeremy.
commit 5dd5c5854a8081b9266ede8c29966151885d9d1e
Author: Jeremy Allison <jra at samba.org>
Date: Thu Sep 3 07:38:21 2009 -0700
Another part of the fix for bug 6651 - smbd SIGSEGV when breaking oplocks.
SA_INFO_QUEUE_COUNT *MUST* be a power of 2, in order for the ring buffer
wrap to work correctly at the 32 bit boundary. Thanks to Petr
Vandrovec <petr at vandrovec.name> for this.
-----------------------------------------------------------------------
Summary of changes:
lib/tevent/tevent_signal.c | 8 ++++++--
source3/smbd/oplock_linux.c | 4 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
Changeset truncated at 500 lines:
diff --git a/lib/tevent/tevent_signal.c b/lib/tevent/tevent_signal.c
index b329f8c..ef9c0cf 100644
--- a/lib/tevent/tevent_signal.c
+++ b/lib/tevent/tevent_signal.c
@@ -32,8 +32,12 @@
#define NUM_SIGNALS 64
-/* maximum number of SA_SIGINFO signals to hold in the queue */
-#define SA_INFO_QUEUE_COUNT 100
+/* maximum number of SA_SIGINFO signals to hold in the queue.
+ NB. This *MUST* be a power of 2, in order for the ring buffer
+ wrap to work correctly. Thanks to Petr Vandrovec <petr at vandrovec.name>
+ for this. */
+
+#define SA_INFO_QUEUE_COUNT 64
struct sigcounter {
uint32_t count;
diff --git a/source3/smbd/oplock_linux.c b/source3/smbd/oplock_linux.c
index 535e809..c60c745 100644
--- a/source3/smbd/oplock_linux.c
+++ b/source3/smbd/oplock_linux.c
@@ -99,8 +99,8 @@ static void linux_oplock_signal_handler(struct tevent_context *ev_ctx,
fsp = file_find_fd(fd);
if (fsp == NULL) {
- DEBUG(0,("linux_oplock_signal_handler: failed to find fsp for file fd=%d\n", fd ));
- smb_panic("linux_oplock_signal_handler\n");
+ DEBUG(0,("linux_oplock_signal_handler: failed to find fsp for file fd=%d (file was closed ?)\n", fd ));
+ return;
}
break_kernel_oplock(smbd_messaging_context(), fsp);
}
--
Samba Shared Repository
More information about the samba-cvs
mailing list