To enable pmsg, just set pmsg_size when block device register blkzone.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 21
fs/pstore/blkoops.c| 10 ++
fs/pstore/blkzone.c| 253 +
include/linux/pstore_blk.h | 1 +
4
blkoops is a sample for pstore/blk. It can only record oops, excluding
panics as no read/write apis for panic registered. It support settings
on Kconfg/module parameters. It can record oops log even power failure
if "PSTORE_BLKOOPS_BLKDEV" on Kconfig or "blkdev" on module parameter
is valid. Otherw
The document, at Documentation/admin-guide/pstore-block.rst,
tells user how to use pstore_blk and the attentions about panic
read/write
Signed-off-by: liaoweixiong
---
Documentation/admin-guide/pstore-block.rst | 233 +
MAINTAINERS| 1
Why should we need pstore_block?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have b
pstore_blk is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_blk?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fact, there is already a sample
There are various reasons, including bencmarking, to disable spectrev2
mitigation on a machine. Provide a command-line to do so.
Signed-off-by: Jeremy Linton
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
---
Documentation/admin-guide/kernel-parameters.txt | 8
arch/arm64/kernel/cp
On 2019-02-26 19:20, Greg Kroah-Hartman wrote:
> On Tue, Feb 26, 2019 at 02:33:41PM +0800, liaoweixiong wrote:
>> Why should we need pstore_block?
>> 1. Most embedded intelligent equipment have no persistent ram, which
>> increases costs. We perfer to cheaper solutions, like block devices.
>> In
On Tue, Feb 26, 2019 at 12:49 PM Denis Efremov wrote:
> Recent "New LSM Hooks" discussion has led me to the
> thought that it might be a good idea to slightly
> update the current documentation. The patchset adds
> nothing new to the documentation, only fixes the old
> description of hooks to refl
On Tue, Feb 26, 2019 at 06:18:25PM +0100, Andrey Konovalov wrote:
> On Fri, Feb 22, 2019 at 11:55 PM Dave Hansen wrote:
> >
> > On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > > The following testing approaches has been taken to find potential issues
> > > with user pointer untagging:
> > >
> > >
On 2/25/19 10:20 PM, Len Brown wrote:
> -/* leaf 0xb sub-leaf types */
> +/* extended topology sub-leaf types */
> #define INVALID_TYPE 0
> #define SMT_TYPE 1
> #define CORE_TYPE2
> +#define DIE_TYPE 5
Looking in the SDM, Vol. 3A "8.9.1 Hierarchical Mapping of Shared
Resources", the
As linux-5.0 is coming up soon, the howto.rst document can be
updated for the new kernel version. Instead of changing all 4.x
references to 5.x, this time we git rid of all explicit version
numbers and rework some kernel trees' name to keep the docs
current and real.
Signed-off-by: Zenghui Yu
---
On 2/26/19 9:18 AM, Andrey Konovalov wrote:
>> This seems like something
>> where we would ideally add an __tagged annotation (or something) to the
>> source tree and then have sparse rules that can look for missed untags.
> This has been suggested before, search for __untagged here [1].
> However
On 25/02/2019 18:02, Szabolcs Nagy wrote:
On 25/02/2019 16:57, Catalin Marinas wrote:
On Tue, Feb 19, 2019 at 06:38:31PM +, Szabolcs Nagy wrote:
i think these rules work for the cases i care about, a more
tricky question is when/how to check for the new syscall abi
and when/how the TCR_EL1.
On Fri, Feb 22, 2019 at 11:55 PM Dave Hansen wrote:
>
> On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > The following testing approaches has been taken to find potential issues
> > with user pointer untagging:
> >
> > 1. Static testing (with sparse [3] and separately with a custom static
> >an
Hi Jon,
On Tue, Feb 26, 2019 at 2:26 AM Jonathan Corbet wrote:
>
> On Sun, 24 Feb 2019 23:45:23 +0800
> Zenghui Yu wrote:
>
> > As linux-5.0 is coming up soon, the howto.rst document can be
> > updated for the new kernel version. Change all 4.x references
> > to 5.x now.
> >
> > Signed-off-by: Z
On Fri, Feb 22, 2019 at 5:10 PM Szabolcs Nagy wrote:
>
> On 22/02/2019 15:40, Andrey Konovalov wrote:
> > On Fri, Feb 22, 2019 at 4:35 PM Szabolcs Nagy wrote:
> >>
> >> On 22/02/2019 12:53, Andrey Konovalov wrote:
> >>> This patchset is meant to be merged together with "arm64 relaxed ABI" [1].
>
On Sat, Feb 23, 2019 at 12:07 AM Dave Hansen wrote:
>
> On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > --- a/mm/mprotect.c
> > +++ b/mm/mprotect.c
> > @@ -578,6 +578,7 @@ static int do_mprotect_pkey(unsigned long start, size_t
> > len,
> > SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t,
On Sat, Feb 23, 2019 at 12:06 AM Dave Hansen wrote:
>
> On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > userfaultfd_register() and userfaultfd_unregister() use provided user
> > pointers for vma lookups, which can only by done with untagged pointers.
>
> So, we have to patch all these sites before
On Sat, Feb 23, 2019 at 12:03 AM Dave Hansen wrote:
>
> On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -2730,7 +2730,7 @@ void *copy_mount_options(const void __user * data)
> >* the remainder of the page.
> >*/
> > /* copy
On Wed, Feb 20, 2019 at 10:08:48AM -0500, Len Brown wrote:
> Thanks for the comments, Peter. I'll update the patch to address the
> syntax points. (Maybe checkpatch.pl should be updated to reflect your
> preferences?).
Don't know about checkpatch; I ignore plenty of its output. I think tglx
start
On Tue, Feb 26, 2019 at 02:33:41PM +0800, liaoweixiong wrote:
> Why should we need pstore_block?
> 1. Most embedded intelligent equipment have no persistent ram, which
> increases costs. We perfer to cheaper solutions, like block devices.
> In fast, there is already a sample for block device logger
21 matches
Mail list logo
