From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 9SLRMLisGmD0WAAAWB0awg (envelope-from ) for ; Wed, 03 Feb 2021 09:01:28 -0500 Received: by simark.ca (Postfix, from userid 112) id AB4321EFCD; Wed, 3 Feb 2021 09:01:28 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 246121E939 for ; Wed, 3 Feb 2021 09:01:27 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 45B8A398E425; Wed, 3 Feb 2021 14:01:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45B8A398E425 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612360886; bh=L13y/fuqOsOhEUkZ/jf7FL19Yvx9nM1c+Ws08y71kZw=; h=Subject:In-Reply-To:Date:References:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=CKijR8UQ76V0QNamG2Xl90fy55Usl6zKqRnDAeKFbbXt46uf8fN34FzINrMJEKL1r oiw2HgoS5gevHrsbiYFzBKFfrisAp46ovXqSZyiZF6jXEdnFpeteO66ahpjCoeiM8q sDUBwBrf1u/CDt4g63jpnp6dWsRIZAAIlZbSrUfU= Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) by sourceware.org (Postfix) with ESMTPS id 27AB6398E425 for ; Wed, 3 Feb 2021 14:01:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 27AB6398E425 Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id 7GR5lP6Rtf72J7IihlnKyi; Wed, 03 Feb 2021 14:01:23 +0000 Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-ch2-15v.sys.comcast.net with ESMTPSA id 7Iiflmgxj1LZY7Iigl81xE; Wed, 03 Feb 2021 14:01:23 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduledrgedvgdehkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedvtdevjeeuhefhiedvteffjeeuffehkefgudeutdevffefkeeijeelfeevuefhgeenucfkphepjeefrdeitddrvddvfedruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehpkhhonhhinhhgrdgrkhguvghsihhgnhdrtghomhdpihhnvghtpeejfedriedtrddvvdefrddutddupdhmrghilhhfrhhomhepphgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheplhgvohhnrdhhvgesmhhsnhdrtghomhdprhgtphhtthhopehguggssehsohhurhgtvgifrghrvgdrohhrgh X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl. In-Reply-To: Date: Wed, 3 Feb 2021 09:01:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: He Leon X-Mailer: Apple Mail (2.3445.104.17) X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul Koning via Gdb Reply-To: Paul Koning Cc: "gdb@sourceware.org" Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" > On Feb 2, 2021, at 11:13 PM, He Leon wrote: >=20 > Paul, >=20 > Thanks for your reply. >=20 > 1) APP cannot capture interrupt: for current *PROCESS* or for current = *THREAD*? >=20 > For multi-thread secario, if current thread stays inside ioctl and = other threads are not. Can "contrl+c" work for gdb and switch to other = thread? > I have checked this, seems not work.=20 Process, I believe. Signals are delivered to a process. >=20 > 2) Actually my ioctl is very simple, only inifinit loop of "printk()" = or "msleep()", how it impacts "interruptible" attribution? >=20 > seem if not quit from ioctl, "control+c" doesn't work. > I have even added "set_current_state(TASK_INTERRUPTIBLE)" in = ioctl, still doesn't work. I don't know Linux drivers (is this Linux?). In the operating systems I = know, a thread isn't interruptible in kernel mode. That makes sense, in = kernel mode there can be kernel state being modified, and to allow the = thread to be interrupted in the middle of that would make the OS state = invalid. So typically syscalls or drivers have to allow explicitly for = interrupts at specific points in their execution. If they do, an = interrupt can take effect but only at those points; if they don't do = this then the operation isn't interruptible at all and Control/C doesn't = take effect until the thread returns to user mode. Again, that's a general statement; I don't know the Linux specifics. =20 paul