Re: [PATCH net] net: account for current skb length when deciding about UFO

ther fragments) for skb == NULL. > > Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach") > Fixes: e4c5e13aa45c ("ipv6: Should use consistent conditional judgement for > ip6 fragment between __ip6_append_data and ip6_finish_output") > Signed-off-by: M

Re: [PATCH net] net: account for current skb length when deciding about UFO

ther fragments) for skb == NULL. > > Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach") > Fixes: e4c5e13aa45c ("ipv6: Should use consistent conditional judgement for > ip6 fragment between __ip6_append_data and ip6_finish_output") > Signed-off-by: Mich

Re: [PATCH 5/5] sctp: Adjust one function call together with a variable assignment

t; - if ((in_dev = __in_dev_get_rcu(dev)) == NULL) { > + in_dev = __in_dev_get_rcu(dev); > + if (!in_dev) { > rcu_read_unlock(); > return; > } > Acked-by: Vlad Yasevich <vyasev...@gmail.com> -vlad

Re: [PATCH 5/5] sctp: Adjust one function call together with a variable assignment

n_dev = __in_dev_get_rcu(dev); > + if (!in_dev) { > rcu_read_unlock(); > return; > } > Acked-by: Vlad Yasevich -vlad

Re: [PATCH 4/5] sctp: Improve a size determination in sctp_inetaddr_event()

switch (ev) { > case NETDEV_UP: > - addr = kmalloc(sizeof(struct sctp_sockaddr_entry), GFP_ATOMIC); > + addr = kmalloc(sizeof(*addr), GFP_ATOMIC); > if (addr) { > addr->a.v4.sin_family = AF_INET; > addr->a.v4.sin_port = 0; > Acked-by: Vlad Yasevich <vyasev...@gmail.com> -vlad

Re: [PATCH 4/5] sctp: Improve a size determination in sctp_inetaddr_event()

tp_sockaddr_entry), GFP_ATOMIC); > + addr = kmalloc(sizeof(*addr), GFP_ATOMIC); > if (addr) { > addr->a.v4.sin_family = AF_INET; > addr->a.v4.sin_port = 0; > Acked-by: Vlad Yasevich -vlad

Re: [PATCH 3/5] sctp: Fix a typo in a comment line in sctp_init()

If we can't get that many pages > * reduce the order and try again >*/ > Acked-by: Vlad Yasevich <vyasev...@gmail.com. -vlad

Re: [PATCH 3/5] sctp: Fix a typo in a comment line in sctp_init()

d initialize the SCTP port hash table. > - * Note that order is initalized to start at the max sized > + * Note that order is initialized to start at the max sized >* table we want to support. If we can't get that many pages > * reduce the order and try again >*/ > Acked-by: Vlad Yasevich

Re: [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()

endpoint_hash alloc\n"); > status = -ENOMEM; > goto err_ehash_alloc; > } > Acked-by: Vlad Yasevich <vyasev...@gmail.com> At the time this was written, it was patterned after TCP. Since then TCP changed significantly. We can surely clean-up the pr_err() here and possibly update the code as well later. -vlad

Re: [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()

.5e7c8a344770 100644 > --- a/net/sctp/protocol.c > +++ b/net/sctp/protocol.c > @@ -1447,5 +1447,4 @@ static __init int sctp_init(void) > if (!sctp_ep_hashtable) { > - pr_err("Failed endpoint_hash alloc\n"); > status = -ENOMEM; >

Re: [PATCH 1/5] sctp: Use kmalloc_array() in sctp_init()

ccording to > the Linux coding style convention. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Acked-by: Vlad Yasevich <vyasev...@gmail.com> -vlad > --- > net/sctp/protocol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) &

Re: [PATCH 1/5] sctp: Use kmalloc_array() in sctp_init()

convention. > > Signed-off-by: Markus Elfring Acked-by: Vlad Yasevich -vlad > --- > net/sctp/protocol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c > index 989a900383b5..2b1a6215bd2f 10064

Re: [PATCH net] ipv6: sctp: clone options to avoid use after free

to avoid > future mistakes. > > Reported-by: Dmitry Vyukov > Signed-off-by: Eric Dumazet Acked-by: Vlad Yasevich This is sufficient for accept() processing, but looks like peeloff is missing a bunch of ipv6 support. I'll see if I can cook something up to fix that part. -vlad > --- &g

Re: [PATCH net] ipv6: sctp: clone options to avoid use after free

a common helper to avoid > future mistakes. > > Reported-by: Dmitry Vyukov <dvyu...@google.com> > Signed-off-by: Eric Dumazet <eduma...@google.com> Acked-by: Vlad Yasevich <vyasev...@gmail.com> This is sufficient for accept() processing, but looks like peeloff is mis

Re: use-after-free in sctp_do_sm

On 12/04/2015 07:55 AM, Marcelo Ricardo Leitner wrote: > On Fri, Dec 04, 2015 at 11:40:02AM +0100, Dmitry Vyukov wrote: >> On Thu, Dec 3, 2015 at 9:51 PM, Joe Perches wrote: >>> (adding lkml as this is likely better discussed there) >>> >>> On Thu, 2015-12-03 at 15:42 -0500, Jason Baron wrote:

Re: use-after-free in sctp_do_sm

On 12/04/2015 07:55 AM, Marcelo Ricardo Leitner wrote: > On Fri, Dec 04, 2015 at 11:40:02AM +0100, Dmitry Vyukov wrote: >> On Thu, Dec 3, 2015 at 9:51 PM, Joe Perches wrote: >>> (adding lkml as this is likely better discussed there) >>> >>> On Thu, 2015-12-03 at 15:42 -0500,

Re: [PATCH net-next] macvtap/macvlan: use IFF_NO_QUEUE

On 08/27/2015 10:42 PM, Jason Wang wrote: > > > On 08/27/2015 06:43 PM, Michael S. Tsirkin wrote: >> On Wed, Aug 26, 2015 at 01:45:30PM +0800, Jason Wang wrote: >>> >>> On 08/26/2015 12:32 AM, Vlad Yasevich wrote: >>>> On 08/25/2015 07:30 AM, J

Re: [PATCH net-next] macvtap/macvlan: use IFF_NO_QUEUE

On 08/27/2015 10:42 PM, Jason Wang wrote: On 08/27/2015 06:43 PM, Michael S. Tsirkin wrote: On Wed, Aug 26, 2015 at 01:45:30PM +0800, Jason Wang wrote: On 08/26/2015 12:32 AM, Vlad Yasevich wrote: On 08/25/2015 07:30 AM, Jason Wang wrote: On 08/25/2015 06:17 PM, Michael S. Tsirkin wrote

Re: [PATCH net-next] macvtap/macvlan: use IFF_NO_QUEUE

On 08/25/2015 07:30 AM, Jason Wang wrote: > > > On 08/25/2015 06:17 PM, Michael S. Tsirkin wrote: >> On Mon, Aug 24, 2015 at 04:33:12PM +0800, Jason Wang wrote: For macvlan, switch to use IFF_NO_QUEUE instead of tx_queue_len = 0. For macvtap, after commit

Re: [PATCH net-next] macvtap/macvlan: use IFF_NO_QUEUE

On 08/25/2015 07:30 AM, Jason Wang wrote: On 08/25/2015 06:17 PM, Michael S. Tsirkin wrote: On Mon, Aug 24, 2015 at 04:33:12PM +0800, Jason Wang wrote: For macvlan, switch to use IFF_NO_QUEUE instead of tx_queue_len = 0. For macvtap, after commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523

Re: [PATCH] sctp: Add counters for out data chunk discards

On 07/06/2015 01:37 PM, Vitaly Andrianov wrote: > This commit adds a MIB entry for out data chunk discards. > Number of outgoing SCTP DATA chunks for a SCTP association for which no > problems were encountered to prevent their transmission but were discarded. > Data chunks are discarded due to

Re: [PATCH] sctp: Add counters for out data chunk discards

On 07/06/2015 01:37 PM, Vitaly Andrianov wrote: This commit adds a MIB entry for out data chunk discards. Number of outgoing SCTP DATA chunks for a SCTP association for which no problems were encountered to prevent their transmission but were discarded. Data chunks are discarded due to

Re: kernel >= 4.0: crashes when using traceroute6 with isatap

On 05/12/2015 04:36 PM, Eric Dumazet wrote: > On Tue, 2015-05-12 at 16:18 -0400, Vlad Yasevich wrote: >> On 05/06/2015 06:11 PM, Wolfgang Walter wrote: >>> Am Mittwoch, 6. Mai 2015, 11:15:18 schrieben Sie: >>>> (Cc'ing netdev.) >>>> >>>>

Re: kernel >= 4.0: crashes when using traceroute6 with isatap

On 05/06/2015 06:11 PM, Wolfgang Walter wrote: > Am Mittwoch, 6. Mai 2015, 11:15:18 schrieben Sie: >> (Cc'ing netdev.) >> >> On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter wrote: >>> Am Samstag, 2. Mai 2015, 02:16:36 schrieb Wolfgang Walter: Hello, kernel 4.0 (and 4.0.1) crashes

Re: kernel >= 4.0: crashes when using traceroute6 with isatap

On 05/06/2015 06:42 PM, Eric Dumazet wrote: > On Thu, 2015-05-07 at 00:04 +0200, Wolfgang Walter wrote: >> Am Mittwoch, 6. Mai 2015, 12:10:00 schrieb Eric Dumazet: >>> On Wed, 2015-05-06 at 11:15 -0700, Cong Wang wrote: (Cc'ing netdev.) On Sat, May 2, 2015 at 5:29 AM, Wolfgang

Re: kernel = 4.0: crashes when using traceroute6 with isatap

On 05/06/2015 06:42 PM, Eric Dumazet wrote: On Thu, 2015-05-07 at 00:04 +0200, Wolfgang Walter wrote: Am Mittwoch, 6. Mai 2015, 12:10:00 schrieb Eric Dumazet: On Wed, 2015-05-06 at 11:15 -0700, Cong Wang wrote: (Cc'ing netdev.) On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter li...@stwm.de

Re: kernel = 4.0: crashes when using traceroute6 with isatap

On 05/06/2015 06:11 PM, Wolfgang Walter wrote: Am Mittwoch, 6. Mai 2015, 11:15:18 schrieben Sie: (Cc'ing netdev.) On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter li...@stwm.de wrote: Am Samstag, 2. Mai 2015, 02:16:36 schrieb Wolfgang Walter: Hello, kernel 4.0 (and 4.0.1) crashes

Re: kernel = 4.0: crashes when using traceroute6 with isatap

On 05/12/2015 04:36 PM, Eric Dumazet wrote: On Tue, 2015-05-12 at 16:18 -0400, Vlad Yasevich wrote: On 05/06/2015 06:11 PM, Wolfgang Walter wrote: Am Mittwoch, 6. Mai 2015, 11:15:18 schrieben Sie: (Cc'ing netdev.) On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter li...@stwm.de wrote: Am

Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

e did bisect, and the below looks the culprit; >>>>> >>>>> 32dce968dd987adfb0c00946d78dad9154f64759 is the first bad commit >>>>> commit 32dce968dd987adfb0c00946d78dad9154f64759 >>>>> Author: Vlad Yasevich >>>>> Date: Sat Jan 3

Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

32dce968dd987adfb0c00946d78dad9154f64759 Author: Vlad Yasevich vyasev...@gmail.com Date: Sat Jan 31 10:40:18 2015 -0500 ipv6: Allow for partial checksums on non-ufo packets Currntly, if we are not doing UFO on the packet, all UDP packets will start with CHECKSUM_NONE and thus

Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

rror >>>>>>> message in >>>>> host too. >>>>>>> ixgbe :2d:00.0: partial checksum but l4 proto=3a! >>>>>>> >>>>>>> Do you have any idea about that? >>>>>> >>>>>> Ah,

Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

32dce968dd987adfb0c00946d78dad9154f64759 Author: Vlad Yasevich vyasev...@gmail.com Date: Sat Jan 31 10:40:18 2015 -0500 ipv6: Allow for partial checksums on non-ufo packets Currntly, if we are not doing UFO on the packet, all UDP packets will start with CHECKSUM_NONE and thus

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

On 01/23/2015 12:10 PM, Daniel Borkmann wrote: > On 01/23/2015 05:05 PM, Vlad Yasevich wrote: >> On 01/23/2015 06:50 AM, Daniel Borkmann wrote: >>> On 01/23/2015 11:25 AM, Sun Paul wrote: >>> ... >>>> I would like to check the behave in LKSCTP. >>>

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

On 01/23/2015 05:25 AM, Sun Paul wrote: > Hi > > I would like to check the behave in LKSCTP. > > we are running DIAMETER message over SCTP, and we have set the > parameter "net.sctp.association_max_retrans = 4" in the LinuxOS. > > We noticed that when remote peer have retry to send the same

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

On 01/23/2015 06:50 AM, Daniel Borkmann wrote: > Hi, > > On 01/23/2015 11:25 AM, Sun Paul wrote: > ... >> I would like to check the behave in LKSCTP. >> >> we are running DIAMETER message over SCTP, and we have set the >> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS. >> >> We

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

On 01/23/2015 12:10 PM, Daniel Borkmann wrote: On 01/23/2015 05:05 PM, Vlad Yasevich wrote: On 01/23/2015 06:50 AM, Daniel Borkmann wrote: On 01/23/2015 11:25 AM, Sun Paul wrote: ... I would like to check the behave in LKSCTP. we are running DIAMETER message over SCTP, and we have set

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

On 01/23/2015 06:50 AM, Daniel Borkmann wrote: Hi, On 01/23/2015 11:25 AM, Sun Paul wrote: ... I would like to check the behave in LKSCTP. we are running DIAMETER message over SCTP, and we have set the parameter net.sctp.association_max_retrans = 4 in the LinuxOS. We noticed that when

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

On 01/23/2015 05:25 AM, Sun Paul wrote: Hi I would like to check the behave in LKSCTP. we are running DIAMETER message over SCTP, and we have set the parameter net.sctp.association_max_retrans = 4 in the LinuxOS. We noticed that when remote peer have retry to send the same request for

Re: [PATCH 3.2 105/131] net: Correctly set segment mac_len in skb_segment().

On 09/11/2014 08:32 AM, Ben Hutchings wrote: > 3.2.63-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Vlad Yasevich > > [ Upstream commit fcdfe3a7fa4cb74391d42b6a26dc07c20dab1d82 ] > > When performing segm

Re: [PATCH 3.2 105/131] net: Correctly set segment mac_len in skb_segment().

On 09/11/2014 08:32 AM, Ben Hutchings wrote: 3.2.63-rc1 review patch. If anyone has any objections, please let me know. -- From: Vlad Yasevich vyase...@redhat.com [ Upstream commit fcdfe3a7fa4cb74391d42b6a26dc07c20dab1d82 ] When performing segmentation, the mac_len

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

On 09/02/2014 02:15 PM, Cong Wang wrote: > On Tue, Sep 2, 2014 at 11:11 AM, Eric Dumazet wrote: >> On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote: >>> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa >> I definitely don't have a problem cleaning this up in net-next. I wanted a

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

On 09/02/2014 02:15 PM, Cong Wang wrote: On Tue, Sep 2, 2014 at 11:11 AM, Eric Dumazet eric.duma...@gmail.com wrote: On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote: On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa I definitely don't have a problem cleaning this up in net-next. I

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

On 08/29/2014 11:26 AM, Tommi Rantala wrote: > Hi, > > Was fuzzing Linus v3.17-rc2-89-g59753a8 with Trinity as the root user > in qemu, when I hit the following assertion failures. > > Tommi > > > [init] Started watchdog process, PID is 4841 > [main] Main thread is alive. > [ 77.229699]

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

On 08/29/2014 11:26 AM, Tommi Rantala wrote: Hi, Was fuzzing Linus v3.17-rc2-89-g59753a8 with Trinity as the root user in qemu, when I hit the following assertion failures. Tommi [init] Started watchdog process, PID is 4841 [main] Main thread is alive. [ 77.229699] sctp:

Re: [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe

Deepak Khandelwal > Suggested-by: Vlad Yasevich > Suggested-by: Michael Tuexen > Suggested-by: Daniel Borkmann > Signed-off-by: Zhu Yanjun Acked-by: Vlad Yasevich Thanks -vlad > --- > net/sctp/associola.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe

khandelwal.deepak.1...@gmail.com Suggested-by: Vlad Yasevich vyasev...@gmail.com Suggested-by: Michael Tuexen tue...@fh-muenster.de Suggested-by: Daniel Borkmann dbork...@redhat.com Signed-off-by: Zhu Yanjun yanjun@windriver.com Acked-by: Vlad Yasevich vyasev...@gmail.com Thanks -vlad --- net

3.16-rc1 kernel BUG triggered at mutex.c:586

Trying to boot 3.16.0-rc1+ (the + is a small vlan related patch) on a tests system triggers the following BUG: Jun 16 13:54:50 scratch kernel: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 Jun 16 13:54:50 scratch kernel: in_atomic(): 1, irqs_disabled(): 1, pid:

3.16-rc1 kernel BUG triggered at mutex.c:586

Trying to boot 3.16.0-rc1+ (the + is a small vlan related patch) on a tests system triggers the following BUG: Jun 16 13:54:50 scratch kernel: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 Jun 16 13:54:50 scratch kernel: in_atomic(): 1, irqs_disabled(): 1, pid:

Re: [PATCH v2] sctp: Fix sk_ack_backlog wrap-around problem

ist. > > Fix-suggested-by: Neil Horman > Signed-off-by: Xufeng Zhang Acked-by: Vlad Yasevich Thanks -vlad > --- > Change for v2: > Drop the redundant test for temp suggested by Vlad Yasevich. > > net/sctp/associola.c |2 +- > 1 files changed, 1 insertions(+)

Re: [PATCH v2] sctp: Fix sk_ack_backlog wrap-around problem

Signed-off-by: Xufeng Zhang xufeng.zh...@windriver.com Acked-by: Vlad Yasevich vyasev...@gmail.com Thanks -vlad --- Change for v2: Drop the redundant test for temp suggested by Vlad Yasevich. net/sctp/associola.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff

Re: [PATCH] sctp: Fix sk_ack_backlog wrap-around problem

On 06/11/2014 08:55 AM, Vlad Yasevich wrote: > On 06/10/2014 10:37 PM, Xufeng Zhang wrote: >> Consider the scenario: >> For a TCP-style socket, while processing the COOKIE_ECHO chunk in >> sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, >> a new a

Re: [PATCH] sctp: Fix sk_ack_backlog wrap-around problem

On 06/10/2014 10:37 PM, Xufeng Zhang wrote: > Consider the scenario: > For a TCP-style socket, while processing the COOKIE_ECHO chunk in > sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, > a new association would be created in sctp_unpack_cookie(), but afterwards, > some

Re: [PATCH] sctp: Fix sk_ack_backlog wrap-around problem

On 06/10/2014 10:37 PM, Xufeng Zhang wrote: Consider the scenario: For a TCP-style socket, while processing the COOKIE_ECHO chunk in sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, a new association would be created in sctp_unpack_cookie(), but afterwards, some processing

Re: [PATCH] sctp: Fix sk_ack_backlog wrap-around problem

On 06/11/2014 08:55 AM, Vlad Yasevich wrote: On 06/10/2014 10:37 PM, Xufeng Zhang wrote: Consider the scenario: For a TCP-style socket, while processing the COOKIE_ECHO chunk in sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, a new association would be created

Re: [PULL 2/2] vhost: replace rcu with mutex

On 06/03/2014 08:48 AM, Paolo Bonzini wrote: > Il 02/06/2014 23:58, Eric Dumazet ha scritto: >> This looks dubious >> >> What about using kfree_rcu() instead ? > > It would lead to unbound allocation from userspace. > >> translate_desc() still uses rcu_read_lock(), its not clear if the mutex >>

Re: [PULL 2/2] vhost: replace rcu with mutex

On 06/03/2014 08:48 AM, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. translate_desc() still uses rcu_read_lock(), its not clear if the mutex is really

Re: [PATCH net] bridge: notify user space after fdb update

On 05/27/2014 06:45 PM, Jon Maxwell wrote: > There has been a number incidents recently where customers running KVM have > reported that VM hosts on different Hypervisors are unreachable. Based on > pcap traces we found that the bridge was broadcasting the ARP request out > onto the network.

Re: [PATCH net] bridge: notify user space after fdb update

On 05/27/2014 06:45 PM, Jon Maxwell wrote: There has been a number incidents recently where customers running KVM have reported that VM hosts on different Hypervisors are unreachable. Based on pcap traces we found that the bridge was broadcasting the ARP request out onto the network. However

Re: skbuff truesize incorrect.

On 05/22/2014 03:07 PM, Jim Baxter wrote: > Hi, I was hoping you can help me with some questions. > > I have been investigating a network issue with bursts of network traffic > over USB CDC-NCM, the issue is that the kernel is dropping packets > because sk_rcvqueues_full() returns true due to

Re: skbuff truesize incorrect.

On 05/22/2014 03:07 PM, Jim Baxter wrote: Hi, I was hoping you can help me with some questions. I have been investigating a network issue with bursts of network traffic over USB CDC-NCM, the issue is that the kernel is dropping packets because sk_rcvqueues_full() returns true due to

Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)

On 05/20/2014 12:55 AM, valdis.kletni...@vt.edu wrote: > On Mon, 19 May 2014 23:49:22 +0930, David Newall said: > >> How does a packet get fragmented in this case? Does it only happen when >> bridging to a device with smaller MTU? That scenario sounds quite >> un-bridge-like. It also sounds

Re: linux-next: build failure after merge of the net tree

On 05/19/2014 08:59 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > > In file included from arch/powerpc/net/bpf_jit_comp.c:16:0: > include/linux/if_vlan.h: In function 'vlan_get_encap_level': >

Re: linux-next: build failure after merge of the net tree

On 05/19/2014 08:59 PM, Stephen Rothwell wrote: Hi all, After merging the net tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from arch/powerpc/net/bpf_jit_comp.c:16:0: include/linux/if_vlan.h: In function 'vlan_get_encap_level':

Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)

On 05/20/2014 12:55 AM, valdis.kletni...@vt.edu wrote: On Mon, 19 May 2014 23:49:22 +0930, David Newall said: How does a packet get fragmented in this case? Does it only happen when bridging to a device with smaller MTU? That scenario sounds quite un-bridge-like. It also sounds like

Re: [PATCH] macvlan: Fix checksum errors when ip_summed is CHECKSUM_PARTIAL

On 05/19/2014 01:24 PM, Michael Spang wrote: > Changing ip_summed from CHECKSUM_PARTIAL to CHECKSUM_UNNECESSARY > will result in an incorrect checksum if the packet is sent off the box. > > Cc: sta...@vger.kernel.org > Signed-off-by: Michael Spang > --- > drivers/net/macvlan.c | 4 +++- > 1

Re: [PATCH] macvlan: Fix checksum errors when ip_summed is CHECKSUM_PARTIAL

On 05/19/2014 01:24 PM, Michael Spang wrote: Changing ip_summed from CHECKSUM_PARTIAL to CHECKSUM_UNNECESSARY will result in an incorrect checksum if the packet is sent off the box. Cc: sta...@vger.kernel.org Signed-off-by: Michael Spang sp...@chromium.org --- drivers/net/macvlan.c | 4

Re: [PATCH 2/3] bridge: trigger a bridge calculation upon port changes

On 04/30/2014 06:59 PM, Luis R. Rodriguez wrote: > On Wed, Apr 30, 2014 at 04:04:34PM -0400, Vlad Yasevich wrote: >> On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote: >>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c >>> index 54d207d..dcd9378 100644 >>>

Re: [PATCH 2/3] bridge: trigger a bridge calculation upon port changes

On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote: > On Tue, Mar 18, 2014 at 02:22:43PM -0700, Luis R. Rodriguez wrote: >> On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote: >>> On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez wrote: On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong

Re: [PATCH 1/3] bridge: preserve random init MAC address

On 04/22/2014 03:41 PM, Luis R. Rodriguez wrote: > On Wed, Mar 19, 2014 at 7:05 PM, Luis R. Rodriguez wrote: >> On Tue, Mar 18, 2014 at 08:10:56PM -0700, Stephen Hemminger wrote: >>> On Wed, 12 Mar 2014 20:15:25 -0700 >>> "Luis R. Rodriguez" wrote: >>> As it is now if you add create a

Re: [PATCH 1/3] bridge: preserve random init MAC address

On 04/22/2014 03:41 PM, Luis R. Rodriguez wrote: On Wed, Mar 19, 2014 at 7:05 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Tue, Mar 18, 2014 at 08:10:56PM -0700, Stephen Hemminger wrote: On Wed, 12 Mar 2014 20:15:25 -0700 Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is now if

Re: [PATCH 2/3] bridge: trigger a bridge calculation upon port changes

On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote: On Tue, Mar 18, 2014 at 02:22:43PM -0700, Luis R. Rodriguez wrote: On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote: On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Mar 13, 2014 at 11:26:25AM -0700,

Re: [PATCH 2/3] bridge: trigger a bridge calculation upon port changes

On 04/30/2014 06:59 PM, Luis R. Rodriguez wrote: On Wed, Apr 30, 2014 at 04:04:34PM -0400, Vlad Yasevich wrote: On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote: diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index 54d207d..dcd9378 100644 --- a/net/bridge/br_if.c +++ b/net/bridge

Re: [PATCH V2] sctp: reset flowi4_oif parameter on route lookup

You'll detect that all the flow are routed to eth0.2(10.0.1.254). > > Signed-off-by: Xufeng Zhang > Signed-off-by: Julian Anastasov Acked-by: Vlad Yasevich -vlad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vg

Re: [PATCH V2] sctp: reset flowi4_oif parameter on route lookup

...@windriver.com Signed-off-by: Julian Anastasov j...@ssi.bg Acked-by: Vlad Yasevich vyasev...@gmail.com -vlad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 03/03/2014 04:13 AM, Christian Borntraeger wrote: > On 02/03/14 02:21, Vlad Yasevich wrote: >> On 03/01/2014 02:27 PM, Vlad Yasevich wrote: >>> On 03/01/2014 06:15 AM, Christian Borntraeger wrote: >>>> On 28/02/14 23:14, Vlad Yasevich wrote: >>>>>

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 03/03/2014 04:13 AM, Christian Borntraeger wrote: On 02/03/14 02:21, Vlad Yasevich wrote: On 03/01/2014 02:27 PM, Vlad Yasevich wrote: On 03/01/2014 06:15 AM, Christian Borntraeger wrote: On 28/02/14 23:14, Vlad Yasevich wrote: On 02/27/2014 03:52 PM, Christian Borntraeger wrote: Vlad

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 03/01/2014 02:27 PM, Vlad Yasevich wrote: > On 03/01/2014 06:15 AM, Christian Borntraeger wrote: >> On 28/02/14 23:14, Vlad Yasevich wrote: >>> On 02/27/2014 03:52 PM, Christian Borntraeger wrote: >>>> Vlad, >>>> >>>> commit 6acf54f1cf0a6747

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 03/01/2014 06:15 AM, Christian Borntraeger wrote: > On 28/02/14 23:14, Vlad Yasevich wrote: >> On 02/27/2014 03:52 PM, Christian Borntraeger wrote: >>> Vlad, >>> >>> commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 >>> macvtap: Add support of pac

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 03/01/2014 06:15 AM, Christian Borntraeger wrote: On 28/02/14 23:14, Vlad Yasevich wrote: On 02/27/2014 03:52 PM, Christian Borntraeger wrote: Vlad, commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 macvtap: Add support of packet capture on macvtap device. causes a performance

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 03/01/2014 02:27 PM, Vlad Yasevich wrote: On 03/01/2014 06:15 AM, Christian Borntraeger wrote: On 28/02/14 23:14, Vlad Yasevich wrote: On 02/27/2014 03:52 PM, Christian Borntraeger wrote: Vlad, commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 macvtap: Add support of packet capture

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 02/27/2014 03:52 PM, Christian Borntraeger wrote: > Vlad, > > commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 > macvtap: Add support of packet capture on macvtap device. > > causes a performance regression for iperf traffic between two KVM guests > on my s390 system. Both guests are

Re: macvtap performance regression (bisected) between 3.13 and 3.14-rc1

On 02/27/2014 03:52 PM, Christian Borntraeger wrote: Vlad, commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 macvtap: Add support of packet capture on macvtap device. causes a performance regression for iperf traffic between two KVM guests on my s390 system. Both guests are connected

Re: [PATCH RFC] sctp: Update HEARTBEAT timer immediately after user changed HB.interval

On 02/18/2014 10:39 AM, David Laight wrote: >>> + >>> + /* Update the heartbeat timer immediately. */ >>> + if (!mod_timer(>hb_timer, >>> + sctp_transport_timeout(trans))) >>> +

Re: [PATCH RFC] sctp: Update HEARTBEAT timer immediately after user changed HB.interval

On 02/18/2014 12:56 AM, Xufeng Zhang wrote: > For an established association, if user has updated the HB.interval > parameter by setsockopt(), this new heartbeat interval will not > take effect until: > - the expiry of the heartbeat timer and new hearbeat is sent. > - DATA chunk has been sent

Re: [PATCH RFC] sctp: Update HEARTBEAT timer immediately after user changed HB.interval

On 02/18/2014 12:56 AM, Xufeng Zhang wrote: For an established association, if user has updated the HB.interval parameter by setsockopt(), this new heartbeat interval will not take effect until: - the expiry of the heartbeat timer and new hearbeat is sent. - DATA chunk has been sent and

Re: [PATCH RFC] sctp: Update HEARTBEAT timer immediately after user changed HB.interval

On 02/18/2014 10:39 AM, David Laight wrote: + + /* Update the heartbeat timer immediately. */ + if (!mod_timer(trans-hb_timer, + sctp_transport_timeout(trans))) +

Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap

On 01/10/2014 02:06 AM, Jason Wang wrote: > On 01/10/2014 05:39 AM, Stephen Hemminger wrote: >> On Thu, 09 Jan 2014 16:55:07 +0800 >> Jason Wang wrote: >> >>> What if use do want a qdisc and want to change the its queue length for >>> tun/macvlan? And the the name tx_queue_length is misleading.

Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap

On 01/10/2014 02:06 AM, Jason Wang wrote: On 01/10/2014 05:39 AM, Stephen Hemminger wrote: On Thu, 09 Jan 2014 16:55:07 +0800 Jason Wang jasow...@redhat.com wrote: What if use do want a qdisc and want to change the its queue length for tun/macvlan? And the the name tx_queue_length is

Re: [patch net-next v3] ipv6: log autoconfiguration failures

On 12/13/2013 10:45 AM, Denys Vlasenko wrote: > If ipv6 auto-configuration does not work, currently it's hard > to track what's going on. This change adds log messages > (at debug level) on every code path where ipv6 autoconf fails. > > v3: changed pr_debug's to pr_warn's. > > Signed-off-by:

Re: [patch net-next v3] ipv6: log autoconfiguration failures

On 12/13/2013 10:45 AM, Denys Vlasenko wrote: If ipv6 auto-configuration does not work, currently it's hard to track what's going on. This change adds log messages (at debug level) on every code path where ipv6 autoconf fails. v3: changed pr_debug's to pr_warn's. Signed-off-by: Denys

Re: [patch net-next v2] ipv6: log autoconfiguration failures

On 12/12/2013 12:22 PM, David Miller wrote: > From: Denys Vlasenko > Date: Thu, 12 Dec 2013 12:17:42 +0100 > >> I can easily imagine their frustration. Kernel _knows_ why >> it didn't work, and it's not expected to normally pappen, >> why didn't it tell anything about it? > > Packets are

Re: [patch net-next v2] ipv6: log autoconfiguration failures

On 12/12/2013 12:22 PM, David Miller wrote: From: Denys Vlasenko dvlas...@redhat.com Date: Thu, 12 Dec 2013 12:17:42 +0100 I can easily imagine their frustration. Kernel _knows_ why it didn't work, and it's not expected to normally pappen, why didn't it tell anything about it? Packets

Re: [PATCH net V3 2/2] macvtap: signal truncated packets

hecking work. > > Cc: Vlad Yasevich > Cc: Zhi Yong Wu > Cc: Michael S. Tsirkin > Signed-off-by: Jason Wang Acked-by: Vlad Yasevich -vlad > --- > Changes from V2: > - use total as the bytes of packet returned > Changes from V1: > - increase total unconditionally > - d

Re: [PATCH net V3 2/2] macvtap: signal truncated packets

: Vlad Yasevich vyasev...@gmail.com Cc: Zhi Yong Wu wu...@linux.vnet.ibm.com Cc: Michael S. Tsirkin m...@redhat.com Signed-off-by: Jason Wang jasow...@redhat.com Acked-by: Vlad Yasevich vyasev...@gmail.com -vlad --- Changes from V2: - use total as the bytes of packet returned Changes from V1

Re: [PATCH 2/2] tun: remove useless codes in tun_chr_aio_read() and tun_recvmsg()

On 12/09/2013 08:36 PM, David Miller wrote: > From: Zhi Yong Wu > Date: Sat, 7 Dec 2013 04:55:00 +0800 > >> From: Zhi Yong Wu >> >> By checking related codes, it is impossible that ret > len or total_len, >> so we should remove some useless codes in both above functions. >> >> Signed-off-by:

Re: [PATCH 2/2] tun: remove useless codes in tun_chr_aio_read() and tun_recvmsg()

On 12/09/2013 08:36 PM, David Miller wrote: From: Zhi Yong Wu zwu.ker...@gmail.com Date: Sat, 7 Dec 2013 04:55:00 +0800 From: Zhi Yong Wu wu...@linux.vnet.ibm.com By checking related codes, it is impossible that ret len or total_len, so we should remove some useless codes in both above

Re: [PATCH net 1/2] tun: unbreak truncated packet signalling

eater than iov length in tun_put_user(). This patch fixes this >> by always return the length of packet plus possible vlan header. Caller can >> detect the truncated packet by comparing the return value and the size of iov >> length. >> >> Reported-by: Vlad Yasevich >

Re: [PATCH net 1/2] tun: unbreak truncated packet signalling

(). This patch fixes this by always return the length of packet plus possible vlan header. Caller can detect the truncated packet by comparing the return value and the size of iov length. Reported-by: Vlad Yasevich vyasev...@gmail.com Cc: Vlad Yasevich vyasev...@gmail.com Cc: Zhi Yong Wu wu

Re: [PATCH 1/2] macvtap: remove useless codes in macvtap_aio_read() and macvtap_recvmsg()

On 12/06/2013 03:54 PM, Zhi Yong Wu wrote: > From: Zhi Yong Wu > > By checking related codes, it is impossible that ret > len or total_len, > so we should remove some useless coeds in both above functions. Looks like commit 6680ec68eff47d36f67b4351bc9836fd6cba9532 Author: Jason Wang Date:

Re: [PATCH v2 2/2] tun: update file current position

On 12/06/2013 12:45 PM, David Miller wrote: > From: Zhi Yong Wu > Date: Fri, 6 Dec 2013 17:08:50 +0800 > >> From: Zhi Yong Wu >> >> Signed-off-by: Zhi Yong Wu > > Also applied and queued up for -stable, thanks. > > I noticed in these two cases that that min_t() adjustment of 'ret' > seems

  1   2   3   4   >