From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD7263B0AC8 for ; Wed, 8 Apr 2026 11:26:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775647619; cv=none; b=LKMbimLgEyj309xukcYy0jZR12LIW+agD82WytiTnMxVzgmWWGGpYVMDGREh5Iu2LJVaZtKX1AtU4mCX4hbT2TH+o7YRtGCZmVtZS7O53odGSqpPIINiEPPJiRvZllGYF7o7gCK/Ywz+UbM+ADaOOImoCX8J0Bp2CxOpgYtUEXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775647619; c=relaxed/simple; bh=AzehQ18alrzr2B4IsDUBovXNCXWu6SlHUOMWZ0pewVw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=u+XIQoFoedOf9v5tZnS6nd+LsZFCB86cKv26tAN0cy+XEfL2G0eYzMNsWXsc1e66Krez/odE/jCeZkl+npZ0zrrF/pcwtGVAiCkZ0yv9UabHGCZlrl4xONgflvenc+LqzZ4Vl+V9zhUJcF3WE4sVrnEJOErYUxtQECRM5DOkjd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CsKD0Hkp; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CsKD0Hkp" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-488af96f6b2so41317645e9.0 for ; Wed, 08 Apr 2026 04:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775647616; x=1776252416; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=9Ge0u9kdZKFhKwQUuXKTE2s3xbjDUvzv/MSs18Mhdv0=; b=CsKD0HkpgqXsNjJgnvcv1ObDqF2sJmD5u1ayZeItzhEm0pRTwzxeUt0DKfNcEkHsgG HFZQXixnRkBfI0onpORV800pN0LBi/bS9OSNqtTkPOgv3rbybTu1DgQEpB4uhZVNi1AK QWypWUqmF2oeu4Zou+cgRBX33kyRPAo7Yu0Yye/j9RqGoh6PXhmqQlaS3H3fmg5o5XGM GVTYJ8Tv4ChS7F8aIKwcrN6XXp8pCMRrlMd/Iv32DLR3r2NNzAhySOKo89fdq6nTAagf cXMaORSDxcyLD6igT7iMJFVyVOgafM2DgDiEVjgkMlmLXB3j7lBjG7IbTdUM13TRJMsr vhTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775647616; x=1776252416; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=9Ge0u9kdZKFhKwQUuXKTE2s3xbjDUvzv/MSs18Mhdv0=; b=dvtDHlX73TV6bblbKu470yobg35f6mdrhwXNEkTG5fheZYHKIOXODiN4zDJtvnjGSQ d7M2swBRd9GDYUbtYI8DsAa6r8r/8XX1YxzpvWWwb0IUbq8uAhBiuMNb3IhZJn7cXQp8 bKIYMziLumBg1OVNUmnkJ4xC/+pwB+5sKfsAX2fXeDzhkqlyvljA5fYi2UdduhxiWYWA tY2f3RQzNL/sE+HnpmTvd7ApsL6fZf7gMo1BMwN3fFDx9USVIsTkd4n3VljMNCe2Iwvn Bc1nt9prEm8lyMwC4s/fqmVAUiwotlVS8a1xpvkA0bkkN0HI72GafyZkPo0flmiY9l5J Iv+A== X-Forwarded-Encrypted: i=1; AJvYcCUMIji0TeA/0Gdm965xfzNfS3VKeyzWP9Q6vvSRE/QAFPbhFbr8MjYlci/xaDMUQfmFlhBj2ZlIH7ctThs=@vger.kernel.org X-Gm-Message-State: AOJu0YyyoMS8MPQ4TjUWgtMiyqdchXPZJPgOvk9hdLGvRLogKUzbugm3 8zuHjIZqJu8dzkwtbeF04sDTdir86jeNMh6XNqc4Qm3DbeMCUocV9bT/ X-Gm-Gg: AeBDietUCVB/S9w/IsMqkaNq3eDI4ELF7fJ5326TGsQnTcmdbobYD2CC3goM0AVooTl STVS5Zn94v6TJQZGYZheD4VKymln3gS7BrMr8R8aiznkcRcU8II4c8Q2NxMX6KSqvVbYSUGXXAu Le8czqXTRdNG7Ix2pnSvAF3ZhiIQD5VtkJDcm6Wo9Co/nq3CsnXjzFSEMTJe5O0Zl6e3zqB64SE CofzFM5i4iZQ7e+cNQofB3qaNPkdiebFh9uXYgssJa87drRAAVG8sZ/XP4pzbJxFSd13UGUWoAz iL0n8OgbOIED0Dgli4V34ovteMxvigTeSlXh2A63SGnG/c1y7NAJbMZRlfW+1XAyAMCQrMAZ1/w zGQP1dQnvCRkBuBKDufeFVd3+RbjdzLL/94UXbrOnR9ueW52SArpfb0QLEYafHWwOdmXEzTSy5a ka/p2JHeiW3Y6LsR2n/2tWL8Zl9OyGbgW/yJ6Jp3VGwkMP2apu1dm9UXnZ5mlqrN26 X-Received: by 2002:a05:600c:3544:b0:485:303b:c50a with SMTP id 5b1f17b1804b1-488997352d3mr282797795e9.13.1775647616063; Wed, 08 Apr 2026 04:26:56 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488c5d85452sm16295135e9.15.2026.04.08.04.26.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 04:26:55 -0700 (PDT) Date: Wed, 8 Apr 2026 12:26:53 +0100 From: David Laight To: Breno Leitao Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Willem de Bruijn , metze@samba.org, axboe@kernel.dk, Stanislav Fomichev , io-uring@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, Linus Torvalds , linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers Message-ID: <20260408122653.295953dd@pumpkin> In-Reply-To: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org> References: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 08 Apr 2026 03:30:28 -0700 Breno Leitao wrote: > Currently, the .getsockopt callback requires __user pointers: > > int (*getsockopt)(struct socket *sock, int level, > int optname, char __user *optval, int __user *optlen); > > This prevents kernel callers (io_uring, BPF) from using getsockopt on > levels other than SOL_SOCKET, since they pass kernel pointers. > > Following Linus' suggestion [0], this series introduces sockopt_t, a > type-safe wrapper around iov_iter, and a getsockopt_iter callback that > works with both user and kernel buffers. AF_PACKET and CAN raw are > converted as initial users, with selftests covering the trickiest > conversion patterns. What are you doing about the cases where 'optlen' is a complete lie? IIRC there is one related to some form of async io where it is just the length of the header, the actual buffer length depends on data in the header. This doesn't matter with the existing code for applications, when they get it wrong they just crash. But kernel users will need to pass the actual buffer length separately from optlen. It also affects any code that tries to cache the actual data and copy it back to userspace in the syscall wrapper - which makes sense for most short getsockopt. (This is different from historic code where the length might be assumed to be 4 regardless of what was passed.) David