From owner-freebsd-fs@FreeBSD.ORG Wed Dec 10 09:24:35 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DF1076F; Wed, 10 Dec 2014 09:24:35 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7A25169; Wed, 10 Dec 2014 09:24:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sBA9OSc3052136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 11:24:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sBA9OSc3052136 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sBA9OSjm052135; Wed, 10 Dec 2014 11:24:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Dec 2014 11:24:28 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: fuse dirent bug??? Message-ID: <20141210092428.GE97072@kib.kiev.ua> References: <156074187.8997064.1418182890206.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156074187.8997064.1418182890206.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Filesystems , George Neville-Neil X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 09:24:35 -0000 On Tue, Dec 09, 2014 at 10:41:30PM -0500, Rick Macklem wrote: > Hi, > > While looking at the fuse code to change it to use a new > "struct dirent", I spotted this line, which doesn't look > correct. > > Line 358 of sys/fs/fuse/fuse_internal.c: > ((char *)cookediov->base)[bytesavail] = '\0'; > - I think this is intended to null terminate the name, > since it comes right after the memcpy() of the file name. > However, bytesavail is the value returned by GENERIC_DIRSIZ(), > which means [bytesavail] after "cookediov->base" would be the > first byte after the "struct dirent" (including the space for > null termination and padding. > > If I'm correct, I think this line can be replaced by: > de->d_name[fudge->namelen] = '\0'; > which would be the byte after the name in the structure. > > Also, although I think the first argument to the memcpy() call > just above this is correct, it is complex/convoluted. > Wouldn't just writing "memcpy(de->d_name, ..." make it > more readable? > > Anyone out there familiar with fuse able to look at/test this? No, I am not familiar with fuse. Still, I think you are right. OTOH, it is probably very rare to result in the actual override of the last byte after the buffer, since dirents have to fill the buffer to the last byte. One additional note. The getdirentries(2) specifies that the name must be null-terminated. But sys/dirent.h comment claims that the whole padding must be zeroed. I did not tracked the source of the buffer in fuse_internal_readdir(), so my question is whether the buffer is zeroed before filled. If not, padding must be cleared.