2002-07-27 13:43:16

by Anton Altaparmakov

[permalink] [raw]
Subject: [BK PATCH 2.5] fs/ntfs/dir.c: use PAGE_CACHE_MASK_LL with 64-bit values

Linus,

Following from previous patch which introduced PAGE_CACHE_MASK_LL, this
one fixes a bug in fs/ntfs/dir.c which was using PAGE_CACHE_MASK
on 64-bit values... It now uses PAGE_CACHE_MASK_LL.

Patch together with the other two patches available from:

bk pull http://linux-ntfs.bkbits.net/linux-2.5-pm

Best regards,

Anton
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/, http://www-stu.christs.cam.ac.uk/~aia21/

===================================================================

This will update the following files:

fs/ntfs/dir.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)

through these ChangeSets:

<[email protected]> (02/07/27 1.479)
fs/ntfs/dir.c: Use PAGE_CACHE_MASK_LL() on 64-bit values.


diff -Nru a/fs/ntfs/dir.c b/fs/ntfs/dir.c
--- a/fs/ntfs/dir.c Sat Jul 27 14:24:09 2002
+++ b/fs/ntfs/dir.c Sat Jul 27 14:24:09 2002
@@ -1232,7 +1232,8 @@
ntfs_debug("Handling index buffer 0x%Lx.",
(long long)bmp_pos + cur_bmp_pos);
/* If the current index buffer is in the same page we reuse the page. */
- if ((prev_ia_pos & PAGE_CACHE_MASK) != (ia_pos & PAGE_CACHE_MASK)) {
+ if ((prev_ia_pos & PAGE_CACHE_MASK_LL) !=
+ (ia_pos & PAGE_CACHE_MASK_LL)) {
prev_ia_pos = ia_pos;
if (likely(ia_page != NULL))
ntfs_unmap_page(ia_page);

===================================================================

This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##


begin 664 bkpatch22037
M'XL(`/F>0CT``\V4T6K;,!2&KZVG.*,P$HIM2;:LV.#1-`WM2,I"2J^-K,B+
M66('2\DVIH>?FD*S)-U@91>SA(V.#D>__N_@"WC4JLL\40M*T`7<M=IDGA2-
M$670*.-"\[9UH7"KNU!W,ES5S?:;3P/F;];(;<^$D4O8J4YG'@FBEXCYOE&9
M-Q_?/DZ'<X3R'$9+T7Q6#\I`GB/3=CNQ6N@K89:KM@E,)QJ]5D8$LEW;EU1+
M,:9N,,(CS!)+$AQS*\F"$!$3M<`T'B0QVLN_.L@^+<`I)Q&E#%LV8`RC&R!!
MS%/`-,0\I!Q(G-$H8_P2DPQC.*T'EP1\C*[AW\H>(0F5#AOC7HNZ"V3VA`-F
MP]MQ,1J.[L;%_?!A4DRGO3ZT#22Q7]8&G("MT@&:@+M,G*+9P5GD_^6#$!88
M?8#KB3T28DG*,29N1#AEJ<5N06R%TVH@JRH5I;M1&9WY=%+D%^\CQFS,G1?[
M5CA*>VJ'MYU_SOVU\PFCQ+%/;)PPQO?L$WJ&GOT6/06?_'?HG[W\!'[W=3\=
MRMEQP3?TP@UQG("@C_LO15Y=0:^WZ=2NJ$6Q:36\?T5A'][ER/.\WI]R^O#C
:\+>02R6_Z.TZ'Z1110>E1#\!=V0"HX@$````
`
end


2002-07-28 18:11:49

by Eric W. Biederman

[permalink] [raw]
Subject: Re: [BK PATCH 2.5] fs/ntfs/dir.c: use PAGE_CACHE_MASK_LL with 64-bit values

Anton Altaparmakov <[email protected]> writes:

> Linus,
>
> Following from previous patch which introduced PAGE_CACHE_MASK_LL, this
> one fixes a bug in fs/ntfs/dir.c which was using PAGE_CACHE_MASK
> on 64-bit values... It now uses PAGE_CACHE_MASK_LL.
>
> Patch together with the other two patches available from:
>
> bk pull http://linux-ntfs.bkbits.net/linux-2.5-pm
>
> Best regards,
>
> Anton
> --
> Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
> Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
> WWW: http://linux-ntfs.sf.net/, http://www-stu.christs.cam.ac.uk/~aia21/
>
> ===================================================================
>
> This will update the following files:
>
> fs/ntfs/dir.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletion(-)
>
> through these ChangeSets:
>
> <[email protected]> (02/07/27 1.479)
> fs/ntfs/dir.c: Use PAGE_CACHE_MASK_LL() on 64-bit values.
>
>
> diff -Nru a/fs/ntfs/dir.c b/fs/ntfs/dir.c
> --- a/fs/ntfs/dir.c Sat Jul 27 14:24:09 2002
> +++ b/fs/ntfs/dir.c Sat Jul 27 14:24:09 2002
> @@ -1232,7 +1232,8 @@
> ntfs_debug("Handling index buffer 0x%Lx.",
> (long long)bmp_pos + cur_bmp_pos);
> /* If the current index buffer is in the same page we reuse the page. */
>
> - if ((prev_ia_pos & PAGE_CACHE_MASK) != (ia_pos & PAGE_CACHE_MASK)) {
> + if ((prev_ia_pos & PAGE_CACHE_MASK_LL) !=
> + (ia_pos & PAGE_CACHE_MASK_LL)) {
> prev_ia_pos = ia_pos;
> if (likely(ia_page != NULL))
> ntfs_unmap_page(ia_page);


Hmm. Wouldn't
prev_ia_pos >> PAGE_CACHE_SHIFT != ia_pos >> PAGE_CACHE_SHIFT
work just as well? And be some safer as the result could be stored in
32bits?

Eric

2002-07-28 18:56:53

by Anton Altaparmakov

[permalink] [raw]
Subject: Re: [BK PATCH 2.5] fs/ntfs/dir.c: use PAGE_CACHE_MASK_LL with 64-bit values

At 19:03 28/07/02, Eric W. Biederman wrote:
>Anton Altaparmakov <[email protected]> writes:
>
> > Linus,
> >
> > Following from previous patch which introduced PAGE_CACHE_MASK_LL, this
> > one fixes a bug in fs/ntfs/dir.c which was using PAGE_CACHE_MASK
> > on 64-bit values... It now uses PAGE_CACHE_MASK_LL.
> >
> > Patch together with the other two patches available from:
> >
> > bk pull http://linux-ntfs.bkbits.net/linux-2.5-pm
> >
> > Best regards,
> >
> > Anton
> > --
> > Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
> > Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
> > WWW: http://linux-ntfs.sf.net/, http://www-stu.christs.cam.ac.uk/~aia21/
> >
> > ===================================================================
> >
> > This will update the following files:
> >
> > fs/ntfs/dir.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletion(-)
> >
> > through these ChangeSets:
> >
> > <[email protected]> (02/07/27 1.479)
> > fs/ntfs/dir.c: Use PAGE_CACHE_MASK_LL() on 64-bit values.
> >
> >
> > diff -Nru a/fs/ntfs/dir.c b/fs/ntfs/dir.c
> > --- a/fs/ntfs/dir.c Sat Jul 27 14:24:09 2002
> > +++ b/fs/ntfs/dir.c Sat Jul 27 14:24:09 2002
> > @@ -1232,7 +1232,8 @@
> > ntfs_debug("Handling index buffer 0x%Lx.",
> > (long long)bmp_pos + cur_bmp_pos);
> > /* If the current index buffer is in the same page we reuse the
> page. */
> >
> > - if ((prev_ia_pos & PAGE_CACHE_MASK) != (ia_pos & PAGE_CACHE_MASK)) {
> > + if ((prev_ia_pos & PAGE_CACHE_MASK_LL) !=
> > + (ia_pos & PAGE_CACHE_MASK_LL)) {
> > prev_ia_pos = ia_pos;
> > if (likely(ia_page != NULL))
> > ntfs_unmap_page(ia_page);
>
>
>Hmm. Wouldn't
>prev_ia_pos >> PAGE_CACHE_SHIFT != ia_pos >> PAGE_CACHE_SHIFT
>work just as well? And be some safer as the result could be stored in
>32bits?

No it couldn't necessarily. (Althought we would have refused to open the
directory if it would be but I would like to see those kinds of limits
removed.)

Yes, the shifts would do the same but they would generate more inefficient
code (this is a completely unverified and possibly wild assumption).

Best regards,

Anton


--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/