Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936848AbXHHQnR (ORCPT ); Wed, 8 Aug 2007 12:43:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763874AbXHHQnA (ORCPT ); Wed, 8 Aug 2007 12:43:00 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:50971 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764234AbXHHQm7 (ORCPT ); Wed, 8 Aug 2007 12:42:59 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Tejun Heo Cc: Cornelia Huck , Greg KH , linux-kernel@vger.kernel.org, satyam@infradead.org, stern@rowland.harvard.edu, Linux Containers , gregkh@suse.de Subject: Re: [PATCH 0/25] Sysfs cleanups & tagged directory support References: <11860582832964-git-send-email-htejun@gmail.com> <20070808093815.0935a18e@gondolin.boeblingen.de.ibm.com> <20070808095432.4a520735@gondolin.boeblingen.de.ibm.com> <20070808103759.0850383c@gondolin.boeblingen.de.ibm.com> <20070808161631.1ccf27fd@gondolin.boeblingen.de.ibm.com> <46B9D4B8.4050201@gmail.com> <20070808165027.29af40b5@gondolin.boeblingen.de.ibm.com> <46B9D961.4000902@gmail.com> <46B9DDA1.1080704@gmail.com> <46B9DE5E.7050406@suse.de> <46B9E948.8080605@suse.de> Date: Wed, 08 Aug 2007 10:37:10 -0600 In-Reply-To: <46B9E948.8080605@suse.de> (Tejun Heo's message of "Thu, 09 Aug 2007 01:03:20 +0900") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1123 Lines: 28 Tejun Heo writes: > Hello, > > Eric W. Biederman wrote: >>> More specifically, d_off field. It's a bit twisted. For the last >>> entry, filp->f_pos gets written into the field and gets wrapped while >>> being copied out to userland or in glibc. >> >> That could do it, and glibc is crunching it. Oh well, it is >> easy enough to avoid as long as our inode numbers are small which >> the idr allocator seems to ensure. > > Yeah, now I think about it. glibc throws out entries which don't fit in > the data structure specified by the called API, so it probably threw out > the last entry which has UINT_MAX in d_off which doesn't fit in the > readdir() return structure. Using INT_MAX should be just fine as IDA > always allocates the first empty slot. We can add paranoia check in ino > allocation path. Sounds reasonable. Annoying but reasonable. Eric - 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/