Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sun, Mar 27, 2022 at 4:37 PM Halil Pasic wrote: > > > For the record, I believe that the partial revert proposed here > https://www.spinics.net/lists/linux-wireless/msg222300.html > would have been a wiser choice, than a complete revert of commit > aa6f8dcbab47 ("swiotlb: rework "fix info leak

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sun, Mar 27, 2022 at 4:52 PM Halil Pasic wrote: > > I have no intention of pursuing this. When fixing the information leak, > I happened to realize, that a somewhat similar situation can emerge when > mappings are reused. It seemed like an easy fix, so I asked the swiotlb > maintainers, and

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sun, Mar 27, 2022 at 12:23 PM Linus Torvalds wrote: > > So I will propose that we really make it very much about practical > concerns, and we document things as > > (a) the "sync" operation has by definition a "whose _future_ access > do

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sun, Mar 27, 2022 at 8:24 AM David Laight wrote: > > Aren't bounce buffers just a more extreme case on non-coherent > memory accesses? No. In fact, this whoe change came about exactly because bounce buffers are different. The difference is that bounce buffers have that (wait for it) bounce

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds wrote: > > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic wrote: > > > > I agree it CPU modified buffers *concurrently* with DMA can never work, > > and I believe the ownership model was conceived to prevent this > > situ

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic wrote: > > I agree it CPU modified buffers *concurrently* with DMA can never work, > and I believe the ownership model was conceived to prevent this > situation. But that just means that the "ownership" model is garbage, and cannot handle this REAL

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sat, Mar 26, 2022 at 3:38 PM David Laight wrote: > > Is the idea of 'buffer ownership' even a good one? I do think it might be best to not think in those terms, but literally just in data movement terms. Because the "buffer ownership" mental model is clearly confused, when data transfer

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Sat, Mar 26, 2022 at 9:06 AM Toke Høiland-Jørgensen wrote: > > I was also toying with the idea of having a copy-based peek helper like: > > u32 data = dma_peek_word(buf, offset) I really don't think you can or want to have a word-based one. That said, I like the *name* of that thing. I

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Fri, Mar 25, 2022 at 2:13 PM Johannes Berg wrote: > > Well I see now that you said 'cache "writeback"' in (1), and 'flush' in > (2), so perhaps you were thinking of the same, and I'm just calling it > "flush" and "invalidate" respectively? Yeah, so I mentally tend to think of the operations

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Fri, Mar 25, 2022 at 1:38 PM Johannes Berg wrote: > > > (2) The CPU now wants to see any state written by the device since > > the last sync > > > > This is "dma_sync_single_for_cpu(DMA_FROM_DEVICE)". > > > > A bounce-buffer implementation needs to copy *from* the bounce buffer. > > >

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Fri, Mar 25, 2022 at 12:14 PM Robin Murphy wrote: > > Note "between the DMA transfers", and not "during the DMA transfers". > The fundamental assumption of the streaming API is that only one thing > is ever accessing the mapping at any given time, which is what the whole > notion of ownership

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Fri, Mar 25, 2022 at 12:26 PM Oleksandr Natalenko wrote: > > On pátek 25. března 2022 19:30:21 CET Linus Torvalds wrote: > > The reason the ath9k issue was found quickly > > is very likely *NOT* because ath9k is the only thing affected. No, > > it's because at

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Fri, Mar 25, 2022 at 11:42 AM Robin Murphy wrote: > > Note that the current code is already a violation of the DMA > API (because the device keeps writing even when it doesn't have > ownership), so there's not a very strong argument in that regard. See my other email. I actually think that

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Fri, Mar 25, 2022 at 3:25 AM Maxime Bizon wrote: > > In the non-cache-coherent scenario, and assuming dma_map() did an > initial cache invalidation, you can write this: .. but the problem is that the dma mapping code is supposed to just work, and the driver isn't supposed to know or care

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Thu, Mar 24, 2022 at 10:07 AM Toke Høiland-Jørgensen wrote: > > Right, but is that sync_for_device call really needed? Well, imagine that you have a non-cache-coherent DMA (not bounce buffers - just bad hardware)... So the driver first does that dma_sync_single_for_cpu() for the CPU see the

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Wed, Mar 23, 2022 at 12:06 PM Robin Murphy wrote: > > On 2022-03-23 17:27, Linus Torvalds wrote: > > > > I'm assuming that the ath9k issue is that it gives DMA mapping a big > > enough area to handle any possible packet size, and just expects - > > quite reason

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

On Wed, Mar 23, 2022 at 12:19 AM Oleksandr Natalenko wrote: > > The following upstream commits: > > aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE" > ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE > > break ath9k-based Wi-Fi access point for me. The AP emits beacons,

Re: [PATCH v2 1/1] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"

On Sat, Mar 5, 2022 at 11:58 PM Christoph Hellwig wrote: > > All of thee apply to all I/O. SG_IO is just a vector here as a > particularly badly designed userspace interface that happens to get a > decent test coverage. I phrased that badly. I didn't mean SG_IO in particular, I meant any of the

Re: [PATCH v2 1/1] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"

On Sat, Mar 5, 2022 at 9:07 AM Halil Pasic wrote: > > Unfortunately, we ended up merging an old version of the patch "fix info > leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph > (the swiotlb maintainer), he asked me to create an incremental fix > (after I have pointed

Re: [git pull] IOMMU Updates for Linux v5.16

On Thu, Nov 4, 2021 at 7:16 AM Joerg Roedel wrote: > > there is a merge conflict this time between the IOMMU tree and FPU > changes which came from the tip tree. My conflict resolution is > attached. The conflict is trivial, no worries. But as I was resolving it, I looked at that PASID_DISABLED

Re: [PATCH v2 0/6] memblock: cleanup memblock_free interface

On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote: > > The first patch is a cleanup of numa_distance allocation in arch_numa I've > spotted during the conversion. > The second patch is a fix for Xen memory freeing on some of the error > paths. Well, at least patch 2 looks like something that

Re: [PATCH 0/3] memblock: cleanup memblock_free interface

On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote: > > The core change is in the third patch that makes memblock_free() a > counterpart of memblock_alloc() and adds memblock_phys_alloc() to be a ^^^ > counterpart of memblock_phys_alloc(). That should be 'memblock_phys_free()'

Re: [GIT PULL] dma-mapping fixes for Linux 5.15

On Fri, Sep 17, 2021 at 4:23 AM Christoph Hellwig wrote: > > nvme fixes for Linux 5.15 This presumably went to the wrong person for the same reason the subject line was bogus. I got these fixes through Jens, if you had an _actual_ dma-mapping branch you wanted me to pull, you did the wrong pull

Re: [PATCH] iommu: Clarify default domain Kconfig

On Wed, Sep 8, 2021 at 5:55 AM Robin Murphy wrote: > > Although strictly it is the AMD and Intel drivers which have an existing > expectation of lazy behaviour by default, it ends up being rather > unintuitive to describe this literally in Kconfig. Express it instead as > an architecture

Re: [git pull] IOMMU Updates for Linux v5.15

On Fri, Sep 3, 2021 at 7:03 AM Joerg Roedel wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git > tags/iommu-updates-v5.15 So I've merged this, but I'm not entirely happy with some of the rather insane Kconfig choices. In particular, the defaults for this: choice

Re: [GIT PULL] dma-mapping fix for Linux 5.14

On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig wrote: > > dma-mapping fix for Lonux 5.14 We're calling it "Lonux" now? > - handle vmalloc addresses in dma_common_{mmap,get_sgtable} > (Roman Skakun) I've pulled this, but my reaction is that we've tried to avoid this in the past. Why

Re: swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb) stable/for-linus-5.12)

