Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

2018-01-05 Thread Ozgur


06.01.2018, 00:20, "Tobias Hommel" <netdev-l...@genoetigt.de>:
> Hi,

Hi Tobias,

> I'm running into a NULL pointer dereference after updating from Linux 4.1.6 to
> 4.14.11 (see kernel log below). I tried 4.14.3 initially which did not work
> either.
> Anyone has an idea what is happening here?
>
> The affected machine has 2 active ethernet interfaces (igb driver) and acts as
> a VPN gateway running strongswan. There are several hundreds of IPSec
> roadwarriors connecting to eth1. eth0 connects to an infrastructure running an
> HTTP server.
> During my tests these roadwarriors connect to the gateway, sometimes download 
> a
> large file from the HTTP server, disconnect and after a random delay repeat
> these steps.
>
> Some observations I made:
> * SMP Affinity for IRQs of the NICs Rx/Tx queues (/proc/irq/$IRQ/smp_affinity)
>   * all affinities set to default ff is broken
>   * setting affinity for all queues of both interfaces to the same CPU seems 
> to
> work fine (running stable for more than 1 day now)
>   * setting affinity of eth0 queues to CPU 1 and affinity of eth1 queues to 
> CPU
> 2 is broken and seems to always trigger the bug on CPU 1
> * the top 6 entries of the call trace are the same every time the system
>   crashes, the other entries differ sometimes
>
> The bug is 100% reproducible on the Intel Atom machine from the log below and
> also on a HP ProLiant Gen6 (also igb driver).
> I can, of course, provide further information (CPU, NIC, kernel config, more
> traces, etc.) if required.
> If helpful I could also run tests on HP ProLiant Gen9 which has different NICs
> (tg3).
>
> [ 7998.489094] BUG: unable to handle kernel NULL pointer dereference at 
> 0020
> [ 7998.496993] IP: xfrm_lookup+0x2a/0x7e0
> [ 7998.500759] PGD 0 P4D 0
> [ 7998.503316] Oops:  [#1] SMP PTI
> [ 7998.506835] Modules linked in:
> [ 7998.509929] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.14.11 #3
> [ 7998.516244] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 
> 07/11/2016
> [ 7998.524039] task: 8826bb118000 task.stack: 947ac00f
> [ 7998.530004] RIP: 0010:xfrm_lookup+0x2a/0x7e0
> [ 7998.534298] RSP: 0018:947ac00f3b60 EFLAGS: 00010246
> [ 7998.539550] RAX:  RBX: 93074040 RCX: 
> 
> [ 7998.546709] RDX: 947ac00f3bd8 RSI:  RDI: 
> 93074040
> [ 7998.553868] RBP: 93074040 R08: 0002 R09: 
> 0001
> [ 7998.561026] R10: 0032 R11:  R12: 
> 947ac00f3bd8
> [ 7998.568212] R13:  R14: 0002 R15: 
> 8826b69a8078
> [ 7998.575395] FS: () GS:8826bfc8() 
> knlGS:
> [ 7998.583550] CS: 0010 DS:  ES:  CR0: 80050033
> [ 7998.589324] CR2: 0020 CR3: 0001781da000 CR4: 
> 001006e0
> [ 7998.596482] Call Trace:
> [ 7998.598959] __xfrm_route_forward+0xa4/0x110
> [ 7998.603263] ip_forward+0x3e0/0x450
> [ 7998.606778] ? ip_rcv_finish+0x61/0x3a0
> [ 7998.610645] ip_rcv+0x2c4/0x390
> [ 7998.613818] ? inet_del_offload+0x30/0x30
> [ 7998.617857] __netif_receive_skb_core+0x751/0xb00
> [ 7998.622562] ? skb_send_sock+0x40/0x40
> [ 7998.626356] ? netif_receive_skb_internal+0x47/0xf0
> [ 7998.631252] netif_receive_skb_internal+0x47/0xf0
> [ 7998.635987] napi_gro_receive+0x70/0x90
> [ 7998.639835] gro_cell_poll+0x53/0x90
> [ 7998.643439] net_rx_action+0x1fc/0x310
> [ 7998.647210] ? rebalance_domains+0x101/0x2b0
> [ 7998.651500] __do_softirq+0xd5/0x1cf
> [ 7998.655105] run_ksoftirqd+0x14/0x30
> [ 7998.658712] smpboot_thread_fn+0xf9/0x150
> [ 7998.662723] kthread+0xef/0x130
> [ 7998.665893] ? sort_range+0x20/0x20
> [ 7998.669404] ? kthread_park+0x60/0x60
> [ 7998.673098] ret_from_fork+0x1f/0x30
> [ 7998.676674] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 
> d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 
> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
> [ 7998.695681] RIP: xfrm_lookup+0x2a/0x7e0 RSP: 947ac00f3b60
> [ 7998.701479] CR2: 0020
> [ 7998.704799] ---[ end trace 0544b1946919baad ]---
> [ 7998.709442] Kernel panic - not syncing: Fatal exception in interrupt
> [ 7998.715918] Kernel Offset: 0x1100 from 0x8100 (relocation 
> range: 0x8000-0xbfff)


this error doesn't look like the last version kernel, I think this problem NIC 
driver.
What is the use network ethernet card model?
And which driver version you use?

> Best regards,
>
> Tobias Hommel

Ozgur


Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

2018-01-03 Thread Ozgur


03.01.2018, 21:57, "Cong Wang" <xiyou.wangc...@gmail.com>:
> On Tue, Jan 2, 2018 at 3:58 PM, syzbot
> <syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com> wrote:
>>  Hello,
>>
>>  syzkaller hit the following crash on
>>  61233580f1f33c50e159c50e24d80ffd2ba2e06b
>>  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>>  compiler: gcc (GCC) 7.1.1 20170620
>>  .config is attached
>>  Raw console output is attached.
>>  C reproducer is attached
>>  syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>>  for information about syzkaller reproducers
>>
>>  IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>  Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com
>>  It will help syzbot understand when the bug is fixed. See footer for
>>  details.
>>  If you forward the report, please keep this part and the footer.
>>
>>  TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
>>  cookies. Check SNMP counters.
>>  ==
>>  BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
>>  BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
>>  net/ipv6/tcp_ipv6.c:1144
>>  Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196
>>
>>  CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
>>  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>  Google 01/01/2011
>>  Call Trace:
>>   
>>   __dump_stack lib/dump_stack.c:17 [inline]
>>   dump_stack+0x194/0x257 lib/dump_stack.c:53
>>   print_address_description+0x73/0x250 mm/kasan/report.c:252
>>   kasan_report_error mm/kasan/report.c:351 [inline]
>>   kasan_report+0x25b/0x340 mm/kasan/report.c:409
>>   check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>   check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>   memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>   memcpy include/linux/string.h:344 [inline]
>>   tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144
>
> tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
> to this bug. I guess IPv6 is not supported for TLS? If so, need
> a check on proto in tls_init()...

Hello,

I think IPv6 supports with TLS.
There was a previously posted commit by Mellanox:

https://patchwork.ozlabs.org/patch/801530/

Ozgur

>>   tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>>   cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>>   tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>>   tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>>   tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>>   ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>>   dst_input include/net/dst.h:466 [inline]
>>   ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>>   __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>>   __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>>   process_backlog+0x203/0x740 net/core/dev.c:5205
>>   napi_poll net/core/dev.c:5603 [inline]
>>   net_rx_action+0x792/0x1910 net/core/dev.c:5669
>>   __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>   do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>>   
>>   do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>>   do_softirq kernel/softirq.c:177 [inline]
>>   __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>>   local_bh_enable include/linux/bottom_half.h:32 [inline]
>>   rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>>   ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>>   ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>>   NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>>   ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>>   dst_output include/net/dst.h:460 [inline]
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>>   inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>>   tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>>   tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>>   __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>>   tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>>   tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>&g

Re: [PATCH 2/2] net: wireless: fix to uses struct

2016-12-21 Thread Ozgur Karatas

22.12.2016, 01:06, "Paul Bolle" <pebo...@tiscali.nl>:
> On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
>>  I don't have a problem with C programming
>
> I'm sorry, but you do need to learn C, at a basic level, first.

Hmm, I don't like to discussion but I'm an assertive on C/C++.
So, I'm not into the Linux kernel, I writing code with C/C++ for many years. 
I'm having trouble using Linux tools and trying to learn 
git/diff/format-patch/etc. 

Also, I'm reading over 600 e-mails per day and I'm reading to Documentation 
(kernel). I learn :)

