[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 09/17] xen/hypfs: move per-node function pointers into a dedicated struct
On 02.12.20 16:36, Jan Beulich wrote:
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,
It is.
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
Thanks.
@@ -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.)
No, not really.
I'll change that.
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|