Re: [PATCH v2 1/2] RDMA/rxe: Fix null-ptr-deref in kernel_sock_shutdown().

["yanjun.zhu" <yanjun.zhu@linux.dev>]

On 4/27/26 7:38 AM, David Ahern wrote:
> On 4/26/26 9:53 PM, Zhu Yanjun wrote:
>>> That said, I don't have a strong preference, so up to you
>>> maintainers.  Simple lockless solution vs per-newlink/dellink
>>> locking.
>> To be honest, I do not have a strong preference here, though
>>
>> I lean slightly toward the per-newlink/dellink locking approach.
>>
>> Both the simple lockless solution and the locking approach seem
>>
>> reasonable, depending on whether we prioritize simplicity or
>>
>> explicit synchronization and lifecycle clarity.
>>
>> It would be helpful to get feedback from David Ahern, Leon,
>>
>> and Jason to converge on a final direction.
> 
> 
> Going in circles. I have said from the beginning of network namespace
> support for rxe do not open the port until first rxe device create and
> once opened leave it open. Simple design that limits socket churn to
> users wanting to leverage rxe in a network namespace. Zhu Yanjun, if you
> are going to be a maintainer of a feature you need to have a consistent
> stance on the architecture and code design.

Thanks for the clarification — I see your point about keeping the design 
simple and avoiding unnecessary socket churn.

I agree that deferring the port open until the first RXE device is 
created, and keeping it open afterwards, provides a cleaner and more 
predictable model. It also better scopes the overhead to users who 
actually rely on RXE within a network namespace.

My earlier responses were not consistent, and that’s on me. I was 
exploring different approaches, but I understand that as a maintainer I 
need to converge on a clear and stable architectural direction.

Unless there are strong objections, I will align the implementation with 
this model and make sure the behavior is consistent across the code 
paths. I’ll also revisit the current patches to ensure they follow this 
design principle.

Please let me know if there are additional constraints or edge cases I 
should consider.

@Kuniyuki Iwashima, Please follow the per-newlink/dellink locking 
approach. Thanks a lot.

Zhu Yanjun