On Thu, Aug 21, 2014 at 10:19:51PM -0400, Pranith Kumar wrote:
> Fix the following build error:
>
> drivers/edac/ppc4xx_edac.c: In function 'mfsdram':
> drivers/edac/ppc4xx_edac.c:249: error: implicit declaration of function
> '__mfdcri'
> drivers/edac/ppc4xx_edac.c: In function 'mtsdram':
> drive
ed a crash
> on boot.
>
> To fix this, the PCI controller code now creates a child platform
> device specifically for EDAC, which the mpc85xx-pci-edac driver binds
> to.
>
> Signed-off-by: Scott Wood
> Cc: Jia Hongtao
> Cc: Borislav Petkov
> Cc: Johannes Th
Adding the respective arch MLs to CC, as an FYI.
On Tue, Jan 05, 2016 at 11:54:30AM -0700, Toshi Kani wrote:
> Set IORESOURCE_SYSTEM_RAM to 'flags' of resource ranges with
> "System RAM", "Kernel code", "Kernel data", and "Kernel bss".
>
> Note that:
> - IORESOURCE_SYSRAM (i.e. modifier bit) is
arm-ker...@lists.infradead.org
Cc: linux-m...@linux-mips.org
Cc: linux-mm
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1452020081-26534-6-git-send-email-t
On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users. It's getting more and more
> complicated to decide which mitigations are needed for a given
> architecture. Compl
On Thu, Apr 04, 2019 at 11:44:12AM -0500, Josh Poimboeuf wrote:
> Configure x86 runtime CPU speculation bug mitigations in accordance with
> the 'cpu_spec_mitigations=' cmdline options. This affects Meltdown,
> Spectre v2, Speculative Store Bypass, and L1TF.
>
> The default behavior is unchanged.
On Fri, Apr 05, 2019 at 09:20:48AM -0500, Josh Poimboeuf wrote:
> In your scenario, the fact that it's so easy to remember would save the
> day, since you wouldn't have to go look up some obscure shortened option
> name in the documentation :-)
No no, the idea is for the short option to be memorab
On Fri, Apr 05, 2019 at 09:31:01AM -0500, Josh Poimboeuf wrote:
> My thinking was that the individual options could be used to override
> the global option. But maybe that's overkill? I dunno.
You mean if the user deliberately types:
"cpu_spec_mitigations=off spectre_v2=auto"
on the cmdline to
Thinking about this more, we can shave off the first 4 chars and have it
be:
spec_mitigations=
I think it is painfully clear which speculation mitigations we mean. And
the other switches don't have "cpu_" prefixes too so...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top
On Wed, Apr 10, 2019 at 03:48:48PM +1000, Michael Ellerman wrote:
> What about when we have a mitigation for a non-speculation related bug :)
Like that is *ever* going to happen... :-P
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Apr 12, 2019 at 03:39:28PM -0500, Josh Poimboeuf wrote:
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 38890f62f9a8..aed9083f8eac 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -2320,3 +2320,18 @@ void __init boot_cpu_hotplug_init(void)
> #endif
> this_cpu_write(cpuhp_stat
--
> include/linux/compiler_types.h | 3 +--
> lib/Kconfig.debug | 14 ++
> 4 files changed, 15 insertions(+), 19 deletions(-)
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
.
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/powerpc/platforms/pseries/Kconfig | 2 +-
arch/s390/Kconfig | 2 +-
arch/x86/Kconfig | 2 +-
arch/x86/mm/mem_encrypt.c | 4 ++--
include/linux/dma-direct.h
On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
> On 3/17/20 4:18 AM, Borislav Petkov wrote:
> > Back then when the whole SME machinery started getting mainlined, it
> > was agreed that for simplicity, clarity and sanity's sake, the terms
> > denoting e
On Tue, Mar 17, 2020 at 02:24:59PM -0700, Dave Hansen wrote:
> No, there are just two states. I just think the "!encrypted" case
> should not be called "decrypted".
Yeah, we suck at naming - news at 11! :-)
I believe we even considered things like "encrypted" vs "clear" but
that sucked too. ;-\
Hi,
here's v2 with build breakage fixed on ppc and s390 (obviously I can't
grep :-\) and commit message extended to explain more why.
Thx.
---
From: Borislav Petkov
Date: Tue, 17 Mar 2020 12:03:05 +0100
Back then when the whole SME machinery started getting mainlined, it
was agree
On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote:
> I thought we agreed that decrypted is absolutely the wrong term.
I don't think we did. At least I don't know where we did that.
> So NAK - if you want to change things it needs to go the other way.
We are already using "decrypt
On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote:
> Let me add another vote from a native English speaker that "unencrypted" is
> the appropriate term to imply the *absence* of encryption, whereas
> "decrypted" implies the *reversal* of applied encryption.
>
> Naming things is famously
On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
> TBH, I don't see how
>
> if (force_dma_decrypted(dev))
> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>
> makes more sense than the above. It's both non-sensical unless there is
9087c37584fb
On Mon, Mar 30, 2020 at 03:08:19PM +1100, Stephen Rothwell wrote:
> What you really need is an Ack from the PowerPC people for the fix you
> suggested and then tha fix should go in the same series that is now
> causing the failure (preferably before the problematic (for PowerPC)
> patch.
I'll zap
On Mon, Mar 30, 2020 at 07:04:16PM +1100, Michael Ellerman wrote:
> Or just squash the hunk Stephen posted into the commit, which is what I
> thought would happen to begin with.
>
> You can have my ack for it:
>
> Acked-by: Michael Ellerman (powerpc)
Thanks but considering how this is not reall
On Tue, Oct 29, 2019 at 08:01:17PM -0500, Segher Boessenkool wrote:
> I am still not convinced the worse name is a better name, no :-) But if
> you don't want to do the work, and instead prefer the much smaller change,
> that is of course a fine decision. Thank you!
>
> (I would be happy with suc
On Wed, Nov 06, 2019 at 03:12:58PM +0100, Richard Henderson wrote:
> During patch review for an addition of archrandom.h for arm64, it was
> suggeted that the arch_random_get_* functions should be marked __must_check.
> Which does sound like a good idea, since the by-reference integer output
> may
On Mon, Nov 11, 2019 at 07:08:51PM +0100, Geert Uytterhoeven wrote:
> vmlinux-std.lds: All other classic 680x0 targets with an MMU, e.g. plain
> defconfig aka multi_defconfig.
FWIW, the defconfig doesn't build with the cross compiler¹ here, even with Kees'
patch applied but for a
On Sat, Apr 25, 2020 at 11:04:40AM -0400, Arvind Sankar wrote:
> I'd put the clause about stack protector being disabled and the
> tail-call one together, to make clear that you still need the never
> return and always inline bits.
Done.
> Also, this function is implemented by multiple arch's and
On Sat, Apr 25, 2020 at 07:31:40PM +0200, Borislav Petkov wrote:
> Hmm, that's what I was afraid of - having to sprinkle this around. Yah, let's
> wait for compiler guys to have a look here and then maybe I'll convert that
> thing to a macro called
>
>
On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote:
> That is a lot more typing then
> asm("");
That's why a macro with a hopefully more descriptive name would be
telling more than a mere asm("").
> but more seriously, you probably should explain why you do not want a
> tail
On Sat, Apr 25, 2020 at 02:15:49PM -0500, Segher Boessenkool wrote:
> My point is that you should explain at *every use* of this why you cannot
> have tail calls *there*. This is very unusual, after all.
>
> There are *very* few places where you want to prevent tail calls, that's
> why there is n
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 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
ul Burton
> Cc: James Hogan
> Cc: Ley Foon Tan
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rich Felker
> Cc: "David S. Miller"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
>
On Sat, Dec 08, 2018 at 03:36:52PM +0900, Masahiro Yamada wrote:
> x86 maintainers,
>
> Ping.
You got the required ACKs. If you want me to carry this one and the
UML one through the tip tree, lemme know. Or you can do what Richard
suggested. Your call.
Thx.
--
Regards/Gruss,
Boris.
Good m
On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote:
> Bhupesh Sharma (5):
> crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo
> arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
> Documentation/arm64: Fix a simple typo in memory.rst
> Documentation/vmcoreinfo: Ad
On Fri, Nov 29, 2019 at 01:55:14AM +0530, Bhupesh Sharma wrote:
> Fix a simple typo in arm64/memory.rst
>
> Cc: Jonathan Corbet
> Cc: James Morse
> Cc: Mark Rutland
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Catalin Marinas
> Cc: Ard Biesheuvel
> Cc: linux-...@vger.kernel.org
> Cc: linux-ke
On Mon, Dec 16, 2019 at 12:16:12PM +0530, Bhupesh Sharma wrote:
> I remember there was a suggestion during the review of an earlier
> version to keep them as a separate patch(es) so that the documentation
> text is easier to review,
Documentation text is one sentence, respectively. Not really wort
ked good and asked if he should take
> them through the tip tree but things seem to have got lost since then.
Or, alternatively, akpm could take them. In any case, if someone else
ends up doing that, for the x86 bits:
Reviewed-by: Borislav Petkov
Thx.
--
Regards/Gruss,
Boris.
https:
On Mon, Jan 20, 2020 at 05:26:27PM +, Mark Brown wrote:
> I think the important thing here is that *someone* takes the patches.
> We've now got Ted and Borislav both saying they're OK applying the
> patches, an additional proposal that Andrew takes the patches, nobody
> saying anything negative
On Mon, Aug 13, 2012 at 02:43:34PM +0300, Kirill A. Shutemov wrote:
> $ cat test.c
> #include
> #include
>
> #define SIZE 1024*1024*1024
>
> void clear_page_nocache_sse2(void *page) __attribute__((regparm(1)));
>
> int main(int argc, char** argv)
> {
> char *p;
> unsigned long
On Mon, Nov 19, 2012 at 01:20:05PM -0500, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
> needed.
Erm, I don't understand. __devexit_p is defined also for modules not
only for CONFIG_HOTPLUG:
#if defined(MODULE) || defined(CONFIG_HOTPLUG)
#define __
On Thu, Nov 22, 2012 at 10:22:22AM -0800, Greg KH wrote:
> On Thu, Nov 22, 2012 at 02:44:51PM +0100, Borislav Petkov wrote:
> > On Mon, Nov 19, 2012 at 01:20:05PM -0500, Bill Pemberton wrote:
> > > CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
> > &
y and if you haven't done so yet.
Thanks for explaining.
Btw, you can have my
Acked-by: Borislav Petkov
for the amd64_edac pieces.
--
Regards/Gruss,
Boris.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequenti
the memory via chip select rows.
>
> Reviewed-by: Aristeu Rozanski
> Cc: Doug Thompson
> Cc: Borislav Petkov
> Cc: Mark Gross
> Cc: Jason Uhlenkott
> Cc: Tim Small
> Cc: Ranganathan Desikan
> Cc: "Arvind R."
> Cc: Olof Johansson
> Cc: Egor Ma
On Tue, Apr 17, 2012 at 04:28:49PM -0300, Mauro Carvalho Chehab wrote:
> Ok. well, we can either multiply nr_pages by channel_count or to let it
> clear that this is per channel. I prefer the last option (see the enclosed
> patch).
>
> >> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl
r-csrow
> data, storing it, instead at the right place.
>
> The first step is to move grain, mtype, dtype and edac_mode to the
> per-dimm struct.
>
> Reviewed-by: Aristeu Rozanski
> Cc: Doug Thompson
> Cc: Borislav Petkov
> Cc: Mark Gross
> Cc: Jason Uhlenkott
>
Btw,
this patch gives
[8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
(0:0:0): row 0, chan 0
[8.287594] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 1: dimm1
(0:1:0): row 0, chan 1
[8.296784] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 2: dimm2
(1:0
On Fri, Apr 27, 2012 at 10:11:35AM -0400, Joe Perches wrote:
> > > -extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned
> > > nr_csrows,
> > > - unsigned nr_chans, int edac_index);
> > > +struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned
On Fri, Apr 27, 2012 at 01:07:38PM -0300, Mauro Carvalho Chehab wrote:
> Yes. This is a common issue at the EDAC core: on several places, it calls the
> edac debug macros (DEBUGF0...DEBUGF4) passing a __func__ as an argument, while
> the debug macros already handles that. I suspect that, in the pas
On Fri, Apr 27, 2012 at 04:24:28PM -0300, Mauro Carvalho Chehab wrote:
> Em 27-04-2012 15:11, Luck, Tony escreveu:
> +for (i = 0; i < dimm->mci->n_layers; i++) {
> +printk(KERN_CONT "%d", dimm->location[i]);
> +if (i < dimm->mci->n_layers - 1)
On Fri, Apr 27, 2012 at 12:36:12PM -0300, Mauro Carvalho Chehab wrote:
> The fix for it were in another patch[1], as calling them as "rank" is
> needed also at the sysfs API.
No, this doesn't fix it either:
[ 10.486440] EDAC MC: DCT0 chip selects:
[ 10.486443] EDAC amd64: MC: 0: 2048MB 1: 2
On Fri, Apr 27, 2012 at 02:52:35PM -0300, Mauro Carvalho Chehab wrote:
[..]
> >> +struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index,
> >> + unsigned n_layers,
> >> + struct edac_mc_layer *layers,
> >> + b
On Sun, Apr 29, 2012 at 11:16:53AM -0300, Mauro Carvalho Chehab wrote:
> > Hey, are you looking at compiled code or at source code? Because I'm
> > looking at source code, and it is a pretty safe bet the majority of the
> > people here do that too.
>
> What I said is that, from source code POV, a
On Sun, Apr 29, 2012 at 10:49:44AM -0300, Mauro Carvalho Chehab wrote:
> > [ 10.486440] EDAC MC: DCT0 chip selects:
> > [ 10.486443] EDAC amd64: MC: 0: 2048MB 1: 2048MB
> > [ 10.486445] EDAC amd64: MC: 2: 2048MB 3: 2048MB
> > [ 10.486448] EDAC amd64: MC: 4: 0MB 5: 0MB
> > [ 10
On Mon, Apr 30, 2012 at 07:58:33AM -0300, Mauro Carvalho Chehab wrote:
> It seems you have a very short memory.
Oh, puh-lease, let's don't start with the insults now. You're not a
saint yourself. And maybe the fact that I'm having hard time grasping
your code is maybe because it is a load of crap
On Mon, Apr 30, 2012 at 08:45:09AM -0300, Mauro Carvalho Chehab wrote:
> Em 30-04-2012 08:11, Borislav Petkov escreveu:
> > On Mon, Apr 30, 2012 at 07:58:33AM -0300, Mauro Carvalho Chehab wrote:
>
> >> For example, this is the mapping used by the second memory controller of
On Mon, Apr 30, 2012 at 08:23:42AM -0300, Mauro Carvalho Chehab wrote:
> With this I fully agree: you're nacking patches because it is not the way you
Where? Have I written Nacked-by somewhere?
> write your code, not because the code there is doing anything wrong.
>
> If you point anything wrong
Starting a new thread because the old one grew too big and
is out of my screen. Patch below is git-formatted from
git://git.infradead.org/users/mchehab/edac.git
> commit 447b7929e633027ffe131f2f8f246bba5690cee7
> Author: Mauro Carvalho Chehab
> Date: Wed Apr 18 15:20:50 2012 -0300
>
> edac
On Thu, May 03, 2012 at 11:16:54AM -0300, Mauro Carvalho Chehab wrote:
> >> + bool enable_filter,
> >> + unsigned pos[EDAC_MAX_LAYERS])
> >
> > Passing the whole array as an argument instead of only a pointer to it?
>
> This is C, and not
ible, preceding it with
> several other patches that simplified the logic here. Yet, as the
> internal API changes, all drivers need changes. The changes are
> generally bigger in the drivers for FB-DIMMs.
>
> Cc: Aristeu Rozanski
> Cc: Doug Thompson
> Cc: Borislav Petkov
&
breaking thread because it grew too big.
On Fri, May 04, 2012 at 07:48:42AM -0300, Mauro Carvalho Chehab wrote:
[ … ]
> + memset(&pos, 0, sizeof(pos));
> + row = 0;
> + chn = 0;
> + debugf4("%s: initializing %d %s\n", __func__, tot_dimms,
> + per_rank ? "ranks" : "dim
On Thu, Sep 26, 2019 at 10:55:40AM -0700, Kees Cook wrote:
> Instead of depending on markings in the section following NOTES to
> restore the associated Program Header, use a dummy section, as done
> in other architectures.
This is very laconic and after some staring at ld.info, I think you mean
t
On Thu, Sep 26, 2019 at 10:55:41AM -0700, Kees Cook wrote:
> In preparation for moving NOTES into RO_DATA, this provides a mechanism
s/this provides/provide/ - imperative tone. Check all your commit
messages pls.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Sep 26, 2019 at 10:55:47AM -0700, Kees Cook wrote:
> Many architectures have an EXCEPTION_TABLE that needs only to be
> read-only. As such, it should live in RO_DATA. This creates a macro to
> identify this case for the architectures that can move EXCEPTION_TABLE
> into RO_DATA.
>
> Signed
On Thu, Sep 26, 2019 at 10:56:01AM -0700, Kees Cook wrote:
> The resource reservations in made for the kernel image did not reflect
^
/proc/iomem
> the gaps between text, rodata, and data. This adds the rodata resource
s/This adds/Add/
On Thu, Sep 26, 2019 at 10:55:33AM -0700, Kees Cook wrote:
> This series works to move the linker sections for NOTES and
> EXCEPTION_TABLE into the RO_DATA area, where they belong on most
> (all?) architectures. The problem being addressed was the discovery
> by Rick Edgecombe that the exception ta
On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
> Names *matter*, internal names doubly so. So why replace a good name with
> a worse name? Because it is slightly less work for you?
So if we agree on the name "notes" and we decide to rename the other
arches, this should all b
On Sun, Sep 18, 2022 at 01:20:13AM +0200, Uwe Kleine-König wrote:
> When moving the definition of ppc4xx_edac_driver further down, the
> forward declarations can just be dropped.
>
> Do this to reduce line needless repetition.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/edac/ppc4xx_edac
On Fri, Oct 28, 2022 at 07:46:08AM -0700, Yury Norov wrote:
> I'll take it in bitmap-for-next this weekend.
Why?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Oct 28, 2022 at 10:13:28AM -0500, Yury Norov wrote:
> Because it's related to bitmap API usage and has been revealed after
> some work in bitmaps.
So first of all, that "fix" needs to explain what exactly it is fixing.
Not "it fixes this and that warning" but why the input arg to
cpumask_n
On Mon, Oct 31, 2022 at 09:06:04AM +0100, Andrew Jones wrote:
> The valid cpumask range is [0, nr_cpu_ids) and cpumask_next() always
> returns a CPU ID greater than its input, which results in its input
> range being [-1, nr_cpu_ids - 1). Ensure showing CPU info avoids
> triggering error condit
On Mon, Oct 31, 2022 at 11:03:27AM +0100, Andrew Jones wrote:
> Currently (after the revert of 78e5a3399421)
After the revert?
That commit is still in the latest Linus tree.
> with DEBUG_PER_CPU_MAPS we'll get a warning splat when the cpu is
> outside the range [-1, nr_cpu_ids)
Yah, that range
On Mon, Feb 27, 2023 at 02:29:29PM -0800, Rick Edgecombe wrote:
> [0]
> https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t
I guess that sub-thread about how you arrived at this "pass a VMA"
decision should be in the Link tag. But that's for the committer, I'd
say.
Th
On Thu, Mar 14, 2024 at 08:37:09AM -0700, Dave Hansen wrote:
> This is pretty close to just a raw dump of the XSAVE CPUID leaves.
> Rather than come up with an XSAVE-specific ABI that depends on CPUID
> *ANYWAY* (because it dumps the "flags" register aka. ECX), maybe we
> should just bite the bulle
On Thu, Mar 14, 2024 at 09:19:15AM -0700, Dave Hansen wrote:
> Are you envisioning an *XSAVE* state component that's not described by
> CPUID?
I want to be prepared. You can imagine some of the short cuts and
corners cutting hw guys would do so I'd want to be prepared there and
not tie this to CPU
On Thu, Mar 14, 2024 at 04:25:44PM +, Willgerodt, Felix wrote:
> I am wondering if it wouldn't be easier for everyone if corefiles would just
> contain space for all possible XSAVE components?
You mean we should shuffle out from the kernel 8K of AMX state even if
nothing uses it or the machine
On Sat, Mar 16, 2024 at 12:51:28AM +0100, Thomas Gleixner wrote:
> Anything which is not enumerated in CPUID does not exist in
> XSTATE. Period and end of story.
But why not have a simple buffer definition which doesn't need CPUID?
Also, doing the CPUID thing would need extending the gdb remote p
On Fri, May 10, 2024 at 11:29:26AM -0700, Axel Rasmussen wrote:
> @@ -3938,7 +3938,7 @@ static vm_fault_t handle_pte_marker(struct vm_fault
> *vmf)
>
> /* Higher priority than uffd-wp when data corrupted */
> if (marker & PTE_MARKER_POISONED)
> - return VM_FAULT_HWPOISON;
On Wed, May 15, 2024 at 10:33:03AM -0700, Axel Rasmussen wrote:
> Right, the goal is to still have the process get a SIGBUS, but to
> avoid the "MCE error" log message. The basic issue is, unprivileged
> users can set these markers up, and thereby completely spam up the
> log.
What is the real att
On Wed, May 15, 2024 at 12:19:16PM -0700, Axel Rasmussen wrote:
> An unprivileged process can allocate a VMA, use the userfaultfd API to
> install one of these PTE markers, and then register a no-op SIGBUS
> handler. Now it can access that address in a tight loop,
Maybe the userfaultfd should not
On Wed, May 22, 2024 at 06:42:55PM +0530, Balasubrmanian, Vignesh wrote:
> > > +enum custom_feature {
> > > + FEATURE_XSAVE_FP = 0,
> > > + FEATURE_XSAVE_SSE = 1,
> > > + FEATURE_XSAVE_YMM = 2,
> > > + FEATURE_XSAVE_BNDREGS = 3,
> > > + FEATURE_XSAVE_BNDCSR = 4,
> > > + FEAT
On Thu, May 23, 2024 at 11:57:00AM +0530, Balasubrmanian, Vignesh wrote:
> Currently, this enum is the same as XSAVE, but when we add other features,
> this
> enum might have a different value of the XSAVE features and can be modified
> without disturbing the existing kernel code.
We will do that
On Sun, May 26, 2024 at 10:24:41AM +0530, Balasubrmanian, Vignesh wrote:
> If we can add a new enum only when we extend, then as Thomas suggested can
> we use other kernel variables as in the first version of the patch until we
> extend for other/new features?
I assume by "other kernel variables"
> Cc: Michael Ellerman
> Cc: Thomas Bogendoerfer
> Cc: Jonathan Corbet
> Cc: Paul Mackerras
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.
On Thu, Nov 03, 2022 at 01:59:45PM +0100, Andrew Jones wrote:
> The patch I'm proposing ensures cpumask_next()'s range, which is actually
> [-1, nr_cpus_ids - 1),
Lemme make sure I understand it correctly: on the upper boundary, if you
supply for n the value nr_cpu_ids - 2, then it will return pot
On Thu, Nov 03, 2022 at 04:34:04PM +0100, Andrew Jones wrote:
> Indeed, but that's less of an issue with cpumask_next() than with
> the way cpuinfo implements its start and next seq ops (next
> unconditionally increments *pos and then calls start and start
> must use *pos - 1 since the first time i
On Thu, Nov 03, 2022 at 09:30:54AM -0700, yury.no...@gmail.com wrote:a
> Callers should pass sane arguments into internal functions if they
> expect sane output.
What internal function? It's in a global header.
> The API not exported to userspace shouldn't sanity-check all inputs
> arguments.
Th
On Thu, Nov 03, 2022 at 10:31:30AM -0700, Yury Norov wrote:
> Let's take for example cpu_llc_shared_mask() added by you in
> arch/x86/include/asm/smp.h recently:
>
> static inline struct cpumask *cpu_llc_shared_mask(int cpu)
> {
> return per_cpu(cpu_llc_shared_map, cpu);
> }
>
> It
+ PPC ML as an FYI that this change will come through tip.
On Fri, Mar 25, 2022 at 11:39:51AM -0400, Brian Gerst wrote:
> x86-32 was the last architecture that implemented separate user and
> kernel registers.
>
> Signed-off-by: Brian Gerst
> ---
> arch/powerpc/kernel/fadump.c | 2
On Wed, Sep 08, 2021 at 05:58:33PM -0500, Tom Lendacky wrote:
> In prep for other confidential computing technologies, introduce a generic
preparation
> helper function, cc_platform_has(), that can be used to check for specific
> active confidential computing attributes, like memory encryption. T
On Wed, Sep 08, 2021 at 05:58:34PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/kernel/cc_platform.c b/arch/x86/kernel/cc_platform.c
> new file mode 100644
> index ..3c9bacd3c3f3
> --- /dev/null
> +++ b/arch/x86/kernel/cc_platform.c
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
> Introduce a powerpc version of the cc_platform_has() function. This will
> be used to replace the powerpc mem_encrypt_active() implementation, so
> the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
> attribute.
>
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote:
> Yes, see
> https://lore.kernel.org/linuxppc-dev/20210914123919.58203...@canb.auug.org.au/T/#t
Aha, more compiler magic stuff ;-\
Oh well, I guess that fix will land upstream soon.
Thx.
--
Regards/Gruss,
Boris.
https://pe
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 18fe19916bc3..4b54a2377821 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char
On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote:
> I don't love it, a new C file and an out-of-line call to then call back
> to a static inline that for most configuration will return false ... but
> whatever :)
Yeah, hch thinks it'll cause a big mess otherwise:
https://lore.kern
On Wed, Sep 08, 2021 at 05:58:31PM -0500, Tom Lendacky wrote:
> This patch series provides a generic helper function, cc_platform_has(),
> to replace the sme_active(), sev_active(), sev_es_active() and
> mem_encrypt_active() functions.
>
> It is expected that as new confidential computing technolo
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Tom already told you to look at the previous threads. Let's read them
together. This one, for example:
htt
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote:
> I have a Intel variant patch (please check following patch). But it includes
> TDX changes as well. Shall I move TDX changes to different patch and just
> create a separate patch for adding intel_cc_platform_has()?
Yes,
*/
> +#ifdef CONFIG_SMP
> + u32 cpu;/* current CPU */
> +#endif
> };
>
> #define INIT_THREAD_INFO(tsk)\
> --
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Sep 21, 2021 at 12:04:58PM -0500, Tom Lendacky wrote:
> Looks like instrumentation during early boot. I worked with Boris offline to
> exclude arch/x86/kernel/cc_platform.c from some of the instrumentation and
> that allowed an allyesconfig to boot.
And here's the lineup I have so far, I'd
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> I still believe calling cc_platform_has() from __startup_64() is totally
> broken as it lacks proper wrapping while accessing global variables.
Well, one of the issues on the AMD side was using boot_cpu_data too
early and the In
1 - 100 of 225 matches
Mail list logo
