* [PATCH 1/2] tuntap: reduce memory using of queues
From: Jason Wang @ 2013-01-23 13:59 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel
Cc: Jason Wang, Eric Dumazet, David Woodhouse
A MAX_TAP_QUEUES(1024) queues of tuntap device is always allocated
unconditionally even userspace only requires a single queue device. This is
unnecessary and will lead a very high order of page allocation when has a high
possibility to fail. Solving this by creating a one queue net device when
userspace only use one queue and also reduce MAX_TAP_QUEUES to
DEFAULT_MAX_NUM_RSS_QUEUES which can guarantee the success of
the allocation.
Reported-by: Dirk Hohndel <dirk@hohndel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index c81680d..8939d21 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -109,11 +109,10 @@ struct tap_filter {
unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
};
-/* 1024 is probably a high enough limit: modern hypervisors seem to support on
- * the order of 100-200 CPUs so this leaves us some breathing space if we want
- * to match a queue per guest CPU.
- */
-#define MAX_TAP_QUEUES 1024
+/* DEFAULT_MAX_NUM_RSS_QUEUES were choosed to let the rx/tx queues allocated for
+ * the netdevice to be fit in one page. So we can make sure the success of
+ * memory allocation. TODO: increase the limit. */
+#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
#define TUN_FLOW_EXPIRE (3 * HZ)
@@ -1583,6 +1582,8 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
else {
char *name;
unsigned long flags = 0;
+ int queues = ifr->ifr_flags & IFF_MULTI_QUEUE ?
+ MAX_TAP_QUEUES : 1;
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
return -EPERM;
@@ -1606,8 +1607,8 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
name = ifr->ifr_name;
dev = alloc_netdev_mqs(sizeof(struct tun_struct), name,
- tun_setup,
- MAX_TAP_QUEUES, MAX_TAP_QUEUES);
+ tun_setup, queues, queues);
+
if (!dev)
return -ENOMEM;
--
1.7.1
^ permalink raw reply related
* [PATCH] net: ks8851: convert to threaded IRQ
From: Felipe Balbi @ 2013-01-23 13:51 UTC (permalink / raw)
To: davem; +Cc: sboyd, mjr, netdev, Felipe Balbi
just as it should have been. It also helps
removing the, now unnecessary, workqueue.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/net/ethernet/micrel/ks8851.c | 41 ++++++++++--------------------------
1 file changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index 286816a..48ecb36 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -69,7 +69,6 @@ union ks8851_tx_hdr {
* @mii: The MII state information for the mii calls.
* @rxctrl: RX settings for @rxctrl_work.
* @tx_work: Work queue for tx packets
- * @irq_work: Work queue for servicing interrupts
* @rxctrl_work: Work queue for updating RX mode and multicast lists
* @txq: Queue of packets for transmission.
* @spi_msg1: pre-setup SPI transfer with one message, @spi_xfer1.
@@ -121,7 +120,6 @@ struct ks8851_net {
struct ks8851_rxctrl rxctrl;
struct work_struct tx_work;
- struct work_struct irq_work;
struct work_struct rxctrl_work;
struct sk_buff_head txq;
@@ -444,23 +442,6 @@ static void ks8851_init_mac(struct ks8851_net *ks)
}
/**
- * ks8851_irq - device interrupt handler
- * @irq: Interrupt number passed from the IRQ handler.
- * @pw: The private word passed to register_irq(), our struct ks8851_net.
- *
- * Disable the interrupt from happening again until we've processed the
- * current status by scheduling ks8851_irq_work().
- */
-static irqreturn_t ks8851_irq(int irq, void *pw)
-{
- struct ks8851_net *ks = pw;
-
- disable_irq_nosync(irq);
- schedule_work(&ks->irq_work);
- return IRQ_HANDLED;
-}
-
-/**
* ks8851_rdfifo - read data from the receive fifo
* @ks: The device state.
* @buff: The buffer address
@@ -595,19 +576,20 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
}
/**
- * ks8851_irq_work - work queue handler for dealing with interrupt requests
- * @work: The work structure that was scheduled by schedule_work()
+ * ks8851_irq - IRQ handler for dealing with interrupt requests
+ * @irq: IRQ number
+ * @_ks: cookie
*
- * This is the handler invoked when the ks8851_irq() is called to find out
- * what happened, as we cannot allow ourselves to sleep whilst waiting for
- * anything other process has the chip's lock.
+ * This handler is invoked when the IRQ line asserts to find out what happened.
+ * As we cannot allow ourselves to sleep in HARDIRQ context, this handler runs
+ * in thread context.
*
* Read the interrupt status, work out what needs to be done and then clear
* any of the interrupts that are not needed.
*/
-static void ks8851_irq_work(struct work_struct *work)
+static irqreturn_t ks8851_irq(int irq, void *_ks)
{
- struct ks8851_net *ks = container_of(work, struct ks8851_net, irq_work);
+ struct ks8851_net *ks = _ks;
unsigned status;
unsigned handled = 0;
@@ -688,7 +670,7 @@ static void ks8851_irq_work(struct work_struct *work)
if (status & IRQ_TXI)
netif_wake_queue(ks->netdev);
- enable_irq(ks->netdev->irq);
+ return IRQ_HANDLED;
}
/**
@@ -896,7 +878,6 @@ static int ks8851_net_stop(struct net_device *dev)
mutex_unlock(&ks->lock);
/* stop any outstanding work */
- flush_work(&ks->irq_work);
flush_work(&ks->tx_work);
flush_work(&ks->rxctrl_work);
@@ -1438,7 +1419,6 @@ static int ks8851_probe(struct spi_device *spi)
spin_lock_init(&ks->statelock);
INIT_WORK(&ks->tx_work, ks8851_tx_work);
- INIT_WORK(&ks->irq_work, ks8851_irq_work);
INIT_WORK(&ks->rxctrl_work, ks8851_rxctrl_work);
/* initialise pre-made spi transfer messages */
@@ -1505,7 +1485,8 @@ static int ks8851_probe(struct spi_device *spi)
ks8851_read_selftest(ks);
ks8851_init_mac(ks);
- ret = request_irq(spi->irq, ks8851_irq, IRQF_TRIGGER_LOW,
+ ret = request_threaded_irq(spi->irq, NULL, ks8851_irq,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
ndev->name, ks);
if (ret < 0) {
dev_err(&spi->dev, "failed to get irq\n");
--
1.8.1.rc1.5.g7e0651a
^ permalink raw reply related
* Re: [PATCH 1/2 net-next] net: fec: add napi support to improve proformance
From: Eric Dumazet @ 2013-01-23 13:49 UTC (permalink / raw)
To: Frank Li
Cc: Frank Li, shawn.guo, B38611, davem, linux-arm-kernel, netdev,
bhutchings, s.hauer
In-Reply-To: <CAHrpEqTqSfBCpoMZ9S81VoXWgVK1iOR+e2OasARgbTD8m_RRvw@mail.gmail.com>
On Wed, 2013-01-23 at 15:37 +0800, Frank Li wrote:
> 2013/1/23 Eric Dumazet <eric.dumazet@gmail.com>:
> > On Wed, 2013-01-23 at 12:12 +0800, Frank Li wrote:
> >> Add napi support
> >>
> >> Before this patch
> >>
> >> iperf -s -i 1
> >> ------------------------------------------------------------
> >> Server listening on TCP port 5001
> >> TCP window size: 85.3 KByte (default)
> >> ------------------------------------------------------------
> >> [ 4] local 10.192.242.153 port 5001 connected with 10.192.242.138 port 50004
> >> [ ID] Interval Transfer Bandwidth
> >> [ 4] 0.0- 1.0 sec 41.2 MBytes 345 Mbits/sec
> >> [ 4] 1.0- 2.0 sec 43.7 MBytes 367 Mbits/sec
> >> [ 4] 2.0- 3.0 sec 42.8 MBytes 359 Mbits/sec
> >> [ 4] 3.0- 4.0 sec 43.7 MBytes 367 Mbits/sec
> >> [ 4] 4.0- 5.0 sec 42.7 MBytes 359 Mbits/sec
> >> [ 4] 5.0- 6.0 sec 43.8 MBytes 367 Mbits/sec
> >> [ 4] 6.0- 7.0 sec 43.0 MBytes 361 Mbits/sec
> >>
> >> After this patch
> >> [ 4] 2.0- 3.0 sec 51.6 MBytes 433 Mbits/sec
> >> [ 4] 3.0- 4.0 sec 51.8 MBytes 435 Mbits/sec
> >> [ 4] 4.0- 5.0 sec 52.2 MBytes 438 Mbits/sec
> >> [ 4] 5.0- 6.0 sec 52.1 MBytes 437 Mbits/sec
> >> [ 4] 6.0- 7.0 sec 52.1 MBytes 437 Mbits/sec
> >> [ 4] 7.0- 8.0 sec 52.3 MBytes 439 Mbits/sec
> >
> > Strange, as you still call netif_rx()
> >
> > NAPI should call netif_receive_skb() instead
> >
>
> Thank you point out.
> After re-test, I found performance is almost no change if use netif_receive_skb.
> I am not sure if it is my NAPI implement problem.
>
> napi_gro_received is better than netif_receive_skb, but worse than netif_rx.
>
> From performance point view,
>
> netif_rx --- fastest
> napi_gro_received --- middle, near to netif_rx
> netif_receive_skb --- slowest, almost the same as original no-napi version.
>
> Do you have any idea about this phenomena?
No idea, you'll have to find out using perf tool if available.
Is your machine SMP, and the application running on another cpu than the
softirq handler for your device ?
A NAPI driver must call netif_receive_skb(), especially if
the RX path does a full copy of the frame : Its hot in cpu cache and
should be processed at once.
Escaping to netif_rx() is only adding an extra softirq and risk of data
being evicted from cpu caches.
Here your performance increase only comes from hw_lock being not anymore
locked in RX path.
^ permalink raw reply
* Re: [PATCH] sctp: set association state to established in dupcook_a handler
From: Neil Horman @ 2013-01-23 13:46 UTC (permalink / raw)
To: xufengzhang.main; +Cc: vyasevich, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <1358926720-25557-1-git-send-email-xufengzhang.main@gmail.com>
On Wed, Jan 23, 2013 at 03:38:40PM +0800, xufengzhang.main@gmail.com wrote:
> From: Xufeng Zhang <xufeng.zhang@windriver.com>
>
> While sctp handling a duplicate COOKIE-ECHO and the action is
> 'Association restart', sctp_sf_do_dupcook_a() will processing
> the unexpected COOKIE-ECHO for peer restart, but it does not set
> the association state to SCTP_STATE_ESTABLISHED, so the association
> could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
> This violates the sctp specification:
> RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
> Action
> A) In this case, the peer may have restarted. .....
> After this, the endpoint shall enter the ESTABLISHED state.
>
> Fix this problem by adding a SCTP_CMD_NEW_STATE cmd to the command
> list so as to set the restart association to SCTP_STATE_ESTABLISHED
> state properly.
>
> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
> ---
> net/sctp/sm_statefuns.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 618ec7e..528f1c8 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -1779,6 +1779,8 @@ static sctp_disposition_t sctp_sf_do_dupcook_a(struct net *net,
>
> /* Update the content of current association. */
> sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(new_asoc));
> + sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
> + SCTP_STATE(SCTP_STATE_ESTABLISHED));
> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
> return SCTP_DISPOSITION_CONSUME;
> --
> 1.7.0.2
>
>
Looks reasonable to me, thanks
nit: The RFC indicate the association should enter the ESTABLISHED state after
preforming all other actions, so it seems that the state change should occur
after the ULP event is sent
Neil
^ permalink raw reply
* Re: tun mq failure
From: Jason Wang @ 2013-01-23 13:20 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev
In-Reply-To: <20130123131845.GB18276@redhat.com>
On 01/23/2013 09:18 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 23, 2013 at 08:08:07PM +0800, Jason Wang wrote:
>> On 01/23/2013 07:06 PM, Hannes Frederic Sowa wrote:
>>> On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
>>>> This is when trying to start a VPN using some old openvpn binary so MQ
>>>> is not set.
>>>>
>>>> So
>>>> 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
>>>> 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
>>>> memory. This is quite likely to fail.
>>>> Let's start with a small limit on number of queues, like 8?
>>>> Then we know it will succeed.
>>>> Longer term we might want to solve it differently.
>>> This has been come up before:
>>> http://thread.gmane.org/gmane.linux.network/255647/focus=255902
>>>
>>> I think a solution to this problem is still outstanding.
>>>
>> I draft a patch in the reply of in that thread, but didn't get feedback
>> from reporter.
> Yes it's essentialy same.
> So can you please submit an official patch with proper
> subject commit log and signature?
Ok, will post the patch soon.
^ permalink raw reply
* [PATCH 2/2] ninfod: Make -v exit correctly.
From: Jan Synacek @ 2013-01-23 13:37 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
In-Reply-To: <1358948265-20867-1-git-send-email-jsynacek@redhat.com>
Signed-off-by: Jan Synacek <jsynacek@redhat.com>
---
ninfod/ninfod.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/ninfod/ninfod.c b/ninfod/ninfod.c
index 58b15aa..52cf446 100644
--- a/ninfod/ninfod.c
+++ b/ninfod/ninfod.c
@@ -639,12 +639,15 @@ int main (int argc, char **argv)
parse_args(argc, argv);
- if (opt_h || opt_v)
- print_copying();
if (opt_h) {
+ print_copying();
print_usage();
exit(1);
}
+ if (opt_v) {
+ print_copying();
+ return 0;
+ }
limit_capabilities();
--
1.8.1
^ permalink raw reply related
* [PATCH 1/2] ninfod: Call limit/drop_capabilities() and open_sock() after checking for -h or -v.
From: Jan Synacek @ 2013-01-23 13:37 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
In-Reply-To: <1358948265-20867-1-git-send-email-jsynacek@redhat.com>
Signed-off-by: Jan Synacek <jsynacek@redhat.com>
---
ninfod/ninfod.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/ninfod/ninfod.c b/ninfod/ninfod.c
index d1b99d9..58b15aa 100644
--- a/ninfod/ninfod.c
+++ b/ninfod/ninfod.c
@@ -637,16 +637,8 @@ int main (int argc, char **argv)
appname = argv[0];
- limit_capabilities();
-
- sock = open_sock();
- if (sock < 0)
- sock_errno = errno;
-
parse_args(argc, argv);
- drop_capabilities();
-
if (opt_h || opt_v)
print_copying();
if (opt_h) {
@@ -654,6 +646,14 @@ int main (int argc, char **argv)
exit(1);
}
+ limit_capabilities();
+
+ sock = open_sock();
+ if (sock < 0)
+ sock_errno = errno;
+
+ drop_capabilities();
+
if (sock_errno) {
DEBUG(LOG_ERR, "socket: %s\n", strerror(sock_errno));
exit(1);
--
1.8.1
^ permalink raw reply related
* [PATCH 0/2] iputils: ninfod minor changes
From: Jan Synacek @ 2013-01-23 13:37 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
Functions limiting capabilities as well as opening a socket could have been
called needlessly if ninfod was invoked with -h.
Also, ninfod incorrectly kept running if invoked with -v.
Jan Synacek (2):
ninfod: Call limit/drop_capabilities() and open_sock() after checking
for -h or -v.
ninfod: Make -v exit correctly.
ninfod/ninfod.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--
1.8.1
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-23 13:35 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <50FF8DEC.9070901-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Tue, 2013-01-22 at 23:14 -0800, Ben Greear wrote:
> How are the non-ref-counted dst objects used safely? Any chance
> that tearing down the IP protocol on a device (or deleting a device)
> could delete a dst that is referenced by an skb (and thus crashes as
> I see)?
There is probably a bug. Normally it should be RCU protected.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: v3 for tcp friends?
From: Weiping Pan @ 2013-01-23 13:16 UTC (permalink / raw)
To: Li Yu; +Cc: netdev, David Miller, Eric Dumazet, Bruce Curtis
In-Reply-To: <50FFB2D2.4050603@gmail.com>
On 01/23/2013 05:52 PM, Li Yu wrote:
> 于 2013年01月23日 17:39, Li Yu 写道:
>> 于 2013年01月23日 15:58, Li Yu 写道:
>>> 于 2013年01月23日 15:21, Li Yu 写道:
>>>> 于 2013年01月23日 14:46, Eric Dumazet 写道:
>>>>> On Wed, 2013-01-23 at 14:12 +0800, Li Yu wrote:
>>>>>> Oops, this hang is not since TCP friends patch!
>>>>>>
>>>>>> sk_sndbuf_get() is broken by 32 bits integer overflow
>>>>>> because of so large value in net.ipv4.tcp_{rmem,wmem}.
>>>>>>
>>>>>> but this hang also can be found in net-next.git
>>>>>> (3.8.0-rc3+), if we run below commands, then all new
>>>>>> TCP connections stop working!
>>>>>>
>>>>>> # when TCP friends is disabled
>>>>>> sysctl -w net.ipv4.tcp_rmem="4096 4294967296 4294967296" # 4GB
>>>>>> sysctl -w net.ipv4.tcp_wmem="4096 4294967296 4294967296"
>>>>>
>>>>> Right we need to make sure we dont overflow.
>>>>>
>>>>> Try the following fix :
>>>>>
>>>>> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
>>>>> index a25e1d2..1459145 100644
>>>>> --- a/net/ipv4/sysctl_net_ipv4.c
>>>>> +++ b/net/ipv4/sysctl_net_ipv4.c
>>>>> @@ -549,14 +549,16 @@ static struct ctl_table ipv4_table[] = {
>>>>> .data = &sysctl_tcp_wmem,
>>>>> .maxlen = sizeof(sysctl_tcp_wmem),
>>>>> .mode = 0644,
>>>>> - .proc_handler = proc_dointvec
>>>>> + .extra1 = &zero,
>>
>> If we added below:
>>
>> +static int one = 1;
>> +static int int_max = INT_MAX;
>> ....
>> + .extra1 = &one,
>> + .extra2 = &int_max,
>>
>
> The "int_max" may be unnecessary here :)
Hi, Li Yu,
I tested that your patch works fine.
Can you post a complete patch ?
thanks
Weiping Pan
^ permalink raw reply
* Re: tun mq failure
From: Michael S. Tsirkin @ 2013-01-23 13:18 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev
In-Reply-To: <50FFD2A7.6010402@redhat.com>
On Wed, Jan 23, 2013 at 08:08:07PM +0800, Jason Wang wrote:
> On 01/23/2013 07:06 PM, Hannes Frederic Sowa wrote:
> > On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
> >> This is when trying to start a VPN using some old openvpn binary so MQ
> >> is not set.
> >>
> >> So
> >> 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
> >> 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
> >> memory. This is quite likely to fail.
> >> Let's start with a small limit on number of queues, like 8?
> >> Then we know it will succeed.
> >> Longer term we might want to solve it differently.
> > This has been come up before:
> > http://thread.gmane.org/gmane.linux.network/255647/focus=255902
> >
> > I think a solution to this problem is still outstanding.
> >
> I draft a patch in the reply of in that thread, but didn't get feedback
> from reporter.
Yes it's essentialy same.
So can you please submit an official patch with proper
subject commit log and signature?
^ permalink raw reply
* Re: tun mq failure
From: Michael S. Tsirkin @ 2013-01-23 13:18 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev
In-Reply-To: <50FFD33B.2090103@redhat.com>
On Wed, Jan 23, 2013 at 08:10:35PM +0800, Jason Wang wrote:
> On 01/23/2013 07:41 PM, Michael S. Tsirkin wrote:
> > On Wed, Jan 23, 2013 at 12:06:40PM +0100, Hannes Frederic Sowa wrote:
> >> On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
> >>> This is when trying to start a VPN using some old openvpn binary so MQ
> >>> is not set.
> >>>
> >>> So
> >>> 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
> >>> 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
> >>> memory. This is quite likely to fail.
> >>> Let's start with a small limit on number of queues, like 8?
> >>> Then we know it will succeed.
> >>> Longer term we might want to solve it differently.
> >> This has been come up before:
> >> http://thread.gmane.org/gmane.linux.network/255647/focus=255902
> >>
> >> I think a solution to this problem is still outstanding.
> > Right. What (at least I) missed is that it's the
> > queue array allocation that fails here.
> > So I think something like the following will sort the first issue
> > (compiled only):
> >
> > For the second, for 3.8 maybe the prudent thing to do is
> > to set MAX_TAP_QUEUES to a small value, like 8, to avoid
> > userspace relying on a large number of queues being available,
> > and look at a better way to do this longer term, like
> > using an array of pointers.
>
> Sure, this is just the method I reply in that thread. Not sure 8 is the
> best, but since it fit into one page, should be ok. Maybe we can use
> flex array to avoid high order memory allocation in the longer term.
Right so let's for now use DEFAULT_MAX_NUM_RSS_QUEUES as Eric suggested.
> >
> > --->
> >
> > tun: don't waste memory on unused queues
> >
> > If MQ flag is off, we never attach more than 1 queue.
> > So let's not allocate memory for the unused ones.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ---
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index af372d0..813d303 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -1577,6 +1577,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> > else {
> > char *name;
> > unsigned long flags = 0;
> > + unsigned int max_tap_queues;
> >
> > if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> > return -EPERM;
> > @@ -1599,9 +1600,13 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> > if (*ifr->ifr_name)
> > name = ifr->ifr_name;
> >
> > + if (ifr->ifr_flags & IFF_MULTI_QUEUE)
> > + max_tap_queues = MAX_TAP_QUEUES;
> > + else
> > + max_tap_queues = 1;
> > dev = alloc_netdev_mqs(sizeof(struct tun_struct), name,
> > tun_setup,
> > - MAX_TAP_QUEUES, MAX_TAP_QUEUES);
> > + max_tap_queues, max_tap_queues);
> > if (!dev)
> > return -ENOMEM;
> >
^ permalink raw reply
* [RFC PATCH v3 linux-next] et131x: Promote staging et131x driver to drivers/net
From: Mark Einon @ 2013-01-23 12:45 UTC (permalink / raw)
To: davem, gregkh, sfr; +Cc: netdev, devel, linux-kernel, dan.carpenter, Mark Einon
In-Reply-To: <1358935859-29525-1-git-send-email-mark.einon@gmail.com>
This patch moves the et131x gigabit ethernet driver from drivers/staging
to drivers/net/ethernet/agere.
All the existing issues noted for this driver have been resolved, apart
from one performance issue where some fragmented packets suffer from
frame receive errors.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
Changes from V2 - vendor name changed from Atheros to Agere in drivers/net/ethernet/agere/Kconfig
MAINTAINERS | 11 ++++---
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/agere/Kconfig | 32 ++++++++++++++++++++
.../et131x => net/ethernet/agere}/Makefile | 1 +
.../et131x => net/ethernet/agere}/et131x.c | 0
.../et131x => net/ethernet/agere}/et131x.h | 0
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/staging/et131x/Kconfig | 10 ------
drivers/staging/et131x/README | 16 ----------
11 files changed, 41 insertions(+), 34 deletions(-)
create mode 100644 drivers/net/ethernet/agere/Kconfig
rename drivers/{staging/et131x => net/ethernet/agere}/Makefile (98%)
rename drivers/{staging/et131x => net/ethernet/agere}/et131x.c (100%)
rename drivers/{staging/et131x => net/ethernet/agere}/et131x.h (100%)
delete mode 100644 drivers/staging/et131x/Kconfig
delete mode 100644 drivers/staging/et131x/README
diff --git a/MAINTAINERS b/MAINTAINERS
index e80447a..cb09e9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3029,6 +3029,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
F: drivers/video/s1d13xxxfb.c
F: include/video/s1d13xxxfb.h
+ET131X NETWORK DRIVER
+M: Mark Einon <mark.einon@gmail.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/ethernet/agere
+
ETHEREXPRESS-16 NETWORK DRIVER
M: Philip Blundell <philb@gnu.org>
L: netdev@vger.kernel.org
@@ -7473,11 +7479,6 @@ M: David Rowe <david@rowetel.com>
S: Odd Fixes
F: drivers/staging/echo/
-STAGING - ET131X NETWORK DRIVER
-M: Mark Einon <mark.einon@gmail.com>
-S: Odd Fixes
-F: drivers/staging/et131x/
-
STAGING - FLARION FT1000 DRIVERS
M: Marek Belisko <marek.belisko@gmail.com>
S: Odd Fixes
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index ed956e0..4b4edbb 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -20,6 +20,7 @@ config SUNGEM_PHY
source "drivers/net/ethernet/3com/Kconfig"
source "drivers/net/ethernet/adaptec/Kconfig"
source "drivers/net/ethernet/aeroflex/Kconfig"
+source "drivers/net/ethernet/agere/Kconfig"
source "drivers/net/ethernet/alteon/Kconfig"
source "drivers/net/ethernet/amd/Kconfig"
source "drivers/net/ethernet/apple/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..7a96adb 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_VENDOR_3COM) += 3com/
obj-$(CONFIG_NET_VENDOR_8390) += 8390/
obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
obj-$(CONFIG_GRETH) += aeroflex/
+obj-$(CONFIG_NET_VENDOR_AGERE) += agere/
obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
obj-$(CONFIG_NET_VENDOR_AMD) += amd/
obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
diff --git a/drivers/net/ethernet/agere/Kconfig b/drivers/net/ethernet/agere/Kconfig
new file mode 100644
index 0000000..efe0b90
--- /dev/null
+++ b/drivers/net/ethernet/agere/Kconfig
@@ -0,0 +1,32 @@
+#
+# Agere device configuration
+#
+
+config NET_VENDOR_AGERE
+ bool "Agere devices"
+ default y
+ depends on PCI
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about Agere devices. If you say Y, you will be asked
+ for your specific card in the following questions.
+
+if NET_VENDOR_AGERE
+
+config ET131X
+ tristate "Agere ET-1310 Gigabit Ethernet support"
+ depends on PCI
+ select PHYLIB
+ ---help---
+ This driver supports Agere ET-1310 ethernet adapters.
+
+ To compile this driver as a module, choose M here. The module
+ will be called et131x.
+
+endif # NET_VENDOR_AGERE
+
diff --git a/drivers/staging/et131x/Makefile b/drivers/net/ethernet/agere/Makefile
similarity index 98%
rename from drivers/staging/et131x/Makefile
rename to drivers/net/ethernet/agere/Makefile
index 027ff94..740f413 100644
--- a/drivers/staging/et131x/Makefile
+++ b/drivers/net/ethernet/agere/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_ET131X) += et131x.o
+
diff --git a/drivers/staging/et131x/et131x.c b/drivers/net/ethernet/agere/et131x.c
similarity index 100%
rename from drivers/staging/et131x/et131x.c
rename to drivers/net/ethernet/agere/et131x.c
diff --git a/drivers/staging/et131x/et131x.h b/drivers/net/ethernet/agere/et131x.h
similarity index 100%
rename from drivers/staging/et131x/et131x.h
rename to drivers/net/ethernet/agere/et131x.h
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 0b47a06..5dee726 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -24,8 +24,6 @@ menuconfig STAGING
if STAGING
-source "drivers/staging/et131x/Kconfig"
-
source "drivers/staging/slicoss/Kconfig"
source "drivers/staging/usbip/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index b026ea3..6983d77 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -5,7 +5,6 @@ obj-$(CONFIG_STAGING) += staging.o
obj-y += media/
obj-y += net/
-obj-$(CONFIG_ET131X) += et131x/
obj-$(CONFIG_SLICOSS) += slicoss/
obj-$(CONFIG_USBIP_CORE) += usbip/
obj-$(CONFIG_W35UND) += winbond/
diff --git a/drivers/staging/et131x/Kconfig b/drivers/staging/et131x/Kconfig
deleted file mode 100644
index 8190f2a..0000000
--- a/drivers/staging/et131x/Kconfig
+++ /dev/null
@@ -1,10 +0,0 @@
-config ET131X
- tristate "Agere ET-1310 Gigabit Ethernet support"
- depends on PCI && NET && NETDEVICES
- select PHYLIB
- default n
- ---help---
- This driver supports Agere ET-1310 ethernet adapters.
-
- To compile this driver as a module, choose M here. The module
- will be called et131x.
diff --git a/drivers/staging/et131x/README b/drivers/staging/et131x/README
deleted file mode 100644
index 38537d4..0000000
--- a/drivers/staging/et131x/README
+++ /dev/null
@@ -1,16 +0,0 @@
-This is a driver for the ET1310 network device.
-
-Based on the driver found at https://sourceforge.net/projects/et131x/
-
-Cleaned up immensely by Olaf Hartman and Christoph Hellwig <hch@infradead.org>
-
-Note, the powermanagement options were removed from the vendor provided
-driver as they did not build properly at the time.
-
-TODO:
- - some rx packets have CRC/code/frame errors
-
-Please send patches to:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Mark Einon <mark.einon@gmail.com>
-
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3] crypto: add support for the NIST CMAC hash
From: Tom St Denis @ 2013-01-23 12:43 UTC (permalink / raw)
To: steffen klassert; +Cc: linux-kernel, netdev, Herbert Xu, David Miller
In-Reply-To: <793795323.107470.1358944861780.JavaMail.root@elliptictech.com>
Signed-off-by: Tom St Denis <tstdenis@elliptictech.com>
---
crypto/Kconfig | 9 ++
crypto/Makefile | 1 +
crypto/cmac.c | 317 +++++++++++++++++++++++++++++++++++++++++++
crypto/testmgr.c | 9 ++
crypto/testmgr.h | 52 +++++++
include/uapi/linux/pfkeyv2.h | 1 +
net/xfrm/xfrm_algo.c | 17 +++
7 files changed, 406 insertions(+)
create mode 100644 crypto/cmac.c
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4641d95..7ab11a9 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -301,6 +301,15 @@ config CRYPTO_XCBC
http://csrc.nist.gov/encryption/modes/proposedmodes/
xcbc-mac/xcbc-mac-spec.pdf
+config CRYPTO_CMAC
+ tristate "CMAC support"
+ select CRYPTO_HASH
+ select CRYPTO_MANAGER
+ help
+ NIST CMAC cipher based MAC algorithm
+ http://tools.ietf.org/rfc/rfc4494.txt
+ http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
+
config CRYPTO_VMAC
tristate "VMAC support"
depends on EXPERIMENTAL
diff --git a/crypto/Makefile b/crypto/Makefile
index d59dec7..85a615d 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_CRYPTO_USER) += crypto_user.o
obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
obj-$(CONFIG_CRYPTO_VMAC) += vmac.o
obj-$(CONFIG_CRYPTO_XCBC) += xcbc.o
+obj-$(CONFIG_CRYPTO_CMAC) += cmac.o
obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o
obj-$(CONFIG_CRYPTO_MD4) += md4.o
obj-$(CONFIG_CRYPTO_MD5) += md5.o
diff --git a/crypto/cmac.c b/crypto/cmac.c
new file mode 100644
index 0000000..1ffeea7
--- /dev/null
+++ b/crypto/cmac.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright (C)2006 USAGI/WIDE Project
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author:
+ * Tom St Denis <tstdenis@elliptictech.com>
+ *
+ * Derived from the XCBC code of:
+ * Kazunori Miyazawa <miyazawa@linux-ipv6.org>
+ */
+
+#include <crypto/internal/hash.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+/*
+ * +------------------------
+ * | <parent tfm>
+ * +------------------------
+ * | cmac_tfm_ctx
+ * +------------------------
+ * | consts (block size * 2)
+ * +------------------------
+ */
+struct cmac_tfm_ctx {
+ struct crypto_cipher *child;
+ u8 ctx[];
+};
+
+/*
+ * +------------------------
+ * | <shash desc>
+ * +------------------------
+ * | cmac_desc_ctx
+ * +------------------------
+ * | odds (block size)
+ * +------------------------
+ * | prev (block size)
+ * +------------------------
+ */
+struct cmac_desc_ctx {
+ unsigned int len;
+ u8 ctx[];
+};
+
+static int crypto_cmac_digest_setkey(struct crypto_shash *parent,
+ const u8 *inkey, unsigned int keylen)
+{
+ unsigned long alignmask = crypto_shash_alignmask(parent);
+ struct cmac_tfm_ctx *ctx = crypto_shash_ctx(parent);
+ int bs = crypto_shash_blocksize(parent);
+ u8 *consts = PTR_ALIGN(&ctx->ctx[0], alignmask + 1);
+ int x, y, err = 0;
+ u8 msb, mask;
+
+ switch (bs) {
+ case 16:
+ mask = 0x87;
+ break;
+ case 8:
+ mask = 0x1B;
+ break;
+ default:
+ return -EINVAL; /* only support 64/128 bit block ciphers */
+ }
+
+ err = crypto_cipher_setkey(ctx->child, inkey, keylen);
+ if (err)
+ return err;
+
+ /* encrypt the zero block */
+ memset(consts, 0, bs);
+ crypto_cipher_encrypt_one(ctx->child, consts, consts);
+
+ for (x = 0; x < 2; x++) {
+ /* if msb(L * u^(x+1)) = 0 then just shift,
+ otherwise shift and xor constant mask */
+ msb = consts[x*bs + 0] >> 7;
+
+ /* shift left */
+ for (y = 0; y < (bs - 1); y++)
+ consts[x*bs + y] =
+ ((consts[x*bs + y] << 1) |
+ (consts[x*bs + y+1] >> 7)) & 255;
+
+ consts[x*bs + bs - 1] =
+ ((consts[x*bs + bs - 1] << 1) ^
+ (msb ? mask : 0)) & 255;
+
+ /* copy up as require */
+ if (x == 0)
+ memcpy(&consts[(x+1)*bs], &consts[x*bs], bs);
+ }
+ return 0;
+}
+
+static int crypto_cmac_digest_init(struct shash_desc *pdesc)
+{
+ unsigned long alignmask = crypto_shash_alignmask(pdesc->tfm);
+ struct cmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
+ int bs = crypto_shash_blocksize(pdesc->tfm);
+ u8 *prev = PTR_ALIGN(&ctx->ctx[0], alignmask + 1) + bs;
+
+ ctx->len = 0;
+ memset(prev, 0, bs);
+
+ return 0;
+}
+
+static int crypto_cmac_digest_update(struct shash_desc *pdesc, const u8 *p,
+ unsigned int len)
+{
+ struct crypto_shash *parent = pdesc->tfm;
+ unsigned long alignmask = crypto_shash_alignmask(parent);
+ struct cmac_tfm_ctx *tctx = crypto_shash_ctx(parent);
+ struct cmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
+ struct crypto_cipher *tfm = tctx->child;
+ int bs = crypto_shash_blocksize(parent);
+ u8 *odds = PTR_ALIGN(&ctx->ctx[0], alignmask + 1);
+ u8 *prev = odds + bs;
+
+ /* checking the data can fill the block */
+ if ((ctx->len + len) <= bs) {
+ memcpy(odds + ctx->len, p, len);
+ ctx->len += len;
+ return 0;
+ }
+
+ /* filling odds with new data and encrypting it */
+ memcpy(odds + ctx->len, p, bs - ctx->len);
+ len -= bs - ctx->len;
+ p += bs - ctx->len;
+
+ crypto_xor(prev, odds, bs);
+ crypto_cipher_encrypt_one(tfm, prev, prev);
+
+ /* clearing the length */
+ ctx->len = 0;
+
+ /* encrypting the rest of data */
+ while (len > bs) {
+ crypto_xor(prev, p, bs);
+ crypto_cipher_encrypt_one(tfm, prev, prev);
+ p += bs;
+ len -= bs;
+ }
+
+ /* keeping the surplus of blocksize */
+ if (len) {
+ memcpy(odds, p, len);
+ ctx->len = len;
+ }
+
+ return 0;
+}
+
+static int crypto_cmac_digest_final(struct shash_desc *pdesc, u8 *out)
+{
+ struct crypto_shash *parent = pdesc->tfm;
+ unsigned long alignmask = crypto_shash_alignmask(parent);
+ struct cmac_tfm_ctx *tctx = crypto_shash_ctx(parent);
+ struct cmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
+ struct crypto_cipher *tfm = tctx->child;
+ int bs = crypto_shash_blocksize(parent);
+ u8 *consts = PTR_ALIGN(&tctx->ctx[0], alignmask + 1);
+ u8 *odds = PTR_ALIGN(&ctx->ctx[0], alignmask + 1);
+ u8 *prev = odds + bs;
+ unsigned int offset = 0;
+
+ if (ctx->len != bs) {
+ unsigned int rlen;
+ u8 *p = odds + ctx->len;
+
+ *p = 0x80;
+ p++;
+
+ rlen = bs - ctx->len - 1;
+ if (rlen)
+ memset(p, 0, rlen);
+
+ offset += bs;
+ }
+
+ crypto_xor(prev, odds, bs);
+ crypto_xor(prev, consts + offset, bs);
+
+ crypto_cipher_encrypt_one(tfm, out, prev);
+
+ return 0;
+}
+
+static int cmac_init_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_cipher *cipher;
+ struct crypto_instance *inst = (void *)tfm->__crt_alg;
+ struct crypto_spawn *spawn = crypto_instance_ctx(inst);
+ struct cmac_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ cipher = crypto_spawn_cipher(spawn);
+ if (IS_ERR(cipher))
+ return PTR_ERR(cipher);
+
+ ctx->child = cipher;
+
+ return 0;
+};
+
+static void cmac_exit_tfm(struct crypto_tfm *tfm)
+{
+ struct cmac_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ crypto_free_cipher(ctx->child);
+}
+
+static int cmac_create(struct crypto_template *tmpl, struct rtattr **tb)
+{
+ struct shash_instance *inst;
+ struct crypto_alg *alg;
+ unsigned long alignmask;
+ int err;
+
+ err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_SHASH);
+ if (err)
+ return err;
+
+ alg = crypto_get_attr_alg(tb, CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ return PTR_ERR(alg);
+
+ switch (alg->cra_blocksize) {
+ case 16:
+ break;
+ default:
+ goto out_put_alg;
+ }
+
+ inst = shash_alloc_instance("cmac", alg);
+ err = PTR_ERR(inst);
+ if (IS_ERR(inst))
+ goto out_put_alg;
+
+ err = crypto_init_spawn(shash_instance_ctx(inst), alg,
+ shash_crypto_instance(inst),
+ CRYPTO_ALG_TYPE_MASK);
+ if (err)
+ goto out_free_inst;
+
+ alignmask = alg->cra_alignmask | 3;
+ inst->alg.base.cra_alignmask = alignmask;
+ inst->alg.base.cra_priority = alg->cra_priority;
+ inst->alg.base.cra_blocksize = alg->cra_blocksize;
+
+ inst->alg.digestsize = alg->cra_blocksize;
+ inst->alg.descsize = ALIGN(sizeof(struct cmac_desc_ctx),
+ crypto_tfm_ctx_alignment()) +
+ (alignmask &
+ ~(crypto_tfm_ctx_alignment() - 1)) +
+ alg->cra_blocksize * 2;
+
+ inst->alg.base.cra_ctxsize = ALIGN(sizeof(struct cmac_tfm_ctx),
+ alignmask + 1) +
+ alg->cra_blocksize * 2;
+ inst->alg.base.cra_init = cmac_init_tfm;
+ inst->alg.base.cra_exit = cmac_exit_tfm;
+
+ inst->alg.init = crypto_cmac_digest_init;
+ inst->alg.update = crypto_cmac_digest_update;
+ inst->alg.final = crypto_cmac_digest_final;
+ inst->alg.setkey = crypto_cmac_digest_setkey;
+
+ err = shash_register_instance(tmpl, inst);
+ if (err) {
+out_free_inst:
+ shash_free_instance(shash_crypto_instance(inst));
+ }
+
+out_put_alg:
+ crypto_mod_put(alg);
+ return err;
+}
+
+static struct crypto_template crypto_cmac_tmpl = {
+ .name = "cmac",
+ .create = cmac_create,
+ .free = shash_free_instance,
+ .module = THIS_MODULE,
+};
+
+static int __init crypto_cmac_module_init(void)
+{
+ return crypto_register_template(&crypto_cmac_tmpl);
+}
+
+static void __exit crypto_cmac_module_exit(void)
+{
+ crypto_unregister_template(&crypto_cmac_tmpl);
+}
+
+module_init(crypto_cmac_module_init);
+module_exit(crypto_cmac_module_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("CMAC keyed hash algorithm");
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index edf4a08..6de7994 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2859,6 +2859,15 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "cmac(aes)",
+ .test = alg_test_hash,
+ .suite = {
+ .hash = {
+ .vecs = aes_cmac128_tv_template,
+ .count = CMAC_AES_TEST_VECTORS
+ }
+ }
+ }, {
.alg = "xcbc(aes)",
.test = alg_test_hash,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index b5721e0..9688bfe 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1639,6 +1639,58 @@ static struct hash_testvec hmac_sha256_tv_template[] = {
},
};
+#define CMAC_AES_TEST_VECTORS 4
+
+static struct hash_testvec aes_cmac128_tv_template[] = {
+ {
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6\xab"
+ "\xf7\x15\x88\x09\xcf\x4f\x3c",
+ .plaintext = zeroed_string,
+ .digest = "\xbb\x1d\x69\x29\xe9\x59\x37\x28\x7f"
+ "\xa3\x7d\x12\x9b\x75\x67\x46",
+ .psize = 0,
+ .ksize = 16,
+ },
+
+ {
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6\xab\xf7"
+ "\x15\x88\x09\xcf\x4f\x3c",
+ .plaintext = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96\xe9\x3d"
+ "\x7e\x11\x73\x93\x17\x2a",
+ .digest = "\x07\x0a\x16\xb4\x6b\x4d\x41\x44\xf7\x9b"
+ "\xdd\x9d\xd0\x4a\x28\x7c",
+ .psize = 16,
+ .ksize = 16,
+ },
+
+ {
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6\xab\xf7"
+ "\x15\x88\x09\xcf\x4f\x3c",
+ .plaintext = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96\xe9"
+ "\x3d\x7e\x11\x73\x93\x17"
+ "\x2a\xae\x2d\x8a\x57\x1e\x03\xac\x9c\x9e\xb7\x6f\xac\x45\xaf"
+ "\x8e\x51\x30\xc8\x1c\x46\xa3\x5c\xe4\x11",
+ .digest = "\xdf\xa6\x67\x47\xde\x9a\xe6\x30\x30\xca\x32"
+ "\x61\x14\x97\xc8\x27",
+ .psize = 40,
+ .ksize = 16,
+ },
+ {
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6\xab\xf7"
+ "\x15\x88\x09\xcf\x4f\x3c",
+ .plaintext = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96\xe9"
+ "\x3d\x7e\x11\x73\x93\x17"
+ "\x2a\xae\x2d\x8a\x57\x1e\x03\xac\x9c\x9e\xb7\x6f\xac\x45\xaf"
+ "\x8e\x51\x30\xc8\x1c\x46\xa3\x5c\xe4\x11\xe5\xfb\xc1\x19\x1a"
+ "\x0a\x52\xef\xf6\x9f\x24\x45\xdf\x4f\x9b\x17\xad\x2b\x41\x7b"
+ "\xe6\x6c\x37\x10",
+ .digest = "\x51\xf0\xbe\xbf\x7e\x3b\x9d\x92\xfc\x49\x74"
+ "\x17\x79\x36\x3c\xfe",
+ .psize = 64,
+ .ksize = 16,
+ },
+};
+
#define XCBC_AES_TEST_VECTORS 6
static struct hash_testvec aes_xcbc128_tv_template[] = {
diff --git a/include/uapi/linux/pfkeyv2.h b/include/uapi/linux/pfkeyv2.h
index 0b80c80..d61898e 100644
--- a/include/uapi/linux/pfkeyv2.h
+++ b/include/uapi/linux/pfkeyv2.h
@@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
#define SADB_X_AALG_SHA2_512HMAC 7
#define SADB_X_AALG_RIPEMD160HMAC 8
#define SADB_X_AALG_AES_XCBC_MAC 9
+#define SADB_X_AALG_AES_CMAC_MAC 10
#define SADB_X_AALG_NULL 251 /* kame */
#define SADB_AALG_MAX 251
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 4ce2d93..bd6f227 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -265,6 +265,23 @@ static struct xfrm_algo_desc aalg_list[] = {
}
},
{
+ .name = "cmac(aes)",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 96,
+ .icv_fullbits = 128,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_AES_CMAC_MAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 128,
+ .sadb_alg_maxbits = 128
+ }
+},
+{
.name = "xcbc(aes)",
.uinfo = {
--
1.8.1.rc2.6.g18499ba
^ permalink raw reply related
* Upcoming cross-tree build breakage on merge window
From: Rafał Miłecki @ 2013-01-23 12:13 UTC (permalink / raw)
To: john, ralf, David S. Miller
Cc: linux-mips, Network Development, Hauke Mehrtens
I've noticed possible build breakage when two trees get merged:
net-next and linux-john (MIPS).
This is about two following commits:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commit;h=dd4544f05469aaaeee891d7dc54d66430344321e
http://git.linux-mips.org/?p=john/linux-john.git;a=commit;h=a008ca117bc85a9d66c47cd5ab18a6c332411919
The first one adds "bgmac" driver which uses asm/mach-bcm47xx/nvram.h
and nvram_getenv. The second one renames them.
Can you handle this in some clever way during merge window, please?
The fix is trivial:
1) Use <bcm47xx_nvram.h>
2) Use bcm47xx_nvram_getenv
--
Rafał
^ permalink raw reply
* Re: tun mq failure
From: Jason Wang @ 2013-01-23 12:10 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev
In-Reply-To: <20130123114102.GA10426@redhat.com>
On 01/23/2013 07:41 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 23, 2013 at 12:06:40PM +0100, Hannes Frederic Sowa wrote:
>> On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
>>> This is when trying to start a VPN using some old openvpn binary so MQ
>>> is not set.
>>>
>>> So
>>> 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
>>> 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
>>> memory. This is quite likely to fail.
>>> Let's start with a small limit on number of queues, like 8?
>>> Then we know it will succeed.
>>> Longer term we might want to solve it differently.
>> This has been come up before:
>> http://thread.gmane.org/gmane.linux.network/255647/focus=255902
>>
>> I think a solution to this problem is still outstanding.
> Right. What (at least I) missed is that it's the
> queue array allocation that fails here.
> So I think something like the following will sort the first issue
> (compiled only):
>
> For the second, for 3.8 maybe the prudent thing to do is
> to set MAX_TAP_QUEUES to a small value, like 8, to avoid
> userspace relying on a large number of queues being available,
> and look at a better way to do this longer term, like
> using an array of pointers.
Sure, this is just the method I reply in that thread. Not sure 8 is the
best, but since it fit into one page, should be ok. Maybe we can use
flex array to avoid high order memory allocation in the longer term.
>
> --->
>
> tun: don't waste memory on unused queues
>
> If MQ flag is off, we never attach more than 1 queue.
> So let's not allocate memory for the unused ones.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index af372d0..813d303 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1577,6 +1577,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> else {
> char *name;
> unsigned long flags = 0;
> + unsigned int max_tap_queues;
>
> if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> return -EPERM;
> @@ -1599,9 +1600,13 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> if (*ifr->ifr_name)
> name = ifr->ifr_name;
>
> + if (ifr->ifr_flags & IFF_MULTI_QUEUE)
> + max_tap_queues = MAX_TAP_QUEUES;
> + else
> + max_tap_queues = 1;
> dev = alloc_netdev_mqs(sizeof(struct tun_struct), name,
> tun_setup,
> - MAX_TAP_QUEUES, MAX_TAP_QUEUES);
> + max_tap_queues, max_tap_queues);
> if (!dev)
> return -ENOMEM;
>
^ permalink raw reply
* Re: tun mq failure
From: Jason Wang @ 2013-01-23 12:08 UTC (permalink / raw)
To: Michael S. Tsirkin, netdev
In-Reply-To: <20130123110640.GC7005@order.stressinduktion.org>
On 01/23/2013 07:06 PM, Hannes Frederic Sowa wrote:
> On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
>> This is when trying to start a VPN using some old openvpn binary so MQ
>> is not set.
>>
>> So
>> 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
>> 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
>> memory. This is quite likely to fail.
>> Let's start with a small limit on number of queues, like 8?
>> Then we know it will succeed.
>> Longer term we might want to solve it differently.
> This has been come up before:
> http://thread.gmane.org/gmane.linux.network/255647/focus=255902
>
> I think a solution to this problem is still outstanding.
>
I draft a patch in the reply of in that thread, but didn't get feedback
from reporter.
^ permalink raw reply
* Re: Unix Socket buffer attribution
From: Cong Wang @ 2013-01-23 11:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAJ4BwwFZo=ktoNBpw14yxyvR1QPQ_xVzKRs=R7qv03g1uwn8pg@mail.gmail.com>
On Tue, 22 Jan 2013 at 02:01 GMT, Yannick Koehler <yannick@koehler.name> wrote:
>
> I believe that the problem is that once we move the skb into the
> client's receive queue we need to decrease the sk_wmem_alloc variable
> of the server socket since that skb is no more tied to the server.
> The code should then account for this memory as part of the
> sk_rmem_alloc variable on the client's socket. The function
> "skb_set_owner_r(skb,owner)" would seem to be the function to do that,
> so it would seem to me.
Something like below??
-------->
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 0c61236..e273072 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1205,6 +1205,7 @@ restart:
unix_state_unlock(sk);
+ skb_set_owner_r(skb, other);
/* take ten and and send info to listening sock */
spin_lock(&other->sk_receive_queue.lock);
__skb_queue_tail(&other->sk_receive_queue, skb);
@@ -1578,6 +1579,7 @@ restart:
if (sock_flag(other, SOCK_RCVTSTAMP))
__net_timestamp(skb);
+ skb_set_owner_r(skb, other);
maybe_add_creds(skb, sock, other);
skb_queue_tail(&other->sk_receive_queue, skb);
if (max_level > unix_sk(other)->recursion_level)
@@ -1693,6 +1695,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
(other->sk_shutdown & RCV_SHUTDOWN))
goto pipe_err_free;
+ skb_set_owner_r(skb, other);
maybe_add_creds(skb, sock, other);
skb_queue_tail(&other->sk_receive_queue, skb);
if (max_level > unix_sk(other)->recursion_level)
^ permalink raw reply related
* Re: tun mq failure
From: Michael S. Tsirkin @ 2013-01-23 11:41 UTC (permalink / raw)
To: Jason Wang, netdev
In-Reply-To: <20130123110640.GC7005@order.stressinduktion.org>
On Wed, Jan 23, 2013 at 12:06:40PM +0100, Hannes Frederic Sowa wrote:
> On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
> > This is when trying to start a VPN using some old openvpn binary so MQ
> > is not set.
> >
> > So
> > 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
> > 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
> > memory. This is quite likely to fail.
> > Let's start with a small limit on number of queues, like 8?
> > Then we know it will succeed.
> > Longer term we might want to solve it differently.
>
> This has been come up before:
> http://thread.gmane.org/gmane.linux.network/255647/focus=255902
>
> I think a solution to this problem is still outstanding.
Right. What (at least I) missed is that it's the
queue array allocation that fails here.
So I think something like the following will sort the first issue
(compiled only):
For the second, for 3.8 maybe the prudent thing to do is
to set MAX_TAP_QUEUES to a small value, like 8, to avoid
userspace relying on a large number of queues being available,
and look at a better way to do this longer term, like
using an array of pointers.
--->
tun: don't waste memory on unused queues
If MQ flag is off, we never attach more than 1 queue.
So let's not allocate memory for the unused ones.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index af372d0..813d303 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1577,6 +1577,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
else {
char *name;
unsigned long flags = 0;
+ unsigned int max_tap_queues;
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
return -EPERM;
@@ -1599,9 +1600,13 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (*ifr->ifr_name)
name = ifr->ifr_name;
+ if (ifr->ifr_flags & IFF_MULTI_QUEUE)
+ max_tap_queues = MAX_TAP_QUEUES;
+ else
+ max_tap_queues = 1;
dev = alloc_netdev_mqs(sizeof(struct tun_struct), name,
tun_setup,
- MAX_TAP_QUEUES, MAX_TAP_QUEUES);
+ max_tap_queues, max_tap_queues);
if (!dev)
return -ENOMEM;
^ permalink raw reply related
* Re: [RFC PATCH v2 linux-next] et131x: Promote staging et131x driver to drivers/net
From: Mark Einon @ 2013-01-23 11:31 UTC (permalink / raw)
To: Dan Carpenter; +Cc: davem, gregkh, sfr, devel, netdev, linux-kernel
In-Reply-To: <20130123103108.GA4584@mwanda>
On 23 January 2013 10:31, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Wed, Jan 23, 2013 at 10:10:58AM +0000, Mark Einon wrote:
>> diff --git a/drivers/net/ethernet/agere/Kconfig b/drivers/net/ethernet/agere/Kconfig
>> new file mode 100644
>> index 0000000..6854966
>> --- /dev/null
>> +++ b/drivers/net/ethernet/agere/Kconfig
>> @@ -0,0 +1,32 @@
>> +#
>> +# Agere device configuration
>> +#
>> +
>> +config NET_VENDOR_AGERE
>> + bool "Agere devices"
>> + default y
>> + depends on PCI
>> + ---help---
>> + If you have a network (Ethernet) card belonging to this class, say Y
>> + and read the Ethernet-HOWTO, available from
>> + <http://www.tldp.org/docs.html#howto>.
>> +
>> + Note that the answer to this question doesn't directly affect the
>> + kernel: saying N will just cause the configurator to skip all
>> + the questions about Atheros devices. If you say Y, you will be asked
> ^^^^^^^
> Agere?
Well spotted, thanks. I'll fix it asap.
>
>> + for your specific card in the following questions.
>> +
>
> I think you should just leave this block out entirely. It doesn't
> save time for anyone.
It looks to be standard boilerplate for all the net/ethernet drivers
having their own directory. I'm going to leave it in for now.
If that's an issue that needs a change, it would also affect the other
drivers and I think should be tackled as a separate thing.
Cheers,
Mark
^ permalink raw reply
* Re: tun mq failure
From: Hannes Frederic Sowa @ 2013-01-23 11:06 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, netdev
In-Reply-To: <20130123100516.GB8108@redhat.com>
On Wed, Jan 23, 2013 at 12:05:16PM +0200, Michael S. Tsirkin wrote:
> This is when trying to start a VPN using some old openvpn binary so MQ
> is not set.
>
> So
> 1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
> 2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
> memory. This is quite likely to fail.
> Let's start with a small limit on number of queues, like 8?
> Then we know it will succeed.
> Longer term we might want to solve it differently.
This has been come up before:
http://thread.gmane.org/gmane.linux.network/255647/focus=255902
I think a solution to this problem is still outstanding.
^ permalink raw reply
* [PATCH net] net: cdc_mbim: send ZLP only for the specific buggy device
From: Bjørn Mork @ 2013-01-23 10:57 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum, Greg Suarez,
Bjørn Mork, Alexey ORISHKO, Yauheni Kaliuta
Reverting 328d7b8 and instead adding an exception for the
Sierra Wireless MC7710.
commit 328d7b8 (net: cdc_mbim: send ZLP after max sized NTBs)
added a workaround for an issue observed on one specific device.
Concerns were raised that this workaround adds a performance
penalty to all devices based on questionable, if not buggy,
behaviour of a single device:
"If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU
load, increasing interrupt load by factor of 2 in high load traffic
scenario and possibly decreasing throughput for all other devices
which behaves correctly."
"The idea of NCM was to avoid extra ZLPs. If your transfer is exactly
dwNtbOutMaxSize, it's known, you can submit such request on the receiver
side and you do not need any EOT indicatation, so the frametime can be
used for useful data."
Adding a device specific exception to prevent the workaround from
affecting well behaved devices.
The assumption here is that needing a ZLP is truly an *exception*.
We do not yet have enough data to verify this. The generic
workaround in commit 328d7b8 should be considered acceptable despite
the performance penalty if the exception list becomes a maintainance
hassle.
Cc: Alexey ORISHKO <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Cc: Yauheni Kaliuta <y.kaliuta-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
Sorry about all the back and forth here. And as indicated in the commit
message, I am not guaranteeing this is the last round either...
I am not going to maintain an ever-growing exception list. My personal
accptance limit for such lists in a class driver is extremely low. I am
going to reconsider the original patch the next time a device wants this
specific workaround. And I fear that will happen really soon, based on
the facts that the device the issue in question
- is based on Qualcomm firmware,
- is commercially available now,
- is just one of a gazillion expected Qualcomm hardware/firmware based
MBIM devices on their way to a Linux computer near you...
Yes the firmware is of course buggy as hell. We don't expect anything
else. But it doesn't matter. If a significant number of MBIM devices
from a number of different vendors have the same bug, then we will do
what's needed to support them. Including accepting smaller performance
penalties not noticable to any end user. In fact not even measurable to
anyone without device firmware debugging tools.
But please let this go into 3.8 for now, and let us all hope I am wrong
this time too, as I often am :-)
Bjørn
drivers/net/usb/cdc_mbim.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 3a5673a..248d2dc 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -366,6 +366,21 @@ err:
static const struct driver_info cdc_mbim_info = {
.description = "CDC MBIM",
+ .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN,
+ .bind = cdc_mbim_bind,
+ .unbind = cdc_mbim_unbind,
+ .manage_power = cdc_mbim_manage_power,
+ .rx_fixup = cdc_mbim_rx_fixup,
+ .tx_fixup = cdc_mbim_tx_fixup,
+};
+
+/* MBIM and NCM devices should not need a ZLP after NTBs with
+ * dwNtbOutMaxSize length. This driver_info is for the exceptional
+ * devices requiring it anyway, allowing them to be supported without
+ * forcing the performance penalty on all the sane devices.
+ */
+static const struct driver_info cdc_mbim_info_zlp = {
+ .description = "CDC MBIM",
.flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN | FLAG_SEND_ZLP,
.bind = cdc_mbim_bind,
.unbind = cdc_mbim_unbind,
@@ -385,6 +400,10 @@ static const struct usb_device_id mbim_devs[] = {
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&cdc_mbim_info,
},
+ /* Sierra Wireless MC7710 need ZLPs */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68a2, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&cdc_mbim_info_zlp,
+ },
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&cdc_mbim_info,
},
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* tun mq failure
From: Michael S. Tsirkin @ 2013-01-23 10:05 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev
I see this with -rc3:
[531261.470349] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[531276.878261] openvpn: page allocation failure: order:7, mode:0x10c0d0
[531276.878270] Pid: 10421, comm: openvpn Tainted: G W
3.8.0-rc3-mst #216
[531276.878274] Call Trace:
[531276.878289] [<ffffffff8113c08b>] warn_alloc_failed+0xfb/0x180
[531276.878297] [<ffffffff8113e9a0>] ? page_alloc_cpu_notify+0x60/0x60
[531276.878303] [<ffffffff8113e9b6>] ? drain_local_pages+0x16/0x20
[531276.878312] [<ffffffff810c3823>] ? on_each_cpu_mask+0x53/0x70
[531276.878318] [<ffffffff8113f155>] __alloc_pages_nodemask+0x5a5/0x990
[531276.878329] [<ffffffff8117c2b8>] alloc_pages_current+0xe8/0x200
[531276.878334] [<ffffffff8113bf34>] __get_free_pages+0x14/0x50
[531276.878341] [<ffffffff811856bf>] kmalloc_order_trace+0x3f/0xb0
[531276.878347] [<ffffffff811888df>] __kmalloc+0x17f/0x190
[531276.878356] [<ffffffff8154e7f5>] alloc_netdev_mqs+0x155/0x300
[531276.878395] [<ffffffffa03761c0>] ? tun_chr_poll+0xf0/0xf0 [tun]
[531276.878420] [<ffffffffa037904c>] __tun_chr_ioctl+0xa6c/0x1080 [tun]
[531276.878440] [<ffffffffa0379694>] tun_chr_compat_ioctl+0x34/0x40
[tun]
[531276.878460] [<ffffffff811e8cad>] compat_sys_ioctl+0x10d/0x1520
[531276.878468] [<ffffffff81186f65>] ? kmem_cache_free+0x35/0x150
[531276.878476] [<ffffffff811a2456>] ? final_putname+0x26/0x50
[531276.878487] [<ffffffff810e51f3>] ? __audit_syscall_exit+0x1a3/0x2c0
[531276.878496] [<ffffffff8165d72c>] sysenter_dispatch+0x7/0x21
[531276.878501] Mem-Info:
[531276.878505] Node 0 DMA per-cpu:
[531276.878513] CPU 0: hi: 0, btch: 1 usd: 0
[531276.878517] CPU 1: hi: 0, btch: 1 usd: 0
[531276.878522] CPU 2: hi: 0, btch: 1 usd: 0
[531276.878526] CPU 3: hi: 0, btch: 1 usd: 0
[531276.878530] Node 0 DMA32 per-cpu:
[531276.878536] CPU 0: hi: 186, btch: 31 usd: 0
[531276.878540] CPU 1: hi: 186, btch: 31 usd: 0
[531276.878544] CPU 2: hi: 186, btch: 31 usd: 0
[531276.878549] CPU 3: hi: 186, btch: 31 usd: 0
[531276.878552] Node 0 Normal per-cpu:
[531276.878557] CPU 0: hi: 186, btch: 31 usd: 0
[531276.878561] CPU 1: hi: 186, btch: 31 usd: 0
[531276.878565] CPU 2: hi: 186, btch: 31 usd: 0
[531276.878570] CPU 3: hi: 186, btch: 31 usd: 0
[531276.878581] active_anon:295155 inactive_anon:139890 isolated_anon:0
[531276.878581] active_file:698789 inactive_file:703169 isolated_file:0
[531276.878581] unevictable:0 dirty:35015 writeback:105138 unstable:0
[531276.878581] free:39426 slab_reclaimable:76276
slab_unreclaimable:41668
[531276.878581] mapped:37045 shmem:141260 pagetables:4302 bounce:0
[531276.878581] free_cma:0
[531276.878593] Node 0 DMA free:15880kB min:128kB low:160kB high:192kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15640kB
managed:15896kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:16kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? yes
[531276.878609] lowmem_reserve[]: 0 3423 7933 7933
[531276.878618] Node 0 DMA32 free:81400kB min:29104kB low:36380kB
high:43656kB active_anon:214676kB inactive_anon:50704kB
active_file:1489740kB inactive_file:1496792kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:3505444kB
managed:3465472kB mlocked:0kB dirty:61408kB writeback:132556kB
mapped:73704kB shmem:50844kB slab_reclaimable:115032kB
slab_unreclaimable:33400kB kernel_stack:112kB pagetables:1052kB
unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
[531276.878645] lowmem_reserve[]: 0 0 4510 4510
[531276.878700] Node 0 Normal free:60424kB min:38348kB low:47932kB
high:57520kB active_anon:965944kB inactive_anon:508856kB
active_file:1305416kB inactive_file:1315884kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:4618656kB
managed:4559280kB mlocked:0kB dirty:78652kB writeback:287996kB
mapped:74476kB shmem:514196kB slab_reclaimable:190072kB
slab_unreclaimable:133256kB kernel_stack:2920kB pagetables:16156kB
unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
[531276.878721] lowmem_reserve[]: 0 0 0 0
[531276.878730] Node 0 DMA: 0*4kB 1*8kB (U) 0*16kB 0*32kB 2*64kB (U)
1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) =
15880kB
[531276.878762] Node 0 DMA32: 1464*4kB (UEMR) 1824*8kB (UEMR) 1051*16kB
(UEM) 833*32kB (EM) 252*64kB (UEM) 5*128kB (UEM) 4*256kB (E) 0*512kB
0*1024kB 0*2048kB 0*4096kB = 81712kB
[531276.878794] Node 0 Normal: 5035*4kB (UEM) 1907*8kB (UEM) 999*16kB
(UEM) 253*32kB (UEM) 8*64kB (EM) 4*128kB (EM) 1*256kB (M) 0*512kB
0*1024kB 0*2048kB 0*4096kB = 60756kB
[531276.878825] 1543233 total pagecache pages
[531276.878829] 0 pages in swap cache
[531276.878834] Swap cache stats: add 0, delete 0, find 0/0
[531276.878837] Free swap = 0kB
[531276.878841] Total swap = 0kB
[531276.899643] 2090480 pages RAM
[531276.899645] 75724 pages reserved
[531276.899646] 2248928 pages shared
[531276.899646] 974316 pages non-shared
[531276.899648] netdev: Unable to allocate 1024 tx queues
This is when trying to start a VPN using some old openvpn binary so MQ
is not set.
So
1. I think we should limit allocation of MQ to when MQ flag is set in SETIFF.
2. order 7 allocation is 2^^7 pages - about half a megabyte of contigious
memory. This is quite likely to fail.
Let's start with a small limit on number of queues, like 8?
Then we know it will succeed.
Longer term we might want to solve it differently.
--
MST
^ permalink raw reply
* Re: Doubts about listen backlog and tcp_max_syn_backlog
From: Leandro Lucarella @ 2013-01-23 10:47 UTC (permalink / raw)
To: Rick Jones; +Cc: Eric Dumazet, netdev, linux-kernel
In-Reply-To: <50FF0C25.9000300@hp.com>
On Tue, Jan 22, 2013 at 02:01:09PM -0800, Rick Jones wrote:
> >>If that is being overflowed, I believe you should be seeing something like:
> >>
> >> 14 SYNs to LISTEN sockets dropped
> >>
> >>in the output of netstat -s on the system on which the server
> >>application is running.
> >
> >What is that value reporting exactly?
>
> Netstat is reporting the ListenDrops and/or ListenOverflows which
> map to LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS. Those
> get incremented in tcp_v4_syn_recv_sock() (and its v6 version etc)
>
> if (sk_acceptq_is_full(sk))
> goto exit_overflow;
>
> Will increment both overflows and drops, and drops will increment on
> its own in some additional cases.
>
> >Because we are using syncookies, and AFAIK with that enabled, all
> >SYNs are being replied, and what the listen backlog is really
> >limitting is the "completely established sockets waiting to be
> >accepted", according to listen(2). What I don't really know to be
> >honest, is what a "completely established socket" is, does it mean
> >that the SYN,ACK was sent, or the ACK was received back?
>
> I have always thought it meant that the ACK of the SYN|ACK has been
> received.
>
> SyncookiesSent SyncookiesRecv SyncookiesFailed also appear in
> /proc/net/netstat and presumably in netstat -s output.
Thanks for the info. I'm definitely dropping SYNs and sending cookies,
around 50/s. Is there any way to tell how many connections are queued in
a particular socket?
> >Also, from the client side, when is the connect(2) call done? When the
> >SYN,ACK is received?
>
> That would be my assumption.
Then if syncookies are enabled, the time spent in connect() shouldn't be
bigger than 3 seconds even if SYNs are being "dropped" by listen, right?
(and I'm saying "dropped" because I assume if syncookies are enabled,
SYN,ACK replies are sent anyway, with a cookie, but they are not stored
in the queue/hash table).
> In a previous message:
>
> >What I'm seeing are clients taking either useconds to connect, or 3
> >seconds, which suggest SYNs are getting lost, but the network doesn't
> >seem to be the problem. I'm still investigating this, so unfortunately
> >I'm not really sure.
>
> I recently ran into something like that, which turned-out to be an
> issue with nf_conntrack and its table filling.
Doing a quick research about it, I found that when that happens I should
get a message about it in dmesg (like "kernel: nf_conntrack: table full,
dropping packet.") but I'm not getting any, so I guess that's not a
problem.
Thanks!
--
Leandro Lucarella
sociomantic labs GmbH
http://www.sociomantic.com
^ permalink raw reply
* Re: [RFC PATCH v2 linux-next] et131x: Promote staging et131x driver to drivers/net
From: Dan Carpenter @ 2013-01-23 10:31 UTC (permalink / raw)
To: Mark Einon; +Cc: davem, gregkh, sfr, devel, netdev, linux-kernel
In-Reply-To: <1358935859-29525-1-git-send-email-mark.einon@gmail.com>
On Wed, Jan 23, 2013 at 10:10:58AM +0000, Mark Einon wrote:
> diff --git a/drivers/net/ethernet/agere/Kconfig b/drivers/net/ethernet/agere/Kconfig
> new file mode 100644
> index 0000000..6854966
> --- /dev/null
> +++ b/drivers/net/ethernet/agere/Kconfig
> @@ -0,0 +1,32 @@
> +#
> +# Agere device configuration
> +#
> +
> +config NET_VENDOR_AGERE
> + bool "Agere devices"
> + default y
> + depends on PCI
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Atheros devices. If you say Y, you will be asked
^^^^^^^
Agere?
> + for your specific card in the following questions.
> +
I think you should just leave this block out entirely. It doesn't
save time for anyone.
regards,
dan carpenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox