Re: [RFC] btrfs: Allow read-only mount with corrupted extent tree

On 2021/3/19 下午11:34, Dāvis Mosāns wrote: ceturtd., 2021. g. 18. marts, plkst. 01:49 — lietotājs Qu Wenruo () rakstīja: On 2021/3/18 上午5:03, Dāvis Mosāns wrote: trešd., 2021. g. 17. marts, plkst. 12:28 — lietotājs Qu Wenruo () rakstīja: On 2021/3/17 上午9:29, Dāvis Mosāns wrote: trešd

Re: [RFC] btrfs: Allow read-only mount with corrupted extent tree

On 2021/3/18 上午5:03, Dāvis Mosāns wrote: trešd., 2021. g. 17. marts, plkst. 12:28 — lietotājs Qu Wenruo () rakstīja: On 2021/3/17 上午9:29, Dāvis Mosāns wrote: trešd., 2021. g. 17. marts, plkst. 03:18 — lietotājs Dāvis Mosāns () rakstīja: Currently if there's any corruption at all

Re: [RFC] btrfs: Allow read-only mount with corrupted extent tree

On 2021/3/17 上午9:29, Dāvis Mosāns wrote: trešd., 2021. g. 17. marts, plkst. 03:18 — lietotājs Dāvis Mosāns () rakstīja: Currently if there's any corruption at all in extent tree (eg. even single bit) then mounting will fail with: "failed to read block groups: -5" (-EIO) It happens because

Re: [btrfs] e86bb85b1f: stress-ng.utime.ops_per_sec -70.1% regression

rl: https://github.com/0day-ci/linux/commits/Qu-Wenruo/btrfs-make-btrfs_dirty_inode-to-always-reserve-metadata-space/20210108-134133 base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next in testcase: stress-ng on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 51

Re: [btrfs] ccb0edc68b: xfstests.btrfs.179.fail

On 2020/11/26 下午4:56, kernel test robot wrote: > > Greeting, > > FYI, we noticed the following commit (built with gcc-9): > > commit: ccb0edc68b690d0a62e9377ab509eb2f7cb610d3 ("btrfs: stop running all > delayed refs during snapshot") >

Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")

On 2020/11/23 下午2:47, Jan Kiszka wrote: > On 22.11.20 17:35, Michał Mirosław wrote: >> On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote: >>> On 09.11.20 00:28, Qu Wenruo wrote: >>>> On 2020/11/9 上午1:18, Michał Mirosław wrote: >>>>> On Sun

Re: [PATCH 4.19 29/71] btrfs: tree-checker: Verify inode item

On 2020/11/11 下午9:38, Pavel Machek wrote: > Hi! > >>>> From: Qu Wenruo >>>> >>>> commit 496245cac57e26d8b738d85c7a29cf9a47610f3f upstream. >>>> >>>> There is a report in kernel bugzilla about mismatch file type in dir >&g

Re: [PATCH 4.19 29/71] btrfs: tree-checker: Verify inode item

On 2020/11/11 下午9:13, Pavel Machek wrote: > Hi! > >> From: Qu Wenruo >> >> commit 496245cac57e26d8b738d85c7a29cf9a47610f3f upstream. >> >> There is a report in kernel bugzilla about mismatch file type in dir >> item and inode item. >> >&

Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")

On 2020/11/9 上午1:18, Michał Mirosław wrote: > On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote: >> Hi Michał, >> >> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot >> from NVME. >> >> It turns out that, commit aea6cb9

[PATCH] PCI: Rockchip: output proper error message for regulator error

same time, the dmesg shows nothing about the problem, making debug much harder. This patch will introduce a macro, rockchip_get_regulator(), which we can get mandatory or optional regulator with just one line, with proper error message when it goes wrong. Signed-off-by: Qu Wenruo --- d

Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")

Also add Rockchip and device tree mail lists to the CC, just in case we need to update the device tree for RK808. On 2020/11/8 下午3:35, Qu Wenruo wrote: > Hi Michał, > > Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot > from NVME. > > It turn

About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")

Hi Michał, Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot from NVME. It turns out that, commit aea6cb99703e ("regulator: resolve supply after creating regulator") seems to be the cause. In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is provided by RK808

