Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752179AbbGBIq3 (ORCPT ); Thu, 2 Jul 2015 04:46:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37326 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752737AbbGBIqU (ORCPT ); Thu, 2 Jul 2015 04:46:20 -0400 Message-ID: <1435826719.13145.10.camel@suse.com> Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP. From: Oliver Neukum To: "Daniel P. Berrange" Cc: Jeremy White , hdegoede@redhat.com, spice-devel@lists.freedesktop.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 02 Jul 2015 10:45:19 +0200 In-Reply-To: <20150701090619.GB16822@redhat.com> References: <1435700650-640-1-git-send-email-jwhite@codeweavers.com> <1435700650-640-2-git-send-email-jwhite@codeweavers.com> <20150701090619.GB16822@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1457 Lines: 35 On Wed, 2015-07-01 at 10:06 +0100, Daniel P. Berrange wrote: > I don't really think it is sensible to be defining & implementing new > network services which can't support strong encryption and authentication. > Rather than passing the file descriptor to the kernel and having it do > the I/O directly, I think it would be better to dissassociate the kernel > from the network transport, and thus leave all sockets layer data I/O > to userspace daemons so they can layer in TLS or SASL or whatever else > is appropriate for the security need. Hi, this hits a fundamental limit. Block IO must be done entirely in kernel space or the system will deadlock. The USB stack is part of the block layer and the SCSI error handling. Thus if you involve user space you cannot honor memory allocation with GFP_NOFS and you break all APIs where we pass GFP_NOIO in the USB stack. Supposed you need to reset a storage device for error handling. Your user space programm does a syscall, which allocates memory and needs to launder pages. It proceeds to write to the storage device you wish to reset. It is the same problem FUSE has with writable mmap. You cannot do block devices in user space sanely. Sorry Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/