Dan Williams wrote:
> Dave Jiang wrote:
> >
> >
> > On 2/22/24 7:58 AM, Marek Behún wrote:
> > > A few drivers register a devm action to remove a debugfs directory,
> > > implementing a one-liner function that calls debufs_remove_recursive().
ernel.org/msg1467677.html
[3]: https://lists.xen.org/archives/html/xen-devel/2017-04/msg00419.html
---
Dan Williams (5):
vfs: add flags parameter to ->mmap() in 'struct file_operations'
fs, xfs: introduce S_IOMAP_SEALED
mm: introduce mmap3 for safely defining new mmap
On Thu, Aug 24, 2017 at 9:08 AM, Christoph Hellwig wrote:
> This seems to be missing patches 1 and 3.
Sorry, I didn't cc you directly on those. They're on the list:
https://patchwork.kernel.org/patch/9918657/
https://patchwork.kernel.org/patch/9918663/
___
On Thu, Aug 24, 2017 at 9:58 AM, Christoph Hellwig wrote:
> On Wed, Aug 23, 2017 at 04:48:40PM -0700, Dan Williams wrote:
>> We are running running short of vma->vm_flags. We can avoid needing a
>> new VM_* flag in some cases if the original @flags submitted to mmap(2)
>>
ion?
---
Dan Williams (2):
vfs: add flags parameter to ->mmap() in 'struct file_operations'
mm: introduce MAP_VALIDATE, a mechanism for for safely defining new mmap
flags
arch/arc/kernel/arc_hostlink.c |3 +
arch/mi
On Thu, Aug 31, 2017 at 3:02 AM, Christoph Hellwig wrote:
>> -static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma)
>> +static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma,
>> + unsigned long map_flags)
>> {
>> struct file *lower_fil
MAP_ flags.
Please holler if anything does not look right.
[2]: "Two more approaches to persistent-memory writes"
https://lwn.net/Articles/731706/
---
Dan Williams (2):
vfs: add flags parameter to all ->mmap() handlers
mm: introduce MAP_SHARED_VALIDATE, a mechanism t
On Fri, Jul 21, 2017 at 3:39 PM, Ross Zwisler
wrote:
> To be able to use the common 4k zero page in DAX we need to have our PTE
> fault path look more like our PMD fault path where a PTE entry can be
> marked as dirty and writeable as it is first inserted, rather than waiting
> for a follow-up dax
gma500 expects the OpRegion to be cached (i.e. not __iomem), so
explicitly map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/gma500/opregion.c |8
i-devel at lists.freedesktop.org
Signed-off-by: Dan Williams
---
This is part of the tree-wide conversion of ioremap_cache() to
memremap() targeted for v4.4 [1]
As noted in that cover letter feel free to apply or ack. These
individual conversions can go in independently given the base memremap()
impleme
-by: Dan Williams
---
drivers/gpu/drm/i915/i915_debugfs.c |2 -
drivers/gpu/drm/i915/i915_drv.h | 12 +++--
drivers/gpu/drm/i915/intel_bios.c |7 +--
drivers/gpu/drm/i915/intel_opregion.c | 73 -
drivers/gpu/drm/i915/intel_panel.c|2
conversions have landed.
[1]: https://lwn.net/Articles/653585/
[2]: commit 92281dee825f arch: introduce memremap()
---
Dan Williams (20):
x86: introduce arch_memremap()
arm: introduce arch_memremap()
ia64: introduce arch_memremap()
sh: introduce arch_memremap()
m68k
On Tue, Oct 13, 2015 at 1:24 AM, Daniel Vetter wrote:
> On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
>> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
>> > On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
>> > > i915 expects
On Mon, Oct 12, 2015 at 10:18 PM, Thomas Hellstrom
wrote:
> Hi!
>
> On 10/13/2015 12:35 AM, Dan Williams wrote:
>> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
>> expects the fifo registers to be cacheable. In preparation for
>> de
On Tue, Oct 13, 2015 at 11:37 AM, Thomas Hellstrom
wrote:
> On 10/13/2015 06:35 PM, Dan Williams wrote:
>> On Mon, Oct 12, 2015 at 10:18 PM, Thomas Hellstrom
>> wrote:
>>> Hi!
>>>
>>> On 10/13/2015 12:35 AM, Dan Williams wrote:
>>>> Per c
m-kernel&m=143735199029255&w=2
---
Dan Williams (22):
mm: enhance region_is_ram() to distinguish 'unknown' vs 'mixed'
arch, drivers: don't include directly, use instead
cleanup IORESOURCE_CACHEABLE vs ioremap()
intel_iommu: fix leaked ioremap mapping
lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/i915/intel_opregion.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 481337436f72..16ba7c67410d 100644
--- a/drivers/gpu/drm/i915
acpi_os_ioremap uses cached mappings, however it appears that gma500
wants to read dynamic platform state. Switch to ioremap() to prevent it
reading stale state from cache.
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/gma500
gma500 expects the OpRegion to be cached (i.e. not __iomem), so
explicitly map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/gma500/opregion.c |8
NULL rather than falling back silently to a different
mapping-type. This allows drivers to be stricter about the
mapping-type fallbacks that are permissible.
[1]: http://marc.info/?l=linux-arch&m=14377917405&w=2
---
Dan Williams (24):
mm: enhance region_is_ram() to region_in
-by: Dan Williams
---
drivers/gpu/drm/i915/i915_debugfs.c |2 -
drivers/gpu/drm/i915/i915_drv.h | 12 ++---
drivers/gpu/drm/i915/intel_bios.c |7 +--
drivers/gpu/drm/i915/intel_opregion.c | 87 -
drivers/gpu/drm/i915/intel_panel.c|2
[ My ears have been burning for a couple months regarding this thread
and I have finally had the chance to circle back and read through all
the discussion on PATCH 01/12 and this PATCH 08/12, pardon the latency
while I addressed some CXL backlog ]
Jason Gunthorpe wrote:
> On Mon, Jan 20, 202
David Hildenbrand wrote:
> On 05.06.25 09:46, Christoph Hellwig wrote:
> > On Wed, Jun 04, 2025 at 06:59:09PM -0700, Dan Williams wrote:
> >> +/* return normal pages backed by the page allocator */
> >> +static inline struct page *vm_normal_gfp_pmd
Jason Gunthorpe wrote:
> On Wed, Jun 04, 2025 at 07:35:24PM -0700, Dan Williams wrote:
>
> > If all dax pages are special, then vm_normal_page() should never find
> > them and gup should fail.
> >
> > ...oh, but vm_normal_page_p[mu]d() is not used in the gup path, a
David Hildenbrand wrote:
> On 05.06.25 14:09, Jason Gunthorpe wrote:
> > On Wed, Jun 04, 2025 at 07:35:24PM -0700, Dan Williams wrote:
> >
> >> If all dax pages are special, then vm_normal_page() should never find
> >> them and gup should fail.
> >>
>
_DEV goes later in the series:
Reviewed-by: Dan Williams
>
> Ensure page walkers that currently use pXd_devmap to skip DAX pages
> continue to do so by adding explicit checks of the VMA instead.
tl;dr:
Reviewed-by: Dan Williams
So I went through all the p[mu]d_devmap() checks and indeed this is the
set I also come up with that are implici
nd page table bits
> mm: Remove callers of pfn_t functionality
> mm/memremap: Remove unused devmap_managed_key
I am still reviewing the individual patches, but it is passing my tests
so you can add for the series:
Tested-by: Dan Williams
lse if (pmd_present(pmd)) {
> page = vm_normal_page_pmd(vma, addr, pmd);
> - if (page) {
> + if (page && !is_devdax_page(page) &&
> + !is_fsdax_page(page)) {
It just looks awkward to say "yup, normal page, but not *that*
t;
> Architectures that don't support pte_special also don't support pte_devmap
> so those will continue to rely on pfn_valid() to determine if the page can
> be mapped.
Looks good,
Reviewed-by: Dan Williams
rs of PFN_DEV were setting it before calling
> vmf_insert_mixed(). This is unnecessary as it is no longer checked, instead
> relying on pfn_valid() to determine if there is an associated page or not.
>
> Signed-off-by: Alistair Popple
> Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Dan Williams
by: Alistair Popple
> ---
> include/linux/huge_mm.h | 3 +-
> mm/gup.c| 162 +
> mm/huge_memory.c| 40 +--
> 3 files changed, 5 insertions(+), 200 deletions(-)
Hooray! Goodbye dev_pagemap mess in gup.c.
Reviewed-by: Dan Williams
Alistair Popple wrote:
> DAX was the only thing that created pmd_devmap and pud_devmap entries
> however it no longer does as DAX pages are now refcounted normally and
> pXd_trans_huge() returns true for those. Therefore checking both pXd_devmap
> and pXd_trans_huge() is redundant and the former ca
201 - 233 of 233 matches
Mail list logo
