From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Juergen Gross <jgross@suse.com>,
Jeremy Fitzhardinge <jeremy@xensource.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Chris Wright <chrisw@sous-sol.org>,
Jan Beulich <jbeulich@suse.com>, Olof Johansson <olof@lixom.net>,
xen-devel@lists.xenproject.org,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Jiri Slaby <jirislaby@kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] hvc/xen: prevent concurrent accesses to the shared ring
Date: Wed, 30 Nov 2022 10:26:07 +0100 [thread overview]
Message-ID: <Y4chryL2YvfhgQmk@Air-de-Roger> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2211291351160.4039@ubuntu-linux-20-04-desktop>
On Tue, Nov 29, 2022 at 02:12:10PM -0800, Stefano Stabellini wrote:
> On Tue, 29 Nov 2022, Roger Pau Monne wrote:
> > The hvc machinery registers both a console and a tty device based on
> > the hv ops provided by the specific implementation. Those two
> > interfaces however have different locks, and there's no single locks
> > that's shared between the tty and the console implementations, hence
> > the driver needs to protect itself against concurrent accesses.
> > Otherwise concurrent calls using the split interfaces are likely to
> > corrupt the ring indexes, leaving the console unusable.
> >
> > Introduce a lock to xencons_info to serialize accesses to the shared
> > ring. This is only required when using the shared memory console,
> > concurrent accesses to the hypercall based console implementation are
> > not an issue.
> >
> > Note the conditional logic in domU_read_console() is slightly modified
> > so the notify_daemon() call can be done outside of the locked region:
> > it's an hypercall and there's no need for it to be done with the lock
> > held.
> >
> > Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > While the write handler (domU_write_console()) is used by both the
> > console and the tty ops, that's not the case for the read side
> > (domU_read_console()). It's not obvious to me whether we could get
> > concurrent poll calls from the poll_get_char tty hook, hence stay on
> > the safe side also serialize read accesses in domU_read_console().
>
> I think domU_read_console doesn't need it. struct hv_ops and struct
> console are both already locked although independently locked.
>
> I think we shouldn't add an unrequired lock there.
Not all accesses are done using the tty lock. There's a path using
tty_find_polling_driver() in kgdboc.c that directly calls into the
->poll_get_char() hook without any locks apparently taken.
>
> > ---
> > drivers/tty/hvc/hvc_xen.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 7c23112dc923..d65741983837 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -43,6 +43,7 @@ struct xencons_info {
> > int irq;
> > int vtermno;
> > grant_ref_t gntref;
> > + spinlock_t ring_lock;
> > };
> >
> > static LIST_HEAD(xenconsoles);
> > @@ -84,12 +85,15 @@ static int __write_console(struct xencons_info *xencons,
> > XENCONS_RING_IDX cons, prod;
> > struct xencons_interface *intf = xencons->intf;
> > int sent = 0;
> > + unsigned long flags;
> >
> > + spin_lock_irqsave(&xencons->ring_lock, flags);
> > cons = intf->out_cons;
> > prod = intf->out_prod;
> > mb(); /* update queue values before going on */
> >
> > if ((prod - cons) > sizeof(intf->out)) {
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> > pr_err_once("xencons: Illegal ring page indices");
> > return -EINVAL;
> > }
> > @@ -99,6 +103,7 @@ static int __write_console(struct xencons_info *xencons,
> >
> > wmb(); /* write ring before updating pointer */
> > intf->out_prod = prod;
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> >
> > if (sent)
> > notify_daemon(xencons);
> > @@ -141,16 +146,19 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
> > int recv = 0;
> > struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> > unsigned int eoiflag = 0;
> > + unsigned long flags;
> >
> > if (xencons == NULL)
> > return -EINVAL;
> > intf = xencons->intf;
> >
> > + spin_lock_irqsave(&xencons->ring_lock, flags);
> > cons = intf->in_cons;
> > prod = intf->in_prod;
> > mb(); /* get pointers before reading ring */
> >
> > if ((prod - cons) > sizeof(intf->in)) {
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> > pr_err_once("xencons: Illegal ring page indices");
> > return -EINVAL;
> > }
> > @@ -174,10 +182,13 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
> > xencons->out_cons = intf->out_cons;
> > xencons->out_cons_same = 0;
> > }
> > + if (!recv && xencons->out_cons_same++ > 1) {
> > + eoiflag = XEN_EOI_FLAG_SPURIOUS;
> > + }
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> > +
> > if (recv) {
> > notify_daemon(xencons);
> > - } else if (xencons->out_cons_same++ > 1) {
> > - eoiflag = XEN_EOI_FLAG_SPURIOUS;
> > }
> >
> > xen_irq_lateeoi(xencons->irq, eoiflag);
> > @@ -576,6 +587,7 @@ static int __init xen_hvc_init(void)
> >
> > info = vtermno_to_xencons(HVC_COOKIE);
> > info->irq = bind_evtchn_to_irq_lateeoi(info->evtchn);
> > + spin_lock_init(&info->ring_lock);
>
> Don't we also need a call to spin_lock_init in xencons_connect_backend
> and xen_cons_init and xenboot_console_setup ?
Not in xencons_connect_backend(), as that's called on resume. Will
fix the missing lock init, didn't realize the console init paths are
so convoluted.
Early PV console on the shared ring worked fine, I wonder why that
didn't explode.
Thanks, Roger.
WARNING: multiple messages have this Message-ID (diff)
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Juergen Gross <jgross@suse.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Jan Beulich <jbeulich@suse.com>, Olof Johansson <olof@lixom.net>,
Ingo Molnar <mingo@elte.hu>,
Jeremy Fitzhardinge <jeremy@xensource.com>,
Chris Wright <chrisw@sous-sol.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] hvc/xen: prevent concurrent accesses to the shared ring
Date: Wed, 30 Nov 2022 10:26:07 +0100 [thread overview]
Message-ID: <Y4chryL2YvfhgQmk@Air-de-Roger> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2211291351160.4039@ubuntu-linux-20-04-desktop>
On Tue, Nov 29, 2022 at 02:12:10PM -0800, Stefano Stabellini wrote:
> On Tue, 29 Nov 2022, Roger Pau Monne wrote:
> > The hvc machinery registers both a console and a tty device based on
> > the hv ops provided by the specific implementation. Those two
> > interfaces however have different locks, and there's no single locks
> > that's shared between the tty and the console implementations, hence
> > the driver needs to protect itself against concurrent accesses.
> > Otherwise concurrent calls using the split interfaces are likely to
> > corrupt the ring indexes, leaving the console unusable.
> >
> > Introduce a lock to xencons_info to serialize accesses to the shared
> > ring. This is only required when using the shared memory console,
> > concurrent accesses to the hypercall based console implementation are
> > not an issue.
> >
> > Note the conditional logic in domU_read_console() is slightly modified
> > so the notify_daemon() call can be done outside of the locked region:
> > it's an hypercall and there's no need for it to be done with the lock
> > held.
> >
> > Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > While the write handler (domU_write_console()) is used by both the
> > console and the tty ops, that's not the case for the read side
> > (domU_read_console()). It's not obvious to me whether we could get
> > concurrent poll calls from the poll_get_char tty hook, hence stay on
> > the safe side also serialize read accesses in domU_read_console().
>
> I think domU_read_console doesn't need it. struct hv_ops and struct
> console are both already locked although independently locked.
>
> I think we shouldn't add an unrequired lock there.
Not all accesses are done using the tty lock. There's a path using
tty_find_polling_driver() in kgdboc.c that directly calls into the
->poll_get_char() hook without any locks apparently taken.
>
> > ---
> > drivers/tty/hvc/hvc_xen.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 7c23112dc923..d65741983837 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -43,6 +43,7 @@ struct xencons_info {
> > int irq;
> > int vtermno;
> > grant_ref_t gntref;
> > + spinlock_t ring_lock;
> > };
> >
> > static LIST_HEAD(xenconsoles);
> > @@ -84,12 +85,15 @@ static int __write_console(struct xencons_info *xencons,
> > XENCONS_RING_IDX cons, prod;
> > struct xencons_interface *intf = xencons->intf;
> > int sent = 0;
> > + unsigned long flags;
> >
> > + spin_lock_irqsave(&xencons->ring_lock, flags);
> > cons = intf->out_cons;
> > prod = intf->out_prod;
> > mb(); /* update queue values before going on */
> >
> > if ((prod - cons) > sizeof(intf->out)) {
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> > pr_err_once("xencons: Illegal ring page indices");
> > return -EINVAL;
> > }
> > @@ -99,6 +103,7 @@ static int __write_console(struct xencons_info *xencons,
> >
> > wmb(); /* write ring before updating pointer */
> > intf->out_prod = prod;
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> >
> > if (sent)
> > notify_daemon(xencons);
> > @@ -141,16 +146,19 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
> > int recv = 0;
> > struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> > unsigned int eoiflag = 0;
> > + unsigned long flags;
> >
> > if (xencons == NULL)
> > return -EINVAL;
> > intf = xencons->intf;
> >
> > + spin_lock_irqsave(&xencons->ring_lock, flags);
> > cons = intf->in_cons;
> > prod = intf->in_prod;
> > mb(); /* get pointers before reading ring */
> >
> > if ((prod - cons) > sizeof(intf->in)) {
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> > pr_err_once("xencons: Illegal ring page indices");
> > return -EINVAL;
> > }
> > @@ -174,10 +182,13 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
> > xencons->out_cons = intf->out_cons;
> > xencons->out_cons_same = 0;
> > }
> > + if (!recv && xencons->out_cons_same++ > 1) {
> > + eoiflag = XEN_EOI_FLAG_SPURIOUS;
> > + }
> > + spin_unlock_irqrestore(&xencons->ring_lock, flags);
> > +
> > if (recv) {
> > notify_daemon(xencons);
> > - } else if (xencons->out_cons_same++ > 1) {
> > - eoiflag = XEN_EOI_FLAG_SPURIOUS;
> > }
> >
> > xen_irq_lateeoi(xencons->irq, eoiflag);
> > @@ -576,6 +587,7 @@ static int __init xen_hvc_init(void)
> >
> > info = vtermno_to_xencons(HVC_COOKIE);
> > info->irq = bind_evtchn_to_irq_lateeoi(info->evtchn);
> > + spin_lock_init(&info->ring_lock);
>
> Don't we also need a call to spin_lock_init in xencons_connect_backend
> and xen_cons_init and xenboot_console_setup ?
Not in xencons_connect_backend(), as that's called on resume. Will
fix the missing lock init, didn't realize the console init paths are
so convoluted.
Early PV console on the shared ring worked fine, I wonder why that
didn't explode.
Thanks, Roger.
next prev parent reply other threads:[~2022-11-30 9:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 12:01 [PATCH] hvc/xen: prevent concurrent accesses to the shared ring Roger Pau Monne
2022-11-29 12:01 ` Roger Pau Monne
2022-11-29 22:12 ` Stefano Stabellini
2022-11-29 22:12 ` Stefano Stabellini
2022-11-30 9:26 ` Roger Pau Monné [this message]
2022-11-30 9:26 ` Roger Pau Monné
2022-11-30 9:34 ` Jan Beulich
2022-11-30 9:34 ` Jan Beulich
2022-11-30 10:10 ` Roger Pau Monné
2022-11-30 10:10 ` Roger Pau Monné
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=Y4chryL2YvfhgQmk@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=chrisw@sous-sol.org \
--cc=gregkh@linuxfoundation.org \
--cc=jbeulich@suse.com \
--cc=jeremy@xensource.com \
--cc=jgross@suse.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@elte.hu \
--cc=olof@lixom.net \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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.