An SMMU Stream table is created by the primary kernel. This table is
used by the SMMU to perform address translations for device-originated
transactions. Any crash (if happened) launches the kdump kernel which
re-creates the SMMU Stream table. New transactions will be translated
via this new table.
On 5/11/20 6:57 AM, Mike Rapoport wrote:
> On Wed, May 06, 2020 at 05:41:40PM -0700, Anthony Yznaga wrote:
>> The size of the memblock reserved array may be increased while preserved
>> pages are being reserved. When this happens, preserved pages that have
>> not yet been reserved are at risk for
On Mon, May 11, 2020 at 04:03:25PM -0400, Rafael Aquini wrote:
> On Mon, May 11, 2020 at 06:24:55PM +, Luis Chamberlain wrote:
> > On Sat, May 09, 2020 at 09:57:37AM -0400, Rafael Aquini wrote:
> > > +Trigger Kdump on add_taint()
> > > +
> > > +
> > > +The kernel par
From: Bhupesh Sharma
Date: Mon, 11 May 2020 15:41:40 +0530
...
> Since kdump kernel(s) run under severe memory constraint with the
> basic idea being to save the crashdump vmcore reliably when the primary
> kernel panics/hangs, large memory allocations done by a network driver
> can cause the cr
On Mon, May 11, 2020 at 06:24:55PM +, Luis Chamberlain wrote:
> On Sat, May 09, 2020 at 09:57:37AM -0400, Rafael Aquini wrote:
> > +Trigger Kdump on add_taint()
> > +
> > +
> > +The kernel parameter, panic_on_taint, calls panic() from within
> > add_taint(),
> > +wh
On Sat, May 09, 2020 at 09:57:37AM -0400, Rafael Aquini wrote:
> +Trigger Kdump on add_taint()
> +
> +
> +The kernel parameter, panic_on_taint, calls panic() from within add_taint(),
> +whenever the value set in this bitmask matches with the bit flag being set
> +by add_
David Hildenbrand writes:
> On 09.05.20 17:14, Eric W. Biederman wrote:
>> David Hildenbrand writes:
>>
>>> On 01.05.20 18:57, James Morse wrote:
On x86, the kexec payload contains a copy of the current memory map.
If memory is added or removed, this copy of the memory map becomes
>>>
On Mon, 11 May 2020 18:31:55 +0530, Amit Daniel Kachhap wrote:
> Recently arm64 linux kernel added support for Armv8.3-A Pointer
> Authentication feature. If this feature is enabled in the kernel and the
> hardware supports address authentication then the return addresses are
> signed and stored in
On Wed, May 06, 2020 at 05:41:40PM -0700, Anthony Yznaga wrote:
> The size of the memblock reserved array may be increased while preserved
> pages are being reserved. When this happens, preserved pages that have
> not yet been reserved are at risk for being clobbered when space for a
> larger array
Add documentation for KERNELPACMASK variable being added to the vmcoreinfo.
It indicates the PAC bits mask information of signed kernel pointers if
Armv8.3-A Pointer Authentication feature is present.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Dave Young
Cc: Baoquan He
Signed-o
Recently arm64 linux kernel added support for Armv8.3-A Pointer
Authentication feature. If this feature is enabled in the kernel and the
hardware supports address authentication then the return addresses are
signed and stored in the stack to prevent ROP kind of attack. Kdump tool
will now dump the
On 11.05.20 13:27, Baoquan He wrote:
> On 05/11/20 at 10:19am, David Hildenbrand wrote:
>> On 09.05.20 17:14, Eric W. Biederman wrote:
> + * If the memory layout changes, any loaded kexec image should be evicted
> + * as it may contain a copy of the (now stale) memory map. This also
>
On 05/11/20 at 10:19am, David Hildenbrand wrote:
> On 09.05.20 17:14, Eric W. Biederman wrote:
> >>> + * If the memory layout changes, any loaded kexec image should be evicted
> >>> + * as it may contain a copy of the (now stale) memory map. This also
> >>> means
> >>> + * we don't need to check t
Changes since v1:
- v1 can be seen here:
http://lists.infradead.org/pipermail/kexec/2020-May/024935.html
- Addressed review comments received on v1:
* Removed unnecessary paranthesis.
* Used a different macro for minimum RX/TX ring count value in kdump
kernel.
Since kdump
Since we have kdump kernel(s) running under severe memory constraint
it makes sense to disable the qed SRIOV functionality when running the
kdump kernel as kdump configurations on several distributions don't
support SRIOV targets for saving the vmcore (see [1] for example).
Currently the qed SRIOV
Normally kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs.
Currently the qed* ethernet driver ends up consuming a lot of memory in
the kdump kernel, leading to kdump kernel panic when one tries t
On 09.05.20 02:45, Andrew Morton wrote:
> On Thu, 26 Mar 2020 18:07:29 + James Morse wrote:
>
>> Memory added to the system by hotplug has a 'System RAM' resource created
>> for it. This is exposed to user-space via /proc/iomem.
>>
>> This poses problems for kexec on arm64. If kexec decides t
On 09.05.20 17:14, Eric W. Biederman wrote:
> David Hildenbrand writes:
>
>> On 01.05.20 18:57, James Morse wrote:
>>> On x86, the kexec payload contains a copy of the current memory map.
>>> If memory is added or removed, this copy of the memory map becomes
>>> stale. Getting this wrong may prev
18 matches
Mail list logo
