Reminder: Invoice 898808
___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH -next] ACPI: NFIT: Fix judgment of rc is '-ENXIO'
On Tue, Oct 27, 2020 at 2:38 PM Zhang Qilong wrote: > > Initial value of rc is '-ENXIO', and we should > use the initial value to check it. > > Signed-off-by: Zhang Qilong > --- > drivers/acpi/nfit/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c > index 756227837b3b..3a3c209ed3d3 100644 > --- a/drivers/acpi/nfit/core.c > +++ b/drivers/acpi/nfit/core.c > @@ -1564,7 +1564,7 @@ static ssize_t format1_show(struct device *dev, > le16_to_cpu(nfit_dcr->dcr->code)); > break; > } > - if (rc != ENXIO) > + if (rc != -ENXIO) > break; > } > mutex_unlock(_desc->init_mutex); > -- Applied as 5.10-rc material with a subject edit, thanks! ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
【三菱ＵＦＪニコス銀行】お届け情報変更受付のお知らせ
linux-nvdimm@lists.01.org 様 平素は弊社カードならびにインターネットサービス「三菱ＵＦＪ」をご愛用いただき、厚く御礼申し上げます。 このメールでは、「三菱ＵＦＪ」にご登録の情報の変更受付を許可したことをお知らせしております。ご変更をお願い致します。 →ご変更はこちらから ※カードお届け内容の変更はお手続き内容および時間帯によって、画面への反映が翌日以降となる場合がございます。 ■□■三菱ＵＦＪニコス銀行からのお知らせ■□■ ▼カードご利用の際、暗証番号が必要な場合がございます。 暗証番号をご存じでない場合は、弊社ホームページから簡単に照会お手続きいただけます。 ぜひ、お早めにご確認ください。 http://www.cr.mnfg.shwxtfood.com/ 今後とも「三菱ＵＦＪ」のご利用をよろしくお願いいたします。 ━━━ ＜三菱ＵＦＪ銀行＞ http://www.cr.mnfg.shwxtfood.com/ ※本メールは送信専用です。 ※本メールは「三菱ＵＦＪ」にメールアドレスをご登録いただいており、「三菱ＵＦＪ」で各種お申し込みをされた方にお送りしています。 ━━━ 【お問い合わせ先】 三菱ＵＦＪ銀行インターネットバンキングヘルプデスク 0120-543-555 または042-311-7000（通話料有料） 受付時間／毎日9:00～21:00 三菱東京ＵＦＪ銀行 BizSTATION ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Invoice 858299
___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH -next] ACPI: NFIT: Fix judgment of rc is '-ENXIO'
On Tue, 2020-10-27 at 21:49 +0800, Zhang Qilong wrote: > Initial value of rc is '-ENXIO', and we should > use the initial value to check it. > > Signed-off-by: Zhang Qilong > --- > drivers/acpi/nfit/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Looks good, Reviewed-by: Vishal Verma > > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c > index 756227837b3b..3a3c209ed3d3 100644 > --- a/drivers/acpi/nfit/core.c > +++ b/drivers/acpi/nfit/core.c > @@ -1564,7 +1564,7 @@ static ssize_t format1_show(struct device *dev, > le16_to_cpu(nfit_dcr->dcr->code)); > break; > } > - if (rc != ENXIO) > + if (rc != -ENXIO) > break; > } > mutex_unlock(_desc->init_mutex); ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Low-Cost Loans for SMEs & Investment Funding.
Dear My name is Nicholas Toms, an investment portfolio manager with ACLL . We offer the right loan Investment funding with low interest to finance your business or project ranging from US$1M to US$2BIllion. Kindly contact me for more details as I am open to questions. Sincerely, Nicholas Toms ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH 06/10] x86/entry: Move nmi entry/exit into common code
On Tue, Oct 27 2020 at 00:07, Ira Weiny wrote:
> On Fri, Oct 23, 2020 at 11:50:11PM +0200, Thomas Gleixner wrote:
>> > #ifndef irqentry_state
>> > typedef struct irqentry_state {
>> > - boolexit_rcu;
>> > + union {
>> > + boolexit_rcu;
>> > + boollockdep;
>> > + };
>> > } irqentry_state_t;
>> > #endif
>>
>> -E_NO_KERNELDOC
>
> Adding: Paul McKenney
>
> I'm happy to write something but I'm very unfamiliar with this code. So I'm
> getting confused what exactly exit_rcu is flagging.
>
> I can see that exit_rcu is a bad name for the state used in
> irqentry_nmi_[enter|exit](). Furthermore, I see why 'lockdep' is a better
> name. But similar lockdep handling is used in irqentry_exit() if exit_rcu is
> true...
No, it's not similar at all. Lockdep state vs. interrupts and regular
exceptions is always consistent.
In the NMI case, that's not guaranteed because of
local_irq_disable()
arch_local_irq_disable()
<- NMI race window
trace_hardirqs_off()
same the other way round
local_irq_enable()
trace_hardirqs_on()
<- NMI race window
arch_local_irq_enable()
IOW, the hardware state and the lockdep state are not consistent.
> /**
> * struct irqentry_state - Opaque object for exception state storage
> * @exit_rcu: Used exclusively in the irqentry_*() calls; tracks if the
> *exception hit the idle task which requires special handling,
> *including calling rcu_irq_exit(), when the exception
> exits.
calls; signals whether the exit path has to invoke rcu_irq_exit().
> * @lockdep: Used exclusively in the irqentry_nmi_*() calls; ensures lockdep
> * tracking is maintained if hardirqs were already enabled
ensures that lockdep state is restored correctly on exit from nmi.
> *
> * This opaque object is filled in by the irqentry_*_enter() functions and
> * should be passed back into the corresponding irqentry_*_exit()
> functions
s/should/must/
> * when the exception is complete.
> *
> * Callers of irqentry_*_[enter|exit]() should consider this structure
> opaque
s/should/must/
> * and all members private. Descriptions of the members are provided to aid
> in
> * the maintenance of the irqentry_*() functions.
> */
>
> Perhaps Paul can enlighten me on how exit_rcu is used beyond just flagging a
> call to rcu_irq_exit()?
I can do that as well :) The only purpose is to invoke rcu_irq_exit()
conditionally.
> Why do we call lockdep_hardirqs_off() only when in the idle task? That
> implies
> that regs_irqs_disabled() can only be false if we were in the idle task to
> match up the lockdep on/off calls.
You're reading the code slightly wrong.
> This does not make sense to me because why do we need the extra check
> for exit_rcu? I'm still trying to understand when regs_irqs_disabled() is
> false.
It's false when the interrupted context had interrupts enabled.
So we have the following scenarios:
Usermode Idletask irqs enabled RCU entry RCU exit
Y N YY Y
N N YN N
N N NN N
N Y YY Y
N Y NY Y
Now you might wonder about irqs enabled/disabled. This code is not only
used for interrupts (device, ipi, local timer...) where interrupts are
obviously enabled, it's also used for exception entry/exit. You can have
e.g. pagefaults in interrupt disabled regions.
> Also, the comment in irqentry_enter() refers to irq_enter_from_user_mode()
> which
> does not seem to exist anymore. So I'm not sure what careful sequence it is
> referring to.
That was renamed to irqentry_enter_from_user_mode() and the comment was
not updated. Sorry for leaving this hard to solve puzzle around.
Thanks,
tglx
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH -next] ACPI: NFIT: Fix judgment of rc is '-ENXIO'
> Initial value of rc is '-ENXIO', and we should > use the initial value to check it. > > Signed-off-by: Zhang Qilong > --- > drivers/acpi/nfit/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c > index 756227837b3b..3a3c209ed3d3 100644 > --- a/drivers/acpi/nfit/core.c > +++ b/drivers/acpi/nfit/core.c > @@ -1564,7 +1564,7 @@ static ssize_t format1_show(struct device *dev, > le16_to_cpu(nfit_dcr->dcr->code)); > break; > } > - if (rc != ENXIO) > + if (rc != -ENXIO) > break; > } > mutex_unlock(_desc->init_mutex); Reviewed-by: Pankaj Gupta ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
[PATCH -next] ACPI: NFIT: Fix judgment of rc is '-ENXIO'
Initial value of rc is '-ENXIO', and we should use the initial value to check it. Signed-off-by: Zhang Qilong --- drivers/acpi/nfit/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index 756227837b3b..3a3c209ed3d3 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -1564,7 +1564,7 @@ static ssize_t format1_show(struct device *dev, le16_to_cpu(nfit_dcr->dcr->code)); break; } - if (rc != ENXIO) + if (rc != -ENXIO) break; } mutex_unlock(_desc->init_mutex); -- 2.17.1 ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] MIPS: export has_transparent_hugepage() for modules
On Fri, Oct 23, 2020 at 12:44:40PM -0700, Randy Dunlap wrote:
> MIPS should export its local version of "has_transparent_hugepage"
> so that loadable modules (dax) can use it.
>
> Fixes this build error:
> ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined!
>
> Fixes: fd8cfd300019 ("arch: fix has_transparent_hugepage()")
> Reported-by: kernel test robot
> Signed-off-by: Randy Dunlap
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> Cc: Dan Williams
> Cc: Vishal Verma
> Cc: Dave Jiang
> Cc: linux-nvdimm@lists.01.org
> Cc: Hugh Dickins
> Cc: Andrew Morton
> ---
> arch/mips/mm/tlb-r4k.c |1 +
> 1 file changed, 1 insertion(+)
applied to mips-fixes.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v7 3/7] set_memory: allow set_direct_map_*_noflush() for multiple pages
On Tue, Oct 27, 2020 at 09:12:23AM +0100, David Hildenbrand wrote:
> On 26.10.20 20:01, Edgecombe, Rick P wrote:
> > On Mon, 2020-10-26 at 10:37 +0200, Mike Rapoport wrote:
> >> +++ b/arch/x86/mm/pat/set_memory.c
> >> @@ -2184,14 +2184,14 @@ static int __set_pages_np(struct page *page,
> >> int numpages)
> >> return __change_page_attr_set_clr(, 0);
> >> }
> >>
> >> -int set_direct_map_invalid_noflush(struct page *page)
> >> +int set_direct_map_invalid_noflush(struct page *page, int numpages)
> >> {
> >> - return __set_pages_np(page, 1);
> >> + return __set_pages_np(page, numpages);
> >> }
> >>
> >> -int set_direct_map_default_noflush(struct page *page)
> >> +int set_direct_map_default_noflush(struct page *page, int numpages)
> >> {
> >> - return __set_pages_p(page, 1);
> >> + return __set_pages_p(page, numpages);
> >> }
> >
> > Somewhat related to your other series, this could result in large NP
> > pages and trip up hibernate.
> >
>
> It feels somewhat desirable to disable hibernation once secretmem is
> enabled, right? Otherwise you'll be writing out your secrets to swap,
> where they will remain even after booting up again ...
>
> Skipping secretmem pages when hibernating is the wrong approach I guess ...
Completely agree.
I'll look into preventing hibernation from touching secretmem.
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v7 1/7] mm: add definition of PMD_PAGE_ORDER
On 26.10.20 09:37, Mike Rapoport wrote: > From: Mike Rapoport > > The definition of PMD_PAGE_ORDER denoting the number of base pages in the > second-level leaf page is already used by DAX and maybe handy in other > cases as well. > > Several architectures already have definition of PMD_ORDER as the size of > second level page table, so to avoid conflict with these definitions use > PMD_PAGE_ORDER name and update DAX respectively. > > Signed-off-by: Mike Rapoport Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v7 3/7] set_memory: allow set_direct_map_*_noflush() for multiple pages
On 26.10.20 20:01, Edgecombe, Rick P wrote:
> On Mon, 2020-10-26 at 10:37 +0200, Mike Rapoport wrote:
>> +++ b/arch/x86/mm/pat/set_memory.c
>> @@ -2184,14 +2184,14 @@ static int __set_pages_np(struct page *page,
>> int numpages)
>> return __change_page_attr_set_clr(, 0);
>> }
>>
>> -int set_direct_map_invalid_noflush(struct page *page)
>> +int set_direct_map_invalid_noflush(struct page *page, int numpages)
>> {
>> - return __set_pages_np(page, 1);
>> + return __set_pages_np(page, numpages);
>> }
>>
>> -int set_direct_map_default_noflush(struct page *page)
>> +int set_direct_map_default_noflush(struct page *page, int numpages)
>> {
>> - return __set_pages_p(page, 1);
>> + return __set_pages_p(page, numpages);
>> }
>
> Somewhat related to your other series, this could result in large NP
> pages and trip up hibernate.
>
It feels somewhat desirable to disable hibernation once secretmem is
enabled, right? Otherwise you'll be writing out your secrets to swap,
where they will remain even after booting up again ...
Skipping secretmem pages when hibernating is the wrong approach I guess ...
--
Thanks,
David / dhildenb
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH 07/10] x86/entry: Pass irqentry_state_t by reference
On Fri, Oct 23, 2020 at 11:56:33PM +0200, Thomas Gleixner wrote: > On Thu, Oct 22 2020 at 15:26, ira weiny wrote: > > From: Ira Weiny > > > > In preparation for adding PKS information to struct irqentry_state_t > > change all call sites and usages to pass the struct by reference > > instead of by value. > > This still does not explain WHY you need to do that. 'Preparation' is a > pretty useless information. > > What is the actual reason for this? Just because PKS information feels > better that way? > > Also what is PKS information? Changelogs have to make sense on their own > and not only in the context of a larger series of changes. I've reworded this to explain the addition of new members which would make passing by value less efficient with additional structure changes being added later in the series. > > > While we are editing the call sites it is a good time to standardize on > > the name 'irq_state'. > > While at it change all usage sites to consistently use the variable > name 'irq_state'. > > Or something like that. See Documentation/process/... Sorry, bad habit. Fixed. Thanks, Ira > > Thanks, > > tglx > ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH 06/10] x86/entry: Move nmi entry/exit into common code
On Fri, Oct 23, 2020 at 11:50:11PM +0200, Thomas Gleixner wrote:
> On Thu, Oct 22 2020 at 15:26, ira weiny wrote:
>
> > From: Thomas Gleixner
> >
> > Lockdep state handling on NMI enter and exit is nothing specific to X86.
> > It's
> > not any different on other architectures. Also the extra state type is not
> > necessary, irqentry_state_t can carry the necessary information as well.
> >
> > Move it to common code and extend irqentry_state_t to carry lockdep
> > state.
>
> This lacks something like:
>
> [ Ira: Made the states a union as they are mutually exclusive and added
> the missing kernel doc ]
Fair enough. done.
>
> Hrm.
>
> > #ifndef irqentry_state
> > typedef struct irqentry_state {
> > - boolexit_rcu;
> > + union {
> > + boolexit_rcu;
> > + boollockdep;
> > + };
> > } irqentry_state_t;
> > #endif
>
> -E_NO_KERNELDOC
Adding: Paul McKenney
I'm happy to write something but I'm very unfamiliar with this code. So I'm
getting confused what exactly exit_rcu is flagging.
I can see that exit_rcu is a bad name for the state used in
irqentry_nmi_[enter|exit](). Furthermore, I see why 'lockdep' is a better
name. But similar lockdep handling is used in irqentry_exit() if exit_rcu is
true...
Given my limited knowledge; here is my proposed text:
/**
* struct irqentry_state - Opaque object for exception state storage
* @exit_rcu: Used exclusively in the irqentry_*() calls; tracks if the
*exception hit the idle task which requires special handling,
*including calling rcu_irq_exit(), when the exception exits.
* @lockdep: Used exclusively in the irqentry_nmi_*() calls; ensures lockdep
* tracking is maintained if hardirqs were already enabled
*
* This opaque object is filled in by the irqentry_*_enter() functions and
* should be passed back into the corresponding irqentry_*_exit() functions
* when the exception is complete.
*
* Callers of irqentry_*_[enter|exit]() should consider this structure opaque
* and all members private. Descriptions of the members are provided to aid in
* the maintenance of the irqentry_*() functions.
*/
Perhaps Paul can enlighten me on how exit_rcu is used beyond just flagging a
call to rcu_irq_exit()?
Why do we call lockdep_hardirqs_off() only when in the idle task? That implies
that regs_irqs_disabled() can only be false if we were in the idle task to
match up the lockdep on/off calls. This does not make sense to me because why
do we need the extra check for exit_rcu? I'm still trying to understand when
regs_irqs_disabled() is false.
} else if (!regs_irqs_disabled(regs)) {
...
} else {
/*
* IRQ flags state is correct already. Just tell RCU if it
* was not watching on entry.
*/
if (state.exit_rcu)
rcu_irq_exit();
}
Also, the comment in irqentry_enter() refers to irq_enter_from_user_mode() which
does not seem to exist anymore. So I'm not sure what careful sequence it is
referring to.
/*
* If RCU is not watching then the same careful
* sequence vs. lockdep and tracing is required
* as in irq_enter_from_user_mode().
*/
?
Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