I don't have to problem with C, you can see my early codes and software 
(github).

I need to get a good sense of the coding style and Documentation.

And thank you.

Regards

> Paul Bolle

~Ozgur


Re: [PATCH 2/2] net: wireless: fix to uses struct

2016-12-21 Thread Ozgur Karatas

My previous patch is invalid, I'm sorry.
The last patc will be fellow because "regulatory_request" is defined as a 
"static struct".

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/reg.c  | 10 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;

@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4


Re: [PATCH 2/2] net: wireless: fix to uses struct

2016-12-21 Thread Ozgur Karatas

22.12.2016, 00:34, "Paul Bolle" <pebo...@tiscali.nl>:
> On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
>>  I compiled and didn't to errors.
>
> Really?

I'm very sorry. The "regulatory_request" is defined a static struct. I missed.

line: static struct regulatory_request core_request_world = {

I send to wrong line please can ignore last message and should be fix to as 
follows:

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
 {
struct regulatory_request *request;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char 
*alpha2)
 
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

> $ make net/wireless/reg.o
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALL scripts/checksyscalls.sh
>   CC net/wireless/reg.o
> net/wireless/reg.c: In function ‘regulatory_hint_core’:
> net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only 
> once for each function it appears in
> net/wireless/reg.c: In function ‘regulatory_hint_user’:
> net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> net/wireless/reg.c: In function ‘regulatory_hint’:
> net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
> make[1]: *** [net/wireless/reg.o] Error 1
> Makefile:1640: recipe for target 'net/wireless/reg.o' failed
> make: *** [net/wireless/reg.o] Error 2

$ make M=net/wireless/
  CC  net/wireless//core.o
  CC  net/wireless//sysfs.o
  CC  net/wireless//radiotap.o
  CC  net/wireless//util.o
  CC  net/wireless//reg.o
  CC  net/wireless//scan.o
  CC  net/wireless//nl80211.o
  CC  net/wireless//mlme.o
  CC  net/wireless//ibss.o
  CC  net/wireless//sme.o
  CC  net/wireless//chan.o
  CC  net/wireless//ethtool.o
  CC  net/wireless//mesh.o
  CC  net/wireless//ap.o
  CC  net/wireless//trace.o
  CC  net/wireless//ocb.o
  LD  net/wireless//cfg80211.o
  LD  net/wireless//built-in.o
  Building modules, stage 2.
  MODPOST 0 modules

$ make net/wireless/reg.o
scripts/kconfig/conf  --silentoldconfig Kconfig
*
* Restart config...
*
*
* Memory power savings
*

> Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?

I don't have a problem with C programming, So only I'm learning the kernel. 
Also, this is a lie if say "I'm expert to C".

I think be re-learned every day. wrong?

> Paul Bolle

Regards,

~ Ozgur


[PATCH 2/2] net: wireless: fix to uses struct

2016-12-21 Thread Ozgur Karatas

The patch fixed to struct uses in reg.c, I think doesn't need to be use to 
"struct". 
There is dataype not have to logical link and each is different definitons.

I'm undecided on this patch. I compiled and didn't to errors.
 
Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/reg.c  | 10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
 {
struct regulatory_request *request;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char 
*alpha2)
 
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4


[PATCH 1/2] net: wireless: fixed to checkpatch errors

2016-12-21 Thread Ozgur Karatas

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next 
line.
The patch fix to readability and Coding Style.

Sİgned-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/chan.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..8c7ac7f 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -891,7 +891,8 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
  : CHAN_MODE_EXCLUSIVE;
 
/* consider worst-case - IBSS can try to return to the
-* original user-specified channel as creator */
+* original user-specified channel as creator 
+*/
if (wdev->ibss_dfs_possible)
*radar_detect |= BIT(wdev->chandef.width);
return;
-- 
2.1.4


Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

2016-12-16 Thread Ozgur Karatas


16.12.2016, 21:08, "Sergei Shtylyov" <sergei.shtyl...@cogentembedded.com>:
> Hello.

Hi

> On 12/16/2016 09:21 PM, Ozgur Karatas wrote:
>
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>>
>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>>  ---
>>   tools/net/bpf_dbg.c | 2 +-
>>   1 files changed, 1 insertion(+), 1 deletions(-)
>>
>>  diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
>>  index 4f254bc..f715f46 100644
>>  --- a/tools/net/bpf_dbg.c
>>  +++ b/tools/net/bpf_dbg.c
>>  @@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
>>
>>   if (!bpf_prog_loaded())
>>   return CMD_ERR;
>>  - if (strlen(line_string) > 0 &&
>>  + if (strlen(line_string) > 0 &&)
>
> Have tried to you compile that? :-/

Yes, i compiled but I apologize if there was NAK.
Also, checkpatch give a error.

I could be wrong, will review again.

Best Regards!

>>   (line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
>
> I think the code was correct before your patch...
>
>>   single_line = true;
>>   if (single_line)
>
> MBR, Sergei

~Ozgur


Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

2016-12-16 Thread Ozgur Karatas
16.12.2016, 20:35, "Joe Perches" <j...@perches.com>:
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.

Also, checkpatch script give a error, it should not forget.

$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c
tools/net/bpf_dbg.c:1216: ERROR: do not use assignment in if condition

After fix:

$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c 
total: 0 errors, 6 warnings, 1395 lines checked

Regards,

~Ozgur


Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

2016-12-16 Thread Ozgur Karatas
16.12.2016, 20:35, "Joe Perches" <j...@perches.com>:
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.

Dear Perches,

I have already tested and it was not a part of the code anyway. if there is no 
parentheses, the code works incorrectly and give a error. 
I'm sorry, have a little problem with my english but "line_string" variables 
would not equal NULL, 10. So the code it skips it and runs to "bpf_prog_len".
If it should be equal "0 &&" and already be completed (>) right?

if (strlen(line_string) > 0 &&
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)

Testing:

$ make M=tools/
tools//Makefile:6: scripts/Makefile.include: No such file or directory
$ cp tools/scripts/Makefile.include scripts/Makefile
$ make M=tools/
  Building modules, stage 2.
  MODPOST 0 modules

I try to module (insmod) and worked.

Regards,

 ~Ozgur


[PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

2016-12-16 Thread Ozgur Karatas

This patch fixed to keyboard typo, brackets not closed. 
I think, it should be close to parenthes.

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 tools/net/bpf_dbg.c   | 2 +-
 1 files changed, 1 insertion(+), 1 deletions(-)

diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
index 4f254bc..f715f46 100644
--- a/tools/net/bpf_dbg.c
+++ b/tools/net/bpf_dbg.c
@@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
 
if (!bpf_prog_loaded())
return CMD_ERR;
-   if (strlen(line_string) > 0 &&
+   if (strlen(line_string) > 0 &&)
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
single_line = true;
if (single_line)
-- 
2.1.4


Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

2016-12-12 Thread Ozgur Karatas


12.12.2016, 20:18, "Leon Romanovsky" <l...@kernel.org>:
> On Mon, Dec 12, 2016 at 03:04:28PM +0200, Ozgur Karatas wrote:
>>  Dear Romanovsky;
>
> Please avoid top-posting in your replies.
> Thanks

Dear Leon; 
thanks for the information., I will pay attention.

>>  I'm trying to learn english and I apologize for my mistake words and 
>> phrases. So, I think the code when call to "sg_set_buf" and next time set 
>> memory and buffer. For example, isn't to call "WARN_ON" function, get a 
>> error to implicit declaration, right?
>>
>>  Because, you will use to "BUG_ON" get a error implicit declaration of 
>> functions.
>
> I'm not sure that I followed you. mem->offset is set by sg_set_buf from
> buf variable returned by dma_alloc_coherent(). HW needs to get very
> precise size of this buf, in multiple of pages and aligned to pages
> boundaries.

I have studied the following your coding and I guess that's the right patchs.
You are the very expert in this matter, thank you for the correct for me.

I learn to your style as an example.

Regards,

Ozgur Karatas

> See the patch inline which removes this BUG_ON in proper and safe way.
>
> From 7babe807affa2b27d51d3610afb75b693929ea1a Mon Sep 17 00:00:00 2001
> From: Leon Romanovsky <leo...@mellanox.com>
> Date: Mon, 12 Dec 2016 20:02:45 +0200
> Subject: [PATCH] net/mlx4: Remove BUG_ON from ICM allocation routine
>
> This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent()
> by checking DMA address aligment in advance and performing proper
> folding in case of error.
>
> Fixes: 5b0bf5e25efe ("mlx4_core: Support ICM tables in coherent memory")
> Reported-by: Ozgur Karatas <okara...@member.fsf.org>
> Signed-off-by: Leon Romanovsky <leo...@mellanox.com>
> ---
>  drivers/net/ethernet/mellanox/mlx4/icm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 2a9dd46..e1f9e7c 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -118,8 +118,13 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
> struct scatterlist *mem,
>  if (!buf)
>  return -ENOMEM;
>
> + if (offset_in_page(buf)) {
> + dma_free_coherent(dev, PAGE_SIZE << order,
> + buf, sg_dma_address(mem));
> + return -ENOMEM;
> + }
> +
>  sg_set_buf(mem, buf, PAGE_SIZE << order);
> - BUG_ON(mem->offset);
>  sg_dma_len(mem) = PAGE_SIZE << order;
>  return 0;
>  }
> --
> 2.10.2


Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

2016-12-12 Thread Ozgur Karatas
Dear Romanovsky;

I'm trying to learn english and I apologize for my mistake words and phrases. 
So, I think the code when call to "sg_set_buf" and next time set memory and 
buffer. For example, isn't to call "WARN_ON" function, get a error to implicit 
declaration, right?

Because, you will use to "BUG_ON" get a error implicit declaration of functions.

sg_set_buf(mem, buf, PAGE_SIZE << order);
WARN_ON(mem->offset);

Thanks for information and learn to me.

Regards,

Ozgur Karatas

12.12.2016, 14:39, "Leon Romanovsky" <l...@kernel.org>:
> On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote:
>>  Hello all,
>>  I think should be use to "WARN_ON" and checkpatch script give to error, I 
>> fixed and I think should don't use "BUG_ON".
>>  Regards,
>>
>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>
> NAK, Leon Romanovsky <leo...@mellanox.com>
>
> If we put aside commit message issue, which was pointed to you by Stefan, your
> proposed change is incorrect. By chnaging BUG_ONs to be WARN_ONs, you
> will left the driver in improper state.
>
> Thanks
>
>>  ---
>>  drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
>>
>>  diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
>> b/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  index 2a9dd46..3fde535 100644
>>  --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  @@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
>> struct scatterlist *mem,
>>   return -ENOMEM;
>>
>>   sg_set_buf(mem, buf, PAGE_SIZE << order);
>>  - BUG_ON(mem->offset);
>>  + WARN_ON(mem->offset);
>>   sg_dma_len(mem) = PAGE_SIZE << order;
>>   return 0;
>>   }
>>  @@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, 
>> int npages,
>>   int ret;
>>
>>   /* We use sg_set_buf for coherent allocs, which assumes low memory 
>> */
>>  - BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>  + WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>
>>   icm = kmalloc_node(sizeof(*icm),
>>  gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
>>  --
>>  2.1.4


Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON

2016-12-12 Thread Ozgur Karatas
Dear Stefan;

I'm reading to Documentation/SubmittingPatches and I still apologized for 
misrepresentations my patches. 
I will add a next time good commit message and commit subjects.

Sorry,

Regards

Ozgur Karatas

12.12.2016, 13:20, "Stefan Schmidt" <ste...@osg.samsung.com>:
> Hello.
>
> On 12/12/16 11:58, Ozgur Karatas wrote:
>>  Hello all,
>>  I think should be use to "WARN_ON" and checkpatch script give to error, I 
>> fixed and I think should don't use "BUG_ON".
>>  Regards,
>>
>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>
> I pointed you already before to the Documentation how to prepare a
> commit subject and commit message. You just replied with that you are
> new to contributing patches. That is all fine and many people are new
> each release. Please take the time to read the provided and pointed out
> docs.
>
> If you keep ignoring such suggestions and docs I would think people will
> keep ignoring your patches.
>
> regards
> Stefan Schmidt


[PATCH 1/1] Fixed to BUG_ON to WARN_ON def

2016-12-12 Thread Ozgur Karatas
Hello all, 
I think should be use to "WARN_ON" and checkpatch script give to error, I fixed 
and I think  should don't use "BUG_ON".
Regards,

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
drivers/net/ethernet/mellanox/mlx4/icm.c |  4 ++--

diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
b/drivers/net/ethernet/mellanox/mlx4/icm.c
index 2a9dd46..3fde535 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
struct scatterlist *mem,
return -ENOMEM;
 
sg_set_buf(mem, buf, PAGE_SIZE << order);
-   BUG_ON(mem->offset);
+   WARN_ON(mem->offset);
sg_dma_len(mem) = PAGE_SIZE << order;
return 0;
 }
@@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int 
npages,
int ret;
 
/* We use sg_set_buf for coherent allocs, which assumes low memory */
-   BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
+   WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
 
icm = kmalloc_node(sizeof(*icm),
   gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
-- 
2.1.4


[PATCH 130/130] Fixed to checkpatch errors.

2016-12-05 Thread Ozgur Karatas
Hello,

Fixed to checkpatch errors.

ERROR: net/wireless/util.c:1787: ERROR: that open brace { should be on the 
previous line
ERROR: net/wireless/util.c:1792: ERROR: that open brace { should be on the 
previous line

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/util.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 659b507..f4ac755 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1783,11 +1783,13 @@ EXPORT_SYMBOL(cfg80211_free_nan_func);
 
 /* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
 /* Ethernet-II snap header (RFC1042 for most EtherTypes) */
-const unsigned char rfc1042_header[] __aligned(2) =
-   { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
+const unsigned char rfc1042_header[] __aligned(2) = {
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
+};
 EXPORT_SYMBOL(rfc1042_header);
 
 /* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
-const unsigned char bridge_tunnel_header[] __aligned(2) =
-   { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
+const unsigned char bridge_tunnel_header[] __aligned(2) = {
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8
+};
 EXPORT_SYMBOL(bridge_tunnel_header);
-- 
2.1.4


[PATCH] Fixed to checkpatch.pl errors to vlan_dev.c

2016-12-05 Thread Ozgur Karatas
Hello all,

I will solve a checkpatch errors.

Signed-off-by: Ozgur Karatas <oz...@member.fsf.org>

---
 net/8021q/vlan_dev.c   |   2 +-
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index fbfacd5..2edb495 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -738,7 +738,7 @@ static int vlan_dev_netpoll_setup(struct net_device *dev, 
struct netpoll_info *n

 static void vlan_dev_netpoll_cleanup(struct net_device *dev)
 {
-   struct vlan_dev_priv *vlan= vlan_dev_priv(dev);
+   struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
struct netpoll *netpoll = vlan->netpoll;

if (!netpoll)


I coding cpustat

2006-06-29 Thread Ozgur Karatas
Hello,
I have written a program which gives CPU statistics, then what should i do
for putting this program in to the default kernel? This code is written to
take CPU loading statistics. cpustat; shows the usage load statistic of
your CPU. I Code tested for Intel Processors. After then code will be
ported for AMD. Can we add this default kernel?
Best Regards.

,''`.  Ozgur Karatas
: :' :  [EMAIL PROTECTED]
`. `'   http://www.ozgurkaratas.com
  `-Powered By Debian GNU\Linux


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Fw: [Bugme-new] [Bug 6268] New: b44 driver - system hangs while changing MAC address

2006-03-22 Thread Ozgur Karatas
postfix:~# ifconfig
eth0  Link encap:Ethernet  HWaddr 00:00:E8:6B:24:B6
  inet addr:192.168.1.98  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::200:e8ff:fe6b:24b6/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:6343 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2700 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:4963472 (4.7 MiB)  TX bytes:218489 (213.3 KiB)
  Interrupt:10 Base address:0xd000


or

postfix:~# uname -ar
Linux postfix 2.6.12-1-386 #1 Tue Sep 27 12:41:08 JST 2005 i686 GNU/Linux
postfix:~#



 Begin forwarded message:

 Date: Wed, 22 Mar 2006 02:32:49 -0800
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [Bugme-new] [Bug 6268] New: b44 driver - system hangs while
 changing MAC address


 http://bugzilla.kernel.org/show_bug.cgi?id=6268

Summary: b44 driver - system hangs while changing MAC address
 Kernel Version: 2.6.16
 Status: NEW
   Severity: normal
  Owner: [EMAIL PROTECTED]
  Submitter: [EMAIL PROTECTED]


 Most recent kernel where this bug did not occur: 2.6.16

 Distribution: Arch Linux (current - 22.03.06)

 Hardware Environment: Acer TravelMate 2403, Broadcom BCM4401-B0 ethernet
 card

 Software Environment: Linux kernel 2.6.15.6 - 2.6.16 (didn't try earlier
 versions, but probably they are affected too)

 Problem Description:
   System hangs without any message while trying to change MAC address of
 ethernet
 card that wasn't already up before. Basically, system freezes when the
 ethernet
 card isn't initialized during start of the system (no ifconfig eth0 up)
 and
 the first call to ifconfig is: ifconfig eth0 hw ether my_new_MAC (where
 my_new_MAC is something like XX:XX:XX:XX:XX). But when I do: ifconfig
 eth0
 192.168.0.1 up; ifconfig eth0 down; ifconfig eth0 hw ether my_new_MAC
 everything works O.K., MAC is changed and network is working great.

 Steps to reproduce:
   Boot your system without running network initializing srcipts (e.g
 disable it
 in your runlevel configuration). Try to change MAC address - that should
 cause
 system freeze.

 --- You are receiving this mail because: ---
 You are on the CC list for the bug, or are watching someone who is.
 -
 To unsubscribe from this list: send the line unsubscribe netdev in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ozgur Karatas
CCNA
Network Enginner
ozgur (at) ozgurkaratas [dot] com
http://www.ozgurkaratas.com
--

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


SIOCGMIIPHY on 'eth2' failed: Operation not supported

2006-03-06 Thread Ozgur Karatas
hello,

ozgur:/lib/modules/2.6.12-1-386/kernel/drivers/net# uname -ar
Linux ozgur 2.6.12-1-386 #1 Tue Sep 27 12:41:08 JST 2005 i686 GNU/Linux
ozgur:/lib/modules/2.6.12-1-386/kernel/drivers/net#ls
3c501.koamd8111e.ko  dl2k.ko  forcedeth.ko  ne2.ko 
ppp_generic.ko  slip.ko tun.ko
3c503.koappletalkdummy.ko hamachi.kone2k-pci.ko
pppoe.kosmc9194.ko  typhoon.ko
3c505.koarcnet   e1000hamradio  ne3210.ko  
pppox.kosmc-mca.ko  via-rhine.ko
3c507.koat1700.koe100.ko  hp100.ko  ne.ko  
ppp_synctty.ko  smc-ultra32.ko  via-velocity.ko
3c509.koatp.ko   e2100.ko hp.ko netconsole.ko  
r8169.kosmc-ultra.kowan
3c515.kob44.ko   eepro100.ko  hp-plus.koni5010.ko  
rrunner.ko  starfire.ko wd.ko
3c523.kobnx2.ko  eepro.ko ibmlana.koni52.ko
s2io.ko sundance.ko wireless
3c527.kobonding  eexpress.ko  irda  ni65.ko
sb1000.ko   sungem.ko   yellowfin.ko
3c59x.kobsd_comp.ko  epic100.ko   ixgb  ns83820.ko 
seeq8005.ko sungem_phy.ko   znet.ko
8139cp.ko   cs89x0.koeql.ko   lance.ko  pcmcia 
shaper.ko   sunhme.ko
8139too.ko  de600.ko es3210.kolne390.ko pcnet32.ko 
sis900.ko   tg3.ko
82596.kode620.ko eth16i.kolp486e.ko plip.ko
sk98lin tlan.ko
8390.ko defxx.ko ewrk3.ko mii.koppp_async.koskfp  
 tokenring
ac3200.ko   depca.ko fealnx.konatsemi.koppp_deflate.ko 
slhc.ko tulip


ozgur:/lib/modules/2.6.12-1-386/kernel/drivers/net# mii-tool
eth0: negotiated 100baseTx-FD, link ok
eth1: negotiated 100baseTx-FD, link ok
SIOCGMIIPHY on 'eth2' failed: Operation not supported
ozgur:/lib/modules/2.6.12-1-386/kernel/drivers/net#

why SIOCGMIIPHY operation not supported?

 drivers/net/spider_net.c:421: multiple definition of `mii_phy_probe'
 drivers/net/sungem_phy.o(.opd+0x160):drivers/net/sungem_phy.c:95: first
 defined here
 -
 To unsubscribe from this list: send the line unsubscribe netdev in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Ozgur Karatas
CCNA
Network Enginner
ozgur (at) ozgurkaratas [dot] com
http://www.ozgurkaratas.com
--

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html