linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ankijain@codeaurora.org
To: linux-fsdevel@vger.kernel.org
Cc: linux-fsdevel-owner@vger.kernel.org
Subject: Re: Page fault while link_path_walk for path_len > 4060 bytes
Date: Mon, 14 Aug 2017 16:44:00 +0530	[thread overview]
Message-ID: <3958983ccec4aca494bf72c397f34bfa@codeaurora.org> (raw)
In-Reply-To: <54083a824d6705a93d972ca5ef3a7b35@codeaurora.org>

Hi linux-fsdevel

could you please look at this issue or suggest how we can proceed 
further.

Thanks,

On 2017-08-07 17:48, ankijain@codeaurora.org wrote:
> On 2017-08-07 11:52, ankijain@codeaurora.org wrote:
>> Hi
>> 
>> We are facing a issue while creating the directories up-to maximum 
>> depth.
>> While doing this, page fault occurs some times if PATH_LEN is near to
>> page boundary.
>> During hash_name() calculation inside link_path_walk(),
>> load_unaligned_zeropad() is causing page fault as it tries to access
>> next page data(which is not mapped).
>> We have already taken a lock(rcu_read_lock) in path_init() and as a
>> part of page fault it checks if process can sleep (might_sleep), which
>> results in panic as rcu_read_lock is already taken in path_init().
>> 
>> One observation : Panic happens only when page(which contain the
>> path_name and length > 4060) is the last page of the slab memory.
>> 
>> Test Case detail:
>> Kernel version : 4.4
>> We are following stress-ng test.
>> https://github.com/ColinIanKing/stress-ng
>> 
>> 1. dirdeep for creating directory upto maximum depth.
>> 2. vm for memory allocation in backgroud.
>> 
>> Above 2 test cases are running simultaneously and it takes ~3-4 hours
>> to reproduce this issue.
>> 
>> Pasting comment section for load_unaligned_zeropad():
>> /*
>>   * Load an unaligned word from kernel space.
>>   *
>>   * In the (very unlikely) case of the word being a page-crosser
>>   * and the next page not being mapped, take the exception and
>>   * return zeroes in the non-existing part.
>>   */
>> 
>> Wanted to confirm if this "very unlikely case" mentioned above is
>> pointing to the same issue ?
>> Also let us know if this is a known issue and if some fix is already
>> available. If not, please suggest how we can proceed further.
>> 
>> Appreciate your help. Thanks in advance!!
>> 
>> Regards,
>> Ankit Jain
>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation 
>> Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project

      reply	other threads:[~2017-08-14 11:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  6:22 Page fault while link_path_walk for path_len > 4060 bytes ankijain
2017-08-07 12:18 ` ankijain
2017-08-14 11:14   ` ankijain [this message]

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=3958983ccec4aca494bf72c397f34bfa@codeaurora.org \
    --to=ankijain@codeaurora.org \
    --cc=linux-fsdevel-owner@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).