[PATCH nf] netfilter: nf_nat: range size must be at least 1

2018-02-12 Thread Florian Westphal 
 divide error:  [#1] SMP KASAN
 RIP: 0010:nf_nat_l4proto_unique_tuple+0x291/0x530
 net/netfilter/nf_nat_proto_common.c:88

looks like a day 0 bug.
Avoid this by forcing a min_range of 1.

Reported-by: 
Signed-off-by: Florian Westphal 
---
 net/netfilter/nf_nat_proto_common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nf_nat_proto_common.c 
b/net/netfilter/nf_nat_proto_common.c
index fbce552a796e..2d1fc3722ed2 100644
--- a/net/netfilter/nf_nat_proto_common.c
+++ b/net/netfilter/nf_nat_proto_common.c
@@ -72,6 +72,8 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto 
*l3proto,
} else {
min = ntohs(range->min_proto.all);
range_size = ntohs(range->max_proto.all) - min + 1;
+   if (range_size == 0)
+   range_size = 1;
}
 
if (range->flags & NF_NAT_RANGE_PROTO_RANDOM) {
-- 
2.13.6

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v2] netfilter: x_tables: fix missing timer initialization in xt_LED

2018-02-12 Thread Paolo Abeni 
syzbot reported that xt_LED may try to use the ledinternal->timer
without previously initializing it:

[ cut here ]
kernel BUG at kernel/time/timer.c:958!
invalid opcode:  [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 1826 Comm: kworker/1:2 Not tainted 4.15.0+ #306
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:__mod_timer kernel/time/timer.c:958 [inline]
RIP: 0010:mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102
RSP: 0018:8801d24fe9f8 EFLAGS: 00010293
RAX: 8801d25246c0 RBX: 8801aec6cb50 RCX: 816052c6
RDX:  RSI: fffbd14b RDI: 8801aec6cb68
RBP: 8801d24fec98 R08:  R09: 11003a49fd6c
R10: 8801d24feb28 R11: 0005 R12: dc00
R13: 8801d24fec70 R14: fffbd14b R15: 8801af608f90
FS:  () GS:8801db50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 206d6fd0 CR3: 06a22001 CR4: 001606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  led_tg+0x1db/0x2e0 net/netfilter/xt_LED.c:75
  ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
  ip6table_raw_hook+0x65/0x80 net/ipv6/netfilter/ip6table_raw.c:42
  nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
  nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
  nf_hook.constprop.27+0x3f6/0x830 include/linux/netfilter.h:243
  NF_HOOK include/linux/netfilter.h:286 [inline]
  ndisc_send_skb+0xa51/0x1370 net/ipv6/ndisc.c:491
  ndisc_send_ns+0x38a/0x870 net/ipv6/ndisc.c:633
  addrconf_dad_work+0xb9e/0x1320 net/ipv6/addrconf.c:4008
  process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
  kthread+0x33c/0x400 kernel/kthread.c:238
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
Code: 85 2a 0b 00 00 4d 8b 3c 24 4d 85 ff 75 9f 4c 8b bd 60 fd ff ff e8 bb
57 10 00 65 ff 0d 94 9a a1 7e e9 d9 fc ff ff e8 aa 57 10 00 <0f> 0b e8 a3
57 10 00 e9 14 fb ff ff e8 99 57 10 00 4c 89 bd 70
RIP: __mod_timer kernel/time/timer.c:958 [inline] RSP: 8801d24fe9f8
RIP: mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102 RSP: 8801d24fe9f8
---[ end trace f661ab06f5dd8b3d ]---

The ledinternal struct can be shared between several different
xt_LED targets, but the related timer is currently initialized only
if the first target requires it. Fix it by unconditionally
initializing the timer struct.

v1 -> v2: call del_timer_sync() unconditionally, too.

Fixes: 268cb38e1802 ("netfilter: x_tables: add LED trigger target")
Reported-by: syzbot+10c98dc5725c6c8fc...@syzkaller.appspotmail.com
Signed-off-by: Paolo Abeni 
---
 net/netfilter/xt_LED.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/xt_LED.c b/net/netfilter/xt_LED.c
index 1dcad893df78..0fb2133165aa 100644
--- a/net/netfilter/xt_LED.c
+++ b/net/netfilter/xt_LED.c
@@ -142,9 +142,10 @@ static int led_tg_check(const struct xt_tgchk_param *par)
goto exit_alloc;
}
 
