Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Tue, Mar 20, 2018 at 7:29 AM, Linus Torvalds wrote: > On Mon, Mar 19, 2018 at 2:43 AM, David Laight wrote: >> >> Is it necessary to have the full checks for old versions of gcc? >> >> Even -Wvla could be predicated on very recent gcc -

[PATCH] btrfs: qgroups: remove unused label

ng EDQUOT"") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- fs/btrfs/qgroup.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index de3b96f1005b..2b89848e767d 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -2429,7 +2429,6 @@

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

On Thu, Dec 7, 2017 at 1:32 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 2017年12月06日 22:18, Arnd Bergmann wrote: >> The return value of sizeof() is of type size_t, so we must print it >> using the %z format modifier rather than %l to avoid this warning >>

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

unsigned int', but argument 5 has type 'u32' {aka 'unsigned int'} [-Werror=format=] Fixes: 005887f2e3e0 ("btrfs: tree-checker: Add checker for dir item") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- fs/btrfs/tree-checker.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: next/master build: 214 builds: 29 failed, 185 passed, 29 errors, 68 warnings (next-20171016)

On Tue, Oct 17, 2017 at 1:02 AM, kernelci.org bot wrote: > > next/master build: 214 builds: 29 failed, 185 passed, 29 errors, 68 warnings > (next-20171016) > Full Build Summary: > https://kernelci.org/build/next/branch/master/kernel/next-20171016/ > Tree: next > Branch:

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

the format string to use %zu instead of %lu for size_t. Fixes: c1f6520bf360 ("btrfs: tree-checker: Enhance output for check_extent_data_item") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- fs/btrfs/tree-checker.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

On Fri, Jun 2, 2017 at 2:18 PM, Yan, Zheng <uker...@gmail.com> wrote: > On Fri, Jun 2, 2017 at 7:33 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Fri, Jun 2, 2017 at 1:18 PM, Yan, Zheng <uker...@gmail.com> wrote: >> What I meant is another related problem in

Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

On Fri, Jun 2, 2017 at 1:18 PM, Yan, Zheng <uker...@gmail.com> wrote: > On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <uker...@gmail.com> wrote: >>> On Fri, Jun 2, 2017 at 5:45 PM,

Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <uker...@gmail.com> wrote: > On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <uker...@gmail.com> wrote: >>> On Fri, Jun 2, 2017 at 8:57 AM, De

Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

26 PM, Yan, Zheng <uker...@gmail.com> wrote: >>>> On Thu, Jun 1, 2017 at 6:22 PM, Arnd Bergmann <a...@arndb.de> wrote: >>>>> On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng <uker...@gmail.com> wrote: >>>>>> On Sat, Apr 8, 2017 at 8:57 AM, Deep

Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng wrote: > On Sat, Apr 8, 2017 at 8:57 AM, Deepa Dinamani wrote: >> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c >> index 517838b..77204da 100644 >> --- a/drivers/block/rbd.c >> +++

Re: [PATCH] Btrfs: work around maybe-uninitialized warning

On Fri, May 19, 2017 at 8:10 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, May 18, 2017 at 03:33:29PM +0200, Arnd Bergmann wrote: >> A rewrite of btrfs_submit_direct_hook appears to have introduced a warning: >> >> fs/btrfs/inode.c: In function 'btrfs_submit_direct

[PATCH] Btrfs: work around maybe-uninitialized warning

ys be entered at least once. Fixes: 0fd27e06c61b ("Btrfs: use bio_clone_bioset_partial to simplify DIO submit") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- --- fs/btrfs/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btr

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

On Sat, Apr 8, 2017 at 5:58 PM, Deepa Dinamani wrote: >> I have no problem merging this patch into audit/next for v4.12, would >> you prefer me to do that so at least this patch is merged? > > This would be fine. > But, I think whoever takes the last 2 deletion patches

[PATCH] btrfs: fix uninitialized variable access after ASSERT

false enospc for compression") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- fs/btrfs/inode.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e6f35d923d67..b1d2b38d29aa 100644 --- a/fs/btrfs/inode.c +++ b/

Re: [GIT PULL] [PATCH v4 00/26] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Monday, August 15, 2016 6:23:12 PM CEST Greg KH wrote: > On Sat, Aug 13, 2016 at 03:48:12PM -0700, Deepa Dinamani wrote: > > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > > macros. > > The macros are not y2038 safe. There is no plan to transition them into > >

Re: [Y2038] [PATCH v3 00/24] Delete CURRENT_TIME_SEC and replace current_fs_time()

; y2038 safe. > ktime_get_* api's can be used in their place. And, these are y2038 safe. > > CURRENT_TIME will be deleted after 4.8 rc1 as there is a dependency function > time64_to_tm() for one of the CURRENT_TIME occurance. > > Thanks to Arnd Bergmann for all the guidance and disc

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

