On Fri, 2017-06-02 at 11:28 -0500, Shiraz Saleem wrote:
> On Wed, May 31, 2017 at 02:10:31PM -0600, Bart Van Assche wrote:
> > On Wed, 2017-05-31 at 12:42 -0500, Shiraz Saleem wrote:
> > > > 5. I proposed a solution -> go and fix your user space program.
> > >
> > > This is a kernel patch you are trying to revert, you are breaking existing
> > > kernel functionality. Nothing to do with user space.
> > >
> > > Bottom line, come up with a solution that will address both port mapper
> > > functionality and your issue.
> >
> > Hello Shiraz,
> >
> > Sorry that this means additional work for you, but I agree with Leon that
> > user space software should not assume that netlink sockets are a reliable
> > communication mechanism.
>
> Hi Bart - Thank you for your response.
>
> The original problem was that ibnl_unicast, which is used to send nl messages from
> portmapper kernel space to user-space, would occasionally and momentarily fail under stress.
> We could have retried the call for a certain amount of time, but since netlink_unicast has a
> nonblock/block parameter, we chose to use the blocking option with a timeout. So we thought we
> did account for deadlocks with this timeout.
Hello Shiraz,
According to what I see in iwpmd/iwpmd.conf the default value for the iwpmd
netlink socket receive buffer size is 419430400 bytes. So I'm surprised that
sending netlink messages occasionally fails since the receive buffer is so
large?
Bart.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