About the rockpi4 pcie controller failed to initialize problem in v5.10-rc2

Hi guys, I see your awesome contribution to support Rock Pi 4B. However in recent rc (v5.10-rc2), I found that even with `vpcie1v8` and `vpcie0v9` added, `regulartor_dev_lookup()` now just returns -EPROBE_DEFER, preventing rockchip pcie controller to be initialized. The full callchain is:

Re: Very slow realtek 8169 ethernet performance, but only one interface, on ThinkPad T14.

On 2020/11/5 下午5:13, Heiner Kallweit wrote: > On 05.11.2020 08:42, Qu Wenruo wrote: >> >> >> On 2020/11/5 下午3:01, Heiner Kallweit wrote: >>> On 05.11.2020 03:48, Qu Wenruo wrote: >>>> Hi, >>>> >>>> Not sure if this is a regre

Re: Very slow realtek 8169 ethernet performance, but only one interface, on ThinkPad T14.

On 2020/11/5 下午3:01, Heiner Kallweit wrote: > On 05.11.2020 03:48, Qu Wenruo wrote: >> Hi, >> >> Not sure if this is a regression or not, but just find out that after >> upgrading to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen >> version) b

Very slow realtek 8169 ethernet performance, but only one interface, on ThinkPad T14.

Hi, Not sure if this is a regression or not, but just find out that after upgrading to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen version) becomes very slow. Only *2~3* Mbps. The laptop has two ethernet interfaces, one needs a passive adapter, the other one is a standard

v5.10-rc2 kernel unable to initialize RK3399 pcie root complex

Hi, Recently I tried to run v5.10-rc2 kernel on my RK3399 board (Rock Pi 4B, 4G ram version), most drivers work, but the PCIE RC of the board fails to register, without obvious dmesg error. My previous v5.9 kernel runs pretty fine on that board, and can boot from root on LVM on NVME device

Re: ERROR: modpost: "__udivdi3" [fs/btrfs/btrfs.ko] undefined!

On 2020/11/3 下午5:47, Geert Uytterhoeven wrote: > On Tue, Nov 3, 2020 at 10:43 AM Naresh Kamboju > wrote: >> Linux next 20201103 tag make modules failed for i386 and arm >> architecture builds. >> >> Error log: >> LD [M] fs/btrfs/btrfs.o >> MODPOST Module.symvers >> ERROR: modpost:

Re: [btrfs] 3b54a0a703: WARNING:at_fs/btrfs/inode.c:#btrfs_finish_ordered_io[btrfs]

On 2020/9/16 上午11:32, Oliver Sang wrote: > On Tue, Sep 15, 2020 at 04:00:40PM +0800, Qu Wenruo wrote: >> >> >> On 2020/9/15 下午3:40, Qu Wenruo wrote: >>> >>> >>> On 2020/9/15 下午1:54, Oliver Sang wrote: >>>> On Wed, Sep 09, 2020 at 03:4

Re: [btrfs] 3b54a0a703: WARNING:at_fs/btrfs/inode.c:#btrfs_finish_ordered_io[btrfs]

On 2020/9/15 下午3:40, Qu Wenruo wrote: > > > On 2020/9/15 下午1:54, Oliver Sang wrote: >> On Wed, Sep 09, 2020 at 03:49:30PM +0800, Qu Wenruo wrote: >>> >>> >>> On 2020/9/9 下午3:08, kernel test robot wrote: >>>> Greeting, >>&g

Re: [btrfs] 3b54a0a703: WARNING:at_fs/btrfs/inode.c:#btrfs_finish_ordered_io[btrfs]

On 2020/9/15 下午1:54, Oliver Sang wrote: > On Wed, Sep 09, 2020 at 03:49:30PM +0800, Qu Wenruo wrote: >> >> >> On 2020/9/9 下午3:08, kernel test robot wrote: >>> Greeting, >>> >>> FYI, we noticed the following commit (built with gcc-9): >>

Re: [btrfs] 3b54a0a703: WARNING:at_fs/btrfs/inode.c:#btrfs_finish_ordered_io[btrfs]

