Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp648826pxb; Thu, 19 Aug 2021 08:04:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgFIZDgu3z2l77RCXrij+sBJ2SUhGT6dilfoIDlrs/WKs5i8Cjg6DrZb0pmTArSeIhMyLP X-Received: by 2002:a5d:91c2:: with SMTP id k2mr11637473ior.117.1629385443467; Thu, 19 Aug 2021 08:04:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629385443; cv=none; d=google.com; s=arc-20160816; b=NaoOFVQrdmg52kCvNiH4F6o4hjxfDTPNLsjRf8KdUnpne/JUQ/9JBWFNsYgsxn6wm3 xizuyVKTHV+aBqHMB7DQc1Q5NBzBF6tv1lxfA19z8Qv1GmOty/xhpPI4UZCp38APmiLt 3fnEnh8XS79cX2r2rtiLxblXLu5tL/ghviIR+SUdJ0mtKx8mf+jGFnt+/3Fp4HnNSkHG ltLVSFERE+s6PKoAgHYVcCW5uZAuyJdLbeRNcPIQpj/HQ2d9z7FPgTP/Md8YswXLu1Cr +cS27JHF3M0OhZRXxxBbCw5oLP6Kb8If/G4vHUlLb/sPM4VYdJaVyqEjhx0KBA2vl3BV bIwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=O2cg4YKliybaZDM12jwBQyJhexKRCZ7Wkr8pWi2DdGE=; b=XuyxRC/q2bX0zAeY+qDH2c7+6DEd0pB17OA5eq9ij3eLCSEj8Iyk75d1L94LTIeNB2 EVOHcRjWZNBQNwDbXiX2xH0wDqhZLFqknCaAolkT0gXty++Fgs3CO/9uS1RuXfJijNCV /Yc6uD7SeUCwgciT2Za8IMV7/r5L7V2aSUeuaNM9dw0ESSvefDERKc22G322SmsSLnoK C34yXNQfzg/sh4xvY+ef1rqb+m9dzxRIMldf6eHQSrW58mW9rWu4UWKWK//3bB/U8zDE TcRJ9FHldCzY8Sa/7pwCKkN3q6QZ5VgMz5DDTM6g9yYTm90nWkbYkd74+WVFlldELX50 CFFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q17si3360274iow.102.2021.08.19.08.03.46; Thu, 19 Aug 2021 08:04:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229612AbhHSPCW convert rfc822-to-8bit (ORCPT + 99 others); Thu, 19 Aug 2021 11:02:22 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:59232 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240676AbhHSPCV (ORCPT ); Thu, 19 Aug 2021 11:02:21 -0400 Received: from smtpclient.apple (p5b3d23f8.dip0.t-ipconnect.de [91.61.35.248]) by mail.holtmann.org (Postfix) with ESMTPSA id 76A76CED16; Thu, 19 Aug 2021 17:01:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: how to cleanly shutdown an application using HCI_CHANNEL_USER From: Marcel Holtmann In-Reply-To: Date: Thu, 19 Aug 2021 17:01:42 +0200 Cc: linux-bluetooth@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: References: To: "Peter A. Bigot" X-Mailer: Apple Mail (2.3654.120.0.1.13) Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Peter, > I'm using an AF_BLUETOOTH socket bound with HCI_CHANNEL_USER from a > user-mode application with cap_net_admin=ep. As expected this > requires the device be down, and brings the device up automatically. > > When I close that socket and exit the application, the device appears > to remain up forever. Which prevents me from re-starting the > application. > > I tried to issue HCIDEVDOWN before closing, but that produces EBADFD > because ioctls cannot be performed with HCI_CHANNEL_RAW. > > I can bring the interface down from within the application if, after > closing the socket, I wait a second or so, then create a new bound > HCI_CHANNEL_RAW socket and issue HCIDEVDOWN on it. > > Is there some other way to cleanly shut down an application that used > HCI_CHANNEL_USER so that the device is returned to down state on exit? > Or is this supposed to happen automatically (I see code that suggests > it should)? > > Kernel version is 5.11.0-7620-generic (System76), and I'm using go > 1.16, if that's relevant. I think you found a regression. Calling close() on the HCI User Channel should bring the device back down. This used to work correctly, can you please bisect which kernel patch broke this. Back in the days I added tools/userchan-tester, but it seems I never included enough test cases to catch this regression. Regards Marcel