From: Alexander Duyck
Date: Sat, 30 Jan 2016 17:13:35 -0800
> The NIC hardware only allows us to set receive buffer sizes in 1K
> increments. I think fm10k may be an exception in that it may be able
> to support 512 byte, but otherwise igb and ixgbe are strictly set in
> 1K increments. So basic
On 2016/1/31 5:30, Florian Westphal wrote:
> Weidong Wang wrote:
>> In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
>> so remove the check
>> @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct
>> nf_conn *i, void *data),
>> lockp = &nf_conntra
On Sat, Jan 30, 2016 at 11:26 AM, Eric Dumazet wrote:
> On Sat, 2016-01-30 at 10:36 -0800, Alexander Duyck wrote:
>
>> As far as the NET_IP_ALIGN on the page offset I think it is a horrible
>> idea. Basically it means we have to allocate at least 1K more space
>> than we need since page sizes are
From: Johan Hedberg
Date: Sat, 30 Jan 2016 18:25:18 +0200
> Here's a set of important Bluetooth fixes for the 4.5 kernel:
>
> - Two fixes to 6LoWPAN code (one fixing a potential crash)
> - Fix LE pairing with devices using both public and random addresses
> - Fix allocation of dynamic LE PSM
From: Jarod Wilson
Date: Sat, 30 Jan 2016 15:53:05 -0500
> On Sat, Jan 30, 2016 at 03:39:01PM -0500, Jarod Wilson wrote:
>> Ew, no, it won't work correctly on 32-bit. The for loop is going to copy
>> data into dst from beyond the end of netdev_stats, and the range looks
>> like it won't be right
On Fri, Jan 29, 2016 at 2:38 PM, Timur Tabi wrote:
> Rob Herring wrote:
[...]
Isn't this a user enabled feature if the h/w supports it?
>>>
>>>
>>>
>>> Is there a sysfs entry for that? We were planning on having a similar
>>> ACPI
>>> property.
>>
>>
>> It would be in ethtool I think.
>
>
Weidong Wang wrote:
> In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
> so remove the check
> @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct
> nf_conn *i, void *data),
> lockp = &nf_conntrack_locks[*bucket % CONNTRACK_LOCKS];
>
On Sat, Jan 30, 2016 at 03:39:01PM -0500, Jarod Wilson wrote:
> On Sat, Jan 30, 2016 at 10:34:32AM -0800, Eric Dumazet wrote:
> > On Sat, 2016-01-30 at 13:19 -0500, Jarod Wilson wrote:
> > > The netdev_stats_to_stats64 function copies the deprecated
> > > net_device_stats format stats into rtnl_lin
On Sat, Jan 30, 2016 at 10:34:32AM -0800, Eric Dumazet wrote:
> On Sat, 2016-01-30 at 13:19 -0500, Jarod Wilson wrote:
> > The netdev_stats_to_stats64 function copies the deprecated
> > net_device_stats format stats into rtnl_link_stats64 for legacy support
> > purposes, but with the BUILD_BUG_ON a
On Sat, 2016-01-30 at 10:36 -0800, Alexander Duyck wrote:
> As far as the NET_IP_ALIGN on the page offset I think it is a horrible
> idea. Basically it means we have to allocate at least 1K more space
> than we need since page sizes are powers of 2, and buffer sizes in
> hardware are measured in
On (01/30/16 09:43), Tom Herbert wrote:
> That is not the only case, If a GRE TEB packet is ever received and
> flow dissector is called for any reason (like skb_get_hash) there's
> going to be problems-- and this doesn't require GRE to even be
> configured on the host.
>
> I have a patch that cha
On Sat, Jan 30, 2016 at 4:26 PM, Joe Perches wrote:
> On Sat, 2016-01-30 at 09:51 -0800, Eric Dumazet wrote:
>> On Sat, 2016-01-30 at 12:05 -0200, Lucas Tanure wrote:
>> > On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy wrote:
>> > > On 30.01, Lucas Tanure wrote:
>> > > > As suggested by checkp
On Sat, Jan 30, 2016 at 8:17 AM, Sowmini Varadhan
wrote:
> On (01/29/16 19:23), Eric Dumazet wrote:
>> BTW, even a memcpy(&key_addrs->v4addrs, &iph->saddr, 8) could crash, as
>> the compiler can certainly assume src and dst are 4 bytes aligned, and
>> could use word accesses when inlining memcpy()
On Sat, 2016-01-30 at 13:19 -0500, Jarod Wilson wrote:
> The netdev_stats_to_stats64 function copies the deprecated
> net_device_stats format stats into rtnl_link_stats64 for legacy support
> purposes, but with the BUILD_BUG_ON as it was, it wasn't possible to
> extend rtnl_link_stats64 without als
On Sat, 2016-01-30 at 09:51 -0800, Eric Dumazet wrote:
> On Sat, 2016-01-30 at 12:05 -0200, Lucas Tanure wrote:
> > On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy wrote:
> > > On 30.01, Lucas Tanure wrote:
> > > > As suggested by checkpatch.pl:
> > > > CHECK: Prefer kernel type 'uX' over 'uintX
The netdev_stats_to_stats64 function copies the deprecated
net_device_stats format stats into rtnl_link_stats64 for legacy support
purposes, but with the BUILD_BUG_ON as it was, it wasn't possible to
extend rtnl_link_stats64 without also extending net_device_stats. Relax
the BUILD_BUG_ON to only re
On Fri, Jan 29, 2016 at 07:37:51PM -0800, David Miller wrote:
> From: Jarod Wilson
> Date: Thu, 28 Jan 2016 10:49:44 -0500
>
> > The network core tries to keep track of dropped packets, but some packets
> > you wouldn't really call dropped, so much as intentionally ignored, under
> > certain circ
Be informed that Muthoot Finance give out Guarantee Business Loans, Automobile
Purchase Loans, House Purchase Loans, Personal Loans at 3% interest rate, for
more info email: muthootfinancceh...@gmail.com
Estar informado de que Muthoot Finanzas Dar a conocer Garanta de negocios
Prstamos, Prs
On Sat, 2016-01-30 at 12:05 -0200, Lucas Tanure wrote:
> On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy wrote:
> > On 30.01, Lucas Tanure wrote:
> >> As suggested by checkpatch.pl:
> >> CHECK: Prefer kernel type 'uX' over 'uintX_t'
> >
> > You might have noticed we have literally hundreds of th
On Sat, Jan 30, 2016 at 8:17 AM, Sowmini Varadhan
wrote:
> On (01/29/16 19:23), Eric Dumazet wrote:
>> BTW, even a memcpy(&key_addrs->v4addrs, &iph->saddr, 8) could crash, as
>> the compiler can certainly assume src and dst are 4 bytes aligned, and
>> could use word accesses when inlining memcpy()
On Sat, 2016-01-30 at 12:05 -0200, Lucas Tanure wrote:
> On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy wrote:
> > On 30.01, Lucas Tanure wrote:
> > > As suggested by checkpatch.pl:
> > > CHECK: Prefer kernel type 'uX' over 'uintX_t'
> >
> > You might have noticed we have literally hundreds of
Thanks for pointing this out!
At a first look I'd propose to merge the two identical
pci_fee_consistent() in a single one, and place it in an error exit
path at the end of function.
BTW, looking at the code, it seems there is another leak here that
your patch does not address: we still leaks allo
Patch makes safe an access to 'oiph' and 'oudph' variables
if they was not initilized.
Signed-off-by: Vasily Averin
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
b/drivers/net/eth
Hi Dave,
Here's a set of important Bluetooth fixes for the 4.5 kernel:
- Two fixes to 6LoWPAN code (one fixing a potential crash)
- Fix LE pairing with devices using both public and random addresses
- Fix allocation of dynamic LE PSM values
- Fix missing COMPATIBLE_IOCTL for UART line discipl
Acked-by: Andrea Merello
On Sat, Jan 16, 2016 at 2:02 PM, Jia-Ju Bai wrote:
> When pci_request_regions in rtl8180_probe fails, pci_disable_device is not
> called to disable the device which is enabled by pci_enbale_device.
>
> This patch fixes the problem by adding a new lable in error handling
On (01/29/16 19:23), Eric Dumazet wrote:
> BTW, even a memcpy(&key_addrs->v4addrs, &iph->saddr, 8) could crash, as
> the compiler can certainly assume src and dst are 4 bytes aligned, and
> could use word accesses when inlining memcpy() even on Sparc.
>
> Apparently the compiler used by Sowmini is
On 26.01.2016 02:58, Jeff Kirsher wrote:
> From: Arnd Bergmann
>
> intel/i40e/i40e_txrx.c: In function 'i40e_xmit_frame_ring':
> intel/i40e/i40e_txrx.c:2367:20: error: 'oiph' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> intel/i40e/i40e_txrx.c:2317:16: note: 'oiph'
On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy wrote:
> On 30.01, Lucas Tanure wrote:
>> As suggested by checkpatch.pl:
>> CHECK: Prefer kernel type 'uX' over 'uintX_t'
>
> You might have noticed we have literally hundreds of them spread over 100
> files in the netfilter code. We'll gradually c
On 30.01, Lucas Tanure wrote:
> As suggested by checkpatch.pl:
> CHECK: Prefer kernel type 'uX' over 'uintX_t'
You might have noticed we have literally hundreds of them spread over 100
files in the netfilter code. We'll gradually change them when the code is
touched anyways.
> net/ipv4/netfilter
change made to resolve following checkpatch message:
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
Signed-off-by: Lucas Tanure
---
net/ipv4/netfilter/ip_tables.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/netfilter/ip_table
Fix checkpatch warning
WARNING: Use #include instead of
Signed-off-by: Lucas Tanure
---
net/ipv4/netfilter/ip_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index b99affa..aa0e41e 100644
--- a/net/ipv
Fix the checkpatch.pl issues:
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: spaces preferred around that '<<' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
Signed-off-by: Lucas Tanure
---
net/ipv4/netfilter/ip_tables.c |
As suggested by checkpatch.pl:
CHECK: Prefer kernel type 'uX' over 'uintX_t'
Signed-off-by: Lucas Tanure
---
net/ipv4/netfilter/ip_tables.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index 79d4a04..dcc6
In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
so remove the check
Signed-off-by: Weidong Wang
---
net/netfilter/nf_conntrack_core.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack
On 01/30/2016 07:59 AM, David Miller wrote:
> From: Nikolay Aleksandrov
> Date: Fri, 29 Jan 2016 22:48:26 +0100
>
>> On 01/29/2016 10:45 PM, Jay Vosburgh wrote:
>>> Nikolay Aleksandrov wrote:
>>>
On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
> As subject says, 802.3ad bonding is not worki
Sat, Jan 30, 2016 at 07:59:24AM CET, da...@davemloft.net wrote:
>From: Nikolay Aleksandrov
>Date: Fri, 29 Jan 2016 22:48:26 +0100
>
>> On 01/29/2016 10:45 PM, Jay Vosburgh wrote:
>>> Nikolay Aleksandrov wrote:
>>>
On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
> As subject says, 802.3ad bo
On 30 January 2016 at 08:03, David Miller wrote:
> From: Rafał Miłecki
> Date: Sat, 30 Jan 2016 00:41:07 +0100
>
>> Chipsets with BCM4707 / BCM53018 ID require special handling at a few
>> places in the code. It's likely there will be more IDs to check in the
>> future. To simplify it add this tr
37 matches
Mail list logo
