can the idle value of /proc/stat decrease?
Our recent test shows that the idle value of /proc/stat can decrease. Is this an unreported bug? or it has been reported and the solution is waiting to get merged. The results of the two readings from /proc/stat are shown as below, the interval between the two readings is 150 ms: cat /proc/stat cpu0 5536 10 14160 4118960 0 0 227128 0 0 0 cat /proc/stat cpu0 5536 10 14160 4118959 0 0 227143 0 0 0
Re: [PATCH] m68k: let clk_enable() return immediately if clk is NULL
Hi Defang,
On Mon, Dec 28, 2020 at 3:08 AM Defang Bo wrote:
> Similar to commit<742859adc721>("m68k: let clk_disable() return immediately
> if clk is NULL").
> there should be a check for clk to prevent NULL pointer dereference.
>
> Signed-off-by: Defang Bo
Thanks for your patch!
> --- a/arch/m68k/coldfire/clk.c
> +++ b/arch/m68k/coldfire/clk.c
> @@ -90,6 +90,9 @@ EXPORT_SYMBOL(clk_get);
> int clk_enable(struct clk *clk)
> {
> unsigned long flags;
Please keep the blank line between variable declarations and
statements (no complaint from scripts/checkpatch.pl? See
Documentation/process/submitting-patches.rst
).
> + if (!clk)
> + return -EINVAL;
> +
> spin_lock_irqsave(_lock, flags);
> if ((clk->enabled++ == 0) && clk->clk_ops)
> clk->clk_ops->enable(clk);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] drm/hisilicon: Use simple encoder
The hibmc driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index d35548d..c76f996 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "hibmc_drm_drv.h"
#include "hibmc_drm_regs.h"
@@ -90,10 +91,6 @@ static const struct drm_encoder_helper_funcs
hibmc_encoder_helper_funcs = {
.mode_set = hibmc_encoder_mode_set,
};
-static const struct drm_encoder_funcs hibmc_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
int hibmc_vdac_init(struct hibmc_drm_private *priv)
{
struct drm_device *dev = >dev;
@@ -109,8 +106,7 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
}
encoder->possible_crtcs = 0x1;
- ret = drm_encoder_init(dev, encoder, _encoder_funcs,
- DRM_MODE_ENCODER_DAC, NULL);
+ ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
if (ret) {
drm_err(dev, "failed to init encoder: %d\n", ret);
return ret;
--
2.7.4
Re: Linux 5.11-rc1
[ Please CC me I am not subscribed to LKML and linux-kbuild ML ] Hi Linus, Hi Mashiro, thanks for the Linux v5.11-rc1 release. With a new release I always do my first builds with my distro's default compiler and linker (GCC v10.2.1 and GNU/ld BFD v2.35.1). ( It's approx. 40% faster than LLVM toolchain v11.0.1-rc2 here on Debian/testing AMD64. ) The only warning I see for the first time (with v5.10.3 not observed): sh ./scripts/depmod.sh depmod 5.11.0-rc1-1-amd64-gcc10-bfd Warning: 'make modules_install' requires depmod. Please install it. This is probably in the kmod package. The only change I see in this area is: 436e980e2ed5 kbuild: don't hardcode depmod path depmod from kmod Debian package is placed and I have no /sbin in my user's path (and not before?): $ dpkg -L kmod | grep bin | grep depmod /sbin/depmod $ which depmod [ empty ] $ echo $PATH /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games OK, this is a warning, but might confuse other users. Please, let me know if you need further information and keep me CCed. Thanks. Regards, - Sedat - [1] https://git.kernel.org/linus/436e980e2ed526832de822cbf13c317a458b78e1
Re: [PATCH 2/2] arm64: mm: fix kdump broken with ZONE_DMA reintroduced
Hi Nicolas,
Thanks for your review.
On 2020/12/26 18:34, Nicolas Saenz Julienne wrote:
> Hi Chen, thanks for looking at this.
>
> On Sat, 2020-12-26 at 11:35 +0800, Chen Zhou wrote:
>> If the memory reserved for crash dump kernel falled in ZONE_DMA32,
>> the devices in crash dump kernel need to use ZONE_DMA will alloc fail.
>>
>> Fix this by reserving low memory in ZONE_DMA if CONFIG_ZONE_DMA is
>> enabled, otherwise, reserving in ZONE_DMA32.
>>
>> Fixes: bff3b04460a8 ("arm64: mm: reserve CMA and crashkernel in ZONE_DMA32")
> I'm not so sure this counts as a fix, if someone backports it it'll probably
> break things as it depends on the series that dynamically sizes DMA zones.
I write this just because kdump is broken from this commit.
>
>> Signed-off-by: Chen Zhou
>> ---
> Why not doing the same with CMA? You'll probably have to move the
> dma_contiguous_reserve() call into bootmem_init() so as to make sure that
> arm64_dma_phys_limit is populated.
You are right, CMA also need this. I will do this in next version.
Thanks,
Chen Zhou
>
> Regards,
> Nicolas
>
>> arch/arm64/mm/init.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 7b9809e39927..5074e945f1a6 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -85,7 +85,8 @@ static void __init reserve_crashkernel(void)
>>
>>
>> if (crash_base == 0) {
>> /* Current arm64 boot protocol requires 2MB alignment */
>> -crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit,
>> +crash_base = memblock_find_in_range(0,
>> +arm64_dma_phys_limit ? : arm64_dma32_phys_limit,
>> crash_size, SZ_2M);
>> if (crash_base == 0) {
>> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>
[PATCH] dm snap : add sanity checks to snapshot_ctr
Similar to commit<70de2cbda8a5>("dm thin: add sanity checks
to thin-pool and external snapshot creation"),there should be a check
for argc and argv to prevent Null pointer dereferencing when the dm_get_device
invoked twice on the same device path with differnt mode.
Signed-off-by: Defang Bo
---
drivers/md/dm-snap.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 4668b2c..dccce8b 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1258,6 +1258,13 @@ static int snapshot_ctr(struct dm_target *ti, unsigned
int argc, char **argv)
as.argc = argc;
as.argv = argv;
+
+ if (!strcmp(argv[0], argv[1])) {
+ ti->error = "Error setting metadata or data device";
+ r = -EINVAL;
+ goto bad;
+ }
+
dm_consume_args(, 4);
r = parse_snapshot_features(, s, ti);
if (r)
--
2.7.4
[PATCH] net: remove disc_data_lock in ppp line discipline
In tty layer, it use tty->ldisc_sem to proect tty_ldisc_ops.
So I think tty->ldisc_sem can also protect tty->disc_data;
For examlpe,
When cpu A is running ppp_synctty_ioctl that hold the tty->ldisc_sem,
at the same time if cpu B calls ppp_synctty_close, it will wait until
cpu A release tty->ldisc_sem. So I think it is unnecessary to have the
disc_data_lock;
cpu A cpu B
tty_ioctl tty_reopen
->hold tty->ldisc_sem->hold tty->ldisc_sem(write), failed
->ld->ops->ioctl ->wait...
->release tty->ldisc_sem ->wait...OK,hold tty->ldisc_sem
->tty_ldisc_reinit
->tty_ldisc_close
->ld->ops->close
Signed-off-by: Gao Yan
---
drivers/net/ppp/ppp_async.c | 11 ++-
drivers/net/ppp/ppp_synctty.c | 12 ++--
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ppp/ppp_async.c b/drivers/net/ppp/ppp_async.c
index 29a0917a8..20b50facd 100644
--- a/drivers/net/ppp/ppp_async.c
+++ b/drivers/net/ppp/ppp_async.c
@@ -127,17 +127,13 @@ static const struct ppp_channel_ops async_ops = {
* FIXME: this is no longer true. The _close path for the ldisc is
* now guaranteed to be sane.
*/
-static DEFINE_RWLOCK(disc_data_lock);
static struct asyncppp *ap_get(struct tty_struct *tty)
{
- struct asyncppp *ap;
+ struct asyncppp *ap = tty->disc_data;
- read_lock(_data_lock);
- ap = tty->disc_data;
if (ap != NULL)
refcount_inc(>refcnt);
- read_unlock(_data_lock);
return ap;
}
@@ -214,12 +210,9 @@ ppp_asynctty_open(struct tty_struct *tty)
static void
ppp_asynctty_close(struct tty_struct *tty)
{
- struct asyncppp *ap;
+ struct asyncppp *ap = tty->disc_data;
- write_lock_irq(_data_lock);
- ap = tty->disc_data;
tty->disc_data = NULL;
- write_unlock_irq(_data_lock);
if (!ap)
return;
diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c
index 0f338752c..53fb68e29 100644
--- a/drivers/net/ppp/ppp_synctty.c
+++ b/drivers/net/ppp/ppp_synctty.c
@@ -129,17 +129,12 @@ ppp_print_buffer (const char *name, const __u8 *buf, int
count)
*
* FIXME: Fixed in tty_io nowadays.
*/
-static DEFINE_RWLOCK(disc_data_lock);
-
static struct syncppp *sp_get(struct tty_struct *tty)
{
- struct syncppp *ap;
+ struct syncppp *ap = tty->disc_data;
- read_lock(_data_lock);
- ap = tty->disc_data;
if (ap != NULL)
refcount_inc(>refcnt);
- read_unlock(_data_lock);
return ap;
}
@@ -213,12 +208,9 @@ ppp_sync_open(struct tty_struct *tty)
static void
ppp_sync_close(struct tty_struct *tty)
{
- struct syncppp *ap;
+ struct syncppp *ap = tty->disc_data;
- write_lock_irq(_data_lock);
- ap = tty->disc_data;
tty->disc_data = NULL;
- write_unlock_irq(_data_lock);
if (!ap)
return;
--
2.17.1
[PATCH] dm-snapshot: Flush merged data before committing metadata
If the origin device has a volatile write-back
cache and the following events occur:
1: After finishing merge operation of one set of exceptions,
merge_callback() is invoked.
2: Update the metadata in COW device tracking the merge completion.
This update to COW device is flushed cleanly.
3: System crashes and the origin device's cache where the recent
merge was completed has not been flushed.
During the next cycle when we read the metadata from the COW device,
we will skip reading those metadata whose merge was completed in
step (1). This will lead to data loss/corruption.
To address this, flush the origin device post merge IO before
updating the metadata.
Signed-off-by: Akilesh Kailash
---
drivers/md/dm-snap.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 4668b2cd98f4..11890db71f3f 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -141,6 +141,11 @@ struct dm_snapshot {
* for them to be committed.
*/
struct bio_list bios_queued_during_merge;
+
+ /*
+* Flush data after merge.
+*/
+ struct bio flush_bio;
};
/*
@@ -1121,6 +1126,17 @@ static void snapshot_merge_next_chunks(struct
dm_snapshot *s)
static void error_bios(struct bio *bio);
+static int flush_data(struct dm_snapshot *s)
+{
+ struct bio *flush_bio = >flush_bio;
+
+ bio_reset(flush_bio);
+ bio_set_dev(flush_bio, s->origin->bdev);
+ flush_bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH;
+
+ return submit_bio_wait(flush_bio);
+}
+
static void merge_callback(int read_err, unsigned long write_err, void
*context)
{
struct dm_snapshot *s = context;
@@ -1134,6 +1150,11 @@ static void merge_callback(int read_err, unsigned long
write_err, void *context)
goto shut;
}
+ if (flush_data(s) < 0) {
+ DMERR("Flush after merge failed: shutting down merge");
+ goto shut;
+ }
+
if (s->store->type->commit_merge(s->store,
s->num_merging_chunks) < 0) {
DMERR("Write error in exception store: shutting down merge");
@@ -1318,6 +1339,7 @@ static int snapshot_ctr(struct dm_target *ti, unsigned
int argc, char **argv)
s->first_merging_chunk = 0;
s->num_merging_chunks = 0;
bio_list_init(>bios_queued_during_merge);
+ bio_init(>flush_bio, NULL, 0);
/* Allocate hash table for COW data */
if (init_hash_tables(s)) {
@@ -1504,6 +1526,8 @@ static void snapshot_dtr(struct dm_target *ti)
dm_exception_store_destroy(s->store);
+ bio_uninit(>flush_bio);
+
dm_put_device(ti, s->cow);
dm_put_device(ti, s->origin);
--
2.29.2.729.g45daf8777d-goog
Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks
On Fri, Dec 25, 2020 at 12:48 PM Zhen Lei wrote:
>
> The outercache of some Hisilicon SOCs support physical addresses wider
> than 32-bits. The unsigned long datatype is not sufficient for mapping
> physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE:
> use phys_addr_t instead of unsigned long in outercache functions") has
> already modified the outercache functions. But the parameters of the
> outercache hooks are not changed. This patch use phys_addr_t instead of
> unsigned long in outercache hooks: inv_range, clean_range, flush_range.
>
> To ensure the outercache that does not support LPAE works properly, do
> cast phys_addr_t to unsigned long by adding a middle-tier function.
> For example:
> -static void l2c220_inv_range(unsigned long start, unsigned long end)
> +static void __l2c220_inv_range(unsigned long start, unsigned long end)
> {
> ...
> }
> +static void l2c220_inv_range(phys_addr_t start, phys_addr_t end)
> +{
> + __l2c220_inv_range(start, end);
> +}
>
> Note that the outercache functions have been doing this cast before this
> patch. So now, the cast is just moved to the middle-tier function.
>
> No functional change.
>
> Signed-off-by: Zhen Lei
This looks reasonable in principle, but it would be helpful to
understand better which SoCs are affected. In which way is
this specific to Hisilicon implementations, and why would others
not need this?
Wouldn't this also be needed by an Armada XP that supports
more than 4GB of RAM but has an outer cache?
I suppose those SoCs using off-the-shelf Arm cores are either
pre-LPAE and cannot address memory above 4GB, or they do
not need the outer_cache interfaces.
> diff --git a/arch/arm/mm/cache-feroceon-l2.c b/arch/arm/mm/cache-feroceon-l2.c
> index 5c1b7a7b9af6300..ab1d8051bf832c9 100644
> --- a/arch/arm/mm/cache-feroceon-l2.c
> +++ b/arch/arm/mm/cache-feroceon-l2.c
> @@ -168,7 +168,7 @@ static unsigned long calc_range_end(unsigned long start,
> unsigned long end)
> return range_end;
> }
>
> -static void feroceon_l2_inv_range(unsigned long start, unsigned long end)
> +static void __feroceon_l2_inv_range(unsigned long start, unsigned long end)
> {
> /*
> * Clean and invalidate partial first cache line.
> @@ -198,7 +198,12 @@ static void feroceon_l2_inv_range(unsigned long start,
> unsigned long end)
> dsb();
> }
>
> -static void feroceon_l2_clean_range(unsigned long start, unsigned long end)
> +static void feroceon_l2_inv_range(phys_addr_t start, phys_addr_t end)
> +{
> + __feroceon_l2_inv_range(start, end);
> +}
> +
What is this indirection for? It looks like you do this for all implementations,
so the actual address gets truncated here.
Arnd
[PATCH] pinctrl: ralink: rt2880: fix '-Wmissing-prototypes' in init function
Kernel test robot reported the following warning:
'warning: no previous prototype for 'rt2880_pinmux_init''.
This function is the entry point for the platform driver and
it is private to this driver. Hence declare it 'static' which is
the correct thing to do fixing also this warning.
Reported-by: kernel test robot
Signed-off-by: Sergio Paracuellos
---
Hi Linus,
Just a note to let you know that this patch is rebased on the top of this
series which are pending to be applied:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-December/149353.html
Thanks in advance for your time!
Best regards,
Sergio Paracuellos
drivers/pinctrl/ralink/pinctrl-rt2880.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/ralink/pinctrl-rt2880.c
b/drivers/pinctrl/ralink/pinctrl-rt2880.c
index 983da62ff3be..1f8e8d5b71fd 100644
--- a/drivers/pinctrl/ralink/pinctrl-rt2880.c
+++ b/drivers/pinctrl/ralink/pinctrl-rt2880.c
@@ -361,7 +361,7 @@ static struct platform_driver rt2880_pinmux_driver = {
},
};
-int __init rt2880_pinmux_init(void)
+static int __init rt2880_pinmux_init(void)
{
return platform_driver_register(_pinmux_driver);
}
--
2.25.1
Re: [PATCH] ASoC: audio-graph-card: Drop remote-endpoint as required property
Hi Rob, The remote-endpoint may not be available if it is part of some pluggable module. One such example would be an audio card, the Codec endpoint will not be available until it is plugged in. Hence drop 'remote-endpoint' as a required property. Please hold off on this. I have more changes coming. Is this a good time to push for audio-graph-port changes?
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, 27 Dec 2020, Linus Torvalds wrote: > On Sun, Dec 27, 2020 at 3:48 PM Kirill A. Shutemov > wrote: > > > > I did what Hugh proposed and it got clear to my eyes. It gets somewhat > > large, but take a look. > > Ok, it's not that much bigger, and the end result is certainly much > clearer wrt locking. > > So that last version of yours with the fix for the uninitialized 'ret' > variable looks good to me. > > Of course, I've said that before, and have been wrong. So ... And guess what... it's broken. I folded it into testing rc1: segfault on cc1, systemd "Journal file corrupted, rotating", seen on more than one machine. I've backed it out, rc1 itself seems fine, I'll leave rc1 under load overnight, then come back to the faultaround patch tomorrow; won't glance at it tonight, but maybe Kirill will guess what's wrong. Hugh
Re: [PATCH] staging: android: ashmem: Declared file operation with const keyword
On Mon, Dec 28, 2020 at 12:13:00AM -0500, jovin555 wrote:
> Warning found by checkpatch.pl script.
>
> Signed-off-by: jovin555
> ---
> drivers/staging/android/ashmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c
> index c05a214191da..f9cfa15b785f 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file,
> unsigned long addr,
>
> static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
> struct ashmem_area *asma = file->private_data;
> int ret = 0;
>
Did you build your modified kernel with this change in it?
Always do so...
greg k-h
Re: [PATCH] cpuset: Remove stale URLs in the MAINTAINERS entry
On 2020/12/28 14:01, Joe Perches wrote: > On Mon, 2020-12-28 at 11:17 +0800, Zefan Li wrote: >> Those URLs are no longer accessable. >> >> Reported-by: Steve Wahl >> Signed-off-by: Zefan Li >> --- >> MAINTAINERS | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index ae9b1dd748c4..2fe8eb54639e 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -4477,8 +4477,6 @@ CONTROL GROUP - CPUSET >> M: Li Zefan >> L: cgro...@vger.kernel.org >> S: Maintained >> -W: http://www.bullopensource.org/cpuset/ >> -W: http://oss.sgi.com/projects/cpusets/ > > The general argument to avoid removal of these no longer valid links > is that they may still be available from archive.org. > > For instance: > > https://web.archive.org/web/20170512010721/http://oss.sgi.com/projects/cpusets/ > > It may be appropriate to copy the content into a local Documentation > file somewhere to avoid the need to lookup old reference links. > I don't think the contents in those links provide valuable information about cpusets. We have documents in Documentation/admin-guide/cgroup/ and man cpuset(7). So I think we can just remove them.
Re: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for suspend/resume") causing hibernate resume failures
On Sun, 27 Dec 2020, Kenneth R. Crudup wrote: > I'll try your patch after the revert and see if anything changes. I just realized today's patch makes no sense if it's reverted, so nevermind. -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
ERROR: ".of_device_get_match_data" undefined!
Hi Shengjiu, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5c8fe583cce542aa0b84adc939ce85293de36e5e commit: c05f10f28ef697aae8f1d82012d660af3cfc8cf9 ASoC: fsl_asrc: Add support for imx8qm & imx8qxp date: 12 months ago config: powerpc64-randconfig-s032-20201223 (attached as .config) compiler: powerpc64-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-184-g1b896707-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c05f10f28ef697aae8f1d82012d660af3cfc8cf9 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout c05f10f28ef697aae8f1d82012d660af3cfc8cf9 # 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 All errors (new ones prefixed by >>): ERROR: ".__stack_chk_fail" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined! ERROR: ".regcache_cache_only" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined! ERROR: ".ftrace_likely_update" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined! ERROR: ".__devm_regmap_init_mmio_clk" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined! ERROR: ".regmap_write" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_property_match_string" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".regmap_update_bits_base" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".devm_kmalloc" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".snprintf" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".__mutex_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".devm_request_threaded_irq" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".platform_device_unregister" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".regcache_sync" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".__platform_driver_register" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_find_property" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_find_node_opts_by_path" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_property_read_variable_u32_array" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".devm_ioremap_resource" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_match_device" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".debugfs_create_file" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".single_open" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".mutex_lock" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_node_put" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".of_get_property" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".strrchr" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".debugfs_remove_recursive" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".snd_pcm_hw_constraint_step" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".platform_device_register_full" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".platform_driver_unregister" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".regmap_read" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".debugfs_create_dir" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".devm_snd_soc_register_component" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".platform_get_resource" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".snd_soc_set_ac97_ops" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".snd_pcm_format_width" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".regcache_mark_dirty" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".seq_printf" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: "._dev_warn" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".udelay" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".memcpy" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".memset" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".snd_soc_set_ac97_ops_of_reset" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: "._dev_err" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".platform_get_irq" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".__stack_chk_fail" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR: ".mutex_unlock" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined! ERROR:
Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()
On 24-12-20, 16:00, Dmitry Osipenko wrote: > In a device driver I want to set PD to the lowest performance state by > removing the performance vote when dev_pm_opp_set_rate(dev, 0) is > invoked by the driver. > > The OPP core already does this, but if OPP levels don't start from 0 in > a device-tree for PD, then it currently doesn't work since there is a > need to get a rounded-up performance state because > dev_pm_opp_set_voltage() takes OPP entry for the argument (patches 9 and > 28). > > The PD powering off and performance-changes are separate from each other > in the GENPD core. The GENPD core automatically turns off domain when > all devices within the domain are suspended by system-suspend or RPM. > > The performance state of a power domain is controlled solely by a device > driver. GENPD core only aggregates the performance requests, it doesn't > change the performance state of a domain by itself when device is > suspended or resumed, IIUC this is intentional. And I want to put domain > into lowest performance state when device is suspended. Right, so if you really want to just drop the performance vote, then with a value of 0 for the performance state the call will reach to your genpd's callback ->set_performance_state(). Just as dev_pm_opp_set_rate() accepts the frequency to be 0, I would expect dev_pm_opp_set_rate() to accept opp argument as NULL and in that case set voltage to 0 and do regulator_disable() as well. Won't that work better than going for the lowest voltage ? -- viresh
RE: [PATCH] scsi: qedi: add printf attribute to log function
> -Original Message-
> From: t...@redhat.com
> Sent: Monday, December 21, 2020 9:54 PM
> To: Nilesh Javali ; Manish Rangankar
> ; j...@linux.ibm.com;
> martin.peter...@oracle.com
> Cc: GR-QLogic-Storage-Upstream upstr...@marvell.com>; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Tom Rix
> Subject: [PATCH] scsi: qedi: add printf attribute to log function
>
> From: Tom Rix
>
> Attributing the function allows the compiler to more thoroughly check the
> use of the function with -Wformat and similar flags.
>
> Signed-off-by: Tom Rix
> ---
> drivers/scsi/qedi/qedi_dbg.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/qedi/qedi_dbg.h b/drivers/scsi/qedi/qedi_dbg.h
> index 37d084086fd4..b2c9b0a2db6a 100644
> --- a/drivers/scsi/qedi/qedi_dbg.h
> +++ b/drivers/scsi/qedi/qedi_dbg.h
> @@ -78,13 +78,16 @@ struct qedi_dbg_ctx {
> #define QEDI_INFO(pdev, level, fmt, ...) \
> qedi_dbg_info(pdev, __func__, __LINE__, level, fmt, \
> ## __VA_ARGS__)
> -
> +__printf(4, 5)
> void qedi_dbg_err(struct qedi_dbg_ctx *qedi, const char *func, u32 line,
> const char *fmt, ...);
> +__printf(4, 5)
> void qedi_dbg_warn(struct qedi_dbg_ctx *qedi, const char *func, u32 line,
> const char *fmt, ...);
> +__printf(4, 5)
> void qedi_dbg_notice(struct qedi_dbg_ctx *qedi, const char *func, u32
> line,
>const char *fmt, ...);
> +__printf(5, 6)
> void qedi_dbg_info(struct qedi_dbg_ctx *qedi, const char *func, u32 line,
> u32 info, const char *fmt, ...);
>
Thanks,
Acked-by: Manish Rangankar
Re: [PATCH] cpuset: Remove stale URLs in the MAINTAINERS entry
On Mon, 2020-12-28 at 11:17 +0800, Zefan Li wrote: > Those URLs are no longer accessable. > > Reported-by: Steve Wahl > Signed-off-by: Zefan Li > --- > MAINTAINERS | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ae9b1dd748c4..2fe8eb54639e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4477,8 +4477,6 @@ CONTROL GROUP - CPUSET > M: Li Zefan > L: cgro...@vger.kernel.org > S: Maintained > -W: http://www.bullopensource.org/cpuset/ > -W: http://oss.sgi.com/projects/cpusets/ The general argument to avoid removal of these no longer valid links is that they may still be available from archive.org. For instance: https://web.archive.org/web/20170512010721/http://oss.sgi.com/projects/cpusets/ It may be appropriate to copy the content into a local Documentation file somewhere to avoid the need to lookup old reference links.
Re: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for suspend/resume") causing hibernate resume failures
OK, got more info: On Sun, 27 Dec 2020, Bjorn Helgaas wrote: > If it's convenient, can you try the patch below? If the debug patch > doesn't help: > - Are you seeing the hibernate/resume problem when on AC or on > battery? OK, so: - on TLP, before your patch, it panic()s on AC, but not on battery - on TLP, with your patch, it panic()s on battery, but NOT on AC - if TLP is masked, it still panic()s, but I forget if AC or battery - even if I mask TLP, with your commit in place it panic()s > - If you revert 4257f7e008ea, does hibernate/resume work fine? Both > with the tlp tweak and without? Definitely with the revert everything works. I'll try your patch after the revert and see if anything changes. -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
Re: [External] [PATCH 1/2] mm: memcg: fix memcg file_dirty numa stat
On Mon, Dec 28, 2020 at 2:13 AM Shakeel Butt wrote:
>
> The kernel updates the per-node NR_FILE_DIRTY stats on page migration
> but not the memcg numa stats. That was not an issue until recently the
> commit 5f9a4f4a7096 ("mm: memcontrol: add the missing numa_stat interface
> for cgroup v2") exposed numa stats for the memcg. So fixing the
> file_dirty per-memcg numa stat.
>
> Fixes: 5f9a4f4a7096 ("mm: memcontrol: add the missing numa_stat interface for
> cgroup v2")
Thanks for catching this problem.
Reviewed-by: Muchun Song
> Signed-off-by: Shakeel Butt
> Cc:
> ---
> mm/migrate.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index ee5e612b4cd8..613794f6a433 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -500,9 +500,9 @@ int migrate_page_move_mapping(struct address_space
> *mapping,
> __inc_lruvec_state(new_lruvec, NR_SHMEM);
> }
> if (dirty && mapping_can_writeback(mapping)) {
> - __dec_node_state(oldzone->zone_pgdat, NR_FILE_DIRTY);
> + __dec_lruvec_state(old_lruvec, NR_FILE_DIRTY);
> __dec_zone_state(oldzone, NR_ZONE_WRITE_PENDING);
> - __inc_node_state(newzone->zone_pgdat, NR_FILE_DIRTY);
> + __inc_lruvec_state(new_lruvec, NR_FILE_DIRTY);
> __inc_zone_state(newzone, NR_ZONE_WRITE_PENDING);
> }
> }
> --
> 2.29.2.729.g45daf8777d-goog
>
--
Yours,
Muchun
Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: Fix some resource leaks in the error handling path of the probe function
On 27-12-20, 18:22, Christophe JAILLET wrote:
> Le 22/12/2020 à 05:35, Viresh Kumar a écrit :
> > On 19-12-20, 11:17, Christophe JAILLET wrote:
> > > If 'cpufreq_register_driver()' fails, we must release the resources
> > > allocated in 'brcm_avs_prepare_init()' as already done in the remove
> > > function.
> > >
> > > To do that, introduce a new function 'brcm_avs_prepare_uninit()' in order
> > > to avoid code duplication. This also makes the code more readable (IMHO).
> > >
> > > Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver
> > > for Broadcom STB SoCs")
> > > Signed-off-by: Christophe JAILLET
> > > ---
> > > I'm not sure that the existing error handling in the remove function is
> > > correct and/or needed.
> > > ---
> > > drivers/cpufreq/brcmstb-avs-cpufreq.c | 25 -
> > > 1 file changed, 20 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > > b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > > index 3e31e5d28b79..750ca7cfccb0 100644
> > > --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > > +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > > @@ -597,6 +597,16 @@ static int brcm_avs_prepare_init(struct
> > > platform_device *pdev)
> > > return ret;
> > > }
> > > +static void brcm_avs_prepare_uninit(struct platform_device *pdev)
> > > +{
> > > + struct private_data *priv;
> > > +
> > > + priv = platform_get_drvdata(pdev);
> > > +
> > > + iounmap(priv->avs_intr_base);
> > > + iounmap(priv->base);
> > > +}
> > > +
> > > static int brcm_avs_cpufreq_init(struct cpufreq_policy *policy)
> > > {
> > > struct cpufreq_frequency_table *freq_table;
> > > @@ -732,21 +742,26 @@ static int brcm_avs_cpufreq_probe(struct
> > > platform_device *pdev)
> > > brcm_avs_driver.driver_data = pdev;
> > > - return cpufreq_register_driver(_avs_driver);
> > > + ret = cpufreq_register_driver(_avs_driver);
> > > + if (ret)
> > > + goto err_uninit;
> > > +
> > > + return 0;
> > > +
> > > +err_uninit:
> > > + brcm_avs_prepare_uninit(pdev);
> > > + return ret;
> >
> > Maybe rewrite as:
> >
> > ret = cpufreq_register_driver(_avs_driver);
> > if (ret)
> > brcm_avs_prepare_uninit(pdev);
> > return ret;
> >
>
> Personlaly, I prefer what I have proposed. Having a clear and dedicated
> error handling path is more future proff, IMHO.
I would have agreed to that if there were other things we were handling in the
error path, but right now we are adding an extra label, goto, etc without any
need. If in future this needs a change, we can always come back to it and update
with a label. But right now I would suggest to keep it simple.
> > > }
> > > static int brcm_avs_cpufreq_remove(struct platform_device *pdev)
> > > {
> > > - struct private_data *priv;
> > > int ret;
> > > ret = cpufreq_unregister_driver(_avs_driver);
> > > if (ret)
> > > return ret;
> >
> > Instead of returning here, it can be just WARN_ON(ret); and then go on and
> > free
> > the resources and this needs to be done in a separate patch.
>
> Ok, I agree (see my comment below the --- in my patch).
> I'll send a patch for it when the first patch will be applied, unless you
> prefer if I resend as a serie.
Based on the above comment from me, I am expecting another version from you for
this patch. So you can fix both the issues in the same patchset.
--
viresh
[PATCH] opp: Call the missing clk_put() on error
Fix the clock reference counting by calling the missing clk_put() in the
error path.
Cc: v5.10 # v5.10
Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return
-EPROBE_DEFER")
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index c9e50836b4c2..8c905aabacc0 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1101,7 +1101,7 @@ static struct opp_table *_allocate_opp_table(struct
device *dev, int index)
ret = dev_pm_opp_of_find_icc_paths(dev, opp_table);
if (ret) {
if (ret == -EPROBE_DEFER)
- goto remove_opp_dev;
+ goto put_clk;
dev_warn(dev, "%s: Error finding interconnect paths: %d\n",
__func__, ret);
@@ -1113,6 +1113,9 @@ static struct opp_table *_allocate_opp_table(struct
device *dev, int index)
return opp_table;
+put_clk:
+ if (!IS_ERR(opp_table->clk))
+ clk_put(opp_table->clk);
remove_opp_dev:
_remove_opp_dev(opp_dev, opp_table);
err:
--
2.25.0.rc1.19.g042ed3e048af
Re: [PATCH] opp: fix memory leak in _allocate_opp_table
On 24-12-20, 18:49, quanyang.w...@windriver.com wrote: > From: Quanyang Wang > > In function _allocate_opp_table, opp_dev is allocated and referenced > by opp_table via _add_opp_dev. But in the case that the subsequent calls > return -EPROBE_DEFER, it will jump to err label and opp_table will be > freed. Then opp_dev becomes an unreferenced object to cause memory leak. > So let's call _remove_opp_dev to do the cleanup. > > This fixes the following kmemleak report: > > unreferenced object 0x000801524a00 (size 128): > comm "swapper/0", pid 1, jiffies 4294892465 (age 84.616s) > hex dump (first 32 bytes): > 40 00 56 01 08 00 ff ff 40 00 56 01 08 00 ff ff @.V.@.V. > b8 52 77 7f 08 00 ff ff 00 3c 4c 00 08 00 ff ff .Rw.. backtrace: > [] kmemleak_alloc+0x30/0x40 > [<56da48f0>] kmem_cache_alloc+0x3d4/0x588 > [ ] _add_opp_dev+0x2c/0x88 > [<62a380cd>] _add_opp_table_indexed+0x124/0x268 > [<8b4c8f1f>] dev_pm_opp_of_add_table+0x20/0x1d8 > [ ] dev_pm_opp_of_cpumask_add_table+0x48/0xf0 > [ ] dt_cpufreq_probe+0x20c/0x448 > [<30a3a26c>] platform_probe+0x68/0xd8 > [ ] really_probe+0xd0/0x3a0 > [<642e856f>] driver_probe_device+0x58/0xb8 > [ ] device_driver_attach+0x74/0x80 > [<04f254b8>] __driver_attach+0x58/0xe0 > [<09d5d19e>] bus_for_each_dev+0x70/0xc8 > [<00d22e1c>] driver_attach+0x24/0x30 > [<01d4e952>] bus_add_driver+0x14c/0x1f0 > [<89928aaa>] driver_register+0x64/0x120 > > Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return > -EPROBE_DEFER") > Signed-off-by: Quanyang Wang > --- > drivers/opp/core.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Applied with an additional patch. Thanks. Author: Viresh Kumar Date: Mon Dec 28 10:51:04 2020 +0530 opp: Call the missing clk_put() on error Fix the clock reference counting by calling the missing clk_put() in the error path. Cc: v5.10 # v5.10 Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER") Signed-off-by: Viresh Kumar --- drivers/opp/core.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/opp/core.c b/drivers/opp/core.c index c9e50836b4c2..8c905aabacc0 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -1101,7 +1101,7 @@ static struct opp_table *_allocate_opp_table(struct device *dev, int index) ret = dev_pm_opp_of_find_icc_paths(dev, opp_table); if (ret) { if (ret == -EPROBE_DEFER) - goto remove_opp_dev; + goto put_clk; dev_warn(dev, "%s: Error finding interconnect paths: %d\n", __func__, ret); @@ -1113,6 +1113,9 @@ static struct opp_table *_allocate_opp_table(struct device *dev, int index) return opp_table; +put_clk: + if (!IS_ERR(opp_table->clk)) + clk_put(opp_table->clk); remove_opp_dev: _remove_opp_dev(opp_dev, opp_table); err: -- viresh
[PATCH] staging: android: ashmem: Declared file operation with const keyword
Warning found by checkpatch.pl script.
Signed-off-by: jovin555
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index c05a214191da..f9cfa15b785f 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, unsigned
long addr,
static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
{
- static struct file_operations vmfile_fops;
+ static const struct file_operations vmfile_fops;
struct ashmem_area *asma = file->private_data;
int ret = 0;
--
2.20.1
Re: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for suspend/resume") causing hibernate resume failures
On Sun, 27 Dec 2020, Bjorn Helgaas wrote: > If it's convenient, can you try the patch below? Will do! Also: > - Are you seeing the hibernate/resume problem when on AC or on > battery? Um, I forget :) but want to say "both". I'll try both ways and let you know. > - If you revert 4257f7e008ea, does hibernate/resume work fine? Both > with the tlp tweak and without? Yeah, but TBH there were two other PM regressions in this -rc cycle, so you guys are in good company :) > - Collect "sudo lspci -vv" output before hibernate and (if possible) > after resume when you see the problem. See attached. > I guess tlp only uses /sys/module/pcie_aspm/parameters/policy, so it > sets the same ASPM policy system-wide. Yeah. -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA00:00.0 Host bridge [0600]: Intel Corporation Device [8086:8a12] (rev 03) Subsystem: Dell Device [1028:08b0] Flags: bus master, fast devsel, latency 0, IOMMU group 0 Capabilities: [e0] Vendor Specific Information: Len=10 Kernel driver in use: icl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Plus Graphics G7 [8086:8a52] (rev 07) (prog-if 00 [VGA controller]) DeviceName: To Be Filled by O.E.M. Subsystem: Dell Iris Plus Graphics G7 [1028:08b0] Flags: bus master, fast devsel, latency 0, IRQ 201, IOMMU group 1 Memory at 603d00 (64-bit, non-prefetchable) [size=16M] Memory at 40 (64-bit, prefetchable) [size=256M] I/O ports at 4000 [size=64] Expansion ROM at 000c [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Device [8086:8a03] (rev 03) Subsystem: Dell Device [1028:08b0] Flags: fast devsel, IRQ 16, IOMMU group 2 Memory at 603eba (64-bit, non-prefetchable) [size=64K] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Capabilities: [e0] Vendor Specific Information: Len=0c Kernel driver in use: proc_thermal 00:05.0 Multimedia controller [0480]: Intel Corporation Device [8086:8a19] (rev 03) Subsystem: Dell Device [1028:08b0] Flags: fast devsel, IRQ 255, IOMMU group 3 Memory at 603c00 (64-bit, non-prefetchable) [disabled] [size=16M] Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Power Management version 3 00:07.0 PCI bridge [0604]: Intel Corporation Ice Lake Thunderbolt 3 PCI Express Root Port #0 [8086:8a1d] (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 155, IOMMU group 4 Bus: primary=00, secondary=01, subordinate=2d, sec-latency=0 I/O behind bridge: 5000-6fff [size=8K] Memory behind bridge: 7e00-8a1f [size=194M] Prefetchable memory behind bridge: 0060-00601bff [size=448M] Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [90] Subsystem: Device [:] Capabilities: [a0] Power Management version 3 Capabilities: [100] Null Capabilities: [220] Access Control Services Capabilities: [a00] Downstream Port Containment Kernel driver in use: pcieport 00:07.2 PCI bridge [0604]: Intel Corporation Ice Lake Thunderbolt 3 PCI Express Root Port #2 [8086:8a21] (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 156, IOMMU group 5 Bus: primary=00, secondary=2e, subordinate=58, sec-latency=0 I/O behind bridge: 7000-7fff [size=4K] Memory behind bridge: 7000-7c1f [size=194M] Prefetchable memory behind bridge: 00602000-00603bff [size=448M] Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [90] Subsystem: Device [:] Capabilities: [a0] Power Management version 3 Capabilities: [100] Null Capabilities: [220] Access Control Services Capabilities: [a00] Downstream Port Containment Kernel driver in use: pcieport 00:0d.0 USB controller [0c03]: Intel Corporation Ice Lake
Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On 12/23/2020 8:10 PM, Alexander Potapenko wrote: >> >> Michan, We would still need config option so that we can reduce the >> memory consumption on low ram devices using config. >> >> Alex, On this, >> "I also suppose device vendors may prefer setting a fixed (maybe >> non-default) hash size for low-memory devices rather than letting the >> admins increase it." >> I see kernel param swiotlb does similar thing i.e; '0' to disable and >> set a value to configure size. >> >> I am fine with either of the approaches, >> >> 1. I can split this patch into two >>i) A bool variable to enable/disable stack depot. >>ii) A config for the size. > > I still believe this is a more appropriate solution. > > Thanks in advance! > Thanks, Will work on a patch with above approach. Thanks, Vijay -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
dmaengine : xilinx_dma two issues
Hello,
I'm trying to get the 5.10 kernel up and running for our system, and
I'm running into a couple of issues with xilinx_dma.
First, commit 14ccf0aab46e 'dmaengine: xilinx_dma: In dma channel
probe fix node order dependency' breaks our usage. Before this commit
a call to:
dma_request_chan(_dev->dev, "axi_dma_0");
returns fine, but after that commit it returns -19. The reason for
this seems to be that the only channel that is setup is channel 1
(chan->id is 1 in xilinx_dma_chan_probe()). However in
of_dma_xilinx_xlate() chan_id is gets set to 0 (int chan_id =
dma_spec->args[0];), which causes the:
!xdev->chan[chan_id]
test to fail in of_dma_xilinx_xlate()
Our device-tree entry looks like this:
axi_dma_0: dma@80002000 {
status = "okay";
#dma-cells = <1>;
compatible = "xlnx,axi-dma-1.00.a";
interrupt-parent = <>;
interrupts = <0 89 4>;
reg = <0x0 0x80002000 0x0 0x1000>;
xlnx,addrwidth = <0x20>;
clocks = <_clk LPD_LSBUS>, <_clk LPD_LSBUS>,
<_clk LPD_LSBUS>, <_clk LPD_LSBUS>;
clock-names = "s_axi_lite_aclk", "m_axi_sg_aclk",
"m_axi_mm2s_aclk", "m_axi_s2mm_aclk";
dma-channel@80002030 {
compatible = "xlnx,axi-dma-s2mm-channel";
dma-channels = <0x1>;
interrupts = <0 89 4>;
xlnx,datawidth = <0x20>;
xlnx,device-id = <0x0>;
};
};
This is on a 5.10.1 kernel on arm64 zynqmp hardware.
The second issue goes a little further back to commit e81274cd6b526
'dmaengine: add support to dynamic register/unregister of channels'.
After this commit even just removing the module 'rmmod xilinx_dma',
without ever using it, results in a kernel oops like this:
[ 37.214568] xilinx-vdma 80002000.dma: ch 0: SG disabled
[ 37.219807] xilinx-vdma 80002000.dma: WARN: Device release is not
defined so it is not safe to unbind this driver while in use
[ 37.231299] xilinx-vdma 80002000.dma: Xilinx AXI DMA Engine Driver Probed!!
[ 42.100660] Unable to handle kernel paging request at virtual
address dead0108
[ 42.108598] Mem abort info:
[ 42.111393] ESR = 0x9644
[ 42.114443] EC = 0x25: DABT (current EL), IL = 32 bits
[ 42.119744] SET = 0, FnV = 0
[ 42.122794] EA = 0, S1PTW = 0
[ 42.125918] Data abort info:
[ 42.128789] ISV = 0, ISS = 0x0044
[ 42.132617] CM = 0, WnR = 1
[ 42.135577] [dead0108] address between user and kernel address ranges
[ 42.142705] Internal error: Oops: 9644 [#1] SMP
[ 42.147566] Modules linked in: xilinx_dma(-) clk_xlnx_clock_wizard
uio_pdrv_genirq
[ 42.155139] CPU: 1 PID: 2075 Comm: rmmod Not tainted
5.10.1-00026-g3a2e6dd7a05-dirty #192
[ 42.163302] Hardware name: Enclustra XU5 SOM (DT)
[ 42.167992] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[ 42.173996] pc : xilinx_dma_chan_remove+0x74/0xa0 [xilinx_dma]
[ 42.179815] lr : xilinx_dma_chan_remove+0x70/0xa0 [xilinx_dma]
[ 42.185636] sp : ffc01112bca0
[ 42.188935] x29: ffc01112bca0 x28: ff80402ea640
[ 42.194238] x27: x26:
[ 42.199542] x25: x24:
[ 42.204845] x23: x22:
[ 42.210149] x21: ffc0088a2028 x20: ff8040c08410
[ 42.215452] x19: ff80423fa480 x18:
[ 42.220756] x17: x16:
[ 42.226059] x15: ffc010ce88c8 x14: 0040
[ 42.231363] x13: ff00 x12:
[ 42.236667] x11: 0028 x10: 7fff
[ 42.241970] x9 : 00f0dfe0 x8 :
[ 42.247273] x7 : ffc010da4000 x6 :
[ 42.252577] x5 : 00210d00 x4 : ffc010da4da0
[ 42.257881] x3 : ff80423fa578 x2 :
[ 42.263184] x1 : dead0100 x0 : dead0122
[ 42.268488] Call trace:
[ 42.270923] xilinx_dma_chan_remove+0x74/0xa0 [xilinx_dma]
[ 42.276399] xilinx_dma_remove+0x3c/0x70 [xilinx_dma]
[ 42.281446] platform_drv_remove+0x24/0x38
[ 42.285530] device_release_driver_internal+0xec/0x1a8
[ 42.290659] driver_detach+0x64/0xd8
[ 42.294226] bus_remove_driver+0x58/0xb8
[ 42.298133] driver_unregister+0x30/0x60
[ 42.302048] platform_driver_unregister+0x14/0x20
[ 42.306744] xilinx_vdma_driver_exit+0x18/0x978 [xilinx_dma]
[ 42.312396] __arm64_sys_delete_module+0x1e4/0x270
[ 42.317178] el0_svc_common.constprop.4+0x68/0x170
[ 42.321959] do_el0_svc+0x70/0x90
[ 42.325267] el0_svc+0x14/0x20
[ 42.328313] el0_sync_handler+0x90/0xb8
[ 42.332141] el0_sync+0x158/0x180
[ 42.335442] Code: 95dfce29 9103c260 95de7ffb a9490261 (f9000420)
[ 42.341525] ---[ end trace dbd90aeb5ca71943 ]---
So if I use the 04c2bc2bede1 (commit before 14ccf0aab46e) version of
xilinx_dma.c and never remove the module then it is working with the
5.10.1 kernel.
Hopefully, this will be clear to someone how these issues can be
resolved. In general we've been
[PATCH] selftests/powerpc: make the test check in eeh-basic.sh posix compliant
The == operand is a bash extension, thus this will fail on Ubuntu with
As the /bin/sh on Ubuntu is pointed to DASH.
Use -eq to fix this posix compatibility issue.
Fixes: 996f9e0f93f162 ("selftests/powerpc: Fix eeh-basic.sh exit codes")
Signed-off-by: Po-Hsu Lin
---
tools/testing/selftests/powerpc/eeh/eeh-basic.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/eeh/eeh-basic.sh
b/tools/testing/selftests/powerpc/eeh/eeh-basic.sh
index 0d783e1..64779f0 100755
--- a/tools/testing/selftests/powerpc/eeh/eeh-basic.sh
+++ b/tools/testing/selftests/powerpc/eeh/eeh-basic.sh
@@ -86,5 +86,5 @@ echo "$failed devices failed to recover ($dev_count tested)"
lspci | diff -u $pre_lspci -
rm -f $pre_lspci
-test "$failed" == 0
+test "$failed" -eq 0
exit $?
--
2.7.4
Re: [PATCH v5 10/15] sched: Introduce force_compatible_cpus_allowed_ptr() to limit CPU affinity
Just a couple minor nits.
On Tue, Dec 8, 2020 at 5:29 AM Will Deacon wrote:
>
> Asymmetric systems may not offer the same level of userspace ISA support
> across all CPUs, meaning that some applications cannot be executed by
> some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do
> not feature support for 32-bit applications on both clusters.
>
> Although userspace can carefully manage the affinity masks for such
> tasks, one place where it is particularly problematic is execve()
> because the CPU on which the execve() is occurring may be incompatible
> with the new application image. In such a situation, it is desirable to
> restrict the affinity mask of the task and ensure that the new image is
> entered on a compatible CPU. From userspace's point of view, this looks
> the same as if the incompatible CPUs have been hotplugged off in the
> task's affinity mask.
>
> In preparation for restricting the affinity mask for compat tasks on
> arm64 systems without uniform support for 32-bit applications, introduce
> force_compatible_cpus_allowed_ptr(), which restricts the affinity mask
> for a task to contain only compatible CPUs.
>
> Reviewed-by: Quentin Perret
> Signed-off-by: Will Deacon
> ---
> include/linux/sched.h | 1 +
> kernel/sched/core.c | 100 +++---
> 2 files changed, 86 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 76cd21fa5501..e42dd0fb85c5 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1653,6 +1653,7 @@ extern int task_can_attach(struct task_struct *p, const
> struct cpumask *cs_cpus_
> #ifdef CONFIG_SMP
> extern void do_set_cpus_allowed(struct task_struct *p, const struct cpumask
> *new_mask);
> extern int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask
> *new_mask);
> +extern void force_compatible_cpus_allowed_ptr(struct task_struct *p);
> #else
> static inline void do_set_cpus_allowed(struct task_struct *p, const struct
> cpumask *new_mask)
> {
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 92ac3e53f50a..1cfc94be18a9 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1863,25 +1863,19 @@ void do_set_cpus_allowed(struct task_struct *p, const
> struct cpumask *new_mask)
> }
>
> /*
> - * Change a given task's CPU affinity. Migrate the thread to a
> - * proper CPU and schedule it away if the CPU it's executing on
> - * is removed from the allowed bitmask.
> - *
> - * NOTE: the caller must have a valid reference to the task, the
> - * task must not exit() & deallocate itself prematurely. The
> - * call is not atomic; no spinlocks may be held.
> + * Called with both p->pi_lock and rq->lock held; drops both before
> returning.
Maybe annotate with __releases()?
> */
> -static int __set_cpus_allowed_ptr(struct task_struct *p,
> - const struct cpumask *new_mask, bool check)
> +static int __set_cpus_allowed_ptr_locked(struct task_struct *p,
> +const struct cpumask *new_mask,
> +bool check,
> +struct rq *rq,
> +struct rq_flags *rf)
> {
> const struct cpumask *cpu_valid_mask = cpu_active_mask;
> const struct cpumask *cpu_allowed_mask = task_cpu_possible_mask(p);
> unsigned int dest_cpu;
> - struct rq_flags rf;
> - struct rq *rq;
> int ret = 0;
>
> - rq = task_rq_lock(p, );
> update_rq_clock(rq);
>
> if (p->flags & PF_KTHREAD) {
> @@ -1936,7 +1930,7 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
> if (task_running(rq, p) || p->state == TASK_WAKING) {
> struct migration_arg arg = { p, dest_cpu };
> /* Need help from migration thread: drop lock and wait. */
> - task_rq_unlock(rq, p, );
> + task_rq_unlock(rq, p, rf);
> stop_one_cpu(cpu_of(rq), migration_cpu_stop, );
> return 0;
> } else if (task_on_rq_queued(p)) {
> @@ -1944,20 +1938,96 @@ static int __set_cpus_allowed_ptr(struct task_struct
> *p,
> * OK, since we're going to drop the lock immediately
> * afterwards anyway.
> */
> - rq = move_queued_task(rq, , p, dest_cpu);
> + rq = move_queued_task(rq, rf, p, dest_cpu);
> }
> out:
> - task_rq_unlock(rq, p, );
> + task_rq_unlock(rq, p, rf);
>
> return ret;
> }
>
> +/*
> + * Change a given task's CPU affinity. Migrate the thread to a
> + * proper CPU and schedule it away if the CPU it's executing on
> + * is removed from the allowed bitmask.
> + *
> + * NOTE: the caller must have a valid reference to the task, the
> + * task must not exit() & deallocate itself prematurely. The
> + * call is not atomic; no spinlocks may
Re: BUG: unable to handle kernel NULL pointer dereference in call_rcu
On Sun, 2020-12-27 at 20:51 +0100, Dmitry Vyukov wrote:
> /\/\/\/\On Sun, Dec 27, 2020 at 8:45 PM Andrew Morton
> wrote:
> >
> > (cc KASAN developers)
> >
> > On Sat, 26 Dec 2020 15:25:14 -0800 syzbot
> > wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:614cb589 Merge tag 'acpi-5.11-rc1-2' of
> > > git://git.kernel.o..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=10a82a50d0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13
> > > compiler: gcc (GCC) 10.1.0-syz 20200507
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > commit:
> > > Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com
> > >
> > > BUG: kernel NULL pointer dereference, address: 0008
> > > #PF: supervisor read access in kernel mode
> > > #PF: error_code(0x) - not-present page
> > > PGD 2d993067 P4D 2d993067 PUD 19a3c067 PMD 0
> > > Oops: [#1] PREEMPT SMP KASAN
> > > CPU: 1 PID: 3852 Comm: kworker/1:2 Not tainted 5.10.0-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Workqueue: events free_ipc
> > > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341
>
> +Walter, Andrey
>
> void kasan_record_aux_stack(void *addr)
> {
> ...
> alloc_meta = kasan_get_alloc_meta(cache, object);
> alloc_meta->aux_stack[1] = alloc_meta->aux_stack[0];
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> It crashes on NULL deref here, I assume alloc_meta is NULL. We may not
> have it for some slabs. Do we miss a NULL check here?
>
Hi Dmitry,
Yes, I will send a patch to fix it.
Thanks for your suggestion.
Walter
>
>
>
> > > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce
> > > 48 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89
> > > 43 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7
> > > RSP: 0018:c90002e6fae8 EFLAGS: 00010046
> > > RAX: RBX: RCX: 88803980
> > > RDX: 0078 RSI: 88803980 RDI: 0800
> > > RBP: 837ef3a0 R08: 0040 R09: 002e
> > > R10: 8132b7ea R11: 003f R12: 00035b40
> > > R13: 888039800088 R14: c90002e6fc08 R15: 0200
> > > FS: () GS:8880b9d0()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: 0008 CR3: 11841000 CR4: 001506e0
> > > DR0: DR1: DR2:
> > > DR3: DR6: fffe0ff0 DR7: 0400
> > > Call Trace:
> > > __call_rcu kernel/rcu/tree.c:2965 [inline]
> > > call_rcu+0xbb/0x710 kernel/rcu/tree.c:3038
> > > ipc_rcu_putref+0x83/0xb0 ipc/util.c:505
> > > freeary+0x139c/0x1b30 ipc/sem.c:1188
> > > free_ipcs+0x98/0x1e0 ipc/namespace.c:112
> > > sem_exit_ns+0x1b/0x40 ipc/sem.c:260
> > > free_ipc_ns ipc/namespace.c:124 [inline]
> > > free_ipc+0xf8/0x200 ipc/namespace.c:141
> > > process_one_work+0x98d/0x1630 kernel/workqueue.c:2275
> > > worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
> > > kthread+0x3b1/0x4a0 kernel/kthread.c:292
> > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
> > > Modules linked in:
> > > CR2: 0008
> > > ---[ end trace 28dc093e61d44dc2 ]---
> > > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341
> > > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce
> > > 48 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89
> > > 43 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7
> > > RSP: 0018:c90002e6fae8 EFLAGS: 00010046
> > > RAX: RBX: RCX: 88803980
> > > RDX: 0078 RSI: 88803980 RDI: 0800
> > > RBP: 837ef3a0 R08: 0040 R09: 002e
> > > R10: 8132b7ea R11: 003f R12: 00035b40
> > > R13: 888039800088 R14: c90002e6fc08 R15: 0200
> > > FS: () GS:8880b9d0()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: 0008 CR3: 11841000 CR4: 001506e0
> > > 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
Re: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for suspend/resume") causing hibernate resume failures
> From: Kenneth R. Crudup > > I've been running Linus' master branch on my laptop (Dell XPS 13 > 2-in-1). With this commit in place, after resuming from hibernate > my machine is essentially useless, with a torrent of disk I/O errors > on my NVMe device (at least, and possibly other devices affected) > until a reboot. > > I do use tlp to set the PCIe ASPM to "performance" on AC and > "powersupersave" on battery. Thanks a lot for the report, and sorry for the breakage. 4257f7e008ea restores PCI_L1SS_CTL1, then PCI_L1SS_CTL2. I think it should do those in the reverse order, since the Enable bits are in PCI_L1SS_CTL1. It also restores L1SS state (potentially enabling L1.x) before we restore the PCIe Capability (potentially enabling ASPM as a whole). Those probably should also be in the other order. If it's convenient, can you try the patch below? If the debug patch doesn't help: - Are you seeing the hibernate/resume problem when on AC or on battery? - What if you don't use tlp? Does hibernate/resume work fine then? If tlp makes a difference, can you collect "sudo lspci -vv" output with and without using tlp (before hibernate)? - If you revert 4257f7e008ea, does hibernate/resume work fine? Both with the tlp tweak and without? - Collect "sudo lspci -vv" output before hibernate and (if possible) after resume when you see the problem. I guess tlp only uses /sys/module/pcie_aspm/parameters/policy, so it sets the same ASPM policy system-wide. Bjorn diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b9fecc25d213..6598b5cd3154 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1665,9 +1665,8 @@ void pci_restore_state(struct pci_dev *dev) * LTR itself (in the PCIe capability). */ pci_restore_ltr_state(dev); - pci_restore_aspm_l1ss_state(dev); - pci_restore_pcie_state(dev); + pci_restore_aspm_l1ss_state(dev); pci_restore_pasid_state(dev); pci_restore_pri_state(dev); pci_restore_ats_state(dev); diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c index a08e7d6dc248..c4a99274b4bb 100644 --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -752,8 +752,8 @@ void pci_save_aspm_l1ss_state(struct pci_dev *dev) return; cap = (u32 *)_state->cap.data[0]; - pci_read_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, cap++); pci_read_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL2, cap++); + pci_read_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, cap++); } void pci_restore_aspm_l1ss_state(struct pci_dev *dev) @@ -774,8 +774,8 @@ void pci_restore_aspm_l1ss_state(struct pci_dev *dev) return; cap = (u32 *)_state->cap.data[0]; - pci_write_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, *cap++); pci_write_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL2, *cap++); + pci_write_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, *cap++); } static void pcie_config_aspm_dev(struct pci_dev *pdev, u32 val)
[PATCH] drm/amd/display: avoid null pointer dereference in dm_set_vblank
[Why]
Similar to commit("drm/amd/display: Guard against null crtc in
CRC IRQ"), a null pointer deference can occur if crtc is null in
dm_set_vblank.
[How]
Check that CRTC is non-null before accessing its fields.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e2b23486..f820962 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4875,11 +4875,19 @@ static inline int dm_set_vupdate_irq(struct drm_crtc
*crtc, bool enable)
static inline int dm_set_vblank(struct drm_crtc *crtc, bool enable)
{
enum dc_irq_source irq_source;
- struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
- struct amdgpu_device *adev = drm_to_adev(crtc->dev);
- struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
+ struct amdgpu_crtc *acrtc;
+ struct amdgpu_device *adev;
+ struct dm_crtc_state *acrtc_state;
int rc = 0;
+ if (crtc == NULL)
+ return -EINVAL;
+
+ acrtc = to_amdgpu_crtc(crtc);
+ adev = drm_to_adev(crtc->dev);
+ acrtc_state = to_dm_crtc_state(crtc->state);
+
+
if (enable) {
/* vblank irq on -> Only need vupdate irq in vrr mode */
if (amdgpu_dm_vrr_active(acrtc_state))
--
2.7.4
Re: [PATCH v5 08/15] cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus()
On Tue, Dec 8, 2020 at 5:29 AM Will Deacon wrote:
>
> Asymmetric systems may not offer the same level of userspace ISA support
> across all CPUs, meaning that some applications cannot be executed by
> some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do
> not feature support for 32-bit applications on both clusters.
>
> Modify guarantee_online_cpus() to take task_cpu_possible_mask() into
> account when trying to find a suitable set of online CPUs for a given
> task. This will avoid passing an invalid mask to set_cpus_allowed_ptr()
> during ->attach() and will subsequently allow the cpuset hierarchy to be
> taken into account when forcefully overriding the affinity mask for a
> task which requires migration to a compatible CPU.
>
> Cc: Li Zefan
> Cc: Tejun Heo
> Cc: Johannes Weiner
> Signed-off-by: Will Deacon
> ---
> include/linux/cpuset.h | 3 ++-
> kernel/cgroup/cpuset.c | 33 +++--
> 2 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
> index 04c20de66afc..414a8e694413 100644
> --- a/include/linux/cpuset.h
> +++ b/include/linux/cpuset.h
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #ifdef CONFIG_CPUSETS
> @@ -184,7 +185,7 @@ static inline void cpuset_read_unlock(void) { }
> static inline void cpuset_cpus_allowed(struct task_struct *p,
>struct cpumask *mask)
> {
> - cpumask_copy(mask, cpu_possible_mask);
> + cpumask_copy(mask, task_cpu_possible_mask(p));
> }
>
> static inline void cpuset_cpus_allowed_fallback(struct task_struct *p)
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index e970737c3ed2..d30febf1f69f 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -372,18 +372,26 @@ static inline bool is_in_v2_mode(void)
> }
>
> /*
> - * Return in pmask the portion of a cpusets's cpus_allowed that
> - * are online. If none are online, walk up the cpuset hierarchy
> - * until we find one that does have some online cpus.
> + * Return in pmask the portion of a task's cpusets's cpus_allowed that
> + * are online and are capable of running the task. If none are found,
> + * walk up the cpuset hierarchy until we find one that does have some
> + * appropriate cpus.
> *
> * One way or another, we guarantee to return some non-empty subset
> * of cpu_online_mask.
> *
> * Call with callback_lock or cpuset_mutex held.
> */
> -static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
> +static void guarantee_online_cpus(struct task_struct *tsk,
> + struct cpumask *pmask)
> {
> - while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
> + struct cpuset *cs = task_cs(tsk);
> + const struct cpumask *possible_mask = task_cpu_possible_mask(tsk);
> +
> + if (WARN_ON(!cpumask_and(pmask, possible_mask, cpu_online_mask)))
IIUC, this represents the case when there is no online CPU that can
run this task. In this situation guarantee_online_cpus() will return
an online CPU which can't run the task (because we ignore
possible_mask). I don't think this can be considered a valid fallback
path. However I think patch [13/15] ensures that we never end up in
this situation by disallowing to offline the last 32-bit capable CPU.
If that's true then maybe the patches can be reordered so that [13/15]
comes before this one and this condition can be treated as a bug here?
> + cpumask_copy(pmask, cpu_online_mask);
> +
> + while (!cpumask_intersects(cs->effective_cpus, pmask)) {
> cs = parent_cs(cs);
> if (unlikely(!cs)) {
> /*
> @@ -393,11 +401,10 @@ static void guarantee_online_cpus(struct cpuset *cs,
> struct cpumask *pmask)
> * cpuset's effective_cpus is on its way to be
> * identical to cpu_online_mask.
> */
> - cpumask_copy(pmask, cpu_online_mask);
> return;
> }
> }
> - cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
> + cpumask_and(pmask, pmask, cs->effective_cpus);
> }
>
> /*
> @@ -2176,15 +2183,13 @@ static void cpuset_attach(struct cgroup_taskset *tset)
>
> percpu_down_write(_rwsem);
>
> - /* prepare for attach */
> - if (cs == _cpuset)
> - cpumask_copy(cpus_attach, cpu_possible_mask);
> - else
> - guarantee_online_cpus(cs, cpus_attach);
> -
> guarantee_online_mems(cs, _attach_nodemask_to);
>
> cgroup_taskset_for_each(task, css, tset) {
> + if (cs != _cpuset)
> + guarantee_online_cpus(task, cpus_attach);
> + else
> + cpumask_copy(cpus_attach,
> task_cpu_possible_mask(task));
> /*
>
[PATCH V1] nohz: exit nohz idle before invoking softirq
From: "shiyan.csy" exit nohz idle before invoking softirq, or it maymiss some ticks during softirq. Signed-off-by: Shiyan Chen --- kernel/softirq.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/softirq.c b/kernel/softirq.c index 9d71046..59bd6fe 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -404,6 +404,10 @@ static inline void tick_irq_exit(void) if (!in_irq()) tick_nohz_irq_exit(); } + + /* need to exit nohz idle if there's a softirq */ + if (in_serving_softirq() || local_softirq_pending()) + tick_nohz_idle_exit(); #endif } @@ -416,10 +420,11 @@ static inline void __irq_exit_rcu(void) #endif account_hardirq_exit(current); preempt_count_sub(HARDIRQ_OFFSET); - if (!in_interrupt() && local_softirq_pending()) - invoke_softirq(); + /* must call before invoke_softirq */ tick_irq_exit(); + if (!in_interrupt() && local_softirq_pending()) + invoke_softirq(); } /** -- 1.8.3.1
[PATCH] fs: amend SLAB_RECLAIM_ACCOUNT on gfs2_quotad_cachep
From: Zhaoyang Huang
As gfs2_quotad_cachep has registered the shrinker, amending
SLAB_RECLAIM_ACCOUNT when create gfs2_quotad_cachep, which
make the slab acount to be presiced.
Signed-off-by: Zhaoyang Huang
---
fs/gfs2/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/gfs2/main.c b/fs/gfs2/main.c
index 136484e..db39de9 100644
--- a/fs/gfs2/main.c
+++ b/fs/gfs2/main.c
@@ -136,7 +136,7 @@ static int __init init_gfs2_fs(void)
gfs2_quotad_cachep = kmem_cache_create("gfs2_quotad",
sizeof(struct gfs2_quota_data),
- 0, 0, NULL);
+ 0, SLAB_RECLAIM_ACCOUNT, NULL);
if (!gfs2_quotad_cachep)
goto fail_cachep6;
--
1.9.1
[PATCH] x86: Include thunk_$(BITS).o only if CONFIG_PREEMPTION=y
The newer GNU assembler may not generate a symbol table for the empty object file. Since objtool doesn't like empty object files without symbol table and thunk_$(BITS).o doesn't have a symbol table when CONFIG_PREEMPTION isn't enabled, include thunk_$(BITS).o only if CONFIG_PREEMPTION is enabled. Signed-off-by: H.J. Lu --- arch/x86/entry/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile index 08bf95dbc911..83c98dae74a6 100644 --- a/arch/x86/entry/Makefile +++ b/arch/x86/entry/Makefile @@ -21,12 +21,13 @@ CFLAGS_syscall_64.o += $(call cc-option,-Wno-override-init,) CFLAGS_syscall_32.o+= $(call cc-option,-Wno-override-init,) CFLAGS_syscall_x32.o += $(call cc-option,-Wno-override-init,) -obj-y := entry_$(BITS).o thunk_$(BITS).o syscall_$(BITS).o +obj-y := entry_$(BITS).o syscall_$(BITS).o obj-y += common.o obj-y += vdso/ obj-y += vsyscall/ +obj-$(CONFIG_PREEMPTION) += thunk_$(BITS).o obj-$(CONFIG_IA32_EMULATION) += entry_64_compat.o syscall_32.o obj-$(CONFIG_X86_X32_ABI) += syscall_x32.o -- 2.29.2
[PATCH] perf record: Tweak "Lowering..." warning in record_opts__config_freq
That is, instead of "Lowering default frequency rate to " say
"Lowering default frequency rate from to ", specifying
the overridden default frequency , so you don't have to grep
through the source to "remember" that was e.g. 4000.
Signed-off-by: Hans-Peter Nilsson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Adrian Hunter
Cc: Kan Liang
Cc: Ian Rogers
---
tools/perf/util/record.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index 07e4b96a6625..3b38e7be10da 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c
@@ -202,10 +202,10 @@ static int record_opts__config_freq(struct record_opts
*opts)
* Default frequency is over current maximum.
*/
if (max_rate < opts->freq) {
- pr_warning("Lowering default frequency rate to %u.\n"
+ pr_warning("Lowering default frequency rate from %u to %u.\n"
"Please consider tweaking "
"/proc/sys/kernel/perf_event_max_sample_rate.\n",
- max_rate);
+ opts->freq, max_rate);
opts->freq = max_rate;
}
--
2.11.0
brgds, H-P
[PATCH] locking/qspinlock: Modify comments to adapt to code modification.
The function 'pv_wait_head_or_lock' comment is not modified in
commit 625e88be1f41 ("locking/qspinlock: Merge 'struct __qspinlock'
into 'struct qspinlock'"). Fix it.
Signed-off-by: Xiangyang Yu
---
kernel/locking/qspinlock_paravirt.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/locking/qspinlock_paravirt.h
b/kernel/locking/qspinlock_paravirt.h
index e84d21aa0722..0b7ecf4eb8b8 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -393,7 +393,7 @@ static void pv_kick_node(struct qspinlock *lock, struct
mcs_spinlock *node)
}
/*
- * Wait for l->locked to become clear and acquire the lock;
+ * Wait for lock->locked to become clear and acquire the lock;
* halt the vcpu after a short spin.
* __pv_queued_spin_unlock() will wake us.
*
@@ -447,9 +447,9 @@ pv_wait_head_or_lock(struct qspinlock *lock, struct
mcs_spinlock *node)
* when we observe _Q_SLOW_VAL in
__pv_queued_spin_unlock()
* we'll be sure to be able to observe our hash entry.
*
-* [S] [Rmw] l->locked ==
_Q_SLOW_VAL
-* MB RMB
-* [RmW] l->locked = _Q_SLOW_VAL [L]
+* [S] [Rmw] lock->locked
== _Q_SLOW_VAL
+* MB RMB
+* [RmW] lock->locked = _Q_SLOW_VAL [L]
*
* Matches the smp_rmb() in __pv_queued_spin_unlock().
*/
--
2.23.0
[PATCH] cpuset: Remove stale URLs in the MAINTAINERS entry
Those URLs are no longer accessable. Reported-by: Steve Wahl Signed-off-by: Zefan Li --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ae9b1dd748c4..2fe8eb54639e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4477,8 +4477,6 @@ CONTROL GROUP - CPUSET M: Li Zefan L: cgro...@vger.kernel.org S: Maintained -W: http://www.bullopensource.org/cpuset/ -W: http://oss.sgi.com/projects/cpusets/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git F: Documentation/admin-guide/cgroup-v1/cpusets.rst F: include/linux/cpuset.h -- 2.22.0
arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: sparse: incorrect type in argument 1 (different base types)
Hi Luc,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5c8fe583cce542aa0b84adc939ce85293de36e5e
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 4 months ago
config: sh-randconfig-s032-20201223 (attached as .config)
compiler: sh4-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-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# 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=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: sparse: incorrect type in
>> argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned long addr @@
arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: got unsigned long addr
>> arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: sparse: incorrect type in
>> argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned long addr @@
arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/cpu/irq/ipr.c:35:9: sparse: got unsigned long addr
arch/sh/kernel/cpu/irq/ipr.c:36:15: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long addr @@
arch/sh/kernel/cpu/irq/ipr.c:36:15: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/cpu/irq/ipr.c:36:15: sparse: got unsigned long addr
arch/sh/kernel/cpu/irq/ipr.c:44:9: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long addr @@
arch/sh/kernel/cpu/irq/ipr.c:44:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/cpu/irq/ipr.c:44:9: sparse: got unsigned long addr
arch/sh/kernel/cpu/irq/ipr.c:44:9: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long addr @@
arch/sh/kernel/cpu/irq/ipr.c:44:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/cpu/irq/ipr.c:44:9: sparse: got unsigned long addr
--
arch/sh/kernel/cpu/sh3/probe.c:30:18: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long [assigned] addr0 @@
arch/sh/kernel/cpu/sh3/probe.c:30:18: sparse: expected void const
volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh3/probe.c:30:18: sparse: got unsigned long
[assigned] addr0
arch/sh/kernel/cpu/sh3/probe.c:31:9: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long [assigned] addr0 @@
arch/sh/kernel/cpu/sh3/probe.c:31:9: sparse: expected void const
volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh3/probe.c:31:9: sparse: got unsigned long
[assigned] addr0
arch/sh/kernel/cpu/sh3/probe.c:32:18: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long [assigned] addr1 @@
arch/sh/kernel/cpu/sh3/probe.c:32:18: sparse: expected void const
volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh3/probe.c:32:18: sparse: got unsigned long
[assigned] addr1
arch/sh/kernel/cpu/sh3/probe.c:33:9: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long [assigned] addr1 @@
arch/sh/kernel/cpu/sh3/probe.c:33:9: sparse: expected void const
volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh3/probe.c:33:9: sparse: got unsigned long
[assigned] addr1
arch/sh/kernel/cpu/sh3/probe.c:36:17: sparse: sparse: incorrect type in
argument 1 (different base types) @@ expected void const volatile [noderef]
__iomem *ptr
[PATCH] powerpc/mm: add sanity check to avoid null pointer dereference
Similar to commit<0dc294f717d4>("powerpc/mm: bail out early when flushing TLB
page"),
there should be a check for 'mm' to prevent Null pointer dereference
in case of 'mm' argument was legitimately passed.
Signed-off-by: Defang Bo
---
arch/powerpc/mm/nohash/tlb.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index 5872f69..1d89335 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -192,6 +192,9 @@ void local_flush_tlb_mm(struct mm_struct *mm)
{
unsigned int pid;
+ if (WARN_ON(!mm))
+ return;
+
preempt_disable();
pid = mm->context.id;
if (pid != MMU_NO_CONTEXT)
@@ -205,8 +208,11 @@ void __local_flush_tlb_page(struct mm_struct *mm, unsigned
long vmaddr,
{
unsigned int pid;
+ if (WARN_ON(!mm))
+ return;
+
preempt_disable();
- pid = mm ? mm->context.id : 0;
+ pid = mm->context.id;
if (pid != MMU_NO_CONTEXT)
_tlbil_va(vmaddr, pid, tsize, ind);
preempt_enable();
@@ -268,6 +274,9 @@ void flush_tlb_mm(struct mm_struct *mm)
{
unsigned int pid;
+ if (WARN_ON(!mm))
+ return;
+
preempt_disable();
pid = mm->context.id;
if (unlikely(pid == MMU_NO_CONTEXT))
--
2.7.4
Re: Re: [PATCH] net/mlx5e: Fix two double free cases
> On Mon, Dec 21, 2020 at 04:50:31PM +0800, Dinghao Liu wrote: > > mlx5e_create_ttc_table_groups() frees ft->g on failure of > > kvzalloc(), but such failure will be caught by its caller > > in mlx5e_create_ttc_table() and ft->g will be freed again > > in mlx5e_destroy_flow_table(). The same issue also occurs > > in mlx5e_create_ttc_table_groups(). > > > > Signed-off-by: Dinghao Liu > > --- > > drivers/net/ethernet/mellanox/mlx5/core/en_fs.c | 8 ++-- > > 1 file changed, 2 insertions(+), 6 deletions(-) > > I'm not thrilled to see release in the error flow that will be done in > the different function. The missing piece is "ft->g = NULL" after kfree(). > > And also fixes lines are missing in all your patches. > Thank you for your advice! I will resend a new patch soon. Regards, Dinghao
[PATCH V3] drm/ast: Fixed CVE for DP501
[Bug][DP501]
If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for
CVE_2019_6260 item3, and then the monitor's EDID is unable read through
Parade DP501.
The reason is the DP501's FW is mapped to BMC addressing space rather
than Host addressing space.
The resolution is that using "pci_iomap_range()" maps to DP501's FW that
stored on the end of FB (Frame Buffer).
0In this case, FrameBuffer reserves the last 2MB used for the image of
DP501.
Signed-off-by: KuoHsiang Chou
Reported-by: kernel test robot
---
drivers/gpu/drm/ast/ast_dp501.c | 139 +++-
drivers/gpu/drm/ast/ast_drv.h | 12 +++
drivers/gpu/drm/ast/ast_main.c | 8 ++
3 files changed, 123 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index 88121c0e0d05..cd93c44f2662 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -189,6 +189,9 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32
size)
u32 i, data;
u32 boot_address;
+ if (ast->config_mode != ast_use_p2a)
+ return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (data) {
boot_address = get_fw_base(ast);
@@ -207,6 +210,9 @@ static bool ast_launch_m68k(struct drm_device *dev)
u8 *fw_addr = NULL;
u8 jreg;
+ if (ast->config_mode != ast_use_p2a)
+ return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (!data) {
@@ -271,25 +277,55 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev)
struct ast_private *ast = to_ast_private(dev);
u32 boot_address, offset, data;
u8 linkcap[4], linkrate, linklanes, maxclk = 0xff;
+ u32 *plinkcap;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10) /* version: 1x */
- return maxclk;
-
- /* Read Link Capability */
- offset = 0xf014;
- *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
- if (linkcap[2] == 0) {
- linkrate = linkcap[0];
- linklanes = linkcap[1];
- data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * linklanes);
- if (data > 0xff)
- data = 0xff;
- maxclk = (u8)data;
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
+
+ /* validate FW version */
+ offset = AST_DP501_GBL_VERSION;
+ data = ast_mindwm(ast, boot_address + offset);
+ if ((data & AST_DP501_FW_VERSION_MASK) !=
AST_DP501_FW_VERSION_1) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = AST_DP501_LINKRATE;
+ plinkcap = (u32 *)linkcap;
+ *plinkcap = ast_mindwm(ast, boot_address + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
+ } else {
+ if (!ast->dp501_fw_buf)
+ return AST_DP501_DEFAULT_DCLK; /* 1024x768 as default
*/
+
+ /* dummy read */
+ offset = 0x;
+ data = readl(ast->dp501_fw_buf + offset);
+
+ /* validate FW version */
+ offset = AST_DP501_GBL_VERSION;
+ data = readl(ast->dp501_fw_buf + offset);
+ if ((data & AST_DP501_FW_VERSION_MASK) !=
AST_DP501_FW_VERSION_1) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = AST_DP501_LINKRATE;
+ plinkcap = (u32 *)linkcap;
+ *plinkcap = readl(ast->dp501_fw_buf + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
}
return maxclk;
}
@@ -298,26 +334,57 @@ bool ast_dp501_read_edid(struct drm_device *dev, u8
*ediddata)
{
struct ast_private *ast = to_ast_private(dev);
u32 i, boot_address, offset, data;
+ u32 *pEDIDidx;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10)
- return false;
-
Re: Re: [PATCH] IB/sa: Fix memleak in ib_nl_make_request
> On Sun, Dec 20, 2020 at 04:13:14PM +0800, Dinghao Liu wrote: > > When rdma_nl_multicast() fails, skb should be freed > > just like when ibnl_put_msg() fails. > > It is not so simple as you wrote in the description. > > There are no other places in the linux kernel that free > SKBs after netlink_multicast() failure. > It's clear for me, thanks. Regards, Dinghao
[PATCH V3] drm/ast: Fixed CVE for DP501
[Bug][DP501]
If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for
CVE_2019_6260 item3, and then the monitor's EDID is unable read through
Parade DP501.
The reason is the DP501's FW is mapped to BMC addressing space rather
than Host addressing space.
The resolution is that using "pci_iomap_range()" maps to DP501's FW that
stored on the end of FB (Frame Buffer).
0In this case, FrameBuffer reserves the last 2MB used for the image of
DP501.
Signed-off-by: KuoHsiang Chou
Reported-by: kernel test robot
---
drivers/gpu/drm/ast/ast_dp501.c | 139 +++-
drivers/gpu/drm/ast/ast_drv.h | 12 +++
drivers/gpu/drm/ast/ast_main.c | 8 ++
3 files changed, 123 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index 88121c0e0d05..cd93c44f2662 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -189,6 +189,9 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32
size)
u32 i, data;
u32 boot_address;
+ if (ast->config_mode != ast_use_p2a)
+ return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (data) {
boot_address = get_fw_base(ast);
@@ -207,6 +210,9 @@ static bool ast_launch_m68k(struct drm_device *dev)
u8 *fw_addr = NULL;
u8 jreg;
+ if (ast->config_mode != ast_use_p2a)
+ return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (!data) {
@@ -271,25 +277,55 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev)
struct ast_private *ast = to_ast_private(dev);
u32 boot_address, offset, data;
u8 linkcap[4], linkrate, linklanes, maxclk = 0xff;
+ u32 *plinkcap;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10) /* version: 1x */
- return maxclk;
-
- /* Read Link Capability */
- offset = 0xf014;
- *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
- if (linkcap[2] == 0) {
- linkrate = linkcap[0];
- linklanes = linkcap[1];
- data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * linklanes);
- if (data > 0xff)
- data = 0xff;
- maxclk = (u8)data;
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
+
+ /* validate FW version */
+ offset = AST_DP501_GBL_VERSION;
+ data = ast_mindwm(ast, boot_address + offset);
+ if ((data & AST_DP501_FW_VERSION_MASK) !=
AST_DP501_FW_VERSION_1) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = AST_DP501_LINKRATE;
+ plinkcap = (u32 *)linkcap;
+ *plinkcap = ast_mindwm(ast, boot_address + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
+ } else {
+ if (!ast->dp501_fw_buf)
+ return AST_DP501_DEFAULT_DCLK; /* 1024x768 as default
*/
+
+ /* dummy read */
+ offset = 0x;
+ data = readl(ast->dp501_fw_buf + offset);
+
+ /* validate FW version */
+ offset = AST_DP501_GBL_VERSION;
+ data = readl(ast->dp501_fw_buf + offset);
+ if ((data & AST_DP501_FW_VERSION_MASK) !=
AST_DP501_FW_VERSION_1) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = AST_DP501_LINKRATE;
+ plinkcap = (u32 *)linkcap;
+ *plinkcap = readl(ast->dp501_fw_buf + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
}
return maxclk;
}
@@ -298,26 +334,57 @@ bool ast_dp501_read_edid(struct drm_device *dev, u8
*ediddata)
{
struct ast_private *ast = to_ast_private(dev);
u32 i, boot_address, offset, data;
+ u32 *pEDIDidx;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10)
- return false;
-
[PATCH v6 3/4] MIPS: Loongson64: DTS: Add SPI support to LS7A
Add spi support.
Reviewed-by: Huacai Chen
Signed-off-by: Qing Zhang
---
v2:
- Add spi about pci device DT
v3:
- Remove spiflash node
v4:
- Remove useless compatible
v5:
- Remove num-chipselects
v6:
- No changes
---
arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index f99a7a1..dba717d 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -405,6 +405,15 @@
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 39
IRQ_TYPE_LEVEL_HIGH>;
};
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ };
};
isa {
--
2.1.0
[PATCH v6 4/4] MIPS: Loongson: Enable Loongson LS7A SPI in loongson3_defconfig
This is now supported, enable for Loongson systems. Reviewed-by: Huacai Chen Signed-off-by: Qing Zhang --- v2: - Modify CONFIG_SPI_LOONGSON to CONFIG_SPI_LS7A v3: - No changes v4: - No changes v5: - No changes v6: - No changes --- arch/mips/configs/loongson3_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index 38a817e..28784cb 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -271,6 +271,9 @@ CONFIG_HW_RANDOM=y CONFIG_RAW_DRIVER=m CONFIG_I2C_CHARDEV=y CONFIG_I2C_PIIX4=y +CONFIG_SPI=y +CONFIG_SPI_MASTER=y +CONFIG_SPI_LS7A=y CONFIG_GPIO_LOONGSON=y CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM93=m -- 2.1.0
[PATCH v6 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
The SPI controller has the following characteristics:
- Full-duplex synchronous serial data transmission
- Support up to 4 variable length byte transmission
- Main mode support
- Mode failure generates an error flag and issues an interrupt request
- Double buffer receiver
- Serial clock with programmable polarity and phase
- SPI can be controlled in wait mode
- Support boot from SPI
Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
eg:
[root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
Erased 262144 bytes from address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
Copied 13 bytes from 1.img to address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
Copied 13 bytes from address 0x0002 in flash to 2.img
[root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
Signed-off-by: Qing Zhang
---
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
- Fix unclear indentation
- make conditional statements to improve legibility
- Don't use static inline
- the core handle message queue
- Add a new binding document
- Fix probe part mixed pdev and PCI
v3:
- expose set_cs to the core and let it handle things
- replace transfer_one_message to transfer_one
- replace spi_alloc_master to devm_spi_alloc_master
- split out into prepare/unprepare_message
- releases pci regions before unregister master
v4:
- names used in the manual
- rename ls7a_spi_do_transfer to ls7a_spi_setup_transfer
- change read the spcr and sper outside of this function
- mode configuration moved to prepare instead
- remove redundancy code about unprepare/prepare_message
- used 0x4 instead of 0x1,WFEMPTY instead of RFEMPTY
v5:
- remove unnecessary blank lines
v6:
- keep blank line before the last "return xxx"
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-ls7a.c | 282 +
3 files changed, 290 insertions(+)
create mode 100644 drivers/spi/spi-ls7a.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aadaea0..af7c0d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -413,6 +413,13 @@ config SPI_LP8841_RTC
Say N here unless you plan to run the kernel on an ICP DAS
LP-8x4x industrial computer.
+config SPI_LS7A
+ tristate "Loongson LS7A SPI Controller Support"
+ depends on CPU_LOONGSON64 || COMPILE_TEST
+ help
+ This drivers supports the Loongson LS7A SPI controller in master
+ SPI mode.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea582..d015cf2 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
+obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
new file mode 100644
index 000..8592b85
--- /dev/null
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Loongson LS7A SPI Controller driver
+//
+// Copyright (C) 2020 Loongson Technology Corporation Limited.
+//
+
+#include
+#include
+#include
+
+/* define spi register */
+#defineSPCR0x00
+#defineSPSR0x01
+#defineFIFO0x02
+#defineSPER0x03
+#defineSFC_PARAM 0x04
+#defineSFC_SOFTCS 0x05
+#defineSFC_TIMING 0x06
+
+struct ls7a_spi {
+ struct spi_master *master;
+ void __iomem *base;
+ unsigned int hz;
+ unsigned int mode;
+};
+
+static void ls7a_spi_write_reg(struct ls7a_spi *spi,
+ unsigned char reg,
+ unsigned char data)
+{
+ writeb(data, spi->base + reg);
+}
+
+static char ls7a_spi_read_reg(struct ls7a_spi *spi, unsigned char reg)
+{
+ return readb(spi->base + reg);
+}
+
+static int ls7a_spi_prepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct ls7a_spi *ls7a_spi;
+ struct spi_device *spi = msg->spi;
+ unsigned char val;
+
+ ls7a_spi = spi_master_get_devdata(master);
+
+ if (ls7a_spi->mode != spi->mode) {
+ val = ls7a_spi_read_reg(ls7a_spi, SPCR);
+ val &= ~0xc;
+ if (spi->mode & SPI_CPOL)
+ val |= 8;
+
[PATCH v6 2/4] spi: ls7a: Add YAML schemas
Switch the DT binding to a YAML schema to enable the DT validation.
Reviewed-by: Huacai Chen
Signed-off-by: Qing Zhang
---
v4:
- fix warnings/errors about running 'make dt_binding_check'
v5:
- remove num-chipelects
v6:
- No changes
---
.../devicetree/bindings/spi/loongson,spi-ls7a.yaml | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
diff --git a/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
new file mode 100644
index 000..b90b28b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/loongson,spi-ls7a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A PCH SPI Controller
+
+maintainers:
+ - Qing Zhang
+
+description: |
+ This controller can be found in Loongson-3 systems with LS7A PCH.
+
+properties:
+ compatible:
+const: loongson,ls7a-spi
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+pci {
+#address-cells = <3>;
+#size-cells = <2>;
+
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0800";
+
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+};
+};
+
+...
--
2.1.0
[PATCH net v2] net: hdlc_ppp: Fix issues when mod_timer is called while timer is running
ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
held. It may call mod_timer to add a new timer. However, at the same time
ppp_timer may be already running and waiting for "ppp->lock". In this
case, there's no need for ppp_timer to continue running and it can just
exit.
If we let ppp_timer continue running, it may call add_timer. This causes
kernel panic because add_timer can't be called with a timer pending.
This patch fixes this problem.
Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic
HDLC.")
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_ppp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index 64f855651336..261b53fc8e04 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net/wan/hdlc_ppp.c
@@ -569,6 +569,13 @@ static void ppp_timer(struct timer_list *t)
unsigned long flags;
spin_lock_irqsave(>lock, flags);
+ /* mod_timer could be called after we entered this function but
+* before we got the lock.
+*/
+ if (timer_pending(>timer)) {
+ spin_unlock_irqrestore(>lock, flags);
+ return;
+ }
switch (proto->state) {
case STOPPING:
case REQ_SENT:
--
2.27.0
Re: [PATCH v2 0/3] RFC: Solve several problems in stage 2 translation
Hi Will, Marc, Gently Ping. Is there any comments about this V2 series? Many thanks, Yanan. On 2020/12/16 20:28, Yanan Wang wrote: Hi, this is the second version, thanks for reading. PATCH1/3: Procedures of hyp stage 1 mapping and guest stage 2 mapping are different, but they are tied closely by function kvm_set_valid_leaf_pte(). So separate them by rewriting kvm_set_valid_leaf_pte(). PATCH2/3: To avoid unnecessary update and small loops, add prejudgement in the translation fault handler: Skip updating the PTE with break-before-make if we are trying to recreate the exact same mapping or only change the access permissions. Actually, change of permissions will be handled through the relax_perms path next time if necessary. (1) If there are some vCPUs accessing the same GPA at the same time and the leaf PTE is not set yet, then they will all cause translation faults and the first vCPU holding mmu_lock will set valid leaf PTE, and the others will later update the old PTE with a new one if they are different. (2) When changing a leaf entry or a table entry with break-before-make, if there are some vCPUs accessing the same GPA just catch the moment when the target PTE is set invalid in a BBM procedure coincidentally, they will all cause translation faults and will later update the old PTE with a new one if they are different. The worst case can be like this: vCPU A causes a translation fault with RW prot and sets the leaf PTE with RW permissions, and then the next vCPU B with RO prot updates the PTE back to RO permissions with break-before-make. And the BBM-invalid moment may trigger more unnecessary translation faults, then some useless small loops might occur which could lead to vCPU stuck. PATCH3/3: We now mark the page dirty and set the bitmap before calling fault handlers in user_mem_abort(), and we might end up having spurious dirty pages if update of permissions or mapping has failed. So, mark the page dirty only if the fault is handled successfully. Let the guest directly enter again but not return to userspace if we were trying to recreate the same mapping or only change access permissions with BBM, which is not permitted in the mapping path. Changes from v1: - Make part of the diff as an independent patch (PATCH1/3), and add Will's Signed-off-by. - Use *return -EPERM* way when changing permissions only in the mapping path. - Add a new patch (PATCH3/3). Yanan Wang (3): KVM: arm64: Decouple partial code of hyp stage 1 mapping and guest stage 2 mapping KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler KVM: arm64: Mark the page dirty only if the fault is handled successfully arch/arm64/kvm/hyp/pgtable.c | 78 arch/arm64/kvm/mmu.c | 18 +++-- 2 files changed, 58 insertions(+), 38 deletions(-)
[PATCH] perf arm64: Simplify mksyscalltbl
This patch isn't intended to have any effect on the compiled
code. It just removes one level of indirection: calling the
*host* compiler to build and then run a program that just
printf:s the numerical entries of the syscall-table. In other
words, the generated syscalls.c changes from:
[46] = "ftruncate",
to:
[__NR3264_ftruncate] = "ftruncate",
The latter is as good as the former to the user of perf, and
this can be done directly by the shell-script. The syscalls
defined as non-literal values (like "#define __NR_ftruncate
__NR3264_ftruncate") are trivially resolved at compile-time
without namespace-leaking and/or collision for its sole user,
perf/util/syscalltbl.c, that just #includes the generated file.
A future "-mabi=32" support would probably have to handle this
differently, but that is a pre-existing problem not affected by
this simplification.
Calling the *host* compiler only complicates things and
accidentally can get a completely wrong set of files and syscall
numbers, see earlier commits. Note that the script parameter
hostcc is now unused.
At the time of this patch, powerpc (the origin, see comments),
and also e.g. x86 has moved on, from filtering "gcc -dM -E"
output to reading separate specific text-file, a table of
syscall numbers. IMHO should arm64 consider adopting this.
Signed-off-by: Hans-Peter Nilsson
Cc: John Garry
Cc: Will Deacon
Cc: Mathieu Poirier
Cc: Leo Yan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Kim Phillips
---
tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index a7ca48d1e37b..22cdf911dd9a 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -23,34 +23,17 @@ create_table_from_c()
{
local sc nr last_sc
- create_table_exe=`mktemp ${TMPDIR:-/tmp}/create-table-XX`
-
- {
-
- cat <<-_EoHEADER
- #include
- #include "$input"
- int main(int argc, char *argv[])
- {
- _EoHEADER
-
while read sc nr; do
- printf "%s\n" " printf(\"\\t[%d] = \\\"$sc\\\",\\n\",
__NR_$sc);"
+ printf "%s\n" " [$nr] = \"$sc\","
last_sc=$sc
done
- printf "%s\n" " printf(\"#define SYSCALLTBL_ARM64_MAX_ID %d\\n\",
__NR_$last_sc);"
- printf "}\n"
-
- } | $hostcc -I $incpath/include/uapi -o $create_table_exe -x c -
-
- $create_table_exe
-
- rm -f $create_table_exe
+ printf "%s\n" "#define SYSCALLTBL_ARM64_MAX_ID __NR_$last_sc"
}
create_table()
{
+ echo "#include \"$input\""
echo "static const char *syscalltbl_arm64[] = {"
create_table_from_c
echo "};"
--
2.11.0
brgds, H-P
[PATCH] m68k: let clk_enable() return immediately if clk is NULL
Similar to commit<742859adc721>("m68k: let clk_disable() return immediately if
clk is NULL").
there should be a check for clk to prevent NULL pointer dereference.
Signed-off-by: Defang Bo
---
arch/m68k/coldfire/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 7bc666e..6decd11 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -90,6 +90,9 @@ EXPORT_SYMBOL(clk_get);
int clk_enable(struct clk *clk)
{
unsigned long flags;
+ if (!clk)
+ return -EINVAL;
+
spin_lock_irqsave(_lock, flags);
if ((clk->enabled++ == 0) && clk->clk_ops)
clk->clk_ops->enable(clk);
--
2.7.4
{standard input}:533: Error: opcode not supported on this processor: mips3 (mips3) `dins $8,$11,32,32'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5c8fe583cce542aa0b84adc939ce85293de36e5e
commit: c7e2d71dda7ac4731bae54a25c49cd81fe7b9046 MIPS: Fix set_pte() for
Netlogic XLR using cmpxchg64()
date: 1 year, 11 months ago
config: mips-randconfig-c004-20201228 (attached as .config)
compiler: mipsel-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=c7e2d71dda7ac4731bae54a25c49cd81fe7b9046
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout c7e2d71dda7ac4731bae54a25c49cd81fe7b9046
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:533: Error: opcode not supported on this processor: mips3
>> (mips3) `dins $8,$11,32,32'
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for TI_SOC_THERMAL
Depends on THERMAL && (ARCH_HAS_BANDGAP || COMPILE_TEST && HAS_IOMEM
Selected by
- MMC_SDHCI_OMAP && MMC && MMC_SDHCI_PLTFM && OF
WARNING: unmet direct dependencies detected for TI_SOC_THERMAL
Depends on THERMAL && (ARCH_HAS_BANDGAP || COMPILE_TEST && HAS_IOMEM
Selected by
- MMC_SDHCI_OMAP && MMC && MMC_SDHCI_PLTFM && OF
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] perf arm64: Fix mksyscalltbl, don't lose syscalls due to sort -nu
When using "sort -nu", arm64 syscalls were lost. That is, the io_setup syscall (number 0) and all but one (typically ftruncate; 64) of the syscalls that are defined symbolically (like "#define __NR_ftruncate __NR3264_ftruncate") at the point where "sort" is applied. This creation-of-syscalls.c-scheme is, judging from comments, copy-pasted from powerpc, and worked there because at the time, its tools/arch/powerpc/include/uapi/asm/unistd.h had *literals*, like "#define __NR_ftruncate 93". With sort being numeric and the non-numeric key effectively evaluating to 0, the sort option "-u" means these "duplicates" are removed. There's no need to remove syscall lines with duplicate numbers for arm64 because there are none, so let's fix that by just losing the "-u". Having the table numerically sorted on syscall-number for the rest of the syscalls looks nice, so keep the "-n". Signed-off-by: Hans-Peter Nilsson Cc: John Garry Cc: Will Deacon Cc: Mathieu Poirier Cc: Leo Yan Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Mark Rutland Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Kim Phillips --- tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl index 459469b7222c..a7ca48d1e37b 100755 --- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl +++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl @@ -58,5 +58,5 @@ create_table() $gcc -E -dM -x c -I $incpath/include/uapi $input \ |sed -ne 's/^#define __NR_//p' \ - |sort -t' ' -k2 -nu\ + |sort -t' ' -k2 -n \ |create_table -- 2.11.0 brgds, H-P
Re: [linux-sunxi] Re: [PATCH RESEND] ARM: configs: sunxi: enable brcm wireless
On Mon, Dec 28, 2020 at 4:03 AM Jernej Škrabec wrote: > > Hi! > > Dne nedelja, 27. december 2020 ob 21:00:00 CET je Corentin Labbe napisal(a): > > Lot of sunxi boards have BRCM wireless device, so let's enable necessary > > options for it in our defconfig. > > Idea is good but modules (=m) instead of build in (=y) would be better. As you > said, not all boards have such wifi and there is no need to make kernel binary > bigger. It's probably not very useful on its own if built in, since it also needs firmware blobs, and when built in it doesn't wait for the rootfs to be available. ChenYu > Best regards, > Jernej > > > > > Signed-off-by: Corentin Labbe > > --- > > arch/arm/configs/sunxi_defconfig | 23 ++- > > 1 file changed, 22 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm/configs/sunxi_defconfig > > b/arch/arm/configs/sunxi_defconfig index a60c134c5e04..4891aefdef7d 100644 > > --- a/arch/arm/configs/sunxi_defconfig > > +++ b/arch/arm/configs/sunxi_defconfig > > @@ -52,7 +52,28 @@ CONFIG_STMMAC_ETH=y > > # CONFIG_NET_VENDOR_WIZNET is not set > > CONFIG_MICREL_PHY=y > > CONFIG_REALTEK_PHY=y > > -# CONFIG_WLAN is not set > > +CONFIG_WLAN=y > > +# CONFIG_WLAN_VENDOR_ADMTEK is not set > > +# CONFIG_WLAN_VENDOR_ATH is not set > > +# CONFIG_WLAN_VENDOR_ATMEL is not set > > +CONFIG_WLAN_VENDOR_BROADCOM=y > > +# CONFIG_WLAN_VENDOR_CISCO is not set > > +# CONFIG_WLAN_VENDOR_INTEL is not set > > +# CONFIG_WLAN_VENDOR_INTERSIL is not set > > +# CONFIG_WLAN_VENDOR_MARVELL is not set > > +# CONFIG_WLAN_VENDOR_MEDIATEK is not set > > +# CONFIG_WLAN_VENDOR_MICROCHIP is not set > > +# CONFIG_WLAN_VENDOR_RALINK is not set > > +# CONFIG_WLAN_VENDOR_REALTEK is not set > > +# CONFIG_WLAN_VENDOR_RSI is not set > > +# CONFIG_WLAN_VENDOR_ST is not set > > +# CONFIG_WLAN_VENDOR_TI is not set > > +# CONFIG_WLAN_VENDOR_ZYDAS is not set > > +# CONFIG_WLAN_VENDOR_QUANTENNA is not set > > +CONFIG_CFG80211=y > > +CONFIG_CFG80211_WEXT=y > > +CONFIG_MAC80211=y > > +CONFIG_BRCMFMAC=y > > CONFIG_INPUT_EVDEV=y > > CONFIG_KEYBOARD_SUN4I_LRADC=y > > # CONFIG_INPUT_MOUSE is not set > > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/25142918.GuFC1uy7vR%40jernej-laptop.
arch/sh/mm/cache-sh7705.c:116:32: sparse: sparse: incorrect type in argument 1 (different base types)
Hi Luc,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5c8fe583cce542aa0b84adc939ce85293de36e5e
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 4 months ago
config: sh-randconfig-s031-20201228 (attached as .config)
compiler: sh4-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-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# 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=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> arch/sh/mm/cache-sh7705.c:116:32: sparse: sparse: incorrect type in argument
>> 1 (different base types) @@ expected void const volatile [noderef]
>> __iomem *ptr @@ got unsigned long [assigned] addr @@
arch/sh/mm/cache-sh7705.c:116:32: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh7705.c:116:32: sparse: got unsigned long [assigned]
addr
arch/sh/mm/cache-sh7705.c:119:33: sparse: sparse: incorrect type in argument
1 (different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long [assigned] addr @@
arch/sh/mm/cache-sh7705.c:119:33: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh7705.c:119:33: sparse: got unsigned long [assigned]
addr
arch/sh/mm/cache-sh7705.c:49:32: sparse: sparse: incorrect type in argument
1 (different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long [assigned] addr @@
arch/sh/mm/cache-sh7705.c:49:32: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh7705.c:49:32: sparse: got unsigned long [assigned]
addr
arch/sh/mm/cache-sh7705.c:52:33: sparse: sparse: incorrect type in argument
1 (different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long [assigned] addr @@
arch/sh/mm/cache-sh7705.c:52:33: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh7705.c:52:33: sparse: got unsigned long [assigned]
addr
--
drivers/input/joydev.c:528:24: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected signed int const *__gu_addr @@
got signed int [noderef] [usertype] __user * @@
drivers/input/joydev.c:528:24: sparse: expected signed int const
*__gu_addr
drivers/input/joydev.c:528:24: sparse: got signed int [noderef]
[usertype] __user *
drivers/input/joydev.c:528:24: sparse: sparse: incorrect type in argument 1
(different address spaces) @@ expected void const volatile [noderef] __user
*ptr @@ got signed int const *__gu_addr @@
drivers/input/joydev.c:528:24: sparse: expected void const volatile
[noderef] __user *ptr
drivers/input/joydev.c:528:24: sparse: got signed int const *__gu_addr
drivers/input/joydev.c:680:26: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected long const *__gu_addr @@ got
long [noderef] __user * @@
drivers/input/joydev.c:680:26: sparse: expected long const *__gu_addr
drivers/input/joydev.c:680:26: sparse: got long [noderef] __user *
>> drivers/input/joydev.c:680:26: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __user *ptr @@ got long const *__gu_addr @@
drivers/input/joydev.c:680:26: sparse: expected void const volatile
[noderef] __user *ptr
drivers/input/joydev.c:680:26: sparse: got long const *__gu_addr
--
>> drivers/spi/spi-lp8841-rtc.c:112:17: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got void *iomem @@
drivers/spi/spi-lp8841-rtc.c:112:17: sparse: expected void const
volatile [noderef] __iomem *ptr
drivers/spi/spi-lp8841-rtc.c:112:17: sparse: got void *iomem
drivers/spi/spi-lp8841-rtc.c:121:17: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] __iomem *ptr @@ got void *iomem @@
drivers/spi/spi-lp8841-rtc.c:121:17: sparse:
RE: regmap: debugfs: fix a memory leak when calling regmap_attach_dev
> Do you mean so?
>
> commit:
> 9b947a13e7f6 ("regmap: use debugfs even when no device")
> Please take another look at known information sources.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n89
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n121
> Which one do you mean by "another null point"?
How do you think about to check if calls of the function “kasprintf” succeeded
here?
https://elixir.bootlin.com/linux/v5.10.3/source/lib/kasprintf.c#L53
Will any more exception handling become relevant also for the implementation of
the function “regmap_debugfs_init”?
-Original Message-
From: Markus Elfring
Sent: Sunday, December 27, 2020 9:40 PM
To: Wang, Xiaolei ; kernel-janit...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; Greg Kroah-Hartman
; Mark Brown ; Rafael J.
Wysocki
Subject: Re: regmap: debugfs: fix a memory leak when calling regmap_attach_dev
> Do you mean so?
>
> commit:
> 9b947a13e7f6 ("regmap: use debugfs even when no device")
> Please take another look at known information sources.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n89
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n121
> Which one do you mean by "another null point"?
> How do you think about to check if calls of the function “kasprintf”
> succeeded here?
> https://elixir.bootlin.com/linux/v5.10.3/source/lib/kasprintf.c#L53
> Will any more exception handling become relevant also for the implementation
> of the function “regmap_debugfs_init”?
Thanks for your suggestion, I will modify the commit log and add another null
point check together with corresponding exception handling
Regards,
Xiaolei
Re: [PATCH 4/5] irqtime: Move irqtime entry accounting after irq offset incrementation
Hi Frederic
On 12/02/20 12:57, Frederic Weisbecker wrote:
> #endif /* _LINUX_KERNEL_VTIME_H */
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 02163d4260d7..5f611658eeab 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -44,12 +44,13 @@ static void irqtime_account_delta(struct irqtime
> *irqtime, u64 delta,
> }
>
> /*
> - * Called before incrementing preempt_count on {soft,}irq_enter
> + * Called after incrementing preempt_count on {soft,}irq_enter
> * and before decrementing preempt_count on {soft,}irq_exit.
> */
> -void irqtime_account_irq(struct task_struct *curr)
> +void irqtime_account_irq(struct task_struct *curr, unsigned int offset)
> {
> struct irqtime *irqtime = this_cpu_ptr(_irqtime);
> + unsigned int pc;
> s64 delta;
> int cpu;
>
> @@ -59,6 +60,7 @@ void irqtime_account_irq(struct task_struct *curr)
> cpu = smp_processor_id();
> delta = sched_clock_cpu(cpu) - irqtime->irq_start_time;
> irqtime->irq_start_time += delta;
> + pc = preempt_count() - offset;
>
> /*
>* We do not account for softirq time from ksoftirqd here.
> @@ -66,9 +68,9 @@ void irqtime_account_irq(struct task_struct *curr)
>* in that case, so as not to confuse scheduler with a special task
>* that do not consume any time, but still wants to run.
>*/
> - if (hardirq_count())
> + if (pc & HARDIRQ_MASK)
> irqtime_account_delta(irqtime, delta, CPUTIME_IRQ);
> - else if (in_serving_softirq() && curr != this_cpu_ksoftirqd())
> + else if ((pc & SOFTIRQ_OFFSET) && curr != this_cpu_ksoftirqd())
Noob question. Why for SOFTIRQs we do sofirq_count() & *SOFTIRQ_OFFSET*? It
seems we're in-softirq only if the count is odd numbered.
/me tries to dig more
Hmm could it be because the softirq count is actually 1 bit and the rest is
for SOFTIRQ_DISABLE_OFFSET (BH disabled)?
IOW, 1 bit is for we're in softirq context, and the remaining 7 bits are to
count BH disable nesting, right?
I guess this would make sense; we don't nest softirqs processing AFAIK. But
I could be misreading the code too :-)
> irqtime_account_delta(irqtime, delta, CPUTIME_SOFTIRQ);
> }
>
> @@ -417,11 +419,13 @@ void vtime_task_switch(struct task_struct *prev)
> }
> # endif
>
> -void vtime_account_irq(struct task_struct *tsk)
> +void vtime_account_irq(struct task_struct *tsk, unsigned int offset)
> {
> - if (hardirq_count()) {
> + unsigned int pc = preempt_count() - offset;
> +
> + if (pc & HARDIRQ_OFFSET) {
Shouldn't this be HARDIRQ_MASK like above?
> vtime_account_hardirq(tsk);
> - } else if (in_serving_softirq()) {
> + } else if (pc & SOFTIRQ_OFFSET) {
> vtime_account_softirq(tsk);
> } else if (!IS_ENABLED(CONFIG_HAVE_VIRT_CPU_ACCOUNTING_IDLE) &&
> is_idle_task(tsk)) {
Thanks
--
Qais Yousef
Re: [PATCH -next] regulator: qcom-rpmh: fix build after QCOM_COMMAND_DB is tristate
On Fri, Dec 25 2020 at 11:50 -0700, Randy Dunlap wrote:
Restrict REGULATOR_QCOM_RPMH to QCOM_COMMAND_DB it the latter is enabled.
Fixes this build error:
microblaze-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function
`rpmh_regulator_probe':
(.text+0x354): undefined reference to `cmd_db_read_addr'
Fixes: 778279f4f5e4 ("soc: qcom: cmd-db: allow loading as a module")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Cc: Lina Iyer
Cc: Liam Girdwood
Cc: Mark Brown
Reviewed-by: Lina Iyer
---
drivers/regulator/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next-20201223.orig/drivers/regulator/Kconfig
+++ linux-next-20201223/drivers/regulator/Kconfig
@@ -881,6 +881,7 @@ config REGULATOR_QCOM_RPM
config REGULATOR_QCOM_RPMH
tristate "Qualcomm Technologies, Inc. RPMh regulator driver"
depends on QCOM_RPMH || (QCOM_RPMH=n && COMPILE_TEST)
+ depends on QCOM_COMMAND_DB || !QCOM_COMMAND_DB
help
This driver supports control of PMIC regulators via the RPMh hardware
block found on Qualcomm Technologies Inc. SoCs. RPMh regulator
[PATCH] Revert "mfd: syscon: Don't free allocated name for regmap_config"
From: Limeng
This reverts commit 529a1101212a785c5df92c314b0e718287150c3b.
The reverted patch moves the memory free to error path, but introduce
a memory leak. There is another commit 94cc89eb8fa5("regmap: debugfs:
Fix handling of name string for debugfs init delays") fixing this
debugfs init issue from root cause. With this fixing, the name field
in struct regmap_debugfs_node is removed. When initialize debugfs
for syscon driver, the name field of struct regmap_config is not
used anymore. So, revert this patch directly to avoid memory leak.
Fixes: 529a1101212a("mfd: syscon: Don't free allocated name for regmap_config")
Cc: sta...@vger.kernel.org
Signed-off-by: Meng Li
---
drivers/mfd/syscon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca465794ea9c..df5cebb372a5 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -108,6 +108,7 @@ static struct syscon *of_syscon_register(struct device_node
*np, bool check_clk)
syscon_config.max_register = resource_size() - reg_io_width;
regmap = regmap_init_mmio(NULL, base, _config);
+ kfree(syscon_config.name);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
ret = PTR_ERR(regmap);
@@ -144,7 +145,6 @@ static struct syscon *of_syscon_register(struct device_node
*np, bool check_clk)
regmap_exit(regmap);
err_regmap:
iounmap(base);
- kfree(syscon_config.name);
err_map:
kfree(syscon);
return ERR_PTR(ret);
--
2.17.1
[PATCH] ARM64: RAS: Update code to trace out more data for ARM processor
The original arm_event trace code only traces out ARM processor
error information data. According to UEFI_2_8_A_Feb14 specification
chapter N2.4.4, the ARM processor error section includes several
ARM processor error information, several ARM processor
context information and several vendor specific error
information structures.
Add code to trace out all ARM processor context information and
vendor specific error information with raw hex format.
Signed-off-by: Jason Tian
---
drivers/ras/ras.c | 22 +-
include/ras/ras_event.h | 41 +++--
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index 3f3890732..a0a6b2f87 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -23,7 +23,27 @@ void log_non_standard_event(const uuid_le *sec_type, const
uuid_le *fru_id,
void log_arm_hw_error(struct cper_sec_proc_arm *err)
{
- trace_arm_event(err);
+ u32 pei_len;
+ u32 ctx_len;
+ u32 vsei_len;
+ u8 *pei_err;
+ u8 *ctx_err;
+ u8 *ven_err_data;
+
+ pei_len = sizeof(struct cper_arm_err_info) * err->err_info_num;
+ pei_err = (u8 *) err + sizeof(struct cper_sec_proc_arm);
+
+ ctx_len = sizeof(struct cper_arm_ctx_info) * err->context_info_num;
+ ctx_err = pei_err + sizeof(struct cper_arm_err_info) *
+ err->err_info_num;
+
+ vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) +
+ pei_len + ctx_len);
+ ven_err_data = ctx_err + sizeof(struct cper_arm_ctx_info) *
+ err->context_info_num;
+
+ trace_arm_event(err, pei_err, pei_len, ctx_err, ctx_len,
+ ven_err_data, vsei_len);
}
static int __init ras_init(void)
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index a0794632f..7b1082774 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -168,11 +168,22 @@ TRACE_EVENT(mc_event,
* This event is generated when hardware detects an ARM processor error
* has occurred. UEFI 2.6 spec section N.2.4.4.
*/
+ #define APEIL "ARM Processor Err Info data len"
+ #define APEID "ARM Processor Err Info raw data"
+ #define APECIL "ARM Processor Err Context Info data len"
+ #define APECID "ARM Processor Err Context Info raw data"
+ #define VSEIL "Vendor Specific Err Info data len"
+ #define VSEID "Vendor Specific Err Info raw data"
TRACE_EVENT(arm_event,
- TP_PROTO(const struct cper_sec_proc_arm *proc),
+ TP_PROTO(const struct cper_sec_proc_arm *proc, const u8 *pei_err,
+ const u32 pei_len,
+ const u8 *ctx_err,
+ const u32 ctx_len,
+ const u8 *oem,
+ const u32 oem_len),
- TP_ARGS(proc),
+ TP_ARGS(proc, pei_err, pei_len, ctx_err, ctx_len, oem, oem_len),
TP_STRUCT__entry(
__field(u64, mpidr)
@@ -180,6 +191,12 @@ TRACE_EVENT(arm_event,
__field(u32, running_state)
__field(u32, psci_state)
__field(u8, affinity)
+ __field(u32, pei_len)
+ __dynamic_array(u8, buf, pei_len)
+ __field(u32, ctx_len)
+ __dynamic_array(u8, buf1, ctx_len)
+ __field(u32, oem_len)
+ __dynamic_array(u8, buf2, oem_len)
),
TP_fast_assign(
@@ -199,12 +216,24 @@ TRACE_EVENT(arm_event,
__entry->running_state = ~0;
__entry->psci_state = ~0;
}
+ __entry->pei_len = pei_len;
+ memcpy(__get_dynamic_array(buf), pei_err, pei_len);
+ __entry->ctx_len = ctx_len;
+ memcpy(__get_dynamic_array(buf1), ctx_err, ctx_len);
+ __entry->oem_len = oem_len;
+ memcpy(__get_dynamic_array(buf2), oem, oem_len);
),
- TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
- "running state: %d; PSCI state: %d",
- __entry->affinity, __entry->mpidr, __entry->midr,
- __entry->running_state, __entry->psci_state)
+ TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; running
state: %d; "
+ "PSCI state: %d; %s: %d; %s: %s; %s: %d; %s: %s; %s: %d; %s:
%s",
+ __entry->affinity, __entry->mpidr, __entry->midr,
+ __entry->running_state, __entry->psci_state,
+ APEIL, __entry->pei_len, APEID,
+ __print_hex(__get_dynamic_array(buf), __entry->pei_len),
+ APECIL, __entry->ctx_len, APECID,
+ __print_hex(__get_dynamic_array(buf1), __entry->ctx_len),
+ VSEIL, __entry->oem_len, VSEID,
+ __print_hex(__get_dynamic_array(buf2), __entry->oem_len))
);
/*
--
2.25.1
Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
Hi Asutosh, On Sun, 2020-12-27 at 17:32 -0800, Asutosh Das (asd) wrote: > On 12/24/2020 5:47 AM, Stanley Chu wrote: > > Hi Avri, Bean, > > > > On Thu, 2020-12-24 at 13:01 +0100, Bean Huo wrote: > >> On Thu, 2020-12-24 at 11:03 +, Avri Altman wrote: > > Do you see any substantial benefit of having > > fWriteBoosterBufferFlushEn > > disabled? > > 1. The definition of fWriteBoosterBufferFlushEn is that host allows > device to do flush in anytime after fWriteBoosterBufferFlushEn is > set as > on. This is not what we want. > > Just Like BKOP, We do not want flush happening beyond host's > expected > timing that device performance may be "randomly" dropped. > >>> > >>> Explicit flush takes place only when the device is idle: > >>> if fWriteBoosterBufferFlushEn is set, the device is idle, and before > >>> h8 received. > >>> If a request arrives, the flush operation should be halted. > >>> So no performance degradation is expected. > >> > >> Hi Stanley > >> > >> Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will > >> flush only when it is in idle, once there is new incoming request, the > >> flush will be suspended. You should be very careful when you want to > >> skip this stetting of this flag. > > > > Very appreciate your the clarification. > > > > However similar to "Background Operations Termination Latency", while > > the next request comes, device may need some time to suspend on-going > > flush operations. This delay may "randomly" degrade the performance > > right? > > > > Have you actually seen this happening? I've not come across any random > performance degradation concerns, hence asking. > > From what I've observed is the handling of WB buffer flush depends on > how flash vendors implement it. Some vendors that I've seen just create > a separate WB buffer in an instant. I don't know the intricacies of > their implementation, but I guess the new WB buffer handles the requests > while the previous one is being flushed. > Anyway, for Qualcomm platforms we plan to have > fWriteBoosterBufferFlushEn=1 by default. Thanks for above information and discussion : ) Actually we've not come across any random performance degradation due to fWriteBoosterBufferFlushEn=1 as well. Since the implementation of fWriteBoosterBufferFlushEn may differ by different vendors, we would like to keep current configuration used in our mass-produced products first. But this is an interesting topic for possible termination latency of WriteBooster flush. Maybe we could discuss with vendors to explicitly define the required latency in UFS specification, just like "Background Operations Termination Latency"? Then host can choose the best configuration according to the definition provided by the device. Thanks. Stanley Chu > > > Since the configuration, i.e., enable > > fWriteBoosterBufferFlushDuringHibernate only with > > fWriteBoosterBufferFlushEn disabled, has been applied in many of our > > mass-produced products these yeas, we would like to keep it unless the > > new setting has obvious benefits. > > > > Thanks, > > Stanley Chu > > > >> > >> Bean > >> > > > >
Re: [PATCH 1/3] blk-mq: allow hardware queue to get more tag while sharing a tag set
Hi, On 2020/12/27 19:58, Ming Lei wrote: Hi Yu Kuai, On Sat, Dec 26, 2020 at 06:28:06PM +0800, Yu Kuai wrote: When sharing a tag set, if most disks are issuing small amount of IO, and only a few is issuing a large amount of IO. Current approach is to limit the max amount of tags a disk can get equally to the average of total tags. Thus the few heavy load disk can't get enough tags while many tags are still free in the tag set. Yeah, current approach just allocates same share for each active queue which is evaluated in each timeout period. That said you are trying to improve the following case: - heavy IO on one or several disks, and the average share for these disks become bottleneck of IO performance - small amount IO on other disks attached to the same host, and all IOs are submitted to disk in <30 second period. Just wondering if you may share the workload you are trying to optimize, or it is just one improvement in theory? And what is the disk(hdd, ssd or nvme) and host? And how many disks in your setting? And how deep the tagset depth is? The details of the environment that we found the problem are as follows: total driver tags: 128 number of disks: 13 (network drive, and they form a dm-multipath) default queue_depth: 32 disk performance: when test with 4k randread and single thread, iops is 300. And can up to 4000 with 32 thread. test cmd: fio -ioengine=psync -numjobs=32 ... We found that mpath will issue sg_io periodically(about 15s)，which lead to active_queues setting to 13 for about 5s in every 15s. By the way, I'm not sure this is a common scenario, however, sq don't have such problem, Thanks Yu Kuai
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, Dec 27, 2020 at 3:48 PM Kirill A. Shutemov wrote: > > I did what Hugh proposed and it got clear to my eyes. It gets somewhat > large, but take a look. Ok, it's not that much bigger, and the end result is certainly much clearer wrt locking. So that last version of yours with the fix for the uninitialized 'ret' variable looks good to me. Of course, I've said that before, and have been wrong. So ... Linus
Re: [PATCH v2 2/3] scsi: ufs: Add handling of the return value of pm_runtime_get_sync()
On 2020-12-25 01:20, Bean Huo wrote:
From: Bean Huo
The race issue may exist between UFS access in UFS sysfs context and
UFS
shutdown, thus will cause pm_runtime_get_sync() resume failure.
Are you trying to fix the race condition by adding these checks or just
adding these checks in case pm_runtime_get_sync() fails?
Can Guo.
Add handling of the return value of pm_runtime_get_sync(). Let it
return
in case pm_runtime_get_sync() resume failed.
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufs-sysfs.c | 38 ++--
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c
b/drivers/scsi/ufs/ufs-sysfs.c
index 0e1438485133..8e5e36e01bee 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -154,12 +154,17 @@ static ssize_t auto_hibern8_show(struct device
*dev,
struct device_attribute *attr, char *buf)
{
u32 ahit;
+ int ret;
struct ufs_hba *hba = dev_get_drvdata(dev);
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
- pm_runtime_get_sync(hba->dev);
+ ret = pm_runtime_get_sync(hba->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(hba->dev);
+ return ret;
+ }
ufshcd_hold(hba, false);
ahit = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
ufshcd_release(hba);
@@ -225,7 +230,12 @@ static ssize_t ufs_sysfs_read_desc_param(struct
ufs_hba *hba,
if (param_size > 8)
return -EINVAL;
- pm_runtime_get_sync(hba->dev);
+ ret = pm_runtime_get_sync(hba->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(hba->dev);
+ return ret;
+ }
+
ret = ufshcd_read_desc_param(hba, desc_id, desc_index,
param_offset, desc_buf, param_size);
pm_runtime_put_sync(hba->dev);
@@ -594,7 +604,11 @@ static ssize_t _name##_show(struct device
*dev,\
desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_ATOMIC);\
if (!desc_buf) \
return -ENOMEM; \
- pm_runtime_get_sync(hba->dev); \
+ ret = pm_runtime_get_sync(hba->dev); \
+ if (ret < 0) { \
+ pm_runtime_put_noidle(hba->dev); \
+ return ret; \
+ } \
ret = ufshcd_query_descriptor_retry(hba,\
UPIU_QUERY_OPCODE_READ_DESC, QUERY_DESC_IDN_DEVICE, \
0, 0, desc_buf, _len); \
@@ -653,7 +667,11 @@ static ssize_t _name##_show(struct device
*dev,\
struct ufs_hba *hba = dev_get_drvdata(dev); \
if (ufshcd_is_wb_flags(QUERY_FLAG_IDN##_uname)) \
index = ufshcd_wb_get_query_index(hba); \
- pm_runtime_get_sync(hba->dev); \
+ ret = pm_runtime_get_sync(hba->dev); \
+ if (ret < 0) { \
+ pm_runtime_put_noidle(hba->dev); \
+ return ret; \
+ } \
ret = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_READ_FLAG, \
QUERY_FLAG_IDN##_uname, index, ); \
pm_runtime_put_sync(hba->dev); \
@@ -711,7 +729,11 @@ static ssize_t _name##_show(struct device
*dev,\
u8 index = 0; \
if (ufshcd_is_wb_attrs(QUERY_ATTR_IDN##_uname)) \
index = ufshcd_wb_get_query_index(hba); \
- pm_runtime_get_sync(hba->dev); \
+ ret = pm_runtime_get_sync(hba->dev); \
+ if (ret < 0) { \
+ pm_runtime_put_noidle(hba->dev); \
+ return ret; \
+ } \
ret = ufshcd_query_attr(hba, UPIU_QUERY_OPCODE_READ_ATTR, \
QUERY_ATTR_IDN##_uname, index, 0, ); \
pm_runtime_put_sync(hba->dev); \
@@ -850,7 +872,11 @@ static ssize_t
dyn_cap_needed_attribute_show(struct device *dev,
u8 lun = ufshcd_scsi_to_upiu_lun(sdev->lun);
Re: [PATCH v1 02/19] x86/insn: Add @buf_len param to insn_init() kernel-doc comment
On Wed, 23 Dec 2020 18:42:16 +0100 Borislav Petkov wrote: > From: Borislav Petkov > > It wasn't documented so add it. No functional changes. > Thank you for fixing! Acked-by: Masami Hiramatsu > Signed-off-by: Borislav Petkov > --- > arch/x86/lib/insn.c | 1 + > tools/arch/x86/lib/insn.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c > index 404279563891..1ba994862b56 100644 > --- a/arch/x86/lib/insn.c > +++ b/arch/x86/lib/insn.c > @@ -37,6 +37,7 @@ > * insn_init() - initialize struct insn > * @insn: insn to be initialized > * @kaddr: address (in kernel memory) of instruction (or copy thereof) > + * @buf_len: length of the insn buffer at @kaddr > * @x86_64: !0 for 64-bit kernel or 64-bit app > */ > void insn_init(struct insn *insn, const void *kaddr, int buf_len, int x86_64) > diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c > index 0151dfc6da61..f3277d6e4ef2 100644 > --- a/tools/arch/x86/lib/insn.c > +++ b/tools/arch/x86/lib/insn.c > @@ -37,6 +37,7 @@ > * insn_init() - initialize struct insn > * @insn: insn to be initialized > * @kaddr: address (in kernel memory) of instruction (or copy thereof) > + * @buf_len: length of the insn buffer at @kaddr > * @x86_64: !0 for 64-bit kernel or 64-bit app > */ > void insn_init(struct insn *insn, const void *kaddr, int buf_len, int x86_64) > -- > 2.29.2 > -- Masami Hiramatsu
[PATCH net-next] net: nfc: nci: Change the NCI close sequence
From: Bongsu Jeon Change the NCI close sequence because the NCI Command timer should be deleted after flushing the NCI command work queue. Signed-off-by: Bongsu Jeon --- net/nfc/nci/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c index e64727e1a72f..79bebf4b0796 100644 --- a/net/nfc/nci/core.c +++ b/net/nfc/nci/core.c @@ -579,11 +579,11 @@ static int nci_close_device(struct nci_dev *ndev) clear_bit(NCI_INIT, >flags); - del_timer_sync(>cmd_timer); - /* Flush cmd wq */ flush_workqueue(ndev->cmd_wq); + del_timer_sync(>cmd_timer); + /* Clear flags */ ndev->flags = 0; -- 2.17.1
Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
On 12/24/2020 5:47 AM, Stanley Chu wrote: Hi Avri, Bean, On Thu, 2020-12-24 at 13:01 +0100, Bean Huo wrote: On Thu, 2020-12-24 at 11:03 +, Avri Altman wrote: Do you see any substantial benefit of having fWriteBoosterBufferFlushEn disabled? 1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as on. This is not what we want. Just Like BKOP, We do not want flush happening beyond host's expected timing that device performance may be "randomly" dropped. Explicit flush takes place only when the device is idle: if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received. If a request arrives, the flush operation should be halted. So no performance degradation is expected. Hi Stanley Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag. Very appreciate your the clarification. However similar to "Background Operations Termination Latency", while the next request comes, device may need some time to suspend on-going flush operations. This delay may "randomly" degrade the performance right? Have you actually seen this happening? I've not come across any random performance degradation concerns, hence asking. From what I've observed is the handling of WB buffer flush depends on how flash vendors implement it. Some vendors that I've seen just create a separate WB buffer in an instant. I don't know the intricacies of their implementation, but I guess the new WB buffer handles the requests while the previous one is being flushed. Anyway, for Qualcomm platforms we plan to have fWriteBoosterBufferFlushEn=1 by default. Since the configuration, i.e., enable fWriteBoosterBufferFlushDuringHibernate only with fWriteBoosterBufferFlushEn disabled, has been applied in many of our mass-produced products these yeas, we would like to keep it unless the new setting has obvious benefits. Thanks, Stanley Chu Bean -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project
Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
On 2020-12-24 21:47, Stanley Chu wrote: Hi Avri, Bean, On Thu, 2020-12-24 at 13:01 +0100, Bean Huo wrote: On Thu, 2020-12-24 at 11:03 +, Avri Altman wrote: > > > Do you see any substantial benefit of having > > > fWriteBoosterBufferFlushEn > > > disabled? > > > > 1. The definition of fWriteBoosterBufferFlushEn is that host allows > > device to do flush in anytime after fWriteBoosterBufferFlushEn is > > set as > > on. This is not what we want. > > > > Just Like BKOP, We do not want flush happening beyond host's > > expected > > timing that device performance may be "randomly" dropped. > > Explicit flush takes place only when the device is idle: > if fWriteBoosterBufferFlushEn is set, the device is idle, and before > h8 received. > If a request arrives, the flush operation should be halted. > So no performance degradation is expected. Hi Stanley Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag. Very appreciate your the clarification. However similar to "Background Operations Termination Latency", while the next request comes, device may need some time to suspend on-going flush operations. This delay may "randomly" degrade the performance right? That can be case by case (or vendor by vendor), but generally I agree with you on this. Since the configuration, i.e., enable fWriteBoosterBufferFlushDuringHibernate only with fWriteBoosterBufferFlushEn disabled, has been applied in many of our mass-produced products these yeas, we would like to keep it unless the new setting has obvious benefits. Thanks for sharing the info. I will leave the decision to Asutosh on this. Thanks, Can Guo. Thanks, Stanley Chu Bean
Re: [PATCH v5 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
Hi, Huacai
On 12/28/2020 08:32 AM, Huacai Chen wrote:
Hi, Qing,
On Sat, Dec 26, 2020 at 5:13 PM Qing Zhang wrote:
The SPI controller has the following characteristics:
- Full-duplex synchronous serial data transmission
- Support up to 4 variable length byte transmission
- Main mode support
- Mode failure generates an error flag and issues an interrupt request
- Double buffer receiver
- Serial clock with programmable polarity and phase
- SPI can be controlled in wait mode
- Support boot from SPI
Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
eg:
[root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
Erased 262144 bytes from address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
Copied 13 bytes from 1.img to address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
Copied 13 bytes from address 0x0002 in flash to 2.img
[root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
Signed-off-by: Qing Zhang
---
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
- Fix unclear indentation
- make conditional statements to improve legibility
- Don't use static inline
- the core handle message queue
- Add a new binding document
- Fix probe part mixed pdev and PCI
v3:
- expose set_cs to the core and let it handle things
- replace transfer_one_message to transfer_one
- replace spi_alloc_master to devm_spi_alloc_master
- split out into prepare/unprepare_message
- releases pci regions before unregister master
v4:
- names used in the manual
- rename ls7a_spi_do_transfer to ls7a_spi_setup_transfer
- change read the spcr and sper outside of this function
- mode configuration moved to prepare instead
- remove redundancy code about unprepare/prepare_message
- used 0x4 instead of 0x1,WFEMPTY instead of RFEMPTY
v5:
- remove unnecessary blank lines
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-ls7a.c | 280 +
3 files changed, 288 insertions(+)
create mode 100644 drivers/spi/spi-ls7a.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aadaea0..af7c0d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -413,6 +413,13 @@ config SPI_LP8841_RTC
Say N here unless you plan to run the kernel on an ICP DAS
LP-8x4x industrial computer.
+config SPI_LS7A
+ tristate "Loongson LS7A SPI Controller Support"
+ depends on CPU_LOONGSON64 || COMPILE_TEST
+ help
+ This drivers supports the Loongson LS7A SPI controller in master
+ SPI mode.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea582..d015cf2 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
+obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
new file mode 100644
index 000..d24b6d91
--- /dev/null
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Loongson LS7A SPI Controller driver
+//
+// Copyright (C) 2020 Loongson Technology Corporation Limited.
+//
+
+#include
+#include
+#include
+
+/* define spi register */
+#defineSPCR0x00
+#defineSPSR0x01
+#defineFIFO0x02
+#defineSPER0x03
+#defineSFC_PARAM 0x04
+#defineSFC_SOFTCS 0x05
+#defineSFC_TIMING 0x06
+
+struct ls7a_spi {
+ struct spi_master *master;
+ void __iomem *base;
+ unsigned int hz;
+ unsigned int mode;
+};
+
+static void ls7a_spi_write_reg(struct ls7a_spi *spi,
+ unsigned char reg,
+ unsigned char data)
+{
+ writeb(data, spi->base + reg);
+}
+
+static char ls7a_spi_read_reg(struct ls7a_spi *spi, unsigned char reg)
+{
+ return readb(spi->base + reg);
+}
+
+static int ls7a_spi_prepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct ls7a_spi *ls7a_spi;
+ struct spi_device *spi = msg->spi;
+ unsigned char val;
+
+ ls7a_spi = spi_master_get_devdata(master);
+
+ if (ls7a_spi->mode != spi->mode) {
+ val = ls7a_spi_read_reg(ls7a_spi, SPCR);
+ val &= ~0xc;
+
Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API
Hi,
On Wed, 23 Dec 2020 18:42:17 +0100
Borislav Petkov wrote:
> From: Borislav Petkov
>
> Users of the instruction decoder should use this to decode instruction
> bytes. For that, have insn*() helpers return an int value to denote
> success/failure. When there's an error fetching the next insn byte and
> the insn falls short, return -ENODATA to denote that.
-ENODATA sounds good to me :)
Acked-by: Masami Hiramatsu
BTW, insn_decode() can return -EINVAL if !insn_complete(), is that OK?
>
> While at it, make insn_get_opcode() more stricter as to whether what has
> seen so far is a valid insn and if not.
>
> Copy linux/kconfig.h for the tools-version of the decoder so that it can
> use IS_ENABLED().
I think tools clone code must not use INSN_MODE_KERN because the tools may
not use kernel Kconfig.
Hmm, this may be better to make a different patch to introduce a NOSYNC tag
for sync checker in the tools. Something like;
> +int insn_decode(struct insn *insn, const void *kaddr, int buf_len, enum
> insn_mode m)
> +{
> + int ret;
> +
> + if (m == INSN_MODE_KERN)
return -EINVAL; /* NOSYNC */
> + else
> + insn_init(insn, kaddr, buf_len, m == INSN_MODE_64);
> +
Then we can simple file list for sync-check.sh.
Thank you,
>
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/include/asm/insn.h | 24 ++-
> arch/x86/lib/insn.c | 239 +++---
> tools/arch/x86/include/asm/insn.h | 24 ++-
> tools/arch/x86/lib/insn.c | 239 +++---
> tools/include/linux/kconfig.h | 73 +
> 5 files changed, 475 insertions(+), 124 deletions(-)
> create mode 100644 tools/include/linux/kconfig.h
>
> diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
> index a8c3d284fa46..088aa90e9158 100644
> --- a/arch/x86/include/asm/insn.h
> +++ b/arch/x86/include/asm/insn.h
> @@ -87,13 +87,23 @@ struct insn {
> #define X86_VEX_M_MAX0x1f/* VEX3.M Maximum value
> */
>
> extern void insn_init(struct insn *insn, const void *kaddr, int buf_len, int
> x86_64);
> -extern void insn_get_prefixes(struct insn *insn);
> -extern void insn_get_opcode(struct insn *insn);
> -extern void insn_get_modrm(struct insn *insn);
> -extern void insn_get_sib(struct insn *insn);
> -extern void insn_get_displacement(struct insn *insn);
> -extern void insn_get_immediate(struct insn *insn);
> -extern void insn_get_length(struct insn *insn);
> +extern int insn_get_prefixes(struct insn *insn);
> +extern int insn_get_opcode(struct insn *insn);
> +extern int insn_get_modrm(struct insn *insn);
> +extern int insn_get_sib(struct insn *insn);
> +extern int insn_get_displacement(struct insn *insn);
> +extern int insn_get_immediate(struct insn *insn);
> +extern int insn_get_length(struct insn *insn);
> +
> +enum insn_mode {
> + INSN_MODE_32,
> + INSN_MODE_64,
> + /* Mode is determined by the current kernel build. */
> + INSN_MODE_KERN,
> + INSN_NUM_MODES,
> +};
> +
> +extern int insn_decode(struct insn *insn, const void *kaddr, int buf_len,
> enum insn_mode m);
>
> /* Attribute will be determined after getting ModRM (for opcode groups) */
> static inline void insn_get_attribute(struct insn *insn)
> diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> index 1ba994862b56..b373aadcdd02 100644
> --- a/arch/x86/lib/insn.c
> +++ b/arch/x86/lib/insn.c
> @@ -13,6 +13,9 @@
> #include
> #include
>
> +#include
> +#include
> +
> #include
>
> /* Verify next sizeof(t) bytes can be on the same instruction */
> @@ -80,12 +83,15 @@ static int __insn_get_emulate_prefix(struct insn *insn,
> return 1;
>
> err_out:
> - return 0;
> + return -ENODATA;
> }
>
> static void insn_get_emulate_prefix(struct insn *insn)
> {
> - if (__insn_get_emulate_prefix(insn, xen_prefix, sizeof(xen_prefix)))
> + int ret;
> +
> + ret = __insn_get_emulate_prefix(insn, xen_prefix, sizeof(xen_prefix));
> + if (ret > 0)
> return;
>
> __insn_get_emulate_prefix(insn, kvm_prefix, sizeof(kvm_prefix));
> @@ -98,8 +104,12 @@ static void insn_get_emulate_prefix(struct insn *insn)
> * Populates the @insn->prefixes bitmap, and updates @insn->next_byte
> * to point to the (first) opcode. No effect if @insn->prefixes.got
> * is already set.
> + *
> + * * Returns:
> + * 0: on success
> + * < 0: on error
> */
> -void insn_get_prefixes(struct insn *insn)
> +int insn_get_prefixes(struct insn *insn)
> {
> struct insn_field *prefixes = >prefixes;
> insn_attr_t attr;
> @@ -107,7 +117,7 @@ void insn_get_prefixes(struct insn *insn)
> int i, nb;
>
> if (prefixes->got)
> - return;
> + return 0;
>
> insn_get_emulate_prefix(insn);
>
> @@ -218,8 +228,10 @@ void insn_get_prefixes(struct insn *insn)
>
> prefixes->got = 1;
>
> + return 0;
> +
> err_out:
> - return;
> + return
Re: [PATCH] mm: add prototype for __add_to_page_cache_locked()
On Wed, Dec 23, 2020 at 7:54 AM Christoph Hellwig wrote: > > On Wed, Dec 23, 2020 at 12:11:36PM +, Matthew Wilcox wrote: > > On Wed, Dec 23, 2020 at 08:31:26AM +, Christoph Hellwig wrote: > > > Can we please make the eBPF code stop referencing this function instead > > > of papering over this crap? It has no business poking into page cache > > > internals. > > > > The reference from the BPF code is simply "you can inject errors here". > > And I think we want to be able to inject errors to test the error paths, > > no? > > Something that expects a symbol to be global is just pretty broken. > I think it need to change so that whatever instrumentation is done can > coexist with a static function. Pls read commit description that made it global. It has nothing to do with bpf.
Re: [PATCH v5 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
Hi, Qing,
On Sat, Dec 26, 2020 at 5:13 PM Qing Zhang wrote:
>
> The SPI controller has the following characteristics:
>
> - Full-duplex synchronous serial data transmission
> - Support up to 4 variable length byte transmission
> - Main mode support
> - Mode failure generates an error flag and issues an interrupt request
> - Double buffer receiver
> - Serial clock with programmable polarity and phase
> - SPI can be controlled in wait mode
> - Support boot from SPI
>
> Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
>
> eg:
>
> [root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
> Erased 262144 bytes from address 0x0002 in flash
> [root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
> Copied 13 bytes from 1.img to address 0x0002 in flash
> [root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
> Copied 13 bytes from address 0x0002 in flash to 2.img
> [root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
>
> Signed-off-by: Qing Zhang
> ---
>
> v2:
> - keep Kconfig and Makefile sorted
> - make the entire comment a C++ one so things look more intentional
> - Fix unclear indentation
> - make conditional statements to improve legibility
> - Don't use static inline
> - the core handle message queue
> - Add a new binding document
> - Fix probe part mixed pdev and PCI
>
> v3:
> - expose set_cs to the core and let it handle things
> - replace transfer_one_message to transfer_one
> - replace spi_alloc_master to devm_spi_alloc_master
> - split out into prepare/unprepare_message
> - releases pci regions before unregister master
>
> v4:
> - names used in the manual
> - rename ls7a_spi_do_transfer to ls7a_spi_setup_transfer
> - change read the spcr and sper outside of this function
> - mode configuration moved to prepare instead
> - remove redundancy code about unprepare/prepare_message
> - used 0x4 instead of 0x1,WFEMPTY instead of RFEMPTY
>
> v5:
> - remove unnecessary blank lines
>
> ---
> drivers/spi/Kconfig| 7 ++
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-ls7a.c | 280
> +
> 3 files changed, 288 insertions(+)
> create mode 100644 drivers/spi/spi-ls7a.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index aadaea0..af7c0d4 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -413,6 +413,13 @@ config SPI_LP8841_RTC
> Say N here unless you plan to run the kernel on an ICP DAS
> LP-8x4x industrial computer.
>
> +config SPI_LS7A
> + tristate "Loongson LS7A SPI Controller Support"
> + depends on CPU_LOONGSON64 || COMPILE_TEST
> + help
> + This drivers supports the Loongson LS7A SPI controller in master
> + SPI mode.
> +
> config SPI_MPC52xx
> tristate "Freescale MPC52xx SPI (non-PSC) controller support"
> depends on PPC_MPC52xx
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 6fea582..d015cf2 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
> obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
> obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
> obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
> +obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
> obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
> obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
> obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
> diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
> new file mode 100644
> index 000..d24b6d91
> --- /dev/null
> +++ b/drivers/spi/spi-ls7a.c
> @@ -0,0 +1,280 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Loongson LS7A SPI Controller driver
> +//
> +// Copyright (C) 2020 Loongson Technology Corporation Limited.
> +//
> +
> +#include
> +#include
> +#include
> +
> +/* define spi register */
> +#defineSPCR0x00
> +#defineSPSR0x01
> +#defineFIFO0x02
> +#defineSPER0x03
> +#defineSFC_PARAM 0x04
> +#defineSFC_SOFTCS 0x05
> +#defineSFC_TIMING 0x06
> +
> +struct ls7a_spi {
> + struct spi_master *master;
> + void __iomem *base;
> + unsigned int hz;
> + unsigned int mode;
> +};
> +
> +static void ls7a_spi_write_reg(struct ls7a_spi *spi,
> + unsigned char reg,
> + unsigned char data)
> +{
> + writeb(data, spi->base + reg);
> +}
> +
> +static char ls7a_spi_read_reg(struct ls7a_spi *spi, unsigned char reg)
> +{
> + return readb(spi->base + reg);
> +}
> +
> +static int ls7a_spi_prepare_message(struct spi_master *master,
> + struct spi_message *msg)
> +{
> + struct ls7a_spi *ls7a_spi;
> + struct spi_device *spi = msg->spi;
> +
Re: [PATCH v5 3/4] MIPS: Loongson64: DTS: Add SPI support to LS7A
Reviewed-by: Huacai Chen
On Sat, Dec 26, 2020 at 5:16 PM Qing Zhang wrote:
>
> Add spi support.
>
> Signed-off-by: Qing Zhang
> ---
>
> v2:
> - Add spi about pci device DT
>
> v3:
> - Remove spiflash node
>
> v4:
> - Remove useless compatible
>
> v5:
> - Remove num-chipselects
>
> ---
> arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
> b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
> index f99a7a1..dba717d 100644
> --- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
> +++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
> @@ -405,6 +405,15 @@
> interrupt-map-mask = <0 0 0 0>;
> interrupt-map = <0 0 0 0 39
> IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> + spi@16,0 {
> + compatible = "pci0014,7a0b.0",
> + "pci0014,7a0b",
> + "pciclass088000",
> + "pciclass0880";
> +
> + reg = <0xb000 0x0 0x0 0x0 0x0>;
> + };
> };
>
> isa {
> --
> 2.1.0
>
Re: [PATCH v5 2/4] spi: ls7a: Add YAML schemas
Reviewed-by: Huacai Chen
On Sat, Dec 26, 2020 at 5:13 PM Qing Zhang wrote:
>
> Switch the DT binding to a YAML schema to enable the DT validation.
>
> Signed-off-by: Qing Zhang
> ---
>
> v4:
> - fix warnings/errors about running 'make dt_binding_check'
>
> v5:
> - remove num-chipelects
>
> ---
> .../devicetree/bindings/spi/loongson,spi-ls7a.yaml | 44
> ++
> 1 file changed, 44 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
> b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
> new file mode 100644
> index 000..b90b28b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/loongson,spi-ls7a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Loongson LS7A PCH SPI Controller
> +
> +maintainers:
> + - Qing Zhang
> +
> +description: |
> + This controller can be found in Loongson-3 systems with LS7A PCH.
> +
> +properties:
> + compatible:
> +const: loongson,ls7a-spi
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +pci {
> +#address-cells = <3>;
> +#size-cells = <2>;
> +
> +spi@16,0 {
> +compatible = "pci0014,7a0b.0",
> + "pci0014,7a0b",
> + "pciclass088000",
> + "pciclass0800";
> +
> +reg = <0xb000 0x0 0x0 0x0 0x0>;
> +};
> +};
> +
> +...
> --
> 2.1.0
>
[PATCH net] net: hdlc_ppp: Fix issues when mod_timer is called while timer is running
ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
held. It may call mod_timer to add a new timer. However, at the same time
ppp_timer may be already running and waiting for "ppp->lock". In this
case, there's no need for ppp_timer to continue running and it can just
exit.
If we let ppp_timer continue running, it may call add_timer. This causes
kernel panic because add_timer can't be called with a timer pending.
This patch fixes this problem.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_ppp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index 64f855651336..261b53fc8e04 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net/wan/hdlc_ppp.c
@@ -569,6 +569,13 @@ static void ppp_timer(struct timer_list *t)
unsigned long flags;
spin_lock_irqsave(>lock, flags);
+ /* mod_timer could be called after we entered this function but
+* before we got the lock.
+*/
+ if (timer_pending(>timer)) {
+ spin_unlock_irqrestore(>lock, flags);
+ return;
+ }
switch (proto->state) {
case STOPPING:
case REQ_SENT:
--
2.27.0
Linux 5.11-rc1
Two weeks have passed, Christmas is over, and so is the merge window. I want to thank all the maintainers who sent in their pull requests early: we all wanted to get things done before the holidays really hit, and mostly it seemed to work quite well. In fact, it was rather nice to handle the big bulk of all the merge window pull requests in the first three or four days of the merge window. I wouldn't want to do it that way every time - it would stress me out - but as an occasional "let's get it over with so that the second week is calm" it really wasn't bad at all. It probably helped that 5.11 isn't going to be an LTS release and isn't as big as 5.10 was, but it's not small either. Solidly average. Well, it's average, unless you look at the actual diffs, and notice another huge dump of AMD GPU descriptor header files, which completely dwarfs all the "real" changes here. The AMD "Van Gogh" include file additions are in fact about two thirds of the whole patch, even if it comes from basically one single commit that just adds the register definitions. We've had it before, I'm sure we'll see it in the future too: header files probably generated from the hardware description for all the possible bit masks etc get very very big. Oh well. If you ignore that area, everything else looks normal. Driver updates dominate, but all the usual other suspects are there: arch updates, filesystems, networking, docs and tooling. And while it doesn't look like a huge release, it's certainly still big enough that what's appended below is just my "merge log". As always, my merge logs credit only the people I pull from, which is a much smaller set than all the people involved in actually writing the patches. As usual we had more than 1500 actual developers, and roughly 12,500 changes merged. That's pretty much our average these days. Please go kick the tires, Linus --- Al Viro (3): epoll updates regset updates misc vfs updates Alex Williamson (1): VFIO updates Alexandre Belloni (1): RTC updates Andreas Gruenbacher (1): gfs2 updates Andrew Morton (5): misc updates more updates yet more updates still more updates KASAN updates Arnaldo Carvalho de Melo (2): perf tools updates more perf tools updates Arnd Bergmann (8): asm-generic cleanups asm-generic mmu-context cleanup asm-generic cross-architecture timer cleanup ARM SoC updates ARM SoC defconfig updates ARM device tree updates ARM SoC driver updates ARM SoC OMAP GenPD updates Benson Leung (1): chrome platform updates Bjorn Andersson (3): remoteproc updates hwspinlock updates rpmsg updates Bjorn Helgaas (2): PCI updates PCI fixes Boris Brezillon (1): i3c updates Borislav Petkov (12): EDAC updates x86 RAS updates x86 microcode loader update x86 SGC support x86 cpuid updates x86 platform updates misc x86 updates x86 mm update x86 cleanups x86 cache resource control updates x86 build updates EFI updates Casey Schaufler (2): smack updates smack fix Catalin Marinas (2): arm64 updates more arm64 updates Christian Brauner (4): time namespace updates misc fixes close_range/openat2 updates close_range fix Christoph Hellwig (2): configfs update dma-mapping updates Chuck Lever (1): nfsd updates Corey Minyard (1): IPMI updates Dan Williams (1): libnvdimm updates Daniel Lezcano (2): thermal updates thermal fixlet Daniel Vetter (1): more drm updates Darrick Wong (1): xfs updates Dave Airlie (2): drm updates drm fixes David Kleikamp (1): jfs updates David Sterba (1): btrfs updates David Teigland (1): dlm updates Dmitry Torokhov (1): input updates Dominik Brodowski (1): pcmcia updates Dominique Martinet (1): 9p update Eric Biederman (3): signal cleanup execve updates exec-update-lock update Eric Biggers (2): fscrypt updates fsverity updates Gao Xiang (1): erofs updates Geert Uytterhoeven (1): m68k updates Greg KH (5): USB / Thunderbolt updates tty / serial updates driver core updates char / misc driver updates staging / IIO driver updates Greg Ungerer (1): m68knommu updates Guenter Roeck (2): hwmon updates another hwmon update Gustavo A (1): fallthrough fixes Hans de Goede (1): x86 platform driver updates Heiko Carstens (2): s390 updates more s390 updates Helge Deller (1): parisc updates Herbert Xu (2): crypto updates crypto fixes Ilya Dryomov (1): ceph updates Ingo Molnar (4): scheduler fix timer fixes locking fixes objtool fix Jaegeuk Kim (1): f2fs updates Jakub Kicinski (2): networking updates networking fixes James Bottomley (1): SCSI updates Jan Kara (2): fsnotify updates ext2, reiserfs, quota and writeback updates Jason Gunthorpe
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, Dec 27, 2020 at 03:40:36PM -0800, Linus Torvalds wrote:
> I think Kirill was intending to move the "if (ret)" up into the path
> that sets it, IOW something like
>
> + if (!(vma->vm_flags & VM_SHARED)) {
> + ret = check_stable_address_space(vma->vm_mm);
> + if (ret)
> + return ret;
> + }
>
> instead. But that patch as-is is broken.
>
> Kirill?
Right. Once again, patch is below.
>From d50eff470de025f602711ef546aa87d0da1727f5 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov"
Date: Sat, 19 Dec 2020 15:19:23 +0300
Subject: [PATCH] mm: Cleanup faultaround and finish_fault() codepaths
alloc_set_pte() has two users with different requirements: in the
faultaround code, it called from an atomic context and PTE page table
has to be preallocated. finish_fault() can sleep and allocate page table
as needed.
PTL locking rules are also strange, hard to follow and overkill for
finish_fault().
Let's untangle the mess. alloc_set_pte() has gone now. All locking is
explicit.
The price is some code duplication to handle huge pages in faultaround
path, but it should be fine, having overall improvement in readability.
Signed-off-by: Kirill A. Shutemov
---
fs/xfs/xfs_file.c | 7 +-
include/linux/mm.h | 12 +--
include/linux/pgtable.h | 11 +++
mm/filemap.c| 172 ++-
mm/memory.c | 192 +++-
5 files changed, 207 insertions(+), 187 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 5b0f93f73837..040fa64291ed 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1319,17 +1319,20 @@ xfs_filemap_pfn_mkwrite(
return __xfs_filemap_fault(vmf, PE_SIZE_PTE, true);
}
-static void
+static vm_fault_t
xfs_filemap_map_pages(
struct vm_fault *vmf,
+ unsigned long address,
pgoff_t start_pgoff,
pgoff_t end_pgoff)
{
struct inode*inode = file_inode(vmf->vma->vm_file);
+ vm_fault_t ret;
xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
- filemap_map_pages(vmf, start_pgoff, end_pgoff);
+ ret = filemap_map_pages(vmf, address, start_pgoff, end_pgoff);
xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
+ return ret;
}
static const struct vm_operations_struct xfs_file_vm_ops = {
diff --git a/include/linux/mm.h b/include/linux/mm.h
index db6ae4d3fb4e..4e1d2945a71a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -534,8 +534,8 @@ struct vm_fault {
* is not NULL, otherwise pmd.
*/
pgtable_t prealloc_pte; /* Pre-allocated pte page table.
-* vm_ops->map_pages() calls
-* alloc_set_pte() from atomic context.
+* vm_ops->map_pages() sets up a page
+* table from from atomic context.
* do_fault_around() pre-allocates
* page table to avoid allocation from
* atomic context.
@@ -562,7 +562,7 @@ struct vm_operations_struct {
vm_fault_t (*fault)(struct vm_fault *vmf);
vm_fault_t (*huge_fault)(struct vm_fault *vmf,
enum page_entry_size pe_size);
- void (*map_pages)(struct vm_fault *vmf,
+ vm_fault_t (*map_pages)(struct vm_fault *vmf, unsigned long address,
pgoff_t start_pgoff, pgoff_t end_pgoff);
unsigned long (*pagesize)(struct vm_area_struct * area);
@@ -972,7 +972,9 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct
vm_area_struct *vma)
return pte;
}
-vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct page *page);
+vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
+void do_set_pte(struct vm_fault *vmf, struct page *page);
+
vm_fault_t finish_fault(struct vm_fault *vmf);
vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
#endif
@@ -2621,7 +2623,7 @@ extern void truncate_inode_pages_final(struct
address_space *);
/* generic vm_area_ops exported for stackable file systems */
extern vm_fault_t filemap_fault(struct vm_fault *vmf);
-extern void filemap_map_pages(struct vm_fault *vmf,
+extern vm_fault_t filemap_map_pages(struct vm_fault *vmf, unsigned long
address,
pgoff_t start_pgoff, pgoff_t end_pgoff);
extern vm_fault_t filemap_page_mkwrite(struct vm_fault *vmf);
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index e237004d498d..869c1921ceda 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1259,6 +1259,17 @@ static inline int pmd_trans_unstable(pmd_t *pmd)
#endif
}
+/*
+ * the ordering of these checks is important for pmds with
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, Dec 27, 2020 at 11:38:22AM -0800, Linus Torvalds wrote:
> On Sat, Dec 26, 2020 at 6:38 PM Hugh Dickins wrote:
> >
> > This patch (like its antecedents) moves the pte_unmap_unlock() from
> > after do_fault_around()'s "check if the page fault is solved" into
> > filemap_map_pages() itself (which apparently does not NULLify vmf->pte
> > after unmapping it, which is poor, but good for revealing this issue).
> > That looks cleaner, but of course there was a very good reason for its
> > original positioning.
>
> Good catch.
>
> > Maybe you want to change the ->map_pages prototype, to pass down the
> > requested address too, so that it can report whether the requested
> > address was resolved or not. Or it could be left to __do_fault(),
> > or even to a repeated fault; but those would be less efficient.
>
> Let's keep the old really odd "let's unlock in the caller" for now,
> and minimize the changes.
I did what Hugh proposed and it got clear to my eyes. It gets somewhat
large, but take a look.
The patch below incorporates all fixups from the thread.
>From 3496fc6bde3f6ed0c98d811dda02465bf86fdb90 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov"
Date: Sat, 19 Dec 2020 15:19:23 +0300
Subject: [PATCH] mm: Cleanup faultaround and finish_fault() codepaths
alloc_set_pte() has two users with different requirements: in the
faultaround code, it called from an atomic context and PTE page table
has to be preallocated. finish_fault() can sleep and allocate page table
as needed.
PTL locking rules are also strange, hard to follow and overkill for
finish_fault().
Let's untangle the mess. alloc_set_pte() has gone now. All locking is
explicit.
The price is some code duplication to handle huge pages in faultaround
path, but it should be fine, having overall improvement in readability.
Signed-off-by: Kirill A. Shutemov
---
fs/xfs/xfs_file.c | 7 +-
include/linux/mm.h | 12 +--
include/linux/pgtable.h | 11 +++
mm/filemap.c| 172 +++-
mm/memory.c | 191 +++-
5 files changed, 206 insertions(+), 187 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 5b0f93f73837..040fa64291ed 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1319,17 +1319,20 @@ xfs_filemap_pfn_mkwrite(
return __xfs_filemap_fault(vmf, PE_SIZE_PTE, true);
}
-static void
+static vm_fault_t
xfs_filemap_map_pages(
struct vm_fault *vmf,
+ unsigned long address,
pgoff_t start_pgoff,
pgoff_t end_pgoff)
{
struct inode*inode = file_inode(vmf->vma->vm_file);
+ vm_fault_t ret;
xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
- filemap_map_pages(vmf, start_pgoff, end_pgoff);
+ ret = filemap_map_pages(vmf, address, start_pgoff, end_pgoff);
xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
+ return ret;
}
static const struct vm_operations_struct xfs_file_vm_ops = {
diff --git a/include/linux/mm.h b/include/linux/mm.h
index db6ae4d3fb4e..4e1d2945a71a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -534,8 +534,8 @@ struct vm_fault {
* is not NULL, otherwise pmd.
*/
pgtable_t prealloc_pte; /* Pre-allocated pte page table.
-* vm_ops->map_pages() calls
-* alloc_set_pte() from atomic context.
+* vm_ops->map_pages() sets up a page
+* table from from atomic context.
* do_fault_around() pre-allocates
* page table to avoid allocation from
* atomic context.
@@ -562,7 +562,7 @@ struct vm_operations_struct {
vm_fault_t (*fault)(struct vm_fault *vmf);
vm_fault_t (*huge_fault)(struct vm_fault *vmf,
enum page_entry_size pe_size);
- void (*map_pages)(struct vm_fault *vmf,
+ vm_fault_t (*map_pages)(struct vm_fault *vmf, unsigned long address,
pgoff_t start_pgoff, pgoff_t end_pgoff);
unsigned long (*pagesize)(struct vm_area_struct * area);
@@ -972,7 +972,9 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct
vm_area_struct *vma)
return pte;
}
-vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct page *page);
+vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
+void do_set_pte(struct vm_fault *vmf, struct page *page);
+
vm_fault_t finish_fault(struct vm_fault *vmf);
vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
#endif
@@ -2621,7 +2623,7 @@ extern void truncate_inode_pages_final(struct
address_space *);
/* generic vm_area_ops exported for stackable file systems */
extern
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, Dec 27, 2020 at 3:12 PM Linus Torvalds
wrote:
>
> Ok, your fix for that folded in, and here's yet another version.
Still not good.
I don't know what happened, but the change of
- vm_fault_t ret = 0;
+ vm_fault_t ret;
is very very wrong. The next user is
+ if (!(vma->vm_flags & VM_SHARED))
+ ret = check_stable_address_space(vma->vm_mm);
+ if (ret)
+ return ret;
so now 'ret' will potentially be used uninitialized (although this is
the kind of thing that a compiler might almost accidentally end up
fixing - with a single dominating assignment, I could imagine the
compiler moving the test to that assignment and thus "fixing" the code
without really even meaning to).
I think Kirill was intending to move the "if (ret)" up into the path
that sets it, IOW something like
+ if (!(vma->vm_flags & VM_SHARED)) {
+ ret = check_stable_address_space(vma->vm_mm);
+ if (ret)
+ return ret;
+ }
instead. But that patch as-is is broken.
Kirill?
Linus
[PATCH 3/3] fs/btrfs: avoid null pointer dereference if reloc control has not been initialized
Similar to commmit<389305b2>, it turns out that fs_info::reloc_ctl can be NULL , so there should be a check for rc to prevent null pointer dereference. Signed-off-by: Defang Bo --- fs/btrfs/relocation.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 3602806..ca03571 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -626,6 +626,9 @@ static int __must_check __add_reloc_root(struct btrfs_root *root) struct mapping_node *node; struct reloc_control *rc = fs_info->reloc_ctl; + if (!rc) + return 0; + node = kmalloc(sizeof(*node), GFP_NOFS); if (!node) return -ENOMEM; @@ -703,6 +706,9 @@ static int __update_reloc_root(struct btrfs_root *root) struct rb_node *rb_node; struct mapping_node *node = NULL; struct reloc_control *rc = fs_info->reloc_ctl; + + if (!rc) + return 0; spin_lock(>reloc_root_tree.lock); rb_node = rb_simple_search(>reloc_root_tree.rb_root, -- 2.7.4
Re: LXC broken with 5.10-stable?, ok with 5.9-stable (Re: Linux 5.10.3)
On Sun, Dec 27, 2020 at 1:25 PM Al Viro wrote: > > > Is there any point in not doing the same (scripted, obviously) for > all instances with .read == seq_read? IIRC, Christoph even posted > something along those lines, but it went nowhere for some reason... I'd rather limit splice (and kernel_read too, for that matter) as much as possible. It was a mistake originally to allow it everywhere, and it's come back to bite us. So I'd rather have people notice these odd corner cases and get them fixed one by one than just say "anything goes". There's hopefully not any actually left anyway... Linus
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, Dec 27, 2020 at 2:35 PM Hugh Dickins wrote:
>
> Yes, this one passes my testing on x86_64 and on i386.
Ok, good.
> But...
>
> ... Damian very helpfully reports that it does not build when
> CONFIG_TRANSPARENT_HUGEPAGE is not set, since the "static " has
> not been removed from the alternative definition of do_set_pmd().
Ok, your fix for that folded in, and here's yet another version.
Damian, hopefully your configuration builds and works too now.
But obviously it's too late for this merge window that I'm just about
to close, so I hope Andrew can pick this up - I hope it's now in good
enough shape to go into -mm and then we can do it next merge window or
something.
Andrew?
Linus
From fa131b02ada30b20194ec5e76c97cbed38465356 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov"
Date: Sat, 19 Dec 2020 15:19:23 +0300
Subject: [PATCH vN+1] mm: Cleanup faultaround and finish_fault() codepaths
alloc_set_pte() has two users with different requirements: in the
faultaround code, it called from an atomic context and PTE page table
has to be preallocated. finish_fault() can sleep and allocate page table
as needed.
PTL locking rules are also strange, hard to follow and overkill for
finish_fault().
Let's untangle the mess. alloc_set_pte() has gone now. All locking is
explicit.
The price is some code duplication to handle huge pages in faultaround
path, but it should be fine, having overall improvement in readability.
Signed-off-by: Kirill A. Shutemov
Tested-by: Hugh Dickins
Cc: Damian Tometzki
Signed-off-by: Linus Torvalds
---
include/linux/mm.h | 8 +-
include/linux/pgtable.h | 11 +++
mm/filemap.c| 168 ++--
mm/memory.c | 166 ---
4 files changed, 194 insertions(+), 159 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5299b90a6c40..c0643a0ad5ff 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -535,8 +535,8 @@ struct vm_fault {
* is not NULL, otherwise pmd.
*/
pgtable_t prealloc_pte; /* Pre-allocated pte page table.
- * vm_ops->map_pages() calls
- * alloc_set_pte() from atomic context.
+ * vm_ops->map_pages() sets up a page
+ * table from from atomic context.
* do_fault_around() pre-allocates
* page table to avoid allocation from
* atomic context.
@@ -981,7 +981,9 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct vm_area_struct *vma)
return pte;
}
-vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct page *page);
+vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
+void do_set_pte(struct vm_fault *vmf, struct page *page);
+
vm_fault_t finish_fault(struct vm_fault *vmf);
vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
#endif
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 8fcdfa52eb4b..36eb748f3c97 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1314,6 +1314,17 @@ static inline int pmd_trans_unstable(pmd_t *pmd)
#endif
}
+/*
+ * the ordering of these checks is important for pmds with _page_devmap set.
+ * if we check pmd_trans_unstable() first we will trip the bad_pmd() check
+ * inside of pmd_none_or_trans_huge_or_clear_bad(). this will end up correctly
+ * returning 1 but not before it spams dmesg with the pmd_clear_bad() output.
+ */
+static inline int pmd_devmap_trans_unstable(pmd_t *pmd)
+{
+ return pmd_devmap(*pmd) || pmd_trans_unstable(pmd);
+}
+
#ifndef CONFIG_NUMA_BALANCING
/*
* Technically a PTE can be PROTNONE even when not doing NUMA balancing but
diff --git a/mm/filemap.c b/mm/filemap.c
index 5c9d564317a5..dbc2eda92a53 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "internal.h"
#define CREATE_TRACE_POINTS
@@ -2911,50 +2912,133 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
}
EXPORT_SYMBOL(filemap_fault);
+static bool filemap_map_pmd(struct vm_fault *vmf, struct page *page)
+{
+ struct mm_struct *mm = vmf->vma->vm_mm;
+
+ /* Huge page is mapped? No need to proceed. */
+ if (pmd_trans_huge(*vmf->pmd)) {
+ unlock_page(page);
+ put_page(page);
+ return true;
+ }
+
+ if (pmd_none(*vmf->pmd) && PageTransHuge(page)) {
+ vm_fault_t ret = do_set_pmd(vmf, page);
+ if (!ret) {
+ /* The page is mapped successfully, reference consumed. */
+ unlock_page(page);
+ return true;
+ }
+ }
+
+ if (pmd_none(*vmf->pmd)) {
+ vmf->ptl = pmd_lock(mm, vmf->pmd);
+ if (likely(pmd_none(*vmf->pmd))) {
+ mm_inc_nr_ptes(mm);
+ pmd_populate(mm, vmf->pmd, vmf->prealloc_pte);
+ vmf->prealloc_pte = NULL;
+ }
+ spin_unlock(vmf->ptl);
+ }
+
+ /* See comment in handle_pte_fault() */
+ if (pmd_devmap_trans_unstable(vmf->pmd)) {
+ unlock_page(page);
+ put_page(page);
+ return true;
+ }
+
+ return false;
+}
+
+static struct page *next_uptodate_page(struct page *page, struct vm_fault *vmf,
+ struct
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, 27 Dec 2020, Damian Tometzki wrote:
> On Sun, 27. Dec 11:38, Linus Torvalds wrote:
> > On Sat, Dec 26, 2020 at 6:38 PM Hugh Dickins wrote:
> > >
> > > This patch (like its antecedents) moves the pte_unmap_unlock() from
> > > after do_fault_around()'s "check if the page fault is solved" into
> > > filemap_map_pages() itself (which apparently does not NULLify vmf->pte
> > > after unmapping it, which is poor, but good for revealing this issue).
> > > That looks cleaner, but of course there was a very good reason for its
> > > original positioning.
> >
> > Good catch.
> >
> > > Maybe you want to change the ->map_pages prototype, to pass down the
> > > requested address too, so that it can report whether the requested
> > > address was resolved or not. Or it could be left to __do_fault(),
> > > or even to a repeated fault; but those would be less efficient.
> >
> > Let's keep the old really odd "let's unlock in the caller" for now,
> > and minimize the changes.
> >
> > Adding a big big comment at the end of filemap_map_pages() to note the
> > odd delayed page table unlocking.
> >
> > Here's an updated patch that combines Kirill's original patch, his
> > additional incremental patch, and the fix for the pte lock oddity into
> > one thing.
> >
> > Does this finally pass your testing?
Yes, this one passes my testing on x86_64 and on i386. But...
> >
> >Linus
> Hello together,
>
> when i try to build this patch, i got the following error:
>
> CC arch/x86/kernel/cpu/mce/threshold.o
> mm/memory.c:3716:19: error: static declaration of ‘do_set_pmd’ follows
> non-static declaration
> static vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
>^~
> In file included from mm/memory.c:43:
> ./include/linux/mm.h:984:12: note: previous declaration of ‘do_set_pmd’ was
> here
> vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
> ^~
> make[3]: *** [scripts/Makefile.build:279: mm/memory.o] Error 1
> make[2]: *** [Makefile:1805: mm] Error 2
> make[2]: *** Waiting for unfinished jobs
> CC arch/x86/kernel/cpu/mce/therm_throt.o
... Damian very helpfully reports that it does not build when
CONFIG_TRANSPARENT_HUGEPAGE is not set, since the "static " has
not been removed from the alternative definition of do_set_pmd().
And its BUILD_BUG() becomes invalid once it's globally available.
You don't like unnecessary BUG()s, and I don't like returning
success there: VM_FAULT_FALLBACK seems best.
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3713,10 +3713,9 @@ out:
return ret;
}
#else
-static vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
+vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
{
- BUILD_BUG();
- return 0;
+ return VM_FAULT_FALLBACK;
}
#endif
(I'm also a wee bit worried by filemap.c's +#include :
that's the kind of thing that might turn out not to work on some arch.)
Hugh
Re: [PATCH 1/5] clump_bits: Introduce the for_each_set_clump macro
On Sat, Dec 26, 2020 at 7:42 AM Syed Nayyar Waris wrote: > > This macro iterates for each group of bits (clump) with set bits, > within a bitmap memory region. For each iteration, "start" is set to > the bit offset of the found clump, while the respective clump value is > stored to the location pointed by "clump". Additionally, the > bitmap_get_value() and bitmap_set_value() functions are introduced to > respectively get and set a value of n-bits in a bitmap memory region. > The n-bits can have any size from 1 to BITS_PER_LONG. size less > than 1 or more than BITS_PER_LONG causes undefined behaviour. > Moreover, during setting value of n-bit in bitmap, if a situation arise > that the width of next n-bit is exceeding the word boundary, then it > will divide itself such that some portion of it is stored in that word, > while the remaining portion is stored in the next higher word. Similar > situation occurs while retrieving the value from bitmap. > > GCC gives warning in bitmap_set_value(): https://godbolt.org/z/rjx34r > Add explicit check to see if the value being written into the bitmap > does not fall outside the bitmap. > The situation that it is falling outside would never be possible in the > code because the boundaries are required to be correct before the > function is called. The responsibility is on the caller for ensuring the > boundaries are correct. > The code change is simply to silence the GCC warning messages > because GCC is not aware that the boundaries have already been checked. > As such, we're better off using __builtin_unreachable() here because we > can avoid the latency of the conditional check entirely. Didn't the __builtin_unreachable() end up leading to an objtool warning about incorrect stack frames for the code path that leads into the undefined behavior? I thought I saw a message from the 0day build bot about that and didn't expect to see it again after that. Can you actually measure any performance difference compared to BUG_ON() that avoids the undefined behavior? Practically all CPUs from the past 20 years have branch predictors that should completely hide measurable overhead from this. Arnd
Re: PROBLEM: Recent raid10 block discard patchset causes filesystem corruption on fstrim
Hi Xiao, On Thu, Dec 24, 2020 at 2:18 AM Xiao Ni wrote: > > > [...] > > [ 789.709501] discard bio start : 70968, size : 191176 > [ 789.709507] first stripe index 69, start disk index 0, start disk > offset 70968 > [ 789.709509] last stripe index 256, end disk index 0, end disk offset > 262144 > [ 789.709511] disk 0, dev start : 70968, dev end : 262144 > [ 789.709515] disk 1, dev start : 70656, dev end : 262144 > > For example, in this test case, it has 2 near copies. The > start_disk_offset for the first disk is 70968. > It should use the same offset address for second disk. But it uses the > start address of this chunk. > It discard more region. The patch in the attachment can fix this > problem. It split the region that > doesn't align with chunk size. > > There is another problem. The stripe size should be calculated > differently for near layout and far layout. > > @Song, do you want me to use a separate patch for this fix, or fix this > in the original patch? Please fold in the changes in the original patches and resend the whole set. Thanks, Song > > Merry Christmas > Xiao >
drivers/platform/x86/amd-pmc.c:88:5: warning: "CONFIG_DEBUG_FS" is not defined, evaluates to 0
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f838f8d2b694cf9d524dc4423e9dd2db13892f3f
commit: 156ec4731cb22b06c08e27debc1ef9f16f4bbb5e platform/x86: amd-pmc: Add AMD
platform support for S2Idle
date: 7 weeks ago
config: i386-randconfig-p002-20201222 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=156ec4731cb22b06c08e27debc1ef9f16f4bbb5e
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 156ec4731cb22b06c08e27debc1ef9f16f4bbb5e
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/platform/x86/amd-pmc.c:88:5: warning: "CONFIG_DEBUG_FS" is not
>> defined, evaluates to 0 [-Wundef]
88 | #if CONFIG_DEBUG_FS
| ^~~
vim +/CONFIG_DEBUG_FS +88 drivers/platform/x86/amd-pmc.c
87
> 88 #if CONFIG_DEBUG_FS
89 static int smu_fw_info_show(struct seq_file *s, void *unused)
90 {
91 struct amd_pmc_dev *dev = s->private;
92 u32 value;
93
94 value = ioread32(dev->smu_base + AMD_SMU_FW_VERSION);
95 seq_printf(s, "SMU FW Info: %x\n", value);
96 return 0;
97 }
98 DEFINE_SHOW_ATTRIBUTE(smu_fw_info);
99
---
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] gpiolib: cdev: fix frame size warning in gpio_ioctl()
On Sun, Dec 27, 2020 at 5:11 PM Kent Gibson wrote:
> The kernel test robot reports the following warning in [1]:
>
> drivers/gpio/gpiolib-cdev.c: In function 'gpio_ioctl':
> >>drivers/gpio/gpiolib-cdev.c:1437:1: warning: the frame size of 1040 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
>
> Refactor gpio_ioctl() to handle each ioctl in its own helper function
> and so reduce the variables stored on the stack to those explicitly
> required to service the ioctl at hand.
>
> The lineinfo_get_v1() helper handles both the GPIO_GET_LINEINFO_IOCTL
> and GPIO_GET_LINEINFO_WATCH_IOCTL, as per the corresponding v2
> implementation - lineinfo_get().
>
> [1] https://lore.kernel.org/lkml/202012270910.vw3qc1er-...@intel.com/
>
> Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and
> GPIO_V2_GET_LINEINFO_WATCH_IOCTL")
> Reported-by: kernel test robot
> Signed-off-by: Kent Gibson
That's an interesting regression.
Anyway the kernel look better after than before the patch, so
Reviewed-by: Linus Walleij
Bartosz will pick patches for Torvalds this kernel cycle.
Yours,
Linus Walleij
Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers
wrote:
>
> - On Dec 27, 2020, at 1:28 PM, Andy Lutomirski l...@kernel.org wrote:
>
> >
> > I admit that I'm rather surprised that the code worked at all on arm64,
> > and I'm suspicious that it has never been very well tested. My apologies
> > for not reviewing this more carefully in the first place.
>
> Please refer to
> Documentation/features/sched/membarrier-sync-core/arch-support.txt
>
> It clearly states that only arm, arm64, powerpc and x86 support the membarrier
> sync core feature as of now:
Sigh, I missed arm (32). Russell or ARM folks, what's the right
incantation to make the CPU notice instruction changes initiated by
other cores on 32-bit ARM?
>
>
> # Architecture requirements
> #
> # * arm/arm64/powerpc
> #
> # Rely on implicit context synchronization as a result of exception return
> # when returning from IPI handler, and when returning to user-space.
> #
> # * x86
> #
> # x86-32 uses IRET as return from interrupt, which takes care of the IPI.
> # However, it uses both IRET and SYSEXIT to go back to user-space. The IRET
> # instruction is core serializing, but not SYSEXIT.
> #
> # x86-64 uses IRET as return from interrupt, which takes care of the IPI.
> # However, it can return to user-space through either SYSRETL (compat code),
> # SYSRETQ, or IRET.
> #
> # Given that neither SYSRET{L,Q}, nor SYSEXIT, are core serializing, we rely
> # instead on write_cr3() performed by switch_mm() to provide core
> serialization
> # after changing the current mm, and deal with the special case of kthread ->
> # uthread (temporarily keeping current mm into active_mm) by issuing a
> # sync_core_before_usermode() in that specific case.
>
I need to update that document as part of my series.
> This is based on direct feedback from the architecture maintainers.
>
> You seem to have noticed odd cases on arm64 where this guarantee does not
> match reality. Where exactly can we find this in the code, and which part
> of the architecture manual can you point us to which supports your concern ?
>
> Based on the notes I have, use of `eret` on aarch64 guarantees a context
> synchronizing
> instruction when returning to user-space.
Based on my reading of the manual, ERET on ARM doesn't synchronize
anything at all. I can't find any evidence that it synchronizes data
or instructions, and I've seen reports that the CPU will happily
speculate right past it.
--Andy
Re: [PATCH 5.10 00/40] 5.10.3-rc1 review
On Sun, 2020-12-27 at 17:05 +0100, Greg Kroah-Hartman wrote: > On Sun, Dec 27, 2020 at 09:20:07PM +0530, Jeffrin Jose T wrote: > > On Sat, 2020-12-26 at 16:06 +0100, Greg Kroah-Hartman wrote: > > > On Thu, Dec 24, 2020 at 03:13:38PM +0530, Jeffrin Jose T wrote: > > > > On Wed, 2020-12-23 at 16:33 +0100, Greg Kroah-Hartman wrote: > > > > > This is the start of the stable review cycle for the 5.10.3 > > > > > release. > > > > > There are 40 patches in this series, all will be posted as a > > > > > response > > > > > to this one. If anyone has any issues with these being > > > > > applied, > > > > > please > > > > > let me know. > > > > > > > > > > Responses should be made by Fri, 25 Dec 2020 15:05:02 +. > > > > > Anything received after that time might be too late. > > > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.3-rc1.gz > > > > > or in the git tree and branch at: > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/ > > > > > linu > > > > > x- > > > > > stable-rc.git linux-5.10.y > > > > > and the diffstat can be found below. > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > > > > > hello , > > > > Compiled and booted 5.10.3-rc1+. > > > > > > > > dmesg -l err gives... > > > > --x-x---> > > > > 43.190922] Bluetooth: hci0: don't support firmware rome > > > > 0x31010100 > > > > --x---x-> > > > > > > > > My Bluetooth is Off. > > > > > > Is this a new warning? Does it show up on 5.10.2? > > > > > > > Tested-by: Jeffrin Jose T > > > > > > thanks for testing? > > > > > > greg k-h > > > > this does not show up in 5.10.2-rc1+ > > Odd. Can you run 'git bisect' to find the offending commit? > > Does this same error message show up in Linus's git tree? > > thanks, > > greg k-h i will try to do "git bisect" . i saw this error in linus's tree. -- software engineer rajagiri school of engineering and technology - autonomous
Re: [PATCH 4/5] gpio: xilinx: Utilize generic bitmap_get_value and _set_value
On Sat, Dec 26, 2020 at 7:44 AM Syed Nayyar Waris wrote: > This patch reimplements the xgpio_set_multiple() function in > drivers/gpio/gpio-xilinx.c to use the new generic functions: > bitmap_get_value() and bitmap_set_value(). The code is now simpler > to read and understand. Moreover, instead of looping for each bit > in xgpio_set_multiple() function, now we can check each channel at > a time and save cycles. > > Cc: William Breathitt Gray > Cc: Bartosz Golaszewski > Cc: Michal Simek > Signed-off-by: Syed Nayyar Waris (...) > +#include <../drivers/gpio/clump_bits.h> What is this? Isn't a simple #include "clump_bits.h" enough? We need an ACK from the Xilinx people that they think this actually improves the readability and maintainability of their driver. Yours, Linus Walleij
Re: [PATCH AUTOSEL 5.4 075/130] net/lapb: fix t1 timer handling for LAPB_STATE_0
On Thu, Dec 24, 2020 at 01:49:47AM -0800, Xie He wrote: On Wed, Dec 23, 2020 at 9:01 AM Xie He wrote: I don't think this patch is suitable for stable branches. This patch is part of a patch series that changes the lapb module from "establishing the L2 connection only when needed by L3", to "establishing the L2 connection automatically whenever we are able to". This is a behavioral change. It should be seen as a new feature. It is not a bug fix. Applying this patch without other patches in the same series will also introduce problems, because this patch relies on part of the changes in the subsequent patch in the same series to be correct. I'll drop it, thanks! -- Thanks, Sasha
Re: [PATCH 0/5] Introduce the for_each_set_clump macro
On Sat, Dec 26, 2020 at 7:41 AM Syed Nayyar Waris wrote: > Since this patchset primarily affects GPIO drivers, would you like > to pick it up through your GPIO tree? Actually Bartosz is handling the GPIO patches for v5.12. I tried to merge the patch series before but failed for various reasons. Yours, Linus Walleij
Re: LXC broken with 5.10-stable?, ok with 5.9-stable (Re: Linux 5.10.3)
On Sun, Dec 27, 2020 at 12:12:00PM -0800, Linus Torvalds wrote:
> On Sun, Dec 27, 2020 at 11:05 AM Linus Torvalds
> wrote:
> >
> > On Sun, Dec 27, 2020 at 10:39 AM Jussi Kivilinna
> > wrote:
> > >
> > > 5.10.3 with patch compiles fine, but does not solve the issue.
> >
> > Duh. adding the read_iter only fixes kernel_read(). For splice, it also
> > needs a
> >
> > .splice_read = generic_file_splice_read,
> >
> > in the file operations, something like this...
>
> Ok, I verified that patch with the test-case in the bugzilla, and it
> seems trivially fine.
>
> So it's committed as 14e3e989f6a5 ("proc mountinfo: make splice
> available again") now.
Is there any point in not doing the same (scripted, obviously) for
all instances with .read == seq_read? IIRC, Christoph even posted
something along those lines, but it went nowhere for some reason...
Re: [RFC PATCH 3/3] gpio: ep93xx: specify gpio_irq_chip->first
On Thu, Dec 24, 2020 at 12:22 PM Nikita Shubin wrote: > Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE. > > So we need to specify girq->first otherwise: > > "If device tree is used, then first_irq will be 0 and > irqs get mapped dynamically on the fly" > > And that's not the thing we want. > > Signed-off-by: Nikita Shubin Reviewed-by: Linus Walleij We can only fix this properly once we convert the platform to device tree. (Along with making the irqchip hierarchical.) Yours, Linus Walleij
Re: [RFC PATCH 2/3] gpio: ep93xx: drop to_irq binding
On Thu, Dec 24, 2020 at 12:22 PM Nikita Shubin wrote: > As ->to_irq is redefined in gpiochip_add_irqchip, having it defined in > driver is useless, so let's drop it. > > Also i think it is worth to give a gentle warning in > gpiochip_add_irqchip, to prevent people relying on to_irq. > > For example > > WARN_ON_ONCE(gc->to_irq, > "to_irq is redefined in gpiochip_add_irqchip" \ > "and you shouldn't rely on it\n"); > > Signed-off-by: Nikita Shubin Reviewed-by: Linus Walleij Take out the suggestion in the commit message and implement it, but I think WARN_ON is too nasty, just use dev_err(). Yours, Linus Walleij
Re: [PATCH v6 08/12] gpio: bd9571mwv: Add BD9574MWF support
On Wed, Dec 23, 2020 at 11:22 AM Yoshihiro Shimoda wrote: > Add support for BD9574MWF which is similar chip with BD9571MWV. > Note that BD9574MWF has additional features "RECOV_GPOUT", > "FREQSEL" and "RTC_IN", but supports GPIO function only. > > Signed-off-by: Yoshihiro Shimoda > Reviewed-by: Matti Vaittinen Acked-by: Linus Walleij This looks like it compile-time depends on the other patches right? Yours, Linus Walleij
Re: [PATCH v6 07/12] gpio: bd9571mwv: rid of using struct bd9571mwv
On Wed, Dec 23, 2020 at 11:22 AM Yoshihiro Shimoda wrote: > To simplify this driver, use dev_get_regmap() and > rid of using struct bd9571mwv. > > Signed-off-by: Yoshihiro Shimoda > Reviewed-by: Matti Vaittinen Acked-by: Linus Walleij Is this patch depending on other patches in the series or can it be applied directly to the GPIO tree as-is? Yours, Linus Walleij