-   /* See if we need to set up a timer */
-   if (ledinfo->delay > 0)
-   timer_setup(>timer, led_timeout_callback, 0);
+   /* Since the letinternal timer can be shared between multiple targets,
+* always set it up, even if the current target does not need it
+*/
+   timer_setup(>timer, led_timeout_callback, 0);
 
list_add_tail(>list, _led_triggers);
 
@@ -181,8 +182,7 @@ static void led_tg_destroy(const struct xt_tgdtor_param 
*par)
 
list_del(>list);
 
-   if (ledinfo->delay > 0)
-   del_timer_sync(>timer);
+   del_timer_sync(>timer);
 
led_trigger_unregister(>netfilter_led_trigger);
 
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] netfilter: x_tables: fix missing timer initialization in xt_LED

2018-02-12 Thread Dmitry Vyukov 
On Mon, Feb 12, 2018 at 6:17 PM, Paolo Abeni  wrote:
> syzbot reported that xt_LED may try to use the ledinternal->timer
> without previously initializing it:
>
> [ cut here ]
> kernel BUG at kernel/time/timer.c:958!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 1826 Comm: kworker/1:2 Not tainted 4.15.0+ #306
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: ipv6_addrconf addrconf_dad_work
> RIP: 0010:__mod_timer kernel/time/timer.c:958 [inline]
> RIP: 0010:mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102
> RSP: 0018:8801d24fe9f8 EFLAGS: 00010293
> RAX: 8801d25246c0 RBX: 8801aec6cb50 RCX: 816052c6
> RDX:  RSI: fffbd14b RDI: 8801aec6cb68
> RBP: 8801d24fec98 R08:  R09: 11003a49fd6c
> R10: 8801d24feb28 R11: 0005 R12: dc00
> R13: 8801d24fec70 R14: fffbd14b R15: 8801af608f90
> FS:  () GS:8801db50() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 206d6fd0 CR3: 06a22001 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>   led_tg+0x1db/0x2e0 net/netfilter/xt_LED.c:75
>   ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
>   ip6table_raw_hook+0x65/0x80 net/ipv6/netfilter/ip6table_raw.c:42
>   nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
>   nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
>   nf_hook.constprop.27+0x3f6/0x830 include/linux/netfilter.h:243
>   NF_HOOK include/linux/netfilter.h:286 [inline]
>   ndisc_send_skb+0xa51/0x1370 net/ipv6/ndisc.c:491
>   ndisc_send_ns+0x38a/0x870 net/ipv6/ndisc.c:633
>   addrconf_dad_work+0xb9e/0x1320 net/ipv6/addrconf.c:4008
>   process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
>   worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>   kthread+0x33c/0x400 kernel/kthread.c:238
>   ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
> Code: 85 2a 0b 00 00 4d 8b 3c 24 4d 85 ff 75 9f 4c 8b bd 60 fd ff ff e8 bb
> 57 10 00 65 ff 0d 94 9a a1 7e e9 d9 fc ff ff e8 aa 57 10 00 <0f> 0b e8 a3
> 57 10 00 e9 14 fb ff ff e8 99 57 10 00 4c 89 bd 70
> RIP: __mod_timer kernel/time/timer.c:958 [inline] RSP: 8801d24fe9f8
> RIP: mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102 RSP: 8801d24fe9f8
> ---[ end trace f661ab06f5dd8b3d ]---
>
> The ledinternal struct can be shared between several different
> xt_LED targets, but the related timer is currently initialized only
> if the first target requires it. Fix it by unconditionally
> initializing the timer struct.
>
> Fixes: 268cb38e1802 ("netfilter: x_tables: add LED trigger target")
> Reported-by: syzbot+10c98dc5725c6c8fc...@syzkaller.appspotmail.com
> Signed-off-by: Paolo Abeni 
> ---
>  net/netfilter/xt_LED.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/netfilter/xt_LED.c b/net/netfilter/xt_LED.c
> index 1dcad893df78..87c90d7ebec0 100644
> --- a/net/netfilter/xt_LED.c
> +++ b/net/netfilter/xt_LED.c
> @@ -142,9 +142,10 @@ static int led_tg_check(const struct xt_tgchk_param *par)
> goto exit_alloc;
> }
>
> -   /* See if we need to set up a timer */
> -   if (ledinfo->delay > 0)
> -   timer_setup(>timer, led_timeout_callback, 0);
> +   /* Since the letinternal timer can be shared between multiple targets,
> +* always set it up, even if the current target does not need it
> +*/
> +   timer_setup(>timer, led_timeout_callback, 0);

