All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	YueHaibing <yuehaibing@huawei.com>,
	"Simon Gaiser" <simon@invisiblethingslab.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] xen-pciback: optionally allow interrupt enable flag writes
Date: Thu, 19 Dec 2019 12:20:24 +0100	[thread overview]
Message-ID: <c0e27fbe-e2f7-22ca-c3f4-bafb252c7bcc@suse.com> (raw)
In-Reply-To: <20191219034941.19141-1-marmarek@invisiblethingslab.com>

On 19.12.2019 04:49, Marek Marczykowski-Górecki  wrote:
> +enum interrupt_type xen_pcibk_get_interrupt_type(struct pci_dev *dev)
> +{
> +	int err;
> +	u16 val;
> +
> +	err = pci_read_config_word(dev, PCI_COMMAND, &val);
> +	if (err)
> +		return INTERRUPT_TYPE_ERR;
> +	if (!(val & PCI_COMMAND_INTX_DISABLE))
> +		return INTERRUPT_TYPE_INTX;
> +
> +	/* Do not trust dev->msi(x)_enabled here, as enabling could be done
> +	 * bypassing the pci_*msi* functions, by the qemu.
> +	 */

Judging from this comment, how can you assume only one of the
three variants is actually enabled? It's against the spec, yes,
but it's not at all impossible afaict. I think you want the
return value here to be
- negative errno values (no need to discard the actual error
  codes) or
- a non-negative bitmap indicating which of the interrupt types
  is/are currently enabled.
That way ...

> +static int msi_msix_flags_write(struct pci_dev *dev, int offset, u16 new_value,
> +				void *data)
> +{
> +	int err;
> +	u16 old_value;
> +	const struct msi_msix_field_config *field_config = data;
> +	const struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(dev);
> +
> +	if (xen_pcibk_permissive || dev_data->permissive)
> +		goto write;
> +
> +	err = pci_read_config_word(dev, offset, &old_value);
> +	if (err)
> +		return err;
> +
> +	if (new_value == old_value)
> +		return 0;
> +
> +	if (!dev_data->allow_interrupt_control ||
> +	    (new_value ^ old_value) & ~field_config->enable_bit)
> +		return PCIBIOS_SET_FAILED;
> +
> +	if (new_value & field_config->enable_bit) {
> +		/* don't allow enabling together with other interrupt types */
> +		const enum interrupt_type int_type = xen_pcibk_get_interrupt_type(dev);
> +		if (int_type == INTERRUPT_TYPE_NONE ||
> +		    int_type == field_config->int_type)

... equality comparisons like this one will actually become safe.

Jan

WARNING: multiple messages have this Message-ID (diff)
From: Jan Beulich <jbeulich@suse.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: "Juergen Gross" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	YueHaibing <yuehaibing@huawei.com>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Simon Gaiser" <simon@invisiblethingslab.com>,
	xen-devel@lists.xenproject.org,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen-pciback: optionally allow interrupt enable flag writes
Date: Thu, 19 Dec 2019 12:20:24 +0100	[thread overview]
Message-ID: <c0e27fbe-e2f7-22ca-c3f4-bafb252c7bcc@suse.com> (raw)
In-Reply-To: <20191219034941.19141-1-marmarek@invisiblethingslab.com>

On 19.12.2019 04:49, Marek Marczykowski-Górecki  wrote:
> +enum interrupt_type xen_pcibk_get_interrupt_type(struct pci_dev *dev)
> +{
> +	int err;
> +	u16 val;
> +
> +	err = pci_read_config_word(dev, PCI_COMMAND, &val);
> +	if (err)
> +		return INTERRUPT_TYPE_ERR;
> +	if (!(val & PCI_COMMAND_INTX_DISABLE))
> +		return INTERRUPT_TYPE_INTX;
> +
> +	/* Do not trust dev->msi(x)_enabled here, as enabling could be done
> +	 * bypassing the pci_*msi* functions, by the qemu.
> +	 */

Judging from this comment, how can you assume only one of the
three variants is actually enabled? It's against the spec, yes,
but it's not at all impossible afaict. I think you want the
return value here to be
- negative errno values (no need to discard the actual error
  codes) or
- a non-negative bitmap indicating which of the interrupt types
  is/are currently enabled.
That way ...

> +static int msi_msix_flags_write(struct pci_dev *dev, int offset, u16 new_value,
> +				void *data)
> +{
> +	int err;
> +	u16 old_value;
> +	const struct msi_msix_field_config *field_config = data;
> +	const struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(dev);
> +
> +	if (xen_pcibk_permissive || dev_data->permissive)
> +		goto write;
> +
> +	err = pci_read_config_word(dev, offset, &old_value);
> +	if (err)
> +		return err;
> +
> +	if (new_value == old_value)
> +		return 0;
> +
> +	if (!dev_data->allow_interrupt_control ||
> +	    (new_value ^ old_value) & ~field_config->enable_bit)
> +		return PCIBIOS_SET_FAILED;
> +
> +	if (new_value & field_config->enable_bit) {
> +		/* don't allow enabling together with other interrupt types */
> +		const enum interrupt_type int_type = xen_pcibk_get_interrupt_type(dev);
> +		if (int_type == INTERRUPT_TYPE_NONE ||
> +		    int_type == field_config->int_type)

... equality comparisons like this one will actually become safe.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-12-19 11:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19  3:49 [PATCH v2] xen-pciback: optionally allow interrupt enable flag writes Marek Marczykowski-Górecki
2019-12-19  3:49 ` [Xen-devel] " Marek Marczykowski-Górecki
2019-12-19 11:20 ` Jan Beulich [this message]
2019-12-19 11:20   ` Jan Beulich
2019-12-19 12:57   ` Marek Marczykowski-Górecki
2019-12-19 12:57     ` [Xen-devel] " Marek Marczykowski-Górecki
2019-12-20 19:11 ` Boris Ostrovsky
2019-12-20 19:11   ` [Xen-devel] " Boris Ostrovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0e27fbe-e2f7-22ca-c3f4-bafb252c7bcc@suse.com \
    --to=jbeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=roger.pau@citrix.com \
    --cc=simon@invisiblethingslab.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.