lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 10 Dec 2022 09:05:02 -0700
From:   Jens Axboe <>
To:     Willy Tarreau <>
Cc:     Linus Torvalds <>,
        netdev <>,
        "" <>
Subject: Re: [GIT PULL] Add support for epoll min wait time

On 12/10/22 8:58?AM, Willy Tarreau wrote:
> Hi Jens,
> On Sat, Dec 10, 2022 at 08:36:11AM -0700, Jens Axboe wrote:
>> Hi Linus,
>> I've had this done for months and posted a few times, but little
>> attention has been received.
> I personally think this is particularly cool, for having faced the
> same needs in the past. I'm just wondering how long we'll avoid the
> need for marking certain FDs as urgent (i.e. for inter-thread wakeup)
> which would bypass the min delay.

Thanks! No opinion on urgent fds, it's not something I have looked

> I'm just seeing something a bit odd in this series:
>> ----------------------------------------------------------------
>> epoll-min_ts-2022-12-08
>> ----------------------------------------------------------------
>> Jens Axboe (8):
>>       eventpoll: cleanup branches around sleeping for events
>>       eventpoll: don't pass in 'timed_out' to ep_busy_loop()
>>       eventpoll: split out wait handling
>>       eventpoll: move expires to epoll_wq
>>       eventpoll: move file checking earlier for epoll_ctl()
>>       eventpoll: add support for min-wait
>>       eventpoll: add method for configuring minimum wait on epoll context
>>       eventpoll: ensure we pass back -EBADF for a bad file descriptor
> This last patch fixes a bug introduced by the 5th one. Why not squash it
> instead of purposely introducing a bug then its fix ? Or maybe it was
> just overlooked when you sent the PR ?

I didn't want to rebase it, so I just put the fix at the end. Not that
important imho, only issue there was an ltp case getting a wrong error
value. Hence didn't deem it important enough to warrant a rebase.

Jens Axboe

Powered by blists - more mailing lists