> From: Rick Jones [mailto:rick.jon...@hpe.com] > Sent: Tuesday, June 28, 2016 23:43 > To: Dexuan Cui <de...@microsoft.com>; David Miller <da...@davemloft.net> > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; vkuzn...@redhat.com; > cav...@redhat.com; KY Srinivasan <k...@microsoft.com>; Haiyang Zhang > <haiya...@microsoft.com>; j...@perches.com > Subject: Re: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets > > On 06/28/2016 02:59 AM, Dexuan Cui wrote: > > The idea here is: IMO the syscalls sys_read()/write() shoudn't return > > -ENOMEM, so I have to make sure the buffer allocation succeeds? > > > > I tried to use kmalloc with __GFP_NOFAIL, but I hit a warning in > > in mm/page_alloc.c: > > WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); > > > > What error code do you think I should return? > > EAGAIN, ERESTARTSYS, or something else? > > > > May I have your suggestion? Thanks! > > What happens as far as errno is concerned when an application makes a > read() call against a (say TCP) socket associated with a connection > which has been reset? I suppose it is ECONNRESET (Connection reset by peer).
> Is it limited to those errno values listed in the > read() manpage, or does it end-up getting an errno value from those > listed in the recv() manpage? Or, perhaps even one not (presently) > listed in either? > > rick jones Actually "man read/write" says "Other errors may occur, depending on the object connected to fd". "man send/recv" indeed lists ENOMEM. Considering AF_HYPERV is a new socket type, ENOMEM seems OK to me and I'm going to post a new version of the patch. In the long run, I think we should add a new API in the VMBus driver, allowing data copy from VMBus ringbuffer into user mode buffer directly. This way, we can even eliminate this temporary buffer. Thanks, -- Dexuan _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
