On Sun, Aug 29, 2021 at 08:25:14PM +0800, Shiyang Ruan wrote:
> Punch hole on a reflinked file needs dax_iomap_cow_copy() too.
> Otherwise, data in not aligned area will be not correct. So, add the
> srcmap to dax_iomap_zero() and replace memset() as dax_iomap_cow_copy().
>
> Signed-off-by:
On Sun, Aug 29, 2021 at 08:25:13PM +0800, Shiyang Ruan wrote:
> We replace the existing entry to the newly allocated one in case of CoW.
> Also, we mark the entry as PAGECACHE_TAG_TOWRITE so writeback marks this
> entry as writeprotected. This helps us snapshots so new write
> pagefaults after
On Mon, Aug 16, 2021 at 02:03:57PM +0800, Shiyang Ruan wrote:
> + id = dax_read_lock();
> + while ((ret = iomap_iter2(_src, _dest, ops)) > 0) {
> + it_src.processed = it_dest.processed =
> + dax_range_compare_iter(_src, _dest, same);
> + }
> +
On Fri, Aug 20, 2021 at 08:18:44AM -0700, Dan Williams wrote:
> I notice that the @iomap argument to ->iomap_end() is reliably coming
> from @iter. So you could do the following in your iomap_end()
> callback:
>
> struct iomap_iter *iter = container_of(iomap, typeof(*iter), iomap);
>
On Mon, Aug 16, 2021 at 02:03:56PM +0800, Shiyang Ruan wrote:
> Some operations, such as comparing a range of data in two files under
> fsdax mode, requires nested iomap_begin()/iomap_end() on two files.
> Thus, we introduce iomap_iter2() to accept two iteraters to operate
> action on two files.
On Thu, Aug 19, 2021 at 03:54:01PM -0700, Dan Williams wrote:
>
> static void *dax_insert_entry(struct xa_state *xas, struct vm_fault *vmf,
> const struct iomap_iter *iter, void
> *entry, pfn_t pfn,
> unsigned long flags)
>
>
> > {
>
Can you also clean up the reference to strlen_user in the comments
in the ia64 and mips code, please?
> This also removes all the superflous freezer calls on all filesystems
> as they are no longer needed as the VFS now performs filesystem
> freezing/thaw if the filesystem has support for it. The filesystem
> therefore is in charge of properly dealing with quiescing of the
> filesystem through its
Wouldn't it be simpler to just add a new flag to signal a kernel
initiated freeze, or even better the exact reason (suspend) instead of
overloading the state machine?
On Sat, Apr 17, 2021 at 12:10:21AM +, Luis Chamberlain wrote:
> freeze_super() holds a write lock, however we wish to also enable
> callers which already hold the write lock. To do this provide a helper
> and make freeze_super() use it. This way, all that freeze_super() does
> now is lock
Just to despit my 2 cents again: I think the way this is specified
in the virtio spec is actively harmful and we should not suport it in
Linux.
If others override me we at least need to require a detailed
documentation of these fields as the virto spec does not provide it.
Please also do not
On Mon, Apr 19, 2021 at 05:30:49PM -0700, Rajat Jain wrote:
> The current flag name "untrusted" is not correct as it is populated
> using the firmware property "external-facing" for the parent ports. In
> other words, the firmware only says which ports are external facing, so
> the field really
On Sun, Apr 18, 2021 at 08:14:41AM +, Alexander Egorenkov wrote:
> If CONFIG_NEED_SG_DMA_LENGTH is NOT enabled then sg_dma_len() is an alias
> for the length field in a SGL. In that case sg_split() wrongly resets
> the length of split SGLs to zero after it was set correctly before.
Why is
On Fri, Apr 16, 2021 at 05:13:44PM +0800, Kai-Heng Feng wrote:
> On AMD platforms that use s2idle, NVMe timeouts on s2idle resume,
> because their SMU FW may cut off NVMe power during sleep.
We're already have a discussion on a proper quirk for thse broken
platforms on the linux-nvme list, please
On Thu, Apr 15, 2021 at 04:24:15PM -0400, Konrad Rzeszutek Wilk wrote:
> So you are exposing these two:
> EXPORT_SYMBOL_GPL(get_vm_area);
> EXPORT_SYMBOL_GPL(ioremap_page_range);
>
> But if you used vmap wouldn't you get the same thing for free?
Yes, this needs to go into some vmap version,
On Fri, Apr 16, 2021 at 04:27:55PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch. Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
>
On Wed, Apr 14, 2021 at 09:44:35AM +0100, Stefan Hajnoczi wrote:
> On Mon, Apr 12, 2021 at 10:42:17AM +0100, Christoph Hellwig wrote:
> > A note to the virtio committee: eMMC is the worst of all the currently
> > active storage standards by a large margin. It defines very str
On Mon, Apr 12, 2021 at 08:00:24AM -0400, Michael S. Tsirkin wrote:
> On Mon, Apr 12, 2021 at 10:42:17AM +0100, Christoph Hellwig wrote:
> > A note to the virtio committee: eMMC is the worst of all the currently
> > active storage standards by a large margin. It defines very str
t robot
> Signed-off-by: Joerg Roedel
Sorry for introducing this. The fix looks good:
Reviewed-by: Christoph Hellwig
On Wed, Apr 14, 2021 at 05:11:11PM -0700, Nathan Chancellor wrote:
> dev_attr_show() calls _iommu_event_show() via an indirect call but
> _iommu_event_show()'s type does not currently match the type of the
> show() member in 'struct device_attribute', resulting in a Control Flow
> Integrity
> *
> * Returns 0 on success and < 0 on error.
> @@ -28,6 +28,9 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t
> min, ioasid_t max)
> int ret = 0;
> ioasid_t pasid;
>
> + if (mm != current->mm)
> + return -EINVAL;
> +
Why not remove the parameter
On Wed, Apr 14, 2021 at 08:27:56AM -0700, Jacob Pan wrote:
> static int idxd_enable_system_pasid(struct idxd_device *idxd)
> {
> - int flags;
> + unsigned int flags;
> unsigned int pasid;
> struct iommu_sva *sva;
>
> - flags = SVM_FLAG_SUPERVISOR_MODE;
> + flags =
binfmt_flat tends to go through Greg's uclinux tree, adding him and
the list.
On Wed, Apr 14, 2021 at 10:46:36PM -0700, Palmer Dabbelt wrote:
> On Wed, 14 Apr 2021 17:32:10 PDT (-0700), Damien Le Moal wrote:
>>> On 2021/04/08 0:49, Damien Le Moal wrote:
>>> RISC-V NOMMU flat binaries cannot
Same comments as for the net driver. In addition to all the poking
into kernel internals the fact that this is duplicated in the two main
drivers should have been a huge red flag.
> +struct dma_range {
> + dma_addr_t dma;
> + u32 mapping_size;
> +};
That's a rather generic name that is bound to create a conflict sooner
or later.
> #include "hyperv_net.h"
> #include "netvsc_trace.h"
> +#include "../../hv/hyperv_vmbus.h"
Please move public interfaces out of the
> +static dma_addr_t hyperv_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + phys_addr_t map, phys
On Wed, Apr 14, 2021 at 10:49:41AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> UIO HV driver should not load in the isolation VM for security reason.
> Return ENOTSUPP in the hv_uio_probe() in the isolation VM.
What is the "security reason"? After all a user can simply patch the
code and
> +EXPORT_SYMBOL_GPL(hv_ghcb_msr_write);
Just curious, who is going to use all these exports? These seems like
extremely low-level functionality. Isn't there a way to build a more
useful higher level API?
> +/*
> + * hv_set_mem_host_visibility - Set host visibility for specified memory.
> + */
I don't think this comment really clarifies anything over the function
name. What is 'host visibility'
> +int hv_set_mem_host_visibility(void *kbuffer, u32 size, u32 visibility)
Should size be a size_t?
On Tue, Apr 13, 2021 at 11:22:14AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> For Hyper-V isolation VM with AMD SEV SNP, the bounce buffer(shared memory)
> needs to be accessed via extra address space(e.g address above bit39).
> Hyper-V code may remap extra address space outside of swiotlb.
On Mon, Apr 12, 2021 at 11:03:46AM +0200, Borislav Petkov wrote:
> IDE/ATAPI DRIVERS
> -M: Borislav Petkov
> L: linux-...@vger.kernel.org
> S: Maintained
> F: Documentation/cdrom/ide-cd.rst
The Maintained should also become Orphaned then.
On Mon, Apr 12, 2021 at 08:48:08AM -0700, Darrick J. Wong wrote:
> A couple of revisions ago I specifically asked Gustavo to create these
> 'silly' sizeof helpers to clean up...
>
> > > - (sizeof(struct xfs_efd_log_item) +
> > > -
On Tue, Apr 13, 2021 at 05:43:18PM +0200, Helge Deller wrote:
> On 4/12/21 10:55 AM, Christoph Hellwig wrote:
>> The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for
>> 32-bit syscall APIs, but we also need them for compat handling on 64-bit
>> kernel
And more importantly please test with a file system that uses the
iomap direct I/O code (btrfs, gfs2, ext4, xfs, zonefs) as we should
never just work aroudn a legacy codebase that should go away in the
block layer.
> Below are the results of running xfstests for "all" with the following
> configuration in local.config:
...
> Other tests might need to be run in order to verify everything is working
> as expected. For such tests, the intervention of the maintainers might be
> needed.
This is a little weird
A note to the virtio committee: eMMC is the worst of all the currently
active storage standards by a large margin. It defines very strange
ad-hoc interfaces that expose very specific internals and often provides
very poor abstractions. It would be great it you could reach out to the
wider
Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants. An extra define is added for the packing required on x86.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h | 16
arch
Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/uapi/asm/fcntl.h | 26 +++---
include/uapi/asm-generic/fcntl.h
.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h| 4
arch/mips/include/asm/compat.h | 4
arch/mips/include/uapi/asm/fcntl.h | 2 --
arch/powerpc/include/asm/compat.h | 4
arch/s390/include/asm/compat.h | 4
arch/sparc/include
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 9dc0bf0c5a6ee8..fb454bb629d114 100644
Hi all,
currently we deal with the slight differents in the various architecture
variants of the flock and flock64 stuctures in a very cruft way. This
series switches to just use small arch hooks and define the rest in
asm-generic and linux/compat.h instead.
Diffstat:
Don't bother to define emtpty versions of the macros if the architecture
doesn't define them.
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 12
tools/include/uapi/asm-generic/fcntl.h | 12
2 files changed, 8 insertions(+), 16 deletions
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> +extern int verify_page_range(struct mm_struct *mm,
No need for the extern here.
> +int verify_page_range(struct mm_struct *mm,
> + unsigned long addr, unsigned long size,
> + int (*fn)(pte_t
"
Can't we keep the includes at the top of the file?
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Mon, Apr 12, 2021 at 10:00:14AM +0200, Peter Zijlstra wrote:
> Instead of relying on apply_to_page_range() being available to
> modules, move its use into core kernel code and export it's
> application.
This doesn't exactly look great, but at least it contains the damage..
>
> NOTE: ideally
On Mon, Apr 12, 2021 at 10:00:13AM +0200, Peter Zijlstra wrote:
> There are no modular in-tree users, remove the EXPORT.
>
> This is an unsafe function in that it gives direct access to the
> page-tables.
>
> Signed-off-by: Peter Zijlstra (Intel)
Looks good,
Reviewed-by: Christoph Hellwig
Thanks,
applied to nvme-5.13.
Thanks,
applied to nvme-5.13.
Applied to nvme-5.13.
On Fri, Apr 09, 2021 at 07:50:38PM +0100, Matthew Wilcox (Oracle) wrote:
> Signed-off-by: Matthew Wilcox (Oracle)
Looks good,
Reviewed-by: Christoph Hellwig
\
Why not merge this into a single line, which seems a little more
readable:
access_ok(__p, sizeof(*__p)) ? __put_user((x), __p) : -EFAULT; \
Same for the get_user side.
Otherwise looks great:
Reviewed-by: Christoph Hellwig
On Thu, Apr 08, 2021 at 02:18:03PM +0200, Oscar Salvador wrote:
> Enable x86_64 platform to use the MHP_MEMMAP_ON_MEMORY feature.
> +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
> + def_bool y
This needs to go into a common file, with the architectures just
selecting the symbol.
On Thu, Apr 08, 2021 at 12:30:16PM +0200, Javier González wrote:
>>> Aligning to MDTS is our current behavior, although all kernels up to
>>> 5.11 had a bug in the calculation.
>>
>> I see. Let me check internally and see what's going on with
>> write-zeroes on this model.
>
> We still need to
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph M??llner wrote:
> Gentlemen, please rethink your wording.
> RISC-V is neither "crap" nor a "trainwreck", regardless if you like it or not.
No, by all objective standards the RISC-V memory model and privileged
architecture is a trainwreck.
On Wed, Apr 07, 2021 at 08:56:37PM +0900, Damien Le Moal wrote:
> Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
> the data start"") restored offsetting the start of the data section by
> a number of words defined by MAX_SHARED_LIBS. As a result, since
> MAX_SHARED_LIBS is
On Tue, Apr 06, 2021 at 09:15:50AM +0200, Peter Zijlstra wrote:
> Anyway, given you have such a crap architecture (and here I thought
> RISC-V was supposed to be a modern design *sigh*), you had better go
> look at the sparc64 atomic implementation which has a software backoff
> for failed CAS in
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Apr 06, 2021 at 05:25:30PM +0100, Matthew Wilcox wrote:
> About a third of ->index can be folio_offset(), based on a crude:
>
> $ git grep 'page->index.*PAGE_' |wc -l
> 101
>
> and I absolutely don't mind cleaning that up as part of the folio work,
> but that still leaves 200-250
On Tue, Apr 06, 2021 at 03:55:11PM +0100, Matthew Wilcox wrote:
> Assuming we're getting rid of them all though, we have to include:
>
> $ git grep 'page->mapping' fs |wc -l
> 358
> $ git grep 'page->index' fs |wc -l
> 355
Are they all going to stay? Or are we going to clean up some of that
On Tue, Apr 06, 2021 at 04:54:57PM +0200, Christoph Hellwig wrote:
> That is something everyone gets wrong at first (yourself included)
The yourself here should have been a yours truly or "myself", sorry.
On Tue, Apr 06, 2021 at 11:40:39AM -0300, Jason Gunthorpe wrote:
> Yes, but the complexity is how the drivers are constructed they are
> designed to reject flags they don't know about..
>
> Hum, it looks like someone has already been in here and we now have a
> IB_ACCESS_OPTIONAL concept.
>
>
On Tue, Apr 06, 2021 at 03:40:22PM +0100, Matthew Wilcox wrote:
> On Tue, Apr 06, 2021 at 03:31:50PM +0100, Christoph Hellwig wrote:
> > > > As Christoph, I'm not a fan of this :/
> > >
> > > What would you prefer?
> >
> > Looking a
On Tue, Apr 06, 2021 at 01:48:07PM +0100, Matthew Wilcox wrote:
> Now, maybe we should put this optimisation into the definition of nth_page?
That would be nice.
> > As Christoph, I'm not a fan of this :/
>
> What would you prefer?
Looking at your full folio series on git.infradead.org, there
is unchanged in size.
Looks good,
Reviewed-by: Christoph Hellwig
wake_up_page_bit(page, PG_private_2);
> + struct folio *folio = page_folio(page);
> + VM_BUG_ON_FOLIO(!FolioPrivate2(folio), folio);
A whitespace between the declaration and the code would be nice.
Otherwise looks good;
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
4
> bytes as a result of this patch.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Looks good,
Reviewed-by: Christoph Hellwig
.
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Apr 06, 2021 at 11:04:37AM -0300, Jason Gunthorpe wrote:
> It might be idiodic, but I have to keep the uverbs thing working
> too.
>
> There is a lot of assumption baked in to all the drivers that
> user/kernel is the same thing, we'd have to go in and break this.
>
> Essentially #2 ends
213 bytes, due to removing all the
> compound_head() calls. The 30 byte wrapper function makes this a net
> saving of 70 bytes.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Looks good,
Reviewed-by: Christoph Hellwig
0
> bytes for me.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Looks good,
Reviewed-by: Christoph Hellwig
age_folio()
> in __lock_folio_or_retry() for a total saving of 24 bytes.
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
ll
> have unlock_page(), it's a net increase of 24 bytes of text for the
> kernel as a whole, but any path that uses unlock_folio() will execute
> 4 fewer instructions.
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 31, 2021 at 07:47:16PM +0100, Matthew Wilcox (Oracle) wrote:
> Add new wrapper functions folio_memcg(), lock_folio_memcg(),
> unlock_folio_memcg(), mem_cgroup_folio_lruvec() and
> count_memcg_folio_event()
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 31, 2021 at 07:47:15PM +0100, Matthew Wilcox (Oracle) wrote:
> This is the folio equivalent of page_mapcount().
>
> Signed-off-by: Matthew Wilcox (Oracle)
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 31, 2021 at 07:47:13PM +0100, Matthew Wilcox (Oracle) wrote:
> These are just wrappers around their page counterpart.
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 31, 2021 at 07:47:12PM +0100, Matthew Wilcox (Oracle) wrote:
> This helper returns the page index of the next folio in the file (ie
> the end of this folio, plus one).
Looks good,
Reviewed-by: Christoph Hellwig
Except for the implementation details using the unions field (I'm not
going to mention these going forward), this looks good:
Reviewed-by: Christoph Hellwig
ould be trivially
avoided this looks good:
Reviewed-by: Christoph Hellwig
ePoisoned
> case as a poisoned page has every bit set, which would include PageTail.
>
> This saves 1727 bytes of text with the distro-derived config that
> I'm testing due to removing a double call to compound_head() in
> PageSwapCache().
Looks good,
Reviewed-by: Christoph Hellwig
good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
return page_ref_count(compound_head(page));
> +}
I don't think this change belongs in here. It seems useful though,
so maybe split it into a standalone patch?
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Wed, Mar 31, 2021 at 07:47:05PM +0100, Matthew Wilcox (Oracle) wrote:
> These are the folio equivalents of VM_BUG_ON_PAGE and VM_WARN_ON_ONCE_PAGE.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Reviewed-by: Zi Yan
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 31, 2021 at 07:47:04PM +0100, Matthew Wilcox (Oracle) wrote:
> Allow page counters to be more readily modified by callers which have
> a folio. Name these wrappers with 'stat' instead of 'state' as requested
> by Linus here:
Looks good,
Reviewed-by: Christoph Hellwig
good,
Reviewed-by: Christoph Hellwig
On Tue, Apr 06, 2021 at 09:13:12AM -0300, Jason Gunthorpe wrote:
> So we broadly have two choice
> 1) Diverge the kernel and user interfaces and make the RDMA drivers
> special case all the kernel stuff to force
> ACCESS_RELAXED_ORDERING when they are building MRs and processing
> FMR
Btw, there is a bunch of cleanups that would fit in nicely on top of
this:
- remove the unused __invoke_copy_from function
- fold __get_user_check into get_user as it is the only caller
- fold __get_user_nocheck into __get_user as it is the only caller
- fold __put_user_check into put_user as
On Sat, Apr 03, 2021 at 04:10:16PM +0800, Ming Lei wrote:
> We still may shutdown blktrace if current is the last opener, otherwise
> new blktrace can't be started and memory should be leaked forever, and
> what do you think of the revised version?
I don't think this works. For one there might
On Tue, Apr 06, 2021 at 08:23:28AM +0300, Leon Romanovsky wrote:
> The same proposal (enable unconditionally) was raised during
> submission preparations and we decided to follow same pattern
> as other verbs objects which receive flag parameter.
A flags argument can be added when it actually is
On Mon, Apr 05, 2021 at 08:23:55AM +0300, Leon Romanovsky wrote:
> From: Avihai Horon
>
> Add access flags parameter to ib_alloc_mr() and to ib_mr_pool_init(),
> and refactor relevant code. This parameter is used to pass MR access
> flags during MR allocation.
>
> In the following patches, the
On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> >From Avihai,
>
> Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering
> imposed on PCI transactions, and thus, can improve performance.
>
> Until now, relaxed ordering could be set
So it turns out that while git-am complained it did apply the patch
just fine and it didn't look whitespace mangled. No idea what went
on there, but the patch is in nvme-5.13 now.
101 - 200 of 23088 matches
Mail list logo
