From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome de Vivie Subject: Re: Does struct qstr->name should be terminated ? Date: Thu, 25 Mar 2004 01:09:04 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <40622320.8000904@free.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Wilcox , Jan Hudec , linux-fsdevel@vger.kernel.org Return-path: Received: from fep02.swip.net ([130.244.199.130]:19927 "EHLO fep02-svc.swip.net") by vger.kernel.org with ESMTP id S262916AbUCYAEG (ORCPT ); Wed, 24 Mar 2004 19:04:06 -0500 To: Bryan Henderson In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: >>>I'd think that it's treated as a nomral string in quite a few places, > > so > >>>it needs to be NUL terminated. (But not searched the sources.) >> >>Why not? It isn't hard to find. >> >>fs/dcache.c:703: str[name->len] = 0; > > > That's technically an area where it's treated like a normal string, but I thougth that qstr->name was not treated as a normal string and has been design to speedup d_compare test with strncmp instead of strcmp. That's why i never bother with the null termination caracter. > not really relevant to the question (which is "what if I don't > nul-terminate the thing"? Do you have an example handy of a strcmp() or > such that would fail if the NUL terminator were not there? In yourfs->d_lookup, you can reallocate qstr and pad d_name with random caracters. After that, unexpected behavior could happen after a mv(1): the VFS could increment qstr->len. The result is one more caracter for some entries after a ls(1).