From: Meelis Roos <mroos@linux.ee>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>,
linux-kernel@vger.kernel.org, peterz@infradead.org,
sparclinux@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org
Cc: dave.hansen@intel.com, namit@vmware.com,
Meelis Roos <mroos@linux.ee>,
"David S. Miller" <davem@davemloft.net>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v2] vmalloc: Fix issues with flush flag
Date: Tue, 21 May 2019 00:36:22 +0300 [thread overview]
Message-ID: <90f8a4e1-aa71-0c10-1a91-495ba0cb329b@linux.ee> (raw)
In-Reply-To: <20190520200703.15997-1-rick.p.edgecombe@intel.com>
> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
>
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
> sparc machine. On investigation some issues were noticed:
>
> 1. The calculation of the direct map address range to flush was wrong.
> This could cause problems on x86 if a RO direct map alias ever got loaded
> into the TLB. This shouldn't normally happen, but it could cause the
> permissions to remain RO on the direct map alias, and then the page
> would return from the page allocator to some other component as RO and
> cause a crash.
>
> 2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
> do on a free operation. Simply flushing the TLB instead of the whole
> vm_unmap_alias() operation makes the frees faster and pushes the heavy
> work to happen on allocation where it would be more expected.
> In addition to the extra work, vm_unmap_alias() takes some locks including
> a long hold of vmap_purge_lock, which will make all other
> VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
>
> 3. page_address() can have locking on some configurations, so skip calling
> this when possible to further speed this up.
>
> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
> Reported-by: Meelis Roos<mroos@linux.ee>
> Cc: Meelis Roos<mroos@linux.ee>
> Cc: Peter Zijlstra<peterz@infradead.org>
> Cc: "David S. Miller"<davem@davemloft.net>
> Cc: Dave Hansen<dave.hansen@intel.com>
> Cc: Borislav Petkov<bp@alien8.de>
> Cc: Andy Lutomirski<luto@kernel.org>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: Nadav Amit<namit@vmware.com>
> Signed-off-by: Rick Edgecombe<rick.p.edgecombe@intel.com>
> ---
>
> Changes since v1:
> - Update commit message with more detail
> - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case
It does not work on my V445 where the initial problem happened.
[ 46.582633] systemd[1]: Detected architecture sparc64.
Welcome to Debian GNU/Linux 10 (buster)!
[ 46.759048] systemd[1]: Set hostname to <v445>.
[ 46.831383] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[ 67.989695] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 68.074706] rcu: 0-...!: (0 ticks this GP) idle=5c6/1/0x4000000000000000 softirq=33/33 fqs=0
[ 68.198443] rcu: 2-...!: (0 ticks this GP) idle=e7e/1/0x4000000000000000 softirq=67/67 fqs=0
[ 68.322198] (detected by 1, t=5252 jiffies, g=-939, q=108)
[ 68.402204] CPU[ 0]: TSTATE[0000000080001603] TPC[000000000043f298] TNPC[000000000043f29c] TASK[systemd-debug-g:89]
[ 68.556001] TPC[smp_synchronize_tick_client+0x18/0x1a0] O7[0xfff000010000691c] I7[xcall_sync_tick+0x1c/0x2c] RPC[alloc_set_pte+0xf4/0x300]
[ 68.750973] CPU[ 2]: TSTATE[0000000080001600] TPC[000000000043f298] TNPC[000000000043f29c] TASK[systemd-cryptse:88]
[ 68.904741] TPC[smp_synchronize_tick_client+0x18/0x1a0] O7[filemap_map_pages+0x3cc/0x3e0] I7[xcall_sync_tick+0x1c/0x2c] RPC[handle_mm_fault+0xa0/0x180]
[ 69.115991] rcu: rcu_sched kthread starved for 5252 jiffies! g-939 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3
[ 69.262239] rcu: RCU grace-period kthread stack dump:
[ 69.334741] rcu_sched I 0 10 2 0x06000000
[ 69.413495] Call Trace:
[ 69.448501] [000000000093325c] schedule+0x1c/0xc0
[ 69.517253] [0000000000936c74] schedule_timeout+0x154/0x260
[ 69.598514] [00000000004b65a4] rcu_gp_kthread+0x4e4/0xac0
[ 69.677261] [000000000047ecfc] kthread+0xfc/0x120
[ 69.746018] [00000000004060a4] ret_from_fork+0x1c/0x2c
[ 69.821014] [0000000000000000] 0x0
and hangs here, software watchdog kicks in soon.
--
Meelis Roos
next prev parent reply other threads:[~2019-05-20 21:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 20:07 [PATCH v2] vmalloc: Fix issues with flush flag Rick Edgecombe
2019-05-20 21:25 ` Andy Lutomirski
2019-05-20 21:48 ` Edgecombe, Rick P
2019-05-20 21:36 ` Meelis Roos [this message]
2019-05-20 22:17 ` Edgecombe, Rick P
2019-05-20 22:48 ` David Miller
2019-05-21 0:20 ` Edgecombe, Rick P
2019-05-21 0:33 ` David Miller
2019-05-21 1:20 ` Edgecombe, Rick P
2019-05-21 1:43 ` David Miller
2019-05-21 1:59 ` Edgecombe, Rick P
2019-05-22 17:40 ` David Miller
2019-05-22 19:26 ` Edgecombe, Rick P
2019-05-22 22:40 ` Edgecombe, Rick P
2019-05-24 15:50 ` Edgecombe, Rick P
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=90f8a4e1-aa71-0c10-1a91-495ba0cb329b@linux.ee \
--to=mroos@linux.ee \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sparclinux@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).