tions") > url: > https://github.com/0day-ci/linux/commits/Qu-Wenruo/btrfs-Enhanced-runtime-defence-against-fuzzed-images/20200809-201720 > base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next > > in testcase: fio-basic > with following parameters: > &g

[PATCH] module: Add more error message for failed kernel module loading

extra info. So this patch will add extra error messages for -ENOEXEC and -EPERM errors, allowing user to do better debugging and reporting. Signed-off-by: Qu Wenruo Reviewed-by: Lucas De Marchi --- Changelog: v2: - Add extra section description for the error message of module_enforce_rw

[PATCH] module: Add more error message for failed kernel module loading

get extra info. So this patch will add extra error messages for -ENOEXEC and -EPERM errors, allowing user to do better debugging and reporting. Signed-off-by: Qu Wenruo --- kernel/module.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/modu

[PATCH] module: Add more error message for failed kernel module loading

get extra info. So this patch will add extra error messages for -ENOEXEC and -EPERM errors, allowing user to do better debugging and reporting. Signed-off-by: Qu Wenruo --- kernel/module.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/modu

Re: [PATCH] btrfs: block-group: Fix free-space bitmap threshould

block > group item") > CC: sta...@vger.kernel.org # 5.8+ > Signed-off-by: Marcos Paulo de Souza Reviewed-by: Qu Wenruo It would be even nicer if you could add some warning or self-test on cache->length to prevent such problem from happening again. Thanks, Qu > --- > fs/

Re: [PATCH v2] kobject: Restore old behaviour of kobject_del(NULL)

d2fb4bf9 ("kobject: Avoid premature parent object freeing in > kobject_cleanup()") > Reported-by: Qu Wenruo Sorry, I should use my suse mailbox for that. > Cc: Heikki Krogerus > Signed-off-by: Andy Shevchenko Reviewed-by: Qu Wenruo Thanks, Qu > --- > v2: replaced

Re: [PATCH] kobject: Avoid premature parent object freeing in kobject_cleanup()

On 2020/8/3 下午3:27, Andy Shevchenko wrote: > On Mon, Aug 3, 2020 at 10:25 AM Andy Shevchenko > wrote: >> On Mon, Aug 3, 2020 at 9:47 AM Qu Wenruo wrote: >>> On 2020/6/5 上午1:46, Rafael J. Wysocki wrote: > >>>> +void kobject_del(struct kobject *kobj) >&

Re: [PATCH] kobject: Avoid premature parent object freeing in kobject_cleanup()

On 2020/6/5 上午1:46, Rafael J. Wysocki wrote: > From: Heikki Krogerus > > If kobject_del() is invoked by kobject_cleanup() to delete the > target kobject, it may cause its parent kobject to be freed > before invoking the target kobject's ->release() method, which > effectively means freeing the

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

On 2020/5/1 上午9:05, Stephen Rothwell wrote: > Hi all, > > On Fri, 1 May 2020 10:24:53 +1000 Stephen Rothwell > wrote: >> >> Today's linux-next merge of the btrfs tree got a conflict in: >> >> fs/btrfs/transaction.c >> >> between commit: >> >> fcc99734d1d4 ("btrfs: transaction: Avoid

Re: [PATCH] btrfs: fix gcc-4.8 build warning

backref, don't add refs from shared block when > resolving normal backref") OK, at least this fix is mentioning it's older gcc causing problem, and the fix using GNU extension is also clear. Reviewed-by: Qu Wenruo Thanks, Qu > Signed-off-by: Arnd Bergmann > --- > fs/btrfs/backref.c |

[PATCH v3] tools/lib/traceevent, perf tools: Handle %pU format correctly

east print fsid correctly: 0.000 xfs_io/79619 btrfs:qgroup_meta_reserve:23ad1511-dd83-47d4-a79c-e96625a15a6e refroot=5(FS_TREE) type=0x0 diff=2 Signed-off-by: Qu Wenruo --- Changelog: v2: - Use more comment explaining the finetunings we skipped for %pU* - Extra check for the field before readin

[PATCH] tools/lib/traceevent, perf tools: Handle %pU format correctly

