* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 8:18 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516080702.GA1857@gondor.apana.org.au>
On Mon, May 16, 2011 at 06:07:02PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
> >
> > So how is NETIF_F_SG supposed to be enabled then?
>
> It should either be enabled at device creation time, or whatever
> user-space entity managing the device creation should enable it
> along with checksumming and anything else applicable.
There's no interface for userspace to enable it: userspace
only has an ioctl to enable/disable checksum offloading.
SG is an implementation detail.
> > In upstream kernels userspace can disable checksum offloading then
> > re-enable and get SG set back. userspace came to depend on this
> > behaviour so I think changing this is a regression.
>
> Can you point me to the relevant code in the upstream kernel?
> I'm not aware of any automatic SG enabling for network devices
> in general when you enable checksum offloading.
>
> Cheers,
I think what happens _SG is enabled at device creation time and
then upstream just keeps it on always, even when user clears
CSUM. With net-next code changed so that _SG gets cleared when CSUM
'gets cleared. But then it does not get reenabled when CSUM
gets reenabled.
> --
> Email: Herbert Xu <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
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 8:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516073210.GB6610@redhat.com>
On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
>
> So how is NETIF_F_SG supposed to be enabled then?
It should either be enabled at device creation time, or whatever
user-space entity managing the device creation should enable it
along with checksumming and anything else applicable.
> In upstream kernels userspace can disable checksum offloading then
> re-enable and get SG set back. userspace came to depend on this
> behaviour so I think changing this is a regression.
Can you point me to the relevant code in the upstream kernel?
I'm not aware of any automatic SG enabling for network devices
in general when you enable checksum offloading.
Cheers,
--
Email: Herbert Xu <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
* Re: [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Or Gerlitz @ 2011-05-16 8:05 UTC (permalink / raw)
To: Hefty, Sean
Cc: Roland Dreier, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373F428-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hefty, Sean wrote:
>> +struct rdma_cm_id_stats {
>> + __u32 qp_num;
>> + __u32 bound_dev_if;
>> + __u32 port_space;
>> + __s32 pid;
>> + __u8 cm_state;
>> + __u8 node_type;
>> + __u8 port_num;
>> + __u8 reserved;
>> +};
>
> We may also want to add qp_type
Sean,
Isn't the port space enough here? specifically, what qp type buys us
over port space?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 7:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110505100506.GA20111@gondor.apana.org.au>
On Thu, May 05, 2011 at 08:05:06PM +1000, Herbert Xu wrote:
> On Thu, May 05, 2011 at 05:34:43PM +0800, Shan Wei wrote:
> >
> > TUN_F_TSO4, TUN_F_TSO6, TUN_F_TSO_ECN, TUN_F_UFO these features are
> > depend on NETIF_F_SG. If NETIF_F_SG is not set, these features are not be
> > enabled and warnings are printed in netdev_fix_features().
>
> No, when the user turns off checksum offload everything should
> be turned off as well. However, when it's turned on, we shouldn't
> enable everything automatically.
>
> Cheers,
So how is NETIF_F_SG supposed to be enabled then?
In upstream kernels userspace can disable checksum offloading then
re-enable and get SG set back. userspace came to depend on this
behaviour so I think changing this is a regression.
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 7:28 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, Ben Hutchings, herbert
In-Reply-To: <20110505152644.GA8459@rere.qmqm.pl>
On Thu, May 05, 2011 at 05:26:44PM +0200, Michał Mirosław wrote:
> On Wed, May 04, 2011 at 09:18:14PM +0300, Michael S. Tsirkin wrote:
> > BTW, I just noticed that net-next spits out
> > many of the following when I run any VMs:
> [...]
> > tap0: Features changed: 0x40004040 -> 0x401b4849
>
> Before this message, userspace called ioctl(TIOCSETOFFLOAD)
> turning offloads on.
>
> > tap0: Dropping NETIF_F_SG since no checksum feature.
> > tap0: Dropping NETIF_F_GSO since no SG feature.
> > tap0: Features changed: 0x401b4849 -> 0x40004040
>
> And then it probably called ioctl(TIOCSETOFFLOAD) again, disabling them.
>
> Best Regards,
> Michał Mirosław
I'd have to look at this some more, but I know qemu-kvm
supports offloads with current kernels.
There seems to be some kernel behaviour change here.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
From: Eric Dumazet @ 2011-05-16 7:26 UTC (permalink / raw)
To: David Miller
Cc: solar, segoon, linux-kernel, netdev, peak, kees.cook,
dan.j.rosenberg, eugene, nelhage, kuznet, pekkas, jmorris,
yoshfuji, kaber
In-Reply-To: <20110515.174430.1379973540554096232.davem@davemloft.net>
Le dimanche 15 mai 2011 à 17:44 -0400, David Miller a écrit :
> Just get rid of ping_ioctl() entirely, as that is the effect of
> this change since inet_ioctl() returns -ENOIOCTLCMD when
> sk_prot->ioctl is NULL.
>
> Also get rid of asm/ioctls.h since that will be no longer needed.
Sure, here is updated version, thanks.
[PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
udp_ioctl() really handles UDP and UDPLite protocols.
1) It can increment UDP_MIB_INERRORS in case first_packet_length() finds
a frame with bad checksum.
2) It has a dependency on sizeof(struct udphdr), not applicable to
ICMP/PING
If ping sockets need to handle SIOCINQ/SIOCOUTQ ioctl, this should be
done differently.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Vasiliy Kulikov <segoon@openwall.com>
---
net/ipv4/ping.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 7041d09..41836ab 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -22,7 +22,6 @@
#include <asm/system.h>
#include <linux/uaccess.h>
-#include <asm/ioctls.h>
#include <linux/types.h>
#include <linux/fcntl.h>
#include <linux/socket.h>
@@ -609,23 +608,6 @@ do_confirm:
goto out;
}
-/*
- * IOCTL requests applicable to the UDP^H^H^HICMP protocol
- */
-
-int ping_ioctl(struct sock *sk, int cmd, unsigned long arg)
-{
- pr_debug("ping_ioctl(sk=%p,sk->num=%u,cmd=%d,arg=%lu)\n",
- inet_sk(sk), inet_sk(sk)->inet_num, cmd, arg);
- switch (cmd) {
- case SIOCOUTQ:
- case SIOCINQ:
- return udp_ioctl(sk, cmd, arg);
- default:
- return -ENOIOCTLCMD;
- }
-}
-
int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
size_t len, int noblock, int flags, int *addr_len)
{
@@ -735,7 +717,6 @@ struct proto ping_prot = {
.close = ping_close,
.connect = ip4_datagram_connect,
.disconnect = udp_disconnect,
- .ioctl = ping_ioctl,
.setsockopt = ip_setsockopt,
.getsockopt = ip_getsockopt,
.sendmsg = ping_sendmsg,
^ permalink raw reply related
* Re: [PATCH 14/18] virtio: add api for delayed callbacks
From: Rusty Russell @ 2011-05-16 7:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110515124818.GD24932-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, 15 May 2011 15:48:18 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, May 09, 2011 at 03:27:33PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:52:33 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > Add an API that tells the other side that callbacks
> > > should be delayed until a lot of work has been done.
> > > Implement using the new used_event feature.
> >
> > Since you're going to add a capacity query anyway, why not add the
> > threshold argument here?
>
> I thought that if we keep the API kind of generic
> there might be more of a chance that future transports
> will be able to implement it. For example, with an
> old host we can't commit to a specific index.
No, it's always a hint anyway: you can be notified before the threshold
is reached. But best make it explicit I think.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Rusty Russell @ 2011-05-16 7:12 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110515135541.GF24932-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, 15 May 2011 16:55:41 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, May 09, 2011 at 02:03:26PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:51:47 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > Use the new avail_event feature to reduce the number
> > > of exits from the guest.
> >
> > Figures here would be nice :)
>
> You mean ASCII art in comments?
I mean benchmarks of some kind.
>
> > > @@ -228,6 +237,12 @@ add_head:
> > > * new available array entries. */
> > > virtio_wmb();
> > > vq->vring.avail->idx++;
> > > + /* If the driver never bothers to kick in a very long while,
> > > + * avail index might wrap around. If that happens, invalidate
> > > + * kicked_avail index we stored. TODO: make sure all drivers
> > > + * kick at least once in 2^16 and remove this. */
> > > + if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
> > > + vq->kicked_avail_valid = true;
> >
> > If they don't, they're already buggy. Simply do:
> > WARN_ON(vq->vring.avail->idx == vq->kicked_avail);
>
> Hmm, but does it say that somewhere?
AFAICT it's a corollary of:
1) You have a finite ring of size <= 2^16.
2) You need to kick the other side once you've done some work.
> > > @@ -482,6 +517,8 @@ void vring_transport_features(struct virtio_device *vdev)
> > > break;
> > > case VIRTIO_RING_F_USED_EVENT_IDX:
> > > break;
> > > + case VIRTIO_RING_F_AVAIL_EVENT_IDX:
> > > + break;
> > > default:
> > > /* We don't understand this bit. */
> > > clear_bit(i, vdev->features);
> >
> > Does this belong in a prior patch?
> >
> > Thanks,
> > Rusty.
>
> Well if we don't support the feature in the ring we should not
> ack the feature, right?
Ah, you're right.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 06/18] virtio_ring: avail event index interface
From: Rusty Russell @ 2011-05-16 6:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110515124727.GA24932-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, 15 May 2011 15:47:27 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, May 09, 2011 at 01:43:15PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:51:19 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > #define VIRTIO_RING_F_USED_EVENT_IDX 29
> > > +/* The Host publishes the avail index for which it expects a kick
> > > + * at the end of the used ring. Guest should ignore the used->flags field. */
> > > +#define VIRTIO_RING_F_AVAIL_EVENT_IDX 32
> >
> > Are you really sure we want to separate the two? Seems a little simpler
> > to have one bit to mean "we're publishing our threshold". For someone
> > implementing this from scratch, it's a little simpler.
> >
> > Or are there cases where the old style makes more sense?
> >
> > Thanks,
> > Rusty.
>
> Hmm, it makes debugging easier as each side can disable
> publishing separately - I used it all the time when I saw
> e.g. networking stuck to guess whether I need to investigate the
> interrupt or the exit handling.
>
> But I'm not hung up on this.
>
> Let me know pls.
If we combine them into one, then these patches no longer depend on
the feature bit expansion, which is worthwhile (though I'll take both).
Thanks,
Rusty.
^ permalink raw reply
* [PATCH] 2.6.38 ENC28J60 works with half-duplex DMA
From: Davide Rizzo @ 2011-05-16 5:33 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 100 bytes --]
Please consider this patch, that allows ENC28J60 to be used on
machines with half-duplex DMA on SPI
[-- Attachment #2: enc28j60.c-2.6.38.patch --]
[-- Type: text/x-patch, Size: 5357 bytes --]
This patch modifies SPI access to take advantage of DMA on machines supporting
only half-duplex SPI DMA (like Samsung S3C2410)
Signed-off-by: Davide Rizzo <elpa.rizzo@gmail.com>
---
diff -urNp linux-2.6.38/drivers/net/enc28j60.c linux-2.6.38.elpa/drivers/net/enc28j60.c
--- linux-2.6.38/drivers/net/enc28j60.c 2011-03-15 02:20:32.000000000 +0100
+++ linux-2.6.38.elpa/drivers/net/enc28j60.c 2011-05-14 09:56:05.701797208 +0200
@@ -36,6 +36,8 @@
#define SPI_OPLEN 1
+#define FCLK_MAX 20000000
+
#define ENC28J60_MSG_DEFAULT \
(NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN | NETIF_MSG_LINK)
@@ -84,29 +86,33 @@ static struct {
* SPI read buffer
* wait for the SPI transfer and copy received data to destination
*/
-static int
-spi_read_buf(struct enc28j60_net *priv, int len, u8 *data)
+static int spi_read_buf(struct enc28j60_net *priv, int len, u8 *data)
{
- u8 *rx_buf = priv->spi_transfer_buf + 4;
- u8 *tx_buf = priv->spi_transfer_buf;
struct spi_transfer t = {
- .tx_buf = tx_buf,
- .rx_buf = rx_buf,
- .len = SPI_OPLEN + len,
+ .tx_buf = priv->spi_transfer_buf,
+ .rx_buf = NULL,
+ .len = SPI_OPLEN,
+ .cs_change = 0,
+ .speed_hz = FCLK_MAX,
+ };
+ struct spi_transfer r = {
+ .tx_buf = NULL,
+ .rx_buf = data,
+ .len = len,
+ .cs_change = 1,
+ .speed_hz = FCLK_MAX,
};
struct spi_message msg;
int ret;
- tx_buf[0] = ENC28J60_READ_BUF_MEM;
- tx_buf[1] = tx_buf[2] = tx_buf[3] = 0; /* don't care */
+ priv->spi_transfer_buf[0] = ENC28J60_READ_BUF_MEM;
spi_message_init(&msg);
spi_message_add_tail(&t, &msg);
+ spi_message_add_tail(&r, &msg);
ret = spi_sync(priv->spi, &msg);
- if (ret == 0) {
- memcpy(data, &rx_buf[SPI_OPLEN], len);
+ if (ret == 0)
ret = msg.status;
- }
if (ret && netif_msg_drv(priv))
printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
__func__, ret);
@@ -114,20 +120,26 @@ spi_read_buf(struct enc28j60_net *priv,
return ret;
}
-/*
- * SPI write buffer
- */
-static int spi_write_buf(struct enc28j60_net *priv, int len,
- const u8 *data)
+static int spi_send(struct enc28j60_net *priv, u8 cmd, int len, const u8 *data)
{
int ret;
+ struct spi_message msg;
+ struct spi_transfer t = {
+ .tx_buf = priv->spi_transfer_buf,
+ .rx_buf = NULL,
+ .len = len + 1,
+ .cs_change = 1,
+ .speed_hz = FCLK_MAX,
+ };
if (len > SPI_TRANSFER_BUF_LEN - 1 || len <= 0)
ret = -EINVAL;
else {
- priv->spi_transfer_buf[0] = ENC28J60_WRITE_BUF_MEM;
+ spi_message_init(&msg);
+ spi_message_add_tail(&t, &msg);
+ priv->spi_transfer_buf[0] = cmd;
memcpy(&priv->spi_transfer_buf[1], data, len);
- ret = spi_write(priv->spi, priv->spi_transfer_buf, len + 1);
+ ret = spi_sync(priv->spi, &msg);
if (ret && netif_msg_drv(priv))
printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
__func__, ret);
@@ -136,28 +148,56 @@ static int spi_write_buf(struct enc28j60
}
/*
+ * SPI write buffer
+ */
+static int spi_write_buf(struct enc28j60_net *priv, int len,
+ const u8 *data)
+{
+ return spi_send(priv, ENC28J60_WRITE_BUF_MEM, len, data);
+}
+
+/*
* basic SPI read operation
*/
-static u8 spi_read_op(struct enc28j60_net *priv, u8 op,
- u8 addr)
+static u8 spi_read_op(struct enc28j60_net *priv, u8 op, u8 addr)
{
- u8 tx_buf[2];
- u8 rx_buf[4];
+ u8 tx_buf;
+ u8 rx_buf[SPI_OPLEN + 1];
u8 val = 0;
+ struct spi_transfer t = {
+ .tx_buf = &tx_buf,
+ .rx_buf = NULL,
+ .len = SPI_OPLEN,
+ .cs_change = 0,
+ .speed_hz = FCLK_MAX,
+ };
+ struct spi_transfer r = {
+ .tx_buf = NULL,
+ .rx_buf = rx_buf,
+ .len = SPI_OPLEN,
+ .cs_change = 1,
+ .speed_hz = FCLK_MAX,
+ };
+ struct spi_message msg;
int ret;
- int slen = SPI_OPLEN;
/* do dummy read if needed */
if (addr & SPRD_MASK)
- slen++;
+ r.len++;
+
+ tx_buf = op | (addr & ADDR_MASK);
- tx_buf[0] = op | (addr & ADDR_MASK);
- ret = spi_write_then_read(priv->spi, tx_buf, 1, rx_buf, slen);
- if (ret)
+ spi_message_init(&msg);
+ spi_message_add_tail(&t, &msg);
+ spi_message_add_tail(&r, &msg);
+ ret = spi_sync(priv->spi, &msg);
+ if (ret == 0)
+ ret = msg.status;
+ if (ret && netif_msg_drv(priv))
printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
__func__, ret);
else
- val = rx_buf[slen - 1];
+ val = rx_buf[r.len - 1];
return val;
}
@@ -165,18 +205,9 @@ static u8 spi_read_op(struct enc28j60_ne
/*
* basic SPI write operation
*/
-static int spi_write_op(struct enc28j60_net *priv, u8 op,
- u8 addr, u8 val)
+static int spi_write_op(struct enc28j60_net *priv, u8 op, u8 addr, u8 val)
{
- int ret;
-
- priv->spi_transfer_buf[0] = op | (addr & ADDR_MASK);
- priv->spi_transfer_buf[1] = val;
- ret = spi_write(priv->spi, priv->spi_transfer_buf, 2);
- if (ret && netif_msg_drv(priv))
- printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
- __func__, ret);
- return ret;
+ return spi_send(priv, op | (addr & ADDR_MASK), 1, &val);
}
static void enc28j60_soft_reset(struct enc28j60_net *priv)
@@ -1572,6 +1603,12 @@ static int __devinit enc28j60_probe(stru
dev_set_drvdata(&spi->dev, priv); /* spi to priv reference */
SET_NETDEV_DEV(dev, &spi->dev);
+ /* Configure the SPI bus */
+ spi->mode = SPI_MODE_0;
+ spi->bits_per_word = 8;
+ spi->max_speed_hz = FCLK_MAX;
+ spi_setup(spi);
+
if (!enc28j60_chipset_init(dev)) {
if (netif_msg_probe(priv))
dev_info(&spi->dev, DRV_NAME " chip not found\n");
^ permalink raw reply
* Re: [PATCH net-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Ben Hutchings @ 2011-05-16 2:45 UTC (permalink / raw)
To: Michał Mirosław; +Cc: David Miller, netdev
In-Reply-To: <20110514103539.GA5214@rere.qmqm.pl>
On Sat, 2011-05-14 at 12:35 +0200, Michał Mirosław wrote:
> On Sat, May 14, 2011 at 02:05:42AM +0100, Ben Hutchings wrote:
> > ethtool_set_feature_compat() squashes the feature mask into a boolean,
> > which is not correct for ethtool_ops::set_flags.
> >
> > We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
> > makes things more complicated for the ethtool utility and any other
> > application using the ethtool API. They will still need to fall back to
> > the old offload control commands in order to support older kernel
> > versions. The fallback code in the kernel adds a third possibility for
> > them to handle. So make ETHTOOL_SFEATURES fail when the driver
> > implements the old offload control operations, and let userland do the
> > fallback.
>
> BTW, the idea behind the compat code is that if ETHTOOL_[GS]FEATURES is
> available, then there should be no need to fallback to old ops. For
> a userspace tool that targets only kernels >= 2.6.39 there's no need
> to care about old ops at all.
Well that's not true, because those tools still have to deal with
ETHTOOL_F_COMPAT. And we're supposed to have all drivers converted for
2.6.40, so the hypothetical new tool only has to wait one more release.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next] net: drivers: kill two unused macro definitions
From: David Miller @ 2011-05-15 22:01 UTC (permalink / raw)
To: jpirko; +Cc: shanwei, fubar, andy, mirq-linux, eric.dumazet, ebiederm, netdev
In-Reply-To: <20110514075334.GA2751@psychotron>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sat, 14 May 2011 09:53:35 +0200
> Sat, May 14, 2011 at 09:08:47AM CEST, shanwei@cn.fujitsu.com wrote:
>>
>>
>>Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
...
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: ping: dont call udp_ioctl()
From: David Miller @ 2011-05-15 21:44 UTC (permalink / raw)
To: solar
Cc: eric.dumazet, segoon, linux-kernel, netdev, peak, kees.cook,
dan.j.rosenberg, eugene, nelhage, kuznet, pekkas, jmorris,
yoshfuji, kaber
In-Reply-To: <20110515213018.GA26820@openwall.com>
From: Solar Designer <solar@openwall.com>
Date: Mon, 16 May 2011 01:30:18 +0400
> On Sun, May 15, 2011 at 10:18:40AM +0200, Eric Dumazet wrote:
>> Do we really need to support SIOCOUTQ and SIOCINQ ioctls for ping
>> sockets ?
>
> Probably not.
>
>> BTW, link
>> (ftp://mirrors.kernel.org/openwall/Owl/current/sources/Owl/packages/iputils/iputils-ss020927.tar.gz ) provided in http://openwall.info/wiki/people/segoon/ping is not working.
>>
>> I had to manually patch iputils-s20101006.tar.bz2 instead.
>
> Oh, the link broke precisely because we updated to s20101006 since then,
> and the link was to our current branch. I've just updated the wiki page
> to include links both for iputils-ss020927 and for iputils-s20101006
> (both original tarballs and patches).
>
>> [PATCH net-next-2.6] net: ping: dont call udp_ioctl()
>>
>> udp_ioctl() really handles UDP and UDPLite protocols.
>>
>> 1) It can increment UDP_MIB_INERRORS in case first_packet_length() finds
>> a frame with bad checksum.
>>
>> 2) It has a dependency on sizeof(struct udphdr), not applicable to
>> ICMP/PING
>>
>> If ping sockets need to handle SIOCINQ/SIOCOUTQ ioctl, this should be
>> done differently.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> CC: Vasiliy Kulikov <segoon@openwall.com>
>
> Reviewed-by: Solar Designer <solar@openwall.com>
Just get rid of ping_ioctl() entirely, as that is the effect of
this change since inet_ioctl() returns -ENOIOCTLCMD when
sk_prot->ioctl is NULL.
Also get rid of asm/ioctls.h since that will be no longer needed.
Thanks.
^ permalink raw reply
* Re: [net-next-2.6 00/10] caif: rcu, refactoring and bugfixes
From: David Miller @ 2011-05-15 21:48 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev
In-Reply-To: <1305290648-9613-1-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Fri, 13 May 2011 14:43:58 +0200
> This patch-set introduces RCU in the CAIF stack and
> fixes problems found when removing CAIF Link layer during traffic.
>
> The pattern used for RCU is mostly this:
> rcu_read_lock();
> p = get();
> hold(p);
> rcu_read_unlock();
> use(p);
> put(p);
>
> And when freeing:
> synchronize_rcu();
> wait_refcnt(p);
> kfree(p);
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: ping: dont call udp_ioctl()
From: Solar Designer @ 2011-05-15 21:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Vasiliy Kulikov, David Miller, linux-kernel, netdev, peak,
kees.cook, dan.j.rosenberg, eugene, nelhage, kuznet, pekkas,
jmorris, yoshfuji, kaber
In-Reply-To: <1305447520.3120.88.camel@edumazet-laptop>
On Sun, May 15, 2011 at 10:18:40AM +0200, Eric Dumazet wrote:
> Do we really need to support SIOCOUTQ and SIOCINQ ioctls for ping
> sockets ?
Probably not.
> BTW, link
> (ftp://mirrors.kernel.org/openwall/Owl/current/sources/Owl/packages/iputils/iputils-ss020927.tar.gz ) provided in http://openwall.info/wiki/people/segoon/ping is not working.
>
> I had to manually patch iputils-s20101006.tar.bz2 instead.
Oh, the link broke precisely because we updated to s20101006 since then,
and the link was to our current branch. I've just updated the wiki page
to include links both for iputils-ss020927 and for iputils-s20101006
(both original tarballs and patches).
> [PATCH net-next-2.6] net: ping: dont call udp_ioctl()
>
> udp_ioctl() really handles UDP and UDPLite protocols.
>
> 1) It can increment UDP_MIB_INERRORS in case first_packet_length() finds
> a frame with bad checksum.
>
> 2) It has a dependency on sizeof(struct udphdr), not applicable to
> ICMP/PING
>
> If ping sockets need to handle SIOCINQ/SIOCOUTQ ioctl, this should be
> done differently.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Vasiliy Kulikov <segoon@openwall.com>
Reviewed-by: Solar Designer <solar@openwall.com>
Thanks,
Alexander
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Eric Dumazet @ 2011-05-15 21:10 UTC (permalink / raw)
To: Joe Perches; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1305490850.8178.57.camel@Joe-Laptop>
Le dimanche 15 mai 2011 à 13:20 -0700, Joe Perches a écrit :
> On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> > Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > > There are some addresses in the assigned vendor block that don't obey
> > > the locally assigned convention. These should be avoided by random_ether_addr
> > > assignment.
> > We call random_ether_addr() for some virtual devices, maybe we can add a
> > __random_ether_addr() helper for them and not avoid these OUI ?
>
> Unless it's speed critical, it's probably not worthwhile.
>
Speed was not my concern, but getting idea of why avoiding pre-assigned
OUI was a concern for them, if they dont hit a real Ethernet domain.
> I think that using get_random_bytes, because it can drain
> the entropy pool, may not be a great thing to do.
>
This has litle to do with Stephen patch. You could discuss this with
Matt Mackall.
By the way, since 2.6.29 every exec() gets 16 bytes from
get_random_bytes() for PRNG seeding.
Typical machine starts far more programs than network interfaces ;)
Anyway, it seems to have no impact at all, even gathering 128*6 bytes
here :
# cat /proc/sys/kernel/random/entropy_avail
142
# modprobe dummy numdummies=128
# cat /proc/sys/kernel/random/entropy_avail
156
^ permalink raw reply
* [PATCH] CDC NCM: release interfaces fix in unbind()
From: Alexey Orishko @ 2011-05-15 20:28 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, davem, gregkh, oliver, Alexey Orishko
Signed-off-by: Alexey Orishko <alexey.orishko@stericsson.com>
---
drivers/net/usb/cdc_ncm.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 4ab557d..500b1a6 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -54,7 +54,7 @@
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc.h>
-#define DRIVER_VERSION "06-May-2011"
+#define DRIVER_VERSION "15-May-2011"
/* CDC NCM subclass 3.2.1 */
#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
@@ -652,28 +652,25 @@ error:
static void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf)
{
struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
- struct usb_driver *driver;
+ struct usb_driver *driver = driver_of(intf);
if (ctx == NULL)
return; /* no setup */
- driver = driver_of(intf);
-
- usb_set_intfdata(ctx->data, NULL);
- usb_set_intfdata(ctx->control, NULL);
- usb_set_intfdata(ctx->intf, NULL);
-
/* release interfaces, if any */
if (ctx->data_claimed) {
+ usb_set_intfdata(ctx->data, NULL);
usb_driver_release_interface(driver, ctx->data);
ctx->data_claimed = 0;
}
if (ctx->control_claimed) {
+ usb_set_intfdata(ctx->control, NULL);
usb_driver_release_interface(driver, ctx->control);
ctx->control_claimed = 0;
}
+ usb_set_intfdata(ctx->intf, NULL);
cdc_ncm_free(ctx);
}
--
1.7.4.3
^ permalink raw reply related
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Joe Perches @ 2011-05-15 20:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1305488809.3120.162.camel@edumazet-laptop>
On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > There are some addresses in the assigned vendor block that don't obey
> > the locally assigned convention. These should be avoided by random_ether_addr
> > assignment.
> We call random_ether_addr() for some virtual devices, maybe we can add a
> __random_ether_addr() helper for them and not avoid these OUI ?
Unless it's speed critical, it's probably not worthwhile.
I think that using get_random_bytes, because it can drain
the entropy pool, may not be a great thing to do.
There's little value in crypto secure OUI's for random
ethernet addresses.
I think using get_random_int or random32 is probably good
enough.
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Eric Dumazet @ 2011-05-15 19:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110513171729.247b126e@nehalam>
Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> There are some addresses in the assigned vendor block that don't obey
> the locally assigned convention. These should be avoided by random_ether_addr
> assignment.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
We call random_ether_addr() for some virtual devices, maybe we can add a
__random_ether_addr() helper for them and not avoid these OUI ?
^ permalink raw reply
* Re: [net-next-2.6 00/13][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-05-15 19:46 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1305448890.3355.3.camel@jtkirshe-MOBL1>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 15 May 2011 01:41:30 -0700
> On Sat, 2011-05-14 at 22:21 -0700, David Miller wrote:
>> How are the ethtool op conversions coming so I can apply the patch from
>> Marius that deletes the deprecated ones?
>
> We ran into issues with the driver changes, and we are working on a
> revised patch(s). I will end up breaking up the patch into several
> patches because we have the work done for some of the drivers, and are
> still working on the remaining changes.
>
> I will make sure we get the remaining work done this upcoming week.
Thanks a lot Jeff.
^ permalink raw reply
* [PATCH 1/1] igmp: fix ip_mc_clear_src to not reset ip_mc_list->sf{mode,count}
From: Veaceslav Falico @ 2011-05-15 16:59 UTC (permalink / raw)
To: David S. Miller
Cc: Michal Marek, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, linux-kbuild, linux-kernel,
netdev
ip_mc_clear_src resets the imc->sfcount and imc->sfmode, without taking into
account the current number of sockets listening on that multicast struct, which
can lead to bogus routes for local listeners.
On NETDEV_DOWN/UP event, if there were 3 multicast listeners for that interface's
address, the imc->sfcount[MCAST_EXCLUDE] will be reset to 1. And after that a
listener socket destroys, multicast traffic will not be delivered to local
listeners because __mkroute_output drops the local flag for the route (by
checking ip_check_mc).
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 1fd3d9c..b14f371 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1775,9 +1775,6 @@ static void ip_mc_clear_src(struct ip_mc_list *pmc)
kfree(psf);
}
pmc->sources = NULL;
- pmc->sfmode = MCAST_EXCLUDE;
- pmc->sfcount[MCAST_INCLUDE] = 0;
- pmc->sfcount[MCAST_EXCLUDE] = 1;
}
^ permalink raw reply related
* ©2011 Google 12th Anniversary Celebration Promo (Thanks for contributing to our Success, Congrats!)
From: Promo Announcer ©2011 @ 2011-05-15 16:36 UTC (permalink / raw)
We urgently wish to inform you that your e-mail has won the sum of
£850,000 UK Pounds {with L u c k y # :12-12-23-35-40-41(12) & T i c k
e t # :008 695 757 336 64} in our on-going 12th Anniversary Giveaway
Online promotions. For further information to be provided, you have to
reply this notice immediately to confirm this email account is still
active.
Sincerely!,
MRS MARIA(Assist P r o m o Announcer)
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: more compliant RFC 3168 support
From: Eric Dumazet @ 2011-05-15 16:01 UTC (permalink / raw)
To: Stefanos Harhalakis; +Cc: David Miller, netdev
In-Reply-To: <201105151808.39231.v13@v13.gr>
Le dimanche 15 mai 2011 à 18:08 +0300, Stefanos Harhalakis a écrit :
> Hello,
>
> On Sunday 15 of May 2011, Eric Dumazet wrote:
> > +static inline int ip4_frag_ecn_fold(u8 ecn)
> > +{
> > + switch (ecn) {
> > + /* If same ECN combination was observed on all fragments, do nothing */
> > + case IPFRAG_ECN_NOT_ECT:
> > + case IPFRAG_ECN_ECT_1:
> > + case IPFRAG_ECN_ECT_0:
> > + case IPFRAG_ECN_CE:
> > + /* if a ECT_1 ECT_0 combination was observed, do nothing as well */
> > + case IPFRAG_ECN_ECT_0 | IPFRAG_ECN_ECT_1:
> > + return 0;
> > + /* at least one fragment had CE, and others ECT_0 or ECT_1 */
> > + case IPFRAG_ECN_CE | IPFRAG_ECN_ECT_0:
> > + case IPFRAG_ECN_CE | IPFRAG_ECN_ECT_1:
> > + case IPFRAG_ECN_CE | IPFRAG_ECN_ECT_0 | IPFRAG_ECN_ECT_1:
> > + return INET_ECN_CE;
> > + /* other combinations are invalid : drop frame */
> > + default:
> > + return -1;
> > + }
> > }
>
> You may wish to simplify this exhaustive check to:
>
> if (unlikely((ecn & IPFRAG_ECN_NOT_ECT) && ecn!=IPFRAG_ECN_NOT_ECT))
> return -1;
> else if (ecn & IPFRAG_ECN_CE)
> return INET_ECN_CE;
> else
> return 0;
>
> although I'm not sure which method will be faster.
>
Problem of this version is that common frames in the Internet (NOT_ECT
or ECT_X or ECT_X) will take the longest path to come to "return 0;"
a switch() version is fast because gcc emits a table based jump
> Also, returning the exact same value for NOT_ECT and ECT_X and then ORing
> this with the TOS seems like it will make it loose the ECT_X info. No? (but
> also, I'm not sure if this is needed anyway from that point on).
>
I dont understand what you mean here. We really need to not loose ECT_X,
and I believe we dont.
-1 : Drop the frame anyway
0 : No change on iph->tos field (we keep its value. it can have ECT_X.
Remember all fragments share same (iph->tos & 3) value)
3 : We make sure iph->tos is ORed with 3 to assert CE on result frame.
> p.s. I'm not sure whether this message will make it to the netdev list.
It should, no worry.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: more compliant RFC 3168 support
From: Stefanos Harhalakis @ 2011-05-15 15:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1305466542.3120.129.camel@edumazet-laptop>
Hello,
On Sunday 15 of May 2011, Eric Dumazet wrote:
> +static inline int ip4_frag_ecn_fold(u8 ecn)
> +{
> + switch (ecn) {
> + /* If same ECN combination was observed on all fragments, do nothing */
> + case IPFRAG_ECN_NOT_ECT:
> + case IPFRAG_ECN_ECT_1:
> + case IPFRAG_ECN_ECT_0:
> + case IPFRAG_ECN_CE:
> + /* if a ECT_1 ECT_0 combination was observed, do nothing as well */
> + case IPFRAG_ECN_ECT_0 | IPFRAG_ECN_ECT_1:
> + return 0;
> + /* at least one fragment had CE, and others ECT_0 or ECT_1 */
> + case IPFRAG_ECN_CE | IPFRAG_ECN_ECT_0:
> + case IPFRAG_ECN_CE | IPFRAG_ECN_ECT_1:
> + case IPFRAG_ECN_CE | IPFRAG_ECN_ECT_0 | IPFRAG_ECN_ECT_1:
> + return INET_ECN_CE;
> + /* other combinations are invalid : drop frame */
> + default:
> + return -1;
> + }
> }
You may wish to simplify this exhaustive check to:
if (unlikely((ecn & IPFRAG_ECN_NOT_ECT) && ecn!=IPFRAG_ECN_NOT_ECT))
return -1;
else if (ecn & IPFRAG_ECN_CE)
return INET_ECN_CE;
else
return 0;
although I'm not sure which method will be faster.
Also, returning the exact same value for NOT_ECT and ECT_X and then ORing
this with the TOS seems like it will make it loose the ECT_X info. No? (but
also, I'm not sure if this is needed anyway from that point on).
p.s. I'm not sure whether this message will make it to the netdev list.
^ permalink raw reply
* Re: [PATCH 1/1] IPVS: seq_release_net should be used.
From: Pablo Neira Ayuso @ 2011-05-15 15:12 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Simon Horman, Hans Schillstrom, ja, lvs-devel, netdev,
netfilter-devel
In-Reply-To: <201105141205.41912.hans@schillstrom.com>
On 14/05/11 12:05, Hans Schillstrom wrote:
> On Saturday, May 14, 2011 02:50:26 Simon Horman wrote:
>> On Fri, May 13, 2011 at 08:03:20AM +0200, Hans Schillstrom wrote:
>>> Without this patch every access to ip_vs in procfs will increase
>>> the netns count i.e. an unbalanced get_net()/put_net().
>>> (ipvsadm commands also use procfs.)
>>> The result is you can't exit a netns if reading ip_vs_* procfs entries.
>>
>> Hi Hans,
>>
>> we should try and get this into 2.6.39, right?
>
> Yes, this is a trivial bug fix
I'll pass it to davem.
^ 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