e same as that of the network stack receive side. That means
hard IRQ paths are unacceptable but softirq is OK.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtua
letion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
The value of reqsize must only be changed through the helper.
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
b/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
index 168195672e2e..b2979be613b8 100644
--- a/drivers/crypto/virtio
r
> implementation of serpent cipher")
> Fixes: b9f535ffe38f ("[CRYPTO] twofish: i586 assembly version")
> Fixes: ff0a70fe0536 ("crypto: twofish-x86_64-3way - module init/exit
> functions should be static")
> Fixes: 8280daad436e ("crypto: twofish - add 3-way para
tplug functions with the official version.
> The behavior remains unchanged.
>
> Cc: Gonglei
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: virtualization@lists.linux-foundation.org
> Cc: linux-cry
gned-off-by: Ram Muthiah
> [EB: adjusted commit message]
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/virtio/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
mi_watchdog.c| 2 +-
> drivers/char/virtio_console.c| 8
> 5 files changed, 8 insertions(+), 8 deletions(-)
Patches 1-3 applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: h
crypto/virtio/virtio_crypto_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Vir
ven't managed
>> to find one...
I think what it's trying to separate is using indirect->addr as a
base and then reading from that through copy_from_iter.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
11 +++
> drivers/crypto/virtio/virtio_crypto_algs.c | 4 +---
> 2 files changed, 4 insertions(+), 11 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
__
anually check the kernel code before reporting it.
>
> Signed-off-by: Jia-Ju Bai
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualizati
gt;
> Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
> Signed-off-by: Peter Wu
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
the patches to be squashed
then please send them in one email.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-fou
transfer_xxx_request_to_engine functions
>
> Corentin Labbe (6):
> Documentation: crypto: document crypto engine API
> crypto: engine - Permit to enqueue all async requests
> crypto: omap: convert to new crypto engine API
> crypto: virtio: convert to new crypto engine AP
+ int ret;
> + struct crypto_engine_reqctx *enginectx;
This all looks very good. Just one minor nit, since you're storing
this in the tfm ctx as opposed to the request ctx (which is indeed
an improvement), you should remove the "req" from its name.
Thanks!
all exposed API should
take the final types such as aead_request before casting it.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Vir
not want to expose any of the
base types such as crypto_alg, crypto_async_request to end-users
and that includes drivers. Only core API code should touch these
base types.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herber
> virtio-crypto's algorithm, make it's higher than software
> implementations but lower than the hardware ones.
>
> Suggested-by: Christian Borntraeger
> Signed-off-by: Gonglei
> Acked-by: Christian Borntraeger
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
er and ahash.
>
> For virtio-crypto device, I register an engine for each
> data virtqueue so that we can use the capability of
> multiple data queues in future.
>
> Cc: Baolin Wang
> Cc: Herbert Xu
> Cc: Michael S. Tsirkin
> Signed-off-by: Gonglei
Patch
t now.
Sure feel free to merge it through your tree.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@l
in my
tree before the merge window opened to make it for this cycle.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtu
the host then I'll take this patch.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-founda
p?
This is crazy! smp_rmb started out being strictly stronger than
smp_read_barrier_depends, when did this stop being the case?
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_
| use a fifo as rng backend, execute test 0 ~ 5 with no input of fifo
All applied. Thanks a lot!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization maili
Restore module licence and other attributes
When the virtio_pci driver was moved into virtio_pci_legacy.c the
module licence and other attributes went AWOL. This patch restores
them.
Signed-off-by: Herbert Xu
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.
On Sat, Dec 06, 2014 at 12:16:36PM +0800, Amos Kong wrote:
> When I hotunplug a busy virtio-rng device or try to access
> hwrng attributes in non-smp guest, it gets stuck.
Please resend these via the linux-crypto mailing list so they
can be picked up by patchwork.
Thanks,
--
Email: Herb
On Mon, Nov 10, 2014 at 09:47:27PM +0800, Herbert Xu wrote:
> On Mon, Nov 03, 2014 at 11:56:24PM +0800, Amos Kong wrote:
> >
> > @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
> >
> > if (rng->cleanup)
> > rng->cleanup
leanup_done = true;
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoun
On Sun, Nov 02, 2014 at 11:06:13PM +0800, Amos Kong wrote:
> On Fri, Oct 31, 2014 at 03:23:21PM +0800, Herbert Xu wrote:
> > On Fri, Oct 31, 2014 at 10:28:00AM +1030, Rusty Russell wrote:
> > > Herbert Xu writes:
> > > > On Thu, Sep 18, 2014 at 08:37:45PM +0800,
On Fri, Oct 31, 2014 at 10:28:00AM +1030, Rusty Russell wrote:
> Herbert Xu writes:
> > On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote:
> >> From: Rusty Russell
> >>
> >> The previous patch added one potential problem: we can still be
> >>
bviously better than what we have now, I don't believe
this is 100% safe as the cleanup function might still be running
even after the ref count hits zero. Once we return from this function
the module may be unloaded so we need to ensure that nothing is
runn
usty Russell
You totally corrupted Rusty's patch. If you're going to repost
his series you better make sure that you've got the right patches.
Just as well though as it made me think a little more about this
patch :)
Cheers,
--
Email: Herbert Xu
Home Page: http://go
not going to accept your fix which simply papers over
the problem.
Please bite the bullet and convert this over to RCU.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_
turned is ENOMEM which isn't of much interest to
the caller of probe anyway.
On the other hand, if you are calling hwrng_register you better be
damn sure that your hardware is ready to answer requests from the
hwrng system. Please don't add silly flags to work around this.
Cheers,
-
gt; apparent reason. Seems like a far stretch, though. Does anyone else
> > have an opinion on this?
>
> Herbert, do you have any preference?
So it's only virtio-rng that's a problem, right? How about if we
abuse the scan hook in virtio and move the hwrng_register there
On Tue, Jul 15, 2014 at 10:10:28AM +0530, Amit Shah wrote:
> On (Mon) 14 Jul 2014 [20:50:06], Herbert Xu wrote:
> > On Thu, Jul 10, 2014 at 03:42:33PM +0530, Amit Shah wrote:
> > > v3:
> > > - Kees Cook pointed out a weird side-effect: devices which have
> > &
init
>callback don't contribute to system randomness more than once. The
>weirdness is resolved here by using the randomness each time
>hwrng_init() is attempted, irrespective of the existence of the
>device's ->init() callback.
All applied to crypt
for data to arrive from
> > the host, which never happens.
> >
> > CC: Kees Cook
> > CC: Jason Cooper
> > CC: Herbert Xu
> > CC: # For v3.15+
> > Signed-off-by: Amit Shah
> > ---
> > drivers/char/hw_random/core.c | 6 ++
> >
d as before. There is no need for returning the add_buf
error unless add_buf is now doing an allocation itself that needs
to be retried.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://go
rlier it can go into linux-next.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization maili
mation of turning interrupt notification off. Evidently that
is not working in the way I intended it to.
I'm in the process of repeating the same experiment with cxgb3
which hopefully should let me turn interrupts off on descriptors
while still reporting completion status.
Cheers,
--
Vis
On Sun, Jul 05, 2009 at 11:26:58AM +0800, Herbert Xu wrote:
>
> Here's a another crazy idea:
>
> Let's use dummy TX descriptors to generate an interrupt, either
> with or without transmitting an actual packet on the wire depending
> on the NIC.
Here's an even cr
On Sat, Jul 04, 2009 at 05:09:10PM +0800, Herbert Xu wrote:
>
> One potential problem is if the socket is constantly running
> close to capacity, but that should only happen if the device
> TX queue is also close to capacity which means that the qdisc
> queue should be non-empty.
H
On Sat, Jul 04, 2009 at 03:42:45PM +0800, Herbert Xu wrote:
>
> Here's an idea: We let the sender decide whether we need to enable
> notification. This decision would be carried as a flag in the skb.
> For example, UDP would set this flag when its socket buffer is close
> t
this flag when its socket buffer is close
to capacity. Routing would set this flag per NAPI run, etc.
Of course you'd ignore this flag completely if the qdisc queue is
non-empty.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gon
rg/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mail
need to the skb to be freed (e.g., iSCSI or Xen), this
simply doesn't work.
So anytime someone tries to propose such a solution it is a sign
that they have bigger problems.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.
-
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https:
t a packet that is queued
in this way.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mai
because it's ugly and complex!
The right solution is to stop the queue properly.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
__
ated. As I have said repeatedly your driver should be
checking the stop-queue condition after transmission, not before.
In fact queueing it in the driver is just as bad as return TX_BUSY!
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gond
27;t think we should reshape our APIs based on how
broken the existing users are.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
__
ch case we should handle it
> correctly).
Most of them just do this:
start_xmit:
if (unlikely(queue is full)) {
/* This should never happen. */
return TX_BUSY;
}
transmit
if (queue is full)
stop queue
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email:
ore you get
a packet that overflows by looking at the amount of free queue
space after transmitting each packet.
For most drivers this is easy to do. What's so different about
virtio-net that makes this impossible?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
is just passing the problem to
someone else, which is not nice at all.
For example, anyone running tcpdump will now see the packet
twice.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.ap
o me. If we have to do this
to fix a bug, sure. But just doing it for the sake of it smells
wrong.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
__
On Fri, Apr 24, 2009 at 10:55:49AM +0200, Christian Borntraeger wrote:
> Am Thursday 16 April 2009 13:08:18 schrieb Herbert Xu:
>
> > Here's the patch. I'd appreciate if everyone can review it
> > and see if they can recreate the original race by
> >
> > 1
On Mon, Apr 20, 2009 at 02:26:35AM -0700, David Miller wrote:
>
> Do you think these two patches are ready to go into net-2.6
> now?
I think so.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
P
On Thu, Apr 16, 2009 at 07:09:52PM +0800, Herbert Xu wrote:
>
> tun: Fix sk_sleep races when attaching/detaching
That patch doesn't apply anymore because of contextual changes
caused by the first patch. Here's an update.
tun: Fix sk_sleep races when attaching/detaching
As t
e refcount in tun->sk has been reappropriated
for this purpose since it was already being used for that, albeit
from the opposite angle.
Note that we no longer zero tfile->tun since tun_get will return
NULL anyway after the refcount on tfile hits zero. Instead it
represents whether this dev
this purpose since it was already being used for that, albeit
from the opposite angle.
Note that we no longer zero tfile->tun since tun_get will return
NULL anyway after the refcount on tfile hits zero. Instead it
represents whether this device has ever been attached to a device.
Signed-off-by: H
On Wed, Apr 15, 2009 at 10:38:34PM +0800, Herbert Xu wrote:
>
> So how about this? We replace the dev destructor with our own that
> doesn't immediately call free_netdev. We only call free_netdev once
> all tun fd's attached to the device have been closed.
Here's th
On Thu, Apr 16, 2009 at 07:08:18PM +0800, Herbert Xu wrote:
>
> tun: Only free a netdev when all tun descriptors are closed
With that patch we can now safely move read_wait.
tun: Fix sk_sleep races when attaching/detaching
As the sk_sleep wait queue actually lives in tfile, which
t; less racy to deal with.
As I said the difficulty with putting the socket in tun_file
is how do you get it on the RX callback path without introducing
new races.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herb
counter to tun_struct.
We'd also change the async detach path to set a marker instead
of detaching. That marker can then be checked in places like
tun_get.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
uses sk_sleep can happen
anywhere.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing lis
ave to fix it whatever way we can. You can unfix it when you
come back :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.o
the network namespace
> exiting and destroying all of the virtual network devices before
> we close the file handle.
In that case what's the problem with holding a refcount to the
unregistered device until the process owning the fd closes it?
Cheers,
--
Visit Openswan at http://www.openswan
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.
On Wed, Apr 15, 2009 at 09:46:10PM +0800, Herbert Xu wrote:
>
> Does anything actually rely on this behaviour?
I doubt it :)
> If not we should just change it to not do that.
It appears that this was introduced in
commit c70f182940f988448f3c12a209d18b1edc276e33
Author: Eric W. Bieder
calling poll_wait?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtua
On Wed, Apr 15, 2009 at 04:36:10PM +0800, Herbert Xu wrote:
>
> Let me whip up a patch.
tun: Fix sk_sleep races when attaching/detaching
As the sk_sleep wait queue actually lives in tfile, which may be
detached from the tun device, bad things will happen when we use
sk_sleep after det
read_wait altogether and just use
socket.wait in tun_struct.
Let me whip up a patch.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herber
I outlined in my response to Jeremy's last note.
When combined with namespaces I don't see why using the kernel TCP
stack would create any security problems that wouldn't otherwise
exist.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Hom
> ...
> > + memcpy(hdr, p, sizeof(*hdr));
> > + p += sizeof(*hdr);
>
> I think you need kmap_atomic() here to access the page. And yes, that will
> effect performance :(
No we don't. kmap would only be necessary for highmem which
,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@
On Tue, Jul 15, 2008 at 06:25:04PM +1000, Rusty Russell wrote:
>
> Oops. I grepped for LRO when I did this and found nothing.
>
> How's this one?
Looks good. Thanks!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROT
are
forwarding packets which is totally unnecessary for virtio.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http:/
On Mon, Jul 14, 2008 at 10:40:49PM -0500, Rusty Russell wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
>
> This patch adds some basic ethtool operations to virtio_net so
> I could test SG without GSO (which was really useful because TSO
> turned out to be buggy :)
>
> S
On Thu, May 29, 2008 at 11:32:51AM +0100, Mark McLoughlin wrote:
>
> Subject: [PATCH 1/1] tun: Do not use kmap_atomic() since memcpy_fromiovec()
> can sleep
>
> Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
Good catch!
Thanks,
--
Visit Openswan at http://www.openswa
Mark McLoughlin <[EMAIL PROTECTED]>
Good catch! Clearly shows I never ran this across a real Ethernet
device :)
Acked-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: htt
he guest at least
unpredictable on start-up without increasing the guest's entropy,
and use the host's random to actually increase the guest's entropy.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://go
kb: we only queue one. */
> + kfree_skb(skb);
> + goto stop_queue;
We should increment the drop counter here.
Otherwise these patches all look good to me.
Acked-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswa
d
just drop them if they show up.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Vi
On Tue, Apr 22, 2008 at 05:01:46AM +1000, Rusty Russell wrote:
> On Friday 18 April 2008 13:21:42 Herbert Xu wrote:
> > +static int virtnet_change_mtu(struct net_device *dev, int mtu)
> > +{
> > + int max = 65535 - ETH_HLEN;
> > +
> > + if (mtu >
On Sat, Apr 19, 2008 at 12:08:04AM +1000, Rusty Russell wrote:
> On Friday 18 April 2008 13:24:27 Herbert Xu wrote:
> > Finally this patch lets virtio_net receive GSO packets in addition
> > to sending them. This can definitely be optimised for the non-GSO
> > case. F
skb_shinfo(skb)->nr_frags++;
+ }
+
num = skb_to_sgvec(skb, sg+1, 0, skb->len) + 1;
skb_queue_head(&vi->recv, skb);
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROT
"hardware" checksums? */
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virt
e *vlan, const char
*ifname1,
s = net_tap_fd_init(vlan, fd);
if (!s)
return -1;
+
+s->gso = gso;
snprintf(s->vc->info_str, sizeof(s->vc->info_str),
"tap: ifname=%s setup_script=%s", ifname, setup_script);
if (down_script &&
rr = get_user_skb_frags(iv, count, sinfo->frags);
+ err = get_user_skb_frags(iv, count, sinfo);
if (err < 0)
goto fail;
- sinfo->nr_frags = err;
skb->len += len;
skb->data_len += len;
+ skb->truesize += len;
e IFF_RECV_GSO 0x0800
+#define IFF_ALL_FLAGS (IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE | \
+ IFF_VIRTIO_HDR | IFF_RECV_CSUM | IFF_RECV_GSO)
struct tun_pi {
unsigned short flags;
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EM
N_RECV_CSUM 0x0400
+#define TUN_RECV_GSO 0x0400
/* Ioctl defines */
#define TUNSETNOCSUM _IOW('T', 200, int)
@@ -87,6 +90,9 @@ struct tun_struct {
#define IFF_TAP0x0002
#define IFF_NO_PI 0x1000
#define IFF_ONE_QUEUE 0x2000
+#define IFF_VIRTIO_HDR 0x4000
+#defin
G/TSO, and the other useful for testing SG per se. The
other patch is to the KVM backend to make all this work. It isn't
the prettiest or the smartest solution but it was the easiest :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]&
can clone individual pages out of this skb and put it into a new
skb. Therefore whatever scheme we come up with will either need
to be page-based, or add a flag to tell the network stack that it
can't clone those pages.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbe
just "hdr_len" rather than "gso_hdr_len"?
Sounds fine to me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
__
nothing to do with GSO as you
also need it for SG with large MTUs.
I think this is more flexible than the Xen approach where this is
essentially hard-coded to 64 bytes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: htt
gso_type |= SKB_GSO_DODGY;
>skb_shinfo(skb)->gso_segs = 0;
> + skb_set_transport_header(skb, hdr->gso_hdr_len);
Why do we need this? When receiving GSO packets from an untrusted
source the network stack will fill in the transport header offset
after verifying that the headers are san
e can have these adopt the new SMP barriers
on x86 instead of the IO ones as they currently do.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: htt
causes problems with AF_PACKET seeing things twice.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
to one physical interface
unless it contains IP fragments which should never happen for TCP.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~her
1 - 100 of 114 matches
Mail list logo
