On 11/29/2018 03:33 PM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit: ef78e5ec9214 ia64: export node_distance function
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1514f73340
kernel config: https://syzkaller.appspot.com/x
On 11/30/2018 09:05 AM, Anand Jain wrote:
On 11/29/2018 10:31 PM, David Sterba wrote:
On Wed, Nov 28, 2018 at 04:47:27PM +0800, Anand Jain wrote:
2. scrub_workers_refcnt must eventually be converted to refcount_t type
ok. Added in v2 patch set.
No such thing is in v2 and this would
v3: Drops the patch [1]from this set.
[1]
btrfs: scrub: maintain the unlock order in scrub thread
Fixes the circular locking dependency warning as in patch 1/2,
and patch 2/2 adds lockdep_assert_held() to scrub_workers_get().
Anand Jain (2):
btrfs: scrub: fix circular locking dependency
Circular locking dependency check reports warning[1], that's because
the btrfs_scrub_dev() calls the stack #0 below with, the
fs_info::scrub_lock held. The test case leading to this warning..
mkfs.btrfs -fq /dev/sdb && mount /dev/sdb /btrfs
btrfs scrub start -B /btrfs
In fact we have fs_info:
scrub_workers_refcnt is protected by scrub_lock, add lockdep_assert_held()
function in scrub_workers_get().
Signed-off-by: Anand Jain
Suggested-by: Nikolay Borisov
---
v3: none
v2: born
fs/btrfs/scrub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
in
On 11/29/2018 10:31 PM, David Sterba wrote:
On Wed, Nov 28, 2018 at 04:47:27PM +0800, Anand Jain wrote:
2. scrub_workers_refcnt must eventually be converted to refcount_t type
ok. Added in v2 patch set.
No such thing is in v2 and this would actually get rid of the need to
hold scrub_lo
On 11/29/2018 06:36 PM, Filipe Manana wrote:
On Thu, Nov 29, 2018 at 9:27 AM Anand Jain wrote:
The device_list_mutex and scrub_lock creates a nested locks in
btrfs_scrub_dev().
During lock the order is device_list_mutex and then scrub_lock, and during
unlock, the order is device_list_mutex
On Wed, Nov 28, 2018 at 06:51:59PM +0200, Nikolay Borisov wrote:
> > Got me curious if we could get rid of the size parameter, it's 2x
> > PAGE_SIZE and could be something else in one case but it's not obvious
> > if it really happens.
> >
> > Another thing I noticed is lack of proper error handli
On 29.11.18 г. 18:43 ч., Jean Fobe wrote:
> Hi all,
> I've been studying LZ4 and other compression algorithms on the
> kernel, and seen other projects such as zram and ubifs using the
> crypto api. Is there a technical reason for not using the crypto api
> for compression (and possibly for e
Hi all,
I've been studying LZ4 and other compression algorithms on the
kernel, and seen other projects such as zram and ubifs using the
crypto api. Is there a technical reason for not using the crypto api
for compression (and possibly for encryption) in btrfs?
I did not find any design/tech
extent_readpages processes all pages in the readlist in batches of 16,
this is implemented by a single for loop but thanks to an if condition
the loop does 2 things based on whether we've filled the batch or not.
Additionally due to the structure of the code there is an additional
check which deals
On Mon, Nov 26, 2018 at 04:53:11PM +, Filipe Manana wrote:
> On Fri, Nov 16, 2018 at 11:09 AM wrote:
> >
> > From: Filipe Manana
> >
> > Commit d7396f07358a ("Btrfs: optimize key searches in btrfs_search_slot"),
> > dated from August 2013, introduced an optimization to search for keys in a
>
On Wed, Nov 28, 2018 at 04:47:27PM +0800, Anand Jain wrote:
> > 2. scrub_workers_refcnt must eventually be converted to refcount_t type
>
> ok. Added in v2 patch set.
No such thing is in v2 and this would actually get rid of the need to
hold scrub_lock in scrub_workers_put. Which in turn can be
Hi,
I've encountered mostly reproducable ENOSPC problem with send/receive.
The target is empty, newly created btrfs on regular HDD.
Reproduced twice with Arch Linux 4.19.4 kernel and once with the system
booted from arch install ISO
Current Release: 2018.11.01
Included Kernel: 4.18.16
The fai
> >> There are a bunch of filesystems which essentially open-code lru_to_page
> >> helper. Change them to using the helper. No functional changes.
> >
> > I would just squash the two into a single patch. It makes the first one
> > more obvious. Or is there any reason to have them separate?
>
>
On Thu, Nov 29, 2018 at 10:50:08AM +0200, Nikolay Borisov wrote:
>
>
> On 29.11.18 г. 10:18 ч., Michal Hocko wrote:
> > On Thu 29-11-18 09:52:57, Nikolay Borisov wrote:
> >> There are a bunch of filesystems which essentially open-code lru_to_page
> >> helper. Change them to using the helper. No f
On Thu, Nov 29, 2018 at 9:27 AM Anand Jain wrote:
>
> The device_list_mutex and scrub_lock creates a nested locks in
> btrfs_scrub_dev().
>
> During lock the order is device_list_mutex and then scrub_lock, and during
> unlock, the order is device_list_mutex and then scrub_lock.
> Fix this to the l
On Thu, Nov 29, 2018 at 9:32 AM Lu Fengqi wrote:
>
> The btrfs/001 with inode_cache mount option will encounter the following
> warning:
"The test case btrfs/001 ..."
>
> WARNING: CPU: 1 PID: 23700 at fs/btrfs/inode.c:956
> cow_file_range.isra.19+0x32b/0x430 [btrfs]
> CPU: 1 PID: 23700 Comm: bt
On 29.11.18 09:18, Michal Hocko wrote:
> On Thu 29-11-18 09:52:57, Nikolay Borisov wrote:
>> There are a bunch of filesystems which essentially open-code lru_to_page
>> helper. Change them to using the helper. No functional changes.
>
> I would just squash the two into a single patch. It makes the
The btrfs/001 with inode_cache mount option will encounter the following
warning:
WARNING: CPU: 1 PID: 23700 at fs/btrfs/inode.c:956
cow_file_range.isra.19+0x32b/0x430 [btrfs]
CPU: 1 PID: 23700 Comm: btrfs Kdump: loaded Tainted: GW O
4.20.0-rc4-custom+ #30
Hardware name: QEMU Stand
Circular locking dependency check reports warning[1], that's because
the btrfs_scrub_dev() calls the stack #0 below with, the
fs_info::scrub_lock held. The test case leading to this warning..
mkfs.btrfs -fq /dev/sdb && mount /dev/sdb /btrfs
btrfs scrub start -B /btrfs
In fact we have fs_info:
The device_list_mutex and scrub_lock creates a nested locks in
btrfs_scrub_dev().
During lock the order is device_list_mutex and then scrub_lock, and during
unlock, the order is device_list_mutex and then scrub_lock.
Fix this to the lock order of scrub_lock and then device_list_mutex.
Signed-off-
Idea was to fix the circular locking dependency warning as in patch 2/3,
and in the process also fixes the other identified cleanups patches 1/3,3/3
and they aren't dependent on 2ttch /3.
Anand Jain (3):
btrfs: scrub: maintain the unlock order in scrub thread
btrfs: scrub: fix circular locking
scrub_workers_refcnt is protected by scrub_lock, add lockdep_assert_held()
function in scrub_workers_get().
Signed-off-by: Anand Jain
Suggested-by: Nikolay Borisov
---
v2: born
fs/btrfs/scrub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 9ade0
On Thu 29-11-18 10:50:08, Nikolay Borisov wrote:
>
>
> On 29.11.18 г. 10:18 ч., Michal Hocko wrote:
> > On Thu 29-11-18 09:52:57, Nikolay Borisov wrote:
> >> There are a bunch of filesystems which essentially open-code lru_to_page
> >> helper. Change them to using the helper. No functional change
On 29.11.18 г. 10:18 ч., Michal Hocko wrote:
> On Thu 29-11-18 09:52:57, Nikolay Borisov wrote:
>> There are a bunch of filesystems which essentially open-code lru_to_page
>> helper. Change them to using the helper. No functional changes.
>
> I would just squash the two into a single patch. It
On Thu 29-11-18 09:52:57, Nikolay Borisov wrote:
> There are a bunch of filesystems which essentially open-code lru_to_page
> helper. Change them to using the helper. No functional changes.
I would just squash the two into a single patch. It makes the first one
more obvious. Or is there any reason
27 matches
Mail list logo
