t_user_page*() to
>implement tracking of these pages. This tracking will be separate from
>the existing struct page refcounting.
>
> 4) Use the tracking and identification of these pages, to implement
>special handling (especially in writeback paths) when the pages are
On Tue, Mar 12, 2019 at 05:38:55PM -0700, John Hubbard wrote:
> On 3/12/19 8:30 AM, Ira Weiny wrote:
> > On Wed, Mar 06, 2019 at 03:54:55PM -0800, john.hubb...@gmail.com wrote:
> > > From: John Hubbard
> > >
> > > Introduces put_user_page(), which simply cal
On Mon, Feb 04, 2019 at 05:14:19PM +, Christopher Lameter wrote:
> Frankly I still think this does not solve anything.
>
> Concurrent write access from two sources to a single page is simply wrong.
> You cannot make this right by allowing long term RDMA pins in a filesystem
> and thus the file
oblem is
still under discussion."
-- John Hubbard[2]
The following people have been involved in previous conversations and would be
key to
the face to face discussion.
John Hubbard
Jan Kara
Dave Chinner
Michal Hocko
Dan Williams
Matthew Wilcox
Jason Gunthorpe
Thank y
I had an old invalid address for Jason Gunthorpe in my address book...
Correcting his email in the thread.
On Tue, Feb 05, 2019 at 09:50:59AM -0800, 'Ira Weiny' wrote:
>
> The problem: Once we have pages marked as GUP-pinned how should various
> subsystems work with those
On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > On Mon, Apr 08, 2019 at 10:37:45AM +0800, Huang Shijie wrote:
> > > When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own
> > > get_user_pages_fast().
>
On Wed, Apr 10, 2019 at 09:20:36AM +0800, Huang Shijie wrote:
> On Tue, Apr 09, 2019 at 02:55:31PM +, Weiny, Ira wrote:
> > > On Tue, Apr 09, 2019 at 11:04:18AM +0800, Huang Shijie wrote:
> > > > On Mon, Apr 08, 2019 at 07:49:29PM -0700, Matthew Wilcox wrote:
> > > > > On Tue, Apr 09, 2019 at 0
On Wed, Apr 10, 2019 at 09:18:50AM +0800, Huang Shijie wrote:
> On Tue, Apr 09, 2019 at 01:23:16PM -0700, Ira Weiny wrote:
> > On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > >
On Tue, Feb 19, 2019 at 09:30:33PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series. I was anticipating these going through the mm tree as they
> depend on a cleanup patch the
On Thu, Feb 11, 2021 at 08:38:03PM +0100, David Sterba wrote:
> On Tue, Feb 09, 2021 at 10:22:13PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Per the conversation on V1 it looks like Andrew would like this to go
> > through
> > the btrfs
On Fri, Feb 12, 2021 at 10:38:10AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the btrfs tree got a conflict in:
>
> lib/iov_iter.c
>
> between commit:
>
> 11432a3cc061 ("iov_iter: Add ITER_XARRAY")
>
> from the fscache tree and commit:
>
> 325a835476e3 ("io
On Tue, Feb 23, 2021 at 09:13:42AM -0800, Linus Torvalds wrote:
> On Tue, Feb 23, 2021 at 7:03 AM David Sterba wrote:
> > Ira Weiny (8):
> > iov_iter: Remove memzero_page() in favor of zero_user()
>
> Ugh. I absolutely _detest_ this patch.
Sorry.
>
> &q
On Wed, Feb 24, 2021 at 01:30:49PM +0100, David Sterba wrote:
> On Tue, Feb 23, 2021 at 11:25:06AM -0800, Ira Weiny wrote:
> > On Tue, Feb 23, 2021 at 09:13:42AM -0800, Linus Torvalds wrote:
> > > On Tue, Feb 23, 2021 at 7:03 AM David Sterba wrote:
> [...]
>
>
From: Ira Weiny
Working through a conversion to a call kmap_local_page() instead of
kmap() revealed many places where the pattern kmap/memcpy/kunmap
occurred.
Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
Viro all suggested putting this code into helper functions. Al
From: Ira Weiny
kmap_local_page() is more efficient and is well suited for these calls.
Convert the kmap() to kmap_local_page()
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h | 8
1 file changed, 4 insertions(+), 4
From: Ira Weiny
zero_user() is already defined with the same interface and contains the
same code pattern as memzero_page(). Remove memzero_page() and use the
already defined common function zero_user()
To: Alexander Viro
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
From: Ira Weiny
Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
memory operations do not result in corrupted data in neighbor pages and
to make them consistent with zero_user().[1][2]
[1]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com
From: Ira Weiny
Changes from V1:
Rework commit messages because they were very weak
Change 'fs/btrfs: X' to 'btrfs: x'
https://lore.kernel.org/lkml/20210209151442.gu1...@suse.cz/
Per Andrew
Split out
From: Ira Weiny
3 more common kmap patterns are kmap/memcpy/kunmap, kmap/memmove/kunmap.
and kmap/memset/kunmap.
Add helper functions for those patterns which use kmap_local_page().
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h
From: Ira Weiny
There are many places where the pattern kmap/memcpy/kunmap occurs.
This pattern was lifted to the core common functions
memcpy_[to|from]_page().
Use these new functions to reduce the code, eliminate direct uses of
kmap, and leverage the new core functions use of kmap_local_page
From: Ira Weiny
There are many places where kmap/memove/kunmap patterns occur.
This pattern exists in the core common function copy_highpage().
Use copy_highpage to avoid open coding the use of kmap and leverages the
core functions use of kmap_local_page().
Development of this patch was aided
From: Ira Weiny
There are many places where kmap/memset/kunmap patterns occur.
This pattern exists in the core as zero_user()
Use zero_user() to eliminate direct uses of kmap and leverage the new
core functions use of kmap_local_page().
The development of this patch was aided by the following
On Wed, Feb 10, 2021 at 12:55:02PM +, Christoph Hellwig wrote:
> On Tue, Feb 09, 2021 at 10:22:17PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
> > memory operations do not
On Wed, Feb 10, 2021 at 06:57:30AM +, Chaitanya Kulkarni wrote:
> On 2/9/21 22:25, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
> > memory operations do not result in corrupted data i
On Wed, Feb 10, 2021 at 04:41:34PM +, Christoph Hellwig wrote:
> On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote:
> > On Wed, Feb 10, 2021 at 12:55:02PM +, Christoph Hellwig wrote:
> > > On Tue, Feb 09, 2021 at 10:22:17PM -0800, ira.we...@intel.com wrote:
>
From: Ira Weiny
Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
memory operations do not result in corrupted data in neighbor pages.[1][2]
[1]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com/
[2]
https://lore.kernel.org/lkml
On Wed, Feb 10, 2021 at 06:56:06PM +, Matthew Wilcox wrote:
> On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote:
> > And I thought it was a good idea. Any file system development should have
> > tests with DEBUG_VM which should cover Matthew's concern while
On Thu, Feb 04, 2021 at 01:02:53PM +0530, Prathu Baronia wrote:
> From: Ira Weiny
>
> kmap_atomic() is being deprecated in favor of kmap_local_page().
>
> Replace the uses of kmap_atomic() within the highmem code.
>
> On profiling clear_huge_page() using ftrace an imp
On Fri, Feb 12, 2021 at 02:04:44PM +1100, Stephen Rothwell wrote:
> Hi Ira,
>
> On Thu, 11 Feb 2021 17:07:41 -0800 Ira Weiny wrote:
> >
> > On Fri, Feb 12, 2021 at 10:38:10AM +1100, Stephen Rothwell wrote:
> > > from the fscache tree and commit:
> > >
From: Ira Weiny
kmap is inefficient and we are trying to reduce the usage in the kernel.
There is no readily apparent reason why initp_page needs to be allocated
and kmap'ed() but sigstruct needs to be page aligned and token
512 byte aligned.
kmalloc() can give us this alignment but we ne
-
>
> Malloc test timings for 100MB anon allocation:-
>
> Base data:-
> Number of iterations: 100
> Mean of allocation time: 31831 us
> std deviation: 4286 us
>
> v1 data:-
> Number of iterations: 100
> Mean of allocation tim
ee? If not who?
If you take the above patch I can drop it from the series I'm about to submit
to convert btrfs kmaps.
Ira
>Regards,
>Prathu Baronia
>
> On Wed, Feb 3, 2021 at 1:33 AM Ira Weiny <[2]ira.we...@intel.com> wrote:
>
> On Tue, F
From: Ira Weiny
In dump_user_range() there is no reason for the mapping to be global.
Use kmap_local_page() rather than kmap.
Cc: Andrew Morton
Cc: linux-kernel@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Ira Weiny
---
fs/coredump.c | 4 ++--
1 file changed, 2 insertions
From: Ira Weiny
There is no reason to alloc a page and kmap it to store this temporary
data from the user. This is especially true when we are trying to
remove kmap usages. Also placing the token pointer 1/2 way into the
page is fragile.
Replace this allocation with two kzalloc()'s which
From: Ira Weiny
kmap is inefficient and we are trying to reduce the usage in the kernel.
There is no readily apparent reason why the initp_page page needs to be
allocated and kmap'ed() but sigstruct needs to be page aligned and token
512 byte aligned.
In this case page_address() can be
On Thu, Feb 04, 2021 at 04:26:08PM +0100, David Sterba wrote:
> On Wed, Feb 03, 2021 at 04:56:48PM +0100, David Sterba wrote:
> > On Wed, Jan 27, 2021 at 10:15:03PM -0800, ira.we...@intel.com wrote:
> > > From: Ira Weiny
> > >
> > > When a qstripe is req
On Wed, Feb 03, 2021 at 12:45:33AM +0200, Jarkko Sakkinen wrote:
> On Tue, Feb 02, 2021 at 11:47:19AM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > kmap is inefficient and we are trying to reduce the usage in the kernel.
> > There is no readily app
On Fri, Feb 05, 2021 at 04:34:41PM +0100, David Sterba wrote:
> On Thu, Feb 04, 2021 at 07:52:36PM -0800, Ira Weiny wrote:
> > On Thu, Feb 04, 2021 at 04:26:08PM +0100, David Sterba wrote:
> > > On Wed, Feb 03, 2021 at 04:56:48PM +0100, David Sterba wrote:
> > > >
From: Ira Weiny
kmap is inefficient and we are trying to reduce the usage in the kernel.
There is no readily apparent reason why initp_page needs to be allocated
and kmap'ed() but sigstruct needs to be page aligned and token
512 byte aligned.
kmalloc() can give us this alignment but we ne
On Tue, Feb 09, 2021 at 04:11:23PM +0100, David Sterba wrote:
> On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > There are many places where kmap//kunmap patterns occur. We lift
> > these various patterns to core commo
On Tue, Feb 09, 2021 at 11:09:31AM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2021 16:11:23 +0100 David Sterba wrote:
>
> > On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.we...@intel.com wrote:
> > > From: Ira Weiny
> > >
> > > There are many places
On Tue, Feb 09, 2021 at 01:11:03PM -0800, Andrew Morton wrote:
> > >
> > > It would be best to merge [1/4] via the btrfs tree. Please add my
> > >
> > > Acked-by: Andrew Morton
> > >
> > >
> > > Although I think it would be better if [1/4] merely did the code
> > > movement. Adding those BUG
On Tue, Feb 09, 2021 at 01:58:37PM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2021 13:52:29 -0800 Ira Weiny wrote:
>
> > >
> > > Let's please queue this up separately.
> >
> > Ok can I retain your Ack on the move part of the patch?
>
>
On Thu, Feb 25, 2021 at 02:12:52PM +0100, David Sterba wrote:
> On Wed, Feb 24, 2021 at 09:59:12AM -0800, Ira Weiny wrote:
> > On Wed, Feb 24, 2021 at 01:30:49PM +0100, David Sterba wrote:
> > > On Tue, Feb 23, 2021 at 11:25:06AM -0800, Ira Weiny wrote:
> > > > On T
On Fri, Feb 26, 2021 at 03:23:40PM +0100, David Sterba wrote:
> On Thu, Feb 25, 2021 at 08:32:34AM -0800, Ira Weiny wrote:
> > On Thu, Feb 25, 2021 at 02:12:52PM +0100, David Sterba wrote:
> > > On Wed, Feb 24, 2021 at 09:59:12AM -0800, Ira Weiny wrote:
> > > > On W
On Fri, May 29, 2020 at 11:42:57AM +0800, Shuai He wrote:
> Use kobj_to_dev() API instead of container_of().
>
> Signed-off-by: Shuai He
Seems reasonable:
Reviewed-by: Ira Weiny
> ---
> drivers/dax/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
ing
> > it and partially reverting the next cleanup commits makes those
> > dissapear. sparc32 boot still fails on today's linux-next and mmotm for me
> > with
> >
> > Run /sbin/init as init process
> > with arguments:
> > /sbin/init
> >
On Sun, May 17, 2020 at 10:37:22AM -0700, Guenter Roeck wrote:
> Hi,
>
> On Thu, May 07, 2020 at 07:59:58AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > To support kmap_atomic_prot(), all architectures need to support
> > protections passed to
On Mon, May 18, 2020 at 11:09:46AM -0700, Guenter Roeck wrote:
> On 5/18/20 7:23 AM, Mike Rapoport wrote:
> > On Mon, May 18, 2020 at 02:48:18AM -0700, Guenter Roeck wrote:
> >> On 5/18/20 1:37 AM, Will Deacon wrote:
> >>> On Sat, May 16, 2020 at 05:07:50PM -0700, Guenter Roeck wrote:
> On Sat
From: Ira Weiny
The kunmap_atomic clean up failed to remove one set of pagefault/preempt
enables when vaddr is not in the fixmap.
Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
Signed-off-by: Ira Weiny
---
arch/microblaze/mm/highmem.c | 5 +
arch/mips/mm
On Mon, May 18, 2020 at 09:24:47AM -0700, Eric Biggers wrote:
> On Sun, May 17, 2020 at 10:03:15PM -0700, Ira Weiny wrote:
> > On Fri, May 15, 2020 at 07:02:53PM -0700, Eric Biggers wrote:
> > > On Tue, May 12, 2020 at 10:43:18PM -0700, ira.we...@intel.com wrote:
>
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
>
On Mon, May 18, 2020 at 07:50:36PM -0700, Guenter Roeck wrote:
> Hi Ira,
>
> On 5/18/20 5:03 PM, Ira Weiny wrote:
> > On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> >> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> >>> On S
On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > enables when vaddr is not in
On Mon, May 18, 2020 at 09:24:47AM -0700, Eric Biggers wrote:
> On Sun, May 17, 2020 at 10:03:15PM -0700, Ira Weiny wrote:
First off... OMG...
I'm seeing some possible user pitfalls which are complicating things IMO. It
probably does not matter because most users don't care an
On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > > On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
>
On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > > On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
>
From: Ira Weiny
In prep for the new tri-state mount option which then introduces
EXT4_MOUNT_DAX_NEVER.
Reviewed-by: Jan Kara
Signed-off-by: Ira Weiny
---
Changes:
New patch
---
fs/ext4/ext4.h | 4 ++--
fs/ext4/inode.c | 2 +-
fs/ext4/super.c | 12 ++--
3 files changed, 9
From: Ira Weiny
Add a flag to preserve FS_XFLAG_DAX in the ext4 inode.
Set the flag to be user visible and changeable. Set the flag to be
inherited. Allow applications to change the flag at any time with the
exception of if VERITY or ENCRYPT is set.
Disallow setting VERITY or ENCRYPT if DAX
From: Ira Weiny
Verity and DAX are incompatible. Changing the DAX mode due to a verity
flag change is wrong without a corresponding address_space_operations
update.
Make the 2 options mutually exclusive by returning an error if DAX was
set first.
(Setting DAX is already disabled if Verity is
From: Ira Weiny
Update the document to reflect ext4 and xfs now behave the same.
Reviewed-by: Jan Kara
Signed-off-by: Ira Weiny
---
Changes from RFC:
Update with ext2 text...
---
Documentation/filesystems/dax.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
From: Ira Weiny
Changes from V2:
Rework DAX exclusivity with verity and encryption based on feedback
from Eric
Enable the same per file DAX support in ext4 as was done for xfs. This series
builds and depends on the V11 series for xfs.[1]
This passes the same xfstests test as
From: Ira Weiny
To prevent complications with in memory inodes we only set S_DAX on
inode load. FS_XFLAG_DAX can be changed at any time and S_DAX will
change after inode eviction and reload.
Add init bool to ext4_set_inode_flags() to indicate if the inode is
being newly initialized.
Assert
From: Ira Weiny
We add 'always', 'never', and 'inode' (default). '-o dax' continues to
operate the same which is equivalent to 'always'. This new
functionality is limited to ext4 only.
Specifically we introduce a 2nd DAX mount flag EXT4_MOU
From: Ira Weiny
S_DAX should only be enabled when the underlying block device supports
dax.
Change ext4_should_use_dax() to check for device support prior to the
over riding mount option.
While we are at it change the function to ext4_should_enable_dax() as
this better reflects the ask as well
From: Ira Weiny
When preventing DAX and journaling on an inode. Use the effective DAX
check rather than the mount option.
This will be required to support per inode DAX flags.
Reviewed-by: Jan Kara
Signed-off-by: Ira Weiny
---
fs/ext4/ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2
On Wed, May 20, 2020 at 12:30:56AM +0530, Vaibhav Jain wrote:
> Implement support for fetching nvdimm health information via
> H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
> of 64-bit big-endian integers, bitwise-and of which is then stored in
> 'struct papr_scm_priv' and su
On Wed, May 20, 2020 at 12:30:57AM +0530, Vaibhav Jain wrote:
> Introduce support for Papr nvDimm Specific Methods (PDSM) in papr_scm
> modules and add the command family to the white list of NVDIMM command
> sets. Also advertise support for ND_CMD_CALL for the dimm
> command mask and implement nec
On Wed, May 20, 2020 at 04:11:38PM +0200, Jan Kara wrote:
> On Tue 19-05-20 22:57:52, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Add a flag to preserve FS_XFLAG_DAX in the ext4 inode.
> >
> > Set the flag to be user visible and changeable. Set the
On Wed, May 20, 2020 at 03:37:28PM +0200, Jan Kara wrote:
> On Tue 19-05-20 22:57:49, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > S_DAX should only be enabled when the underlying block device supports
> > dax.
> >
> > Change ext4_should_use_dax
On Wed, May 20, 2020 at 01:26:44PM -0600, Andreas Dilger wrote:
> On May 19, 2020, at 11:57 PM, ira.we...@intel.com wrote:
> >
> > From: Ira Weiny
> >
> > Add a flag to preserve FS_XFLAG_DAX in the ext4 inode.
> >
> > Set the flag to be user visi
On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > > as do the nosmp sparc32 boot tests,
> > > but sparc32 boot tests with SMP enabled still fail with lots of messages
> > > such as:
> > >
> > > BUG: Bad page state
On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> On 5/19/20 10:13 PM, Ira Weiny wrote:
> > On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> >> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 0
From: Ira Weiny
When preventing DAX and journaling on an inode. Use the effective DAX
check rather than the mount option.
This will be required to support per inode DAX flags.
Reviewed-by: Jan Kara
Signed-off-by: Ira Weiny
---
fs/ext4/ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Ira Weiny
Changes from V3:
Change EXT4_DAX_FL to bit24
Cache device DAX support in the super block and use that is
ext4_should_use_dax()
Changes from V2:
Rework DAX exclusivity with verity and encryption based on feedback
from Eric
Enable
From: Ira Weiny
To prevent complications with in memory inodes we only set S_DAX on
inode load. FS_XFLAG_DAX can be changed at any time and S_DAX will
change after inode eviction and reload.
Add init bool to ext4_set_inode_flags() to indicate if the inode is
being newly initialized.
Assert
From: Ira Weiny
We add 'always', 'never', and 'inode' (default). '-o dax' continues to
operate the same which is equivalent to 'always'. This new
functionality is limited to ext4 only.
Specifically we introduce a 2nd DAX mount flag EXT4_MOU
From: Ira Weiny
Verity and DAX are incompatible. Changing the DAX mode due to a verity
flag change is wrong without a corresponding address_space_operations
update.
Make the 2 options mutually exclusive by returning an error if DAX was
set first.
(Setting DAX is already disabled if Verity is
From: Ira Weiny
In prep for the new tri-state mount option which then introduces
EXT4_MOUNT_DAX_NEVER.
Reviewed-by: Jan Kara
Signed-off-by: Ira Weiny
---
Changes:
New patch
---
fs/ext4/ext4.h | 4 ++--
fs/ext4/inode.c | 2 +-
fs/ext4/super.c | 12 ++--
3 files changed, 9
From: Ira Weiny
S_DAX should only be enabled when the underlying block device supports
dax.
Cache the underlying support for DAX in the super block and modify
ext4_should_use_dax() to check for device support prior to the over
riding mount option.
While we are at it change the function to
From: Ira Weiny
Update the document to reflect ext4 and xfs now behave the same.
Reviewed-by: Jan Kara
Signed-off-by: Ira Weiny
---
Changes from RFC:
Update with ext2 text...
---
Documentation/filesystems/dax.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
From: Ira Weiny
Add a flag to preserve FS_XFLAG_DAX in the ext4 inode.
Set the flag to be user visible and changeable. Set the flag to be
inherited. Allow applications to change the flag at any time with the
exception of if VERITY or ENCRYPT is set.
Disallow setting VERITY or ENCRYPT if DAX
On Wed, May 20, 2020 at 10:45:58PM +0530, Vaibhav Jain wrote:
...
> > On Wed, May 20, 2020 at 12:30:56AM +0530, Vaibhav Jain wrote:
...
> >> @@ -39,6 +78,15 @@ struct papr_scm_priv {
> >>struct resource res;
> >>struct nd_region *region;
> >>struct nd_interleave_set nd_set;
> >> +
>
From: Ira Weiny
While reviewing Protection Key Supervisor support it was pointed out
that using a counter to track static branch enable was an anti-pattern
which was better solved using the provided static_branch_{inc,dec}
functions.[1]
Fix up devmap_managed_key to work the same way. Also this
From: Ira Weiny
When MSG_OOB is specified to tls_device_sendpage() the mapped page is
never unmapped.
Hold off mapping the page until after the flags are checked and the page
is actually needed.
Signed-off-by: Ira Weiny
---
net/tls/tls_device.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Ira Weiny
While going through kmap() users the following 2 issues were found via code
inspection.
Ira Weiny (2):
crypto/ux500: Fix kmap() bug
crypto: Remove unused async iterators
crypto/ahash.c| 41 +++
drivers/crypto/ux500/hash
From: Ira Weiny
Once the crypto hash walk is started by crypto_hash_walk_first()
returning non-zero, crypto_hash_walk_done() must be called to unmap any
memory which was mapped by *_walk_first().
Ensure crypto_hash_walk_done() is called properly by:
1) Re-arranging the check for device
From: Ira Weiny
Revert "crypto: hash - Add real ahash walk interface"
This reverts commit 75ecb231ff45b54afa9f4ec9137965c3c00868f4.
The callers of the functions in this commit were removed in ab8085c130ed
Remove these unused calls.
Fixes: ab8085c130ed ("crypto: x86 - remove
>sec.flags': when the operation
> starts, it adds an overwrite bit to the flags; and when the operation
> completes, it removes the bit. Hence security_show() should check the
> 'overwrite' bit first, in order to indicate the actual state when multiple
> bits are s
7;nvdimm->sec.ext_flags'.
>
> Cc: Dan Williams
> Fixes: d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute")
> Signed-off-by: Jane Chu
> Reviewed-by: Dave Jiang
Reviewed-by: Ira Weiny
> ---
> drivers/nvdimm/security.c | 2 +-
>
rwrite nmemX" again,
> the command returns instantly.
>
> Cc: Dave Jiang
> Cc: Dan Williams
> Fixes: 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM
> overwrite support")
> Signed-off-by: Jane Chu
> Reviewed-by: Dave Jiang
Reviewed-by: Ira
em_config,
> + virtio_cread_le(vpmem->vdev, struct virtio_pmem_config,
> size, &vpmem->size);
FWIW I think squashing patch 15/38 and this patch would have made more sense.
Acked-by: Ira Weiny
>
> res.start = vpmem->start;
> --
> MST
>
; Cc: Jérôme Glisse
> Cc: "Matthew Wilcox (Oracle)"
> Cc: Al Viro
> Cc: Christoph Hellwig
> Cc: Dan Williams
> Cc: Dave Chinner
> Cc: Jason Gunthorpe
> Cc: Jonathan Corbet
> Cc: Michal Hocko
> Cc: Mike Kravetz
> Cc: Shuah Khan
> Cc: Vlastimil
On Mon, Aug 10, 2020 at 05:40:13PM -0700, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> While going through kmap() users the following 2 issues were found via code
> inspection.
Any feedback on these patches? Perhaps I've not included the correct people?
Adding
On Thu, Aug 13, 2020 at 11:27:02AM +0800, Wang Qing wrote:
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Wang Qing
LTGM
Reviewed-by: Ira Weiny
> ---
> drivers/dax/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dri
From: Ira Weiny
The #endif at the end of the file matches up with the '#if
defined(HASHED_PAGE_VIRTUAL)' on line 374. Not the CONFIG_HIGHMEM #if
earlier.
Fix comments on both of the #endif's to indicate the correct end of
blocks for each.
Signed-off-by: Ira Weiny
---
m
From: Ira Weiny
kmap_atomic() is being deprecated in favor of kmap_local_page().
Replace the uses of kmap_atomic() within the highmem code.
Signed-off-by: Ira Weiny
---
include/linux/highmem.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a
From: Ira Weiny
Working through a conversion to a call such as kmap_thread() revealed
many places where the pattern kmap/memcpy/kunmap occurred.
Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
Viro all suggested putting this code into helper functions. Al Viro
further
From: Ira Weiny
Changes from V2[1]:
Update this cover letter
Update commit messages
From Matthew Wilcox
Put functions in highmem.h rather than pagemap.h
Investigate 0-day build errors.
AFAICT the patches were applied to the wrong
On Thu, Dec 10, 2020 at 08:30:03AM -0500, Pavel Tatashin wrote:
> On Wed, Dec 9, 2020 at 11:06 PM Ira Weiny wrote:
> >
> > On Wed, Dec 09, 2020 at 07:43:30PM -0500, Pavel Tatashin wrote:
> > > __gup_longterm_locked() has CMA || FS_DAX version and a common stub
> > &g
101 - 200 of 1014 matches
Mail list logo
