From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (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 F2F853438AE for ; Tue, 19 May 2026 22:49:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779230955; cv=none; b=nhPCfc1nW83SreGjihujLYwnbJpQqgB7NXWh5YaNp5mB8kaS/0xUV8YK7nlbtbx0/WhLAuJ1SVnwv9M1sjFZjl0RbX8qy28wzNUWZIxc2ecigmlTGpDCQIj0P5Oz1CyuUvRgcEmPdaA4pB9GTkZnDcW9/ruzdgkiU0b3QBJg4PA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779230955; c=relaxed/simple; bh=FuXHOd5yaQ4LzfOdN1/Nq5sh02lDV3Ri+GcBtPpIqtI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CUGv82ry9XOVwYCq2l5+IcTvQcKVSW8ThM3cayYq2Mev2MnpoJgMU0Ascsw5CP0abNkwWQBrJC78qvLBxhM5COViWoO2866xfcZ6EFLabEzmnx2ITsLk35Vya7BvWT5ARbhFDEmzy4gXZxk+5jMwiE7vEzoD1XosTIi/iCy7lEc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=X9JhlBVD; arc=none smtp.client-ip=209.85.219.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="X9JhlBVD" Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-8b7105dfb35so54411866d6.3 for ; Tue, 19 May 2026 15:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1779230953; x=1779835753; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Y4xuNk5HeOGj7oVkz9btczqrM4Oe3yykQcOEW7pJDCE=; b=X9JhlBVD5fNonRpSjDIDhydgVyUJYLp5miKWUxmPAehYQvy6iCj81r9jC5A9cJB5Iy 0jxekcK7qr60+3YLySwflQltpmqeXdA53MUyiq5VDQor3tM0TqQx5mrK07biCoZwNSi1 ppRqqK+E+YYFz7TwemLeNZjdf90YKK4BLHD4io+XVgvbra7WT7RuWywco9Zv4UIZddZ6 v67A+46AlPEmsrcKDZhywc2+eJ8G+mBvTzVbPrE2dXPHYT55Exzs7/3/RoLnaCcvKxVK yHmakwbhi7nALrXOaz5nRjMjKu1w4Nbmc3fstgVE8gzGdToOgESim3yed7t4UwDJnOTC WPNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779230953; x=1779835753; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Y4xuNk5HeOGj7oVkz9btczqrM4Oe3yykQcOEW7pJDCE=; b=RjOjm9t2lcd5zJs2pIa0BjYXSbHN/M81PCWuUGy8pbH7gmZXL0AYZEPMHdJYDNYG4+ gF+DATO5jIxH256pjFh4A0eaPLhc/22h0JPb1u7RA6ywrF9qlyaGA0m143whLEYn/z9L H1BTdmkYILlCVtamv7wedCUXZp2LsipMx4DPYbDBLAz8+hcUcDBhoYkvJqTE/wjbXke3 dWFrwwy3OFkM4IiYG3QRBXW4xgNXrzZW450L9p3UQlpjr1+U4qcS58FlFtWStsioe/Ys ZZcruC7n/wB2BKwUeu27Wr0Y8epnhbi+nnxzfOpiF6Ln8qJgqVhskK3s2GlIJTB4ngcP zZig== X-Forwarded-Encrypted: i=1; AFNElJ9UwDiygHZfRXJq+8DE3Lso8U2XRKSnnpGzfuXLygmrd4bLPVH9pStYgv6IoTTogY49V4Juaczufok+Q70=@vger.kernel.org X-Gm-Message-State: AOJu0YzZ8+AKPuSCpBF6HRKiwVwY8vOhe/s8s9DR1AiG8MTgSyf66ApQ dCPVxtMErLMlHKyIgl3Hzrg2jb8nsz0RU5ELIqAQlJVb5r2sj8T8Vi/wKrQTgsx1TbX5VGm+dj6 axjo3 X-Gm-Gg: Acq92OFAFzwF5RIiKMonP/KYmmEW3+tiqX74BM2iQDaLHTywksed6bHg88RzZ6IJ4PD oK9u2+0o/FhMwgerUvW04hUhjPiH3Ohvwz4pfpBPt8DVY3mUysEvqAFCNtf1kbVfVsq8oZaOgGx ga65E4Dw6lX9YcxxZFzjWeIVeKAUlsFYRp02Fs21TQe/QsggGA0olXWjRbtFzH6sFudMN6bj47Z MDvi/DEL/ZqGGJkLOgo8VQKcYx9+2d3OkC2QdILfMyURIq8kXDyyP0sCgIp9DaURAqIng5fzxyB GsRUpJdEwG4kQQVgRjXldqyznVq69bXRjN5D2og+0RVtIhzM/Zxa1Vh4kEEbzbyxHt+4pwzB77+ wC34tSDJmqc1SqjEaYa19/BGo/+e/OVGLAnzc534jv/C1Z2YrHiUknpWcRR97AN8TIG1T8Jihl5 /4jf7lTGDY2jttyEiWvOpC68gDIN84NPcQ7Zc9TRhWNi3uEvSgffWweby+6jnoAxwt5WRKwFBGc FZbHg== X-Received: by 2002:a05:622a:a911:b0:510:138e:b83c with SMTP id d75a77b69052e-5165a2760e9mr244413901cf.33.1779230952853; Tue, 19 May 2026 15:49:12 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-516456888f6sm187957931cf.3.2026.05.19.15.49.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 15:49:11 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wPTFP-0000000FyO6-0aaG; Tue, 19 May 2026 19:49:11 -0300 Date: Tue, 19 May 2026 19:49:11 -0300 From: Jason Gunthorpe To: Nathan Chancellor Cc: Leon Romanovsky , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] RDMA/core: Remove _ib_copy_validate_udata_in() and _ib_respond_udata() stubs Message-ID: <20260519224911.GP7702@ziepe.ca> References: <20260519-rdma-core-fix-ib_udata-redef-errors-v1-1-671bf2697fa5@kernel.org> 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-Disposition: inline In-Reply-To: <20260519-rdma-core-fix-ib_udata-redef-errors-v1-1-671bf2697fa5@kernel.org> On Tue, May 19, 2026 at 11:24:36AM -0700, Nathan Chancellor wrote: > After commit 65b044cee9fb ("RDMA/core: Move the _ib_copy_validate_udata* > functions to ib_core_uverbs"), builds without INFINIBAND_USER_ACCESS > enabled fail with: > > drivers/infiniband/core/ib_core_uverbs.c:433:5: error: redefinition of '_ib_copy_validate_udata_in' > 433 | int _ib_copy_validate_udata_in(struct ib_udata *udata, void *req, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from include/rdma/uverbs_std_types.h:10, > from drivers/infiniband/core/uverbs.h:49, > from drivers/infiniband/core/ib_core_uverbs.c:10: > include/rdma/uverbs_ioctl.h:961:19: note: previous definition of '_ib_copy_validate_udata_in' with type 'int(struct ib_udata *, void *, size_t, size_t)' {aka 'int(struct ib_udata *, void *, long unsigned int, long unsigned int)'} > 961 | static inline int _ib_copy_validate_udata_in(struct ib_udata *udata, void *req, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/infiniband/core/ib_core_uverbs.c:483:5: error: redefinition of '_ib_respond_udata' > 483 | int _ib_respond_udata(struct ib_udata *udata, const void *src, size_t len) > | ^~~~~~~~~~~~~~~~~ > include/rdma/uverbs_ioctl.h:968:19: note: previous definition of '_ib_respond_udata' with type 'int(struct ib_udata *, const void *, size_t)' {aka 'int(struct ib_udata *, const void *, long unsigned int)'} > 968 | static inline int _ib_respond_udata(struct ib_udata *udata, const void *src, > | ^~~~~~~~~~~~~~~~~ > > Remove the stubs and adjust the prototypes for _ib_respond_udata() and > _ib_copy_validate_udata_in(), as they will always be available when > INFINIBAND is enabled. Ugh, we should get rid of this option these days.. The right thing is to #ifdef away the moved C code since it doesn't get removed by the makefile and keep the static inlines. Possibly even all of drivers/infiniband/core/ib_core_uverbs.c should be put under a conditional, I'll look at that later --- a/drivers/infiniband/core/ib_core_uverbs.c +++ b/drivers/infiniband/core/ib_core_uverbs.c @@ -417,6 +417,7 @@ struct ib_device *rdma_udata_to_dev(struct ib_udata *udata) } EXPORT_SYMBOL(rdma_udata_to_dev); +#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS) uverbs_api_ioctl_handler_fn uverbs_get_handler_fn(struct ib_udata *udata) { struct uverbs_attr_bundle *bundle = @@ -501,3 +502,4 @@ int _ib_respond_udata(struct ib_udata *udata, const void *src, size_t len) return -EFAULT; } EXPORT_SYMBOL(_ib_respond_udata); +#endif I guess I'll squash it in, unlucky that 0-day didn't notice this, or maybe it isn't working anymore... Thanks, Jason