Linux NFS development
 help / color / mirror / Atom feed
From: Kinglong Mee <kinglongmee@gmail.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	kinglongmee@gmail.com
Subject: Re: NULL pointer dereference using pnfs with block layout
Date: Thu, 15 Oct 2015 20:44:42 +0800	[thread overview]
Message-ID: <561F9FBA.7090501@gmail.com> (raw)
In-Reply-To: <CAHQdGtSzTQLacptvPw0c73zHFn3ixynkpjavC2v-C5FBxNv8Hg@mail.gmail.com>

On 10/14/2015 18:53, Trond Myklebust wrote:
> On Wed, Oct 14, 2015 at 3:18 AM, Kinglong Mee <kinglongmee@gmail.com> wrote:
>> On 10/13/2015 21:45, Trond Myklebust wrote:
>>> On Tue, Oct 13, 2015 at 8:45 AM, Kinglong Mee <kinglongmee@gmail.com> wrote:
>>>> ping ...
>>>>
>>>> What's your opinion about this problem ?
>>>>
>>>> If read/write of block layout file with bad length (res.count != arg.count),
>>>> should nfs retry?  NFS try to call rpc_restart_call_prepare() right now,
>>>> that cause a panic with uninitialized task.
>>>
>>> The client should not be attempting to read more data than what was
>>> requested by the O_DIRECT read request. It should be strictly
>>> respecting the boundaries of the user buffer that was supplied.
>>
>> Yes, that's right.
>>
>>> Any idea why this is happening?
>>
>> As post before, bl_read_pagelist() return a longer result that causes the panic.
>>
>>>>> [ 1004.001842] bl_read_pagelist enter nr_pages 1 offset 2048 count 2048
>>>>> [ 1004.002110] bl_read_pagelist: pg_offset 2048
>>>>> [ 1004.002370] bl_read_pagelist: pg_len 2048 is_dio
>>>>> [ 1004.002617] bl_read_pagelist: pg_len 2048 after do_add_page_to_bio
>>>>> [ 1004.002853] bl_read_pagelist: 2048 4096 "(isect << SECTOR_SHIFT) < header->inode->i_size"
>>>>> [ 1004.003774] NFS: nfs_pgio_result:     0, (status 0), tk_ops      (null)
>>>>> [ 1004.003989] --> nfs4_read_done
>>>>> [ 1004.004224] nfs_readpage_done: 0
>>>>> [ 1004.004459] nfs_pgio_result: 0
>>>>> [ 1004.004691] nfs_readpage_result: eof 0, res.count 4096, args.count 2048
>>>>> [ 1004.004926] nfs_readpage_retry: tk_ops           (null)
> 
> Right, but that means one of two things: Either we need to fix
> bl_read_pagelist, or we need to fall back to read-through-MDS in this
> case.

I don't know the restrict of calling bl_read_pagelist,
Should the offset or count be aligning to PAGE_SIZE or not?

If not, there maybe some problem exist in bl_read_pagelist.

Otherwise, if bl_read_pagelist success but with res.count 
that not equal to args.count, nfs should fall back to read-through-MDS.

So, both need be fixed.

thanks,
Kinglong Mee

  reply	other threads:[~2015-10-15 12:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-21  3:22 NULL pointer dereference using pnfs with block layout Kinglong Mee
2015-10-13 12:45 ` Kinglong Mee
2015-10-13 13:45   ` Trond Myklebust
2015-10-14  7:18     ` Kinglong Mee
2015-10-14 10:53       ` Trond Myklebust
2015-10-15 12:44         ` Kinglong Mee [this message]
2015-10-16  9:22           ` [PATCH 1/2] nfs/blocklayout: Fix bad using of page offset in bl_read_pagelist Kinglong Mee
2015-10-16  9:23           ` [PATCH 2/2] NFSv4.1/pnfs: Retry through MDS when getting bad length of data Kinglong Mee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=561F9FBA.7090501@gmail.com \
    --to=kinglongmee@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox