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.
On Mon, Feb 15, 2021 at 10:46:23PM +, David Howells wrote:
> The in_softirq() in netfs_rreq_terminated() works fine for the cache being
> on a normal disk, as the completion handlers may get called in softirq
> context, but for an NVMe drive, the completion handler may get called in
> IRQ
Looks good,
Reviewed-by: Christoph Hellwig
ere?
Otherwise this looks good:
Reviewed-by: Christoph Hellwig
On Thu, Feb 11, 2021 at 10:08:18AM +0100, Ricardo Ribalda wrote:
> Hi Christoph
>
> What are your merge plans for the uvc change?
> http://git.infradead.org/users/hch/dma-mapping.git/commit/3dc47131f8aacc2093f68a9971d24c754e435520
>
> Are you going to remove the patch on your Merge request and
On Wed, Feb 03, 2021 at 09:54:48AM -0400, Jason Gunthorpe wrote:
> If people are accepting that these device-specific drivers are
> required then we need to come to a community consensus to decide what
> direction to pursue:
>
> * Do we embrace the driver core and use it to load VFIO modules like
On Tue, Feb 02, 2021 at 04:59:23PM -0700, Alex Williamson wrote:
> vfio-pci-igd support knows very little about the device, we're
> effectively just exposing a firmware table and some of the host bridge
> config space (read-only). So the idea that the host kernel needs to
> have updated i915
On Thu, Feb 04, 2021 at 11:12:49AM +0200, Max Gurtovoy wrote:
> But the PCI function (the bounded BDF) is GPU function or NVLINK function ?
>
> If it's NVLINK function then we should fail probing in the host vfio-pci
> driver.
>
> if its a GPU function so it shouldn't been called nvlink2
On Wed, Feb 10, 2021 at 09:34:52AM -0400, Jason Gunthorpe wrote:
> > I'm a bit confused about the change from v1 to v2, especially about
> > how to inject module specific operations. From live migration p.o.v
> > it may requires two hook points at least for some devices (e.g. i40e
> > in original
~
> ./include/linux/minmax.h:58:19: note: in expansion of macro
> ‘__careful_cmp’
> #define max(x, y) __careful_cmp(x, y, >)
>^
> kernel/dma/contiguous.c:402:35: note: in expansion of macro ‘max’
> phys_addr_t align = PAGE_SIZE << ma
On Thu, Feb 11, 2021 at 11:52:10AM +0530, Anshuman Khandual wrote:
> MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable
> for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled
> or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can
> - if (HPAGE_SHIFT > PAGE_SHIFT)
> + if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER))
No need for the braces.
On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote:
> Really what you want to do here is leave the CPU page in the VMA and
> the page tables where it started and deny CPU access to the page. Then
> all the proper machinery will continue to work.
>
> IMHO "migration" is the wrong idea
ng
> for EVA mode, too. So no need to do set_fs(KERNEL_DS) here.
>
> Signed-off-by: Thomas Bogendoerfer
Looks good,
Reviewed-by: Christoph Hellwig
... it might be time to kill off the remaining set_fs() users in mips
code as well ...
>
> If just plain bad. Those other handlers are ran from non-preemptible
> context and had better use _nofault() functions. Also, there is no
> upstream usage of this.
>
> Signed-off-by: Peter Zijlstra (Intel)
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote:
> On Wed, Feb 10, 2021 at 12:55:02PM +0000, 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 boun
> + if (XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) ||
> + (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK))) {
> + // TODO check and try to fix metadata
> + rc = -EFSCORRUPTED;
> + xfs_force_shutdown(cur->bc_mp, SHUTDOWN_CORRUPT_META);
> +static int pmem_pagemap_memory_failure(struct dev_pagemap *pgmap,
> + unsigned long pfn, int flags)
> +{
> + struct pmem_device *pdev;
> + struct gendisk *disk;
> + loff_t disk_offset;
> + int rc = 0;
> + unsigned long size = page_size(pfn_to_page(pfn));
> +
> +
> +extern int mf_dax_mapping_kill_procs(struct address_space *mapping, pgoff_t
> index, int flags);
No nee for the extern, please avoid the overly long line.
> @@ -120,6 +121,13 @@ static int hwpoison_filter_dev(struct page *p)
> if (PageSlab(p))
> return -EINVAL;
>
> +
On Mon, Feb 08, 2021 at 06:55:21PM +0800, Shiyang Ruan wrote:
> In fsdax mode, the memory failure happens on block device. So, it is
> needed to introduce an interface for block devices. Each kind of block
> device can handle the memory failure in ther own ways.
As told before: DAX operations
On Mon, Feb 08, 2021 at 06:55:20PM +0800, Shiyang Ruan wrote:
> When memory-failure occurs, we call this function which is implemented
> by each kind of devices. For the fsdax case, pmem device driver
> implements it. Pmem device driver will find out the block device where
> the error page
On Tue, Feb 09, 2021 at 05:46:13PM +0800, Ruan Shiyang wrote:
>
>
> On 2021/2/9 下午5:34, Christoph Hellwig wrote:
>> On Tue, Feb 09, 2021 at 05:15:13PM +0800, Ruan Shiyang wrote:
>>> The dax dedupe comparison need the iomap_ops pointer as argument, so my
>>> unde
On Mon, Feb 08, 2021 at 06:55:30PM +0800, Shiyang Ruan wrote:
> Since owner tarcking is triggerred by pmem device, these functions are
s/tarcking/tracking/
> useless. So remove them.
Note that this patch does not apply for me when applying your two series
on top of 5.11-rc5.
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
r()
Looks good,
Reviewed-by: Christoph Hellwig
ser().[1][2]
s/VM_BUG_ON/BUG_ON/g ?
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
CONFIG_DMA_MAYBE_COHERENT just guards two early init options now. Just
enable them unconditionally for CONFIG_DMA_NONCOHERENT.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig| 8 ++--
arch/mips/kernel/setup.c | 2 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff
Just select DMA_NONCOHERENT and ARCH_HAS_SETUP_DMA_OPS from the
MIPS_GENERIC platform instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Huacai Chen
---
arch/mips/Kconfig | 3 ++-
arch/mips/mm/dma-noncoherent.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff
the
->dma_coherent field to this default the amount of arch hooks required
for this behavior can be greatly reduced.
Signed-off-by: Christoph Hellwig
Acked-by: Greg Kroah-Hartman
---
arch/mips/Kconfig | 1 -
arch/mips/alchemy/common/setup.c | 2 +-
arch/mips/include/asm/
a bit.
Signed-off-by: Christoph Hellwig
---
arch/mips/mti-malta/malta-setup.c | 32 +--
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/arch/mips/mti-malta/malta-setup.c
b/arch/mips/mti-malta/malta-setup.c
index e1fb8b5349447e..4caff9e3b45637 100644
Factor out a alchemy_dma_coherent helper that determines if the platform
is DMA coherent. Also stop initializing the hw_coherentio variable, given
that is only ever set to a non-zero value by the malta setup code.
Signed-off-by: Christoph Hellwig
---
arch/mips/alchemy/common/setup.c | 33
Replace the global coherentio enum, and the hw_coherentio (fake) boolean
variables with a single boolean dma_default_coherent flag.
Signed-off-by: Christoph Hellwig
---
arch/mips/alchemy/common/setup.c | 3 +--
arch/mips/include/asm/dma-coherence.h | 24
arch/mips
Hi Thomas,
this series cleans up some of the mips (maybe) noncoherent support.
It also remove the need for the special header only
provided by mips.
Changes since v1:
- fix a bisection issue due to a missing brace
- simplify the parameter parsing given that it happens after
plat_mem_init
On Tue, Feb 09, 2021 at 02:12:37PM +0100, Thomas Bogendoerfer wrote:
> > +#ifdef CONFIG_DMA_MAYBE_COHERENT
> > +extern bool dma_default_coherent;
> > static inline bool dev_is_dma_coherent(struct device *dev)
> > {
> > - return coherentio == IO_COHERENCE_ENABLED ||
> > - (coherentio
On Wed, Feb 10, 2021 at 01:39:42AM +0100, Filippo Sironi wrote:
> Amazon NVMe controllers do not support 64-bit DMA addresses; they are
> limited to 48-bit DMA addresses. Let's add a quirk to ensure that we
> make use of 48-bit DMA addresses to avoid misbehavior.
This should probably say some,
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Feb 09, 2021 at 03:46:13PM +0100, Ricardo Ribalda wrote:
> Hi Christoph
>
> I have tested it in both arm and x86, since there are not significant
> changes with the previous version I did not do a performance test.
I'll take this as a Tested-by.
On Tue, Feb 09, 2021 at 04:16:20PM +0100, Jessica Yu wrote:
> Hmm, these errors don't look like it's related to that particular commit. I
> was
> able to reproduce these weird autoksym errors even without any modules-next
> patches applied, and on a clean v5.11-rc7 tree.
I OTOH can't reproduce
On Tue, Feb 09, 2021 at 12:45:11PM +, Robin Murphy wrote:
> It's not a bug, it's a fundamental design failure. dma_get_sgtable() has
> only ever sort-of-worked for DMA buffers that come from CMA or regular page
> allocations. In particular, a "no-map" DMA pool is not backed by kernel
>
On Tue, Feb 09, 2021 at 10:23:12AM +0100, Greg KH wrote:
> > From the view point of ZeroCopy using DMABUF, is 5.4 not
> > mature enough, and is 5.10 enough mature ?
> > This is the most important point for judging migration.
>
> How do you judge "mature"?
>
> And again, if a feature isn't
On Tue, Feb 09, 2021 at 05:15:13PM +0800, Ruan Shiyang wrote:
> The dax dedupe comparison need the iomap_ops pointer as argument, so my
> understanding is that we don't modify the argument list of
> generic_remap_file_range_prep(), but move its code into
> __generic_remap_file_range_prep()
On Thu, Feb 04, 2021 at 01:53:50PM +0100, Jan Kara wrote:
> Now quota data stored in a normal file is a setup we try to deprecate
> anyway so another option is to just leave quotactl_path() only for those
> setups where quota metadata is managed by the filesystem so we don't need
> to pass quota
On Tue, Feb 09, 2021 at 02:21:18PM +0800, Claire Chang wrote:
> This can be dropped if Christoph's swiotlb cleanups are landed.
> https://lore.kernel.org/linux-iommu/20210207160934.2955931-1-...@lst.de/T/#m7124f29b6076d462101fcff6433295157621da09
>
FYI, I've also started looking into additional
On Mon, Feb 08, 2021 at 12:14:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > ring buffer or whatever because you know I/O will be copied anyway
> > and none of all the hard work higher layers do to make the I/O suitable
> > for a normal device apply.
>
> I lost you here. Sorry, are you saying have
On Mon, Feb 08, 2021 at 08:33:50PM +0900, Tomasz Figa wrote:
> Sorry for the delay. The whole series looks very good to me. Thanks a lot.
>
> Reviewed-by: Tomasz Figa
Thanks.
Ricardo, do the uvcvideo changes look good to you? I'd like to queue
the series up for this merge window.
On Mon, Feb 08, 2021 at 07:26:25PM -0400, Jason Gunthorpe wrote:
> > > page_mkclean() has some technique to make the notifier have the right
> > > size without becoming entangled in the PTL locks..
> >
> > Right. I guess it's because dax doesn't have "struct page*" on the
> > back, so it
>
> It
On Mon, Feb 08, 2021 at 07:18:56PM +0100, Paolo Bonzini wrote:
> Fair enough. I would expect that pretty much everyone using follow_pfn will
> at least want to switch to this one (as it's less bad and not impossible to
> use correctly), but I'll squash this in:
Daniel looked into them, so he
On Fri, Feb 05, 2021 at 04:39:13PM +0100, Andrey Konovalov wrote:
> Export mte_enable_kernel_sync() and mte_set_report_once() to fix:
>
> ERROR: modpost: "mte_enable_kernel_sync" [lib/test_kasan.ko] undefined!
> ERROR: modpost: "mte_set_report_once" [lib/test_kasan.ko] undefined!
Please put this
On Sun, Feb 07, 2021 at 11:13:52AM -0500, Sasha Levin wrote:
> + (u8)(LINUX_VERSION_MAJOR), (u8)(LINUX_VERSION_PATCHLEVEL),
> + (u16)(LINUX_VERSION_SUBLEVEL));
No need for the casts and braces.
Otherwise this looks good, but please also kill off KERNEL_VERSION
and
> +int follow_invalidate_pte(struct mm_struct *mm, unsigned long address,
> + struct mmu_notifier_range *range, pte_t **ptepp,
> pmd_t **pmdpp,
> + spinlock_t **ptlp);
This adds a very pointless overy long line.
> +/**
> + * follow_pte - look up PTE
On Mon, Feb 08, 2021 at 04:57:33PM +0100, Maciej W. Rozycki wrote:
> > diff --git a/arch/mips/mti-malta/malta-setup.c
> > b/arch/mips/mti-malta/malta-setup.c
> > index e98cc977a735b2..f8c9663e7faa10 100644
> > --- a/arch/mips/mti-malta/malta-setup.c
> > +++ b/arch/mips/mti-malta/malta-setup.c
> >
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -977,10 +977,14 @@ xfs_free_file_space(
> if (offset + len > XFS_ISIZE(ip))
> len = XFS_ISIZE(ip) - offset;
> error = iomap_zero_range(VFS_I(ip), offset, len, NULL,
> -
On Mon, Feb 08, 2021 at 01:09:22AM +0800, Shiyang Ruan wrote:
> With dax we cannot deal with readpage() etc. So, we create a
> funciton callback to perform the file data comparison and pass
s/funciton/function/g
> +#define MIN(a, b) (((a) < (b)) ? (a) : (b))
This should use the existing min or
> static void *dax_insert_entry(struct xa_state *xas,
> struct address_space *mapping, struct vm_fault *vmf,
> - void *entry, pfn_t pfn, unsigned long flags, bool dirty)
> + void *entry, pfn_t pfn, unsigned long flags, bool insert_flags)
> {
> void
> switch (iomap.type) {
> case IOMAP_MAPPED:
> +cow:
> if (iomap.flags & IOMAP_F_NEW) {
> count_vm_event(PGMAJFAULT);
> count_memcg_event_mm(vma->vm_mm, PGMAJFAULT);
> major = VM_FAULT_MAJOR;
>
On Mon, Feb 08, 2021 at 01:09:19AM +0800, Shiyang Ruan wrote:
> dax_copy_edges() is a helper functions performs a copy from one part of
> the device to another for data not page aligned.
The function looks good to me, but adding a static function without a
user is not very bisection friendly.
Looks good,
Reviewed-by: Christoph Hellwig
an effect for alchemy.
Signed-off-by: Christoph Hellwig
---
arch/mips/kernel/setup.c | 16
arch/mips/mti-malta/malta-setup.c | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index
Just select DMA_NONCOHERENT and ARCH_HAS_SETUP_DMA_OPS from the
MIPS_GENERIC platform instead.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig | 8 ++--
arch/mips/mm/dma-noncoherent.c | 2 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/mips
Merge plat_enable_iocoherency into plat_setup_iocoherency to simplify
the code a bit.
Signed-off-by: Christoph Hellwig
---
arch/mips/mti-malta/malta-setup.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/mips/mti-malta/malta-setup.c
b/arch/mips/mti
the
->dma_coherent field to this default the amount of arch hooks required
for this behavior can be greatly reduced.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig | 9 ++---
arch/mips/alchemy/common/setup.c | 2 +-
arch/mips/include/asm/dma-coherence.h |
Replace the global coherentio enum, and the hw_coherentio (fake) boolean
variables with a single boolean dma_default_coherent flag. Only the
malta setup code needs two additional local boolean variables to
preserved the command line overrides.
Signed-off-by: Christoph Hellwig
---
arch/mips
Factor out a alchemy_dma_coherent helper that determines if the platform
is DMA coherent. Also stop initializing the hw_coherentio variable, given
that is only ever set to a non-zero value by the malta setup code.
Signed-off-by: Christoph Hellwig
---
arch/mips/alchemy/common/setup.c | 33
Hi Thomas,
this series cleans up some of the mips (maybe) noncoherent support.
It also remove the need for the special header only
provided by mips.
Any comments?
On Tue, Feb 02, 2021 at 10:51:03AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series adds the new noncontiguous DMA allocation API requested by
> various media driver maintainers.
>
> Changes since v1:
> - document that fl
The following changes since commit dd86e7fa07a3ec33c92c957ea7b642c4702516a0:
Merge tag 'pci-v5.11-fixes-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci (2021-02-04 16:05:40
-0800)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git
On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> So one thing that has been on my mind for a while: I'd really like
> to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> to swiotlb the main difference seems to be:
>
> - additional reason
On Fri, Feb 05, 2021 at 10:52:37AM +, Song Bao Hua (Barry Song) wrote:
> I assume there is no need to keep the same size with 5.11-rc, so
> could change the struct to:
>
> struct map_benchmark {
> __u64 avg_map_100ns; /* average map latency in 100ns */
> __u64 map_stddev; /*
On Fri, Feb 05, 2021 at 03:24:06PM +0100, Ulf Hansson wrote:
> On Thu, 21 Jan 2021 at 09:13, Liu Xiang wrote:
> >
> > After commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314", request is
> > completed in softirq. This may cause the system to suffer bad preemptoff
> > time.
> > The mmc driver has
On Wed, Feb 03, 2021 at 02:36:38PM -0500, Konrad Rzeszutek Wilk wrote:
> > So what? If you guys want to provide a new capability you'll have to do
> > work. And designing a new protocol based around the fact that the
> > hardware/hypervisor is not trusted and a copy is always required makes
> >
Thanks,
applied.
On Fri, Feb 05, 2021 at 10:32:26AM +, Song Bao Hua (Barry Song) wrote:
> I can keep the struct size unchanged by changing the struct to
>
> struct map_benchmark {
> __u64 avg_map_100ns; /* average map latency in 100ns */
> __u64 map_stddev; /* standard deviation of map latency */
This is a pattern we've seen in a few other net driver, so we should
be ok. It just is rather hairy and needs a good justification, which
seems to be given here.
On Fri, Feb 05, 2021 at 03:00:35PM +1300, Barry Song wrote:
> + __u32 dma_trans_ns; /* time for DMA transmission in ns */
> __u64 expansion[10];/* For future use */
We need to keep the struct size, so the expansion field needs to
shrink by the equivalent amount of data that is added
On Fri, Feb 05, 2021 at 10:17:08AM +0800, Ming Lei wrote:
> block ioctl(BLKRRPART) always drops current partitions and adds
> partitions again, even though there isn't any change in partitions table.
>
> ioctl(BLKRRPART) may be called by systemd-udevd and some disk utilities
> frequently.
Err,
So one thing that has been on my mind for a while: I'd really like
to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
to swiotlb the main difference seems to be:
- additional reasons to bounce I/O vs the plain DMA capable
- the possibility to do a hypercall on arm/arm64
-
On Tue, Feb 02, 2021 at 07:02:41PM +0100, Jan Kara wrote:
> Hum, let me think out loud. The path we pass to Q_QUOTAON is a path to
> quota file - unless the filesystem stores quota in hidden files in which
> case this argument is just ignored. You're right we could require that
> specifically for
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> This patch converts several swiotlb related variables to arrays, in
> order to maintain stat/status for different swiotlb buffers. Here are
> variables involved:
>
> - io_tlb_start and io_tlb_end
> - io_tlb_nslabs and io_tlb_used
> -
On Wed, Feb 03, 2021 at 01:23:31PM -0800, Dan Williams wrote:
> > I'd prefer to keep the helpers for now as I do find them helpful, and so far
> > nobody else who has touched the code has complained. If you feel strongly, I
> > will change it.
>
> After seeing the options, I think I'd prefer to
On Tue, Feb 02, 2021 at 10:24:18AM -0800, Ben Widawsky wrote:
> > > + /* Cap 4000h - CXL_CAP_CAP_ID_MEMDEV */
> > > + struct {
> > > + void __iomem *regs;
> > > + } mem;
> >
> > This style looks massively obsfucated. For one the comments look like
> > absolute gibberish, but also what is
On Tue, Feb 02, 2021 at 10:31:51AM -0800, Ben Widawsky wrote:
> > > + if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> > > + rc = 0;
> > > + cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> > > + if (!cxlm)
> > > + rc =
Thanks,
applied to nvme-5.12.
Please try with this extra patch:
---
>From 212764c3c15ce859e6f55d2146f450ea4ca6fdb9 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 3 Feb 2021 14:27:13 +0100
Subject: nvme-pci: fix 2nd PRP setup in nvme_setup_prp_simple
Use the dma address instead of the bio_vec off
On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> Your comment makes sense but then that would require the cooperation
> of these vendors and the cloud providers to agree on something meaningful.
> I am also not sure whether the end result would be better than hardening
> this
On Wed, Feb 03, 2021 at 12:22:31PM +0100, Filippo Sironi wrote:
> To avoid issues, it is easier to apply the quirk to all Amazon NVMe
> controllers for now till the new lines of controllers with the fix comes
> out. At that point, we'll be able to restrict the application to the known
> bad
On Wed, Feb 03, 2021 at 12:12:31PM +0100, Filippo Sironi wrote:
> I don't disagree on the first part of your sentence, this is a big
> oversight.
But it is not what your commit log suggests.
> On the other hand, those controllers are out there and are in use by a lot
> of customers. We can
On Wed, Feb 03, 2021 at 11:34:50AM +0100, Daniel Vetter wrote:
> On Thu, Jan 28, 2021 at 07:14:10PM +0100, Christoph Hellwig wrote:
> > drm_fb_helper_modinit has a lot of boilerplate for what is not very
> > simple functionality. Just open code it in the only caller using
On Wed, Feb 03, 2021 at 10:43:38AM +0100, Filippo Sironi wrote:
> Certain NVMe controllers don't support 64-bit DMA addresses. Instead,
> they are limited to 48-bit DMA addresses. Let's add a quirk to use them
> properly.
WTF? This is such a grave NVMe spec compiance bug that I do not think
we
FYI, this is the updated version:
---
>From 664ca3378deac7530fe8fc15fe73d583ddf2 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 20 Jan 2021 14:58:27 +0100
Subject: module: pass struct find_symbol_args to find_symbol
Simplify the calling convention by pass
On Tue, Feb 02, 2021 at 12:40:54PM +0800, Lu Baolu wrote:
> Intel platform VT-d (v3.2) comes with a new type of DMAR subtable
> SATC. The SATC table includes a list of SoC integrated devices
> that require SATC. OS software can use this table to enable ATS
> only for the devices in the list.
This
On Tue, Feb 02, 2021 at 02:50:17PM -0400, Jason Gunthorpe wrote:
> For uAPI compatability vfio_pci.ko would need some
> request_module()/symbol_get() trick to pass control over to the device
> specific module.
Err, don't go there.
Please do the DRIVER_EXPLICIT_BIND_ONLY thing first, which avoids
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
This has no business in a kernel header.
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 25e08e5f40bd..33432a4cbe23 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3179,6 +3179,20 @@ struct device *get_device(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(get_device);
>
> +/**
> + *
501 - 600 of 23089 matches
Mail list logo