in their place. And, these are y2038 safe. > > Thanks to Arnd Bergmann for all the guidance and discussions. > > Patches 2-4 were mostly generated using coccinelle scripts. > > All filesystem timestamps use current_fs_time() for right granularity as > mentioned in the respecti

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Monday, June 20, 2016 11:03:01 AM CEST you wrote: > On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani > wrote: > > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > > macros. > Gcc handles 8-byte structure returns (on most architectures) by >

[PATCH] btrfs: avoid uninitialized variable warning

initialization. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: 47dc196ae719 ("btrfs: use proper type for failrec in extent_state") --- fs/btrfs/extent_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 27577f1b10

[PATCH] btrfs: fix size_t format string

is the same length as unsigned long, but the compiler does not know this, and warns about potentially unportable code here. The correct printf string for size_t is %z. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: ce7fca5f57ed0f btrfs: add checks for sys_chunk_array sizes Cc: David Sterba dste

[PATCH] Btrfs: avoid build warning on 32-bit

: cast to pointer from integer of different size [-Wint-to-pointer-cast] This adds an intermediate cast to 'unsigned long', which tells the compiler to ignore the type mismatch. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: f612496bca664 (Btrfs: cleanup the read failure record after write

ENOSPC on mostly empty file system

Hi Chris, As I mentioned at the kernel summit, I have a file system that I use mostly for storing my one kernel git tree and occasionally some build trees (those are normally on a tmpfs), and I have again run into the problem where the file system is only partially full (I think 18% in this case)

Re: ENOSPC on mostly empty file system

On Tuesday 09 September 2014 16:29:05 Arnd Bergmann wrote: I also played around with it some more. After removing a few small files, I could create new files with up to 20-60MB again before hitting ENOSPC. I then did a 'make clean' in all the object directories I had and after that could

Re: ENOSPC on mostly empty file system

On Tuesday 09 September 2014 21:49:12 Clemens Eisserer wrote: Hi Arnd, Ok, one more data point: Why don't you provide the data point you were specifically asked for, btrfs fi df ;) I've cleaned it up again already. At the moment, it's working fine, with this data: Data: total=65.11GB,

Re: ENOSPC on mostly empty file system

On Tuesday 09 September 2014 22:57:25 Hugo Mills wrote: On Tue, Sep 09, 2014 at 11:49:10PM +0200, Arnd Bergmann wrote: Ok, now I'm in the bad state again (after running a 'make allmodconfig' kernel build: Label: none uuid: 1d88cccb-3d0e-42d9-8252-a226dc5c2e47 Total devices 1

Re: [RFC 00/32] making inode time stamps y2038 ready

On Tuesday 03 June 2014, Dave Chinner wrote: On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote: On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote: On 06/02/2014 12:55 PM, Arnd Bergmann wrote: The possible uses I can see for non-ktime_t types in the kernel are: * inodes

Re: [RFC 00/32] making inode time stamps y2038 ready

On Monday 02 June 2014, Joseph S. Myers wrote: On Mon, 2 Jun 2014, Arnd Bergmann wrote: Ok. Sorry about missing linux-api, I confused it with linux-arch, which may not be as relevant here, except for the one question whether we actually want to have the new ABI on all 32-bit architectures

Re: [RFC 00/32] making inode time stamps y2038 ready

On Wednesday 04 June 2014 13:30:32 Nicolas Pitre wrote: On Wed, 4 Jun 2014, Arnd Bergmann wrote: On Tuesday 03 June 2014, Dave Chinner wrote: Just ot be pedantic, inodes don't need 96 bit timestamps - some filesystems can *support up to* 96 bit timestamps. If the kernel only supports

Re: [RFC 00/32] making inode time stamps y2038 ready

On Saturday 31 May 2014 18:30:49 Vyacheslav Dubeyko wrote: By the way, what about NILFS2? Is NILFS2 ready for suggested approach without any changes? nilfs2 and a lot of other file systems don't need any changes for this, because they don't assign the inode time stamp fields to a 'struct

Re: [RFC 00/32] making inode time stamps y2038 ready

On Tuesday 03 June 2014 14:33:10 Joseph S. Myers wrote: On Tue, 3 Jun 2014, Arnd Bergmann wrote: I think John Stultz and Thomas Gleixner have already started looking at how the timekeeping code can be updated. Once that is done, we should be able to add a functional 64-bit gettimeofday

Re: [RFC 00/32] making inode time stamps y2038 ready

On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote: On 06/02/2014 12:55 PM, Arnd Bergmann wrote: The bit that is really going to hurt is every single ioctl that uses a timespec. Honestly, though, I really don't understand the point with struct inode_time. It seems like the zeroeth

Re: [RFC 00/32] making inode time stamps y2038 ready

On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote: On Fri, 30 May 2014, Arnd Bergmann wrote: a) is this the right approach in general? The previous discussion pointed this way, but there may be other opinions. The syscall changes seem like the sort of thing I'd expect, although

Re: [RFC 00/32] making inode time stamps y2038 ready

On Monday 02 June 2014 12:26:22 H. Peter Anvin wrote: On 06/02/2014 12:19 PM, Arnd Bergmann wrote: On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote: On Fri, 30 May 2014, Arnd Bergmann wrote: a) is this the right approach in general? The previous discussion pointed this way

