All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	willy@infradead.org
Subject: Re: [PATCH 3/3] mm/swapfile.c: count won't be bigger than SWAP_MAP_MAX
Date: Fri, 08 May 2020 07:48:01 +0800	[thread overview]
Message-ID: <87ftcbtiha.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20200507222014.6s5szrt6zy2b6ybo@master> (Wei Yang's message of "Thu, 7 May 2020 22:20:14 +0000")

Wei Yang <richard.weiyang@gmail.com> writes:

> On Wed, May 06, 2020 at 04:22:54PM +0800, Huang, Ying wrote:
>>Wei Yang <richard.weiyang@gmail.com> writes:
>>
>>> On Fri, May 01, 2020 at 03:48:53PM -0700, Andrew Morton wrote:
>>>>On Fri,  1 May 2020 01:52:59 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:
>>>>
>>>>> When the condition is true, there are two possibilities:
>>>>
>>>>I'm struggling with this one.
>>>>
>>>>>    1. count == SWAP_MAP_BAD
>>>>>    2. count == (SWAP_MAP_MAX & COUNT_CONTINUED) == SWAP_MAP_SHMEM
>>>>
>>>>I'm not sure what 2. is trying to say.  For a start, (SWAP_MAP_MAX &
>>>>COUNT_CONTINUED) is zero.  I guess it meant "|"?
>>>
>>> Oops, you are right. It should be (SWAP_MAP_MAX | COUNT_CONTINUED).
>>>
>>> Sorry for the confusion.
>>>
>>>>
>>>>Also, the return value documentation says we return EINVAL for migration
>>>>entries.  Where's that happening, or is the comment out of date?
>>>>
>>>
>>> Not paid attention to this.
>>>
>>> Take look into the code, I don't find a relationship between the swap count
>>> and migration. Seems we just make a migration entry but not duplicate it.  
>>> If my understanding is correct.
>>
>>Per my understanding, one functionality of the error path is to catch
>>the behavior that shouldn't happen at all.  For example, if
>>__swap_duplicate() is called for the migration entry because of some
>>race condition.
>>
>
> If __swap_duplicate() run for a migration entry, it returns since
> get_swap_entry() couldn't find a swap_info_struct. So the return value is
> -EINVAL.
>
> While when this situation would happen? And the race condition you mean is?

Sorry for confusing.  I don't mean there are some known race conditions
in current kernel that will trigger the error code path.  I mean we may
use the error path to identify some race conditions in the future.

I remember that Matthew thought that the swap code should work
reasonably even for garbage PTE.

Best Regards,
Huang, Ying

>>Best Regards,
>>Huang, Ying

  reply	other threads:[~2020-05-07 23:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01  1:52 [PATCH 1/3] mm/swapfile.c: classify SWAP_MAP_XXX to make it more readable Wei Yang
2020-05-01  1:52 ` [PATCH 2/3] mm/swapfile.c: __swap_entry_free() always free 1 entry Wei Yang
2020-05-01  1:52 ` [PATCH 3/3] mm/swapfile.c: count won't be bigger than SWAP_MAP_MAX Wei Yang
2020-05-01 22:48   ` Andrew Morton
2020-05-02 13:29     ` Wei Yang
2020-05-02 13:41       ` Wei Yang
2020-05-06  8:22       ` Huang, Ying
2020-05-06  8:22         ` Huang, Ying
2020-05-07 22:20         ` Wei Yang
2020-05-07 23:48           ` Huang, Ying [this message]
2020-05-07 23:48             ` Huang, Ying
2020-05-08 21:19             ` Wei Yang

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=87ftcbtiha.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richard.weiyang@gmail.com \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.