[PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

[PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

[Namjae Jeon]

Hi,

Could you please pick up exfat stable patches ?

Thanks!

Hyeongseok Kim (1):
  exfat: fix wrong size update of stream entry by typo

Ilya Ponetayev (1):
  exfat: fix name_hash computation on big endian systems

Namjae Jeon (2):
  exfat: fix overflow issue in exfat_cluster_to_sector()
  exfat: fix wrong hint_stat initialization in exfat_find_dir_entry()

 fs/exfat/dir.c      | 2 +-
 fs/exfat/exfat_fs.h | 2 +-
 fs/exfat/file.c     | 2 +-
 fs/exfat/nls.c      | 8 ++++----
 4 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.17.1

[PATCH 5.7.y 1/4] exfat: fix overflow issue in exfat_cluster_to_sector()

[Namjae Jeon]

[ Upstream commit 43946b70494beefe40ec1b2ba4744c0f294d7736 ]

An overflow issue can occur while calculating sector in
exfat_cluster_to_sector(). It needs to cast clus's type to sector_t
before left shifting.

Fixes: 1acf1a564b60 ("exfat: add in-memory and on-disk structures and headers")
Cc: stable@vger.kernel.org # v5.7
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
---
 fs/exfat/exfat_fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index d865050fa6cd..99e9baf2d31d 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -375,7 +375,7 @@ static inline bool exfat_is_last_sector_in_cluster(struct exfat_sb_info *sbi,
 static inline sector_t exfat_cluster_to_sector(struct exfat_sb_info *sbi,
 		unsigned int clus)
 {
-	return ((clus - EXFAT_RESERVED_CLUSTERS) << sbi->sect_per_clus_bits) +
+	return ((sector_t)(clus - EXFAT_RESERVED_CLUSTERS) << sbi->sect_per_clus_bits) +
 		sbi->data_start_sector;
 }
 
-- 
2.17.1

[PATCH 5.7.y 2/4] exfat: fix wrong hint_stat initialization in exfat_find_dir_entry()

[Namjae Jeon]

[ Upstream commit d2fa0c337d97a5490190b9f3b9c73c8f9f3602a1 ]

We found the wrong hint_stat initialization in exfat_find_dir_entry().
It should be initialized when cluster is EXFAT_EOF_CLUSTER.

Fixes: ca06197382bd ("exfat: add directory operations")
Cc: stable@vger.kernel.org # v5.7
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
---
 fs/exfat/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index 6db302d76d4c..0c244eb706bd 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -1160,7 +1160,7 @@ int exfat_find_dir_entry(struct super_block *sb, struct exfat_inode_info *ei,
 			ret = exfat_get_next_cluster(sb, &clu.dir);
 		}
 
-		if (ret || clu.dir != EXFAT_EOF_CLUSTER) {
+		if (ret || clu.dir == EXFAT_EOF_CLUSTER) {
 			/* just initialized hint_stat */
 			hint_stat->clu = p_dir->dir;
 			hint_stat->eidx = 0;
-- 
2.17.1

[PATCH 5.7.y 3/4] exfat: fix wrong size update of stream entry by typo

[Namjae Jeon]

From: Hyeongseok Kim <hyeongseok@gmail.com>

[ Upstream commit 41e3928f8c58184fcf0bb22e822af39a436370c7 ]

The stream.size field is updated to the value of create timestamp
of the file entry. Fix this to use correct stream entry pointer.

Fixes: 29bbb14bfc80 ("exfat: fix incorrect update of stream entry in __exfat_truncate()")
Signed-off-by: Hyeongseok Kim <hyeongseok@gmail.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
---
 fs/exfat/file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index b93aa9e6cb16..04278f3c0adf 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -175,7 +175,7 @@ int __exfat_truncate(struct inode *inode, loff_t new_size)
 			ep2->dentry.stream.size = 0;
 		} else {
 			ep2->dentry.stream.valid_size = cpu_to_le64(new_size);
-			ep2->dentry.stream.size = ep->dentry.stream.valid_size;
+			ep2->dentry.stream.size = ep2->dentry.stream.valid_size;
 		}
 
 		if (new_size == 0) {
-- 
2.17.1

[PATCH 5.7.y 4/4] exfat: fix name_hash computation on big endian systems

[Namjae Jeon]

From: Ilya Ponetayev <i.ponetaev@ndmsystems.com>

[ Upstream commit db415f7aae07cadcabd5d2a659f8ad825c905299 ]

On-disk format for name_hash field is LE, so it must be explicitly
transformed on BE system for proper result.

Fixes: 370e812b3ec1 ("exfat: add nls operations")
Cc: stable@vger.kernel.org # v5.7
Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
Signed-off-by: Ilya Ponetayev <i.ponetaev@ndmsystems.com>
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
---
 fs/exfat/nls.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/exfat/nls.c b/fs/exfat/nls.c
index 6d1c3ae130ff..a647f8127f3b 100644
--- a/fs/exfat/nls.c
+++ b/fs/exfat/nls.c
@@ -495,7 +495,7 @@ static int exfat_utf8_to_utf16(struct super_block *sb,
 		struct exfat_uni_name *p_uniname, int *p_lossy)
 {
 	int i, unilen, lossy = NLS_NAME_NO_LOSSY;
-	unsigned short upname[MAX_NAME_LENGTH + 1];
+	__le16 upname[MAX_NAME_LENGTH + 1];
 	unsigned short *uniname = p_uniname->name;
 
 	WARN_ON(!len);
@@ -523,7 +523,7 @@ static int exfat_utf8_to_utf16(struct super_block *sb,
 		    exfat_wstrchr(bad_uni_chars, *uniname))
 			lossy |= NLS_NAME_LOSSY;
 
-		upname[i] = exfat_toupper(sb, *uniname);
+		upname[i] = cpu_to_le16(exfat_toupper(sb, *uniname));
 		uniname++;
 	}
 
@@ -614,7 +614,7 @@ static int exfat_nls_to_ucs2(struct super_block *sb,
 		struct exfat_uni_name *p_uniname, int *p_lossy)
 {
 	int i = 0, unilen = 0, lossy = NLS_NAME_NO_LOSSY;
-	unsigned short upname[MAX_NAME_LENGTH + 1];
+	__le16 upname[MAX_NAME_LENGTH + 1];
 	unsigned short *uniname = p_uniname->name;
 	struct nls_table *nls = EXFAT_SB(sb)->nls_io;
 
@@ -628,7 +628,7 @@ static int exfat_nls_to_ucs2(struct super_block *sb,
 		    exfat_wstrchr(bad_uni_chars, *uniname))
 			lossy |= NLS_NAME_LOSSY;
 
-		upname[unilen] = exfat_toupper(sb, *uniname);
+		upname[unilen] = cpu_to_le16(exfat_toupper(sb, *uniname));
 		uniname++;
 		unilen++;
 	}
-- 
2.17.1

Re: [PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

[Sasha Levin]

On Fri, Jul 24, 2020 at 09:15:40AM +0900, Namjae Jeon wrote:
>Hi,
>
>Could you please pick up exfat stable patches ?

I see that the upstream commits already have stable tags and don't need
modifications for backporting, so there is no need to explicitly send
them here - they will be picked up automatically.

-- 
Thanks,
Sasha

RE: [PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

[Namjae Jeon]

> 
> On Fri, Jul 24, 2020 at 09:15:40AM +0900, Namjae Jeon wrote:
> >Hi,
> >
> >Could you please pick up exfat stable patches ?
> 
Hi Sasha,
> I see that the upstream commits already have stable tags and don't need modifications for backporting,
> so there is no need to explicitly send them here - they will be picked up automatically.
Okay, I see:)
Thanks for your mail!
> 
> --
> Thanks,
> Sasha

Re: [PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

[Greg KH]

On Fri, Jul 24, 2020 at 01:00:58PM +0900, Namjae Jeon wrote:
> > 
> > On Fri, Jul 24, 2020 at 09:15:40AM +0900, Namjae Jeon wrote:
> > >Hi,
> > >
> > >Could you please pick up exfat stable patches ?
> > 
> Hi Sasha,
> > I see that the upstream commits already have stable tags and don't need modifications for backporting,
> > so there is no need to explicitly send them here - they will be picked up automatically.
> Okay, I see:)

As Sasha said, these will normally get picked up automatically.  We wait
until a patch is in a release from Linus (i.e. a -rc) before taking
them, but we can take them earilier if you ask for them.

You did include one patch in this series that was not marked for stable,
so I've taken that, and the other 3 now to make it easy.

thanks,

greg k-h

Re: FW: Re: [PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

[Namjae Jeon]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

> > > On Fri, Jul 24, 2020 at 09:15:40AM +0900, Namjae Jeon wrote:
> > > >Hi,
> > > >
> > > >Could you please pick up exfat stable patches ?
> > >
> > Hi Sasha,
> > > I see that the upstream commits already have stable tags and don't need modifications for backporting,
> > > so there is no need to explicitly send them here - they will be picked up automatically.
> > Okay, I see:)
>
Hi Greg,

Sorry for late reply. I checked this mail late.
> As Sasha said, these will normally get picked up automatically.  We wait
> until a patch is in a release from Linus (i.e. a -rc) before taking
> them, but we can take them earilier if you ask for them.
Okay, I like that you apply them after 5.8-rc7 is released if these
patches can be applied in 5.7. I was just worried that 5.7 stable
kernel release is closed without these patches being applied :)
>
> You did include one patch in this series that was not marked for stable,
> so I've taken that, and the other 3 now to make it easy.
Ah, okay, I will check stable mark in patches next time.

Thanks for your mail!
>
> thanks,
>
> greg k-h
>
>
>
>
>

[-- Attachment #2: noname --]
[-- Type: image/gif, Size: 13402 bytes --]

[-- Attachment #3: noname --]
[-- Type: image/gif, Size: 13402 bytes --]