Hi!
> Yup, because there is nothing in the pipe (which you probably realise).
>
> The question is, if we want to test actual splicing, should we fill the
> pipe in the lib?
>
> If so should that be an option that we set? TST_FD_FOREACH or
> TST_FD_FOREACH2 could take an opts struct for e.g. or even tst_test. I
> guess with TST_FD_FOREACH2 there is no need to do add anything now.
That would be much more complex. For splicing from a TCP socket I would
have to set up a TCP server, connect the socket there and feed the data
from a sever...
So maybe later on. I would like to avoid adding more complexity to the
patchset at this point and focus on testing errors for now.
> > + if (fd_in->type == TST_FD_PIPE_READ) {
> > + switch (fd_out->type) {
> > + case TST_FD_FILE:
> > + case TST_FD_PIPE_WRITE:
> > + case TST_FD_UNIX_SOCK:
> > + case TST_FD_INET_SOCK:
> > + case TST_FD_MEMFD:
> > + return;
> > + default:
> > + break;
> > + }
> > + }
> > +
> > + if (fd_out->type == TST_FD_PIPE_WRITE) {
> > + switch (fd_in->type) {
> > + /* While these combinations succeeed */
> > + case TST_FD_FILE:
> > + case TST_FD_MEMFD:
> > + return;
> > + /* And this complains about socket not being connected */
> > + case TST_FD_INET_SOCK:
> > + return;
> > + default:
> > + break;
> > + }
> > + }
> > +
> > + /* These produce EBADF instead of EINVAL */
> > + switch (fd_out->type) {
> > + case TST_FD_DIR:
> > + case TST_FD_DEV_ZERO:
> > + case TST_FD_PROC_MAPS:
> > + case TST_FD_INOTIFY:
> > + case TST_FD_PIPE_READ:
> > + exp_errno = EBADF;
> > + default:
> > + break;
> > + }
> > +
> > + if (fd_in->type == TST_FD_PIPE_WRITE)
> > + exp_errno = EBADF;
> > +
> > + if (fd_in->type == TST_FD_OPEN_TREE || fd_out->type == TST_FD_OPEN_TREE ||
> > + fd_in->type == TST_FD_PATH || fd_out->type == TST_FD_PATH)
> > + exp_errno = EBADF;
>
> This seems like something that could change due to checks changing
> order.
I was hoping that kernel devs would look at the current state, which is
documented in these conditions and tell me how shold we set the
expectations. At least the open_tree() seems to differ from the rest in
several cases, so maybe needs to be aligned with the rest.
> This is a bit offtopic, but we maybe need errno sets, which would be
> useful for our other discussion on relaxing errno checking.
Indeed that is something we have to do either way.
--
Cyril Hrubis
chrubis@xxxxxxx
