On 01.12.2020 09:21, Juergen Gross wrote:
> @@ -297,6 +321,7 @@ int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
> int ret;
>
> ASSERT(this_cpu(hypfs_locked) == hypfs_write_locked);
> + ASSERT(leaf->e.max_size);
>
> if ( ulen > leaf->e.max_size )
> return -ENOSPC;
> @@ -357,6 +382,7 @@ int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
> int ret;
>
> ASSERT(this_cpu(hypfs_locked) == hypfs_write_locked);
> + ASSERT(leaf->e.max_size);
>
> /* Avoid oversized buffer allocation. */
> if ( ulen > MAX_PARAM_SIZE )
At the first glance both of these hunks look as if they
wouldn't belong here, but I guess the ASSERT()s are getting
lifted here from hypfs_write(). (The first looks even somewhat
redundant with the immediately following if().) If this
understanding of mine is correct,
Reviewed-by: Jan Beulich <jbeul...@suse.com>
> @@ -382,19 +408,20 @@ int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
> return ret;
> }
>
> +int hypfs_write_deny(struct hypfs_entry_leaf *leaf,
> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned int ulen)
> +{
> + return -EACCES;
> +}
> +
> static int hypfs_write(struct hypfs_entry *entry,
> XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
> ulen)
As a tangent, is there a reason these write functions don't take
handles of "const void"? (I realize this likely is nothing that
wants addressing right here.)
Jan
