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

Kuniyuki Iwashima
2026-04-28T00:52:40Z

On Mon, Apr 27, 2026 at 1:20 PM yanjun.zhu <yanjun.zhu@linux.dev> wrote:
>
> 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.

To be clear, you meant implementing David' idea, right ?
I'm asking because dellink won't need locking then.