public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Harald Freudenberger <freude@linux.ibm.com>,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH 4/4] s390/uaccess: remove set_fs() interface
Date: Wed, 16 Sep 2020 14:36:03 +0200	[thread overview]
Message-ID: <20200916123603.GC7076@osiris> (raw)
In-Reply-To: <20200915193755.GA8528@osiris>

On Tue, Sep 15, 2020 at 09:37:55PM +0200, Heiko Carstens wrote:
> On Tue, Sep 15, 2020 at 06:02:43PM +0200, Christoph Hellwig wrote:
> > That logic always confused me and still keeps confusing me,
> > dumb questions below:
...
> > > +	bool old;
> > >  
> > > -	old_fs = enable_sacf_uaccess();
> > > +	old = enable_sacf_uaccess();
> > >  	switch (op) {
> > >  	case FUTEX_OP_SET:
> > >  		__futex_atomic_op("lr %2,%5\n",
> > > @@ -53,7 +53,7 @@ static inline int arch_futex_atomic_op_inuser(int op, int oparg, int *oval,
> > >  	default:
> > >  		ret = -ENOSYS;
> > >  	}
> > > -	disable_sacf_uaccess(old_fs);
> > > +	disable_sacf_uaccess(old);
> > 
> > Do we need to return the old value here?  The way I understand it
> > this is context switched with the thread, and given that only small
> > isolated code bases now use it, sacf use can't nest, can it?
> 
> I just realized that this is broken for uaccess in irq context
> (e.g. copy_from_user_nofault()). With set_fs() removal the calls to
> force_uaccess_begin()/end() will do nothing, while before
> set_fs(USER_DS) actually enforced that control registers on s390 were
> setup correctly.
> This wouldn't be the case anymore now. If e.g. a code sequence within
> enable_sacf_uaccess() would be interrupted, and from within interrupt
> context copy_from_user_nofault() would be executed, this would read
> from kernel space instead from user space.
> 
> Needs fix.

So, I can think of several ways to fix this (or better: make this
robust). However given that I will be away the next two weeks this is
not going to happen for the upcoming merge window. I really don't want
to rush this, since this has potential for severe subtle bugs... like
we had them already several times with our address space and dynamic
page table upgrade handling in the past (and like I nearly introduced
at least one bug with this patch).

Therefore the first three patches of this series are scheduled for the
upcoming merge window, while the final set_fs() removal should come
one merge later.

  reply	other threads:[~2020-09-16 17:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 15:43 [PATCH 0/4] s390: set_fs() removal Heiko Carstens
2020-09-15 15:43 ` [PATCH 1/4] s390/zcrypt: remove set_fs() invocation in zcrypt device driver Heiko Carstens
2020-09-15 15:43 ` [PATCH 2/4] s390/dis: get rid of set_fs() usage Heiko Carstens
2020-09-15 15:52   ` Christoph Hellwig
2020-09-15 16:55     ` Heiko Carstens
2020-09-15 15:43 ` [PATCH 3/4] s390/uaccess: implement HAVE_GET_KERNEL_NOFAULT support Heiko Carstens
2020-09-15 15:43 ` [PATCH 4/4] s390/uaccess: remove set_fs() interface Heiko Carstens
2020-09-15 16:02   ` Christoph Hellwig
2020-09-15 16:49     ` Heiko Carstens
2020-09-15 19:37     ` Heiko Carstens
2020-09-16 12:36       ` Heiko Carstens [this message]
2020-11-25  8:38         ` Christoph Hellwig
2020-11-25  8:51           ` Christian Borntraeger
2020-11-25 16:36             ` Christoph Hellwig

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=20200916123603.GC7076@osiris \
    --to=hca@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=linux-s390@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox