Re: [PATCH 2/4] clk: qcom: Add SDX55 GCC support
Quoting Manivannan Sadhasivam (2020-11-05 00:51:48)
> On Wed, Nov 04, 2020 at 06:23:37PM -0800, Stephen Boyd wrote:
> > > diff --git a/drivers/clk/qcom/gcc-sdx55.c b/drivers/clk/qcom/gcc-sdx55.c
> > > new file mode 100644
> > > index ..75831c829202
> > > --- /dev/null
> > > +++ b/drivers/clk/qcom/gcc-sdx55.c
> > > @@ -0,0 +1,1667 @@
> > > +
>
> [...]
>
> > > +static const struct clk_div_table post_div_table_lucid_even[] = {
> > > + { 0x0, 1 },
> > > + { 0x1, 2 },
> > > + { 0x3, 4 },
> > > + { 0x7, 8 },
> > > + { }
> > > +};
> >
> > I think this table is common to all lucid plls? Maybe we can push it
> > into the clk_ops somehow and stop duplicating it here?
> >
>
> Are you referring to lucid plls in this driver? Because, this table is
> not common for other SoCs. And I don't think having this way introduces
> any overhead, so I'd prefer keeping it as it is.
>
Yes all lucid type PLLs probably have the same divider table.
>
> > > +/* For CPUSS functionality the SYS NOC clock needs to be left enabled */
> > > +static struct clk_branch gcc_sys_noc_cpuss_ahb_clk = {
> > > + .halt_reg = 0x4010,
> > > + .halt_check = BRANCH_HALT_VOTED,
> > > + .clkr = {
> > > + .enable_reg = 0x6d008,
> > > + .enable_mask = BIT(0),
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "gcc_sys_noc_cpuss_ahb_clk",
> > > + .parent_hws = (const struct clk_hw *[]){
> > > + _cpuss_ahb_clk_src.clkr.hw },
> > > + .num_parents = 1,
> > > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT,
> >
> > These CLK_IS_CRITICAL clks can't be set once at driver probe time and
> > forgotten about? It would be nice to not allocate memory for things that
> > never matter.
> >
>
> Makes sense! But are we moving into the direction of deprecating the use
> of CLK_IS_CRITICAL?
No? Just judiciously using it.
Re: [PATCH 07/15] input: touchscreen: usbtouchscreen: Remove unused variable 'ret'
On Thu, 12 Nov 2020, Dmitry Torokhov wrote: > On Thu, Nov 12, 2020 at 11:01:56AM +, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/input/touchscreen/usbtouchscreen.c: In function ‘nexio_read_data’: > > drivers/input/touchscreen/usbtouchscreen.c:1052:50: warning: variable > > ‘ret’ set but not used [-Wunused-but-set-variable] > > > > Cc: Dmitry Torokhov > > Cc: Henrik Rydberg > > Cc: James Hilliard > > Cc: Daniel Ritz > > Cc: linux-in...@vger.kernel.org > > Signed-off-by: Lee Jones > > --- > > drivers/input/touchscreen/usbtouchscreen.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/input/touchscreen/usbtouchscreen.c > > b/drivers/input/touchscreen/usbtouchscreen.c > > index 397cb1d3f481b..c3b7130cd9033 100644 > > --- a/drivers/input/touchscreen/usbtouchscreen.c > > +++ b/drivers/input/touchscreen/usbtouchscreen.c > > @@ -1049,7 +1049,7 @@ static int nexio_read_data(struct usbtouch_usb > > *usbtouch, unsigned char *pkt) > > unsigned int data_len = be16_to_cpu(packet->data_len); > > unsigned int x_len = be16_to_cpu(packet->x_len); > > unsigned int y_len = be16_to_cpu(packet->y_len); > > - int x, y, begin_x, begin_y, end_x, end_y, w, h, ret; > > + int x, y, begin_x, begin_y, end_x, end_y, w, h; > > > > /* got touch data? */ > > if ((pkt[0] & 0xe0) != 0xe0) > > @@ -1061,7 +1061,7 @@ static int nexio_read_data(struct usbtouch_usb > > *usbtouch, unsigned char *pkt) > > x_len -= 0x80; > > > > /* send ACK */ > > - ret = usb_submit_urb(priv->ack, GFP_ATOMIC); > > + usb_submit_urb(priv->ack, GFP_ATOMIC); > > I wonder if we should handle potential errors instead. Your call. I'll do whatever you decide. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 06/15] input: touchscreen: melfas_mip4: Remove a bunch of unused variables
On Thu, 12 Nov 2020, Dmitry Torokhov wrote:
> On Thu, Nov 12, 2020 at 11:01:55AM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/input/touchscreen/melfas_mip4.c: In function ‘mip4_report_touch’:
> > drivers/input/touchscreen/melfas_mip4.c:474:5: warning: variable ‘size’
> > set but not used [-Wunused-but-set-variable]
> > drivers/input/touchscreen/melfas_mip4.c:472:5: warning: variable
> > ‘pressure_stage’ set but not used [-Wunused-but-set-variable]
> > drivers/input/touchscreen/melfas_mip4.c:469:7: warning: variable ‘palm’
> > set but not used [-Wunused-but-set-variable]
> > drivers/input/touchscreen/melfas_mip4.c:468:7: warning: variable ‘hover’
> > set but not used [-Wunused-but-set-variable]
> >
> > Cc: Sangwon Jee
> > Cc: Dmitry Torokhov
> > Cc: Henrik Rydberg
> > Cc: linux-in...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/input/touchscreen/melfas_mip4.c | 11 ---
> > 1 file changed, 11 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/melfas_mip4.c
> > b/drivers/input/touchscreen/melfas_mip4.c
> > index f67efdd040b24..9c98759098c7a 100644
> > --- a/drivers/input/touchscreen/melfas_mip4.c
> > +++ b/drivers/input/touchscreen/melfas_mip4.c
> > @@ -465,13 +465,9 @@ static void mip4_report_keys(struct mip4_ts *ts, u8
> > *packet)
> > static void mip4_report_touch(struct mip4_ts *ts, u8 *packet)
> > {
> > int id;
> > - bool hover;
> > - bool palm;
> > bool state;
> > u16 x, y;
> > - u8 pressure_stage = 0;
> > u8 pressure;
> > - u8 size;
> > u8 touch_major;
> > u8 touch_minor;
> >
> > @@ -480,14 +476,11 @@ static void mip4_report_touch(struct mip4_ts *ts, u8
> > *packet)
> > case 1:
> > /* Touch only */
> > state = packet[0] & BIT(7);
> > - hover = packet[0] & BIT(5);
> > - palm = packet[0] & BIT(4);
>
> No really happy that we'd be losing information about protocol. Is there
> a better way to suppress the warning while keeping this info?
Yes. We can either convert the information to comments, or mark the
variables as __always_unused.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 2/2] arm: lib: xor-neon: move pragma options to makefile
On Thu, 12 Nov 2020 at 22:23, Adrian Ratiu wrote:
>
> Using a pragma like GCC optimize is a bad idea because it tags
> all functions with an __attribute__((optimize)) which replaces
> optimization options rather than appending so could result in
> dropping important flags. Not recommended for production use.
>
> Because these options should always be enabled for this file,
> it's better to set them via command line. tree-vectorize is on
> by default in Clang, but it doesn't hurt to make it explicit.
>
> Suggested-by: Arvind Sankar
> Suggested-by: Ard Biesheuvel
> Signed-off-by: Adrian Ratiu
> ---
> arch/arm/lib/Makefile | 2 +-
> arch/arm/lib/xor-neon.c | 10 --
> 2 files changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 6d2ba454f25b..12d31d1a7630 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -45,6 +45,6 @@ $(obj)/csumpartialcopyuser.o:
> $(obj)/csumpartialcopygeneric.S
>
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
>NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp
> -mfpu=neon
> - CFLAGS_xor-neon.o+= $(NEON_FLAGS)
> + CFLAGS_xor-neon.o+= $(NEON_FLAGS) -ftree-vectorize
> -Wno-unused-variable
>obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> endif
> diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> index e1e76186ec23..62b493e386c4 100644
> --- a/arch/arm/lib/xor-neon.c
> +++ b/arch/arm/lib/xor-neon.c
> @@ -14,16 +14,6 @@ MODULE_LICENSE("GPL");
> #error You should compile this file with '-march=armv7-a -mfloat-abi=softfp
> -mfpu=neon'
> #endif
>
> -/*
> - * Pull in the reference implementations while instructing GCC (through
> - * -ftree-vectorize) to attempt to exploit implicit parallelism and emit
> - * NEON instructions.
> - */
> -#ifdef CONFIG_CC_IS_GCC
> -#pragma GCC optimize "tree-vectorize"
> -#endif
> -
> -#pragma GCC diagnostic ignored "-Wunused-variable"
> #include
>
> struct xor_block_template const xor_block_neon_inner = {
> --
> 2.29.2
>
So what is the status now here? How does putting -ftree-vectorize on
the command line interact with Clang?
Re: [PATCH v2 1/2] arm: lib: xor-neon: remove unnecessary GCC < 4.6 warning
On Thu, 12 Nov 2020 at 22:23, Adrian Ratiu wrote:
>
> From: Nathan Chancellor
>
> Drop warning because kernel now requires GCC >= v4.9 after
> commit 6ec4476ac825 ("Raise gcc version requirement to 4.9").
>
> Reported-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> Signed-off-by: Adrian Ratiu
Again, this does not do what it says on the tin.
If you want to disable the pragma for Clang, call that out in the
commit log, and don't hide it under a GCC version change.
Without the pragma, the generated code is the same as the generic
code, so it makes no sense to build xor-neon.ko at all, right?
> ---
> arch/arm/lib/xor-neon.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> index b99dd8e1c93f..e1e76186ec23 100644
> --- a/arch/arm/lib/xor-neon.c
> +++ b/arch/arm/lib/xor-neon.c
> @@ -19,15 +19,8 @@ MODULE_LICENSE("GPL");
> * -ftree-vectorize) to attempt to exploit implicit parallelism and emit
> * NEON instructions.
> */
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
> +#ifdef CONFIG_CC_IS_GCC
> #pragma GCC optimize "tree-vectorize"
> -#else
> -/*
> - * While older versions of GCC do not generate incorrect code, they fail to
> - * recognize the parallel nature of these functions, and emit plain ARM code,
> - * which is known to be slower than the optimized ARM code in asm-arm/xor.h.
> - */
> -#warning This code requires at least version 4.6 of GCC
> #endif
>
> #pragma GCC diagnostic ignored "-Wunused-variable"
> --
> 2.29.2
>
Re: [PATCH 1/3] net: mac80211: use core API for updating TX stats
Am 12.11.2020 um 12:09 schrieb Lev Stipakov:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add")
> has added function "dev_sw_netstats_tx_add()" to update
> net device per-cpu TX stats.
>
> Use this function instead of ieee80211_tx_stats().
>
I think you can do the same with ieee80211_rx_stats().
> Signed-off-by: Lev Stipakov
> ---
> net/mac80211/tx.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 5f05f4651dd7..7807f8178527 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -38,16 +38,6 @@
>
> /* misc utils */
>
> -static inline void ieee80211_tx_stats(struct net_device *dev, u32 len)
> -{
> - struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
> -
> - u64_stats_update_begin(>syncp);
> - tstats->tx_packets++;
> - tstats->tx_bytes += len;
> - u64_stats_update_end(>syncp);
> -}
> -
> static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
>struct sk_buff *skb, int group_addr,
>int next_frag_len)
> @@ -3403,7 +3393,7 @@ static void ieee80211_xmit_fast_finish(struct
> ieee80211_sub_if_data *sdata,
> if (key)
> info->control.hw_key = >conf;
>
> - ieee80211_tx_stats(skb->dev, skb->len);
> + dev_sw_netstats_tx_add(skb->dev, 1, skb->len);
>
> if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
> tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
> @@ -4021,7 +4011,7 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
> goto out;
> }
>
> - ieee80211_tx_stats(dev, skb->len);
> + dev_sw_netstats_tx_add(dev, 1, skb->len);
>
> ieee80211_xmit(sdata, sta, skb);
> }
> @@ -4248,7 +4238,7 @@ static void ieee80211_8023_xmit(struct
> ieee80211_sub_if_data *sdata,
>
> info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
>
> - ieee80211_tx_stats(dev, skb->len);
> + dev_sw_netstats_tx_add(dev, 1, skb->len);
>
> sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
> sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
>
Re: [PATCH 1/3] net: mac80211: use core API for updating TX stats
Am 13.11.2020 um 00:30 schrieb Jakub Kicinski:
> On Thu, 12 Nov 2020 13:09:53 +0200 Lev Stipakov wrote:
>> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add")
>> has added function "dev_sw_netstats_tx_add()" to update
>> net device per-cpu TX stats.
>>
>> Use this function instead of ieee80211_tx_stats().
>>
>> Signed-off-by: Lev Stipakov
>
> Heiner is actively working on this.
>
> Heiner, would you mind looking at these three patches? If you have
> these changes queued in your tree I'm happy to wait for them.
>
This series is a good follow-up to what I did already.
I'll have a look at it.
Re: [PATCH 2/3] net: openvswitch: use core API for updating TX stats
Am 12.11.2020 um 12:11 schrieb Lev Stipakov:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
> function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
> stats.
>
> Use this function instead of own code. While on it, replace
> "len" variable with "skb->len".
>
Using dev_sw_netstats_tx_add() is fine, however you have to keep
variable len, see remark in the code.
In addition you can replace internal_get_stats() with dev_get_tstats64().
> Signed-off-by: Lev Stipakov
> ---
> net/openvswitch/vport-internal_dev.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/net/openvswitch/vport-internal_dev.c
> b/net/openvswitch/vport-internal_dev.c
> index 1e30d8df3ba5..116738d36e02 100644
> --- a/net/openvswitch/vport-internal_dev.c
> +++ b/net/openvswitch/vport-internal_dev.c
> @@ -33,23 +33,17 @@ static struct internal_dev *internal_dev_priv(struct
> net_device *netdev)
> static netdev_tx_t
> internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
> {
> - int len, err;
> + int err;
>
> - len = skb->len;
> rcu_read_lock();
> err = ovs_vport_receive(internal_dev_priv(netdev)->vport, skb, NULL);
We would have a well-hidden problem here. ovs_vport_receive() calls function
ovs_dp_process_packet() that frees the skb under certain circumstances.
Note that the skb can be freed even if ovs_vport_receive() returns OK.
Using skb->len after calling ovs_vport_receive() could result in a
use-after-free therefore. So you have to keep variable len.
> rcu_read_unlock();
>
> - if (likely(!err)) {
> - struct pcpu_sw_netstats *tstats = this_cpu_ptr(netdev->tstats);
> -
> - u64_stats_update_begin(>syncp);
> - tstats->tx_bytes += len;
> - tstats->tx_packets++;
> - u64_stats_update_end(>syncp);
> - } else {
> + if (likely(!err))
> + dev_sw_netstats_tx_add(netdev, 1, skb->len);
> + else
> netdev->stats.tx_errors++;
> - }
> +
> return NETDEV_TX_OK;
> }
>
>
Re: [PATCH 3/3] net: xfrm: use core API for updating TX stats
Am 12.11.2020 um 12:13 schrieb Lev Stipakov:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
> function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
> stats.
>
> Use this function instead of own code.
>
LGTM. In addition you can replace xfrmi_get_stats64() with
dev_get_tstats64().
> Signed-off-by: Lev Stipakov
> ---
> net/xfrm/xfrm_interface.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
> index 9b8e292a7c6a..43ee4c5a6fa9 100644
> --- a/net/xfrm/xfrm_interface.c
> +++ b/net/xfrm/xfrm_interface.c
> @@ -319,12 +319,7 @@ xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev,
> struct flowi *fl)
>
> err = dst_output(xi->net, skb->sk, skb);
> if (net_xmit_eval(err) == 0) {
> - struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
> -
> - u64_stats_update_begin(>syncp);
> - tstats->tx_bytes += length;
> - tstats->tx_packets++;
> - u64_stats_update_end(>syncp);
> + dev_sw_netstats_tx_add(dev, 1, length);
> } else {
> stats->tx_errors++;
> stats->tx_aborted_errors++;
>
Re: [LINUX PATCH V3 0/9] gpio-xilinx: Update on xilinx gpio driver
On 12. 11. 20 18:12, Srinivas Neeli wrote: > This patch series does the following: > -Add clock support > -Add interrupt support > -Add support for suspend and resume > -Add remove support > -Add MAINTAINERS fragment > --- > Changes in V3: > -Created separate patch to arrange headers in sorting order. > -Updated dt-bindings. > -Created separate patch for Clock changes and runtime resume. > and suspend. > -Created separate patch for spinlock changes. > -Created separate patch for remove support. > -Fixed coverity errors. > -Updated minor review comments. > > Changes in V2: > -Added check for return value of platform_get_irq() API. > -Updated code to support rising edge and falling edge. > -Added xgpio_xlate() API to support switch. > -Added MAINTAINERS fragment. > > Tested Below scenarios: > -Tested Loop Back.(channel 1.0 connected to channel 2.0) > -Tested External switch(Used DIP switch) > -Tested Cascade scenario(Here gpio controller acting as > an interrupt controller). > --- > > Srinivas Neeli (9): > gpio: gpio-xilinx: Arrange headers in sorting order > dt-bindings: gpio: gpio-xilinx: Add clk support to xilinx soft gpio IP > gpio: gpio-xilinx: Add clock support > gpio: gpio-xilinx: Reduce spinlock array to single > gpio: gpio-xilinx: Add interrupt support > gpio: gpio-xilinx: Add remove function > gpio: gpio-xilinx: Add support for suspend and resume > gpio: gpio-xilinx: Check return value of of_property_read_u32 > MAINTAINERS: add fragment for xilinx GPIO drivers > > .../devicetree/bindings/gpio/gpio-xilinx.txt | 2 + > MAINTAINERS| 10 + > drivers/gpio/Kconfig | 2 + > drivers/gpio/gpio-xilinx.c | 398 > +++-- > 4 files changed, 390 insertions(+), 22 deletions(-) > For the whole series. Acked-by: Michal Simek Thanks, Michal
[PATCH] rtc: brcmstb-waketimer: Remove redundant null check before clk_disable_unprepare
Because clk_disable_unprepare() already checked NULL clock parameter, so the additional check is unnecessary, just remove it. Signed-off-by: Xu Wang --- drivers/rtc/rtc-brcmstb-waketimer.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c b/drivers/rtc/rtc-brcmstb-waketimer.c index 4fee57c51280..375a9987a1d6 100644 --- a/drivers/rtc/rtc-brcmstb-waketimer.c +++ b/drivers/rtc/rtc-brcmstb-waketimer.c @@ -264,8 +264,7 @@ static int brcmstb_waketmr_probe(struct platform_device *pdev) unregister_reboot_notifier(>reboot_notifier); err_clk: - if (timer->clk) - clk_disable_unprepare(timer->clk); + clk_disable_unprepare(timer->clk); return ret; } -- 2.17.1
Re: [PATCH] drivers: staging: retire drivers/staging/goldfish
On Thu, Nov 12, 2020 at 03:49:07PM -0800, r...@google.com wrote: > From: Roman Kiryanov > > Android Studio Emulator (goldfish) migrated > to Intel HDA. When was that? > > Signed-off-by: Roman Kiryanov > --- > arch/mips/configs/generic/board-ranchu.config | 1 - > drivers/staging/Kconfig | 2 - > drivers/staging/Makefile | 1 - > drivers/staging/goldfish/Kconfig | 7 - > drivers/staging/goldfish/Makefile | 6 - > drivers/staging/goldfish/README | 5 - > drivers/staging/goldfish/goldfish_audio.c | 383 -- What about the other goldfish drivers? thanks, greg k-h
Re: [PATCH V3] arm64/mm: Validate hotplug range before creating linear mapping
On Fri, 13 Nov 2020 at 08:31, Anshuman Khandual
wrote:
>
> During memory hotplug process, the linear mapping should not be created for
> a given memory range if that would fall outside the maximum allowed linear
> range. Else it might cause memory corruption in the kernel virtual space.
>
> Maximum linear mapping region is [PAGE_OFFSET..(PAGE_END -1)] accommodating
> both its ends but excluding PAGE_END. Max physical range that can be mapped
> inside this linear mapping range, must also be derived from its end points.
>
> This ensures that arch_add_memory() validates memory hot add range for its
> potential linear mapping requirements, before creating it with
> __create_pgd_mapping().
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Ard Biesheuvel
> Cc: Steven Price
> Cc: Robin Murphy
> Cc: David Hildenbrand
> Cc: Andrew Morton
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Fixes: 4ab215061554 ("arm64: Add memory hotplug support")
> Signed-off-by: Anshuman Khandual
> ---
> This applies on 5.10-rc3
>
> Changes in V3:
>
> - Dropped comment paragraphs from code and commit message per Ard
> - Dropped parenthesis brackets in the comparison per Ard
>
> Changes in V2:
> (https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khand...@arm.com/)
>
> - Replaced (start + size) with (start + size - 1) in the comparison per Ard
> - Dropped parenthesis brackets in the comparison per Ard
>
> Changes in V1:
> (https://lore.kernel.org/linux-arm-kernel/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/)
>
> arch/arm64/mm/mmu.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 1c0f3e02f731..ca692a815731 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1444,11 +1444,28 @@ static void __remove_pgd_mapping(pgd_t *pgdir,
> unsigned long start, u64 size)
> free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
> }
>
> +static bool inside_linear_region(u64 start, u64 size)
> +{
> + /*
> +* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
> +* accommodating both its ends but excluding PAGE_END. Max physical
> +* range which can be mapped inside this linear mapping range, must
> +* also be derived from its end points.
> +*/
> + return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> + (start + size - 1) <= __pa(PAGE_END - 1);
> +}
> +
> int arch_add_memory(int nid, u64 start, u64 size,
> struct mhp_params *params)
> {
> int ret, flags = 0;
>
> + if (!inside_linear_region(start, size)) {
> + pr_err("[%llx %llx] is outside linear mapping region\n",
> start, start + size);
> + return -EINVAL;
> + }
> +
> if (rodata_full || debug_pagealloc_enabled())
> flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
>
Reviewed-by: Ard Biesheuvel
Re: [PATCH v2 5/6] regulator: mcp16502: add support for ramp delay
Hi Claudiu, I love your patch! Yet something to improve: [auto build test ERROR on regulator/for-next] [also build test ERROR on linus/master linux/master v5.10-rc3 next-20201112] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Claudiu-Beznea/regulator-mcp16502-add-support-for-ramp-delay/2020-170928 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next config: nios2-randconfig-r034-2020 (attached as .config) compiler: nios2-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/d97d6b70286fa3a28e744a55da1b7eb6a026cee3 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Claudiu-Beznea/regulator-mcp16502-add-support-for-ramp-delay/2020-170928 git checkout d97d6b70286fa3a28e744a55da1b7eb6a026cee3 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=nios2 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from include/asm-generic/bug.h:20, from ./arch/nios2/include/generated/asm/bug.h:1, from include/linux/bug.h:5, from include/linux/thread_info.h:12, from include/asm-generic/current.h:5, from ./arch/nios2/include/generated/asm/current.h:1, from include/linux/sched.h:12, from include/linux/ratelimit.h:6, from include/linux/dev_printk.h:16, from include/linux/device.h:15, from include/linux/gpio/driver.h:5, from include/asm-generic/gpio.h:11, from include/linux/gpio.h:62, from drivers/regulator/mcp16502.c:11: drivers/regulator/mcp16502.c: In function 'mcp16502_set_voltage_time_sel': >> drivers/regulator/mcp16502.c:295:54: error: 'const struct linear_range' has >> no member named 'uV_step'; did you mean 'step'? 295 | uV_delta = abs(new_sel * rdev->desc->linear_ranges->uV_step - | ^~~ include/linux/kernel.h:287:38: note: in definition of macro '__abs_choose_expr' 287 | __builtin_types_compatible_p(typeof(x), signed type) || \ | ^ drivers/regulator/mcp16502.c:295:13: note: in expansion of macro 'abs' 295 | uV_delta = abs(new_sel * rdev->desc->linear_ranges->uV_step - | ^~~ drivers/regulator/mcp16502.c:296:47: error: 'const struct linear_range' has no member named 'uV_step'; did you mean 'step'? 296 | old_sel * rdev->desc->linear_ranges->uV_step); | ^~~ include/linux/kernel.h:287:38: note: in definition of macro '__abs_choose_expr' 287 | __builtin_types_compatible_p(typeof(x), signed type) || \ | ^ drivers/regulator/mcp16502.c:295:13: note: in expansion of macro 'abs' 295 | uV_delta = abs(new_sel * rdev->desc->linear_ranges->uV_step - | ^~~ >> drivers/regulator/mcp16502.c:295:54: error: 'const struct linear_range' has >> no member named 'uV_step'; did you mean 'step'? 295 | uV_delta = abs(new_sel * rdev->desc->linear_ranges->uV_step - | ^~~ include/linux/kernel.h:288:38: note: in definition of macro '__abs_choose_expr' 288 | __builtin_types_compatible_p(typeof(x), unsigned type), \ | ^ drivers/regulator/mcp16502.c:295:13: note: in expansion of macro 'abs' 295 | uV_delta = abs(new_sel * rdev->desc->linear_ranges->uV_step - | ^~~ drivers/regulator/mcp16502.c:296:47: error: 'const struct linear_range' has no member named 'uV_step'; did you mean 'step'? 296 | old_sel * rdev->desc->linear_ranges->uV_step); | ^~~ include/linux/kernel.h:288:38: note: in definition of macro '__abs_choose_expr' 288 | __builtin_types_compatible_p(typeof(x), unsigned type), \ | ^ drivers/regulator/mcp16502.c:295:13: note: in expansion of macro 'abs' 295 | uV_delta = abs(new_sel * rdev->desc->linear
Re: [PATCH 08/15] input: touchscreen: surface3_spi: Remove set but unused variable 'timestamp'
On Fri, Nov 13, 2020 at 8:40 AM Dmitry Torokhov
wrote:
>
> On Thu, Nov 12, 2020 at 11:01:57AM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/input/touchscreen/surface3_spi.c: In function
> > ‘surface3_spi_process_touch’:
> > drivers/input/touchscreen/surface3_spi.c:97:6: warning: variable
> > ‘timestamp’ set but not used [-Wunused-but-set-variable]
> >
> > Cc: Dmitry Torokhov
> > Cc: Henrik Rydberg
> > Cc: Benjamin Tissoires
> > Cc: linux-in...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/input/touchscreen/surface3_spi.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/surface3_spi.c
> > b/drivers/input/touchscreen/surface3_spi.c
> > index ce4828b1415a8..72dc4c562a4e1 100644
> > --- a/drivers/input/touchscreen/surface3_spi.c
> > +++ b/drivers/input/touchscreen/surface3_spi.c
> > @@ -94,9 +94,7 @@ static void surface3_spi_report_touch(struct
> > surface3_ts_data *ts_data,
> >
> > static void surface3_spi_process_touch(struct surface3_ts_data *ts_data,
> > u8 *data)
> > {
> > - u16 timestamp;
> > unsigned int i;
> > - timestamp = get_unaligned_le16([15]);
>
> Benjamin, should we pass timing data on to userspace instead?
Last time I checked, libinput was not using the HW timestamp. So I
don't mind dropping it.
Not sure if chrome/android uses it.
Cheers,
Benjamin
>
> >
> > for (i = 0; i < 13; i++) {
> > struct surface3_ts_data_finger *finger;
> > --
> > 2.25.1
> >
>
> Thanks.
>
> --
> Dmitry
Re: [PATCH][next] drm/ttm: fix spelling mistake "swaput" -> "swapout"
Am 12.11.20 um 10:50 schrieb Colin King:
From: Colin Ian King
There is a spelling mistake in a warning message, fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e6bcbfe530ec..d32ca8734aa7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1494,7 +1494,7 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
ret = ttm_bo_handle_move_mem(bo, _mem, true, , );
if (unlikely(ret != 0)) {
- WARN(ret == -EMULTIHOP, "Unexpected multihop in swaput -
likely driver bug.\n");
+ WARN(ret == -EMULTIHOP, "Unexpected multihop in swapout -
likely driver bug.\n");
goto out;
}
}
Re: [PATCH 06/15] input: touchscreen: melfas_mip4: Remove a bunch of unused variables
On Thu, Nov 12, 2020 at 11:01:55AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/touchscreen/melfas_mip4.c: In function ‘mip4_report_touch’:
> drivers/input/touchscreen/melfas_mip4.c:474:5: warning: variable ‘size’ set
> but not used [-Wunused-but-set-variable]
> drivers/input/touchscreen/melfas_mip4.c:472:5: warning: variable
> ‘pressure_stage’ set but not used [-Wunused-but-set-variable]
> drivers/input/touchscreen/melfas_mip4.c:469:7: warning: variable ‘palm’ set
> but not used [-Wunused-but-set-variable]
> drivers/input/touchscreen/melfas_mip4.c:468:7: warning: variable ‘hover’ set
> but not used [-Wunused-but-set-variable]
>
> Cc: Sangwon Jee
> Cc: Dmitry Torokhov
> Cc: Henrik Rydberg
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/input/touchscreen/melfas_mip4.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/input/touchscreen/melfas_mip4.c
> b/drivers/input/touchscreen/melfas_mip4.c
> index f67efdd040b24..9c98759098c7a 100644
> --- a/drivers/input/touchscreen/melfas_mip4.c
> +++ b/drivers/input/touchscreen/melfas_mip4.c
> @@ -465,13 +465,9 @@ static void mip4_report_keys(struct mip4_ts *ts, u8
> *packet)
> static void mip4_report_touch(struct mip4_ts *ts, u8 *packet)
> {
> int id;
> - bool hover;
> - bool palm;
> bool state;
> u16 x, y;
> - u8 pressure_stage = 0;
> u8 pressure;
> - u8 size;
> u8 touch_major;
> u8 touch_minor;
>
> @@ -480,14 +476,11 @@ static void mip4_report_touch(struct mip4_ts *ts, u8
> *packet)
> case 1:
> /* Touch only */
> state = packet[0] & BIT(7);
> - hover = packet[0] & BIT(5);
> - palm = packet[0] & BIT(4);
No really happy that we'd be losing information about protocol. Is there
a better way to suppress the warning while keeping this info?
> id = (packet[0] & 0x0F) - 1;
> x = ((packet[1] & 0x0F) << 8) | packet[2];
> y = (((packet[1] >> 4) & 0x0F) << 8) |
> packet[3];
> pressure = packet[4];
> - size = packet[5];
> if (ts->event_format == 0) {
> touch_major = packet[5];
> touch_minor = packet[5];
> @@ -501,14 +494,10 @@ static void mip4_report_touch(struct mip4_ts *ts, u8
> *packet)
> default:
> /* Touch + Force(Pressure) */
> id = (packet[0] & 0x0F) - 1;
> - hover = packet[1] & BIT(2);
> - palm = packet[1] & BIT(1);
> state = packet[1] & BIT(0);
> x = ((packet[2] & 0x0F) << 8) | packet[3];
> y = (((packet[2] >> 4) & 0x0F) << 8) |
> packet[4];
> - size = packet[6];
> - pressure_stage = (packet[7] & 0xF0) >> 4;
> pressure = ((packet[7] & 0x0F) << 8) |
> packet[8];
> touch_major = packet[9];
> --
> 2.25.1
>
Thanks.
--
Dmitry
Re: [PATCH 08/15] input: touchscreen: surface3_spi: Remove set but unused variable 'timestamp'
On Thu, Nov 12, 2020 at 11:01:57AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/touchscreen/surface3_spi.c: In function
> ‘surface3_spi_process_touch’:
> drivers/input/touchscreen/surface3_spi.c:97:6: warning: variable ‘timestamp’
> set but not used [-Wunused-but-set-variable]
>
> Cc: Dmitry Torokhov
> Cc: Henrik Rydberg
> Cc: Benjamin Tissoires
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/input/touchscreen/surface3_spi.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/surface3_spi.c
> b/drivers/input/touchscreen/surface3_spi.c
> index ce4828b1415a8..72dc4c562a4e1 100644
> --- a/drivers/input/touchscreen/surface3_spi.c
> +++ b/drivers/input/touchscreen/surface3_spi.c
> @@ -94,9 +94,7 @@ static void surface3_spi_report_touch(struct
> surface3_ts_data *ts_data,
>
> static void surface3_spi_process_touch(struct surface3_ts_data *ts_data, u8
> *data)
> {
> - u16 timestamp;
> unsigned int i;
> - timestamp = get_unaligned_le16([15]);
Benjamin, should we pass timing data on to userspace instead?
>
> for (i = 0; i < 13; i++) {
> struct surface3_ts_data_finger *finger;
> --
> 2.25.1
>
Thanks.
--
Dmitry
[PATCH] drm/tilcdc: Remove unnecessary THIS_MODULE
As THIS_MODULE has been set in platform_driver_register(),
so remove it.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 00efc30..4235780 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -399,7 +399,6 @@ static struct platform_driver panel_driver = {
.probe = panel_probe,
.remove = panel_remove,
.driver = {
- .owner = THIS_MODULE,
.name = "tilcdc-panel",
.of_match_table = panel_of_match,
},
--
2.7.4
Re: [LKP] Re: [mm/memcg] bd0b230fe1: will-it-scale.per_process_ops -22.7% regression
On Thu, Nov 12, 2020 at 11:43:45AM -0500, Waiman Long wrote:
> >>We tried below patch to make the 'page_counter' aligned.
> >> diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
> >> index bab7e57..9efa6f7 100644
> >> --- a/include/linux/page_counter.h
> >> +++ b/include/linux/page_counter.h
> >> @@ -26,7 +26,7 @@ struct page_counter {
> >>/* legacy */
> >>unsigned long watermark;
> >>unsigned long failcnt;
> >> -};
> >> +} cacheline_internodealigned_in_smp;
> >>and with it, the -22.7% peformance change turns to a small -1.7%, which
> >>confirms the performance bump is caused by the change to data alignment.
> >>
> >>After the patch, size of 'page_counter' increases from 104 bytes to 128
> >>bytes, and the size of 'mem_cgroup' increases from 2880 bytes to 3008
> >>bytes(with our kernel config). Another major data structure which
> >>contains 'page_counter' is 'hugetlb_cgroup', whose size will change
> >>from 912B to 1024B.
> >>
> >>Should we make these page_counters aligned to reduce cacheline conflict?
> >I would rather focus on a more effective mem_cgroup layout. It is very
> >likely that we are just stumbling over two counters here.
> >
> >Could you try to add cache alignment of counters after memory and see
> >which one makes the difference? I do not expect memsw to be the one
> >because that one is used together with the main counter. But who knows
> >maybe the way it crosses the cache line has the exact effect. Hard to
> >tell without other numbers.
> >
> >Btw. it would be great to see what the effect is on cgroup v2 as well.
> >
> >Thanks for pursuing this!
>
> The contention may be in the page counters themselves or it can be in other
> fields below the page counters. The cacheline alignment will cause
> "high_work" just after the page counters to start at a cacheline boundary. I
> will try removing the cacheline alignment in the page counter and add it to
> high_work to see there is any change in performance. If there is no change,
> the performance problem will not be in the page counters.
Yes, that's a good spot to check. I even doubt it could be other members of
'struct mem_cgroup', which affects the benchmark, as we've seen some other
performance bump which is possibly related to it too.
Thanks,
Feng
Re: [PATCH] arm64: mm: account for hotplug memory when randomizing the linear region
On 11/13/20 12:36 PM, Ard Biesheuvel wrote:
> On Fri, 13 Nov 2020 at 08:03, Anshuman Khandual
> wrote:
>>
>>
>>
>> On 11/13/20 11:44 AM, Ard Biesheuvel wrote:
>>> On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual
>>> wrote:
On 11/12/20 2:55 PM, Catalin Marinas wrote:
> Hi Anshuman,
>
> On Wed, Nov 11, 2020 at 09:18:56AM +0530, Anshuman Khandual wrote:
>> On 11/11/20 12:44 AM, Catalin Marinas wrote:
>>> On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
As a hardening measure, we currently randomize the placement of
physical memory inside the linear region when KASLR is in effect.
Since the random offset at which to place the available physical
memory inside the linear region is chosen early at boot, it is
based on the memblock description of memory, which does not cover
hotplug memory. The consequence of this is that the randomization
offset may be chosen such that any hotplugged memory located above
memblock_end_of_DRAM() that appears later is pushed off the end of
the linear region, where it cannot be accessed.
[...]
>>>
>>> Applied to arm64 (for-next/mem-hotplug), thanks!
>>>
>>> [1/1] arm64: mm: account for hotplug memory when randomizing the linear
>>> region
>>> https://git.kernel.org/arm64/c/97d6786e0669
>>
>> Got delayed and never made here in time, sorry about that. Nonetheless,
>> I have got something working with respect to the generic mechanism that
>> David Hildenbrand had asked for earlier.
>>
>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/
>
> There was a lot of discussion around this patch but I haven't seen any
> new version posted.
Just posted before some time.
https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khand...@arm.com/
>>>
>>> You failed to cc me on that patch.
>>
>> I could see 'a...@kernel.org' marked as a copy on the patch. You
>> did not receive the email ? The CC list is in the commit message
>> itself. Even the lore.kernel.org based URL does list you email
>> as well. Not sure what might have happened.
>>
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: Mark Rutland
>> Cc: Ard Biesheuvel
>> Cc: Steven Price
>> Cc: Robin Murphy
>> Cc: David Hildenbrand
>> Cc: Andrew Morton
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>
> Right. Not sure what happened there, I may have deleted it by
> accident. Apologies.
>
>>>
>>> The logic looks correct but please fix up the comment block:
>>> - PAGE_END is no longer defined in terms of vabits_actual
>>> - bits [51..48] are not ignored by the MMU
>>>
>>> Actually, I think the entire second paragraph of that comment block
>>> can be dropped.
>>
>> And from the commit message as well, had reused it in both places.
>>
>>>
>>> Please also fix up the coding style:
>>> - put && at the end of the first line
>>> - drop the redundant parens
>>> - fix the indentation
>>
>> Does this look okay ?
>>
>> static bool inside_linear_region(u64 start, u64 size)
>> {
>> /*
>> * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
>> * accommodating both its ends but excluding PAGE_END. Max physical
>> * range which can be mapped inside this linear mapping range, must
>> * also be derived from its end points.
>> */
>> return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
>> (start + size - 1) <= __pa(PAGE_END - 1);
>> }
>
> Not sure whether the whitespace has been mangled by the email client,
> but the first ( on the second line should align vertically with the
> 's' of 'start' on the first line
It was not aligned vertically here but fixed it. I hope you have received
the latest version this time.
https://lore.kernel.org/linux-arm-kernel/1605252614-761-1-git-send-email-anshuman.khand...@arm.com/
Re: [PATCH 05/15] input: touchscreen: imx6ul_tsc: Remove set but unused variable 'value'
On Thu, Nov 12, 2020 at 11:01:54AM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/touchscreen/imx6ul_tsc.c: In function ‘adc_irq_fn’: > drivers/input/touchscreen/imx6ul_tsc.c:307:6: warning: variable ‘value’ set > but not used [-Wunused-but-set-variable] > > Cc: Dmitry Torokhov > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Haibo Chen > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 02/15] input: keyboard: samsung-keypad: Remove set but unused variable 'var'
On Thu, Nov 12, 2020 at 11:01:51AM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/keyboard/samsung-keypad.c: In function ‘samsung_keypad_irq’: > drivers/input/keyboard/samsung-keypad.c:149:15: warning: variable ‘val’ set > but not used [-Wunused-but-set-variable] > > Cc: Dmitry Torokhov > Cc: Joonyoung Shim > Cc: Donghwa Lee > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 07/15] input: touchscreen: usbtouchscreen: Remove unused variable 'ret'
On Thu, Nov 12, 2020 at 11:01:56AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/touchscreen/usbtouchscreen.c: In function ‘nexio_read_data’:
> drivers/input/touchscreen/usbtouchscreen.c:1052:50: warning: variable ‘ret’
> set but not used [-Wunused-but-set-variable]
>
> Cc: Dmitry Torokhov
> Cc: Henrik Rydberg
> Cc: James Hilliard
> Cc: Daniel Ritz
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/input/touchscreen/usbtouchscreen.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/usbtouchscreen.c
> b/drivers/input/touchscreen/usbtouchscreen.c
> index 397cb1d3f481b..c3b7130cd9033 100644
> --- a/drivers/input/touchscreen/usbtouchscreen.c
> +++ b/drivers/input/touchscreen/usbtouchscreen.c
> @@ -1049,7 +1049,7 @@ static int nexio_read_data(struct usbtouch_usb
> *usbtouch, unsigned char *pkt)
> unsigned int data_len = be16_to_cpu(packet->data_len);
> unsigned int x_len = be16_to_cpu(packet->x_len);
> unsigned int y_len = be16_to_cpu(packet->y_len);
> - int x, y, begin_x, begin_y, end_x, end_y, w, h, ret;
> + int x, y, begin_x, begin_y, end_x, end_y, w, h;
>
> /* got touch data? */
> if ((pkt[0] & 0xe0) != 0xe0)
> @@ -1061,7 +1061,7 @@ static int nexio_read_data(struct usbtouch_usb
> *usbtouch, unsigned char *pkt)
> x_len -= 0x80;
>
> /* send ACK */
> - ret = usb_submit_urb(priv->ack, GFP_ATOMIC);
> + usb_submit_urb(priv->ack, GFP_ATOMIC);
I wonder if we should handle potential errors instead.
>
> if (!usbtouch->type->max_xc) {
> usbtouch->type->max_xc = 2 * x_len;
> --
> 2.25.1
>
Thanks.
--
Dmitry
Re: [PATCH v4] clk: samsung: Prevent potential endless loop in the PLL set_rate ops
On Tue, Nov 10, 2020 at 08:32:26PM +0100, Sylwester Nawrocki wrote:
> The PLL status polling loops in the set_rate callbacks of some PLLs
> have no timeout detection and may become endless loops when something
> goes wrong with the PLL.
>
> For some PLLs there is already the ktime API based timeout detection,
> but it will not work in all conditions when .set_rate gets called.
> In particular, before the clocksource is initialized or when the
> timekeeping is suspended.
>
> This patch adds a common helper with the PLL status bit polling and
> timeout detection. For conditions where the timekeeping API should not
> be used a simple readl_relaxed/cpu_relax() busy loop is added with the
> iterations limit derived from measurements of readl_relaxed() execution
> time for various PLL types and Exynos SoCs variants.
>
> Actual PLL lock time depends on the P divider value, the VCO frequency
> and a constant PLL type specific LOCK_FACTOR and can be calculated as
>
> lock_time = Pdiv * LOCK_FACTOR / VCO_freq
>
> For the ktime API use cases a common timeout value of 20 ms is applied
> for all the PLLs with an assumption that maximum possible value of Pdiv
> is 64, maximum possible LOCK_FACTOR value is 3000 and minimum VCO
> frequency is 24 MHz.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> I'm not sure whether we actually need to implement precise timeouts,
> likely the simple busy loop case would be enough. AFAIK the PLL
> failures happen very rarely, mostly in early code development stage
> for given platform.
>
> Changes since v3:
> - dropped udelay() from the PLL status bit polling loop as it didn't
>work on arm64 at early boot time, before timekeeping was initialized,
> - use the timekeeping API in cases when it is already initialized and
>not suspended,
> - use samsung_pll_lock_wait() also in samsung_pll3xxx_enable() function,
>now all potential endless loops are removed.
> ---
> drivers/clk/samsung/clk-pll.c | 147
> --
> 1 file changed, 71 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index ac70ad7..cefb57e 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -8,14 +8,17 @@
>
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include "clk.h"
> #include "clk-pll.h"
>
> -#define PLL_TIMEOUT_MS 10
> +#define PLL_TIMEOUT_US 2U
> +#define PLL_TIMEOUT_LOOPS100U
>
> struct samsung_clk_pll {
> struct clk_hw hw;
> @@ -63,6 +66,53 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
> return rate_table[i - 1].rate;
> }
>
> +static bool __early_timeout = true;
Drop the __ prefix and maybe use "pll_early_timeout".
This looks like __ro_after_init.
Best regards,
Krzysztof
Re: [PATCH 00/19] [Set 2] Rid W=1 warnings from GPU
On Fri, 13 Nov 2020, Alex Deucher wrote:
> On Fri, Nov 13, 2020 at 2:19 AM Lee Jones wrote:
> >
> > On Fri, 06 Nov 2020, Lee Jones wrote:
> >
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
> > > niggly little warnings.
> > >
> > > There are 5000 warnings to work through. It will take a couple more
> > > sets. Although, ("drm/amd/display/dc/basics/fixpt31_32: Move
> > > variables to where they're used") does take care of 2000 of them!
> > >
> > > Lee Jones (19):
> > > drm/ttm/ttm_range_manager: Demote non-conformant kernel-doc header
> > > drm/r128/ati_pcigart: Source file headers are not good candidates for
> > > kernel-doc
> > > drm/selftests/test-drm_dp_mst_helper: Move
> > > 'sideband_msg_req_encode_decode' onto the heap
> > > drm/mga/mga_dma: Demote kernel-doc abusers to standard comment blocks
> > > drm/mga/mga_state: Remove unused variable 'buf_priv'
> > > drm/radeon/atom: Move prototype into shared location
> > > drm/radeon/radeon_kms: Include header containing our own prototypes
> > > drm/omapdrm/omap_gem: Fix misnamed and missing parameter descriptions
> > > drm/omapdrm/omap_dmm_tiler: Demote abusive use of kernel-doc format
> > > drm/radeon/radeon: Move prototype into shared header
> > > drm/radeon/radeon_drv: Source file headers are not good candidates for
> > > kernel-doc
> > > drm/amd/display/dc/basics/fixpt31_32: Move variables to where they're
> > > used
> > > drm/radeon/radeon_drv: Move prototypes to a shared headerfile
> > > drm/amd/amdgpu/amdgpu_device: Provide documentation for 'reg_addr'
> > > params
> > > drm/radeon: Move prototypes to shared header
> > > drm/amd/amdgpu/amdgpu_kms: Remove 'struct drm_amdgpu_info_device
> > > dev_info' from the stack
> > > drm/radeon/radeon_kms: Fix misnaming of 'radeon_info_ioctl's dev param
> > > drm/radeon/atombios_crtc: Remove description of non-existent function
> > > param 'encoder'
> > > drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'
> > >
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 104 +-
> > > .../drm/amd/display/dc/basics/fixpt31_32.c| 5 +
> > > .../gpu/drm/amd/display/include/fixed31_32.h | 6 -
> > > drivers/gpu/drm/mga/mga_dma.c | 10 +-
> > > drivers/gpu/drm/mga/mga_state.c | 2 -
> > > drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 6 +-
> > > drivers/gpu/drm/omapdrm/omap_gem.c| 3 +-
> > > drivers/gpu/drm/r128/ati_pcigart.c| 2 +-
> > > drivers/gpu/drm/radeon/atom.h | 6 +
> > > drivers/gpu/drm/radeon/atombios_crtc.c| 1 -
> > > drivers/gpu/drm/radeon/atombios_encoders.c| 4 -
> > > drivers/gpu/drm/radeon/radeon.h | 6 +
> > > drivers/gpu/drm/radeon/radeon_device.c| 1 +
> > > drivers/gpu/drm/radeon/radeon_device.h| 32 ++
> > > drivers/gpu/drm/radeon/radeon_display.c | 4 -
> > > drivers/gpu/drm/radeon/radeon_drv.c | 11 +-
> > > drivers/gpu/drm/radeon/radeon_drv.h | 7 ++
> > > drivers/gpu/drm/radeon/radeon_kms.c | 3 +-
> > > .../drm/selftests/test-drm_dp_mst_helper.c| 11 +-
> > > drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
> > > drivers/gpu/drm/v3d/v3d_drv.c | 36 --
> > > 22 files changed, 138 insertions(+), 126 deletions(-)
> > > create mode 100644 drivers/gpu/drm/radeon/radeon_device.h
> >
> > Still no Radeon patches in today's -next.
> >
> > I really wanted to have had this set rebased by now.
> >
> > How long do they take to peculate through?
>
> Usually a day or two, but I was swamped the last couple of days. I
> pushed an updated -next branch today:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next
Ah, wonderful.
I'll rebase all of the sets on Monday and see what we're left with.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [LKP] Re: [mm/memcg] bd0b230fe1: will-it-scale.per_process_ops -22.7% regression
On Thu, Nov 12, 2020 at 03:16:54PM +0100, Michal Hocko wrote:
> On Thu 12-11-20 20:28:44, Feng Tang wrote:
> > Hi Michal,
> >
> > On Wed, Nov 04, 2020 at 09:15:46AM +0100, Michal Hocko wrote:
> > > > > > Hi Michal,
> > > > > >
> > > > > > We used the default configure of cgroups, not sure what
> > > > > > configuration you
> > > > > > want,
> > > > > > could you give me more details? and here is the cgroup info of
> > > > > > will-it-scale
> > > > > > process:
> > > > > >
> > > > > > $ cat /proc/3042/cgroup
> > > > > > 12:hugetlb:/
> > > > > > 11:memory:/system.slice/lkp-bootstrap.service
> > > > >
> > > > > OK, this means that memory controler is enabled and in use. Btw. do
> > > > > you
> > > > > get the original performance if you add one phony page_counter after
> > > > > the
> > > > > union?
> > > > >
> > > > I add one phony page_counter after the union and re-test, the regression
> > > > reduced to -1.2%. It looks like the regression caused by the data
> > > > structure
> > > > layout change.
> > >
> > > Thanks for double checking. Could you try to cache align the
> > > page_counter struct? If that helps then we should figure which counters
> > > acks against each other by adding the alignement between the respective
> > > counters.
> >
> > We tried below patch to make the 'page_counter' aligned.
> >
> > diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
> > index bab7e57..9efa6f7 100644
> > --- a/include/linux/page_counter.h
> > +++ b/include/linux/page_counter.h
> > @@ -26,7 +26,7 @@ struct page_counter {
> > /* legacy */
> > unsigned long watermark;
> > unsigned long failcnt;
> > -};
> > +} cacheline_internodealigned_in_smp;
> >
> > and with it, the -22.7% peformance change turns to a small -1.7%, which
> > confirms the performance bump is caused by the change to data alignment.
> >
> > After the patch, size of 'page_counter' increases from 104 bytes to 128
> > bytes, and the size of 'mem_cgroup' increases from 2880 bytes to 3008
> > bytes(with our kernel config). Another major data structure which
> > contains 'page_counter' is 'hugetlb_cgroup', whose size will change
> > from 912B to 1024B.
> >
> > Should we make these page_counters aligned to reduce cacheline conflict?
>
> I would rather focus on a more effective mem_cgroup layout. It is very
> likely that we are just stumbling over two counters here.
>
> Could you try to add cache alignment of counters after memory and see
> which one makes the difference? I do not expect memsw to be the one
> because that one is used together with the main counter. But who knows
> maybe the way it crosses the cache line has the exact effect. Hard to
> tell without other numbers.
I added some alignments change around the 'memsw', but neither of them can
restore the -22.7%. Following are some log showing how the alignments
are:
tl: memcg=0x7cd1000 memory=0x7cd10d0 memsw=0x7cd1140 kmem=0x7cd11b0
tcpmem=0x7cd1220
t2: memcg=0x7cd memory=0x7cd00d0 memsw=0x7cd0140 kmem=0x7cd01c0
tcpmem=0x7cd0230
So both of the 'memsw' are aligned, but t2's 'kmem' is aligned while
t1's is not.
I will check more on the perf data about detailed hotspots.
Thanks,
Feng
> Btw. it would be great to see what the effect is on cgroup v2 as well.
>
> Thanks for pursuing this!
> --
> Michal Hocko
> SUSE Labs
[PATCH] macintosh: windfarm: Use NULL to compare with pointer-typed value rather than 0
Compare pointer-typed values to NULL rather than 0.
Signed-off-by: Xu Wang
---
drivers/macintosh/windfarm_pm121.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm121.c
b/drivers/macintosh/windfarm_pm121.c
index ab467b9c31be..62826844b584 100644
--- a/drivers/macintosh/windfarm_pm121.c
+++ b/drivers/macintosh/windfarm_pm121.c
@@ -650,7 +650,7 @@ static void pm121_create_cpu_fans(void)
/* First, locate the PID params in SMU SBD */
hdr = smu_get_sdb_partition(SMU_SDB_CPUPIDDATA_ID, NULL);
- if (hdr == 0) {
+ if (hdr == NULL) {
printk(KERN_WARNING "pm121: CPU PID fan config not found.\n");
goto fail;
}
@@ -969,7 +969,7 @@ static int pm121_init_pm(void)
const struct smu_sdbp_header *hdr;
hdr = smu_get_sdb_partition(SMU_SDB_SENSORTREE_ID, NULL);
- if (hdr != 0) {
+ if (hdr != NULL) {
struct smu_sdbp_sensortree *st =
(struct smu_sdbp_sensortree *)[1];
pm121_mach_model = st->model_id;
--
2.17.1
[PATCH] tracing: remove the unused value assignment in test_create_synth_event
From: Kaixu Xia
The value of variable ret is overwritten on the delete branch in the
test_create_synth_event(), so here the value assignment is useless.
Remove it.
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
---
kernel/trace/synth_event_gen_test.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/trace/synth_event_gen_test.c
b/kernel/trace/synth_event_gen_test.c
index edd912cd14aa..c76b4c189560 100644
--- a/kernel/trace/synth_event_gen_test.c
+++ b/kernel/trace/synth_event_gen_test.c
@@ -276,10 +276,8 @@ static int __init test_create_synth_event(void)
*/
create_synth_test = trace_get_event_file(NULL, "synthetic",
"create_synth_test");
- if (IS_ERR(create_synth_test)) {
- ret = PTR_ERR(create_synth_test);
+ if (IS_ERR(create_synth_test))
goto delete;
- }
/* Enable the event or you won't see anything */
ret = trace_array_set_clr_event(create_synth_test->tr,
--
2.20.0
[PATCH V3] arm64/mm: Validate hotplug range before creating linear mapping
During memory hotplug process, the linear mapping should not be created for
a given memory range if that would fall outside the maximum allowed linear
range. Else it might cause memory corruption in the kernel virtual space.
Maximum linear mapping region is [PAGE_OFFSET..(PAGE_END -1)] accommodating
both its ends but excluding PAGE_END. Max physical range that can be mapped
inside this linear mapping range, must also be derived from its end points.
This ensures that arch_add_memory() validates memory hot add range for its
potential linear mapping requirements, before creating it with
__create_pgd_mapping().
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Ard Biesheuvel
Cc: Steven Price
Cc: Robin Murphy
Cc: David Hildenbrand
Cc: Andrew Morton
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Fixes: 4ab215061554 ("arm64: Add memory hotplug support")
Signed-off-by: Anshuman Khandual
---
This applies on 5.10-rc3
Changes in V3:
- Dropped comment paragraphs from code and commit message per Ard
- Dropped parenthesis brackets in the comparison per Ard
Changes in V2:
(https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khand...@arm.com/)
- Replaced (start + size) with (start + size - 1) in the comparison per Ard
- Dropped parenthesis brackets in the comparison per Ard
Changes in V1:
(https://lore.kernel.org/linux-arm-kernel/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/)
arch/arm64/mm/mmu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 1c0f3e02f731..ca692a815731 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1444,11 +1444,28 @@ static void __remove_pgd_mapping(pgd_t *pgdir, unsigned
long start, u64 size)
free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
}
+static bool inside_linear_region(u64 start, u64 size)
+{
+ /*
+* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
+* accommodating both its ends but excluding PAGE_END. Max physical
+* range which can be mapped inside this linear mapping range, must
+* also be derived from its end points.
+*/
+ return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
+ (start + size - 1) <= __pa(PAGE_END - 1);
+}
+
int arch_add_memory(int nid, u64 start, u64 size,
struct mhp_params *params)
{
int ret, flags = 0;
+ if (!inside_linear_region(start, size)) {
+ pr_err("[%llx %llx] is outside linear mapping region\n", start,
start + size);
+ return -EINVAL;
+ }
+
if (rodata_full || debug_pagealloc_enabled())
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
--
2.20.1
RE: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver
Hi Vignesh, Thanks for your information. > -Original Message- > From: Vignesh Raghavendra > Sent: Wednesday, November 11, 2020 1:44 PM > To: Chin-Ting Kuo ; Boris Brezillon > > Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller > driver > > Hi Chin-Ting, > > On 11/6/20 11:57 PM, Chin-Ting Kuo wrote: > > Hi Boris, > > > >> -Original Message- > >> From: Boris Brezillon > >> Sent: Friday, November 6, 2020 7:30 PM > >> To: Chin-Ting Kuo > >> Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory > >> controller driver > >> > >> +Tudor and Vignesh > >> > >> On Fri, 6 Nov 2020 10:21:06 + > >> Chin-Ting Kuo wrote: > >> > >>> Hi Boris, > >>> > >>> Thanks for your comments and suggestions. > >>> > -Original Message- > From: Boris Brezillon > Sent: Friday, November 6, 2020 5:06 PM > To: Chin-Ting Kuo > Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory > controller driver > > On Fri, 6 Nov 2020 08:58:23 + > Chin-Ting Kuo wrote: > > > Hi Boris, > > > > Thanks for your quick reply. > > > >> -Original Message- > >> From: Boris Brezillon > >> Sent: Thursday, November 5, 2020 11:12 PM > >> To: Cédric Le Goater ; robh...@kernel.org > >> Cc: Chin-Ting Kuo ; > >> broo...@kernel.org; j...@jms.id.au; and...@aj.id.au; > >> bbrezil...@kernel.org; devicet...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; linux-asp...@lists.ozlabs.org; > >> linux-...@vger.kernel.org; BMC-SW > >> Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory > >> controller driver > >> > >> Hi, > >> > >> On Thu, 5 Nov 2020 15:09:11 +0100 Cédric Le Goater > >> wrote: > >> > >>> Hello Chin-Ting, > >>> > >>> Thanks for this driver. It's much cleaner than the previous and > >>> we should try adding support for the AST2500 SoC also. I guess > >>> we can keep the old driver for the AST2400 which has a > >> different register layout. > >>> > >>> On the patchset, I think we should split this patch in three : > >>> > >>> - basic support > >>> - AHB window calculation depending on the flash size > >>> - read training support > >> > >> I didn't look closely at the implementation, but if the read > >> training tries to read a section of the NOR, I'd recommend > >> exposing that feature through spi-mem and letting the SPI-NOR > >> framework trigger the training instead of doing that at dirmap > >> creation time (remember that spi-mem is also used for SPI NANDs > >> which use the dirmap > API too, and this training is unlikely to work there). > >> > >> The SPI-NOR framework could pass a read op template and a > >> reference pattern such that all the spi-mem driver has to do is > >> execute the template op and compare the output to the reference > >> buffer. > >> > > > > I agree it. Before, I were not able to find a suitable location to > > implement > read training feature. > > I think that I can add a SPI timing training function in > > "spi_controller_mem_ops" struct and call it by a wrapper function > > called at > the bottom of spi_nor_probe() in spi-nor.c. > > Maybe, SPI-NOR framework does not need to pass reference buffer > > since calibration method depends on each SoC itself and buffer > > size may be > variant. > > The detail calibration method may be implemented in each SoC SPI > >> driver. > > That's a real problem IMO. What makes this pattern SoC specific? I > can see why the location in flash could be *board* specific, but > the pattern should be pretty common, right? As for the spi-mem > operation to be executed, it's definitely memory specific (I can > imagine some flash vendors providing a specific command returning a > fixed pattern that's not actually stored on a visible portion of the > flash). > >>> > >>> You are right, the pattern should be pretty common. The thing I was > >>> worried about is the size of that buffer since, maybe, some > >>> controllers need to read more data than others in order to get good > >>> training > >> result. > >> > >> It would be good to see how other controllers implement that. I know > >> that the Cadence controller had something similar. Vignesh might be > >> able to share his thoughts on this. > > > > Cadence controllers requires to read fixed length calibration pattern multiple > times (while tuning PHY registers) from non zero address location. Pattern is > Flash independent and SoC independent. Hence, can be hard coded in driver > (no need to read at slower speed). > This method is more suitable. > > Oh, maybe, I misunderstood your meaning and I did not describe clearly > early. > > As you mentioned before, for some SPI-NOR flashes, there indeed exists > > a command used for read
Re: [PATCH 00/19] [Set 2] Rid W=1 warnings from GPU
On Fri, Nov 13, 2020 at 2:19 AM Lee Jones wrote:
>
> On Fri, 06 Nov 2020, Lee Jones wrote:
>
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > There are 5000 warnings to work through. It will take a couple more
> > sets. Although, ("drm/amd/display/dc/basics/fixpt31_32: Move
> > variables to where they're used") does take care of 2000 of them!
> >
> > Lee Jones (19):
> > drm/ttm/ttm_range_manager: Demote non-conformant kernel-doc header
> > drm/r128/ati_pcigart: Source file headers are not good candidates for
> > kernel-doc
> > drm/selftests/test-drm_dp_mst_helper: Move
> > 'sideband_msg_req_encode_decode' onto the heap
> > drm/mga/mga_dma: Demote kernel-doc abusers to standard comment blocks
> > drm/mga/mga_state: Remove unused variable 'buf_priv'
> > drm/radeon/atom: Move prototype into shared location
> > drm/radeon/radeon_kms: Include header containing our own prototypes
> > drm/omapdrm/omap_gem: Fix misnamed and missing parameter descriptions
> > drm/omapdrm/omap_dmm_tiler: Demote abusive use of kernel-doc format
> > drm/radeon/radeon: Move prototype into shared header
> > drm/radeon/radeon_drv: Source file headers are not good candidates for
> > kernel-doc
> > drm/amd/display/dc/basics/fixpt31_32: Move variables to where they're
> > used
> > drm/radeon/radeon_drv: Move prototypes to a shared headerfile
> > drm/amd/amdgpu/amdgpu_device: Provide documentation for 'reg_addr'
> > params
> > drm/radeon: Move prototypes to shared header
> > drm/amd/amdgpu/amdgpu_kms: Remove 'struct drm_amdgpu_info_device
> > dev_info' from the stack
> > drm/radeon/radeon_kms: Fix misnaming of 'radeon_info_ioctl's dev param
> > drm/radeon/atombios_crtc: Remove description of non-existent function
> > param 'encoder'
> > drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 104 +-
> > .../drm/amd/display/dc/basics/fixpt31_32.c| 5 +
> > .../gpu/drm/amd/display/include/fixed31_32.h | 6 -
> > drivers/gpu/drm/mga/mga_dma.c | 10 +-
> > drivers/gpu/drm/mga/mga_state.c | 2 -
> > drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 6 +-
> > drivers/gpu/drm/omapdrm/omap_gem.c| 3 +-
> > drivers/gpu/drm/r128/ati_pcigart.c| 2 +-
> > drivers/gpu/drm/radeon/atom.h | 6 +
> > drivers/gpu/drm/radeon/atombios_crtc.c| 1 -
> > drivers/gpu/drm/radeon/atombios_encoders.c| 4 -
> > drivers/gpu/drm/radeon/radeon.h | 6 +
> > drivers/gpu/drm/radeon/radeon_device.c| 1 +
> > drivers/gpu/drm/radeon/radeon_device.h| 32 ++
> > drivers/gpu/drm/radeon/radeon_display.c | 4 -
> > drivers/gpu/drm/radeon/radeon_drv.c | 11 +-
> > drivers/gpu/drm/radeon/radeon_drv.h | 7 ++
> > drivers/gpu/drm/radeon/radeon_kms.c | 3 +-
> > .../drm/selftests/test-drm_dp_mst_helper.c| 11 +-
> > drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
> > drivers/gpu/drm/v3d/v3d_drv.c | 36 --
> > 22 files changed, 138 insertions(+), 126 deletions(-)
> > create mode 100644 drivers/gpu/drm/radeon/radeon_device.h
>
> Still no Radeon patches in today's -next.
>
> I really wanted to have had this set rebased by now.
>
> How long do they take to peculate through?
Usually a day or two, but I was swamped the last couple of days. I
pushed an updated -next branch today:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next
Alex
>
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Smack: fix kernel-doc interface on functions
The are some kernel-doc interface issues:
security/smack/smackfs.c:1950: warning: Function parameter or member
'list' not described in 'smk_parse_label_list'
security/smack/smackfs.c:1950: warning: Excess function parameter
'private' description in 'smk_parse_label_list'
security/smack/smackfs.c:1979: warning: Function parameter or member
'list' not described in 'smk_destroy_label_list'
security/smack/smackfs.c:1979: warning: Excess function parameter 'head'
description in 'smk_destroy_label_list'
security/smack/smackfs.c:2141: warning: Function parameter or member
'count' not described in 'smk_read_logging'
security/smack/smackfs.c:2141: warning: Excess function parameter 'cn'
description in 'smk_read_logging'
security/smack/smackfs.c:2278: warning: Function parameter or member
'format' not described in 'smk_user_access'
Correct them in this patch.
Signed-off-by: Alex Shi
Cc: Casey Schaufler
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
security/smack/smackfs.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index e567b4baf3a0..5d44b7d258ef 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -1942,7 +1942,7 @@ static void smk_list_swap_rcu(struct list_head *public,
* smk_parse_label_list - parse list of Smack labels, separated by spaces
*
* @data: the string to parse
- * @private: destination list
+ * @list: destination list
*
* Returns zero on success or error code, as appropriate
*/
@@ -1973,7 +1973,7 @@ static int smk_parse_label_list(char *data, struct
list_head *list)
/**
* smk_destroy_label_list - destroy a list of smack_known_list_elem
- * @head: header pointer of the list to destroy
+ * @list: header pointer of the list to destroy
*/
void smk_destroy_label_list(struct list_head *list)
{
@@ -2131,7 +2131,7 @@ static const struct file_operations smk_unconfined_ops = {
* smk_read_logging - read() for /smack/logging
* @filp: file pointer, not actually used
* @buf: where to put the result
- * @cn: maximum to send along
+ * @count: maximum to send along
* @ppos: where to start
*
* Returns number of bytes read or error code, as appropriate
@@ -2272,6 +2272,7 @@ static const struct file_operations smk_load_self_ops = {
* @buf: data from user space
* @count: bytes sent
* @ppos: where to start - must be 0
+ * @format: /smack/load or /smack/load2 or /smack/change-rule format.
*/
static ssize_t smk_user_access(struct file *file, const char __user *buf,
size_t count, loff_t *ppos, int format)
--
2.29.GIT
Re: [PATCH v4 01/11] firmware: raspberrypi: Keep count of all consumers
On Thu, Nov 12, 2020 at 07:52:14PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 12, 2020 at 6:40 PM Nicolas Saenz Julienne
> wrote:
> >
> > When unbinding the firmware device we need to make sure it has no
> > consumers left. Otherwise we'd leave them with a firmware handle
> > pointing at freed memory.
> >
> > Keep a reference count of all consumers and introduce rpi_firmware_put()
> > which will permit automatically decrease the reference count upon
> > unbinding consumer drivers.
>
> ...
>
> > /**
> > - * rpi_firmware_get - Get pointer to rpi_firmware structure.
> > * @firmware_node:Pointer to the firmware Device Tree node.
> > *
> > + * The reference to rpi_firmware has to be released with
> > rpi_firmware_put().
> > + *
> > * Returns NULL is the firmware device is not ready.
> > */
> > struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
> > {
> > struct platform_device *pdev =
> > of_find_device_by_node(firmware_node);
> > + struct rpi_firmware *fw;
> >
> > if (!pdev)
> > return NULL;
> >
> > - return platform_get_drvdata(pdev);
> > + fw = platform_get_drvdata(pdev);
> > + if (!fw)
> > + return NULL;
> > +
> > + if (!kref_get_unless_zero(>consumers))
> > + return NULL;
>
> Don't we have a more traditional way of doing this, i.e.
> try_module_get() coupled with get_device() ?
get_device() will make sure that device is there, but gives no
assurances that device is bound to a driver, so it will not help with
the racy access to firmware via platform_get_drvdata() call.
Thanks.
--
Dmitry
Re: [PATCH v2 2/4] docs: hwmon: (ltc2945): change type of val to ULL in ltc2945_val_to_reg()
Hi Alexandru,
I love your patch! Yet something to improve:
[auto build test ERROR on hwmon/hwmon-next]
[also build test ERROR on v5.10-rc3 next-20201112]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Alexandru-Ardelean/hwmon-ltc2945-add-support-for-sense-resistor/2020-171129
base:
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-next
config: powerpc64-randconfig-r005-2020 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
874b0a0b9db93f5d3350ffe6b5efda2d908415d0)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
#
https://github.com/0day-ci/linux/commit/4e0e9315df2733ae5efe6095c5ab9b7675d07fb0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Alexandru-Ardelean/hwmon-ltc2945-add-support-for-sense-resistor/2020-171129
git checkout 4e0e9315df2733ae5efe6095c5ab9b7675d07fb0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/hwmon/ltc2945.c:256:26: error: incompatible pointer types passing
>> 'unsigned long long *' to parameter of type 'unsigned long *'
>> [-Werror,-Wincompatible-pointer-types]
ret = kstrtoul(buf, 10, );
^~~~
include/linux/kernel.h:351:90: note: passing argument to parameter 'res' here
static inline int __must_check kstrtoul(const char *s, unsigned int base,
unsigned long *res)
^
1 error generated.
vim +256 drivers/hwmon/ltc2945.c
6700ce035f8301 Guenter Roeck 2014-01-11 241
5614e26d84a99a Guenter Roeck 2018-12-06 242 static ssize_t
ltc2945_value_store(struct device *dev,
6700ce035f8301 Guenter Roeck 2014-01-11 243
struct device_attribute *da,
6700ce035f8301 Guenter Roeck 2014-01-11 244
const char *buf, size_t count)
6700ce035f8301 Guenter Roeck 2014-01-11 245 {
6700ce035f8301 Guenter Roeck 2014-01-11 246 struct
sensor_device_attribute *attr = to_sensor_dev_attr(da);
c159257a60302f Alexandru Ardelean 2020-11-11 247 struct ltc2945_state
*st = dev_get_drvdata(dev);
c159257a60302f Alexandru Ardelean 2020-11-11 248 struct regmap *regmap =
st->regmap;
6700ce035f8301 Guenter Roeck 2014-01-11 249 u8 reg = attr->index;
4e0e9315df2733 Alexandru Ardelean 2020-11-11 250 unsigned long long val;
6700ce035f8301 Guenter Roeck 2014-01-11 251 u8 regbuf[3];
6700ce035f8301 Guenter Roeck 2014-01-11 252 int num_regs;
6700ce035f8301 Guenter Roeck 2014-01-11 253 int regval;
6700ce035f8301 Guenter Roeck 2014-01-11 254 int ret;
6700ce035f8301 Guenter Roeck 2014-01-11 255
6700ce035f8301 Guenter Roeck 2014-01-11 @256 ret = kstrtoul(buf, 10,
);
6700ce035f8301 Guenter Roeck 2014-01-11 257 if (ret)
6700ce035f8301 Guenter Roeck 2014-01-11 258 return ret;
6700ce035f8301 Guenter Roeck 2014-01-11 259
6700ce035f8301 Guenter Roeck 2014-01-11 260 /* convert to register
value, then clamp and write result */
6700ce035f8301 Guenter Roeck 2014-01-11 261 regval =
ltc2945_val_to_reg(dev, reg, val);
6700ce035f8301 Guenter Roeck 2014-01-11 262 if (is_power_reg(reg)) {
6700ce035f8301 Guenter Roeck 2014-01-11 263 regval =
clamp_val(regval, 0, 0xff);
6700ce035f8301 Guenter Roeck 2014-01-11 264 regbuf[0] =
regval >> 16;
6700ce035f8301 Guenter Roeck 2014-01-11 265 regbuf[1] =
(regval >> 8) & 0xff;
6700ce035f8301 Guenter Roeck 2014-01-11 266 regbuf[2] =
regval;
6700ce035f8301 Guenter Roeck 2014-01-11 267 num_regs = 3;
6700ce035f8301 Guenter Roeck 2014-01-11 268 } else {
6700ce035f8301 Guenter Roeck 2014-01-11 269 regval =
clamp_val(regval, 0, 0xfff) << 4;
6700ce035f8301 Guenter Roeck 2014-01-11 270 regbuf[0] =
regval >> 8;
6700ce035f8301 Guenter Roeck 2014-01-11 271 regbuf[1] =
regval & 0xff;
6700ce035f8301 Guenter Roeck 2014-01-11
[PATCH] gcov: fix kernel-doc markup issue
Fix the following kernel-doc issue in gcov:
kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'dst'
not described in 'gcov_info_add'
kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'src'
not described in 'gcov_info_add'
kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'dest'
description in 'gcov_info_add'
kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'source'
description in 'gcov_info_add'
Signed-off-by: Alex Shi
Cc: Peter Oberparleiter
Cc: linux-kernel@vger.kernel.org
---
kernel/gcov/gcc_4_7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index 53c67c87f141..789c2a8ba801 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -229,10 +229,10 @@ int gcov_info_is_compatible(struct gcov_info *info1,
struct gcov_info *info2)
/**
* gcov_info_add - add up profiling data
- * @dest: profiling data set to which data is added
- * @source: profiling data set which is added
+ * @dst: profiling data set to which data is added
+ * @src: profiling data set which is added
*
- * Adds profiling counts of @source to @dest.
+ * Adds profiling counts of @src to @dst.
*/
void gcov_info_add(struct gcov_info *dst, struct gcov_info *src)
{
--
2.29.GIT
[PATCH 4/6] timekeeping: remove static functions from kernel-doc markup
There are couple of functions are 'static' without correct kernel-doc marks. Since they are not likely be used by others, moving them out of kernel-doc is better. Signed-off-by: Alex Shi Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: linux-kernel@vger.kernel.org --- kernel/time/timekeeping.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 9db6aee48c52..9bee13d94d70 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1403,7 +1403,7 @@ void timekeeping_warp_clock(void) } } -/** +/* * __timekeeping_set_tai_offset - Sets the TAI offset from UTC and monotonic * */ @@ -1413,7 +1413,7 @@ static void __timekeeping_set_tai_offset(struct timekeeper *tk, s32 tai_offset) tk->offs_tai = ktime_add(tk->offs_real, ktime_set(tai_offset, 0)); } -/** +/* * change_clocksource - Swaps clocksources if a new one is available * * Accumulates current time interval and initializes new clocksource @@ -2011,7 +2011,7 @@ static void timekeeping_adjust(struct timekeeper *tk, s64 offset) } } -/** +/* * accumulate_nsecs_to_secs - Accumulates nsecs into secs * * Helper function that accumulates the nsecs greater than a second @@ -2059,7 +2059,7 @@ static inline unsigned int accumulate_nsecs_to_secs(struct timekeeper *tk) return clock_set; } -/** +/* * logarithmic_accumulation - shifted accumulation of cycles * * This functions accumulates a shifted interval of cycles into @@ -2295,7 +2295,7 @@ ktime_t ktime_get_update_offsets_now(unsigned int *cwsseq, ktime_t *offs_real, return base; } -/** +/* * timekeeping_validate_timex - Ensures the timex is ok for use in do_adjtimex */ static int timekeeping_validate_timex(const struct __kernel_timex *txc) -- 2.29.GIT
[PATCH 1/6] time: fix kernel-doc markup
The kernel-doc interface error cause some warning:
kernel/time/timeconv.c:79: warning: Function parameter or member
'totalsecs' not described in 'time64_to_tm'
kernel/time/timeconv.c:79: warning: Function parameter or member
'offset' not described in 'time64_to_tm'
kernel/time/timeconv.c:79: warning: Function parameter or member
'result' not described in 'time64_to_tm'
Fix them.
Signed-off-by: Alex Shi
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: linux-kernel@vger.kernel.org
---
kernel/time/timeconv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/time/timeconv.c b/kernel/time/timeconv.c
index 589e0a552129..62e3b46717a6 100644
--- a/kernel/time/timeconv.c
+++ b/kernel/time/timeconv.c
@@ -70,10 +70,10 @@ static const unsigned short __mon_yday[2][13] = {
/**
* time64_to_tm - converts the calendar time to local broken-down time
*
- * @totalsecs the number of seconds elapsed since 00:00:00 on January 1, 1970,
+ * @totalsecs: the number of seconds elapsed since 00:00:00 on January 1, 1970,
* Coordinated Universal Time (UTC).
- * @offset offset seconds adding to totalsecs.
- * @result pointer to struct tm variable to receive broken-down time
+ * @offset:offset seconds adding to totalsecs.
+ * @result:pointer to struct tm variable to receive broken-down time
*/
void time64_to_tm(time64_t totalsecs, int offset, struct tm *result)
{
--
2.29.GIT
[PATCH 6/6] timekeeping: fix kernel-doc mark issue on read_persistent_clock64
Fix the kernel-doc markup: kernel/time/timekeeping.c:1563: warning: Function parameter or member 'wall_time' not described in 'read_persistent_wall_and_boot_offset' kernel/time/timekeeping.c:1563: warning: Function parameter or member 'boot_offset' not described in 'read_persistent_wall_and_boot_offset' Signed-off-by: Alex Shi Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: linux-kernel@vger.kernel.org --- kernel/time/timekeeping.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 08ab749a76fc..665e820bb883 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1556,8 +1556,9 @@ void __weak read_persistent_clock64(struct timespec64 *ts) *from the boot. * * Weak dummy function for arches that do not yet support it. - * wall_time - current time as returned by persistent clock - * boot_offset - offset that is defined as wall_time - boot_time + * @wall_time: - current time as returned by persistent clock + * @boot_offset: - offset that is defined as wall_time - boot_time + * * The default function calculates offset based on the current value of * local_clock(). This way architectures that support sched_clock() but don't * support dedicated boot time clock will provide the best estimate of the -- 2.29.GIT
[PATCH 3/6] timekeeping: add kernel-doc markup for pvclock notifier
Add the missed parameter explaination for kernel-doc markup to remove
warning:
kernel/time/timekeeping.c:651: warning: Function parameter or member
'nb' not described in 'pvclock_gtod_register_notifier'
kernel/time/timekeeping.c:670: warning: Function parameter or member
'nb' not described in 'pvclock_gtod_unregister_notifier'
Signed-off-by: Alex Shi
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: linux-kernel@vger.kernel.org
---
kernel/time/timekeeping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d0f7cd1b8823..9db6aee48c52 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -648,6 +648,7 @@ static void update_pvclock_gtod(struct timekeeper *tk, bool
was_set)
/**
* pvclock_gtod_register_notifier - register a pvclock timedata update listener
+ * @nb: a notifier entry which register on pvclock_gtod_chain.
*/
int pvclock_gtod_register_notifier(struct notifier_block *nb)
{
@@ -667,6 +668,7 @@ EXPORT_SYMBOL_GPL(pvclock_gtod_register_notifier);
/**
* pvclock_gtod_unregister_notifier - unregister a pvclock
* timedata update listener
+ * @nb: a notifier entry which unregister on pvclock_gtod_chain.
*/
int pvclock_gtod_unregister_notifier(struct notifier_block *nb)
{
--
2.29.GIT
[PATCH 5/6] timekeeping: add ts/tk explaination for kernel-doc
this patch fixed kernel-doc mark incorrection: kernel/time/timekeeping.c:1543: warning: Function parameter or member 'ts' not described in 'read_persistent_clock64' kernel/time/timekeeping.c:764: warning: Function parameter or member 'tk' not described in 'timekeeping_forward_now' kernel/time/timekeeping.c:1331: warning: Function parameter or member 'ts' not described in 'timekeeping_inject_offset' kernel/time/timekeeping.c:1331: warning: Excess function parameter 'tv' description in 'timekeeping_inject_offset' Signed-off-by: Alex Shi Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: linux-kernel@vger.kernel.org --- kernel/time/timekeeping.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 9bee13d94d70..08ab749a76fc 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -759,6 +759,7 @@ static void timekeeping_update(struct timekeeper *tk, unsigned int action) /** * timekeeping_forward_now - update clock to the current time + * @tk: pointer to time clock which will be correct. * * Forward the current clock to update its state since the last call to * update_wall_time(). This is useful before significant clock changes, @@ -1327,7 +1328,7 @@ EXPORT_SYMBOL(do_settimeofday64); /** * timekeeping_inject_offset - Adds or subtracts from the current time. - * @tv:pointer to the timespec variable containing the offset + * @ts:pointer to the timespec variable containing the offset * * Adds or subtracts an offset value from the current time. */ @@ -1536,6 +1537,7 @@ u64 timekeeping_max_deferment(void) /** * read_persistent_clock64 - Return time from the persistent clock. + * @ts: pointer to timespec to initialize. * * Weak dummy function for arches that do not yet support it. * Reads the time from the battery backed persistent clock. @@ -1640,6 +1642,7 @@ static struct timespec64 timekeeping_suspend_time; /** * __timekeeping_inject_sleeptime - Internal function to add sleep interval + * @tk: pointer to a timekeeper to be updated * @delta: pointer to a timespec delta value * * Takes a timespec offset measuring a suspend interval and properly -- 2.29.GIT
[PATCH 2/6] timekeeping: add missed kernel-doc marks for 'tkf'
Fix the kernel-doc markup and remove the following warning: kernel/time/timekeeping.c:415: warning: Function parameter or member 'tkf' not described in 'update_fast_timekeeper' kernel/time/timekeeping.c:464: warning: Function parameter or member 'tkf' not described in '__ktime_get_fast_ns' Signed-off-by: Alex Shi Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: linux-kernel@vger.kernel.org --- kernel/time/timekeeping.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index daa0ff017819..d0f7cd1b8823 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -399,6 +399,7 @@ static inline u64 timekeeping_cycles_to_ns(const struct tk_read_base *tkr, u64 c /** * update_fast_timekeeper - Update the fast and NMI safe monotonic timekeeper. * @tkr: Timekeeping readout base from which we take the update + * @tkf: NMI safe timekeeper * * We want to use this from any context including NMI and tracing / * instrumenting the timekeeping code itself. @@ -430,6 +431,7 @@ static void update_fast_timekeeper(const struct tk_read_base *tkr, /** * ktime_get_mono_fast_ns - Fast NMI safe access to clock monotonic + * @tkf: NMI safe timekeeper * * This timestamp is not guaranteed to be monotonic across an update. * The timestamp is calculated by: -- 2.29.GIT
linux-next: Signed-off-by missing for commit in the crypto tree
Hi all,
Commit
50d7e084c48d ("crypto: hisilicon/hpre - add initial settings adapt to
'Kunpeng 930'")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpivFRefcauo.pgp
Description: OpenPGP digital signature
general protection fault in tomoyo_socket_sendmsg_permission
Hello, syzbot found the following issue on: HEAD commit:9dbc1c03 Merge tag 'xfs-5.10-fixes-3' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1045303450 kernel config: https://syzkaller.appspot.com/x/.config?x=1735b7978b1c3721 dashboard link: https://syzkaller.appspot.com/bug?extid=95ce4b142579611ef0a9 compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+95ce4b142579611ef...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc03: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0018-0x001f] CPU: 0 PID: 23364 Comm: vhci_tx Not tainted 5.10.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tomoyo_socket_sendmsg_permission+0x80/0x340 security/tomoyo/network.c:762 Code: c7 40 0c f3 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 a0 00 00 00 31 c0 e8 0b 70 f1 fd 48 8d 7d 18 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 0f 85 7d 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c RSP: 0018:c90016f77ad0 EFLAGS: 00010206 RAX: 0003 RBX: 192002deef5b RCX: 83b3789e RDX: 8880186c8000 RSI: 837e9945 RDI: 0018 RBP: R08: 0030 R09: c90016f77d97 R10: R11: R12: dc00 R13: c90016f77ce8 R14: c90016f77ce8 R15: FS: () GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 562623b70868 CR3: 2af19000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: security_socket_sendmsg+0x50/0xb0 security/security.c:2140 sock_sendmsg+0x3f/0x120 net/socket.c:668 vhci_send_cmd_submit+0x897/0xf90 drivers/usb/usbip/vhci_tx.c:139 vhci_tx_loop+0xfc/0x370 drivers/usb/usbip/vhci_tx.c:241 kthread+0x3af/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Modules linked in: ---[ end trace 535369ec3e6ef304 ]--- RIP: 0010:tomoyo_socket_sendmsg_permission+0x80/0x340 security/tomoyo/network.c:762 Code: c7 40 0c f3 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 a0 00 00 00 31 c0 e8 0b 70 f1 fd 48 8d 7d 18 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 0f 85 7d 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c RSP: 0018:c90016f77ad0 EFLAGS: 00010206 RAX: 0003 RBX: 192002deef5b RCX: 83b3789e RDX: 8880186c8000 RSI: 837e9945 RDI: 0018 RBP: R08: 0030 R09: c90016f77d97 R10: R11: R12: dc00 R13: c90016f77ce8 R14: c90016f77ce8 R15: FS: () GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f0c3a930740 CR3: 2af19000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH] media: cx88: use ARRAY_SIZE
Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element
Signed-off-by: Xu Wang
---
drivers/media/pci/cx88/cx88-mpeg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-mpeg.c
b/drivers/media/pci/cx88/cx88-mpeg.c
index a57c991b165b..a3edb548afde 100644
--- a/drivers/media/pci/cx88/cx88-mpeg.c
+++ b/drivers/media/pci/cx88/cx88-mpeg.c
@@ -524,8 +524,7 @@ static int cx8802_request_acquire(struct cx8802_driver *drv)
core->last_analog_input = core->input;
core->input = 0;
for (i = 0;
-i < (sizeof(core->board.input) /
- sizeof(struct cx88_input));
+i < ARRAY_SIZE(core->board.input);
i++) {
if (core->board.input[i].type == CX88_VMUX_DVB) {
core->input = i;
--
2.17.1
Re: iommu/vt-d: Cure VF irqdomain hickup
Hi Thomas,
On 2020/11/13 3:15, Thomas Gleixner wrote:
The recent changes to store the MSI irqdomain pointer in struct device
missed that Intel DMAR does not register virtual function devices. Due to
that a VF device gets the plain PCI-MSI domain assigned and then issues
compat MSI messages which get caught by the interrupt remapping unit.
Cure that by inheriting the irq domain from the physical function
device.
That's a temporary workaround. The correct fix is to inherit the irq domain
from the bus, but that's a larger effort which needs quite some other
changes to the way how x86 manages PCI and MSI domains.
Fixes: 85a8dfc57a0b ("iommm/vt-d: Store irq domain in struct device")
Reported-by: Jason Gunthorpe
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/dmar.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -333,6 +333,11 @@ static void dmar_pci_bus_del_dev(struct
dmar_iommu_notify_scope_dev(info);
}
+static inline void vf_inherit_msi_domain(struct pci_dev *pdev)
+{
+ dev_set_msi_domain(>dev, dev_get_msi_domain(>physfn->dev));
+}
+
static int dmar_pci_bus_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -342,8 +347,20 @@ static int dmar_pci_bus_notifier(struct
/* Only care about add/remove events for physical functions.
* For VFs we actually do the lookup based on the corresponding
* PF in device_to_iommu() anyway. */
- if (pdev->is_virtfn)
+ if (pdev->is_virtfn) {
+ /*
+* Note: This is a horrible hack and needs to be cleaned
+* up by assigning the domain to the bus, but that's too
+* big of a change for post rc3.
+*
+* Ensure that the VF device inherits the irq domain of the
+* PF device:
+*/
+ if (action == BUS_NOTIFY_ADD_DEVICE)
+ vf_inherit_msi_domain(pdev);
return NOTIFY_DONE;
+ }
+
if (action != BUS_NOTIFY_ADD_DEVICE &&
action != BUS_NOTIFY_REMOVED_DEVICE)
return NOTIFY_DONE;
We also encountered this problem in internal testing. This patch can
solve the problem.
Acked-by: Lu Baolu
Best regards,
baolu
Re: [PATCH 00/19] [Set 2] Rid W=1 warnings from GPU
On Fri, 06 Nov 2020, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There are 5000 warnings to work through. It will take a couple more
> sets. Although, ("drm/amd/display/dc/basics/fixpt31_32: Move
> variables to where they're used") does take care of 2000 of them!
>
> Lee Jones (19):
> drm/ttm/ttm_range_manager: Demote non-conformant kernel-doc header
> drm/r128/ati_pcigart: Source file headers are not good candidates for
> kernel-doc
> drm/selftests/test-drm_dp_mst_helper: Move
> 'sideband_msg_req_encode_decode' onto the heap
> drm/mga/mga_dma: Demote kernel-doc abusers to standard comment blocks
> drm/mga/mga_state: Remove unused variable 'buf_priv'
> drm/radeon/atom: Move prototype into shared location
> drm/radeon/radeon_kms: Include header containing our own prototypes
> drm/omapdrm/omap_gem: Fix misnamed and missing parameter descriptions
> drm/omapdrm/omap_dmm_tiler: Demote abusive use of kernel-doc format
> drm/radeon/radeon: Move prototype into shared header
> drm/radeon/radeon_drv: Source file headers are not good candidates for
> kernel-doc
> drm/amd/display/dc/basics/fixpt31_32: Move variables to where they're
> used
> drm/radeon/radeon_drv: Move prototypes to a shared headerfile
> drm/amd/amdgpu/amdgpu_device: Provide documentation for 'reg_addr'
> params
> drm/radeon: Move prototypes to shared header
> drm/amd/amdgpu/amdgpu_kms: Remove 'struct drm_amdgpu_info_device
> dev_info' from the stack
> drm/radeon/radeon_kms: Fix misnaming of 'radeon_info_ioctl's dev param
> drm/radeon/atombios_crtc: Remove description of non-existent function
> param 'encoder'
> drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 104 +-
> .../drm/amd/display/dc/basics/fixpt31_32.c| 5 +
> .../gpu/drm/amd/display/include/fixed31_32.h | 6 -
> drivers/gpu/drm/mga/mga_dma.c | 10 +-
> drivers/gpu/drm/mga/mga_state.c | 2 -
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 6 +-
> drivers/gpu/drm/omapdrm/omap_gem.c| 3 +-
> drivers/gpu/drm/r128/ati_pcigart.c| 2 +-
> drivers/gpu/drm/radeon/atom.h | 6 +
> drivers/gpu/drm/radeon/atombios_crtc.c| 1 -
> drivers/gpu/drm/radeon/atombios_encoders.c| 4 -
> drivers/gpu/drm/radeon/radeon.h | 6 +
> drivers/gpu/drm/radeon/radeon_device.c| 1 +
> drivers/gpu/drm/radeon/radeon_device.h| 32 ++
> drivers/gpu/drm/radeon/radeon_display.c | 4 -
> drivers/gpu/drm/radeon/radeon_drv.c | 11 +-
> drivers/gpu/drm/radeon/radeon_drv.h | 7 ++
> drivers/gpu/drm/radeon/radeon_kms.c | 3 +-
> .../drm/selftests/test-drm_dp_mst_helper.c| 11 +-
> drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
> drivers/gpu/drm/v3d/v3d_drv.c | 36 --
> 22 files changed, 138 insertions(+), 126 deletions(-)
> create mode 100644 drivers/gpu/drm/radeon/radeon_device.h
Still no Radeon patches in today's -next.
I really wanted to have had this set rebased by now.
How long do they take to peculate through?
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH net-next RFC v2] MAINTAINERS: Add Martin Schiller as a maintainer for the X.25 stack
Martin Schiller is an active developer and reviewer for the X.25 code. His company is providing products based on the Linux X.25 stack. So he is a good candidate for maintainers of the X.25 code. The original maintainer of the X.25 network layer (Andrew Hendry) has not sent any email to the netdev mail list since 2013. So he is probably inactive now. Cc: Martin Schiller Cc: Andrew Hendry Signed-off-by: Xie He --- MAINTAINERS | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2a0fde12b650..5adb78cb0d92 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9832,13 +9832,6 @@ S: Maintained F: arch/mips/lantiq F: drivers/soc/lantiq -LAPB module -L: linux-...@vger.kernel.org -S: Orphan -F: Documentation/networking/lapb-module.rst -F: include/*/lapb.h -F: net/lapb/ - LASI 53c700 driver for PARISC M: "James E.J. Bottomley" L: linux-s...@vger.kernel.org @@ -18979,12 +18972,18 @@ L:linux-kernel@vger.kernel.org S: Maintained N: axp[128] -X.25 NETWORK LAYER -M: Andrew Hendry +X.25 STACK +M: Martin Schiller L: linux-...@vger.kernel.org -S: Odd Fixes +S: Maintained +F: Documentation/networking/lapb-module.rst F: Documentation/networking/x25* +F: drivers/net/wan/hdlc_x25.c +F: drivers/net/wan/lapbether.c +F: include/*/lapb.h F: include/net/x25* +F: include/uapi/linux/x25.h +F: net/lapb/ F: net/x25/ X86 ARCHITECTURE (32-BIT AND 64-BIT) -- 2.27.0
Re: [PATCH 11/25] soc: fsl: qe: qe_common: Fix misnamed function attribute 'addr'
On Thu, 12 Nov 2020, Leo Li wrote:
>
>
> > -Original Message-
> > From: Lee Jones
> > Sent: Thursday, November 12, 2020 4:33 AM
> > To: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > Qiang Zhao ; Leo Li ; Scott
> > Wood ; act ; Dan Malek
> > ; Software, Inc ; Vitaly
> > Bordug ; linuxppc-...@lists.ozlabs.org
> > Subject: Re: [PATCH 11/25] soc: fsl: qe: qe_common: Fix misnamed function
> > attribute 'addr'
> >
> > On Tue, 03 Nov 2020, Lee Jones wrote:
> >
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/soc/fsl/qe/qe_common.c:237: warning: Function parameter or
> > member 'addr' not described in 'cpm_muram_dma'
> > > drivers/soc/fsl/qe/qe_common.c:237: warning: Excess function parameter
> > 'offset' description in 'cpm_muram_dma'
> > >
> > > Cc: Qiang Zhao
> > > Cc: Li Yang
> > > Cc: Scott Wood
> > > Cc: act
> > > Cc: Dan Malek
> > > Cc: "Software, Inc"
> > > Cc: Vitaly Bordug
> > > Cc: linuxppc-...@lists.ozlabs.org
> > > Signed-off-by: Lee Jones
> > > ---
> > > drivers/soc/fsl/qe/qe_common.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/soc/fsl/qe/qe_common.c
> > > b/drivers/soc/fsl/qe/qe_common.c index 75075591f6308..497a7e0fd0272
> > > 100644
> > > --- a/drivers/soc/fsl/qe/qe_common.c
> > > +++ b/drivers/soc/fsl/qe/qe_common.c
> > > @@ -231,7 +231,7 @@ EXPORT_SYMBOL(cpm_muram_offset);
> > >
> > > /**
> > > * cpm_muram_dma - turn a muram virtual address into a DMA address
> > > - * @offset: virtual address from cpm_muram_addr() to convert
> > > + * @addr: virtual address from cpm_muram_addr() to convert
> > > */
> > > dma_addr_t cpm_muram_dma(void __iomem *addr) {
> >
> > Any idea who will pick this up?
>
> I can pick them up through my tree, but I haven't created the
> for-next branch for the next kernel yet. Will look through this
> series soon. Thanks.
Thank you Leo.
There's not rush. Just trying to ensure they don't get forgotten.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [Fonts] 9522750c66: fio.read_iops 7.5% improvement
On Fri, 13 Nov 2020, Greg Kroah-Hartman wrote:
> On Thu, Nov 12, 2020 at 10:06:25PM +0800, kernel test robot wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a 7.5% improvement of fio.read_iops due to commit:
> >
> >
> > commit: 9522750c66c689b739e151fcdf895420dc81efc0 ("Fonts: Replace discarded
> > const qualifier")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> I strongly doubt this :)
Ahh, I was going to put it on my CV (resume). ;)
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] net: dsa: sja1105: Fix return value check in sja1105_ptp_clock_register()
On Thu Nov 12 2020, YueHaibing wrote:
> drivers/net/dsa/sja1105/sja1105_ptp.c:869 sja1105_ptp_clock_register() warn:
> passing zero to 'PTR_ERR'
>
> ptp_clock_register() returns ERR_PTR() and never returns
> NULL. The NULL test should be removed.
Which is not true. From the documentation:
* Returns a valid pointer on success or PTR_ERR on failure. If PHC
* support is missing at the configuration level, this function
* returns NULL, and drivers are expected to gracefully handle that
* case separately.
Please, always Cc Richard for PTP patches.
Actually you can have a look at this discussion here:
https://lkml.kernel.org/netdev/1605086686-5140-1-git-send-email-wangq...@vivo.com/
>
> Fixes: bb77f36ac21d ("net: dsa: sja1105: Add support for the PTP clock")
> Signed-off-by: YueHaibing
> ---
> drivers/net/dsa/sja1105/sja1105_ptp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/sja1105/sja1105_ptp.c
> b/drivers/net/dsa/sja1105/sja1105_ptp.c
> index 1b90570b257b..1e41d491c854 100644
> --- a/drivers/net/dsa/sja1105/sja1105_ptp.c
> +++ b/drivers/net/dsa/sja1105/sja1105_ptp.c
> @@ -865,7 +865,7 @@ int sja1105_ptp_clock_register(struct dsa_switch *ds)
> spin_lock_init(_data->meta_lock);
>
> ptp_data->clock = ptp_clock_register(_data->caps, ds->dev);
> - if (IS_ERR_OR_NULL(ptp_data->clock))
> + if (IS_ERR(ptp_data->clock))
When you do this, you'll have to make sure that the driver handles the
NULL case "gracefully".
Thanks,
Kurt
signature.asc
Description: PGP signature
linux-next: Tree for Nov 13
Hi all,
Changes since 20201112:
The drivers-memory tree still had its build failure.
The ext3 tree gained a build failure so I used the version from
next-20201112.
The usb-chipidea-next tree gained a build failure for which I reverted
a commit.
The akpm tree gained a build failure for which I applied a patch.
Non-merge commits (relative to Linus' tree): 5104
5240 files changed, 526195 insertions(+), 83948 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 htmldocs. 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 327 trees (counting Linus' and 85 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 (af5043c89a8e Merge tag 'acpi-5.10-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1)
Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in
setuid/setgid directory)
Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super
early in asm boot trampoline)
Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid
fortify_panic() when copying optprobe template)
Merging arm64-fixes/for-next/fixes (04e613ded8c2 arm64: smp: Tell RCU about
CPUs that fail to come online)
Merging arm-soc-fixes/arm/fixes (3d696f42c7f4 soc: ti: ti_sci_pm_domains: check
for proper args count in xlate)
Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1)
Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver
to platform driver)
Merging powerpc-fixes/fixes (01776f070ffc powerpc/32s: Use relocation offset
when setting early hash table)
Merging s390-fixes/fixes (78d732e1f326 s390/cpum_sf.c: fix file permission for
cpum_sfb_size)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (edbc21113bde lan743x: fix use of uninitialized variable)
Merging bpf/master (9602182810cc MAINTAINERS/bpf: Update Andrii's entry.)
Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in
xfrm_user_policy())
Merging netfilter/master (fea07a487c6d net: openvswitch: silence suspicious RCU
usage warning)
Merging ipvs/master (fea07a487c6d net: openvswitch: silence suspicious RCU
usage warning)
Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in
case of assert during CSA)
Merging mac80211/master (b2911a84396f mac80211: minstrel: fix tx status
processing corner case)
Merging rdma-fixes/for-rc (f8394f232b1e Linux 5.10-rc3)
Merging sound-current/for-linus (b5acfe152aba ALSA: hda/realtek: Add some Clove
SSID in the ALC293(ALC1220))
Merging sound-asoc-fixes/for-linus (016af47764cd Merge remote-tracking branch
'asoc/for-5.10' into asoc-linus)
Merging regmap-fixes/for-linus (3650b228f83a Linux 5.10-rc1)
Merging regulator-fixes/for-linus (365ec8b61689 regulator: pfuze100: limit
pfuze-support-disable-sw to pfuze{100,200})
Merging spi-fixes/for-linus (5900ea64d9ee Merge remote-tracking branch
'spi/for-5.10' into spi-linus)
Merging pci-current/for-linus (832ea234277a PCI: mvebu: Fix duplicate resource
requests)
Merging driver-core.current/driver-core-linus (f8394f232b1e Linux 5.10-rc3)
Merging tty.current/tty-linus (425af483523b serial: ar933x_uart: disable cl
Re: [PATCH] arm64: mm: account for hotplug memory when randomizing the linear region
On Fri, 13 Nov 2020 at 08:03, Anshuman Khandual
wrote:
>
>
>
> On 11/13/20 11:44 AM, Ard Biesheuvel wrote:
> > On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual
> > wrote:
> >>
> >>
> >>
> >> On 11/12/20 2:55 PM, Catalin Marinas wrote:
> >>> Hi Anshuman,
> >>>
> >>> On Wed, Nov 11, 2020 at 09:18:56AM +0530, Anshuman Khandual wrote:
> On 11/11/20 12:44 AM, Catalin Marinas wrote:
> > On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
> >> As a hardening measure, we currently randomize the placement of
> >> physical memory inside the linear region when KASLR is in effect.
> >> Since the random offset at which to place the available physical
> >> memory inside the linear region is chosen early at boot, it is
> >> based on the memblock description of memory, which does not cover
> >> hotplug memory. The consequence of this is that the randomization
> >> offset may be chosen such that any hotplugged memory located above
> >> memblock_end_of_DRAM() that appears later is pushed off the end of
> >> the linear region, where it cannot be accessed.
> >>
> >> [...]
> >
> > Applied to arm64 (for-next/mem-hotplug), thanks!
> >
> > [1/1] arm64: mm: account for hotplug memory when randomizing the linear
> > region
> > https://git.kernel.org/arm64/c/97d6786e0669
>
> Got delayed and never made here in time, sorry about that. Nonetheless,
> I have got something working with respect to the generic mechanism that
> David Hildenbrand had asked for earlier.
>
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/
> >>>
> >>> There was a lot of discussion around this patch but I haven't seen any
> >>> new version posted.
> >>
> >> Just posted before some time.
> >>
> >> https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khand...@arm.com/
> >>
> >
> > You failed to cc me on that patch.
>
> I could see 'a...@kernel.org' marked as a copy on the patch. You
> did not receive the email ? The CC list is in the commit message
> itself. Even the lore.kernel.org based URL does list you email
> as well. Not sure what might have happened.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Ard Biesheuvel
> Cc: Steven Price
> Cc: Robin Murphy
> Cc: David Hildenbrand
> Cc: Andrew Morton
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
Right. Not sure what happened there, I may have deleted it by
accident. Apologies.
> >
> > The logic looks correct but please fix up the comment block:
> > - PAGE_END is no longer defined in terms of vabits_actual
> > - bits [51..48] are not ignored by the MMU
> >
> > Actually, I think the entire second paragraph of that comment block
> > can be dropped.
>
> And from the commit message as well, had reused it in both places.
>
> >
> > Please also fix up the coding style:
> > - put && at the end of the first line
> > - drop the redundant parens
> > - fix the indentation
>
> Does this look okay ?
>
> static bool inside_linear_region(u64 start, u64 size)
> {
> /*
> * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
> * accommodating both its ends but excluding PAGE_END. Max physical
> * range which can be mapped inside this linear mapping range, must
> * also be derived from its end points.
> */
> return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> (start + size - 1) <= __pa(PAGE_END - 1);
> }
Not sure whether the whitespace has been mangled by the email client,
but the first ( on the second line should align vertically with the
's' of 'start' on the first line
About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource]
Hello,
[Added lkml and the people involved in commit 7945f929f1a7
("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the
new readers: This is about patches making use of
devm_platform_ioremap_resource() instead of open coding it. Full context
at https://lore.kernel.org/r/20201112190649.GA908613@ulmo]
On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-König wrote:
> On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote:
> > I also think that it's overly narrow is scope, so you can't actually
> > "blindly" use this helper and I've seen quite a few cases where this was
> > unknowingly used for cases where it shouldn't have been used and then
> > broke things (because some drivers must not do the request_mem_region()
> > for example).
>
> You have a link to such an accident?
I got a hint in private here:
https://lore.kernel.org/r/1555670144-24220-1-git-send-email-aisheng.d...@nxp.com
devm_platform_ioremap_resource() is platform_get_resource() +
devm_ioremap_resource() and here it was used to replace
platform_get_resource() + devm_ioremap().
IMHO the unlucky thing in this situation is that devm_ioremap_resource()
and devm_ioremap() are different by more than just how they get the area
to remap. (i.e. devm_ioremap_resource() also does
devm_request_mem_region().)
So the problem is not the added wrapper, but unclear semantics in the
functions it uses. In my eyes devm_ioremap() and
devm_platform_ioremap_resource() should better be named
devm_request_ioremap() and devm_platform_request_ioremap_resource()
respectively. Is it worth to rename these for clearity?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH 1/1] kasan: fix object remain in offline per-cpu quarantine
On Fri, Nov 13, 2020 at 3:32 AM Kuan-Ying Lee wrote: > > On Thu, 2020-11-12 at 09:39 +0100, Dmitry Vyukov wrote: > > On Thu, Nov 12, 2020 at 7:25 AM Kuan-Ying Lee > > wrote: > > > > > > We hit this issue in our internal test. > > > When enabling generic kasan, a kfree()'d object is put into per-cpu > > > quarantine first. If the cpu goes offline, object still remains in > > > the per-cpu quarantine. If we call kmem_cache_destroy() now, slub > > > will report "Objects remaining" error. > > > > > > [ 74.982625] > > > = > > > [ 74.983380] BUG test_module_slab (Not tainted): Objects remaining in > > > test_module_slab on __kmem_cache_shutdown() > > > [ 74.984145] > > > - > > > [ 74.984145] > > > [ 74.984883] Disabling lock debugging due to kernel taint > > > [ 74.985561] INFO: Slab 0x(ptrval) objects=34 used=1 > > > fp=0x(ptrval) flags=0x20010200 > > > [ 74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB > > > 5.10.0-rc1-7-g4525c8781ec0-dirty #10 > > > [ 74.987262] Hardware name: linux,dummy-virt (DT) > > > [ 74.987606] Call trace: > > > [ 74.987924] dump_backtrace+0x0/0x2b0 > > > [ 74.988296] show_stack+0x18/0x68 > > > [ 74.988698] dump_stack+0xfc/0x168 > > > [ 74.989030] slab_err+0xac/0xd4 > > > [ 74.989346] __kmem_cache_shutdown+0x1e4/0x3c8 > > > [ 74.989779] kmem_cache_destroy+0x68/0x130 > > > [ 74.990176] test_version_show+0x84/0xf0 > > > [ 74.990679] module_attr_show+0x40/0x60 > > > [ 74.991218] sysfs_kf_seq_show+0x128/0x1c0 > > > [ 74.991656] kernfs_seq_show+0xa0/0xb8 > > > [ 74.992059] seq_read+0x1f0/0x7e8 > > > [ 74.992415] kernfs_fop_read+0x70/0x338 > > > [ 74.993051] vfs_read+0xe4/0x250 > > > [ 74.993498] ksys_read+0xc8/0x180 > > > [ 74.993825] __arm64_sys_read+0x44/0x58 > > > [ 74.994203] el0_svc_common.constprop.0+0xac/0x228 > > > [ 74.994708] do_el0_svc+0x38/0xa0 > > > [ 74.995088] el0_sync_handler+0x170/0x178 > > > [ 74.995497] el0_sync+0x174/0x180 > > > [ 74.996050] INFO: Object 0x(ptrval) @offset=15848 > > > [ 74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 > > > cpu=6 pid=172 > > > [ 75.000802] stack_trace_save+0x9c/0xd0 > > > [ 75.002420] set_track+0x64/0xf0 > > > [ 75.002770] alloc_debug_processing+0x104/0x1a0 > > > [ 75.003171] ___slab_alloc+0x628/0x648 > > > [ 75.004213] __slab_alloc.isra.0+0x2c/0x58 > > > [ 75.004757] kmem_cache_alloc+0x560/0x588 > > > [ 75.005376] test_version_show+0x98/0xf0 > > > [ 75.005756] module_attr_show+0x40/0x60 > > > [ 75.007035] sysfs_kf_seq_show+0x128/0x1c0 > > > [ 75.007433] kernfs_seq_show+0xa0/0xb8 > > > [ 75.007800] seq_read+0x1f0/0x7e8 > > > [ 75.008128] kernfs_fop_read+0x70/0x338 > > > [ 75.008507] vfs_read+0xe4/0x250 > > > [ 75.008990] ksys_read+0xc8/0x180 > > > [ 75.009462] __arm64_sys_read+0x44/0x58 > > > [ 75.010085] el0_svc_common.constprop.0+0xac/0x228 > > > [ 75.011006] kmem_cache_destroy test_module_slab: Slab cache still has > > > objects > > > > > > Register a cpu hotplug function to remove all objects in the offline > > > per-cpu quarantine when cpu is going offline. Set a per-cpu variable > > > to indicate this cpu is offline. > > > > > > Signed-off-by: Kuan-Ying Lee > > > --- > > > mm/kasan/quarantine.c | 59 +-- > > > 1 file changed, 57 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c > > > index 4c5375810449..67fb91ae2bd0 100644 > > > --- a/mm/kasan/quarantine.c > > > +++ b/mm/kasan/quarantine.c > > > @@ -29,6 +29,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "../slab.h" > > > #include "kasan.h" > > > @@ -97,6 +98,7 @@ static void qlist_move_all(struct qlist_head *from, > > > struct qlist_head *to) > > > * guarded by quarantine_lock. > > > */ > > > > Hi Kuan-Ying, > > > > Thanks for fixing this. > > > > > static DEFINE_PER_CPU(struct qlist_head, cpu_quarantine); > > > +static DEFINE_PER_CPU(int, cpu_quarantine_offline); > > > > I think cpu_quarantine_offline is better be part of cpu_quarantine > > because it logically is and we already obtain a pointer to > > cpu_quarantine in quarantine_put, so it will also make the code a bit > > shorter. > > > > Ok. Got it. > > > > > > /* Round-robin FIFO array of batches. */ > > > static struct qlist_head global_quarantine[QUARANTINE_BATCHES]; > > > @@ -176,6 +178,8 @@ void quarantine_put(struct kasan_free_meta *info, > > > struct kmem_cache *cache) > > > unsigned long flags; > > > struct qlist_head *q; > > > struct qlist_head temp = QLIST_INIT; > > > + int *offline; > > > + struct qlist_head q_offline = QLIST_INIT; > > > > > > /* > > > * Note:
Re: [PATCH] arm64: mm: account for hotplug memory when randomizing the linear region
On 11/13/20 11:44 AM, Ard Biesheuvel wrote:
> On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual
> wrote:
>>
>>
>>
>> On 11/12/20 2:55 PM, Catalin Marinas wrote:
>>> Hi Anshuman,
>>>
>>> On Wed, Nov 11, 2020 at 09:18:56AM +0530, Anshuman Khandual wrote:
On 11/11/20 12:44 AM, Catalin Marinas wrote:
> On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
>> As a hardening measure, we currently randomize the placement of
>> physical memory inside the linear region when KASLR is in effect.
>> Since the random offset at which to place the available physical
>> memory inside the linear region is chosen early at boot, it is
>> based on the memblock description of memory, which does not cover
>> hotplug memory. The consequence of this is that the randomization
>> offset may be chosen such that any hotplugged memory located above
>> memblock_end_of_DRAM() that appears later is pushed off the end of
>> the linear region, where it cannot be accessed.
>>
>> [...]
>
> Applied to arm64 (for-next/mem-hotplug), thanks!
>
> [1/1] arm64: mm: account for hotplug memory when randomizing the linear
> region
> https://git.kernel.org/arm64/c/97d6786e0669
Got delayed and never made here in time, sorry about that. Nonetheless,
I have got something working with respect to the generic mechanism that
David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/
>>>
>>> There was a lot of discussion around this patch but I haven't seen any
>>> new version posted.
>>
>> Just posted before some time.
>>
>> https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khand...@arm.com/
>>
>
> You failed to cc me on that patch.
I could see 'a...@kernel.org' marked as a copy on the patch. You
did not receive the email ? The CC list is in the commit message
itself. Even the lore.kernel.org based URL does list you email
as well. Not sure what might have happened.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Ard Biesheuvel
Cc: Steven Price
Cc: Robin Murphy
Cc: David Hildenbrand
Cc: Andrew Morton
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
>
> The logic looks correct but please fix up the comment block:
> - PAGE_END is no longer defined in terms of vabits_actual
> - bits [51..48] are not ignored by the MMU
>
> Actually, I think the entire second paragraph of that comment block
> can be dropped.
And from the commit message as well, had reused it in both places.
>
> Please also fix up the coding style:
> - put && at the end of the first line
> - drop the redundant parens
> - fix the indentation
Does this look okay ?
static bool inside_linear_region(u64 start, u64 size)
{
/*
* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
* accommodating both its ends but excluding PAGE_END. Max physical
* range which can be mapped inside this linear mapping range, must
* also be derived from its end points.
*/
return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
(start + size - 1) <= __pa(PAGE_END - 1);
}
linux-next: build failure after merge of the akpm tree
Hi all,
After merging the akpm tree, today's linux-next build (i386 defconfig)
failed like this:
mm/secretmem.c: In function 'secretmem_memcg_charge':
mm/secretmem.c:72:4: error: 'struct page' has no member named 'memcg_data'
72 | p->memcg_data = page->memcg_data;
|^~
mm/secretmem.c:72:23: error: 'struct page' has no member named 'memcg_data'
72 | p->memcg_data = page->memcg_data;
| ^~
mm/secretmem.c: In function 'secretmem_memcg_uncharge':
mm/secretmem.c:86:4: error: 'struct page' has no member named 'memcg_data'
86 | p->memcg_data = 0;
|^~
Caused by commit
5f964602825e ("secretmem: add memcg accounting")
memcg_data only exists when CONFIG_MEMCG is set.
I have applied the following patch for today.
From: Stephen Rothwell
Date: Fri, 13 Nov 2020 17:50:30 +1100
Subject: [PATCH] secretmem-add-memcg-accounting-fix2
Signed-off-by: Stephen Rothwell
---
mm/secretmem.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 5ed6b2070136..3dfdbd85ba00 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -69,7 +69,9 @@ static int secretmem_memcg_charge(struct page *page, gfp_t
gfp, int order)
for (i = 1; i < nr_pages; i++) {
struct page *p = page + i;
+#ifdef CONFIG_MEMCG
p->memcg_data = page->memcg_data;
+#endif
}
return 0;
@@ -83,7 +85,9 @@ static void secretmem_memcg_uncharge(struct page *page, int
order)
for (i = 1; i < nr_pages; i++) {
struct page *p = page + i;
+#ifdef CONFIG_MEMCG
p->memcg_data = 0;
+#endif
}
memcg_kmem_uncharge_page(page, PMD_PAGE_ORDER);
--
2.28.0
This unfortunately produced these warnings:
mm/secretmem.c: In function 'secretmem_memcg_charge':
mm/secretmem.c:70:16: warning: unused variable 'p' [-Wunused-variable]
70 | struct page *p = page + i;
|^
mm/secretmem.c: In function 'secretmem_memcg_uncharge':
mm/secretmem.c:86:16: warning: unused variable 'p' [-Wunused-variable]
86 | struct page *p = page + i;
|^
which I will fix up for the next linux-next release, if necessary.
--
Cheers,
Stephen Rothwell
pgpxetQDcc4Ky.pgp
Description: OpenPGP digital signature
Re: [PATCH 02/19] elf: Move arch_setup_additional_pages() to generic elf.h
Hi Dmitry, Thank you for the patch! Yet something to improve: [auto build test ERROR on c34f157421f6905e6b4a79a312e9175dce2bc607] url: https://github.com/0day-ci/linux/commits/Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354 base:c34f157421f6905e6b4a79a312e9175dce2bc607 config: riscv-allmodconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/c46ac7ddea192a97f9b0b3aa3536566a37389bec git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354 git checkout c46ac7ddea192a97f9b0b3aa3536566a37389bec # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from include/linux/elf.h:6, from include/linux/module.h:18, from include/linux/irqchip.h:15, from arch/riscv/kernel/irq.c:9: >> arch/riscv/include/asm/elf.h:8: error: unterminated #ifndef 8 | #ifndef _ASM_RISCV_ELF_H | arch/riscv/kernel/irq.c:19:13: warning: no previous prototype for 'init_IRQ' [-Wmissing-prototypes] 19 | void __init init_IRQ(void) | ^~~~ -- In file included from include/linux/elf.h:6, from arch/riscv/kernel/ptrace.c:15: >> arch/riscv/include/asm/elf.h:8: error: unterminated #ifndef 8 | #ifndef _ASM_RISCV_ELF_H | arch/riscv/kernel/ptrace.c:140:15: warning: no previous prototype for 'do_syscall_trace_enter' [-Wmissing-prototypes] 140 | __visible int do_syscall_trace_enter(struct pt_regs *regs) | ^~ arch/riscv/kernel/ptrace.c:163:16: warning: no previous prototype for 'do_syscall_trace_exit' [-Wmissing-prototypes] 163 | __visible void do_syscall_trace_exit(struct pt_regs *regs) |^ -- In file included from include/linux/elf.h:6, from include/linux/module.h:18, from include/linux/kallsyms.h:13, from include/linux/ftrace.h:11, from include/linux/perf_event.h:49, from include/linux/trace_events.h:10, from include/trace/syscall.h:7, from include/linux/syscalls.h:84, from arch/riscv/kernel/signal.c:11: >> arch/riscv/include/asm/elf.h:8: error: unterminated #ifndef 8 | #ifndef _ASM_RISCV_ELF_H | arch/riscv/kernel/signal.c:309:27: warning: no previous prototype for 'do_notify_resume' [-Wmissing-prototypes] 309 | asmlinkage __visible void do_notify_resume(struct pt_regs *regs, | ^~~~ -- In file included from include/linux/elf.h:6, from include/linux/module.h:18, from include/linux/kallsyms.h:13, from include/linux/ftrace.h:11, from include/linux/perf_event.h:49, from include/linux/trace_events.h:10, from include/trace/syscall.h:7, from include/linux/syscalls.h:84, from arch/riscv/kernel/syscall_table.c:8: >> arch/riscv/include/asm/elf.h:8: error: unterminated #ifndef 8 | #ifndef _ASM_RISCV_ELF_H | arch/riscv/kernel/syscall_table.c:14:36: warning: initialized field overwritten [-Woverride-init] 14 | #define __SYSCALL(nr, call) [nr] = (call), |^ include/uapi/asm-generic/unistd.h:29:37: note: in expansion of macro '__SYSCALL' 29 | #define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _sys) | ^ include/uapi/asm-generic/unistd.h:34:1: note: in expansion of macro '__SC_COMP' 34 | __SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup) | ^ arch/riscv/kernel/syscall_table.c:14:36: note: (near initialization for 'sys_call_table[0]') 14 | #define __SYSCALL(nr, call) [nr] = (call), |^ include/uapi/asm-generic/unistd.h:29:37: note: in expansion of macro '__SYSCALL' 29 | #define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _sys) | ^ include/uapi/asm-generic/unistd.h:34:1: note: in expansion of macro '__SC_COMP' 34 | __SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup) | ^
Re: [PATCH 02/19] elf: Move arch_setup_additional_pages() to generic elf.h
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on c34f157421f6905e6b4a79a312e9175dce2bc607]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
base:c34f157421f6905e6b4a79a312e9175dce2bc607
config: riscv-randconfig-r026-20201109 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
09ec07827b1128504457a93dee80b2ceee1af600)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/c46ac7ddea192a97f9b0b3aa3536566a37389bec
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
git checkout c46ac7ddea192a97f9b0b3aa3536566a37389bec
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
#ifndef _ASM_RISCV_ELF_H
^
In file included from arch/riscv/kernel/traps_misaligned.c:9:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/riscv/include/asm/io.h:149:
include/asm-generic/io.h:556:9: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return inb(addr);
^
arch/riscv/include/asm/io.h:55:76: note: expanded from macro 'inb'
#define inb(c) ({ u8 __v; __io_pbr(); __v =
readb_cpu((void*)(PCI_IOBASE + (c))); __io_par(__v); __v; })
~~ ^
arch/riscv/include/asm/mmio.h:87:48: note: expanded from macro 'readb_cpu'
#define readb_cpu(c)({ u8 __r = __raw_readb(c); __r; })
^
In file included from arch/riscv/kernel/traps_misaligned.c:9:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/riscv/include/asm/io.h:149:
include/asm-generic/io.h:564:9: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return inw(addr);
^
arch/riscv/include/asm/io.h:56:76: note: expanded from macro 'inw'
#define inw(c) ({ u16 __v; __io_pbr(); __v =
readw_cpu((void*)(PCI_IOBASE + (c))); __io_par(__v); __v; })
~~ ^
arch/riscv/include/asm/mmio.h:88:76: note: expanded from macro 'readw_cpu'
#define readw_cpu(c)({ u16 __r = le16_to_cpu((__force
__le16)__raw_readw(c)); __r; })
^
include/uapi/linux/byteorder/little_endian.h:36:51: note: expanded from
macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
^
In file included from arch/riscv/kernel/traps_misaligned.c:9:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/riscv/include/asm/io.h:149:
include/asm-generic/io.h:572:9: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return inl(addr);
^
arch/riscv/include/asm/io.h:57:76: note: expanded from macro 'inl'
#define inl(c) ({ u32 __v; __io_pbr(); __v =
readl_cpu((void*)(PCI_IOBASE + (c))); __io_par(__v); __v; })
~~ ^
arch/riscv/include/asm/mmio.h:89:76: note: expanded from macro 'readl_cpu'
#define readl_cpu(c)({ u32 __r = le32_to_cpu((__force
__le32)__raw_readl(c)); __r; })
^
include/uapi/linux/byteorder/little_endian.h:34:51: note: expanded from
macro '__le32_to_cpu'
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
^
In file included from arch/riscv/kernel/traps_misaligned.c:9:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/riscv/include/asm/io.h:149:
include/asm-generic/io.h:580:2: warning: performing pointer arithmetic on a
null pointer has
Re: [PATCH 06/19] elf/vdso: Reuse arch_setup_additional_pages() parameters
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on c34f157421f6905e6b4a79a312e9175dce2bc607]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
base:c34f157421f6905e6b4a79a312e9175dce2bc607
config: ia64-randconfig-r035-20201109 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/04586680978b048abe74dd892c5b1fcde7c486a3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
git checkout 04586680978b048abe74dd892c5b1fcde7c486a3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) ||
ARCH_WANT_FRAME_POINTERS
Selected by
- FAULT_INJECTION_STACKTRACE_FILTER && FAULT_INJECTION_DEBUG_FS &&
STACKTRACE_SUPPORT && !X86_64 && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM
&& !ARC && !X86
In file included from arch/ia64/include/asm/pgtable.h:154,
from include/linux/pgtable.h:6,
from arch/ia64/include/asm/uaccess.h:40,
from include/linux/uaccess.h:11,
from include/linux/sched/task.h:11,
from include/linux/sched/signal.h:9,
from arch/ia64/kernel/asm-offsets.c:10:
arch/ia64/include/asm/mmu_context.h: In function 'reload_context':
arch/ia64/include/asm/mmu_context.h:127:41: warning: variable 'old_rr4' set
but not used
127 | unsigned long rr0, rr1, rr2, rr3, rr4, old_rr4;
| ^~~
In file included from arch/ia64/include/asm/sections.h:10,
from include/linux/interrupt.h:20,
from arch/ia64/include/asm/mca.h:17,
from arch/ia64/kernel/asm-offsets.c:18:
include/linux/elf.h: At top level:
include/linux/elf.h:121:1: error: expected identifier or '(' before '{' token
121 | {
| ^
arch/ia64/kernel/asm-offsets.c:23:6: warning: no previous prototype for 'foo'
23 | void foo(void)
| ^~~
In file included from arch/ia64/include/asm/sections.h:10,
from include/linux/interrupt.h:20,
from arch/ia64/include/asm/mca.h:17,
from arch/ia64/kernel/asm-offsets.c:18:
>> include/linux/elf.h:120:19: warning: 'arch_setup_additional_pages' declared
>> 'static' but never defined
120 | static inline int arch_setup_additional_pages(unsigned long
| ^~~
Makefile arch include kernel scripts source usr [scripts/Makefile.build:117:
arch/ia64/kernel/asm-offsets.s] Error 1
Target '__build' not remade because of errors.
Makefile arch include kernel scripts source usr [Makefile:1198: prepare0]
Error 2
Target 'prepare' not remade because of errors.
make: Makefile arch include kernel scripts source usr [Makefile:185:
__sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +120 include/linux/elf.h
106
107 #ifdef CONFIG_ARCH_HAS_SETUP_ADDITIONAL_PAGES
108 /**
109 * arch_setup_additional_pages - Premap VMAs in a new-execed process
110 * @sysinfo_ehdr: Returns vDSO position to be set in the initial
111 * auxiliary vector (tag AT_SYSINFO_EHDR) by binfmt
112 * loader. On failure isn't initialized.
113 * As address == 0 is never used, it allows to
check
114 * if the tag should be set.
115 *
116 * Return: Zero if successful, or a negative error code on failure.
117 */
118 extern int arch_setup_additional_pages(unsigned long *sysinfo_ehdr);
119 #else
> 120 static inline int arch_setup_additional_pages(unsigned long
> *sysinfo_ehdr);
121 {
122 return 0;
123 }
124 #endif
125
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] panic: Avoid dump_stack() twice
On 2020/11/13 14:39, Alexey Kardashevskiy wrote: Fixed already https://ozlabs.org/~akpm/mmots/broken-out/panic-dont-dump-stack-twice-on-warn.patch Sorry for breaking this :( OK.
[PATCH net] net: ethernet: ti: cpsw: fix error return code in cpsw_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 83a8471ba255 ("net: ethernet: ti: cpsw: refactor probe to group common
hw initialization")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/net/ethernet/ti/cpsw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 9fd1f77..7882a00 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1631,6 +1631,7 @@ static int cpsw_probe(struct platform_device *pdev)
CPSW_MAX_QUEUES, CPSW_MAX_QUEUES);
if (!ndev) {
dev_err(dev, "error allocating net_device\n");
+ ret = -ENOMEM;
goto clean_cpts;
}
--
2.9.5
Re: [Fonts] 9522750c66: fio.read_iops 7.5% improvement
On Thu, Nov 12, 2020 at 10:06:25PM +0800, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a 7.5% improvement of fio.read_iops due to commit:
>
>
> commit: 9522750c66c689b739e151fcdf895420dc81efc0 ("Fonts: Replace discarded
> const qualifier")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
I strongly doubt this :)
[PATCH] IB/hfi1: fix error return code in hfi1_init_dd()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/infiniband/hw/hfi1/chip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hfi1/chip.c
b/drivers/infiniband/hw/hfi1/chip.c
index 7eaf9953..c87b94e 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -15245,7 +15245,8 @@ int hfi1_init_dd(struct hfi1_devdata *dd)
& CCE_REVISION_SW_MASK);
/* alloc netdev data */
- if (hfi1_netdev_alloc(dd))
+ ret = hfi1_netdev_alloc(dd);
+ if (ret)
goto bail_cleanup;
ret = set_up_context_variables(dd);
--
2.9.5
[git pull] drm fixes for 5.10-rc4
Hi Linus, Nearly didn't send you a PR this week at all, but a few things trickled in over the day, not a huge amount here, some i915, amdgpu and a bunch of misc fixes. I have a couple of nouveau fixes outstanding due to the PR having the wrong base, I'll figure it out next week. Dave. drm-fixes-2020-11-13: drm fixes for 5.10-rc4 amdgpu: - Pageflip fix for DCN3 - Declare TA firmware for green sardine - Headless navi fix i915: - Pull phys pread/pwrite implementations to the backend - Correctly set SFC capability for video engines bridge: - cdns Kconfig fix hyperv_fb: - fix missing include gma500: - oob access fix mcde: - unbalanced regulator fix The following changes since commit f8394f232b1eab649ce2df5c5f15b0e528c92091: Linux 5.10-rc3 (2020-11-08 16:10:16 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-13 for you to fetch changes up to 41f3ed2cac86ba533ce6a334a2e7fae5c7082946: Merge tag 'amd-drm-fixes-5.10-2020-11-12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-11-13 16:05:31 +1000) drm fixes for 5.10-rc4 amdgpu: - Pageflip fix for DCN3 - Declare TA firmware for green sardine - Headless navi fix i915: - Pull phys pread/pwrite implementations to the backend - Correctly set SFC capability for video engines bridge: - cdns Kconfig fix hyperv_fb: - fix missing include gma500: - oob access fix mcde: - unbalanced regulator fix Bhawanpreet Lakha (1): drm/amd/display: Add missing pflip irq Chris Wilson (1): drm/i915/gem: Pull phys pread/pwrite implementations to the backend Dave Airlie (3): Merge tag 'drm-misc-fixes-2020-11-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2020-11-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.10-2020-11-12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Linus Walleij (1): drm/mcde: Fix unbalanced regulator Matthew Auld (1): drm/i915/gem: Allow backends to override pread implementation Nishanth Menon (1): drm: bridge: cdns: Kconfig: Switch over dependency to ARCH_K3 Olaf Hering (1): video: hyperv_fb: include vmalloc.h Roman Li (1): drm/amdgpu: add ta firmware load for green-sardine Thomas Zimmermann (1): drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[] Tianci.Yin (1): drm/amdgpu: enable DCN for navi10 headless SKU Venkata Sandeep Dhanalakota (1): drm/i915: Correctly set SFC capability for video engines drivers/gpu/drm/amd/amdgpu/nv.c| 3 +- drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 + .../amd/display/dc/irq/dcn30/irq_service_dcn30.c | 4 +- drivers/gpu/drm/bridge/cadence/Kconfig | 2 +- drivers/gpu/drm/gma500/psb_irq.c | 34 + drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 + drivers/gpu/drm/i915/gem/i915_gem_phys.c | 55 ++ drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +- drivers/gpu/drm/i915/i915_gem.c| 32 +++-- drivers/gpu/drm/mcde/mcde_drv.c| 8 +++- drivers/video/fbdev/hyperv_fb.c| 1 + 11 files changed, 90 insertions(+), 55 deletions(-)
Re: [PATCH] panic: Avoid dump_stack() twice
Fixed already
https://ozlabs.org/~akpm/mmots/broken-out/panic-dont-dump-stack-twice-on-warn.patch
Sorry for breaking this :(
On 13/11/2020 16:47, Kefeng Wang wrote:
stacktrace will be dumped twice on ARM64 after commit 3f388f28639f
("panic: dump registers on panic_on_warn"), will not dump_stack
when no regs as before.
Fixes: 3f388f28639f ("panic: dump registers on panic_on_warn")
Signed-off-by: Kefeng Wang
---
kernel/panic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 396142ee43fd..332736a72a58 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -605,7 +605,8 @@ void __warn(const char *file, int line, void *caller,
unsigned taint,
panic("panic_on_warn set ...\n");
}
- dump_stack();
+ if (!regs)
+ dump_stack();
print_irqtrace_events(current);
--
Alexey
Re: mmotm 2020-11-12-20-01 uploaded (mm/secretmem.c)
On 11/12/20 8:02 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2020-11-12-20-01 has been uploaded to > >https://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > https://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > > You will need quilt to apply these patches to the latest Linus release (5.x > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > https://ozlabs.org/~akpm/mmotm/series > > The file broken-out.tar.gz contains two datestamp files: .DATE and > .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, > followed by the base kernel version against which this patch series is to > be applied. Lots of build errors like this: when CONFIG_MEMCG is not set/enabled: ../mm/secretmem.c:72:4: error: ‘struct page’ has no member named ‘memcg_data’ ../mm/secretmem.c:72:23: error: ‘struct page’ has no member named ‘memcg_data’ ../mm/secretmem.c:86:4: error: ‘struct page’ has no member named ‘memcg_data’ -- ~Randy Reported-by: Randy Dunlap
[PATCH net] net: stmmac: dwmac-intel-plat: fix error return code in intel_eth_plat_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 9efc9b2b04c7 ("net: stmmac: Add dwmac-intel-plat for GBE driver")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c
index f61cb99..82b1c7a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c
@@ -113,8 +113,10 @@ static int intel_eth_plat_probe(struct platform_device
*pdev)
/* Enable TX clock */
if (dwmac->data->tx_clk_en) {
dwmac->tx_clk = devm_clk_get(>dev, "tx_clk");
- if (IS_ERR(dwmac->tx_clk))
+ if (IS_ERR(dwmac->tx_clk)) {
+ ret = PTR_ERR(dwmac->tx_clk);
goto err_remove_config_dt;
+ }
clk_prepare_enable(dwmac->tx_clk);
--
2.9.5
[PATCH RFC v1 1/1] scsi: pm: Leave runtime resume along if block layer PM is enabled
If block layer runtime PM is enabled for one SCSI device, then there is
no need to forcibly change the SCSI device and its request queue's runtime
PM status to active in scsi_dev_type_resume(), since block layer PM shall
resume the SCSI device on the demand of bios.
Cc: Stanley Chu
Cc: Bart Van Assche
Signed-off-by: Can Guo
---
drivers/scsi/scsi_pm.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 3717eea..278c27e 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -79,23 +79,22 @@ static int scsi_dev_type_resume(struct device *dev,
scsi_device_resume(to_scsi_device(dev));
dev_dbg(dev, "scsi resume: %d\n", err);
- if (err == 0) {
- pm_runtime_disable(dev);
- err = pm_runtime_set_active(dev);
- pm_runtime_enable(dev);
+ if (scsi_is_sdev_device(dev)) {
+ struct scsi_device *sdev;
+ sdev = to_scsi_device(dev);
/*
-* Forcibly set runtime PM status of request queue to "active"
-* to make sure we can again get requests from the queue
-* (see also blk_pm_peek_request()).
-*
-* The resume hook will correct runtime PM status of the disk.
+* If block layer runtime PM is enabled for the SCSI device,
+* let block layer PM handle its runtime PM routines.
*/
- if (!err && scsi_is_sdev_device(dev)) {
- struct scsi_device *sdev = to_scsi_device(dev);
+ if (sdev->request_queue->dev)
+ return err;
+ }
- blk_set_runtime_active(sdev->request_queue);
- }
+ if (err == 0) {
+ pm_runtime_disable(dev);
+ err = pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
}
return err;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH] brcmfmac: fix error return code in brcmf_cfg80211_connect()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 3b1e0a7bdfee ("brcmfmac: add support for SAE authentication offload")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index a2dbbb9..0ee421f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2137,7 +2137,8 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct
net_device *ndev,
BRCMF_WSEC_MAX_PSK_LEN);
else if (profile->use_fwsup == BRCMF_PROFILE_FWSUP_SAE) {
/* clean up user-space RSNE */
- if (brcmf_fil_iovar_data_set(ifp, "wpaie", NULL, 0)) {
+ err = brcmf_fil_iovar_data_set(ifp, "wpaie", NULL, 0);
+ if (err) {
bphy_err(drvr, "failed to clean up user-space RSNE\n");
goto done;
}
--
2.9.5
Re: [PATCH] arm64: mm: account for hotplug memory when randomizing the linear region
On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual wrote: > > > > On 11/12/20 2:55 PM, Catalin Marinas wrote: > > Hi Anshuman, > > > > On Wed, Nov 11, 2020 at 09:18:56AM +0530, Anshuman Khandual wrote: > >> On 11/11/20 12:44 AM, Catalin Marinas wrote: > >>> On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote: > As a hardening measure, we currently randomize the placement of > physical memory inside the linear region when KASLR is in effect. > Since the random offset at which to place the available physical > memory inside the linear region is chosen early at boot, it is > based on the memblock description of memory, which does not cover > hotplug memory. The consequence of this is that the randomization > offset may be chosen such that any hotplugged memory located above > memblock_end_of_DRAM() that appears later is pushed off the end of > the linear region, where it cannot be accessed. > > [...] > >>> > >>> Applied to arm64 (for-next/mem-hotplug), thanks! > >>> > >>> [1/1] arm64: mm: account for hotplug memory when randomizing the linear > >>> region > >>> https://git.kernel.org/arm64/c/97d6786e0669 > >> > >> Got delayed and never made here in time, sorry about that. Nonetheless, > >> I have got something working with respect to the generic mechanism that > >> David Hildenbrand had asked for earlier. > >> > >> https://patchwork.kernel.org/project/linux-arm-kernel/patch/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/ > > > > There was a lot of discussion around this patch but I haven't seen any > > new version posted. > > Just posted before some time. > > https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khand...@arm.com/ > You failed to cc me on that patch. The logic looks correct but please fix up the comment block: - PAGE_END is no longer defined in terms of vabits_actual - bits [51..48] are not ignored by the MMU Actually, I think the entire second paragraph of that comment block can be dropped. Please also fix up the coding style: - put && at the end of the first line - drop the redundant parens - fix the indentation > > > >> I am wondering if we could instead consider merging the above patch with > >> a small change that Ard had pointed out earlier [1], I will send out a > >> revision if required. > > > > If your patch fixes the randomisation issue that Ard addressed, I'm > > happy to replace that with your patch. But please post a new version and > > get some acks in place from the parties involved in the discussion. > > The above patch is not a replacement for Ard's randomization patch here but > rather complements it. Hence both these patches should be considered, which > will make memory hotplug better on the platform.
[PATCH net] qlcnic: fix error return code in qlcnic_83xx_restart_hw()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 3ced0a88cd4c ("qlcnic: Add support to run firmware POST")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
index b8af59f..d2c1907 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
@@ -2231,7 +2231,8 @@ static int qlcnic_83xx_restart_hw(struct qlcnic_adapter
*adapter)
/* Boot either flash image or firmware image from host file system */
if (qlcnic_load_fw_file == 1) {
- if (qlcnic_83xx_load_fw_image_from_host(adapter))
+ err = qlcnic_83xx_load_fw_image_from_host(adapter);
+ if (err)
return err;
} else {
QLC_SHARED_REG_WR32(adapter, QLCNIC_FW_IMG_VALID,
--
2.9.5
[PATCH] crypto: lib/curve25519 - Move selftest prototype into header file
On Fri, Nov 13, 2020 at 01:56:46PM +0800, kernel test robot wrote:
>
> All warnings (new ones prefixed by >>):
>
> >> lib/crypto/curve25519-selftest.c:1283:13: warning: no previous prototype
> >> for 'curve25519_selftest' [-Wmissing-prototypes]
> 1283 | bool __init curve25519_selftest(void)
> | ^~~
---8<---
This patch moves the curve25519_selftest into curve25519.h so
we don't get a warning from gcc complaining about a missing
prototype.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/include/crypto/curve25519.h b/include/crypto/curve25519.h
index 4e6dc840b159..ece6a9b5fafc 100644
--- a/include/crypto/curve25519.h
+++ b/include/crypto/curve25519.h
@@ -28,6 +28,8 @@ void curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
void curve25519_base_arch(u8 pub[CURVE25519_KEY_SIZE],
const u8 secret[CURVE25519_KEY_SIZE]);
+bool curve25519_selftest(void);
+
static inline
bool __must_check curve25519(u8 mypublic[CURVE25519_KEY_SIZE],
const u8 secret[CURVE25519_KEY_SIZE],
diff --git a/lib/crypto/curve25519.c b/lib/crypto/curve25519.c
index 288a62cd29b2..fb29739e8c29 100644
--- a/lib/crypto/curve25519.c
+++ b/lib/crypto/curve25519.c
@@ -13,8 +13,6 @@
#include
#include
-bool curve25519_selftest(void);
-
static int __init mod_init(void)
{
if (!IS_ENABLED(CONFIG_CRYPTO_MANAGER_DISABLE_TESTS) &&
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] kbuild: Always link with '-z norelro'
On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
wrote:
>
> On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> > On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> > wrote:
> > >
> > > Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> > > script and options") added '-z norelro' to the arm64 Makefile when
> > > CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> > > defaults to '-z relro' but the kernel does not use program headers or
> > > adhere to the section layout that is required for RELRO to work.
> > >
> > > Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> > > CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> > > an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> > > unset.
> > >
> > > As it turns out, ARM experiences the same error after CONFIG_KASAN was
> > > implemented, meaning that '-z norelro' needs to be added to that
> > > Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
> > >
> > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > ld.lld: error: section: .exit.data is not contiguous with other relro
> > > sections
> > >
> > > To avoid playing whack-a-mole with different architectures over time,
> > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > because '-z norelro' is the default for it.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > > Suggested-by: Nick Desaulniers
> > > Signed-off-by: Nathan Chancellor
> >
> > Why not add it additionally to KBUILD_LDFLAGS_MODULE a la
> > `--build-id=sha1` a few lines above? (or `LDFLAGS_MODULE`, but that
> > looks unused?) We probably don't want this for modules either. In
> > that case, you could add -z norelo to the two existing lines with
> > `--build-id=sha1` above?
>
> Yes, I can do that. I will send a v2 along tomorrow morning to let
> others comment.
>
Modules are partially linked objects, so there is no point in passing
-z options for them.
[PATCH net] cx82310_eth: fix error return code in cx82310_bind()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: ca139d76b0d9 ("cx82310_eth: re-enable ethernet mode after router reboot")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/net/usb/cx82310_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index ca89d82..c4568a4 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -197,7 +197,8 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
}
/* enable ethernet mode (?) */
- if (cx82310_enable_ethernet(dev))
+ ret = cx82310_enable_ethernet(dev);
+ if (ret)
goto err;
/* get the MAC address */
--
2.9.5
Re: [PATCH v4 01/18] dt-bindings: usb: usb-hcd: Detach generic USB controller properties
On Wed, 2020-11-11 at 12:08 +0300, Serge Semin wrote: > There can be three distinctive types of the USB controllers: USB hosts, > USB peripherals/gadgets and USB OTG, which can switch from one role to > another. In order to have that hierarchy handled in the DT binding files, > we need to collect common properties in a common DT schema and specific > properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is > dedicated for the USB host controllers only, let's move some common > properties from there into the usb.yaml schema. So the later would be > available to evaluate all currently supported types of the USB > controllers. > > While at it add an explicit "additionalProperties: true" into the > usb-hcd.yaml as setting the additionalProperties/unevaluateProperties > properties is going to be get mandatory soon. > > Signed-off-by: Serge Semin > > --- > > Changelog v4: > - This is a new patch created as a result of the comment left > by Chunfeng Yun in v3 > --- > .../devicetree/bindings/usb/usb-hcd.yaml | 14 ++--- > .../devicetree/bindings/usb/usb.yaml | 29 +++ > 2 files changed, 32 insertions(+), 11 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml > > diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml > b/Documentation/devicetree/bindings/usb/usb-hcd.yaml > index 7263b7f2b510..81f3ad1419d8 100644 > --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml > +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml > @@ -9,18 +9,10 @@ title: Generic USB Host Controller Device Tree Bindings > maintainers: >- Greg Kroah-Hartman > > -properties: > - $nodename: > -pattern: "^usb(@.*)?" > +allOf: > + - $ref: usb.yaml# > > - phys: > -$ref: /schemas/types.yaml#/definitions/phandle-array > -description: > - List of all the USB PHYs on this HCD > - > - phy-names: > -description: > - Name specifier for the USB PHY > +additionalProperties: true This seems already added by the applied patch 6a0e321ea735 "dt-bindings: Explicitly allow additional properties in common schemas" > > examples: >- | > diff --git a/Documentation/devicetree/bindings/usb/usb.yaml > b/Documentation/devicetree/bindings/usb/usb.yaml > new file mode 100644 > index ..941ad59fbac5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/usb.yaml > @@ -0,0 +1,29 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/usb/usb.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic USB Controller Device Tree Bindings > + > +maintainers: > + - Greg Kroah-Hartman > + > +select: false > + > +properties: > + $nodename: > +pattern: "^usb(@.*)?" > + > + phys: > +$ref: /schemas/types.yaml#/definitions/phandle-array > +description: > + List of all the USB PHYs on this HCD > + > + phy-names: > +description: > + Name specifier for the USB PHY > + > +additionalProperties: true > + > +...
linux-next: build warning after merge of the akpm-current tree
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in lib/cmdline_kunit.o
Introduced by commit
f1a15df76475 ("lib/cmdline_kunit: add a new test suite for cmdline API")
--
Cheers,
Stephen Rothwell
pgpwOq2BtzM_F.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 00/14] iommu/amd: Add Generic IO Page Table Framework Support
Joerg, Please ignore to include the V3. I am working on V4 to resubmit. Thank you, Suravee On 11/11/20 10:10 AM, Suravee Suthikulpanit wrote: Hi Joerg, Do you have any update on this series? Thanks, Suravee On 11/2/20 10:16 AM, Suravee Suthikulpanit wrote: Joerg, You mentioned to remind you to pull this in to linux-next. Thanks, Suravee On 10/4/20 8:45 AM, Suravee Suthikulpanit wrote: The framework allows callable implementation of IO page table. This allows AMD IOMMU driver to switch between different types of AMD IOMMU page tables (e.g. v1 vs. v2). This series refactors the current implementation of AMD IOMMU v1 page table to adopt the framework. There should be no functional change. Subsequent series will introduce support for the AMD IOMMU v2 page table. Thanks, Suravee Change from V2 (https://lore.kernel.org/lkml/835c0d46-ed96-9fbe-856a-777dcffac...@amd.com/T/#t) - Patch 2/14: Introduce helper function io_pgtable_cfg_to_data. - Patch 13/14: Put back the struct iommu_flush_ops since patch v2 would run into NULL pointer bug when calling free_io_pgtable_ops if not defined. Change from V1 (https://lkml.org/lkml/2020/9/23/251) - Do not specify struct io_pgtable_cfg.coherent_walk, since it is not currently used. (per Robin) - Remove unused struct iommu_flush_ops. (patch 2/13) - Move amd_iommu_setup_io_pgtable_ops to iommu.c instead of io_pgtable.c patch 13/13) Suravee Suthikulpanit (14): iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline iommu/amd: Prepare for generic IO page table framework iommu/amd: Move pt_root to to struct amd_io_pgtable iommu/amd: Convert to using amd_io_pgtable iommu/amd: Declare functions as extern iommu/amd: Move IO page table related functions iommu/amd: Restructure code for freeing page table iommu/amd: Remove amd_iommu_domain_get_pgtable iommu/amd: Rename variables to be consistent with struct io_pgtable_ops iommu/amd: Refactor fetch_pte to use struct amd_io_pgtable iommu/amd: Introduce iommu_v1_iova_to_phys iommu/amd: Introduce iommu_v1_map_page and iommu_v1_unmap_page iommu/amd: Introduce IOMMU flush callbacks iommu/amd: Adopt IO page table framework drivers/iommu/amd/Kconfig | 1 + drivers/iommu/amd/Makefile | 2 +- drivers/iommu/amd/amd_iommu.h | 22 + drivers/iommu/amd/amd_iommu_types.h | 43 +- drivers/iommu/amd/io_pgtable.c | 564 drivers/iommu/amd/iommu.c | 646 +++- drivers/iommu/io-pgtable.c | 3 + include/linux/io-pgtable.h | 2 + 8 files changed, 691 insertions(+), 592 deletions(-) create mode 100644 drivers/iommu/amd/io_pgtable.c
lib/crypto/curve25519-selftest.c:1283:13: warning: no previous prototype for 'curve25519_selftest'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba commit: aa127963f1cab2b93c74c9b128a84610203fb674 crypto: lib/curve25519 - re-add selftests date: 11 months ago config: nios2-randconfig-r033-20201113 (attached as .config) compiler: nios2-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa127963f1cab2b93c74c9b128a84610203fb674 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout aa127963f1cab2b93c74c9b128a84610203fb674 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=nios2 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> lib/crypto/curve25519-selftest.c:1283:13: warning: no previous prototype for >> 'curve25519_selftest' [-Wmissing-prototypes] 1283 | bool __init curve25519_selftest(void) | ^~~ vim +/curve25519_selftest +1283 lib/crypto/curve25519-selftest.c 1282 > 1283 bool __init curve25519_selftest(void) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] dt-bindings: mfd: mediatek: Add bindings for MT6360 PMIC
Dear Reviewers,
Please let me know if there is anything need to be revised.
Gene Chen 於 2020年8月20日 週四 下午4:36寫道：
>
> From: Gene Chen
>
> Add bindings for MT6360 PMIC
>
> Signed-off-by: Gene Chen
> ---
> Documentation/devicetree/bindings/mfd/mt6360.yaml | 142
> ++
> 1 file changed, 142 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/mt6360.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/mt6360.yaml
> b/Documentation/devicetree/bindings/mfd/mt6360.yaml
> new file mode 100644
> index 000..5ad1afd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mt6360.yaml
> @@ -0,0 +1,142 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/mt6360.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MT6360 PMIC from MediaTek Integrated
> +
> +maintainers:
> + - Gene Chen
> +
> +description: |
> + MT6360 is a PMIC device with the following sub modules.
> + It is interfaced to host controller using I2C interface.
> +
> + This document describes the binding for PMIC device and its sub module.
> +
> +properties:
> + compatible:
> +const: mediatek,mt6360
> +
> + reg:
> +description:
> + I2C device address.
> +maxItems: 1
> +
> + wakeup-source: true
> +
> + interrupts:
> +maxItems: 1
> +
> + interrupt-names:
> + enum:
> +- IRQB
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> +const: 1
> +description:
> + The first cell is the IRQ number.
> +
> + regulator:
> +$ref: ../regulator/mt6360-regulator.yaml
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +mt6360@34 {
> +compatible = "mediatek,mt6360";
> +reg = <0x34>;
> +wakeup-source;
> +interrupts-extended = < 0 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-names = "IRQB";
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +regulator {
> +compatible = "mediatek,mt6360-regulator";
> +LDO_VIN3-supply = <>;
> +buck1 {
> +regulator-compatible = "BUCK1";
> +regulator-name = "mt6360,buck1";
> +regulator-min-microvolt = <30>;
> +regulator-max-microvolt = <130>;
> +regulator-allowed-modes = + MT6360_OPMODE_LP
> + MT6360_OPMODE_ULP>;
> +};
> +BUCK2: buck2 {
> +regulator-compatible = "BUCK2";
> +regulator-name = "mt6360,buck2";
> +regulator-min-microvolt = <30>;
> +regulator-max-microvolt = <130>;
> +regulator-allowed-modes = + MT6360_OPMODE_LP
> + MT6360_OPMODE_ULP>;
> +};
> +ldo6 {
> +regulator-compatible = "LDO6";
> +regulator-name = "mt6360,ldo6";
> +regulator-min-microvolt = <50>;
> +regulator-max-microvolt = <210>;
> +regulator-allowed-modes = + MT6360_OPMODE_LP>;
> +};
> +ldo7 {
> +regulator-compatible = "LDO7";
> +regulator-name = "mt6360,ldo7";
> +regulator-min-microvolt = <50>;
> +regulator-max-microvolt = <210>;
> +regulator-allowed-modes = + MT6360_OPMODE_LP>;
> +};
> +ldo1 {
> +regulator-compatible = "LDO1";
> +regulator-name = "mt6360,ldo1";
> +regulator-min-microvolt = <120>;
> +regulator-max-microvolt = <360>;
> +regulator-allowed-modes = + MT6360_OPMODE_LP>;
> +};
> +ldo2 {
> +regulator-compatible = "LDO2";
> +regulator-name = "mt6360,ldo2";
> +regulator-min-microvolt = <120>;
> +regulator-max-microvolt = <360>;
> +regulator-allowed-modes = + MT6360_OPMODE_LP>;
> +};
> +ldo3 {
> +regulator-compatible = "LDO3";
> +
Re: [RESEND PATCH] arm64: dts: ti: k3-j7200-mcu-wakeup: Enable ADC support
On 29/10/20 10:39 AM, Vignesh Raghavendra wrote: > J7200 has a single instance of 8 channel ADC in MCU domain. Add DT node > for the same. > > Signed-off-by: Vignesh Raghavendra Reviewed-by: Sekhar Nori Thanks, Sekhar
Re: KASAN: vmalloc-out-of-bounds Read in bpf_trace_run3
On Wed, Nov 11, 2020 at 03:57:50PM +0100, Dmitry Vyukov wrote:
> On Mon, Nov 2, 2020 at 12:54 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:080b6f40 bpf: Don't rely on GCC __attribute__((optimize)) ..
> > git tree: bpf
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1089d37c50
> > kernel config: https://syzkaller.appspot.com/x/.config?x=58a4ca757d776bfe
> > dashboard link: https://syzkaller.appspot.com/bug?extid=d29e58bb557324e55e5e
> > compiler: gcc (GCC) 10.1.0-syz 20200507
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10f4b03250
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1371a47c50
> >
> > The issue was bisected to:
> >
> > commit 9df1c28bb75217b244257152ab7d788bb2a386d0
> > Author: Matt Mullins
> > Date: Fri Apr 26 18:49:47 2019 +
> >
> > bpf: add writable context for raw tracepoints
>
>
> We have a number of kernel memory corruptions related to bpf_trace_run now:
> https://groups.google.com/g/syzkaller-bugs/search?q=kernel%2Ftrace%2Fbpf_trace.c
>
> Can raw tracepoints "legally" corrupt kernel memory (a-la /dev/kmem)?
> Or they shouldn't?
>
> Looking at the description of Matt's commit, it seems that corruptions
> should not be possible (bounded buffer, checked size, etc). Then it
> means it's a real kernel bug?
This bug doesn't seem to be related to the writability of the
tracepoint; it bisected to that commit simply because it used
BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE for the reproducer and it EINVAL's
before that program type was introduced. The BPF program it loads is
pretty much a no-op.
The problem here is a kmalloc failure injection into
tracepoint_probe_unregister, but the error is ignored -- so the bpf
program is freed even though the tracepoint is never unregistered.
I have a first pass at a patch to pipe through the error code, but it's
pretty ugly. It's also called from the file_operations ->release(), for
which errors are solidly ignored in __fput(), so I'm not sure what the
best way to handle ENOMEM is...
>
>
>
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12b6c4da50
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=11b6c4da50
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16b6c4da50
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+d29e58bb557324e55...@syzkaller.appspotmail.com
> > Fixes: 9df1c28bb752 ("bpf: add writable context for raw tracepoints")
> >
> > ==
> > BUG: KASAN: vmalloc-out-of-bounds in __bpf_trace_run
> > kernel/trace/bpf_trace.c:2045 [inline]
> > BUG: KASAN: vmalloc-out-of-bounds in bpf_trace_run3+0x3e0/0x3f0
> > kernel/trace/bpf_trace.c:2083
> > Read of size 8 at addr c9e6c030 by task kworker/0:3/3754
> >
> > CPU: 0 PID: 3754 Comm: kworker/0:3 Not tainted 5.9.0-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: 0x0 (events)
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x107/0x163 lib/dump_stack.c:118
> > print_address_description.constprop.0.cold+0x5/0x4c8 mm/kasan/report.c:385
> > __kasan_report mm/kasan/report.c:545 [inline]
> > kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
> > __bpf_trace_run kernel/trace/bpf_trace.c:2045 [inline]
> > bpf_trace_run3+0x3e0/0x3f0 kernel/trace/bpf_trace.c:2083
> > __bpf_trace_sched_switch+0xdc/0x120 include/trace/events/sched.h:138
> > __traceiter_sched_switch+0x64/0xb0 include/trace/events/sched.h:138
> > trace_sched_switch include/trace/events/sched.h:138 [inline]
> > __schedule+0xeb8/0x2130 kernel/sched/core.c:4520
> > schedule+0xcf/0x270 kernel/sched/core.c:4601
> > worker_thread+0x14c/0x1120 kernel/workqueue.c:2439
> > kthread+0x3af/0x4a0 kernel/kthread.c:292
> > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
> >
> >
> > Memory state around the buggy address:
> > c9e6bf00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > c9e6bf80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > >c9e6c000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > ^
> > c9e6c080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > c9e6c100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > ==
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > syzbot can test patches
[PATCH] panic: Avoid dump_stack() twice
stacktrace will be dumped twice on ARM64 after commit 3f388f28639f
("panic: dump registers on panic_on_warn"), will not dump_stack
when no regs as before.
Fixes: 3f388f28639f ("panic: dump registers on panic_on_warn")
Signed-off-by: Kefeng Wang
---
kernel/panic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 396142ee43fd..332736a72a58 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -605,7 +605,8 @@ void __warn(const char *file, int line, void *caller,
unsigned taint,
panic("panic_on_warn set ...\n");
}
- dump_stack();
+ if (!regs)
+ dump_stack();
print_irqtrace_events(current);
--
2.26.2
linux-next: build failure after merge of the usb-chipidea-next tree
Hi all,
After merging the usb-chipidea-next tree, today's linux-next build
(powerpc allyesconfig) failed like this:
In file included from drivers/usb/chipidea/trace.h:18,
from drivers/usb/chipidea/trace.c:11:
drivers/usb/chipidea/ci.h: In function 'ci_otg_is_fsm_mode':
drivers/usb/chipidea/ci.h:440:47: error: invalid use of undefined type 'struct
ci_hdrc_platform_data'
440 | struct usb_otg_caps *otg_caps = >platdata->ci_otg_caps;
| ^~
Caused by commit
87a6b8617a72 ("usb: chipidea: add tracepoint support for udc")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpzXp_iWpun2.pgp
Description: OpenPGP digital signature
Re: [PATCH] hugetlbfs: fix anon huge page migration race
On Thu, Nov 05, 2020 at 11:50:58AM -0800, Mike Kravetz wrote:
> Qian Cai reported the following BUG in [1]
>
> [ 6147.019063][T45242] LTP: starting move_pages12
> [ 6147.475680][T64921] BUG: unable to handle page fault for address:
> ffe0
> ...
> [ 6147.525866][T64921] RIP: 0010:anon_vma_interval_tree_iter_first+0xa2/0x170
> avc_start_pgoff at mm/interval_tree.c:63
> [ 6147.620914][T64921] Call Trace:
> [ 6147.624078][T64921] rmap_walk_anon+0x141/0xa30
> rmap_walk_anon at mm/rmap.c:1864
> [ 6147.628639][T64921] try_to_unmap+0x209/0x2d0
> try_to_unmap at mm/rmap.c:1763
> [ 6147.633026][T64921] ? rmap_walk_locked+0x140/0x140
> [ 6147.637936][T64921] ? page_remove_rmap+0x1190/0x1190
> [ 6147.643020][T64921] ? page_not_mapped+0x10/0x10
> [ 6147.647668][T64921] ? page_get_anon_vma+0x290/0x290
> [ 6147.652664][T64921] ? page_mapcount_is_zero+0x10/0x10
> [ 6147.657838][T64921] ? hugetlb_page_mapping_lock_write+0x97/0x180
> [ 6147.663972][T64921] migrate_pages+0x1005/0x1fb0
> [ 6147.668617][T64921] ? remove_migration_pte+0xac0/0xac0
> [ 6147.673875][T64921] move_pages_and_store_status.isra.47+0xd7/0x1a0
> [ 6147.680181][T64921] ? migrate_pages+0x1fb0/0x1fb0
> [ 6147.685002][T64921] __x64_sys_move_pages+0xa5c/0x1100
> [ 6147.690176][T64921] ? trace_hardirqs_on+0x20/0x1b5
> [ 6147.695084][T64921] ? move_pages_and_store_status.isra.47+0x1a0/0x1a0
> [ 6147.701653][T64921] ? rcu_read_lock_sched_held+0xaa/0xd0
> [ 6147.707088][T64921] ? switch_fpu_return+0x196/0x400
> [ 6147.712083][T64921] ? lockdep_hardirqs_on_prepare+0x38c/0x550
> [ 6147.717954][T64921] ? do_syscall_64+0x24/0x310
> [ 6147.722513][T64921] do_syscall_64+0x5f/0x310
> [ 6147.726897][T64921] ? trace_hardirqs_off+0x12/0x1a0
> [ 6147.731894][T64921] ? asm_exc_page_fault+0x8/0x30
> [ 6147.736714][T64921] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Hugh Dickens diagnosed this as a migration bug caused by code introduced
> to use i_mmap_rwsem for pmd sharing synchronization. Specifically, the
> routine unmap_and_move_huge_page() is always passing the TTU_RMAP_LOCKED
> flag to try_to_unmap() while holding i_mmap_rwsem. This is wrong for
> anon pages as the anon_vma_lock should be held in this case. Further
> analysis suggested that i_mmap_rwsem was not required to he held at all
> when calling try_to_unmap for anon pages as an anon page could never be
> part of a shared pmd mapping.
>
> Discussion also revealed that the hack in hugetlb_page_mapping_lock_write
> to drop page lock and acquire i_mmap_rwsem is wrong. There is no way to
> keep mapping valid while dropping page lock.
>
> This patch does the following:
> - Do not take i_mmap_rwsem and set TTU_RMAP_LOCKED for anon pages when
> calling try_to_unmap.
> - Remove the hacky code in hugetlb_page_mapping_lock_write. The routine
> will now simply do a 'trylock' while still holding the page lock. If
> the trylock fails, it will return NULL. This could impact the callers:
> - migration calling code will receive -EAGAIN and retry up to the hard
> coded limit (10).
> - memory error code will treat the page as BUSY. This will force
> killing (SIGKILL) instead of SIGBUS any mapping tasks.
> Do note that this change in behavior only happens when there is a race.
> None of the standard kernel testing suites actually hit this race, but
> it is possible.
>
> [1] https://lore.kernel.org/lkml/20200708012044.gc...@lca.pw/
> [2]
> https://lore.kernel.org/linux-mm/alpine.LSU.2.11.2010071833100.2214@eggly.anvils/
>
> Reported-by: Qian Cai
> Suggested-by: Hugh Dickins
> Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
> synchronization")
> Cc:
> Signed-off-by: Mike Kravetz
This approch looks simpler and better than former ones.
Thank you for the update.
Acked-by: Naoya Horiguchi
Re: [PATCH 0/7] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
On Fri, Nov 13, 2020 at 1:40 AM Chuanhong Guo wrote: > > On Thu, Nov 12, 2020 at 1:23 PM Sergio Paracuellos > wrote: > > > > To avoid weird behaviour because of some drivers are > > not using properly clocks we have the CLK_IGNORED_UNUSED, which as you > > can see is currently being used in my code. Using that all seems to > > work as expected as it is now. > > The whole point of having a clock gate driver is to gate unused > clocks to save (maybe a tiny bit of) power. It's other peripheral > drivers' fault that it doesn't enable clocks properly and we shouldn't > just work-around the problem in the clock driver by disallowing auto > clock gating. > Totally agreed with what you are saying here but I don't really think using the flag is a workaround. It is just a way to ensure no regressions occurred until all drivers are adapted and also having all of them enabled is the behaviour. For me adapt the rest of driver code should be a different patch set after this driver is properly finished and mainlined. > -- > Regards, > Chuanhong Guo Best regards, Sergio Paracuellos
Re: [PATCH] scsi: ufs: Add retry flow for failed hba enabling
On 2020-11-12 13:45, Stanley Chu wrote:
Once hba enabling is failed, add retry mechanism and in the
meanwhile allow vendors to apply specific handlings before
the next retry. For example, vendors can do vendor-specific
host reset flow in variant function "ufshcd_vops_hce_enable_notify()".
Signed-off-by: Stanley Chu
Reviewed-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 8001bbfec5c0..9186ee01379a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4328,8 +4328,10 @@ static inline void ufshcd_hba_stop(struct
ufs_hba *hba)
*/
static int ufshcd_hba_execute_hce(struct ufs_hba *hba)
{
- int retry;
+ int retry_outer = 3;
+ int retry_inner;
+start:
if (!ufshcd_is_hba_active(hba))
/* change controller state to "reset state" */
ufshcd_hba_stop(hba);
@@ -4355,13 +4357,17 @@ static int ufshcd_hba_execute_hce(struct
ufs_hba *hba)
ufshcd_delay_us(hba->vps->hba_enable_delay_us, 100);
/* wait for the host controller to complete initialization */
- retry = 50;
+ retry_inner = 50;
while (ufshcd_is_hba_active(hba)) {
- if (retry) {
- retry--;
+ if (retry_inner) {
+ retry_inner--;
} else {
dev_err(hba->dev,
"Controller enable failed\n");
+ if (retry_outer) {
+ retry_outer--;
+ goto start;
+ }
return -EIO;
}
usleep_range(1000, 1100);
Re: linux-x25 mail list not working
On 2020-11-13 03:17, John 'Warthog9' Hawley wrote: Give it a try now, there was a little wonkiness with the alias setup for it, and I have no historical context for a 'why', but I adjusted a couple of things and I was able to subscribe myself. - John 'Warthog9' Hawley Thanks a lot John! Now it seems to work again. - Martin On 11/12/2020 10:27 AM, Xie He wrote: Hi Linux maintainers, The linux-x25 mail list doesn't seem to be working. We sent a lot of emails to linux-x25 but Martin Schiller as a subscriber hasn't received a single email from the mail list. Looking at the mail list archive at: https://www.spinics.net/lists/linux-x25/ I see the last email in the archive was in 2009. It's likely that this mail list has stopped working since 2009. Can you please help fix this mail list. Thanks! Xie He
Re: [PATCH v6 1/2] kunit: Support for Parameterized Testing
On Thu, Nov 12, 2020 at 8:37 PM Marco Elver wrote: > > On Thu, Nov 12, 2020 at 04:18PM +0800, David Gow wrote: > > On Thu, Nov 12, 2020 at 12:55 AM Bird, Tim wrote: > [...] > > > > kunit_tool has a bug when parsing the comments / diagnostic lines, > > > > which requires a ": " to be present. This is a bug, which is being > > > > fixed[1], so while it's _nice_ to not trigger it, it's not really an > > > > important long-term goal of the format. In any case, this kunit_tool > > > > issue only affects the comment lines: if the per-parameter result line > > > > is an actual result, rather than just a diagnostic, this shouldn't be > > > > a problem. > > > > > > > > In any case, I still prefer my proposed option for now -- noting that > > > > these per-parameter results are not actually supposed to be parsed -- > > > > with then the possibility of expanding them to actual nested results > > > > later should we wish. But if the idea of having TAP-like lines in > > > > diagnostics seems too dangerous (e.g. because people will try to parse > > > > them anyway), then I think the options we have are to stick to the > > > > output format given in the current version of this patch (which > > > > doesn't resemble a TAP result), make each parameterised version its > > > > own test (without a "container test", which would require a bit of > > > > extra work while computing test plans), or to hold this whole feature > > > > back until we can support arbitrary test hierarchies in KUnit. > > > It seems like you're missing a 4th option, which is just tack the > > > parameter > > > name on, without using a colon, and have these testcases treated > > > as unique within the context of the super-test. Is there some reason > > > these can't be expressed as individual testcases in the parent test? > > > > > > > No: there's no fundamental reason why we couldn't do that, though > > there are some things which make it suboptiomal, IMHO. > > > > Firstly, there could be a lot of parameters, and that by not grouping > > them together it could make dealing with the results a little > > unwieldy. The other side of that is that it'll result in tests being > > split up and renamed as they're ported to use this, whereas if the > > whole test shows up once (with subtests or without), the old test name > > can still be there, with a single PASS/FAIL for the whole test. > > Agree, it's suboptimal and having the parameterized not be absorbed by > the whole suite would be strongly preferred. > > > (It also might be a little tricky with the current implementation to > > produce the test plan, as the parameters come from a generator, and I > > don't think there's a way of getting the number of parameters ahead of > > time. That's a problem with the sub-subtest model, too, though at > > least there it's a little more isolated from other tests.) > > The whole point of generators, as I envisage it, is to also provide the > ability for varying parameters dependent on e.g. environment, > configuration, number of CPUs, etc. The current array-based generator is > the simplest possible use-case. > > However, we *can* require generators generate a deterministic number of > parameters when called multiple times on the same system. I think this is a reasonable compromise, though it's not actually essential. As I understand the TAP spec, the test plan is actually optional (and/or can be at the end of the sequence of tests), though kunit_tool currently only supports having it at the beginning (which is strongly preferred by the spec anyway). I think we could get away with having it at the bottom of the subtest results though, which would save having to run the generator twice, when subtest support is added to kunit_tool. > To that end, I propose a v7 (below) that takes care of getting number of > parameters (and also displays descriptions for each parameter where > available). > > Now it is up to you how you want to turn the output from diagnostic > lines into something TAP compliant, because now we have the number of > parameters and can turn it into a subsubtest. But I think kunit-tool > doesn't understand subsubtests yet, so I suggest we take these patches, > and then somebody can prepare kunit-tool. > This sounds good to me. The only thing I'm not sure about is the format of the parameter description: thus far test names be valid C identifier names, due to the fact they're named after the test function. I don't think there's a fundamental reason parameters (and hence, potentially, subsubtests) need to follow that convention as well, but it does look a bit odd. Equally, the square brackets around the description shouldn't be necessary according to the TAP spec, but do seem to make things a little more readable, particuarly with the names in the ext4 inode test. I'm not too worried about either of those, though: I'm sure it'll look fine once I've got used to it. > Or did I miss something else? > > > > > Personally, I'd rather not hold this feature
Re: [PATCH 3/3] powerpc: rewrite atomics to use ARCH_ATOMIC
Hi Nicholas, I love your patch! Perhaps something to improve: [auto build test WARNING on powerpc/next] [also build test WARNING on asm-generic/master linus/master v5.10-rc3 next-20201112] [cannot apply to scottwood/next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-convert-to-use-ARCH_ATOMIC/2020-190941 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc64-randconfig-s031-2020 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-107-gaf3512a6-dirty # https://github.com/0day-ci/linux/commit/9e1bec8fe216b0745c647e52c40d1f0033fb4efd git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Nicholas-Piggin/powerpc-convert-to-use-ARCH_ATOMIC/2020-190941 git checkout 9e1bec8fe216b0745c647e52c40d1f0033fb4efd # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> drivers/gpu/drm/drm_lock.c:75:24: sparse: sparse: incorrect type in argument >> 1 (different modifiers) @@ expected void *ptr @@ got unsigned int >> volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:75:24: sparse: expected void *ptr >> drivers/gpu/drm/drm_lock.c:75:24: sparse: got unsigned int volatile >> *__ai_ptr >> drivers/gpu/drm/drm_lock.c:75:24: sparse: sparse: incorrect type in argument >> 1 (different modifiers) @@ expected void *ptr @@ got unsigned int >> volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:75:24: sparse: expected void *ptr >> drivers/gpu/drm/drm_lock.c:75:24: sparse: got unsigned int volatile >> *__ai_ptr drivers/gpu/drm/drm_lock.c:118:24: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void *ptr @@ got unsigned int volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:118:24: sparse: expected void *ptr drivers/gpu/drm/drm_lock.c:118:24: sparse: got unsigned int volatile *__ai_ptr drivers/gpu/drm/drm_lock.c:118:24: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void *ptr @@ got unsigned int volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:118:24: sparse: expected void *ptr drivers/gpu/drm/drm_lock.c:118:24: sparse: got unsigned int volatile *__ai_ptr drivers/gpu/drm/drm_lock.c:141:24: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void *ptr @@ got unsigned int volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:141:24: sparse: expected void *ptr drivers/gpu/drm/drm_lock.c:141:24: sparse: got unsigned int volatile *__ai_ptr drivers/gpu/drm/drm_lock.c:141:24: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void *ptr @@ got unsigned int volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:141:24: sparse: expected void *ptr drivers/gpu/drm/drm_lock.c:141:24: sparse: got unsigned int volatile *__ai_ptr drivers/gpu/drm/drm_lock.c:319:40: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void *ptr @@ got unsigned int volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:319:40: sparse: expected void *ptr drivers/gpu/drm/drm_lock.c:319:40: sparse: got unsigned int volatile *__ai_ptr drivers/gpu/drm/drm_lock.c:319:40: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void *ptr @@ got unsigned int volatile *__ai_ptr @@ drivers/gpu/drm/drm_lock.c:319:40: sparse: expected void *ptr drivers/gpu/drm/drm_lock.c:319:40: sparse: got unsigned int volatile *__ai_ptr vim +75 drivers/gpu/drm/drm_lock.c 4ac5ec40ec70022 Daniel Vetter 2010-08-23 48 bd50d4a2168370b Benjamin Gaignard 2020-03-06 49 /* 1a75a222f5ca106 Daniel Vetter 2016-06-14 50 * Take the heavyweight lock. 1a75a222f5ca106 Daniel Vetter 2016-06-14 51 * 1a75a222f5ca106 Daniel Vetter 2016-06-14 52 * \param lock lock pointer. 1a75a222f5ca106 Daniel Vetter 2016-06-14 53 * \param context locking context. 1a75a222f5ca106 Daniel Vetter 2016-06-14 54 * \return one if the lock is held, or zero otherwise. 1a75a222f5ca106 Daniel Vetter 2016-06-14 55 * 1a75a222f5
Re: [PATCH] scsi: ufs: Fix a bug in ufshcd_system_resume()
On 2020-11-10 16:55, Yang Yang wrote:
During system resume, ufshcd_system_resume() won't resume UFS host if
runtime suspended. After that, scsi_bus_resume() try to set SCSI host's
RPM status to RPM_ACTIVE, this will fail because UFS host's RPM status
is still RPM_SUSPENDED. So fix it.
scsi host0: scsi_runtime_suspend()
ufshcd_runtime_suspend()
scsi host0: scsi_bus_suspend()
ufshcd_system_suspend()
--
ufshcd_pltfrm_resume()
scsi host0: scsi_bus_resume()
scsi host0: scsi_bus_resume_common()
scsi host0: pm_runtime_set_active(dev)
scsi host0: runtime PM trying to activate child device host0 but
parent
(880.ufshc) is not active
Fixes: 57d104c153d3 ("ufs: add UFS power management support")
Signed-off-by: Yang Yang
---
drivers/scsi/ufs/ufshcd.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8f573a02713..9e666e1ad58c 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8767,11 +8767,7 @@ int ufshcd_system_resume(struct ufs_hba *hba)
if (!hba)
return -EINVAL;
- if (!hba->is_powered || pm_runtime_suspended(hba->dev))
- /*
-* Let the runtime resume take care of resuming
-* if runtime suspended.
-*/
+ if (!hba->is_powered)
goto out;
else
ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
@@ -8779,8 +8775,15 @@ int ufshcd_system_resume(struct ufs_hba *hba)
trace_ufshcd_system_resume(dev_name(hba->dev), ret,
ktime_to_us(ktime_sub(ktime_get(), start)),
hba->curr_dev_pwr_mode, hba->uic_link_state);
- if (!ret)
+ if (!ret) {
hba->is_sys_suspended = false;
+
+ if (pm_runtime_suspended(hba->dev)) {
+ pm_runtime_disable(hba->dev);
+ pm_runtime_set_active(hba->dev);
+ pm_runtime_enable(hba->dev);
+ }
+ }
return ret;
}
EXPORT_SYMBOL(ufshcd_system_resume);
It is designed like this - if hba is runtime suspend, do not resume it
during system resume, which is the so called deferred resume feature.
This is to leave the runtime PM management to block layer PM, which
is more power efficiency.
scsi host0: runtime PM trying to activate child device host0 but parent
(880.ufshc) is not active
The log is not harmful or fatal, maybe just annoying. Do you see real
problem with it? If yes, please share it here.
Thanks,
Can Guo.
[PATCH] perf stat: Use proper cpu for shadow stats
Currently perf stat shows some metrics (like IPC) for defined events.
But when no aggregation mode is used (-A option), it shows incorrect
values since it used a value from a different cpu.
Before:
$ perf stat -aA -e cycles,instructions sleep 1
Performance counter stats for 'system wide':
CPU0 116,057,380 cycles
CPU1 86,084,722 cycles
CPU2 99,423,125 cycles
CPU3 98,272,994 cycles
CPU0 53,369,217 instructions #0.46 insn per cycle
CPU1 33,378,058 instructions #0.29 insn per cycle
CPU2 58,150,086 instructions #0.50 insn per cycle
CPU3 40,029,703 instructions #0.34 insn per cycle
1.001816971 seconds time elapsed
So the IPC for CPU1 should be 0.38 (= 33,378,058 / 86,084,722)
but it was 0.29 (= 33,378,058 / 116,057,380) and so on.
After:
$ perf stat -aA -e cycles,instructions sleep 1
Performance counter stats for 'system wide':
CPU0 109,621,384 cycles
CPU1 159,026,454 cycles
CPU2 99,460,366 cycles
CPU3 124,144,142 cycles
CPU0 44,396,706 instructions #0.41 insn per cycle
CPU1 120,195,425 instructions #0.76 insn per cycle
CPU2 44,763,978 instructions #0.45 insn per cycle
CPU3 69,049,079 instructions #0.56 insn per cycle
1.001910444 seconds time elapsed
Reported-by: Sam Xi
Fixes: 44d49a600259 ("perf stat: Support metrics in --per-core/socket mode")
Signed-off-by: Namhyung Kim
---
tools/perf/util/stat-display.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index 4b57c0c07632..a963b5b8eb72 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -324,13 +324,10 @@ static int first_shadow_cpu(struct perf_stat_config
*config,
struct evlist *evlist = evsel->evlist;
int i;
- if (!config->aggr_get_id)
- return 0;
-
if (config->aggr_mode == AGGR_NONE)
return id;
- if (config->aggr_mode == AGGR_GLOBAL)
+ if (!config->aggr_get_id)
return 0;
for (i = 0; i < evsel__nr_cpus(evsel); i++) {
--
2.29.2.299.gdc1121823c-goog
[GIT PULL] more ext4 fixes for v5.10-rc4
The following changes since commit 52d1998d09af92d44ffce7454637dd3fd1afdc7d: Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt (2020-11-10 10:05:37 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus_bugfixes for you to fetch changes up to d196e229a80c39254f4adbc312f55f5198e98941: Revert "ext4: fix superblock checksum calculation race" (2020-11-11 14:24:18 -0500) Two ext4 bug fixes, one via a revert of a commit sent during the merge window. Harshad Shirwadkar (1): ext4: handle dax mount option collision Theodore Ts'o (1): Revert "ext4: fix superblock checksum calculation race" fs/ext4/ext4.h | 6 +++--- fs/ext4/super.c | 11 --- 2 files changed, 3 insertions(+), 14 deletions(-)
Re: [PATCH 24/24] perf record: Add --buildid-mmap option to enable mmap's build id
On Mon, Nov 09, 2020 at 10:54:15PM +0100, Jiri Olsa wrote:
> Adding --buildid-mmap option to enable build id in mmap2 events.
> It will only work if there's kernel support for that and it disables
> build id cache (implies --no-buildid).
>
> It's also possible to enable it permanently via config option
> in ~.perfconfig file:
>
> [record]
> build-id=mmap
You also need to update the documentation.
>
> Also added build_id bit in the verbose output for perf_event_attr:
>
> # perf record --buildid-mmap -vv
> ...
> perf_event_attr:
> type 1
> size 120
> ...
> build_id 1
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/Documentation/perf-record.txt | 3 +++
> tools/perf/builtin-record.c | 20
> tools/perf/util/evsel.c | 10 ++
> tools/perf/util/perf_api_probe.c | 10 ++
> tools/perf/util/perf_api_probe.h | 1 +
> tools/perf/util/perf_event_attr_fprintf.c | 1 +
> tools/perf/util/record.h | 1 +
> 7 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-record.txt
> b/tools/perf/Documentation/perf-record.txt
> index 76b9326a..1bcf51e24979 100644
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -482,6 +482,9 @@ Specify vmlinux path which has debuginfo.
> --buildid-all::
> Record build-id of all DSOs regardless whether it's actually hit or not.
>
> +--buildid-mmap::
> +Record build ids in mmap2 events, disables build id cache (implies
> --no-buildid).
> +
> --aio[=n]::
> Use control blocks in asynchronous (Posix AIO) trace writing mode
> (default: 1, max: 4).
> Asynchronous mode is supported only when linking Perf tool with libc library
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index adf311d15d3d..47bae9d82d43 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -102,6 +102,7 @@ struct record {
> boolno_buildid_cache;
> boolno_buildid_cache_set;
> boolbuildid_all;
> + boolbuildid_mmap;
> booltimestamp_filename;
> booltimestamp_boundary;
> struct switch_outputswitch_output;
> @@ -2139,6 +2140,8 @@ static int perf_record_config(const char *var, const
> char *value, void *cb)
> rec->no_buildid_cache = true;
> else if (!strcmp(value, "skip"))
> rec->no_buildid = true;
> + else if (!strcmp(value, "mmap"))
> + rec->buildid_mmap = true;
> else
> return -1;
> return 0;
> @@ -2554,6 +2557,8 @@ static struct option __record_options[] = {
> "file", "vmlinux pathname"),
> OPT_BOOLEAN(0, "buildid-all", _all,
> "Record build-id of all DSOs regardless of hits"),
> + OPT_BOOLEAN(0, "buildid-mmap", _mmap,
> + "Record build-id in map events"),
> OPT_BOOLEAN(0, "timestamp-filename", _filename,
> "append timestamp to output filename"),
> OPT_BOOLEAN(0, "timestamp-boundary", _boundary,
> @@ -2657,6 +2662,21 @@ int cmd_record(int argc, const char **argv)
>
> }
>
> + if (rec->buildid_mmap) {
> + if (!perf_can_record_build_id()) {
> + pr_err("Failed: no support to record build id in mmap
> events, update your kernel.\n");
> + err = -EINVAL;
> + goto out_opts;
> + }
> + pr_debug("Enabling build id in mmap2 events.\n");
> + /* Enable mmap build id synthesizing. */
> + symbol_conf.buildid_mmap2 = true;
> + /* Enable perf_event_attr::build_id bit. */
> + rec->opts.build_id = true;
> + /* Disable build id cache. */
> + rec->no_buildid = true;
I'm afraid this can make it miss some build-id in the end because of
the possibility of the failure.
> + }
> +
> if (rec->opts.kcore)
> rec->data.is_dir = true;
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 1cad6051d8b0..749d806ee1d1 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -1170,10 +1170,12 @@ void evsel__config(struct evsel *evsel, struct
> record_opts *opts,
> if (opts->sample_weight)
> evsel__set_sample_bit(evsel, WEIGHT);
>
> - attr->task = track;
> - attr->mmap = track;
> - attr->mmap2 = track && !perf_missing_features.mmap2;
> - attr->comm = track;
> + attr->task = track;
> + attr->mmap = track;
> + attr->mmap2= track && !perf_missing_features.mmap2;
> + attr->comm = track;
>
Re: [PATCH 15/24] perf tools: Synthesize build id for kernel/modules/tasks
On Mon, Nov 09, 2020 at 10:54:06PM +0100, Jiri Olsa wrote:
> Adding build id to synthesized mmap2 events for
> everything - kernel/modules/tasks.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/util/synthetic-events.c | 33 ++
> 1 file changed, 33 insertions(+)
>
> diff --git a/tools/perf/util/synthetic-events.c
> b/tools/perf/util/synthetic-events.c
> index a18ae502d765..a9d5d1ff2cad 100644
> --- a/tools/perf/util/synthetic-events.c
> +++ b/tools/perf/util/synthetic-events.c
> @@ -347,6 +347,32 @@ static bool read_proc_maps_line(struct io *io, __u64
> *start, __u64 *end,
> }
> }
>
> +static void perf_record_mmap2__read_build_id(struct perf_record_mmap2 *event,
> + bool is_kernel)
> +{
> + struct build_id bid;
> + int rc;
> +
> + if (is_kernel)
> + rc = sysfs__read_build_id("/sys/kernel/notes", );
> + else
> + rc = filename__read_build_id(event->filename, ) > 0 ? 0 :
> -1;
> +
> + if (rc == 0) {
> + memcpy(event->build_id, bid.data, sizeof(bid.data));
> + event->build_id_size = (u8) bid.size;
> + } else {
> + if (event->filename[0] == '/') {
> + pr_debug2("Failed to read build ID for %s\n",
> + event->filename);
> + }
> + memset(event->build_id, 0x0, sizeof(event->build_id));
Likewise, we should not set the misc bit here IMHO.
Thanks,
Namhyung
> + }
> + event->header.misc |= PERF_RECORD_MISC_BUILD_ID;
> + event->__reserved_1 = 0;
> + event->__reserved_2 = 0;
> +}
> +
> int perf_event__synthesize_mmap_events(struct perf_tool *tool,
> union perf_event *event,
> pid_t pid, pid_t tgid,
> @@ -453,6 +479,9 @@ int perf_event__synthesize_mmap_events(struct perf_tool
> *tool,
> event->mmap2.pid = tgid;
> event->mmap2.tid = pid;
>
> + if (symbol_conf.buildid_mmap2)
> + perf_record_mmap2__read_build_id(>mmap2, false);
> +
> if (perf_tool__process_synth_event(tool, event, machine,
> process) != 0) {
> rc = -1;
> break;
> @@ -630,6 +659,8 @@ int perf_event__synthesize_modules(struct perf_tool
> *tool, perf_event__handler_t
>
> memcpy(event->mmap2.filename, pos->dso->long_name,
> pos->dso->long_name_len + 1);
> +
> + perf_record_mmap2__read_build_id(>mmap2, false);
> } else {
> size = PERF_ALIGN(pos->dso->long_name_len + 1,
> sizeof(u64));
> event->mmap.header.type = PERF_RECORD_MMAP;
> @@ -1050,6 +1081,8 @@ static int __perf_event__synthesize_kernel_mmap(struct
> perf_tool *tool,
> event->mmap2.start = map->start;
> event->mmap2.len = map->end - event->mmap.start;
> event->mmap2.pid = machine->pid;
> +
> + perf_record_mmap2__read_build_id(>mmap2, true);
> } else {
> size = snprintf(event->mmap.filename,
> sizeof(event->mmap.filename),
> "%s%s", machine->mmap_name,
> kmap->ref_reloc_sym->name) + 1;
> --
> 2.26.2
>
Re: [PATCH 03/24] perf: Add build id data in mmap2 event
Hi Jiri,
On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote:
> Adding support to carry build id data in mmap2 event.
>
> The build id data replaces maj/min/ino/ino_generation
> fields, whichc are also used to identify map's binary,
> so it's ok to replace them with build id data:
>
> union {
> struct {
> u32 maj;
> u32 min;
> u64 ino;
> u64 ino_generation;
> };
> struct {
> u8build_id[20];
> u8build_id_size;
> u8__reserved_1;
> u16 __reserved_2;
> };
> };
>
> Replaced maj/min/ino/ino_generation fields give us size
> of 24 bytes. We use 20 bytes for build id data, 1 byte
> for size and rest is unused.
>
> There's new misc bit for mmap2 to signal there's build
> id data in it:
>
> #define PERF_RECORD_MISC_BUILD_ID (1 << 14)
>
> Signed-off-by: Jiri Olsa
> ---
[SNIP]
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index da467e1dd49a..808473b6ce85 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -51,6 +51,7 @@
> #include
> #include
> #include
> +#include
>
> #include "internal.h"
>
> @@ -395,6 +396,7 @@ static atomic_t nr_ksymbol_events __read_mostly;
> static atomic_t nr_bpf_events __read_mostly;
> static atomic_t nr_cgroup_events __read_mostly;
> static atomic_t nr_text_poke_events __read_mostly;
> +static atomic_t nr_build_id_events __read_mostly;
>
> static LIST_HEAD(pmus);
> static DEFINE_MUTEX(pmus_lock);
> @@ -4672,6 +4674,8 @@ static void unaccount_event(struct perf_event *event)
> dec = true;
> if (event->attr.mmap || event->attr.mmap_data)
> atomic_dec(_mmap_events);
> + if (event->attr.build_id)
> + atomic_dec(_build_id_events);
> if (event->attr.comm)
> atomic_dec(_comm_events);
> if (event->attr.namespaces)
> @@ -7942,6 +7946,8 @@ struct perf_mmap_event {
> u64 ino;
> u64 ino_generation;
> u32 prot, flags;
> + u8 build_id[BUILD_ID_SIZE];
> + u32 build_id_size;
>
> struct {
> struct perf_event_headerheader;
> @@ -7997,13 +8003,23 @@ static void perf_event_mmap_output(struct perf_event
> *event,
> mmap_event->event_id.pid = perf_event_pid(event, current);
> mmap_event->event_id.tid = perf_event_tid(event, current);
>
> + if (event->attr.mmap2 && event->attr.build_id)
> + mmap_event->event_id.header.misc |= PERF_RECORD_MISC_BUILD_ID;
> +
> perf_output_put(, mmap_event->event_id);
>
> if (event->attr.mmap2) {
> - perf_output_put(, mmap_event->maj);
> - perf_output_put(, mmap_event->min);
> - perf_output_put(, mmap_event->ino);
> - perf_output_put(, mmap_event->ino_generation);
> + if (event->attr.build_id) {
> + u8 size[4] = { (u8) mmap_event->build_id_size, 0, 0, 0
> };
> +
> + __output_copy(, mmap_event->build_id,
> BUILD_ID_SIZE);
> + __output_copy(, size, 4);
> + } else {
> + perf_output_put(, mmap_event->maj);
> + perf_output_put(, mmap_event->min);
> + perf_output_put(, mmap_event->ino);
> + perf_output_put(, mmap_event->ino_generation);
> + }
> perf_output_put(, mmap_event->prot);
> perf_output_put(, mmap_event->flags);
> }
> @@ -8132,6 +8148,11 @@ static void perf_event_mmap_event(struct
> perf_mmap_event *mmap_event)
>
> mmap_event->event_id.header.size = sizeof(mmap_event->event_id) + size;
>
> + if (atomic_read(_build_id_events)) {
> + build_id_parse_size(vma, mmap_event->build_id,
> + _event->build_id_size);
This can fail, right? Then we need to fallback to use dev/ino..
Thanks,
Namhyung
> + }
> +
> perf_iterate_sb(perf_event_mmap_output,
> mmap_event,
> NULL);
> @@ -11069,6 +11090,8 @@ static void account_event(struct perf_event *event)
> inc = true;
> if (event->attr.mmap || event->attr.mmap_data)
> atomic_inc(_mmap_events);
> + if (event->attr.build_id)
> + atomic_inc(_build_id_events);
> if (event->attr.comm)
> atomic_inc(_comm_events);
> if (event->attr.namespaces)
> --
> 2.26.2
>
Re: [PATCH] bpf: Expose a bpf_sock_from_file helper to tracing programs
Hi Florent, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on bpf-next/master] [also build test WARNING on next-20201112] [cannot apply to bpf/master linus/master v5.10-rc3] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Florent-Revest/bpf-Expose-a-bpf_sock_from_file-helper-to-tracing-programs/20201113-041233 base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master config: i386-randconfig-s001-2020 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-107-gaf3512a6-dirty # https://github.com/0day-ci/linux/commit/7fd0725829bee29729e56964e32cad7eb9dc9a85 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Florent-Revest/bpf-Expose-a-bpf_sock_from_file-helper-to-tracing-programs/20201113-041233 git checkout 7fd0725829bee29729e56964e32cad7eb9dc9a85 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> kernel/trace/bpf_trace.c:1267:29: sparse: sparse: symbol >> 'bpf_sock_from_file_proto' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[RFC PATCH] bpf: bpf_sock_from_file_proto can be static
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
bpf_trace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 4749575b81b2d1..c34c81095d61c1 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1264,7 +1264,7 @@ BTF_ID_LIST(bpf_sock_from_file_btf_ids)
BTF_ID(struct, socket)
BTF_ID(struct, file)
-const struct bpf_func_proto bpf_sock_from_file_proto = {
+static const struct bpf_func_proto bpf_sock_from_file_proto = {
.func = bpf_sock_from_file,
.gpl_only = true,
.ret_type = RET_PTR_TO_BTF_ID_OR_NULL,
Re: [External] Re: [PATCH v3 05/21] mm/hugetlb: Introduce pgtable allocation/freeing helpers
On Fri, Nov 13, 2020 at 8:38 AM Mike Kravetz wrote:
>
> On 11/10/20 7:41 PM, Muchun Song wrote:
> > On Wed, Nov 11, 2020 at 8:47 AM Mike Kravetz
> > wrote:
> >>
> >> On 11/8/20 6:10 AM, Muchun Song wrote:
> >> I am reading the code incorrectly it does not appear page->lru (of the huge
> >> page) is being used for this purpose. Is that correct?
> >>
> >> If it is correct, would using page->lru of the huge page make this code
> >> simpler? I am just missing the reason why you are using
> >> page_huge_pte(page)->lru
> >
> > For 1GB HugeTLB pages, we should pre-allocate more than one page
> > table. So I use a linked list. The page_huge_pte(page) is the list head.
> > Because the page->lru shares storage with page->pmd_huge_pte.
>
> Sorry, but I do not understand the statement page->lru shares storage with
> page->pmd_huge_pte. Are you saying they are both in head struct page of
> the huge page?
>
> Here is what I was suggesting. If we just use page->lru for the list
> then vmemmap_pgtable_prealloc() could be coded like the following:
>
> static int vmemmap_pgtable_prealloc(struct hstate *h, struct page *page)
> {
> struct page *pte_page, *t_page;
> unsigned int nr = pgtable_pages_to_prealloc_per_hpage(h);
>
> if (!nr)
> return 0;
>
> /* Store preallocated pages on huge page lru list */
> INIT_LIST_HEAD(>lru);
>
> while (nr--) {
> pte_t *pte_p;
>
> pte_p = pte_alloc_one_kernel(_mm);
> if (!pte_p)
> goto out;
> list_add(_to_page(pte_p)->lru, >lru);
> }
>
> return 0;
> out:
> list_for_each_entry_safe(pte_page, t_page, >lru, lru)
> pte_free_kernel(_mm, page_to_virt(pte_page));
> return -ENOMEM;
> }
>
> By doing this we could eliminate the routines,
> vmemmap_pgtable_init()
> vmemmap_pgtable_deposit()
> vmemmap_pgtable_withdraw()
> and simply use the list manipulation routines.
Now I know what you mean. Yeah, just use page->lru can make code
simply. Thanks for your suggestions.
>
> To me, that looks simpler than the proposed code in this patch.
> --
> Mike Kravetz
--
Yours,
Muchun
Re: [PATCH] drm/i915/gvt: return error when failing to take the module reference
On 2020.11.12 21:22:32 +0800, Xiongfeng Wang wrote:
> When we fail to take the module reference, we go to the 'undo*' branch and
> return. But the returned variable 'ret' has been set as zero by the
> above code. Change 'ret' to '-ENODEV' in this situation.
>
> Fixes: 9bdb073464d6 ("drm/i915/gvt: Change KVMGT as self load module")
> Reported-by: Hulk Robot
> Signed-off-by: Xiongfeng Wang
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index ad8a9df..778eb8c 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -829,8 +829,10 @@ static int intel_vgpu_open(struct mdev_device *mdev)
> /* Take a module reference as mdev core doesn't take
>* a reference for vendor driver.
>*/
> - if (!try_module_get(THIS_MODULE))
> + if (!try_module_get(THIS_MODULE)) {
> + ret = -ENODEV;
> goto undo_group;
> + }
>
> ret = kvmgt_guest_init(mdev);
> if (ret)
> --
Thanks for the fix!
Reviewed-by: Zhenyu Wang
--
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
