From owner-freebsd-hackers@freebsd.org Wed Jan 2 16:37:36 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF8361427A8D for ; Wed, 2 Jan 2019 16:37:36 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8EB495029; Wed, 2 Jan 2019 16:37:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 137E8B14CE; Wed, 2 Jan 2019 17:37:32 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7RGpNdGIeqM; Wed, 2 Jan 2019 17:37:31 +0100 (CET) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 04B01B14C5; Wed, 2 Jan 2019 17:37:31 +0100 (CET) Subject: Re: Using kqueue with aio_read/write To: Alan Somers Cc: FreeBSD Hackers References: <8753521a-4555-ec2a-5efc-dee2660b4d9b@digiware.nl> <969d9a38-d3dd-78d0-c974-ba14ec4747db@digiware.nl> <016fda76-8f02-ca62-af7d-062262bd4a09@digiware.nl> From: Willem Jan Withagen Message-ID: <7847cb4f-5957-3145-7ffb-dc0b702f32fd@digiware.nl> Date: Wed, 2 Jan 2019 17:37:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 16:37:37 -0000 On 02/01/2019 15:59, Alan Somers wrote: > On Wed, Jan 2, 2019 at 5:53 AM Willem Jan Withagen wrote: >> On 02/01/2019 03:23, Alan Somers wrote: >>> On Tue, Jan 1, 2019 at 6:56 PM Willem Jan Withagen wrote: >>>> On 28/12/2018 02:47, Alan Somers wrote: >>>>> On Thu, Dec 27, 2018 at 6:15 PM Willem Jan Withagen wrote: >>>>>> Hi, >>>>>> >>>>>> Im trying to understand why I cannot get so code to work. >>>>>> This is the smallest extract I can make to show my problem. >>>>>> >>>>>> I would expect the kevent() call to return every timeo tick. >>>>>> Even if I tell it NOT to time-out I get these spurts of errors >>>>>> >>>>>> Since there is nothing to trigger the AIO-event, I would expect kqueue >>>>>> to hold indefinitly. >>>>>> >>>>>> But it does not generate anything other than errors >>>>>> And instead it repeatedly complains that there is a permission error: >>>>>> get_events_kevent: EV_Error(1) kevent(): Operation not permitted >>>>>> >>>>>> But I'm not getting where that would the case... >>>>>> >>>>>> Surely a pilot error, but I do overlook it al the time. >>>>>> So suggestions are welcome. >>>>>> >>>>>> Thanx, >>>>>> --WjW >>>>>> >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> >>>>>> #define BUFFER_SIZE 512 >>>>>> #define MAX_EVENTS 32 >>>>>> >>>>>> #define FILENAME "/tmp/aio_test" >>>>>> char filename[256]; >>>>>> int fd; >>>>>> int done = 0; >>>>>> >>>>>> void get_events_kevent(int fd, int kq) >>>>>> { >>>>>> printf("get_events function fd = %d, kq = %d\n", fd, kq); >>>>>> int i = 0, errcnt = 0, err, ret, reterr, rev; >>>>>> int search = 1; >>>>>> >>>>>> int timeout_ms = 10; >>>>>> struct timespec timeo = { >>>>>> timeout_ms / 1000, >>>>>> (timeout_ms % 1000) * 1000 * 1000 >>>>>> }; >>>>>> struct kevent filter[16]; >>>>>> struct kevent changed[16]; >>>>>> >>>>>> EV_SET(&filter[0], fd, EVFILT_AIO, >>>>>> EV_ADD, >>>>>> 0, 0, 0 ); >>>>> This is the first problem. There's no need to explicitly set >>>>> EVFILT_AIO on the kqueue. It gets set by the aio_read(2) or similar >>>>> syscall. And this invocation wouldn't be correct anyway, because for >>>>> AIO the ident field refers to the address of the struct aiocb, not the >>>>> file descriptor. If the only events you care about are AIO, then you >>>>> can pass NULL as the filter argument to kevent. I suspect this is the >>>>> cause of your problem. The kernel probably thinks you're trying to >>>>> register for an aiocb that's outside of your address space or >>>>> something like that. >>>>> >>>>> >>>>>> while (!done) { >>>>>> printf("+"); >>>>>> rev = kevent(kq, filter, 1, changed, 16, 0); //&timeo); >>>>>> if (rev < 0) { >>>>>> perror("kevent error"); >>>>>> } else if (rev == 0) { >>>>>> printf("T"); >>>>>> } else { >>>>>> printf("rev(%d)\n", rev); >>>>>> if (changed[0].flags == EV_ERROR) { >>>>>> errno = changed[0].data; >>>>>> printf( "%s: EV_Error(%d) kevent(): %s\n", __func__, errno, >>>>>> strerror(errno)); >>>>>> memset(&changed[0], 0, sizeof(struct kevent)); >>>>>> } else { >>>>>> err = aio_error((struct aiocb*)changed[0].udata); >>>>> No need to call aio_error(2) after kevent(2) returns. You can go >>>>> straight to aio_return. aio_error shouldn't hurt, but it isn't >>>>> necessary. >>>> According to kevent(2) calling kevent can return errors on the called >>>> aio_calls. >>>> It then returns with EV_ERROR in flags, and errno is stored in the >>>> event.data. >>>> >>>> But what would be going on when the event's flag contains EV_ERROR but >>>> event's data is still 0??? >>>> >>>> the udata field still seems to point to the aio data that was passed >>>> into the aio block when calling aio_read(). >>>> >>>> Should I ignore this as a non-error? >>>> >>>> --WjW >>> Are you sure you bzero()ed your aiocb before initializing it? Any >>> stack garbage that was present in its >>> aio_sigevent.sigev_notify_kevent_flags field will be dutifully copied >>> into the returned kevent. And in any case, the definitive way to get >>> the final status of a completed aio operation is with aio_return. >> That seems to help in getting things clear... >> >> -13> 2019-01-02 13:32:31.834 dc15a80 1 bdev:327 paio >> get_next_completed processing event i = 0 aio_return(22) (22) Invalid >> argument >> >> Disadvantage is that it is not clear yet which of the many arguments >> that is? >> >> --WjW > It could be failing for any reason that read(2) can fail. Or, the > iocb might not be complete. aio_error(2) would tell you. One common > problem is if you allocate the iocb on the stack and accidentally move > it after calling aio_read(). That's bitten me before. Well the main part that is biting here, is that it sort of has to be compatible with what Sage ea. have cooked up to manage the iov/iocb/aiocb  stuff. And I need to do it with keeping the Linux code working as well. And the real mess was to sort out get the correct pointer into the aio_write() and find it back in get_next_event() to finish that. But it looks like I've sorted that part now. Get_next_event() actually now finds the correct aiocb. and I can aio_return() without errors. Now the next trick is going to take it of the list off outstanding aio's in the ceph-list. That still asserts somewhere. But slowly getting there. Just running my head into a wall at some times. --WjW