Re: [f2fs-dev] [PATCH] f2fs: Cast expression type to unsigned long in __count_extent_cache()

2024-03-11 Thread David Laight
From: Jaegeuk Kim > Sent: 11 March 2024 20:37 > On 03/10, David Laight wrote: > > From: Roman Smirnov > > > Sent: 05 March 2024 08:10 > > > > > > Cast expression type to unsigned long in __count_extent_cache() > > > to prevent integer overflow

Re: [f2fs-dev] [PATCH] f2fs: Cast expression type to unsigned long in __count_extent_cache()

2024-03-10 Thread David Laight
From: Roman Smirnov > Sent: 05 March 2024 08:10 > > Cast expression type to unsigned long in __count_extent_cache() > to prevent integer overflow. > > Found by Linux Verification Center (linuxtesting.org) with Svace. Another broken analysis tool :-) > Signed-off-by: Roman Smirnov >

Re: [f2fs-dev] [PATCH v2 4/6] fs: Establish locking order for unrelated directories

2023-06-01 Thread David Laight
From: Jan Kara > Sent: 01 June 2023 17:14 > > On Thu 01-06-23 15:37:32, David Laight wrote: > > ... > > > > > + * Lock any non-NULL argument. The caller must make sure that if he > > > > > is passing > > > > > + * in two direct

Re: [f2fs-dev] [PATCH v2 4/6] fs: Establish locking order for unrelated directories

2023-06-01 Thread David Laight
... > > > + * Lock any non-NULL argument. The caller must make sure that if he is > > > passing > > > + * in two directories, one is not ancestor of the other Not directly relevant to this change but is the 'not an ancestor' check actually robust? I found a condition in which the kernel 'pwd'

Re: [f2fs-dev] [PATCH] f2fs: fix unaligned field offset in 32-bits platform

2023-03-10 Thread David Laight
From: Jaegeuk Kim > Sent: 09 March 2023 23:55 > > On 03/08, David Laight wrote: > > From: Chao Yu > > > Sent: 07 March 2023 15:14 > > > > > > F2FS-fs (dm-x): inconsistent rbtree, cur(3470333575168) > > > next(3320009719808) > > >

Re: [f2fs-dev] [PATCH] f2fs: fix unaligned field offset in 32-bits platform

2023-03-08 Thread David Laight
From: Chao Yu > Sent: 07 March 2023 15:14 > > F2FS-fs (dm-x): inconsistent rbtree, cur(3470333575168) next(3320009719808) > [ cut here ] > kernel BUG at fs/f2fs/gc.c:602! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > PC is at get_victim_by_default+0x13c0/0x1498 >

Re: [f2fs-dev] Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1

2023-01-20 Thread David Laight
From: Segher Boessenkool > Sent: 20 January 2023 10:54 ... > > > I suggest to file a bug against gcc complaining about a "spurious > > > warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is > > > adapted to not emit the warning about the pointer division if the result > > > is

Re: [f2fs-dev] [PATCH v1 3/5] treewide: use get_random_u32() when possible

2022-10-12 Thread David Laight
From: Joe Perches > Sent: 12 October 2022 20:17 > > On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote: > > The prandom_u32() function has been a deprecated inline wrapper around > > get_random_u32() for several releases now, and compiles down to the > > exact same code. Replace the

Re: [f2fs-dev] [PATCH 0/6] Remove usage of list iterator past the loop body

