On Fri, 2016-07-08 at 12:15 +0900, Masashi Honma wrote:
=
> Thanks for comment.
>
> I have selected GFP flags based on existing code.
>
> I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because
> skb was allocated with GFP_ATOMIC.
Point is : we should remove GFP_ATOMIC uses as much as
On 2016年07月08日 11:56, Eric Dumazet wrote:
Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in
this patch is definitely not good.
Further more, RTNL is a mutex, held in control path, designed to allow
schedules and waiting for memory under pressure.
We do not want to
On Wed, 2016-07-06 at 09:28 +0900, Masashi Honma wrote:
> Signed-off-by: Masashi Honma
> ---
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a1f6b7b..2b0b994 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -628,7 +628,7 @@ static int
* Added two tests for 100pps support to libxt_hashlimit.t
* cfg_copy returns -EINVAL and all callers of cfg_copy will
look for the error value
--
libxt_hashlimit: Create revision 2 of xt_hashlimit to support higher pps rates
Create a new revision for the hashlimit iptables extension
Removed the call to BUG() in cfg_copy, we return -EINVAL
instead and all calls to cfg_copy check for this
--
netfilter: Create revision 2 of xt_hashlimit to support higher pps rates
Create a new revision for the hashlimit iptables extension module. Rev 2
will support higher pps of upto 1
I am planning to add a revision 2 for the hashlimit xtables module to
support higher packets per second rates. This patch renames all the
functions and variables related to revision 1 by adding _v1 at the end of
the names.
Signed-off-by: Vishwanath Pai
Signed-off-by: Joshua Hunt