Re: [Iscsitarget-devel] Question regarding iet_seq_start

[Ross W. <rsw...@gm...>]

On Tue, May 7, 2013 at 1:15 PM, Arne Redlich <arn...@go...>wrote:

> 2013/5/7 Ross Walker <rsw...@gm...>:
> > On Tue, May 7, 2013 at 12:46 PM, Arne Redlich <
> arn...@go...>
> > wrote:
> >>
> >> 2013/5/7 Ross Walker <rsw...@gm...>:
>
> [...]
>
> >> > static void iet_seq_stop(struct seq_file *m, void *v)
> >> > {
> >> >         if (PTR_ERR(v) != -EINTR)
> >> >                 mutex_unlock(&target_list_mutex);
> >> > }
> >>
> >> Shivaram, Ross,
> >>
> >> I think it's indeed better to attempt to maintain the interruptibility
> >> of the procfs calls to rule out regressions. That being said,
> >> traverse() has this loop:
> >>
> >>         p = m->op->start(m, &index);
> >>         while (p) {
> >>                 error = PTR_ERR(p);
> >>                 if (IS_ERR(p))
> >>                         break;
> >>                 error = m->op->show(m, p);
> >>                 if (error < 0)
> >>                         break;
> >>                 if (unlikely(error)) {
> >>                         error = 0;
> >>                         m->count = 0;
> >>                 }
> >>                 if (seq_overflow(m))
> >>                         goto Eoverflow;
> >>                 if (pos + m->count > offset) {
> >>                         m->from = offset - pos;
> >>                         m->count -= m->from;
> >>                         m->index = index;
> >>                         break;
> >>                 }
> >>                 pos += m->count;
> >>                 m->count = 0;
> >>                 if (pos == offset) {
> >>                         index++;
> >>                         m->index = index;
> >>                         break;
> >>                 }
> >>                 p = m->op->next(m, p, &index);
> >>         }
> >>         m->op->stop(m, p);
> >>
> >> so the question is: can iet_seq_next return ERR_PTR(EINTR)? Otherwise
> >> the above patch won't work.
> >>
> >> Also, any reason not to CC iet-devel?
> >
> >
> > Fell off list in replies...
> >
> > Kernel code shows seq_list_next returns either the next on the list or
> NULL,
> > no ERR_PTR handling at all.
>
> Yes, I realized that too after hitting send. This is what the
> seq_file.txt documentation has to say:
>
> "It's worth noting that the iterator value returned by start() and
> manipulated by the other functions is considered to be completely opaque by
> the seq_file code. It can thus be anything that is useful in stepping
> through the data to be output."
>
> So I think the patch is ok. Will you apply it?
>

Sure.

-Ross