As Jia-Ju Bai reported:
"According to fs/f2fs/trace.c, the kernel module may sleep under a spinlock.
The function call path is:
f2fs_trace_pid (acquire the spinlock)
f2fs_radix_tree_insert
cond_resched --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug i
Hi Hyunchul,
On 2017/12/12 10:15, Hyunchul Lee wrote:
> Hi Chao,
>
> On 12/11/2017 10:15 PM, Chao Yu wrote:
>> Hi Hyunchul,
>>
>> On 2017/12/1 16:28, Hyunchul Lee wrote:
>>> Hi Chao,
>>>
>>> On 11/30/2017 04:06 PM, Chao Yu wrote:
Hi Hyunchul,
On 2017/11/28 8:23, Hyunchul Lee wrote:
Hi Chao,
On 12/11/2017 10:15 PM, Chao Yu wrote:
> Hi Hyunchul,
>
> On 2017/12/1 16:28, Hyunchul Lee wrote:
>> Hi Chao,
>>
>> On 11/30/2017 04:06 PM, Chao Yu wrote:
>>> Hi Hyunchul,
>>>
>>> On 2017/11/28 8:23, Hyunchul Lee wrote:
From: Hyunchul Lee
This implements which hint is pas
Hi Jia-Ju,
Thanks for your report. :)
On 2017/12/12 8:59, Jia-Ju Bai wrote:
> According to fs/f2fs/trace.c, the kernel module may sleep under a spinlock.
> The function call path is:
> f2fs_trace_pid (acquire the spinlock)
>f2fs_radix_tree_insert
> cond_resched --> may sleep
>
> I do no
According to fs/f2fs/trace.c, the kernel module may sleep under a spinlock.
The function call path is:
f2fs_trace_pid (acquire the spinlock)
f2fs_radix_tree_insert
cond_resched --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analys
On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 02:12:28PM -0800, Joe Perches wrote:
> > Completely reasonable. Thanks.
>
> If we're doing "completely reasonable" complaints, then ...
>
> - I don't understand why plain 'unsigned' is deemed bad.
That was a Dav
On Mon, Dec 11, 2017 at 02:12:28PM -0800, Joe Perches wrote:
> On Tue, 2017-12-12 at 08:43 +1100, Dave Chinner wrote:
> > On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> > > On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > > > 1. Using lockdep_set_novalidate_class()
On 12/05/2017 04:40 PM, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> This is documentation on how to use the XArray, not details about its
> internal implementation.
>
> Signed-off-by: Matthew Wilcox
> ---
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/xarray.rst | 2
On Mon, Dec 11, 2017 at 02:12:28PM -0800, Joe Perches wrote:
> Completely reasonable. Thanks.
If we're doing "completely reasonable" complaints, then ...
- I don't understand why plain 'unsigned' is deemed bad.
- The rule about all function parameters in prototypes having a name
doesn't ma
On Tue, 2017-12-12 at 08:43 +1100, Dave Chinner wrote:
> On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> > On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > > 1. Using lockdep_set_novalidate_class() for anything other
> > > than device->mutex will throw checkpatch warnin
On Sun, Dec 10, 2017 at 08:23:15PM -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 10:57:45AM +1100, Dave Chinner wrote:
> > i.e. the fact the cmpxchg failed may not have anything to do with a
> > race condtion - it failed because the slot wasn't empty like we
> > expected it to be. There c
On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > 1. Using lockdep_set_novalidate_class() for anything other
> > than device->mutex will throw checkpatch warnings. Nice. (*)
> []
> > (*) checkpatch.pl is considered most
> On 08.12.2017, at 03:51, Jason A. Donenfeld wrote:
>
> Hi Eric,
>
> Nice to see more use of ChaCha20. However...
>
> Can we skip over the "sort of worse than XTS, but not having _real_
> authentication sucks anyway in either case, so whatever" and move
> directly to, "linux finally supports
On 2017/12/11 12:23, Yunlei He wrote:
> Came across a dead loop in recovery like this:
>
> ..
> [ 24.680480s][pid:320,cpu0,init]find_fsync_dnodes: blkaddr =13597696
> [ 24.698394s][pid:320,cpu0,init]find_fsync_dnodes: blkaddr =13597697
> [ 24.724334s][pid:320,cpu0,init]find_fsync_dnodes:
On 2017/12/8 13:44, heyunlei wrote:
>
>
>> -Original Message-
>> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
>> Sent: Friday, December 08, 2017 1:27 PM
>> To: heyunlei
>> Cc: Yuchao (T); linux-f2fs-devel@lists.sourceforge.net; Wangbintian; Jianing
>> (Euler)
>> Subject: Re: [f2fs-dev][
On 2017/12/6 11:31, Yunlei He wrote:
> No need return value in restore summary process
>
> Signed-off-by: Yunlei He
Reviewed-by: Chao Yu
Thanks,
--
Check out the vibrant tech community on one of the world's most
engag
Hi Hyunchul,
On 2017/12/1 16:28, Hyunchul Lee wrote:
> Hi Chao,
>
> On 11/30/2017 04:06 PM, Chao Yu wrote:
>> Hi Hyunchul,
>>
>> On 2017/11/28 8:23, Hyunchul Lee wrote:
>>> From: Hyunchul Lee
>>>
>>> This implements which hint is passed down to block layer
>>> for datas from the specific segment
On 2017/12/5 16:38, LiFan wrote:
> Since the variable release is only nonzero when another unlikely
> case occurs, use unlikely() on it seems logical.
>
> Signed-off-by: Fan li
Reviewed-by: Chao Yu
Thanks,
--
Check ou
Hi Jaegeuk,
On 2017/12/1 15:36, Jaegeuk Kim wrote:
> Hi Chao,
>
> This is really hard to review and risky a lot to apply it shortly. Do we have
> a
I can understand your concern.
> strong reason we have to do this? The original design goal was to minimize
> allocation delay which is almost zer
19 matches
Mail list logo
