Re: [PATCH V2 5/5] RDMA CM: Netlink Client

[Nir Muchtar <nirm-smomgflXvOZWk0Htik3J/w@public.gmane.org>]

On Tue, 2010-12-07 at 14:29 -0700, Jason Gunthorpe wrote:

> What you've done in your v2 patch won't work if the table you are
> dumping is too large, once you pass sk_rmem_alloc for the netlink
> socket it will deadlock. The purpose of dump_start is to avoid that
> deadlock. (review my past messages on the subject)
> 
> Your v1 patch wouldn't deadlock, but it would fail to dump with
> ENOMEM, and provides an avenue to build an unprivileged kernel OOM
> DOS.
> 
> The places in the kernel that don't use dump_start have to stay under
> sk_rmem_alloc.
> 
> Jason

Sorry, I still need some clarifications...
When you say deadlocks, do you mean when calling malloc with a lock or
when overflowing a socket receive buffer?
For the second case, when we use netlink_unicast, the skbuff is sent and
freed. It is transferred to the userspace's socket using netlink_sendskb
and accumulated in its recv buff.

Are you referring to a deadlock there? I still fail to see the issue.
Why would the kernel socket recv buff reach a limit? Could you please
elaborate?

Thanks,
Nir

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html