> -Original Message-
> From: Jane Chu
> Subject: Re: [PATCH RESEND v6 8/9] md: Implement dax_holder_operations
>
> On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
> > This is the case where the holder represents a mapped device, or a
> > list of mapped devices more exactly(because it is
> -Original Message-
> From: Jane Chu
> Subject: Re: [PATCH RESEND v6 2/9] dax: Introduce holder for dax_device
>
>
> On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
> > --- a/drivers/dax/super.c
> > +++ b/drivers/dax/super.c
> > @@ -214,6 +214,8 @@ enum dax_device_flags {
> >* @cdev:
> -Original Message-
> From: Jane Chu
> Subject: Re: [PATCH RESEND v6 1/9] pagemap: Introduce ->memory_failure()
>
> Hi, ShiYang,
>
> So I applied the v6 patch series to my 5.14-rc3 as it's what you indicated is
> what
> v6 was based at, and injected a hardware poison.
>
> I'm seeing
On 8/4/21 3:56 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series adds a bvec_virt helper to return the virtual address of the
> data in bvec to replace the open coded calculation, and as a reminder
> that generall bio/bvec data can be in high memory unless it is caller
> controller or in an
On Mon, Aug 16, 2021 at 09:21:58AM +0200, Christoph Hellwig wrote:
> On Sun, Aug 15, 2021 at 07:27:37AM -0700, Guenter Roeck wrote:
> > [ 14.467748][T1] Possible unsafe locking scenario:
> > [ 14.467748][T1]
> > [ 14.467928][T1]CPU0CPU1
> > [
ping.
On Wed, Aug 04, 2021 at 11:56:19AM +0200, Christoph Hellwig wrote:
> Hi Jens,
>
> this series adds a bvec_virt helper to return the virtual address of the
> data in bvec to replace the open coded calculation, and as a reminder
> that generall bio/bvec data can be in high memory unless it
On Sun, Aug 15, 2021 at 07:27:37AM -0700, Guenter Roeck wrote:
> [ 14.467748][T1] Possible unsafe locking scenario:
> [ 14.467748][T1]
> [ 14.467928][T1]CPU0CPU1
> [ 14.468058][T1]
> [ 14.468187][T1]
