* Re: TCP: orphans broken by RFC 2525 #2.17
From: Eric Dumazet @ 2010-09-27 5:48 UTC (permalink / raw)
To: Willy Tarreau; +Cc: David Miller, netdev
In-Reply-To: <20100927053901.GL12373@1wt.eu>
Le lundi 27 septembre 2010 à 07:39 +0200, Willy Tarreau a écrit :
> On Sun, Sep 26, 2010 at 06:12:02PM -0700, David Miller wrote:
> > From: Willy Tarreau <w@1wt.eu>
> > Date: Mon, 27 Sep 2010 01:25:30 +0200
> >
> > > Agreed. But that's not a reason for killing outgoing data that is
> > > being sent when there are some data left in the rcv buffer.
> >
> > What alternative notification to the peer do you suggest other than a
> > reset, then? TCP gives us no other.
>
> I know, and I agree to send the reset, but after the data are correctly
> transferred. This reset's purpose is only to inform the other side that
> the data it sent were destroyed. It is not a requirement to tell it they
> were destroyed earlier or later. What matters is that it's informed they
> were destroyed.
>
> That's why I think that it is perfectly reasonable to either destroy them
> after the ACK or simply notify about their destruction after the ACK.
>
> Instead of having :
>
> A B
>
> ---> <SEQ=100><ACK=300> --->
> <--- <SEQ=300><ACK=100><DATA=10> <---
> ---> <SEQ=100><ACK=310> --->
> send(100)
> shutdown()
> close()
> ---> <SEQ=100><CTL=RST> --->
>
> We would just have :
>
> A B
>
> ---> <SEQ=100><ACK=300> --->
> <--- <SEQ=300><ACK=100><DATA=10> <---
> ---> <SEQ=100><ACK=310> --->
> send(100)
> shutdown()
> close()
> ---> <SEQ=100><ACK=310><DATA=100><CTL=FIN> --->
> <--- <SEQ=300><ACK=111> <---
> ---> <SEQ=111><CTL=RST> --->
>
> Note that the notification is exactly the same as if we wanted
> to notify B about the destruction of data that were sent just
> after the close, because the RST only carries a SEQ field and
> no ACK indicating what it destroyed :
>
> A B
>
> ---> <SEQ=100><ACK=300> --->
> send(100)
> shutdown()
> ---> <SEQ=100><ACK=310><DATA=100><CTL=FIN> --->
> <--- <SEQ=300><ACK=111><DATA=10> <---
> close()
> ---> <SEQ=111><CTL=RST> --->
>
> In my opinion, last two examples are perfectly valid, they just mean
> "after that, I close and don't want to hear about you again".
>
> > That's the thing, data integrity is full duplex, thus once it has been
> > compromised in one direction everything currently in flight must be
> > zapped.
>
> I'm well aware of that, and even though that's an annoying method, we
> must live with it, it's probably one of the things that contribute TCP
> its well known reliability. But I think that RFC 2525 abused the TCP
> use based on traces showing a bad behaviour and overlooked all impacts
> (nothing there talks about the case of data being sent or in flight at
> the moment of the close).
If you can cook a patch that makes sure the RST is sent, just do so.
Your previous attempt was wrong, since the RST was sent only if client
sent "req3".
If it sent "req1", "req2" only, req2 was unread and still no RST sent.
This is an RFC violation.
Its a bit tricky, because you cannot send the FIN flag on the last
segment, but have to wait for the final ACK coming from client, to
finally send an RST.
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Jarek Poplawski @ 2010-09-27 5:46 UTC (permalink / raw)
To: Changli Gao
Cc: xiaohui.xin, David S. Miller, Eric Dumazet, Oliver Hartkopp,
Michael S. Tsirkin, netdev
In-Reply-To: <AANLkTin71NME-WwD+tjuxFyh_6Ue7gFTXpLwDUVtaLKR@mail.gmail.com>
On Mon, Sep 27, 2010 at 09:24:02AM +0800, Changli Gao wrote:
> On Fri, Sep 24, 2010 at 2:36 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On 2010-09-23 12:15, Changli Gao wrote:
> >> Since skb->destructor() is used to account socket memory, and maybe called
> >> before the skb is sent out, a corrupt skb maybe sent out finally.
> >>
> >> A new destructor is added into structure skb_shared_info(), and it won't
> >> be called until the last reference to the data of an skb is put. af_packet
> >> uses this destructor instead.
> >
> > IMHO, we shouldn't allow for fixing the bad design of one protocol at
> > the expense of others by adding more and more conditionals. The proper
> > way of handling paged skbs (splice compatible) exists. And the current
> > patch doesn't even fix the problem completely against things like
> > pskb_expand_head or pskb_copy.
>
> pskb_expand_head is handled in my patch, but not pskb_copy().
It's not enough: "skb_shinfo(skb)->data_destructor = NULL" means
skb_release_data() for the original skb->data will not have one, and
you don't know which of the two releases will be the last.
Jarek P.
^ permalink raw reply
* linux-next: build failure after merge of the final tree (net tree related)
From: Stephen Rothwell @ 2010-09-27 5:44 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Ohad Ben-Cohen, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
Hi all,
After merging the final tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Assembler messages:
Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
Presumably caused by commit 61ee7007a5d61aa066076da578e8e8084e122d7d
("wl12xx: add platform data passing support").
I do my builds with a separate object directory (which may be a reason
you don't see this).
I have reverted that commit for today (and commits
09cecc340b3b4d9960b039c0f576548bbf857f5a ("wl1271: take irq info from
private board data") and 15cea99306ae14ce5f7c3d3989bcc17202e2b0be
("wl1271: make ref_clock configurable by board") which follow it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Eric Dumazet @ 2010-09-27 5:40 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, xiaosuo, socketcan, mst, netdev
In-Reply-To: <20100926.182548.179922569.davem@davemloft.net>
Le dimanche 26 septembre 2010 à 18:25 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 24 Sep 2010 09:01:00 +0200
>
> > af_packet (tx with mmap) is broken. I wonder who really uses it ?
>
> I suspect now that af_packet supports VNET headers on transmit,
> there are some things using this tx+mmap thing for sure.
>
> > To properly cope with paged skbs, it should not try to fit several
> > packets per page.
> >
> > The mmap api should change so that one mmaped page belongs to at most
> > one skb, or else we need invasive changes in net/core
> >
> > This probably makes this stuff less interesting, unless the need is to
> > send big packets. In this case, why splice was not used instead of
> > custom mmap ?
>
> I don't really see what the big issue is.
>
> When the data destructor runs it means that packet's part of the pages
> are available for reuse for the tx mmap client. And if I read it
> correctly, that's exactly what tpacket_destruct_skb() is in fact doing.
>
> There seems to be no conflict with that rule and reusing a page for
> multiple packets.
I was wondering if somewhere we transfert a frag from one skb1 to
another skb2, and eventually free skb1.
I just check tcp collapse and found it was not coping with frags, yet.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-27 5:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100926.181202.28824153.davem@davemloft.net>
On Sun, Sep 26, 2010 at 06:12:02PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 27 Sep 2010 01:25:30 +0200
>
> > Agreed. But that's not a reason for killing outgoing data that is
> > being sent when there are some data left in the rcv buffer.
>
> What alternative notification to the peer do you suggest other than a
> reset, then? TCP gives us no other.
I know, and I agree to send the reset, but after the data are correctly
transferred. This reset's purpose is only to inform the other side that
the data it sent were destroyed. It is not a requirement to tell it they
were destroyed earlier or later. What matters is that it's informed they
were destroyed.
That's why I think that it is perfectly reasonable to either destroy them
after the ACK or simply notify about their destruction after the ACK.
Instead of having :
A B
---> <SEQ=100><ACK=300> --->
<--- <SEQ=300><ACK=100><DATA=10> <---
---> <SEQ=100><ACK=310> --->
send(100)
shutdown()
close()
---> <SEQ=100><CTL=RST> --->
We would just have :
A B
---> <SEQ=100><ACK=300> --->
<--- <SEQ=300><ACK=100><DATA=10> <---
---> <SEQ=100><ACK=310> --->
send(100)
shutdown()
close()
---> <SEQ=100><ACK=310><DATA=100><CTL=FIN> --->
<--- <SEQ=300><ACK=111> <---
---> <SEQ=111><CTL=RST> --->
Note that the notification is exactly the same as if we wanted
to notify B about the destruction of data that were sent just
after the close, because the RST only carries a SEQ field and
no ACK indicating what it destroyed :
A B
---> <SEQ=100><ACK=300> --->
send(100)
shutdown()
---> <SEQ=100><ACK=310><DATA=100><CTL=FIN> --->
<--- <SEQ=300><ACK=111><DATA=10> <---
close()
---> <SEQ=111><CTL=RST> --->
In my opinion, last two examples are perfectly valid, they just mean
"after that, I close and don't want to hear about you again".
> That's the thing, data integrity is full duplex, thus once it has been
> compromised in one direction everything currently in flight must be
> zapped.
I'm well aware of that, and even though that's an annoying method, we
must live with it, it's probably one of the things that contribute TCP
its well known reliability. But I think that RFC 2525 abused the TCP
use based on traces showing a bad behaviour and overlooked all impacts
(nothing there talks about the case of data being sent or in flight at
the moment of the close).
Regards,
Willy
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Jarek Poplawski @ 2010-09-27 5:30 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, eric.dumazet, socketcan, mst, netdev
In-Reply-To: <20100926.182208.102539866.davem@davemloft.net>
On Sun, Sep 26, 2010 at 06:22:08PM -0700, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Fri, 24 Sep 2010 06:36:23 +0000
>
> > af_packet could check some flag which guarantees the queued dev can do
> > skb_orphan after the real xmit and copy buffers otherwise.
>
> Jarek, we pre-orphan SKBs in the core way before device even gets
> the packet.
I'm not sure which place in the core do you mean; skb_orphan_try() in
dev_hard_start_xmit() depends on ->tx_flags.
Jarek P.
^ permalink raw reply
* [PATCH v2 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar A Sanghvi @ 2010-09-27 5:07 UTC (permalink / raw)
To: remi.denis-courmont, davem, netdev
Cc: STEricsson_nomadik_linux, sudeep.divakaran, gulshan.karmani,
Kumar Sanghvi, Linus Walleij
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Phonet stack assumes the presence of Pipe Controller, either in Modem or
on Application Processing Engine user-space for the Pipe data.
Nokia Slim Modems like WG2.5 used in ST-Ericsson U8500 platform do not
implement Pipe controller in them.
This patch adds Pipe Controller implemenation to Phonet stack to support
Pipe data over Phonet stack for Nokia Slim Modems.
Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
Changes:
-v2: Correction for header retrieving after pskb_may_pull
include/linux/phonet.h | 5 +
include/net/phonet/pep.h | 21 +++
net/phonet/Kconfig | 11 ++
net/phonet/pep.c | 448 +++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 479 insertions(+), 6 deletions(-)
diff --git a/include/linux/phonet.h b/include/linux/phonet.h
index 85e14a8..96f5625 100644
--- a/include/linux/phonet.h
+++ b/include/linux/phonet.h
@@ -36,6 +36,11 @@
/* Socket options for SOL_PNPIPE level */
#define PNPIPE_ENCAP 1
#define PNPIPE_IFINDEX 2
+#define PNPIPE_CREATE 3
+#define PNPIPE_ENABLE 4
+#define PNPIPE_DISABLE 5
+#define PNPIPE_DESTROY 6
+#define PNPIPE_INQ 7
#define PNADDR_ANY 0
#define PNADDR_BROADCAST 0xFC
diff --git a/include/net/phonet/pep.h b/include/net/phonet/pep.h
index 37f23dc..def6cfa 100644
--- a/include/net/phonet/pep.h
+++ b/include/net/phonet/pep.h
@@ -45,6 +45,10 @@ struct pep_sock {
u8 tx_fc; /* TX flow control */
u8 init_enable; /* auto-enable at creation */
u8 aligned;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ u16 remote_pep;
+ u8 pipe_state;
+#endif
};
static inline struct pep_sock *pep_sk(struct sock *sk)
@@ -165,4 +169,21 @@ enum {
PEP_IND_READY,
};
+#ifdef CONFIG_PHONET_PIPECTRLR
+#define PNS_PEP_CONNECT_UTID 0x02
+#define PNS_PIPE_CREATED_IND_UTID 0x04
+#define PNS_PIPE_ENABLE_UTID 0x0A
+#define PNS_PIPE_ENABLED_IND_UTID 0x0C
+#define PNS_PIPE_DISABLE_UTID 0x0F
+#define PNS_PIPE_DISABLED_IND_UTID 0x11
+#define PNS_PEP_DISCONNECT_UTID 0x06
+
+/* Used for tracking state of a pipe */
+enum {
+ PIPE_IDLE,
+ PIPE_DISABLED,
+ PIPE_ENABLED,
+};
+#endif /* CONFIG_PHONET_PIPECTRLR */
+
#endif
diff --git a/net/phonet/Kconfig b/net/phonet/Kconfig
index 6ec7d55..901956a 100644
--- a/net/phonet/Kconfig
+++ b/net/phonet/Kconfig
@@ -14,3 +14,14 @@ config PHONET
To compile this driver as a module, choose M here: the module
will be called phonet. If unsure, say N.
+
+config PHONET_PIPECTRLR
+ bool "Phonet Pipe Controller"
+ depends on PHONET
+ default N
+ help
+ The Pipe Controller implementation in Phonet stack to support Pipe
+ data with Nokia Slim modems like WG2.5 used on ST-Ericsson U8500
+ platform.
+
+ If unsure, say N.
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index d0e7eb2..7bf23cf 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -88,6 +88,15 @@ static int pep_reply(struct sock *sk, struct sk_buff *oskb,
const struct pnpipehdr *oph = pnp_hdr(oskb);
struct pnpipehdr *ph;
struct sk_buff *skb;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ const struct phonethdr *hdr = pn_hdr(oskb);
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = hdr->pn_sdev,
+ .spn_obj = hdr->pn_sobj,
+ };
+#endif
skb = alloc_skb(MAX_PNPIPE_HEADER + len, priority);
if (!skb)
@@ -105,10 +114,271 @@ static int pep_reply(struct sock *sk, struct sk_buff *oskb,
ph->pipe_handle = oph->pipe_handle;
ph->error_code = code;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ return pn_skb_send(sk, skb, &spn);
+#else
return pn_skb_send(sk, skb, &pipe_srv);
+#endif
}
#define PAD 0x00
+
+#ifdef CONFIG_PHONET_PIPECTRLR
+static u8 pipe_negotiate_fc(u8 *host_fc, u8 *remote_fc, int len)
+{
+ int i, j;
+ u8 base_fc, final_fc;
+
+ for (i = 0; i < len; i++) {
+ base_fc = host_fc[i];
+ for (j = 0; j < len; j++) {
+ if (remote_fc[j] == base_fc) {
+ final_fc = base_fc;
+ goto done;
+ }
+ }
+ }
+ return -EINVAL;
+
+done:
+ return final_fc;
+
+}
+
+static int pipe_get_flow_info(struct sock *sk, struct sk_buff *skb,
+ u8 *pref_rx_fc, u8 *req_tx_fc)
+{
+ struct pnpipehdr *hdr;
+ u8 n_sb;
+
+ if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
+ return -EINVAL;
+
+ hdr = pnp_hdr(skb);
+ n_sb = hdr->data[4];
+
+ __skb_pull(skb, sizeof(*hdr) + 4);
+ while (n_sb > 0) {
+ u8 type, buf[3], len = sizeof(buf);
+ u8 *data = pep_get_sb(skb, &type, &len, buf);
+
+ if (data == NULL)
+ return -EINVAL;
+
+ switch (type) {
+ case PN_PIPE_SB_REQUIRED_FC_TX:
+ if (len < 3 || (data[2] | data[3] | data[4]) > 3)
+ break;
+ req_tx_fc[0] = data[2];
+ req_tx_fc[1] = data[3];
+ req_tx_fc[2] = data[4];
+ break;
+
+ case PN_PIPE_SB_PREFERRED_FC_RX:
+ if (len < 3 || (data[2] | data[3] | data[4]) > 3)
+ break;
+ pref_rx_fc[0] = data[2];
+ pref_rx_fc[1] = data[3];
+ pref_rx_fc[2] = data[4];
+ break;
+
+ }
+ n_sb--;
+ }
+ return 0;
+}
+
+static int pipe_handler_send_req(struct sock *sk, u16 dobj, u8 utid,
+ u8 msg_id, u8 p_handle, gfp_t priority)
+{
+ int len;
+ struct pnpipehdr *ph;
+ struct sk_buff *skb;
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(dobj),
+ .spn_obj = pn_obj(dobj),
+ };
+
+ static const u8 data[4] = {
+ PAD, PAD, PAD, PAD,
+ };
+
+ switch (msg_id) {
+ case PNS_PEP_CONNECT_REQ:
+ len = sizeof(data);
+ break;
+
+ case PNS_PEP_DISCONNECT_REQ:
+ case PNS_PEP_ENABLE_REQ:
+ case PNS_PEP_DISABLE_REQ:
+ len = 0;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ skb = alloc_skb(MAX_PNPIPE_HEADER + len, priority);
+ if (!skb)
+ return -ENOMEM;
+ skb_set_owner_w(skb, sk);
+
+ skb_reserve(skb, MAX_PNPIPE_HEADER);
+ if (len) {
+ __skb_put(skb, len);
+ skb_copy_to_linear_data(skb, data, len);
+ }
+ __skb_push(skb, sizeof(*ph));
+ skb_reset_transport_header(skb);
+ ph = pnp_hdr(skb);
+ ph->utid = utid;
+ ph->message_id = msg_id;
+ ph->pipe_handle = p_handle;
+ ph->error_code = PN_PIPE_NO_ERROR;
+
+ return pn_skb_send(sk, skb, &spn);
+}
+
+static int pipe_handler_send_created_ind(struct sock *sk, u16 dobj,
+ u8 utid, u8 p_handle, u8 msg_id, u8 tx_fc, u8 rx_fc)
+{
+ int err_code;
+ struct pnpipehdr *ph;
+ struct sk_buff *skb;
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(dobj),
+ .spn_obj = pn_obj(dobj),
+ };
+
+ static u8 data[4] = {
+ 0x03, 0x04,
+ };
+ data[2] = tx_fc;
+ data[3] = rx_fc;
+
+ /*
+ * actually, below is number of sub-blocks and not error code.
+ * Pipe_created_ind message format does not have any
+ * error code field. However, the Phonet stack will always send
+ * an error code as part of pnpipehdr. So, use that err_code to
+ * specify the number of sub-blocks.
+ */
+ err_code = 0x01;
+
+ skb = alloc_skb(MAX_PNPIPE_HEADER + sizeof(data), GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+ skb_set_owner_w(skb, sk);
+
+ skb_reserve(skb, MAX_PNPIPE_HEADER);
+ __skb_put(skb, sizeof(data));
+ skb_copy_to_linear_data(skb, data, sizeof(data));
+ __skb_push(skb, sizeof(*ph));
+ skb_reset_transport_header(skb);
+ ph = pnp_hdr(skb);
+ ph->utid = utid;
+ ph->message_id = msg_id;
+ ph->pipe_handle = p_handle;
+ ph->error_code = err_code;
+
+ return pn_skb_send(sk, skb, &spn);
+}
+
+static int pipe_handler_send_ind(struct sock *sk, u16 dobj, u8 utid,
+ u8 p_handle, u8 msg_id)
+{
+ int err_code;
+ struct pnpipehdr *ph;
+ struct sk_buff *skb;
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(dobj),
+ .spn_obj = pn_obj(dobj),
+ };
+
+ /*
+ * actually, below is a filler.
+ * Pipe_enabled/disabled_ind message format does not have any
+ * error code field. However, the Phonet stack will always send
+ * an error code as part of pnpipehdr. So, use that err_code to
+ * specify the filler value.
+ */
+ err_code = 0x0;
+
+ skb = alloc_skb(MAX_PNPIPE_HEADER, GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+ skb_set_owner_w(skb, sk);
+
+ skb_reserve(skb, MAX_PNPIPE_HEADER);
+ __skb_push(skb, sizeof(*ph));
+ skb_reset_transport_header(skb);
+ ph = pnp_hdr(skb);
+ ph->utid = utid;
+ ph->message_id = msg_id;
+ ph->pipe_handle = p_handle;
+ ph->error_code = err_code;
+
+ return pn_skb_send(sk, skb, &spn);
+}
+
+static int pipe_handler_enable_pipe(struct sock *sk, int cmd)
+{
+ int ret;
+ struct pep_sock *pn = pep_sk(sk);
+
+ switch (cmd) {
+ case PNPIPE_ENABLE:
+ ret = pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PIPE_ENABLE_UTID, PNS_PEP_ENABLE_REQ,
+ pn->pipe_handle, GFP_ATOMIC);
+ break;
+
+ case PNPIPE_DISABLE:
+ ret = pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PIPE_DISABLE_UTID, PNS_PEP_DISABLE_REQ,
+ pn->pipe_handle, GFP_ATOMIC);
+ break;
+
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static int pipe_handler_create_pipe(struct sock *sk, int pipe_handle, int cmd)
+{
+ int ret;
+ struct pep_sock *pn = pep_sk(sk);
+
+ switch (cmd) {
+ case PNPIPE_CREATE:
+ ret = pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PEP_CONNECT_UTID, PNS_PEP_CONNECT_REQ,
+ pipe_handle, GFP_ATOMIC);
+ break;
+
+ case PNPIPE_DESTROY:
+ ret = pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PEP_DISCONNECT_UTID,
+ PNS_PEP_DISCONNECT_REQ,
+ pn->pipe_handle, GFP_ATOMIC);
+ break;
+
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+#endif
+
static int pep_accept_conn(struct sock *sk, struct sk_buff *skb)
{
static const u8 data[20] = {
@@ -173,6 +443,14 @@ static int pipe_snd_status(struct sock *sk, u8 type, u8 status, gfp_t priority)
struct pep_sock *pn = pep_sk(sk);
struct pnpipehdr *ph;
struct sk_buff *skb;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(pn->remote_pep),
+ .spn_obj = pn_obj(pn->remote_pep),
+ };
+#endif
skb = alloc_skb(MAX_PNPIPE_HEADER + 4, priority);
if (!skb)
@@ -192,7 +470,11 @@ static int pipe_snd_status(struct sock *sk, u8 type, u8 status, gfp_t priority)
ph->data[3] = PAD;
ph->data[4] = status;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ return pn_skb_send(sk, skb, &spn);
+#else
return pn_skb_send(sk, skb, &pipe_srv);
+#endif
}
/* Send our RX flow control information to the sender.
@@ -308,6 +590,12 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
struct pnpipehdr *hdr = pnp_hdr(skb);
struct sk_buff_head *queue;
int err = 0;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ struct phonethdr *ph = pn_hdr(skb);
+ static u8 host_pref_rx_fc[3], host_req_tx_fc[3];
+ u8 remote_pref_rx_fc[3], remote_req_tx_fc[3];
+ u8 negotiated_rx_fc, negotiated_tx_fc;
+#endif
BUG_ON(sk->sk_state == TCP_CLOSE_WAIT);
@@ -316,6 +604,40 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
pep_reject_conn(sk, skb, PN_PIPE_ERR_PEP_IN_USE);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_CONNECT_RESP:
+ if ((ph->pn_sdev == pn_dev(pn->remote_pep)) &&
+ (ph->pn_sobj == pn_obj(pn->remote_pep))) {
+ pipe_get_flow_info(sk, skb, remote_pref_rx_fc,
+ remote_req_tx_fc);
+
+ negotiated_tx_fc = pipe_negotiate_fc(remote_req_tx_fc,
+ host_pref_rx_fc,
+ sizeof(host_pref_rx_fc));
+ negotiated_rx_fc = pipe_negotiate_fc(host_req_tx_fc,
+ remote_pref_rx_fc,
+ sizeof(host_pref_rx_fc));
+
+ pn->pipe_state = PIPE_DISABLED;
+ pipe_handler_send_created_ind(sk, pn->remote_pep,
+ PNS_PIPE_CREATED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_CREATED_IND,
+ negotiated_tx_fc, negotiated_rx_fc);
+ pipe_handler_send_created_ind(sk, pn->pn_sk.sobject,
+ PNS_PIPE_CREATED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_CREATED_IND,
+ negotiated_tx_fc, negotiated_rx_fc);
+ } else {
+ pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PEP_CONNECT_UTID,
+ PNS_PEP_CONNECT_REQ, pn->pipe_handle,
+ GFP_ATOMIC);
+ pipe_get_flow_info(sk, skb, host_pref_rx_fc,
+ host_req_tx_fc);
+ }
+ break;
+#endif
+
case PNS_PEP_DISCONNECT_REQ:
pep_reply(sk, skb, PN_PIPE_NO_ERROR, NULL, 0, GFP_ATOMIC);
sk->sk_state = TCP_CLOSE_WAIT;
@@ -323,11 +645,41 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
sk->sk_state_change(sk);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_DISCONNECT_RESP:
+ pn->pipe_state = PIPE_IDLE;
+ pipe_handler_send_req(sk, pn->pn_sk.sobject,
+ PNS_PEP_DISCONNECT_UTID,
+ PNS_PEP_DISCONNECT_REQ, pn->pipe_handle,
+ GFP_KERNEL);
+ break;
+#endif
+
case PNS_PEP_ENABLE_REQ:
/* Wait for PNS_PIPE_(ENABLED|REDIRECTED)_IND */
pep_reply(sk, skb, PN_PIPE_NO_ERROR, NULL, 0, GFP_ATOMIC);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_ENABLE_RESP:
+ if ((ph->pn_sdev == pn_dev(pn->remote_pep)) &&
+ (ph->pn_sobj == pn_obj(pn->remote_pep))) {
+ pn->pipe_state = PIPE_ENABLED;
+ pipe_handler_send_ind(sk, pn->remote_pep,
+ PNS_PIPE_ENABLED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_ENABLED_IND);
+ pipe_handler_send_ind(sk, pn->pn_sk.sobject,
+ PNS_PIPE_ENABLED_IND_UTID,
+ pn->pipe_handle, PNS_PIPE_ENABLED_IND);
+ } else
+ pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PIPE_ENABLE_UTID,
+ PNS_PEP_ENABLE_REQ, pn->pipe_handle,
+ GFP_KERNEL);
+
+ break;
+#endif
+
case PNS_PEP_RESET_REQ:
switch (hdr->state_after_reset) {
case PN_PIPE_DISABLE:
@@ -346,6 +698,27 @@ static int pipe_do_rcv(struct sock *sk, struct sk_buff *skb)
pep_reply(sk, skb, PN_PIPE_NO_ERROR, NULL, 0, GFP_ATOMIC);
break;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNS_PEP_DISABLE_RESP:
+ if ((ph->pn_sdev == pn_dev(pn->remote_pep)) &&
+ (ph->pn_sobj == pn_obj(pn->remote_pep))) {
+ pn->pipe_state = PIPE_DISABLED;
+ pipe_handler_send_ind(sk, pn->remote_pep,
+ PNS_PIPE_DISABLED_IND_UTID,
+ pn->pipe_handle,
+ PNS_PIPE_DISABLED_IND);
+ pipe_handler_send_ind(sk, pn->pn_sk.sobject,
+ PNS_PIPE_DISABLED_IND_UTID,
+ pn->pipe_handle,
+ PNS_PIPE_DISABLED_IND);
+ } else
+ pipe_handler_send_req(sk, pn->remote_pep,
+ PNS_PIPE_DISABLE_UTID,
+ PNS_PEP_DISABLE_REQ, pn->pipe_handle,
+ GFP_KERNEL);
+ break;
+#endif
+
case PNS_PEP_CTRL_REQ:
if (skb_queue_len(&pn->ctrlreq_queue) >= PNPIPE_CTRLREQ_MAX) {
atomic_inc(&sk->sk_drops);
@@ -519,6 +892,9 @@ static int pep_connreq_rcv(struct sock *sk, struct sk_buff *skb)
newpn->rx_fc = newpn->tx_fc = PN_LEGACY_FLOW_CONTROL;
newpn->init_enable = enabled;
newpn->aligned = aligned;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ newpn->remote_pep = pn->remote_pep;
+#endif
BUG_ON(!skb_queue_empty(&newsk->sk_receive_queue));
skb_queue_head(&newsk->sk_receive_queue, skb);
@@ -781,6 +1157,10 @@ static int pep_setsockopt(struct sock *sk, int level, int optname,
{
struct pep_sock *pn = pep_sk(sk);
int val = 0, err = 0;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ int remote_pep;
+ int pipe_handle;
+#endif
if (level != SOL_PNPIPE)
return -ENOPROTOOPT;
@@ -791,6 +1171,48 @@ static int pep_setsockopt(struct sock *sk, int level, int optname,
lock_sock(sk);
switch (optname) {
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNPIPE_CREATE:
+ if (val) {
+ if (pn->pipe_state > PIPE_IDLE) {
+ err = -EFAULT;
+ break;
+ }
+ remote_pep = val & 0xFFFF;
+ pipe_handle = (val >> 16) & 0xFF;
+ pn->remote_pep = remote_pep;
+ err = pipe_handler_create_pipe(sk, pipe_handle,
+ PNPIPE_CREATE);
+ break;
+ }
+
+ case PNPIPE_ENABLE:
+ if (pn->pipe_state != PIPE_DISABLED) {
+ err = -EFAULT;
+ break;
+ }
+ err = pipe_handler_enable_pipe(sk, PNPIPE_ENABLE);
+ break;
+
+ case PNPIPE_DISABLE:
+ if (pn->pipe_state != PIPE_ENABLED) {
+ err = -EFAULT;
+ break;
+ }
+
+ err = pipe_handler_enable_pipe(sk, PNPIPE_DISABLE);
+ break;
+
+ case PNPIPE_DESTROY:
+ if (pn->pipe_state < PIPE_DISABLED) {
+ err = -EFAULT;
+ break;
+ }
+
+ err = pipe_handler_create_pipe(sk, 0x0, PNPIPE_DESTROY);
+ break;
+#endif
+
case PNPIPE_ENCAP:
if (val && val != PNPIPE_ENCAP_IP) {
err = -EINVAL;
@@ -840,6 +1262,13 @@ static int pep_getsockopt(struct sock *sk, int level, int optname,
case PNPIPE_ENCAP:
val = pn->ifindex ? PNPIPE_ENCAP_IP : PNPIPE_ENCAP_NONE;
break;
+
+#ifdef CONFIG_PHONET_PIPECTRLR
+ case PNPIPE_INQ:
+ val = pn->pipe_state;
+ break;
+#endif
+
case PNPIPE_IFINDEX:
val = pn->ifindex;
break;
@@ -859,7 +1288,14 @@ static int pipe_skb_send(struct sock *sk, struct sk_buff *skb)
{
struct pep_sock *pn = pep_sk(sk);
struct pnpipehdr *ph;
- int err;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ struct sockaddr_pn spn = {
+ .spn_family = AF_PHONET,
+ .spn_resource = 0xD9,
+ .spn_dev = pn_dev(pn->remote_pep),
+ .spn_obj = pn_obj(pn->remote_pep),
+ };
+#endif
if (pn_flow_safe(pn->tx_fc) &&
!atomic_add_unless(&pn->tx_credits, -1, 0)) {
@@ -877,11 +1313,11 @@ static int pipe_skb_send(struct sock *sk, struct sk_buff *skb)
} else
ph->message_id = PNS_PIPE_DATA;
ph->pipe_handle = pn->pipe_handle;
-
- err = pn_skb_send(sk, skb, &pipe_srv);
- if (err && pn_flow_safe(pn->tx_fc))
- atomic_inc(&pn->tx_credits);
- return err;
+#ifdef CONFIG_PHONET_PIPECTRLR
+ return pn_skb_send(sk, skb, &spn);
+#else
+ return pn_skb_send(sk, skb, &pipe_srv);
+#endif
}
static int pep_sendmsg(struct kiocb *iocb, struct sock *sk,
--
1.7.2.dirty
^ permalink raw reply related
* linux-next: manual merge of the net tree with the omap tree
From: Stephen Rothwell @ 2010-09-27 4:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Sukumar Ghorai, Tony Lindgren,
linux-omap, Ohad Ben-Cohen, John W. Linville
Hi all,
Today's linux-next merge of the net tree got a conflict in
arch/arm/mach-omap2/board-zoom-peripherals.c between commit
6db649c505ddc6665176807c16745b9e01cf5031 ("omap: mmc: extended to pass
host capabilities from board file") from the omap tree and commits
b642fde7f137566c993991fd2e7bf6b8274bf625 ("omap: zoom: add fixed
regulator device for wlan") and 80b517f362605f2b6a6cfe086604534290aab2de
("omap: zoom: add mmc3/wl1271 device support") from the net tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-zoom-peripherals.c
index e5eac46,6aa0728..0000000
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@@ -16,7 -16,8 +16,9 @@@
#include <linux/gpio.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/mmc/host.h>
+ #include <linux/regulator/fixed.h>
+ #include <linux/wl12xx.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
^ permalink raw reply
* Re: [PATCH 4/4] net: r6040: store BIOS default MAC in perm_add
From: David Miller @ 2010-09-27 2:58 UTC (permalink / raw)
To: otavio; +Cc: netdev
In-Reply-To: <1285555779-5885-1-git-send-email-otavio@ossystems.com.br>
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Sun, 26 Sep 2010 23:49:39 -0300
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Applied.
^ permalink raw reply
* [PATCH 4/4] net: r6040: store BIOS default MAC in perm_add
From: Otavio Salvador @ 2010-09-27 2:49 UTC (permalink / raw)
To: netdev; +Cc: Otavio Salvador
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
drivers/net/r6040.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 142c381..5780d08 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -740,6 +740,9 @@ static void r6040_mac_address(struct net_device *dev)
iowrite16(adrp[0], ioaddr + MID_0L);
iowrite16(adrp[1], ioaddr + MID_0M);
iowrite16(adrp[2], ioaddr + MID_0H);
+
+ /* Store MAC Address in perm_addr */
+ memcpy(dev->perm_addr, dev->dev_addr, ETH_ALEN);
}
static int r6040_open(struct net_device *dev)
--
1.7.2.3.313.gcd15
^ permalink raw reply related
* Re: [PATCH] mm: do not print backtraces on GFP_ATOMIC failures
From: KOSAKI Motohiro @ 2010-09-27 2:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: kosaki.motohiro, Andrew Morton, Rik van Riel, linux-mm,
linux-kernel, netdev
In-Reply-To: <1285088427.2617.723.camel@edumazet-laptop>
> > > @@ -72,7 +72,7 @@ struct vm_area_struct;
> > > /* This equals 0, but use constants in case they ever change */
> > > #define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH)
> > > /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */
> > > -#define GFP_ATOMIC (__GFP_HIGH)
> > > +#define GFP_ATOMIC (__GFP_HIGH | __GFP_NOWARN)
> > > #define GFP_NOIO (__GFP_WAIT)
> > > #define GFP_NOFS (__GFP_WAIT | __GFP_IO)
> > > #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
> >
> > A much finer-tuned implementation would be to add __GFP_NOWARN just to
> > the networking call sites. I asked about this in June and it got
> > nixed:
> >
> > http://www.spinics.net/lists/netdev/msg131965.html
> > --
>
> Yes, I remember this particular report was useful to find and correct a
> bug.
>
> I dont know what to say.
>
> Being silent or verbose, it really depends on the context ?
At least, MM developers don't want to track network allocation failure
issue. We don't have enough knowledge in this area. To be honest, We
are unhappy current bad S/N bug report rate ;)
Traditionally, We hoped this warnings help to debug VM issue. but
It haven't happen. We haven't detect VM issue from this allocation
failure report. Instead, We've received a lot of network allocation
failure report.
Recently, The S/N ratio became more bad. If the network device enable
jumbo frame feature, order-2 GFP_ATOMIC allocation is called frequently.
Anybody don't have to assume order-2 allocation can success anytime.
I'm not against accurate warning at all. but I cant tolerate this
semi-random warning steal our time. If anyone will not make accurate
warning, I hope to remove this one completely instead.
^ permalink raw reply
* Re: [PATCH] ipv6: add a missing unregister_pernet_subsys call
From: David Miller @ 2010-09-27 2:10 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20100924195552.GA8477@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 24 Sep 2010 15:55:52 -0400
> Clean up a missing exit path in the ipv6 module init routines. In
> addrconf_init we call ipv6_addr_label_init which calls register_pernet_subsys
> for the ipv6_addr_label_ops structure. But if module loading fails, or if the
> ipv6 module is removed, there is no corresponding unregister_pernet_subsys call,
> which leaves a now-bogus address on the pernet_list, leading to oopses in
> subsequent registrations. This patch cleans up both the failed load path and
> the unload path. Tested by myself with good results.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
Thanks a lot Neil.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: loopback driver cleanup
From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285321911.2503.48.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 11:51:51 +0200
> loopback driver uses dev->ml_priv to store its percpu stats pointer.
> It uses ugly casts "(void __percpu __force *)" to shut up sparse
> complains.
>
> Define an union to better document we use ml_priv in loopback driver and
> define a lstats field with appropriate types.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow
From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: paulmck, akpm, netdev
In-Reply-To: <1285314363.2503.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 09:46:03 +0200
> [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow
>
> __in_dev_get_rtnl(dev_out) is called while RTNL is not held, thus
> triggers a lockdep fault.
>
> At this point, we only perform a raw test of dev_out->ip_ptr being NULL,
> we dont need to make sure ip_ptr cant changed right after.
>
> We can use rcu_dereference_raw() for this.
>
> Reported-by: Andrew Morton <akpm@linux-foundation.org>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice only
From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, netdev, linux-net-drivers, therbert
In-Reply-To: <1285298795.2380.54.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 05:26:35 +0200
> [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice()
>
> Instead of having two places were we allocate dev->_rx, introduce
> netif_alloc_rx_queues() helper and call it only from
> register_netdevice(), not from alloc_netdev_mq()
>
> Goal is to let drivers change dev->num_rx_queues after allocating netdev
> and before registering it.
>
> This also removes a lot of ifdefs in net/core/dev.c
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
Please cook up a patch that adds a check to make sure that
alloc_netdev_mq() is never called with number of queues < 1
Thanks again!
^ permalink raw reply
* Re: [PATCH 3/9] sgiseeq: use free_netdev(netdev) instead of kfree()
From: David Miller @ 2010-09-27 1:55 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, eric.dumazet, u.kleine-koenig, julia, tj, netdev,
linux-kernel
In-Reply-To: <1285495086-21956-1-git-send-email-segooon@gmail.com>
From: Vasiliy Kulikov <segooon@gmail.com>
Date: Sun, 26 Sep 2010 13:58:06 +0400
> Freeing netdev without free_netdev() leads to net, tx leaks.
> I might lead to dereferencing freed pointer.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> @@
> struct net_device* dev;
> @@
>
> -kfree(dev)
> +free_netdev(dev)
Applied.
^ permalink raw reply
* Re: [PATCH 2/9] rionet: use free_netdev(netdev) instead of kfree()
From: David Miller @ 2010-09-27 1:55 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, tj, netdev, linux-kernel
In-Reply-To: <1285495083-21899-1-git-send-email-segooon@gmail.com>
From: Vasiliy Kulikov <segooon@gmail.com>
Date: Sun, 26 Sep 2010 13:58:03 +0400
> Freeing netdev without free_netdev() leads to net, tx leaks.
> I might lead to dereferencing freed pointer.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> @@
> struct net_device* dev;
> @@
>
> -kfree(dev)
> +free_netdev(dev)
Applied.
^ permalink raw reply
* Re: [PATCH 1/9] ibm_newemac: use free_netdev(netdev) instead of kfree()
From: David Miller @ 2010-09-27 1:54 UTC (permalink / raw)
To: segooon-Re5JQEeQqe8AvxtiuMwx3w
Cc: jpirko-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1285495080-21857-1-git-send-email-segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Vasiliy Kulikov <segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sun, 26 Sep 2010 13:58:00 +0400
> Freeing netdev without free_netdev() leads to net, tx leaks.
> I might lead to dereferencing freed pointer.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> @@
> struct net_device* dev;
> @@
>
> -kfree(dev)
> +free_netdev(dev)
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: update SOCK_MIN_RCVBUF
From: David Miller @ 2010-09-27 1:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285345177.2503.346.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 18:19:37 +0200
> SOCK_MIN_RCVBUF current value is 256 bytes
>
> It doesnt permit to receive the smallest possible frame, considering
> socket sk_rmem_alloc/sk_rcvbuf account skb truesizes. On 64bit arches,
> sizeof(struct sk_buff) is 240 bytes. Add the typical 64 bytes of
> headroom, and we go over the limit.
>
> With old kernels and 32bit arches, we were under the limit, if netdriver
> was doing copybreak.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Fair enough, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] smsc911x: Add MODULE_ALIAS()
From: David Miller @ 2010-09-27 1:50 UTC (permalink / raw)
To: vincent.stehle; +Cc: netdev
In-Reply-To: <4C9BCFC5.9090808@bergerie>
From: Vincent <vincent.stehle@laposte.net>
Date: Fri, 24 Sep 2010 00:08:05 +0200
> The smsc911x ethernet driver is lacking a module alias. This does
> prevent auto-loading of the driver.
>
> The attached patch fixes this. Please apply.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: reset skb queue mapping when rx'ing over tunnel
From: David Miller @ 2010-09-27 1:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev, chavey
In-Reply-To: <1285397350.2478.102.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 25 Sep 2010 08:49:10 +0200
> Le vendredi 24 septembre 2010 à 09:18 -0700, Tom Herbert a écrit :
>> > Hmm...
>> >
>> > This would need to be reverted later when tunnels are updated to be
>> > multiqueue aware ? I made an attempt with GRE some days ago.
>> >
>> > I dont understand why this patch is needed, since get_rps_cpu() has a
>> > check anyway
>> >
>> I think the skb queue_mapping should correspond to a queue in the
>> skb's device as an invariant. In the case that an skb's device is
>> change from a multiqueue device to single queue device (like GRE), the
>> inconsistency in the queue_mapping is fairly innocuous, we get one
>> warning but will pretty much take the unlikely branch for GRE packets
>> then on. But imagine a case where skb's device was change from one
>> multiqueue device to another, but the queue mapping was not also
>> updated. This would cause poor weighting in get_rps_cpus. For
>> example, if the new device had fewer queues than the old one,
>> get_rps_cpu will bias toward using queue 0's rps mask.
>
> I believe your patch is fine. Thanks
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: ESP trailer_len calculation
From: David Miller @ 2010-09-27 1:46 UTC (permalink / raw)
To: herbert; +Cc: kaber, eric.dumazet, netdev
In-Reply-To: <20100925062317.GA15565@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 25 Sep 2010 14:23:17 +0800
> The number 17 does look very strange, however, after going through
> the logic it does seem correct.
>
> To calculate the minimum safe trailer length we need to consider
> the worst-case scenario, and that is a packet where the payload
> just happens to be one byte less than the cipher block size.
>
> ESP always adds two bytes, then pads to at least the cipher
> block size, follwed by the authentication value. So in the
> worst case we need to add
>
> 2 + (blocksize - 1) + authlen =
> blocksize + 1 + authlen
>
> which is exactly what Patrick's patch does.
Thanks for explaining this Herbert, but I have to admit it's a bit
disappointing :-)
So what we have is that headerlen is actually a function f() which
depends upon the payload length and the size of any IP options, rather
than a fixed value that can be computed based upon the cipher
blocksize, encap mode, and device MTU.
I guess if we really cared about this we could make headerlen a method
rather than a value, but I doubt it's that much of an issue.
^ permalink raw reply
* Re: [PATCH] br2684: fix scheduling while atomic
From: David Miller @ 2010-09-27 1:29 UTC (permalink / raw)
To: mmvinni; +Cc: karl, netdev, chas
In-Reply-To: <538742.564.qm@web58407.mail.re3.yahoo.com>
From: Mikko Vinni <mmvinni@yahoo.com>
Date: Thu, 23 Sep 2010 09:51:24 -0700 (PDT)
> From: Karl Hiramoto <karl@hiramoto.org>
>> Subject: [PATCH] br2684: fix scheduling while atomic
>>
>> You can't call atomic_notifier_chain_unregister() while in atomic context.
>>
>> Fix, call un/register_atmdevice_notifier in module __init and __exit.
>>
>> Bug report:
>> http://comments.gmane.org/gmane.linux.network/172603
>>
>> Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
>
> Feel free to add
>
> Reported-and-tested-by: Mikko Vinni <mmvinni@yahoo.com>
Applied, thanks guys.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: propagate NETIF_F_HIGHDMA to vlans
From: David Miller @ 2010-09-27 1:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, yi.zou
In-Reply-To: <1285238771.2864.38.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 23 Sep 2010 12:46:11 +0200
> Automatically allows vlans to get NETIF_F_HIGHDMA if underlying device
> supports it.
>
> On 32bit arches (and more precisely if CONFIG_HIGHMEM is enabled), it
> can help to reduce cost of illegal_highdma() and __skb_linearize()
> calls.
>
> Tested on tg3 , bnx2, bonding, this worked very well.
>
> This is a generalization of a patch provided by Yi Zou & Jeff Kirsher.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: David Miller @ 2010-09-27 1:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, xiaosuo, socketcan, mst, netdev
In-Reply-To: <1285311660.2380.62.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 09:01:00 +0200
> af_packet (tx with mmap) is broken. I wonder who really uses it ?
I suspect now that af_packet supports VNET headers on transmit,
there are some things using this tx+mmap thing for sure.
> To properly cope with paged skbs, it should not try to fit several
> packets per page.
>
> The mmap api should change so that one mmaped page belongs to at most
> one skb, or else we need invasive changes in net/core
>
> This probably makes this stuff less interesting, unless the need is to
> send big packets. In this case, why splice was not used instead of
> custom mmap ?
I don't really see what the big issue is.
When the data destructor runs it means that packet's part of the pages
are available for reuse for the tx mmap client. And if I read it
correctly, that's exactly what tpacket_destruct_skb() is in fact doing.
There seems to be no conflict with that rule and reusing a page for
multiple packets.
^ 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