From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8BCA2F8EB5 for ; Sat, 25 Jul 2026 15:19:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784992768; cv=none; b=bHhm5MoqKrjJFIQgtAnY37CFiHqbexHJTrCgKnl0wNoZWWLDwWL+tmqKrobXEMuWf8Udw+aGD+dQjqncn9Bk32tgQ56ilzZnZD6Gn/l7b42m1ynU1H/hU4XRuK8suUBgyeP/rC5DVE8WZ5jNNn/yKUZlVaRuUKzKxmjaM1x4tFM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784992768; c=relaxed/simple; bh=Hqv3F1djcLzAo9MDiOdGAro4PDCik3lCiqHwZjMccXA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IKCLDHX9XdQjPcECd5AZEEJC0ZuehCvqA+HI9YLrR5bx97HMxXRTv8dUMNnUJwGJIxB3gX7Ky91Z2nMVlp4Q1yQ6T8a/LD8IGwTeCMPgai5M3njfDUeYXqxm8T9GRVxftvtONvQ+kb81VyTA6z7EfU0flhOAYkVCwBZlEkqzPJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=OTC9si2U; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OTC9si2U" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784992761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aIRORT1kU38zV87IyK7DJhs0FHcTVCf+7F2mJTgH46U=; b=OTC9si2UgiN4Xy74pvdhNXPfTUo5oa5Ab/ryrzqxJB+Ca+D1NUYLOJnrt501b+gjXTb+MM WXSNYRPGUriPV1h6FrGJTpkub22E2ZzKNUGNZNCn/9yssHYFVBAHC5/pSr0WcJr3KDqEp4 ZQTnWx272ySyBRgaZJEVWUc7OqpwHnA= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-523-DBXaVzCgOKin7_KDTum_0g-1; Sat, 25 Jul 2026 11:19:15 -0400 X-MC-Unique: DBXaVzCgOKin7_KDTum_0g-1 X-Mimecast-MFC-AGG-ID: DBXaVzCgOKin7_KDTum_0g_1784992753 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2A6421800587; Sat, 25 Jul 2026 15:19:13 +0000 (UTC) Received: from fedora (unknown [10.44.33.21]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id 1EFBA1954229; Sat, 25 Jul 2026 15:19:08 +0000 (UTC) Received: by fedora (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Sat, 25 Jul 2026 17:19:12 +0200 (CEST) Date: Sat, 25 Jul 2026 17:19:07 +0200 From: Oleg Nesterov To: Breno Leitao , Christian Brauner , Mateusz Guzik , Jens Axboe Cc: Alexander Viro , Jan Kara , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org, Alexey Gladkov Subject: Re: [PATCH 0/1] pipe: only enable the extra wake_up(rd_wait) when epoll is actually used Message-ID: References: Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 On 07/24, Oleg Nesterov wrote: > > On 07/23, Oleg Nesterov wrote: > > > > OK, sashiko has some concerns > > > > https://sashiko.dev/#/patchset/amIqmbbZx3NlzUsX%40redhat.com > > Let me quote: > > Does skipping this wakeup for non-epoll consumers break io_uring? > > Applications polling pipes via io_uring do not attach an eventpoll context, > so pipe->epoll_usage will be false. If a writer writes to an empty pipe, > io_uring receives the wakeup. > > If the writer then writes a second chunk before the first is drained, > anon_pipe_write() observes was_empty == false and > pipe_get_epoll_usage() == false, skipping the waitqueue wakeup. > > Could this cause io_uring to miss events and hang permanently, waiting > for a CQE that will never be emitted for the new data? > > and I am starting to think sashiko is right (damn as always ;) and this > patch does affect/break io_uring. > > Jens, could you confirm? If yes, we need to update the comments in pipe.c > (I've attached 1/1 at the end, so that you can see what this patch does) ... > It seems that IORING_OP_POLL_ADD / IORING_POLL_ADD_MULTI is edge-triggered > by default! Like EPOLL_CTL_ADD / EPOLLET. Yes, sashiko is right. With some help from AI I wrote the simple test-case #include #include #include #include #include #include int main(void) { struct io_uring_params p = {}; int fd, pfd[2]; pipe(pfd); fd = syscall(SYS_io_uring_setup, 2, &p); assert(fd >= 0); void *ring = mmap(0, p.cq_off.cqes + p.cq_entries * sizeof(struct io_uring_cqe), PROT_READ | PROT_WRITE, MAP_SHARED, fd, IORING_OFF_SQ_RING); assert(ring != MAP_FAILED); *(unsigned *)(ring + p.sq_off.array) = 0; *(unsigned *)(ring + p.sq_off.tail) = 1; struct io_uring_sqe *sqes = mmap(0, p.sq_entries * sizeof(*sqes), PROT_READ | PROT_WRITE, MAP_SHARED, fd, IORING_OFF_SQES); assert(sqes != MAP_FAILED); sqes[0].opcode = IORING_OP_POLL_ADD; sqes[0].fd = pfd[0]; sqes[0].len = IORING_POLL_ADD_MULTI; sqes[0].poll32_events = EPOLLIN; syscall(SYS_io_uring_enter, fd, 1, 0, 0, 0, 0); unsigned *cq_head = ring + p.cq_off.head; unsigned *cq_tail = ring + p.cq_off.tail; for (int i = 0; i < 2; ++i) { write(pfd[1], "", 1); syscall(SYS_io_uring_enter, fd, 0, 0, IORING_ENTER_GETEVENTS, 0, 0); assert(*cq_tail == ++*cq_head); } return 0; } with this patch the 2nd assert(*cq_tail == ++*cq_head) fails. And just for the record, another one for epoll #include #include #include int main(void) { int pfd[2], efd; struct epoll_event evt = { .events = EPOLLIN | EPOLLET }; pipe(pfd); efd = epoll_create1(0); epoll_ctl(efd, EPOLL_CTL_ADD, pfd[0], &evt); for (int i = 0; i < 2; ++i) { write(pfd[1], "", 1); assert(epoll_wait(efd, &evt, 1, 0) == 1); } return 0; } I'll try to make V2 later. > And. io_poll_parse_events() doesn't set EPOLLET if IORING_POLL_ADD_LEVEL, but > how is it possible to use IORING_POLL_ADD_LEVEL? io_poll_add_prep() only allows > IORING_POLL_ADD_MULTI in flags? OK, I don't understand this code anyway... OK, I see: d59bd748db0a9 ("io_uring/poll: disable level triggered poll") Oleg.