netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re : Bug in using inet_lookup ()
@ 2007-11-14 13:12 Nj A
  2007-11-14 13:31 ` Evgeniy Polyakov
  0 siblings, 1 reply; 4+ messages in thread
From: Nj A @ 2007-11-14 13:12 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: netdev

I suspected it could be that. However, can't see in ip_rcv the right portion that can help.
Any further tip please?

Regards,
----- Message d'origine ----
> De : Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> À : Nj A <nj_a83@yahoo.fr>
> Cc : netdev@vger.kernel.org
> Envoyé le : Mercredi, 14 Novembre 2007, 12h13mn 05s
> Objet : Re: Bug in using inet_lookup ()
> 
> On Wed, Nov 14, 2007 at 09:26:18AM +0000, Nj A (nj_a83@yahoo.fr) wrote:
> > /* The kernel TCP hashtable */
> > struct inet_hashinfo __cacheline_aligned tcp_hashinfo = {
> > .lhash_lock = __RW_LOCK_UNLOCKED (tcp_hashinfo.lhash_lock),
> > .lhash_users = ATOMIC_INIT (0),
> > .lhash_wait = __WAIT_QUEUE_HEAD_INITIALIZER (tcp_hashinfo.lhash_wait),
> > };
> > ...
> > struct sock *sk;
> > struct sk_buff *skb;
> > skb = alloc_skb (MAX_TCP_HEADER + 15, GFP_KERNEL);
> > if (skb == NULL)
> > printk ("%s: Unable to allocate memory \n", __FUNCTION__);
> > sk = inet_lookup (&tcp_hashinfo, ip_src, src_port, ip_dst, dst_port, inet_iif
> (skb));
> > if (!sk)
> > ...
> > This portion of code seems to cause the kernel to panic due to dereferencing a
> NULL pointer.
> > Can anyone please tell me what is the error above?
> > Best Regards,
> 
> Where exactly? Likely in inet_iif(), since it dereferences dst (routing
> info), which is not presented after simple alloc_skb().
> You have to setup skb correctly, check how ip_rcv() does it.
> 
> -- 
> Evgeniy
> Polyakov
>


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Re : Bug in using inet_lookup ()
  2007-11-14 13:12 Re : Bug in using inet_lookup () Nj A
@ 2007-11-14 13:31 ` Evgeniy Polyakov
  0 siblings, 0 replies; 4+ messages in thread
From: Evgeniy Polyakov @ 2007-11-14 13:31 UTC (permalink / raw)
  To: Nj A; +Cc: netdev

On Wed, Nov 14, 2007 at 01:12:11PM +0000, Nj A (nj_a83@yahoo.fr) wrote:
> I suspected it could be that. However, can't see in ip_rcv the right portion that can help.
> Any further tip please?

It is ip_rcv_finish() called from ip_rcv():
	if (skb->dst == NULL) {
		int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
					 skb->dev);
		if (unlikely(err)) {
			if (err == -EHOSTUNREACH)
				IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
			else if (err == -ENETUNREACH)
				IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
			goto drop;
		}
	}

So you will have to specify device, you got your skb via.
Actually it is not exactly needed in some cases, you will need interface
index (dev->ifindex). You can find socket by using that number instead
of dereferencing dst.

