From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) (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 6C8FC18BC3D for ; Fri, 10 Jul 2026 12:52:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783687958; cv=none; b=s+9hrVj2WqfOgQMIwo4ygUwRoEMEIqFLXHmfGa3a+rzdN8un/49IFGjCfZZH0bNFtGEgm9LMrRUSskiDd9ksfD0u3wjfvg8Xp83jsoRXAUO9xjrpAQHSZTII3g7jAr9CTcTltKZXFan74kW7IrLqXXgZo/38U+xTqEgA3MOsvzE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783687958; c=relaxed/simple; bh=RvuTfYBYq4+An7h8RGp7T9Wr2If88HFmr6sWzQCjttE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=apQcYiuL6yfPzvu2AaTL04PlkQka9bPUCPl9JvBG7MI1vtmxksLvjc+YuF/89tMa3XYXeJydXmyASMWctiAW4VIWsiNe7L9mzPnLNx68KZ2ax19bULcCcbMY62Fdp+Y44+o6BJuHY6Efw9ALDLgWWVOXzjk4+yaGMMy/tcuEGU0= 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=AydgSSaH; arc=none smtp.client-ip=209.85.219.42 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="AydgSSaH" Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-8f18d92172aso11500746d6.2 for ; Fri, 10 Jul 2026 05:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1783687955; x=1784292755; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9a3+449cm8MGnIDiFu5KmKBBC+232LbzC7IoKmFpvdY=; b=AydgSSaHO0q+Gw6rYkaFYjAYqRfy6+cNfzkh1Bga1R3n1M006H/UsyumJikjtZXAHm 2gBi7qsUTZw8sFIZXQSIvId8Vyodvc00MrOpO9h0GO54GiuZSpqvCGMdRiCoCc/At74l NKXB3i12zwjihfCHqHsS1KgsTgFCcpDQru/f06jvLYTD0ndoY+GrXnTfungALH7qdQb2 tSgAoOy82PyIqNVKAWhC8CveUgmmvepjo4Ly2bQd8nfiXVy6C1LPIxwuP9rHOF/zm12V 5AH/G2tKIXzCDoXriRmNeccU6H+HxvIpZphJf8g5TPs8zifq6Jooa/iFyTGG1YROP9YP VawQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783687955; x=1784292755; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=9a3+449cm8MGnIDiFu5KmKBBC+232LbzC7IoKmFpvdY=; b=lyjhlCrRZAF3FQ8qjZGmdFP9fXi6MnRZwEkybwHCRdRd2DisU7uacNJmnfP6/2oqxj FimBz/ihcRWS/RzeqqlR5phDBWQUFUkAzV/FydbTNyS0VgJNvSciaSFLUCbkh5mz8Rz8 2UYWY0/HLtyTNvaxrvVb707QoMCU/9Tr6n5ro6RkGYL/ATn+6LOASN+9gTzfpitwBdLL cJ9qUe/VR5L5kwsttNd/TZFonyVYubkMc9F3Tzwpc7WhrHALW5TPGBRk3+U5KLuGMgl7 ihYOB4mW4hAU4c6L/ftKp9UfuGnzpsi9OAbEycb3w51n5gnI9jNg/un3VlQxm9ZW7DJL FgDQ== X-Forwarded-Encrypted: i=1; AHgh+RovYh3g2532SNWHxv+a1UTmxARAOlXwSP1r8hsTfjWcBIeIUl9j5EPCqOzwqqBNZlqE5q/PNemnMAWxiyE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzmvzj5UEMkDS391CLdtBMsF0awF4Rqov1m0Y5+MHlJzTpYoNUu nm4sH+NFISuZkMrQVR90Alpff+crmVKDe6y954m3Z3tYCcRr2FvCPI+ICSazfOTCsoM= X-Gm-Gg: AfdE7ckHt0rI5ls8OrFTyvRLkLQRytbeLPjTOx3AEzMbulGeRMj3chgb0nAo//ja7IT yk7oQbn4K/u0mUbY0ifuTgpy5eUNetX6nEK6jzFizxwUxGSCqxASM85BIu4JVhIaljz5U37eIMj KS6G+IvrYEfVBU9cKGFMQVIk1iNK+I9GSjgsFC5ts9DfjfRVT3vhn1TJY1KiKXMKNa6QCHS1ZiN PUmDL0e7+iWsBcBOk5DJ2QVGNjJIGiVy5bvfjQZv0tPS95TD7GqNHYk75ur3hy/aqLhtk5MuU+7 PxrmDxX0atiz9/RJPqt0ufJedJxPuoow+eqCCbLW2APrBr0oKHhG5gSq8BKv8z/yNepbaqkcCLk ImpbaFBrdS2jzxw2AIfeHQHbB3S6Y1E+Z7mgGJnLSQsjo4gqdFaR1/SZ0VyGwyM8c0DMo4V0= X-Received: by 2002:ad4:4ea4:0:b0:8fd:6dc5:94b with SMTP id 6a1803df08f44-8fec3a05028mr123145186d6.64.1783687955236; Fri, 10 Jul 2026 05:52:35 -0700 (PDT) Received: from ziepe.ca ([159.2.72.92]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ffd80fe009sm40142286d6.38.2026.07.10.05.52.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 05:52:34 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wiAiX-00000006sit-2xhr; Fri, 10 Jul 2026 09:52:33 -0300 Date: Fri, 10 Jul 2026 09:52:33 -0300 From: Jason Gunthorpe To: Konstantin Taranov Cc: Konstantin Taranov , "shirazsaleem@microsoft.com" , Long Li , "leon@kernel.org" , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Adopt robust udata Message-ID: <20260710125233.GN118978@ziepe.ca> References: <20260623114444.1429042-1-kotaranov@linux.microsoft.com> <20260702180158.GU7525@ziepe.ca> 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: On Fri, Jul 10, 2026 at 08:54:03AM +0000, Konstantin Taranov wrote: > > > On Tue, Jun 23, 2026 at 04:44:43AM -0700, Konstantin Taranov wrote: > > > > > +struct mana_ib_uctx_req { > > > + __aligned_u64 client_caps1; > > > + __aligned_u64 client_caps2; > > > + __aligned_u64 client_caps3; > > > + __aligned_u64 client_caps4; > > > + __aligned_u64 comp_mask; > > > +}; > > > > I think Jacob has it right, This is looking pretty gross. > > > > Jason, I sent a response to Jacob earlier. I am not sure you saw it. > The problem of enforcing robust udata on alloc user context is that it blocks > any future additions to the request. Since it is the first IOCTL there is no way > to negotiate the request format. And that is why I wanted to reserve some fields now. With the udata system you can't implement a scheme where you send unknown bits into the kernel and it returns back the ones it understands. That protocol just isn't supported in the 'zero means backwards compat' semantic we are using for udata. So I'd rather not see deviation from that normal protocol (I know a few other places have but lets not grow) > > If you want such a complex protocol then use the new ioctl format and > > declare sensible driver specific attributes. Nobody has converted > > alloc_ucontext yet, but that is usually not hard to do. > > I have a question. If I add now ib_is_udata_in_empty() to alloc user > context, would I be able to adopt new ioctl format and extend the > udata for alloc user context? Yep, they are orthogonal things. the "udata" is only the legacly uhw in/out structs. The ioctl mechanism is uattrs based and completely different. So you can set an optional client_caps uattr and implement this protocol there. Jason