* Re: TCP Congestion Control Algorithms
From: Stephen Hemminger @ 2009-08-31 22:07 UTC (permalink / raw)
To: Lisong Xu; +Cc: netdev
In-Reply-To: <a45e9b40908311410m486a60fel6a81c334732de358@mail.gmail.com>
On Mon, 31 Aug 2009 16:10:59 -0500
Lisong Xu <lisongxu2@gmail.com> wrote:
> Hello,
>
> Since there are multiple different TCP congestion control algorithms
> available in Linux, a Linux server may use any of them.
>
> Is it possible for a regular user to find out the exact TCP congestion
> control algorithm used by a Linux server? For example, if I am
> downloading a file from a remote Linux server using a TCP flow, can I
> find out whether this flow is a TCP/CUBIC flow, or TCP/Newreno, or
> some other TCP protocol?
>
No. you might be able to some nmap style guessing, but no remote
API. You can see locally on the server through /proc/sys/net
^ permalink raw reply
* Re: Crypto oops in async_chainiv_do_postponed
From: Herbert Xu @ 2009-08-31 22:04 UTC (permalink / raw)
To: Brad Bosch; +Cc: linux-crypto, netdev, offbase0
In-Reply-To: <19099.63038.425414.514063@waldo.imnotcreative.homeip.net>
On Mon, Aug 31, 2009 at 11:11:42AM -0500, Brad Bosch wrote:
>
> OK. I was looking for something subtle because the crash takes a long
> time to happen. But do you agree that the race I described above also
> a real bug?
No I don't think it is. CHAINV_STATE_INUSE guarantees that only
one entity can use ctx->err at any time.
> Yes, I see that this bug must be the bug we would likely encounter first.
> Apparently, async_chainiv_do_postponed was never tested? But I don't
> see how the patch you proposed below helps. We still don't seem to be
> returning NULL from skcipher_dequeue_givcrypt when we reach the end of
> the queue because __crypto_dequeue_request is not checking for NULL
> before it subtracts offset.
Where we subtract the offset the pointer can never be NULL. Please
try my patch.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* neighbour table RCU
From: Stephen Hemminger @ 2009-08-31 22:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
Looking at the neighbour table, it should be possible to get
rid of the two reader/writer locks. The hash table lock is pretty
amenable to RCU, but the dynamic resizing makes it non-trivial.
Thinking of using a combination of RCU and sequence counts so that the
reader would just rescan if resize was in progress.
The reader/writer lock on the neighbour entry is more of a problem.
Probably would be simpler/faster to change it into a spinlock and
be done with it.
The reader/writer lock is also used for the proxy list hash table,
but that can just be a simple spinlock.
--
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Anthony Liguori @ 2009-08-31 21:56 UTC (permalink / raw)
To: Avi Kivity
Cc: Xin, Xiaohui, mst@redhat.com, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, linux-mm@kvack.org,
akpm@linux-foundation.org, hpa@zytor.com,
gregory.haskins@gmail.com
In-Reply-To: <4A9C0DC2.6080704@redhat.com>
Avi Kivity wrote:
> On 08/31/2009 02:42 PM, Xin, Xiaohui wrote:
>> Hi, Michael
>> That's a great job. We are now working on support VMDq on KVM, and
>> since the VMDq hardware presents L2 sorting based on MAC addresses
>> and VLAN tags, our target is to implement a zero copy solution using
>> VMDq. We stared from the virtio-net architecture. What we want to
>> proposal is to use AIO combined with direct I/O:
>> 1) Modify virtio-net Backend service in Qemu to submit aio requests
>> composed from virtqueue.
>> 2) Modify TUN/TAP device to support aio operations and the user space
>> buffer directly mapping into the host kernel.
>> 3) Let a TUN/TAP device binds to single rx/tx queue from the NIC.
>> 4) Modify the net_dev and skb structure to permit allocated skb to
>> use user space directly mapped payload buffer address rather then
>> kernel allocated.
>>
>> As zero copy is also your goal, we are interested in what's in your
>> mind, and would like to collaborate with you if possible.
>>
>
> One way to share the effort is to make vmdq queues available as normal
> kernel interfaces.
It may be possible to make vmdq appear like an sr-iov capable device
from userspace. sr-iov provides the userspace interfaces to allocate
interfaces and assign mac addresses. To make it useful, you would have
to handle tx multiplexing in the driver but that would be much easier to
consume for kvm.
Regards,
Anthony Liguori
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* TCP Congestion Control Algorithms
From: Lisong Xu @ 2009-08-31 21:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <a45e9b40908311408l15d68088i459d6a1000cbca07@mail.gmail.com>
Hello,
Since there are multiple different TCP congestion control algorithms
available in Linux, a Linux server may use any of them.
Is it possible for a regular user to find out the exact TCP congestion
control algorithm used by a Linux server? For example, if I am
downloading a file from a remote Linux server using a TCP flow, can I
find out whether this flow is a TCP/CUBIC flow, or TCP/Newreno, or
some other TCP protocol?
Thanks! If I send this email to a wrong mailing list, I am sorry for that.
Lisong
^ permalink raw reply
* [PATCH net-next-2.6] bonding: make ab_arp select active slaves as other modes
From: Jiri Pirko @ 2009-08-31 21:09 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, bonding-devel, nicolas.2p.debian
When I was implementing primary_passive option (formely named primary_lazy) I've
run into troubles with ab_arp. This is the only mode which is not using
bond_select_active_slave() function to select active slave and instead it
selects it itself. This seems to be not the right behaviour and it would be
better to do it in bond_select_active_slave() for all cases. This patch makes
this happen. Please review.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 7c0e0bd..6ebd88d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1093,15 +1093,8 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
return NULL; /* still no slave, return NULL */
}
- /*
- * first try the primary link; if arping, a link must tx/rx
- * traffic before it can be considered the curr_active_slave.
- * also, we would skip slaves between the curr_active_slave
- * and primary_slave that may be up and able to arp
- */
if ((bond->primary_slave) &&
- (!bond->params.arp_interval) &&
- (IS_UP(bond->primary_slave->dev))) {
+ bond->primary_slave->link == BOND_LINK_UP) {
new_active = bond->primary_slave;
}
@@ -1109,15 +1102,14 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
old_active = new_active;
bond_for_each_slave_from(bond, new_active, i, old_active) {
- if (IS_UP(new_active->dev)) {
- if (new_active->link == BOND_LINK_UP) {
- return new_active;
- } else if (new_active->link == BOND_LINK_BACK) {
- /* link up, but waiting for stabilization */
- if (new_active->delay < mintime) {
- mintime = new_active->delay;
- bestslave = new_active;
- }
+ if (new_active->link == BOND_LINK_UP) {
+ return new_active;
+ } else if (new_active->link == BOND_LINK_BACK &&
+ IS_UP(new_active->dev)) {
+ /* link up, but waiting for stabilization */
+ if (new_active->delay < mintime) {
+ mintime = new_active->delay;
+ bestslave = new_active;
}
}
}
@@ -2929,18 +2921,6 @@ static int bond_ab_arp_inspect(struct bonding *bond, int delta_in_ticks)
}
}
- read_lock(&bond->curr_slave_lock);
-
- /*
- * Trigger a commit if the primary option setting has changed.
- */
- if (bond->primary_slave &&
- (bond->primary_slave != bond->curr_active_slave) &&
- (bond->primary_slave->link == BOND_LINK_UP))
- commit++;
-
- read_unlock(&bond->curr_slave_lock);
-
return commit;
}
@@ -2961,90 +2941,58 @@ static void bond_ab_arp_commit(struct bonding *bond, int delta_in_ticks)
continue;
case BOND_LINK_UP:
- write_lock_bh(&bond->curr_slave_lock);
-
- if (!bond->curr_active_slave &&
- time_before_eq(jiffies, dev_trans_start(slave->dev) +
- delta_in_ticks)) {
+ if ((!bond->curr_active_slave &&
+ time_before_eq(jiffies,
+ dev_trans_start(slave->dev) +
+ delta_in_ticks)) ||
+ bond->curr_active_slave != slave) {
slave->link = BOND_LINK_UP;
- bond_change_active_slave(bond, slave);
bond->current_arp_slave = NULL;
pr_info(DRV_NAME
- ": %s: %s is up and now the "
- "active interface\n",
- bond->dev->name, slave->dev->name);
-
- } else if (bond->curr_active_slave != slave) {
- /* this slave has just come up but we
- * already have a current slave; this can
- * also happen if bond_enslave adds a new
- * slave that is up while we are searching
- * for a new slave
- */
- slave->link = BOND_LINK_UP;
- bond_set_slave_inactive_flags(slave);
- bond->current_arp_slave = NULL;
+ ": %s: link status definitely "
+ "up for interface %s.\n",
+ bond->dev->name, slave->dev->name);
- pr_info(DRV_NAME
- ": %s: backup interface %s is now up\n",
- bond->dev->name, slave->dev->name);
- }
+ if (!bond->curr_active_slave ||
+ (slave == bond->primary_slave))
+ goto do_failover;
- write_unlock_bh(&bond->curr_slave_lock);
+ }
- break;
+ continue;
case BOND_LINK_DOWN:
if (slave->link_failure_count < UINT_MAX)
slave->link_failure_count++;
slave->link = BOND_LINK_DOWN;
+ bond_set_slave_inactive_flags(slave);
- if (slave == bond->curr_active_slave) {
- pr_info(DRV_NAME
- ": %s: link status down for active "
- "interface %s, disabling it\n",
- bond->dev->name, slave->dev->name);
-
- bond_set_slave_inactive_flags(slave);
-
- write_lock_bh(&bond->curr_slave_lock);
-
- bond_select_active_slave(bond);
- if (bond->curr_active_slave)
- bond->curr_active_slave->jiffies =
- jiffies;
-
- write_unlock_bh(&bond->curr_slave_lock);
+ pr_info(DRV_NAME
+ ": %s: link status definitely down for "
+ "interface %s, disabling it\n",
+ bond->dev->name, slave->dev->name);
+ if (slave == bond->curr_active_slave) {
bond->current_arp_slave = NULL;
-
- } else if (slave->state == BOND_STATE_BACKUP) {
- pr_info(DRV_NAME
- ": %s: backup interface %s is now down\n",
- bond->dev->name, slave->dev->name);
-
- bond_set_slave_inactive_flags(slave);
+ goto do_failover;
}
- break;
+
+ continue;
default:
pr_err(DRV_NAME
": %s: impossible: new_link %d on slave %s\n",
bond->dev->name, slave->new_link,
slave->dev->name);
+ continue;
}
- }
- /*
- * No race with changes to primary via sysfs, as we hold rtnl.
- */
- if (bond->primary_slave &&
- (bond->primary_slave != bond->curr_active_slave) &&
- (bond->primary_slave->link == BOND_LINK_UP)) {
+do_failover:
+ ASSERT_RTNL();
write_lock_bh(&bond->curr_slave_lock);
- bond_change_active_slave(bond, bond->primary_slave);
+ bond_select_active_slave(bond);
write_unlock_bh(&bond->curr_slave_lock);
}
^ permalink raw reply related
* Re: UDP is bypassing qdisc statistics ....
From: Mark Smith @ 2009-08-31 20:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christoph Lameter, netdev, davem
In-Reply-To: <4A9C2A89.9060002@gmail.com>
On Mon, 31 Aug 2009 21:54:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Christoph Lameter a écrit :
> > This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
> > packet by the qdisc layer:
> >
<snip>
>
> loopback device do bypass qdisc layer for example...
On occassion, I'd have found it useful if it didn't. It'd be convenient
to test out your qdisc config, or test out applications performance
behaviour over a simulated WAN via netem, without having to a
network and two hosts, and all the related miscellaneous setup work.
^ permalink raw reply
* [PATCH] drop_monitor: make last_rx timestamp private
From: Neil Horman @ 2009-08-31 19:58 UTC (permalink / raw)
To: netdev; +Cc: davem, nhorman, eric.dumazet
Hey all-
It was recently pointed out to me that the last_rx field of the net_device
structure wasn't updated regularly. In fact only the bonding driver really uses
it currently. Since the drop_monitor code relies on the last_rx field to detect
drops on recevie in hardware, We need to find a more reliable way to rate limit
our drop checks (so that we don't check for drops on every frame recevied, which
would be inefficient. This patch makes a last_rx timestamp that is private to
the drop monitor code and is updated for every device that we track.
Neil
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
drop_monitor.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 9d66fa9..34a05ce 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -52,6 +52,7 @@ struct per_cpu_dm_data {
struct dm_hw_stat_delta {
struct net_device *dev;
+ unsigned long last_rx;
struct list_head list;
struct rcu_head rcu;
unsigned long last_drop_val;
@@ -179,18 +180,21 @@ static void trace_napi_poll_hit(struct napi_struct *napi)
{
struct dm_hw_stat_delta *new_stat;
- /*
- * Ratelimit our check time to dm_hw_check_delta jiffies
- */
- if (!time_after(jiffies, napi->dev->last_rx + dm_hw_check_delta))
- return;
rcu_read_lock();
list_for_each_entry_rcu(new_stat, &hw_stats_list, list) {
+ /*
+ * only add a note to our monitor buffer if:
+ * 1) this is the dev we received on
+ * 2) its after the last_rx delta
+ * 3) our rx_dropped count has gone up
+ */
if ((new_stat->dev == napi->dev) &&
+ (time_after(jiffies, new_stat->last_rx + dm_hw_check_delta)) &&
(napi->dev->stats.rx_dropped != new_stat->last_drop_val)) {
trace_drop_common(NULL, NULL);
new_stat->last_drop_val = napi->dev->stats.rx_dropped;
+ new_stat->last_rx = jiffies;
break;
}
}
@@ -286,6 +290,7 @@ static int dropmon_net_event(struct notifier_block *ev_block,
goto out;
new_stat->dev = dev;
+ new_stat->last_rx = jiffies;
INIT_RCU_HEAD(&new_stat->rcu);
spin_lock(&trace_state_lock);
list_add_rcu(&new_stat->list, &hw_stats_list);
^ permalink raw reply related
* Re: UDP is bypassing qdisc statistics ....
From: Eric Dumazet @ 2009-08-31 19:54 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, davem
In-Reply-To: <alpine.DEB.1.10.0908311632170.1507@V090114053VZO-1>
Christoph Lameter a écrit :
> This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
> packet by the qdisc layer:
>
> #tc -s qdisc show
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 10491 bytes 72 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
> #ping yy
> PING yy (10.2.36.120) 56(84) bytes of data.
> 64 bytes from yy (10.2.36.120): icmp_seq=1 ttl=64 time=0.933 ms
> 64 bytes from yy (10.2.36.120): icmp_seq=2 ttl=64 time=0.122 ms
> 64 bytes from yy (10.2.36.120): icmp_seq=3 ttl=64 time=0.119 ms
> ^C
> --- yy ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
> rtt min/avg/max/mdev = 0.119/0.391/0.933/0.383 ms
>
> #tc -s qdisc show
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 10839 bytes 75 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
>
> Now I overrun the transmitter with udp multicast traffic:
>
> #./mcast -n1 -r400000
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 0 MC addresses 239.0.192-254.2-254 offset 0
> origin 10.2.36.120
> Sender: Sending 400000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
> ^C
> Unsubscribing from multicast groups
> Done.
>
> #tc -s qdisc show
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 13359 bytes 101 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
>
> The mcast invocation send over 3 million packets(!) but they are not
> accounted for in the qdisc. 500k of those were lost. Also not counted.
> The 26 packets receives are likely only covering the ssh session using
> TCP.
>
> Receiver log:
>
> yy#./mcast
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 10.2.36.121
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 3110416 531472 25555 531472 307958 0.0 151.45 1648.21 1875.68 499.92
> Unsubscribing from 1 multicast addresses origin 10.2.36.121.
>
> What is wrong here? Is UDP bypassing the qdisc layer?
>
> Tried UDP unicast with similar effects.
Not reproductible here, I can see bytes/pkts counts increasing while mcast -n1 -r400000 runs.
# tc -s -d qdisc show dev eth0 ; sleep 1 ; tc -s -d qdisc show dev eth0
qdisc pfifo_fast 0: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 7694155580 bytes 36894415 pkt (dropped 0, overlimits 0 requeues 2)
rate 0bit 0pps backlog 0b 0p requeues 2
qdisc pfifo_fast 0: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 7778853932 bytes 37142071 pkt (dropped 0, overlimits 0 requeues 2)
rate 0bit 0pps backlog 0b 0p requeues 2
Check :
# ip ro
# ip ro get 10.2.36.120
# ip ro get 239.0.192.2
maybe your pings do use eth0, and your multicast doesnt.
loopback device do bypass qdisc layer for example...
^ permalink raw reply
* Re: [PATCH] skb: Augment skb_copy_datagram_iovec TRACE_EVENT to dump more info
From: Steven Rostedt @ 2009-08-31 19:06 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, davem, mingo
In-Reply-To: <20090828231709.GA14063@hmsreliant.think-freely.org>
On Fri, 28 Aug 2009, Neil Horman wrote:
> Thanks, Heres an updated patch with the nits fixed. If you want to go over a
> better way to size strings when the source string isn't immediately available,
> I'll send a subsequent patch to fix that
>
> New version of the patch:
>
> Augment the skb_copy_datagram_iovec TRACE_EVENT to provide same data output as
> the ftracer for skb numa node correlation that was recently removed.
>
> Change notes:
>
> 1) Cleaned up the nits Steven mentioned above
Looks good,
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH] skb: Augment skb_copy_datagram_iovec TRACE_EVENT to dump more info
From: Steven Rostedt @ 2009-08-31 19:05 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, davem, mingo
In-Reply-To: <20090828231709.GA14063@hmsreliant.think-freely.org>
On Fri, 28 Aug 2009, Neil Horman wrote:
> > >
> > > /*
> > > * Tracepoint for free an sk_buff:
> > > @@ -42,16 +43,35 @@ TRACE_EVENT(skb_copy_datagram_iovec,
> > > TP_ARGS(skb, len),
> > >
> > > TP_STRUCT__entry(
> > > - __field( const void *, skbaddr )
> > > + __field( const struct sk_buff *, skb )
> > > __field( int, len )
> > > + __field( int, anid )
> > > + __field( int, cnid )
> > > + __field( int, rx_queue )
> > > + __dynamic_array(char, name, IFNAMSIZ )
> >
> > For string fields we have a __string macro:
> >
> > __string( char, name )
> >
> Yeah, I was going to use that, but I ran into an issue, in that the __string
> macro expects, as its second of two arguments, a pointer to a string with witch
> to determine the dynamic arrays size. The problem is that, if I'm to provide
> that, I need to point it to skb->dev->name, and there is no guarantee that
> skb->dev isn't NULL, at which point I think the use of string breaks down. Note
> below that I obtain the dev pointer by other means and check its validity prior
> to assigning it. If theres a better way to do this, please let me know.
Ah, OK I see the issue. The problem is the code that figures out the
offset. It will always be calculated, and that would cause the skb->dev be
evaluated and if NULL will cause an OOPS.
Yeah, keep the dynamic_array here then.
-- Steve
^ permalink raw reply
* Re: [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT
From: Steven Rostedt @ 2009-08-31 18:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: Xiao Guangrong, David Miller, Neil Horman, Frederic Weisbecker,
Wei Yongjun, Netdev, LKML
In-Reply-To: <20090831084922.GB25811@elte.hu>
On Mon, 31 Aug 2009, Ingo Molnar wrote:
>
> * Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> wrote:
>
> > - Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
> > like below:
>
> I think as long as it does not touch tracing infrastructure (which
> your patches dont do in their current form) this should be
> done/merged via the networking tree.
I agree, all changes that are in include/trace/events/ and trace point
usage can stay within the subsystem tree.
>
> [ There might be some small collisions in define_trace.h (because
> these tracepoints move from legacy to new-style TRACE_EVENT()
> form) but that's OK. ]
But changes to anything in include/trace or kernel/trace needs to go
throught the tracing subsystem. This includes a changes to define_trace.h.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT
From: Steven Rostedt @ 2009-08-31 18:03 UTC (permalink / raw)
To: Xiao Guangrong
Cc: Ingo Molnar, David Miller, Neil Horman, Frederic Weisbecker,
Wei Yongjun, Netdev, LKML
In-Reply-To: <4A9B6AA7.5020508@cn.fujitsu.com>
On Mon, 31 Aug 2009, Xiao Guangrong wrote:
> - Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
> like below:
>
> sshd-2503 [000] 71.920846: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
> sshd-2503 [000] 72.020291: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
> sshd-2503 [000] 72.020418: napi_poll: ifname=eth0 state=NAPI_STATE_SCHED weigth=16 poll=pcnet32_poll
>
> - Remove the "DECLARE_TRACE" definiens in include/trace/define_trace.h,
> because TRACE_EVENT not use it
The above really needs to be in a separate patch, since it is a tracing
infrastructure change.
-- Steve
>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
> ---
> include/trace/define_trace.h | 4 ---
> include/trace/events/napi.h | 43 +++++++++++++++++++++++++++++++++++++----
> 2 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
> index 2a4b3bf..6158741 100644
> --- a/include/trace/define_trace.h
> +++ b/include/trace/define_trace.h
> @@ -31,10 +31,6 @@
> assign, print, reg, unreg) \
> DEFINE_TRACE_FN(name, reg, unreg)
>
> -#undef DECLARE_TRACE
> -#define DECLARE_TRACE(name, proto, args) \
> - DEFINE_TRACE(name)
> -
> #undef TRACE_INCLUDE
> #undef __TRACE_INCLUDE
>
> diff --git a/include/trace/events/napi.h b/include/trace/events/napi.h
> index a8989c4..5c7a192 100644
> --- a/include/trace/events/napi.h
> +++ b/include/trace/events/napi.h
> @@ -1,11 +1,44 @@
> -#ifndef _TRACE_NAPI_H_
> -#define _TRACE_NAPI_H_
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM napi
> +
> +#if !defined(_TRACE_NAPI_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_NAPI_H
>
> #include <linux/netdevice.h>
> #include <linux/tracepoint.h>
>
> -DECLARE_TRACE(napi_poll,
> +#define show_napi_state(state) state ? __print_flags(state, "|", \
> + { (1UL << NAPI_STATE_SCHED), "NAPI_STATE_SCHED" }, \
> + { (1UL << NAPI_STATE_DISABLE), "NAPI_STATE_DISABLE" }, \
> + { (1UL << NAPI_STATE_NPSVC), "NAPI_STATE_NPSVC" }) : "0"
> +
> +TRACE_EVENT(napi_poll,
> +
> TP_PROTO(struct napi_struct *napi),
> - TP_ARGS(napi));
>
> -#endif
> + TP_ARGS(napi),
> +
> + TP_STRUCT__entry(
> + __field( unsigned long, state )
> + __field( int, weight )
> + __field( void *, poll )
> + __string( ifname, (napi->dev ?
> + napi->dev->name : "backlog") )
> + ),
> +
> + TP_fast_assign(
> + __entry->state = napi->state;
> + __entry->weight = napi->weight;
> + __entry->poll = napi->poll;
> + __assign_str(ifname, napi->dev ? napi->dev->name : "backlog")
> + ),
> +
> + TP_printk("ifname=%s state=%s weight=%d poll=%pf",
> + __get_str(ifname), show_napi_state(__entry->state),
> + __entry->weight, __entry->poll)
> +);
> +
> +#endif /* _TRACE_NAPI_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> --
> 1.6.1.2
>
>
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Avi Kivity @ 2009-08-31 17:52 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: mst@redhat.com, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, linux-mm@kvack.org,
akpm@linux-foundation.org, hpa@zytor.com,
gregory.haskins@gmail.com
In-Reply-To: <C85CEDA13AB1CF4D9D597824A86D2B9006AEB944B8@PDSMSX501.ccr.corp.intel.com>
On 08/31/2009 02:42 PM, Xin, Xiaohui wrote:
> Hi, Michael
> That's a great job. We are now working on support VMDq on KVM, and since the VMDq hardware presents L2 sorting based on MAC addresses and VLAN tags, our target is to implement a zero copy solution using VMDq. We stared from the virtio-net architecture. What we want to proposal is to use AIO combined with direct I/O:
> 1) Modify virtio-net Backend service in Qemu to submit aio requests composed from virtqueue.
> 2) Modify TUN/TAP device to support aio operations and the user space buffer directly mapping into the host kernel.
> 3) Let a TUN/TAP device binds to single rx/tx queue from the NIC.
> 4) Modify the net_dev and skb structure to permit allocated skb to use user space directly mapped payload buffer address rather then kernel allocated.
>
> As zero copy is also your goal, we are interested in what's in your mind, and would like to collaborate with you if possible.
>
One way to share the effort is to make vmdq queues available as normal
kernel interfaces. It would take quite a bit of work, but the end
result is that no other components need to be change, and it makes vmdq
useful outside kvm. It also greatly reduces the amount of integration
work needed throughout the stack (kvm/qemu/libvirt).
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* UDP is bypassing qdisc statistics ....
From: Christoph Lameter @ 2009-08-31 21:46 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
packet by the qdisc layer:
#tc -s qdisc show
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 10491 bytes 72 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
#ping yy
PING yy (10.2.36.120) 56(84) bytes of data.
64 bytes from yy (10.2.36.120): icmp_seq=1 ttl=64 time=0.933 ms
64 bytes from yy (10.2.36.120): icmp_seq=2 ttl=64 time=0.122 ms
64 bytes from yy (10.2.36.120): icmp_seq=3 ttl=64 time=0.119 ms
^C
--- yy ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.119/0.391/0.933/0.383 ms
#tc -s qdisc show
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 10839 bytes 75 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
Now I overrun the transmitter with udp multicast traffic:
#./mcast -n1 -r400000
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 0 MC addresses 239.0.192-254.2-254 offset 0
origin 10.2.36.120
Sender: Sending 400000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
^C
Unsubscribing from multicast groups
Done.
#tc -s qdisc show
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 13359 bytes 101 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
The mcast invocation send over 3 million packets(!) but they are not
accounted for in the qdisc. 500k of those were lost. Also not counted.
The 26 packets receives are likely only covering the ssh session using
TCP.
Receiver log:
yy#./mcast
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 10.2.36.121
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
3110416 531472 25555 531472 307958 0.0 151.45 1648.21 1875.68 499.92
Unsubscribing from 1 multicast addresses origin 10.2.36.121.
What is wrong here? Is UDP bypassing the qdisc layer?
Tried UDP unicast with similar effects.
^ permalink raw reply
* [PATCH] [net-next] tcp: avoid sending zero TSval
From: Octavian Purdila @ 2009-08-31 17:44 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Per RFC1323, zero TSecr is considered invalid. Thus we must avoid when
possible sending a zero TSval.
Currently, we use the least significant 32 bits of jiffies to fill in
TSval. But that can wrap around to zero (in 5 minutes after reboot,
and every 49 days after that in the worst case).
This patch approximate a wrap-around zero TSval to 1. This is better
then emitting a value which will be ignored.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
net/ipv4/tcp_output.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
[-- Attachment #2: 71e6d2ae2ae12cfaf0d7cb8e010fd0c7f520874b.diff --]
[-- Type: text/x-patch, Size: 598 bytes --]
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 4e00442..607d675 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -415,7 +415,10 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
(TCPOPT_TIMESTAMP << 8) |
TCPOLEN_TIMESTAMP);
}
- *ptr++ = htonl(opts->tsval);
+ /* Currently, opts->tsval always comes from tcp_time_stamp.
+ * Thus, if zero, its caused by jiffie wrap-around, and we can
+ * approximate it to one to avoid a later TSecr drop */
+ *ptr++ = htonl(opts->tsval?:1);
*ptr++ = htonl(opts->tsecr);
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6] drivers: Kill now superfluous ->last_rx stores
From: Neil Horman @ 2009-08-31 17:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Netdev
In-Reply-To: <4A9BFBAA.10705@gmail.com>
On Mon, Aug 31, 2009 at 06:34:50PM +0200, Eric Dumazet wrote:
> Eric Dumazet a écrit :
> > Neil Horman a écrit :
> >> I still see a large number of drivers that update dev->last_rx, although its
> >> not all as I look through the list, so something definately seems amiss.
> >
> > Some drivers still update dev->last_rx for their own needs, not a core
> > network concern.
> >
> > But a cleanup is certainly possible on few other drivers, about a dozen
> > if I count correctly.
>
> Well, a litle bit more if we look outside of drivers/net
>
> [PATCH net-next-2.6] drivers: Kill now superfluous ->last_rx stores
>
> The generic packet receive code takes care of setting
> netdev->last_rx when necessary, for the sake of the
> bonding ARP monitor.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Neil Horman <nhorman@txudriver.com>
Thanks!
Neil
^ permalink raw reply
* [PATCH] sky2: fix management of driver LED
From: Stephen Hemminger @ 2009-08-31 17:31 UTC (permalink / raw)
To: Mike McCormack, David Miller; +Cc: netdev, Rene Mayrhofer, Richard Leitner
In-Reply-To: <4A9928C9.7000907@ring3k.org>
Observed by Mike McCormack.
The LED bit here is just a software controlled value used to
turn on one of the LED's on some boards. The register value was wrong,
which could have been causing some power control issues.
Get rid of problematic define use the correct mask.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/sky2.c | 12 ++++++------
drivers/net/sky2.h | 9 +--------
2 files changed, 7 insertions(+), 14 deletions(-)
--- a/drivers/net/sky2.c 2009-08-31 09:05:07.941736447 -0700
+++ b/drivers/net/sky2.c 2009-08-31 09:46:24.611967164 -0700
@@ -256,6 +256,9 @@ static void sky2_power_on(struct sky2_hw
sky2_read32(hw, B2_GP_IO);
}
+
+ /* Turn on "driver loaded" LED */
+ sky2_write16(hw, B0_CTST, Y2_LED_STAT_ON);
}
static void sky2_power_aux(struct sky2_hw *hw)
@@ -274,6 +277,9 @@ static void sky2_power_aux(struct sky2_h
sky2_write8(hw, B0_POWER_CTRL,
(PC_VAUX_ENA | PC_VCC_ENA |
PC_VAUX_ON | PC_VCC_OFF));
+
+ /* turn off "driver loaded LED" */
+ sky2_write16(hw, B0_CTST, Y2_LED_STAT_OFF);
}
static void sky2_gmac_reset(struct sky2_hw *hw, unsigned port)
@@ -1866,9 +1872,6 @@ static int sky2_down(struct net_device *
sky2_phy_power_down(hw, port);
spin_unlock_bh(&sky2->phy_lock);
- /* turn off LED's */
- sky2_write16(hw, B0_Y2LED, LED_STAT_OFF);
-
sky2_tx_reset(hw, port);
/* Free any pending frames stuck in HW queue */
@@ -2982,8 +2985,6 @@ static void sky2_reset(struct sky2_hw *h
sky2_write8(hw, B2_TI_CTRL, TIM_STOP);
sky2_write8(hw, B2_TI_CTRL, TIM_CLR_IRQ);
- sky2_write8(hw, B0_Y2LED, LED_STAT_ON);
-
/* Turn off descriptor polling */
sky2_write32(hw, B28_DPT_CTRL, DPT_STOP);
@@ -4600,7 +4601,6 @@ static void __devexit sky2_remove(struct
sky2_power_aux(hw);
- sky2_write16(hw, B0_Y2LED, LED_STAT_OFF);
sky2_write8(hw, B0_CTST, CS_RST_SET);
sky2_read8(hw, B0_CTST);
--- a/drivers/net/sky2.h 2009-08-31 09:05:07.954719390 -0700
+++ b/drivers/net/sky2.h 2009-08-31 09:05:36.488716877 -0700
@@ -155,7 +155,7 @@ enum pci_cfg_reg1 {
enum csr_regs {
B0_RAP = 0x0000,
B0_CTST = 0x0004,
- B0_Y2LED = 0x0005,
+
B0_POWER_CTRL = 0x0007,
B0_ISRC = 0x0008,
B0_IMSK = 0x000c,
@@ -283,13 +283,6 @@ enum {
CS_RST_SET = 1, /* Set Software reset */
};
-/* B0_LED 8 Bit LED register */
-enum {
-/* Bit 7.. 2: reserved */
- LED_STAT_ON = 1<<1, /* Status LED on */
- LED_STAT_OFF = 1, /* Status LED off */
-};
-
/* B0_POWER_CTRL 8 Bit Power Control reg (YUKON only) */
enum {
PC_VAUX_ENA = 1<<7, /* Switch VAUX Enable */
^ permalink raw reply
* Re: [PATCH next] sky2: Create buffer alloc and free helpers
From: Stephen Hemminger @ 2009-08-31 17:29 UTC (permalink / raw)
To: Mike McCormack, David Miller; +Cc: netdev
In-Reply-To: <4A992974.1060308@ring3k.org>
On Sat, 29 Aug 2009 22:13:24 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> Refactor similar two sections of code that free buffers into one.
> Only call tx_init if all buffer allocations succeed.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets
From: Octavian Purdila @ 2009-08-31 17:15 UTC (permalink / raw)
To: David Miller; +Cc: themann, raisch, eric.dumazet, netdev
In-Reply-To: <20090830.221105.37473168.davem@davemloft.net>
On Monday 31 August 2009 08:11:05 David Miller wrote:
> From: Octavian Purdila <opurdila@ixiacom.com>
> Date: Thu, 27 Aug 2009 02:08:31 +0300
>
> > This fixes a temporary performance issue we noticed in back to back
> > TSO - LRO tests when such tests are run within five minutes after
> > boot.
> >
> > The TSval field of TCP packets is filled in based on the current
> > jiffie, which is initialized at -300*HZ. That means that in 5 minutes
> > after reboot it will wrap to zero.
>
> RFC1323 says we absolutely must ignore zero TSecr values.
>
> It is a bug that the stack emits a zero value when it means to give a
> real TSecr value that will be used.
>
> Probably we can do something like emit '1' when we would emit '0'
> based upon jiffies.
>
> And this would be an improvement from now in that having a off-by-one
> TSecr in this situation is better than emitting one which we can
> guarentee will be ignored.
Right, why did I thought that the LRO TSecr issue can happen even when
emitting a right TSval ? :-/
I'll follow with a patch which takes this approach.
Thanks,
tavi
^ permalink raw reply
* [PATCH] Re: Latest PreemptRT patch error on imx35
From: Tim Sander @ 2009-08-31 16:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-rt-users, David S. Miller, Sascha Hauer, Greg Ungerer,
netdev
In-Reply-To: <20090831132200.GA21836@pengutronix.de>
Hi Uwe
> The exact problem is:
> fec_enet_mii (this takes &fep->mii_lock) and calls mip->mii_func
> which happens to be mii_queue. mii_queue in turn takes
> &fep->mii_lock again.
Mh, lets see, i tried this:
--- linux-2.6.30/drivers/net/fec.orig.c 2009-08-31 18:01:25.000000000 +0200
+++ linux-2.6.30/drivers/net/fec.c 2009-08-31 18:06:31.000000000 +0200
@@ -622,8 +622,7 @@
goto unlock;
}
- if (mip->mii_func != NULL)
- (*(mip->mii_func))(readl(fep->hwp + FEC_MII_DATA), dev);
+ mii_queue_locked(readl(fep->hwp + FEC_MII_DATA), dev);
mii_head = mip->mii_next;
mip->mii_next = mii_free;
@@ -637,17 +636,9 @@
}
static int
-mii_queue(struct net_device *dev, int regval, void (*func)(uint, struct
net_device *))
+mii_queue_locked(struct net_device *dev, int regval, void (*func)(uint,
struct net_device *))
{
- struct fec_enet_private *fep;
- unsigned long flags;
- mii_list_t *mip;
int retval;
-
- /* Add PHY address to register command */
- fep = netdev_priv(dev);
- spin_lock_irqsave(&fep->mii_lock, flags);
-
regval |= fep->phy_addr << 23;
retval = 0;
@@ -666,6 +657,22 @@
} else {
retval = 1;
}
+ return retval;
+}
+
+static int
+mii_queue(struct net_device *dev, int regval, void (*func)(uint, struct
net_device *))
+{
+ struct fec_enet_private *fep;
+ unsigned long flags;
+ mii_list_t *mip;
+ int retval;
+
+ /* Add PHY address to register command */
+ fep = netdev_priv(dev);
+ spin_lock_irqsave(&fep->mii_lock, flags);
+
+ retval=mii_queue_locked(dev,regval,net_device);
spin_unlock_irqrestore(&fep->mii_lock, flags);
return retval;
---
But it still gives me:
FEC Ethernet Driver
kernel BUG at kernel/rtmutex.c:807!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT
Modules linked in:
CPU: 0 Not tainted (2.6.31-rc8-rt9 #1)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<c0024184>] lr : [<c0024180>] psr: 00000193
sp : c7891ef0 ip : c7891e30 fp : 00000002
r10: c7911c24 r9 : c031f9cc r8 : c0351e54
r7 : 40000113 r6 : c0195c74 r5 : c7890000 r4 : 600e0000
r3 : 00000000 r2 : 00000001 r1 : c7890000 r0 : 0000002a
Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387d Table: 80004008 DAC: 00000017
Process irq/57-fec (pid: 243, stack limit = 0xc7890268)
Stack: (0xc7891ef0 to 0xc7892000)
1ee0: c025fb3c c025fd38 00000000 40000113
1f00: ffffffff c7891f10 c025fcd8 c0032124 00000000 c7891f20 c0031764 c781e01c
1f20: c78ffb40 00000017 00000000 c7819b20 c7891f74 600e0000 c7911800 c0195c74
1f40: c7911c24 c0351e54 c031f9cc c0351e58 00000002 c0195dfc c0351d64 c7911b20
1f60: c7911800 c7911c24 c0351e54 c0196794 c025ee80 c031f9c4 c79885a0 c7890000
1f80: c031f988 c79885c8 c031f9e4 c0062950 00000000 00000032 c7891fbc c781fe4c
1fa0: c79885a0 c006281c 00000000 00000000 00000000 00000000 00000000 c004c5e8
1fc0: 00000000 00000000 c7891fc8 c7891fc8 c7891fd0 c7891fd0 00000000 00000000
1fe0: c7891fe0 c7891fe0 00000000 00000000 00000000 c00218b4 ffebfef3 ddddebfd
[<c0024184>] (__bug+0x1c/0x28) from [<c025fd38>]
(rt_spin_lock_slowlock+0x220/0x234)
[<c025fd38>] (rt_spin_lock_slowlock+0x220/0x234) from [<c0195dfc>]
(mii_queue+0x20/0xb4)
[<c0195dfc>] (mii_queue+0x20/0xb4) from [<c0196794>]
(fec_enet_interrupt+0x84/0x104)
[<c0196794>] (fec_enet_interrupt+0x84/0x104) from [<c0062950>]
(irq_thread+0x134/0x1c0)
[<c0062950>] (irq_thread+0x134/0x1c0) from [<c004c5e8>] (kthread+0x7c/0x84)
[<c004c5e8>] (kthread+0x7c/0x84) from [<c00218b4>]
(kernel_thread_exit+0x0/0x8)
Code: e1a01000 e59f000c eb08e8b0 e3a03000 (e5833000)
---[ end trace 25de9c8d632021f6 ]---
exiting task "irq/57-fec" (243) is an active IRQ thread (irq 57)
Best regards
Tim
^ permalink raw reply
* [PATCH net-next-2.6] drivers: Kill now superfluous ->last_rx stores
From: Eric Dumazet @ 2009-08-31 16:34 UTC (permalink / raw)
To: David Miller; +Cc: Neil Horman, Netdev
In-Reply-To: <4A9BD13E.4040501@gmail.com>
Eric Dumazet a écrit :
> Neil Horman a écrit :
>> I still see a large number of drivers that update dev->last_rx, although its
>> not all as I look through the list, so something definately seems amiss.
>
> Some drivers still update dev->last_rx for their own needs, not a core
> network concern.
>
> But a cleanup is certainly possible on few other drivers, about a dozen
> if I count correctly.
Well, a litle bit more if we look outside of drivers/net
[PATCH net-next-2.6] drivers: Kill now superfluous ->last_rx stores
The generic packet receive code takes care of setting
netdev->last_rx when necessary, for the sake of the
bonding ARP monitor.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/firewire/net.c | 2 --
drivers/ieee1394/eth1394.c | 1 -
drivers/infiniband/hw/amso1100/c2.c | 1 -
drivers/infiniband/hw/nes/nes_hw.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 1 -
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 1 -
drivers/misc/sgi-xp/xpnet.c | 1 -
drivers/net/arm/ks8695net.c | 1 -
drivers/net/arm/w90p910_ether.c | 1 -
drivers/net/atl1c/atl1c_main.c | 1 -
drivers/net/benet/be_main.c | 2 --
drivers/net/can/dev.c | 1 -
drivers/net/can/sja1000/sja1000.c | 2 --
drivers/net/davinci_emac.c | 1 -
drivers/net/ethoc.c | 1 -
drivers/net/igbvf/netdev.c | 4 ----
drivers/net/smsc911x.c | 1 -
drivers/net/smsc9420.c | 1 -
drivers/net/vxge/vxge-main.c | 2 --
drivers/net/wireless/b43legacy/xmit.c | 1 -
drivers/net/xilinx_emaclite.c | 1 -
drivers/s390/net/ctcm_main.c | 1 -
drivers/s390/net/netiucv.c | 1 -
drivers/s390/net/qeth_l2_main.c | 1 -
drivers/s390/net/qeth_l3_main.c | 1 -
25 files changed, 1 insertion(+), 32 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index a42209a..3f58969 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -663,8 +663,6 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
if (netif_queue_stopped(net))
netif_wake_queue(net);
- net->last_rx = jiffies;
-
return 0;
}
diff --git a/drivers/ieee1394/eth1394.c b/drivers/ieee1394/eth1394.c
index f5c586c..f3bf083 100644
--- a/drivers/ieee1394/eth1394.c
+++ b/drivers/ieee1394/eth1394.c
@@ -1300,7 +1300,6 @@ static void ether1394_iso(struct hpsb_iso *iso)
hpsb_iso_recv_release_packets(iso, i);
- dev->last_rx = jiffies;
}
/******************************************
diff --git a/drivers/infiniband/hw/amso1100/c2.c b/drivers/infiniband/hw/amso1100/c2.c
index 0cfbb6d..8c5d284 100644
--- a/drivers/infiniband/hw/amso1100/c2.c
+++ b/drivers/infiniband/hw/amso1100/c2.c
@@ -530,7 +530,6 @@ static void c2_rx_interrupt(struct net_device *netdev)
netif_rx(skb);
- netdev->last_rx = jiffies;
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += buflen;
}
diff --git a/drivers/infiniband/hw/nes/nes_hw.c b/drivers/infiniband/hw/nes/nes_hw.c
index 4a84d02..97d4c2a 100644
--- a/drivers/infiniband/hw/nes/nes_hw.c
+++ b/drivers/infiniband/hw/nes/nes_hw.c
@@ -2741,7 +2741,7 @@ void nes_nic_ce_handler(struct nes_device *nesdev, struct nes_hw_nic_cq *cq)
}
skip_rx_indicate0:
- nesvnic->netdev->last_rx = jiffies;
+ ;
/* nesvnic->netstats.rx_packets++; */
/* nesvnic->netstats.rx_bytes += rx_pkt_size; */
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 181b1f3..986f07f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -663,7 +663,6 @@ copied:
skb_reset_mac_header(skb);
skb_pull(skb, IPOIB_ENCAP_LEN);
- dev->last_rx = jiffies;
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index e7e5adf..c9dcb20 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -277,7 +277,6 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
skb_reset_mac_header(skb);
skb_pull(skb, IPOIB_ENCAP_LEN);
- dev->last_rx = jiffies;
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/misc/sgi-xp/xpnet.c b/drivers/misc/sgi-xp/xpnet.c
index 212da9a..16f0abd 100644
--- a/drivers/misc/sgi-xp/xpnet.c
+++ b/drivers/misc/sgi-xp/xpnet.c
@@ -240,7 +240,6 @@ xpnet_receive(short partid, int channel, struct xpnet_message *msg)
(void *)skb->head, (void *)skb->data, skb_tail_pointer(skb),
skb_end_pointer(skb), skb->len);
- xpnet_device->last_rx = jiffies;
xpnet_device->stats.rx_packets++;
xpnet_device->stats.rx_bytes += skb->len + ETH_HLEN;
diff --git a/drivers/net/arm/ks8695net.c b/drivers/net/arm/ks8695net.c
index 35cd264..e12d2c8 100644
--- a/drivers/net/arm/ks8695net.c
+++ b/drivers/net/arm/ks8695net.c
@@ -467,7 +467,6 @@ ks8695_rx_irq(int irq, void *dev_id)
netif_rx(skb);
/* Record stats */
- ndev->last_rx = jiffies;
ndev->stats.rx_packets++;
ndev->stats.rx_bytes += pktlen;
goto rx_finished;
diff --git a/drivers/net/arm/w90p910_ether.c b/drivers/net/arm/w90p910_ether.c
index 890716f..04f4114 100644
--- a/drivers/net/arm/w90p910_ether.c
+++ b/drivers/net/arm/w90p910_ether.c
@@ -777,7 +777,6 @@ static void netdev_rx(struct net_device *dev)
rxbd = ðer->rdesc->desclist[ether->cur_rx];
- dev->last_rx = jiffies;
} while (1);
}
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index 1d601ce..81c6928 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -1740,7 +1740,6 @@ rrs_checked:
} else
netif_receive_skb(skb);
- netdev->last_rx = jiffies;
(*work_done)++;
count++;
}
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 7b9efee..0695acc 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -774,8 +774,6 @@ static void be_rx_compl_process(struct be_adapter *adapter,
netif_receive_skb(skb);
}
- adapter->netdev->last_rx = jiffies;
-
return;
}
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index e1a4f82..1d29082 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -357,7 +357,6 @@ void can_restart(unsigned long data)
netif_rx(skb);
- dev->last_rx = jiffies;
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index b3004de..56a1355 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -339,7 +339,6 @@ static void sja1000_rx(struct net_device *dev)
netif_rx(skb);
- dev->last_rx = jiffies;
stats->rx_packets++;
stats->rx_bytes += dlc;
}
@@ -454,7 +453,6 @@ static int sja1000_err(struct net_device *dev, uint8_t isrc, uint8_t status)
netif_rx(skb);
- dev->last_rx = jiffies;
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 5e6652b..d465eaa 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1920,7 +1920,6 @@ static int emac_net_rx_cb(struct emac_priv *priv,
skb_put(p_skb, net_pkt_list->pkt_length);
EMAC_CACHE_INVALIDATE((unsigned long)p_skb->data, p_skb->len);
p_skb->protocol = eth_type_trans(p_skb, priv->ndev);
- p_skb->dev->last_rx = jiffies;
netif_receive_skb(p_skb);
priv->net_dev_stats.rx_bytes += net_pkt_list->pkt_length;
priv->net_dev_stats.rx_packets++;
diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
index 4dbe5f1..710b564 100644
--- a/drivers/net/ethoc.c
+++ b/drivers/net/ethoc.c
@@ -404,7 +404,6 @@ static int ethoc_rx(struct net_device *dev, int limit)
void *src = priv->membase + bd.addr;
memcpy_fromio(skb_put(skb, size), src, size);
skb->protocol = eth_type_trans(skb, dev);
- dev->last_rx = jiffies;
priv->stats.rx_packets++;
priv->stats.rx_bytes += size;
netif_receive_skb(skb);
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index 3f03c42..3dced7c 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -96,8 +96,6 @@ static void igbvf_receive_skb(struct igbvf_adapter *adapter,
E1000_RXD_SPC_VLAN_MASK);
else
netif_receive_skb(skb);
-
- netdev->last_rx = jiffies;
}
static inline void igbvf_rx_checksum_adv(struct igbvf_adapter *adapter,
@@ -342,8 +340,6 @@ send_up:
igbvf_receive_skb(adapter, netdev, skb, staterr,
rx_desc->wb.upper.vlan);
- netdev->last_rx = jiffies;
-
next_desc:
rx_desc->wb.upper.status_error = 0;
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index c266785..ccdd196 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -1047,7 +1047,6 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
/* Update counters */
dev->stats.rx_packets++;
dev->stats.rx_bytes += (pktlength - 4);
- dev->last_rx = jiffies;
}
/* Return total received packets */
diff --git a/drivers/net/smsc9420.c b/drivers/net/smsc9420.c
index 60abdb1..4434b51 100644
--- a/drivers/net/smsc9420.c
+++ b/drivers/net/smsc9420.c
@@ -817,7 +817,6 @@ static void smsc9420_rx_handoff(struct smsc9420_pdata *pd, const int index,
skb->protocol = eth_type_trans(skb, dev);
netif_receive_skb(skb);
- dev->last_rx = jiffies;
}
static int smsc9420_alloc_rx_buffer(struct smsc9420_pdata *pd, int index)
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 094d155..53941b9 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -588,8 +588,6 @@ vxge_rx_1b_compl(struct __vxge_hw_ring *ringh, void *dtr,
if (first_dtr)
vxge_hw_ring_rxd_post_post_wmb(ringh, first_dtr);
- dev->last_rx = jiffies;
-
vxge_debug_entryexit(VXGE_TRACE,
"%s:%d Exiting...",
__func__, __LINE__);
diff --git a/drivers/net/wireless/b43legacy/xmit.c b/drivers/net/wireless/b43legacy/xmit.c
index f79cee8..103f3c9 100644
--- a/drivers/net/wireless/b43legacy/xmit.c
+++ b/drivers/net/wireless/b43legacy/xmit.c
@@ -590,7 +590,6 @@ void b43legacy_rx(struct b43legacy_wldev *dev,
chanstat);
}
- dev->stats.last_rx = jiffies;
memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status));
ieee80211_rx_irqsafe(dev->wl->hw, skb);
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 7e05b40..dc22782 100755
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -587,7 +587,6 @@ static void xemaclite_rx_handler(struct net_device *dev)
dev->stats.rx_packets++;
dev->stats.rx_bytes += len;
- dev->last_rx = jiffies;
netif_rx(skb); /* Send the packet upstream */
}
diff --git a/drivers/s390/net/ctcm_main.c b/drivers/s390/net/ctcm_main.c
index 38b5079..c5b8387 100644
--- a/drivers/s390/net/ctcm_main.c
+++ b/drivers/s390/net/ctcm_main.c
@@ -164,7 +164,6 @@ void ctcm_unpack_skb(struct channel *ch, struct sk_buff *pskb)
priv->stats.rx_packets++;
priv->stats.rx_bytes += skblen;
netif_rx_ni(skb);
- dev->last_rx = jiffies;
if (len > 0) {
skb_pull(pskb, header->length);
if (skb_tailroom(pskb) < LL_HEADER_LENGTH) {
diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index bb1183a..271c4a8 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -676,7 +676,6 @@ static void netiucv_unpack_skb(struct iucv_connection *conn,
* we must use netif_rx_ni() instead of netif_rx()
*/
netif_rx_ni(skb);
- dev->last_rx = jiffies;
skb_pull(pskb, header->next);
skb_put(pskb, NETIUCV_HDRLEN);
}
diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 12ee7a3..7d7d6d9 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -449,7 +449,6 @@ static void qeth_l2_process_inbound_buffer(struct qeth_card *card,
QETH_DBF_HEX(CTRL, 3, hdr, QETH_DBF_CTRL_LEN);
continue;
}
- card->dev->last_rx = jiffies;
card->stats.rx_packets++;
card->stats.rx_bytes += len;
}
diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/qeth_l3_main.c
index d9fabe3..d2eabbc 100644
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1987,7 +1987,6 @@ static void qeth_l3_process_inbound_buffer(struct qeth_card *card,
continue;
}
- card->dev->last_rx = jiffies;
card->stats.rx_packets++;
card->stats.rx_bytes += len;
}
^ permalink raw reply related
* Re: [PATCH 2/2 next] sky2: B0_Y2LED controls the LEDs for both ports
From: Stephen Hemminger @ 2009-08-31 16:16 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Rene Mayrhofer, Richard Leitner
In-Reply-To: <4A99F8F6.6040903@ring3k.org>
On Sun, 30 Aug 2009 12:58:46 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> Only disable LED status control when both ports are disabled.
> The previous code disabled LED status control unconditionally
> in sky2_down.
>
> Tested with the limitation that my sky2 interface has no LEDs
> and a single port.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
> ---
> drivers/net/sky2.c | 23 ++++++++++++++++++++---
> 1 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index 2827f0d..864b8dc 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -213,6 +213,22 @@ static inline u16 gm_phy_read(struct sky2_hw *hw, unsigned port, u16 reg)
> return v;
> }
>
> +static void sky2_disable_status_led(struct sky2_port *sky2)
> +{
> + struct sky2_hw *hw = sky2->hw;
> + struct net_device *otherdev = hw->dev[sky2->port^1];
> +
> + if (!(otherdev && netif_running(otherdev))) {
> + sky2_write8(hw, B0_Y2LED, LED_STAT_OFF);
> + }
> +}
> +
> +static void sky2_enable_status_led(struct sky2_port *sky2)
> +{
> + struct sky2_hw *hw = sky2->hw;
> +
> + sky2_write8(hw, B0_Y2LED, LED_STAT_ON);
> +}
>
> static void sky2_power_on(struct sky2_hw *hw)
> {
> @@ -1530,6 +1546,8 @@ static int sky2_up(struct net_device *dev)
> if (err)
> goto err_out;
>
> + sky2_enable_status_led(sky2);
> +
> /* Enable interrupts from phy/mac for port */
> imask = sky2_read32(hw, B0_IMSK);
> imask |= portirq_msk[port];
> @@ -1886,8 +1904,7 @@ static int sky2_down(struct net_device *dev)
> sky2_phy_power_down(hw, port);
> spin_unlock_bh(&sky2->phy_lock);
>
> - /* turn off LED's */
> - sky2_write16(hw, B0_Y2LED, LED_STAT_OFF);
> + sky2_disable_status_led(sky2);
>
> sky2_tx_reset(hw, port);
>
> @@ -2989,7 +3006,7 @@ static void sky2_reset(struct sky2_hw *hw)
> sky2_write8(hw, B2_TI_CTRL, TIM_STOP);
> sky2_write8(hw, B2_TI_CTRL, TIM_CLR_IRQ);
>
> - sky2_write8(hw, B0_Y2LED, LED_STAT_ON);
> + sky2_write8(hw, B0_Y2LED, LED_STAT_OFF);
>
> /* Turn off descriptor polling */
> sky2_write32(hw, B28_DPT_CTRL, DPT_STOP);
NAK. I have simpler version of this coming.
--
^ permalink raw reply
* Re: Crypto oops in async_chainiv_do_postponed
From: Brad Bosch @ 2009-08-31 16:11 UTC (permalink / raw)
To: Herbert Xu; +Cc: Brad Bosch, linux-crypto, netdev, offbase0
In-Reply-To: <20090829104606.GA13141@gondor.apana.org.au>
Herbert Xu writes:
> Thanks for the detailed analysis and patch!
No problem, thanks for looking at it!
>
> > The null dereference occurs when subreq is dereferenced in
> > async_chainiv_do_postponed(). My guess is that the
> > skcipher_givcrypt_request block has been freed and subsequently
> > overwritten by the time the postponed request is processed. This
> > could happen if chainiv_givencrypt() returns anything other than
> > -EINPROGRESS after postponing the request. From what I can see, this
> > could indeed happen since the same err field in async_chainiv_ctx is
> > used both when the request is postponed and also when it is later
> > processed by the worker thread. Neither the lock, nor the
> > CHAINIV_STATE_INUSE bit in ctx->state will prevent this race which
> > results in the -EINPROGRESS err being overwritten between the time it
> > is placed in ctx->err in async_chainiv_postpone_request() and when it
> > is read back out in async_chainiv_schedule_work(). I am curious why
> > this method of returning the error code was used in the first place.
>
> Actually I think the problem is much less subtle than that :)
OK. I was looking for something subtle because the crash takes a long
time to happen. But do you agree that the race I described above also
a real bug?
>
> The problem is that whenever crypto_dequeue_request returns NULL,
> chainiv will never see the NULL pointer because we end up converting
> the pointer to skcipher_givcrypt_request which would have the value
> (NULL - off) where off is non-zero.
Yes, I see that this bug must be the bug we would likely encounter first.
Apparently, async_chainiv_do_postponed was never tested? But I don't
see how the patch you proposed below helps. We still don't seem to be
returning NULL from skcipher_dequeue_givcrypt when we reach the end of
the queue because __crypto_dequeue_request is not checking for NULL
before it subtracts offset.
Wouldn't the following (simpler, but untested) patch work?
Index: skcipher.h
===================================================================
RCS file: /share/cvs/sdg/kernels/kernel.wms/kernel_2_6_27/src/include/crypto/internal/skcipher.h,v
retrieving revision 1.1.1.1.4.2
diff -u -r1.1.1.1.4.2 skcipher.h
--- skcipher.h 10 Mar 2009 05:25:25 -0000 1.1.1.1.4.2
+++ skcipher.h 31 Aug 2009 15:56:50 -0000
@@ -85,8 +85,9 @@
static inline struct skcipher_givcrypt_request *skcipher_dequeue_givcrypt(
struct crypto_queue *queue)
{
- return container_of(ablkcipher_dequeue_request(queue),
- struct skcipher_givcrypt_request, creq);
+ struct ablkcipher_request *req = ablkcipher_dequeue_request(queue);
+ return req ? container_of(req, struct skcipher_givcrypt_request, creq)
+ : NULL;
}
static inline void *skcipher_givcrypt_reqctx(
Thanks!
--Brad
>
> Please let me know if this patch fixes the crash for you.
>
> commit 0c7d400fafaeab6014504a6a6249f01bac7f7db4
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat Aug 29 20:44:04 2009 +1000
>
> crypto: skcipher - Fix skcipher_dequeue_givcrypt NULL test
>
> As struct skcipher_givcrypt_request includes struct crypto_request
> at a non-zero offset, testing for NULL after converting the pointer
> returned by crypto_dequeue_request does not work. This can result
> in IPsec crashes when the queue is depleted.
>
> This patch fixes it by doing the pointer conversion only when the
> return value is non-NULL. In particular, we create a new function
> __crypto_dequeue_request that does the pointer conversion.
>
> Reported-by: Brad Bosch <bradbosch@comcast.net>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/crypto/algapi.c b/crypto/algapi.c
> index 56c62e2..df0863d 100644
> --- a/crypto/algapi.c
> +++ b/crypto/algapi.c
> @@ -692,7 +692,7 @@ out:
> }
> EXPORT_SYMBOL_GPL(crypto_enqueue_request);
>
> -struct crypto_async_request *crypto_dequeue_request(struct crypto_queue *queue)
> +void *__crypto_dequeue_request(struct crypto_queue *queue, unsigned int offset)
> {
> struct list_head *request;
>
> @@ -707,7 +707,14 @@ struct crypto_async_request *crypto_dequeue_request(struct crypto_queue *queue)
> request = queue->list.next;
> list_del(request);
>
> - return list_entry(request, struct crypto_async_request, list);
> + return (char *)list_entry(request, struct crypto_async_request, list) -
> + offset;
> +}
> +EXPORT_SYMBOL_GPL(__crypto_dequeue_request);
> +
> +struct crypto_async_request *crypto_dequeue_request(struct crypto_queue *queue)
> +{
> + return __crypto_dequeue_request(queue, 0);
> }
> EXPORT_SYMBOL_GPL(crypto_dequeue_request);
>
> diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
> index 0105454..5a2bd1c 100644
> --- a/include/crypto/algapi.h
> +++ b/include/crypto/algapi.h
> @@ -137,6 +137,7 @@ struct crypto_instance *crypto_alloc_instance(const char *name,
> void crypto_init_queue(struct crypto_queue *queue, unsigned int max_qlen);
> int crypto_enqueue_request(struct crypto_queue *queue,
> struct crypto_async_request *request);
> +void *__crypto_dequeue_request(struct crypto_queue *queue, unsigned int offset);
> struct crypto_async_request *crypto_dequeue_request(struct crypto_queue *queue);
> int crypto_tfm_in_queue(struct crypto_queue *queue, struct crypto_tfm *tfm);
>
> diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
> index 2ba42cd..3a748a6 100644
> --- a/include/crypto/internal/skcipher.h
> +++ b/include/crypto/internal/skcipher.h
> @@ -79,8 +79,8 @@ static inline int skcipher_enqueue_givcrypt(
> static inline struct skcipher_givcrypt_request *skcipher_dequeue_givcrypt(
> struct crypto_queue *queue)
> {
> - return container_of(ablkcipher_dequeue_request(queue),
> - struct skcipher_givcrypt_request, creq);
> + return __crypto_dequeue_request(
> + queue, offsetof(struct skcipher_givcrypt_request, creq.base));
> }
>
> static inline void *skcipher_givcrypt_reqctx(
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* differences in skb allocation in fill_packet_ipv4 and fill_packet_ipv6
From: Lucian Adrian Grijincu @ 2009-08-31 16:08 UTC (permalink / raw)
To: netdev
The skb is allocated differently in fill_packet_ipv4 and fill_packet_ipv6 (net/core/pktgen.c).
in fill_packet_ipv4():
datalen = (odev->hard_header_len + 16) & ~0xf;
skb = alloc_skb(pkt_dev->cur_pkt_size + 64 + datalen +
pkt_dev->pkt_overhead, GFP_ATOMIC);
but in fill_packet_ipv6():
skb = alloc_skb(pkt_dev->cur_pkt_size + 64 + 16 +
pkt_dev->pkt_overhead, GFP_ATOMIC);
hard_header_len was first added here in:
7ac5459ec0f074022818af35c589b9e2b406d7c3
[PKTGEN]: Respect hard_header_len of device.
A snip from the patch:
- skb = alloc_skb(pkt_dev->cur_pkt_size + 64 + 16, GFP_ATOMIC);
+ datalen = (odev->hard_header_len + 16) & ~0xf;
+ skb = alloc_skb(pkt_dev->cur_pkt_size + 64 + datalen, GFP_ATOMIC);
This patch only modifies fill_packet_ipv4(). Did someone forget to update
fill_packet_ipv6() as well or was this an ipv4-specific change (and why
would it be so)?
--
.
..: Lucian
^ 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