Since it is "static" the user must be in the same source file (or - theoretically - any included header).
So just use the "find" function of your $PREFERRED_EDITOR.

Bernd

Signature · 3 lines

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Adrian Bunk

2005-06-13 12:10 UTC #17 lore raw

In reply to Rommer

Quoted 1 line · Rommer

Hello,

Hi Roman,

Quoted 3 lines

Where used strange function udp_v4_hash?
linux-2.6.11.11, net/ipv4/udp.c:204
...

do a simple

grep -r udp_v4_hash *

in the main directory of the kernel sources and you'll find it.

Quoted 1 line

Best regards, Roman

cu
Adrian

Signature · 4 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Måns Rullgård

2005-06-13 12:26 UTC #2 lore raw

In reply to Bernd Petrovitsch

Quoted 8 lines · Bernd Petrovitsch

Quoted 4 lines · Rommer
Where used strange function udp_v4_hash?
linux-2.6.11.11, net/ipv4/udp.c:204
static void udp_v4_hash(struct sock *sk)
Since it is "static" the user must be in the same source file (or - theoretically - any included header).

It's not that simple. It is assigned to the 'hash' field of a struct proto, which is exported. It could be used from anywhere, but hopefully isn't. Something else is supposed to ensure that it is never called when using the UDP protocol.

Signature · 2 lines

Måns Rullgård
[email protected]

Bernd Petrovitsch

2005-06-13 12:34 UTC #3 lore raw

Quoted 6 lines · Måns Rullgård

Quoted 4 lines · Bernd Petrovitsch
Quoted 3 lines · Rommer
Where used strange function udp_v4_hash?
linux-2.6.11.11, net/ipv4/udp.c:204

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
static void udp_v4_hash(struct sock *sk)
Since it is "static" the user must be in the same source file (or - theoretically - any included header).
It's not that simple. It is assigned to the 'hash' field of a struct

If you interpret "called" word-by-word yes. I assumed "used".

Quoted 1 line

proto, which is exported. It could be used from anywhere, but

The the OP has to grep for dereferences for this hash variable and check if it is (or may be) from the given struct.
Well, that's the virtue of object-orientation: Follow the objects, not the functions/methods.

Quoted 2 lines

hopefully isn't. Something else is supposed to ensure that it is never called when using the UDP protocol.

Apparently.

Bernd

Signature · 3 lines

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Rommer

author

2005-06-13 12:55 UTC #4 lore raw

Hello,

So, why BUG(), not just void function?

Quoted 37 lines · Bernd Petrovitsch

Quoted 8 lines · Måns Rullgård
Quoted 5 lines · Bernd Petrovitsch
Quoted 3 lines · Rommer
Where used strange function udp_v4_hash?
linux-2.6.11.11, net/ipv4/udp.c:204
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
static void udp_v4_hash(struct sock *sk)
Since it is "static" the user must be in the same source file (or - theoretically - any included header).
It's not that simple. It is assigned to the 'hash' field of a struct
If you interpret "called" word-by-word yes. I assumed "used".
Quoted 1 line
proto, which is exported. It could be used from anywhere, but
The the OP has to grep for dereferences for this hash variable and check if it is (or may be) from the given struct.
Well, that's the virtue of object-orientation: Follow the objects, not the functions/methods.
Quoted 2 lines
hopefully isn't. Something else is supposed to ensure that it is never called when using the UDP protocol.
Apparently.
Bernd

Signature · 1 line

Best regards, Roman

Bernd Petrovitsch

2005-06-13 12:58 UTC #5 lore raw

Quoted 1 line · Rommer

So, why BUG(), not just void function?

So that the kernel oopses and someone notices that serious breakage immediately.

Bernd

Signature · 3 lines

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Måns Rullgård

2005-06-13 13:00 UTC #6 lore raw

In reply to Rommer

Quoted 26 lines · Rommer

Quoted 25 lines · Bernd Petrovitsch
Quoted 8 lines · Måns Rullgård
Quoted 5 lines · Bernd Petrovitsch
Quoted 3 lines · Rommer
Where used strange function udp_v4_hash?
linux-2.6.11.11, net/ipv4/udp.c:204
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
static void udp_v4_hash(struct sock *sk)
Since it is "static" the user must be in the same source file (or - theoretically - any included header).
It's not that simple. It is assigned to the 'hash' field of a struct
If you interpret "called" word-by-word yes. I assumed "used".
Quoted 1 line
proto, which is exported. It could be used from anywhere, but
The the OP has to grep for dereferences for this hash variable and check
if it is (or may be) from the given struct.
Well, that's the virtue of object-orientation: Follow the objects, not the functions/methods.

