Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> wrote:

> OK, mc->error must be static data, so no lifetime problems.

Technically, mc->error is only good as long as we hold a ref on its module.
It might be better to copy the string, especially as we can then do
printf-style formatting.

> But is it possible for the compiler to mess this up and reload msg from
> mc->error when it's about to do the user copy, so that if some other thread
> has managed to change mc->error (or is the error state sticky and no further
> operations allowed?) we'd copy from a string with a different length?

Yeah - I need to put a READ_ONCE() in there.

> Where does fs_name now get freed? vfs_fsopen doesn't seem to do it on
> success? (If it did, the fallthrough from err_mc: to err_fs_name: would
> be wrong.)

I'll add a free right after the vfs_fsopen() call before checking the error -
then I can get rid of err_fs_name.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux