On 7 November 2015 at 13:31, Jay Vosburgh wrote:
>
> Toby Corkindale wrote:
> [...]
> >The thing is, I've been running PPP devices in balance-rr mode for
> >quite a while. It worked fine, and I'd like to continue having that
> >functionality. These changes to the kernel have broken that
> >funct
aarch64 and s390x support eBPF JIT too, correct document to reflect this and
avoid any confusion.
Signed-off-by: Yang Shi
---
Documentation/networking/filter.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/filter.txt
b/Documentation/network
Please ignore this one, forgot to cc to linux-arm-kernel list.
Sorry for the inconvenience.
Yang
On 11/6/2015 9:34 PM, Yang Shi wrote:
ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too. Wh
ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too. Whenever, it pointed to the bottom of BPF prog stack instead of
the top.
So, when copying data via bpf_probe_read, it will be copied to (SP -
ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too. Whenever, it pointed to the bottom of BPF prog stack instead of
the top.
So, when copying data via bpf_probe_read, it will be copied to (SP -
From: SF Markus Elfring
Date: Fri, 6 Nov 2015 08:15:30 +0100
> From: Markus Elfring
> Date: Fri, 6 Nov 2015 08:00:22 +0100
>
> The of_node_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected
From: Iyappan Subramanian
Date: Thu, 5 Nov 2015 21:35:06 -0800
> This patch fixes the RGMII 10/100M mode by reprogramming the clock.
>
> Signed-off-by: Iyappan Subramanian
> Tested-by: Fushen Chen
Why are you targetting a bug fix at net-next? That is inappropriate.
--
To unsubscribe from th
related:
https://bugzilla.kernel.org/show_bug.cgi?id=107421
https://bugzilla.kernel.org/show_bug.cgi?id=104351
4.3.0 smp x86_64
[4.384336] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[4.384747] r8169 :0e:00.0 eth0: RTL8101e at
0xc906, 00:1b:38:b5:9f:d6, XID 9420 I
From: Michal Hocko
Date: Fri, 6 Nov 2015 17:46:57 +0100
> On Fri 06-11-15 11:19:53, Johannes Weiner wrote:
>> You might think sending these emails is helpful, but it really
>> isn't. Not only is it not contributing code, insights, or solutions,
>> you're now actively sabotaging someone else's eff
Toby Corkindale wrote:
[...]
>The thing is, I've been running PPP devices in balance-rr mode for
>quite a while. It worked fine, and I'd like to continue having that
>functionality. These changes to the kernel have broken that
>functionality, by requiring the MAC address support unconditionally.
Richard/Thomas:
On Tue, 13 Oct 2015 06:59:26 -0700, Richard Cochran
wrote:
On Mon, Oct 12, 2015 at 11:45:21AM -0700, Christopher S. Hall wrote:
+struct ptp_sys_offset_precise {
+ unsigned int rsv[4];/* Reserved for future use. */
+ struct ptp_clock_time dev;
+ struct p
On 11/07/2015 02:23 AM, Jay Vosburgh wrote:
> Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
> are not ARPHRD_ETHER, if needed, it resets the bonding device back to
> ARPHRD_ETHER by calling ether_setup.
>
> Unfortunately, ether_setup clobbers dev->flags, clearing I
On 11/06/2015 12:30 PM, Arnd Bergmann wrote:
On Friday 06 November 2015 11:16:52 Guenter Roeck wrote:
On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote:
On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote:
On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote:
Anyway
Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
are not ARPHRD_ETHER, if needed, it resets the bonding device back to
ARPHRD_ETHER by calling ether_setup.
Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
if the bond device is up, leaving it in a q
On Fri, Nov 6, 2015 at 7:27 AM, David Laight wrote:
>> From: Linus Torvalds
>> Sent: 03 November 2015 20:45
>> On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds
>> wrote:
>> > result = add_overflow(
>> > mul_overflow(sec, SEC_CONVERSION, &overflow),
>> > mul_overflow(nsec, NSEC
Repeat the nf_conntrack_in() call when it returns NF_REPEAT. This
avoids dropping a SYN packet re-opening an existing TCP connection.
Signed-off-by: Jarno Rajahalme
---
net/openvswitch/conntrack.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/con
Extend OVS conntrack interface to cover NAT. New nested
OVS_CT_ATTR_NAT attribute may be used to include NAT with a CT action.
A bare OVS_CT_ATTR_NAT only mangles existing and expected connections.
If OVS_NAT_ATTR_SRC or OVS_NAT_ATTR_DST is included within the nested
attributes, new (non-committed
This series adds NAT support to openvswitch kernel module. A few
changes are needed to the netfilter code to facilitate this (patches
1-3/8). Patches 4-7 make the openvswitch kernel module ready for the
patch 8 that adds the NAT support for calling into netfilter NAT code
from the openvswitch con
Remove the definition of IP_CT_NEW_REPLY from the kernel as it does
not make sense. This allows the definition of IP_CT_NUMBER to be
simplified as well.
Signed-off-by: Jarno Rajahalme
---
include/uapi/linux/netfilter/nf_conntrack_common.h | 12 +---
net/openvswitch/conntrack.c
There is no need to help connections that are not confirmed, so we can
delay helping new connections to the time when they are confirmed.
This change is needed for NAT support, and having this as a separate
patch will make the following NAT patch a bit easier to review.
Signed-off-by: Jarno Rajaha
NAT checksum recalculation code assumes existence of skb_dst, which
becomes a problem for a later patch in the series ("openvswitch:
Interface with NAT."). Simplify this by removing the check on
skb_dst, as the checksum will be dealt with later in the stack.
Suggested-by: Pravin Shelar
Signed-of
Add a new function ovs_ct_find_existing() to find an existing
conntrack entry for which this packet was already applied to. This is
only to be called when there is evidence that the packet was already
tracked and committed, but we lost the ct reference due to an
userspace upcall.
ovs_ct_find_exis
Only a successful nf_conntrack_in() call can effect a connection state
change, so if suffices to update the key only after the
nf_conntrack_in() returns.
This change is needed for the later NAT patches.
Signed-off-by: Jarno Rajahalme
---
net/openvswitch/conntrack.c | 9 ++---
1 file changed
Define a new inline function to map conntrack status to enum
ip_conntrack_info. This removes the need to otherwise duplicate this
code in a later patch ("openvswitch: Find existing conntrack entry
after upcall.").
Signed-off-by: Jarno Rajahalme
---
include/net/netfilter/nf_conntrack.h | 15
Hello,
On Fri, 6 Nov 2015, Neil Horman wrote:
> The solution is to recognize that its pointless to promote an address to be a
> new primary, if there is a possibility that it will just be removed in the
> near
> future. As such this patch peeks ahead to the next request in the provided
Toby Corkindale wrote:
>I originally reported this in Dec 2014, as:
>https://bugzilla.kernel.org/show_bug.cgi?id=89161
>
>The bug is still present in the 4.2 Linux kernel.
I had some time to look into this today, and there is a related
code path that panics the kernel, so I'm working on
On 11/6/15 2:18 PM, Simon Xiao wrote:
The .config file used to build linux-next kernel is attached to this mail.
Thanks.
Failed to notice this on the first response; my brain filled in. Why
linux-next tree? Can you try net-next which is more relevant for this
mailing list, post the top commi
Hi Eric,
does this resolve the issues you're having on the TX_RING when dealing
with trafgen [1]?
Thanks a lot,
Daniel
[1] http://thread.gmane.org/gmane.linux.network/385988
Daniel Borkmann (2):
packet: do skb_probe_transport_header when we actually have data
packet: fix tpacket_snd max f
There seem to be a couple of issues in tpacket_snd() path. Since it's
introduction in commit 69e3c75f4d54 ("net: TX_RING and packet mmap"),
TX_RING could be used from SOCK_DGRAM and SOCK_RAW side. When used
with SOCK_DGRAM only, the size_max > dev->mtu + reserve check should
have reserve as 0, but
In tpacket_fill_skb() commit c1aad275b029 ("packet: set transport
header before doing xmit") and later on 40893fd0fd4e ("net: switch
to use skb_probe_transport_header()") was probing for a transport
header on the skb from a ring buffer slot, but at a time, where
the skb has _not even_ been filled w
Hi Marcin,
[...]
>> +static int mvneta_config_rss(struct mvneta_port *pp)
>> +{
>> + int cpu;
>> + u32 val;
>> +
>> + netif_tx_stop_all_queues(pp->dev);
>> +
>> + /* Mask all ethernet port interrupts */
>> + mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
>
> Shouldn't t
On 11/6/15 1:31 PM, Simon Xiao wrote:
I compared the network throughput performance on SLES12 bare metal servers,
between SLES12 default kernel and latest linux-next (2015-11-05) kernel, based
on the test results, I suspect there is a network regression exists on
Linux-Next over the 40G Ethern
I compared the network throughput performance on SLES12 bare metal servers,
between SLES12 default kernel and latest linux-next (2015-11-05) kernel, based
on the test results, I suspect there is a network regression exists on
Linux-Next over the 40G Ethernet network:
a) iperf3 reports 50% perfor
On Friday 06 November 2015 11:16:52 Guenter Roeck wrote:
> On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote:
> > On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote:
> > > > Anyway, if it gets that complicated,
On Fri, Nov 06, 2015 at 03:07:30PM +, David Laight wrote:
> > Oh, _lovely_. So instead of continuation of that write(2) going down
> > the throat of something opened by unrelated thread, it (starting from a
> > pretty arbitrary point) will go into the descriptor the closing thread
> > passed
I recently got a report that, after a user added 40,000 addresses to an
interface and ran ip addr flush , their system blocked on interface access
for literally hours, and issued hundreds of hung task warnings. due to rtnl
being held during this operation.
While its certainly arguable that long de
Hi Gregory,
> I also choose to associate all the TX queues on the same CPU that the
> one associated to the RX queue. It allows to contain all the
> interrupts on the same CPU. I think that an improvement on this side
> would be the support of the XPS.
>
Did you make some tries? E.g. after mappi
With x86_64_defconfig:
GCC thinks that in nfulnl_recv_config flags parameter is not inited but
it was under the same condition (nfula[NFULA_CFG_FLAGS] == true).
Suppress this warning:
net/netfilter/nfnetlink_log.c: In function ‘nfulnl_recv_config’:
net/netfilter/nfnetlink_log.c:320:
On Fri, 2015-11-06 at 20:14 +0100, ronny.hegew...@online.de wrote:
> I think the checksum-building is not broken because of this on itself. The
> problem i see is for example in case pages are sent from a block-device
> over the net.
>
> Depending on the block-device this pages might be changed
Arnd,
On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote:
> On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote:
> > On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote:
> > > >
> > > > Something like this?
> > > >
> > > > static inline u64 of_translate_address(struct de
Hi Gregory,
2015-11-06 19:35 GMT+01:00 Gregory CLEMENT :
> This patch add the support for the RSS related ethtool
> function. Currently it only use one entry in the indirection table which
> allows associating an mveneta interface to a given CPU.
>
> Signed-off-by: Gregory CLEMENT
> ---
> driver
> Well, looking at the code I don't readily see how this works either,
> but note that tcp_sendmsg has the same check also. If your analysis is
> correct then checksum for IPv6 would commonly be broken (i.e. several
> devices support IPv4 checksum but not IPv6)-- so I find that hard to
> believe so
I thought, it was decided to use 0/NULL/whatever, than uninitialized_var()?
Is right now?
http://thread.gmane.org/gmane.linux.kernel/1383415
2015-11-06 22:10 GMT+03:00 Pablo Neira Ayuso :
> On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote:
>> With x86_64_defconfig:
>> GCC thinks that
Pablo Neira Ayuso wrote:
> On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote:
> > With x86_64_defconfig:
> > GCC thinks that in nfulnl_recv_config flags parameter is not inited but
> > it was under the same condition (nfula[NFULA_CFG_FLAGS] == true).
> > Suppress this warning:
> >
On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote:
> With x86_64_defconfig:
> GCC thinks that in nfulnl_recv_config flags parameter is not inited but
> it was under the same condition (nfula[NFULA_CFG_FLAGS] == true).
> Suppress this warning:
> net/netfilter/nfnetlink_log.c: In f
With x86_64_defconfig:
GCC thinks that in nfulnl_recv_config flags parameter is not inited but
it was under the same condition (nfula[NFULA_CFG_FLAGS] == true).
Suppress this warning:
net/netfilter/nfnetlink_log.c: In function ‘nfulnl_recv_config’:
net/netfilter/nfnetlink_log.c:320:
Hi
I have several pppoe servers running under older kernels, and upgraded
two of them to 4.3.0
After that, one of them randomly rebooting and stacktrace always
different. Also i noticed message appearing, that didnt exist before on
older kernels, appearing on both now:
"neighbour: arp_cache:
This patch add the support for the RSS related ethtool
function. Currently it only use one entry in the indirection table which
allows associating an mveneta interface to a given CPU.
Signed-off-by: Gregory CLEMENT
---
drivers/net/ethernet/marvell/mvneta.c | 114 +
Hi,
this series is a first attempt to add RSS support on mvneta.
this series will allow associating an ethernet interface to a given
CPU through RSS by using "ethtool -X ethX weight". Indeed, currently I
only enable one entry in the RSS lookup table. Even if it is not
really RSS, it allows to get
We enable the percpu interrupt for all the CPU and we just associate a
CPU to a few queue at the neta level. The mapping between the CPUs and
the queues is static. The queues are associated to the CPU module the
number of CPUs. However currently we only use on RX queue for a given
Ethernet port.
S
On Fri, 2015-11-06 at 14:57 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/6/2015 12:25 AM, Michael Chan wrote:
>
> > Assign the return value from bitmap_find_free_region() to an integer
> > variable and check for negative error codes first, before assigning
> > the bit ID to the unsigned sw_i
- Drop 'extern' keyword from all function prototypes.
- Make line breaking of print_* functions consistent.
- Make print_ntable() and ipntable_reset_filter() static and remove
their declaration.
- Drop declaration of non-existent ipaddr_list() and iproute_monitor().
Signed-off-by: Phil Sutter
-
On Fri, Nov 06, 2015 at 05:46:57PM +0100, Michal Hocko wrote:
> The basic problem was that the Delegate feature has been backported to
> our systemd package without further consideration and that has
> invalidated a lot of performance testing because some resource
> controllers have measurable effe
On Friday 06 November 2015 09:32:46 Greg KH wrote:
> On Thu, Nov 05, 2015 at 11:18:37AM +0100, Patrick Schaaf wrote:
> > bnx2x: Don't notify about scratchpad parities
> >
> > This is a (trivial) "backport" of ad6afbe9578d1fa26680faf78c846bd8c00d1d6e
> > to stable kernel 3.14.56.
>
> This patch is
On Thu, Nov 05, 2015 at 11:18:37AM +0100, Patrick Schaaf wrote:
> bnx2x: Don't notify about scratchpad parities
>
> This is a (trivial) "backport" of ad6afbe9578d1fa26680faf78c846bd8c00d1d6e to
> stable kernel 3.14.56.
This patch isn't in 4.1 either, do you want it there as well?
thanks,
greg
On Fri 06-11-15 11:19:53, Johannes Weiner wrote:
> On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote:
> > On Thu 05-11-15 17:52:00, Johannes Weiner wrote:
> > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote:
> > > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko
On Fri, Nov 06, 2015 at 12:05:55PM +0300, Vladimir Davydov wrote:
> On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote:
> > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote:
> ...
> > > 3) keep only some (safe) cache types enabled by default with the current
> > >failin
Hi,
We recently faced the issue described in the patch below on 3.14.56. This fix
was merged in 4.2-rc7. I checked Davem's queue and stable queue and it's not
there yet. Could we please have it in 3.12 and above ? (feature was introduced
in 3.11). I can confirm that it properly fixes the problem f
Jarod Wilson wrote:
The bonding driver saves a copy of slaves' original mac address and then
assigns whatever mac as needed to the slave, depending on mode. In at
least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
mac address of another slave. On release from the bond, the
On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote:
> On Thu 05-11-15 17:52:00, Johannes Weiner wrote:
> > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote:
> > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote:
> > > > This would be true if they moved on to th
On Fri, 2015-11-06 at 13:58 +0100, Dmitry Vyukov wrote:
> Hello,
>
> I am on revision d1e41ff11941784f469f17795a4d9425c2eb4b7a (Nov 5) and
> seeing the following lockdep reports. I don't have exact reproducer
> program as it is caused by several independent programs (state
> accumulated in kernel
> From: Linus Torvalds
> Sent: 03 November 2015 20:45
> On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds
> wrote:
> > result = add_overflow(
> > mul_overflow(sec, SEC_CONVERSION, &overflow),
> > mul_overflow(nsec, NSEC_CONVERSION, &overflow),
> > &overflow);
> >
> >
Jason Baron writes:
> On 11/06/2015 08:06 AM, Dmitry Vyukov wrote:
>> On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote:
>>> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet
>>> wrote:
On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
> Probably the issue discussed in
>
From: Al Viro
> Sent: 04 November 2015 16:28
> On Wed, Nov 04, 2015 at 03:54:09PM +, David Laight wrote:
> > > Sigh... The kernel has no idea when other threads are done with "all
> > > io activities using that fd" - it can wait for them to leave the
> > > kernel mode, but there's fuck-all it
On 11/06/2015 08:06 AM, Dmitry Vyukov wrote:
> On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote:
>> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote:
>>> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
>>>
Probably the issue discussed in
http://thread.gmane.org/gm
On Fri, 2015-11-06 at 14:52 +0100, Dmitry Vyukov wrote:
> Fixed the issue for me.
Thanks Dmitry
I'll submit ~6 additional patches, after doing a long due audit.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More major
The bonding driver saves a copy of slaves' original mac address and then
assigns whatever mac as needed to the slave, depending on mode. In at
least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
mac address of another slave. On release from the bond, the original mac
address
On Wed, Nov 4, 2015 at 12:03 AM, Helge Deller wrote:
>> Also, just looking at other things, we currently do have openrisc that has
>>
>> #define L1_CACHE_BYTES 16
>>
>> so presumably openrisc would have had an issue with that XPS thing,
>
> and mn10300.
And several other architectures that defi
On Thu, Nov 5, 2015 at 10:46 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Thu, 05 Nov 2015 13:39:24 -0800
>
>> From: Eric Dumazet
>>
>> In commit e446f9dfe17b ("net: synack packets can be attached to request
>> sockets"), I missed one remaining case of invalid skb->sk->sk_security
>> acc
On Fri 06-11-15 12:05:55, Vladimir Davydov wrote:
[...]
> If there are no objections, I'll prepare a patch switching to the
> white-list approach. Let's start from obvious things like fs_struct,
> mm_struct, task_struct, signal_struct, dentry, inode, which can be
> easily allocated from user space.
On Thu 05-11-15 15:55:22, Johannes Weiner wrote:
> On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote:
> > On Wed 04-11-15 14:50:37, Johannes Weiner wrote:
[...]
> > This would be true if they moved on to the new cgroup API intentionally.
> > The reality is more complicated though. AFAIK
On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote:
> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote:
>> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
>>
>>> Probably the issue discussed in
>>>
>>> http://thread.gmane.org/gmane.linux.kernel/2057497/
>>>
>>> and previous relate
Hello,
I am on revision d1e41ff11941784f469f17795a4d9425c2eb4b7a (Nov 5) and
seeing the following lockdep reports. I don't have exact reproducer
program as it is caused by several independent programs (state
accumulated in kernel across invocations); if the report is not enough
I can try to cook a
On Thu 05-11-15 17:32:51, Johannes Weiner wrote:
> On Thu, Nov 05, 2015 at 05:28:03PM +0100, Michal Hocko wrote:
[...]
> > Yes, that part is clear and Johannes made it clear that the kmem tcp
> > part is disabled by default. Or are you considering also all the slab
> > usage by the networking code
My Name is Mrs Jessica Peterside from United Kingdom who is suffering from
cancer of the lungs
and I wish to use my fund to serve the poor in your country since I have
limited time on earth
Regards Mrs Jessica Peterside
reply for more details on this Email:mrsjessicapetersid...@gmail.com
--
To
Hello.
On 11/6/2015 12:25 AM, Michael Chan wrote:
Assign the return value from bitmap_find_free_region() to an integer
variable and check for negative error codes first, before assigning
the bit ID to the unsigned sw_id field.
Reported-by: Dan Carpenter
Cc: Dan Carpenter
Signed-off-by: Micha
+1
I like this more since it is much more obvious what is done.
more over we can remove a macro with only 2 users.
re,
wh
Am 06.11.2015 11:57, schrieb Julia Lawall:
>>> Would it be preferable to remove the macro entirely and inline the for
>>> loop header?
>>
>> Could you show me an example o
On Fri, 6 Nov 2015, walter harms wrote:
> +1
>
> I like this more since it is much more obvious what is done.
>
> more over we can remove a macro with only 2 users.
It's not to bad because it turns out to be pretty concise. But I don't
agree about the 2 users. There are 2 users for this speci
Hi Tom,
On Fri, Nov 6, 2015 at 8:19 AM, Tom Herbert wrote:
> Is this about UFO or GSO (in email subject)? UFO should operate
> independently encapsulation or inner packet setting.
I suppose this is about UFO.
Specifically -- let's say I have a list of 500 skbs, which have their
data in place bu
On Fri, Nov 6, 2015 at 5:58 AM, Herbert Xu wrote:
> I don't see anything fundamentally wrong with your idea. After
> all what you're describing is the basis of GSO, i.e., letting
> data stay in the form of super-packets for as long as we can.
>
> Of course there's going to be a lot of niggly bits
On 11/05/2015 11:56 PM, Daniel Borkmann wrote:
On 11/05/2015 05:17 PM, Eric Dumazet wrote:
On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote:
On 11/05/2015 12:38 PM, Eric Dumazet wrote:
If I am not mistaken, af_packet also lacks the ability to properly set
skb->protocol
I noticed thi
net/nfc/nci/hci.c: In function ‘nci_hci_connect_gate’:
net/nfc/nci/hci.c:679: warning: comparison is always false due to limited range
of data type
In case of error, nci_hci_create_pipe() returns NCI_HCI_INVALID_PIPE,
and not a negative error code.
Correct the check to fix this.
Signed-off-by:
On Wed, Nov 04, 2015 at 03:46:54PM -0800, Ani Sinha wrote:
> (removed a bunch of people from CC list)
>
> On Mon, Oct 26, 2015 at 1:06 PM, Pablo Neira Ayuso
> wrote:
>
> > Then we can review and, if no major concerns, I can submit this to
> > -stable.
>
> Now that Neal has sufficiently tested
> > Would it be preferable to remove the macro entirely and inline the for
> > loop header?
>
> Could you show me an example of how this would look exactly?
One possible solution is below. I moved the initialization of the nh
pointer inside the loop to reduce the size of the loop header. One cou
On Thu 05-11-15 17:52:00, Johannes Weiner wrote:
> On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote:
> > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote:
> > > This would be true if they moved on to the new cgroup API intentionally.
> > > The reality is more complicated
On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote:
> On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote:
...
> > 3) keep only some (safe) cache types enabled by default with the current
> >failing semantic and require an explicit enabling for the complete
> >kmem acc
From: Markus Elfring
Date: Fri, 6 Nov 2015 09:30:29 +0100
The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/net/fjes/fjes_hw.c | 4 +---
On Fri, Nov 6, 2015 at 6:34 AM, ronny.hegew...@online.de
wrote:
> While reading through net-code i came across some code in tcp_sendpage which
> i think
> it is not working in the intended way all tie time. But as this code is at
> that a
> central place and pretty old, im suspicious if my analy
88 matches
Mail list logo
