lkml.org 
[lkml]   [2002]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [BUG] Suspected bug in getpeername and getsockname
Date
Actually, you are correct about that.

The reasons why I wanted to pass the address is length
is

1. It gives more flexibility for any body implementing
the protocol specific code.
2. We anyway copy the length in move_addr_to_user, we
might as well do it in the system call and pass the
length to the protocol.
3. We can finally copy only the length specified back
to the user as we do currently.

I correct my self, it is not a BUG.

But, consider a case where a user passes a negative value
in len. The system call calls the protocol specific
code and then later at the end in move_addr_to_user()
catches the error. I feel the error should be
caught first hand, we should not have spent the
time and space calling the protocol specific code at all,
we should catch the error and return immediately.

I feel there are several instances of this in the
socket system calls.

Don't u feel they should be fixed.

Balbir



>If move_addr_to_user() takes care of all of the issues, there is no
>reason for the protocol specific code to know anything about the
>user's len at all.
>
>You have to show me a purpose for it to get passed down. What would
>it get used for? All the protocol specific could should (and does)
>do is provide the data back to the top level routine and
>move_addr_to_user() takes care of the remaining details.




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.536 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site