east print fsid correctly: 0.000 xfs_io/79619 btrfs:qgroup_meta_reserve:23ad1511-dd83-47d4-a79c-e96625a15a6e refroot=5(FS_TREE) type=0x0 diff=2 Signed-off-by: Qu Wenruo --- Please note in above case, the @type and @diff are not properly showed. That's another problem, will be addressed in lat

Re: [PATCH] erofs: move erofs out of staging

[...] >>> I have made a simple fuzzer to inject messy in inode metadata, >>> dir data, compressed indexes and super block, >>> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer >>> >>> I am testing with some given dirs and the following script. >>>

Re: [PATCH] btrfs: fix out of bounds array access while reading extent buffer

On 2019/6/14 下午7:51, Young Xiao wrote: > There is a corner case that slips through the checkers in functions > reading extent buffer, ie. > > if (start < eb->len) and (start + len > eb->len), then: > the checkers in read_extent_buffer_to_user(), and memcmp_extent_buffer() > WARN_ON(start >

[5.2-rc REGRESSION] Random gcc crash for 'make -j12' when low on memory

Hi, When compiling the kernel on v5.2-rc (both rc1 and rc2) with "make -j12", the gcc will randomly crash with segfault, while on v5.1-rc7 everything is OK. The crash only happens when the VM has only 1G ram, when given 4G ram it no longer crash. However according to dmesg, there is no OOM

Re: [btrfs] ddf30cf03f: xfstests.generic.102.fail

On 2019/5/10 上午11:19, kernel test robot wrote: > FYI, we noticed the following commit (built with gcc-7): > > commit: ddf30cf03fb53b9a0ad0f355a69dbedf416edde9 ("btrfs: extent-tree: Use > btrfs_ref to refactor add_pinned_bytes()") >

Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok

On 2019/4/2 上午11:14, Rong Chen wrote: > > On 4/1/19 11:40 PM, David Sterba wrote: >> On Mon, Apr 01, 2019 at 11:02:37PM +0800,  Chen, Rong A  wrote: >>> On 4/1/2019 10:29 PM, Qu Wenruo wrote: >>>> On 2019/4/1 下午10:02,  Chen, Rong A  wrote: >>>>

Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok

On 2019/4/2 上午11:14, Rong Chen wrote: > > On 4/1/19 11:40 PM, David Sterba wrote: >> On Mon, Apr 01, 2019 at 11:02:37PM +0800,  Chen, Rong A  wrote: >>> On 4/1/2019 10:29 PM, Qu Wenruo wrote: >>>> On 2019/4/1 下午10:02,  Chen, Rong A  wrote: >>>>

Re: [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok

On 2019/4/1 下午10:02, Chen, Rong A wrote: > > On 4/1/2019 9:28 PM, Nikolay Borisov wrote: >> >> On 1.04.19 г. 16:24 ч., kernel test robot wrote: >>> FYI, we noticed the following commit (built with gcc-7): >>> >>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs: >>> tree-checker:

Re: [LKP] [btrfs] 44fe89de7d: aim7.jobs-per-min -15.1% regression

On 2019/3/12 下午9:50, kernel test robot wrote: > Greeting, > > FYI, we noticed a -15.1% regression of aim7.jobs-per-min due to commit: > > > commit: 44fe89de7d5157a4f31f13d94802c7619e23f462 ("btrfs: Do mandatory tree > block check before submitting bio") That commit will cause extra check

Re: [PATCH v2 -next] btrfs: Remove unnecessary casts in btrfs_read_root_item

ldn't want to pass negatives to read_extent_buffer(). Also there > is an extra cast. > > This patch shouldn't affect runtime, it's just a clean up. > > Suggested-by: Dan Carpenter > Signed-off-by: YueHaibing Reviewed-by: Qu Wenruo The commit message is much better. Thanks, Qu >

Re: [PATCH -next] btrfs: Fix type conversion in btrfs_read_root_item

On 2019/2/20 上午11:08, YueHaibing wrote: > btrfs_item_size_nr return value is u32, convert it to int may result > in truncation.Also read_extent_buffer expect a unsigned param, so > min_t should use type u32 to compare. Btrfs has a up limit on item size, it will never exceed 64K - various

Re: [LKP] [btrfs] 05a37c4860: kmsg.BTRFS_error(device_vdd):failed_to_verify_dev_extents_against_chunks

On 2019/1/11 下午10:03, kernel test robot wrote: > FYI, we noticed the following commit (built with gcc-7): > > commit: 05a37c48604c19b50873fd9663f9140c150469d1 ("btrfs: volumes: Make sure > no dev extent is beyond device boundary") >

Re: [PATCH v2] btrfs: add a check for sysfs_create_group

oup); > ret = sysfs_create_group(fsid_kobj, _feature_attr_group); > + if (ret) > + btrfs_err(fs_info, "failed to create > btrfs_feature_attr_group.\n"); Forgot to mention, for btrfs_* infrastructure, no need for the ending '\n'. Despite that, looks good. Reviewed

Re: [PATCH] btrfs: add a check for sysfs_create_group

On 2018/12/26 上午11:46, Kangjie Lu wrote: > In case sysfs_create_group fails, let's check its return value and > issues an error message. > > Signed-off-by: Kangjie Lu > --- > fs/btrfs/sysfs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c >

ridiculously slow VM memory performance on Ryzen CPU

Hi, When testing IO heavy work on my VM backed by Ryzen 1700 CPU, I turned to brd modules, but surprisingly, the speed is even slower than some HDD: --- $ sudo modprobe brd rd_nr=1 rd_size=1048576 $ dd if=/dev/zero of=/dev/ram0 bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824

ridiculously slow VM memory performance on Ryzen CPU

Hi, When testing IO heavy work on my VM backed by Ryzen 1700 CPU, I turned to brd modules, but surprisingly, the speed is even slower than some HDD: --- $ sudo modprobe brd rd_nr=1 rd_size=1048576 $ dd if=/dev/zero of=/dev/ram0 bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824

Re: [lkp-robot] [btrfs] 7eafb77890: stderr.fs_mark:fsync_failed_Input/output_error

The latest patch handles it by introducing new @super_num parameter and different check timing. Thanks, Qu On 2018年04月23日 09:20, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: 7eafb77890ff459863e3bc772465cb641c14f754 ("btrfs: Do super block >

Re: [lkp-robot] [btrfs] 7eafb77890: stderr.fs_mark:fsync_failed_Input/output_error

The latest patch handles it by introducing new @super_num parameter and different check timing. Thanks, Qu On 2018年04月23日 09:20, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: 7eafb77890ff459863e3bc772465cb641c14f754 ("btrfs: Do super block >

Re: linux-next: build warning after merge of the btrfs-kdave tree

On 2017年12月22日 00:49, David Sterba wrote: > On Wed, Dec 20, 2017 at 08:12:11AM +0800, Qu Wenruo wrote: >> On 2017年12月20日 06:20, Stephen Rothwell wrote: >>> After merging the btrfs-kdave tree, today's linux-next build (powerpc >>> ppc64_defconfig) produced this warning

Re: linux-next: build warning after merge of the btrfs-kdave tree

On 2017年12月22日 00:49, David Sterba wrote: > On Wed, Dec 20, 2017 at 08:12:11AM +0800, Qu Wenruo wrote: >> On 2017年12月20日 06:20, Stephen Rothwell wrote: >>> After merging the btrfs-kdave tree, today's linux-next build (powerpc >>> ppc64_defconfig) produced this warning

Re: linux-next: build warning after merge of the btrfs-kdave tree

On 2017年12月20日 06:20, Stephen Rothwell wrote: > Hi David, > > After merging the btrfs-kdave tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/btrfs/qgroup.c: In function 'qgroup_reserve': > fs/btrfs/qgroup.c:2432:1: warning: label 'retry' defined but not

Re: linux-next: build warning after merge of the btrfs-kdave tree

On 2017年12月20日 06:20, Stephen Rothwell wrote: > Hi David, > > After merging the btrfs-kdave tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/btrfs/qgroup.c: In function 'qgroup_reserve': > fs/btrfs/qgroup.c:2432:1: warning: label 'retry' defined but not

Re: [PATCH] btrfs: tree-checker: use %zu format string for size_t

87f2e3e0 ("btrfs: tree-checker: Add checker for dir item") Reviewed-by: Qu Wenruo <w...@suse.com> Thanks, Qu > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- > fs/btrfs/tree-checker.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [PATCH] btrfs: tree-checker: use %zu format string for size_t

87f2e3e0 ("btrfs: tree-checker: Add checker for dir item") Reviewed-by: Qu Wenruo Thanks, Qu > Signed-off-by: Arnd Bergmann > --- > fs/btrfs/tree-checker.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/tree-checker.c b/fs/btrf

Re: [GIT PULL] Btrfs changes for 4.15

used parameters from various functions > btrfs: Remove unused arguments from btrfs_changed_cb_t > btrfs: Remove unused parameter from check_direct_IO > btrfs: Rework error handling of add_extent_mapping in > __btrfs_alloc_chunk > btrfs: Remove redundan

Re: [GIT PULL] Btrfs changes for 4.15

used parameters from various functions > btrfs: Remove unused arguments from btrfs_changed_cb_t > btrfs: Remove unused parameter from check_direct_IO > btrfs: Rework error handling of add_extent_mapping in > __btrfs_alloc_chunk > btrfs: Remove redundan

Re: [PATCH] btrfs: tests: Fix a memory leak in error handling path in 'run_test()'

On 2017年09月10日 19:19, Christophe JAILLET wrote: If 'btrfs_alloc_path()' fails, we must free the resourses already allocated, as done in the other error handling paths in this function. Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr> Reviewed-by: Qu Wenruo <qu

Re: [PATCH] btrfs: tests: Fix a memory leak in error handling path in 'run_test()'

On 2017年09月10日 19:19, Christophe JAILLET wrote: If 'btrfs_alloc_path()' fails, we must free the resourses already allocated, as done in the other error handling paths in this function. Signed-off-by: Christophe JAILLET Reviewed-by: Qu Wenruo BTW, I also checked all btrfs_alloc_path

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/07/2017 03:41 PM, Reshetova, Elena wrote: At 03/06/2017 05:43 PM, Reshetova, Elena wrote: At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/07/2017 03:41 PM, Reshetova, Elena wrote: At 03/06/2017 05:43 PM, Reshetova, Elena wrote: At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/06/2017 05:43 PM, Reshetova, Elena wrote: At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/06/2017 05:43 PM, Reshetova, Elena wrote: At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental

Re: [PATCH 1/2] btrfs: drop trace_btrfs_all_work_done() from normal_work_helper()

At 12/21/2016 04:28 PM, Sebastian Andrzej Siewior wrote: On 2016-12-21 08:33:03 [+0800], Qu Wenruo wrote: The trace point only uses the pointer, and this helps us to pair with btrfs_work_queued/sched. | /* For situiations that the work is freed */ | DECLARE_EVENT_CLASS(btrfs__work__done

Re: [PATCH 1/2] btrfs: drop trace_btrfs_all_work_done() from normal_work_helper()

At 12/21/2016 04:28 PM, Sebastian Andrzej Siewior wrote: On 2016-12-21 08:33:03 [+0800], Qu Wenruo wrote: The trace point only uses the pointer, and this helps us to pair with btrfs_work_queued/sched. | /* For situiations that the work is freed */ | DECLARE_EVENT_CLASS(btrfs__work__done

Re: [PATCH 1/2] btrfs: drop trace_btrfs_all_work_done() from normal_work_helper()

At 12/21/2016 01:26 AM, David Sterba wrote: Adding Qu to CC, On Wed, Dec 14, 2016 at 03:05:29PM +0100, Sebastian Andrzej Siewior wrote: For btrfs_scrubparity_helper() the ->func() is set to scrub_parity_bio_endio_worker(). This functions invokes scrub_free_parity() which kfrees() the `work'

Re: [PATCH 1/2] btrfs: drop trace_btrfs_all_work_done() from normal_work_helper()

At 12/21/2016 01:26 AM, David Sterba wrote: Adding Qu to CC, On Wed, Dec 14, 2016 at 03:05:29PM +0100, Sebastian Andrzej Siewior wrote: For btrfs_scrubparity_helper() the ->func() is set to scrub_parity_bio_endio_worker(). This functions invokes scrub_free_parity() which kfrees() the `work'

Re: [PATCH] f2fs: support multiple devices

At 11/10/2016 06:57 AM, Andreas Dilger wrote: On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote: This patch implements multiple devices support for f2fs. Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big volume under one f2fs instance. Internal block

Re: [PATCH] f2fs: support multiple devices

At 11/10/2016 06:57 AM, Andreas Dilger wrote: On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote: This patch implements multiple devices support for f2fs. Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big volume under one f2fs instance. Internal block management is very

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/05/2016 09:19 AM, Zhao Lei wrote: > Hi, Sean Fu > >> From: Sean Fu [mailto:fxinr...@gmail.com] >> Sent: Sunday, September 04, 2016 7:54 PM >> To: dste...@suse.com >> Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; >> zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org; >>

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/05/2016 09:19 AM, Zhao Lei wrote: > Hi, Sean Fu > >> From: Sean Fu [mailto:fxinr...@gmail.com] >> Sent: Sunday, September 04, 2016 7:54 PM >> To: dste...@suse.com >> Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; >> zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org; >>

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/07/2016 09:38 AM, Sean Fu wrote: On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote: At 09/05/2016 09:19 AM, Zhao Lei wrote: Hi, Sean Fu From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com; anand.j

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/07/2016 09:38 AM, Sean Fu wrote: On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote: At 09/05/2016 09:19 AM, Zhao Lei wrote: Hi, Sean Fu From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com; anand.j

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/05/2016 09:19 AM, Zhao Lei wrote: Hi, Sean Fu From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org;

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

At 09/05/2016 09:19 AM, Zhao Lei wrote: Hi, Sean Fu From: Sean Fu [mailto:fxinr...@gmail.com] Sent: Sunday, September 04, 2016 7:54 PM To: dste...@suse.com Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com; zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org;

Re: use-after-free in perf_trace_btrfs__work

Chris Mason wrote on 2016/01/21 12:06 -0500: On Thu, Jan 14, 2016 at 10:07:31PM -0500, Dave Jones wrote: I just hit a bunch of instances of this spew.. This is on Linus' tree from a few hours ago == BUG: KASAN: use-after-free in

Re: use-after-free in perf_trace_btrfs__work

Chris Mason wrote on 2016/01/21 12:06 -0500: On Thu, Jan 14, 2016 at 10:07:31PM -0500, Dave Jones wrote: I just hit a bunch of instances of this spew.. This is on Linus' tree from a few hours ago == BUG: KASAN: use-after-free in

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

David Sterba wrote on 2015/12/30 17:17 +0100: On Wed, Dec 30, 2015 at 10:10:44PM +0800, Qu Wenruo wrote: Now I am on the same side of David. Which means a runtime interface to change them. (along with mkfs option) If provide some configurable features, then it should be able to be tuned

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

On 12/30/2015 05:54 PM, Sanidhya Solanki wrote: On Wed, 30 Dec 2015 19:59:16 +0800 Qu Wenruo wrote: Not really sure about the difference between 2 and 3. I should have made it clear before, I was asking the exact use case in mind when listing the choices. Option 2 would be for SysAdmins

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

On 12/30/2015 02:39 PM, Sanidhya Solanki wrote: On Tue, 29 Dec 2015 18:06:11 +0100 David Sterba wrote: So you want to make the stripe size configurable?... As I see it there are 3 ways to do it: -Make it a compile time option that only configures it for a single system with any devices

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

David Sterba wrote on 2015/12/30 17:17 +0100: On Wed, Dec 30, 2015 at 10:10:44PM +0800, Qu Wenruo wrote: Now I am on the same side of David. Which means a runtime interface to change them. (along with mkfs option) If provide some configurable features, then it should be able to be tuned

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

On 12/30/2015 05:54 PM, Sanidhya Solanki wrote: On Wed, 30 Dec 2015 19:59:16 +0800 Qu Wenruo <quwenruo.bt...@gmx.com> wrote: Not really sure about the difference between 2 and 3. I should have made it clear before, I was asking the exact use case in mind when listing the choices. Op

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

On 12/30/2015 02:39 PM, Sanidhya Solanki wrote: On Tue, 29 Dec 2015 18:06:11 +0100 David Sterba wrote: So you want to make the stripe size configurable?... As I see it there are 3 ways to do it: -Make it a compile time option that only configures it for a single system

Re: [PATCH] btrfs: Remove unneeded cast to s64 for qgroup rfer state

Alexandru Moise wrote on 2015/08/31 09:32 +0300: On Mon, Aug 31, 2015 at 09:44:49AM +0800, Qu Wenruo wrote: >From the perspective of users, qgroup's referenced or exclusive is negative,but user can not continue to write data! a workaround way is to cast u64 to s64 when do

Re: [PATCH] btrfs: Remove unneeded cast to s64 for qgroup rfer state

Alexandru Moise wrote on 2015/08/31 09:32 +0300: On Mon, Aug 31, 2015 at 09:44:49AM +0800, Qu Wenruo wrote: >From the perspective of users, qgroup's referenced or exclusive is negative,but user can not continue to write data! a workaround way is to cast u64 to s64 when do

Re: [PATCH] btrfs: Remove unneeded cast to s64 for qgroup rfer state

Alexandru Moise wrote on 2015/08/29 11:45 +: This patch reverts commit: b4fcd6be6bbd702ae1a6545c9b413681850a9814 Wang Shilong added those casts as a workaround for a bug reproduced using the following steps: Steps to reproduce: mkfs.btrfs mount dd if=/dev/zero

Re: [PATCH] btrfs: Remove unneeded cast to s64 for qgroup rfer state

Alexandru Moise wrote on 2015/08/29 11:45 +: This patch reverts commit: b4fcd6be6bbd702ae1a6545c9b413681850a9814 Wang Shilong added those casts as a workaround for a bug reproduced using the following steps: Steps to reproduce: mkfs.btrfs disk mount disk mnt dd

Re: [PATCH v2 0/6] Btrfs: show subvolume name and ID in /proc/mounts

Original Message Subject: Re: [PATCH v2 0/6] Btrfs: show subvolume name and ID in /proc/mounts From: Omar Sandoval To: David Sterba , Qu Wenruo , Date: 2015年05月11日 17:42 On Thu, Apr 09, 2015 at 02:34:50PM -0700, Omar Sandoval wrote: Here's version 2 of providing

Re: [PATCH v2 0/6] Btrfs: show subvolume name and ID in /proc/mounts

Original Message Subject: Re: [PATCH v2 0/6] Btrfs: show subvolume name and ID in /proc/mounts From: Omar Sandoval osan...@osandov.com To: David Sterba dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com, linux-bt...@vger.kernel.org Date: 2015年05月11日 17:42 On Thu, Apr 09

Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting

Original Message Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting From: Omar Sandoval To: Qu Wenruo Date: 2015年04月08日 15:17 On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote: Original Message Subject: [PATCH 2/3] Btrfs

Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting

Original Message Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting From: Omar Sandoval To: Chris Mason , Josef Bacik , David Sterba , Date: 2015年04月08日 13:34 Currently, mounting a subvolume with subvolid= takes a different code path than mounting with

Re: [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts

Original Message Subject: [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts From: Omar Sandoval To: Chris Mason , Josef Bacik , David Sterba , Date: 2015年04月08日 13:34 Currently, userspace has no way to know which subvolume is mounted.But, now that we're

Re: [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts

Original Message Subject: [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts From: Omar Sandoval osan...@osandov.com To: Chris Mason c...@fb.com, Josef Bacik jba...@fb.com, David Sterba dste...@suse.cz, linux-bt...@vger.kernel.org Date: 2015年04月08日 13:34

Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting

Original Message Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting From: Omar Sandoval osan...@osandov.com To: Chris Mason c...@fb.com, Josef Bacik jba...@fb.com, David Sterba dste...@suse.cz, linux-bt...@vger.kernel.org Date: 2015年04月08日 13:34 Currently,

Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting

Original Message Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting From: Omar Sandoval osan...@osandov.com To: Qu Wenruo quwen...@cn.fujitsu.com Date: 2015年04月08日 15:17 On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote: Original

  1   2   >