Shouldn't this also make del_timer_sync() unconditional?

> list_add_tail(>list, _led_triggers);
>
> --
> 2.14.3
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/3d6e6b945aa88d8b961e9e0e77b4beaabdef49ee.1518455842.git.pabeni%40redhat.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net] netfilter: x_tables: fix missing timer initialization in xt_LED

2018-02-12 Thread Paolo Abeni 
syzbot reported that xt_LED may try to use the ledinternal->timer
without previously initializing it:

[ cut here ]
kernel BUG at kernel/time/timer.c:958!
invalid opcode:  [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 1826 Comm: kworker/1:2 Not tainted 4.15.0+ #306
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:__mod_timer kernel/time/timer.c:958 [inline]
RIP: 0010:mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102
RSP: 0018:8801d24fe9f8 EFLAGS: 00010293
RAX: 8801d25246c0 RBX: 8801aec6cb50 RCX: 816052c6
RDX:  RSI: fffbd14b RDI: 8801aec6cb68
RBP: 8801d24fec98 R08:  R09: 11003a49fd6c
R10: 8801d24feb28 R11: 0005 R12: dc00
R13: 8801d24fec70 R14: fffbd14b R15: 8801af608f90
FS:  () GS:8801db50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 206d6fd0 CR3: 06a22001 CR4: 001606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  led_tg+0x1db/0x2e0 net/netfilter/xt_LED.c:75
  ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
  ip6table_raw_hook+0x65/0x80 net/ipv6/netfilter/ip6table_raw.c:42
  nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
  nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
  nf_hook.constprop.27+0x3f6/0x830 include/linux/netfilter.h:243
  NF_HOOK include/linux/netfilter.h:286 [inline]
  ndisc_send_skb+0xa51/0x1370 net/ipv6/ndisc.c:491
  ndisc_send_ns+0x38a/0x870 net/ipv6/ndisc.c:633
  addrconf_dad_work+0xb9e/0x1320 net/ipv6/addrconf.c:4008
  process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
  kthread+0x33c/0x400 kernel/kthread.c:238
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
Code: 85 2a 0b 00 00 4d 8b 3c 24 4d 85 ff 75 9f 4c 8b bd 60 fd ff ff e8 bb
57 10 00 65 ff 0d 94 9a a1 7e e9 d9 fc ff ff e8 aa 57 10 00 <0f> 0b e8 a3
57 10 00 e9 14 fb ff ff e8 99 57 10 00 4c 89 bd 70
RIP: __mod_timer kernel/time/timer.c:958 [inline] RSP: 8801d24fe9f8
RIP: mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102 RSP: 8801d24fe9f8
---[ end trace f661ab06f5dd8b3d ]---

The ledinternal struct can be shared between several different
xt_LED targets, but the related timer is currently initialized only
if the first target requires it. Fix it by unconditionally
initializing the timer struct.

Fixes: 268cb38e1802 ("netfilter: x_tables: add LED trigger target")
Reported-by: syzbot+10c98dc5725c6c8fc...@syzkaller.appspotmail.com
Signed-off-by: Paolo Abeni 
---
 net/netfilter/xt_LED.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/netfilter/xt_LED.c b/net/netfilter/xt_LED.c
index 1dcad893df78..87c90d7ebec0 100644
--- a/net/netfilter/xt_LED.c
+++ b/net/netfilter/xt_LED.c
@@ -142,9 +142,10 @@ static int led_tg_check(const struct xt_tgchk_param *par)
goto exit_alloc;
}
 
