Re: [PATCH v15 6/7] ext4: disable map_sync for async flush

; > Signed-off-by: Pankaj Gupta > Reviewed-by: Jan Kara Acked-by: Theodore Ts'o ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v5 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote: > > > ### But wait! Doesn't kselftest support in kernel testing?! > > > > > > > > I think I commented on this before. I agree with the statement that > there is no overlap between Kselftest and KUnit. I would like see this > removed.

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > However, the reply is incorrect. Kselftest in-kernel tests (which > is the context here) can be configured as built in instead of as > a module, and built in a UML kernel. The UML kernel can boot, > running the in-kernel tests

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 10:11:01PM -0700, Frank Rowand wrote: > >> You *can* run in-kernel test using modules; but there is no framework > >> for the in-kernel code found in the test modules, which means each of > >> the in-kernel code has to create their own in-kernel test > >> infrastructure. >

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 05:40:48PM -0600, Logan Gunthorpe wrote: > > Based on some of the other commenters, I was under the impression that > kselftests had in-kernel tests but I'm not sure where or if they exist. If > they do exists, it seems like it would make sense to convert those to kunit >

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote: > > The second item, arguably, does have significant overlap with kselftest. > Whether you are running short tests in a light weight UML environment or > higher level tests in an heavier VM the two could be using the same >

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand wrote: > >"My understanding is that the intent of KUnit is to avoid booting a kernel > on >real hardware or in a virtual machine. That seems to be a matter of > semantics >to me because isn't invoking a UML Linux just running

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote: > 1) Tests that exercises typically algorithmic or intricate, complex >code with relatively few outside dependencies, or where the dependencies >are considered worth mocking, such as the basics of container data >structures

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Wed, May 08, 2019 at 07:13:59PM -0700, Frank Rowand wrote: > > If you want to use vice grips as a hammer, screwdriver, monkey wrench, > > etc. there's nothing stopping you from doing that. But it's not fair > > to object to other people who might want to use better tools. > > > > The reality

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Wed, May 08, 2019 at 05:43:35PM -0700, Frank Rowand wrote: > kselftest provides a mechanism for in-kernel tests via modules. For > example, see: > > tools/testing/selftests/vm/run_vmtests invokes: > tools/testing/selftests/vm/test_vmalloc.sh > loads module: > test_vmalloc

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote: > > If KUnit is added to the kernel, and a subsystem that I am submitting > code for has chosen to use KUnit instead of kselftest, then yes, I do > *have* to use KUnit if my submission needs to contain a test for the > code unless I

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

On Tue, May 07, 2019 at 10:01:19AM +0200, Greg KH wrote: > > My understanding is that the intent of KUnit is to avoid booting a kernel on > > real hardware or in a virtual machine. That seems to be a matter of > > semantics > > to me because isn't invoking a UML Linux just running the Linux

Re: [PATCH 2/2] ext4: Fix ENOSPC handling in DAX page fault handler

On Wed, Jan 03, 2018 at 11:08:44AM +0100, Jan Kara wrote: > When allocation of underlying block for a page fault fails, we fail the > fault with SIGBUS. However we may well hit ENOSPC just due to lots of > free blocks being held by the running / committing transaction. So > propagate the error

Re: [PATCH 1/2] dax: Pass detailed error code from dax_iomap_fault()

On Wed, Jan 03, 2018 at 11:08:43AM +0100, Jan Kara wrote: > Ext4 needs to pass through error from its iomap handler to the page > fault handler so that it can properly detect ENOSPC and force > transaction commit and retry the fault (and block allocation). Add > argument to dax_iomap_fault() for

Re: [PATCH v2 5/5] ext4: remove duplicate extended attributes defs

uot;) > > so all the definitions needed by ext4 are available in > include/uapi/linux/fs.h. Remove the duplicates from ext4.h. > > Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> > Reviewed-by: Jan Kara <j...@suse.cz> > Cc: Li Xi <l...@ddn.com> >

Re: [PATCH v2 4/5] ext4: add ext4_should_use_dax()

On Tue, Sep 12, 2017 at 08:46:12AM +0200, Jan Kara wrote: > On Mon 11-09-17 23:05:25, Ross Zwisler wrote: > > This helper, in the spirit of ext4_should_dioread_nolock() et al., replaces > > the complex conditional in ext4_set_inode_flags(). > > > > Signed-off-by: Ross Zwisler

Re: [PATCH v2 2/5] ext4: prevent data corruption with journaling + DAX

On Mon, Sep 11, 2017 at 11:05:23PM -0600, Ross Zwisler wrote: > The current code has the potential for data corruption when changing an > inode's journaling mode, as that can result in a subsequent unsafe change > in S_DAX. > > I've captured an instance of this data corruption in the following

