On Wed, 2007-11-28 at 00:41 -0800, Andrew Morton wrote:
> Given that nameidata_to_filp() can call path_release() which "destroys the
> original nameidata", it looks like this was always buggy?
It does. I can see how I introduced the bug, and your fix does look
like a good one. Thanks.
-- Dave
On Thu, 20 Sep 2007 12:52:56 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> This is the first really tricky patch in the series. It
> elevates the writer count on a mount each time a
> non-special file is opened for write.
>
> This is not completely apparent in the patch because the
> two if()
On Thu, 20 Sep 2007 12:52:56 -0700 Dave Hansen [EMAIL PROTECTED] wrote:
This is the first really tricky patch in the series. It
elevates the writer count on a mount each time a
non-special file is opened for write.
This is not completely apparent in the patch because the
two if()
On Wed, 2007-11-28 at 00:41 -0800, Andrew Morton wrote:
Given that nameidata_to_filp() can call path_release() which destroys the
original nameidata, it looks like this was always buggy?
It does. I can see how I introduced the bug, and your fix does look
like a good one. Thanks.
-- Dave
-
This is the first really tricky patch in the series. It
elevates the writer count on a mount each time a
non-special file is opened for write.
This is not completely apparent in the patch because the
two if() conditions in may_open() above the
mnt_want_write() call are, combined, equivalent to
This is the first really tricky patch in the series. It
elevates the writer count on a mount each time a
non-special file is opened for write.
This is not completely apparent in the patch because the
two if() conditions in may_open() above the
mnt_want_write() call are, combined, equivalent to
6 matches
Mail list logo
