Le 11/10/2017 à 14:30, Vaibhav Jain a écrit :
Presently the PSL9 specific cxl_stop_trace_psl9() only stops the RX0
traces on the CXL adapter when a PSL error irq is triggered. The patch
updates the function to stop all the traces arrays and move them to
the FIN state. The implementation issues t
On Wed, Oct 18, 2017 at 11:24:43AM +1100, Daniel Axtens wrote:
> Hi Daniel,
>
> >> Initially I wondered if this info printk could be moved into
> >> vga_arbiter_check_bridge_sharing(), but it's been separated out since
> >> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
> >> poss
> The printk removals do change the objects.
>
> The value of that type of change is only for resource limited systems.
I imagine that such small code adjustments are also useful for other systems.
> Markus' changelogs leave much to be desired.
Would you like to help more to improve the provid
> On Tue, 17 Oct 2017, Mimi Zohar wrote:
>
> > On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote:
> > >
> > > On Tue, 17 Oct 2017, Mimi Zohar wrote:
> > >
> > > > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > > > wrote:
> > > > > > > Replace the specification of data st
IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
which is the mask register.
Signed-off-by: Christophe Leroy
---
arch/powerpc/sysdev/ipic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 16
On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > The printk removals do change the objects.
> >
> > The value of that type of change is only for resource limited systems.
>
> I imagine that such small code adjustments are also useful for other systems.
Your imagination and mine di
> On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > The printk removals do change the objects.
> > >
> > > The value of that type of change is only for resource limited systems.
> >
> > I imagine that such small code adjustments are also useful for other
> systems.
>
> Your imagina
>> I imagine that such small code adjustments are also useful for other systems.
>
> Your imagination and mine differ.
This can generally be.
> Where do you _think_ it matters?
It seems that this discussion branch referred still to my cover letter
for possible changes in the TPM software area.
On Wed, 18 Oct 2017, alexander.stef...@infineon.com wrote:
> > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > > The printk removals do change the objects.
> > > >
> > > > The value of that type of change is only for resource limited systems.
> > >
> > > I imagine that such sma
On Wed, 2017-10-18 at 12:00 +0200, Julia Lawall wrote:
>
> On Wed, 18 Oct 2017, alexander.stef...@infineon.com wrote:
>
> > > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > > > The printk removals do change the objects.
> > > > >
> > > > > The value of that type of change is o
> On Wed, 18 Oct 2017, alexander.stef...@infineon.com wrote:
>
> > > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > > > The printk removals do change the objects.
> > > > >
> > > > > The value of that type of change is only for resource limited systems.
> > > >
> > > > I imagine
On Wed, 2017-10-18 at 10:44 +, alexander.stef...@infineon.com wrote:
> > For instance, nothing about
> > > > sizeof(type)
> > > > vs
> > > > sizeof(*ptr)
> > > > makes it easier for a human to read the code.
> > >
> > > If it does not make it easier to read the code for you, th
> Ugly grep follows:
>
> $ grep -rohP --include=*.[ch] "\w+\s*=\s*[kv].alloc\s*\(\s*sizeof.*," * | \
> sed -r -e 's/(\w+)\s*=\s*[kv].alloc\s*\(\s*sizeof\s*\(\s*\*\s*\1\s*\)/foo =
> k.alloc(sizeof(*foo))/' \
> -e
> 's/(\w+)\s*=\s*[kv].alloc\s*\(\s*sizeof\s*\(\s*struct\s+\w+\s*\)/foo =
Daniel Vetter writes:
> On Wed, Oct 18, 2017 at 11:24:43AM +1100, Daniel Axtens wrote:
>> Hi Daniel,
>>
>> >> Initially I wondered if this info printk could be moved into
>> >> vga_arbiter_check_bridge_sharing(), but it's been separated out since
>> >> 3448a19da479b ("vgaarb: use bridges to cont
> On Wed, 2017-10-18 at 10:44 +, alexander.stef...@infineon.com wrote:
> > > For instance, nothing about
> > > > > sizeof(type)
> > > > > vs
> > > > > sizeof(*ptr)
> > > > > makes it easier for a human to read the code.
> > > >
> > > > If it does not make it easier to read the code
Distros vary the way they enable SysRq by default - mostly they seem
to enable some mask and then majority of the SysRq functions are
disabled. For instance, xmon does not even have a mask, and unsless
SysRq are completely enabled ( == 1), xmon trigger keeps disabled.
Countless times while investi
On Wed, 2017-10-18 at 13:00 +0200, SF Markus Elfring wrote:
> > Ugly grep follows:
> >
> > $ grep -rohP --include=*.[ch] "\w+\s*=\s*[kv].alloc\s*\(\s*sizeof.*," * | \
> > sed -r -e 's/(\w+)\s*=\s*[kv].alloc\s*\(\s*sizeof\s*\(\s*\*\s*\1\s*\)/foo
> > = k.alloc(sizeof(*foo))/' \
> > -e
>
Unpleasant consequences are possible in both cases.
>> How much do you care to reduce the failure probability further?
>
> Zero.
I am interested to improve the software situation a bit more here.
Regards,
Markus
Kees Cook writes:
> On Tue, Oct 17, 2017 at 5:29 AM, Michael Ellerman wrote:
>> Nicholas Piggin writes:
>>
>>> On Mon, 16 Oct 2017 16:47:10 -0700
>>> Kees Cook wrote:
>>>
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using
From: SF Markus Elfring
> Unpleasant consequences are possible in both cases.
> >> How much do you care to reduce the failure probability further?
> >
> > Zero.
>
> I am interested to improve the software situation a bit more here.
There are probably better places to spend your time!
If you
Breno Leitao writes:
> Currently xmon could call XIVE functions from OPAL even if the XIVE is
> disabled or does not exist in the system, as in POWER8 machines. This
> causes the following exception:
>
> 1:mon> dx
> cpu 0x1: Vector: 700 (Program Check) at [c00423c93450]
> pc: c000
On 10/17/17 8:36 PM, Alexey Kardashevskiy wrote:
> PowerNV KVM guest is a pseries machine so this code will execute there.
>
The configure sriov path will fail and not enable sriov if resources are
not met. I.e. the IOV Bar is not set in PF IOV Resources, which in this
case gets assigned by firmwar
On Wed, 18 Oct 2017, David Laight wrote:
> From: SF Markus Elfring
> > Unpleasant consequences are possible in both cases.
> > >> How much do you care to reduce the failure probability further?
> > >
> > > Zero.
> >
> > I am interested to improve the software situation a bit more here.
>
>
>> If you want 'security' for kmalloc() then:
>>
>> #define KMALLOC_TYPE(flags) (type *)kmalloc(sizeof (type), flags)
>> #define KMALLOC(ptr, flags) *(ptr) = KMALLOC_TYPE(typeof *(ptr), flags)
Such an approach might help.
>> and change:
>> ptr = kmalloc(sizeof *ptr, flags);
>> to:
>> K
On Tue, Oct 17, 2017 at 02:03:02PM +0300, Andy Shevchenko wrote:
> On Mon, 2017-10-16 at 19:33 +0200, SF Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Mon, 16 Oct 2017 18:28:17 +0200
> >
> > Replace the specification of data structures by pointer dereferences
> > as the parameter for t
On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com wrote:
> > > Replace the specification of data structures by pointer dereferences
> > > as the parameter for the operator "sizeof" to make the corresponding
> > > size
> > > determination a bit safer according to the Linux cod
On Tue, Oct 17, 2017 at 04:02:05PM +0300, Andy Shevchenko wrote:
> On Tue, 2017-10-17 at 08:52 -0400, Mimi Zohar wrote:
> > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > wrote:
> > > > > Replace the specification of data structures by pointer
> > > > > dereferences
> > > > >
On Tue, Oct 17, 2017 at 08:41:04PM +0200, SF Markus Elfring wrote:
> Do you find my wording “This issue was detected by using the
> Coccinelle software.” insufficient?
This is fine for cover letter, not for the commits.
After your analysis software finds an issue you should manually analyze
what
On Mon, Oct 16, 2017 at 10:44:18PM +0200, SF Markus Elfring wrote:
> > A minor complaint: all commits are missing "Fixes:" tag.
>
> * Do you require it to be added to the commit messages?
I don't require it. It's part of the development process:
https://www.kernel.org/doc/html/v4.12/process/subm
On Tue, Oct 17, 2017 at 12:44:34PM +0300, Dan Carpenter wrote:
> On Tue, Oct 17, 2017 at 10:56:42AM +0200, Julia Lawall wrote:
> >
> >
> > On Tue, 17 Oct 2017, Dan Carpenter wrote:
> >
> > > On Mon, Oct 16, 2017 at 09:35:12PM +0300, Jarkko Sakkinen wrote:
> > > >
> > > > A minor complaint: all c
On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote:
> On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> > >
> > > Fixes is only for bug fixes. These don't fix any bugs.
> >
> > How do you distinguish these in questionable source code
> > from other error categories or so
On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand wrote:
> On 10/17/17 14:46, Rob Herring wrote:
>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull wrote:
>>> On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring wrote:
>>>
>>> Hi Rob,
>>>
With dependencies on a statically allocated full path name converted
>> Do you find my wording “This issue was detected by using the
>> Coccinelle software.” insufficient?
>
> This is fine for cover letter, not for the commits.
I guess that there are more opinions available by other contributors
for this aspect.
> After your analysis software finds an issue you
>>> A minor complaint: all commits are missing "Fixes:" tag.
>>
>> * Do you require it to be added to the commit messages?
>
> I don't require it. It's part of the development process:
>
> https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html
Yes. - But other contributors pointed
On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand wrote:
>> On 10/17/17 14:46, Rob Herring wrote:
>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull wrote:
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring wrote:
Hi Rob,
> With de
On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand
> > wrote:
> >> On 10/17/17 14:46, Rob Herring wrote:
> >>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull wrote:
> On Mon, Aug 21, 2017
Hi Ram,
On 31/07/2017 02:12, Ram Pai wrote:
> arch independent code calls arch_override_mprotect_pkey()
> to return a pkey that best matches the requested protection.
>
> This patch provides the implementation.
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/mmu_context.h |5 ++
On Wed, Oct 18, 2017 at 05:22:19PM +0200, SF Markus Elfring wrote:
> >> Do you find my wording “This issue was detected by using the
> >> Coccinelle software.” insufficient?
> >
> > This is fine for cover letter, not for the commits.
>
> I guess that there are more opinions available by other con
On 31/07/2017 02:12, Ram Pai wrote:
> helper function that checks if the read/write/execute is allowed
> on the pte.
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++
> arch/powerpc/include/asm/pkeys.h | 12 +++
> arch/powerpc/mm/
Hi Ram,
On 31/07/2017 02:12, Ram Pai wrote:
> Total 32 keys are available on power7 and above. However
> pkey 0,1 are reserved. So effectively we have 30 pkeys.
>
> On 4K kernels, we do not have 5 bits in the PTE to
> represent all the keys; we only have 3bits.Two of those
> keys are res
On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote:
> >
> > On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> > >
> > > >
> > > >
> > > > Fixes is only for bug fixes. These don't fix any bugs.
> > >
> > > How
On 31/07/2017 02:12, Ram Pai wrote:
> Map the PTE protection key bits to the HPTE key protection bits,
> while creating HPTE entries.
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 +
> arch/powerpc/include/asm/mmu_context.h|6 ++
>
> Commit message should just describe in plain text what you are doing
Did other contributors find the wording “Replace …”
> and why.
and “… a bit safer according to the Linux coding style convention.”
sufficient often enough already?
Which description would you find more appropriate for this
Hi Andrey,
I asked Will, about it, and he preferred to have this patched added to
the end of my series instead of replacing "arm64/kasan: add and use
kasan_map_populate()".
In addition, Will's patch stops using large pages for kasan memory, and
thus might add some regression in which case it
On Wed, Oct 18, 2017 at 01:03:10PM -0400, Pavel Tatashin wrote:
> I asked Will, about it, and he preferred to have this patched added to the
> end of my series instead of replacing "arm64/kasan: add and use
> kasan_map_populate()".
As I said, I'm fine either way, I just didn't want to cause extra
As I said, I'm fine either way, I just didn't want to cause extra work
or rebasing:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/535703.html
Makes sense. I am also fine either way, I can submit a new patch merging
together the two if needed.
Pavel
On Wed, Oct 18, 2017 at 09:09:48AM -0700, James Bottomley wrote:
> On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote:
> > >
> > > On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> > > >
> > > > >
> > > > >
>
Thank you Andrey, I will test this patch. Should it go on top or replace
the existing patch in mm-tree? ARM and x86 should be done the same
either both as follow-ups or both replace.
Pavel
On 10/18/2017 08:14 PM, Pavel Tatashin wrote:
> Thank you Andrey, I will test this patch. Should it go on top or replace the
> existing patch in mm-tree? ARM and x86 should be done the same either both as
> follow-ups or both replace.
>
It's a replacement of your patch.
> Pavel
>
> --
> To
On Wed, Oct 18, 2017 at 06:43:10PM +0200, SF Markus Elfring wrote:
> > Commit message should just describe in plain text what you are doing
>
> Did other contributors find the wording “Replace …”
>
>
> > and why.
>
> and “… a bit safer according to the Linux coding style convention.”
> sufficie
On Wed, Oct 18, 2017 at 08:18:58PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 18, 2017 at 06:43:10PM +0200, SF Markus Elfring wrote:
> > > Commit message should just describe in plain text what you are doing
> >
> > Did other contributors find the wording “Replace …”
> >
> >
> > > and why.
> >
Hi Andrew and Michal,
There are a few changes I need to do to my series:
1. Replace these two patches:
arm64/kasan: add and use kasan_map_populate()
x86/kasan: add and use kasan_map_populate()
With:
x86/mm/kasan: don't use vmemmap_populate() to initialize
shadow
arm64/mm/kasan: don't use vme
> For 1/4 and 2/4: explain why the message can be omitted.
Why did you not reply directly with this request for the update steps
with the subject “Delete an error message for a failed memory allocation
in tpm_…()”?
https://patchwork.kernel.org/patch/10009405/
https://patchwork.kernel.org/patch/10
> One more word of advice: send the three as separate patches.
I do not see a need for an immediate resend at the moment.
> My guess is that it takes a factor longer time to apply 4/4
> than other patches because there's more limited crowd who can test it.
This is fine for me if somebody would
On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote:
> > For 1/4 and 2/4: explain why the message can be omitted.
> > That's all.
>
> I assume that there might be also some communication challenges
> involved.
>
>
> > 3/4: definitive NAK, too much noise compared to value.
>
> I tried to
>> Why did you not reply directly with this request for the update steps
>> with the subject “Delete an error message for a failed memory allocation
>> in tpm_…()”?
>>
>> https://patchwork.kernel.org/patch/10009405/
>> https://patchwork.kernel.org/patch/10009415/
>>
>> I find that there can be diff
On Wed, 18 Oct 2017 02:18:46 -0700
Joe Perches wrote:
> On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > The printk removals do change the objects.
> > >
> > > The value of that type of change is only for resource limited
> > > systems.
> >
> > I imagine that such small code
On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
wrote:
> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
>> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand
>> > wrote:
>> >> On 10/17/17 14:46, Rob Herring wrote:
>> >>> On Tue, Oct
On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
wrote:
> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
>> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand
>> > wrote:
>> >> On 10/17/17 14:46, Rob Herring wrote:
>> >>> On Tue, Oct
From: Markus Elfring
Date: Wed, 18 Oct 2017 21:11:23 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (5):
Delete five error messages for a failed memory allocation
Improve nine size determinations
Delete an unnecessary variable initia
From: Markus Elfring
Date: Wed, 18 Oct 2017 16:39:01 +0200
Omit extra messages for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/pseries/dtl.c | 5 +
arch/powerpc/pl
From: Markus Elfring
Date: Wed, 18 Oct 2017 18:18:11 +0200
Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detec
From: Markus Elfring
Date: Wed, 18 Oct 2017 19:14:39 +0200
The variable "table_group" will be set to an appropriate pointer.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+),
From: Markus Elfring
Date: Wed, 18 Oct 2017 20:15:32 +0200
Return directly after a call of the function "kzalloc_node" failed
at the beginning.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powe
From: Markus Elfring
Date: Wed, 18 Oct 2017 20:48:52 +0200
The kfree() function was called in up to two cases by the
iommu_pseries_alloc_group() function during error handling
even if the passed variable contained a null pointer.
* Adjust jump targets according to the Linux coding style conventi
On 10/17/2017 11:54 AM, SF Markus Elfring wrote:
> Markus Elfring (2):
> Delete an error message for a failed memory allocation in update_flash_db()
> Improve a size determination in two functions
For consistency, please use 'powerpc/ps3' not 'powerpc-ps3' as
the commit log subject prefix. Al
On Fri, 8 Sep 2017 15:45:06 -0700
Ram Pai wrote:
> Make sure that the kernel does not access user pages without
> checking their key-protection.
>
Why? This makes the routines AMR/thread specific? Looks like
x86 does this as well, but these routines are used by GUP from
the kernel.
Balbir Sing
pseries/nodes: Ensure enough nodes avail for operations
pseries/findnodes: Find nodes with memory when booting memoryless nodes
pseries/initnodes: Ensure nodes initialized for hotplug
Signed-off-by: Michael Bringmann
Michael Bringmann (3):
pseries/nodes: Ensure enough nodes avail for operati
pseries/nodes: On pseries systems which allow 'hot-add' of CPU or
memory resources, it may occur that the new resources are to be
inserted into nodes that were not used for these resources at bootup.
In the kernel, any node that is used must be defined and initialized.
This patch ensures that suff
pseries/findnodes: On pseries systems which allow 'hot-add' of
resources, we may boot configurations that have CPUs, but no memory
associated to a node by the affinity calculations. Previously, the
software took a shortcut to collapse initialization and references
to such memoryless nodes with ot
pseries/nodes: On pseries systems which allow 'hot-add' of CPU,
it may occur that the new resources are to be inserted into nodes
that were not used for memory resources at bootup. Many different
configurations of PowerPC resources may need to be supported depending
upon the environment. This pat
On Wed, Oct 18, 2017 at 02:24:03PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:53 -0700
> Ram Pai wrote:
>
> > Introduce helper functions that can initialize the bits in the AMR,
> > IAMR and UAMOR register; the bits that correspond to the given pkey.
> >
> > Signed-off-by: Ram Pai
On Wed, Oct 18, 2017 at 02:49:14PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:58 -0700
> Ram Pai wrote:
>
> > Store and restore the AMR, IAMR and UAMOR register state of the task
> > before scheduling out and after scheduling in, respectively.
> >
> > Signed-off-by: Ram Pai
> > ---
On Wed, Oct 18, 2017 at 03:15:22PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:59 -0700
> Ram Pai wrote:
>
> > This patch provides the implementation of execute-only pkey.
> > The architecture-independent layer expects the arch-dependent
> > layer, to support the ability to create and
On Wed, Oct 18, 2017 at 03:27:33PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:45:00 -0700
> Ram Pai wrote:
>
> > arch-independent code expects the arch to map
> > a pkey into the vma's protection bit setting.
> > The patch provides that ability.
> >
> > Signed-off-by: Ram Pai
> > --
On Wed, Oct 18, 2017 at 03:36:35PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:45:01 -0700
> Ram Pai wrote:
>
> > arch independent code calls arch_override_mprotect_pkey()
> > to return a pkey that best matches the requested protection.
> >
> > This patch provides the implementation.
> >
On Wed, Oct 18, 2017 at 03:39:11PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:45:02 -0700
> Ram Pai wrote:
>
> > map the key protection bits of the vma to the pkey bits in
> > the PTE.
> >
> > The Pte bits used for pkey are 3,4,5,6 and 57. The first
> > four bits are the same
On Wed, Oct 18, 2017 at 03:48:31PM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:45:05 -0700
> Ram Pai wrote:
>
> > helper function that checks if the read/write/execute is allowed
> > on the pte.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/include/asm/book3s/64/pgtable.h |
On Thu, Oct 19, 2017 at 06:57:32AM +1100, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:45:06 -0700
> Ram Pai wrote:
>
> > Make sure that the kernel does not access user pages without
> > checking their key-protection.
> >
>
> Why? This makes the routines AMR/thread specific? Looks like
> x86 doe
On Wed, Oct 18, 2017 at 05:58:18PM +0200, Laurent Dufour wrote:
> Hi Ram,
>
> On 31/07/2017 02:12, Ram Pai wrote:
> > arch independent code calls arch_override_mprotect_pkey()
> > to return a pkey that best matches the requested protection.
> >
> > This patch provides the implementation.
> >
> >
On 10/18/17 11:39, Alan Tull wrote:
> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
> wrote:
>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand
wrote:
> On 10/17/17 14:
On 10/18/17 11:30, Rob Herring wrote:
> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
> wrote:
>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand
wrote:
> On 10/17/17 1
On Wed, Oct 18, 2017 at 06:08:34PM +0200, Laurent Dufour wrote:
>
>
> On 31/07/2017 02:12, Ram Pai wrote:
> > helper function that checks if the read/write/execute is allowed
> > on the pte.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++
> >
On Wed, Oct 18, 2017 at 06:08:46PM +0200, Laurent Dufour wrote:
> Hi Ram,
>
> On 31/07/2017 02:12, Ram Pai wrote:
> > Total 32 keys are available on power7 and above. However
> > pkey 0,1 are reserved. So effectively we have 30 pkeys.
> >
> > On 4K kernels, we do not have 5 bits in the PT
On Wed, Oct 18, 2017 at 06:15:40PM +0200, Laurent Dufour wrote:
>
>
> On 31/07/2017 02:12, Ram Pai wrote:
> > Map the PTE protection key bits to the HPTE key protection bits,
> > while creating HPTE entries.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/include/asm/book3s/64/mmu-has
On Wed, 18 Oct 2017 13:47:05 -0700
Ram Pai wrote:
> On Wed, Oct 18, 2017 at 02:49:14PM +1100, Balbir Singh wrote:
> > On Fri, 8 Sep 2017 15:44:58 -0700
> > Ram Pai wrote:
> >
> > > Store and restore the AMR, IAMR and UAMOR register state of the task
> > > before scheduling out and after sche
On Wed, 18 Oct 2017 13:57:39 -0700
Ram Pai wrote:
> On Wed, Oct 18, 2017 at 03:15:22PM +1100, Balbir Singh wrote:
> > On Fri, 8 Sep 2017 15:44:59 -0700
> > Ram Pai wrote:
> >
> > > This patch provides the implementation of execute-only pkey.
> > > The architecture-independent layer expects t
On Wed, 18 Oct 2017 14:10:41 -0700
Ram Pai wrote:
> On Wed, Oct 18, 2017 at 03:36:35PM +1100, Balbir Singh wrote:
> > On Fri, 8 Sep 2017 15:45:01 -0700
> > Ram Pai wrote:
> >
> > > arch independent code calls arch_override_mprotect_pkey()
> > > to return a pkey that best matches the requeste
On Wed, 18 Oct 2017 14:29:24 -0700
Ram Pai wrote:
> On Thu, Oct 19, 2017 at 06:57:32AM +1100, Balbir Singh wrote:
> > On Fri, 8 Sep 2017 15:45:06 -0700
> > Ram Pai wrote:
> >
> > > Make sure that the kernel does not access user pages without
> > > checking their key-protection.
> > >
> >
On Fri, 8 Sep 2017 15:45:07 -0700
Ram Pai wrote:
> This patch provides the implementation for
> arch_vma_access_permitted(). Returns true if the
> requested access is allowed by pkey associated with the
> vma.
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/mmu_context.h |5 ++
On Fri, 8 Sep 2017 15:45:08 -0700
Ram Pai wrote:
> Handle Data and Instruction exceptions caused by memory
> protection-key.
>
> The CPU will detect the key fault if the HPTE is already
> programmed with the key.
>
> However if the HPTE is not hashed, a key fault will not
> be detected by th
On Fri, 8 Sep 2017 15:45:09 -0700
Ram Pai wrote:
> get_pte_pkey() helper returns the pkey associated with
> a address corresponding to a given mm_struct.
>
This is really get_mm_addr_key() -- no?
Balbir Singh.
On Thu, Oct 19, 2017 at 10:00:38AM +1100, Balbir Singh wrote:
> On Wed, 18 Oct 2017 13:47:05 -0700
> Ram Pai wrote:
>
> > On Wed, Oct 18, 2017 at 02:49:14PM +1100, Balbir Singh wrote:
> > > On Fri, 8 Sep 2017 15:44:58 -0700
> > > Ram Pai wrote:
> > >
> > > > Store and restore the AMR, IAMR a
Michael Ellerman writes:
> Kees Cook writes:
>> On Tue, Oct 17, 2017 at 5:29 AM, Michael Ellerman
>> wrote:
>>> Nicholas Piggin writes:
On Mon, 16 Oct 2017 16:47:10 -0700
Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer
> to
>
On Mon, 16 Oct 2017 23:10:01 -0400
jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> (Andrew you already have v1 in your queue of patch 1, patch 2 is new,
> i think you can drop it patch 1 v1 for v2, v2 is bit more conservative
> and i fixed typos)
>
> All this only affect user of invalidat
On Wed Oct 18 17, SF Markus Elfring wrote:
For 1/4 and 2/4: explain why the message can be omitted.
Why did you not reply directly with this request for the update steps
with the subject “Delete an error message for a failed memory allocation
in tpm_…()”?
https://patchwork.kernel.org/patch/100
On Mon, 16 Oct 2017 23:10:02 -0400
jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> + /*
> + * No need to call mmu_notifier_invalidate_range() as we are
> + * downgrading page table protection not changing it to point
> + * to a new page.
> +
On Thu, Oct 19, 2017 at 01:43:19PM +1100, Balbir Singh wrote:
> On Mon, 16 Oct 2017 23:10:01 -0400
> jgli...@redhat.com wrote:
>
> > From: Jérôme Glisse
> >
> > (Andrew you already have v1 in your queue of patch 1, patch 2 is new,
> > i think you can drop it patch 1 v1 for v2, v2 is bit more co
Ram Pai writes:
> diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c
> index 1a68cb1..c6c5559 100644
> --- a/arch/powerpc/mm/hash64_64k.c
> +++ b/arch/powerpc/mm/hash64_64k.c
> @@ -126,18 +113,13 @@ int __hash_page_4K(unsigned long ea, unsigned long
> access, unsigned long
On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote:
> On Mon, 16 Oct 2017 23:10:02 -0400
> jgli...@redhat.com wrote:
>
> > From: Jérôme Glisse
> >
> > + /*
> > +* No need to call mmu_notifier_invalidate_range() as we are
> > +* downgrading page table p
1 - 100 of 124 matches
Mail list logo
