On Wed, Feb 21, 2024 at 8:49 PM Vilas Bhat wrote:
>
> Existing runtime PM ftrace events (`rpm_suspend`, `rpm_resume`,
> `rpm_return_int`) offer limited visibility into the exact timing of device
> runtime power state transitions, particularly when asynchronous operations
> are involved. When the
On Fri, Feb 2, 2024 at 4:49 PM Andy Shevchenko
wrote:
>
> On Mon, Nov 20, 2023 at 07:19:44PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 20, 2023 at 04:11:54PM +0100, Rafael J. Wysocki wrote:
> > > On Mon, Nov 20, 2023 at 4:03 PM Andy Shevchenko
> > > wrote:
>
On Mon, Jan 22, 2024 at 02:02:28PM -0800, Linus Torvalds wrote:
> On Mon, 22 Jan 2024 at 13:59, Darrick J. Wong wrote:
> >
> > though I don't think
> > leaking raw kernel pointers is an awesome idea.
>
> Yeah, I wasn't all that comfortable even with trying to
On Tue, Jan 16, 2024 at 05:55:32PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The dentries and inodes are created in the readdir for the sole purpose of
> getting a consistent inode number. Linus stated that is unnecessary, and
> that all inodes can have the same inode
On Thu, Dec 21, 2023 at 8:57 PM Rafael J. Wysocki wrote:
>
> On Thu, Dec 21, 2023 at 4:24 PM Vincent Guittot
> wrote:
> >
> > Provide to the scheduler a feedback about the temporary max available
> > capacity. Unlike arch_update_thermal_pressure, this does
policy)
> +{
> + unsigned long max_capacity, capped_freq, pressure;
> + u32 max_freq;
> + int cpu;
> +
> + cpu = cpumask_first(policy->related_cpus);
> + pressure = max_capacity = arch_scale_cpu_capacity(cpu);
I would prefer two separate state
On Thu, Dec 14, 2023 at 10:07 AM Lukasz Luba wrote:
>
> On 12/14/23 07:57, Vincent Guittot wrote:
> > On Thu, 14 Dec 2023 at 06:43, Viresh Kumar wrote:
> >>
> >> On 12-12-23, 15:27, Vincent Guittot wrote:
> >>> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy
> >>>
On Mon, Nov 20, 2023 at 4:03 PM Andy Shevchenko
wrote:
>
> On Thu, Oct 19, 2023 at 06:03:28PM -0700, Dan Williams wrote:
> > Andy Shevchenko wrote:
> > > The acpi_evaluate_dsm_typed() provides a way to check the type of the
> > > object evaluated by _DSM call. Use it instead of open coded
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-6.6-rc8
with top-most commit 9b311b7313d6c104dd4a2d43ab54536dce07f960
ACPI: NFIT: Install Notify() handler before getting NFIT table
on top of commit
On Fri, Oct 13, 2023 at 2:22 PM Kuan-Wei Chiu wrote:
>
> The original code used conditional branching in the nfit_mem_cmp
> function to compare two values and return -1, 1, or 0 based on the
> result. However, the list_sort comparison function only needs results
> <0, >0, or =0. This patch
On Wed, Oct 18, 2023 at 6:28 AM Dan Williams wrote:
>
> Michal Wilczynski wrote:
> > The new cleanup.h facilities that arrived in v6.5-rc1 can replace the
> > the usage of devm semantics in acpi_nfit_init_interleave_set(). That
> > routine appears to only be using devm to avoid goto statements.
tioning of the whole devm_*() family of
> functions, since the lifecycle of the device stays the same. It is still
> being created during the enumeration, and destroyed on platform device
> removal.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Mic
On Wed, Oct 11, 2023 at 10:34 AM Michal Wilczynski
wrote:
>
> Since transformation from ACPI driver to platform driver there are two
> devices on which the driver operates - ACPI device and platform device.
> For the sake of reader this calls for the distinction in their naming,
> to avoid
FIT driver uses devm_*() family of functions extensively. This change
> > has no impact on correct functioning of the whole devm_*() family of
> > functions, since the lifecycle of the device stays the same. It is still
> > being created during the enumeration, and destroyed
On Wed, Oct 11, 2023 at 10:34 AM Michal Wilczynski
wrote:
>
> Use modern string_choices API instead of manually determining the
> output using ternary operator.
>
> Suggested-by: Andy Shevchenko
> Reviewed-by: Andy Shevchenko
> Signed-off-by: Michal Wilczynski
> ---
> drivers/acpi/ac.c | 5
On Wed, Oct 11, 2023 at 10:34 AM Michal Wilczynski
wrote:
>
> Remove unnecessary checks for NULL for variables that can't be NULL at
> the point they're checked for it. Defensive programming is discouraged
> in the kernel.
>
> Signed-off-by: Michal Wilczynski
> ---
> drivers/acpi/ac.c | 27
On Mon, Oct 9, 2023 at 3:04 PM Wilczynski, Michal
wrote:
>
>
>
> On 10/9/2023 2:27 PM, Rafael J. Wysocki wrote:
> > On Mon, Oct 9, 2023 at 10:40 AM Wilczynski, Michal
> > wrote:
> >>
[cut]
> >> Yeah we could add platform device without removing acpi
On Mon, Oct 9, 2023 at 10:40 AM Wilczynski, Michal
wrote:
>
>
> Hi !
>
> Thanks a lot for a review, to both of you ! :-)
>
> On 10/7/2023 12:43 PM, Rafael J. Wysocki wrote:
> > On Sat, Oct 7, 2023 at 12:41 PM Rafael J. Wysocki wrote:
> >> On Sat, Oc
On Sat, Oct 7, 2023 at 12:41 PM Rafael J. Wysocki wrote:
>
> On Sat, Oct 7, 2023 at 9:56 AM Andy Shevchenko
> wrote:
> >
> > On Fri, Oct 06, 2023 at 09:47:57PM +0200, Rafael J. Wysocki wrote:
> > > On Fri, Oct 6, 2023 at 8:33 PM Michal Wilczynski
> > >
On Sat, Oct 7, 2023 at 9:56 AM Andy Shevchenko
wrote:
>
> On Fri, Oct 06, 2023 at 09:47:57PM +0200, Rafael J. Wysocki wrote:
> > On Fri, Oct 6, 2023 at 8:33 PM Michal Wilczynski
> > wrote:
>
> ...
>
> > > struct acpi_ac {
> > > struc
lank line to distinguish pdev API vs local ACPI notify function.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Michal Wilczynski
> ---
> drivers/acpi/ac.c | 70 +--
> 1 file changed, 37 insertions(+), 33 deletions(-)
&g
On Thu, Oct 5, 2023 at 10:39 PM Wilczynski, Michal
wrote:
>
>
>
> On 10/5/2023 8:28 PM, Wilczynski, Michal wrote:
> >
> > On 10/5/2023 7:57 PM, Rafael J. Wysocki wrote:
> >> On Monday, September 25, 2023 4:48:35 PM CEST Michal Wilczynski wrote:
> >>>
On Thu, Oct 5, 2023 at 8:27 PM Wilczynski, Michal
wrote:
>
>
>
> On 10/5/2023 7:03 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 5, 2023 5:30:59 PM CEST Rafael J. Wysocki wrote:
> >> On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
> >> wrote:
&
device interfaces with the FW, and the platform device with the rest of
> +the system.
> +
> DMA support
> ===
I rewrote the above entirely, so here's a new patch to replace this one:
---
From: Rafael J. Wysocki
Subject: [PATCH v2 2/9] ACPI: docs: enumeration: Clarify ACPI bus conc
On Thursday, October 5, 2023 5:30:59 PM CEST Rafael J. Wysocki wrote:
> On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
> wrote:
> > On 10/5/2023 12:57 PM, Rafael J. Wysocki wrote:
> > > On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
> > > wrote:
>
>
On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
wrote:
> On 10/5/2023 12:57 PM, Rafael J. Wysocki wrote:
> > On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
> > wrote:
[cut]
> >>>
> >>> That said, why exactly is it better to use acpi_handle instea
On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
wrote:
>
> Hi,
>
> Thanks for your review !
>
> On 10/4/2023 9:09 PM, Rafael J. Wysocki wrote:
> > On Mon, Sep 25, 2023 at 6:31 PM Michal Wilczynski
> > wrote:
> >> acpi_dev_install_notify_handl
On Mon, Sep 25, 2023 at 6:31 PM Michal Wilczynski
wrote:
>
> acpi_dev_install_notify_handler() and acpi_dev_remove_notify_handler()
> are wrappers around ACPICA installers. They are meant to save some
> duplicated code from drivers. However as we're moving towards drivers
> operating on
On 9/26/23 1:34 AM, Christoph Hellwig wrote:
On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
Is there anyone you know of that we could approach to determine a proper
SPDX License for these files?
Answering this question generally, even though it sounds like it wasn't
On Mon, Jul 3, 2023 at 10:03 AM Michal Wilczynski
wrote:
>
> *** IMPORTANT ***
> This is part 1 - only drivers in acpi directory to ease up review
> process. Rest of the drivers will be handled in separate patchsets.
>
> Currently drivers support ACPI event handlers by defining .notify
> callback
On Mon, Jul 3, 2023 at 10:03 AM Michal Wilczynski
wrote:
>
> Nfit driver doesn't use .remove() callback and provide an empty function
> as it's .remove() callback. Remove empty acpi_nfit_remove() and
> initialization of callback.
>
> Suggested-by: Dan Williams
> Signed-off-by: Michal Wilczynski
gt; Move acpi_nfit_notify() upwards in the file, so it can be used inside
> acpi_nfit_add() and acpi_nfit_remove_notify_handler().
Dan, any objections?
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Michal Wilczynski
> ---
> drivers/acpi/nfit/core.c | 41 +++
On Mon, Jul 3, 2023 at 3:01 PM Ben Dooks wrote:
>
> Some of the fields in struct acpi_nfit_control_region are used in big
> endian format, and thus are generatng warnings from spare where the
> member is passed to one of the conversion functions.
>
> Fix the following sparse warnings by changing
On Fri, Jun 30, 2023 at 1:04 PM Rafael J. Wysocki wrote:
>
> On Fri, Jun 30, 2023 at 11:52 AM Wilczynski, Michal
> wrote:
> >
> >
> >
> > On 6/29/2023 6:14 PM, Rafael J. Wysocki wrote:
> > > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > >
On Fri, Jun 30, 2023 at 11:52 AM Wilczynski, Michal
wrote:
>
>
>
> On 6/29/2023 6:14 PM, Rafael J. Wysocki wrote:
> > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > wrote:
> >> Currently terminator line contains redunant characters.
> > Well, they a
On Fri, Jun 30, 2023 at 11:55 AM Wilczynski, Michal
wrote:
>
>
>
> On 6/29/2023 6:18 PM, Rafael J. Wysocki wrote:
> > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > wrote:
> >> Currently logic for installing notifications from ACPI devices is
>
On Fri, Jun 30, 2023 at 11:48 AM Wilczynski, Michal
wrote:
>
>
>
> On 6/29/2023 6:06 PM, Rafael J. Wysocki wrote:
> > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > wrote:
> >> To use new style of installing event handlers acpi_nfit_notify() needs
>
On Fri, Jun 30, 2023 at 11:41 AM Rafael J. Wysocki wrote:
>
> On Fri, Jun 30, 2023 at 11:39 AM Wilczynski, Michal
> wrote:
> >
> >
> >
> > On 6/29/2023 5:55 PM, Rafael J. Wysocki wrote:
> > > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> >
On Fri, Jun 30, 2023 at 11:39 AM Wilczynski, Michal
wrote:
>
>
>
> On 6/29/2023 5:55 PM, Rafael J. Wysocki wrote:
> > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > wrote:
> >> Currently logic for installing notifications from ACPI devices is
>
() at the beginning of .remove()
> callback. Change arguments passed to the notify function to match with
> what's required by acpi_install_notify_handler(). Remove .notify
> callback initialization in acpi_driver.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Michal Wi
On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
wrote:
>
> Currently terminator line contains redunant characters.
Well, they are terminating the list properly AFAICS, so they aren't
redundant and the size of it before and after the change is actually
the same, isn't it?
> Remove them and
On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
wrote:
>
> To use new style of installing event handlers acpi_nfit_notify() needs
> to be known inside acpi_nfit_add(). Move acpi_nfit_notify() upwards in
> the file, so it can be used inside acpi_nfit_add().
>
> Signed-off-by: Michal Wilczynski
() at the beginning of .remove()
> callback. Change arguments passed to the notify function to match with
> what's required by acpi_install_notify_handler(). Remove .notify
> callback initialization in acpi_driver.
>
> While at it, fix lack of whitespaces in .remove() callback.
>
> Sugge
() at the beginning of .remove()
> callback. Change arguments passed to the notify function to match with
> what's required by acpi_install_notify_handler(). Remove .notify
> callback initialization in acpi_driver.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Michal Wil
() at the beginning of .remove()
> callback. Change arguments passed to the notify function to match with
> what's required by acpi_install_notify_handler(). Remove .notify
> callback initialization in acpi_driver.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Mi
On Mon, May 22, 2023 at 5:22 PM Dave Jiang wrote:
>
>
>
> On 5/16/23 1:14 PM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The nfit_intel_shutdown_status() function has a __weak defintion
> > in nfit.c and an override in acpi_nfit_test.c for testing
> > purposes. This works without an
On Mon, Mar 20, 2023 at 06:02:05PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/3/18 4:35, Darrick J. Wong 写道:
> > On Fri, Mar 17, 2023 at 03:59:48AM +, Shiyang Ruan wrote:
> > > As is mentioned[1] before, the generic/388 will randomly fail with dmesg
> > >
On Fri, Mar 17, 2023 at 03:59:48AM +, Shiyang Ruan wrote:
> As is mentioned[1] before, the generic/388 will randomly fail with dmesg
> warning. This case uses fsstress with a lot of random operations. It is hard
> to reproduce. Finally I found a 100% reproduce condition, which is setting
>
the flag needs to be renamed to PAGE_MAPPING_DAX_SHARED.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Allison Henderson
Looks fine to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 38 ++
> include/linux/m
On Mon, Dec 05, 2022 at 01:56:24PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/12/3 10:07, Dan Williams 写道:
> > Shiyang Ruan wrote:
> > > fsdax page is used not only when CoW, but also mapread. To make the it
> > > easily understood, use 'share' to indicate that the dax page is shared
> > > by more
On Thu, Dec 01, 2022 at 03:32:53PM +, Shiyang Ruan wrote:
> Since the basic function for fsdax and reflink has been implemented,
> remove the restrictions of them for widly test.
>
> Signed-off-by: Shiyang Ruan
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/x
On Thu, Dec 01, 2022 at 03:32:10PM +, Shiyang Ruan wrote:
> Zero and truncate on a dax file may execute CoW. So use dax ops which
> contains end work for CoW.
>
> Signed-off-by: Shiyang Ruan
LGTM
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_iomap.c | 4 ++--
&g
them called at the same time.
>
> Signed-off-by: Shiyang Ruan
Thank you for adding that explanation, it makes the problem much more
obvious. :)
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --
;
> Signed-off-by: Shiyang Ruan
Makes sense.
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 19 +++
> fs/xfs/xfs_iomap.c | 2 +-
> 2 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 6b6e07ad8d8
* dax_iomap_cow_copy - Copy the data from source to destination before write
> + * dax_iomap_copy_around - Copy the data from source to destination before
> write
* dax_iomap_copy_around - Prepare for an unaligned write to a
* shared/cow page by copying the data before and after the range to be
On Thu, Dec 01, 2022 at 11:39:12PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/12/1 5:08, Darrick J. Wong 写道:
> > On Tue, Nov 29, 2022 at 11:05:30PM -0800, Dan Williams wrote:
> > > Darrick J. Wong wrote:
> > > > On Tue, Nov 29, 2022 at 07:59:14PM -0800, Dan Wi
share state when CoW happens, in both dax_iomap_rw() and
> dax_zero_iter().
>
> Signed-off-by: Shiyang Ruan
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/fs/d
On Thu, Dec 01, 2022 at 03:28:51PM +, Shiyang Ruan wrote:
> fsdax page is used not only when CoW, but also mapread. To make the it
> easily understood, use 'share' to indicate that the dax page is shared
> by more than one extent. And add helper functions to use it.
>
> Also, the flag needs
On Wed, Nov 30, 2022 at 01:48:59PM -0800, Dan Williams wrote:
> Andrew Morton wrote:
> > On Tue, 29 Nov 2022 19:59:14 -0800 Dan Williams
> > wrote:
> >
> > > [ add Andrew ]
> > >
> > > Shiyang Ruan wrote:
> > > > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > > >
On Tue, Nov 29, 2022 at 11:05:30PM -0800, Dan Williams wrote:
> Darrick J. Wong wrote:
> > On Tue, Nov 29, 2022 at 07:59:14PM -0800, Dan Williams wrote:
> > > [ add Andrew ]
> > >
> > > Shiyang Ruan wrote:
> > > > Many testcases failed i
On Wed, Nov 30, 2022 at 04:58:32PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/11/30 12:08, Darrick J. Wong 写道:
> > On Thu, Nov 24, 2022 at 02:54:53PM +, Shiyang Ruan wrote:
> > > This patch fixes the warning message reported in dax_associate_entry()
> >
On Tue, Nov 29, 2022 at 07:59:14PM -0800, Dan Williams wrote:
> [ add Andrew ]
>
> Shiyang Ruan wrote:
> > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > This also effects dax+noreflink mode if we run the test after a
> > dax+reflink test. So, the most urgent thing
On Thu, Nov 24, 2022 at 02:54:53PM +, Shiyang Ruan wrote:
> This patch fixes the warning message reported in dax_associate_entry()
> and dax_disassociate_entry().
Hmm, that's quite a bit to put in a single patch, but I'll try to get
through this...
> 1. reset page->mapping and ->index when
On Thu, Nov 24, 2022 at 02:54:54PM +, Shiyang Ruan wrote:
> Implement unshare in fsdax mode: copy data from srcmap to iomap.
>
> Signed-off-by: Shiyang Ruan
Heh, I had a version nearly like this in my tree. Makes reviewing
easier:
Reviewed-by: Darrick J. Wong
--D
> ---
On Mon, Nov 28, 2022 at 10:16:23AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/11/28 2:38, Darrick J. Wong 写道:
> > On Thu, Nov 24, 2022 at 02:54:52PM +, Shiyang Ruan wrote:
> > > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > > Thi
On Thu, Nov 24, 2022 at 02:54:52PM +, Shiyang Ruan wrote:
> Many testcases failed in dax+reflink mode with warning message in dmesg.
> This also effects dax+noreflink mode if we run the test after a
> dax+reflink test. So, the most urgent thing is solving the warning
> messages.
>
> Patch 1
the
nodemask, decoupling it from the overloaded initiator_cmp() comparision
callback. This prevents the singular list corner case naturally, and
makes the code easier to follow as well.
Cc:
Cc: Rafael J. Wysocki
Cc: Liu Shixin
Cc: Dan Williams
Cc: Kirill A. Shutemov
Reported-by: Chris Piper
Signed-off
:
> ACPI: HMAT: remove unnecessary variable initialization
> ACPI: HMAT: Fix initiator registration for single-initiator systems
Acked-by: Rafael J. Wysocki
for both and please feel free to ask Dan to take them.
Alternatively, if you want me to apply them, please let me know.
&g
On Sun, Oct 16, 2022 at 10:05:17PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/10/14 23:50, Darrick J. Wong 写道:
> > On Fri, Oct 14, 2022 at 10:24:29AM +0800, Shiyang Ruan wrote:
> > >
> > >
> > > 在 2022/10/14 2:30, Darrick J. Wong 写道:
> > > &g
On Fri, Oct 14, 2022 at 10:24:29AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/10/14 2:30, Darrick J. Wong 写道:
> > On Thu, Sep 29, 2022 at 12:05:14PM -0700, Darrick J. Wong wrote:
> > > On Wed, Sep 28, 2022 at 10:46:17PM +0800, Shiyang Ruan wrote:
> > > >
>
On Thu, Sep 29, 2022 at 12:05:14PM -0700, Darrick J. Wong wrote:
> On Wed, Sep 28, 2022 at 10:46:17PM +0800, Shiyang Ruan wrote:
> >
> >
> > 在 2022/9/28 7:51, Dave Chinner 写道:
> > > On Tue, Sep 27, 2022 at 09:02:48AM -0700, Darrick J. Wong wrote:
> > > >
On Wed, Sep 28, 2022 at 10:46:17PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/9/28 7:51, Dave Chinner 写道:
> > On Tue, Sep 27, 2022 at 09:02:48AM -0700, Darrick J. Wong wrote:
> > > On Tue, Sep 27, 2022 at 02:53:14PM +0800, Shiyang Ruan wrote:
> ...
> > > >
On Tue, Sep 27, 2022 at 02:53:14PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/9/20 5:15, Dave Chinner 写道:
> > On Mon, Sep 19, 2022 at 02:50:03PM +1000, Dave Chinner wrote:
> > > On Thu, Sep 15, 2022 at 09:26:42AM +, Shiyang Ruan wrote:
> > > > Since reflink can work together now, the last
On Tue, Sep 20, 2022 at 12:45:19PM +1000, Dave Chinner wrote:
> On Fri, Sep 02, 2022 at 10:36:01AM +, Shiyang Ruan wrote:
> > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > dev_pagemap_failure()"[1]. With the help of dax_holder and
> > ->notify_failure() mechanism, the pmem
On Thu, Sep 15, 2022 at 10:56:09AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/9/15 2:15, Darrick J. Wong 写道:
> > On Wed, Sep 14, 2022 at 11:09:23AM -0700, Darrick J. Wong wrote:
> > > On Wed, Sep 07, 2022 at 05:46:00PM +0800, Shiyang Ruan wrote:
> > > > pi
On Fri, Sep 02, 2022 at 10:36:00AM +, Shiyang Ruan wrote:
> xfs_notify_failure requires a method to invalidate all mappings.
> drop_pagecache_sb() can do this but it is a static function and only
> build with CONFIG_SYSCTL. Now, move it to super.c and make it available
> for others.
>
>
On Wed, Sep 14, 2022 at 11:09:23AM -0700, Darrick J. Wong wrote:
> On Wed, Sep 07, 2022 at 05:46:00PM +0800, Shiyang Ruan wrote:
> > ping
> >
> > 在 2022/9/2 18:35, Shiyang Ruan 写道:
> > > Changes since v7:
> > >1. Add P1 to fix calculation mistake
>
On Fri, Sep 02, 2022 at 10:36:01AM +, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
On Fri, Sep 02, 2022 at 10:35:59AM +, Shiyang Ruan wrote:
> The end should be start + length - 1. Also fix the calculation of the
> length when seeking for intersection of notify range and device.
>
> Signed-off-by: Shiyang Ruan
Looks correct to me,
Reviewed-by: Darrick J
On Wed, Sep 07, 2022 at 05:46:00PM +0800, Shiyang Ruan wrote:
> ping
>
> 在 2022/9/2 18:35, Shiyang Ruan 写道:
> > Changes since v7:
> >1. Add P1 to fix calculation mistake
> >2. Add P2 to move drop_pagecache_sb() to super.c for xfs to use
> >3. P3: Add invalidate all mappings after
On Wed, Sep 14, 2022 at 08:34:26AM -0400, Brian Foster wrote:
> On Wed, Sep 14, 2022 at 05:38:02PM +0800, Yang, Xiao/杨 晓 wrote:
> > On 2022/9/14 14:44, Yang, Xiao/杨 晓 wrote:
> > > On 2022/9/9 21:01, Brian Foster wrote:
> > > > Yes.. I don't recall all the internals of the tools and test, but IIRC
gt; 2. hold s_umount before sync_filesystem()
> > > 3. do sync_filesystem() after SB_BORN check
> > > 4. Rebased on next-20220714
> > >
> > > [1]:
> > > https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.st...@dwillia2-d
On Thu, Aug 18, 2022 at 07:19:28PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/8/3 12:33, Darrick J. Wong 写道:
> > On Wed, Aug 03, 2022 at 02:43:20AM +, ruansy.f...@fujitsu.com wrote:
> > >
> > > 在 2022/7/19 6:56, Dan Williams 写道:
> > > > Darrick
From: Darrick J. Wong
xfs_dax_failure_fn is used to scan the filesystem during a memory
failure event to look for memory mappings to revoke. Unfortunately, if
it encounters an rmap record for filesystem metadata, it will shut down
the filesystem and the scan immediately. This means that we
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl tags/cxl-for-6.0
...to receive initial support and infrastructure for dynamic CXL region
provisioning and other updates. The support is considered "initial"
because it only tackles persistent memory provisioning,
On Wed, Aug 03, 2022 at 06:47:24AM +, ruansy.f...@fujitsu.com wrote:
>
>
> 在 2022/7/29 12:54, Darrick J. Wong 写道:
> > On Fri, Jul 29, 2022 at 03:55:24AM +, ruansy.f...@fujitsu.com wrote:
> >>
> >>
> >> 在 2022/7/22 0:16, Darrick J. Wong 写道:
>
On Wed, Aug 03, 2022 at 02:43:20AM +, ruansy.f...@fujitsu.com wrote:
>
> 在 2022/7/19 6:56, Dan Williams 写道:
> > Darrick J. Wong wrote:
> >> On Thu, Jul 14, 2022 at 11:21:44AM -0700, Dan Williams wrote:
> >>> ruansy.f...@fujitsu.com wrote:
> >>>>
On Fri, Jul 29, 2022 at 03:55:24AM +, ruansy.f...@fujitsu.com wrote:
>
>
> 在 2022/7/22 0:16, Darrick J. Wong 写道:
> > On Thu, Jul 21, 2022 at 02:06:10PM +, ruansy.f...@fujitsu.com wrote:
> >> 在 2022/7/1 8:31, Darrick J. Wong 写道:
> >>> On Thu, Jun 09, 20
int ret;
>
> + if (!iomi.len)
> + return 0;
Hmm, most of the callers of dax_iomap_rw skip the whole call if
iov_iter_count(to)==0, so I wonder if fuse_dax_read_iter should do the
same?
That said, iomap_dio_rw bails early if you pass it iomi.len, so I don't
have any real objection
On Thu, Jul 21, 2022 at 02:06:10PM +, ruansy.f...@fujitsu.com wrote:
> 在 2022/7/1 8:31, Darrick J. Wong 写道:
> > On Thu, Jun 09, 2022 at 10:34:35PM +0800, Shiyang Ruan wrote:
> >> Failure notification is not supported on partitions. So, when we mount
> >> a reflink
On Thu, Jul 14, 2022 at 11:21:44AM -0700, Dan Williams wrote:
> ruansy.f...@fujitsu.com wrote:
> > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > dev_pagemap_failure()"[1]. With the help of dax_holder and
> > ->notify_failure() mechanism, the pmem driver is able to ask filesystem
>
based on next-20220714
>
> Changes since v4:
> 1. sync_filesystem() at the beginning when MF_MEM_REMOVE
> 2. Rebased on next-20220706
>
> [1]:
> https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.st...@dwillia2-desk3.amr.corp.intel.com/
>
&
On Fri, Jul 08, 2022 at 05:42:22AM +, ruansy.f...@fujitsu.com wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to
On Sun, Jul 03, 2022 at 09:08:38PM +0800, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
though I think this patch applies to ... wherever all
those rmap+reflink+dax patches went. I think that's akpm's tree, right?
Ideally this would go in through there to keep the pieces together, but
I don't mind tossing this in at the end of the 5.20 merge window if akpm
is unwilling.
Reviewed-by:
On Wed, Jun 15, 2022 at 08:54:00PM +0800, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
I don't see any of the patches 1-5,7-13 in current upstream, so
I'm guessing this means Andrew isn't taking it for 5.19?
--D
>
>
> --
> Thanks,
> Ruan.
>
>
> 在 2022/5/12 20:27, Shiyang Ruan 写道:
> >
> >
> > 在 2022/5/11 23:46, Dan Williams 写道:
> >
Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote:
> On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong"
> wrote:
>
> > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> &g
On Tue, May 10, 2022 at 09:20:57PM -0700, Dan Williams wrote:
> On Tue, May 10, 2022 at 7:29 PM Andrew Morton
> wrote:
> >
> > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> > wrote:
> >
> > > > It'll need to be a stable branch somewhere, but I don't think it
> > > > really matters where al
On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> wrote:
>
> > > It'll need to be a stable branch somewhere, but I don't think it
> > > really matters where al long as it's merged into the xfs for-next
> > > tree so it gets
1 - 100 of 41267 matches
Mail list logo