On Fri, Jun 11, 2021 at 3:35 AM Konrad Rzeszutek Wilk wrote: > > Linus, > > Would you be terribly offended if I took your code (s/unsigned > long/unsigned int), and used Chanho's description of the problem (see below)? No offense to that at all - that looks like the right solution. See my answer

Re: swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb) stable/for-linus-5.12)

On Thu, Jun 10, 2021 at 11:21 PM Christoph Hellwig wrote: > > FYI, there has been a patch on the list that should have fixed this > for about a month: > > https://lore.kernel.org/linux-iommu/20210510091816.ga2...@lst.de/T/#m0d0df6490350a08dcc24c9086c8edc165b402d6f Honestly, that patch is all

Re: swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb) stable/for-linus-5.12)

On Thu, Jun 10, 2021 at 7:52 AM Horia Geantă wrote: > > Documentation/core-api/dma-api.rst explicitly allows for partial syncs: > Synchronise a single contiguous or scatter/gather mapping for the CPU > and device. With the sync_sg API, all the parameters must be the same > as those passed into

Re: [GIT PULL] IOMMU updates for 5.11

On Wed, Dec 16, 2020 at 2:10 PM Will Deacon wrote: > > Brill, cheers. I didn't realise you were going by subsystem, so that's > why I was getting worried. My "by subsystem" is a bit fuzzy, and it only really happens when I have a _lot_ of pending pull requests. Which this merge window has had

