On Tue, Apr 13, 2021 at 08:54:55PM +0800, Kemeng Shi wrote:
> Yes. And NT stores should be better for copy_page especially copying a lot
> of pages as only partial memory of copied page will be access recently.
I thought "should be better" too last time when I measured rep; movs vs
NT stores but a
+ linux-nvdimm
Original mail at
https://lkml.kernel.org/r/3f28adee-8214-fa8e-b368-eaf8b1934...@huawei.com
On Tue, Apr 13, 2021 at 02:25:58PM +0800, Kemeng Shi wrote:
> I'm using AEP with dax_kmem drvier, and AEP is export as a NUMA node in
What is AEP?
> my system. I will move cold pages from
On Mon, Oct 19, 2020 at 09:08:03PM -0700, Dan Williams wrote:
> The COPY_MC_TEST facility has served its purpose for validating the
> early termination conditions of the copy_mc_fragile() implementation.
> Remove it and the EXPORT_SYMBOL_GPL of copy_mc_fragile().
>
> Reported-by:
On Wed, Sep 30, 2020 at 09:28:33AM -0700, Linus Torvalds wrote:
> Oh, it's pretty much 100%.
Oh good.
> I can't imagine what would make me skip an rc8 at this point.
> Everything looks good right now (but not rc7, we had a stupid bug),
> but I'd rather wait a week than fins another silly bug the
On Wed, Sep 30, 2020 at 08:49:42AM -0700, Dan Williams wrote:
> There's been a paucity of response on these after converging on the
> feedback from Linus. They missed v5.9, and I started casting about for
> what could be done to make sure they did not also miss v5.10 if the
> quiet continued. The p
On Tue, Sep 29, 2020 at 03:32:07PM -0700, Dan Williams wrote:
> Given that Linus was the primary source of review feedback on these
> patches and a version of them have been soaking in -next with only a
> minor conflict report with vfs.git for the entirety of the v5.9-rc
> cycle (left there inadver
On Wed, Sep 23, 2020 at 09:41:33AM -0700, Dan Williams wrote:
> The rename replaces a single top-level memcpy_mcsafe() with either
> copy_mc_to_user(), or copy_mc_to_kernel().
What is "copy_mc" supposed to mean? Especially if it is called that on
two arches...
> diff --git a/arch/x86/Kconfig b/ar
On Mon, Sep 21, 2020 at 09:32:18AM +0200, Greg KH wrote:
> all my local builds are breaking now too with this :(
>
> Was there a proposed patch anywhere for this?
I've disabled CONFIG_BLK_DEV_PMEM which allowed me to de-select those
two:
# CONFIG_DAX is not set
# CONFIG_FS_DAX is not set
and no
ch-set to simplify content creation for a sysfs attribute.
>
> Cc: Piotr Maziarz
> Cc: Cezary Rojewski
> Cc: Christoph Hellwig
> Cc: Steven Rostedt
> Cc: Borislav Petkov
> Acked-by: Steven Rostedt (VMware)
> Signed-off-by: Vaibhav Jain
> ---
> Changelog:
>
&
On Fri, May 08, 2020 at 05:30:31PM +0530, Vaibhav Jain wrote:
> I am referring to Kernel Loadable Modules with MODULE_LICENSE("GPL")
> here.
And what does "external" refer to? Because if it is out-of-tree, we
don't export symbols for out-of-tree modules.
Looks like you're exporting it for that pa
On Fri, May 08, 2020 at 04:19:19PM +0530, Vaibhav Jain wrote:
> 'seq_buf' provides a very useful abstraction for writing to a string
> buffer without needing to worry about it over-flowing. However even
> though the API has been stable for couple of years now its stills not
> exported to external m
On Thu, Feb 21, 2019 at 11:11:27AM -0500, Jeff Moyer wrote:
> Anyway, given that the correctable errors collector can be turned off in
> the kernel config,
Also, on the cmdline, for whatever reason:
ras=cec_disable
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting
On Wed, Feb 20, 2019 at 11:40:10AM -0800, Dan Williams wrote:
> There is a difference. NVDIMMs have local tracking of discovered
> poison, methods to scan for latent poison, and methods to clear. A CEC
> connection, iiuc, would seem an awkward fit. Awkward because what CEC
> enables is meant to be
On Wed, Feb 20, 2019 at 02:26:45PM -0500, Jeff Moyer wrote:
> Sure, thanks for the quick reply, Boris! Also, thanks for your detailed
> commit messages. They really help with understanding the code changes.
Ha!
>From now on I'll be showing that to *anyone* who complains when I ask of
them to ma
Drop stable@
On Wed, Feb 20, 2019 at 01:59:15PM -0500, Jeff Moyer wrote:
> Sorry for necroposting. I thought the point of the CEC was to make sure
> that the other registered decoders only ever saw uncorrected errors.
Ha, good point! You mean drivers/ras/cec.c, right?
If so, then I don't think
On Tue, Nov 06, 2018 at 10:02:46AM -0800, Dan Williams wrote:
> Just general cautiousness, I'm not opposed to squashing them.
Nah, I can keep them separate - I was just wondering why.
> mce_usable_address() should not have any sensitivity to NVDIMM vs DRAM
> MCEs.
Ok.
Thx.
--
Regards/Gruss,
On Tue, Nov 06, 2018 at 08:20:38AM -0800, Dan Williams wrote:
> I recommended the split so the fixes can be tracked and / or reverted
> independently if they cause problems.
Do you have anything concrete in mind that might go wrong or just a
general cautiousness?
Or do you think the hw might not
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
> Cc: sta...@vger.kernel.org
> Cc: Dan Williams
> Cc: Tony Luck
> Cc: Borislav Petkov
> Signed-off-by: Vishal Verma
> ---
> arch/x86/include/asm/mce.h | 1 +
> arch/x86/kernel/
Drop stable@ from CC.
On Wed, Oct 24, 2018 at 02:01:48PM -0600, Vishal Verma wrote:
> We only want a machine check error to be added to libnvdimm's 'badblock'
> if it was an uncorrectable error.
What is libnvdimm's 'badblock' ?
Also, pls write in the commit message *why* you want only UE errors.
On Tue, May 01, 2018 at 07:25:57PM -0700, Dan Williams wrote:
> Right, but the only way to make MCE non-fatal is to teach the machine
> check handler about recoverable conditions. This patch teaches the
> machine check handler how to recover copy_to_iter() errors.
Yeah, about that: maybe we talked
ehab
Cc: Qiuxu Zhuo
Cc: "Rafael J. Wysocki"
Cc: linux-a...@vger.kernel.org
Cc: linux-edac
Cc: linux-nvdimm@lists.01.org
Link: http://lkml.kernel.org/r/20180312182430.10335-6-tony.l...@intel.com
Signed-off-by: Borislav Petkov
---
drivers/edac/Kconfig| 5 +++-
drivers/ed
On Wed, Feb 28, 2018 at 10:36:21AM -0700, Ross Zwisler wrote:
> Just a quick nit - I think we're supposed to use SPDX license identifiers for
> new files?
One would think checkpatch would warn about that but nope.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting an
On Thu, Feb 22, 2018 at 11:58:06AM -0800, Tony Luck wrote:
> This series was posted as RFC and got some review back in December:
>
>https://marc.info/?l=linux-edac&m=151257213825419&w=2
>
> It couldn't go upstream back then because I was waiting for some updates
> to the ACPICA headers for NF
On Tue, Dec 05, 2017 at 02:24:29PM -0800, Luck, Tony wrote:
> So this is what that would look like (on top of existing patches,
> but would be folded into them for next version):
>
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 5c0c4a358f67..7f0bc4cd5086 100644
> --- a/drivers/
On Tue, Dec 05, 2017 at 12:03:37PM -0800, Luck, Tony wrote:
> I could. But what happens when someone ends up on a system with
> an edac driver configured without ACPI_NFIT that does have NVDIMMs?
Same thing when you land on a system with a kernel where the driver for
a piece of hw is not enabled.
On Thu, Nov 30, 2017 at 12:40:42PM -0800, Tony Luck wrote:
> This just covers the topology function of the EDAC driver.
> We locate which DIMM slots are populated with NVDIMMs and
> query the NFIT and SMBIOS tables to get the size.
>
> Signed-off-by: Tony Luck
> ---
> drivers/edac/Kconfig|
On Thu, Nov 30, 2017 at 12:40:41PM -0800, Tony Luck wrote:
> There are now non-volatile versions of DIMMs. Add a new entry to
> "enum mem_type" and update places that use it with new strings.
>
> Signed-off-by: Tony Luck
> ---
> drivers/edac/edac_mc.c | 1 +
> drivers/edac/edac_mc_sysfs.c
On Mon, Dec 04, 2017 at 02:03:16PM -0800, Luck, Tony wrote:
> I take it that you talked yourself out of asking for the cleanup now?
:-)
Nah, it was just a thinking-out-loud thing. Doesn't make sense to do the
cleanup, it seems.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
On Thu, Nov 30, 2017 at 12:40:40PM -0800, Tony Luck wrote:
> When we first scan the SMBIOS table, save the size of the DIMM.
>
> Provide a function for other code (EDAC driver) to look up the size
> of a DIMM from its SMBIOS handle.
>
> Signed-off-by: Tony Luck
> ---
> drivers/firmware/dmi_scan
On Wed, May 17, 2017 at 06:58:00PM +, Verma, Vishal L wrote:
> Quick/minor observation - you moved the EXPORT_SYMBOL_GPL into your
Yes, it belongs there conceptually.
> original patch, but the commit message of mine still talks about
> exporting. Perhaps it should read:
>
> "Use the new mce_
On Wed, May 10, 2017 at 10:22:32PM +, Verma, Vishal L wrote:
> > I'll prep the queue next week and run tests.
> >
> Ok, Thanks Boris!
Ok, I've pushed a branch:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=tip-ras-pending
Please have a look, test, poke, etc...
Thanks.
-
On Wed, May 10, 2017 at 10:03:42PM +, Verma, Vishal L wrote:
> ... Depending on how frequently machine checks happen that are not
> memory errors but have the addr field set (hopefully rare anyway), we
> could be incorrectly marking a lot of locations as media errors.
Sounds serious enough to
On Wed, May 10, 2017 at 09:12:12PM +, Verma, Vishal L wrote:
> The memory error check in the nfit handler is a valid, and simple fix.
I need the big picture here: "Without this fix, the nfit handler ...".
Then, if the stable rules apply, we can always expedite it through
urgent/stable.
--
R
On Wed, May 10, 2017 at 08:06:53PM +, Verma, Vishal L wrote:
> Ah I was under the impression that this can go in for 4.12..
... and the reason for hurrying it into 4.12 is?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
On Wed, May 10, 2017 at 07:31:30PM +, Verma, Vishal L wrote:
> I didn't see the above patches in the RAS branches of the tip tree -
You need to be patient - we have merge window right now. Next week,
after -rc1 releases, it is business as usual again.
--
Regards/Gruss,
Boris.
Good maili
From: Borislav Petkov
Date: Mon, 24 Apr 2017 13:19:34 +0200
Subject: [PATCH 2/2] x86/ras/mce_amd_inj: Preset MCE injection struct
Populate the MCE injection struct before doing initial injection so that
values which don't change already have proper values.
Signed-off-by: Borislav P
From: Borislav Petkov
Date: Mon, 24 Apr 2017 13:16:50 +0200
Subject: [PATCH 1/2] x86/MCE: Export memory_error()
Export the function which checks whether an MCE is a memory error to
other users so that we can reuse the logic. Drop the boot_cpu_data use,
while at it, as mce.cpuvendor already has
On Fri, Apr 21, 2017 at 01:27:41PM -0700, Luck, Tony wrote:
> Boris: you coded up a "static bool memory_error(struct mce *m)"
> function inside the patches for the corrected error thingy.
>
> Perhaps when it goes upstream it should be available for other
> users too?
I don't see why not. struct m
On Thu, Apr 13, 2017 at 01:31:59PM +0200, Borislav Petkov wrote:
> @@ -321,18 +321,8 @@ static void __print_mce(struct mce *m)
>
> static void print_mce(struct mce *m)
> {
> - int ret = 0;
> -
> __print_mce(m);
> -
> - /*
> - * Print out human-
On Thu, Apr 13, 2017 at 12:29:25AM +0200, Borislav Petkov wrote:
> On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote:
> > We can futz with that and have them specify which chain (or both)
> > that they want to be added to.
>
> Well, I didn't want the atomic chai
On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote:
> We can futz with that and have them specify which chain (or both)
> that they want to be added to.
Well, I didn't want the atomic chain to be a notifier because we can
keep it simple and non-blocking. Only the process context one will b
On Wed, Apr 12, 2017 at 11:47:49PM +0200, Borislav Petkov wrote:
> so we need to think about something better to handle events down the
> whole chain. Maybe route events from the atomic path to the blocking
> path where the sleeping notifier callbacks can sleep as much as they
On Wed, Apr 12, 2017 at 02:19:32PM -0700, Luck, Tony wrote:
> On Wed, Apr 12, 2017 at 11:12:21PM +0200, Thomas Gleixner wrote:
> > There is another solution:
> >
> > Convert the notifier to a blocking notifier and in the panic case, ignore
> > the locking and invoke the notifier chain directly. Th
On Wed, Apr 12, 2017 at 08:27:05PM +, Verma, Vishal L wrote:
> But isn't the atomic notifier call chain always called in atomic
> context?
No, it isn't. We're calling it in normal process context in
mce_gen_pool_process() too.
So this early exit will avoid any sleeping in atomic context. And
On Wed, Apr 12, 2017 at 01:59:03PM -0600, Vishal Verma wrote:
> I don't think we can do anything about the panic path errors.
Then the fix should be a lot easier:
---
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index 3ba1c3472cf9..44c092ec2ac9 100644
--- a/drivers/acpi/nfit/mce
where we can take
> mutexes etc. in the call chain functions.
>
> Reported-by: Ross Zwisler
> Cc: Borislav Petkov
> Cc: Tony Luck
> Cc: Dan Williams
> Signed-off-by: Vishal Verma
> ---
> arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +-
> arch/x86/kernel/cpu/mcheck/mce
46 matches
Mail list logo
