On Tue, 03 Mar 2009 12:15:34 +0200
Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> Boaz Harrosh wrote:
> > Systems other then Linux are more picky with the addr length
> > passed to getnameinfo. They expect it to be set from the
> > returned length of the call to getsockname. Use an
> > os_getsockname_ss, that is implemented diffrently for BSD
> > or Linux.
> >
> > Both getsockname and getnameinfo might fail check for
> > errors.
> >
> > Also added a couple of eprints in error cases.
> >
> > Signed-off-by: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
> <snip>
> > diff --git a/usr/iscsi/iscsid.c b/usr/iscsi/iscsid.c
> > index bfaec87..53b231f 100644
> > --- a/usr/iscsi/iscsid.c
> > +++ b/usr/iscsi/iscsid.c
> > @@ -39,6 +39,7 @@
> > #include "driver.h"
> > #include "scsi.h"
> > #include "crc32c.h"
> > +#include "os.h"
> >
> > #define MAX_QUEUE_CMD 128
> >
> > @@ -743,6 +744,7 @@ static void text_scan_text(struct iscsi_connection *conn)
> > {
> > char *key, *value, *data;
> > int datasize;
> > + int ret;
> >
> > data = conn->req.data;
> > datasize = conn->req.datasize;
> > @@ -760,22 +762,31 @@ static void text_scan_text(struct iscsi_connection *conn)
> > blen = sizeof(buf);
> >
> > slen = sizeof(ss);
> > - conn->tp->ep_getsockname(conn, (struct sockaddr *) &ss,
> > - &slen);
> > + ret = conn->tp->ep_getsockname(conn,
> > + (struct sockaddr *) &ss, &slen);
>
> TOMO if you are already experimenting, it might work if &slen is left
> untouched and is passed as returned from getsockname to getnameinfo.
>
> This might work on both Linux and BSD.
Yes, that's the proper way to handle this issue.
> But then we must make sure
> that all transports set &slen to something good.
All the transports must make sure that ep_getsockname should set slen
because getsockname does for tcp. iser sets it up properly.
So far looks like this patchset adds wrong workarounds instead doing
the right things. Sigh, I have to investigate all the patchset in a
line-by-line manner.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