2022-03-07 Thread David Laight
From: Dan Carpenter > Sent: 07 March 2022 15:01 > > Updating this API is risky because some places rely on the old behavior > and not all of them have been updated. Here are some additional places > you might want to change. I really can't help thinking that trying to merge this patch is

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread David Laight
From: Xiaomeng Tong > Sent: 03 March 2022 07:27 > > On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote: > > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote: > > > The problem is the mis-use of iterator outside the loop on exit, and > > > the iterator will b

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-02 Thread David Laight
From: Xiaomeng Tong > Sent: 03 March 2022 02:27 > > On Wed, 2 Mar 2022 14:04:06 +0000, David Laight > wrote: > > I think that it would be better to make any alternate loop macro > > just set the variable to NULL on the loop exit. > > That is easier to code for and t

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-02 Thread David Laight
From: Xiaomeng Tong > Sent: 02 March 2022 09:31 > > On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds > wrote: > > > > But basically to _me_, the important part is that the end result is > > maintainable longer-term. > > I couldn't agree more. And because of that, I stick with the following >

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-01 Thread David Laight
From: Linus Torvalds > Sent: 01 March 2022 23:03 > > On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote: > > > > Can it be resolved by making: > > #define list_entry_is_head(pos, head, member) ((pos) == NULL) > > and double-checking that it isn't used anywhere el

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-01 Thread David Laight
From: Linus Torvalds > Sent: 01 March 2022 19:07 > On Mon, Feb 28, 2022 at 2:29 PM James Bottomley > wrote: > > > > However, if the desire is really to poison the loop variable then we > > can do > > > > #define list_for_each_entry(pos, head, member) \ > > for

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread David Laight
From: Matthew Wilcox > Sent: 28 February 2022 20:16 > > On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_ 'pos'

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread David Laight
From: Linus Torvalds > Sent: 28 February 2022 19:56 > On Mon, Feb 28, 2022 at 4:19 AM Christian König > wrote: > > > > I don't think that using the extra variable makes the code in any way > > more reliable or easier to read. > > So I think the next step is to do the attached patch (which

Re: [f2fs-dev] [PATCH v2 2/2] f2fs: Advertise encrypted casefolding in sysfs

2021-06-04 Thread David Laight
From: Jaegeuk Kim > Sent: 04 June 2021 05:45 ... > > > @@ -161,6 +161,9 @@ static ssize_t features_show(struct f2fs_attr *a, > > > if (f2fs_sb_has_compression(sbi)) > > > len += scnprintf(buf + len, PAGE_SIZE - len, "%s%s", > > > len ? ", " : "",

Re: [f2fs-dev] [PATCH v2 2/2] f2fs: Advertise encrypted casefolding in sysfs

2021-06-03 Thread David Laight
From: Greg KH > Sent: 03 June 2021 19:13 > > On Thu, Jun 03, 2021 at 10:53:26AM -0700, Jaegeuk Kim wrote: > > On 06/03, Greg KH wrote: > > > On Thu, Jun 03, 2021 at 08:40:24AM -0700, Jaegeuk Kim wrote: > > > > On 06/03, Greg KH wrote: > > > > > On Thu, Jun 03, 2021 at 09:50:38AM +, Daniel

Re: [f2fs-dev] [PATCH] f2fs: change to use rwsem for cp_mutex

2020-11-24 Thread David Laight
From: Chao Yu > Sent: 24 November 2020 03:12 > > On 2020/11/24 1:05, David Laight wrote: > > From: Sahitya Tummala > >> Sent: 23 November 2020 05:29 > >> > >> Use rwsem to ensure serialization of the callers and to avoid > >> starvation of high

Re: [f2fs-dev] [PATCH] f2fs: change to use rwsem for cp_mutex

2020-11-23 Thread David Laight
From: Sahitya Tummala > Sent: 23 November 2020 05:29 > > Use rwsem to ensure serialization of the callers and to avoid > starvation of high priority tasks, when the system is under > heavy IO workload. I can't see any read lock requests. So why the change? David - Registered Address

Re: [f2fs-dev] [PATCH] f2fs: compress: support chksum

2020-11-10 Thread David Laight
From: Chao Yu > Sent: 10 November 2020 06:28 ... > Actually, I think the both results are the same, inode chksum doesn't match > inode > metadata, like current case that cluster chksum doesn't match cluster data, it > doesn't matter how it becomes mismatched. > > And also, in those inode

Re: [f2fs-dev] [PATCH] f2fs: compress: support chksum

2020-11-03 Thread David Laight
From: Chao Yu > Sent: 03 November 2020 02:37 ... > >> Do we need to change fsck.f2fs to recover this? > > However, we don't know which one is correct, compressed data or chksum value? > if compressed data was corrupted, repairing chksum value doesn't help. > > Or how about adding chksum values