Re: [RFC 00/32] making inode time stamps y2038 ready

On Saturday 31 May 2014 16:51:15 Richard Cochran wrote: On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote: I picked this because it is a fairly isolated problem, as the inode time stamps are rarely assigned to any other time values. As a byproduct of this work, I documented

[RFC 12/32] btrfs: convert to struct inode_time

-by: Arnd Bergmann a...@arndb.de Cc: Chris Mason c...@fb.com Cc: Josef Bacik jba...@fb.com Cc: linux-btrfs@vger.kernel.org --- fs/btrfs/file.c| 6 +++--- fs/btrfs/inode.c | 4 ++-- fs/btrfs/ioctl.c | 4 ++-- fs/btrfs/root-tree.c | 2 +- fs/btrfs/transaction.c | 2 +- 5 files

Re: Oops when mounting btrfs partition

On Friday 08 February 2013, David Sterba wrote: On Mon, Feb 04, 2013 at 09:55:50PM +, Arnd Bergmann wrote: On Saturday 02 February 2013, Chris Mason wrote: I've done a full backup of all data now, without any further Ooops messages, but I did get these: [66155.429029] btrfs

Re: Oops when mounting btrfs partition

On Saturday 02 February 2013, Chris Mason wrote: Feb 1 22:57:37 localhost kernel: [ 8561.599482] Kernel BUG at a01fdcf7 [verbose debug info unavailable] Jan 14 19:18:42 localhost kernel: [1060055.746373] btrfs csum failed ino 15619835 off 454656 csum 2755731641 private

Oops when mounting btrfs partition

As mentioned on Google+, I have a partition that I can no longer mount normally, containing a lot of my personal data and all backups from my laptop. I found now that I am still able to mount it using the 'nospace_cache' option, but it takes a couple of minutes and I get INFO: task

Re: Oops when mounting btrfs partition

On Saturday 02 February 2013 10:20:35 Chris Mason wrote: Hi Arnd, First things first, nospace_cache is a safe thing to use. It is slow because it's finding free extents, but it's just a cache and always safe to discard. With your other errors, I'd just mount it readonly and then you won't

Re: [PATCH 0/3] Update LZO compression

the file was renamed, anything including it needs to be updated to the new file name. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c index 4531294..960183d 100644 --- a/lib/decompress_unlzo.c +++ b/lib/decompress_unlzo.c @@ -31,7 +31,7

Re: [PATCH v2 1/5] add metadata_incore ioctl in vfs

in specific approach. Next patch will give an example how to implement .metadata_incore in btrfs. Signed-off-by: Shaohua Li shaohua...@intel.com Looks great! Reviewed-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body

Re: [PATCH v2 3/5]add metadata_readahead ioctl in vfs

-off-by: Shaohua Li shaohua...@intel.com Reviewed-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/5]add metadata_readahead ioctl in vfs

On Wednesday 05 January 2011 03:11:36 Shaohua Li wrote: Did you notice the comment above the function? ;-) You should really add the new ioctls to compat_sys_ioctl, not to the COMPATIBLE_IOCTL() list, in order to make the behavior consistent between 32 and 64 bit user space. The main

Re: [PATCH v2 3/5]add metadata_readahead ioctl in vfs

On Wednesday 05 January 2011 10:09:20 Arnd Bergmann wrote: Thanks, fixed them. The patch you posted still uses COMPATIBLE_IOCTL. Wrong patch? On a second look, I noticed that you now have both the COMPATIBLE_IOCTL and the case statement in compat_sys_ioctl. The former can be dropped

Re: [PATCH v2 1/5] add metadata_incore ioctl in vfs

On Wednesday 05 January 2011 03:17:16 Shaohua Li wrote: On Tue, 2011-01-04 at 17:40 +0800, Arnd Bergmann wrote: Have you tried passing just a single metadata_incore_ent at the ioctl and looping in user space? I would guess the extra overhead of that would be small enough, but that might

Re: [PATCH v2 1/5] add metadata_incore ioctl in vfs

On Thursday 06 January 2011, Shaohua Li wrote: I don't understand. adding a case statement in compat_sys_ioctl, so we will do compat_ioctl_check_table(). If I add COMPATIBLE_IOCTL(), then the check will success, we will go to the found_handler code path and execute do_vfs_ioctl, which is what

Re: [PATCH v2 1/5] add metadata_incore ioctl in vfs

On Tuesday 04 January 2011 06:40:32 Shaohua Li wrote: +static int ioctl_metadata_incore(struct file *filp, void __user *argp) +{ + struct super_block *sb = filp-f_path.dentry-d_inode-i_sb; + struct metadata_incore_args args; + struct metadata_incore_ent ent; + loff_t

Re: Btrfs for mainline

On Saturday 03 January 2009, Chris Mason wrote: Actually a lot of the ioctl API don't just need documentation but a complete redo.  That's true at least for the physical device management and subvolume / snaphot ones. The ioctl interface is definitely not finalized.  Adding more vs