[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 Attachment:
OpenPGP_signature
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |