> From: Shi, Yang
> Sent: Friday, February 05, 2016 5:19 AM
>
> On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> >> Correct FSL folks email address to nxp.com, sorry for the
> inconvenience.
> >
> > Do we need some MAINTAINERS updates in
Hi Ard, Rafael
On Thu, Feb 16, 2017 at 5:14 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> On Wednesday, February 15, 2017 05:44:28 PM Ard Biesheuvel wrote:
>> Hello Bhupesh,
>>
>> On 15 February 2017 at 13:04, Bhupesh Sharma <bhsha...@redhat.com> wrote:
gt;
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Bhupesh Sharma (2):
x86/efi-bgrt: Move efi-bgrt handling out of arch/x86
bgrt: Make ACPI BGRT parsing code common for ARCHs
arch/arm64/kernel/acpi.c | 3 +++
arch/x86/kernel/a
t Fleming <m...@codeblueprint.co.uk>
Cc: Dan Williams <dan.j.willi...@intel.com>
Cc: Dave Young <dyo...@redhat.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
---
arch/x86/platform/efi/Makefile
x.de>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
---
arch/arm64/kernel/acpi.c| 3 +++
arch/x86/kernel/acpi/boot.c | 6 --
drivers/acpi/Kconfig| 2 +-
drivers/acpi/bgrt.c
ably out of scope for you, but since we're moving
>> things around, any chance we could do so in a manner that will enable
>> BGRT support for arm64/ACPI? Happy to test/collaborate on this.
>>
>
> I'm happy to do so, Bhupesh Sharma <bhsha...@redhat.com> said he had
> some i
On Wed, Jan 18, 2017 at 7:30 PM, Ard Biesheuvel
wrote:
> On 18 January 2017 at 13:48, Dave Young wrote:
>> Before invoking the arch specific handler, efi_mem_reserve() reserves
>> the given memory region through memblock.
>>
>> efi_bgrt_init will
, platform
developers may choose where to place this compromise.
Also this patch keeps the default values as new minimums.
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
Reviewed-by: Kees Cook <keesc...@chromium.org>
---
* Changes since v2:
v2 can be seen here (https://patchwork.kern
Hi Michael,
On Wed, Mar 29, 2017 at 1:15 AM, Bhupesh Sharma <bhsha...@redhat.com> wrote:
> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for
> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
> for the mmap base address
Hi Aneesh,
On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
<aneesh.ku...@linux.vnet.ibm.com> wrote:
> Bhupesh Sharma <bhsha...@redhat.com> writes:
>
>> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT)
>> for
>> 32-bit and (30
On Thu, Apr 13, 2017 at 12:39 PM, Balbir Singh wrote:
>>>
>>> Yes. It was derived from TASK_SIZE :
>>>
>>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105
>>>
>>
>> That is getting update to 128TB by default and conditionally to 512TB
>>
>
>
On Thu, Apr 13, 2017 at 12:28 PM, Aneesh Kumar K.V
<aneesh.ku...@linux.vnet.ibm.com> wrote:
>
>
> On Thursday 13 April 2017 12:22 PM, Bhupesh Sharma wrote:
>>
>> Hi Aneesh,
>>
>> On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
>> <aneesh.ku...@l
On Wed, Mar 8, 2017 at 3:05 PM, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote:
>> Yes, it looks better. I can repost with this change. Thanks.
>
> No it doesn't:
>
> #define EFI_VA_START ( -4 * (_AC(1, UL) << 30))
> #define EFI_VA_END
>>vaddr_end >= __START_KERNEL_map);
>> --
>> 2.5.5
>>
>
> Acked-by: Dave Young <dyo...@redhat.com>
>
Thanks Bao for this fix. This makes the KASLR code consistent with
Address space markers hints in [1]
[1] http://lxr.free-electrons.com/source/arch/x86/mm/dump_pagetables.c#L82
Reviewed-by: Bhupesh Sharma <bhsha...@redhat.com>
Regards,
Bhupesh
Hi Dave,
On Wed, Mar 8, 2017 at 1:48 PM, Dave Young wrote:
> On 03/08/17 at 03:47pm, Baoquan He wrote:
>> EFI allocate runtime services regions down from EFI_VA_START, -4G.
>> It should be top-down handling.
>>
>> Signed-off-by: Baoquan He
>> ---
>>
On Wed, Jun 7, 2017 at 2:59 PM, Michael Ellerman wrote:
> Daniel Micay writes:
>
>> Rather than doing this, the base should just be split for an ELF
>> interpreter like PaX.
>
> I don't quite parse that, I think you mean PaX uses a different base for
>
lerman.id.au>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
---
arch/powerpc/include/asm/elf.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
i
On Sat, May 6, 2017 at 5:06 AM, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote:
>> (Including the folks from SGI since this was hit on a UV system)
>
> Wasn't there a BIOS fix supplied at some point which obviated the need
> to boot with
--Original Message-
>> From: Sai Praneeth Prakhya [mailto:sai.praneeth.prak...@intel.com]
>> Sent: Tuesday, September 5, 2017 7:43 PM
>> To: Bhupesh Sharma <bhsha...@redhat.com>
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Matt Fleming
>> &
Hi Sai,
On Sun, Sep 3, 2017 at 1:16 PM, Prakhya, Sai Praneeth
wrote:
>> >
>> > Thanks for this v2.
>> > Introducing the 'efi_switch_mm() ' helper instead of manually
>> > twiddling with %cr3 seems more cleaner.
>> >
>> > I have tested this patchset on a x86_64
Hi Sai,
On Tue, Aug 29, 2017 at 5:07 AM, Sai Praneeth Prakhya
wrote:
> From: Sai Praneeth
>
> Presently, in x86, to invoke any efi function like
> efi_set_virtual_address_map() or any efi_runtime_service() the code path
> typically
On Sat, Sep 2, 2017 at 7:38 PM, Bhupesh Sharma <bhsha...@redhat.com> wrote:
> Hi Sai,
>
> On Tue, Aug 29, 2017 at 5:07 AM, Sai Praneeth Prakhya
> <sai.praneeth.prak...@intel.com> wrote:
>> From: Sai Praneeth <sai.praneeth.prak...@intel.com>
>>
>> Pr
lso add linux-acpi list
>
> Thank you.
>
>> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
>> > <ard.biesheu...@linaro.org> wrote:
>> > > On 15 December 2017 at 09:59, AKASHI Takahiro
>> >
Hi Dave,
On Mon, Dec 18, 2017 at 10:46 AM, Dave Young <dyo...@redhat.com> wrote:
> kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it
> to ke...@lists.infradead.org
>
> Also add linux-acpi list
> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> O
On Mon, Dec 18, 2017 at 4:48 PM, AKASHI Takahiro
<takahiro.aka...@linaro.org> wrote:
> Bhupesh,
>
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro
>> <takahiro.aka...@linaro.org> wrote:
>&g
achines).
So in addition to me testing this on the sgi-uv300 and Dell Optiplex
EFI enabled machine, please feel free to add:
Reviewed-by: Bhupesh Sharma <bhsha...@redhat.com>
Thanks,
Bhupesh
> Note:
> This patch set is based on Linus's tree v4.15-rc3
>
> Sai Praneeth (3):
&
for
assigning the MPIDR_HWID_BITMASK macro value.
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
---
arch/arm64/include/asm/cputype.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index eda8c5f629fc..350c76
On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro
<takahiro.aka...@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>>
>> [snip..]
>>
>> [0.00] linux,usable-memory-range base e80, size 2000
>>
NUMBER(HUGETLB_PAGE_DTOR)=2
NUMBER(VA_BITS)=48
NUMBER(kimage_voffset)=0x5492f5c0
NUMBER(PHYS_OFFSET)=0xee138000
CRASHTIME=1532965574
So, for what it is worth:
Reviewed-by and Tested
have access to
mips hardware, so I will be happy to update the v2 to add mips kernel
bits as well, in case someone is willing to give it a try on their
mips hardware.
> On 19/07/18 15:55, Bhupesh Sharma wrote:
>> On Thu, Jul 19, 2018 at 5:01 PM, James Morse wrote:
>>> On 18/07/
ret = -EFAULT;
>> goto out;
>> }
>> + m = NULL;
>> } else if (m->type == KCORE_VMALLOC) {
>> vread(buf, (char *)start, tsz);
>> /* we have to zero-fill user buffer even if no read */
>> --
>> 2.17.1
Looks sane to me, so:
Reviewed-by: Bhupesh Sharma
Thanks.
On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins <jtopp...@redhat.com> wrote:
> On 02/27/2018 07:40 AM, Bhupesh Sharma wrote:
>> Hi,
>>
>> On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins <jtopp...@redhat.com>
>> wrote:
>>> This patch allo
Hi,
On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
>
> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed
On Wed, Feb 28, 2018 at 3:37 PM, Andy Shevchenko
<andriy.shevche...@linux.intel.com> wrote:
> On Wed, 2018-02-28 at 00:29 +0530, Bhupesh Sharma wrote:
>> On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins <jtopp...@redhat.com
>> > wrote:
>> > On 02/27
ing LPI property table @0x000fc042
[0.00] GICv3: CPU0: using reserved LPI pending table
@0x000fc05c
So, please feel to add:
Tested-by: Bhupesh Sharma
Thanks,
Bhupesh
Hi Dave,
On Mon, Dec 18, 2017 at 10:46 AM, Dave Young wrote:
> kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it
> to ke...@lists.infradead.org
>
> Also add linux-acpi list
> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> On Fri, Dec 15, 2017 at 3:
On Mon, Dec 18, 2017 at 4:48 PM, AKASHI Takahiro
wrote:
> Bhupesh,
>
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro
>> wrote:
>> > On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wr
On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro
wrote:
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>>
>> [snip..]
>>
>> [0.00] linux,usable-memory-range base e80, size 2000
>> [0.00] - e80 , 2000
>> [
in the v3.
Also as I noted during the v2 review, introducing the 'efi_switch_mm()
' helper instead of manually
twiddling with %cr3 seems more cleaner (having personally debugged
this leg several times on the underlying x86 EFI machines).
So in addition to me testing this on the sgi-uv300 and Dell O
Thank you.
>
>> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
>> > wrote:
>> > > On 15 December 2017 at 09:59, AKASHI Takahiro
>> > > wrote:
>> > >> On Wed, Dec 13, 201
i Praneeth Prakhya [mailto:sai.praneeth.prak...@intel.com]
>> Sent: Tuesday, September 5, 2017 7:43 PM
>> To: Bhupesh Sharma
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Matt Fleming
>> ; Ard Biesheuvel ;
>> j...@suse.com; Borislav Petkov ; Luck,
Hi Sai,
On Tue, Aug 29, 2017 at 5:07 AM, Sai Praneeth Prakhya
wrote:
> From: Sai Praneeth
>
> Presently, in x86, to invoke any efi function like
> efi_set_virtual_address_map() or any efi_runtime_service() the code path
> typically involves read_cr3() (save previous pgd), write_cr3()
> (write
On Sat, Sep 2, 2017 at 7:38 PM, Bhupesh Sharma wrote:
> Hi Sai,
>
> On Tue, Aug 29, 2017 at 5:07 AM, Sai Praneeth Prakhya
> wrote:
>> From: Sai Praneeth
>>
>> Presently, in x86, to invoke any efi function like
>> efi_set_virtual_address_map() or any
Hi Sai,
On Sun, Sep 3, 2017 at 1:16 PM, Prakhya, Sai Praneeth
wrote:
>> >
>> > Thanks for this v2.
>> > Introducing the 'efi_switch_mm() ' helper instead of manually
>> > twiddling with %cr3 seems more cleaner.
>> >
>> > I have tested this patchset on a x86_64 machine with the following
>> >
Hi,
On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
>
> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed to the kernel
> is
On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins wrote:
> On 02/27/2018 07:40 AM, Bhupesh Sharma wrote:
>> Hi,
>>
>> On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins
>> wrote:
>>> This patch allows a user to configure ACPI to be preferred over
>>
On Wed, Feb 28, 2018 at 3:37 PM, Andy Shevchenko
wrote:
> On Wed, 2018-02-28 at 00:29 +0530, Bhupesh Sharma wrote:
>> On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins > > wrote:
>> > On 02/27/2018 07:40 AM, Bhupesh Sharma wrote:
>> > >
>
>> > F
for
assigning the MPIDR_HWID_BITMASK macro value.
Signed-off-by: Bhupesh Sharma
---
arch/arm64/include/asm/cputype.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index eda8c5f629fc..350c76a1d15b 100644
--- a/arch
Hi Catalin, Chen,
On Mon, Oct 5, 2020 at 10:39 PM Catalin Marinas wrote:
>
> On Sat, Sep 12, 2020 at 06:44:29AM -0500, John Donnelly wrote:
> > On 9/7/20 8:47 AM, Chen Zhou wrote:
> > > Chen Zhou (9):
> > >x86: kdump: move CRASH_ALIGN to 2M
> > >x86: kdump: make the lower bound of crash
Hi Catalin,
On Tue, Oct 6, 2020 at 11:30 PM Catalin Marinas wrote:
>
> On Mon, Oct 05, 2020 at 11:12:10PM +0530, Bhupesh Sharma wrote:
> > I think my earlier email with the test results on this series bounced
> > off the mailing list server (for some weird reason), but I sti
Hi Chen,
On Wed, Nov 11, 2020 at 7:05 PM chenzhou wrote:
>
> Hi Baoquan, Bhupesh,
>
>
> On 2020/11/11 11:01, Baoquan He wrote:
> > Hi Zhou, Bhupesh
> >
> > On 10/31/20 at 03:44pm, Chen Zhou wrote:
> >> There are following issues in arm64 kdump:
> >> 1. We use crashkernel=X to reserve crashkernel
> + VMCOREINFO_OFFSET(uts_namespace, name);
> VMCOREINFO_SYMBOL(node_online_map);
> #ifdef CONFIG_MMU
> VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir);
> --
> 2.26.2
Thanks for making the changes we discussed in the v1 review. Otherwise
the patch looks fine to me, so:
Reviewed-by: Bhupesh Sharma
Hi John,
On Wed, May 20, 2020 at 1:53 AM John Donnelly
wrote:
>
>
>
> > On May 19, 2020, at 5:21 AM, Arnd Bergmann wrote:
> >
> > On Thu, Mar 26, 2020 at 4:10 AM Chen Zhou wrote:
> >>
> >> Hi all,
> >>
> >> Friendly ping...
> >
> > I was asked about this patch series, and see that you last
Hi John,
On Tue, Jun 2, 2020 at 1:01 AM John Donnelly wrote:
>
> Hi,
>
>
> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> > Hi Chen,
> >
> > On Thu, May 21, 2020 at 3:05 PM Chen Zhou wrote:
> >> This patch series enable reserving crashkernel above 4G in arm64.
> >>
> >> There are following
Hello,
On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote:
>
> Apologies for the delayed update. Its been quite some time since I
> posted the last version (v5), but I have been really caught up in some
> other critical issues.
>
> Changes since v5:
>
ux-arm-ker...@lists.infradead.org
Signed-off-by: Bhupesh Sharma
---
arch/arm64/kernel/kexec_image.c| 2 +-
arch/arm64/kernel/machine_kexec_file.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 2514fd6f12cb..29
Hi Mark,
Thanks for the review.
On Tue, Apr 28, 2020 at 3:37 PM Mark Rutland wrote:
>
> Hi Bhupesh,
>
> On Tue, Apr 28, 2020 at 02:22:17PM +0530, Bhupesh Sharma wrote:
> > commit b326e9560a28 ("hw-breakpoints: Use overflow handler instead of
> >
ation
from 'hw_breakpoint.h' as well.
Cc: Mark Rutland
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Bhupesh Sharma
---
include/linux/hw_breakpoint.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h
index 6058c3844a76..fe1302da8
ation
from 'hw_breakpoint.h' as well.
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Ravi Bangoria
Cc: Michael Ellerman
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Mark Rutland
Signed-off-by: Bhupesh Sharma
---
- Resending with Acked-by from
ed-off-by: Bhupesh Sharma
---
drivers/net/ethernet/qlogic/qede/qede.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede.h
b/drivers/net/ethernet/qlogic/qede/qede.h
index 234c6f30effb..b55ab32ef0b3 100644
--- a/drivers/net/ethernet/qlogic/qede/
ult TX and RX ring count in kdump kernel.
[PATCH 2/2] - Disables qed SRIOV feature in kdump kernel (as it is
normally not a supported kdump target for saving
vmcore).
[1]. Memstrack tool: https://github.com/ryncsn/memstrack
-
Bhupesh Sharma (2):
net: qed*: Reduce RX
-off-by: Bhupesh Sharma
---
drivers/net/ethernet/qlogic/qed/qed_sriov.h | 10 +++---
drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h
b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
Hi David,
On Wed, May 6, 2020 at 2:54 AM David Miller wrote:
>
> From: Bhupesh Sharma
> Date: Wed, 6 May 2020 00:34:40 +0530
>
> > -#define NUM_RX_BDS_DEF ((u16)BIT(10) - 1)
> > +#define NUM_RX_BDS_DEF ((is_kdump_kernel()) ? ((u16)BIT(6)
Hi Peter, Frederic, Ingo
On Thu, Apr 30, 2020 at 9:49 AM Bhupesh Sharma wrote:
>
> Hi Mark,
>
> Thanks for the review.
>
> On Tue, Apr 28, 2020 at 3:37 PM Mark Rutland wrote:
> >
> > Hi Bhupesh,
> >
> > On Tue, Apr 28, 2020 at 02:22:17PM +0530, Bhupe
-off-by: Bhupesh Sharma
---
drivers/net/ethernet/qlogic/qed/qed_sriov.h | 10 +++---
drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h
b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
ed-off-by: Bhupesh Sharma
---
drivers/net/ethernet/qlogic/qede/qede.h | 2 ++
drivers/net/ethernet/qlogic/qede/qede_main.c | 11 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede.h
b/drivers/net/ethernet/qlogic/qede/qede.h
X ring count in kdump kernel.
[PATCH 2/2] - Disables qed SRIOV feature in kdump kernel (as it is
normally not a supported kdump target for saving
vmcore).
[1]. Memstrack tool: https://github.com/ryncsn/memstrack
Bhupesh Sharma (2):
net: qed*: Reduce RX and TX defaul
...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Bhupesh Sharma (2):
crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo
arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
Documentation/admin-guide/kdump/vmcoreinfo.rst | 16
-by: John Donnelly
Signed-off-by: Bhupesh Sharma
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 5 +
kernel/crash_core.c| 1 +
2 files changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump
-by: John Donnelly
Signed-off-by: Bhupesh Sharma
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 11 +++
arch/arm64/include/asm/pgtable-hwdef.h | 1 +
arch/arm64/kernel/crash_core.c | 10 ++
3 files changed, 22 insertions(+)
diff --git a/Documentation
Hello Igor,
On Wed, May 6, 2020 at 12:21 PM Igor Russkikh wrote:
>
>
>
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -574,13 +575,13 @@ int qede_add_tc_flower_fltr(struct qede_dev *edev,
> > __be16 proto,
> > #define RX_RING_SIZE
orse
Cc: Mark Rutland
Cc: Will Deacon
Cc: Catalin Marinas
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: ke...@lists.infradead.org
Reported-by: Prabhakar Kushwaha
Signed-off-by: Bhupesh Sharma
---
arch/arm64/mm/init.
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: ke...@lists.infradead.org
Reported-by: Prabhakar Kushwaha
Signed-off-by: Bhupesh Sharma
---
mm/memcontrol.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: ke...@lists.infradead.org
Reported-by: Prabhakar Kushwaha
Signed-off-by: Bhupesh Sharma
Bhupesh Sharma (2):
mm/memcontrol: Fix OOPS inside mem_cgroup_get_nr_swap_pages()
arm64: Allocate crashker
On Thu, Jul 2, 2020 at 10:45 PM Catalin Marinas wrote:
>
> On Thu, 14 May 2020 00:22:35 +0530, Bhupesh Sharma wrote:
> > Apologies for the delayed update. Its been quite some time since I
> > posted the last version (v5), but I have been really caught up in some
> &g
Hi Michal,
On Thu, Jul 2, 2020 at 11:30 AM Michal Hocko wrote:
>
> On Thu 02-07-20 03:44:19, Bhupesh Sharma wrote:
> > Prabhakar reported an OOPS inside mem_cgroup_get_nr_swap_pages()
> > function in a corner case seen on some arm64 boards when kdump kernel
> > runs wit
Hi Will,
On Thu, Jul 2, 2020 at 1:20 PM Will Deacon wrote:
>
> On Thu, Jul 02, 2020 at 03:44:20AM +0530, Bhupesh Sharma wrote:
> > commit bff3b04460a8 ("arm64: mm: reserve CMA and crashkernel in
> > ZONE_DMA32") allocates crashkernel for arm64 in the ZONE_DMA32.
Hi Chen,
On Fri, Jul 3, 2020 at 9:24 AM Chen Zhou wrote:
>
> This patch series enable reserving crashkernel above 4G in arm64.
>
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> when there is no enough low memory.
> 2.
Hi Chen,
On Fri, Jul 3, 2020 at 10:54 AM chenzhou wrote:
>
> Hi Bhupesh,
>
>
> On 2020/7/3 3:22, Bhupesh Sharma wrote:
> > Hi Will,
> >
> > On Thu, Jul 2, 2020 at 1:20 PM Will Deacon wrote:
> >> On Thu, Jul 02, 2020 at 03:44:20AM +0530, Bhupesh Sharm
2020 at 8:12 PM John Donnelly
> >> wrote:
> >>>
> >>>
> >>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha
> >>>> wrote:
> >>>>
> >>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly
> >>>&g
Hi Kamlakant,
Many thanks for having a look at the patchset.
On Wed, Jun 3, 2020 at 4:50 PM Kamlakant Patel wrote:
>
> Hi Bhupesh,
>
> > -Original Message-
> > From: kexec On Behalf Of Bhupesh
> > Sharma
> > Sent: Thursday, May 14, 20
Hello Scott,
On Thu, Jun 4, 2020 at 12:17 AM Scott Branden
wrote:
>
> Hi Bhupesh,
>
> Would be great to get this patch series upstreamed?
>
> On 2019-12-25 10:49 a.m., Bhupesh Sharma wrote:
> > Hi James,
> >
> > On 12/12/2019 04:02 PM, James Morse wrote:
gt; changes are present)
> When I used crash utility, following is the error:
>
> Thanks,
> -Bharat
>
>
> -Original Message-
> From: Scott Branden [mailto:scott.bran...@broadcom.com]
> Sent: Thursday, April 30, 2020 4:34 AM
> To: Bhupesh Sharma; Amit Kachhap
>
machine_shutdown();
> }
>
> + kmsg_dump(KMSG_DUMP_SHUTDOWN);
> machine_kexec(kexec_image);
>
> #ifdef CONFIG_KEXEC_JUMP
> --
> 2.25.1
LGTM, so:
Reviewed-by: Bhupesh Sharma
Thanks.
Hello Catalin, Will,
On Tue, Jun 2, 2020 at 10:54 AM Bhupesh Sharma wrote:
>
> Hello,
>
> On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote:
> >
> > Apologies for the delayed update. Its been quite some time since I
> > posted the last version (v5), but I have
Hi David,
Thanks for the patch.
On Mon, Jan 14, 2019 at 6:29 PM David Hildenbrand wrote:
>
> This will be done by free_reserved_page().
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Bhupesh Sharma
> Cc: James Morse
> Cc: Marc Zyngier
> Cc: Dave Kleikamp
>
ally marking pages as PG_reserved is not necessary, they are
> already in the desired state (otherwise they would have been handed over
> to the buddy as free pages and bad things would happen).
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: James Morse
> Cc: Bhupesh Shar
Hi Qian Cai,
On Thu, Dec 13, 2018 at 10:53 AM Qian Cai wrote:
>
> On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash
> dump just hung. It has 4 threads on each core. Each 2-core share a same
> L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same
> L3 cache.
>
On Fri, Dec 14, 2018 at 9:39 AM Qian Cai wrote:
>
> On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash
> dump just hung. It has 4 threads on each core. Each 2-core share a same
> L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same
> L3 cache.
>
> It turned
NUMBER(HUGETLB_PAGE_DTOR)=2
NUMBER(VA_BITS)=48
NUMBER(kimage_voffset)=0x5492f5c0
NUMBER(PHYS_OFFSET)=0xee138000
CRASHTIME=1532965574
So, for what it is worth:
Reviewed-by and Tested
Hi Kairui,
Thanks for the patch. Please see my comments in-line:
On 05/10/2019 03:50 PM, Kairui Song wrote:
Device dump allow drivers to add device related dump data to vmcore as
they want. This have a potential issue, the data is stored in memory,
drivers may append too much data and use too
address
supported by underlying kernel.
A reference 'makedumpfile' implementation which uses this approach to
determining the maximum physical address is available in [0].
[0].
https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-va-support-via-vmcore-upstream-v3/arch/arm64.c#L459
Cc: Mark
Herrenschmidt
Cc: Dave Anderson
Cc: Kazuhito Hagio
Cc: x...@kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: ke...@lists.infradead.org
Bhupesh Sharma (2):
arm64, vmcoreinfo : Append 'PTRS_PER_PGD' to vmcoreinfo
crash_core
fashion
is available here:
[0].
https://github.com/bhupesh-sharma/makedumpfile/blob/remove-max-phys-mem-bit-v1/arch/ppc64.c#L471
Cc: Boris Petkov
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: James Morse
Cc: Will Deacon
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Dave
> + DEVID(tee_client_device_id);
> > > + DEVID_FIELD(tee_client_device_id, uuid);
> > > +
> > > return 0;
> > > }
> > > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> > > index a37af7d..d0e4172 100644
> > > --- a/scripts/mod/file2alias.c
> > > +++ b/scripts/mod/file2alias.c
> > > @@ -37,6 +37,9 @@ typedef unsigned char __u8;
> > > typedef struct {
> > > __u8 b[16];
> > > } uuid_le;
> > > +typedef struct {
> > > + __u8 b[16];
> > > +} uuid_t;
> > >
> > > /* Big exception to the "don't include kernel headers into userspace,
> > > which
> > > * even potentially has different endianness and word sizes, since
> > > @@ -1287,6 +1290,21 @@ static int do_typec_entry(const char *filename,
> > > void *symval, char *alias)
> > > return 1;
> > > }
> > >
> > > +/* Looks like: tee:uuid */
> > > +static int do_tee_entry(const char *filename, void *symval, char *alias)
> > > +{
> > > + DEF_FIELD(symval, tee_client_device_id, uuid);
> > > +
> > > + sprintf(alias,
> > > "tee:%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
> > > + uuid.b[0], uuid.b[1], uuid.b[2], uuid.b[3], uuid.b[4],
> > > + uuid.b[5], uuid.b[6], uuid.b[7], uuid.b[8], uuid.b[9],
> > > + uuid.b[10], uuid.b[11], uuid.b[12], uuid.b[13], uuid.b[14],
> > > + uuid.b[15]);
> > > +
> > > + add_wildcard(alias);
> > > + return 1;
> > > +}
> > > +
> > > /* Does namelen bytes of name exactly match the symbol? */
> > > static bool sym_is(const char *name, unsigned namelen, const char
> > > *symbol)
> > > {
> > > @@ -1357,6 +1375,7 @@ static const struct devtable devtable[] = {
> > > {"fslmc", SIZE_fsl_mc_device_id, do_fsl_mc_entry},
> > > {"tbsvc", SIZE_tb_service_id, do_tbsvc_entry},
> > > {"typec", SIZE_typec_device_id, do_typec_entry},
> > > + {"tee", SIZE_tee_client_device_id, do_tee_entry},
> > > };
> > >
> > > /* Create MODULE_ALIAS() statements.
> > > --
> > > 2.7.4
> > >
With Daniel's inputs addressed, for this patch:
Reviewed-by: Bhupesh Sharma
Thanks
ev;
> +};
> +
> +#define to_tee_client_device(d) container_of(d, struct tee_client_device,
> dev)
> +
> +/**
> + * struct tee_client_driver - tee client driver
> + * @id_table: device id table supported by this driver
> + * @driver:driver structure
> + */
> +struct tee_client_driver {
> + const tee_client_device_id *id_table;
> + struct device_driver driver;
> +};
> +
> +#define to_tee_client_driver(d) \
> + container_of(d, struct tee_client_driver, driver)
> +
> #endif /*__TEE_DRV_H*/
> --
> 2.7.4
>
LGTM, if there are no further comments on this patch please free to add:
Reviewed-by: Bhupesh Sharma
Thanks.
Hi Hedi,
Thanks for the patchset.
I will give this a go on my sgi-uv300 machine and come back with more
detailed inputs, but I wanted to ask about the hang/panic you mentioned
in the cover letter when efi_scratch gets clobbered. Can you describe
the same (for e.g. how to reproduce this).
Hi Qian,
On Sat, Dec 15, 2018 at 7:24 AM Qian Cai wrote:
>
> On 12/14/18 2:23 AM, Ard Biesheuvel wrote:
> > On Fri, 14 Dec 2018 at 05:08, Qian Cai wrote:
> >> Also tried to move the local TLB flush part around a bit inside
> >> __cpu_setup(), although it did complete kdump some times, it did
Hi Sumit,
Thanks for the patch. Some nitpicks in-line:
On 01/11/2019 05:17 PM, Sumit Garg wrote:
Introduce a generic TEE bus driver concept for TEE based kernel drivers
which would like to communicate with TEE based devices/services.
In this TEE bus concept, devices/services are identified
xec_file_load' support to have
made way upstream for arm64 as well, but I understand that it is stuck
till we have an agreement on the DT side of things. So, refusing a
crash image loading in such a case makes sense for now.
So, please feel free to add:
Reviewed-by: Bhupesh Sharma
Thanks,
Bhupesh
1 - 100 of 146 matches
Mail list logo