lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Jul 2008 09:32:09 -0400
From:	Paul Moore <paul.moore@...com>
To:	"Denis V. Lunev" <den@...nvz.org>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next? 1/1] netlabel: return msg overflow error from netlbl_cipsov4_list faster

On Friday 11 July 2008 8:13:12 am Denis V. Lunev wrote:
> On Fri, 2008-07-11 at 07:01 -0400, Paul Moore wrote:
> > On Friday 11 July 2008 6:45:49 am Denis V. Lunev wrote:
> > > Currently, we are trying to place the information from the kernel
> > > to 1, 2, 3 and 4 pages sequentially. These pages are allocated
> > > via slab. Though, from the slab point of view steps 3 and 4 are
> > > equivalent on most architectures. So, lets skip 3 pages attempt.
> > >
> > > By the way, should we switch from .doit to .dumpit interface
> > > here? The amount of data seems quite big for me.
> > >
> > > Signed-off-by: Denis V. Lunev <den@...nvz.org>
> >
> > I'll add my ack to this patch because your logic sounds reasonable
> > and I'm glad to have more eyes on the code :)
>
> cool :)
>
> > However, I not a big fan of converting this from a .doit to a
> > .dumpit interface because this would cause userspace breakage.  We
> > could potentially do both for backwards compatibility but I have no
> > idea if it is possible to have both interfaces available at the
> > same time.  One thing to keep in mind before diving into your
> > favorite editor is that I've yet to hear of there being a problem
> > with this NetLabel command and the .doit interface, we may want to
> > hold off to see if it becomes an issue.
> >
> > Acked-by: Paul Moore <paul.moore@...com>
>
> for the dumpip interface. 2-order page is a real pain on the heavy
> loaded systems. Yes, the allocation will not fail, but it can take a
> significant amount of time to perform the allocation.
>
> I understand your logic with keeping this interface, but such
> allocation can take > 1 sec for sure.

Okay, that is good to know.  If it ever starts to become a problem I'll 
look at leveraging the .dumpit interface.

Thanks.

-- 
paul moore
linux @ hp
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists