Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S271279AbTHHHE6 (ORCPT ); Fri, 8 Aug 2003 03:04:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S271281AbTHHHE6 (ORCPT ); Fri, 8 Aug 2003 03:04:58 -0400 Received: from [66.212.224.118] ([66.212.224.118]:275 "EHLO hemi.commfireservices.com") by vger.kernel.org with ESMTP id S271279AbTHHHEz (ORCPT ); Fri, 8 Aug 2003 03:04:55 -0400 Date: Fri, 8 Aug 2003 02:53:08 -0400 (EDT) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: Nagendra Singh Tomar Cc: Paul.Russell@rustcorp.com.au, Linux Kernel Subject: Re: BUG in fs/proc/generic.c:proc_file_read In-Reply-To: Message-ID: References: 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: 1670 Lines: 44 On Thu, 7 Aug 2003, Nagendra Singh Tomar wrote: > In short: > The hack used to be able to read proc files larger than 4k, breaks if the > caller does lseek() after read() > > Detailed: > I am providing a proc read interface to one of my proc files by using the > given hack symantics in which every call to read_proc() writes the data > starting at the begining of the page but sets "*start" artificially to > indicate how many fields have been read. proc_file_read then correctly > adjusts *ppos to signify the artificial position inside the proc file > where the read pointer points. It is *artificial* beacuse it is not the > byte offset but some other offset which only read_proc understands. Next > time around when read_proc gets the *ppos to start reading from it knows > how to calculate the exxat byte offset from the *artificial* *ppos > provided. > This works fine with cat which simply calls read(). The "more" command > though has the following call pattern > > read(fd,buf,4096) = X > lseek(fd,X,SEEK_SET); > > -- lseek modified file->f_pos to the byte offset value, which disturbed > read_proc --- > > read(fd,buf,4096) = 0; > > > the effect is that more never gives me data more than 4096 bytes worth. > > My Question is. Is it a known problem ? Yep known issue, i need to get around to look and test the patch. http://bugzilla.kernel.org/show_bug.cgi?id=952 -- function.linuxpower.ca - 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/