On Tue, 2024-05-21 at 12:48 +0200, Jiri Olsa wrote:
> Currently the application with enabled shadow stack will crash
> if it sets up return uprobe. The reason is the uretprobe kernel
> code changes the user space task's stack, but does not update
> shadow stack accordingly.
>
> Adding new
On Mon, 2024-05-20 at 00:18 +0200, Jiri Olsa wrote:
> anyway I think we can fix that in another way by using the optimized
> trampoline,
> but returning to the user space through iret when shadow stack is detected
> (as I did in the first version, before you adjusted it to the sysret path).
>
>
On Wed, 2024-05-15 at 17:26 +0200, Oleg Nesterov wrote:
> > I think it will crash, there's explanation in the comment in
> > tools/testing/selftests/x86/test_shadow_stack.c test
>
> OK, thanks...
>
> But test_shadow_stack.c doesn't do ARCH_PRCTL(ARCH_SHSTK_DISABLE) if
> all the tests succeed ?
On Wed, 2024-05-15 at 08:36 -0600, Jiri Olsa wrote:
> >
> > Let me ask a couple of really stupid questions. What if the shadow stack
> > is "shorter" than the normal stack? I mean,
The shadow stack could overflow if it is not big enough. However since the
normal stack has return addresses and
On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> Let me repeat I know nothing about shadow stacks, only tried to
> read Documentation/arch/x86/shstk.rst few minutes ago ;)
>
> On 05/13, Jiri Olsa wrote:
> >
> > 1) current uretprobe which are not working at the moment and we change
> >
On Mon, 2024-05-13 at 15:23 -0600, Jiri Olsa wrote:
> so at the moment the patch 6 changes shadow stack for
>
> 1) current uretprobe which are not working at the moment and we change
> the top value of shadow stack with shstk_push_frame
> 2) optimized uretprobe which needs to push new frame on
On Mon, 2024-05-13 at 18:50 +0900, Masami Hiramatsu wrote:
> > I guess it's doable, we'd need to keep both trampolines around, because
> > shadow stack is enabled by app dynamically and use one based on the
> > state of shadow stack when uretprobe is installed
> >
> > so you're worried the
On Thu, 2024-05-09 at 10:30 +0200, Jiri Olsa wrote:
> > Per the earlier discussion, this cannot be reached unless uretprobes are in
> > use,
> > which cannot happen without something with privileges taking an action. But
> > are
> > uretprobes ever used for monitoring applications where security
On Tue, 2024-05-07 at 12:53 +0200, Jiri Olsa wrote:
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index 81e6ee95784d..ae6c3458a675 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -406,6 +406,11 @@ SYSCALL_DEFINE0(uretprobe)
> *
On Mon, 2024-05-06 at 09:18 -0700, Christoph Hellwig wrote:
> > On Mon, May 06, 2024 at 09:07:47AM -0700, Rick Edgecombe wrote:
> > > > if (flags & MAP_FIXED) {
> > > > /* Ok, don't mess with it. */
> > > > - return mm_get_unmapped_area(current->mm, NULL,
> >
On Mon, 2024-05-06 at 12:32 -0400, Liam R. Howlett wrote:
>
> I like this patch.
Thanks for taking a look.
>
> I think the context of current->mm is implied. IOW, could we call it
> get_unmapped_area() instead? There are other functions today that use
> current->mm that don't start with
b/arch/x86/include/asm/shstk.h
> @@ -21,6 +21,8 @@ unsigned long shstk_alloc_thread_stack(struct task_struct
> *p, unsigned long clon
> void shstk_free(struct task_struct *p);
> int setup_signal_shadow_stack(struct ksignal *ksig);
> int restore_signal_shadow_stack(
+Some more shadow stack folks from other archs. We are discussing how uretprobes
work with shadow stack.
Context:
https://lore.kernel.org/lkml/ZjU4ganRF1Cbiug6@krava/
On Fri, 2024-05-03 at 21:18 +0200, Jiri Olsa wrote:
>
> hack below seems to fix it for the current uprobe setup,
> we need
On Fri, 2024-05-03 at 15:04 +0200, Jiri Olsa wrote:
> On Fri, May 03, 2024 at 01:34:53PM +0200, Peter Zijlstra wrote:
> > On Thu, May 02, 2024 at 02:23:08PM +0200, Jiri Olsa wrote:
> > > Adding uretprobe syscall instead of trap to speed up return probe.
> > >
> > > At the moment the uretprobe
On Wed, 2024-03-27 at 15:15 +0200, Jarkko Sakkinen wrote:
> I mean I believe the change itself makes sense, it is just not
> fully documented in the commit message.
Ah, I see. Yes, there could be more background on arch_pick_mmap_layout().
On Tue, 2024-03-26 at 23:38 -0700, Dan Williams wrote:
> > +unsigned long
> > +mm_get_unmapped_area(struct mm_struct *mm, struct file *file,
> > + unsigned long addr, unsigned long len,
> > + unsigned long pgoff, unsigned long flags)
> > +{
>
> Seems like a
On Tue, 2024-03-26 at 13:57 +0200, Jarkko Sakkinen wrote:
> In which conditions which path is used during the initialization of mm
> and why is this the case? It is an open claim in the current form.
There is an arch_pick_mmap_layout() that arch's can have their own rules for.
There is also a
Tue, 2 Jan 2024 11:23:54 +0530
> P K wrote:
>
> > Hi,
> >
> > I am unable to trace nf_nat functions using kprobe with the latest kernel.
> > Previously in kernel 6.1.55-1 it was working fine.
> > Can someone please check if it's broken with the latest c
Hi,
I am unable to trace nf_nat functions using kprobe with the latest kernel.
Previously in kernel 6.1.55-1 it was working fine.
Can someone please check if it's broken with the latest commit or i
have to use it differently?
Mentioned below are output:
Kernel - 6.1.55-1
/ # bpftrace -e
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +/**
> + * struct execmem_range - definition of a memory range suitable for
> code and
> + * related data allocations
> + * @start: address space start
> + * @end: address space end (inclusive)
> + * @pgprot:
On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote:
> On Wed, Oct 04, 2023 at 03:39:26PM +, Edgecombe, Rick P wrote:
> > On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> > > It seems a bit weird to copy all of this. Is it trying to be
> > > fast
On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> It seems a bit weird to copy all of this. Is it trying to be faster
> or
> something?
>
> Couldn't it just check r->start in execmem_text/data_alloc() path and
> switch to EXECMEM_DEFAULT if needed then? The execmem_range_is_data()
> part
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +
> +static void execmem_init_missing(struct execmem_params *p)
> +{
> + struct execmem_range *default_range =
> >ranges[EXECMEM_DEFAULT];
> +
> + for (int i = EXECMEM_DEFAULT + 1;
return 0;
> -}
> -#endif
> -
> -void *module_alloc(unsigned long size)
> +struct execmem_params __init *execmem_arch_params(void)
> {
> - gfp_t gfp_mask = GFP_KERNEL;
> - void *p;
> -
> - if (PAGE_ALIGN(size) > MODULES_LEN)
> - r
nd().
Handle this by setting the err appropriately.
Signed-off-by: Pradeep P V K
---
fs/fuse/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index a5ceccc..102c56f 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1283,6 +1283,7 @@ static ssize
struct msm_drm_private *priv =
dev->dev_private;
060530f1ea6740 Rob Clark 2014-03-03 521 struct platform_device *pdev =
priv->gpu_pdev;
5785dd7a8ef0de Akhil P Oommen 2020-10-28 522 struct icc_path *ocmem_icc_path;
5785dd7a8ef0de Akhil P Oommen 2020-10-28 523 struct icc_path *ic
On Mon, 2021-04-05 at 22:32 +0100, Matthew Wilcox wrote:
> On Mon, Apr 05, 2021 at 02:01:58PM -0700, Dave Hansen wrote:
> > On 4/5/21 1:37 PM, Rick Edgecombe wrote:
> > > +static void __dispose_pages(struct list_head *head)
> > > +{
> > > + struct list_head *cur, *next;
> > > +
> > > +
On Mon, 2021-04-05 at 14:01 -0700, Dave Hansen wrote:
> On 4/5/21 1:37 PM, Rick Edgecombe wrote:
> > +static void __dispose_pages(struct list_head *head)
> > +{
> > + struct list_head *cur, *next;
> > +
> > + list_for_each_safe(cur, next, head) {
> > + list_del(cur);
> >
We were not programing the correct bit while clearing the perfcounter oob.
So, clear it correctly using the new 'clear' bit. This fixes the below
error:
[drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set PERFCOUNTER:
0x8000
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm
The speedbin support requires nvmem driver api. So lets explicitly
enable CONFIG_NVMEM to have this support.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index dabb4a1
On 4/2/2021 3:19 AM, Rob Clark wrote:
On Thu, Apr 1, 2021 at 2:03 PM Dmitry Baryshkov
wrote:
On Thu, 1 Apr 2021 at 23:09, Rob Clark wrote:
On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote:
On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen wrote:
On 2/19/2021 9:30 PM, Rob Clark wrote
"failed to read speed-bin (%d). Some OPPs may not be
supported by hardware",
ret);
Reviewed-by: Akhil P Oommen
This looks "fine" to me. ;)
-Akhil.
that's causing this issue to still reoccur.
>
> Also adding Tomi P Sarvela onto this thread, since they were the ones who
> originally tested this
>
> On Thu, 2021-03-18 at 10:13 +0800, Oliver Sang wrote:
> > Hi Lyude, sorry for later.
> >
> > before we s
From: Pradeep P V K
For data read commands, SDHC may initiate data transfers even before it
completely process the command response. In case command itself fails,
driver un-maps the memory associated with data transfer but this memory
can still be accessed by SDHC for the already initiated data
On 2/25/21 6:38 PM, Dave Young wrote:
On 02/23/21 at 09:41am, Saeed Mirzamohammadi wrote:
This adds crashkernel=auto feature to configure reserved memory for
vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
different kernel distributions and different archs based on their
needs.
in sdhci_request_done().
Suggested-by: Veerabhadrarao Badiganti
Signed-off-by: Pradeep P V K
---
drivers/mmc/host/sdhci.c | 58
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index
On 2/17/21 8:02 PM, Baoquan He wrote:
On 02/11/21 at 10:08am, Saeed Mirzamohammadi wrote:
This adds crashkernel=auto feature to configure reserved memory for
vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
different kernel distributions and different archs based on their
needs.
On 2/19/2021 9:30 PM, Rob Clark wrote:
On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen wrote:
On 2/18/2021 9:41 PM, Rob Clark wrote:
On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen wrote:
On 2/18/2021 2:05 AM, Jonathan Marek wrote:
On 2/17/21 3:18 PM, Rob Clark wrote:
On Wed, Feb 17, 2021
On 2/18/2021 9:41 PM, Rob Clark wrote:
On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen wrote:
On 2/18/2021 2:05 AM, Jonathan Marek wrote:
On 2/17/21 3:18 PM, Rob Clark wrote:
On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
wrote:
On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen
On 2/18/2021 2:05 AM, Jonathan Marek wrote:
On 2/17/21 3:18 PM, Rob Clark wrote:
On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
wrote:
On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
On 2/17/2021 8:36 AM, Rob Clark wrote:
On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek
On 2/11/21 12:08 PM, Saeed Mirzamohammadi wrote:
This adds crashkernel=auto feature to configure reserved memory for
vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
different kernel distributions and different archs based on their
needs.
Signed-off-by: Saeed Mirzamohammadi
On 2/17/2021 8:36 AM, Rob Clark wrote:
On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek wrote:
Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a ENOENT error,
to fix the case where the kernel was compiled without CONFIG_NVMEM.
Fixes: fe7952c629da ("drm/msm: Add speed-bin support
On 2/11/2021 9:32 PM, Jordan Crouse wrote:
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
> a patch that has triggered this response. He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
>
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error
gem_submit_reloc));
/* check for overflow: */
Reviewed-by: Akhil P Oommen
-Akhil.
On Thu, 2021-02-04 at 11:34 +0100, Paolo Bonzini wrote:
> On 04/02/21 03:19, Sean Christopherson wrote:
> > Ah, took me a few minutes, but I see what you're saying. LAM will
> > introduce
> > bits that are repurposed for CR3, but not generic GPAs. And, the
> > behavior is
> > based on CPU
On Wed, 2021-02-03 at 16:01 -0800, Sean Christopherson wrote:
>
> - unsigned long cr3_lm_rsvd_bits;
> + u64 reserved_gpa_bits;
LAM defines bits above the GFN in CR3:
On 2/3/2021 4:22 AM, Bjorn Andersson wrote:
On Fri 08 Jan 12:15 CST 2021, Akhil P Oommen wrote:
Please align the $subject prefix with other changes in the same file.
I fixed it up while picking up the patch this time.
Will take of this in future. Thanks, Bjorn.
-Akhil.
Regards,
Bjorn
Add
On 1/22/2021 10:15 AM, Viresh Kumar wrote:
On 22-01-21, 00:41, Dmitry Osipenko wrote:
21.01.2021 14:17, Viresh Kumar пишет:
@@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned
long target_freq)
if (!ret) {
ret = _set_opp_bw(opp_table, opp, dev,
On Thu, 2021-01-21 at 13:19 +, Matthew Wilcox wrote:
> On Wed, Jan 20, 2021 at 05:41:18PM -0800, Rick Edgecombe wrote:
> > When VM_MAP_PUT_PAGES was added, it was defined with the same value
> > as
> > VM_FLUSH_RESET_PERMS. This doesn't seem like it will cause any big
> > functional problems
On 11/22/20 9:47 PM, Dave Young wrote:
Hi Guilherme,
On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense
to you I'm fine with it. I'd just recommend to test recent kernels in
multiple distros with the minimum "range" to see if
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
>> From: "Daniel P. Smith"
>>
>> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
>> above the TPM hardware interface.
>>
&
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index
On 12/7/2020 4:12 PM, Akhil P Oommen wrote:
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
On 12/7/2020 4:12 PM, Akhil P Oommen wrote:
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618
On Fri, 2020-12-04 at 15:24 -0800, Sean Christopherson wrote:
> On Fri, Nov 20, 2020, Rick Edgecombe wrote:
> > +struct perm_allocation {
> > + struct page **pages;
> > + virtual_perm cur_perm;
> > + virtual_perm orig_perm;
> > + struct vm_struct *area;
> > + unsigned long offset;
> > +
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index
On Fri, 2020-12-04 at 18:12 +1000, Nicholas Piggin wrote:
> Excerpts from Edgecombe, Rick P's message of December 1, 2020 6:21
> am:
> > On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote:
> > > Support huge page vmalloc mappings. Config option
> > > HAVE_ARCH_HUGE_VMALLOC
> > > enables
On 12/2/2020 10:00 PM, Jordan Crouse wrote:
On Wed, Dec 02, 2020 at 08:53:51PM +0530, Akhil P Oommen wrote:
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based
<< Resending since Jordan wasn't in the CC list >>
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation
On Mon, 2020-11-30 at 12:21 -0800, Rick Edgecombe wrote:
> another option could be to use the changes here:
> https://lore.kernel.org/lkml/20201125092208.12544-4-r...@kernel.org/
> to reset the direct map for a large page range at a time for large
> vmalloc pages.
Oops, sorry. This wouldn't be
On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote:
> Support huge page vmalloc mappings. Config option
> HAVE_ARCH_HUGE_VMALLOC
> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> supports PMD sized vmap mappings.
>
> vmalloc will attempt to allocate PMD-sized pages if
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.
Signed-off-by: Akhil P Oommen
---
Changes from v1:
1. Added
On 11/16/2020 10:44 PM, Jordan Crouse wrote:
On Mon, Nov 16, 2020 at 07:40:03PM +0530, Akhil P Oommen wrote:
On 11/12/2020 10:05 PM, Jordan Crouse wrote:
On Thu, Nov 12, 2020 at 09:19:04PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based
Extend speed-bin support to a618 gpu.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e0ff16c..21db7ae 100644
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index
On 11/16/2020 9:52 PM, Rob Clark wrote:
On Mon, Nov 16, 2020 at 6:34 AM Akhil P Oommen wrote:
On 11/12/2020 10:07 PM, Rob Clark wrote:
On Thu, Nov 12, 2020 at 7:49 AM Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed
ith NULL.
This could avoid accessing the already free request from other
contexts while iterating over the requests.
Signed-off-by: Pradeep P V K
---
block/blk-mq.c | 1 +
block/blk-mq.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 55bcee5..9996cb1
On Tue, 2020-11-24 at 10:16 +, Christoph Hellwig wrote:
> On Mon, Nov 23, 2020 at 12:01:35AM +, Edgecombe, Rick P wrote:
> > Another option could be putting the new metadata in vm_struct and
> > just
> > return that, like get_vm_area(). Then we don't need to in
On Tue, 2020-11-24 at 10:19 +, h...@infradead.org wrote:
> But I thought that using those pgprot flags was still sort
> overloading
> > the meaning of pgprot. My understanding was that it is supposed to
> > hold
> > the actual bits set in the PTE. For example large pages or TLB
> > hints
> >
On Mon, 2020-11-23 at 09:00 +, Christoph Hellwig wrote:
> First thanks for doing this, having a vmalloc variant that starts out
> with proper permissions has been on my todo list for a while.
>
> > +#define PERM_R 1
> > +#define PERM_W 2
> > +#define PERM_X 4
> > +#define PERM_RWX
On Sat, 2020-11-21 at 20:10 -0800, Andy Lutomirski wrote:
> On Fri, Nov 20, 2020 at 12:30 PM Rick Edgecombe
> wrote:
> > In order to allow for future arch specific optimizations for
> > vmalloc
> > permissions, first add an implementation of a new interface that
> > will
> > work cross arch by
On 11/12/2020 10:07 PM, Rob Clark wrote:
On Thu, Nov 12, 2020 at 7:49 AM Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend
On 11/12/2020 10:05 PM, Jordan Crouse wrote:
On Thu, Nov 12, 2020 at 09:19:04PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.
Signed-off-by: Akhil P Oommen
---
This patch is rebased on top
On 11/5/2020 2:28 AM, Rob Clark wrote:
On Wed, Nov 4, 2020 at 12:03 PM Rob Herring wrote:
On Fri, 30 Oct 2020 16:17:12 +0530, Akhil P Oommen wrote:
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
structure.
NOTE: for the RFC, early_pcr_extend.c is built unconditionally in the
Makefile. In the full Secure Launch patch set it is conditionally built
if CONFIG_SECURE_LAUNCH is defined.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
---
arch/x86/boot/compressed/Makefile
be included in the compressed
kernel environment.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
---
include/linux/tpm.h| 269 +
include/linux/tpm_buffer.h | 123 +
include/linux/tpm_core.h | 185
Move definitions from drivers/char/tpm/tpm_tis_core.h to new file
drivers/char/tpm/tpm_tis_defs.h. This allows tpm_tis_defs.h to be included
in the Secure Launch early PCR extend module. The rest of tpm_tis_core.h
cannot be included in the compressed kernel environment.
Signed-off-by: Daniel P
Memory management calls cannot be made in the compressed kernel
environment to dynamically allocate TPM buffer space. For the Secure
Launch early PCR extend code, use a static buffer instead.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
---
include/linux/tpm_buffer.h | 12
. The remaining code to do the extend is minimal and appropriate for
the compressed kernel environment.
Thank you,
Daniel P. Smith and Ross Philipson
Daniel P. Smith (4):
tpm: Move TPM TIS definitions out of TIS core header
tpm: Move core definitions and buffer management out of main TPM
header
tpm
From: John Donnelly
The assignment statement of a local variable "struct tp_nvram_state s[2] = {0};
is not valid for all versions of compilers.
Fixes: 515ded02bc4b ("platform/x86: thinkpad_acpi: initialize tp_nvram_state
variable")
Signed-off-by: John Donnelly
---
From: John Donnelly
The assignment statement of a local variable "struct tp_nvram_state s[2] = {0};
"
is not valid for all versions of compilers (UEK6 on OL7).
Fixes: 515ded02bc4b ("platform/x86: thinkpad_acpi: initialize tp_nvram_state
variable")
Signed-off-by: John Donnelly
---
From: John Donnelly
The assignment statement of a local variable "struct hpi_pci pci = { 0
}; " is not valid for all versions of compiler.
Fixes: 9c3c9d37ae1e ("ALSA: asihpi: fix iounmap in error handler")
Signed-off-by: John Donnelly
---
sound/pci/asihpi/hpioctl.c | 3 ++-
1 file changed, 2
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
Reviewed-by: Matthias Kaehlcke
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
Reviewed-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
Tested-by: Matthias Kaehlcke
---
Changes in v5:
1. Update Reviewed-by/Tested-by tags
Changes in v4:
1. Fix gpu cooling map.
2. Add mka's
On 10/30/2020 2:18 AM, m...@chromium.org wrote:
On Thu, Oct 29, 2020 at 01:37:19PM +0530, Akhil P Oommen wrote:
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
Reviewed-by: Matthias Kaehlcke
Wait, I did
On Thu, 2020-10-29 at 10:12 +0200, Mike Rapoport wrote:
> This series goal was primarily to separate dependincies and make it
> clearer what DEBUG_PAGEALLOC and what SET_DIRECT_MAP are. As it
> turned
> out, there is also some lack of consistency between architectures
> that
> implement either of
On Thu, 2020-10-29 at 09:54 +0200, Mike Rapoport wrote:
> __kernel_map_pages() on arm64 will also bail out if rodata_full is
> false:
> void __kernel_map_pages(struct page *page, int numpages, int enable)
> {
> if (!debug_pagealloc_enabled() && !rodata_full)
> return;
>
>
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
Reviewed-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
Reviewed-by: Matthias Kaehlcke
---
Changes in v4:
1. Fix gpu cooling map.
2. Add mka's Reviewed-by tag.
Changes in v3:
1. Minor fix
On 10/29/2020 6:09 AM, m...@chromium.org wrote:
Hi Akhil,
On Wed, Oct 28, 2020 at 07:09:53PM +0530, Akhil P Oommen wrote:
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30
On Wed, 2020-10-28 at 13:09 +0200, Mike Rapoport wrote:
> On Tue, Oct 27, 2020 at 09:46:35AM +0100, David Hildenbrand wrote:
> > On 27.10.20 09:38, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 06:05:30PM +, Edgecombe, Rick P
> > > wrote:
> > >
&g
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180
1 - 100 of 4621 matches
Mail list logo
