Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752787Ab1EISLK (ORCPT ); Mon, 9 May 2011 14:11:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34148 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751705Ab1EISLJ (ORCPT ); Mon, 9 May 2011 14:11:09 -0400 Message-ID: <4DC82E3B.2090501@redhat.com> Date: Mon, 09 May 2011 14:11:07 -0400 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dave Anderson CC: linux-kernel@vger.kernel.org, Josef Bacik Subject: Re: [PATCH] fs: kill default_llseek References: <1850345881.414857.1304964238493.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> In-Reply-To: <1850345881.414857.1304964238493.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2841 Lines: 81 On 05/09/2011 02:03 PM, Dave Anderson wrote: > > On Thursday 05 May 2011 16:27:57 Josef Bacik wrote: >> Looking at this llseek stuff I noticed that default_llseek is the exact same as >> generic_file_llseek, so kill default_llseek. I patched this using spatch with >> just a simple >> >> @@ >> @@ >> >> - default_llseek >> + generic_file_llseek > > ... > >> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c >> index d245cb2..6f37c39 100644 >> --- a/fs/proc/kcore.c >> +++ b/fs/proc/kcore.c >> @@ -558,7 +558,7 @@ static int open_kcore(struct inode *inode, struct file *filp) >> static const struct file_operations proc_kcore_operations = { >> .read = read_kcore, >> .open = open_kcore, >> - .llseek = default_llseek, >> + .llseek = generic_file_llseek, >> }; > >> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c >> index 74802bc5..0cafd9e 100644 >> --- a/fs/proc/vmcore.c >> +++ b/fs/proc/vmcore.c >> @@ -163,7 +163,7 @@ static ssize_t read_vmcore(struct file *file, char __user *buffer, >> >> static const struct file_operations proc_vmcore_operations = { >> .read = read_vmcore, >> - .llseek = default_llseek, >> + .llseek = generic_file_llseek, >> }; > > Both /proc/kcore and /proc/vmcore currently require default_llseek(). > They were both changed to use generic_file_llseek(), but then subsequently > reverted back to default_llseek(): > > commit c227e69028473c7c7994a9b0a2cc0034f3f7e0fe > Author: Arnd Bergmann > Date: Wed Sep 22 13:04:54 2010 -0700 > > /proc/vmcore: fix seeking > > Commit 73296bc611 ("procfs: Use generic_file_llseek in /proc/vmcore") > broke seeking on /proc/vmcore. This changes it back to use default_llseek > in order to restore the original behaviour. > ... > > > commit ceff1a770933e2ca2bf995b453dade4ec47a9878 > Author: Dave Anderson > Date: Wed Jan 12 17:00:36 2011 -0800 > > /proc/kcore: fix seeking > > Commit 34aacb2920 ("procfs: Use generic_file_llseek in /proc/kcore") broke > seeking on /proc/kcore. This changes it back to use default_llseek in > order to restore the original behavior. > ... > How is it getting s_maxbytes set to 0? I'm looking everywhere and I can't see how that can happen. It seems that anybody using sget should be getting it set to MAX_NONLFS so they should all be ok. I'm looking at proc in particular and it doesn't do anything special, so it should be ok. (Obviously it wasn't, I'm just trying to understand how we're getting s_maxbytes == 0 so we can fix that and kill default_llseek). Thanks, Josef -- 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/