From nobody Fri Apr 17 19:43:44 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5DFBC43334 for ; Fri, 22 Jul 2022 20:15:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234091AbiGVUPW (ORCPT ); Fri, 22 Jul 2022 16:15:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236770AbiGVUPU (ORCPT ); Fri, 22 Jul 2022 16:15:20 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A737613D0F for ; Fri, 22 Jul 2022 13:15:19 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id u15-20020a25ab0f000000b0066e49f6c461so4402621ybi.2 for ; Fri, 22 Jul 2022 13:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:mime-version:message-id:date:from:to:cc; bh=c/c766f5IweLiXfTzCwsILplI2BRgHB64Zpkrcr5r4c=; b=IVmB1KhfRC9dhpaTkpIjZ6E3f+Szh9fFdOVOyseY1NVukF8w6zwOAocHq6J1WNgOx7 MkeP7D6XmaSW+5oGvdDUL4lzrNGQs+5+3SzlU1AMRuxE8aagduAp2F/E7t9ZmgbuwpjO f306zDfgyelvBDZnfGcG8V+emseVEwfjhn1IjzDmb1pHxpuSwWN5tvBBazNN5/qG4idy 0HIiZvpiJVPJ0ZAcKaJCuS/PXvPEoLzAMUJto3JnYgY7Ng6J/iATPcYHANgx87GtHulV wiCPLmIuBvP3zKYVaBGLJd3oDLj4WIAhZAT9wtlrMeNw2yNlJnbECqep3fMPmM0ZgOif HqKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:mime-version:message-id:date:x-gm-message-state :from:to:cc; bh=c/c766f5IweLiXfTzCwsILplI2BRgHB64Zpkrcr5r4c=; b=VRxkKBCYUKpn/g/tcno4G0KPJApzEArh4Hjkgj6NoDA8gwbQzcy+SfomV4enZvgAjl 41dzZzVU0tJ/7kz9kYKuMf7QtvrbRseLRkFRu6jVF5ahsgjysBJJVLN1+OXs7RuZQWuf Dghp93L4AvQ6paE2d4PTpoRjuBEfqUHlPDnGX4GzCopUbJCDRzUq4C3tbo5CbMuhAL8L I/u2QGEzaQ0aaZEzUOfemwOC6qONHga6sfXiuDAiJA115rhQekQYLqLCDDZjfgh2DrbI /SuU9BMeRb+LDE8q1zzuTFjfhvc4cddI4nH1xQIMaShLERcOdU4sriCnYsQR+QMxXGWI +ZMQ== X-Gm-Message-State: AJIora87ILwQ7CY879UVAaq4CcQLUBlVTLMPRgUFFfshiX2oQO1rz83e 5kkc7j2DFdYIJiACEigvVfc4s2ie7YkxOm07rw1N X-Google-Smtp-Source: AGRyM1uRjPK6eRsDWx956R4w3PIY9GowmVfxAwibKdWDAaVTmRSzk/CGssJt4ZsxlokH97WRezORFs8FoPg+8IAOZxDR X-Received: from ajr0.svl.corp.google.com ([2620:15c:2d4:203:1623:4cce:b896:4e2f]) (user=axelrasmussen job=sendgmr) by 2002:a25:af93:0:b0:670:7de3:6c30 with SMTP id g19-20020a25af93000000b006707de36c30mr1242861ybh.569.1658520918930; Fri, 22 Jul 2022 13:15:18 -0700 (PDT) Date: Fri, 22 Jul 2022 13:15:13 -0700 Message-Id: <20220722201513.1624158-1-axelrasmussen@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.37.1.359.gd136c6c3e2-goog Subject: [PATCH] userfaultfd: don't fail on unrecognized features From: Axel Rasmussen To: Alexander Viro , Andrew Morton , Peter Xu Cc: Axel Rasmussen , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The basic interaction for setting up a userfaultfd is, userspace issues a UFFDIO_API ioctl, and passes in a set of zero or more feature flags, indicating the features they would prefer to use. Of course, different kernels may support different sets of features (depending on kernel version, kconfig options, architecture, etc). Userspace's expectations may also not match: perhaps it was built against newer kernel headers, which defined some features the kernel it's running on doesn't support. Currently, if userspace passes in a flag we don't recognize, the initialization fails and we return -EINVAL. This isn't great, though. Userspace doesn't have an obvious way to react to this; sure, one of the features I asked for was unavailable, but which one? The only option it has is to turn off things "at random" and hope something works. Instead, modify UFFDIO_API to just ignore any unrecognized feature flags. The interaction is now that the initialization will succeed, and as always we return the *subset* of feature flags that can actually be used back to userspace. Now userspace has an obvious way to react: it checks if any flags it asked for are missing. If so, it can conclude this kernel doesn't support those, and it can either resign itself to not using them, or fail with an error on its own, or whatever else. Signed-off-by: Axel Rasmussen --- fs/userfaultfd.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index e943370107d0..4974da1f620c 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1923,10 +1923,8 @@ static int userfaultfd_api(struct userfaultfd_ctx *c= tx, ret =3D -EFAULT; if (copy_from_user(&uffdio_api, buf, sizeof(uffdio_api))) goto out; - features =3D uffdio_api.features; - ret =3D -EINVAL; - if (uffdio_api.api !=3D UFFD_API || (features & ~UFFD_API_FEATURES)) - goto err_out; + /* Ignore unsupported features (userspace built against newer kernel) */ + features =3D uffdio_api.features & UFFD_API_FEATURES; ret =3D -EPERM; if ((features & UFFD_FEATURE_EVENT_FORK) && !capable(CAP_SYS_PTRACE)) goto err_out; --=20 2.37.1.359.gd136c6c3e2-goog