Dear Sir
Please quote me the item as below.Also the expected date of delivery and payment terms:
Thank you.
Best regards,
Sherry
Marine Division – Service Dept___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to
On Fri, May 7, 2021 at 5:17 AM Dan Williams wrote:
>
> On Thu, May 6, 2021 at 10:28 AM Kaneda, Erik wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Yi Zhang
> > > Sent: Wednesday, May 5, 2021 8:05 PM
> > > To: Williams, Dan J ; Moore, Robert
> > >
> > > Cc: linux-nvdimm ; Kaneda
Στις 2021-05-06 20:05, James Bottomley έγραψε:
On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote:
Also, there is a way to still read that memory when root by
1. Having kdump active (which would often be the case, but maybe not
to dump user pages )
2. Triggering a kernel crash (easy vi
Amazon.co.jp にご登録のアカウント（名前、パスワード、その他個人情報）の確認...
Аmazon お客様
残念ながら、あなたのアカウント
Аmazon を更新できませんでした。
これは、カードが期限切れになったか。請求先住所が変更されたなど、さまざまな理由で発生する可能性があります。
アカウント情報の一部が誤っている故に、お客様のアカウントを維持するため
Аmazon 情報を確認する必要・ェあります。今アカウントを確認できます。
Аmazon ログイン なお、24時間以内にご確認がない場合、誠に遺憾ながら、アカウントをロックさせていただくことを警告いた
On Thu, May 6, 2021 at 10:28 AM Kaneda, Erik wrote:
>
>
>
> > -Original Message-
> > From: Yi Zhang
> > Sent: Wednesday, May 5, 2021 8:05 PM
> > To: Williams, Dan J ; Moore, Robert
> >
> > Cc: linux-nvdimm ; Kaneda, Erik
> > ; Wysocki, Rafael J
> > Subject: Re: [bug report] system panic
On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote:
> On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
[...]
> >1. Memory safety for user space code. Once the secret memory is
> > allocated, the user can't accidentally pass it into the
> > kernel to be
> > transmitt
On 5/6/21 11:27 AM, Joao Martins wrote:
> On 5/5/21 11:43 PM, Dan Williams wrote:
>> I suspect it's a good sign I'm only finding cosmetic and changelog
>> changes in the review...
>
> Hopefully it continues that way, but the meat of the series is located
> in patches 4, 6, 7 and 11. *Specially* 6
On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
> On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
> > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport
> > wrote:
> >
> > > This is an implementation of "secret" mappings backed by a file
> > > descriptor.
tl;dr: I like thi
> -Original Message-
> From: Yi Zhang
> Sent: Wednesday, May 5, 2021 8:05 PM
> To: Williams, Dan J ; Moore, Robert
>
> Cc: linux-nvdimm ; Kaneda, Erik
> ; Wysocki, Rafael J
> Subject: Re: [bug report] system panic at nfit_get_smbios_id+0x6e/0xf0
> [nfit] during boot
>
> On Sat, May 1
Is this intended to protect keys/etc after the attacker has
gained the ability to run arbitrary kernel-mode code? If so,
that seems optimistic, doesn't it?
Not exactly: there are many types of kernel attack, but mostly the
attacker either manages to effect a privilege escalation to root or
gets
On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote:
> On 06.05.21 17:26, James Bottomley wrote:
> > On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
> > > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport > > >
> > > wrote:
> > >
> > > > This is an implementation of "secret" mapping
On 06.05.21 17:26, James Bottomley wrote:
On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport
wrote:
This is an implementation of "secret" mappings backed by a file
descriptor.
The file descriptor backing secret memory mappings is created
On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote:
> On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport
> wrote:
>
> > This is an implementation of "secret" mappings backed by a file
> > descriptor.
> >
> > The file descriptor backing secret memory mappings is created using
> > a dedicated me
Hello linux-nvdimm@lists.01.org
We noticed that you need to re-verify your email account.
Just click the button below (just a few seconds).
For security reasons, we are verifying that the ownership of this email address is valid.
Confirm your email address: linux-nvdimm@lists.01.org
Fail
On 5/6/21 12:43 PM, Matthew Wilcox wrote:
> On Thu, May 06, 2021 at 11:23:25AM +0100, Joao Martins wrote:
I think it is ok for dax/nvdimm to continue to maintain their align
value because it should be ok to have 4MB align if the device really
wanted. However, when it goes to map that
On Thu, May 06, 2021 at 11:23:25AM +0100, Joao Martins wrote:
> >> I think it is ok for dax/nvdimm to continue to maintain their align
> >> value because it should be ok to have 4MB align if the device really
> >> wanted. However, when it goes to map that alignment with
> >> memremap_pages() it can
On 5/6/21 2:18 AM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> A compound pagemap is a dev_pagemap with @align > PAGE_SIZE and it
>> means that pages are mapped at a given huge page alignment and utilize
>> uses compound pages as opposed to order-0 pages.
>>
On 5/5/21 11:43 PM, Dan Williams wrote:
> I suspect it's a good sign I'm only finding cosmetic and changelog
> changes in the review...
Hopefully it continues that way, but the meat of the series is located
in patches 4, 6, 7 and 11. *Specially* 6 and 7.
I very strongly suspect I am gonna get
On 5/6/21 12:14 AM, Dan Williams wrote:
> On Wed, May 5, 2021 at 3:38 PM Joao Martins wrote:
>>
>>
>>
>> On 5/5/21 11:34 PM, Dan Williams wrote:
>>> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
>>> wrote:
@altmap is stored in a dev_pagemap, but it will be repurposed for
hotplug
On 5/6/21 9:05 AM, Aneesh Kumar K.V wrote:
>
>
> IIUC this series is about devdax namespace with aligh of 1G or 2M where we can
> save the vmmemap space by not allocating memory for tail struct pages?
>
Right.
It reuses base pages across the vmemmap, but for the base pages containing
only t
On 5/6/21 12:03 AM, Dan Williams wrote:
> On Wed, May 5, 2021 at 3:36 PM Joao Martins wrote:
> [..]
>>> Ah yup, my eyes glazed over that. I think this is another place that
>>> benefits from a more specific name than "align". "pfns_per_compound"
>>> "compound_pfns"?
>>>
>> We are still describing
IIUC this series is about devdax namespace with aligh of 1G or 2M where we can
save the vmmemap space by not allocating memory for tail struct pages?
Dan Williams writes:
> > enum:
>> >
>> > enum devmap_geometry {
>> > DEVMAP_PTE,
>> > DEVMAP_PMD,
>> > DEVMAP_PUD,
>> > }
>> >
>>
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
23 matches
Mail list logo
