On Thu, Sep 20, 2001 at 02:33:34PM -0400, Alexander Viro wrote:
>
>
> On Thu, 20 Sep 2001, Andrea Arcangeli wrote:
>
> > > > + truncate_inode_pages(rd_inode[minor]->i_mapping, 0);
> > > > rd_inode[minor] = NULL;
> > > > rd_blocksizes[minor] = rd_blocksize;
> > > > + unlock:
> > > > up(&bdev->bd_sem);
> > >
> > > Now think what happens if you go through that code twice. What argument will
> > > be passed to iput() the second time you call it?
> >
> > the second time we won't go through that code.
>
> IOW, subsequent calls of ioctl(fd, BLKFLSBUF) will not work. Which is
> better than oopsing, but doesn't look right.
The second call will do the work if there's something to do. If somebody
did an open/read/writes/close in the middle, it should do the work as
usual. I actually can see a problem if you use the different inodes, but
that will be sorted out too automatically as soon as we stop pinning the
inodes.
> Question: why the hell do we bother with iput() and decrementing counters
> at all?
Yes, that part should be rewritten using the bdev as you did recently,
the ipinning of the ramdisk also in the previous 2.4 kernels (before
your recent patch) had the same problem of my ipinning in the blkdev
highlevel (it looked only a cleanup but it wasn't).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:39 EST