On Tue 09 Oct at 13:14:49 +0200 [EMAIL PROTECTED] said:
> FWIW I had to do Tim's bits too. Just moving all output from the start
> into the show method didn't fix it.
Yes. The way the original lockdep_proc.c code was doing its pointers
around its seq data was definitely wrong, regardless of the o
On Tue, 2007-10-09 at 02:30 +0100, Al Viro wrote:
> On Mon, Oct 08, 2007 at 06:15:51PM -0700, Tim Pepper wrote:
> >
> > When a read() requests an amount of data smaller than the amount of data
> > that the seq_file's foo_show() outputs, the output starts looping and
> > outputs the "stuck" element
On Tue 09 Oct at 02:30:11 +0100 [EMAIL PROTECTED] said:
> On Mon, Oct 08, 2007 at 06:15:51PM -0700, Tim Pepper wrote:
> >
> > - if (&class->lock_entry == all_lock_classes.next)
> > + if (*pos == 0)
> > seq_printf(m, "all lock classes:\n");
>
> Do not generate output outside of ->s
On Mon, Oct 08, 2007 at 06:15:51PM -0700, Tim Pepper wrote:
>
> When a read() requests an amount of data smaller than the amount of data
> that the seq_file's foo_show() outputs, the output starts looping and
> outputs the "stuck" element's data infinitely. There may be multiple
> sequential call
When a read() requests an amount of data smaller than the amount of data
that the seq_file's foo_show() outputs, the output starts looping and
outputs the "stuck" element's data infinitely. There may be multiple
sequential calls to foo_start(), foo_next()/foo_show(), and foo_stop()
for a single o
5 matches
Mail list logo
