From: "Balbir Singh" <balbir_soni@hotmail.com>
To: davem@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] Suspected bug in getpeername and getsockname
Date: Thu, 17 Jan 2002 14:11:06 -0800 [thread overview]
Message-ID: <F255p0VatC6ZUbPHiNK0001e34f@hotmail.com> (raw)
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
next reply other threads:[~2002-01-17 22:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-17 22:11 Balbir Singh [this message]
2002-01-17 22:30 ` [BUG] Suspected bug in getpeername and getsockname David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2002-01-18 0:05 Balbir Singh
2002-01-17 23:35 Balbir Singh
2002-01-17 23:38 ` David S. Miller
2002-01-17 23:20 Balbir Singh
2002-01-17 23:26 ` David S. Miller
2002-01-17 16:27 Balbir Singh
2002-01-17 20:24 ` kuznet
2002-01-17 21:11 ` David S. Miller
2002-01-16 0:51 Balbir Singh
2002-01-17 0:54 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F255p0VatC6ZUbPHiNK0001e34f@hotmail.com \
--to=balbir_soni@hotmail.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.