Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753399AbbGBLfM (ORCPT ); Thu, 2 Jul 2015 07:35:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56753 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753283AbbGBLfE (ORCPT ); Thu, 2 Jul 2015 07:35:04 -0400 Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP. To: Oliver Neukum , "Daniel P. Berrange" References: <1435700650-640-1-git-send-email-jwhite@codeweavers.com> <1435700650-640-2-git-send-email-jwhite@codeweavers.com> <20150701090619.GB16822@redhat.com> <1435826719.13145.10.camel@suse.com> Cc: Jeremy White , spice-devel@lists.freedesktop.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org From: Hans de Goede Message-ID: <559521E5.2090400@redhat.com> Date: Thu, 2 Jul 2015 13:35:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <1435826719.13145.10.camel@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1576 Lines: 39 Hi, On 02-07-15 10:45, Oliver Neukum wrote: > 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. So how is this dealt with for usbip ? Regards, Hans -- 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/