-- 
	Evgeniy Polyakov

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re : Bug in using inet_lookup ()
@ 2007-11-16  9:47 Nj A
  2007-11-16 10:08 ` Evgeniy Polyakov
  0 siblings, 1 reply; 4+ messages in thread
From: Nj A @ 2007-11-16  9:47 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: netdev

Hello,
> Please show at least one bug trace when inet_lookup(&tcp_hashinfo, 0, 0, 0, 0,
> 0) fails :)
Trying this the system hangs :-( (setting panic* doesn't change more).
However, using (&tcp_hashinfo, ip_src, p_src, ip_dst, p_dst, 0) gives the following oops:
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000xxxx
printing eip:
c02f19e1
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c02f19e1>]    Not tainted VLI
EFLAGS: 00010282   (2.6.18 #1)
EIP is at inet_lookup+0x300x500
eax: 9e3779b9   ebx: 00000004   ecx: 9e377a57   edx: f4046f84
esi: f46a6010   edi: 00000000   ebp: 0000009e   esp: f4046f38
ds: 007b   es: 007b   ss: 0068
Process knl-thread (pid: 3068, ti=f4046000 task=f46f0610 task.ti=f4046000)
Stack: 22921900 f6953840 f46a6010 f46a6000 f4046f84 00000004 f46a6010 f46a6000
f6953840 f8d3314a 00000004 b7f3a000 00000404 00000005 00000bfe 00000000
00000bfe 00000404 00000000 f4046fa8 f6953840 f4aa7880 f4aa7800 f4046fa8
Code: 00 00 00 8d bc 27 00 00 00 00 55 89 cd 57 0f b7 c9 56 81 e9 47 86 c8 61 53 83 ec 14 89 54 24 10 8b b8 54 02 00 00 b8 b9 79 37 9e <8b> 5f 10 29 d8 89 da 03 44 24 28 c1 ea 0d 29 c8 29 d9 31 d0 89
EIP: [<c02f19e1>] inet_lookup +0x300x500 SS:ESP 0068:f4046f38

> Yes, to show the code you are using.
Ok so basically I am receiving via Netlink a state telling me the ip_src, psrc, ip_dst, pdst.
The goal is to lookup the corresponding state. Going through the inet_lookup() function I see that's it is not amazing it returns the wrong thing.
/* Receive state via Netlink in payload */
...
if ((s_skb = alloc_skb (MAX_TCP_HEADER + 15, GFP_ATOMIC)) == NULL)
 {
   err = -ENOMEM;
 }
  dev = s_skb->dev;
  if (!dev)
   {
      goto pdev;
   }
sk =
     inet_lookup (&tcp_hashinfo, payload->src, payload->p_src, payload->dst, payload->p_dst, inet_iif (s_skb));
if (!sk)
     goto no_tcp_socket;
 if (sk->sk_state == TCP_TIME_WAIT)
     goto time_wait_socket;
 ...
      bh_lock_sock (sk);
 pdev:
      spin_lock (&tmp_lock);
      new_dev = list_entry (&tmp, struct net_device, todo_list);
      spin_unlock (&tmp_lock);
      if (!new_dev)
            goto err;
      s_skb->dev = new_dev;
...
 switch (sk->sk_state)
 {
  case TCP_SYN_RECV:
   ..
  case TCP_LISTEN:
  ..
  case TCP_SYN_SENT:
  ..
 }
   bh_unlock_sock (sk);
...
/* send reply via Netlink */

Cheers,


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Re : Bug in using inet_lookup ()
  2007-11-16  9:47 Nj A
@ 2007-11-16 10:08 ` Evgeniy Polyakov
  0 siblings, 0 replies; 4+ messages in thread
From: Evgeniy Polyakov @ 2007-11-16 10:08 UTC (permalink / raw)
  To: Nj A; +Cc: netdev