-   /* See if we need to set up a timer */
-   if (ledinfo->delay > 0)
-   timer_setup(>timer, led_timeout_callback, 0);
+   /* Since the letinternal timer can be shared between multiple targets,
+* always set it up, even if the current target does not need it
+*/
+   timer_setup(>timer, led_timeout_callback, 0);
 
list_add_tail(>list, _led_triggers);
 
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to retrieve original source address with FTP/NAT/TPROXY

2018-02-12 Thread Gregory Vander Schueren 

Hi Pablo,

Thank you for getting back to me. Also thanks for pointing me to
libnetfilter_conntrack, I will definitely have a look.

I am using kernel 4.1.39 and the issue can be reproduced with the 
following ruleset on the Proxy host:


iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -A PREROUTING -p tcp ! --dport 21 -i eth0 -j TPROXY 
--tproxy-mark 0x1/0x1 --on-port 


Then I simply retrieve an FTP file (in passive mode) from the client and 
I use a toy C program (see below) on the Proxy to retrieve the source IP.


I am still wondering if the IP returned by accept is a normal behavior. 
What do you think? Don't we expect accept() to return the client's IP?


Regards,
Gregory

#include 
#include 
int main()
{
struct sockaddr_in addr;
socklen_t len = sizeof(addr);
int sock;
int one = 1;

addr.sin_family = AF_INET;
addr.sin_port = htons();
addr.sin_addr.s_addr = INADDR_ANY;

sock = socket(PF_INET, SOCK_STREAM, 0);
setsockopt(sock, SOL_IP, IP_TRANSPARENT, , sizeof(one));
bind(sock, (struct sockaddr*), sizeof(addr));
listen(sock, 1);
accept(sock,(struct sockaddr *), );

char *ip = inet_ntoa(addr.sin_addr);
printf("%s\n", ip);
}

On 02/08/2018 05:55 PM, Pablo Neira Ayuso wrote:

Hi Gregory,

On Tue, Feb 06, 2018 at 03:40:20PM +0100, Gregory Vander Schueren wrote:

Hello,

I have the following IPv4 network:

FTPClient <-> Proxy <--> FTPServer.
  10.0.0.2  10.0.0.1   1.1.1.11.1.1.2

FTPClient connects to FTPServer in PASSIVE mode, meaning the FTPClient
initiates the data connection towards FTPServer. Proxy performs NAT in the
POSTROUTING chain using the iptables MASQUERADE target. On Proxy, I use the
iptables TPROXY target to redirect the FTP data connection towards a local
socket.

Upon accept() on this socket, the address returned by accept() is 1.1.1.1,
not the IP of the Client (10.0.0.2) as I expected. Using getpeername() also
returns 1.1.1.1. For other TCP connections than FTP accept() or
getpeername() returns 10.0.0.2.

I noticed this only occurs when using the NF_CONNTRACK_FTP and NF_NAT_FTP
kernel modules.

Note that I was able to retrieve the FTPClient IP on Proxy from
/proc/net/ip_conntrack. I also made a quick patch to add a SO_ORIGINAL_SRC 
socket option
(similar to SO_ORIGINAL_DST) which allows to retrieve the FTPClient
IP. Since this option does not exist yet, I am wondering if this is
relevant to add such an option?


You can use libnetfilter_conntrack to do this these days, via ctnetlink.


Also, this does not occur in IPv6.

Is this behavior normal?


Probably it is related to your ruleset? You could post an example to
reproduce the issue and your kernel version.

Thanks.



--

--
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: general protection fault in ipt_do_table

2018-02-12 Thread Dmitry Vyukov 
On Mon, Feb 12, 2018 at 5:20 PM, Florian Westphal  wrote:
> syzbot  wrote:
>> Hello,
>>
>> syzbot hit the following crash on net-next commit
>> 9a61df9e5f7471fe5be3e02bd0bed726b2761a54 (Sat Feb 10 03:32:41 2018 +)
>> Merge tag 'kbuild-v4.16-2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
>>
>> So far this crash happened 2 times on net-next, upstream.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
>
> #sys-dup: general protection fault in ip6t_do_table

