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

Re: [PATCH 4/4] sysctl: align handling of unsupported commands


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Milan Djokic <milan_djokic@xxxxxxxx>
  • Date: Tue, 9 Dec 2025 14:05:21 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/kFEARygEVgtismNz/youeB9N5GMG8Y2r7IzauzXu6M=; b=N4Ly9DtUx1T/oNNdgULQmGqA2WVPslS9FiLMw1SrTUxxHQNNtFZyAKGjXZgzMYODoct/kN3M2iHdRR65/aR/lwLsTPr/kX2yEkPFO0oCZ2TbUsy7XjcyTysJ0W2kCfnIlOT8P/fgosmHEl4FkR1JhWg9hP17nkin98sSIJJ2be27Srktv8n6pEkuqFMbMgf0AaDu5VE4032sLDSHFHYqBbshEjaPmXQ8lueLBIkoZrRAQY6E+zbfJ9EzgoYbc7c72iWFfMgwhdeZtnoW+cjdFV9RojLybY8mEn5cEw12MNZMxA9nq8rNzUxsYEFQcP+0d3VSW9B4iiTe+xv0VLMMyA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L0igy82zBHoF0swnnXo/XP6rQ1XvPnpmBX1VzSA16wE+dH2abSbuJTylLbcS/rnWkCdCq2FMyQnbs5+qvCAM2UQvg7j3xE7GWFVJ/3Dg+FXFVB6tZJaU5jI6fzw571AyFh189jmfPTzSK9qBzxyza44Swhx59OdUzJCMoKOEcqT1pK1aCKMDISlWFIfu6ZDCFBqkf83l1ZQ/052ub0sbfUWFgqOIZgzkN/x1Uxfaq9ovbdBNniSbJ8o8BFfzEQ2iEiqwHpJmCm63QjpIQgjHL1Ifyj1FXpTtD6ZVw80cUsiFsT+N7hPuQQwie5bmVrcA3GJ06tJCF3eRAqA8nMbGIQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 09 Dec 2025 13:05:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12/8/25 14:32, Jan Beulich wrote:
On 05.12.2025 21:36, Milan Djokic wrote:
Handling of unsupported sysctl commands currently diverges: some commands
return -EOPNOTSUPP, while others fall back to generic -ENOSYS.

Unify the behavior so that unsupported commands consistently return the
appropriate error code, allowing the control domain to correctly identify
unsupported operations.

Using IS_ENABLED() macro to identify disabled commands, allowing
dead code to be removed at compile time.

Signed-off-by: Milan Djokic <milan_djokic@xxxxxxxx>

Overall quite okay imo, yet there are a number of small issues.

@@ -170,19 +173,22 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
          op->u.availheap.avail_bytes <<= PAGE_SHIFT;
          break;
-#ifdef CONFIG_PM_STATS
      case XEN_SYSCTL_get_pmstat:
-        ret = do_get_pm_info(&op->u.get_pmstat);
+        if ( !IS_ENABLED(CONFIG_PM_STATS) )
+            ret = -EOPNOTSUPP;
+        else
+            ret = do_get_pm_info(&op->u.get_pmstat);
          break;
-#endif
-#ifdef CONFIG_PM_OP
      case XEN_SYSCTL_pm_op:
-        ret = do_pm_op(&op->u.pm_op);
-        if ( ret == -EAGAIN )
-            copyback = 1;
+        if ( !IS_ENABLED(CONFIG_PM_OP) )
+            ret = -EOPNOTSUPP;
+        else {

Misplaced figure brace.

--- a/xen/include/xen/perfc.h
+++ b/xen/include/xen/perfc.h
@@ -92,7 +92,6 @@ DECLARE_PER_CPU(perfc_t[NUM_PERFCOUNTERS], perfcounters);
  #endif
struct xen_sysctl_perfc_op;
-int perfc_control(struct xen_sysctl_perfc_op *pc);
extern void cf_check perfc_printall(unsigned char key);
  extern void cf_check perfc_reset(unsigned char key);
@@ -114,4 +113,7 @@ extern void cf_check perfc_reset(unsigned char key);
#endif /* CONFIG_PERF_COUNTERS */ +struct xen_sysctl_perfc_op;
+extern int perfc_control(struct xen_sysctl_perfc_op *pc);

Why would you move the function decl, but duplicate the struct forward decl?

--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -7,6 +7,7 @@
#include <asm/system.h>
  #include <asm/spinlock.h>
+#include <public/sysctl.h>

Why would this be needed? It means effectively the whole codebase gains a
dependency on this header even when DEBUG_LOCK_PROFILE=n. Yes, you may
need ...

@@ -40,8 +41,6 @@ union lock_debug { };
#ifdef CONFIG_DEBUG_LOCK_PROFILE -#include <public/sysctl.h>
-
  /*
      lock profiling on:
@@ -164,7 +163,6 @@ void _lock_profile_deregister_struct(int32_t type,
  #define lock_profile_deregister_struct(type, ptr)                             
\
      _lock_profile_deregister_struct(type, &((ptr)->profile_head))
-extern int spinlock_profile_control(struct xen_sysctl_lockprof_op *pc);
  extern void cf_check spinlock_profile_printall(unsigned char key);
  extern void cf_check spinlock_profile_reset(unsigned char key);
@@ -360,4 +358,6 @@ static always_inline void nrspin_lock_irq(rspinlock_t *l)
  #define nrspin_unlock_irqrestore(l, f) _nrspin_unlock_irqrestore(l, f)
  #define nrspin_unlock_irq(l)           _nrspin_unlock_irq(l)
+extern int spinlock_profile_control(struct xen_sysctl_lockprof_op *pc);
+
  #endif /* __SPINLOCK_H__ */

... a forward decl of struct xen_sysctl_lockprof_op; I don't see what's
wrong with doing just that.

Jan

I’ll correct these mistakes. Thanks for the suggestions.

BR,
Milan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.