Quoted 4 lines

Quoted 2 lines
Quoted 2 lines
hopefully isn't. Something else is supposed to ensure that it is never called when using the UDP protocol.
So, why BUG(), not just void function?

Calling the function would be the result of a bug elsewhere in the code, which should be detected and reported.

Signature · 2 lines

Måns Rullgård
[email protected]

Jesper Juhl

2005-06-13 17:23 UTC #7 lore raw

Quoted 28 lines · Måns Rullgård

Quoted 26 lines · Rommer
Quoted 25 lines · Bernd Petrovitsch
Quoted 8 lines · Måns Rullgård
Quoted 5 lines · Bernd Petrovitsch
Quoted 3 lines · Rommer
Where used strange function udp_v4_hash?
linux-2.6.11.11, net/ipv4/udp.c:204
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
static void udp_v4_hash(struct sock *sk)
Since it is "static" the user must be in the same source file (or - theoretically - any included header).
It's not that simple. It is assigned to the 'hash' field of a struct
If you interpret "called" word-by-word yes. I assumed "used".
Quoted 1 line
proto, which is exported. It could be used from anywhere, but
The the OP has to grep for dereferences for this hash variable and check
if it is (or may be) from the given struct.
Well, that's the virtue of object-orientation: Follow the objects, not the functions/methods.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
hopefully isn't. Something else is supposed to ensure that it is never called when using the UDP protocol.
So, why BUG(), not just void function?
Calling the function would be the result of a bug elsewhere in the code, which should be detected and reported.

Why not remove the function and audit the code for users (and if any, remove them)...? Let's get rid of it instead of having a function sit around the only purpose of which is to BUG();

Signature · 3 lines

Jesper Juhl <[email protected]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

David S. Miller

maintainer

2005-06-13 19:46 UTC #8 lore raw

From: Jesper Juhl <[email protected]>
Date: Mon, 13 Jun 2005 19:23:36 +0200

Quoted 3 lines

Why not remove the function and audit the code for users (and if any, remove them)...? Let's get rid of it instead of having a function sit around the only purpose of which is to BUG();

Then if someone breaks that invariant, we'll never find out.

The code is staying, sorry.

Herbert Xu

2005-06-13 21:42 UTC #9 lore raw

Quoted 10 lines · David S. Miller

From: Jesper Juhl <[email protected]>
Date: Mon, 13 Jun 2005 19:23:36 +0200
Quoted 3 lines
Why not remove the function and audit the code for users (and if any, remove them)...? Let's get rid of it instead of having a function sit around the only purpose of which is to BUG();
Then if someone breaks that invariant, we'll never find out.
The code is staying, sorry.

It'll dump the stack anyway if we just make it a NULL pointer.

Signed-off-by Herbert Xu <[email protected]>

Cheers,

Signature · 5 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

net/ipv4/udp.c +1 -6

@@ -201,11 +201,6 @@ fail:
 	return 1;
 }
 
-static void udp_v4_hash(struct sock *sk)
-{
-	BUG();
-}
-
 static void udp_v4_unhash(struct sock *sk)
 {
 	write_lock_bh(&udp_hash_lock);

@@ -1370,7 +1365,7 @@ struct proto udp_prot = {
 	.recvmsg =	udp_recvmsg,
 	.sendpage =	udp_sendpage,
 	.backlog_rcv =	udp_queue_rcv_skb,
-	.hash =		udp_v4_hash,
+	/* .hash is intentionally left NULL */
 	.unhash =	udp_v4_unhash,
 	.get_port =	udp_v4_get_port,
 	.obj_size =	sizeof(struct udp_sock),

net/ipv6/udp.c +1 -6

@@ -135,11 +135,6 @@ fail:
 	return 1;
 }
 
-static void udp_v6_hash(struct sock *sk)
-{
-	BUG();
-}
-
 static void udp_v6_unhash(struct sock *sk)
 {
  	write_lock_bh(&udp_hash_lock);

@@ -1048,7 +1043,7 @@ struct proto udpv6_prot = {
 	.sendmsg =	udpv6_sendmsg,
 	.recvmsg =	udpv6_recvmsg,
 	.backlog_rcv =	udpv6_queue_rcv_skb,
-	.hash =		udp_v6_hash,
+	/* .hash is intentionally left NULL */
 	.unhash =	udp_v6_unhash,
 	.get_port =	udp_v6_get_port,
 	.obj_size =	sizeof(struct udp6_sock),

David S. Miller

maintainer

2005-06-13 21:57 UTC #10 lore raw

From: Herbert Xu <[email protected]>
Date: Tue, 14 Jun 2005 07:42:52 +1000

Quoted 1 line

It'll dump the stack anyway if we just make it a NULL pointer.

Some platforms don't handle that very cleanly, for example it may be necessary to have something mapped at page zero for one reason or another.

Herbert Xu

2005-06-13 23:04 UTC #11 lore raw

Quoted 8 lines · David S. Miller

From: Herbert Xu <[email protected]>
Date: Tue, 14 Jun 2005 07:42:52 +1000
Quoted 1 line
It'll dump the stack anyway if we just make it a NULL pointer.
Some platforms don't handle that very cleanly, for example it may be necessary to have something mapped at page zero for one reason or another.

Are there any existing platforms that do that in kernel mode?

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

David S. Miller

maintainer

2005-06-13 23:20 UTC #12 lore raw

From: Herbert Xu <[email protected]>
Date: Tue, 14 Jun 2005 09:04:22 +1000

Quoted 11 lines · David S. Miller

Quoted 8 lines
From: Herbert Xu <[email protected]>
Date: Tue, 14 Jun 2005 07:42:52 +1000
Quoted 1 line
It'll dump the stack anyway if we just make it a NULL pointer.
Some platforms don't handle that very cleanly, for example it may be necessary to have something mapped at page zero for one reason or another.
Are there any existing platforms that do that in kernel mode?

X86 did, especially during bootup, for a long time.

I know the highly optimized sparc64 instruction TLB miss handler doesn't handle this properly and this usually hangs the machine. I've put some checks in there that tries to handle it properly, but there are still some cases that pass through.

Andi Kleen

2005-06-13 23:53 UTC #13 lore raw

Quoted 9 lines · David S. Miller

From: Herbert Xu <[email protected]>
Date: Tue, 14 Jun 2005 09:04:22 +1000
Quoted 6 lines · David S. Miller
Quoted 5 lines
From: Herbert Xu <[email protected]>
Date: Tue, 14 Jun 2005 07:42:52 +1000
Quoted 1 line
It'll dump the stack anyway if we just make it a NULL pointer.

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
Some platforms don't handle that very cleanly, for example it may be necessary to have something mapped at page zero for one reason or another.
Are there any existing platforms that do that in kernel mode?
X86 did, especially during bootup, for a long time.

Still does, as does x86-64, but actually it could be changed now using change_page_attr (and then later undoing it). Is it worth it?

-Andi

David S. Miller

maintainer

2005-06-14 00:00 UTC #14 lore raw

From: Andi Kleen <[email protected]>
Date: Tue, 14 Jun 2005 01:53:56 +0200

Quoted 2 lines

Still does, as does x86-64, but actually it could be changed now using change_page_attr (and then later undoing it). Is it worth it?

A lot of bootup OOPS's have occured in the past and were never discovered until someone on a non-x86 platform tested the patch.

Andi Kleen

2005-06-14 00:12 UTC #15 lore raw

Quoted 9 lines · David S. Miller

From: Andi Kleen <[email protected]>
Date: Tue, 14 Jun 2005 01:53:56 +0200
Quoted 2 lines
Still does, as does x86-64, but actually it could be changed now using change_page_attr (and then later undoing it). Is it worth it?
A lot of bootup OOPS's have occured in the past and were never discovered until someone on a non-x86 platform tested the patch.

Ok I can fix it, but only reasonably after mem_init (at least without hacking up change_page_attr a lot to deal with bootmem). Is that still worth it?

-Andi

David S. Miller

maintainer

2005-06-14 01:11 UTC #16 lore raw

From: Andi Kleen <[email protected]>
Date: 14 Jun 2005 02:12:49 +0200,Tue, 14 Jun 2005 02:12:49 +0200

Quoted 3 lines

Ok I can fix it, but only reasonably after mem_init (at least without hacking up change_page_attr a lot to deal with bootmem). Is that still worth it?

I think so.