From: "jarkko@kernel.org" <jarkko@kernel.org>
To: "Huang, Kai" <kai.huang@intel.com>
Cc: "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"pmenzel@molgen.mpg.de" <pmenzel@molgen.mpg.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"Dhanraj, Vijay" <vijay.dhanraj@intel.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"x86@kernel.org" <x86@kernel.org>,
"haitao.huang@linux.intel.com" <haitao.huang@linux.intel.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] x86/sgx: Do not fail on incomplete sanitization on premature stop of ksgxd
Date: Mon, 5 Sep 2022 12:44:56 +0300 [thread overview]
Message-ID: <YxXFGLSmRri2T1yb@kernel.org> (raw)
In-Reply-To: <a5fa56bdc57d6472a306bd8d795afc674b724538.camel@intel.com>
On Mon, Sep 05, 2022 at 07:50:33AM +0000, Huang, Kai wrote:
> On Sat, 2022-09-03 at 13:26 +0300, Jarkko Sakkinen wrote:
> > > static int ksgxd(void *p)
> > > {
> > > + unsigned long left_dirty;
> > > +
> > > set_freezable();
> > >
> > > /*
> > > * Sanitize pages in order to recover from kexec(). The 2nd pass is
> > > * required for SECS pages, whose child pages blocked EREMOVE.
> > > */
> > > - __sgx_sanitize_pages(&sgx_dirty_page_list);
> > > - __sgx_sanitize_pages(&sgx_dirty_page_list);
> > > + left_dirty = __sgx_sanitize_pages(&sgx_dirty_page_list);
> > > + pr_debug("%ld unsanitized pages\n", left_dirty);
> > %lu
> >
>
> I assume the intention is to print out the unsanitized SECS pages, but what is
> the value of printing it? To me it doesn't provide any useful information, even
> for debug.
How do you measure "useful"?
If for some reason there were unsanitized pages, I would at least
want to know where it ended on the first value.
Plus it does zero harm unless you explicitly turn it on.
> Besides, the first call of __sgx_sanitize_pages() can return 0, due to either
> kthread_should_stop() being true, or all EPC pages are EREMOVED successfully.
> So in this case kernel will print out "0 unsanitized pages\n", which doesn't
> make a lot sense?
>
> > >
> > > - /* sanity check: */
> > > - WARN_ON(!list_empty(&sgx_dirty_page_list));
> > > + left_dirty = __sgx_sanitize_pages(&sgx_dirty_page_list);
> > > + /*
> > > + * Never expected to happen in a working driver. If it happens the
> > > bug
> > > + * is expected to be in the sanitization process, but successfully
> > > + * sanitized pages are still valid and driver can be used and most
> > > + * importantly debugged without issues. To put short, the global
> > > state
> > > + * of kernel is not corrupted so no reason to do any more
> > > complicated
> > > + * rollback.
> > > + */
> > > + if (left_dirty)
> > > + pr_err("%ld unsanitized pages\n", left_dirty);
> > %lu
>
> No strong opinion, but IMHO we can still just WARN() when it is driver bug:
>
> 1) There's no guarantee the driver can continue to work if it has bug;
>
> 2) WARN() can panic() the kernel if /proc/sys/kernel/panic_on_warn is set is
> fine. It's expected behaviour. If I understand correctly, there are many
> places in the kernel that uses WARN() to catch bugs.
>
> In fact, we can even view WARN() as an advantage. For instance, if we only print
> out "xx unsanitized pages" in the existing code, people may even wouldn't have
> noticed this bug.
>
> From this perspective, if you want to print out, I think you may want to make
> the message more visible, that people can know it's driver bug. Perhaps
> something like "The driver has bug, please report to kernel community..", etc.
>
> 3) Changing WARN() to pr_err() conceptually isn't mandatory to fix this
> particular bug. So, it's kinda mixing things together.
>
> But again, no strong opinion here.
>
> --
> Thanks,
> -Kai
>
>
BR, Jarkko
next prev parent reply other threads:[~2022-09-05 9:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-03 6:01 [PATCH 0/2] x86/sgx: Fixes for v6.0 Jarkko Sakkinen
2022-09-03 6:01 ` [PATCH 1/2] x86/sgx: Do not fail on incomplete sanitization on premature stop of ksgxd Jarkko Sakkinen
2022-09-03 10:26 ` Jarkko Sakkinen
2022-09-05 7:50 ` Huang, Kai
2022-09-05 9:44 ` jarkko [this message]
2022-09-05 10:17 ` jarkko
2022-09-05 11:32 ` Huang, Kai
2022-09-03 6:01 ` [PATCH 2/2] x86/sgx: Handle VA page allocation failure for EAUG on PF Jarkko Sakkinen
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=YxXFGLSmRri2T1yb@kernel.org \
--to=jarkko@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kai.huang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pmenzel@molgen.mpg.de \
--cc=reinette.chatre@intel.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vijay.dhanraj@intel.com \
--cc=x86@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 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.