Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_drv.c | 64 ++-
1 file changed, 3 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 87e7214a8e3565
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/cmm.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/cmm.c
b/arch/powerpc/platforms/pseries/cmm.c
Add a new alloc_anon_inode helper that allocates an inode on
the anon_inode file system.
Signed-off-by: Christoph Hellwig
---
fs/anon_inodes.c| 15 +--
include/linux/anon_inodes.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/anon_inodes.c b
Hi all,
this series first renames the existing alloc_anon_inode to
alloc_anon_inode_sb to clearly mark it as requiring a superblock.
It then adds a new alloc_anon_inode that works on the anon_inode
file system super block, thus removing tons of boilerplate code.
The few remainig callers of
Rename alloc_inode to free the name for a new variant that does not
need boilerplate to create a super_block first.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/cmm.c | 2 +-
drivers/dma-buf/dma-buf.c| 2 +-
drivers/gpu/drm/drm_drv.c| 2 +-
drivers
on adding parentheses is not required (unlike for
macros).
Otherwise this looks good:
Reviewed-by: Christoph Hellwig
On Tue, Mar 09, 2021 at 10:18:43AM +, Sanket Parmar wrote:
> > On Tue, Mar 09, 2021 at 06:19:40AM +0100, Sanket Parmar wrote:
> > > dma_alloc_coherent() might fail on the platform with a small DMA region.
> > >
> > > To avoid such failure in cdns3_prepare_aligned_request_buf(),
> > >
On Mon, Mar 08, 2021 at 10:42:43AM +, Caleb Connolly wrote:
> >> +#define UFSHCI_VER(major, minor) \
> >> + ((major << 8) + (minor << 4))
> > This needs braces around major and minor. Or better just convert it
> > to an inline function (and use a lower case name).
>
> Other (similar)
On Tue, Mar 09, 2021 at 06:19:40AM +0100, Sanket Parmar wrote:
> dma_alloc_coherent() might fail on the platform with a small DMA region.
>
> To avoid such failure in cdns3_prepare_aligned_request_buf(),
> dma_alloc_coherent() is replaced with kmalloc and dma_map API to
> allocate aligned request
On Mon, Mar 08, 2021 at 02:47:28PM -0700, Alex Williamson wrote:
> By linking all the device fds we provide to userspace to an
> address space through a new pseudo fs, we can use tools like
> unmap_mapping_range() to zap all vmas associated with a device.
>
> Suggested-by: Jason Gunthorpe
>
On Mon, Mar 08, 2021 at 09:07:45PM -0400, Jason Gunthorpe wrote:
> Indeed, checkpatch has been warning about this too
And checkaptch as so often these days is completely full of shit.
There is ansolutely not objective reason against using bare unsigned
except for a weird anal preference of a
On Mon, Mar 08, 2021 at 10:54:22PM -0800, Dan Williams wrote:
> Previous kernels allowed the BLKROSET to override the disk's read-only
> status. With that situation fixed the pmem driver needs to rely on
> revalidate_disk() to clear the disk read-only status after the host
> region has been marked
On Wed, Mar 03, 2021 at 06:30:34PM +0100, Martin Wilck wrote:
> I wonder if it wouldn't be wiser to remove this code
>
> if (disk->flags & GENHD_FL_HIDDEN) {
> dev_set_uevent_suppress(ddev, 0);
> return;
> }
>
> from register_disk(). The way you
This looks like a really nice improvement!
A bunch of comments below:
> @@ -696,10 +685,21 @@ static inline u32 ufshcd_get_intr_mask(struct ufs_hba
> *hba)
> */
> static inline u32 ufshcd_get_ufs_version(struct ufs_hba *hba)
> {
> + u32 ufshci_ver;
missing eempty line after the
Looks good,
Reviewed-by: Christoph Hellwig
On Thu, Mar 04, 2021 at 05:26:42PM -0700, Jens Axboe wrote:
> Christoph, since there's multiple commits with issues, mind resending
> a fixed branch? Then I'll drop the one I pulled today.
I've fixed the commit id and dropped the patch without the author
signoff, but your branch still has the
On Thu, Mar 04, 2021 at 02:42:50PM -0800, Darrick J. Wong wrote:
> My vision here, however, is to establish upcalls for /both/ types of
> stroage.
I already have patches for doing these kinds of callbacks properly
for the block layer. They will be posted shortly.
On Wed, Mar 03, 2021 at 05:18:05PM +0800, Art Nikpal wrote:
> hello Christoph
> i have see your patch https://lkml.org/lkml/2020/7/14/1508
> /* using deprecated initrd support, will be removed in 2021*/
>
> How can I clarify the situation ?!
>
> im using squashfs as ramdisk / all system works
gt; simplify the code.
>
> Signed-off-by: Shiyang Ruan
Looks good,
Reviewed-by: Christoph Hellwig
y: Shiyang Ruan
Looks good,
Reviewed-by: Christoph Hellwig
On Fri, Feb 26, 2021 at 08:20:22AM +0800, Shiyang Ruan wrote:
> The core logic in the two dax page fault functions is similar. So, move
> the logic into a common helper function. Also, to facilitate the
> addition of new features, such as CoW, switch-case is no longer used to
> handle different
On Fri, Feb 26, 2021 at 08:20:25AM +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
to_kernel(daddr, saddr, length);
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Wed, Mar 03, 2021 at 09:57:48AM +, ruansy.f...@fujitsu.com wrote:
> > What is the advantage of the ioemap_end handler here? It adds another
> > indirect funtion call to the fast path, so if we can avoid it, I'd
> > rather do that.
>
> These code were in xfs_file_dax_write(). I moved them
Looks good,
Reviewed-by: Christoph Hellwig
On Fri, Feb 26, 2021 at 08:20:29AM +0800, Shiyang Ruan wrote:
> error = iomap_zero_range(VFS_I(ip), offset, len, NULL,
> - _buffered_write_iomap_ops);
> + IS_DAX(VFS_I(ip)) ?
> + _dax_write_iomap_ops : _buffered_write_iomap_ops);
Please add a
On Wed, Mar 03, 2021 at 09:41:54AM +, ruansy.f...@fujitsu.com wrote:
>
> > >
> > > if (dirty)
> > > __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
> >
> > I still think the __mark_inode_dirty should just be moved into the one
> > caller that needs it.
>
> I found that
qty: 299.264 avg 318.080 std 1.615 min 2806.667 max (uS)
raw decode speed: 365.470 Mbits/s
raw URB handling speed: 295.986 Mbits/s
throughput: 13.136 Mbits/s
URB decode CPU usage 3.594500 %
Signed-off-by: Ricardo Ribalda
Reviewed-by: Tomasz Figa
Signed-off-by: Christoph Hellwig
---
drivers/m
Implement support for allocating a non-contiguous DMA region.
Signed-off-by: Christoph Hellwig
Reviewed-by: Tomasz Figa
Tested-by: Ricardo Ribalda
---
drivers/iommu/dma-iommu.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c
-by: Christoph Hellwig
Reviewed-by: Tomasz Figa
Tested-by: Ricardo Ribalda
---
kernel/dma/mapping.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9ce86c77651c6f..07f964ebcda15e 100644
--- a/kernel/dma
removed and never fully implemented DMA_ATTR_NON_CONSISTENT
Signed-off-by: Christoph Hellwig
Reviewed-by: Tomasz Figa
Tested-by: Ricardo Ribalda
---
Documentation/core-api/dma-api.rst | 78 +
include/linux/dma-map-ops.h| 19 ++
include/linux/dma-mapping.h
Split out a new helper that only allocates a sg_table worth of
memory without mapping it into contiguous kernel address space.
Signed-off-by: Christoph Hellwig
Reviewed-by: Tomasz Figa
Tested-by: Ricardo Ribalda
---
drivers/iommu/dma-iommu.c | 67 ---
1
Add a helper to map memory allocated using dma_alloc_pages into
a user address space, similar to the dma_alloc_attrs function for
coherent allocations.
Signed-off-by: Christoph Hellwig
Reviewed-by: Tomasz Figa
Tested-by: Ricardo Ribalda
---
Documentation/core-api/dma-api.rst | 10
Hi all,
this series adds the new noncontiguous DMA allocation API requested by
various media driver maintainers.
Changes since v2:
- rebased to Linux 5.12-rc1
- dropped one already merged patch
- pass an attrs argument to dma_alloc_noncontigous
- clarify the dma_vmap_noncontiguous
remap_vmalloc_range_partial is only used to implement remap_vmalloc_range
and by procfs. Unexport it.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 4f5f8c907897ae..631915ff6d1b4d 100644
--- a/mm/vmalloc.c
Use remap_vmalloc_range instead of open coding it using
remap_vmalloc_range_partial.
Signed-off-by: Christoph Hellwig
---
samples/vfio-mdev/mdpy.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index 9894693f3be178
Hi Andrew,
this series removes an open coded instance of remap_vmalloc_range and
removes the unused remap_vmalloc_range_partial export.
On Mon, Mar 01, 2021 at 05:02:43PM +0900, Sergey Senozhatsky wrote:
> > I plan to resend the whole series with the comments very soon.
>
> Oh, OK.
>
> I thought the series was in linux-next already so a single patch
> would do.
It was, with an emphasys on was. I hadn't realized I need an ack
On Tue, Feb 16, 2021 at 06:55:39PM +, Robin Murphy wrote:
> On 2021-02-02 09:51, Christoph Hellwig wrote:
>> Add a new API that returns a potentiall virtually non-contigous sg_table
>> and a DMA address. This API is only properly implemented for dma-iommu
>> a
On Mon, Mar 01, 2021 at 01:13:41PM +0530, Anshuman Khandual wrote:
> > doesn't this need a 'if HUGETLB_PAGE'
>
> While making HUGETLB_PAGE_SIZE_VARIABLE a generic option, also made it
> dependent on HUGETLB_PAGE. Should not that gate HUGETLB_PAGE_SIZE_VARIABLE
> when HUGETLB_PAGE is not available
On Mon, Mar 01, 2021 at 04:17:42PM +0900, Sergey Senozhatsky wrote:
> > > Do you think we could add the attrs parameter to the
> > > dma_alloc_noncontiguous() API?
> >
> > Yes, we could probably do that.
>
> I can cook a patch, unless somebody is already looking into it.
I plan to resend the
This should be handled by the DMA mapping layer, just like for native
SEV support.
: Andrew Morton
> Cc: Christoph Hellwig
> Cc: linux-i...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Suggested-by: Christoph Hellwig
> Signed-off-by: Anshuman Khandual
> ---
> This change wa
On Fri, Feb 26, 2021 at 08:36:55AM +0100, Daniel Vetter wrote:
> Also given that both deal with struct page there's a ton of divergence
> between these two that doesn't make much sense. Maybe could even share
> the code fully, aside from how you allocate the struct pages.
I've been saying that
Nice cleanup!
Reviewed-by: Christoph Hellwig
break;
Just return false here directly and remove the ret variable?
Very nice cleanup!
Reviewed-by: Christoph Hellwig
and to make the arguments similar for both a read and write entry
> creation.
>
> Signed-off-by: Alistair Popple
Looks good,
Reviewed-by: Christoph Hellwig
> - struct page *page = migration_entry_to_page(entry);
> + struct page *page = pfn_to_page(swp_offset(entry));
I wonder if keeping a single special_entry_to_page() helper would still
me a useful. But I'm not entirely sure. There are also two more open
coded copies of
On Thu, Feb 25, 2021 at 11:35:57AM -0500, Alan Stern wrote:
> This thread seems to have fallen through the cracks. Maybe now would be
> a good time to address the problem (since we originally planned to fix
> it in 5.11!).
>
> The questions listed below are pretty self-contained, although the
On Mon, Feb 22, 2021 at 01:55:23PM -0400, Jason Gunthorpe wrote:
> > +static bool strict_mmio_maps = true;
> > +module_param_named(strict_mmio_maps, strict_mmio_maps, bool, 0644);
> > +MODULE_PARM_DESC(strict_mmio_maps,
> > +"Restrict to safe DMA mappings of device memory (true).");
>
On Mon, Feb 22, 2021 at 09:50:35AM -0700, Alex Williamson wrote:
> By linking all the device fds we provide to userspace to an
> address space through a new pseudo fs, we can use tools like
> unmap_mapping_range() to zap all vmas associated with a device.
>
> Suggested-by: Jason Gunthorpe
>
On Fri, Feb 26, 2021 at 12:17:50PM +0800, Claire Chang wrote:
> Do you think I should fix this and rebase on the latest linux-next
> now? I wonder if there are more factor and clean up coming and I
> should wait after that.
Here is my preferred plan:
1) wait for my series to support the min
On Fri, Feb 26, 2021 at 10:32:50AM +1100, Stephen Rothwell wrote:
> > > -return filemap_read(iocb, to, ret);
> > > +if (iocb->ki_flags & IOCB_NOWAIT)
> > > +iocb->ki_flags |= IOCB_NOIO;
> > > +
> > > - ret = generic_file_buffered_read(iocb, to, ret);
> >
On Thu, Feb 25, 2021 at 03:08:37PM +0800, Jiapeng Chong wrote:
> Fix the following sparse warning:
>
> kernel/kallsyms.c:457:12: warning: symbol 'arch_get_kallsym' was not
> declared. Should it be static?
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Please just remove the
On Thu, Feb 18, 2021 at 08:20:18AM -0800, Darrick J. Wong wrote:
> > I think a nested call like this is necessary. That's why I use the open
> > code way.
>
> This might be a good place to implement an iomap_apply2() loop that
> actually /does/ walk all the extents of file1 and file2. There's
On Wed, Feb 24, 2021 at 09:48:21AM -0700, Jens Axboe wrote:
> Would make sense to rename blk_get_request() to blk_mq_alloc_request()
> and then we have API symmetry. The get/put don't make sense when there
> are no references involved.
>
> But it's a lot of churn for very little reward, which is
On Wed, Feb 24, 2021 at 07:23:54PM +0800, Ming Lei wrote:
> > > The two patches changes block ioctl(BLKRRPART) for avoiding drop &
> > > re-add partitions if partitions state isn't changed. The current
> > > behavior confuses userspace because partitions can disappear anytime
> > > when calling
Shouldn't storvsc just use blk_queue_virt_boundary instead of all this
mess?
Thanks,
applied to nvme-5.12 with a slight tweak to the commit message.
Thanks,
applied to nvme-5.12.
On Wed, Feb 24, 2021 at 04:59:37PM +0800, Greentime Hu wrote:
> Christoph Hellwig 於 2021年2月24日 週三 下午3:47寫道：
> >
> > On Thu, Jan 28, 2021 at 11:16:33AM +0100, Christoph Hellwig wrote:
> > > On Tue, Jul 21, 2020 at 01:28:00PM +0200, Christoph Hellwig wrote:
> > &
On Tue, Feb 23, 2021 at 12:07:39PM -0800, Linus Torvalds wrote:
> On Tue, Feb 23, 2021 at 12:03 PM Linus Torvalds
> wrote:
> >
> > This is unacceptably slow. If that symbol trimming takes 30% of the
> > whole kernel build time, it needs to be fixed or removed.
>
> I think I'm going to mark
is transmitting
Christoph Hellwig (1):
dma-mapping: remove the {alloc,free}_noncoherent methods
Documentation/core-api/dma-api.rst | 64 +
drivers/iommu/dma-iommu.c | 30
include/linux/dma-map-ops.h | 5
On Thu, Jan 28, 2021 at 11:16:33AM +0100, Christoph Hellwig wrote:
> On Tue, Jul 21, 2020 at 01:28:00PM +0200, Christoph Hellwig wrote:
> > Can you pich the patches up in the nds32 tree for Linus? There are
> > not short-term dependencies on them.
>
> It seems like th
On Tue, Feb 23, 2021 at 11:55:50AM -0800, Linus Torvalds wrote:
> On Tue, Feb 23, 2021 at 10:42 AM Linus Torvalds
> wrote:
> >
> > I think there is something horribly wrong in my tree, and my build
> > process is now about 30% slower. It went from 5+ minutes to 8+
> > minutes. The main suspect
On Tue, Feb 23, 2021 at 04:08:52PM +0100, Christoph Hellwig wrote:
> On Tue, Feb 23, 2021 at 07:37:52AM +, Chaitanya Kulkarni wrote:
> > On 2/22/21 23:10, Christoph Hellwig wrote:
> > > On Tue, Feb 23, 2021 at 03:51:23AM +, Chaitanya Kulkarni wrote:
> > >> L
On Tue, Feb 23, 2021 at 07:37:52AM +, Chaitanya Kulkarni wrote:
> On 2/22/21 23:10, Christoph Hellwig wrote:
> > On Tue, Feb 23, 2021 at 03:51:23AM +, Chaitanya Kulkarni wrote:
> >> Looking at the other call sites do we need something like following ?
> >> Since
On Tue, Feb 23, 2021 at 08:04:08AM +0100, Christoph Hellwig wrote:
> The problem is that the blk-crypto fallback code calls bio_split
> with a NULL bioset. That was aready broken before, as the mempool
> needed to guarantee forward progress was missing, but is not fatal.
>
> Saty
On Mon, Feb 22, 2021 at 08:22:09PM -0800, John Stultz wrote:
> I'm wondering if given there are multiple call sites, that in
> bio_alloc_bioset() would something like the following make more sense?
> (apologies, copy pasted so this is whitespace corrupted)
> thanks
No. The fallback from the
On Tue, Feb 23, 2021 at 03:51:23AM +, Chaitanya Kulkarni wrote:
> Looking at the other call sites do we need something like following ?
> Since __blk_queue_bounce() passes the NULL for the passthru case as a
> bio_set value ?
Well, that is a somewhat odd calling convention. What about the
The problem is that the blk-crypto fallback code calls bio_split
with a NULL bioset. That was aready broken before, as the mempool
needed to guarantee forward progress was missing, but is not fatal.
Satya, can you look into adding a mempool that can guarantees forward
progress here?
Please try the patch below:
---
>From 85943345b41ec04f5a9e92dfad85b0fb24e2d2eb Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 23 Feb 2021 07:28:22 +0100
Subject: block: don't skip empty device in in disk_uevent
Restore the previous behavior by using the correct flag for the wh
On Sun, Feb 21, 2021 at 04:32:38AM +0100, Maciej W. Rozycki wrote:
> I haven't booted Linux on my Malta for a while now, but it turns out to
> work just fine, and your patch set does not regress it booting multi-user
> NFS-rooted over FDDI.
>
> I note however that the system does not reboot
On Thu, Feb 18, 2021 at 03:33:39PM +, Joao Martins wrote:
> in a bvec at once? e.g. something like from this:
>
> bio_for_each_segment_all(bvec, bio, iter_all) {
> if (mark_dirty && !PageCompound(bvec->bv_page))
>
On Fri, Feb 19, 2021 at 11:27:13AM +0100, Petr Mladek wrote:
> I am personally fine with adding this API. I am going to
> comment the original code. Well, there might be a push-back
> from other people because there will be no in-tree user.
Adding a new API without an intree user is a complete
On Fri, Feb 19, 2021 at 03:45:09AM -0500, Jason Wang wrote:
> We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a
> lot of confusion. E.g it may break various default configs which want
> virtio devices.
>
> So this patch fixes this by hide the prompot and document the
>
> page = migration_entry_to_page(swpent);
> else if (is_device_private_entry(swpent))
> page = device_private_entry_to_page(swpent);
> + else if (is_device_exclusive_entry(swpent))
> + page =
On Thu, Feb 18, 2021 at 04:21:26PM +0100, Thomas Zimmermann wrote:
> Sure, it's at [1]. For udl, the dmabuf would need to be in system memory.
> The driver creates urbs from the framebuffer content and sends them to the
> device for displaying.
>
> My question is more: what's the best interface
On Thu, Feb 18, 2021 at 03:56:00PM +0100, Thomas Zimmermann wrote:
> I only have udl devices, but I expect that other DRM USB adapters are also
> affected.
Find where the driver calls dma_map_* itself instead of using the USB
wrappers and fix that..
On Wed, Feb 17, 2021 at 10:56:11AM +0800, Ruan Shiyang wrote:
> I'd like to confirm one thing... I have checked all of this patchset by
> checkpatch.pl and it did not report the overly long line warning. So, I
> should still obey the rule of 80 chars one line?
checkpatch.pl is completely
On Thu, Feb 18, 2021 at 08:24:23AM +, Nadav Amit wrote:
> In general, thanks for the feedback (I will reply after I follow your
> feedback). I do have a general question - I thought it was decided that
> clarity should be preferred over following the 80-column limit. Please let
> me know if I
On Tue, Feb 09, 2021 at 02:16:48PM -0800, Nadav Amit wrote:
> + /*
> + * Although we could have used on_each_cpu_cond_mask(),
> + * open-coding it has performance advantages, as it eliminates
> + * the need for indirect calls or retpolines. In
Given that the last patch killed the last previously existing
user of on_each_cpu_cond_mask there are now the only users.
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, flush_tlb_func,
> -(void *)info, 1);
> +
On Tue, Feb 09, 2021 at 02:16:46PM -0800, Nadav Amit wrote:
> +/*
> + * Flags to be used as scf_flags argument of smp_call_function_many_cond().
> + */
> +#define SCF_WAIT (1U << 0) /* Wait until function execution
> completed */
> +#define SCF_RUN_LOCAL(1U << 1) /* Run
On Wed, Feb 17, 2021 at 05:26:54PM +, Luis Henriques wrote:
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file. Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return
Looks good:
Reviewed-by: Christoph Hellwig
This whole idea of cross-device copie has always been a horrible idea,
and I've been arguing against it since the patches were posted.
On Fri, Feb 12, 2021 at 01:08:39PM +, Joao Martins wrote:
> Hey,
>
> This series improves page unpinning, with an eye on improving MR
> deregistration for big swaths of memory (which is bound by the page
> unpining), particularly:
Can you also take a look at the (bdev and iomap) direct I/O
On Wed, Feb 17, 2021 at 11:07:14AM +0800, Ming Lei wrote:
> Do you think it is correct for ioctl(BLKRRPART) to always drop/re-add
> partition device node?
Yes, that is what it is designed to do. The only reason to call this
ioctl is when userspace software has written new partition table
Your new iomremap variant needs proper documentation explaining the
semantics in detail.
On Mon, Feb 15, 2021 at 03:47:00PM +, David Howells wrote:
> Add an alternate API by which the cache can be accessed through a kiocb,
> doing async DIO, rather than using the current API that tells the cache
> where all the pages are.
>
> The new API is intended to be used in conjunction with
On Mon, Feb 15, 2021 at 03:44:52PM +, David Howells wrote:
> Provide a function, readahead_expand(), that expands the set of pages
> specified by a readahead_control object to encompass a revised area with a
> proposed size and length.
>
> The proposed area must include all of the old area
> +extern void unlock_page_private_2(struct page *page);
No need for the extern.
Otherwise this looks good:
Reviewed-by: Christoph Hellwig
On Mon, Feb 15, 2021 at 03:45:01PM +, David Howells wrote:
> Export rw_verify_area() for so that cachefiles can use it before issuing
> call_read_iter() and call_write_iter() to effect async DIO operations
> against the cache. This is analogous to aio_read() and aio_write().
I don't think
On Tue, Feb 16, 2021 at 09:29:31AM +, David Howells wrote:
> Is there a better way to do it? The intent is to process the assessment phase
> in the calling thread's context if possible rather than bumping over to a
> worker thread. For synchronous I/O, for example, that's done in the
On Sun, Feb 14, 2021 at 11:30:52AM +0800, Kyle Tso wrote:
> Export a function for other drivers to get the partner Source
> Capabilities.
>
> Signed-off-by: Kyle Tso
Who is going to use this? Please submit any new export together with
the actual user.
On Sun, Feb 14, 2021 at 12:06:11AM +, Yiwei Zhang wrote:
> The existing kthread_mod_delayed_work api will queue a new work if
> failing to cancel the current work due to no longer being pending.
> However, there's a case that the same work can be enqueued from both
> an async request and a
On Tue, Feb 16, 2021 at 05:14:55PM +0900, Tomasz Figa wrote:
> When working on the videobuf2 integration with Sergey I noticed that
> we always pass 0 as DMA attrs here, which removes the ability for
> drivers to use DMA_ATTR_ALLOC_SINGLE_PAGES.
>
> It's quite important from a system stability
e looks good:
Reviewed-by: Christoph Hellwig
On Mon, Feb 15, 2021 at 09:53:05AM -0500, Alex Xu (Hello71) wrote:
> Since maxlen is already exposed, we can allocate approximately the right
> amount directly, fixing up those drivers which set a bogus maxlen. These
> drivers were located based on those which had copy_x_user replaced in
>
On Mon, Feb 15, 2021 at 12:03:41PM +0800, Ming Lei wrote:
> Hello,
I think this is a fundamentally bad idea. We should not keep the
parsed partition state around forever just to work around some buggy
user space software.
401 - 500 of 23087 matches
Mail list logo
