From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from erelay6.ox.registrar-servers.com ([192.64.117.97]:50843 "EHLO
	erelay6.ox.registrar-servers.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751285AbcB2Pli (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 29 Feb 2016 10:41:38 -0500
Date: Mon, 29 Feb 2016 07:41:31 -0800
From: Amber Thrall <amber@thrall.me>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/1] fs: strncmp() for user space buffers
Message-ID: <20160229154131.GA1050@ARCH>
References: <1456699822-2924-1-git-send-email-amber@thrall.me>
 <20160228230303.GQ17997@ZenIV.linux.org.uk>
 <20160228233908.GA1982@ARCH>
 <20160229021047.GU17997@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160229021047.GU17997@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 02/29, Al Viro wrote:
> On Sun, Feb 28, 2016 at 03:39:08PM -0800, Amber Thrall wrote:
> > Apologies for the confusing name, struggled to find an appropriate name
> > while staying consistent with the naming schemes of
> > simple_read/write_to_buffer() functions, as it based off of them. I'd
> > love to hear alternative names.
> > 
> > I saw possible uses for this proposed function being an easy way to
> > interact with debugfs, via their write file operation. For
> > example in the function xenvif_write_io_ring() the string "kick" is
> > checked for against a user space buffer.
> 
> TBH, that caller leaves an impression of rather... poor API - "any write
> of no more than 32 bytes that starts with 'k' 'i' 'c' 'k' is OK (and
> everything beyond first 4 characters is ignored), anything else is
> rejected, in some cases with whining into syslog, in some - quietly".
> I don't know if encouraging stuff like that is a good idea...
> 
> In any case, you've ended up open-coding kmemdup_user() + strncmp() + kfree();
> the problem with combining those into a single helper is that calling
> conventions will be very error-prone - you have zero/positive/negative for
> passing strncmp() result *and* you need to report errors somehow.

The conflicts between strncmp() and error values hadn't crossed my mind.
The function could return the value from strncmp() via pointer, but it
wouldn't match up with strncmp's formatting making the function
confusing to use.

Thanks for the input, I'm still new to working with the kernel and have
a lot to learn.