From nobody Sun Jan 14 17:07:34 2024 X-Original-To: freebsd-threads@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TChY52w0pz56gQH for ; Sun, 14 Jan 2024 17:07:53 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TChY50cVHz4SYZ; Sun, 14 Jan 2024 17:07:53 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2cd33336b32so104232491fa.0; Sun, 14 Jan 2024 09:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705252068; x=1705856868; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=L1+XgSQ7GL3/5CTaus0gQwHH5I5ZuOKws/zAG8i0DyA=; b=RoDnz7wFJeUVu+QjylIYNmMtsSOk03MiZ8hrCaKMKaELq1VpPUa9pNJL2OJ57Y/mPB Qe4VcsJ+ZrS4gpA1CZNi7kQqZR3pF8fwxozXKlS6+QaEvjrgQ6xXCQOnOwB4/qZFyN5F mAsC5Z8bM9u4LUzcteErxDJkzpOsVO8ymerGH/D3zs7zj+EgsW2ni+IxoEUgMho80y4c vzNcSdUMgRr7J+gAG78U9DS63ThPyVN7Jcso+EOawIOMw3gV0H4cpEfFCtVtzrnMqcZV EEYMtjjnPFdVMZXA61lcrAKV3pd8fzFsPM27CoUHqm0cJsn8wxis27bcJCErY41T81sf LX9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705252068; x=1705856868; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L1+XgSQ7GL3/5CTaus0gQwHH5I5ZuOKws/zAG8i0DyA=; b=Cqt/DVDiRrFtcHI8dk1JSGRmBYIciVD0RqAU42TwYCAmjtxOoxLlT8m8OXOLvAW+9S LgoXloH0yP/sxxlcQLmCkZEUhruKb4TjF2+gP4177EZbleGDsfCNRTdPoCGfDE7ZSAYy xszRxKqcsy4UvbKF8kwhpDIVOz8mRKyCr9w43QAQ+I9AgB533XFOB3xAaBGr8c+rG8st BLUGE1HB05FQsBUqRGUw4UFq3KLgUlfqIVX8u2f4ta7vofd3zdnhryFMrc3m1avJ/zKU 1foilflAP5k/uePLjmrtpM8DL4ZRPWseX2ZwOTosUIR3vhCsUodNhM069muAb9VIcpec UIVg== X-Gm-Message-State: AOJu0YyyhygygAn5iqKHdUy93hPxR34auCRmbqO1sCtIOxZPEXzPuytq 8nEw2PZnJsqUjsu9cAFIqTU36En6dVzfZmUeFLIgtAmAywo= X-Google-Smtp-Source: AGHT+IHrduTqxpuVgZdzGr47/T8TiNiVZa5bT7zRSpRGcYvCez9hCLNul0OWicfnLqegyhamlMP99+JN/hjU6aa3B0c= X-Received: by 2002:a2e:a413:0:b0:2cd:8f26:a1e9 with SMTP id p19-20020a2ea413000000b002cd8f26a1e9mr2082843ljn.37.1705252067435; Sun, 14 Jan 2024 09:07:47 -0800 (PST) List-Id: Threading List-Archive: https://lists.freebsd.org/archives/freebsd-threads List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Sun, 14 Jan 2024 14:07:34 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Alan Somers Cc: Konstantin Belousov , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TChY50cVHz4SYZ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] Em dom., 14 de jan. de 2024 =C3=A0s 13:30, Alan Somers escreveu: > I don't understand. What are you worried about that would block? > lseek never does. It never actually goes to disk; it just retrieves a > variable from within the kernel. So while the expense of a syscall is > non-zero, you don't have to worry about lseek blocking. Sorry, that was a lot of condensed information that I dumped together. We can use lseek to get the offset and use AIO specifying the offset we just queried. However the untrusted sandboxed process might actually send as a socket file descriptor (we don't control what we get from the untrusted sandboxed process), and lseek is then inappropriate. From what I've read from the source code, we can pass these bogus offsets to AIO, and it'll just work. However we're still paying an extra syscall (and code doesn't feel right anyway). Anyway, the kernel *already* has this thread pool (AIO daemons), and the only change required here is a flag that controls whether FOF_OFFSET is passed along. That's a pretty non-invasive change. What is the problem? Again, the model already works fine on Windows and Linux. -- Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/