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

Re: [PATCH v7 12/16] emul/ns16550: implement dump_state() hook


  • To: Mykola Kvach <xakep.amatop@xxxxxxxxx>
  • From: dmukhin@xxxxxxxx
  • Date: Thu, 14 May 2026 16:35:28 -0700
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=ford.com; dkim=pass (signature was verified) header.d=saarlouis.ford.com; dkim=pass (signature was verified) header.d=ford.com; arc=none (0)
  • 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=LIj+1mCibHRzkDOLI6NPciksdPra6i7uppubfVT4rMk=; b=n8OwvelyiZRSYOKwTeIKS6nyN6cwLGpg2meKF73izQKt8q4M+LAcgDZjG9RxXLXhIrMW+vZdwpoYfdvQaND9zdrR2qi8ztvLGUAUNNQMWWFnZJ94HttI2tzY16rC2umLzsHzD7A1XQK5wg7ADDkXvEgzAcwmw5O6ownruE9I4TplarZuAobfypAXAG61/vrjiGOK0ggBFjc+btVGQDS5CBslZoFG9DaLXZWPOe4yV8Y/LLHr380VdccDn6gl88IF3mWgpuSzXIEG18y7S6TfQp7VKOSqfLbuVvOZ7uPFYwJdQUGoLAqeVFYXyP3JSyyzSVlRmOi2L1VXTprS8jO0pw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fZBNM4+55XkBoubIy8H2j21BKgfKNVB7BdXIHfCI/4v456i8zkGyZvqQlHuiM4GvP9JdbAhyScRIhKVh9P+nQZGdnsF/9lGJy+DW24vQA2A+MtQSWK8SZenE/9ps+J/t4po9sm9qdeNOddWVdvpYNkyllCdwlZf8yfXUVh0dbqSrXIYTViyheJBxrjB4BP6EYlhD34l7qruYdqUmdfXY4coQDtLxfZiK3sIY+zyY8Erk4W9kpUz1od+uTAKZOCT1aDozBnGVoL6+/zo/e8Kesz05+t7QHv9yw1/SKlWGUuaO6kaBH4NpGPr0iiZB/uLDnyXRSMdizvW4fC29dFnH/A==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, anthony.perard@xxxxxxxxxx, jbeulich@xxxxxxxx, julien@xxxxxxx, michal.orzel@xxxxxxx, roger.pau@xxxxxxxxxx, sstabellini@xxxxxxxxxx, dmukhin@xxxxxxxx
  • Delivery-date: Thu, 14 May 2026 23:35:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Pser-m365-app: SER-APP

On Tue, Nov 18, 2025 at 08:00:00AM +0200, Mykola Kvach wrote:
> Hi Denis,
> 
> Thank you for the patch.
..
> 
> > +static void cf_check ns16x50_dump_state(void *arg)
> > +{
> > +#ifdef CONFIG_VUART_NS16X50_DEBUG
> > +    struct vuart_ns16x50 *vdev = arg;
> > +    const struct domain *d = vdev->owner;
> > +    const struct vuart_info *info = vdev->info;
> > +    const struct xencons_interface *cons;
> > +    const uint8_t *regs;
> > +
> > +    if ( !vdev )
> 
> Is this NULL check actually useful here? At this point we’ve already
> dereferenced vdev (vdev->owner / vdev->info), so if arg could be NULL
> we’d already be in UB. Either the hook never receives NULL (and we can
> drop the check or turn it into ASSERT(vdev)), or the check should be
> moved before the first dereference.

Will promote to ASSERT().

> 
> > +        return;
> > +
> > +    /* Allow printing state in case of a deadlock. */
> > +    if ( !spin_trylock(&vdev->lock) )
> > +        return;
> > +
> > +    cons = &vdev->cons;
> > +    regs = &vdev->regs[0];
> > +
> > +    printk("Virtual " pr_prefix " (%s) I/O port 0x%04x IRQ#%d owner %pd\n",
> > +            vdev->name, info->base_addr, info->irq, d);
> > +
> > +    printk("  RX FIFO size %ld in_prod %d in_cons %d used %d\n",
> > +            ARRAY_SIZE(cons->in), cons->in_prod, cons->in_cons,
> > +            cons->in_prod - cons->in_cons);
> > +
> > +    printk("  TX FIFO size %ld out_prod %d out_cons %d used %d\n",
> > +            ARRAY_SIZE(cons->out), cons->out_prod, cons->out_cons,
> > +            cons->out_prod - cons->out_cons);
> > +
> > +    printk("  %02"PRIx8" RBR %02"PRIx8" THR %02"PRIx8" DLL %02"PRIx8" DLM 
> > %02"PRIx8"\n",
> > +            UART_RBR,
> 
> Should this be using cons->in / cons->out instead of cons?

Yes, it should!
Thanks for the catch!

> 
> > +            cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)],
> > +            cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)],
> 
> As written, MASK_XENCONS_IDX() gets &vdev->cons (struct pointer), not the
> RX/TX arrays themselves, so its size/index calculation will use the size
> of the pointer/struct rather than the in[]/out[] ring size. I think this
> should be:
> 
>     cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)],
>     cons->out[MASK_XENCONS_IDX(cons->out_prod, cons->out)],
> 
> 
> Best regards,
> Mykola



 


Rackspace

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