Re: [GIT PULL] IOMMU updates for 5.11

On Wed, Dec 16, 2020 at 10:54 AM Will Deacon wrote: > > I'm hoping to wind down a bit next week (ho ho ho), so I just wanted to > check whether this had got caught in your spam filters, whether you wanted > me to change something or whether you're just snowed under in pull requests. No, it

Re: [GIT PULL] IOMMU fix for 5.10 (-final)

On Wed, Dec 9, 2020 at 11:12 AM Jerry Snitselaar wrote: > > Since the field in the device table entry format expects it to be n > where there are 2^n entries in the table I guess it should be: > > #define DTE_IRQ_TABLE_LEN 9 > #define MAX_IRQS_PER_TABLE (1 << DTE_IRQ_TABLE_LEN) No, that

Re: [GIT PULL] dma-mapping fix for 5.10

On Sat, Oct 31, 2020 at 2:40 AM Christoph Hellwig wrote: > > dma-mapping fix for 5.10: > > - fix an integer overflow on 32-bit platforms in the new DMA range code >(Geert Uytterhoeven) So this is just a stylistic nit, and has no impact on this pull (which I've done). But looking at the

Re: [git pull] IOMMU Updates for Linux v5.10

On Tue, Oct 13, 2020 at 9:04 AM Joerg Roedel wrote: > > there is a minor conflict this time in include/linux/iommu.h which > should be easy to resolve. I would attach my resolution, but somehow git > [show|log] didn't show it to me. So when a resolution takes one side over the other (as opposed

Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock()

On Fri, Aug 14, 2020 at 5:26 PM Hugh Dickins wrote: > > We used to rely on page count there, and on trylock_page() only; but > there was at least one user whose app went wrong when occasionally we > COWed the page, just because something else momentarily took a reference > to it, or locked it.

Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock()

On Thu, Aug 13, 2020 at 10:42 PM Christoph Hellwig wrote: > > The whole thing predates my involvement with the code, but I defintively > think the patch from Hugh is a major improvement. But I would also > have no problem with just removing it entirely. I decided to just do both, since neither

Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock()

On Wed, Aug 12, 2020 at 8:17 PM Hugh Dickins wrote: > > Since commit 2a9127fcf229 ("mm: rewrite wait_on_page_bit_common() logic") > improved unlock_page(), it has become more noticeable how cow_user_page() > in a kernel with CONFIG_DMA_API_DEBUG=y can create and suffer from heavy > contention on

Re: revert scope for 5.8, was Re: dma-pool fixes

On Sat, Aug 1, 2020 at 4:57 AM Amit Pundir wrote: > > Hi, I found the problematic memory region. It was a memory > chunk reserved/removed in the downstream tree but was > seemingly reserved upstream for different drivers. Is this happening with a clean tree, or are there external drivers

Re: [git pull] iommu: Move Intel and AMD drivers to a subdirectory

On Fri, Jun 12, 2020 at 8:22 AM Joerg Roedel wrote: > > I am not sure it is the right time to send this. Looks good to me. Any time a directory starts to have a lot of filenames with a particular prefix, moving them deeper like this seems to make sense. And doing it just before the -rc1 release

Re: [git pull] IOMMU Fixes for Linux v5.7-rc4

On Sun, May 10, 2020 at 5:26 AM Joerg Roedel wrote: > >The first race condition was around > the non-atomic update of the domain page-table root pointer > and the variable containing the page-table depth (called > mode). This is fixed now be merging

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

On Wed, Mar 11, 2020 at 10:21 AM Artem S. Tashkinov wrote: > > I've been able to compile and run > e3a36eb6dfaeea8175c05d5915dcf0b939be6dab successfully. I won't claim > this patch doesn't break something for other people :-) Thanks, that's all I was looking for. If it breaks something for

Re: [PATCH] device core: fix dma_mask handling in platform_device_register_full

On Wed, Mar 11, 2020 at 10:18 AM Greg KH wrote: > > Is this still needed with the patch that Linus just committed to his > tree? My patch is basically the same, just with the field renamed too, and not blindly just assigning to "*pdev->dev.dma_mask" (my variant does

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

On Wed, Mar 11, 2020 at 9:24 AM Linus Torvalds wrote: > > So it will have a different commit ID, updated message, and be a mix > of my patch and Christoph's. I ended up pushing it out before starting on the pull requests, so it's out there now. Artem, it would be good to have con

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

On Wed, Mar 11, 2020 at 9:21 AM Linus Torvalds wrote: > > It's commit e423fb6929d4 ("driver code: clarify and fix platform > device DMA mask allocation") in my tree. I've not pushed it out yet (I > have a few pending pull requests), but it should be out shortly. Actually, l

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

On Wed, Mar 11, 2020 at 9:02 AM Artem S. Tashkinov wrote: > > With this patch the system works (I haven't created an initrd, so it > doesn't completely boot and panics on not being able to mount root fs > but that's expected). Perfect. I ended up applying my earlier cleanup patch with just the

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

On Wed, Mar 11, 2020 at 8:53 AM Artem S. Tashkinov wrote: > > I'm not sure I can call or do anything because the system is dead and > I'm looking at the kernel panic message. The console is dead. The root > file system is not yet mounted. Initrd can't be loaded either. I have no > COM

Re: [PATCH v3] iommu: fix KASAN use-after-free in iommu_insert_resv_region

On Mon, Dec 16, 2019 at 6:36 AM Auger Eric wrote: >On 12/16/19 3:24 PM, Qian Cai wrote: > > > > Looks like Joerg is away for a few weeks. Could Andrew or Linus pick up this > > use-after-free? I've taken it. > Note the right version to pick up is the v4, reviewed by Jerry: >

Re: [GIT PULL] dma-mapping updates for 5.4

On Wed, Sep 18, 2019 at 8:27 AM Christoph Hellwig wrote: > > please pull the dma-mapping updates for 5.4. Pulled. > In addition to the usual Kconfig conflics where you just want to keep > both edits there are a few more interesting merge issues this time: > > - most importanly powerpc and

Re: [PATCH v2] iommu/amd: fix a crash in iova_magazine_free_pfns

On Thu, Jul 11, 2019 at 9:18 AM Qian Cai wrote: > > The commit b3aa14f02254 ("iommu: remove the mapping_error dma_map_ops > method") incorrectly changed the checking from dma_ops_alloc_iova() in > map_sg() causes a crash under memory pressure as dma_ops_alloc_iova() > never return

Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Linus Torvalds wrote: > > > With SMEP, user space pages are always NX. > > We talk past each other. The user space page in the ring3 valid virtual > address space (non negative) is of

Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote: > > It's not necessarily a W+X issue. The user space text is mapped in the > kernel as well and even if it is mapped RX then this can happen. So any > kernel mappings of user space text need to be mapped NX! With SMEP, user space pages are

Re: [GIT PULL] remove dma_zalloc_coherent

On Sat, Jan 12, 2019 at 10:14 AM Christoph Hellwig wrote: > > Lets see if this works better as a pull request than the > plain patches: So I'm still debating this myself, which is why I haven't reacted. The reason I'm not entirely sure this makes sense is that not every user actually mmaps

Re: [RFC] avoid indirect calls for DMA direct mappings

On Thu, Dec 6, 2018 at 10:43 AM Christoph Hellwig wrote: > > > > > (a) the dma_is_direct() function/macro uses "likely()" for the test > > I'm a little worried about that. Yes, for the common case it is > likely. But if you run a setup where you say always have an iommu > it is not, in fact it

Re: [RFC] avoid indirect calls for DMA direct mappings

On Thu, Dec 6, 2018 at 10:28 AM Linus Torvalds wrote: > > Put another way, you made the fast case unnecessarily slow. Side note: the code seems to be a bit confused about it, because *some* cases test the fast case first, and some do it after they've already accessed the pointer for th

Re: remove the ->mapping_error method from dma_map_ops V3

On Fri, Nov 30, 2018 at 5:23 AM Christoph Hellwig wrote: > > Error reporting for the dma_map_single and dma_map_page operations is > currently a mess. [..] I don't see anything objectionable there, but it's not like I checked any of the context of the patches. For all I know there are odd corner

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 29, 2018 at 10:31 AM Christoph Hellwig wrote: > > > Or, better yet, plan on removing the single-page dma mappign entirely > > at a later date, and make the issue moot. > > What would be the replacement? Build a S/G list for every single page > mapping? Not sure that would create a

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote: > > We can. At least in theory. The problem is that depending on the > crazy mapping from physical and kernel virtual address to dma addresses > these might be pages at pretty random places. Look at fun like >

Re: remove the ->mapping_error method from dma_map_ops V2

On Wed, Nov 28, 2018, 10:08 Russell King - ARM Linux > > > You already cannot do that kmalloc(), exactly because of ERR_PTR(). > > I'm very sorry, but I think you are confused. > > kmalloc() returns a _virtual_ address, which quite rightly must not be > in the top 4K of 4GB, exactly due to

Re: remove the ->mapping_error method from dma_map_ops V2

On Wed, Nov 28, 2018 at 9:45 AM Russell King - ARM Linux wrote: > > > I don't think this is a huge deal, but ERR_PTR() has been hugely > > successful elsewhere. And I'm not hugely convinced about all these > > "any address can be valid" arguments. How the hell do you generate a > > random dma

Re: remove the ->mapping_error method from dma_map_ops V2

On Tue, Nov 27, 2018 at 11:41 PM Christoph Hellwig wrote: > > On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote: > > Well, I can tweak the last patch to return -EINVAL from dma_mapping_error > > instead of the old 1 is as bool true. The callers should all be fine, > > although

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote: > > Unfortunately, with things like the top-down IOVA allocator, and 32-bit > systems in general, "the top 4095" values may well still be valid > addresses - Ugh. > The only immediate benefit I can see is that we could distinguish cases > like

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux wrote: > > I'm afraid that won't work very well - 32 bit platforms with 64-bit > addresses (LPAE) would have dma_addr_t as a 64-bit value, which > wouldn't fit into an unsigned long. Good point. So we'd have to have a special IS_DMA_ERR()

Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote: > > The 0 return doesn't work for direct mappings that have ram at address > zero and a lot of IOMMUs that start allocating bus space from address > zero, so we can't consolidate on that, but I think we can move everyone > to all-Fs, which

Re: [GIT PULL] dma-mapping fix for 4.20

On Sat, Nov 3, 2018 at 1:42 AM Christoph Hellwig wrote: > > Avoid compile warnings on non-default arm64 configs Pulled, Linus ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [GIT PULL] second round of dma mapping updates for 4.20

On Fri, Oct 26, 2018 at 6:24 AM Christoph Hellwig wrote: > > Second batch of dma-mapping updates for 4.20: Pulled, Linus ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [git pull] IOMMU Updates for Linux v4.20

On Fri, Oct 26, 2018 at 4:27 AM Joerg Roedel wrote: > > IOMMU Updates for Linux v4.20 Thanks, pulled, Linus ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [git pull] IOMMU Updates for Linux v4.19

On Fri, Aug 24, 2018 at 6:01 AM Joerg Roedel wrote: > > note that this time there is a trivial conflict when merging this into > your tree. The conflict is in drivers/iommu/ipmmu-vmsa.c, apparently > some other tree also added DT matching entries there. No, the IOMMU_OF_DECLARE() thing went away

Re: [GIT PULL] dma-mapping file renames for Linux 4.18

On Tue, Jun 19, 2018 at 1:44 PM Christoph Hellwig wrote: > > below is a rename of the assorted dma-mapping files to that they live > under kernel/dma and lose their dma-* prefixes. If there is any time > to do this it is right after -rc1, so let me know if this is something > you'd take. I iwas

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote: > > Note this is barely tested. I intend to do more testing of next few days > but i do not have access to all hardware that make use of the mmu_notifier > API. Thanks for doing this. > First 2 patches convert existing

Re: [git pull] IOMMU Updates for Linux v4.13

On Wed, Jul 12, 2017 at 4:42 AM, Joerg Roedel wrote: > > Doing the pull-request against v4.12 blows up the diffstat, so I decided > to do the request against the last merge-base. Please let me know if I > should merge against v4.12 and re-send the request. No, this is the right

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote: > > This patch changes all users of IS_ERR_VALUE() that I could find > on 32-bit ARM randconfig builds and x86 allmodconfig. For the > moment, this doesn't change the definition of IS_ERR_VALUE() > because there are probably

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 2:46 PM, Andrew Morton wrote: > > So you do plan to add some sort of typechecking into IS_ERR_VALUE()? The easiest way to do it is to just turn the (x) into (unsigned long)(void *)(x), which then complains about casting an integer to a pointer

Re: [PATCH 4/4] iommu/vt-d: Do access checks before calling handle_mm_fault()

On Tue, Nov 10, 2015 at 5:26 AM, Joerg Roedel wrote: > + > +static bool access_error(struct vm_area_struct *vma, struct page_req_dsc > *req) > +{ > + return !((req->rd_req && (vma->vm_flags & VM_READ)) || > +(req->wr_req && (vma->vm_flags & VM_WRITE)) ||

Re: [GIT PULL] IOVA fix for 4.3

On Wed, Sep 30, 2015 at 11:49 AM, David Woodhouse wrote: > > Linus, please pull from > > git://git.infradead.org/intel-iommu.git Umm. What happened to this pull request? I want to see the expected diffstat in addition to the shortlog... Linus

Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, Sep 15, 2015 at 6:45 AM, Steven Rostedt wrote: > > Linus, This patch changes a lot of u32s into bools in structures. > What's your take on that? So in general, I'd tend to prefer "bool" to be used primarily as a return value for functions, but I have to say, in the

Re: [git pull] IOMMU Updates for Linux v4.2

On Tue, Jun 23, 2015 at 2:24 AM, Joerg Roedel j...@8bytes.org wrote: I attached my resolution of the conflicts to this pull-request and compiled and run-time tested my resolution on an Intel VT-d and an AMD IOMMU machine. Hmm. My resolution doesn't look the same at all, but that could easily

Re: [GIT PULL] Intel IOMMU for 4.1

On Mon, Apr 27, 2015 at 8:39 AM, Alex Williamson alex.william...@redhat.com wrote: Since this got pulled anyway, do you plan to follow-up with patches to limit the graphics RMRR exception to the known and acceptable uses and document them, or should I send a revert patch? I don't think what

Re: [PATCH 1/2] drivers: Move iommu/ before gpu/ in Makefile

On Tue, Dec 23, 2014 at 4:09 AM, Oded Gabbay oded.gab...@amd.com wrote: Hello Linus, Dave Airlie asked me to send this patch to you for review. I'm not entirely happy about the fix, since we generally *should* order things by the different init-levels, but we've done the link order thing

Re: [git pull] IOMMU Fixes for Linux v3.16-rc2

Joerg, this email was in my spam-box. No real indication as to why, although the usual suspect is Received-SPF: none (google.com: j...@8bytes.org does not designate permitted sender hosts) client-ip=85.214.48.195; presumably together with some other trigger that makes gmail unhappy. Anyway,

Re: [GIT PULL (PATCH 0/4)] VFIO driver for v3.6

On Mon, Jul 30, 2012 at 4:17 PM, Alex Williamson alex.william...@redhat.com wrote: I'm pretty anxious to find out as well. Linus, ping, any thoughts on including this in 3.6? Thanks, I just pulled it, but then I unpulled again when I realized it's not a signed tag and it's on github.