From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752888AbdEPQ1t (ORCPT ); Tue, 16 May 2017 12:27:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:53154 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750799AbdEPQ1q (ORCPT ); Tue, 16 May 2017 12:27:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 203FE239C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mhiramat@kernel.org Date: Wed, 17 May 2017 01:27:38 +0900 From: Masami Hiramatsu To: Steven Rostedt Cc: LKML , Thomas Gleixner Subject: Re: WARNING at arch/x86/kernel/alternative.c:707 text_poke+0x25d/0x270 Message-Id: <20170517012738.8627bfae95df7c64f08f6d95@kernel.org> In-Reply-To: <20170516113019.0bfcd516@gandalf.local.home> References: <20170516094802.76a468bb@gandalf.local.home> <20170517001539.171b05fd39bbdd4ce36566c2@kernel.org> <20170516113019.0bfcd516@gandalf.local.home> X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 May 2017 11:30:19 -0400 Steven Rostedt wrote: > On Wed, 17 May 2017 00:15:39 +0900 > Masami Hiramatsu wrote: > > > > > It appears that the kprobe_optimizer work thread call happened after > > > the init pages were freed, causing alternative.c to give the above > > > warning because the text that is being unoptimized happens to no longer > > > exist. > > > > Ah, I see. I need to check that case. Actually for the module > > init text area, kill_kprobe() correctly kicks kill_optimized_kprobe() > > so it should safe. But above case is on the init-text in kernel > > itself. I guess module_notifier may not be called for that area... > > Hmm, what happens if you add a kprobe to a module, remove it, and then > remove the module. In that case the kprobe will be removed before unloading the module. If the kprobe is optimized, the optimized probe itself is queued to unoptimize. > If the module is still loaded when it is removed, > wouldn't that cause the optimized probe to be delayed? Yes, it is queued, but before unloading module, it should be dequeued forcibly by kill_optimized_kprobe() from module-notifier. > Wouldn't that > open a race where the optimizer work queue can be called when no module > exists? Since both kprobe_mutex and module_mutex are held in optimizer, I couldn't think there is such race. I guess when the kernel's init-text (not module's one) is freed, it doesn't kick the module notifier and kprobes missed that. Thank you, -- Masami Hiramatsu