* [PATCH net-next-2.6] net: ping: dont call udp_ioctl()
From: Eric Dumazet @ 2011-05-15 8:18 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: David Miller, solar, linux-kernel, netdev, peak, kees.cook,
dan.j.rosenberg, eugene, nelhage, kuznet, pekkas, jmorris,
yoshfuji, kaber
In-Reply-To: <20110513200100.GA3875@albatros>
Le samedi 14 mai 2011 à 00:01 +0400, Vasiliy Kulikov a écrit :
> +/*
> + * 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;
> + }
> +}
Do we really need to support SIOCOUTQ and SIOCINQ ioctls for ping
sockets ?
I ask this because udp_ioctl() assumes it handles UDP frames, and can
change UDP_MIB_INERRORS in case first_packet_length() finds a frame with
bad checksum.
[ UDP let the checksum be completed and checked when it performs the
Kernel->User copy ]
I would just remove this legacy, please shout if you believe we really
should support ioctl...
[ I actually tested that ping was still working correctly, of course ]
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.
Thanks
[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>
---
net/ipv4/ping.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 7041d09..952505a 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -610,20 +610,15 @@ do_confirm:
}
/*
- * IOCTL requests applicable to the UDP^H^H^HICMP protocol
+ * IOCTL requests applicable to PING sockets
*/
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;
- }
+
+ return -ENOIOCTLCMD;
}
int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
^ permalink raw reply related
* Re: [net-next-2.6 00/13][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-05-15 8:41 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, gospo@redhat.com, bphilips@novell.com
In-Reply-To: <20110515.012108.15947576632987708.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
On Sat, 2011-05-14 at 22:21 -0700, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Sat, 14 May 2011 18:23:34 -0700
>
> > The following series contains updates to e1000e, ixgbevf and ixgbe.
> >
> > -e1000e: minor comment fix
> > -ixgbevf: add support for macvlan
> > -ixgbe: mostly cleanup with the addition of support for a new adapter
> >
> > The following are changes since commit 7be799a70ba3dd90a59e8d2c72bbe06020005b3f:
> > ipv4: Remove rt->rt_dst reference from ip_forward_options()
> > and are available in the git repository at:
> > master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
>
> Pulled, thanks Jeff.
>
> How are the ethtool op conversions coming so I can apply the patch from
> Marius that deletes the deprecated ones?
>
> Thanks.
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] ENC28J60 works with half-duplex DMA
From: Davide Rizzo @ 2011-05-15 10:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 4 bytes --]
---
[-- 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: strange code in cdc-ncm
From: Alexey ORISHKO @ 2011-05-15 11:21 UTC (permalink / raw)
To: Oliver Neukum
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> It seems a bit strange to me. If you may or may not have claimed an interface,
> how can you unconditionally zero out intfdata?
>
> Regards
> Oliver
Hi Oliver, thanks for pointing out. I'll make a fix and post a patch.
Best regards,
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Email Quota Exceeded
From: Mail Administrator @ 2011-05-15 11:15 UTC (permalink / raw)
Symantec Mail Security replaced Message Body with this text message. The original text contained prohibited content and was quarantined.
ID:MAILSVR::SYQ398b7068
^ permalink raw reply
* Re: [PATCH 06/18] virtio_ring: avail event index interface
From: Michael S. Tsirkin @ 2011-05-15 12:47 UTC (permalink / raw)
To: Rusty Russell
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: <87aaewh5pg.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
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 a new feature bit for the host to
> > declare that it uses an avail_event index
> > (like Xen) instead of a feature bit
> > to enable/disable interrupts.
> >
> > Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > include/linux/virtio_ring.h | 11 ++++++++---
> > 1 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
> > index f5c1b75..f791772 100644
> > --- a/include/linux/virtio_ring.h
> > +++ b/include/linux/virtio_ring.h
> > @@ -32,6 +32,9 @@
> > /* The Guest publishes the used index for which it expects an interrupt
> > * at the end of the avail ring. Host should ignore the avail->flags field. */
> > #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.
--
MST
^ permalink raw reply
* Re: [PATCH 08/18] virtio_ring: support for used_event idx feature
From: Michael S. Tsirkin @ 2011-05-15 12:47 UTC (permalink / raw)
To: Rusty Russell
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: <878vugh5ib.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
On Mon, May 09, 2011 at 01:47:32PM +0930, Rusty Russell wrote:
> On Wed, 4 May 2011 23:51:38 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > Add support for the used_event idx feature: when enabling
> > interrupts, publish the current avail index value to
> > the host so that we get interrupts on the next update.
> >
> > Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > drivers/virtio/virtio_ring.c | 14 ++++++++++++++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 507d6eb..3a3ed75 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -320,6 +320,14 @@ void *virtqueue_get_buf(struct virtqueue *_vq, unsigned int *len)
> > ret = vq->data[i];
> > detach_buf(vq, i);
> > vq->last_used_idx++;
> > + /* If we expect an interrupt for the next entry, tell host
> > + * by writing event index and flush out the write before
> > + * the read in the next get_buf call. */
> > + if (!(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)) {
> > + vring_used_event(&vq->vring) = vq->last_used_idx;
> > + virtio_mb();
> > + }
> > +
>
> Hmm, so you're still using the avail->flags; it's just if thresholding
> is enabled the host will ignore it?
>
> It's a little subtle, but it keeps this patch small.
Right, that's exactly why I do it this way.
> Perhaps we'll want to make it more explicit later.
>
> Thanks,
> Rusty.
Yes, e.g. it might be better to avoid touching that cache line,
and track the current status in a private field in the guest.
But I was unable to measure any effect from doing it either way.
--
MST
^ permalink raw reply
* Re: [PATCH 14/18] virtio: add api for delayed callbacks
From: Michael S. Tsirkin @ 2011-05-15 12:48 UTC (permalink / raw)
To: Rusty Russell
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: <871v08h0vm.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
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.
>
> Then the caller can choose how much space it needs. Maybe net and block
> will want different things...
>
> Cheers,
> Rusty.
Hmm, maybe. OK.
--
MST
^ permalink raw reply
* [PATCH net-next-2.6] ipv4: more compliant RFC 3168 support
From: Eric Dumazet @ 2011-05-15 13:35 UTC (permalink / raw)
To: Stefanos Harhalakis, David Miller; +Cc: netdev
In-Reply-To: <1305464176.3120.113.camel@edumazet-laptop>
Commit 6623e3b24a5e (ipv4: IP defragmentation must be ECN aware) was an
attempt to not lose "Congestion Experienced" (CE) indications when
performing datagram defragmentation.
Stefanos Harhalakis raised the point that RFC 3168 requirements were not
completely met by this commit.
In particular, we MUST detect invalid combinations and eventually drop
illegal frames.
Reported-by: Stefanos Harhalakis <v13@v13.gr>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/ip_fragment.c | 66 ++++++++++++++++++++++++++-------------
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index b1d282f..1f74089 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -77,20 +77,46 @@ struct ipq {
struct inet_peer *peer;
};
-#define IPFRAG_ECN_CLEAR 0x01 /* one frag had INET_ECN_NOT_ECT */
-#define IPFRAG_ECN_SET_CE 0x04 /* one frag had INET_ECN_CE */
+/* RFC 3168 support :
+ * We want to check ECN values of all fragments, do detect invalid combinations.
+ * In ipq->ecn, we store the OR value of each ip4_frag_ecn() fragment value.
+ */
+enum {
+ IPFRAG_ECN_NOT_ECT = 0x01, /* one frag had ECN_NOT_ECT */
+ IPFRAG_ECN_ECT_1 = 0x02, /* one frag had ECN_ECT_1 */
+ IPFRAG_ECN_ECT_0 = 0x04, /* one frag had ECN_ECT_0 */
+ IPFRAG_ECN_CE = 0x08, /* one frag had ECN_CE */
+};
static inline u8 ip4_frag_ecn(u8 tos)
{
- tos = (tos & INET_ECN_MASK) + 1;
- /*
- * After the last operation we have (in binary):
- * INET_ECN_NOT_ECT => 001
- * INET_ECN_ECT_1 => 010
- * INET_ECN_ECT_0 => 011
- * INET_ECN_CE => 100
- */
- return (tos & 2) ? 0 : tos;
+ return 1 << (tos & INET_ECN_MASK);
+}
+
+/* Given the OR values of all fragments, apply RFC 3168 5.3 requirements
+ * Return : -1 if frame should be dropped.
+ * >= 0 value, to be ORed in to final iph->tos field
+ */
+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;
+ }
}
static struct inet_frags ip4_frags;
@@ -524,9 +550,15 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
int len;
int ihlen;
int err;
+ int ecn;
ipq_kill(qp);
+ ecn = ip4_frag_ecn_fold(qp->ecn);
+ if (unlikely(ecn == -1)) {
+ err = -EINVAL;
+ goto out_fail;
+ }
/* Make the one we just received the head. */
if (prev) {
head = prev->next;
@@ -605,17 +637,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
iph = ip_hdr(head);
iph->frag_off = 0;
iph->tot_len = htons(len);
- /* RFC3168 5.3 Fragmentation support
- * If one fragment had INET_ECN_NOT_ECT,
- * reassembled frame also has INET_ECN_NOT_ECT
- * Elif one fragment had INET_ECN_CE
- * reassembled frame also has INET_ECN_CE
- */
- if (qp->ecn & IPFRAG_ECN_CLEAR)
- iph->tos &= ~INET_ECN_MASK;
- else if (qp->ecn & IPFRAG_ECN_SET_CE)
- iph->tos |= INET_ECN_CE;
-
+ iph->tos |= ecn;
IP_INC_STATS_BH(net, IPSTATS_MIB_REASMOKS);
qp->q.fragments = NULL;
qp->q.fragments_tail = NULL;
^ permalink raw reply related
* Re: [PATCH 09/18] virtio: use avail_event index
From: Michael S. Tsirkin @ 2011-05-15 13:55 UTC (permalink / raw)
To: Rusty Russell
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: <874o54h4rt.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
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?
> > @@ -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?
It seems that most drivers use locking to prevent
posting more buffers while they drain the used ring,
and also kick at least once in vq->num buffers,
which I guess in the end would work out fine
as vq num is never as large as 2^15.
> > +static bool vring_notify(struct vring_virtqueue *vq)
> > +{
> > + u16 old, new;
> > + bool v;
> > + if (!vq->event)
> > + return !(vq->vring.used->flags & VRING_USED_F_NO_NOTIFY);
> > +
> > + v = vq->kicked_avail_valid;
> > + old = vq->kicked_avail;
> > + new = vq->kicked_avail = vq->vring.avail->idx;
> > + vq->kicked_avail_valid = true;
> > + if (unlikely(!v))
> > + return true;
>
> This is the only place you actually used kicked_avail_valid. Is it
> possible to initialize it in such a way that you can remove this?
If we kill the code above as you suggested, likely yes.
Maybe an explicit flag is more obvious?
> > @@ -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?
^ 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
* 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 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
* ©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
* [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
* 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
* 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: [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
* [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: 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
* 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: [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: 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: [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-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
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