From: "David S. Miller" <davem@redhat.com>
To: balbir_soni@hotmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] Suspected bug in getpeername and getsockname
Date: Thu, 17 Jan 2002 14:30:15 -0800 (PST) [thread overview]
Message-ID: <20020117.143015.51703736.davem@redhat.com> (raw)
In-Reply-To: <F255p0VatC6ZUbPHiNK0001e34f@hotmail.com>
In-Reply-To: <F255p0VatC6ZUbPHiNK0001e34f@hotmail.com>
From: "Balbir Singh" <balbir_soni@hotmail.com>
Date: Thu, 17 Jan 2002 14:11:06 -0800
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.
And you could do what with this flexibility that can't be taken care
of at the top level?
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.
Why? What are you going to DO, read this: _DO_, with the
value?
3. We can finally copy only the length specified back
to the user as we do currently.
We already do this in move_addr_to_user. If we do it in
one place, we don't have to duplicate (and thus risk bugs
in) this logic in the various protocols.
But, consider a case where a user passes a negative value
in len.
Now you are totally talking non-sense. A negative len is
an error (-EINVAL) and move_addr_to_user handles this case
just fine.
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.
...
Don't u feel they should be fixed.
If you want to move the "if (len < 0) return -EINVAL;" right before
the ->getname() invocation, feel free. However, this is code
duplication and is error prone.
But either way, this is not an argument at all to move the user len
into the protocols. YOU DONT NEED TO, and you never will, to
accomplish any legitimate task.
Again the question remains, why would you ever need the user len in
the protocol handlers? All I am hearing is a bunch of hot air so far
with no real substance.
Franks a lot,
David S. Miller
davem@redhat.com
next prev parent reply other threads:[~2002-01-17 22:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-17 22:11 [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2002-01-17 22:30 ` David S. Miller [this message]
-- 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=20020117.143015.51703736.davem@redhat.com \
--to=davem@redhat.com \
--cc=balbir_soni@hotmail.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.