From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751675AbcGPNbw (ORCPT ); Sat, 16 Jul 2016 09:31:52 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33591 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593AbcGPNbt (ORCPT ); Sat, 16 Jul 2016 09:31:49 -0400 MIME-Version: 1.0 In-Reply-To: <20160716112632.GA7096@grep.be> References: <1466760574-1916-1-git-send-email-mpa@pengutronix.de> <1466760574-1916-2-git-send-email-mpa@pengutronix.de> <20160716112632.GA7096@grep.be> From: Pranay Srivastava Date: Sat, 16 Jul 2016 19:01:47 +0530 Message-ID: Subject: Re: [Nbd] [PATCH 2/2] nbd: Disallow ioctls on disconnected block device To: Wouter Verhelst Cc: Alex Bligh , "nbd-general@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 16, 2016 at 4:56 PM, Wouter Verhelst wrote: > On Sat, Jul 16, 2016 at 03:38:40PM +0530, Pranay Srivastava wrote: >> Okay. So how about we include some negotiated key which goes in with every >> request which the server could maintain for clients that can be checked while >> resetting the connection with the same server? > > Wut? > >> So am I correct that this situation can >> indeed happen or the server will throw an error back to client in case >> the troubled >> nbd-client is trying to reconnect to the original server but requests >> are going to >> another server? >> >> If yes to above query then what is the best effort we can do to avoid >> such scenarios? > > Tell userspace not to do stupid things? > > This isn't a problem. The kernel assumes that whatever userspace does, > once the connection is set up again everything's the way it was before. > If that's not true, then userspace is to blame, not kernel space. > > Adding a "key" which we need to pass is going to make things wildly more > complicated for no benefit. Okay. So let things roll for timeout but stop for disconnect. > > -- > < ron> I mean, the main *practical* problem with C++, is there's like a dozen > people in the world who think they really understand all of its rules, > and pretty much all of them are just lying to themselves too. > -- #debian-devel, OFTC, 2016-02-12 -- ---P.K.S