this should read as:

#syz dup: general protection fault in ip6t_do_table

> (well, its not strictly a duplicate but ip(6)tables is copypastry
>  sauce so its bug compatible, the fix I sent for ip6tables report
>  also fixes ip and arptables.)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: general protection fault in ipt_do_table

2018-02-12 Thread Florian Westphal 
syzbot  wrote:
> Hello,
> 
> syzbot hit the following crash on net-next commit
> 9a61df9e5f7471fe5be3e02bd0bed726b2761a54 (Sat Feb 10 03:32:41 2018 +)
> Merge tag 'kbuild-v4.16-2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> 
> So far this crash happened 2 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.

#sys-dup: general protection fault in ip6t_do_table

(well, its not strictly a duplicate but ip(6)tables is copypastry
 sauce so its bug compatible, the fix I sent for ip6tables report
 also fixes ip and arptables.)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [kbuild-all] [nf:master 1/9] arch/x86/tools/insn_decoder_test: warning: ffffffff817c07c3: 0f ff e9 ud0 %ecx, %ebp

2018-02-12 Thread Li, Philip 
> On Wed 07-02-18 10:16:31, Wu Fengguang wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
> > head:   b408c5b04f82fe4e20bceb8e4f219453d4f21f02
> > commit: 0537250fdc6c876ed4cbbe874c739aebef493ee2 [1/9] netfilter: x_tables:
> make allocation less aggressive
> > config: x86_64-rhel-7.2 (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> > reproduce:
> > git checkout 0537250fdc6c876ed4cbbe874c739aebef493ee2
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> >
> > All warnings (new ones prefixed by >>):
> >
> >arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction 
> > decoder
> bug, please report this.
> >arch/x86/tools/insn_decoder_test: warning: 817aed81: 0f ff c3
>   ud0%ebx,%eax
> 
> I really fail to see how the above patch could have made any difference.
> I am even not sure what the actual bug is, to be honest.
sorry for the noise, this is a false positive after we upgrade to gcc7.3. We 
have
blacklisted this warning in test farm, and kernel side has started the fix to 
handle
this. Kindly ignore this report.

> 
> --
> Michal Hocko
> SUSE Labs
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] .gitignore: ignore ASN.1 auto generated files

2018-02-12 Thread Zhu Lingshan 
when build kernel with default configure, files:

generatenet/ipv4/netfilter/nf_nat_snmp_basic-asn1.c
net/ipv4/netfilter/nf_nat_snmp_basic-asn1.h

will be automatically generated by ASN.1 compiler, so
No need to track them in git, it's better to ignore them.

Signed-off-by: Zhu Lingshan 
---
Changes in v2:
  -correct ANS.1 --> ASN.1 in title

 .gitignore | 4 
 1 file changed, 4 insertions(+)

diff --git a/.gitignore b/.gitignore
index 705e09913dc2..1be78fd8163b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,3 +127,7 @@ all.config
 
 # Kdevelop4
 *.kdev4
+
+#Automatically generated by ASN.1 compiler
+net/ipv4/netfilter/nf_nat_snmp_basic-asn1.c
+net/ipv4/netfilter/nf_nat_snmp_basic-asn1.h
-- 
2.13.6

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [nf:master 1/9] arch/x86/tools/insn_decoder_test: warning: ffffffff817c07c3: 0f ff e9 ud0 %ecx,%ebp

2018-02-12 Thread Michal Hocko 
On Wed 07-02-18 10:16:31, Wu Fengguang wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
> head:   b408c5b04f82fe4e20bceb8e4f219453d4f21f02
> commit: 0537250fdc6c876ed4cbbe874c739aebef493ee2 [1/9] netfilter: x_tables: 
> make allocation less aggressive
> config: x86_64-rhel-7.2 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout 0537250fdc6c876ed4cbbe874c739aebef493ee2
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
>arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction 
> decoder bug, please report this.
>arch/x86/tools/insn_decoder_test: warning: 817aed81:   0f ff 
> c3ud0%ebx,%eax

I really fail to see how the above patch could have made any difference.
I am even not sure what the actual bug is, to be honest.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html