From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by befuddled.reisers.ca (Postfix, from userid 65534) id DC6311EF219; Thu, 13 Jul 2017 07:31:04 -0400 (EDT) Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by befuddled.reisers.ca (Postfix) with ESMTPS id 54BCF1EF0A9 for ; Thu, 13 Jul 2017 07:30:59 -0400 (EDT) Received: by mail-wr0-f193.google.com with SMTP id 77so8972821wrb.3 for ; Thu, 13 Jul 2017 04:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=K1QbePRLF7HT2/kVIuBaWL6I1AqZJh5aHVEm/e87wYE=; b=W8GEZGXG8fzv+tmELECXPHRpXFU5zPhQ8L5W+7uJAu6UHT0nS+uV+oR00syZpN4rTx XoslINOM/3bSoMBv3ySIQRtj9a4cAf+CG33e3+0Lmz6Xz2vKTMliEcUOfWUIXCfoAR5x c3xZxXIhzQhkuHO+80OOm1I5jgehFg75QiADLhZrPdwyvRBE+W+5k+BquJWp11WTV5ce eOAAiiH2LqdVKAUQ7Tw1jpgsu2BQXSezCWWpOnKesP2g0GV++7ifm2Kq+1eHWfhLgwu1 8KG55sciLqj9R9W6MBVhUoqx+AyshOAi8mQxO+MDv/C4BjxDKzhTovui2J7rtPm2Ko07 I4nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=K1QbePRLF7HT2/kVIuBaWL6I1AqZJh5aHVEm/e87wYE=; b=oO5DsCvybFQWj8kmDnQlzwffSqBSoeYbemZHoe2yYY8hLsmUNVLi9iZCtReZjf7dig GGCBNeVDIfe/FMM5B7WCNQn3NFteSUYYQBvz7w6hlUguqR+ShM1eAyL+5A9XZhBA6ter J+dpoMPyVp4ctqYh26jByvOXYPjH7VK0wVa8iYgv1G1cQy71Q/tEoPVjwPHPxaN3Jshz pbjh4lRvcKCkJoO9jTFRVLQc6qy5Vmo41zIsWwfbh1hHct9/nt1Ycak3+iJO5aC0fI5w 7pa1qqjqc+K68cbazpLl08xp4DF0EIHBtBf0yxFaJazcrTrgGHESHwIpRSWVs6UBNtSw z6Yw== X-Gm-Message-State: AIVw111UXWf0B/YPStzzVIbxBtrl81qVHgMEyXNBUpHcLujVbSZbdDe9 ANhxwvOXuNYSuQ== X-Received: by 10.223.177.129 with SMTP id q1mr1379443wra.82.1499945397389; Thu, 13 Jul 2017 04:29:57 -0700 (PDT) Received: from sanghar ([2a00:23c4:7320:5900:224:d6ff:fe76:7136]) by smtp.gmail.com with ESMTPSA id v203sm6626609wmd.2.2017.07.13.04.29.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Jul 2017 04:29:56 -0700 (PDT) Date: Thu, 13 Jul 2017 12:29:54 +0100 From: Okash Khawaja To: Alan Cox Cc: Greg Kroah-Hartman , Jiri Slaby , Samuel Thibault , linux-kernel@vger.kernel.org, William Hubbs , Chris Brannon , Kirk Reiser , speakup@linux-speakup.org, devel@driverdev.osuosl.org Subject: Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export Message-ID: <20170713112954.GA665@sanghar> References: <20170708083803.GA23080@kroah.com> <20170709114153.157783481@gmail.com> <20170710125233.2006733e@alans-desktop> <20170710123307.GA777@sanghar> <20170712192028.70bc0d54@alans-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170712192028.70bc0d54@alans-desktop> User-Agent: Mutt/1.8.3 (2017-05-23) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-BeenThere: speakup@linux-speakup.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 11:31:04 -0000 On Wed, Jul 12, 2017 at 07:20:28PM +0100, Alan Cox wrote: > > > When opening from kernel, we don't use file pointer. The count mismatch > > is between tty->count and #fd's. So opening from kernel leads to #fd's > > being less than tty->count. I thought this difference is relevant to > > user-space opening of tty, and not to kernel opening of tty. Can you > > suggest how to address this mismatch? > > Your kernel reference is the same as having a file open reference so I > think this actually needs addressing in the maths. In other words count > the number of kernel references and also add that into the test for > check_tty_count (kernel references + #fds == count). > > I'd really like to keep this right because that check has a long history > of catching really nasty race conditions in the tty code. The > open/close/hangup code is really fragile so worth the debugability. I see. Okay based this, check_tty_count can be easily updated to take into account kernel references. > > > Ah may be I didn't notice the active bit. Is it one of the #defines in > > tty.h? Can usage count and active bit be used to differentiate between > > whether the tty was opened by kernel or user? > > It only tells you whether the port is currently active for some purpose, > not which. If you still want to implement exclusivity between kernel and > user then it needs another flag, but I think that flag should be in > port->flags as it is a property of the physical interface. > > (Take a look at tty_port_open for example) Okay I can add TTY_PORT_KOPENED to port->flags and that should work too. However, can you please help me understand this: Our use case requires kernel access to tty_struct and accordingly tty_kopen returns tty_struct. The exclusivity between user and kernel space is also meant to prevent one side from opening tty_struct while another has it opened. In all this, it is tty_struct and not tty_port which is the key resource we are concerned with. So shouldn't the exclusivity flag belong to tty_struct? Adding a the flag to port->flags but controlling it from code for opening and closing tty will also mean we have tty_port_kopened, tty_port_set_kopen etc inside tty open/close code. Am I viewing this problem incorrectly? Thanks, Okash