Re: [PATCH v2 1/5] ext4: prevent data corruption with inline data + DAX

On Mon, Sep 11, 2017 at 11:05:22PM -0600, Ross Zwisler wrote: > If an inode has inline data it is currently prevented from using DAX by a > check in ext4_set_inode_flags(). When the inode grows inline data via > ext4_create_inline_data() or removes its inline data via >

Re: [PATCH 0/9] add ext4 per-inode DAX flag

On Fri, Sep 08, 2017 at 09:25:43AM +1000, Dave Chinner wrote: > > Okay, so other ideas (which you have also probably already though of) > > include: > > > > 1) Just return -EBUSY if anyone tries to change the DAX flag of an inode > > with > > open mappings or any open file handles. > > You

Re: [PATCH v3] Fix ext4 fault handling when mounted with -o dax,ro

On Thu, Aug 24, 2017 at 09:01:44AM -0700, Christoph Hellwig wrote: > > We really need to do the same for ext2 and xfs. And we really should > be doing that in common VM code instead of the file system. See > my recent xfs synchronous page fault series on the mess the inconsistent > handling of

Re: [PATCH v3] Fix ext4 fault handling when mounted with -o dax,ro

On Wed, Aug 23, 2017 at 02:26:52PM -0700, rdod...@gmail.com wrote: > From: Randy Dodgen > > If an ext4 filesystem is mounted with both the DAX and read-only > options, executables on that filesystem will fail to start (claiming > 'Segmentation fault') due to the fault handler

Re: question about ext4 block allocation

On Thu, Feb 09, 2017 at 10:52:28AM -0700, Ross Zwisler wrote: > I've pared down his xfstest to be a pretty minimal reproducer, and you can > find it here: > > https://git.kernel.org/cgit/linux/kernel/git/zwisler/xfstests-dev.git/log/?h=ext4_PMD_allocation I'm getting "No repositories found".

Re: [PATCH 2/2] dax: assert that i_rwsem is held exclusive for writes

On Wed, Jan 11, 2017 at 10:02:50AM +0100, Jan Kara wrote: > On Tue 10-01-17 16:48:08, Christoph Hellwig wrote: > > Make sure all callers follow the same locking protocol, given that DAX > > transparantly replaced the normal buffered I/O path. > > > > Signed-off-by: Christoph Hellwig

Re: [PATCH 1/2] ext4: fix DAX write locking

On Wed, Jan 11, 2017 at 10:01:36AM +0100, Jan Kara wrote: > On Tue 10-01-17 16:48:07, Christoph Hellwig wrote: > > Unlike O_DIRECT DAX is not an optional opt-in feature selected by the > > application, so we'll have to provide the traditional synchronіzation > > of overlapping writes as we do for

Re: [PATCH 1/2] ext4: fix DAX write locking

On Wed, Feb 08, 2017 at 09:14:10AM -0800, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 10:01:36AM +0100, Jan Kara wrote: > > On Tue 10-01-17 16:48:07, Christoph Hellwig wrote: > > > Unlike O_DIRECT DAX is not an optional opt-in feature selected by the > > > application, so we'll have to

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Fri, Nov 25, 2016 at 11:51:26AM -0800, Linus Torvalds wrote: > We do have filesystem code that is just disgusting. As an example: > fs/afs/ tends to have these crazy "_enter()/_exit()" macros in every > single function. If you want that, use the function tracer. That seems > to be just

Re: [PATCH 0/11] ext4: Convert ext4 DAX IO to iomap framework

On Wed, Nov 02, 2016 at 12:09:03AM +0100, Jan Kara wrote: > > > I plan to grab Ross's PMD series in the next couple of days and I'll > > > push it out as a stable topic branch once I've sanity tested it. I > > > don't really want to take a big chunk of ext4 stuff through the XFS > > > tree if it

Re: [PATCH v2 1/9] ext4: allow DAX writeback for hole punch

On Wed, Sep 21, 2016 at 09:22:44AM -0600, Ross Zwisler wrote: > > Ted & Jan, > > I'm still working on the latest version of the PMD work which integrates with > the new struct iomap faults. At this point it doesn't look like I'm going to > make v4.9, but I think that this bug fix at least

Re: DAX can not work on virtual nvdimm device

On Fri, Sep 09, 2016 at 11:19:25AM +0200, Jan Kara wrote: > > > > > 1. make the guest kernel based on your tree, the top commit is > > > > >10d7902fa0e82b (dax: unmap/truncate on device shutdown) and > > > > >the config file can be found in this thread. What git tree is 10d7902fa0e82b