在 2016年01月22日 14:52, Jiri Pirko 写道:
Fri, Jan 22, 2016 at 05:21:28AM CET, wen.gang.w...@oracle.com wrote:
在 2016年01月21日 16:35, Jiri Pirko 写道:
Thu, Jan 21, 2016 at 06:32:58AM CET, wen.gang.w...@oracle.com wrote:
In a bonding setting, we determines fragment size according to MTU and
PMTU assoc
* Alexei Starovoitov wrote:
> > > I could be missing something. I think either this patch is not need or
> > > you
> > > need to teach the tool to ignore all JITed stuff. I don't think it's
> > > practical to annotate everything. Different JITs do their own magic. s390
> > > JIT is even more
Fri, Jan 22, 2016 at 05:21:28AM CET, wen.gang.w...@oracle.com wrote:
>
>
>在 2016年01月21日 16:35, Jiri Pirko 写道:
>>Thu, Jan 21, 2016 at 06:32:58AM CET, wen.gang.w...@oracle.com wrote:
>>>In a bonding setting, we determines fragment size according to MTU and
>>>PMTU associated to the bonding master. If
On 01/20/2016 10:35 PM, Michael S. Tsirkin wrote:
> On Tue, Dec 01, 2015 at 02:39:45PM +0800, Jason Wang wrote:
>> This patch tries to poll for new added tx buffer or socket receive
>> queue for a while at the end of tx/rx processing. The maximum time
>> spent on polling were specified through a
On 01/20/2016 10:09 PM, Michael S. Tsirkin wrote:
> On Tue, Dec 01, 2015 at 02:39:44PM +0800, Jason Wang wrote:
>> Signed-off-by: Jason Wang
> Wow new API with no comments anywhere, and no
> commit log to say what it's good for.
> Want to know what it does and whether
> it's correct? You have to
On Thu, Jan 21, 2016 at 09:55:31PM -0600, Josh Poimboeuf wrote:
> On Thu, Jan 21, 2016 at 06:44:28PM -0800, Alexei Starovoitov wrote:
> > On Thu, Jan 21, 2016 at 04:49:27PM -0600, Josh Poimboeuf wrote:
> > > bpf_jit.S has several callable non-leaf functions which don't honor
> > > CONFIG_FRAME_POIN
在 2016年01月21日 16:35, Jiri Pirko 写道:
Thu, Jan 21, 2016 at 06:32:58AM CET, wen.gang.w...@oracle.com wrote:
In a bonding setting, we determines fragment size according to MTU and
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and call
On Thu, Jan 21, 2016 at 06:55:41PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 21, 2016 at 04:49:35PM -0600, Josh Poimboeuf wrote:
> > stacktool reports the following false positive warnings:
> >
> > stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x5c: sibling call from
> > callable instruct
On Thu, Jan 21, 2016 at 06:44:28PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 21, 2016 at 04:49:27PM -0600, Josh Poimboeuf wrote:
> > bpf_jit.S has several callable non-leaf functions which don't honor
> > CONFIG_FRAME_POINTER, which can result in bad stack traces.
> >
> > Create a stack frame
Hi,
I hit this while I was testing 4.5-rc1 with randconfig during merger period.
And now I noticed that it was fixed after Linus merged akpm branch.
commit eae21770b4fed5597623aad0d618190fa60426ff
Merge: e9f57eb 9f273c2
Author: Linus Torvalds
Date: Thu Jan 21 12:32:08 2016 -0800
Merge bran
On Fri, Jan 22, 2016 at 12:46:28AM +0100, Daniel Borkmann wrote:
> Add a test that symbol from relocation entry is actually related
> to map section and bail out with an error message if it's not the
> case; in relation to [1].
>
> [1] https://llvm.org/bugs/show_bug.cgi?id=26243
>
> Signed-off-
On Thu, Jan 21, 2016 at 04:49:35PM -0600, Josh Poimboeuf wrote:
> stacktool reports the following false positive warnings:
>
> stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x5c: sibling call from
> callable instruction with changed frame pointer
> stacktool: kernel/bpf/core.o: __bpf_prog_ru
On Thu, Jan 21, 2016 at 04:49:27PM -0600, Josh Poimboeuf wrote:
> bpf_jit.S has several callable non-leaf functions which don't honor
> CONFIG_FRAME_POINTER, which can result in bad stack traces.
>
> Create a stack frame before the call instructions when
> CONFIG_FRAME_POINTER is enabled.
>
> Sig
Several times already this has been reported as kasan reports caused by
syzkaller and trinity and people always looked at RCU races, but it is
much more simple. :)
In case we bind a pptp socket multiple times, we simply add it to
the callid_sock list but don't remove the old binding. Thus the old
For interrupt controller that doesn't support irq_disable and hardware
with level interrupt, an extra interrupt may be pending. This patch fixes
the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line,
as suggested by,
'commit e9849777d0e2 ("genirq: Add flag to force mask in
Add a test that symbol from relocation entry is actually related
to map section and bail out with an error message if it's not the
case; in relation to [1].
[1] https://llvm.org/bugs/show_bug.cgi?id=26243
Signed-off-by: Daniel Borkmann
---
tc/tc_bpf.c | 6 ++
1 file changed, 6 insertions(
This is v16 of the compile-time stack metadata validation patch set,
along with proposed fixes for most of the warnings it found. It's based
on the tip/master branch.
v15 can be found here:
https://lkml.kernel.org/r/cover.1450442274.git.jpoim...@redhat.com
For more information about the motiv
From: Or Gerlitz
Date: Fri, 22 Jan 2016 00:45:13 +0200
> Dave, at least in the ConnectX4 (mlx5e driver), as I commented earlier
> on this thread, we can use programmed tags reported by the HW on the
> completion of packets whether the ethtype is ipv4 or ipv6 or
> something else, and let the kern
bpf_jit.S has several functions which can be called from C code. Give
them proper ELF annotations.
Signed-off-by: Josh Poimboeuf
Cc: Alexei Starovoitov
Cc: netdev@vger.kernel.org
---
arch/x86/net/bpf_jit.S | 39 ---
1 file changed, 16 insertions(+), 23 delet
On 01/21/2016 11:49 PM, Josh Poimboeuf wrote:
stacktool reports the following false positive warnings:
stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x5c: sibling call from
callable instruction with changed frame pointer
stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x60: function has
bpf_jit.S has several callable non-leaf functions which don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create a stack frame before the call instructions when
CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
Cc: Alexei Starovoitov
Cc: netdev@vger.kernel.org
stacktool reports the following false positive warnings:
stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x5c: sibling call from
callable instruction with changed frame pointer
stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x60: function has unreachable
instruction
stacktool: kernel/bpf/co
On Thu, Jan 21, 2016 at 11:14 AM, Edward Cree wrote:
> Signed-off-by: Edward Cree
> ---
> Haven't yet tried to write the ethtool client end of this (or a driver
> implementation), but does it look reasonable?
>
> include/uapi/linux/ethtool.h | 30 +-
> 1 file changed,
On Thu, Jan 21, 2016 at 8:56 PM, David Miller wrote:
> From: Or Gerlitz
> Date: Thu, 21 Jan 2016 14:49:25 +0200
>
>> On Thu, Jan 21, 2016 at 1:27 PM, Jesper Dangaard Brouer
>> wrote:
>>> On Wed, 20 Jan 2016 15:27:38 -0800 Tom Herbert wrote:
>>>
eth_type_trans touches headers
>>>
>>> True,
From: Johannes Weiner
Date: Thu, 21 Jan 2016 15:56:28 -0500
> From ac0fd0c5f31cdc73c52fd86f40af419c1871fbcf Mon Sep 17 00:00:00 2001
> From: Johannes Weiner
> Date: Thu, 21 Jan 2016 13:34:47 -0500
> Subject: [PATCH] net: sock: remove dead cgroup methods from struct proto
>
> The cgroup methods
> >> -module_platform_driver(mv88e6123_driver);
> >>
> >> +static int __init mv88e6123_init(void)
> >> +{
> >> + register_switch_driver(&mv88e6123_switch_driver);
> >> +
> >> + return platform_driver_register(&mv88e6123_driver);
> >> +}
> >> +
> >> +static void __exit mv88e6123_exit(void)
> >>
Hi Andrew, Florian,
Florian Fainelli writes:
> Le 23/12/2015 04:56, Andrew Lunn a écrit :
>> Turn mv88e6xxx into a library module, by exporting its symbols. Have
>> each driver register their own driver functions with the DSA core in
>> there init function.
>>
>> This results in each driver be
On Tue, Jan 19, 2016 at 05:00:35AM +, Shaohui Xie wrote:
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Monday, January 18, 2016 11:15 PM
> > To: Shaohui Xie
> > Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com;
> > devicet...@vger.kernel.or
Hi Andrew,
Just a single nitpick below.
Andrew Lunn writes:
> diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
> index 02810a50825b..41472dc409ce 100644
> --- a/drivers/net/dsa/mv88e6060.c
> +++ b/drivers/net/dsa/mv88e6060.c
> @@ -1,6 +1,7 @@
> /*
> * net/dsa/mv88e606
On Thu, Jan 21, 2016 at 10:30:31PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/21/2016 10:01 PM, Johannes Weiner wrote:
>
> >The cgroup methods are no longer used after baac50b ("net:
>
>12-digit ID is now enforced by scripts/checkpatch.pl.
Thanks for the headsup, that hasn't made it i
Hi Andrew,
Andrew Lunn writes:
> mv88e6xxx_lookup_name() returns the model name of a switch at a given
> address on an MII bus. Using mii_bus it identify the bus rather than
> the host device is more logical, so change the parameter.
>
> Signed-off-by: Andrew Lunn
> ---
> drivers/net/dsa/mv88e
> > @@ -176,6 +170,15 @@ static int mv88e6060_setup(struct dsa_switch *ds,
> > struct device *dev)
> > {
> > int i;
> > int ret;
> > + struct mv88e6060_priv *priv;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
Hi Andrew,
Andrew Lunn writes:
> Rather than looking up the mii bus and address every time, do it once
> and setup, and keep it in the private structure.
>
> Signed-off-by: Andrew Lunn
> ---
> drivers/net/dsa/mv88e6060.c | 23 +--
> drivers/net/dsa/mv88e6060.h | 11
Update lan78xx to use patch of commit 4f2aaf7dd95b
("Merge branch 'fix-phy-ignore-interrupts'")
Signed-off-by: Woojung Huh
---
drivers/net/usb/lan78xx.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/
Hello everyone
I am playing with changing netmask for ip v4 address and find out that
there is no
other possibility to do it except:
ip address add 1.2.3.4/21 dev
ip address del 1.2.3.4/24 dev
Looks like all is working but I would like to get official answer
that this is safe to do in such way
On Thu, Jan 21, 2016 at 11:57:16AM -0800, Eric Dumazet wrote:
> On Thu, 2016-01-21 at 17:37 -0200, Marcelo Ricardo Leitner wrote:
> > On Thu, Jan 21, 2016 at 11:27:36AM -0800, Eric Dumazet wrote:
> > > On Fri, 2016-01-22 at 01:49 +0800, Xin Long wrote:
> > > > Previously, before rhashtable, /proc a
From: Teresa Remmet
Date: Wed, 20 Jan 2016 13:40:35 +0100
> When the lan87xx_read_status function is getting called the
> energy detect mode is enabled again even if it has been
> disabled by device tree.
>
> Added private struct to check the energy detect status.
>
> Signed-off-by: Teresa Remm
From: Jisheng Zhang
Date: Wed, 20 Jan 2016 19:27:21 +0800
> Some platforms may provide more than one clk for the mvneta IP, for
> example Marvell BG4CT provides "core" clk for the mac core, and "axi"
> clk for the AXI bus logic.
>
> This series tries to addess the "more than one clk" issue. Note
Thu, Jan 21, 2016 at 12:47:54PM CET, pru...@brocade.com wrote:
>Add RTM_NEWADDR and RTM_DELADDR netlink messages to indicate
>interest in specific multicast hardware addresses. These messages
>are sent when addressed are added or deleted from the appropriate
>interface driver.
>
>Signed-off-by: Pat
From: Jisheng Zhang
Date: Wed, 20 Jan 2016 16:36:25 +0800
> When s->type is T_REG_64, the high 32bits are lost in val. This patch
> fixes this trivial issue.
>
> Signed-off-by: Jisheng Zhang
> Fixes: 9b0cdefa4cd5 ("net: mvneta: add ethtool statistics")
Applied.
From: Kejian Yan
Date: Wed, 20 Jan 2016 16:00:19 +0800
> This patch replace the assoication between dsaf and enet from string
> matching to object reference. It requires the DTS to be updated within
> BIOS. Thanks god it can be done for all released boards.
>
> Signed-off-by: Kejian Yan
> Acked
Signed-off-by: Edward Cree
---
Haven't yet tried to write the ethtool client end of this (or a driver
implementation), but does it look reasonable?
include/uapi/linux/ethtool.h | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/
On Thu, 2016-01-21 at 17:37 -0200, Marcelo Ricardo Leitner wrote:
> On Thu, Jan 21, 2016 at 11:27:36AM -0800, Eric Dumazet wrote:
> > On Fri, 2016-01-22 at 01:49 +0800, Xin Long wrote:
> > > Previously, before rhashtable, /proc assoc listing was done by
> > > read-locking the entire hash entry and
On Thu, Jan 21, 2016 at 11:27:36AM -0800, Eric Dumazet wrote:
> On Fri, 2016-01-22 at 01:49 +0800, Xin Long wrote:
> > Previously, before rhashtable, /proc assoc listing was done by
> > read-locking the entire hash entry and dumping all assocs at once, so we
> > were sure that the assoc wasn't free
From: David Miller
Date: Thu, 21 Jan 2016 10:45:20 -0800
>
> Yes, you will submit to me a patch to remove the unused code.
I should have paraphrased it better:
"I have the patch ready and will submit it when net-next opens again."
Hello.
On 01/21/2016 10:01 PM, Johannes Weiner wrote:
The cgroup methods are no longer used after baac50b ("net:
12-digit ID is now enforced by scripts/checkpatch.pl.
tcp_memcontrol: simplify linkage between socket and page counter").
The hunk to delete them was included in the original
On Fri, 2016-01-22 at 01:49 +0800, Xin Long wrote:
> Previously, before rhashtable, /proc assoc listing was done by
> read-locking the entire hash entry and dumping all assocs at once, so we
> were sure that the assoc wasn't freed because it wouldn't be possible to
> remove it from the hash meanwhi
From: Or Gerlitz
Date: Thu, 21 Jan 2016 20:40:53 +0200
> On Thu, Jan 21, 2016 at 8:24 PM, Faisal Latif wrote:
>
>> We can certainly take up the discussion on improving the current port mapper
>> design/implementation. But
>> that would be more appropriate in a separate thread.
>
> If we obser
From: Eric Dumazet
Date: Thu, 21 Jan 2016 08:02:54 -0800
> From: Eric Dumazet
>
> Neal reported crashes with this stack trace :
>
> RIP: 0010:[] tcp_v4_send_ack+0x41/0x20f
> ...
> CR2: 0018 CR3: 00044005c000 CR4: 001427e0
> ...
> [] tcp_v4_reqsk_send_ack+0xa5/0xb4
>
From: Jiri Benc
Date: Thu, 21 Jan 2016 15:57:15 +0100
> On Wed, 20 Jan 2016 16:22:47 -0800, Jesse Gross wrote:
>> When configuring checksums on UDP tunnels, the flags are different
>> for IPv4 vs. IPv6 (and reversed). However, when lightweight tunnels
>> are enabled the flags used are always the
From: Shuah Khan
Date: Thu, 21 Jan 2016 07:04:17 -0700
> On 01/20/2016 10:10 PM, Jεan Sacren wrote:
>> From: David Miller
>> Date: Tue, 19 Jan 2016 14:36:28 -0500
>>>
>>> From: Julia Lawall
>>> Date: Tue, 19 Jan 2016 19:54:20 +0100 (CET)
>>
>> [...]
>>
I just wondered. I was looking at
From: Or Gerlitz
Date: Thu, 21 Jan 2016 14:49:25 +0200
> On Thu, Jan 21, 2016 at 1:27 PM, Jesper Dangaard Brouer
> wrote:
>> On Wed, 20 Jan 2016 15:27:38 -0800 Tom Herbert wrote:
>>
>>> eth_type_trans touches headers
>>
>> True, the eth_type_trans() call in the driver is a major bottleneck,
>>
The cgroup methods are no longer used after baac50b ("net:
tcp_memcontrol: simplify linkage between socket and page counter").
The hunk to delete them was included in the original patch but must
have gotten lost during conflict resolution on the way upstream.
Fixes: baac50b ("net: tcp_memcontrol:
First, this doesn't compile.
Second, net-next is closed.
From: Jesper Dangaard Brouer
Date: Thu, 21 Jan 2016 12:27:30 +0100
> eth_type_trans() does two things:
>
> 1) determine skb->protocol
> 2) setup skb->pkt_type = PACKET_{BROADCAST,MULTICAST,OTHERHOST}
>
> Could the HW descriptor deliver the "proto", or perhaps just some bits
> on the most common
From: Florian Fainelli
Date: Wed, 20 Jan 2016 22:32:09 -0800
> On January 20, 2016 6:58:09 PM PST, David Miller wrote:
>>From:
>>Date: Thu, 21 Jan 2016 00:59:42 +
>>
>>> > I'm experiencing misbehavior after restart system.
Can you wait applying the patch?
Sorry about it.
>>
From: Sudip Mukherjee
Date: Thu, 21 Jan 2016 10:42:31 +0530
> The defconfig build of blackfin is failing with the error:
>
> arch/blackfin/include/asm/bfin_serial.h:269:0: warning: "port_membase"
> redefined
> drivers/net/irda/bfin_sir.h:85:0: note: this is the location of the previous
> defin
From: Jεan Sacren
Date: Wed, 20 Jan 2016 22:10:56 -0700
> From: David Miller
> Date: Tue, 19 Jan 2016 14:36:28 -0500
>>
>> From: Julia Lawall
>> Date: Tue, 19 Jan 2016 19:54:20 +0100 (CET)
>
> [...]
>
>> > I just wondered. I was looking at dependencies between networking files.
>> > This one
On Thu, Jan 21, 2016 at 8:24 PM, Faisal Latif wrote:
> We can certainly take up the discussion on improving the current port mapper
> design/implementation. But
> that would be more appropriate in a separate thread.
If we observe a kernel API / mechanism which could be wrongly
duplicated betwee
We need limits.h for PATH_MAX, fixes:
rt_names.c:364:13: error: ‘PATH_MAX’ undeclared (first use in this
function)
Signed-off-by: Gustavo Zacarias
---
lib/rt_names.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/rt_names.c b/lib/rt_names.c
index f6d17c0..b665d3e 100644
--- a/lib/rt_na
On Thu, Jan 21, 2016 at 07:05:48PM +0200, Or Gerlitz wrote:
> On 1/21/2016 5:32 PM, Steve Wise wrote:
> >Only a single user-space daemon is used.
>
> Good.
>
> >Someone from Intel might have insight into the architecture and design.
> >Perhaps the intention is that individual drivers might want
On Fri, Jan 22, 2016 at 1:49 AM, Xin Long wrote:
Fixing a bug that was introduce in rhashtable patchset and a follow-up
cleanup that is now possible
> Xin Long (3):
> sctp: fix the transport dead race check by using atomic_add_unless on
> refcnt
> sctp: hold transport before we access t-
On Fri, Jan 22, 2016 at 01:49:09AM +0800, Xin Long wrote:
> After we use refcnt to check if transport is alive, the dead can be
> removed from sctp_transport.
>
> The traversal of transport_addr_list in procfs dump is using
> list_for_each_entry_rcu, no need to check if it has been freed.
>
> sct
On Fri, Jan 22, 2016 at 01:49:08AM +0800, Xin Long wrote:
> Previously, before rhashtable, /proc assoc listing was done by
> read-locking the entire hash entry and dumping all assocs at once, so we
> were sure that the assoc wasn't freed because it wouldn't be possible to
> remove it from the hash
On Fri, Jan 22, 2016 at 01:49:07AM +0800, Xin Long wrote:
> Now when __sctp_lookup_association is running in BH, it will try to
> check if t->dead is set, but meanwhile other CPUs may be freeing this
> transport and this assoc and if it happens that
> __sctp_lookup_association checked t->dead a bit
Previously, before rhashtable, /proc assoc listing was done by
read-locking the entire hash entry and dumping all assocs at once, so we
were sure that the assoc wasn't freed because it wouldn't be possible to
remove it from the hash meanwhile.
Now we use rhashtable to list transports, and dump ent
After we use refcnt to check if transport is alive, the dead can be
removed from sctp_transport.
The traversal of transport_addr_list in procfs dump is using
list_for_each_entry_rcu, no need to check if it has been freed.
sctp_generate_t3_rtx_event and sctp_generate_heartbeat_event is
protected b
Xin Long (3):
sctp: fix the transport dead race check by using atomic_add_unless on
refcnt
sctp: hold transport before we access t->asoc in sctp proc
sctp: remove the dead field of sctp_transport
include/net/sctp/structs.h | 5 ++---
net/sctp/input.c | 17 +++--
n
Now when __sctp_lookup_association is running in BH, it will try to
check if t->dead is set, but meanwhile other CPUs may be freeing this
transport and this assoc and if it happens that
__sctp_lookup_association checked t->dead a bit too early, it may think
that the association is still good while
On Thu, 2016-01-21 at 08:38 -0800, Tom Herbert wrote:
> Sure, but the receive path is parallelized.
This is true for multiqueue processing, assuming you can dedicate many
cores to process RX.
> Improving parallelism has
> continuously shown to have much more impact than attempting to
> optimize
On Thu, Jan 21, 2016 at 03:18:18PM -0200, Marcelo Ricardo Leitner wrote:
> On Tue, Jan 19, 2016 at 09:38:54AM -0500, Vlad Yasevich wrote:
> > On 01/15/2016 02:01 PM, Marcelo Ricardo Leitner wrote:
> > > On Wed, Jan 13, 2016 at 10:52:31AM +0100, Dmitry Vyukov wrote:
> > >> Hello,
> > >>
> > >> The f
On Tue, Jan 19, 2016 at 09:38:54AM -0500, Vlad Yasevich wrote:
> On 01/15/2016 02:01 PM, Marcelo Ricardo Leitner wrote:
> > On Wed, Jan 13, 2016 at 10:52:31AM +0100, Dmitry Vyukov wrote:
> >> Hello,
> >>
> >> The following program causes use-after-free in __sctp_connect:
> >>
> > ...
> >> INFO: Fre
Helmut Schaa writes:
> On Thu, Jan 21, 2016 at 5:56 PM, Helmut Schaa
> wrote:
>> On Sat, Oct 17, 2015 at 10:04 PM, Paul McQuade wrote:
>>> Removed empty spaces before/after parenthesis
>>>
>>> Signed-off-by: Paul McQuade
>>
>> Just noticed these did not get applied by Kalle yet.
>
> Kalle, can
On Sat, Oct 17, 2015 at 11:11 PM, Paul McQuade wrote:
> Space needed before open parenthesis
>
> Signed-off-by: Paul McQuade
Looks valid to me.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt2x00debug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 1/21/2016 5:32 PM, Steve Wise wrote:
Only a single user-space daemon is used.
Good.
Someone from Intel might have insight into the architecture and design.
Perhaps the intention is that individual drivers might want to have their own
handlers for these various operations. But currently
On Sat, Oct 17, 2015 at 11:06 PM, Paul McQuade wrote:
> Removed empty spaces before/after parenthesis
>
> Signed-off-by: Paul McQuade
Looks valid to me as well.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt2x00.h | 24
> 1 file changed, 12 insertions(
On Thu, Jan 21, 2016 at 5:56 PM, Helmut Schaa
wrote:
> On Sat, Oct 17, 2015 at 10:04 PM, Paul McQuade wrote:
>> Removed empty spaces before/after parenthesis
>>
>> Signed-off-by: Paul McQuade
>
> Just noticed these did not get applied by Kalle yet.
Kalle, can you fix up the path (ralink/rt2x00
On Sat, Oct 17, 2015 at 11:06 PM, Paul McQuade wrote:
> Code Style: pointer is declared wrong
>
> Signed-off-by: Paul McQuade
Thanks for fixing this code style issue.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt2x00.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(
On Sat, Oct 17, 2015 at 10:04 PM, Paul McQuade wrote:
> Removed empty spaces before/after parenthesis
>
> Signed-off-by: Paul McQuade
Just noticed these did not get applied by Kalle yet.
Looks good to me.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt61pci.h | 20 ++--
On Thu, Jan 21, 2016 at 4:23 AM, Jesper Dangaard Brouer
wrote:
> On Wed, 20 Jan 2016 15:27:38 -0800
> Tom Herbert wrote:
>
>> weaknesses of Toeplitz we talked about recently and that fact that
>> Jenkins is really fast to compute, I am starting to think maybe we
>> should always do a software has
On Thu, 2016-01-21 at 12:27 +0100, Jesper Dangaard Brouer wrote:
> In my experiments, where I extract several packet before calling
> napi_gro_receive(), and I also delay calling eth_type_trans(). Most of
> my speedup comes from this trick, as the prefetch() now that enough
> time.
It really dep
On 01/21/2016 04:28 PM, Damien Riegel wrote:
> I tested the new technologic version and it works as expected.
Thanks.
> Would be nice if someone could test the nxp version to ensure no
> regressions has been introduced (I don't have such hardware here).
I don't have the hardware, either.
Marc
-
On Thu, Jan 21, 2016 at 11:02 AM, Eric Dumazet wrote:
> From: Eric Dumazet
...
> The problem here is the skb we provide to tcp_v4_send_ack() had to
> be parked in the backlog of a new TCP fastopen child because this child
> was owned by the user at the time an out of window packet arrived.
>
> Be
From: Eric Dumazet
Neal reported crashes with this stack trace :
RIP: 0010:[] tcp_v4_send_ack+0x41/0x20f
...
CR2: 0018 CR3: 00044005c000 CR4: 001427e0
...
[] tcp_v4_reqsk_send_ack+0xa5/0xb4
[] tcp_check_req+0x2ea/0x3e0
[] tcp_rcv_state_process+0x850/0x2500
[] tc
Hi Marc,
I tested the new technologic version and it works as expected. Would be
nice if someone could test the nxp version to ensure no regressions has
been introduced (I don't have such hardware here).
On Wed, Jan 20, 2016 at 04:43:31PM +0100, Marc Kleine-Budde wrote:
> From: Damien Riegel
>
hi guys
As per the comment at the top of net/core/neighbor.c we should be
taking this lock even for scanning the hash buckets. I do see that
this lock is taken in pneigh_lookup() but not in neigh_lookup(). Am i
missing something?
For the context I am investigating the following crash which happen
> On 1/21/2016 12:57 AM, Steve Wise wrote:
> > I also asked you why the port mapper code has to be present in each
> > iwarp driver and not part of the IB core stack, and you responded
> > "i40iw iwarp driver registers with port mapper and uses its services.
> > Beside that it is not the scope of t
Julia Lawall writes:
> On Sat, 2 Jan 2016, SF Markus Elfring wrote:
>
>> >> Move the jump label directly before the desired log statement
>> >> so that the variable "err" will not be checked once more
>> >> after it was determined that a function call failed.
>> >> Use the identifier "report_fail
On Wed, 20 Jan 2016 16:22:47 -0800, Jesse Gross wrote:
> When configuring checksums on UDP tunnels, the flags are different
> for IPv4 vs. IPv6 (and reversed). However, when lightweight tunnels
> are enabled the flags used are always the IPv4 versions, which are
> ignored in the IPv6 code paths. Th
Pali Rohár writes:
> On Thursday 21 January 2016 15:48:14 Kalle Valo wrote:
>> Pali Rohár writes:
>>
>> > On Thursday 14 January 2016 10:16:54 Pavel Machek wrote:
>> >> On Wed 2016-01-13 23:32:47, Arend van Spriel wrote:
>> >> > On 12/26/2015 12:45 PM, Pali Rohár wrote:
>> >> > >Port the bt_coe
On 01/20/2016 10:10 PM, Jεan Sacren wrote:
> From: David Miller
> Date: Tue, 19 Jan 2016 14:36:28 -0500
>>
>> From: Julia Lawall
>> Date: Tue, 19 Jan 2016 19:54:20 +0100 (CET)
>
> [...]
>
>>> I just wondered. I was looking at dependencies between networking files.
>>> This one stands out becau
fix build warnings when CONFIG_VXLAN or CONFIG_GENEVE is not set.
$ make M=drivers/net/ethernet/intel/i40e C=2
CHECK drivers/net/ethernet/intel/i40e/i40e_main.c
CC [M] drivers/net/ethernet/intel/i40e/i40e_main.o
drivers/net/ethernet/intel/i40e/i40e_main.c:8604:13: warning:
'i40e_add_gene
On Thu, 21 Jan 2016 14:49:25 +0200 Or Gerlitz wrote:
> On Thu, Jan 21, 2016 at 1:27 PM, Jesper Dangaard Brouer
> wrote:
> > On Wed, 20 Jan 2016 15:27:38 -0800 Tom Herbert wrote:
> >
> >> eth_type_trans touches headers
> >
> > True, the eth_type_trans() call in the driver is a major bottlen
On Thursday 21 January 2016 15:48:14 Kalle Valo wrote:
> Pali Rohár writes:
>
> > On Thursday 14 January 2016 10:16:54 Pavel Machek wrote:
> >> On Wed 2016-01-13 23:32:47, Arend van Spriel wrote:
> >> > On 12/26/2015 12:45 PM, Pali Rohár wrote:
> >> > >Port the bt_coex_mode sysfs interface from w
Pali Rohár writes:
> On Thursday 14 January 2016 10:16:54 Pavel Machek wrote:
>> On Wed 2016-01-13 23:32:47, Arend van Spriel wrote:
>> > On 12/26/2015 12:45 PM, Pali Rohár wrote:
>> > >Port the bt_coex_mode sysfs interface from wl1251 driver version included
>> > >in the Maemo Fremantle kernel t
Pali Rohár writes:
> Port the bt_coex_mode sysfs interface from wl1251 driver version included
> in the Maemo Fremantle kernel to allow bt-coexistence mode configuration.
> This enables userspace applications to set one of the modes
> WL1251_BT_COEX_OFF, WL1251_BT_COEX_ENABLE and WL1251_BT_COEX_M
On Tue, Jan 19, 2016 at 11:07:20PM -0200, Marcelo Ricardo Leitner wrote:
> On Tue, Jan 19, 2016 at 08:02:30PM -0200, Marcelo Ricardo Leitner wrote:
> > > --- a/net/sctp/proc.c
> > > +++ b/net/sctp/proc.c
> > > @@ -491,6 +491,7 @@ static int sctp_remaddr_seq_show(struct seq_file
> > > *seq, void *v
Hi Yuval,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Yuval-Mintz/qed-qede-use-8-7-3-0-FW/20160121-203046
config: i386-randconfig-s0-201603 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH
On Thu, Jan 21, 2016 at 1:27 PM, Jesper Dangaard Brouer
wrote:
> On Wed, 20 Jan 2016 15:27:38 -0800 Tom Herbert wrote:
>
>> eth_type_trans touches headers
>
> True, the eth_type_trans() call in the driver is a major bottleneck,
> because it touch the packet header and happens very early in the dr
On 01/20/2016 09:59 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 11:32:58PM +0100, Marek Marczykowski-Górecki wrote:
>> On Tue, Dec 01, 2015 at 05:00:42PM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Nov 17, 2015 at 03:45:15AM +0100, Marek Marczykowski-Górecki wrote:
On Wed,
1 - 100 of 117 matches
Mail list logo
