Re: [PATCH] mm: cleancache: fix corruption on missed inode invalidation
On 11/16/18 1:31 AM, Andrew Morton wrote:
> On Mon, 12 Nov 2018 12:57:34 +0300 Pavel Tikhomirov
> wrote:
>
>> If all pages are deleted from the mapping by memory reclaim and also
>> moved to the cleancache:
>>
>> __delete_from_page_cache
>> (no shadow case)
>> unaccount_page_cache_page
>> cleancache_put_page
>> page_cache_delete
>> mapping->nrpages -= nr
>> (nrpages becomes 0)
>>
>> We don't clean the cleancache for an inode after final file truncation
>> (removal).
>>
>> truncate_inode_pages_final
>> check (nrpages || nrexceptional) is false
>> no truncate_inode_pages
>> no cleancache_invalidate_inode(mapping)
>>
>> These way when reading the new file created with same inode we may get
>> these trash leftover pages from cleancache and see wrong data instead of
>> the contents of the new file.
>>
>> Fix it by always doing truncate_inode_pages which is already ready for
>> nrpages == 0 && nrexceptional == 0 case and just invalidates inode.
>>
>
> Data corruption sounds serious. Shouldn't we backport this into
> -stable kernels?
Yes, it was broken in 4.14 kernel and it should affect all who uses cleancache
Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")
Re: [PATCH] mm: cleancache: fix corruption on missed inode invalidation
On 11/16/18 1:31 AM, Andrew Morton wrote:
> On Mon, 12 Nov 2018 12:57:34 +0300 Pavel Tikhomirov
> wrote:
>
>> If all pages are deleted from the mapping by memory reclaim and also
>> moved to the cleancache:
>>
>> __delete_from_page_cache
>> (no shadow case)
>> unaccount_page_cache_page
>> cleancache_put_page
>> page_cache_delete
>> mapping->nrpages -= nr
>> (nrpages becomes 0)
>>
>> We don't clean the cleancache for an inode after final file truncation
>> (removal).
>>
>> truncate_inode_pages_final
>> check (nrpages || nrexceptional) is false
>> no truncate_inode_pages
>> no cleancache_invalidate_inode(mapping)
>>
>> These way when reading the new file created with same inode we may get
>> these trash leftover pages from cleancache and see wrong data instead of
>> the contents of the new file.
>>
>> Fix it by always doing truncate_inode_pages which is already ready for
>> nrpages == 0 && nrexceptional == 0 case and just invalidates inode.
>>
>
> Data corruption sounds serious. Shouldn't we backport this into
> -stable kernels?
Yes, it was broken in 4.14 kernel and it should affect all who uses cleancache
Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")
Re: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3
On Thu, Nov 15, 2018 at 11:30:15AM -0600, Bjorn Helgaas wrote: > > But I guess you have to do this anyway just to add the vendor/device > ID to the driver, so maybe this isn't a big deal to you. If you can > do a quirk like this in the driver, it would be invisible to me and I > wouldn't care. I just don't want to deal with ongoing tweaks like > this in the PCI core :) No, NVMe is a spec with a class code, and a specification that is vendor independent. NVMe devices declare invididual features based on common fields. APST is an optional feature with all kinds of parameters, but there is absolutely no language that a host should not put the device into D3 mode if APST is supported anywhere in the NVMe spec, and such behavior is also rather counter intuitive. If SK Hynix thinks this is sensible behavior they should bring it up in the NVMe technical working group. I've pinged a contact there to see what this whole story is about.
Re: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3
On Thu, Nov 15, 2018 at 11:30:15AM -0600, Bjorn Helgaas wrote: > > But I guess you have to do this anyway just to add the vendor/device > ID to the driver, so maybe this isn't a big deal to you. If you can > do a quirk like this in the driver, it would be invisible to me and I > wouldn't care. I just don't want to deal with ongoing tweaks like > this in the PCI core :) No, NVMe is a spec with a class code, and a specification that is vendor independent. NVMe devices declare invididual features based on common fields. APST is an optional feature with all kinds of parameters, but there is absolutely no language that a host should not put the device into D3 mode if APST is supported anywhere in the NVMe spec, and such behavior is also rather counter intuitive. If SK Hynix thinks this is sensible behavior they should bring it up in the NVMe technical working group. I've pinged a contact there to see what this whole story is about.
Re: [PATCH v2 1/2] Makefile: Fix distcc compilation with x86 macros
On Thu, Nov 15, 2018 at 1:01 PM Nadav Amit wrote: > > Introducing the use of asm macros in c-code broke distcc, since it only > sends the preprocessed source file. The solution is to break the > compilation into two separate phases of compilation and assembly, and > between the two concatenate the assembly macros and the compiled (yet > not assembled) source file. Since this is less efficient, this > compilation mode is only used when distcc or icecc are used. > > Note that the assembly stage should also be distributed, if distcc is > configured using "CFLAGS=-DENABLE_REMOTE_ASSEMBLE". > > Reported-by: Logan Gunthorpe > Signed-off-by: Nadav Amit Wow, this is so ugly. I realized how much I hated this by now. My question is, how long do we need to carry this? As far as I understood from the long discussion https://lkml.org/lkml/2018/10/7/92 people are trying to deal with it on the compiler side. Is it right? https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01932.html Once it is supported, what would happen on the kernel side? > --- > Makefile | 4 +++- > arch/x86/Makefile | 7 +-- > scripts/Makefile.build | 30 -- > 3 files changed, 36 insertions(+), 5 deletions(-) > > diff --git a/Makefile b/Makefile > index 9fce8b91c15f..c07349fc38c7 100644 > --- a/Makefile > +++ b/Makefile > @@ -743,7 +743,9 @@ KBUILD_CFLAGS += $(call cc-option, -gsplit-dwarf, -g) > else > KBUILD_CFLAGS += -g > endif > -KBUILD_AFLAGS += -Wa,-gdwarf-2 > +AFLAGS_DEBUG_INFO = -Wa,-gdwarf-2 > +export AFLAGS_DEBUG_INFO > +KBUILD_AFLAGS += $(AFLAGS_DEBUG_INFO) > endif > ifdef CONFIG_DEBUG_INFO_DWARF4 > KBUILD_CFLAGS += $(call cc-option, -gdwarf-4,) > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index f5d7f4134524..b5953cbcc9c8 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -235,10 +235,13 @@ archscripts: scripts_basic > archheaders: > $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all > > +ASM_MACRO_FILE = arch/x86/kernel/macros.s > +export ASM_MACRO_FILE > + > archmacros: > - $(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s > + $(Q)$(MAKE) $(build)=arch/x86/kernel $(ASM_MACRO_FILE) > > -ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s > +ASM_MACRO_FLAGS = -Wa,$(ASM_MACRO_FILE) > export ASM_MACRO_FLAGS > KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index 6a6be9f440cf..b8d26bdf48b0 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -155,8 +155,34 @@ $(obj)/%.ll: $(src)/%.c FORCE > > quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ > > +# If distcc (or icecc) are used, and when assembly macro files are needed, > the > +# compilation stage and the assembly stage needs to be separated. Providing > the > +# "IGNORE_DISTCC=y" option disables separate compilation and assembly. > + > +cmd_cc_o_c_direct = $(CC) $(c_flags) -c -o $(1) $< > + > +ifneq ($(if $(IGNORE_DISTCC),,$(shell $(CC) --version 2>&1 | head -n 1 | > grep -E 'distcc|ICECC')),) > +a_flags_no_debug = $(filter-out $(AFLAGS_DEBUG_INFO), $(a_flags)) > +c_flags_no_macros = $(filter-out $(ASM_MACRO_FLAGS), $(c_flags)) > + > +cmd_cc_o_c_two_steps = \ > + $(CC) $(c_flags_no_macros) $(DISABLE_LTO) -fverbose-asm -S \ > + -o $(@D)/.$(@F:.o=.s) $<; \ > + cat $(ASM_MACRO_FILE) $(@D)/.$(@F:.o=.s) > \ > + $(@D)/.tmp_$(@F:.o=.s); \ > + $(CC) $(a_flags_no_debug) -c -o $(1) $(@D)/.tmp_$(@F:.o=.s);\ > + rm -f $(@D)/.$(@F:.o=.s) $(@D)/.tmp_$(@F:.o=.s) \ > + > +cmd_cc_o_c_helper =\ > + $(if $(findstring $(ASM_MACRO_FLAGS),$(c_flags)), \ > + $(call cmd_cc_o_c_two_steps, $(1)), \ > + $(call cmd_cc_o_c_direct, $(1))) > +else > +cmd_cc_o_c_helper = $(call cmd_cc_o_c_direct, $(1)) > +endif > + > ifndef CONFIG_MODVERSIONS > -cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< > +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$@) > > else > # When module versioning is enabled the following steps are executed: > @@ -171,7 +197,7 @@ else > # replace the unresolved symbols __crc_exported_symbol with > # the actual value of the checksum generated by genksyms > > -cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $< > +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$(@D)/.tmp_$(@F)) > > cmd_modversions_c = > \ > if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then > \ > -- > 2.17.1 > -- Best Regards Masahiro Yamada
Re: [PATCH 1/1] Input: synaptics - enable SMBus for HP 15-ay000 (SYN3221).
On Fri, Nov 16, 2018 at 6:00 AM Teika Kazura wrote:
>
> SMBus works fine for the touchpad with id SYN3221, used in the HP 15-ay000
> series,
Nice.
Thanks for the patch.
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
>
> This device has been reported in these messages in the "linux-input" mailing
> list:
> * https://marc.info/?l=linux-input=152016683003369=2
> * https://www.spinics.net/lists/linux-input/msg52525.html
>
> Reported-by: Nitesh Debnath
> Reported-by: Teika Kazura
> Signed-off-by: Teika Kazura
> ---
> drivers/input/mouse/synaptics.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 55d33500d5..591b776f22 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -179,6 +179,7 @@ static const char * const smbus_pnp_ids[] = {
> "LEN0096", /* X280 */
> "LEN0097", /* X280 -> ALPS trackpoint */
> "LEN200f", /* T450s */
> + "SYN3221", /* HP 15-ay000 */
> NULL
> };
>
> --
> 2.18.1
Re: [PATCH 1/1] Input: synaptics - enable SMBus for HP 15-ay000 (SYN3221).
On Fri, Nov 16, 2018 at 6:00 AM Teika Kazura wrote:
>
> SMBus works fine for the touchpad with id SYN3221, used in the HP 15-ay000
> series,
Nice.
Thanks for the patch.
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
>
> This device has been reported in these messages in the "linux-input" mailing
> list:
> * https://marc.info/?l=linux-input=152016683003369=2
> * https://www.spinics.net/lists/linux-input/msg52525.html
>
> Reported-by: Nitesh Debnath
> Reported-by: Teika Kazura
> Signed-off-by: Teika Kazura
> ---
> drivers/input/mouse/synaptics.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 55d33500d5..591b776f22 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -179,6 +179,7 @@ static const char * const smbus_pnp_ids[] = {
> "LEN0096", /* X280 */
> "LEN0097", /* X280 -> ALPS trackpoint */
> "LEN200f", /* T450s */
> + "SYN3221", /* HP 15-ay000 */
> NULL
> };
>
> --
> 2.18.1
Re: [PATCH v2 1/2] Makefile: Fix distcc compilation with x86 macros
On Thu, Nov 15, 2018 at 1:01 PM Nadav Amit wrote: > > Introducing the use of asm macros in c-code broke distcc, since it only > sends the preprocessed source file. The solution is to break the > compilation into two separate phases of compilation and assembly, and > between the two concatenate the assembly macros and the compiled (yet > not assembled) source file. Since this is less efficient, this > compilation mode is only used when distcc or icecc are used. > > Note that the assembly stage should also be distributed, if distcc is > configured using "CFLAGS=-DENABLE_REMOTE_ASSEMBLE". > > Reported-by: Logan Gunthorpe > Signed-off-by: Nadav Amit Wow, this is so ugly. I realized how much I hated this by now. My question is, how long do we need to carry this? As far as I understood from the long discussion https://lkml.org/lkml/2018/10/7/92 people are trying to deal with it on the compiler side. Is it right? https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01932.html Once it is supported, what would happen on the kernel side? > --- > Makefile | 4 +++- > arch/x86/Makefile | 7 +-- > scripts/Makefile.build | 30 -- > 3 files changed, 36 insertions(+), 5 deletions(-) > > diff --git a/Makefile b/Makefile > index 9fce8b91c15f..c07349fc38c7 100644 > --- a/Makefile > +++ b/Makefile > @@ -743,7 +743,9 @@ KBUILD_CFLAGS += $(call cc-option, -gsplit-dwarf, -g) > else > KBUILD_CFLAGS += -g > endif > -KBUILD_AFLAGS += -Wa,-gdwarf-2 > +AFLAGS_DEBUG_INFO = -Wa,-gdwarf-2 > +export AFLAGS_DEBUG_INFO > +KBUILD_AFLAGS += $(AFLAGS_DEBUG_INFO) > endif > ifdef CONFIG_DEBUG_INFO_DWARF4 > KBUILD_CFLAGS += $(call cc-option, -gdwarf-4,) > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index f5d7f4134524..b5953cbcc9c8 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -235,10 +235,13 @@ archscripts: scripts_basic > archheaders: > $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all > > +ASM_MACRO_FILE = arch/x86/kernel/macros.s > +export ASM_MACRO_FILE > + > archmacros: > - $(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s > + $(Q)$(MAKE) $(build)=arch/x86/kernel $(ASM_MACRO_FILE) > > -ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s > +ASM_MACRO_FLAGS = -Wa,$(ASM_MACRO_FILE) > export ASM_MACRO_FLAGS > KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index 6a6be9f440cf..b8d26bdf48b0 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -155,8 +155,34 @@ $(obj)/%.ll: $(src)/%.c FORCE > > quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ > > +# If distcc (or icecc) are used, and when assembly macro files are needed, > the > +# compilation stage and the assembly stage needs to be separated. Providing > the > +# "IGNORE_DISTCC=y" option disables separate compilation and assembly. > + > +cmd_cc_o_c_direct = $(CC) $(c_flags) -c -o $(1) $< > + > +ifneq ($(if $(IGNORE_DISTCC),,$(shell $(CC) --version 2>&1 | head -n 1 | > grep -E 'distcc|ICECC')),) > +a_flags_no_debug = $(filter-out $(AFLAGS_DEBUG_INFO), $(a_flags)) > +c_flags_no_macros = $(filter-out $(ASM_MACRO_FLAGS), $(c_flags)) > + > +cmd_cc_o_c_two_steps = \ > + $(CC) $(c_flags_no_macros) $(DISABLE_LTO) -fverbose-asm -S \ > + -o $(@D)/.$(@F:.o=.s) $<; \ > + cat $(ASM_MACRO_FILE) $(@D)/.$(@F:.o=.s) > \ > + $(@D)/.tmp_$(@F:.o=.s); \ > + $(CC) $(a_flags_no_debug) -c -o $(1) $(@D)/.tmp_$(@F:.o=.s);\ > + rm -f $(@D)/.$(@F:.o=.s) $(@D)/.tmp_$(@F:.o=.s) \ > + > +cmd_cc_o_c_helper =\ > + $(if $(findstring $(ASM_MACRO_FLAGS),$(c_flags)), \ > + $(call cmd_cc_o_c_two_steps, $(1)), \ > + $(call cmd_cc_o_c_direct, $(1))) > +else > +cmd_cc_o_c_helper = $(call cmd_cc_o_c_direct, $(1)) > +endif > + > ifndef CONFIG_MODVERSIONS > -cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< > +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$@) > > else > # When module versioning is enabled the following steps are executed: > @@ -171,7 +197,7 @@ else > # replace the unresolved symbols __crc_exported_symbol with > # the actual value of the checksum generated by genksyms > > -cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $< > +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$(@D)/.tmp_$(@F)) > > cmd_modversions_c = > \ > if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then > \ > -- > 2.17.1 > -- Best Regards Masahiro Yamada
[PATCH 2/2] ASoC: sdm845: Add support for Secondary MI2S interface
Add support to configure bit clock for secondary MI2S
TX interface.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/sdm845.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 84e6ee7..58593db 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -19,6 +19,7 @@
struct sdm845_snd_data {
struct snd_soc_card *card;
uint32_t pri_mi2s_clk_count;
+ uint32_t sec_mi2s_clk_count;
uint32_t quat_tdm_clk_count;
};
@@ -121,6 +122,15 @@ static int sdm845_snd_startup(struct snd_pcm_substream
*substream)
snd_soc_dai_set_fmt(cpu_dai, fmt);
break;
+ case SECONDARY_MI2S_TX:
+ if (++(data->sec_mi2s_clk_count) == 1) {
+ snd_soc_dai_set_sysclk(cpu_dai,
+ Q6AFE_LPASS_CLK_ID_SEC_MI2S_IBIT,
+ MI2S_BCLK_RATE, SNDRV_PCM_STREAM_CAPTURE);
+ }
+ snd_soc_dai_set_fmt(cpu_dai, fmt);
+ break;
+
case QUATERNARY_TDM_RX_0:
case QUATERNARY_TDM_TX_0:
if (++(data->quat_tdm_clk_count) == 1) {
@@ -157,6 +167,14 @@ static void sdm845_snd_shutdown(struct snd_pcm_substream
*substream)
};
break;
+ case SECONDARY_MI2S_TX:
+ if (--(data->sec_mi2s_clk_count) == 0) {
+ snd_soc_dai_set_sysclk(cpu_dai,
+ Q6AFE_LPASS_CLK_ID_SEC_MI2S_IBIT,
+ 0, SNDRV_PCM_STREAM_CAPTURE);
+ }
+ break;
+
case QUATERNARY_TDM_RX_0:
case QUATERNARY_TDM_TX_0:
if (--(data->quat_tdm_clk_count) == 0) {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 2/2] ASoC: sdm845: Add support for Secondary MI2S interface
Add support to configure bit clock for secondary MI2S
TX interface.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/sdm845.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 84e6ee7..58593db 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -19,6 +19,7 @@
struct sdm845_snd_data {
struct snd_soc_card *card;
uint32_t pri_mi2s_clk_count;
+ uint32_t sec_mi2s_clk_count;
uint32_t quat_tdm_clk_count;
};
@@ -121,6 +122,15 @@ static int sdm845_snd_startup(struct snd_pcm_substream
*substream)
snd_soc_dai_set_fmt(cpu_dai, fmt);
break;
+ case SECONDARY_MI2S_TX:
+ if (++(data->sec_mi2s_clk_count) == 1) {
+ snd_soc_dai_set_sysclk(cpu_dai,
+ Q6AFE_LPASS_CLK_ID_SEC_MI2S_IBIT,
+ MI2S_BCLK_RATE, SNDRV_PCM_STREAM_CAPTURE);
+ }
+ snd_soc_dai_set_fmt(cpu_dai, fmt);
+ break;
+
case QUATERNARY_TDM_RX_0:
case QUATERNARY_TDM_TX_0:
if (++(data->quat_tdm_clk_count) == 1) {
@@ -157,6 +167,14 @@ static void sdm845_snd_shutdown(struct snd_pcm_substream
*substream)
};
break;
+ case SECONDARY_MI2S_TX:
+ if (--(data->sec_mi2s_clk_count) == 0) {
+ snd_soc_dai_set_sysclk(cpu_dai,
+ Q6AFE_LPASS_CLK_ID_SEC_MI2S_IBIT,
+ 0, SNDRV_PCM_STREAM_CAPTURE);
+ }
+ break;
+
case QUATERNARY_TDM_RX_0:
case QUATERNARY_TDM_TX_0:
if (--(data->quat_tdm_clk_count) == 0) {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 0/2] ASoC: SDM845: Update MI2S and TDM configuration
Update bit clock rate, slot width for TDM and MI2S interfaces. Also add support for secondary MI2S TX interface in SDM845 machine driver. Rohit kumar (2): ASoC: sdm845: Update slot_width for Quaternary TDM port ASoC: sdm845: Add support for Secondary MI2S interface sound/soc/qcom/sdm845.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 1/2] ASoC: sdm845: Update slot_width for Quaternary TDM port
Change slot_width for quaternary TDM port to 16 and
update bclk rate for TDM and MI2S interfaces
accordingly.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/sdm845.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 8d0cdff..84e6ee7 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -13,7 +13,8 @@
#define DEFAULT_SAMPLE_RATE_48K48000
#define DEFAULT_MCLK_RATE 24576000
-#define DEFAULT_BCLK_RATE 12288000
+#define TDM_BCLK_RATE 6144000
+#define MI2S_BCLK_RATE 1536000
struct sdm845_snd_data {
struct snd_soc_card *card;
@@ -33,7 +34,7 @@ static int sdm845_tdm_snd_hw_params(struct snd_pcm_substream
*substream,
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
- slot_width = 32;
+ slot_width = 16;
break;
default:
dev_err(rtd->dev, "%s: invalid param format 0x%x\n",
@@ -115,7 +116,7 @@ static int sdm845_snd_startup(struct snd_pcm_substream
*substream)
DEFAULT_MCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
snd_soc_dai_set_sysclk(cpu_dai,
Q6AFE_LPASS_CLK_ID_PRI_MI2S_IBIT,
- DEFAULT_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
+ MI2S_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
}
snd_soc_dai_set_fmt(cpu_dai, fmt);
break;
@@ -125,7 +126,7 @@ static int sdm845_snd_startup(struct snd_pcm_substream
*substream)
if (++(data->quat_tdm_clk_count) == 1) {
snd_soc_dai_set_sysclk(cpu_dai,
Q6AFE_LPASS_CLK_ID_QUAD_TDM_IBIT,
- DEFAULT_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
+ TDM_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
}
break;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 0/2] ASoC: SDM845: Update MI2S and TDM configuration
Update bit clock rate, slot width for TDM and MI2S interfaces. Also add support for secondary MI2S TX interface in SDM845 machine driver. Rohit kumar (2): ASoC: sdm845: Update slot_width for Quaternary TDM port ASoC: sdm845: Add support for Secondary MI2S interface sound/soc/qcom/sdm845.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 1/2] ASoC: sdm845: Update slot_width for Quaternary TDM port
Change slot_width for quaternary TDM port to 16 and
update bclk rate for TDM and MI2S interfaces
accordingly.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/sdm845.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 8d0cdff..84e6ee7 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -13,7 +13,8 @@
#define DEFAULT_SAMPLE_RATE_48K48000
#define DEFAULT_MCLK_RATE 24576000
-#define DEFAULT_BCLK_RATE 12288000
+#define TDM_BCLK_RATE 6144000
+#define MI2S_BCLK_RATE 1536000
struct sdm845_snd_data {
struct snd_soc_card *card;
@@ -33,7 +34,7 @@ static int sdm845_tdm_snd_hw_params(struct snd_pcm_substream
*substream,
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
- slot_width = 32;
+ slot_width = 16;
break;
default:
dev_err(rtd->dev, "%s: invalid param format 0x%x\n",
@@ -115,7 +116,7 @@ static int sdm845_snd_startup(struct snd_pcm_substream
*substream)
DEFAULT_MCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
snd_soc_dai_set_sysclk(cpu_dai,
Q6AFE_LPASS_CLK_ID_PRI_MI2S_IBIT,
- DEFAULT_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
+ MI2S_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
}
snd_soc_dai_set_fmt(cpu_dai, fmt);
break;
@@ -125,7 +126,7 @@ static int sdm845_snd_startup(struct snd_pcm_substream
*substream)
if (++(data->quat_tdm_clk_count) == 1) {
snd_soc_dai_set_sysclk(cpu_dai,
Q6AFE_LPASS_CLK_ID_QUAD_TDM_IBIT,
- DEFAULT_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
+ TDM_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
}
break;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v2 2/2] x86: set a dependency on macros.S
On Thu, Nov 15, 2018 at 1:01 PM Nadav Amit wrote:
>
> Changes in macros.S should trigger the recompilation of all C files, as
> the macros might need to affect their compilation.
>
> Acked-by: Ingo Molnar
> Signed-off-by: Nadav Amit
> ---
When we talked about this last time,
we agreed to not do this
because a single line change in asm headers
would cause global rebuilding.
Did you change your mind?
> scripts/Makefile.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index b8d26bdf48b0..efec77991c2b 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -313,13 +313,13 @@ cmd_undef_syms = echo
> endif
>
> # Built-in and composite module parts
> -$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
> +$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
> $(ASM_MACRO_FILE:.s=.S) FORCE
> $(call cmd,force_checksrc)
> $(call if_changed_rule,cc_o_c)
>
> # Single-part modules are special since we need to mark them in $(MODVERDIR)
>
> -$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source)
> $(objtool_dep) FORCE
> +$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source)
> $(objtool_dep) $(ASM_MACRO_FILE:.s=.S) FORCE
> $(call cmd,force_checksrc)
> $(call if_changed_rule,cc_o_c)
> @{ echo $(@:.o=.ko); echo $@; \
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 2/2] x86: set a dependency on macros.S
On Thu, Nov 15, 2018 at 1:01 PM Nadav Amit wrote:
>
> Changes in macros.S should trigger the recompilation of all C files, as
> the macros might need to affect their compilation.
>
> Acked-by: Ingo Molnar
> Signed-off-by: Nadav Amit
> ---
When we talked about this last time,
we agreed to not do this
because a single line change in asm headers
would cause global rebuilding.
Did you change your mind?
> scripts/Makefile.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index b8d26bdf48b0..efec77991c2b 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -313,13 +313,13 @@ cmd_undef_syms = echo
> endif
>
> # Built-in and composite module parts
> -$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
> +$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
> $(ASM_MACRO_FILE:.s=.S) FORCE
> $(call cmd,force_checksrc)
> $(call if_changed_rule,cc_o_c)
>
> # Single-part modules are special since we need to mark them in $(MODVERDIR)
>
> -$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source)
> $(objtool_dep) FORCE
> +$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source)
> $(objtool_dep) $(ASM_MACRO_FILE:.s=.S) FORCE
> $(call cmd,force_checksrc)
> $(call if_changed_rule,cc_o_c)
> @{ echo $(@:.o=.ko); echo $@; \
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
Re: [RFC PATCH 5/5] mm, memory_hotplug: be more verbose for memory offline failures
On Thu 15-11-18 16:07:16, Andrew Morton wrote:
> On Wed, 7 Nov 2018 11:18:30 +0100 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > There is only very limited information printed when the memory offlining
> > fails:
> > [ 1984.506184] rac1 kernel: memory offlining [mem
> > 0x826-0x8267fff] failed due to signal backoff
> >
> > This tells us that the failure is triggered by the userspace
> > intervention but it doesn't tell us much more about the underlying
> > reason. It might be that the page migration failes repeatedly and the
> > userspace timeout expires and send a signal or it might be some of the
> > earlier steps (isolation, memory notifier) takes too long.
> >
> > If the migration failes then it would be really helpful to see which
> > page that and its state. The same applies to the isolation phase. If we
> > fail to isolate a page from the allocator then knowing the state of the
> > page would be helpful as well.
> >
> > Dump the page state that fails to get isolated or migrated. This will
> > tell us more about the failure and what to focus on during debugging.
> >
> > ...
> >
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1388,10 +1388,8 @@ do_migrate_range(unsigned long start_pfn, unsigned
> > long end_pfn)
> > page_is_file_cache(page));
> >
> > } else {
> > -#ifdef CONFIG_DEBUG_VM
> > - pr_alert("failed to isolate pfn %lx\n", pfn);
> > + pr_warn("failed to isolate pfn %lx\n", pfn);
> > dump_page(page, "isolation failed");
> > -#endif
> > put_page(page);
> > /* Because we don't have big zone->lock. we should
> >check this again here. */
> > @@ -1411,8 +1409,14 @@ do_migrate_range(unsigned long start_pfn, unsigned
> > long end_pfn)
> > /* Allocate a new page from the nearest neighbor node */
> > ret = migrate_pages(, new_node_page, NULL, 0,
> > MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> > - if (ret)
> > + if (ret) {
> > + list_for_each_entry(page, , lru) {
> > + pr_warn("migrating pfn %lx failed ",
> > + page_to_pfn(page), ret);
> > + dump_page(page, NULL);
> > + }
>
> ./include/linux/kern_levels.h:5:18: warning: too many arguments for format
> [-Wformat-extra-args]
> #define KERN_SOH "\001" /* ASCII Start Of Header */
> ^
> ./include/linux/kern_levels.h:12:22: note: in expansion of macro ‘KERN_SOH’
> #define KERN_WARNING KERN_SOH "4" /* warning conditions */
> ^~~~
> ./include/linux/printk.h:310:9: note: in expansion of macro ‘KERN_WARNING’
> printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
> ^~~~
> ./include/linux/printk.h:311:17: note: in expansion of macro ‘pr_warning’
> #define pr_warn pr_warning
> ^~
> mm/memory_hotplug.c:1414:5: note: in expansion of macro ‘pr_warn’
> pr_warn("migrating pfn %lx failed ",
> ^~~
yeah, 0day already complained and I've posted a follow up fix
http://lkml.kernel.org/r/20181108081231.gn27...@dhcp22.suse.cz
Let me post a version 2 with all the fixups.
Thanks!
> ---
> a/mm/memory_hotplug.c~mm-memory_hotplug-be-more-verbose-for-memory-offline-failures-fix
> +++ a/mm/memory_hotplug.c
> @@ -1411,7 +1411,7 @@ do_migrate_range(unsigned long start_pfn
> MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> if (ret) {
> list_for_each_entry(page, , lru) {
> - pr_warn("migrating pfn %lx failed ",
> + pr_warn("migrating pfn %lx failed: %d",
> page_to_pfn(page), ret);
> dump_page(page, NULL);
> }
>
--
Michal Hocko
SUSE Labs
Re: [RFC PATCH 5/5] mm, memory_hotplug: be more verbose for memory offline failures
On Thu 15-11-18 16:07:16, Andrew Morton wrote:
> On Wed, 7 Nov 2018 11:18:30 +0100 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > There is only very limited information printed when the memory offlining
> > fails:
> > [ 1984.506184] rac1 kernel: memory offlining [mem
> > 0x826-0x8267fff] failed due to signal backoff
> >
> > This tells us that the failure is triggered by the userspace
> > intervention but it doesn't tell us much more about the underlying
> > reason. It might be that the page migration failes repeatedly and the
> > userspace timeout expires and send a signal or it might be some of the
> > earlier steps (isolation, memory notifier) takes too long.
> >
> > If the migration failes then it would be really helpful to see which
> > page that and its state. The same applies to the isolation phase. If we
> > fail to isolate a page from the allocator then knowing the state of the
> > page would be helpful as well.
> >
> > Dump the page state that fails to get isolated or migrated. This will
> > tell us more about the failure and what to focus on during debugging.
> >
> > ...
> >
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1388,10 +1388,8 @@ do_migrate_range(unsigned long start_pfn, unsigned
> > long end_pfn)
> > page_is_file_cache(page));
> >
> > } else {
> > -#ifdef CONFIG_DEBUG_VM
> > - pr_alert("failed to isolate pfn %lx\n", pfn);
> > + pr_warn("failed to isolate pfn %lx\n", pfn);
> > dump_page(page, "isolation failed");
> > -#endif
> > put_page(page);
> > /* Because we don't have big zone->lock. we should
> >check this again here. */
> > @@ -1411,8 +1409,14 @@ do_migrate_range(unsigned long start_pfn, unsigned
> > long end_pfn)
> > /* Allocate a new page from the nearest neighbor node */
> > ret = migrate_pages(, new_node_page, NULL, 0,
> > MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> > - if (ret)
> > + if (ret) {
> > + list_for_each_entry(page, , lru) {
> > + pr_warn("migrating pfn %lx failed ",
> > + page_to_pfn(page), ret);
> > + dump_page(page, NULL);
> > + }
>
> ./include/linux/kern_levels.h:5:18: warning: too many arguments for format
> [-Wformat-extra-args]
> #define KERN_SOH "\001" /* ASCII Start Of Header */
> ^
> ./include/linux/kern_levels.h:12:22: note: in expansion of macro ‘KERN_SOH’
> #define KERN_WARNING KERN_SOH "4" /* warning conditions */
> ^~~~
> ./include/linux/printk.h:310:9: note: in expansion of macro ‘KERN_WARNING’
> printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
> ^~~~
> ./include/linux/printk.h:311:17: note: in expansion of macro ‘pr_warning’
> #define pr_warn pr_warning
> ^~
> mm/memory_hotplug.c:1414:5: note: in expansion of macro ‘pr_warn’
> pr_warn("migrating pfn %lx failed ",
> ^~~
yeah, 0day already complained and I've posted a follow up fix
http://lkml.kernel.org/r/20181108081231.gn27...@dhcp22.suse.cz
Let me post a version 2 with all the fixups.
Thanks!
> ---
> a/mm/memory_hotplug.c~mm-memory_hotplug-be-more-verbose-for-memory-offline-failures-fix
> +++ a/mm/memory_hotplug.c
> @@ -1411,7 +1411,7 @@ do_migrate_range(unsigned long start_pfn
> MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> if (ret) {
> list_for_each_entry(page, , lru) {
> - pr_warn("migrating pfn %lx failed ",
> + pr_warn("migrating pfn %lx failed: %d",
> page_to_pfn(page), ret);
> dump_page(page, NULL);
> }
>
--
Michal Hocko
SUSE Labs
[PATCH 5/6] zram: add bd_stat statistics
bd_stat reprenents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
Documentation/blockdev/zram.txt| 11
drivers/block/zram/zram_drv.c | 31 ++
drivers/block/zram/zram_drv.h | 5
4 files changed, 55 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index d1f80b077885..a4daca7e5043 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -113,3 +113,11 @@ Contact: Minchan Kim
Description:
The writeback file is write-only and trigger idle and/or
huge page writeback to backing device.
+
+What: /sys/block/zram/bd_stat
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The bd_stat file is read-only and represents backing device's
+ statistics (bd_count, bd_reads, bd_writes.) in a format
+ similar to block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 60b585dab6e0..1f4907307a0d 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -221,6 +221,17 @@ The stat file represents device's mm statistics. It
consists of a single
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
+File /sys/block/zram/bd_stat
+
+The stat file represents device's backing device statistics. It consists of
+a single line of text and contains the following stats separated by whitespace:
+ bd_count size of data written in backing device.
+ Unit: pages
+ bd_reads the number of reads from backing device
+ Unit: pages
+ bd_writes the number of writes to backing device
+ Unit: pages
+
9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index b7b5c9e5f0cd..17d566d9a321 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -505,6 +505,8 @@ static unsigned long alloc_block_bdev(struct zram *zram)
ret = blk_idx;
out:
spin_unlock_irq(>bitmap_lock);
+ if (ret != 0)
+ atomic64_inc(>stats.bd_count);
return ret;
}
@@ -518,6 +520,7 @@ static void free_block_bdev(struct zram *zram, unsigned
long blk_idx)
was_set = test_and_clear_bit(blk_idx, zram->bitmap);
spin_unlock_irqrestore(>bitmap_lock, flags);
WARN_ON_ONCE(!was_set);
+ atomic64_dec(>stats.bd_count);
}
static void zram_page_end_io(struct bio *bio)
@@ -661,6 +664,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
+ atomic64_inc(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -748,6 +752,7 @@ static int read_from_bdev_sync(struct zram *zram, struct
bio_vec *bvec,
static int read_from_bdev(struct zram *zram, struct bio_vec *bvec,
unsigned long entry, struct bio *parent, bool sync)
{
+ atomic64_inc(>stats.bd_reads);
if (sync)
return read_from_bdev_sync(zram, bvec, entry, parent);
else
@@ -790,6 +795,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
submit_bio(bio);
*pentry = entry;
+ atomic64_inc(>stats.bd_writes);
return 0;
}
@@ -1053,6 +1059,25 @@ static ssize_t mm_stat_show(struct device *dev,
return ret;
}
+#ifdef CONFIG_ZRAM_WRITEBACK
+static ssize_t bd_stat_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+ ssize_t ret;
+
+ down_read(>init_lock);
+ ret = scnprintf(buf, PAGE_SIZE,
+ "%8llu %8llu %8llu\n",
+ (u64)atomic64_read(>stats.bd_count),
+ (u64)atomic64_read(>stats.bd_reads),
+ (u64)atomic64_read(>stats.bd_writes));
+ up_read(>init_lock);
+
+ return ret;
+}
+#endif
+
static ssize_t debug_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1073,6 +1098,9 @@ static ssize_t debug_stat_show(struct device *dev,
static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
+#ifdef CONFIG_ZRAM_WRITEBACK
+static DEVICE_ATTR_RO(bd_stat);
+#endif
static DEVICE_ATTR_RO(debug_stat);
static void zram_meta_free(struct zram *zram, u64 disksize)
@@ -1813,6 +1841,9 @@ static struct attribute
[PATCH 6/6] zram: writeback throttle
On small memory system, there are lots of write IO so if we use
flash device as swap, there would be serious flash wearout.
To overcome the problem, system developers need to design write
limitation strategy to guarantee flash health for entire product life.
This patch creates a new konb "writeback_limit" on zram. With that,
if current writeback IO count(/sys/block/zramX/io_stat) excceds
the limitation, zram stops further writeback until admin can reset
the limit.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 9
Documentation/blockdev/zram.txt| 2 +
drivers/block/zram/zram_drv.c | 55 --
drivers/block/zram/zram_drv.h | 2 +
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index a4daca7e5043..210f2cdac752 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -121,3 +121,12 @@ Contact: Minchan Kim
The bd_stat file is read-only and represents backing device's
statistics (bd_count, bd_reads, bd_writes.) in a format
similar to block layer statistics file format.
+
+What: /sys/block/zram/writeback_limit
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback_limit file is read-write and specifies the maximum
+ amount of writeback ZRAM can do. The limit could be changed
+ in run time and "0" means disable the limit.
+ No limit is the initial state.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 1f4907307a0d..39ee416bf552 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -164,6 +164,8 @@ reset WOtrigger device reset
mem_used_max WOreset the `mem_used_max' counter (see later)
mem_limit WOspecifies the maximum amount of memory ZRAM can use
to store the compressed data
+writeback_limit WOspecifies the maximum amount of write IO zram
can
+ write out to backing device
max_comp_streams RWthe number of possible concurrent compress operations
comp_algorithmRWshow and change the compression algorithm
compact WOtrigger memory compaction
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 17d566d9a321..b263febaed10 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -317,6 +317,40 @@ static ssize_t idle_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
+
+static ssize_t writeback_limit_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ u64 val;
+ ssize_t ret = -EINVAL;
+
+ if (kstrtoull(buf, 10, ))
+ return ret;
+
+ down_read(>init_lock);
+ atomic64_set(>stats.bd_wb_limit, val);
+ if (val == 0 || val > atomic64_read(>stats.bd_writes))
+ zram->stop_writeback = false;
+ up_read(>init_lock);
+ ret = len;
+
+ return ret;
+}
+
+static ssize_t writeback_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u64 val;
+ struct zram *zram = dev_to_zram(dev);
+
+ down_read(>init_lock);
+ val = atomic64_read(>stats.bd_wb_limit);
+ up_read(>init_lock);
+
+ return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
+}
+
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
@@ -575,6 +609,7 @@ static ssize_t writeback_store(struct device *dev,
ssize_t ret;
unsigned long mode;
unsigned long blk_idx = 0;
+ u64 wb_count, wb_limit;
#define HUGE_WRITEBACK 0x1
#define IDLE_WRITEBACK 0x2
@@ -610,6 +645,11 @@ static ssize_t writeback_store(struct device *dev,
bvec.bv_len = PAGE_SIZE;
bvec.bv_offset = 0;
+ if (zram->stop_writeback) {
+ ret = -EIO;
+ break;
+ }
+
if (!blk_idx) {
blk_idx = alloc_block_bdev(zram);
if (!blk_idx) {
@@ -664,7 +704,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
- atomic64_inc(>stats.bd_writes);
+ wb_count = atomic64_inc_return(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -687,6 +727,9 @@ static ssize_t writeback_store(struct device *dev,
zram_set_element(zram, index, blk_idx);
blk_idx = 0;
[PATCH 5/6] zram: add bd_stat statistics
bd_stat reprenents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
Documentation/blockdev/zram.txt| 11
drivers/block/zram/zram_drv.c | 31 ++
drivers/block/zram/zram_drv.h | 5
4 files changed, 55 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index d1f80b077885..a4daca7e5043 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -113,3 +113,11 @@ Contact: Minchan Kim
Description:
The writeback file is write-only and trigger idle and/or
huge page writeback to backing device.
+
+What: /sys/block/zram/bd_stat
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The bd_stat file is read-only and represents backing device's
+ statistics (bd_count, bd_reads, bd_writes.) in a format
+ similar to block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 60b585dab6e0..1f4907307a0d 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -221,6 +221,17 @@ The stat file represents device's mm statistics. It
consists of a single
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
+File /sys/block/zram/bd_stat
+
+The stat file represents device's backing device statistics. It consists of
+a single line of text and contains the following stats separated by whitespace:
+ bd_count size of data written in backing device.
+ Unit: pages
+ bd_reads the number of reads from backing device
+ Unit: pages
+ bd_writes the number of writes to backing device
+ Unit: pages
+
9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index b7b5c9e5f0cd..17d566d9a321 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -505,6 +505,8 @@ static unsigned long alloc_block_bdev(struct zram *zram)
ret = blk_idx;
out:
spin_unlock_irq(>bitmap_lock);
+ if (ret != 0)
+ atomic64_inc(>stats.bd_count);
return ret;
}
@@ -518,6 +520,7 @@ static void free_block_bdev(struct zram *zram, unsigned
long blk_idx)
was_set = test_and_clear_bit(blk_idx, zram->bitmap);
spin_unlock_irqrestore(>bitmap_lock, flags);
WARN_ON_ONCE(!was_set);
+ atomic64_dec(>stats.bd_count);
}
static void zram_page_end_io(struct bio *bio)
@@ -661,6 +664,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
+ atomic64_inc(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -748,6 +752,7 @@ static int read_from_bdev_sync(struct zram *zram, struct
bio_vec *bvec,
static int read_from_bdev(struct zram *zram, struct bio_vec *bvec,
unsigned long entry, struct bio *parent, bool sync)
{
+ atomic64_inc(>stats.bd_reads);
if (sync)
return read_from_bdev_sync(zram, bvec, entry, parent);
else
@@ -790,6 +795,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
submit_bio(bio);
*pentry = entry;
+ atomic64_inc(>stats.bd_writes);
return 0;
}
@@ -1053,6 +1059,25 @@ static ssize_t mm_stat_show(struct device *dev,
return ret;
}
+#ifdef CONFIG_ZRAM_WRITEBACK
+static ssize_t bd_stat_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+ ssize_t ret;
+
+ down_read(>init_lock);
+ ret = scnprintf(buf, PAGE_SIZE,
+ "%8llu %8llu %8llu\n",
+ (u64)atomic64_read(>stats.bd_count),
+ (u64)atomic64_read(>stats.bd_reads),
+ (u64)atomic64_read(>stats.bd_writes));
+ up_read(>init_lock);
+
+ return ret;
+}
+#endif
+
static ssize_t debug_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1073,6 +1098,9 @@ static ssize_t debug_stat_show(struct device *dev,
static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
+#ifdef CONFIG_ZRAM_WRITEBACK
+static DEVICE_ATTR_RO(bd_stat);
+#endif
static DEVICE_ATTR_RO(debug_stat);
static void zram_meta_free(struct zram *zram, u64 disksize)
@@ -1813,6 +1841,9 @@ static struct attribute
[PATCH 6/6] zram: writeback throttle
On small memory system, there are lots of write IO so if we use
flash device as swap, there would be serious flash wearout.
To overcome the problem, system developers need to design write
limitation strategy to guarantee flash health for entire product life.
This patch creates a new konb "writeback_limit" on zram. With that,
if current writeback IO count(/sys/block/zramX/io_stat) excceds
the limitation, zram stops further writeback until admin can reset
the limit.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 9
Documentation/blockdev/zram.txt| 2 +
drivers/block/zram/zram_drv.c | 55 --
drivers/block/zram/zram_drv.h | 2 +
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index a4daca7e5043..210f2cdac752 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -121,3 +121,12 @@ Contact: Minchan Kim
The bd_stat file is read-only and represents backing device's
statistics (bd_count, bd_reads, bd_writes.) in a format
similar to block layer statistics file format.
+
+What: /sys/block/zram/writeback_limit
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback_limit file is read-write and specifies the maximum
+ amount of writeback ZRAM can do. The limit could be changed
+ in run time and "0" means disable the limit.
+ No limit is the initial state.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 1f4907307a0d..39ee416bf552 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -164,6 +164,8 @@ reset WOtrigger device reset
mem_used_max WOreset the `mem_used_max' counter (see later)
mem_limit WOspecifies the maximum amount of memory ZRAM can use
to store the compressed data
+writeback_limit WOspecifies the maximum amount of write IO zram
can
+ write out to backing device
max_comp_streams RWthe number of possible concurrent compress operations
comp_algorithmRWshow and change the compression algorithm
compact WOtrigger memory compaction
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 17d566d9a321..b263febaed10 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -317,6 +317,40 @@ static ssize_t idle_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
+
+static ssize_t writeback_limit_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ u64 val;
+ ssize_t ret = -EINVAL;
+
+ if (kstrtoull(buf, 10, ))
+ return ret;
+
+ down_read(>init_lock);
+ atomic64_set(>stats.bd_wb_limit, val);
+ if (val == 0 || val > atomic64_read(>stats.bd_writes))
+ zram->stop_writeback = false;
+ up_read(>init_lock);
+ ret = len;
+
+ return ret;
+}
+
+static ssize_t writeback_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u64 val;
+ struct zram *zram = dev_to_zram(dev);
+
+ down_read(>init_lock);
+ val = atomic64_read(>stats.bd_wb_limit);
+ up_read(>init_lock);
+
+ return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
+}
+
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
@@ -575,6 +609,7 @@ static ssize_t writeback_store(struct device *dev,
ssize_t ret;
unsigned long mode;
unsigned long blk_idx = 0;
+ u64 wb_count, wb_limit;
#define HUGE_WRITEBACK 0x1
#define IDLE_WRITEBACK 0x2
@@ -610,6 +645,11 @@ static ssize_t writeback_store(struct device *dev,
bvec.bv_len = PAGE_SIZE;
bvec.bv_offset = 0;
+ if (zram->stop_writeback) {
+ ret = -EIO;
+ break;
+ }
+
if (!blk_idx) {
blk_idx = alloc_block_bdev(zram);
if (!blk_idx) {
@@ -664,7 +704,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
- atomic64_inc(>stats.bd_writes);
+ wb_count = atomic64_inc_return(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -687,6 +727,9 @@ static ssize_t writeback_store(struct device *dev,
zram_set_element(zram, index, blk_idx);
blk_idx = 0;
[PATCH 4/6] zram: support idle page writeback
This patch supports new feature "zram idle page writeback".
On zram-swap usecase, zram has usually idle swap pages come
from many processes. It's pointless to keep in memory(ie, zram).
To solve the problem, this feature gives idle page writeback to
backing device so the goal is to save more memory space
on embedded system.
Normal sequence to use the feature is as follows,
while (1) {
# mark allocated zram slot to idle
echo 1 > /sys/block/zram0/idle
sleep several hours
# idle zram slots are still IDLE marked.
echo 3 > /sys/block/zram0/writeback
# write the IDLE marked slot into backing device and free
# the memory.
}
echo 'val' > /sys/block/zramX/writeback
val is combination of bits.
0th bit: hugepage writeback
1th bit: idlepage writeback
Thus,
1 -> hugepage writeback
2 -> idlepage writeabck
3 -> writeback both pages
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 7 +
Documentation/blockdev/zram.txt| 19 +++
drivers/block/zram/Kconfig | 5 +-
drivers/block/zram/zram_drv.c | 166 +++--
drivers/block/zram/zram_drv.h | 1 +
5 files changed, 187 insertions(+), 11 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 04c9a5980bc7..d1f80b077885 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -106,3 +106,10 @@ Contact: Minchan Kim
idle file is write-only and mark zram slot as idle.
If system has mounted debugfs, user can see which slots
are idle via /sys/kernel/debug/zram/zram/block_state
+
+What: /sys/block/zram/writeback
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback file is write-only and trigger idle and/or
+ huge page writeback to backing device.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index f3bcd716d8a9..60b585dab6e0 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -244,6 +244,25 @@ to backing storage rather than keeping it in memory.
User should set up backing device via /sys/block/zramX/backing_dev
before disksize setting.
+User can writeback idle pages to backing device. To use the feature,
+first, user need to mark zram slots allocated currently as idle.
+Afterward, slots not accessed since then will have still idle mark.
+Then, if user does,
+ "echo val > /sys/block/zramX/writeback"
+
+ val is combination of bits.
+
+ 0th bit: hugepage writeback
+ 1th bit: idlepage writeback
+
+ Thus,
+ 1 -> hugepage writeback
+ 2 -> idlepage writeabck
+ 3 -> writeback both pages
+
+zram will writeback the idle/huge pages to backing device and free the
+memory space pages occupied so save memory.
+
= memory tracking
With CONFIG_ZRAM_MEMORY_TRACKING, user can know information of the
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index fcd055457364..1ffc64770643 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -15,7 +15,7 @@ config ZRAM
See Documentation/blockdev/zram.txt for more information.
config ZRAM_WRITEBACK
- bool "Write back incompressible page to backing device"
+ bool "Write back incompressible or idle page to backing device"
depends on ZRAM
help
With incompressible page, there is no memory saving to keep it
@@ -23,6 +23,9 @@ config ZRAM_WRITEBACK
For this feature, admin should set up backing device via
/sys/block/zramX/backing_dev.
+With /sys/block/zramX/{idle,writeback}, application could ask
+idle page's writeback to the backing device to save in memory.
+
See Documentation/blockdev/zram.txt for more information.
config ZRAM_MEMORY_TRACKING
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f956179076ce..b7b5c9e5f0cd 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -52,6 +52,9 @@ static unsigned int num_devices = 1;
static size_t huge_class_size;
static void zram_free_page(struct zram *zram, size_t index);
+static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
+ u32 index, int offset, struct bio *bio);
+
static int zram_slot_trylock(struct zram *zram, u32 index)
{
@@ -73,13 +76,6 @@ static inline bool init_done(struct zram *zram)
return zram->disksize;
}
-static inline bool zram_allocated(struct zram *zram, u32 index)
-{
-
- return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
- zram->table[index].handle;
-}
-
static inline struct zram *dev_to_zram(struct device *dev)
{
return (struct zram *)dev_to_disk(dev)->private_data;
@@ -138,6 +134,13 @@ static void
[PATCH 4/6] zram: support idle page writeback
This patch supports new feature "zram idle page writeback".
On zram-swap usecase, zram has usually idle swap pages come
from many processes. It's pointless to keep in memory(ie, zram).
To solve the problem, this feature gives idle page writeback to
backing device so the goal is to save more memory space
on embedded system.
Normal sequence to use the feature is as follows,
while (1) {
# mark allocated zram slot to idle
echo 1 > /sys/block/zram0/idle
sleep several hours
# idle zram slots are still IDLE marked.
echo 3 > /sys/block/zram0/writeback
# write the IDLE marked slot into backing device and free
# the memory.
}
echo 'val' > /sys/block/zramX/writeback
val is combination of bits.
0th bit: hugepage writeback
1th bit: idlepage writeback
Thus,
1 -> hugepage writeback
2 -> idlepage writeabck
3 -> writeback both pages
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 7 +
Documentation/blockdev/zram.txt| 19 +++
drivers/block/zram/Kconfig | 5 +-
drivers/block/zram/zram_drv.c | 166 +++--
drivers/block/zram/zram_drv.h | 1 +
5 files changed, 187 insertions(+), 11 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 04c9a5980bc7..d1f80b077885 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -106,3 +106,10 @@ Contact: Minchan Kim
idle file is write-only and mark zram slot as idle.
If system has mounted debugfs, user can see which slots
are idle via /sys/kernel/debug/zram/zram/block_state
+
+What: /sys/block/zram/writeback
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback file is write-only and trigger idle and/or
+ huge page writeback to backing device.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index f3bcd716d8a9..60b585dab6e0 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -244,6 +244,25 @@ to backing storage rather than keeping it in memory.
User should set up backing device via /sys/block/zramX/backing_dev
before disksize setting.
+User can writeback idle pages to backing device. To use the feature,
+first, user need to mark zram slots allocated currently as idle.
+Afterward, slots not accessed since then will have still idle mark.
+Then, if user does,
+ "echo val > /sys/block/zramX/writeback"
+
+ val is combination of bits.
+
+ 0th bit: hugepage writeback
+ 1th bit: idlepage writeback
+
+ Thus,
+ 1 -> hugepage writeback
+ 2 -> idlepage writeabck
+ 3 -> writeback both pages
+
+zram will writeback the idle/huge pages to backing device and free the
+memory space pages occupied so save memory.
+
= memory tracking
With CONFIG_ZRAM_MEMORY_TRACKING, user can know information of the
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index fcd055457364..1ffc64770643 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -15,7 +15,7 @@ config ZRAM
See Documentation/blockdev/zram.txt for more information.
config ZRAM_WRITEBACK
- bool "Write back incompressible page to backing device"
+ bool "Write back incompressible or idle page to backing device"
depends on ZRAM
help
With incompressible page, there is no memory saving to keep it
@@ -23,6 +23,9 @@ config ZRAM_WRITEBACK
For this feature, admin should set up backing device via
/sys/block/zramX/backing_dev.
+With /sys/block/zramX/{idle,writeback}, application could ask
+idle page's writeback to the backing device to save in memory.
+
See Documentation/blockdev/zram.txt for more information.
config ZRAM_MEMORY_TRACKING
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f956179076ce..b7b5c9e5f0cd 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -52,6 +52,9 @@ static unsigned int num_devices = 1;
static size_t huge_class_size;
static void zram_free_page(struct zram *zram, size_t index);
+static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
+ u32 index, int offset, struct bio *bio);
+
static int zram_slot_trylock(struct zram *zram, u32 index)
{
@@ -73,13 +76,6 @@ static inline bool init_done(struct zram *zram)
return zram->disksize;
}
-static inline bool zram_allocated(struct zram *zram, u32 index)
-{
-
- return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
- zram->table[index].handle;
-}
-
static inline struct zram *dev_to_zram(struct device *dev)
{
return (struct zram *)dev_to_disk(dev)->private_data;
@@ -138,6 +134,13 @@ static void
[PATCH 1/6] zram: fix lockdep warning of free block handling
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 254.521732] b1828693 (&(>bitmap_lock)->rlock){+.?.}, at:
put_entry_bdev+0x1e/0x50
[ 254.521732] {SOFTIRQ-ON-W} state was registered at:
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] zram_make_request+0x755/0xdc9
[ 254.521732] generic_make_request+0x373/0x6a0
[ 254.521732] submit_bio+0x6c/0x140
[ 254.521732] __swap_writepage+0x3a8/0x480
[ 254.521732] shrink_page_list+0x1102/0x1a60
[ 254.521732] shrink_inactive_list+0x21b/0x3f0
[ 254.521732] shrink_node_memcg.constprop.99+0x4f8/0x7e0
[ 254.521732] shrink_node+0x7d/0x2f0
[ 254.521732] do_try_to_free_pages+0xe0/0x300
[ 254.521732] try_to_free_pages+0x116/0x2b0
[ 254.521732] __alloc_pages_slowpath+0x3f4/0xf80
[ 254.521732] __alloc_pages_nodemask+0x2a2/0x2f0
[ 254.521732] __handle_mm_fault+0x42e/0xb50
[ 254.521732] handle_mm_fault+0x55/0xb0
[ 254.521732] __do_page_fault+0x235/0x4b0
[ 254.521732] page_fault+0x1e/0x30
[ 254.521732] irq event stamp: 228412
[ 254.521732] hardirqs last enabled at (228412): []
__slab_free+0x3e6/0x600
[ 254.521732] hardirqs last disabled at (228411): []
__slab_free+0x1c5/0x600
[ 254.521732] softirqs last enabled at (228396): []
__do_softirq+0x31e/0x427
[ 254.521732] softirqs last disabled at (228403): []
irq_exit+0xd1/0xe0
[ 254.521732]
[ 254.521732] other info that might help us debug this:
[ 254.521732] Possible unsafe locking scenario:
[ 254.521732]
[ 254.521732]CPU0
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] *** DEADLOCK ***
[ 254.521732]
[ 254.521732] no locks held by zram_verify/2095.
[ 254.521732]
[ 254.521732] stack backtrace:
[ 254.521732] CPU: 5 PID: 2095 Comm: zram_verify Not tainted 4.19.0+ #390
[ 254.521732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 254.521732] Call Trace:
[ 254.521732]
[ 254.521732] dump_stack+0x67/0x9b
[ 254.521732] print_usage_bug+0x1bd/0x1d3
[ 254.521732] mark_lock+0x4aa/0x540
[ 254.521732] ? check_usage_backwards+0x160/0x160
[ 254.521732] __lock_acquire+0x51d/0x1300
[ 254.521732] ? free_debug_processing+0x24e/0x400
[ 254.521732] ? bio_endio+0x6d/0x1a0
[ 254.521732] ? lockdep_hardirqs_on+0x9b/0x180
[ 254.521732] ? lock_acquire+0x90/0x180
[ 254.521732] lock_acquire+0x90/0x180
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] put_entry_bdev+0x1e/0x50
[ 254.521732] zram_free_page+0xf6/0x110
[ 254.521732] zram_slot_free_notify+0x42/0xa0
[ 254.521732] end_swap_bio_read+0x5b/0x170
[ 254.521732] blk_update_request+0x8f/0x340
[ 254.521732] scsi_end_request+0x2c/0x1e0
[ 254.521732] scsi_io_completion+0x98/0x650
[ 254.521732] blk_done_softirq+0x9e/0xd0
[ 254.521732] __do_softirq+0xcc/0x427
[ 254.521732] irq_exit+0xd1/0xe0
[ 254.521732] do_IRQ+0x93/0x120
[ 254.521732] common_interrupt+0xf/0xf
[ 254.521732]
With writeback feature, zram_slot_free_notify could be called
in softirq context by end_swap_bio_read. However, bitmap_lock
is not aware of that so lockdep yell out. Thanks.
The problem is not only bitmap_lock but it is also zram_slot_lock
so straightforward solution would disable irq on zram_slot_lock
which covers every bitmap_lock, too.
Although duration disabling the irq is short in many places
zram_slot_lock is used, a place(ie, decompress) is not fast
enough to hold irqlock on relying on compression algorithm
so it's not a option.
The approach in this patch is just "best effort", not guarantee
"freeing orphan zpage". If the zram_slot_lock contention may happen,
kernel couldn't free the zpage until it recycles the block. However,
such contention between zram_slot_free_notify and other places to
hold zram_slot_lock should be very rare in real practice.
To see how often it happens, this patch adds new debug stat
"miss_free".
It also adds irq lock in get/put_block_bdev to prevent deadlock
lockdep reported. The reason I used irq disable rather than bottom
half is swap_slot_free_notify could be called with irq disabled
so it breaks local_bh_enable's rule. The irqlock works on only
writebacked zram slot entry so it should be not frequent lock.
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 56 +--
drivers/block/zram/zram_drv.h | 1 +
2 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4879595200e1..472027eaed60 100644
---
[PATCH 3/6] zram: introduce ZRAM_IDLE flag
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo 1 > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by /sys/kernel/debug/zram/zram0/block_state.
30075.033841 ...i
30163.806904 s..i
30263.806919 ..hi
Once there is IO for the slot, the mark will be disappeared.
30075.033841 ...
30163.806904 s..i
30263.806919 ..hi
Therefore, 300th block is idle zpage. With this feature,
user can how many zram has idle pages which are waste of memory.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8
Documentation/blockdev/zram.txt| 10 +++--
drivers/block/zram/zram_drv.c | 44 --
drivers/block/zram/zram_drv.h | 1 +
4 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index c1513c756af1..04c9a5980bc7 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -98,3 +98,11 @@ Contact: Minchan Kim
The backing_dev file is read-write and set up backing
device for zram to write incompressible pages.
For using, user should enable CONFIG_ZRAM_WRITEBACK.
+
+What: /sys/block/zram/idle
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ idle file is write-only and mark zram slot as idle.
+ If system has mounted debugfs, user can see which slots
+ are idle via /sys/kernel/debug/zram/zram/block_state
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 3c1b5ab54bc0..f3bcd716d8a9 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -169,6 +169,7 @@ comp_algorithmRWshow and change the compression
algorithm
compact WOtrigger memory compaction
debug_statROthis file is used for zram debugging purposes
backing_dev RWset up backend storage for zram to write out
+idle WOmark allocated slot as idle
User space is advised to use the following files to read the device statistics.
@@ -251,16 +252,17 @@ pages of the process with*pagemap.
If you enable the feature, you could see block state via
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
- 30075.033841 .wh
- 30163.806904 s..
- 30263.806919 ..h
+ 30075.033841 .wh.
+ 30163.806904 s...
+ 30263.806919 ..hi
First column is zram's block index.
Second column is access time since the system was booted
Third column is state of the block.
(s: same page
w: written page to backing store
-h: huge page)
+h: huge page
+i: idle page)
First line of above example says 300th block is accessed at 75.033841sec
and the block's state is huge so it is written back to the backing
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index bc59db2b1036..f956179076ce 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -281,6 +281,34 @@ static ssize_t mem_used_max_store(struct device *dev,
return len;
}
+static ssize_t idle_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
+ int index;
+
+ down_read(>init_lock);
+ if (!init_done(zram)) {
+ up_read(>init_lock);
+ return -EINVAL;
+ }
+
+ for (index = 0; index < nr_pages; index++) {
+ zram_slot_lock(zram, index);
+ if (!zram_allocated(zram, index))
+ goto next;
+
+ zram_set_flag(zram, index, ZRAM_IDLE);
+next:
+ zram_slot_unlock(zram, index);
+ }
+
+ up_read(>init_lock);
+
+ return len;
+}
+
#ifdef CONFIG_ZRAM_WRITEBACK
static void reset_bdev(struct zram *zram)
{
@@ -658,6 +686,7 @@ static void zram_debugfs_destroy(void)
static void zram_accessed(struct zram *zram, u32 index)
{
+ zram_clear_flag(zram, index, ZRAM_IDLE);
zram->table[index].ac_time = ktime_get_boottime();
}
@@ -690,12 +719,13 @@ static ssize_t read_block_state(struct file *file, char
__user *buf,
ts = ktime_to_timespec64(zram->table[index].ac_time);
copied = snprintf(kbuf + written, count,
- "%12zd %12lld.%06lu %c%c%c\n",
+ "%12zd %12lld.%06lu %c%c%c%c\n",
index, (s64)ts.tv_sec,
ts.tv_nsec / NSEC_PER_USEC,
zram_test_flag(zram,
[PATCH 1/6] zram: fix lockdep warning of free block handling
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 254.521732] b1828693 (&(>bitmap_lock)->rlock){+.?.}, at:
put_entry_bdev+0x1e/0x50
[ 254.521732] {SOFTIRQ-ON-W} state was registered at:
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] zram_make_request+0x755/0xdc9
[ 254.521732] generic_make_request+0x373/0x6a0
[ 254.521732] submit_bio+0x6c/0x140
[ 254.521732] __swap_writepage+0x3a8/0x480
[ 254.521732] shrink_page_list+0x1102/0x1a60
[ 254.521732] shrink_inactive_list+0x21b/0x3f0
[ 254.521732] shrink_node_memcg.constprop.99+0x4f8/0x7e0
[ 254.521732] shrink_node+0x7d/0x2f0
[ 254.521732] do_try_to_free_pages+0xe0/0x300
[ 254.521732] try_to_free_pages+0x116/0x2b0
[ 254.521732] __alloc_pages_slowpath+0x3f4/0xf80
[ 254.521732] __alloc_pages_nodemask+0x2a2/0x2f0
[ 254.521732] __handle_mm_fault+0x42e/0xb50
[ 254.521732] handle_mm_fault+0x55/0xb0
[ 254.521732] __do_page_fault+0x235/0x4b0
[ 254.521732] page_fault+0x1e/0x30
[ 254.521732] irq event stamp: 228412
[ 254.521732] hardirqs last enabled at (228412): []
__slab_free+0x3e6/0x600
[ 254.521732] hardirqs last disabled at (228411): []
__slab_free+0x1c5/0x600
[ 254.521732] softirqs last enabled at (228396): []
__do_softirq+0x31e/0x427
[ 254.521732] softirqs last disabled at (228403): []
irq_exit+0xd1/0xe0
[ 254.521732]
[ 254.521732] other info that might help us debug this:
[ 254.521732] Possible unsafe locking scenario:
[ 254.521732]
[ 254.521732]CPU0
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] *** DEADLOCK ***
[ 254.521732]
[ 254.521732] no locks held by zram_verify/2095.
[ 254.521732]
[ 254.521732] stack backtrace:
[ 254.521732] CPU: 5 PID: 2095 Comm: zram_verify Not tainted 4.19.0+ #390
[ 254.521732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 254.521732] Call Trace:
[ 254.521732]
[ 254.521732] dump_stack+0x67/0x9b
[ 254.521732] print_usage_bug+0x1bd/0x1d3
[ 254.521732] mark_lock+0x4aa/0x540
[ 254.521732] ? check_usage_backwards+0x160/0x160
[ 254.521732] __lock_acquire+0x51d/0x1300
[ 254.521732] ? free_debug_processing+0x24e/0x400
[ 254.521732] ? bio_endio+0x6d/0x1a0
[ 254.521732] ? lockdep_hardirqs_on+0x9b/0x180
[ 254.521732] ? lock_acquire+0x90/0x180
[ 254.521732] lock_acquire+0x90/0x180
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] put_entry_bdev+0x1e/0x50
[ 254.521732] zram_free_page+0xf6/0x110
[ 254.521732] zram_slot_free_notify+0x42/0xa0
[ 254.521732] end_swap_bio_read+0x5b/0x170
[ 254.521732] blk_update_request+0x8f/0x340
[ 254.521732] scsi_end_request+0x2c/0x1e0
[ 254.521732] scsi_io_completion+0x98/0x650
[ 254.521732] blk_done_softirq+0x9e/0xd0
[ 254.521732] __do_softirq+0xcc/0x427
[ 254.521732] irq_exit+0xd1/0xe0
[ 254.521732] do_IRQ+0x93/0x120
[ 254.521732] common_interrupt+0xf/0xf
[ 254.521732]
With writeback feature, zram_slot_free_notify could be called
in softirq context by end_swap_bio_read. However, bitmap_lock
is not aware of that so lockdep yell out. Thanks.
The problem is not only bitmap_lock but it is also zram_slot_lock
so straightforward solution would disable irq on zram_slot_lock
which covers every bitmap_lock, too.
Although duration disabling the irq is short in many places
zram_slot_lock is used, a place(ie, decompress) is not fast
enough to hold irqlock on relying on compression algorithm
so it's not a option.
The approach in this patch is just "best effort", not guarantee
"freeing orphan zpage". If the zram_slot_lock contention may happen,
kernel couldn't free the zpage until it recycles the block. However,
such contention between zram_slot_free_notify and other places to
hold zram_slot_lock should be very rare in real practice.
To see how often it happens, this patch adds new debug stat
"miss_free".
It also adds irq lock in get/put_block_bdev to prevent deadlock
lockdep reported. The reason I used irq disable rather than bottom
half is swap_slot_free_notify could be called with irq disabled
so it breaks local_bh_enable's rule. The irqlock works on only
writebacked zram slot entry so it should be not frequent lock.
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 56 +--
drivers/block/zram/zram_drv.h | 1 +
2 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4879595200e1..472027eaed60 100644
---
[PATCH 3/6] zram: introduce ZRAM_IDLE flag
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo 1 > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by /sys/kernel/debug/zram/zram0/block_state.
30075.033841 ...i
30163.806904 s..i
30263.806919 ..hi
Once there is IO for the slot, the mark will be disappeared.
30075.033841 ...
30163.806904 s..i
30263.806919 ..hi
Therefore, 300th block is idle zpage. With this feature,
user can how many zram has idle pages which are waste of memory.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8
Documentation/blockdev/zram.txt| 10 +++--
drivers/block/zram/zram_drv.c | 44 --
drivers/block/zram/zram_drv.h | 1 +
4 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index c1513c756af1..04c9a5980bc7 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -98,3 +98,11 @@ Contact: Minchan Kim
The backing_dev file is read-write and set up backing
device for zram to write incompressible pages.
For using, user should enable CONFIG_ZRAM_WRITEBACK.
+
+What: /sys/block/zram/idle
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ idle file is write-only and mark zram slot as idle.
+ If system has mounted debugfs, user can see which slots
+ are idle via /sys/kernel/debug/zram/zram/block_state
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 3c1b5ab54bc0..f3bcd716d8a9 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -169,6 +169,7 @@ comp_algorithmRWshow and change the compression
algorithm
compact WOtrigger memory compaction
debug_statROthis file is used for zram debugging purposes
backing_dev RWset up backend storage for zram to write out
+idle WOmark allocated slot as idle
User space is advised to use the following files to read the device statistics.
@@ -251,16 +252,17 @@ pages of the process with*pagemap.
If you enable the feature, you could see block state via
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
- 30075.033841 .wh
- 30163.806904 s..
- 30263.806919 ..h
+ 30075.033841 .wh.
+ 30163.806904 s...
+ 30263.806919 ..hi
First column is zram's block index.
Second column is access time since the system was booted
Third column is state of the block.
(s: same page
w: written page to backing store
-h: huge page)
+h: huge page
+i: idle page)
First line of above example says 300th block is accessed at 75.033841sec
and the block's state is huge so it is written back to the backing
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index bc59db2b1036..f956179076ce 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -281,6 +281,34 @@ static ssize_t mem_used_max_store(struct device *dev,
return len;
}
+static ssize_t idle_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
+ int index;
+
+ down_read(>init_lock);
+ if (!init_done(zram)) {
+ up_read(>init_lock);
+ return -EINVAL;
+ }
+
+ for (index = 0; index < nr_pages; index++) {
+ zram_slot_lock(zram, index);
+ if (!zram_allocated(zram, index))
+ goto next;
+
+ zram_set_flag(zram, index, ZRAM_IDLE);
+next:
+ zram_slot_unlock(zram, index);
+ }
+
+ up_read(>init_lock);
+
+ return len;
+}
+
#ifdef CONFIG_ZRAM_WRITEBACK
static void reset_bdev(struct zram *zram)
{
@@ -658,6 +686,7 @@ static void zram_debugfs_destroy(void)
static void zram_accessed(struct zram *zram, u32 index)
{
+ zram_clear_flag(zram, index, ZRAM_IDLE);
zram->table[index].ac_time = ktime_get_boottime();
}
@@ -690,12 +719,13 @@ static ssize_t read_block_state(struct file *file, char
__user *buf,
ts = ktime_to_timespec64(zram->table[index].ac_time);
copied = snprintf(kbuf + written, count,
- "%12zd %12lld.%06lu %c%c%c\n",
+ "%12zd %12lld.%06lu %c%c%c%c\n",
index, (s64)ts.tv_sec,
ts.tv_nsec / NSEC_PER_USEC,
zram_test_flag(zram,
[PATCH 2/6] zram: refactoring flags and writeback stuff
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
drivers/block/zram/zram_drv.h | 8 +--
2 files changed, 44 insertions(+), 69 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 472027eaed60..bc59db2b1036 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -55,17 +55,17 @@ static void zram_free_page(struct zram *zram, size_t index);
static int zram_slot_trylock(struct zram *zram, u32 index)
{
- return bit_spin_trylock(ZRAM_LOCK, >table[index].value);
+ return bit_spin_trylock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_lock(struct zram *zram, u32 index)
{
- bit_spin_lock(ZRAM_LOCK, >table[index].value);
+ bit_spin_lock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_unlock(struct zram *zram, u32 index)
{
- bit_spin_unlock(ZRAM_LOCK, >table[index].value);
+ bit_spin_unlock(ZRAM_LOCK, >table[index].flags);
}
static inline bool init_done(struct zram *zram)
@@ -76,7 +76,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
zram->table[index].handle;
}
@@ -99,19 +99,19 @@ static void zram_set_handle(struct zram *zram, u32 index,
unsigned long handle)
static bool zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- return zram->table[index].value & BIT(flag);
+ return zram->table[index].flags & BIT(flag);
}
static void zram_set_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value |= BIT(flag);
+ zram->table[index].flags |= BIT(flag);
}
static void zram_clear_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value &= ~BIT(flag);
+ zram->table[index].flags &= ~BIT(flag);
}
static inline void zram_set_element(struct zram *zram, u32 index,
@@ -127,15 +127,15 @@ static unsigned long zram_get_element(struct zram *zram,
u32 index)
static size_t zram_get_obj_size(struct zram *zram, u32 index)
{
- return zram->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
+ return zram->table[index].flags & (BIT(ZRAM_FLAG_SHIFT) - 1);
}
static void zram_set_obj_size(struct zram *zram,
u32 index, size_t size)
{
- unsigned long flags = zram->table[index].value >> ZRAM_FLAG_SHIFT;
+ unsigned long flags = zram->table[index].flags >> ZRAM_FLAG_SHIFT;
- zram->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
+ zram->table[index].flags = (flags << ZRAM_FLAG_SHIFT) | size;
}
#if PAGE_SIZE != 4096
@@ -282,16 +282,11 @@ static ssize_t mem_used_max_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
-static bool zram_wb_enabled(struct zram *zram)
-{
- return zram->backing_dev;
-}
-
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
- if (!zram_wb_enabled(zram))
+ if (!zram->backing_dev)
return;
bdev = zram->bdev;
@@ -318,7 +313,7 @@ static ssize_t backing_dev_show(struct device *dev,
ssize_t ret;
down_read(>init_lock);
- if (!zram_wb_enabled(zram)) {
+ if (!zram->backing_dev) {
memcpy(buf, "none\n", 5);
up_read(>init_lock);
return 5;
@@ -446,7 +441,7 @@ static ssize_t backing_dev_store(struct device *dev,
return err;
}
-static unsigned long get_entry_bdev(struct zram *zram)
+static unsigned long alloc_block_bdev(struct zram *zram)
{
unsigned long blk_idx;
unsigned long ret = 0;
@@ -479,13 +474,13 @@ static unsigned long get_entry_bdev(struct zram *zram)
return ret;
}
-static void put_entry_bdev(struct zram *zram, unsigned long entry)
+static void free_block_bdev(struct zram *zram, unsigned long blk_idx)
{
int was_set;
unsigned long flags;
spin_lock_irqsave(>bitmap_lock, flags);
- was_set = test_and_clear_bit(entry, zram->bitmap);
+ was_set = test_and_clear_bit(blk_idx, zram->bitmap);
spin_unlock_irqrestore(>bitmap_lock, flags);
WARN_ON_ONCE(!was_set);
}
@@ -599,7 +594,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio)
return -ENOMEM;
- entry = get_entry_bdev(zram);
+ entry = alloc_block_bdev(zram);
if (!entry) {
bio_put(bio);
return -ENOSPC;
@@ -610,7 +605,7 @@ static int write_to_bdev(struct zram *zram,
[PATCH 0/6] zram idle page writeback
Inherently, swap device has many idle pages which are rare touched since it was allocated. It is never problem if we use storage device as swap. However, it's just waste for zram-swap. This patchset supports zram idle page writeback feature. * Admin can define what is idle page "no access since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Minchan Kim (6): zram: fix lockdep warning of free block handling zram: refactoring flags and writeback stuff zram: introduce ZRAM_IDLE flag zram: support idle page writeback zram: add bd_stat statistics zram: writeback throttle Documentation/ABI/testing/sysfs-block-zram | 32 ++ Documentation/blockdev/zram.txt| 42 +- drivers/block/zram/Kconfig | 5 +- drivers/block/zram/zram_drv.c | 435 + drivers/block/zram/zram_drv.h | 18 +- 5 files changed, 438 insertions(+), 94 deletions(-) -- 2.19.1.1215.g8438c0b245-goog
[PATCH 2/6] zram: refactoring flags and writeback stuff
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
drivers/block/zram/zram_drv.h | 8 +--
2 files changed, 44 insertions(+), 69 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 472027eaed60..bc59db2b1036 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -55,17 +55,17 @@ static void zram_free_page(struct zram *zram, size_t index);
static int zram_slot_trylock(struct zram *zram, u32 index)
{
- return bit_spin_trylock(ZRAM_LOCK, >table[index].value);
+ return bit_spin_trylock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_lock(struct zram *zram, u32 index)
{
- bit_spin_lock(ZRAM_LOCK, >table[index].value);
+ bit_spin_lock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_unlock(struct zram *zram, u32 index)
{
- bit_spin_unlock(ZRAM_LOCK, >table[index].value);
+ bit_spin_unlock(ZRAM_LOCK, >table[index].flags);
}
static inline bool init_done(struct zram *zram)
@@ -76,7 +76,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
zram->table[index].handle;
}
@@ -99,19 +99,19 @@ static void zram_set_handle(struct zram *zram, u32 index,
unsigned long handle)
static bool zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- return zram->table[index].value & BIT(flag);
+ return zram->table[index].flags & BIT(flag);
}
static void zram_set_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value |= BIT(flag);
+ zram->table[index].flags |= BIT(flag);
}
static void zram_clear_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value &= ~BIT(flag);
+ zram->table[index].flags &= ~BIT(flag);
}
static inline void zram_set_element(struct zram *zram, u32 index,
@@ -127,15 +127,15 @@ static unsigned long zram_get_element(struct zram *zram,
u32 index)
static size_t zram_get_obj_size(struct zram *zram, u32 index)
{
- return zram->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
+ return zram->table[index].flags & (BIT(ZRAM_FLAG_SHIFT) - 1);
}
static void zram_set_obj_size(struct zram *zram,
u32 index, size_t size)
{
- unsigned long flags = zram->table[index].value >> ZRAM_FLAG_SHIFT;
+ unsigned long flags = zram->table[index].flags >> ZRAM_FLAG_SHIFT;
- zram->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
+ zram->table[index].flags = (flags << ZRAM_FLAG_SHIFT) | size;
}
#if PAGE_SIZE != 4096
@@ -282,16 +282,11 @@ static ssize_t mem_used_max_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
-static bool zram_wb_enabled(struct zram *zram)
-{
- return zram->backing_dev;
-}
-
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
- if (!zram_wb_enabled(zram))
+ if (!zram->backing_dev)
return;
bdev = zram->bdev;
@@ -318,7 +313,7 @@ static ssize_t backing_dev_show(struct device *dev,
ssize_t ret;
down_read(>init_lock);
- if (!zram_wb_enabled(zram)) {
+ if (!zram->backing_dev) {
memcpy(buf, "none\n", 5);
up_read(>init_lock);
return 5;
@@ -446,7 +441,7 @@ static ssize_t backing_dev_store(struct device *dev,
return err;
}
-static unsigned long get_entry_bdev(struct zram *zram)
+static unsigned long alloc_block_bdev(struct zram *zram)
{
unsigned long blk_idx;
unsigned long ret = 0;
@@ -479,13 +474,13 @@ static unsigned long get_entry_bdev(struct zram *zram)
return ret;
}
-static void put_entry_bdev(struct zram *zram, unsigned long entry)
+static void free_block_bdev(struct zram *zram, unsigned long blk_idx)
{
int was_set;
unsigned long flags;
spin_lock_irqsave(>bitmap_lock, flags);
- was_set = test_and_clear_bit(entry, zram->bitmap);
+ was_set = test_and_clear_bit(blk_idx, zram->bitmap);
spin_unlock_irqrestore(>bitmap_lock, flags);
WARN_ON_ONCE(!was_set);
}
@@ -599,7 +594,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio)
return -ENOMEM;
- entry = get_entry_bdev(zram);
+ entry = alloc_block_bdev(zram);
if (!entry) {
bio_put(bio);
return -ENOSPC;
@@ -610,7 +605,7 @@ static int write_to_bdev(struct zram *zram,
[PATCH 0/6] zram idle page writeback
Inherently, swap device has many idle pages which are rare touched since it was allocated. It is never problem if we use storage device as swap. However, it's just waste for zram-swap. This patchset supports zram idle page writeback feature. * Admin can define what is idle page "no access since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Minchan Kim (6): zram: fix lockdep warning of free block handling zram: refactoring flags and writeback stuff zram: introduce ZRAM_IDLE flag zram: support idle page writeback zram: add bd_stat statistics zram: writeback throttle Documentation/ABI/testing/sysfs-block-zram | 32 ++ Documentation/blockdev/zram.txt| 42 +- drivers/block/zram/Kconfig | 5 +- drivers/block/zram/zram_drv.c | 435 + drivers/block/zram/zram_drv.h | 18 +- 5 files changed, 438 insertions(+), 94 deletions(-) -- 2.19.1.1215.g8438c0b245-goog
Re: [alsa-devel] [PATCH v3 1/5] ALSA: soc-compress: add support to snd_compr_set_runtime_buffer()
Hi Srinivas, One minor comment: > struct snd_compr_ops *ops; > + struct snd_dma_buffer *dma_buffer_p; I don't think it is necessary to encode the type inside the name variable So, dma_buffer would sounds better to me then dma_buffer_p; > void *buffer; It is also consistent with this ^ > +static inline void snd_compr_set_runtime_buffer( > + struct snd_compr_stream *substream, > + struct snd_dma_buffer *bufp) Also buf instead of bufp here. thanks, Daniel.
Re: [alsa-devel] [PATCH v3 1/5] ALSA: soc-compress: add support to snd_compr_set_runtime_buffer()
Hi Srinivas, One minor comment: > struct snd_compr_ops *ops; > + struct snd_dma_buffer *dma_buffer_p; I don't think it is necessary to encode the type inside the name variable So, dma_buffer would sounds better to me then dma_buffer_p; > void *buffer; It is also consistent with this ^ > +static inline void snd_compr_set_runtime_buffer( > + struct snd_compr_stream *substream, > + struct snd_dma_buffer *bufp) Also buf instead of bufp here. thanks, Daniel.
Re: [PATCH 4/8] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS
On Fri, Nov 16, 2018 at 2:13 PM Nicolas Pitre wrote:
>
> On Thu, 15 Nov 2018, Masahiro Yamada wrote:
>
> > My main motivation of this commit is to clean up scripts/Kbuild.include
> > and scripts/Makefile.build.
> >
> > Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> > possibly exported symbols are detected by letting $(CPP) replace
> > EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is
> > post-processed by sed, and passed to fixdep. The extra preprocessing
> > is costly, and hacking cmd_and_fixdep is ugly.
> >
> > I came up with a new way to find exported symbols; insert a dummy
> > symbol __ksym_marker_* to each potentially exported symbol. Those
> > dummy symbols are picked up by $(NM), post-processed by sed, then
> > appended to .*.cmd files. I collected the post-process part to a
> > new shell script scripts/gen_ksymdeps.sh for readability. The dummy
> > symbols are put into the .discard.* section so that the linker
> > script rips them off the final vmlinux or modules.
>
> Brilliant! I really like it.
>
> Minor comments below.
>
> > diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> > index 4d73e6e..294d6ae 100644
> > --- a/include/asm-generic/export.h
> > +++ b/include/asm-generic/export.h
> > @@ -59,16 +59,19 @@ __kcrctab_\name:
> > .endm
> > #undef __put
> >
> > -#if defined(__KSYM_DEPS__)
> > -
> > -#define __EXPORT_SYMBOL(sym, val, sec) === __KSYM_##sym ===
> > -
> > -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> > +#if defined(CONFIG_TRIM_UNUSED_KSYMS)
> >
> > #include
> > #include
> >
> > +.macro __ksym_marker sym
> > + .section ".discard.ksym","a"
> > +__ksym_marker_\sym:
> > + .previous
>
> Does this work as intended? I have vague memories about having problems
> with sections being discarded when they don't allocate any space.
What I can tell is, this patch produces the same size kernel
(after dropping debug info by 'strip' command).
> > +.endm
> > +
> > #define __EXPORT_SYMBOL(sym, val, sec) \
> > + __ksym_marker sym; \
> > __cond_export_sym(sym, val, sec, __is_defined(__KSYM_##sym))
> > #define __cond_export_sym(sym, val, sec, conf) \
> > ___cond_export_sym(sym, val, sec, conf)
> > diff --git a/include/linux/export.h b/include/linux/export.h
> > index ce764a5..0413a3d 100644
> > --- a/include/linux/export.h
> > +++ b/include/linux/export.h
> > @@ -92,22 +92,22 @@ struct kernel_symbol {
> > */
> > #define __EXPORT_SYMBOL(sym, sec)
> >
> > -#elif defined(__KSYM_DEPS__)
> > +#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> > +
> > +#include
> >
> > /*
> > * For fine grained build dependencies, we want to tell the build system
> > * about each possible exported symbol even if they're not actually
> > exported.
> > - * We use a string pattern that is unlikely to be valid code that the build
> > - * system filters out from the preprocessor output (see ksym_dep_filter
> > - * in scripts/Kbuild.include).
> > + * We use a symbol pattern __ksym_marker_ that the build system
> > filters
> > + * from the $(NM) output (see scripts/gen_ksymdep.sh). These symbols are
> > + * discarded in the final link stage.
> > */
> > -#define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
> > -
> > -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> > -
> > -#include
> > +#define __ksym_marker(sym) \
> > + static int __ksym_marker_##sym[0] __section(".discard.ksym") __used
>
> Even if this is discarded during the final link, maybe this could save
> a tiny amount of disk space by using a char instead?
I am afraid you missed '[0]' after the symbol name.
This is actually zero-length array.
No memory allocated for this dummy section.
As far as I tested, this is working.
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index 7f3ca6e..e5ba9b1 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -254,9 +254,18 @@ objtool_dep = $(objtool_obj)
> > \
> > $(wildcard include/config/orc/unwinder.h \
> >include/config/stack/validation.h)
> >
> > +ifdef CONFIG_TRIM_UNUSED_KSYMS
> > +cmd_gen_ksymdeps = \
> > + $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >
> > $(dot-target).tmp; \
> > + cat $(dot-target).tmp >> $(dot-target).cmd; \
> > + rm -f $(dot-target).tmp;
>
> Why don't you append to $(dot-target).cmd directly?
If scripts/gen_ksymdeps.sh fails for some reasons,
it will error out immediately thanks to 'set -e' flag.
Appending incomplete portion might end up with a corrupted .*.cmd file.
Probably, that would not happen, but I just wanted to ensure it.
>
> Nicolas
--
Best Regards
Masahiro Yamada
Re: [PATCH 4/8] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS
On Fri, Nov 16, 2018 at 2:13 PM Nicolas Pitre wrote:
>
> On Thu, 15 Nov 2018, Masahiro Yamada wrote:
>
> > My main motivation of this commit is to clean up scripts/Kbuild.include
> > and scripts/Makefile.build.
> >
> > Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> > possibly exported symbols are detected by letting $(CPP) replace
> > EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is
> > post-processed by sed, and passed to fixdep. The extra preprocessing
> > is costly, and hacking cmd_and_fixdep is ugly.
> >
> > I came up with a new way to find exported symbols; insert a dummy
> > symbol __ksym_marker_* to each potentially exported symbol. Those
> > dummy symbols are picked up by $(NM), post-processed by sed, then
> > appended to .*.cmd files. I collected the post-process part to a
> > new shell script scripts/gen_ksymdeps.sh for readability. The dummy
> > symbols are put into the .discard.* section so that the linker
> > script rips them off the final vmlinux or modules.
>
> Brilliant! I really like it.
>
> Minor comments below.
>
> > diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> > index 4d73e6e..294d6ae 100644
> > --- a/include/asm-generic/export.h
> > +++ b/include/asm-generic/export.h
> > @@ -59,16 +59,19 @@ __kcrctab_\name:
> > .endm
> > #undef __put
> >
> > -#if defined(__KSYM_DEPS__)
> > -
> > -#define __EXPORT_SYMBOL(sym, val, sec) === __KSYM_##sym ===
> > -
> > -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> > +#if defined(CONFIG_TRIM_UNUSED_KSYMS)
> >
> > #include
> > #include
> >
> > +.macro __ksym_marker sym
> > + .section ".discard.ksym","a"
> > +__ksym_marker_\sym:
> > + .previous
>
> Does this work as intended? I have vague memories about having problems
> with sections being discarded when they don't allocate any space.
What I can tell is, this patch produces the same size kernel
(after dropping debug info by 'strip' command).
> > +.endm
> > +
> > #define __EXPORT_SYMBOL(sym, val, sec) \
> > + __ksym_marker sym; \
> > __cond_export_sym(sym, val, sec, __is_defined(__KSYM_##sym))
> > #define __cond_export_sym(sym, val, sec, conf) \
> > ___cond_export_sym(sym, val, sec, conf)
> > diff --git a/include/linux/export.h b/include/linux/export.h
> > index ce764a5..0413a3d 100644
> > --- a/include/linux/export.h
> > +++ b/include/linux/export.h
> > @@ -92,22 +92,22 @@ struct kernel_symbol {
> > */
> > #define __EXPORT_SYMBOL(sym, sec)
> >
> > -#elif defined(__KSYM_DEPS__)
> > +#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> > +
> > +#include
> >
> > /*
> > * For fine grained build dependencies, we want to tell the build system
> > * about each possible exported symbol even if they're not actually
> > exported.
> > - * We use a string pattern that is unlikely to be valid code that the build
> > - * system filters out from the preprocessor output (see ksym_dep_filter
> > - * in scripts/Kbuild.include).
> > + * We use a symbol pattern __ksym_marker_ that the build system
> > filters
> > + * from the $(NM) output (see scripts/gen_ksymdep.sh). These symbols are
> > + * discarded in the final link stage.
> > */
> > -#define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
> > -
> > -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> > -
> > -#include
> > +#define __ksym_marker(sym) \
> > + static int __ksym_marker_##sym[0] __section(".discard.ksym") __used
>
> Even if this is discarded during the final link, maybe this could save
> a tiny amount of disk space by using a char instead?
I am afraid you missed '[0]' after the symbol name.
This is actually zero-length array.
No memory allocated for this dummy section.
As far as I tested, this is working.
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index 7f3ca6e..e5ba9b1 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -254,9 +254,18 @@ objtool_dep = $(objtool_obj)
> > \
> > $(wildcard include/config/orc/unwinder.h \
> >include/config/stack/validation.h)
> >
> > +ifdef CONFIG_TRIM_UNUSED_KSYMS
> > +cmd_gen_ksymdeps = \
> > + $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >
> > $(dot-target).tmp; \
> > + cat $(dot-target).tmp >> $(dot-target).cmd; \
> > + rm -f $(dot-target).tmp;
>
> Why don't you append to $(dot-target).cmd directly?
If scripts/gen_ksymdeps.sh fails for some reasons,
it will error out immediately thanks to 'set -e' flag.
Appending incomplete portion might end up with a corrupted .*.cmd file.
Probably, that would not happen, but I just wanted to ensure it.
>
> Nicolas
--
Best Regards
Masahiro Yamada
Re: [PATCH V3 1/3] mmc: sdhci: Allow platform controlled voltage switching
On 16/11/18 1:17 AM, Evan Green wrote:
> On Wed, Nov 14, 2018 at 6:36 AM Veerabhadrarao Badiganti
> wrote:
>>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index b001cf4..3c28152 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -524,6 +524,7 @@ struct sdhci_host {
> bool pending_reset; /* Cmd/data reset is pending */
> bool irq_wake_enabled; /* IRQ wakeup is enabled */
> bool v4_mode; /* Host Version 4 Enable */
> + bool vqmmc_enabled; /* Vqmmc is enabled */
I still don't love this, since it doesn't mean what it says. Everyone
else that has a vqmmc_enabled member uses it to actually mean "vqmmc
is enabled", but this doesn't mean that. For example, you don't clear
this when you disable the regulator in patch 3, so this would be set
even if the regulator is disabled, and you don't set it when sdhci
enables the regulator, so the regulator is on when this flag is not
set.
>> Hi Evan
>>
>> This flag is meant to say "disable vqmmc *only* if it is enabled by host
>> driver (sdhci_host)".
>> If host driver doesn't enable vqmmc (enabled by platfrm driver) or if it
>> fails to enable it, then don't call disable vqmmc.
>>
>> Agree with you, the present name is not conveying its purpose.
>> It must be something like "vqmmc_enabled_by_host".
>>
>> Please let me know if you have any suggestions on this name.
>
> Yeah. Maybe vqmmc_pltfrm_controlled? Or vqmmc_enabled_by_platfrm as
> you suggested?
"pltfrm" doesn't mean anything here. Just change the comment "vqmmc enabled
in sdhci.c"
Re: [PATCH V3 1/3] mmc: sdhci: Allow platform controlled voltage switching
On 16/11/18 1:17 AM, Evan Green wrote:
> On Wed, Nov 14, 2018 at 6:36 AM Veerabhadrarao Badiganti
> wrote:
>>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index b001cf4..3c28152 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -524,6 +524,7 @@ struct sdhci_host {
> bool pending_reset; /* Cmd/data reset is pending */
> bool irq_wake_enabled; /* IRQ wakeup is enabled */
> bool v4_mode; /* Host Version 4 Enable */
> + bool vqmmc_enabled; /* Vqmmc is enabled */
I still don't love this, since it doesn't mean what it says. Everyone
else that has a vqmmc_enabled member uses it to actually mean "vqmmc
is enabled", but this doesn't mean that. For example, you don't clear
this when you disable the regulator in patch 3, so this would be set
even if the regulator is disabled, and you don't set it when sdhci
enables the regulator, so the regulator is on when this flag is not
set.
>> Hi Evan
>>
>> This flag is meant to say "disable vqmmc *only* if it is enabled by host
>> driver (sdhci_host)".
>> If host driver doesn't enable vqmmc (enabled by platfrm driver) or if it
>> fails to enable it, then don't call disable vqmmc.
>>
>> Agree with you, the present name is not conveying its purpose.
>> It must be something like "vqmmc_enabled_by_host".
>>
>> Please let me know if you have any suggestions on this name.
>
> Yeah. Maybe vqmmc_pltfrm_controlled? Or vqmmc_enabled_by_platfrm as
> you suggested?
"pltfrm" doesn't mean anything here. Just change the comment "vqmmc enabled
in sdhci.c"
Re: [PATCH tip/core/rcu 6/7] mm: Replace spin_is_locked() with lockdep
On Thu, Nov 15, 2018 at 10:49:17AM -0800, Davidlohr Bueso wrote: > On Sun, 11 Nov 2018, Paul E. McKenney wrote: > > >From: Lance Roy > > > >lockdep_assert_held() is better suited to checking locking requirements, > >since it only checks if the current thread holds the lock regardless of > >whether someone else does. This is also a step towards possibly removing > >spin_is_locked(). > > So fyi I'm not crazy about these kind of patches simply because lockdep > is a lot less used out of anything that's not a lab, and we can be missing > potential offenders. There's obviously nothing wrong about what you describe > above perse, just my two cents. Fair point! One countervailing advantage of lockdep is that it is not subject to the false negatives that can happen if someone else happens to be currently holding the lock. But what would you suggest instead? Thanx, Paul
Re: [PATCH tip/core/rcu 6/7] mm: Replace spin_is_locked() with lockdep
On Thu, Nov 15, 2018 at 10:49:17AM -0800, Davidlohr Bueso wrote: > On Sun, 11 Nov 2018, Paul E. McKenney wrote: > > >From: Lance Roy > > > >lockdep_assert_held() is better suited to checking locking requirements, > >since it only checks if the current thread holds the lock regardless of > >whether someone else does. This is also a step towards possibly removing > >spin_is_locked(). > > So fyi I'm not crazy about these kind of patches simply because lockdep > is a lot less used out of anything that's not a lab, and we can be missing > potential offenders. There's obviously nothing wrong about what you describe > above perse, just my two cents. Fair point! One countervailing advantage of lockdep is that it is not subject to the false negatives that can happen if someone else happens to be currently holding the lock. But what would you suggest instead? Thanx, Paul
RE: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON flash
Hi Boris, Please apply this patch series [1] in the coming release. -- Regards Yogesh Gaur [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384 > -Original Message- > From: Yogesh Narayan Gaur > Sent: Tuesday, October 23, 2018 3:31 PM > To: 'Boris Brezillon' > Cc: Mark Brown ; Tudor Ambarus > ; linux-...@lists.infradead.org; linux- > s...@vger.kernel.org; marek.va...@gmail.com; cyrille.pitc...@wedev4u.fr; > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux- > ker...@vger.kernel.org > Subject: RE: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON flash > > Hi Boris, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Tuesday, October 23, 2018 3:27 PM > > To: Yogesh Narayan Gaur > > Cc: Mark Brown ; Tudor Ambarus > > ; linux-...@lists.infradead.org; linux- > > s...@vger.kernel.org; marek.va...@gmail.com; > > cyrille.pitc...@wedev4u.fr; computersforpe...@gmail.com; > > frieder.schre...@exceet.de; linux- ker...@vger.kernel.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON > > flash > > > > Hi Yogesh, > > > > On Tue, 23 Oct 2018 09:39:25 + > > Yogesh Narayan Gaur wrote: > > > > > Hi, > > > > > > Did we have have any comments or remarks about this patch-series, > > > if not > > please apply. > > > > Sorry, but it was already too late for this release, and the merge > > window just started, so it will have to wait at least 2 more weeks. > Ok. > > > > > We've been lagging with SPI NOR patches for the last couple releases > > because I clearly don't have time to review those contributions, and > > it seems Marek does not have time either. > > > > > > > > Both patches in the series been reviewed by Tudor. > > > > Things are improving a bit thanks to Tudor's involvement in the review > > process, but I'd like to remember you that you, as a regular > > contributor to the spi-nor subsystem, can help us with that too. That > > is, help review patches coming from others instead of only focusing on your > own contributions. > > > Sure, I would start doing the review of other contributor patches. > > -- > Regards > Yogesh Gaur. > > > Regards, > > > > Boris
RE: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON flash
Hi Boris, Please apply this patch series [1] in the coming release. -- Regards Yogesh Gaur [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384 > -Original Message- > From: Yogesh Narayan Gaur > Sent: Tuesday, October 23, 2018 3:31 PM > To: 'Boris Brezillon' > Cc: Mark Brown ; Tudor Ambarus > ; linux-...@lists.infradead.org; linux- > s...@vger.kernel.org; marek.va...@gmail.com; cyrille.pitc...@wedev4u.fr; > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux- > ker...@vger.kernel.org > Subject: RE: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON flash > > Hi Boris, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Tuesday, October 23, 2018 3:27 PM > > To: Yogesh Narayan Gaur > > Cc: Mark Brown ; Tudor Ambarus > > ; linux-...@lists.infradead.org; linux- > > s...@vger.kernel.org; marek.va...@gmail.com; > > cyrille.pitc...@wedev4u.fr; computersforpe...@gmail.com; > > frieder.schre...@exceet.de; linux- ker...@vger.kernel.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON > > flash > > > > Hi Yogesh, > > > > On Tue, 23 Oct 2018 09:39:25 + > > Yogesh Narayan Gaur wrote: > > > > > Hi, > > > > > > Did we have have any comments or remarks about this patch-series, > > > if not > > please apply. > > > > Sorry, but it was already too late for this release, and the merge > > window just started, so it will have to wait at least 2 more weeks. > Ok. > > > > > We've been lagging with SPI NOR patches for the last couple releases > > because I clearly don't have time to review those contributions, and > > it seems Marek does not have time either. > > > > > > > > Both patches in the series been reviewed by Tudor. > > > > Things are improving a bit thanks to Tudor's involvement in the review > > process, but I'd like to remember you that you, as a regular > > contributor to the spi-nor subsystem, can help us with that too. That > > is, help review patches coming from others instead of only focusing on your > own contributions. > > > Sure, I would start doing the review of other contributor patches. > > -- > Regards > Yogesh Gaur. > > > Regards, > > > > Boris
Re: [resend PATCH 1/3] pwm: mediatek: drop flag 'has_clks'
On Wed, Nov 14, 2018 at 01:47:52PM +0100, Thierry Reding wrote: > On Tue, Nov 13, 2018 at 10:08:22AM +0800, Ryder Lee wrote: > > The flag 'has_clks' and related checks are superfluous as the CCF > > subsystem does this for you. > > Both of these mechanisms aren't equivalent. While CCF can deal with > optional clocks, what the has_clks flag actually means is that the > device doesn't need a clock (or doesn't have a clock input) on the > devices where it is cleared. > > So I'd actually be in favor of keeping the has_clks property because it > serves as an additional sanity check. For example if you run this driver > on an SoC that "has clocks" but if you don't list them in DT, then after > this patch the driver will happily continue without clocks, even though > it may break completely without those clocks. I've seen SoCs respond to > disabled clocks for a hardware block in different ways, in many cases an > access to any of the registers will completely hang the CPU. In other > cases it may just crash in some other way or give you some sort of > machine exception. None of those are good, and make the tiny bit of > additional code required to support the has_clks flag very attractive. > > But that's just my opinion. If you prefer to throw away that safety > barrier, be my guest. But if you do, please move this functionality into > the clock framework first and then make the driver use it. The usual policy is: If the things specified in the dt are wrong or incomplete, it's ok to fail however you like. So from a correctness POV I think the change is fine. I don't know about the mips details that John pointed out in a followup to this mail though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [resend PATCH 1/3] pwm: mediatek: drop flag 'has_clks'
On Wed, Nov 14, 2018 at 01:47:52PM +0100, Thierry Reding wrote: > On Tue, Nov 13, 2018 at 10:08:22AM +0800, Ryder Lee wrote: > > The flag 'has_clks' and related checks are superfluous as the CCF > > subsystem does this for you. > > Both of these mechanisms aren't equivalent. While CCF can deal with > optional clocks, what the has_clks flag actually means is that the > device doesn't need a clock (or doesn't have a clock input) on the > devices where it is cleared. > > So I'd actually be in favor of keeping the has_clks property because it > serves as an additional sanity check. For example if you run this driver > on an SoC that "has clocks" but if you don't list them in DT, then after > this patch the driver will happily continue without clocks, even though > it may break completely without those clocks. I've seen SoCs respond to > disabled clocks for a hardware block in different ways, in many cases an > access to any of the registers will completely hang the CPU. In other > cases it may just crash in some other way or give you some sort of > machine exception. None of those are good, and make the tiny bit of > additional code required to support the has_clks flag very attractive. > > But that's just my opinion. If you prefer to throw away that safety > barrier, be my guest. But if you do, please move this functionality into > the clock framework first and then make the driver use it. The usual policy is: If the things specified in the dt are wrong or incomplete, it's ok to fail however you like. So from a correctness POV I think the change is fine. I don't know about the mips details that John pointed out in a followup to this mail though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v2 4/4] ARM: dts: meson: consistently disable pin bias
On Fri, Nov 9, 2018 at 3:05 PM Jerome Brunet wrote: > > On Amlogic chipsets, the bias set through pinconf applies to the pad > itself, not only the GPIO function. This means that even when we change > the function of the pad from GPIO to anything else, the bias previously > set still applies. > > As we have seen with the eMMC, depending on the bias type and the function, > it may trigger problems. > > The underlying issue is that we inherit whatever was left by previous user > of the pad (pinconf, u-boot or the ROM code). As a consequence, the actual > setup we will get is undefined. > > There is nothing mentioned in the documentation about pad bias and pinmux > function, however leaving it undefined is not an option. > > This change consistently disable the pad bias for every pinmux functions. > It seems to work well, we can only assume that the necessary bias (if any) > is already provided by the pin function itself. > > Signed-off-by: Jerome Brunet Acked-by: Martin Blumenstingl my Odroid-C1 still boots fine from SD card and Ethernet (ping) also still works Kevin, can you please move this patch from your v4.21/dt64 branch to the v4.21/dt (32-bit) branch? all other patches from this series are for the 64-bit SoCs, so only this single patch has to be moved Thank you! Regards Martin
Re: [PATCH v2 4/4] ARM: dts: meson: consistently disable pin bias
On Fri, Nov 9, 2018 at 3:05 PM Jerome Brunet wrote: > > On Amlogic chipsets, the bias set through pinconf applies to the pad > itself, not only the GPIO function. This means that even when we change > the function of the pad from GPIO to anything else, the bias previously > set still applies. > > As we have seen with the eMMC, depending on the bias type and the function, > it may trigger problems. > > The underlying issue is that we inherit whatever was left by previous user > of the pad (pinconf, u-boot or the ROM code). As a consequence, the actual > setup we will get is undefined. > > There is nothing mentioned in the documentation about pad bias and pinmux > function, however leaving it undefined is not an option. > > This change consistently disable the pad bias for every pinmux functions. > It seems to work well, we can only assume that the necessary bias (if any) > is already provided by the pin function itself. > > Signed-off-by: Jerome Brunet Acked-by: Martin Blumenstingl my Odroid-C1 still boots fine from SD card and Ethernet (ping) also still works Kevin, can you please move this patch from your v4.21/dt64 branch to the v4.21/dt (32-bit) branch? all other patches from this series are for the 64-bit SoCs, so only this single patch has to be moved Thank you! Regards Martin
Re: [PATCH 0/3] tools/memory-model: Add SRCU support
On Thu, Nov 15, 2018 at 11:19:24AM -0500, Alan Stern wrote: > Paul and other LKMM maintainers: > > The following series of patches adds support for SRCU to the Linux > Kernel Memory Model. That is, it adds the srcu_read_lock(), > srcu_read_unlock(), and synchronize_srcu() primitives to the model. > > Patch 1/3 does some renaming of the RCU parts of the > memory model's existing CAT code, to help distinguish them > from the upcoming SRCU parts. > > Patch 2/3 refactors the definitions of some RCU relations > in the CAT code, in a way that the SRCU portions will need. > > Patch 3/3 actually adds the SRCU support. > > This new code requires herd7 version 7.51+4(dev) or later (now > available in the herdtools7 github repository) to run. Thanks to Luc > for making the necessary changes to support SRCU. These patches pass the tests that I have constructed, and also regression tests, very nice! Applied and pushed, thank you. > The code does not check that the index argument passed to > srcu_read_unlock() is the same as the value returned by the > corresponding srcu_read_lock() call. This is deemed to be a semantic > issue, not directly relevant to the memory model. Agreed. If I understand correctly, there are in theory some use cases that these patches do not support, for example: r1 = srcu_read_lock(a); do_1(); r2 = srcu_read_lock(a); do_2(); srcu_read_unlock(a, r1); do_3(); srcu_read_unlock(a, r2); In practice, I would be more worried about this had I ever managed to find a non-bogus use case for this pattern. ;-) Thanx, Paul
Re: [PATCH 0/3] tools/memory-model: Add SRCU support
On Thu, Nov 15, 2018 at 11:19:24AM -0500, Alan Stern wrote: > Paul and other LKMM maintainers: > > The following series of patches adds support for SRCU to the Linux > Kernel Memory Model. That is, it adds the srcu_read_lock(), > srcu_read_unlock(), and synchronize_srcu() primitives to the model. > > Patch 1/3 does some renaming of the RCU parts of the > memory model's existing CAT code, to help distinguish them > from the upcoming SRCU parts. > > Patch 2/3 refactors the definitions of some RCU relations > in the CAT code, in a way that the SRCU portions will need. > > Patch 3/3 actually adds the SRCU support. > > This new code requires herd7 version 7.51+4(dev) or later (now > available in the herdtools7 github repository) to run. Thanks to Luc > for making the necessary changes to support SRCU. These patches pass the tests that I have constructed, and also regression tests, very nice! Applied and pushed, thank you. > The code does not check that the index argument passed to > srcu_read_unlock() is the same as the value returned by the > corresponding srcu_read_lock() call. This is deemed to be a semantic > issue, not directly relevant to the memory model. Agreed. If I understand correctly, there are in theory some use cases that these patches do not support, for example: r1 = srcu_read_lock(a); do_1(); r2 = srcu_read_lock(a); do_2(); srcu_read_unlock(a, r1); do_3(); srcu_read_unlock(a, r2); In practice, I would be more worried about this had I ever managed to find a non-bogus use case for this pattern. ;-) Thanx, Paul
[PATCH v2 1/2] build_bug.h: remove negative-array fallback for BUILD_BUG_ON()
The kernel can only be compiled with an optimization option (-O2, -Os,
or the currently proposed -Og). Hence, __OPTIMIZE__ is always defined
in the kernel source.
The fallback for -O0 case is just hypothetical and pointless. Moreover,
commit 0bb95f80a38f ("Makefile: Globally enable VLA warning") enabled
-Wvla warning. The use of variable length arrays is banned.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
include/linux/build_bug.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index 43d1fd5..d415c64 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -51,23 +51,9 @@
* If you have some code which relies on certain constants being equal, or
* some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
- *
- * The implementation uses gcc's reluctance to create a negative array, but gcc
- * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
- * inline functions). Luckily, in 4.3 they added the "error" function
- * attribute just for this type of case. Thus, we use a negative sized array
- * (should always create an error on gcc versions older than 4.4) and then call
- * an undefined function with the error attribute (should always create an
- * error on gcc 4.3 and later). If for some reason, neither creates a
- * compile-time error, we'll still have a link-time error, which is harder to
- * track down.
*/
-#ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
-#else
#define BUILD_BUG_ON(condition) \
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
-#endif
/**
* BUILD_BUG - break compile if used.
--
2.7.4
[PATCH v2 1/2] build_bug.h: remove negative-array fallback for BUILD_BUG_ON()
The kernel can only be compiled with an optimization option (-O2, -Os,
or the currently proposed -Og). Hence, __OPTIMIZE__ is always defined
in the kernel source.
The fallback for -O0 case is just hypothetical and pointless. Moreover,
commit 0bb95f80a38f ("Makefile: Globally enable VLA warning") enabled
-Wvla warning. The use of variable length arrays is banned.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
include/linux/build_bug.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index 43d1fd5..d415c64 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -51,23 +51,9 @@
* If you have some code which relies on certain constants being equal, or
* some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
- *
- * The implementation uses gcc's reluctance to create a negative array, but gcc
- * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
- * inline functions). Luckily, in 4.3 they added the "error" function
- * attribute just for this type of case. Thus, we use a negative sized array
- * (should always create an error on gcc versions older than 4.4) and then call
- * an undefined function with the error attribute (should always create an
- * error on gcc 4.3 and later). If for some reason, neither creates a
- * compile-time error, we'll still have a link-time error, which is harder to
- * track down.
*/
-#ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
-#else
#define BUILD_BUG_ON(condition) \
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
-#endif
/**
* BUILD_BUG - break compile if used.
--
2.7.4
Re: [PATCH 0/7] ACPI HMAT memory sysfs representation
On 11/15/2018 04:19 AM, Keith Busch wrote: > This series provides a new sysfs representation for heterogeneous > system memory. > > The previous series that was specific to HMAT that this series was based > on was last posted here: https://lkml.org/lkml/2017/12/13/968 > > Platforms may provide multiple types of cpu attached system memory. The > memory ranges for each type may have different characteristics that > applications may wish to know about when considering what node they want > their memory allocated from. > > It had previously been difficult to describe these setups as memory > rangers were generally lumped into the NUMA node of the CPUs. New > platform attributes have been created and in use today that describe > the more complex memory hierarchies that can be created. > > This series first creates new generic APIs under the kernel's node > representation. These new APIs can be used to create links among local > memory and compute nodes and export characteristics about the memory > nodes. Documentation desribing the new representation are provided. > > Finally the series adds a kernel user for these new APIs from parsing > the ACPI HMAT. Not able to see the patches from this series either on the list or on the archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed about this and the concern which I raised was in absence of a broader NUMA rework for multi attribute memory it might not a good idea to settle down and freeze sysfs interface for the user space.
Re: [PATCH 0/7] ACPI HMAT memory sysfs representation
On 11/15/2018 04:19 AM, Keith Busch wrote: > This series provides a new sysfs representation for heterogeneous > system memory. > > The previous series that was specific to HMAT that this series was based > on was last posted here: https://lkml.org/lkml/2017/12/13/968 > > Platforms may provide multiple types of cpu attached system memory. The > memory ranges for each type may have different characteristics that > applications may wish to know about when considering what node they want > their memory allocated from. > > It had previously been difficult to describe these setups as memory > rangers were generally lumped into the NUMA node of the CPUs. New > platform attributes have been created and in use today that describe > the more complex memory hierarchies that can be created. > > This series first creates new generic APIs under the kernel's node > representation. These new APIs can be used to create links among local > memory and compute nodes and export characteristics about the memory > nodes. Documentation desribing the new representation are provided. > > Finally the series adds a kernel user for these new APIs from parsing > the ACPI HMAT. Not able to see the patches from this series either on the list or on the archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed about this and the concern which I raised was in absence of a broader NUMA rework for multi attribute memory it might not a good idea to settle down and freeze sysfs interface for the user space.
[PATCH v2 2/2] build_bug.h: remove all dummy BUILD_BUG_ON stubs for sparse
The introduction of these dummy BUILD_BUG_ON stubs dates back to
commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
for sparse"). At that time, BUILD_BUG_ON() was implemented with the
negative array trick, which Sparse complains about even if the
condition can be optimized and evaluated to 0 at compile-time.
With the previous commit, the leftover negative array trick is gone.
Sparse is happy with the current BUILD_BUG_ON(), which is implemented
by using the 'error' attribute.
There might be a little room for argument about BUILD_BUG_ON_ZERO().
Sparse reports 'invalid bitfield width, -1' for non-zero value,
and 'bad integer constant expression' for non-constant value.
This is the same criteria as GCC uses. So, if those Sparse errors
occurred, they would cause errors for GCC as well. (Hence, such
errors would have been detected by the normal compile test process.)
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Fix a coding style error (two consecutive blank lines)
include/linux/build_bug.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index d415c64..6625c88 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -4,16 +4,6 @@
#include
-#ifdef __CHECKER__
-#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_ZERO(e) (0)
-#define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON_MSG(cond, msg) (0)
-#define BUILD_BUG_ON(condition) (0)
-#define BUILD_BUG() (0)
-#else /* __CHECKER__ */
-
/* Force a compilation error if a constant expression is not a power of 2 */
#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) \
BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
@@ -64,6 +54,4 @@
*/
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
-#endif /* __CHECKER__ */
-
#endif /* _LINUX_BUILD_BUG_H */
--
2.7.4
[PATCH v2 2/2] build_bug.h: remove all dummy BUILD_BUG_ON stubs for sparse
The introduction of these dummy BUILD_BUG_ON stubs dates back to
commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
for sparse"). At that time, BUILD_BUG_ON() was implemented with the
negative array trick, which Sparse complains about even if the
condition can be optimized and evaluated to 0 at compile-time.
With the previous commit, the leftover negative array trick is gone.
Sparse is happy with the current BUILD_BUG_ON(), which is implemented
by using the 'error' attribute.
There might be a little room for argument about BUILD_BUG_ON_ZERO().
Sparse reports 'invalid bitfield width, -1' for non-zero value,
and 'bad integer constant expression' for non-constant value.
This is the same criteria as GCC uses. So, if those Sparse errors
occurred, they would cause errors for GCC as well. (Hence, such
errors would have been detected by the normal compile test process.)
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Fix a coding style error (two consecutive blank lines)
include/linux/build_bug.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index d415c64..6625c88 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -4,16 +4,6 @@
#include
-#ifdef __CHECKER__
-#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_ZERO(e) (0)
-#define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON_MSG(cond, msg) (0)
-#define BUILD_BUG_ON(condition) (0)
-#define BUILD_BUG() (0)
-#else /* __CHECKER__ */
-
/* Force a compilation error if a constant expression is not a power of 2 */
#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) \
BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
@@ -64,6 +54,4 @@
*/
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
-#endif /* __CHECKER__ */
-
#endif /* _LINUX_BUILD_BUG_H */
--
2.7.4
[PATCH 1/2] build_bug.h: remove negative-array fallback for BUILD_BUG_ON()
The kernel can only be compiled with an optimization option (-O2, -Os,
or the currently proposed -Og). Hence, __OPTIMIZE__ is always defined
in the kernel source.
A fallback for -O0 case is just hypothetical and pointless. Moreover,
commit 0bb95f80a38f ("Makefile: Globally enable VLA warning") enabled
-Wvla warning. The use of variable length arrays is banned.
Signed-off-by: Masahiro Yamada
---
include/linux/build_bug.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index 43d1fd5..d415c64 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -51,23 +51,9 @@
* If you have some code which relies on certain constants being equal, or
* some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
- *
- * The implementation uses gcc's reluctance to create a negative array, but gcc
- * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
- * inline functions). Luckily, in 4.3 they added the "error" function
- * attribute just for this type of case. Thus, we use a negative sized array
- * (should always create an error on gcc versions older than 4.4) and then call
- * an undefined function with the error attribute (should always create an
- * error on gcc 4.3 and later). If for some reason, neither creates a
- * compile-time error, we'll still have a link-time error, which is harder to
- * track down.
*/
-#ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
-#else
#define BUILD_BUG_ON(condition) \
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
-#endif
/**
* BUILD_BUG - break compile if used.
--
2.7.4
[PATCH 2/2] build_bug.h: remove all dummy BUILD_BUG_ON stubs for sparse
The introduction of these dummy BUILD_BUG_ON stubs dates back to
commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
for sparse"). At that time, BUILD_BUG_ON() was implemented with the
negative array trick, which Sparse complains about even if the
condition can be optimized and evaluated to 0 at compile-time.
With the previous commit, the leftover negative array trick is gone.
Sparse is happy with the current BUILD_BUG_ON(), which is implemented
by using the 'error' attribute.
There might be a little room for argument about BUILD_BUG_ON_ZERO().
Sparse reports 'invalid bitfield width, -1' for non-zero value,
and 'bad integer constant expression' for non-constant value.
This is the same criteria as GCC uses. So, if those Sparse errors
occurred, they would cause errors for GCC as well. (Hence, such
errors would have been detected by the normal compile test process.)
Signed-off-by: Masahiro Yamada
---
include/linux/build_bug.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index d415c64..b0828f7 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -4,16 +4,6 @@
#include
-#ifdef __CHECKER__
-#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_ZERO(e) (0)
-#define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON_MSG(cond, msg) (0)
-#define BUILD_BUG_ON(condition) (0)
-#define BUILD_BUG() (0)
-#else /* __CHECKER__ */
-
/* Force a compilation error if a constant expression is not a power of 2 */
#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) \
BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
@@ -64,6 +54,5 @@
*/
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
-#endif /* __CHECKER__ */
#endif /* _LINUX_BUILD_BUG_H */
--
2.7.4
[PATCH 1/2] build_bug.h: remove negative-array fallback for BUILD_BUG_ON()
The kernel can only be compiled with an optimization option (-O2, -Os,
or the currently proposed -Og). Hence, __OPTIMIZE__ is always defined
in the kernel source.
A fallback for -O0 case is just hypothetical and pointless. Moreover,
commit 0bb95f80a38f ("Makefile: Globally enable VLA warning") enabled
-Wvla warning. The use of variable length arrays is banned.
Signed-off-by: Masahiro Yamada
---
include/linux/build_bug.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index 43d1fd5..d415c64 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -51,23 +51,9 @@
* If you have some code which relies on certain constants being equal, or
* some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
- *
- * The implementation uses gcc's reluctance to create a negative array, but gcc
- * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
- * inline functions). Luckily, in 4.3 they added the "error" function
- * attribute just for this type of case. Thus, we use a negative sized array
- * (should always create an error on gcc versions older than 4.4) and then call
- * an undefined function with the error attribute (should always create an
- * error on gcc 4.3 and later). If for some reason, neither creates a
- * compile-time error, we'll still have a link-time error, which is harder to
- * track down.
*/
-#ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
-#else
#define BUILD_BUG_ON(condition) \
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
-#endif
/**
* BUILD_BUG - break compile if used.
--
2.7.4
[PATCH 2/2] build_bug.h: remove all dummy BUILD_BUG_ON stubs for sparse
The introduction of these dummy BUILD_BUG_ON stubs dates back to
commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
for sparse"). At that time, BUILD_BUG_ON() was implemented with the
negative array trick, which Sparse complains about even if the
condition can be optimized and evaluated to 0 at compile-time.
With the previous commit, the leftover negative array trick is gone.
Sparse is happy with the current BUILD_BUG_ON(), which is implemented
by using the 'error' attribute.
There might be a little room for argument about BUILD_BUG_ON_ZERO().
Sparse reports 'invalid bitfield width, -1' for non-zero value,
and 'bad integer constant expression' for non-constant value.
This is the same criteria as GCC uses. So, if those Sparse errors
occurred, they would cause errors for GCC as well. (Hence, such
errors would have been detected by the normal compile test process.)
Signed-off-by: Masahiro Yamada
---
include/linux/build_bug.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index d415c64..b0828f7 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -4,16 +4,6 @@
#include
-#ifdef __CHECKER__
-#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_ZERO(e) (0)
-#define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON_MSG(cond, msg) (0)
-#define BUILD_BUG_ON(condition) (0)
-#define BUILD_BUG() (0)
-#else /* __CHECKER__ */
-
/* Force a compilation error if a constant expression is not a power of 2 */
#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) \
BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
@@ -64,6 +54,5 @@
*/
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
-#endif /* __CHECKER__ */
#endif /* _LINUX_BUILD_BUG_H */
--
2.7.4
[PATCH] initramfs: clean old path before creating a hardlink
Previously, sys_link() will fail due to the new path is already existed.
this case ofen appears when we use a concated initrd, below is an
sample:
1) prepare a basic rootfs, it contains a regular files rc.local
lizhijian@:~/yocto-tiny-i386-2016-04-22$ cat etc/rc.local
#!/bin/sh
echo "Running /etc/rc.local..."
yocto-tiny-i386-2016-04-22$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n
-9 >../rootfs.cgz
2) create a extra initrd which also includes a etc/rc.local
lizhijian@:~/lkp-x86_64/etc$ echo "append initrd" >rc.local
lizhijian@:~/lkp/lkp-x86_64/etc$ cat rc.local
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ ln rc.local rc.local.hardlink
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ stat rc.local rc.local.hardlink
File: 'rc.local'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
File: 'rc.local.hardlink'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
lizhijian@:~/lkp/lkp-x86_64$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip
-n -9 >../rc-local.cgz
lizhijian@:~/lkp/lkp-x86_64$ gzip -dc ../rc-local.cgz | cpio -t
.
etc
etc/rc.local.hardlink <<< it will be extracted first at this initrd
etc/rc.local
3) concate 2 initrds and boot
lizhijian@:~/lkp$ cat rootfs.cgz rc-local.cgz >concate-initrd.cgz
lizhijian@:~/lkp$ qemu-system-x86_64 -nographic -enable-kvm -cpu host -smp 1 -m
1024 -kernel ~/lkp/linux/arch/x86/boot/bzImage -append "console=ttyS0
earlyprint=ttyS0 ignore_loglevel" -initrd ./concate-initr.cgz -serial stdio
-nodefaults
In this case, sys_link(2) will fail and return -EEXIST, so we can only
get the rc.local at rootfs.cgz instead of rc-local.cgz
CC: Philip Li
Signed-off-by: Li Zhijian
---
init/initramfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/init/initramfs.c b/init/initramfs.c
index 6405577..381fd4c 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -291,12 +291,16 @@ static int __init do_reset(void)
return 1;
}
+static void __init clean_path(char *path, umode_t fmode);
+
static int __init maybe_link(void)
{
if (nlink >= 2) {
char *old = find_link(major, minor, ino, mode, collected);
- if (old)
+ if (old) {
+ clean_path(collected, 0);
return (ksys_link(old, collected) < 0) ? -1 : 1;
+ }
}
return 0;
}
--
2.7.4
[PATCH] initramfs: clean old path before creating a hardlink
Previously, sys_link() will fail due to the new path is already existed.
this case ofen appears when we use a concated initrd, below is an
sample:
1) prepare a basic rootfs, it contains a regular files rc.local
lizhijian@:~/yocto-tiny-i386-2016-04-22$ cat etc/rc.local
#!/bin/sh
echo "Running /etc/rc.local..."
yocto-tiny-i386-2016-04-22$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n
-9 >../rootfs.cgz
2) create a extra initrd which also includes a etc/rc.local
lizhijian@:~/lkp-x86_64/etc$ echo "append initrd" >rc.local
lizhijian@:~/lkp/lkp-x86_64/etc$ cat rc.local
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ ln rc.local rc.local.hardlink
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ stat rc.local rc.local.hardlink
File: 'rc.local'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
File: 'rc.local.hardlink'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
lizhijian@:~/lkp/lkp-x86_64$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip
-n -9 >../rc-local.cgz
lizhijian@:~/lkp/lkp-x86_64$ gzip -dc ../rc-local.cgz | cpio -t
.
etc
etc/rc.local.hardlink <<< it will be extracted first at this initrd
etc/rc.local
3) concate 2 initrds and boot
lizhijian@:~/lkp$ cat rootfs.cgz rc-local.cgz >concate-initrd.cgz
lizhijian@:~/lkp$ qemu-system-x86_64 -nographic -enable-kvm -cpu host -smp 1 -m
1024 -kernel ~/lkp/linux/arch/x86/boot/bzImage -append "console=ttyS0
earlyprint=ttyS0 ignore_loglevel" -initrd ./concate-initr.cgz -serial stdio
-nodefaults
In this case, sys_link(2) will fail and return -EEXIST, so we can only
get the rc.local at rootfs.cgz instead of rc-local.cgz
CC: Philip Li
Signed-off-by: Li Zhijian
---
init/initramfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/init/initramfs.c b/init/initramfs.c
index 6405577..381fd4c 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -291,12 +291,16 @@ static int __init do_reset(void)
return 1;
}
+static void __init clean_path(char *path, umode_t fmode);
+
static int __init maybe_link(void)
{
if (nlink >= 2) {
char *old = find_link(major, minor, ino, mode, collected);
- if (old)
+ if (old) {
+ clean_path(collected, 0);
return (ksys_link(old, collected) < 0) ? -1 : 1;
+ }
}
return 0;
}
--
2.7.4
linux-next: Tree for Nov 16
Hi all, Changes since 20181115: The xtensa tree gained a conflict against Linus' tree. The block tree gained a conflict against Linus' tree. The tip tree still had its build failure for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 3059 3132 files changed, 125660 insertions(+), 103426 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 68 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (da5322e65940 Merge tag 'selinux-pr-20181115' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux) Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal code in do_page_fault) Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE) Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit memblock resizing until linear mapping is up) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (b2fed34a628d selftests/powerpc: Adjust wild_bctr to build with old binutils) Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and getsockname.) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (08e14fe429a0 net_sched: sch_fq: ensure maxrate fq parameter applies to EDT flows) Merging bpf/master (da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6 ping binary when it exists) Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace) Merging netfilter/master (29e3880109e3 netfilter: nf_tables: fix use-after-free when deleting compat expressions) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without CONFIG_LEDS_CLASS) Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces) Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits) Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()) Merging sound-asoc-fixes/for-linus (0e6f4dd73a24 Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging regulator-fixes/for-linus (97f11d95dd75 Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (7c9a8d31fb2a Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to device-specific _PXM node values") Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align data[] to ARCH_KMALLOC_MINALIGN) Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb.current/usb-linus (2f31a67f01a8 usb: xhci: Prevent bus suspend if a port connect change or polling state is detected) Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers) Merging usb-serial-fixes
linux-next: Tree for Nov 16
Hi all, Changes since 20181115: The xtensa tree gained a conflict against Linus' tree. The block tree gained a conflict against Linus' tree. The tip tree still had its build failure for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 3059 3132 files changed, 125660 insertions(+), 103426 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 68 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (da5322e65940 Merge tag 'selinux-pr-20181115' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux) Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal code in do_page_fault) Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE) Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit memblock resizing until linear mapping is up) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (b2fed34a628d selftests/powerpc: Adjust wild_bctr to build with old binutils) Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and getsockname.) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (08e14fe429a0 net_sched: sch_fq: ensure maxrate fq parameter applies to EDT flows) Merging bpf/master (da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6 ping binary when it exists) Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace) Merging netfilter/master (29e3880109e3 netfilter: nf_tables: fix use-after-free when deleting compat expressions) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without CONFIG_LEDS_CLASS) Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces) Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits) Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()) Merging sound-asoc-fixes/for-linus (0e6f4dd73a24 Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging regulator-fixes/for-linus (97f11d95dd75 Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (7c9a8d31fb2a Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to device-specific _PXM node values") Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align data[] to ARCH_KMALLOC_MINALIGN) Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb.current/usb-linus (2f31a67f01a8 usb: xhci: Prevent bus suspend if a port connect change or polling state is detected) Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers) Merging usb-serial-fixes
RE: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Frieder,
> -Original Message-
> From: Schrempf Frieder [mailto:frieder.schre...@kontron.de]
> Sent: Thursday, November 15, 2018 7:32 PM
> To: Yogesh Narayan Gaur
> Cc: Boris Brezillon ;
> linux-...@lists.infradead.org;
> linux-...@vger.kernel.org; Marek Vasut ; Mark
> Brown ; Han Xu ;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> miquel.ray...@bootlin.com; David Wolfe ; Fabio
> Estevam ; Prabhakar Kushwaha
> ; shawn...@kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI
> controller
>
> Hi Yogesh,
>
> On 15.11.18 14:12, Boris Brezillon wrote:
> > On Thu, 15 Nov 2018 11:43:05 +
> > Schrempf Frieder wrote:
> >
> >> On 15.11.18 07:22, Yogesh Narayan Gaur wrote:
> >>> Hi Frieder,
> >>>
> >>> With below patch on top of your v5, Read/Write/Erase on CS1 is working
> fine for me.
> >>
> >> Ok, are you sure, that AHB read is working too with this patch?
> >> You are removing the memmap_phy offset from SFAR and the SFXXAD
> >> register values.
> >>
> >> I can understand that selection of the CS and IP commands will work
> >> like this, but I can't understand how AHB read should work without
> >> the base address of the mapped memory.
> >>
> >> I'm afraid I still don't fully understand the background of these
> >> things,
> >
> > Same here. Yogesh, can you give us more detail on why you decided to
> > drop the memmap_phy offset?
>
> Your changes do not work on my setup (i.MX6UL). It looks like your hardware is
> different.
>
> I found this patch for LS2080A: [1]. This would explain why you need to remove
> the offset to make it work.
>
> To verify this, could you please test your setup with the current spi-nor
> driver
> (fsl_quadspi.c). If our assumptions are right, it should only work on CS0 and
> CS1
> with [1] applied.
>
Yes, I need to remove the offset to make it work and this is required for the
NXP Layerscape-2.x SoCs like LS208x/Ls108x etc.
I have modified the patch and have introduced entry in quirks for ls2080a. With
this Read/Write/Erase are working for me for both CS.
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index ce45e8e..5d26f73 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -175,6 +175,9 @@
/* TKT245618, the controller cannot wake up from wait mode */
#define QUADSPI_QUIRK_TKT245618BIT(3)
+/* QSPI_AMBA_BASE is internally added by SOC design for LS-2.x architecture */
+#define QUADSPI_AMBA_BASE_INTERNAL BIT(4)
+
struct fsl_qspi_devtype_data {
unsigned int rxfifo;
unsigned int txfifo;
@@ -227,7 +230,7 @@ static const struct fsl_qspi_devtype_data ls2080a_data = {
.rxfifo = SZ_128,
.txfifo = SZ_64,
.ahb_buf_size = SZ_1K,
- .quirks = QUADSPI_QUIRK_TKT253890,
+ .quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_AMBA_BASE_INTERNAL,
.little_endian = true,
};
@@ -235,6 +238,7 @@ struct fsl_qspi {
void __iomem *iobase;
void __iomem *ahb_addr;
u32 memmap_phy;
+ u32 amba_base_addr;
struct clk *clk, *clk_en;
struct device *dev;
struct completion c;
@@ -264,6 +268,11 @@ static inline int needs_wakeup_wait_mode(struct fsl_qspi
*q)
return q->devtype_data->quirks & QUADSPI_QUIRK_TKT245618;
}
+static inline int has_added_amba_base_internal(struct fsl_qspi *q)
+{
+ return q->devtype_data->quirks & QUADSPI_AMBA_BASE_INTERNAL;
+}
+
/*
* An IC bug makes it necessary to rearrange the 32-bit data.
* Later chips, such as IMX6SLX, have fixed this bug.
@@ -489,29 +498,11 @@ static void fsl_qspi_invalidate(struct fsl_qspi *q)
static void fsl_qspi_select_mem(struct fsl_qspi *q, struct spi_device *spi)
{
unsigned long rate = spi->max_speed_hz;
- int ret, i;
- u32 map_addr;
+ int ret;
if (q->selected == spi->chip_select)
return;
- /*
-* In HW there can be a maximum of four chips on two buses with
-* two chip selects on each bus. We use four chip selects in SW
-* to differentiate between the four chips.
-* We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
-* the chip we want to access.
-*/
- for (i = 0; i < 4; i++) {
- if (i < spi->chip_select)
- map_addr = q->memmap_phy;
- else
- map_addr = q->memmap_phy +
- 2 * q->devtype_data->ahb_buf_size;
-
- qspi_writel(q, map_addr, q->iobase + QUADSPI_SFA1AD + (i * 4));
- }
-
if (needs_4x_clock(q))
rate *= 4;
@@ -534,7 +525,9 @@ static void fsl_qspi_select_mem(struct fsl_qspi *q, struct
spi_device *spi)
static void fsl_qspi_read_ahb(struct fsl_qspi *q, const struct spi_mem_op *op)
{
- memcpy_fromio(op->data.buf.in, q->ahb_addr, op->data.nbytes);
+
RE: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Frieder,
> -Original Message-
> From: Schrempf Frieder [mailto:frieder.schre...@kontron.de]
> Sent: Thursday, November 15, 2018 7:32 PM
> To: Yogesh Narayan Gaur
> Cc: Boris Brezillon ;
> linux-...@lists.infradead.org;
> linux-...@vger.kernel.org; Marek Vasut ; Mark
> Brown ; Han Xu ;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> miquel.ray...@bootlin.com; David Wolfe ; Fabio
> Estevam ; Prabhakar Kushwaha
> ; shawn...@kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI
> controller
>
> Hi Yogesh,
>
> On 15.11.18 14:12, Boris Brezillon wrote:
> > On Thu, 15 Nov 2018 11:43:05 +
> > Schrempf Frieder wrote:
> >
> >> On 15.11.18 07:22, Yogesh Narayan Gaur wrote:
> >>> Hi Frieder,
> >>>
> >>> With below patch on top of your v5, Read/Write/Erase on CS1 is working
> fine for me.
> >>
> >> Ok, are you sure, that AHB read is working too with this patch?
> >> You are removing the memmap_phy offset from SFAR and the SFXXAD
> >> register values.
> >>
> >> I can understand that selection of the CS and IP commands will work
> >> like this, but I can't understand how AHB read should work without
> >> the base address of the mapped memory.
> >>
> >> I'm afraid I still don't fully understand the background of these
> >> things,
> >
> > Same here. Yogesh, can you give us more detail on why you decided to
> > drop the memmap_phy offset?
>
> Your changes do not work on my setup (i.MX6UL). It looks like your hardware is
> different.
>
> I found this patch for LS2080A: [1]. This would explain why you need to remove
> the offset to make it work.
>
> To verify this, could you please test your setup with the current spi-nor
> driver
> (fsl_quadspi.c). If our assumptions are right, it should only work on CS0 and
> CS1
> with [1] applied.
>
Yes, I need to remove the offset to make it work and this is required for the
NXP Layerscape-2.x SoCs like LS208x/Ls108x etc.
I have modified the patch and have introduced entry in quirks for ls2080a. With
this Read/Write/Erase are working for me for both CS.
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index ce45e8e..5d26f73 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -175,6 +175,9 @@
/* TKT245618, the controller cannot wake up from wait mode */
#define QUADSPI_QUIRK_TKT245618BIT(3)
+/* QSPI_AMBA_BASE is internally added by SOC design for LS-2.x architecture */
+#define QUADSPI_AMBA_BASE_INTERNAL BIT(4)
+
struct fsl_qspi_devtype_data {
unsigned int rxfifo;
unsigned int txfifo;
@@ -227,7 +230,7 @@ static const struct fsl_qspi_devtype_data ls2080a_data = {
.rxfifo = SZ_128,
.txfifo = SZ_64,
.ahb_buf_size = SZ_1K,
- .quirks = QUADSPI_QUIRK_TKT253890,
+ .quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_AMBA_BASE_INTERNAL,
.little_endian = true,
};
@@ -235,6 +238,7 @@ struct fsl_qspi {
void __iomem *iobase;
void __iomem *ahb_addr;
u32 memmap_phy;
+ u32 amba_base_addr;
struct clk *clk, *clk_en;
struct device *dev;
struct completion c;
@@ -264,6 +268,11 @@ static inline int needs_wakeup_wait_mode(struct fsl_qspi
*q)
return q->devtype_data->quirks & QUADSPI_QUIRK_TKT245618;
}
+static inline int has_added_amba_base_internal(struct fsl_qspi *q)
+{
+ return q->devtype_data->quirks & QUADSPI_AMBA_BASE_INTERNAL;
+}
+
/*
* An IC bug makes it necessary to rearrange the 32-bit data.
* Later chips, such as IMX6SLX, have fixed this bug.
@@ -489,29 +498,11 @@ static void fsl_qspi_invalidate(struct fsl_qspi *q)
static void fsl_qspi_select_mem(struct fsl_qspi *q, struct spi_device *spi)
{
unsigned long rate = spi->max_speed_hz;
- int ret, i;
- u32 map_addr;
+ int ret;
if (q->selected == spi->chip_select)
return;
- /*
-* In HW there can be a maximum of four chips on two buses with
-* two chip selects on each bus. We use four chip selects in SW
-* to differentiate between the four chips.
-* We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
-* the chip we want to access.
-*/
- for (i = 0; i < 4; i++) {
- if (i < spi->chip_select)
- map_addr = q->memmap_phy;
- else
- map_addr = q->memmap_phy +
- 2 * q->devtype_data->ahb_buf_size;
-
- qspi_writel(q, map_addr, q->iobase + QUADSPI_SFA1AD + (i * 4));
- }
-
if (needs_4x_clock(q))
rate *= 4;
@@ -534,7 +525,9 @@ static void fsl_qspi_select_mem(struct fsl_qspi *q, struct
spi_device *spi)
static void fsl_qspi_read_ahb(struct fsl_qspi *q, const struct spi_mem_op *op)
{
- memcpy_fromio(op->data.buf.in, q->ahb_addr, op->data.nbytes);
+
[PATCH] x86/cpu/AMD: Fix CPB bit for more processors
CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on Model 17, Stepping 0, but revision guide has not been released for newer Family 17h models. Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx" and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", their CPUID Fn_0001_EAX is 0x00810f10 and should have CPB feature according AMD product specifications, however their Fn8000_0007_EDX is 0x6599, indicating they don't support CPB feature. Signed-off-by: Jiaxun Yang --- arch/x86/kernel/cpu/amd.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index eeea634bee0a..7db43ef8e97e 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -821,8 +821,12 @@ static void init_amd_zn(struct cpuinfo_x86 *c) /* * Fix erratum 1076: CPB feature bit not being set in CPUID. It affects * all up to and including B1. +* +* Revision guide for Family 17h, Model 17 has not been released, but +* Model 17, Stepping 0 have the same issue. */ - if (c->x86_model <= 1 && c->x86_stepping <= 1) + if ((c->x86_model <= 1 && c->x86_stepping <= 1) || \ + (c->x86_model == 17 && c->x86_stepping == 0)) set_cpu_cap(c, X86_FEATURE_CPB); } -- 2.19.1
[PATCH] slab: fix 'dubious: x & !y' warning from Sparse
Sparse reports: ./include/linux/slab.h:332:43: warning: dubious: x & !y Signed-off-by: Masahiro Yamada --- include/linux/slab.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 918f374..d395c73 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -329,7 +329,7 @@ static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags) * If an allocation is both __GFP_DMA and __GFP_RECLAIMABLE, return * KMALLOC_DMA and effectively ignore __GFP_RECLAIMABLE */ - return type_dma + (is_reclaimable & !is_dma) * KMALLOC_RECLAIM; + return type_dma + (is_reclaimable && !is_dma) * KMALLOC_RECLAIM; } /* -- 2.7.4
[PATCH] x86/cpu/AMD: Fix CPB bit for more processors
CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on Model 17, Stepping 0, but revision guide has not been released for newer Family 17h models. Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx" and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", their CPUID Fn_0001_EAX is 0x00810f10 and should have CPB feature according AMD product specifications, however their Fn8000_0007_EDX is 0x6599, indicating they don't support CPB feature. Signed-off-by: Jiaxun Yang --- arch/x86/kernel/cpu/amd.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index eeea634bee0a..7db43ef8e97e 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -821,8 +821,12 @@ static void init_amd_zn(struct cpuinfo_x86 *c) /* * Fix erratum 1076: CPB feature bit not being set in CPUID. It affects * all up to and including B1. +* +* Revision guide for Family 17h, Model 17 has not been released, but +* Model 17, Stepping 0 have the same issue. */ - if (c->x86_model <= 1 && c->x86_stepping <= 1) + if ((c->x86_model <= 1 && c->x86_stepping <= 1) || \ + (c->x86_model == 17 && c->x86_stepping == 0)) set_cpu_cap(c, X86_FEATURE_CPB); } -- 2.19.1
[PATCH] slab: fix 'dubious: x & !y' warning from Sparse
Sparse reports: ./include/linux/slab.h:332:43: warning: dubious: x & !y Signed-off-by: Masahiro Yamada --- include/linux/slab.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 918f374..d395c73 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -329,7 +329,7 @@ static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags) * If an allocation is both __GFP_DMA and __GFP_RECLAIMABLE, return * KMALLOC_DMA and effectively ignore __GFP_RECLAIMABLE */ - return type_dma + (is_reclaimable & !is_dma) * KMALLOC_RECLAIM; + return type_dma + (is_reclaimable && !is_dma) * KMALLOC_RECLAIM; } /* -- 2.7.4
Re: [PATCH] ARM: dts: imx6sll: remove unused property in gpc node
On Tue, Nov 06, 2018 at 09:19:36AM +, Anson Huang wrote: > The "fsl,mf-mix-wakeup-irq" is ONLY used as a temporary > solution in NXP's internal tree for Mega/Fast Mix off > feature after suspend, upstream kernel does NOT need it, > remove it. > > Signed-off-by: Anson Huang Applied both, thanks.
Re: [PATCH] ARM: dts: imx6sll: remove unused property in gpc node
On Tue, Nov 06, 2018 at 09:19:36AM +, Anson Huang wrote: > The "fsl,mf-mix-wakeup-irq" is ONLY used as a temporary > solution in NXP's internal tree for Mega/Fast Mix off > feature after suspend, upstream kernel does NOT need it, > remove it. > > Signed-off-by: Anson Huang Applied both, thanks.
Re: [PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk
On Thu, Nov 15, 2018 at 9:03 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Nov 15, 2018 at 4:42 PM Derek Basehore wrote:
> >
> > This adds the xin32k clock to the RK3399 CPU. Even though it's not
> > directly used, muxes will end up traversing the entire clk tree on
> > calls to determine_rate if it doesn't exist.
> >
> > Signed-off-by: Derek Basehore
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > index 99e7f65c1779..6a32293982d0 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > @@ -191,6 +191,13 @@
> > #clock-cells = <0>;
> > };
> >
> > + xin32k: xin32k {
>
> nit: xin32k is the name of the clock that rk3399 consumes. It seems a
> little weird to name this node with that name. Can you call this:
>
> ap_rtc_clk: ap-rtc-clk
>
> ...after the gru schematic? You wouldn't change the
> clock-output-names, just the node name / label.
>
>
> > + compatible = "fixed-clock";
> > + clock-frequency = <32000>;
>
> I checked the datasheet for the 32K clock and it shows that this is a
> 32768 Hz clock, not a 32000 Hz one. I also checked the rk808 clock
> driver (which is supposed to be compatible with rk3399) and it
> produces a 32768 clock.
Ok, sending out an updated patch that addresses these concerns.
Re: [PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk
On Thu, Nov 15, 2018 at 9:03 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Nov 15, 2018 at 4:42 PM Derek Basehore wrote:
> >
> > This adds the xin32k clock to the RK3399 CPU. Even though it's not
> > directly used, muxes will end up traversing the entire clk tree on
> > calls to determine_rate if it doesn't exist.
> >
> > Signed-off-by: Derek Basehore
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > index 99e7f65c1779..6a32293982d0 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > @@ -191,6 +191,13 @@
> > #clock-cells = <0>;
> > };
> >
> > + xin32k: xin32k {
>
> nit: xin32k is the name of the clock that rk3399 consumes. It seems a
> little weird to name this node with that name. Can you call this:
>
> ap_rtc_clk: ap-rtc-clk
>
> ...after the gru schematic? You wouldn't change the
> clock-output-names, just the node name / label.
>
>
> > + compatible = "fixed-clock";
> > + clock-frequency = <32000>;
>
> I checked the datasheet for the 32K clock and it shows that this is a
> 32768 Hz clock, not a 32000 Hz one. I also checked the rk808 clock
> driver (which is supposed to be compatible with rk3399) and it
> produces a 32768 clock.
Ok, sending out an updated patch that addresses these concerns.
[PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk
This adds the xin32k clock to the RK3399 CPU. Even though it's not
directly used, muxes will end up traversing the entire clk tree on
calls to determine_rate if it doesn't exist.
Signed-off-by: Derek Basehore
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..3d09472978f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -191,6 +191,13 @@
#clock-cells = <0>;
};
+ ap_rtc_clk: ap-rtc-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ #clock-cells = <0>;
+ };
+
amba {
compatible = "simple-bus";
#address-cells = <2>;
--
2.19.1.1215.g8438c0b245-goog
[PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk
This adds the xin32k clock to the RK3399 CPU. Even though it's not
directly used, muxes will end up traversing the entire clk tree on
calls to determine_rate if it doesn't exist.
Signed-off-by: Derek Basehore
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..3d09472978f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -191,6 +191,13 @@
#clock-cells = <0>;
};
+ ap_rtc_clk: ap-rtc-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ #clock-cells = <0>;
+ };
+
amba {
compatible = "simple-bus";
#address-cells = <2>;
--
2.19.1.1215.g8438c0b245-goog
Re: [PATCH 4/8] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS
On Thu, 15 Nov 2018, Masahiro Yamada wrote:
> My main motivation of this commit is to clean up scripts/Kbuild.include
> and scripts/Makefile.build.
>
> Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> possibly exported symbols are detected by letting $(CPP) replace
> EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is
> post-processed by sed, and passed to fixdep. The extra preprocessing
> is costly, and hacking cmd_and_fixdep is ugly.
>
> I came up with a new way to find exported symbols; insert a dummy
> symbol __ksym_marker_* to each potentially exported symbol. Those
> dummy symbols are picked up by $(NM), post-processed by sed, then
> appended to .*.cmd files. I collected the post-process part to a
> new shell script scripts/gen_ksymdeps.sh for readability. The dummy
> symbols are put into the .discard.* section so that the linker
> script rips them off the final vmlinux or modules.
Brilliant! I really like it.
Minor comments below.
> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 4d73e6e..294d6ae 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -59,16 +59,19 @@ __kcrctab_\name:
> .endm
> #undef __put
>
> -#if defined(__KSYM_DEPS__)
> -
> -#define __EXPORT_SYMBOL(sym, val, sec) === __KSYM_##sym ===
> -
> -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> +#if defined(CONFIG_TRIM_UNUSED_KSYMS)
>
> #include
> #include
>
> +.macro __ksym_marker sym
> + .section ".discard.ksym","a"
> +__ksym_marker_\sym:
> + .previous
Does this work as intended? I have vague memories about having problems
with sections being discarded when they don't allocate any space.
> +.endm
> +
> #define __EXPORT_SYMBOL(sym, val, sec) \
> + __ksym_marker sym; \
> __cond_export_sym(sym, val, sec, __is_defined(__KSYM_##sym))
> #define __cond_export_sym(sym, val, sec, conf) \
> ___cond_export_sym(sym, val, sec, conf)
> diff --git a/include/linux/export.h b/include/linux/export.h
> index ce764a5..0413a3d 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -92,22 +92,22 @@ struct kernel_symbol {
> */
> #define __EXPORT_SYMBOL(sym, sec)
>
> -#elif defined(__KSYM_DEPS__)
> +#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> +
> +#include
>
> /*
> * For fine grained build dependencies, we want to tell the build system
> * about each possible exported symbol even if they're not actually exported.
> - * We use a string pattern that is unlikely to be valid code that the build
> - * system filters out from the preprocessor output (see ksym_dep_filter
> - * in scripts/Kbuild.include).
> + * We use a symbol pattern __ksym_marker_ that the build system
> filters
> + * from the $(NM) output (see scripts/gen_ksymdep.sh). These symbols are
> + * discarded in the final link stage.
> */
> -#define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
> -
> -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> -
> -#include
> +#define __ksym_marker(sym) \
> + static int __ksym_marker_##sym[0] __section(".discard.ksym") __used
Even if this is discarded during the final link, maybe this could save
a tiny amount of disk space by using a char instead?
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 7f3ca6e..e5ba9b1 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -254,9 +254,18 @@ objtool_dep = $(objtool_obj)
> \
> $(wildcard include/config/orc/unwinder.h \
>include/config/stack/validation.h)
>
> +ifdef CONFIG_TRIM_UNUSED_KSYMS
> +cmd_gen_ksymdeps = \
> + $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >
> $(dot-target).tmp; \
> + cat $(dot-target).tmp >> $(dot-target).cmd; \
> + rm -f $(dot-target).tmp;
Why don't you append to $(dot-target).cmd directly?
Nicolas
Re: [PATCH 4/8] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS
On Thu, 15 Nov 2018, Masahiro Yamada wrote:
> My main motivation of this commit is to clean up scripts/Kbuild.include
> and scripts/Makefile.build.
>
> Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> possibly exported symbols are detected by letting $(CPP) replace
> EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is
> post-processed by sed, and passed to fixdep. The extra preprocessing
> is costly, and hacking cmd_and_fixdep is ugly.
>
> I came up with a new way to find exported symbols; insert a dummy
> symbol __ksym_marker_* to each potentially exported symbol. Those
> dummy symbols are picked up by $(NM), post-processed by sed, then
> appended to .*.cmd files. I collected the post-process part to a
> new shell script scripts/gen_ksymdeps.sh for readability. The dummy
> symbols are put into the .discard.* section so that the linker
> script rips them off the final vmlinux or modules.
Brilliant! I really like it.
Minor comments below.
> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 4d73e6e..294d6ae 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -59,16 +59,19 @@ __kcrctab_\name:
> .endm
> #undef __put
>
> -#if defined(__KSYM_DEPS__)
> -
> -#define __EXPORT_SYMBOL(sym, val, sec) === __KSYM_##sym ===
> -
> -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> +#if defined(CONFIG_TRIM_UNUSED_KSYMS)
>
> #include
> #include
>
> +.macro __ksym_marker sym
> + .section ".discard.ksym","a"
> +__ksym_marker_\sym:
> + .previous
Does this work as intended? I have vague memories about having problems
with sections being discarded when they don't allocate any space.
> +.endm
> +
> #define __EXPORT_SYMBOL(sym, val, sec) \
> + __ksym_marker sym; \
> __cond_export_sym(sym, val, sec, __is_defined(__KSYM_##sym))
> #define __cond_export_sym(sym, val, sec, conf) \
> ___cond_export_sym(sym, val, sec, conf)
> diff --git a/include/linux/export.h b/include/linux/export.h
> index ce764a5..0413a3d 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -92,22 +92,22 @@ struct kernel_symbol {
> */
> #define __EXPORT_SYMBOL(sym, sec)
>
> -#elif defined(__KSYM_DEPS__)
> +#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> +
> +#include
>
> /*
> * For fine grained build dependencies, we want to tell the build system
> * about each possible exported symbol even if they're not actually exported.
> - * We use a string pattern that is unlikely to be valid code that the build
> - * system filters out from the preprocessor output (see ksym_dep_filter
> - * in scripts/Kbuild.include).
> + * We use a symbol pattern __ksym_marker_ that the build system
> filters
> + * from the $(NM) output (see scripts/gen_ksymdep.sh). These symbols are
> + * discarded in the final link stage.
> */
> -#define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
> -
> -#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
> -
> -#include
> +#define __ksym_marker(sym) \
> + static int __ksym_marker_##sym[0] __section(".discard.ksym") __used
Even if this is discarded during the final link, maybe this could save
a tiny amount of disk space by using a char instead?
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 7f3ca6e..e5ba9b1 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -254,9 +254,18 @@ objtool_dep = $(objtool_obj)
> \
> $(wildcard include/config/orc/unwinder.h \
>include/config/stack/validation.h)
>
> +ifdef CONFIG_TRIM_UNUSED_KSYMS
> +cmd_gen_ksymdeps = \
> + $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >
> $(dot-target).tmp; \
> + cat $(dot-target).tmp >> $(dot-target).cmd; \
> + rm -f $(dot-target).tmp;
Why don't you append to $(dot-target).cmd directly?
Nicolas
Re: [PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk
Hi,
On Thu, Nov 15, 2018 at 4:42 PM Derek Basehore wrote:
>
> This adds the xin32k clock to the RK3399 CPU. Even though it's not
> directly used, muxes will end up traversing the entire clk tree on
> calls to determine_rate if it doesn't exist.
>
> Signed-off-by: Derek Basehore
> ---
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 99e7f65c1779..6a32293982d0 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -191,6 +191,13 @@
> #clock-cells = <0>;
> };
>
> + xin32k: xin32k {
nit: xin32k is the name of the clock that rk3399 consumes. It seems a
little weird to name this node with that name. Can you call this:
ap_rtc_clk: ap-rtc-clk
...after the gru schematic? You wouldn't change the
clock-output-names, just the node name / label.
> + compatible = "fixed-clock";
> + clock-frequency = <32000>;
I checked the datasheet for the 32K clock and it shows that this is a
32768 Hz clock, not a 32000 Hz one. I also checked the rk808 clock
driver (which is supposed to be compatible with rk3399) and it
produces a 32768 clock.
Re: [PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk
Hi,
On Thu, Nov 15, 2018 at 4:42 PM Derek Basehore wrote:
>
> This adds the xin32k clock to the RK3399 CPU. Even though it's not
> directly used, muxes will end up traversing the entire clk tree on
> calls to determine_rate if it doesn't exist.
>
> Signed-off-by: Derek Basehore
> ---
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 99e7f65c1779..6a32293982d0 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -191,6 +191,13 @@
> #clock-cells = <0>;
> };
>
> + xin32k: xin32k {
nit: xin32k is the name of the clock that rk3399 consumes. It seems a
little weird to name this node with that name. Can you call this:
ap_rtc_clk: ap-rtc-clk
...after the gru schematic? You wouldn't change the
clock-output-names, just the node name / label.
> + compatible = "fixed-clock";
> + clock-frequency = <32000>;
I checked the datasheet for the 32K clock and it shows that this is a
32768 Hz clock, not a 32000 Hz one. I also checked the rk808 clock
driver (which is supposed to be compatible with rk3399) and it
produces a 32768 clock.
[PATCH 1/1] Input: synaptics - enable SMBus for HP 15-ay000 (SYN3221).
SMBus works fine for the touchpad with id SYN3221, used in the HP 15-ay000
series,
This device has been reported in these messages in the "linux-input" mailing
list:
* https://marc.info/?l=linux-input=152016683003369=2
* https://www.spinics.net/lists/linux-input/msg52525.html
Reported-by: Nitesh Debnath
Reported-by: Teika Kazura
Signed-off-by: Teika Kazura
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 55d33500d5..591b776f22 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -179,6 +179,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN0096", /* X280 */
"LEN0097", /* X280 -> ALPS trackpoint */
"LEN200f", /* T450s */
+ "SYN3221", /* HP 15-ay000 */
NULL
};
--
2.18.1
[PATCH 1/1] Input: synaptics - enable SMBus for HP 15-ay000 (SYN3221).
SMBus works fine for the touchpad with id SYN3221, used in the HP 15-ay000
series,
This device has been reported in these messages in the "linux-input" mailing
list:
* https://marc.info/?l=linux-input=152016683003369=2
* https://www.spinics.net/lists/linux-input/msg52525.html
Reported-by: Nitesh Debnath
Reported-by: Teika Kazura
Signed-off-by: Teika Kazura
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 55d33500d5..591b776f22 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -179,6 +179,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN0096", /* X280 */
"LEN0097", /* X280 -> ALPS trackpoint */
"LEN200f", /* T450s */
+ "SYN3221", /* HP 15-ay000 */
NULL
};
--
2.18.1
Re: possible deadlock in acct_pin_kill
syzbot has found a reproducer for the following crash on:
HEAD commit:da5322e65940 Merge tag 'selinux-pr-20181115' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1570390540
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https://syzkaller.appspot.com/bug?extid=2a73a6ea9507b7112141
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11950d4d40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a73a6ea9507b7112...@syzkaller.appspotmail.com
overlayfs: failed to resolve './file1': -2
overlayfs: filesystem on './file0' not supported as upperdir
==
overlayfs: filesystem on './file0' not supported as upperdir
WARNING: possible circular locking dependency detected
4.20.0-rc2+ #336 Not tainted
--
syz-executor0/7612 is trying to acquire lock:
a1ecfa3f (>lock#2){+.+.}, at: acct_pin_kill+0x26/0x100
kernel/acct.c:173
Process accounting resumed
but task is already holding lock:
1109cf86 (sb_writers#3){.+.+}, at: sb_start_write
include/linux/fs.h:1597 [inline]
1109cf86 (sb_writers#3){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:360
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_writers#3){.+.+}:
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x214/0x370 fs/super.c:1387
file_start_write include/linux/fs.h:2810 [inline]
ovl_write_iter+0x9a7/0xd10 fs/overlayfs/file.c:243
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
do_acct_process+0x1144/0x1660 kernel/acct.c:520
slow_acct_process kernel/acct.c:579 [inline]
acct_process+0x6b1/0x875 kernel/acct.c:605
do_exit+0x1b89/0x26d0 kernel/exit.c:857
do_group_exit+0x177/0x440 kernel/exit.c:970
get_signal+0x8b0/0x1980 kernel/signal.c:2517
do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (_i_mutex_key[depth]){+.+.}:
down_write+0x8a/0x130 kernel/locking/rwsem.c:70
inode_lock include/linux/fs.h:757 [inline]
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
do_acct_process+0x1144/0x1660 kernel/acct.c:520
slow_acct_process kernel/acct.c:579 [inline]
acct_process+0x6b1/0x875 kernel/acct.c:605
do_exit+0x1b89/0x26d0 kernel/exit.c:857
do_group_exit+0x177/0x440 kernel/exit.c:970
get_signal+0x8b0/0x1980 kernel/signal.c:2517
do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (>lock#2){+.+.}:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
acct_pin_kill+0x26/0x100 kernel/acct.c:173
pin_kill+0x29d/0xab0 fs/fs_pin.c:50
acct_on+0x665/0x940 kernel/acct.c:254
__do_sys_acct kernel/acct.c:286 [inline]
__se_sys_acct kernel/acct.c:273 [inline]
__x64_sys_acct+0xc2/0x1f0 kernel/acct.c:273
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
>lock#2 --> _i_mutex_key[depth] --> sb_writers#3
Possible unsafe locking scenario:
CPU0CPU1
lock(sb_writers#3);
lock(_i_mutex_key[depth]);
lock(sb_writers#3);
lock(>lock#2);
*** DEADLOCK ***
2 locks held by syz-executor0/7612:
#0: a4cfd6c1 (acct_on_mutex){+.+.}, at: __
Re: possible deadlock in acct_pin_kill
syzbot has found a reproducer for the following crash on:
HEAD commit:da5322e65940 Merge tag 'selinux-pr-20181115' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1570390540
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https://syzkaller.appspot.com/bug?extid=2a73a6ea9507b7112141
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11950d4d40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a73a6ea9507b7112...@syzkaller.appspotmail.com
overlayfs: failed to resolve './file1': -2
overlayfs: filesystem on './file0' not supported as upperdir
==
overlayfs: filesystem on './file0' not supported as upperdir
WARNING: possible circular locking dependency detected
4.20.0-rc2+ #336 Not tainted
--
syz-executor0/7612 is trying to acquire lock:
a1ecfa3f (>lock#2){+.+.}, at: acct_pin_kill+0x26/0x100
kernel/acct.c:173
Process accounting resumed
but task is already holding lock:
1109cf86 (sb_writers#3){.+.+}, at: sb_start_write
include/linux/fs.h:1597 [inline]
1109cf86 (sb_writers#3){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:360
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_writers#3){.+.+}:
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x214/0x370 fs/super.c:1387
file_start_write include/linux/fs.h:2810 [inline]
ovl_write_iter+0x9a7/0xd10 fs/overlayfs/file.c:243
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
do_acct_process+0x1144/0x1660 kernel/acct.c:520
slow_acct_process kernel/acct.c:579 [inline]
acct_process+0x6b1/0x875 kernel/acct.c:605
do_exit+0x1b89/0x26d0 kernel/exit.c:857
do_group_exit+0x177/0x440 kernel/exit.c:970
get_signal+0x8b0/0x1980 kernel/signal.c:2517
do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (_i_mutex_key[depth]){+.+.}:
down_write+0x8a/0x130 kernel/locking/rwsem.c:70
inode_lock include/linux/fs.h:757 [inline]
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
do_acct_process+0x1144/0x1660 kernel/acct.c:520
slow_acct_process kernel/acct.c:579 [inline]
acct_process+0x6b1/0x875 kernel/acct.c:605
do_exit+0x1b89/0x26d0 kernel/exit.c:857
do_group_exit+0x177/0x440 kernel/exit.c:970
get_signal+0x8b0/0x1980 kernel/signal.c:2517
do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (>lock#2){+.+.}:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
acct_pin_kill+0x26/0x100 kernel/acct.c:173
pin_kill+0x29d/0xab0 fs/fs_pin.c:50
acct_on+0x665/0x940 kernel/acct.c:254
__do_sys_acct kernel/acct.c:286 [inline]
__se_sys_acct kernel/acct.c:273 [inline]
__x64_sys_acct+0xc2/0x1f0 kernel/acct.c:273
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
>lock#2 --> _i_mutex_key[depth] --> sb_writers#3
Possible unsafe locking scenario:
CPU0CPU1
lock(sb_writers#3);
lock(_i_mutex_key[depth]);
lock(sb_writers#3);
lock(>lock#2);
*** DEADLOCK ***
2 locks held by syz-executor0/7612:
#0: a4cfd6c1 (acct_on_mutex){+.+.}, at: __
Re: [PATCH] mm: use managed_zone() for more exact check in zone iteration
On Thu, Nov 15, 2018 at 01:37:35PM -0800, Andrew Morton wrote: >On Thu, 15 Nov 2018 07:50:40 +0800 Wei Yang wrote: > >> For one zone, there are three digits to describe its space range: >> >> spanned_pages >> present_pages >> managed_pages >> >> The detailed meaning is written in include/linux/mmzone.h. This patch >> concerns about the last two. >> >> present_pages is physical pages existing within the zone >> managed_pages is present pages managed by the buddy system >> >> >From the definition, managed_pages is a more strict condition than >> present_pages. >> >> There are two functions using zone's present_pages as a boundary: >> >> populated_zone() >> for_each_populated_zone() >> >> By going through the kernel tree, most of their users are willing to >> access pages managed by the buddy system, which means it is more exact >> to check zone's managed_pages for a validation. >> >> This patch replaces those checks on present_pages to managed_pages by: >> >> * change for_each_populated_zone() to for_each_managed_zone() >> * convert for_each_populated_zone() to for_each_zone() and check >> populated_zone() where is necessary >> * change populated_zone() to managed_zone() at proper places >> >> Signed-off-by: Wei Yang >> >> --- >> >> Michal, after last mail, I did one more thing to replace >> populated_zone() with managed_zone() at proper places. >> >> One thing I am not sure is those places in mm/compaction.c. I have >> chaged them. If not, please let me know. >> >> BTW, I did a boot up test with the patched kernel and looks smooth. > >Seems sensible, but a bit scary. A basic boot test is unlikely to >expose subtle gremlins. > Agree. >Worse, the situations in which managed_zone() != populated_zone() are >rare(?), so it will take a long time for problems to be discovered, I >expect. Hmm... I created a virtual machine with 4 nodes, which has total 6 populated zones. All of them are different. This is a little bit out of my expactation. > >I'll toss it in there for now, let's see who breaks :( Thanks. -- Wei Yang Help you, Help me
Re: [PATCH] mm: use managed_zone() for more exact check in zone iteration
On Thu, Nov 15, 2018 at 01:37:35PM -0800, Andrew Morton wrote: >On Thu, 15 Nov 2018 07:50:40 +0800 Wei Yang wrote: > >> For one zone, there are three digits to describe its space range: >> >> spanned_pages >> present_pages >> managed_pages >> >> The detailed meaning is written in include/linux/mmzone.h. This patch >> concerns about the last two. >> >> present_pages is physical pages existing within the zone >> managed_pages is present pages managed by the buddy system >> >> >From the definition, managed_pages is a more strict condition than >> present_pages. >> >> There are two functions using zone's present_pages as a boundary: >> >> populated_zone() >> for_each_populated_zone() >> >> By going through the kernel tree, most of their users are willing to >> access pages managed by the buddy system, which means it is more exact >> to check zone's managed_pages for a validation. >> >> This patch replaces those checks on present_pages to managed_pages by: >> >> * change for_each_populated_zone() to for_each_managed_zone() >> * convert for_each_populated_zone() to for_each_zone() and check >> populated_zone() where is necessary >> * change populated_zone() to managed_zone() at proper places >> >> Signed-off-by: Wei Yang >> >> --- >> >> Michal, after last mail, I did one more thing to replace >> populated_zone() with managed_zone() at proper places. >> >> One thing I am not sure is those places in mm/compaction.c. I have >> chaged them. If not, please let me know. >> >> BTW, I did a boot up test with the patched kernel and looks smooth. > >Seems sensible, but a bit scary. A basic boot test is unlikely to >expose subtle gremlins. > Agree. >Worse, the situations in which managed_zone() != populated_zone() are >rare(?), so it will take a long time for problems to be discovered, I >expect. Hmm... I created a virtual machine with 4 nodes, which has total 6 populated zones. All of them are different. This is a little bit out of my expactation. > >I'll toss it in there for now, let's see who breaks :( Thanks. -- Wei Yang Help you, Help me
[PATCH] perf stat: Fix shadow stats for clock events
Commit 0aa802a79469 ("perf stat: Get rid of extra clock display
function") introduced scale and unit for clock events. Thus,
perf_stat__update_shadow_stats() now saves scaled values of
clock events in msecs, instead of original nsecs. But while
calculating values of shadow stats we still consider clock
event values in nsecs. This results in a wrong shadow stat
values. Ex,
# ./perf stat -e task-clock,cycles ls
2.60 msec task-clock:u#0.877 CPUs utilized
2,430,564 cycles:u# 1215282.000 GHz
Fix this by saving original nsec values for clock events in
perf_stat__update_shadow_stats(). After patch:
# ./perf stat -e task-clock,cycles ls
3.14 msec task-clock:u#0.839 CPUs utilized
3,094,528 cycles:u#0.985 GHz
Reported-by: Anton Blanchard
Suggested-by: Jiri Olsa
Fixes: 0aa802a79469 ("perf stat: Get rid of extra clock display function")
Signed-off-by: Ravi Bangoria
---
tools/perf/util/stat-shadow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index f0a8cec55c47..3c22c58b3e90 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -209,11 +209,12 @@ void perf_stat__update_shadow_stats(struct perf_evsel
*counter, u64 count,
int cpu, struct runtime_stat *st)
{
int ctx = evsel_context(counter);
+ u64 count_ns = count;
count *= counter->scale;
if (perf_evsel__is_clock(counter))
- update_runtime_stat(st, STAT_NSECS, 0, cpu, count);
+ update_runtime_stat(st, STAT_NSECS, 0, cpu, count_ns);
else if (perf_evsel__match(counter, HARDWARE, HW_CPU_CYCLES))
update_runtime_stat(st, STAT_CYCLES, ctx, cpu, count);
else if (perf_stat_evsel__is(counter, CYCLES_IN_TX))
--
2.17.1
[PATCH] perf stat: Fix shadow stats for clock events
Commit 0aa802a79469 ("perf stat: Get rid of extra clock display
function") introduced scale and unit for clock events. Thus,
perf_stat__update_shadow_stats() now saves scaled values of
clock events in msecs, instead of original nsecs. But while
calculating values of shadow stats we still consider clock
event values in nsecs. This results in a wrong shadow stat
values. Ex,
# ./perf stat -e task-clock,cycles ls
2.60 msec task-clock:u#0.877 CPUs utilized
2,430,564 cycles:u# 1215282.000 GHz
Fix this by saving original nsec values for clock events in
perf_stat__update_shadow_stats(). After patch:
# ./perf stat -e task-clock,cycles ls
3.14 msec task-clock:u#0.839 CPUs utilized
3,094,528 cycles:u#0.985 GHz
Reported-by: Anton Blanchard
Suggested-by: Jiri Olsa
Fixes: 0aa802a79469 ("perf stat: Get rid of extra clock display function")
Signed-off-by: Ravi Bangoria
---
tools/perf/util/stat-shadow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index f0a8cec55c47..3c22c58b3e90 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -209,11 +209,12 @@ void perf_stat__update_shadow_stats(struct perf_evsel
*counter, u64 count,
int cpu, struct runtime_stat *st)
{
int ctx = evsel_context(counter);
+ u64 count_ns = count;
count *= counter->scale;
if (perf_evsel__is_clock(counter))
- update_runtime_stat(st, STAT_NSECS, 0, cpu, count);
+ update_runtime_stat(st, STAT_NSECS, 0, cpu, count_ns);
else if (perf_evsel__match(counter, HARDWARE, HW_CPU_CYCLES))
update_runtime_stat(st, STAT_CYCLES, ctx, cpu, count);
else if (perf_stat_evsel__is(counter, CYCLES_IN_TX))
--
2.17.1
Re: Crash in msm serial on dragonboard with ftrace bootargs
On Thu, Nov 15, 2018 at 4:23 PM Srinivas Kandagatla wrote: > Yes, this is not the solution, but it proves that the hand-off between > booloaders and kernel is the issue. > > In general there is wider issue with resources hand-off between > bootloader and kernel. > > There has been some proposal in the past by Viresh for a new framework > called boot-constriants (https://lkml.org/lkml/2017/12/14/440) which am > not sure if its still actively looked at. But something similar should > be the way to address such issues. It isn't dead code yet and I am waiting to gain few more use-cases before I attempt to convince Greg again :) Here is the code.. git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git boot-constraint -- viresh
Re: Crash in msm serial on dragonboard with ftrace bootargs
On Thu, Nov 15, 2018 at 4:23 PM Srinivas Kandagatla wrote: > Yes, this is not the solution, but it proves that the hand-off between > booloaders and kernel is the issue. > > In general there is wider issue with resources hand-off between > bootloader and kernel. > > There has been some proposal in the past by Viresh for a new framework > called boot-constriants (https://lkml.org/lkml/2017/12/14/440) which am > not sure if its still actively looked at. But something similar should > be the way to address such issues. It isn't dead code yet and I am waiting to gain few more use-cases before I attempt to convince Greg again :) Here is the code.. git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git boot-constraint -- viresh
Re: [PATCH 1/2] clocksource: Demote dbx500 PRCMU clocksource
On 15 November 2018 at 21:32, Linus Walleij wrote:
> Demote the DBx500 PRCMU clocksource to quality 100 and
> mark it as NONSTOP so it will still be used for
> timekeeping across suspend/resume.
>
> The Nomadik MTU timer which has higher precision will
> be used when the system is up and running, thanks to
> the recent changes properly utilizing the suspend
> clocksources.
>
> This was discussed back in 2011 when the driver was
> written, but the infrastructure was not available
> upstream to use this timer properly. Now the
> infrastructure is there, so let's finalize the work.
>
> Cc: Baolin Wang
> Signed-off-by: Linus Walleij
> ---
Glad to see new driver uses the suspend clocksource.
Reviewed-by: Baolin Wang
> drivers/clocksource/clksrc-dbx500-prcmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c
> b/drivers/clocksource/clksrc-dbx500-prcmu.c
> index c1b96dc5f444..4054539fe066 100644
> --- a/drivers/clocksource/clksrc-dbx500-prcmu.c
> +++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
> @@ -46,10 +46,10 @@ static u64 notrace clksrc_dbx500_prcmu_read(struct
> clocksource *cs)
>
> static struct clocksource clocksource_dbx500_prcmu = {
> .name = "dbx500-prcmu-timer",
> - .rating = 300,
> + .rating = 100,
> .read = clksrc_dbx500_prcmu_read,
> .mask = CLOCKSOURCE_MASK(32),
> - .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS |
> CLOCK_SOURCE_SUSPEND_NONSTOP,
> };
>
> #ifdef CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK
> --
> 2.17.2
>
--
Baolin Wang
Best Regards
Re: [PATCH 1/2] clocksource: Demote dbx500 PRCMU clocksource
On 15 November 2018 at 21:32, Linus Walleij wrote:
> Demote the DBx500 PRCMU clocksource to quality 100 and
> mark it as NONSTOP so it will still be used for
> timekeeping across suspend/resume.
>
> The Nomadik MTU timer which has higher precision will
> be used when the system is up and running, thanks to
> the recent changes properly utilizing the suspend
> clocksources.
>
> This was discussed back in 2011 when the driver was
> written, but the infrastructure was not available
> upstream to use this timer properly. Now the
> infrastructure is there, so let's finalize the work.
>
> Cc: Baolin Wang
> Signed-off-by: Linus Walleij
> ---
Glad to see new driver uses the suspend clocksource.
Reviewed-by: Baolin Wang
> drivers/clocksource/clksrc-dbx500-prcmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c
> b/drivers/clocksource/clksrc-dbx500-prcmu.c
> index c1b96dc5f444..4054539fe066 100644
> --- a/drivers/clocksource/clksrc-dbx500-prcmu.c
> +++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
> @@ -46,10 +46,10 @@ static u64 notrace clksrc_dbx500_prcmu_read(struct
> clocksource *cs)
>
> static struct clocksource clocksource_dbx500_prcmu = {
> .name = "dbx500-prcmu-timer",
> - .rating = 300,
> + .rating = 100,
> .read = clksrc_dbx500_prcmu_read,
> .mask = CLOCKSOURCE_MASK(32),
> - .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS |
> CLOCK_SOURCE_SUSPEND_NONSTOP,
> };
>
> #ifdef CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK
> --
> 2.17.2
>
--
Baolin Wang
Best Regards
Re: [PATCH v6 0/2] arm64: dts: add prng-ee nodes
On 15-11-18, 11:20, Andy Gross wrote: > On Thu, Nov 15, 2018 at 09:15:18AM +0530, Vinod Koul wrote: > > On 01-10-18, 11:51, Vinod Koul wrote: > > > This adds prng-ee nodes for msm8996 and sdm845 > > > > Ping Andy, would appreciate if you can pick these up. > > Done. I did have to massage the location in dts for both of these patches to > keep the address order correct. Thank you Andy, appreciate it. I have two more series in queue, QCS404 DTS series https://patchwork.kernel.org/project/linux-arm-msm/list/?series=40841 and QCS404 defconfigs https://patchwork.kernel.org/project/linux-arm-msm/list/?series=40853 Would be great if you can review these as well Regards -- ~Vinod
Re: [PATCH v6 0/2] arm64: dts: add prng-ee nodes
On 15-11-18, 11:20, Andy Gross wrote: > On Thu, Nov 15, 2018 at 09:15:18AM +0530, Vinod Koul wrote: > > On 01-10-18, 11:51, Vinod Koul wrote: > > > This adds prng-ee nodes for msm8996 and sdm845 > > > > Ping Andy, would appreciate if you can pick these up. > > Done. I did have to massage the location in dts for both of these patches to > keep the address order correct. Thank you Andy, appreciate it. I have two more series in queue, QCS404 DTS series https://patchwork.kernel.org/project/linux-arm-msm/list/?series=40841 and QCS404 defconfigs https://patchwork.kernel.org/project/linux-arm-msm/list/?series=40853 Would be great if you can review these as well Regards -- ~Vinod
Re: [PATCH] ASoC: imx-audmux: complete dt-bindings for imx6
On Mon, Nov 05, 2018 at 02:58:02PM +0100, Clément Péron wrote: > From: Colin Didier > > The MX6 Audmux differs from MX51. > > This patch adds the audmux for i.MX6 family. > > Signed-off-by: Colin Didier > Signed-off-by: Clément Péron I think you should send it to ASoC maintainer and list for applying. Shawn > --- > include/dt-bindings/sound/fsl-imx-audmux.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/include/dt-bindings/sound/fsl-imx-audmux.h > b/include/dt-bindings/sound/fsl-imx-audmux.h > index 15f138bebe16..a1d0741d9ed1 100644 > --- a/include/dt-bindings/sound/fsl-imx-audmux.h > +++ b/include/dt-bindings/sound/fsl-imx-audmux.h > @@ -25,6 +25,14 @@ > #define MX51_AUDMUX_PORT65 > #define MX51_AUDMUX_PORT76 > > +#define MX6_AUDMUX_PORT1_SSI10 > +#define MX6_AUDMUX_PORT2_SSI21 > +#define MX6_AUDMUX_PORT3 2 > +#define MX6_AUDMUX_PORT4 3 > +#define MX6_AUDMUX_PORT5 4 > +#define MX6_AUDMUX_PORT6 5 > +#define MX6_AUDMUX_PORT7_SSI36 > + > /* > * TFCSEL/RFCSEL (i.MX27) or TFSEL/TCSEL/RFSEL/RCSEL (i.MX31/51/53/6Q) > * can be sourced from Rx/Tx. > -- > 2.19.1 >
Re: [PATCH] ASoC: imx-audmux: complete dt-bindings for imx6
On Mon, Nov 05, 2018 at 02:58:02PM +0100, Clément Péron wrote: > From: Colin Didier > > The MX6 Audmux differs from MX51. > > This patch adds the audmux for i.MX6 family. > > Signed-off-by: Colin Didier > Signed-off-by: Clément Péron I think you should send it to ASoC maintainer and list for applying. Shawn > --- > include/dt-bindings/sound/fsl-imx-audmux.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/include/dt-bindings/sound/fsl-imx-audmux.h > b/include/dt-bindings/sound/fsl-imx-audmux.h > index 15f138bebe16..a1d0741d9ed1 100644 > --- a/include/dt-bindings/sound/fsl-imx-audmux.h > +++ b/include/dt-bindings/sound/fsl-imx-audmux.h > @@ -25,6 +25,14 @@ > #define MX51_AUDMUX_PORT65 > #define MX51_AUDMUX_PORT76 > > +#define MX6_AUDMUX_PORT1_SSI10 > +#define MX6_AUDMUX_PORT2_SSI21 > +#define MX6_AUDMUX_PORT3 2 > +#define MX6_AUDMUX_PORT4 3 > +#define MX6_AUDMUX_PORT5 4 > +#define MX6_AUDMUX_PORT6 5 > +#define MX6_AUDMUX_PORT7_SSI36 > + > /* > * TFCSEL/RFCSEL (i.MX27) or TFSEL/TCSEL/RFSEL/RCSEL (i.MX31/51/53/6Q) > * can be sourced from Rx/Tx. > -- > 2.19.1 >
Re: [PATCH] ARM: dts: imx6ul: ccimx6ulsom: Fix indentation on iomuxc nodes
On Mon, Nov 05, 2018 at 11:48:04AM +0100, Alex Gonzalez wrote: > This patch corrects indentation problems in the gpmigrp and i2c1grp nodes. > > Signed-off-by: Alex Gonzalez Applied, thanks.
Re: [PATCH] ARM: dts: imx6ul: ccimx6ulsom: Fix indentation on iomuxc nodes
On Mon, Nov 05, 2018 at 11:48:04AM +0100, Alex Gonzalez wrote: > This patch corrects indentation problems in the gpmigrp and i2c1grp nodes. > > Signed-off-by: Alex Gonzalez Applied, thanks.
Re: [PATCH v2] ARM: dts: imx6ul: ccimx6ulsom: Add support for wireless SOM variant
On Mon, Nov 05, 2018 at 11:43:42AM +0100, Alex Gonzalez wrote: > The wireless variants of the ConnecCore 6UL SOM include a Qualcomm > QCA6564 wireless chip with dual WiFi and Bluetooth. > > Both the ConnectCore 6UL SBC Express and Pro boards fit a wireless SOM. > > The Wifi is connected through the SDIO interface on usdhc1 and the > Bluetooth is connected via uart1. > > Reviewed-by: Fabio Estevam > Signed-off-by: Alex Gonzalez Applied, thanks.
Re: [PATCH v2] ARM: dts: imx6ul: ccimx6ulsom: Add support for wireless SOM variant
On Mon, Nov 05, 2018 at 11:43:42AM +0100, Alex Gonzalez wrote: > The wireless variants of the ConnecCore 6UL SOM include a Qualcomm > QCA6564 wireless chip with dual WiFi and Bluetooth. > > Both the ConnectCore 6UL SBC Express and Pro boards fit a wireless SOM. > > The Wifi is connected through the SDIO interface on usdhc1 and the > Bluetooth is connected via uart1. > > Reviewed-by: Fabio Estevam > Signed-off-by: Alex Gonzalez Applied, thanks.
Re: [PATCHv3 1/6] atomics: add common header generation files
Hi Andrew, On Thu, Nov 15, 2018 at 03:10:48PM -0800, Andrew Morton wrote: > On Tue, 4 Sep 2018 11:48:25 +0100 Mark Rutland wrote: > > > To minimize repetition, to allow for future rework, and to ensure > > regularity of the various atomic APIs, we'd like to automatically > > generate (the bulk of) a number of headers related to atomics. > > > > This patch adds the infrastructure to do so, leaving actual conversion > > of headers to subsequent patches. > > This thing is appallingly slow. `sh scripts/atomic/check-atomics.sh' > takes 8 seconds on a machine which builds an allnoconfig kernel in 30 > seconds. Hmm... on my laptop it's less than half that, and allnoconfig takes ~35s, so clearly there's a major difference between our setups. For reference, which distro are you using, and what is /bin/sh on your box? > Um, no. Just no. Please find a way to make this overhead go away. Will do. Trivially, switching to diff -q halves the check runtime for me, and I'm sure there are other parts of the scripting which can be optimized. Thanks, Mark.
Re: [PATCHv3 1/6] atomics: add common header generation files
Hi Andrew, On Thu, Nov 15, 2018 at 03:10:48PM -0800, Andrew Morton wrote: > On Tue, 4 Sep 2018 11:48:25 +0100 Mark Rutland wrote: > > > To minimize repetition, to allow for future rework, and to ensure > > regularity of the various atomic APIs, we'd like to automatically > > generate (the bulk of) a number of headers related to atomics. > > > > This patch adds the infrastructure to do so, leaving actual conversion > > of headers to subsequent patches. > > This thing is appallingly slow. `sh scripts/atomic/check-atomics.sh' > takes 8 seconds on a machine which builds an allnoconfig kernel in 30 > seconds. Hmm... on my laptop it's less than half that, and allnoconfig takes ~35s, so clearly there's a major difference between our setups. For reference, which distro are you using, and what is /bin/sh on your box? > Um, no. Just no. Please find a way to make this overhead go away. Will do. Trivially, switching to diff -q halves the check runtime for me, and I'm sure there are other parts of the scripting which can be optimized. Thanks, Mark.
