There is no chance to get into -ERANGE error condition because
we first call btrfs_getxattr to get the length of the attribute,
then we do a subsequent call with the size from the first call.
Between the 2 calls the size shouldn't change. So remove the
unnecessary -ERANGE error check.
Signed-off-b
It's only coding style fix not functinal change.
When if/else has only one statement then the bracket
is not needed.
Signed-off-by: Chengguang Xu
Reviewed-by: Nikolay Borisov
---
v4:
- Split patch to series.
v3:
- Fix some toher bad practices.
- Add more information to commit log.
v2:
- Avoid
It's no good to override error code when failing from
btrfs_getxattr() in btrfs_get_acl() because it will hide
real root cause.
Signed-off-by: Chengguang Xu
Reviewed-by: Nikolay Borisov
---
v4:
- Split patch to series.
v3:
- Fix some toher bad practices.
- Add more information to commit log.
v
The caller of btrfs_get_acl() checks error condition so there is no
impact from this change. In practice there is no chance to get into
default case of switch statement because VFS has already checked
the type.
Signed-off-by: Chengguang Xu
Reviewed-by: Nikolay Borisov
---
v4:
- Split patch to se
In btrfs_get_acl() the first call of btr_getxattr() is for getting
the length of attribute, the value buffer is never used in this
case. So it's better to replace empty string with NULL.
Signed-off-by: Chengguang Xu
Reviewed-by: Nikolay Borisov
---
v4:
- Split patch to series.
v3:
- Fix some to
This patch set does code cleanups for btrfs_get_acl().
Chengguang Xu (5):
btrfs: return error instead of crash when detecting unexpected type in
btrfs_get_acl()
btrfs: replace empty string with NULL when getting attribute length in
btrfs_get_acl()
btrfs: remove unnecessary -ERANGE ch
On Tue, Jun 26, 2018 at 09:25:22PM +0300, Eugene Bright wrote:
>Greetings!
>
>I've found one more mailing list archive.
>I do not have wiki access, so could someone else add one more link?
I have already added this link for you.
--
Thanks,
Lu
>
>Wiki page:
>https://btrfs.wiki.kernel.org/index.p
Greetings!
I've found one more mailing list archive.
I do not have wiki access, so could someone else add one more link?
Wiki page:
https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list
Additional archive link:
https://www.spinics.net/lists/linux-btrfs/
Thanks!
signature.asc
Description:
Hi Nikolay,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180626]
[cannot apply to btrfs/next v4.18-rc2 v4.18-rc1 v4.17 v4.18-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Mon, Jun 25, 2018 at 10:03:41AM -0700, Chris Mason wrote:
> The vm_fault_t conversion commit introduced a ret2 variable for tracking
> the integer return values from internal btrfs functions. It was
> sometimes returning VM_FAULT_LOCKED for pages that were actually invalid
> and had been remove
On Wed, Jun 27, 2018 at 12:05:39AM +0800, kbuild test robot wrote:
> Hi Nikolay,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on next-20180626]
> [cannot apply to btrfs/next v4.18-rc2 v4.18-rc1 v4.17 v4.18-rc2]
> [if your patch is app
On Tue, Jun 26, 2018 at 02:08:27PM +0800, Chengguang Xu wrote:
> There is no chance to get into -ERANGE error condition because
> we first call btrfs_getxattr to get the length of the attribute,
> then we do a subsequent call with the size from the first call.
> Between the 2 calls the size shouldn
Hi Nikolay,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180626]
[cannot apply to btrfs/next v4.18-rc2 v4.18-rc1 v4.17 v4.18-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On 26.06.2018 09:08, Chengguang Xu wrote:
> There is no chance to get into -ERANGE error condition because
> we first call btrfs_getxattr to get the length of the attribute,
> then we do a subsequent call with the size from the first call.
> Between the 2 calls the size shouldn't change. So remo
On Tue, Jun 26, 2018 at 05:31:40PM +0300, Nikolay Borisov wrote:
>
>
> On 26.06.2018 17:24, David Sterba wrote:
> > The v0 extent type checks are the right case for the unlikely
> > annotations as we don't expect to ever see them, so let's give the
> > compiler some hint.
> >
> > Signed-off-by:
On 06/26/2018 08:19 PM, David Sterba wrote:
On Tue, Jun 26, 2018 at 02:25:11PM +0800, Anand Jain wrote:
(sorry for the delay in reply due to my vacation and, other
urgent things took my priority too).
Please see inline below.
On 06/19/2018 09:53 PM, David Sterba wrote:
On Thu, Jun
On 26.06.2018 17:24, David Sterba wrote:
> The v0 extent type checks are the right case for the unlikely
> annotations as we don't expect to ever see them, so let's give the
> compiler some hint.
>
> Signed-off-by: David Sterba
The question is how helpful those unlikelies are in the generated
The v0 extent type checks are the right case for the unlikely
annotations as we don't expect to ever see them, so let's give the
compiler some hint.
Signed-off-by: David Sterba
---
fs/btrfs/extent-tree.c | 8
fs/btrfs/print-tree.c | 2 +-
fs/btrfs/relocation.c | 8
3 files ch
On Tue, Jun 26, 2018 at 04:57:36PM +0300, Nikolay Borisov wrote:
> Following the removal of the v0 handling code let's be courteous and
> print an error message when such extents are handled. In the cases
> where we have a transaction just abort it, otherwise just call
> btrfs_handle_fs_error. Both
On 25.06.2018 19:38, David Sterba wrote:
> There are several WARN_ON calls that catch incrorrect reference counter
> updates, but this is what the refcount_t does already:
>
> * refcount_inc from 0 will warn
> * refcount_dec_and_test from 0 will warn
>
But these warnings are only going to be
Following the removal of the v0 handling code let's be courteous and
print an error message when such extents are handled. In the cases
where we have a transaction just abort it, otherwise just call
btrfs_handle_fs_error. Both cases result in the FS being re-mounted RO.
Signed-off-by: Nikolay Bori
On Tue, Jun 26, 2018 at 02:25:11PM +0800, Anand Jain wrote:
>
>
> (sorry for the delay in reply due to my vacation and, other
> urgent things took my priority too).
>
> Please see inline below.
>
> On 06/19/2018 09:53 PM, David Sterba wrote:
> > On Thu, Jun 07, 2018 at 06:39:32PM +0200, Dav
On 2018-06-25 21:05, Sterling Windmill wrote:
I am running a single btrfs RAID10 volume of eight LUKS devices, each
using a 2TB SATA hard drive as a backing store. The SATA drives are a
mixture of Seagate and Western Digital drives, some with RPMs ranging
from 5400 to 7200. Each seems to individu
On 06/21/2018 01:51 AM, David Sterba wrote:
Technically this extends the critical section covered by uuid_mutex to:
- parse early mount options -- here we can call device scan on paths
that can be passed as 'device=/dev/...'
- scan the device passed to mount
- open the devices related to
On 26.06.2018 11:46, Misono Tomohiro wrote:
> On 2018/06/26 16:09, Nikolay Borisov wrote:
>> Commit 5d23515be669 ("btrfs: Move qgroup rescan on quota enable to
>> btrfs_quota_enable") not only resulted in an easier to follow code but
>> it also introduced a subtle bug. It changed the timing when
On 2018/06/26 16:09, Nikolay Borisov wrote:
> Commit 5d23515be669 ("btrfs: Move qgroup rescan on quota enable to
> btrfs_quota_enable") not only resulted in an easier to follow code but
> it also introduced a subtle bug. It changed the timing when the initial
> transaction rescan was happening - be
On 06/21/2018 01:51 AM, David Sterba wrote:
The stale device list removal needs to be protected by device_list_mutex
too as this could delete from the list and could race with another list
modification and cause crash.
Its is very less likely or almost practically impossible (unless
instru
Commit 5d23515be669 ("btrfs: Move qgroup rescan on quota enable to
btrfs_quota_enable") not only resulted in an easier to follow code but
it also introduced a subtle bug. It changed the timing when the initial
transaction rescan was happening - before the commit it would happen
after transaction co
28 matches
Mail list logo
