----- Original Message -----
> From: "Cyril Hrubis" <chru...@suse.cz>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net, "Chuck Ebbert" <cebbert.l...@gmail.com>
> Sent: Tuesday, 3 February, 2015 1:51:05 PM
> Subject: Re: [LTP] proposed patch to fix sendmsg01 invalid flags set w/
> control ; returned -1 (expected -1), errno 22
> (expected 95)
>
> Hi!
> > > > recvfrom01: fix test for invalid message flags
> > >
> > > Agreed. We have seen in past, that this (.flags = ~MSG_CMSG_COMPAT)
> > > leads to undefined behavior.
> >
> > It appears the difference comes from LTP:
> >
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/utils/msg_common.h
> >
> > The flags has 0 value when compiled with -m32, so we never make it pass
> > this check:
> > if (flags & MSG_CMSG_COMPAT)
> > return -EINVAL;
> >
> > but the kernel definition is rather based on config option:
> > #if defined(CONFIG_COMPAT)
> > #define MSG_CMSG_COMPAT 0x80000000 /* This message needs 32 bit
> > fixups */
> > #else
> > #define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups */
> > #endif
>
> Tricky.
>
> But looking into the unix_dgram_sendmsg() which should be the one that
> gets called in the particular case, the code realy just checks for the
> MSG_OOB, just like the the recvmsg() case.
>
> ......
>
> err = -EOPNOTSUPP;
> if (msg->msg_flags&MSG_OOB)
> goto out;
> ......
>
> So I guess that we should be safe with changing the test the same way as we
> did
> with recvmsg().
I recall switching one to MSG_OOB in this commit:
commit 1c6354e6a4b92aebcd43351cf4e775a9a12dc8e7
Author: Jan Stancek <jstan...@redhat.com>
Date: Fri Nov 29 11:39:34 2013 +0100
send*: use concrete flags for 'invalid flags set'
I guess, there must have been 2 cases using .flags = ~MSG_CMSG_COMPAT,
and we missed the other one.
>
> > sendmsg01 seems to be the only place where this flag is used.
>
> That is because it has been removed from the recvmsg01.c by the fix
> mentioned in this thread. However the header in question stayed included
> there...
Just before your reply, I've a patch that proposes to remove it.
Regards,
Jan
>
> --
> Cyril Hrubis
> chru...@suse.cz
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list