> Some user who install SIGBUS handler that does longjmp out
> therefore keeping the process alive is confused by the error
> message
> "[188988.765862] Memory failure: 0x1840200: Killing
>cellsrv:33395 due to hardware memory corruption"
> Slightly modify the error message to improve
On Mon, May 20, 2019 at 07:52:03PM -0600, Jane Chu wrote:
> Some user who install SIGBUS handler that does longjmp out
> therefore keeping the process alive is confused by the error
> message
> "[188988.765862] Memory failure: 0x1840200: Killing
>cellsrv:33395 due to hardware memory
tree: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
libnvdimm-fixes
head: ac09ef3d6de21992ad8e372dc97017cc3c46e15e
commit: 17a1362dd849b1c01dedcda38a6c0f5e26582407 [2/3] dax: Arrange for
dax_supported check to span multiple devices
config: i386-randconfig-x006-201920
On 5/16/2019 9:48 PM, Anshuman Khandual wrote:
On 05/17/2019 09:38 AM, Jane Chu wrote:
Some user who install SIGBUS handler that does longjmp out
What the longjmp about ? Are you referring to the mechanism of catching the
signal which was registered ?
Yes.
thanks,
-jane
Some user who install SIGBUS handler that does longjmp out
therefore keeping the process alive is confused by the error
message
"[188988.765862] Memory failure: 0x1840200: Killing
cellsrv:33395 due to hardware memory corruption"
Slightly modify the error message to improve clarity.
原邮件信息 -
发件人:邀请函
收件人:linux-nvdimm
发送时间:2019-5-21 9:50:27
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Thanks Vishal and Naoya!
-jane
On 5/20/2019 3:21 AM, Naoya Horiguchi wrote:
On Fri, May 17, 2019 at 10:18:02AM +0530, Anshuman Khandual wrote:
On 05/17/2019 09:38 AM, Jane Chu wrote:
Some user who install SIGBUS handler that does longjmp out
What the longjmp about ? Are you referring to
发件人: "任主任";;
发送时间: 2019-5-21/ 9:31:08
收件人: "linux-nvdimm";
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Fri, 2019-05-17 at 13:41 -0400, Pavel Tatashin wrote:
> > Hi Pavel,
> >
> > I've still not been able to hit this in my testing, is it something
> > you
> > hit only after applying these patches? i.e. does plain v65 work?
>
> Yes, plain v65 works, but with these patches I see this error.
>
On May 20 2019, Miklos Szeredi wrote:
> On Mon, May 20, 2019 at 04:41:37PM +0200, Miklos Szeredi wrote:
>> On Wed, May 15, 2019 at 03:26:47PM -0400, Vivek Goyal wrote:
>> > If fuse daemon is started with cache=never, fuse falls back to direct IO.
>> > In that write path we don't call
Jeff discovered that performance improves from ~375K iops to ~519K iops
on a simple psync-write fio workload when moving the location of 'struct
page' from the default PMEM location to DRAM. This result is surprising
because the expectation is that 'struct page' for dax is only needed for
third
On Thu, May 16, 2019 at 10:37 PM Vaibhav Jain wrote:
>
> Dan Williams writes:
>
> > On Wed, May 15, 2019 at 10:55 PM Vaibhav Jain wrote:
> >>
> >> Presently __bdev_dax_supported() checks if first sector of last
> >> page ( last_page ) on the block device is aligned to page
> >> boundary.
On Mon, May 20, 2019 at 04:41:37PM +0200, Miklos Szeredi wrote:
> On Wed, May 15, 2019 at 03:26:47PM -0400, Vivek Goyal wrote:
> > If fuse daemon is started with cache=never, fuse falls back to direct IO.
> > In that write path we don't call file_remove_privs() and that means setuid
> > bit is not
On Wed, May 15, 2019 at 03:26:47PM -0400, Vivek Goyal wrote:
> If fuse daemon is started with cache=never, fuse falls back to direct IO.
> In that write path we don't call file_remove_privs() and that means setuid
> bit is not cleared if unpriviliged user writes to a file with setuid bit set.
>
>
On Sun, May 19, 2019 at 03:48:05PM +0800, Eric Ren wrote:
> Hi,
>
> @@ -1784,8 +1822,23 @@ static int fuse_iomap_begin(struct inode *inode,
> > loff_t pos, loff_t length,
> > if (pos >= i_size_read(inode))
> > goto iomap_hole;
> >
> > -
On Fri, May 17, 2019 at 10:18:02AM +0530, Anshuman Khandual wrote:
>
>
> On 05/17/2019 09:38 AM, Jane Chu wrote:
> > Some user who install SIGBUS handler that does longjmp out
>
> What the longjmp about ? Are you referring to the mechanism of catching the
> signal which was registered ?
AFAIK,
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled
On 17.05.19 16:09, Pavel Tatashin wrote:
>>
>> I would think that ACPI hotplug would have a similar problem, but it does
>> this:
>>
>> acpi_unbind_memory_blocks(info);
>> __remove_memory(nid, info->start_addr, info->length);
>
> ACPI does have exactly the same
On Sat 18-05-19 21:46:03, Dan Williams wrote:
> On Fri, May 17, 2019 at 12:25 PM Kees Cook wrote:
> > On Fri, May 17, 2019 at 10:28:48AM -0700, Dan Williams wrote:
> > > It seems dax_iomap_actor() is not a path where we'd be worried about
> > > needing hardened user copy checks.
> >
> > I would
On Fri 17-05-19 13:33:25, Pavel Tatashin wrote:
> On Fri, May 17, 2019 at 1:24 PM Pavel Tatashin
> wrote:
> >
> > On Fri, May 17, 2019 at 1:22 PM Pavel Tatashin
> > wrote:
> > >
> > > On Fri, May 17, 2019 at 10:38 AM Michal Hocko wrote:
> > > >
> > > > On Fri 17-05-19 10:20:38, Pavel Tatashin
20 matches
Mail list logo