On Fri, Nov 16, 2007 at 09:47:08AM +0000, Nj A (nj_a83@yahoo.fr) wrote:
> Hello,
> > Please show at least one bug trace when inet_lookup(&tcp_hashinfo, 0, 0, 0, 0,
> > 0) fails :)
> Trying this the system hangs :-( (setting panic* doesn't change more).

Your code below can not work - you _never_ call inet_lookup().
In your bug inet_lookup() is called, so this wither code is wrong, or
bug is hand written.

And you use inet_iif() which requires dst entry (routing cache), which
you do not setup either.

You can do following to resolve where problem occurs:
$ gdb vmlix
> p inet_lookup
> l *(returned_above_address + 0x300)

it will show you the line where bug occurs.
You have to compile your kernel with debugging symbols.

To prove that inet_lookup() works correctly patch tcv_v4_rcv() to print
lookup result for static source/destination addresses/ports copied from
you message and zero ifindex (the last field).

I'm pretty sure your code, which was not shown yet, has a bug in the
inet_lookup() calling routing.

> However, using (&tcp_hashinfo, ip_src, p_src, ip_dst, p_dst, 0) gives the following oops:

Wrong, you do _NOT_ use this in your code.

> BUG: unable to handle kernel NULL pointer dereference at virtual address 0000xxxx
> printing eip:
> c02f19e1
> *pde = 00000000
> Oops: 0000 [#1]
> CPU:    0
> EIP:    0060:[<c02f19e1>]    Not tainted VLI
> EFLAGS: 00010282   (2.6.18 #1)
> EIP is at inet_lookup+0x300x500
> eax: 9e3779b9   ebx: 00000004   ecx: 9e377a57   edx: f4046f84
> esi: f46a6010   edi: 00000000   ebp: 0000009e   esp: f4046f38
> ds: 007b   es: 007b   ss: 0068
> Process knl-thread (pid: 3068, ti=f4046000 task=f46f0610 task.ti=f4046000)
> Stack: 22921900 f6953840 f46a6010 f46a6000 f4046f84 00000004 f46a6010 f46a6000
> f6953840 f8d3314a 00000004 b7f3a000 00000404 00000005 00000bfe 00000000
> 00000bfe 00000404 00000000 f4046fa8 f6953840 f4aa7880 f4aa7800 f4046fa8
> Code: 00 00 00 8d bc 27 00 00 00 00 55 89 cd 57 0f b7 c9 56 81 e9 47 86 c8 61 53 83 ec 14 89 54 24 10 8b b8 54 02 00 00 b8 b9 79 37 9e <8b> 5f 10 29 d8 89 da 03 44 24 28 c1 ea 0d 29 c8 29 d9 31 d0 89
> EIP: [<c02f19e1>] inet_lookup +0x300x500 SS:ESP 0068:f4046f38
> 
> > Yes, to show the code you are using.
> Ok so basically I am receiving via Netlink a state telling me the ip_src, psrc, ip_dst, pdst.

> sk =
>      inet_lookup (&tcp_hashinfo, payload->src, payload->p_src, payload->dst, payload->p_dst, inet_iif (s_skb));

WRONG!

You did not setup s_skb->dst, so inet_iif() will fail.
Use 0 there, as you were told already several times.
This will not catch device binding though.

> if (!sk)
>      goto no_tcp_socket;
>  if (sk->sk_state == TCP_TIME_WAIT)
>      goto time_wait_socket;
>  ...
>       bh_lock_sock (sk);
>  pdev:
>       spin_lock (&tmp_lock);
>       new_dev = list_entry (&tmp, struct net_device, todo_list);
>       spin_unlock (&tmp_lock);
>       if (!new_dev)
>             goto err;
>       s_skb->dev = new_dev;
> ...
>  switch (sk->sk_state)
>  {
>   case TCP_SYN_RECV:
>    ..
>   case TCP_LISTEN:
>   ..
>   case TCP_SYN_SENT:
>   ..
>  }
>    bh_unlock_sock (sk);
> ...
> /* send reply via Netlink */

This code _NEVER_ calls inet_lookup(), since the first ckeck for
s_skb->dev will fail and you will select device via your list and then
never return to inet_lookup().

Anyway, until your code is presented fully so that people could show you
exactly wrong line it is pretty impossible to try to convince you that
inet_llokup() does work and you have a bug in setup.

-- 
	Evgeniy Polyakov

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-11-16 10:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-14 13:12 Re : Bug in using inet_lookup () Nj A
2007-11-14 13:31 ` Evgeniy Polyakov
  -- strict thread matches above, loose matches on Subject: below --
2007-11-16  9:47 Nj A
2007-11-16 10:08 ` Evgeniy Polyakov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).