[PATCH] Convert Samba to OFD locking.
Simo
s at ssimo.org
Thu May 19 17:17:32 UTC 2016
Feature testing is compketely different from correctness testing. I agree we shouldn't do the latter. But the former is not hard in this case, and would make our code actually more robust.
On May 19, 2016 12:16:09 PM EDT, Jeremy Allison <jra at samba.org> wrote:
>On Wed, May 18, 2016 at 02:42:20PM -0700, Jeremy Allison wrote:
>> From eb7f30b606a006cca80f4de990bb1c9e620a7f97 Mon Sep 17 00:00:00
>2001
>> From: Jeremy Allison <jra at samba.org>
>> Date: Thu, 12 May 2016 21:46:50 +0200
>> Subject: [PATCH 10/10] s3: wscript: Add checks for open file
>description
>> locks.
>>
>> We now use these if available.
>>
>> Signed-off-by: Jeremy Allison <jra at samba.org>
>> ---
>> source3/wscript | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/source3/wscript b/source3/wscript
>> index 3b6f8a4..51c1542 100644
>> --- a/source3/wscript
>> +++ b/source3/wscript
>> @@ -1089,6 +1089,22 @@ syscall(SYS_setgroups32, 0, NULL);
>> execute=True,
>> msg='Checking whether fcntl locking is available')
>>
>> + conf.CHECK_CODE('''
>> + struct flock lck = {
>> + .l_whence = SEEK_SET,
>> + .l_type = F_WRLCK,
>> + .l_start = 0,
>> + .l_len = 1,
>> + .l_pid = 0,
>> + };
>> + int ret = fcntl(0, F_OFD_SETLK, &lck);
>> + int ret1 = fcntl(0, F_OFD_SETLKW, &lck);
>> + int ret2 = fcntl(0, F_OFD_GETLK, &lck);
>> + ''',
>> + 'HAVE_OFD_LOCKS',
>> + msg="Checking whether fcntl lock supports open file
>description locks",
>> + headers='unistd.h sys/types.h sys/stat.h fcntl.h')
>> +
>> # glibc up to 2.3.6 had dangerously broken posix_fallocate(). DON'T
>USE IT.
>> if not conf.CHECK_CODE('''
>> #define _XOPEN_SOURCE 600
>> --
>> 2.8.0.rc3.226.g39d4020
>
>Just to clarify with the people who wanted runtime checks,
>I'm trying to reduce the complexity of runtime code paths.
>
>If for every new system feature we have to not only check
>for existence (which is reasonable) but to check at runtime
>if it *actually works* then we're going to end up with code
>that's really difficult to maintain and support in the long
>run.
>
>The reason I want to move away from this comes from the
>experience with code inside tevent that tries to cope with broken
>kernel
>epoll implementations by building a dynamic environment that
>can switch over to the poll() model on failure.
>
>Even to test that this code worked required an internal
>test framework to tevent_epoll that can simulate a 50%
>system call failure rate.
>
>And there's also the issue of trying to explain code
>like this:
>
>static int std_event_loop_once(struct tevent_context *ev, const char
>*location)
>{
> void *glue_ptr = talloc_parent(ev->ops);
> struct std_event_glue *glue =
> talloc_get_type_abort(glue_ptr,
> struct std_event_glue);
> int ret;
>
> ret = glue->epoll_ops->loop_once(ev, location);
> if (glue->epoll_ops != NULL) {
> /* No fallback */
> return ret;
> }
>
> if (!glue->fallback_replay) {
> /*
> * The problem happened while modifying an event.
> * An event handler was triggered in this case
> * and there is no need to call loop_once() again.
> */
> return ret;
> }
>
> return glue->poll_ops->loop_once(ev, location);
>}
>
>Note that we indirect glue->epoll_ops->loop_once, *then*
>we check it for NULL.
>
>Now this code is perfectly correct (I had the pleasure of
>having to explain this to a Googler who was utterly *convinced*
>that this was a crash bug), but outside of the people who wrote and
>maintain it, it's utterly incomprehensible.
>
>This is where runtime checks for features lead us.
>
>I'd rather not go there again :-).
>
>Cheers,
>
> Jeremy.
--
Simo.
Sent from my mobile device. Please excuse my brevity.
More information about the samba-technical
mailing list