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.
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
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
> >> some
p.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
> Signed
tch1 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 insertions(+)
>
alth-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_scm: Fetch nvdimm health information fro
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
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/x86/lib/copy
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.
---
Dan Wi
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
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
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
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
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
se 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
> > ---
> > Changelog:
> &
y 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: Vaibhav Jain
> > ---
> > Changel
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...@dwillia2-
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
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
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
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/x86/lib/copy
o_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 Williams (
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
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 Williams
> Cc: Mic
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
> &
c_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 Williams (2):
x86,
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/x86/lib/copy
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
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(
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
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 +--
arch/
eric() 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
e(2) to the invalidated 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
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
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 pa
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
: 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 dele
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
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
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
&g
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
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
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()
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
"
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
realizations 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
ackerras
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/powerpc/include/asm/strin
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
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" di
g 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 |5 +++--
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 check as an
_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 needs to
-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..08160011d
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
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
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
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
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
On Tue, Oct 1, 2019 at 2:02 PM Ira Weiny wrote:
>
> On Mon, Sep 30, 2019 at 06:42:33PM +1000, Dave Chinner wrote:
> > On Wed, Sep 25, 2019 at 04:46:03PM -0700, Ira Weiny wrote:
> > > On Tue, Sep 24, 2019 at 08:26:20AM +1000, Dave Chinner wrote:
> > > > Hence, AFIACT, the above definition of a
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-fixes-5.4-rc1
...to receive the completion of the work to fixup libnvdimm operation
on powerpc as well as a collection of typical -rc class fixes. This
powerpc work missed the initial
On Fri, Sep 27, 2019 at 9:14 AM Kaitao Cheng wrote:
>
> There is no need to make the 'node_order' variable static
> since new value always be assigned before use it.
>
> Signed-off-by: Kaitao Cheng
> Signed-off-by: Muchun Song
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Sun, Sep 22, 2019 at 5:04 AM Michael Ellerman wrote:
>
>
>
> On 21 September 2019 4:31:16 am AEST, Dan Williams
> wrote:
> >On Fri, Sep 20, 2019 at 11:18 AM Qian Cai wrote:
> >>
> >> On Fri, 2019-09-20 at 19:55 +0530, Aneesh K
901 - 1000 of 9322 matches
Mail list logo
