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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
