> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
>
> Could we please have a description of that? So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix t
> Should this not also have a capability check. Assuming file permissions
> are sufficient for grabbing a chunk of system memory holding error
> info doesn't seem too scary but it's at odds with a lot of other cases ?
At least one of those other cases (pstore) added a capability check and now
reg
On Mon, Jun 19, 2017 at 08:01:47PM +0200, Borislav Petkov wrote:
> (drop stable from CC)
>
> You could use git's --suppress-cc= option when sending.
I would if I could work out how to use it. From reading the manual
page there seem to be a few options to this, but none of them appear
to just drop
On Wed, Jun 21, 2017 at 02:12:27AM +, Naoya Horiguchi wrote:
> We had better have a reverse operation of this to cancel the unmapping
> when unpoisoning?
When we have unpoisoning, we can add something. We don't seem to have
an inverse function for "set_memory_np" to just flip the _PRESENT bi
>> +if (set_memory_np(decoy_addr, 1))
>> +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", pfn);
>
> Does this patch handle breaking up 512 GiB, 1 GiB or 2 MiB page mappings
> if it's just trying to mark a 4 KiB page as bad?
Yes. The 1:1 mappings start out using the largest supported pag
> Persistent memory does have unpoisoning and would require this inverse
> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c
> nvdimm_clear_poison().
Nice. Well this code will need to cooperate with that ... in particular if the
page
is in an area that can be unpoisoned ... th
On Sun, Oct 15, 2017 at 11:40:46AM +0200, Borislav Petkov wrote:
> On Wed, Oct 11, 2017 at 09:34:22PM +0000, Luck, Tony wrote:
> > > here's a second attempt at a more rigorous simplification: RCU stuff is
> > > gone and only a single loop scans through the elements
" ; inject 5 errors ; "kill -CONT `pgrep mcelog`"
Worked (all five errors reported correctly)
3) "kill -STOP `pgrep mcelog`" ; inject 35 errors ; "kill -CONT `pgrep mcelog`"
mcelog reported Warning: MCE buffer is overflowed.
First 32 (MCE_LOG_LEN) errors reported correctly.
Reviewed-and-tested-by: Tony Luck
-Tony
On Tue, Nov 14, 2017 at 01:55:11PM +0800, Xie XiuQi wrote:
> + /* known AO MCACODs reported via CMC: */
> + MCESEV(
> + AO, "Action optional: memory scrubbing error",
> + SER, MASK(MCI_UC_SAR|MCACOD_SCRUBMSK,
> MCI_STATUS_UC|MCACOD_SCRUB)
I think you should check f
> OK, I'll add check for OVER=0 in v2.
Thinking a bit more on this ... do you just need to remove the check
for S=1 from the existing "AO" entries? Or do we need the CMCI
match entry early in the table?
-Tony
> Yes, we could just remove the check for S=1, and place "AO" entries before
> "UCNA" entries.
>
> Is that right?
Probably. But you should give more thought than I just did to the order to
make sure that we don't give the wrong classification to something because
it now matches something early in
> If we reuse the movable zone, we should set appropriate size of
> mirrored memory region(normal zone) and non-mirrored memory
> region(movable zone). In some cases, kernel will take more memory
> than user, e.g. some apps run in kernel space, like module.
>
> I think user can set the size in BIOS
> It'll refuse if we try to unload pstore module. But we can unload
> ramoops module. Because we only increase a reference count of pstore
> module when the file is opened. We didn't increase ramoops module's
> reference count.
Thanks. Series applied.
I changed:
part1: re-worded commit a little
+ if (reliable_kernelcore) {
+ for_each_memblock(memory, r) {
+ if (memblock_is_mirror(r))
+ continue;
Should we have a safety check here that there is some mirrored memory? If you
give
the kernelcore=reliable option on a ma
-static int __exit ramoops_remove(struct platform_device *pdev)
+static int ramoops_remove(struct platform_device *pdev)
Arnd,
Thanks. I folded that fix into the commit that made the error and rebased (I
don't believe
anyone is foolish enough to base work on my "next" branch)
-Tony
--
To uns
> I think /proc/zoneinfo can show detailed numbers per zone. Do we need some
> for meminfo ?
I wrote a little script (attached) to summarize /proc/zoneinfo ... on my system
it says
$ zoneinfo
Node Normal Movable DMA DMA32
00.00 103020
> What does that mean? What does SGX have to do with MCI_CTL registers?
> Explain that in the commit message so that !Intel people can understand.
I think the SGX folk are worried that it might be possible to compromise the
integrity of code running in SGX if an attacker has control of the host an
> pstore doesn't support unregistering yet. It was marked as TODO.
Thanks for looking to close out this TODO item.
The thing that scared me about unloading pstore was what happens to
a process that is in the middle of reading some /sys/fs/pstore/file-name-here
Do we have all the right reference
First part of each memory controller. I have two memory controllers on each node
Sent from my iPhone
> On Oct 22, 2015, at 18:01, Izumi, Taku wrote:
>
> Dear Tony,
>
>> -Original Message-----
>> From: Luck, Tony [mailto:tony.l...@intel.com]
>> Sent: Friday,
> ping?
I'm not actually sure that the code is wrong. As you say it is a pretty
strange loop.
We seem to want to look at a bunch of conditions, and use "continue" to ignore
bits until we find one that we like the look of. Perhaps as soon as we do, we
want
to believe it to get our return value
- pfn = PFN_DOWN(param1 & param2);
- if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
+ base_addr = param1 & param2;
+ size = (~param2) + 1;
We expect the user will supply us with param2 in the form 0x[fec8]0
with various numbers of leading 'f' and
> + ((param2 & PAGE_MASK) != PAGE_MASK))
>return -EINVAL;
>
> The 3rd condition check makes sure that the param2 mask is the page size or
> less. So, I
> think we are OK on this.
Oops. The original was even on the screen as part of the diff (which I signed
off on just
> Signed-off-by: Toshi Kani
> Reviewed-by: Dan Williams
Acked-by: Tony Luck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Would it help to call routines to read the "before" values of the counter
twice. The first time to preload the cache with anything needed to execute
the perf code path.
>> In an attempt to improve the accuracy of the above I modified it to the
>> following:
>>
>> /* create the two events as before
Counter proposal. We don't need the temp mci_status because we exit the
loop early. Nor the "ret" variable.
How does this look?
-Tony
---
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index e4cf6ff1c2e1..0e30abccfe54 100644
--- a/arch/x86/kernel/cpu/mcheck
On Thu, Jun 21, 2018 at 09:17:11PM +0200, Borislav Petkov wrote:
> On Thu, Jun 21, 2018 at 11:18:09AM -0700, Luck, Tony wrote:
> > Counter proposal. We don't need the temp mci_status because we exit the
> > loop early. Nor the "ret" variable.
> >
> >
> So _why_ doesn't this work? As said by Tony, that first call should
> prime the caches, so the second and third calls should not generate any
> misses.
How much code/data is involved? If there is a lot, then you may be unlucky
with cache coloring and the later parts of the "prime the caches" cod
> I think sb_edac.c (and probably other EDAC stuff) lacks PCI domain
> support
There's a patch queued to fix this.
https://marc.info/?l=linux-edac&m=153256485215534&w=2
> It looks like 88ae80aa609c ("EDAC, skx_edac: Handle systems with
> segmented PCI busses") fixes a similar problem; maybe t
On Fri, Jul 27, 2018 at 04:40:09PM -0500, Yazen Ghannam wrote:
> - /* Don't support asymmetric configurations today */
> - WARN_ON(mca_cfg.banks != 0 && b != mca_cfg.banks);
> - mca_cfg.banks = b;
> + mca_cfg.banks = max(mca_cfg.banks, b);
Should we change mca_cfg.banks to be a per
On Tue, Jul 31, 2018 at 08:03:28PM +0300, Kirill A. Shutemov wrote:
> But it's not the only issue unfortunately. Tony reported issue with
> booting ia64 with the patch. I have no clue why. I rechecked everything
> ia64-specific and looks fine to me. :-/
If I just revert bfd40eaff5ab ("mm: fix vma_
Tested-by: Tony Luck
-Tony
> There's no reliable way to get the old microcode revision which was
> overwritten during the upgrade. If dmesg gets overwritten you lose, like
> in all the other gazillion cases where you lose information due to that.
The primary requirement here is that we report the version of the microcode
in
On Wed, Aug 01, 2018 at 10:15:05AM -0700, Linus Torvalds wrote:
> Tony, can you please double-check my commit ebad825cdd4e ("ia64: mark
> special ia64 memory areas anonymous") fixes things for you? I didn't
> even compile it, but it really looks so obvious that I just committed
> it directly. It's
On Mon, Jul 23, 2018 at 08:56:54AM +0300, Mike Rapoport wrote:
> Hi,
>
> These patches convert ia64 to use NO_BOOTMEM.
>
> The first two patches are cleanups, the third patches reduces usage of
> 'struct bootmem_data' for easier transition and the forth patch actually
> replaces bootmem with memb
> Both are real page. But why do you expect pages to be 64-byte alinged?
> Both are aligned to 64-bit as they suppose to be IIUC.
On a 64-bit kernel sizeof struct page == 64 (after much work by people to
trim out excess stuff). So I thought we made sure to align the base address
of blocks of "str
if (c->x86 == 6 &&
c->x86_model == INTEL_FAM6_BROADWELL_X &&
c->x86_mask == 0x01 &&
+ llc_size_per_core > 2621440 &&
c->microcode < 0x0b21) {
pr_err_once("Erratum BDF90: late loading with revision <
0x0b21 (0x%x) disable
>> I'm not taking this: this looks like a bunch of voodoo magic numbers.
>> Please get someone from Intel to explain first.
>
> Tony, could you clarify this?
Jia,
I'll look for someone who can confirm the 2.5MB/core detail.
-Tony
> I'll look for someone who can confirm the 2.5MB/core detail.
Ok ... re-read the erratum. The 2.5MB/core is clear. The E5+E7 is clear.
No mention of the platform ID, but Jia is dropping that part.
Boris ... what specific questions remain?
-Tony
On Tue, Jan 16, 2018 at 09:01:49PM +0100, Borislav Petkov wrote:
> On Tue, Jan 16, 2018 at 05:24:27PM +0000, Luck, Tony wrote:
> > > I'll look for someone who can confirm the 2.5MB/core detail.
> >
> > Ok ... re-read the erratum. The 2.5MB/core is clear. The E5+E7
On Tue, Jan 16, 2018 at 09:50:37PM +0100, Borislav Petkov wrote:
> ... and there's not a more reliable way to detect those like platform ID
> or so? Because if for anywhere, this is where one *should* use platform
> ID.
>
> Or perhaps some other bit somewhere instead of this cache size thing?
I c
On Mon, Mar 26, 2018 at 10:09:55PM +0200, Borislav Petkov wrote:
> On Mon, Mar 26, 2018 at 08:05:37PM +, Ghannam, Yazen wrote:
> > Sure, I can do that. But I didn't think it was necessary because it doesn't
> > hurt
> > to read the registers whether or not the valid bits are set.
>
> No, this
On Mon, Mar 26, 2018 at 03:19:48PM -0700, Alison Schofield wrote:
> On Thu, Mar 22, 2018 at 04:30:29PM -0700, Luck, Tony wrote:
> > On Thu, Mar 22, 2018 at 01:49:22PM -0700, Alison Schofield wrote:
> > > + if (!topology_same_node(c, o) &&
> > > +
On Thu, Mar 22, 2018 at 01:49:22PM -0700, Alison Schofield wrote:
> + if (!topology_same_node(c, o) &&
> + (c->x86_vendor == X86_VENDOR_INTEL &&
> + c->x86_model == INTEL_FAM6_SKYLAKE_X)) {
Maybe make life easier in the future to add more models
to the list by using x86_match_
> "Hence, pstore calls efi_runtime_services() without using efi_rts_wq" -
> that doesn't sound like optimal design to me. I would try to shove them
> all through the workqueue - not have exceptions.
But pstore is trying to save the last gasp dying words from a kernel that
has paniced. There isn't
> Change the remaining arches (cris, frv, and ia64) to skip INTx setup when
> either MSI or MSI-X is enabled.
My ia64 still boots with this patch applied (and doesn't have any new/different
messages
in the console log). So:
Tested-by: Tony Luck
-Tony
On Wed, Sep 26, 2018 at 06:17:49PM +0200, Borislav Petkov wrote:
> On Wed, Sep 26, 2018 at 01:03:40PM -0300, Mauro Carvalho Chehab wrote:
> > I guess this is/was needed to create things like this:
> >
> > lrwxrwxrwx 1 root root 0 set 26 05:24 /sys/bus/edac/devices/mc ->
> > ../../../devices/s
This issue has made me look a bit more at what EDAC puts in sysfs.
It seems like the current code inherits some useless baggage
from the device calls it makes.
E.g. all the "power" subdirectories:
$ find /sys/devices/system/edac -name power
/sys/devices/system/edac/power
/sys/devices/system/edac/
On Thu, Sep 27, 2018 at 06:52:44AM +0200, Borislav Petkov wrote:
> On Wed, Sep 26, 2018 at 04:02:57PM -0700, Luck, Tony wrote:
> > But ... we are at -rc5. Not sure that we'll figure out, write, test & debug
> > the proper solution in the next 3-4 weeks. So perhaps we should
On Thu, Nov 29, 2018 at 03:26:51PM -0800, Kees Cook wrote:
> On Wed, Sep 6, 2017 at 1:28 PM Helge Deller wrote:
> >
> > Use the %pS instead of the %pF printk format specifier for printing symbols
> > from direct addresses. This is needed for the ia64, ppc64 and parisc64
> > architectures.
> >
> >
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support implementation
> across all the architectures
On Wed, Dec 05, 2018 at 03:13:23PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Rename the containing folder to "mce" which is the most widespread name.
> Drop the "mce[-_]" filename prefix of some compilation units (while
> others don't have it).
>
> This unifies the file naming in
> So the real question is, is there a signifcant class of MCE events that
> are not tied to the reporting channel which is per CPU (-ish ...) MCA
> banks?
Perhaps QPI/UPI interconnect errors?
-Tony
>> +WARN_ONCE(1, "A split lock issue is detected. Please FIX it\n");
>
> But, warning here is also not super useful. Shouldn't we be dumping out
> the info in 'regs' instead of the current context? We don't care about
> the state in the #AC handler, we care about 'regs'.
Maybe:
WARN
On Mon, May 14, 2018 at 06:27:52PM +0200, Borislav Petkov wrote:
> On Mon, May 14, 2018 at 09:19:11PM +0530, Jeffrin Thalakkottoor wrote:
> > hello,
> >
> > output related of "sudo dmesg -l emerg" from my laptop...
> >
> > -
.
Other option would be to fix the microcode update code to make
sure that boot_cpu_data.microcode is right.
But if we go this route we should add:
Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check
records")
Cc: sta...@vger.kernel.org
Can also get a:
Reviewed-by: Tony Luck
-Tony Luck
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> happened so I'll send it later. It is nice to have anyway.
Did you fix up part 2/3? I see 1 & 3 were staged by Thomas in
TIP ras/urgent and ras-urgent-for-linus
On Fri, Jun 15, 2018 at 01:45:18PM +0200, Borislav Petkov wrote:
> On Thu, Jun 14, 2018 at 02:57:54PM -0700, Luck, Tony wrote:
> > On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> > > tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> >
This both compiles and boots on ia64.
Builds OK on x86_64 with an Enterprise OS .config that includes:
CONFIG_HAVE_MEMBLOCK=y
CONFIG_NO_BOOTMEM=y
-Tony
diff --git a/mm/memblock.c b/mm/memblock.c
index cc16d70b8333..0a54d488f767 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1225,6 +122
Bjorn,
Back in commit:
0a70abb38062 ("PCI/ACPI: Support I/O resources when parsing host bridge
resources")
we added acpi_pci_root_remap_iospace(). On ia64 this was a no-op because ia64
didn't define PCI_IOBASE, so the entire body of the function was skipped.
But in the current merge window
On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> Another way would be to add
>
> #include
> +#undef PCI_IOBASE
>
> in your asm/io.h. This is about as ugly as the your version, but
> it would be local to ia64 ;-)
Third way ...
Is "0" actually the right value for PCI_IOBASE for
>> - Some targets don't have any support for I/O space on their PCI bus and just
>>want to get things to compile by setting PCI_IOBASE to zero, this still
>> opens
>> up some of the same problems as above, but doesn't really help otherwise.
That sounds horrible. Why would you want to have
On Fri, Dec 07, 2018 at 11:07:05AM -0800, Christoph Hellwig wrote:
> This works is based on the dma-mapping tree, so you probably want to
> want this git tree for testing:
>
> git://git.infradead.org/users/hch/misc.git dma-direct-calls.2
Pulled this tree. Got HEAD
33b9fc015171 ("dma-
> This should fix it:
...
> +#include
Not quite. Still have an issue with __phys_to_pfn(paddr)
Trying ti #include gave we a raft of redefined
macros. So I just added
#define __phys_to_pfn(paddr)PHYS_PFN(paddr)
to arch/ia64/mm/init.c
That made the build work. But boot spontaneously r
> But that might not be your fault. My ancient system is getting flaky. A v4.19
> build that
> has booted before is also resetting :-(
After a power-cycle (and some time to let the machine cool off). System now
boots
with your patch series plus the __phys_to_pfn() #define
So if you can figure t
I'm curious why you call this "pstore/rom" rather than the more descriptive
"pstore/block".
It looks to be a really good idea.
I think you need to document how the "write" function for the block device must
be written.
Since pstore calls this at "panic" time, the write path:
+ Cannot allocate
>> It looks to be a really good idea.
> Should i add "Acked-by" in next version of patch?
I've only looked at the concept, not at the code yet. So too early to commit to
an "Acked-by"
> I have little experience in sending patch to upstream linux.
You are doing fine so far.
-Tony
> the enforcement clause of the new code of conduct. Since there is concern
> that this becomes binding on the release of the 4.19 kernel
Is there some logic behind that concern? What's magic about the release
of 4.19?
Our benevolent dictator committed that patch. Didn't it take effect
as soon a
> Not usually: people usually have to agree to a change like this. Of
> course "agree" is a variable concept and can be as simple as not object
> by a certain time or by using certain infrastructure.
Perhaps you should review the meaning of the word "dictator". :-)
-Tony
> The fact that you see this, means, the error has reached the last
> notifier. So the EDAC notifier must've run too and handed the error to
> the EDAC driver.
>
> Can you send a full dmesg from that machine, privately to Tony and me is
> fine too.
Some system configuration information would be he
On Mon, Oct 29, 2018 at 06:51:29PM +0100, Borislav Petkov wrote:
> On Mon, Oct 29, 2018 at 04:59:44PM +0000, Luck, Tony wrote:
> > The EDAC driver printed out those messages,
>
> I don't think so - that's __print_mce() in mce.c which dumps the three
> lines under &quo
On Tue, Nov 06, 2018 at 03:32:53PM +0100, Borislav Petkov wrote:
> On Tue, Nov 06, 2018 at 02:44:42PM +0100, Arnd Bergmann wrote:
> > No, it was unintentional, the 'if ACPI' can be dropped when we add
> > 'depends on ACPI'.
>
> So I have one fix already which takes care of non-sensical configs. If
On Mon, Oct 08, 2018 at 08:25:35AM +1000, Dave Airlie wrote:
> This isn't a legally binding license or anything, but departing from
> the upstream wording makes it tricker to merge new upstream versions
> if they are considered appropriate.
The whole document is under 500 words, if we can manage
On Fri, Nov 02, 2018 at 05:10:13PM +0100, Borislav Petkov wrote:
> On Fri, Nov 02, 2018 at 04:32:06PM +0100, Arnd Bergmann wrote:
> > We cannot currently select ACPI_ADXL without also enabling the top-level
> > ACPI option:
> >
> > WARNING: unmet direct dependencies detected for ACPI_ADXL
> > De
> If the filesystem existed on the namespace before the user specified
> the ramoops command line then ramoops will clobber the filesystem and
> the user will only find out when mount later fails. All the kernel
> will say is:
>
> dev_warn(dev, "could not reserve region %pR\n", res);
>
> ...fro
> > The first patch adds PPIN (Protected Processor Inventory Number) field to
> > the tracepoint.
> >
> > The second patch adds the microcode field (Microcode Revision) to the
> > tracepoint.
>
> This is a lot of static information to add to *every* MCE.
8 bytes for PPIN, 4 more for microcode.
Nu
> > 8 bytes for PPIN, 4 more for microcode.
>
> I know, nothing leads to bloat like 0.01% here, 0.001% there...
12 extra bytes divided by (say) 64GB (a very small server these days, may
laptop has that much)
= 0.0001746%
We will need 57000 changes like this one before we get to 0.001% :-)
> > You've spent enough time with Ashok and Thomas tweaking the Linux
> > microcode driver to know that going back to the machine the next day
> > to ask about microcode version has a bunch of ways to get a wrong
> > answer.
>
> Huh, what does that have to do with this?
If deployment of a microcod
> > Is it so very different to add this to a trace record so that rasdaemon
> > can have feature parity with mcelog(8)?
>
> I knew you were gonna say that. When someone decides that it is
> a splendid idea to add more stuff to struct mce then said someone would
> want it in the tracepoint too.
>
>
> But no, that's not the right question to ask.
>
> It is rather: which bits of information are very relevant to an error
> record and which are transient enough so that they cannot be gathered
> from a system by other means or only gathered in a difficult way, and
> should be part of that record.
> Export PPIN through the tracepoint as it provides a unique identifier for
> the system (or socket in case of multi-socket systems) on which the MCE
> has been received.
>
> Signed-off-by: Avadhut Naik
> Reviewed-by: Sohil Mehta
> Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Tony Luck
> Export microcode version through the tracepoint to prevent ambiguity over
> the active version on the system when the MCE was received.
>
> Signed-off-by: Avadhut Naik
> Reviewed-by: Sohil Mehta
> Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Tony Luck
> Tony, any comments? You ok with this, would that fit any Intel-specific vendor
> fields too or do you need some additional Intel-specific changes?
It looks easy enough to add any Intel specific bits to the union later.
Is there anyway that the trace event could be "smarter" about what vendor
s
On Mon, Apr 19, 2021 at 06:49:15PM -0700, Jue Wang wrote:
> On Tue, 13 Apr 2021 07:43:20 +0900, Naoya Horiguchi wrote:
> ...
> > + * This function is intended to handle "Action Required" MCEs on already
> > + * hardware poisoned pages. They could happen, for example, when
> > + * memory_failure() f
On Mon, Apr 19, 2021 at 07:03:01PM -0700, Jue Wang wrote:
> On Tue, 13 Apr 2021 07:43:20 +0900, Naoya Horiguchi wrote:
>
> > This patch suggests to do page table walk to find the error virtual
> > address. If we find multiple virtual addresses in walking, we now can't
> > determine which one is c
> I meant in this case (racing to access the same poisoned pages), the
> page mapping should have been removed by and the hwpoison swap pte
> installed by the winner thread?
My "mutex" patch that Horiguchi-san has included his summary series should
make this happen in most cases. Only problem is i
On Sat, Jan 22, 2022 at 12:40:18AM +, Jane Chu wrote:
> On 1/21/2022 4:31 PM, Jane Chu wrote:
> > On baremetal Intel platform with DCPMEM installed and configured to
> > provision daxfs, say a poison was consumed by a load from a user thread,
> > and then daxfs takes action and clears the poiso
+ m.misc = (MCI_MISC_ADDR_PHYS << 6) |
__ffs64(mem_err->physical_addr_mask);
Do we want to unconditionally trust the sanity of the BIOS provided
physical_address_mask?
There's a warning comment on the kernel __ffs64() function:
* The result is not defined if no bits are set, so check th
> It appears the kernel is trusting that ->physical_addr_mask is non-zero
> in other paths. So this is at least equally broken in the presence of a
> broken BIOS. The impact is potentially larger though with this change,
> so it might be a good follow-on patch to make sure that
> ->physical_addr_ma
On Mon, Jul 18, 2022 at 09:11:33PM +, Jane Chu wrote:
> On 7/18/2022 12:22 PM, Luck, Tony wrote:
> >> It appears the kernel is trusting that ->physical_addr_mask is non-zero
> >> in other paths. So this is at least equally broken in the presence of a
> >> broke
> struct mce m;
> + int lsb = PAGE_SHIFT;
Some maintainers like to order local declaration lines from longest to shortest
> + /*
> + * Even if the ->validation_bits are set for address mask,
> + * to be extra safe, check and reject an error radius '0',
> + * and fall
> What I'm missing from this text here is, what *is* the mce->misc LSB
> field in human speak? What does that field denote?
The SDM says:
Recoverable Address LSB (bits 5:0): The lowest valid recoverable address bit.
Indicates the position of the least
significant bit (LSB) of the recoverable e
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> We should prefer more robust and less ambiguous string interfaces.
>
> A suitable replacement is `strscpy_pad` [2] due to the fact that it guarantees
> NUL-termination on the destination buffer whilst maintaining the
>
> + return in_task() ? task_pid_nr(current) | (smp_processor_id() <<
> CPU_ID_SHIFT) :
There are contexts and CONFIG options around pre-emption where
smp_processor_id()
will throw a warning. Use raw_smp_processor_id().
-Tony
On Wed, Apr 07, 2021 at 11:18:16PM +0200, Borislav Petkov wrote:
> On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote:
> > Andy Lutomirski pointed out that sending SIGBUS to tasks that
> > hit poison in the kernel copying syscall parameters from user
> > address space is not the right semant
> I have one scenario, may you take into account:
>
> If one copyin case occurs, write() returned by your patch, the user process
> may
> check the return values, for errors, it may exit the process, then the error
> page
> will be freed, and then the page maybe alloced to other process or to ker
> What I'm still unclear on, does this new version address that
> "mysterious" hang or panic which the validation team triggered or you
> haven't checked yet?
No :-(
They are triggering some case where multiple threads in a process hit the same
poison, and somehow memory_failure() fails to comple
On Thu, Apr 08, 2021 at 10:49:58AM +0200, Borislav Petkov wrote:
> On Wed, Apr 07, 2021 at 02:43:10PM -0700, Luck, Tony wrote:
> > On Wed, Apr 07, 2021 at 11:18:16PM +0200, Borislav Petkov wrote:
> > > On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote:
> > > &g
> local symbol 0: discarded in section `.exit.text' from
> arch/ia64/kernel/built-in.o
This usually means that there is a static __exit function (or __devexit etc.)
somewhere in the object being linked. The error message is pretty unhelpful
in figuring out *where* in the module. Look at the 'mm
> The quicklists have a long history and this bug has therefore also been in
> IA64 for a long time and it also likely exists on sparc64, sh and sh64. We
> need the patch that I posted to fix the other platforms. And with this fix
> there would be nothing amiss on x86_64 either.
IA64 doesn't do
> + if (pte_present(pteval) &&// swap out ?
> + pte_exec(pteval) &&// flush only new executable page.
> pte_user(pteval) &&// ignore kernel page
> (!pte_present(*ptep) ||// do_no_page or swap in, migration,
> pte_pfn(*ptep) != pte_pfn(pteval)))
301 - 400 of 1172 matches
Mail list logo
