From: Eric Sandeen <sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: Bernd Schubert <bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fan Yong <yong.fan-KloliPT79xf2eFz/2MeuCQ@public.gmane.org>, bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Andreas Dilger <adilger-KloliPT79xf2eFz/2MeuCQ@public.gmane.org> Subject: Re: [PATCH 5 2/4] Return 32/64-bit dir name hash according to usage type Date: Mon, 23 Apr 2012 17:23:22 -0500 [thread overview] Message-ID: <4F95D65A.8070608@redhat.com> (raw) In-Reply-To: <4F95C109.1030401-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> On 4/23/12 3:52 PM, Bernd Schubert wrote: > On 04/23/2012 10:37 PM, Eric Sandeen wrote: ... > diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c > index b867862..3a4988e2 100644 > --- a/fs/ext4/dir.c > +++ b/fs/ext4/dir.c > @@ -363,7 +363,7 @@ loff_t ext4_dir_llseek(struct file *file, loff_t > offset, int origin) > goto out_err; > > if (!dx_dir) { > - if (offset > inode->i_sb->s_maxbytes) > + if (offset > i_size_read(inode)) > goto out_err; > } else if (offset > ext4_get_htree_eof(file)) > goto out_err; I'm curious about the above as well as: case SEEK_END: if (unlikely(offset > 0)) goto out_err; /* not supported for directories */ The previous .llseek handler, and the generic handler for other filesystems, allow seeking past the end of the dir AFAICT. (not sure why you'd want to, but I don't see that you'd get an error back). Is there a reason to uniquely exclude it in ext4? Does that line up with POSIX? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@redhat.com> To: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Cc: linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, Fan Yong <yong.fan@whamcloud.com>, bfields@redhat.com, Andreas Dilger <adilger@whamcloud.com> Subject: Re: [PATCH 5 2/4] Return 32/64-bit dir name hash according to usage type Date: Mon, 23 Apr 2012 17:23:22 -0500 [thread overview] Message-ID: <4F95D65A.8070608@redhat.com> (raw) In-Reply-To: <4F95C109.1030401@itwm.fraunhofer.de> On 4/23/12 3:52 PM, Bernd Schubert wrote: > On 04/23/2012 10:37 PM, Eric Sandeen wrote: ... > diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c > index b867862..3a4988e2 100644 > --- a/fs/ext4/dir.c > +++ b/fs/ext4/dir.c > @@ -363,7 +363,7 @@ loff_t ext4_dir_llseek(struct file *file, loff_t > offset, int origin) > goto out_err; > > if (!dx_dir) { > - if (offset > inode->i_sb->s_maxbytes) > + if (offset > i_size_read(inode)) > goto out_err; > } else if (offset > ext4_get_htree_eof(file)) > goto out_err; I'm curious about the above as well as: case SEEK_END: if (unlikely(offset > 0)) goto out_err; /* not supported for directories */ The previous .llseek handler, and the generic handler for other filesystems, allow seeking past the end of the dir AFAICT. (not sure why you'd want to, but I don't see that you'd get an error back). Is there a reason to uniquely exclude it in ext4? Does that line up with POSIX? -Eric
next prev parent reply other threads:[~2012-04-23 22:23 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-09 13:21 [PATCH 0/4] [RESEND] 32/64 bit llseek hashes (v5) Bernd Schubert 2012-01-09 13:21 ` [PATCH 5 1/4] Add new FMODE flags: FMODE_32bithash and FMODE_64bithash Bernd Schubert 2012-01-09 13:21 ` [PATCH 5 2/4] Return 32/64-bit dir name hash according to usage type Bernd Schubert 2012-03-05 15:59 ` Ted Ts'o [not found] ` <20120305155939.GE21356-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-06 0:40 ` Bernd Schubert 2012-03-06 0:40 ` Bernd Schubert 2012-03-06 2:28 ` Ted Ts'o [not found] ` <20120306022838.GA24323-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-06 9:59 ` Bernd Schubert 2012-03-06 9:59 ` Bernd Schubert [not found] ` <4F55E01B.3060105-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> 2012-03-06 15:15 ` Ted Ts'o 2012-03-06 15:15 ` Ted Ts'o [not found] ` <20120306151543.GA32282-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-07 9:01 ` Bernd Schubert 2012-03-07 9:01 ` Bernd Schubert [not found] ` <20120109132148.2616029.68798.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2012-04-20 20:04 ` Eric Sandeen 2012-04-20 20:04 ` Eric Sandeen [not found] ` <4F91C15B.6070200-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-22 12:51 ` Bernd Schubert 2012-04-22 12:51 ` Bernd Schubert 2012-04-23 20:37 ` Eric Sandeen [not found] ` <4F95BD72.6090200-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-23 20:52 ` Bernd Schubert 2012-04-23 20:52 ` Bernd Schubert 2012-04-23 21:22 ` Eric Sandeen [not found] ` <4F95C109.1030401-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> 2012-04-23 22:23 ` Eric Sandeen [this message] 2012-04-23 22:23 ` Eric Sandeen 2012-04-23 22:42 ` Andreas Dilger [not found] ` <A754D23B-B946-4E80-ACEA-0E2C2E6FAA2E-KloliPT79xf2eFz/2MeuCQ@public.gmane.org> 2012-04-24 16:10 ` Bernd Schubert 2012-04-24 16:10 ` Bernd Schubert 2012-04-24 19:21 ` Eric Sandeen 2012-04-24 21:07 ` Bernd Schubert 2012-04-24 22:24 ` Andreas Dilger 2012-04-25 15:05 ` Eric Sandeen 2012-04-25 15:12 ` Bernd Schubert 2012-04-25 15:36 ` Eric Sandeen 2012-04-24 21:28 ` Andreas Dilger 2012-04-24 21:26 ` Eric Sandeen 2012-01-09 13:21 ` [PATCH 5 3/4] nfsd_open(): rename 'int access' to 'int may_flags' in nfsd_open() Bernd Schubert 2012-01-09 13:21 ` [PATCH 5 4/4] nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes) Bernd Schubert [not found] ` <20120109132158.2616029.30467.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> [not found] ` <20120109132153.2616029.26302.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2012-03-06 0:08 ` [PATCH 5 3/4] nfsd_open(): rename 'int access' to 'int may_flags' in nfsd_open() Ted Ts'o 2012-03-06 0:08 ` Ted Ts'o [not found] ` <20120306000837.GA17164-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-06 2:08 ` J. Bruce Fields 2012-03-06 2:08 ` J. Bruce Fields 2012-03-06 15:18 ` Ted Ts'o 2012-03-06 15:28 ` J. Bruce Fields 2012-03-09 20:51 ` Ted Ts'o [not found] ` <20120309205148.GB5635-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-12 15:09 ` Ted Ts'o 2012-03-12 15:09 ` Ted Ts'o [not found] ` <20120312150912.GB12440-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-12 15:49 ` J. Bruce Fields 2012-03-12 15:49 ` J. Bruce Fields 2012-03-12 22:22 ` J. Bruce Fields 2012-03-13 20:01 ` J. Bruce Fields [not found] ` <20120313200117.GA21991-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-03-13 20:03 ` Bernd Schubert 2012-03-13 20:03 ` Bernd Schubert [not found] ` <4F5FA827.8020606-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> 2012-03-13 20:34 ` J. Bruce Fields 2012-03-13 20:34 ` J. Bruce Fields 2012-03-13 21:09 ` Bernd Schubert 2012-03-13 21:29 ` J. Bruce Fields [not found] ` <20120313212947.GK31995-spRCxval1Z7TsXDwO4sDpg@public.gmane.org> 2012-03-14 14:32 ` Bernd Schubert 2012-03-14 14:32 ` Bernd Schubert [not found] ` <4F60AC0D.9020204-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> 2012-03-14 16:05 ` J. Bruce Fields 2012-03-14 16:05 ` J. Bruce Fields [not found] ` <20120314160529.GB31194-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-03-16 21:22 ` Bernd Schubert 2012-03-16 21:22 ` Bernd Schubert 2012-03-19 2:54 ` Ted Ts'o [not found] ` <20120319025455.GD31682-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-19 20:00 ` J. Bruce Fields 2012-03-19 20:00 ` J. Bruce Fields [not found] ` <20120319200041.GA25161-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-03-20 0:10 ` Ted Ts'o 2012-03-20 0:10 ` Ted Ts'o 2012-04-12 20:49 ` J. Bruce Fields 2012-04-12 20:49 ` J. Bruce Fields [not found] ` <20120412204948.GE6667-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-04-12 21:22 ` Bernd Schubert 2012-04-12 21:22 ` Bernd Schubert [not found] ` <4F8747A1.8060800-97jfqw80gc6171pxa8y+qA@public.gmane.org> 2012-04-12 21:25 ` J. Bruce Fields 2012-04-12 21:25 ` J. Bruce Fields [not found] ` <20120313203446.GB21991-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-03-13 21:10 ` Ted Ts'o 2012-03-13 21:10 ` Ted Ts'o [not found] ` <20120313211009.GA11969-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2012-03-13 21:27 ` J. Bruce Fields 2012-03-13 21:27 ` J. Bruce Fields 2012-01-10 11:27 ` [PATCH 0/4] [RESEND] 32/64 bit llseek hashes (v5) Andreas Dilger 2012-01-11 14:48 ` J. Bruce Fields [not found] ` <20120111144827.GA32381-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-01-11 15:31 ` Ted Ts'o 2012-01-11 15:31 ` Ted Ts'o 2012-03-05 12:23 ` Bernd Schubert
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4F95D65A.8070608@redhat.com \ --to=sandeen-h+wxahxf7alqt0dzr+alfa@public.gmane.org \ --cc=adilger-KloliPT79xf2eFz/2MeuCQ@public.gmane.org \ --cc=bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org \ --cc=bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=yong.fan-KloliPT79xf2eFz/2MeuCQ@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.