On Wed, Jun 24, 2020 at 3:06 PM Wei Yang
wrote:
>
> On Wed, Jun 24, 2020 at 09:10:09AM -0700, Dan Williams wrote:
> >On Tue, Jun 23, 2020 at 11:14 PM Wei Yang
> > wrote:
> >>
> >> On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal Hocko wrote:
> >&
On Wed, Jun 24, 2020 at 11:55 AM David E. Box
wrote:
>
> Friendly reminder. Thanks.
Are you looking for this to be merged by ACPI with an NVMe ack, or
merged by NVMe with an ACPI ack? It sometimes helps to be explicit to
break the log jam.
>
> David
>
> On Fri, 2020-06-12 at 13:48 -0700, David E
On Tue, Jun 23, 2020 at 11:14 PM Wei Yang
wrote:
>
> On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal Hocko wrote:
> >On Tue 23-06-20 17:42:58, Wei Yang wrote:
> >> For early sections, we assumes its memmap will never be partially
> >> removed. But current behavior breaks this.
> >>
> >> Let's cor
9/0xb3
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Suggested-by: David Howells
Fixes: 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than a
mask")
Signed-off-by: Dan Williams
---
drivers/nvdimm/security.c |2 +-
1 file changed, 1 insertion(+),
On Tue, Jun 23, 2020 at 5:55 PM David Howells wrote:
>
> Dan Williams wrote:
>
> > > This commit:
> > >
> > > > keys: Make the KEY_NEED_* perms an enum rather than a mask
> > >
> > > ...upstream as:
> > >
> >
On Tue, Jun 23, 2020 at 2:43 AM Wei Yang
wrote:
>
> For early sections, we assumes its memmap will never be partially
> removed. But current behavior breaks this.
Where do we assume that?
The primary use case for this was mapping pmem that collides with
System-RAM in the same 128MB section. That
On Tue, Jun 16, 2020 at 6:15 PM Williams, Dan J
wrote:
>
> Hi David,
>
> On Tue, 2020-06-02 at 16:55 +0100, David Howells wrote:
> > Date: Tue, 02 Jun 2020 16:51:44 +0100
> >
> > Hi Linus,
> >
> > Can you pull this, please? It adds a general notification queue
> > concept
> > and adds an event so
On Mon, Jun 22, 2020 at 12:33 AM David Hildenbrand wrote:
>
> On 20.06.20 03:49, Dan Williams wrote:
> > On Fri, Jun 19, 2020 at 5:59 AM David Hildenbrand wrote:
> >>
> >> Commit e900a918b098 ("mm: shuffle initial free memory to improve
> >&
On Mon, Jun 22, 2020 at 12:28 AM David Hildenbrand wrote:
>
> On 20.06.20 03:41, Dan Williams wrote:
> > On Fri, Jun 19, 2020 at 6:00 AM David Hildenbrand wrote:
> >>
> >> It's not completely obvious why we have to shuffle the complete zone, as
> >>
r.corp.intel.com
> [3]
> https://lkml.kernel.org/r/CAPcyv4irwGUU2x+c6b4L=kbb1dnasnkaazd6ospyjl9kfsn...@mail.gmail.com
>
> Cc: Andrew Morton
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Minchan Kim
> Cc: Huang Ying
> Cc: Wei Yang
> Cc: Mel Gorman
> Cc: Dan Williams
> S
ike Patch1 since that original commit was missing the proper
commentary in the code?
> Cc: Andrew Morton
> Cc: Alexander Duyck
> Cc: Dan Williams
> Cc: Michal Hocko
> Signed-off-by: David Hildenbrand
> ---
> mm/memory_hotplug.c | 8
> 1 file changed, 8 inserti
he ndctl tool to retrieve a health-command payload.
--------
Dan Williams (1):
Merge branch 'for-5.8/papr_scm' into libnvdimm-for-next
Vaibhav Jain (6):
powerpc: Document details on H_SCM_HEALTH hcall
seq_buf: Export seq_buf_printf
powerpc/papr_
Apr 30, 2020 at 6:21 PM Dan Williams
wrote:
> >
> > However now I see that copy_user_generic() works for the wrong reason.
> > It works because the exception on the source address due to poison
> > looks no different than a write fault on the user address to the
Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Reported-by: Erwin Tsaur
Tested-by: Erwin Tsaur
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Signed-off-by: Dan Williams
---
arch/x86/include/asm/uaccess.h |3 +++
arch/x86/lib/copy_mc.c | 12 +---
arch/x8
lets the architecture organize the implementation
accordingly.
For both powerpc and x86 a copy_mc_generic() implementation is added as
the backend for these interfaces.
Patches are relative to v5.8-rc1. It has a recent build success
notification from the kbuild robot and is passing local nvdimm tests.
---
D
On Tue, Jun 16, 2020 at 11:48 PM Michal Hocko wrote:
>
> On Tue 16-06-20 10:03:31, Dan Williams wrote:
> > On Tue, Jun 16, 2020 at 10:00 AM Dan Williams
> > wrote:
> > >
> > > On Tue, Jun 16, 2020 at 5:51 AM Michal Hocko wrote:
> > > >
> >
On Tue, Jun 16, 2020 at 10:00 AM Dan Williams wrote:
>
> On Tue, Jun 16, 2020 at 5:51 AM Michal Hocko wrote:
> >
> > On Tue 16-06-20 13:52:12, David Hildenbrand wrote:
> > > Commit e900a918b098 ("mm: shuffle initial free memory to improve
> > > m
each memory block (e.g., 128MB .. 2G on
> > x86-64) will get onlined individually, resulting in a shuffle_zone() for
> > every memory block getting onlined.
> >
> > Cc: Andrew Morton
> > Cc: Alexander Duyck
> > Cc: Dan Williams
> > Cc: Michal Hocko
>
On Tue, Jun 16, 2020 at 6:45 AM David Hildenbrand wrote:
>
> On 16.06.20 14:41, Michal Hocko wrote:
> > [Add Dan]
>
> Whops, dropped by mistake. Thanks for adding.
>
> >
> > On Tue 16-06-20 13:52:13, David Hildenbrand wrote:
> >> Commit e900a918b098 ("mm: shuffle initial free memory to improve
> >
On Mon, Jun 15, 2020 at 5:56 AM Borislav Petkov wrote:
>
> On Mon, Jun 15, 2020 at 06:14:03PM +0530, Vaibhav Jain wrote:
> > 'seq_buf' provides a very useful abstraction for writing to a string
> > buffer without needing to worry about it over-flowing. However even
> > though the API has been stab
On Sat, Jun 13, 2020 at 12:29 PM Rafael J. Wysocki wrote:
[,,]
> > While I agree that this is still somewhat suboptimal, improving this
> > would require more changes in the OSL code.
>
> After writing the above I started to think about the extra changes needed
> to improve that and I realized tha
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-for-5.8
...to receive a smattering of cleanups for v5.8. I was considering at
least one more late breaking topic for -rc1 (papr_scm device health
reporting), but a last minute kbuild-robot rep
On Wed, Jun 10, 2020 at 5:10 AM Vaibhav Jain wrote:
>
> Dan Williams writes:
>
> > On Tue, Jun 9, 2020 at 10:54 AM Vaibhav Jain wrote:
> >>
> >> Thanks Dan for the consideration and taking time to look into this.
> >>
> >> My responses below:
On Tue, Jun 9, 2020 at 12:57 PM David Miller wrote:
>
> From: "Williams, Dan J"
> Date: Tue, 9 Jun 2020 19:30:50 +
>
> > On Tue, 2020-06-09 at 11:36 -0700, David Miller wrote:
> >> From: Stephen Hemminger
> >> Date: Tue, 9 Jun 2020 10:19:35 -0700
> >>
> >> > Yes, words do matter and convey a
On Tue, Jun 9, 2020 at 10:54 AM Vaibhav Jain wrote:
>
> Thanks Dan for the consideration and taking time to look into this.
>
> My responses below:
>
> Dan Williams writes:
>
> > On Mon, Jun 8, 2020 at 5:16 PM kernel test robot wrote:
> >>
> >>
On Mon, Jun 8, 2020 at 5:16 PM kernel test robot wrote:
>
> Hi Vaibhav,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on powerpc/next]
> [also build test WARNING on linus/master v5.7 next-20200605]
> [cannot apply to linux-nvdimm/libnvdimm-for-next scottwo
t; > papr_scm_ndctl() in case of a PDSM request is received via ND_CMD_CALL
> > command from libnvdimm.
> >
> > Cc: "Aneesh Kumar K . V"
> > Cc: Dan Williams
> > Cc: Michael Ellerman
> > Cc: Ira Weiny
> > Signed-off-by: Vaibhav Jain
> > -
;return' statement thereby ensuring that value of
> > 'cmd_rc' is always logged when papr_scm_ndctl() returns.
> >
> > Cc: "Aneesh Kumar K . V"
> > Cc: Dan Williams
> > Cc: Michael Ellerman
> > Cc: Ira Weiny
> > Signed-off-by: Vaibh
On Wed, May 27, 2020 at 4:32 PM Dan Williams wrote:
>
> Changes since v4 [1]:
> - Fix up .gitignore for PowerPC test artifacts (Michael)
>
> - Collect Michael's Ack.
>
> [1]:
> http://lore.kernel.org/r/159010126119.975921.6614194205409771984.st...@dwil
On Fri, Jun 5, 2020 at 8:22 AM Vaibhav Jain wrote:
[..]
> > Oh, why not define a maximal health payload with all the attributes
> > you know about today, leave some room for future expansion, and then
> > report a validity flag for each attribute? This is how the "intel"
> > smart-health payload w
ated. Among other
> situations, that list can be walked in non-NMI interrupt context,
> so using a sleeping lock to protect it is not an option.
>
> However, performance issues related to the RCU usage in there
> appear, as described by Dan Williams:
>
> "Recently a performance
On Fri, Jun 5, 2020 at 9:22 AM Rafael J. Wysocki wrote:
[..]
> > The fix we are looking at now is to pre-map operation regions in a
> > similar manner as the way APEI resources are pre-mapped. The
> > pre-mapping would arrange for synchronize_rcu_expedited() to be elided
> > on each dynamic mappin
On Fri, Jun 5, 2020 at 6:32 AM Rafael J. Wysocki wrote:
>
> On Fri, May 8, 2020 at 1:55 AM Dan Williams wrote:
> >
> > Recently a performance problem was reported for a process invoking a
> > non-trival ASL program. The method call in this case ends up
> > repet
Apr 30, 2020 at 6:21 PM Dan Williams
wrote:
> >
> > However now I see that copy_user_generic() works for the wrong reason.
> > It works because the exception on the source address due to poison
> > looks no different than a write fault on the user address to the
Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Reported-by: Erwin Tsaur
Tested-by: Erwin Tsaur
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Signed-off-by: Dan Williams
---
arch/x86/include/asm/uaccess.h |3 +++
arch/x86/lib/copy_mc.c | 12 +---
arch/x8
_mc_to_user() and copy_mc_to_kernel() clearly indicate the
intended use case and lets the architecture organize the implementation
accordingly.
For both powerpc and x86 a copy_mc_generic() implementation is added as
the backend for these interfaces.
Patches are relative to tip/master.
---
Dan Willi
On Wed, May 27, 2020 at 4:02 PM Arvind Sankar wrote:
>
> On Wed, May 27, 2020 at 03:56:45PM -0700, Dan Williams wrote:
> > On Wed, May 27, 2020 at 3:47 PM Arvind Sankar wrote:
> > >
> > > On Wed, May 27, 2020 at 10:30:18PM +, Williams, Dan J wrote:
> > &
On Wed, May 27, 2020 at 3:47 PM Arvind Sankar wrote:
>
> On Wed, May 27, 2020 at 10:30:18PM +, Williams, Dan J wrote:
> > On Fri, 2020-05-08 at 20:01 +0200, Ard Biesheuvel wrote:
> > > From: Arvind Sankar
> > >
> > > Consolidate the initrd loading in efi_main.
> > >
> > > The command line opt
rtunate that
we already have 2 ways to describe persistent memory devices, let's
not perpetuate a third so that "grep" has a chance to find
interrelated code across architectures. Other than that this looks
good to me.
> Cc: "Aneesh Kumar K . V"
> Cc: Dan Willi
On Sat, May 23, 2020 at 5:04 AM Michael Ellerman wrote:
>
> Hi Dan,
>
> Sorry one minor nit below.
>
> Dan Williams writes:
> > diff --git a/tools/testing/selftests/powerpc/copyloops/.gitignore
> > b/tools/testing/selftests/powerpc/copyloops/.gitignore
> &
_kernel() clearly indicate the
intended use case and lets the architecture organize the implementation
accordingly.
For both powerpc and x86 a copy_mc_generic() implementation is added as
the backend for these interfaces.
Patches are relative to tip/master.
---
Dan Williams (2):
x86, powe
Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Reported-by: Erwin Tsaur
Tested-by: Erwin Tsaur
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Signed-off-by: Dan Williams
---
arch/x86/include/asm/uaccess.h |3 +++
arch/x86/lib/copy_mc.c | 12 +---
arch/x8
Apr 30, 2020 at 6:21 PM Dan Williams
wrote:
> >
> > However now I see that copy_user_generic() works for the wrong reason.
> > It works because the exception on the source address due to poison
> > looks no different than a write fault on the user address to the
t /dev/mem to idle io memory ranges")
Signed-off-by: Dan Williams
---
Changes since v3 [1]:
- Drop redundant memory barriers, READ_ONCE() and WRITE_ONCE() ensure
sufficient ordering (Matthew)
- Drop redundant setting of i_mapping->host. (Matthew)
[1]:
http://lore.kernel.org/r/159002475918
On Thu, May 21, 2020 at 4:41 AM Matthew Wilcox wrote:
>
> On Wed, May 20, 2020 at 09:39:49PM -0700, Dan Williams wrote:
> > On Wed, May 20, 2020 at 9:37 PM Dan Williams
> > wrote:
> > > On Wed, May 20, 2020 at 7:26 PM Matthew Wilcox
> > > wrote:
> &
On Wed, May 20, 2020 at 9:37 PM Dan Williams wrote:
>
> On Wed, May 20, 2020 at 7:26 PM Matthew Wilcox wrote:
> >
> > On Wed, May 20, 2020 at 06:35:25PM -0700, Dan Williams wrote:
> > > +static struct inode *devmem_inode;
> > > +
> > > +#ifdef CONF
On Wed, May 20, 2020 at 7:26 PM Matthew Wilcox wrote:
>
> On Wed, May 20, 2020 at 06:35:25PM -0700, Dan Williams wrote:
> > +static struct inode *devmem_inode;
> > +
> > +#ifdef CONFIG_IO_STRICT_DEVMEM
> > +void revoke_devmem(struct resource *res)
> > +{
>
t /dev/mem to idle io memory ranges")
Signed-off-by: Dan Williams
---
Changes since v2 [1]:
- Fix smp_wmb() placement relative to publishing write (Matthew)
[1]:
http://lore.kernel.org/r/158987153989.484.17143582803685077783.st...@dwillia2-desk3.amr.corp.intel
On Wed, May 20, 2020 at 11:27 AM Jim Quinlan wrote:
>
> Sorry, I meant to put you on the to-list for all patches. The last
> time I sent out this many patches using a collective cc-list for all
> patches I was told to reduce my cc-list.
You'd be forgiven. There are some developers that are ok t
On Wed, May 20, 2020 at 12:13 PM Vivek Goyal wrote:
>
> On Tue, May 19, 2020 at 03:12:42PM -0700, Dan Williams wrote:
> > The original copy_mc_fragile() implementation had negative performance
> > implications since it did not use the fast-string instruction sequence
> >
On Wed, May 20, 2020 at 2:54 AM Michael Ellerman wrote:
>
> Hi Dan,
>
> Just a couple of minor things ...
>
> Dan Williams writes:
> > In reaction to a proposal to introduce a memcpy_mcsafe_fast()
> > implementation Linus points out that memcpy_mcsafe() i
Apr 30, 2020 at 6:21 PM Dan Williams
wrote:
> >
> > However now I see that copy_user_generic() works for the wrong reason.
> > It works because the exception on the source address due to poison
> > looks no different than a write fault on the user address to the
Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Reported-by: Erwin Tsaur
Tested-by: Erwin Tsaur
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Signed-off-by: Dan Williams
---
arch/x86/include/asm/uaccess_64.h |3 +++
arch/x86/lib/copy_mc.c| 12 +---
c() implementation is added as
the backend for these interfaces.
Patches are relative to tip/master.
---
Dan Williams (2):
x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,kernel}()
x86/copy_mc: Introduce copy_mc_generic()
arch/powerpc/Kconfig |
On Tue, May 19, 2020 at 11:46 AM Matthew Wilcox wrote:
>
> On Tue, May 19, 2020 at 12:03:06AM -0700, Dan Williams wrote:
> > +void revoke_devmem(struct resource *res)
> > +{
> > + struct inode *inode = READ_ONCE(devmem_inode);
> > +
> > + /*
> >
On Tue, May 19, 2020 at 5:11 AM Greg KH wrote:
>
> On Tue, May 19, 2020 at 12:03:06AM -0700, Dan Williams wrote:
> > Close the hole of holding a mapping over kernel driver takeover event of
> > a given address range.
> >
> > Commit 90a545e98126 ("restric
alidated extent, but they
will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can
block those subsequent accesses.
Cc: Arnd Bergmann
Cc: Ingo Molnar
Cc: Kees Cook
Cc: Russell King
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Fixes: 90a545e98126 ("restrict /dev/mem to idle io
On Mon, May 18, 2020 at 11:08 AM James Morse wrote:
>
> Hi guys,
>
> On 12/05/2020 19:05, Dan Williams wrote:
> > On Tue, May 12, 2020 at 9:28 AM Rafael J. Wysocki
> > wrote:
> >> Dan,
> >>
> >> Has this been addressed in the v2?
> >
>
On Mon, May 18, 2020 at 11:26 AM Luck, Tony wrote:
[..]
> N.B. Linux wants to switch the page to uncacheable so that in the
> persistant memory case the filesytem code can continue to access
> the other "blocks" in the page, rather than lose all of them. That's
> futile in the case where the VMM t
On Mon, May 18, 2020 at 6:52 AM David Woodhouse wrote:
>
> On Wed, 2020-04-29 at 05:20 +, Williams, Dan J wrote:
> > The *patch* is not trying to overrule NVME, and the best I can say is
> > that the Intel Linux team was not in the loop when this was being
> > decided between the platform BIOS
On Tue, May 12, 2020 at 1:08 AM Christoph Hellwig wrote:
>
> On Sat, May 09, 2020 at 08:07:14AM -0700, Dan Williams wrote:
> > > which are all used in the I/O submission path (generic_make_request /
> > > generic_make_request_checks). This is mostly a prep cleanup patch
PATCH] ACPI: Drop rcu
> > usage for MMIO mappings")
> > url:
> > https://github.com/0day-ci/linux/commits/Dan-Williams/ACPI-Drop-rcu-usage-for-MMIO-mappings/20200507-075930
> > base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git
> > linux-next
> &g
On Sat, May 9, 2020 at 1:24 AM Christoph Hellwig wrote:
>
> On Fri, May 08, 2020 at 11:04:45AM -0700, Dan Williams wrote:
> > On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote:
> > >
> > > Hi all,
> > >
> > > various bio based drivers use queu
On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote:
>
> Hi all,
>
> various bio based drivers use queue->queuedata despite already having
> set up disk->private_data, which can be used just as easily. This
> series cleans them up to only use a single private data pointer.
...but isn't the qu
: Borislav Petkov
Cc: Ira Weiny
Cc: James Morse
Cc: Erik Kaneda
Cc: Myron Stowe
Cc: "Rafael J. Wysocki"
Cc: Andy Shevchenko
Signed-off-by: Dan Williams
---
Changes since v1 [1]:
- Actually cc: the most important list for ACPI changes (Rafael)
- Cleanup unnecessary variable initial
On Thu, May 7, 2020 at 2:25 AM Andy Shevchenko
wrote:
>
> On Thu, May 7, 2020 at 3:21 AM Dan Williams wrote:
> >
> > Recently a performance problem was reported for a process invoking a
> > non-trival ASL program. The method call in this case ends up
> > repetitive
On Thu, May 7, 2020 at 9:43 AM Rafael J. Wysocki
wrote:
>
> On 5/7/2020 1:39 AM, Dan Williams wrote:
> > Recently a performance problem was reported for a process invoking a
> > non-trival ASL program. The method call in this case ends up
> > repetitively tri
: Borislav Petkov
Cc: Ira Weiny
Cc: James Morse
Cc: Erik Kaneda
Cc: Myron Stowe
Cc: "Rafael J. Wysocki"
Cc: Andy Shevchenko
Signed-off-by: Dan Williams
---
drivers/acpi/osl.c | 117 +---
1 file changed, 57 insertions(+), 60 deleti
On Mon, May 4, 2020 at 1:26 PM Andy Lutomirski wrote:
>
> On Mon, May 4, 2020 at 1:05 PM Luck, Tony wrote:
> >
> > > When a copy function hits a bad page and the page is not yet known to
> > > be bad, what does it do? (I.e. the page was believed to be fine but
> > > the copy function gets #MC.)
On Sun, May 3, 2020 at 5:57 AM David Laight wrote:
>
> From: Linus Torvalds
> > Sent: 01 May 2020 19:29
> ...
> > And as DavidL pointed out - if you ever have "iomem" as a source or
> > destination, you need yet another case. Not because they can take
> > another kind of fault (although on some pl
On Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote:
>
> >> Now, let's clarify what I want regarding virtio-mem:
> >>
> >> 1. kexec should not add virtio-mem memory to the initial firmware
> >>memmap. The driver has to be in charge as discussed.
> >> 2. kexec should not place kexec images o
On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote:
>
> On 01.05.20 22:12, Dan Williams wrote:
[..]
> >>> Consider the case of EFI Special Purpose (SP) Memory that is
> >>> marked EFI Conventional Memory with the SP attribute. In that case the
> >
On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote:
>
> On 01.05.20 20:43, Dan Williams wrote:
> > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 20:03, Dan Williams wrote:
> >>> On Fri, May 1, 2020 a
On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
>
> On 01.05.20 20:03, Dan Williams wrote:
> > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 19:45, David Hildenbrand wrote:
> >>> On 01.05.20 19:39, Dan Williams
On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
>
> On 01.05.20 19:45, David Hildenbrand wrote:
> > On 01.05.20 19:39, Dan Williams wrote:
> >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
> >>>
> >>> On 01.05.20 18:56, Dan Willi
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>
> On 01.05.20 18:56, Dan Williams wrote:
> > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 00:24, Andrew Morton wrote:
> >>> On Thu, 30 Apr 2020 20:4
On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
>
> On 01.05.20 00:24, Andrew Morton wrote:
> > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand
> > wrote:
> >
> >>>
> >>> Why does the firmware map support hotplug entries?
> >>
> >> I assume:
> >>
> >> The firmware memmap was added p
On Thu, Apr 30, 2020 at 5:10 PM Linus Torvalds
wrote:
>
> On Thu, Apr 30, 2020 at 4:52 PM Dan Williams wrote:
> >
> > You had me until here. Up to this point I was grokking that Andy's
> > "_fallible" suggestion does help explain better than "_safe&
On Thu, Apr 30, 2020 at 12:56 PM Linus Torvalds
wrote:
>
> On Thu, Apr 30, 2020 at 12:23 PM Luck, Tony wrote:
> >
> > How about
> >
> > try_copy_catch(void *dst, void *src, size_t count, int *fault)
> >
> > returns number of bytes not-copied (like copy_to_user etc).
> >
> > if return is n
On Thu, Apr 30, 2020 at 12:23 PM Luck, Tony wrote:
>
> On Thu, Apr 30, 2020 at 11:42:20AM -0700, Andy Lutomirski wrote:
> > I suppose there could be a consistent naming like this:
> >
> > copy_from_user()
> > copy_to_user()
> >
> > copy_from_unchecked_kernel_address() [what probe_kernel_read() is]
On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand wrote:
>
> >>> If the class of memory is different then please by all means let's mark
> >>> it differently in struct resource so everyone knows it is different.
> >>> But that difference needs to be more than hotplug.
> >>>
> >>> That difference
"
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Tony Luck
Cc: Linus Torvalds
Reported-by: Erwin Tsaur
Tested-by: Erwin Tsaur
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Signed-off-by: Dan Williams
---
arch/x86/include/asm/copy_safe.h |2 ++
arch
ations the name "mcsafe" is no longer accurate and
copy_safe() is proposed as its replacement. x86 grows a copy_safe_fast()
implementation as a default implementation that is independent of
detecting the presence of x86-MCA.
---
Dan Williams (2):
copy_safe: Rename memcpy_mcsafe() to co
Herrenschmidt
Cc: Paul Mackerras
Cc: Arnaldo Carvalho de Melo
Cc: Linus Torvalds
Link:
http://lore.kernel.org/r/CAHk-=wjsqtxaqfujxftwnwmgufastgb0dz1dt3v-78quiez...@mail.gmail.com
Signed-off-by: Dan Williams
---
arch/powerpc/Kconfig |2
arch/
On Thu, Apr 30, 2020 at 1:21 AM David Hildenbrand wrote:
> >> Just because we decided to use some DAX memory in the current kernel as
> >> system ram, doesn't mean we should make that decision for the kexec
> >> kernel (e.g., using it as initial memory, placing kexec binaries onto
> >> it, etc.).
On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand wrote:
>
> On 29.04.20 18:08, David Hildenbrand wrote:
> > Some paravirtualized devices that add memory via add_memory() and
> > friends (esp. virtio-mem) don't want to create entries in
> > /sys/firmware/memmap/ - primarily to hinder kexec from a
On Tue, Oct 22, 2019 at 3:02 AM Rafael J. Wysocki wrote:
>
> On Fri, Oct 18, 2019 at 11:25 AM Rafael J. Wysocki wrote:
> >
> > On Wed, Oct 16, 2019 at 3:13 AM Dan Williams
> > wrote:
> > >
> > > Currently hmat.c lives under an "hmat" direc
ed-by: Doug Nelson
Cc:
Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
Reviewed-by: Jan Kara
Cc: Jeff Moyer
Cc: Matthew Wilcox (Oracle)
Signed-off-by: Dan Williams
---
Changes in v2:
- Update the changelog to reflect the user visible effects of the bug
(Jeff)
fs/dax.c |
On Mon, Oct 21, 2019 at 5:07 AM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > Check for NULL entries before checking the entry order, otherwise NULL
> > is misinterpreted as a present pte conflict. The 'order' check needs to
> > happen before the locked ch
_desc = to_acpi_desc(nd_desc);
> > --
>
> Applying as a fix for 5.4, thanks!
>
> @Dan W: Please let me know if you'd rather take it yourself.
If you already have it applied, I have no concerns.
Acked-by: Dan Williams
On Sat, Oct 19, 2019 at 4:09 PM Dan Williams wrote:
>
> On Sat, Oct 19, 2019 at 1:50 PM Matthew Wilcox wrote:
> >
> > On Sat, Oct 19, 2019 at 09:26:19AM -0700, Dan Williams wrote:
> > > Check for NULL entries before checking the entry order, otherwise NULL
> >
On Sat, Oct 19, 2019 at 1:50 PM Matthew Wilcox wrote:
>
> On Sat, Oct 19, 2019 at 09:26:19AM -0700, Dan Williams wrote:
> > Check for NULL entries before checking the entry order, otherwise NULL
> > is misinterpreted as a present pte conflict. The 'order' check ne
eported-by: Doug Nelson
Cc:
Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
Cc: Jan Kara
Cc: Matthew Wilcox (Oracle)
Signed-off-by: Dan Williams
---
fs/dax.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index a71881e77204.
On Fri, Oct 18, 2019 at 2:48 AM Jan Kara wrote:
>
> Hello!
>
> On Fri 18-10-19 16:23:54, kernel test robot wrote:
> > FYI, we noticed a -61.6% regression of fio.write_bw_MBps due to commit:
> >
> >
> > commit: 23c84eb7837514e16d79ed6d849b13745e0ce688 ("dax: Fix missed wakeup
> > with PMD faults")
On Fri, Oct 18, 2019 at 2:40 PM Yang Shi wrote:
>
> On Fri, Oct 18, 2019 at 7:54 AM Dave Hansen wrote:
> >
> > On 10/18/19 12:44 AM, Michal Hocko wrote:
> > > How does this compare to
> > > http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang@linux.alibaba.com
> >
> > It's a _bit_
On Fri, Oct 18, 2019 at 5:37 AM Dan Carpenter wrote:
>
> We change the locking in this function and forgot to update this error
> path so we are accidentally still holding the "dev->lockdep_mutex".
>
> Fixes: 87a30e1f05d7 ("driver-core, libnvdimm: Let device subsystems add local
> lockdep coverag
On Tue, Oct 15, 2019 at 10:59 PM Thomas Hellström (VMware)
wrote:
>
> Hi, Dan,
>
> On 10/16/19 3:44 AM, Dan Williams wrote:
> > On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov
> > wrote:
> >> On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (
On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov wrote:
>
> On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
> > From: Thomas Hellstrom
> >
> > A huge pud page can theoretically be faulted in racing with pmd_alloc()
> > in __handle_mm_fault(). That will lead to pmd_all
On Tue, Oct 15, 2019 at 2:02 PM Stephen Douthit
wrote:
>
> On 10/15/19 3:54 PM, Dan Williams wrote:
> > Commit c312ef176399 "libata/ahci: Drop PCS quirk for Denverton and
> > beyond" got the polarity wrong on the check for which board-ids should
> > have
future if they need the quirk. All prior Intel board ids "<
board_ahci_pcs7" should proceed with applying the quirk.
Reported-by: Andreas Friedrich
Reported-by: Stephen Douthit
Fixes: c312ef176399 ("libata/ahci: Drop PCS quirk for Denverton and beyond")
Cc:
Signed-of
901 - 1000 of 3109 matches
Mail list logo
