Re: [PATCH] gcc-plugins: fix gcc-plugins directory path in documentation
On Wed, Feb 26, 2020 at 3:58 AM Kees Cook wrote: > > On Thu, Feb 13, 2020 at 09:24:10PM +0900, Masahiro Yamada wrote: > > Fix typos "plgins" -> "plugins". > > > > Signed-off-by: Masahiro Yamada > > Thanks! > > Acked-by: Kees Cook > > Jon, can you take this? I noticed this patch had fallen into a crack. Applied to linux-kbuild now. Thanks. > -Kees > > > --- > > > > Documentation/kbuild/reproducible-builds.rst | 2 +- > > scripts/gcc-plugins/Kconfig | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/kbuild/reproducible-builds.rst > > b/Documentation/kbuild/reproducible-builds.rst > > index 503393854e2e..3b25655e441b 100644 > > --- a/Documentation/kbuild/reproducible-builds.rst > > +++ b/Documentation/kbuild/reproducible-builds.rst > > @@ -101,7 +101,7 @@ Structure randomisation > > > > If you enable ``CONFIG_GCC_PLUGIN_RANDSTRUCT``, you will need to > > pre-generate the random seed in > > -``scripts/gcc-plgins/randomize_layout_seed.h`` so the same value > > +``scripts/gcc-plugins/randomize_layout_seed.h`` so the same value > > is used in rebuilds. > > > > Debug info conflicts > > diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig > > index e3569543bdac..7b63c819610c 100644 > > --- a/scripts/gcc-plugins/Kconfig > > +++ b/scripts/gcc-plugins/Kconfig > > @@ -86,7 +86,7 @@ config GCC_PLUGIN_RANDSTRUCT > > source tree isn't cleaned after kernel installation). > > > > The seed used for compilation is located at > > - scripts/gcc-plgins/randomize_layout_seed.h. It remains after > > + scripts/gcc-plugins/randomize_layout_seed.h. It remains after > > a make clean to allow for external modules to be compiled with > > the existing seed and will be removed by a make mrproper or > > make distclean. > > -- > > 2.17.1 > > > > -- > Kees Cook -- Best Regards Masahiro Yamada
[RFC PATCH linus] drivers: thermal: tsens: tsens_critical_irq_thread() can be static
Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into
tsens.c")
Signed-off-by: kernel test robot
---
tsens.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 8d3e94d2a9ed4..39c4462e38f62 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -382,7 +382,7 @@ static inline u32 masked_irq(u32 hw_id, u32 mask, enum
tsens_ver ver)
*
* Return: IRQ_HANDLED
*/
-irqreturn_t tsens_critical_irq_thread(int irq, void *data)
+static irqreturn_t tsens_critical_irq_thread(int irq, void *data)
{
struct tsens_priv *priv = data;
struct tsens_irq_data d;
@@ -452,7 +452,7 @@ irqreturn_t tsens_critical_irq_thread(int irq, void *data)
*
* Return: IRQ_HANDLED
*/
-irqreturn_t tsens_irq_thread(int irq, void *data)
+static irqreturn_t tsens_irq_thread(int irq, void *data)
{
struct tsens_priv *priv = data;
struct tsens_irq_data d;
@@ -520,7 +520,7 @@ irqreturn_t tsens_irq_thread(int irq, void *data)
return IRQ_HANDLED;
}
-int tsens_set_trips(void *_sensor, int low, int high)
+static int tsens_set_trips(void *_sensor, int low, int high)
{
struct tsens_sensor *s = _sensor;
struct tsens_priv *priv = s->priv;
@@ -557,7 +557,7 @@ int tsens_set_trips(void *_sensor, int low, int high)
return 0;
}
-int tsens_enable_irq(struct tsens_priv *priv)
+static int tsens_enable_irq(struct tsens_priv *priv)
{
int ret;
int val = tsens_version(priv) > VER_1_X ? 7 : 1;
@@ -570,7 +570,7 @@ int tsens_enable_irq(struct tsens_priv *priv)
return ret;
}
-void tsens_disable_irq(struct tsens_priv *priv)
+static void tsens_disable_irq(struct tsens_priv *priv)
{
regmap_field_write(priv->rf[INT_EN], 0);
}
Re: [bpf] will-it-scale.per_thread_ops 2.6% improvement
On 6/27/20 1:22 AM, kernel test robot wrote:
Greeting,
FYI, we noticed a 2.6% improvement of will-it-scale.per_thread_ops due to
commit:
Thanks. The improvement is always good although I do not know
what will-it-scale.per_thread_ops exactly running.
But I think the commit
492e639f0c222784e2e0f121966375f641c61b15 ("bpf: Add bpf_seq_printf
and bpf_seq_write helpers")
probably not the reason for the improvement. This patch just add bpf
helpers and they should not be called in normal user codes.
If you want to identify which commit is responsible for the improvement,
you probably want to double check.
commit: 492e639f0c222784e2e0f121966375f641c61b15 ("bpf: Add bpf_seq_printf and
bpf_seq_write helpers")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: will-it-scale
on test machine: 288 threads Intel(R) Xeon Phi(TM) CPU 7295 @ 1.50GHz with 80G
memory
with following parameters:
nr_task: 100%
mode: thread
test: pthread_mutex2
cpufreq_governor: performance
ucode: 0x11
test-description: Will It Scale takes a testcase and runs it from 1 through to
n parallel copies to see if the testcase will scale. It builds both a process
and threads based test in order to see any differences between the two.
test-url: https://github.com/antonblanchard/will-it-scale
In addition to that, the commit also has significant impact on the following
tests:
+--+--+
| testcase: change | will-it-scale: will-it-scale.per_process_ops 2.5%
improvement|
| test machine | 288 threads Intel(R) Xeon Phi(TM) CPU 7295 @ 1.50GHz with
80G memory |
| test parameters | cpufreq_governor=performance
|
| | mode=process
|
| | nr_task=100%
|
| | test=malloc2
|
| | ucode=0x11
|
+--+--+
Details are as below:
-->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
=
compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase/ucode:
gcc-7/performance/x86_64-rhel-7.6/thread/100%/debian-x86_64-20191114.cgz/lkp-knm01/pthread_mutex2/will-it-scale/0x11
commit:
b121b341e5 ("bpf: Add PTR_TO_BTF_ID_OR_NULL support")
492e639f0c ("bpf: Add bpf_seq_printf and bpf_seq_write helpers")
b121b341e5983bdc 492e639f0c222784e2e0f121966
---
%stddev %change %stddev
\ |\
6105969+2.6%6265564will-it-scale.per_thread_ops
9855 +1196.5% 127775 ± 92%
will-it-scale.time.maximum_resident_set_size
1.759e+09+2.6% 1.804e+09will-it-scale.workload
[...]
***
lkp-knm01: 288 threads Intel(R) Xeon Phi(TM) CPU 7295 @ 1.50GHz with 80G memory
=
compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase/ucode:
gcc-9/performance/x86_64-rhel-7.6/thread/100%/debian-x86_64-20191114.cgz/lkp-knm01/context_switch1/will-it-scale/0x11
commit:
b121b341e5 ("bpf: Add PTR_TO_BTF_ID_OR_NULL support")
492e639f0c ("bpf: Add bpf_seq_printf and bpf_seq_write helpers")
b121b341e5983bdc 492e639f0c222784e2e0f121966
---
fail:runs %reproductionfail:runs
| | |
2:2 -100%:2
dmesg.WARNING:at#for_ip_swapgs_restore_regs_and_return_to_usermode/0x
2:2 -100%:2 dmesg.WARNING:stack_recursion
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Rong Chen
[PATCH 5/6] fs/minix: fix block limit check for V1 filesystems
From: Eric Biggers
The minix filesystem reads its maximum file size from its on-disk
superblock. This value isn't necessarily a multiple of the block size.
When it's not, the V1 block mapping code doesn't allow mapping the last
possible block. Commit 6ed6a722f9ab ("minixfs: fix block limit check")
fixed this in the V2 mapping code. Fix it in the V1 mapping code too.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers
---
fs/minix/itree_v1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/minix/itree_v1.c b/fs/minix/itree_v1.c
index c0d418209ead..405573a79aab 100644
--- a/fs/minix/itree_v1.c
+++ b/fs/minix/itree_v1.c
@@ -29,7 +29,7 @@ static int block_to_path(struct inode * inode, long block,
int offsets[DEPTH])
if (block < 0) {
printk("MINIX-fs: block_to_path: block %ld < 0 on dev %pg\n",
block, inode->i_sb->s_bdev);
- } else if (block >= inode->i_sb->s_maxbytes/BLOCK_SIZE) {
+ } else if ((u64)block * BLOCK_SIZE >= inode->i_sb->s_maxbytes) {
if (printk_ratelimit())
printk("MINIX-fs: block_to_path: "
"block %ld too big on dev %pg\n",
--
2.27.0
[PATCH 0/6] fs/minix: fix syzbot bugs and set s_maxbytes
This series fixes all syzbot bugs in the minix filesystem: KASAN: null-ptr-deref Write in get_block KASAN: use-after-free Write in get_block KASAN: use-after-free Read in get_block WARNING in inc_nlink KMSAN: uninit-value in get_block WARNING in drop_nlink It also fixes the minix filesystem to set s_maxbytes correctly, so that userspace sees the correct behavior when exceeding the max file size. Al or Andrew: one of you will need to take these patches, since no one is maintaining this filesystem. Eric Biggers (6): fs/minix: check return value of sb_getblk() fs/minix: don't allow getting deleted inodes fs/minix: reject too-large maximum file size fs/minix: set s_maxbytes correctly fs/minix: fix block limit check for V1 filesystems fs/minix: remove expected error message in block_to_path() fs/minix/inode.c| 42 + fs/minix/itree_common.c | 8 +++- fs/minix/itree_v1.c | 12 ++-- fs/minix/itree_v2.c | 13 ++--- fs/minix/minix.h| 1 - 5 files changed, 57 insertions(+), 19 deletions(-) -- 2.27.0
[PATCH 3/6] fs/minix: reject too-large maximum file size
From: Eric Biggers
If the minix filesystem tries to map a very large logical block number
to its on-disk location, block_to_path() can return offsets that are too
large, causing out-of-bounds memory accesses when accessing indirect
index blocks. This should be prevented by the check against the maximum
file size, but this doesn't work because the maximum file size is read
directly from the on-disk superblock and isn't validated itself.
Fix this by validating the maximum file size at mount time.
Reported-by: syzbot+c7d9ec7a1a7272dd7...@syzkaller.appspotmail.com
Reported-by: syzbot+3b7b03a0c28948054...@syzkaller.appspotmail.com
Reported-by: syzbot+6e056ee473568865f...@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
fs/minix/inode.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index 2bca95abe8f4..0dd929346f3f 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -150,6 +150,23 @@ static int minix_remount (struct super_block * sb, int *
flags, char * data)
return 0;
}
+static bool minix_check_superblock(struct minix_sb_info *sbi)
+{
+ if (sbi->s_imap_blocks == 0 || sbi->s_zmap_blocks == 0)
+ return false;
+
+ /*
+* s_max_size must not exceed the block mapping limitation. This check
+* is only needed for V1 filesystems, since V2/V3 support an extra level
+* of indirect blocks which places the limit well above U32_MAX.
+*/
+ if (sbi->s_version == MINIX_V1 &&
+ sbi->s_max_size > (7 + 512 + 512*512) * BLOCK_SIZE)
+ return false;
+
+ return true;
+}
+
static int minix_fill_super(struct super_block *s, void *data, int silent)
{
struct buffer_head *bh;
@@ -228,11 +245,12 @@ static int minix_fill_super(struct super_block *s, void
*data, int silent)
} else
goto out_no_fs;
+ if (!minix_check_superblock(sbi))
+ goto out_illegal_sb;
+
/*
* Allocate the buffer map to keep the superblock small.
*/
- if (sbi->s_imap_blocks == 0 || sbi->s_zmap_blocks == 0)
- goto out_illegal_sb;
i = (sbi->s_imap_blocks + sbi->s_zmap_blocks) * sizeof(bh);
map = kzalloc(i, GFP_KERNEL);
if (!map)
--
2.27.0
[PATCH 2/6] fs/minix: don't allow getting deleted inodes
From: Eric Biggers
If an inode has no links, we need to mark it bad rather than allowing it
to be accessed. This avoids WARNINGs in inc_nlink() and drop_nlink()
when doing directory operations on a fuzzed filesystem.
Reported-by: syzbot+a9ac3de1b5de5fb10...@syzkaller.appspotmail.com
Reported-by: syzbot+df958cf5688a96ad3...@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
fs/minix/inode.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index 7cb5fd38eb14..2bca95abe8f4 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -468,6 +468,13 @@ static struct inode *V1_minix_iget(struct inode *inode)
iget_failed(inode);
return ERR_PTR(-EIO);
}
+ if (raw_inode->i_nlinks == 0) {
+ printk("MINIX-fs: deleted inode referenced: %lu\n",
+ inode->i_ino);
+ brelse(bh);
+ iget_failed(inode);
+ return ERR_PTR(-ESTALE);
+ }
inode->i_mode = raw_inode->i_mode;
i_uid_write(inode, raw_inode->i_uid);
i_gid_write(inode, raw_inode->i_gid);
@@ -501,6 +508,13 @@ static struct inode *V2_minix_iget(struct inode *inode)
iget_failed(inode);
return ERR_PTR(-EIO);
}
+ if (raw_inode->i_nlinks == 0) {
+ printk("MINIX-fs: deleted inode referenced: %lu\n",
+ inode->i_ino);
+ brelse(bh);
+ iget_failed(inode);
+ return ERR_PTR(-ESTALE);
+ }
inode->i_mode = raw_inode->i_mode;
i_uid_write(inode, raw_inode->i_uid);
i_gid_write(inode, raw_inode->i_gid);
--
2.27.0
[PATCH 1/6] fs/minix: check return value of sb_getblk()
From: Eric Biggers
sb_getblk() can fail, so check its return value.
This fixes a NULL pointer dereference.
Reported-by: syzbot+4a88b2b9dc280f47b...@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Originally-from: Qiujun Huang
Signed-off-by: Eric Biggers
---
fs/minix/itree_common.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/minix/itree_common.c b/fs/minix/itree_common.c
index 043c3fdbc8e7..446148792f41 100644
--- a/fs/minix/itree_common.c
+++ b/fs/minix/itree_common.c
@@ -75,6 +75,7 @@ static int alloc_branch(struct inode *inode,
int n = 0;
int i;
int parent = minix_new_block(inode);
+ int err = -ENOSPC;
branch[0].key = cpu_to_block(parent);
if (parent) for (n = 1; n < num; n++) {
@@ -85,6 +86,11 @@ static int alloc_branch(struct inode *inode,
break;
branch[n].key = cpu_to_block(nr);
bh = sb_getblk(inode->i_sb, parent);
+ if (!bh) {
+ minix_free_block(inode, nr);
+ err = -ENOMEM;
+ break;
+ }
lock_buffer(bh);
memset(bh->b_data, 0, bh->b_size);
branch[n].bh = bh;
@@ -103,7 +109,7 @@ static int alloc_branch(struct inode *inode,
bforget(branch[i].bh);
for (i = 0; i < n; i++)
minix_free_block(inode, block_to_cpu(branch[i].key));
- return -ENOSPC;
+ return err;
}
static inline int splice_branch(struct inode *inode,
--
2.27.0
[PATCH 4/6] fs/minix: set s_maxbytes correctly
From: Eric Biggers
The minix filesystem leaves super_block::s_maxbytes at MAX_NON_LFS
rather than setting it to the actual filesystem-specific limit. This is
broken because it means userspace doesn't see the standard behavior like
getting EFBIG and SIGXFSZ when exceeding the maximum file size.
Fix this by setting s_maxbytes correctly.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers
---
fs/minix/inode.c| 12 +++-
fs/minix/itree_v1.c | 2 +-
fs/minix/itree_v2.c | 3 +--
fs/minix/minix.h| 1 -
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index 0dd929346f3f..7b09a9158e40 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -150,8 +150,10 @@ static int minix_remount (struct super_block * sb, int *
flags, char * data)
return 0;
}
-static bool minix_check_superblock(struct minix_sb_info *sbi)
+static bool minix_check_superblock(struct super_block *sb)
{
+ struct minix_sb_info *sbi = minix_sb(sb);
+
if (sbi->s_imap_blocks == 0 || sbi->s_zmap_blocks == 0)
return false;
@@ -161,7 +163,7 @@ static bool minix_check_superblock(struct minix_sb_info
*sbi)
* of indirect blocks which places the limit well above U32_MAX.
*/
if (sbi->s_version == MINIX_V1 &&
- sbi->s_max_size > (7 + 512 + 512*512) * BLOCK_SIZE)
+ sb->s_maxbytes > (7 + 512 + 512*512) * BLOCK_SIZE)
return false;
return true;
@@ -202,7 +204,7 @@ static int minix_fill_super(struct super_block *s, void
*data, int silent)
sbi->s_zmap_blocks = ms->s_zmap_blocks;
sbi->s_firstdatazone = ms->s_firstdatazone;
sbi->s_log_zone_size = ms->s_log_zone_size;
- sbi->s_max_size = ms->s_max_size;
+ s->s_maxbytes = ms->s_max_size;
s->s_magic = ms->s_magic;
if (s->s_magic == MINIX_SUPER_MAGIC) {
sbi->s_version = MINIX_V1;
@@ -233,7 +235,7 @@ static int minix_fill_super(struct super_block *s, void
*data, int silent)
sbi->s_zmap_blocks = m3s->s_zmap_blocks;
sbi->s_firstdatazone = m3s->s_firstdatazone;
sbi->s_log_zone_size = m3s->s_log_zone_size;
- sbi->s_max_size = m3s->s_max_size;
+ s->s_maxbytes = m3s->s_max_size;
sbi->s_ninodes = m3s->s_ninodes;
sbi->s_nzones = m3s->s_zones;
sbi->s_dirsize = 64;
@@ -245,7 +247,7 @@ static int minix_fill_super(struct super_block *s, void
*data, int silent)
} else
goto out_no_fs;
- if (!minix_check_superblock(sbi))
+ if (!minix_check_superblock(s))
goto out_illegal_sb;
/*
diff --git a/fs/minix/itree_v1.c b/fs/minix/itree_v1.c
index 046cc96ee7ad..c0d418209ead 100644
--- a/fs/minix/itree_v1.c
+++ b/fs/minix/itree_v1.c
@@ -29,7 +29,7 @@ static int block_to_path(struct inode * inode, long block,
int offsets[DEPTH])
if (block < 0) {
printk("MINIX-fs: block_to_path: block %ld < 0 on dev %pg\n",
block, inode->i_sb->s_bdev);
- } else if (block >= (minix_sb(inode->i_sb)->s_max_size/BLOCK_SIZE)) {
+ } else if (block >= inode->i_sb->s_maxbytes/BLOCK_SIZE) {
if (printk_ratelimit())
printk("MINIX-fs: block_to_path: "
"block %ld too big on dev %pg\n",
diff --git a/fs/minix/itree_v2.c b/fs/minix/itree_v2.c
index f7fc7ecc..ee8af2f9e282 100644
--- a/fs/minix/itree_v2.c
+++ b/fs/minix/itree_v2.c
@@ -32,8 +32,7 @@ static int block_to_path(struct inode * inode, long block,
int offsets[DEPTH])
if (block < 0) {
printk("MINIX-fs: block_to_path: block %ld < 0 on dev %pg\n",
block, sb->s_bdev);
- } else if ((u64)block * (u64)sb->s_blocksize >=
- minix_sb(sb)->s_max_size) {
+ } else if ((u64)block * (u64)sb->s_blocksize >= sb->s_maxbytes) {
if (printk_ratelimit())
printk("MINIX-fs: block_to_path: "
"block %ld too big on dev %pg\n",
diff --git a/fs/minix/minix.h b/fs/minix/minix.h
index df081e8afcc3..168d45d3de73 100644
--- a/fs/minix/minix.h
+++ b/fs/minix/minix.h
@@ -32,7 +32,6 @@ struct minix_sb_info {
unsigned long s_zmap_blocks;
unsigned long s_firstdatazone;
unsigned long s_log_zone_size;
- unsigned long s_max_size;
int s_dirsize;
int s_namelen;
struct buffer_head ** s_imap;
--
2.27.0
[PATCH 6/6] fs/minix: remove expected error message in block_to_path()
From: Eric Biggers
When truncating a file to a size within the last allowed logical block,
block_to_path() is called with the *next* block. This exceeds the
limit, causing the "block %ld too big" error message to be printed.
This case isn't actually an error; there are just no more blocks past
that point. So, remove this error message.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers
---
fs/minix/itree_v1.c | 12 ++--
fs/minix/itree_v2.c | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/minix/itree_v1.c b/fs/minix/itree_v1.c
index 405573a79aab..1fed906042aa 100644
--- a/fs/minix/itree_v1.c
+++ b/fs/minix/itree_v1.c
@@ -29,12 +29,12 @@ static int block_to_path(struct inode * inode, long block,
int offsets[DEPTH])
if (block < 0) {
printk("MINIX-fs: block_to_path: block %ld < 0 on dev %pg\n",
block, inode->i_sb->s_bdev);
- } else if ((u64)block * BLOCK_SIZE >= inode->i_sb->s_maxbytes) {
- if (printk_ratelimit())
- printk("MINIX-fs: block_to_path: "
- "block %ld too big on dev %pg\n",
- block, inode->i_sb->s_bdev);
- } else if (block < 7) {
+ return 0;
+ }
+ if ((u64)block * BLOCK_SIZE >= inode->i_sb->s_maxbytes)
+ return 0;
+
+ if (block < 7) {
offsets[n++] = block;
} else if ((block -= 7) < 512) {
offsets[n++] = 7;
diff --git a/fs/minix/itree_v2.c b/fs/minix/itree_v2.c
index ee8af2f9e282..9d00f31a2d9d 100644
--- a/fs/minix/itree_v2.c
+++ b/fs/minix/itree_v2.c
@@ -32,12 +32,12 @@ static int block_to_path(struct inode * inode, long block,
int offsets[DEPTH])
if (block < 0) {
printk("MINIX-fs: block_to_path: block %ld < 0 on dev %pg\n",
block, sb->s_bdev);
- } else if ((u64)block * (u64)sb->s_blocksize >= sb->s_maxbytes) {
- if (printk_ratelimit())
- printk("MINIX-fs: block_to_path: "
- "block %ld too big on dev %pg\n",
- block, sb->s_bdev);
- } else if (block < DIRCOUNT) {
+ return 0;
+ }
+ if ((u64)block * (u64)sb->s_blocksize >= sb->s_maxbytes)
+ return 0;
+
+ if (block < DIRCOUNT) {
offsets[n++] = block;
} else if ((block -= DIRCOUNT) < INDIRCOUNT(sb)) {
offsets[n++] = DIRCOUNT;
--
2.27.0
Re: [PATCH] riscv: Fixup compile error BUILD_BUG_ON failed
On Sun, Jun 28, 2020 at 10:59 AM Masami Hiramatsu wrote:
>
> On Sat, 27 Jun 2020 16:20:02 +
> guo...@kernel.org wrote:
>
> > From: Guo Ren
> >
> > Unfortunately, the current code couldn't be compiled, because
> > BUILD_BUG_ON needs a static defined value, not a dynamic
> > variable with a0 regs. Just use it inline as a solution.
> >
> > CC arch/riscv/kernel/patch.o
> > In file included from ./include/linux/kernel.h:11,
> > from ./include/linux/list.h:9,
> > from ./include/linux/preempt.h:11,
> > from ./include/linux/spinlock.h:51,
> > from arch/riscv/kernel/patch.c:6:
> > In function ‘fix_to_virt’,
> > inlined from ‘patch_map’ at arch/riscv/kernel/patch.c:37:17:
> > ./include/linux/compiler.h:392:38: error: call to
> > ‘__compiletime_assert_205’ declared with attribute error: BUILD_BUG_ON
> > failed: idx >= __end_of_fixed_addresses
> > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > ^
> > ./include/linux/compiler.h:373:4: note: in definition of macro
> > ‘__compiletime_assert’
> > prefix ## suffix();\
> > ^~
> > ./include/linux/compiler.h:392:2: note: in expansion of macro
> > ‘_compiletime_assert’
> > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > ^~~
> > ./include/linux/build_bug.h:39:37: note: in expansion of macro
> > ‘compiletime_assert’
> > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> > ^~
> > ./include/linux/build_bug.h:50:2: note: in expansion of macro
> > ‘BUILD_BUG_ON_MSG’
> > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> > ^~~~
> > ./include/asm-generic/fixmap.h:32:2: note: in expansion of macro
> > ‘BUILD_BUG_ON’
> > BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
> > ^~~~
> >
> > Signed-off-by: Guo Ren
> > Cc: Masami Hiramatsu
> > Cc: Zong Li
> > ---
> > arch/riscv/kernel/patch.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
> > index d4a64df..f8e84f2 100644
> > --- a/arch/riscv/kernel/patch.c
> > +++ b/arch/riscv/kernel/patch.c
> > @@ -20,7 +20,7 @@ struct patch_insn {
> > };
> >
> > #ifdef CONFIG_MMU
> > -static void *patch_map(void *addr, int fixmap)
> > +static inline void *patch_map(void *addr, int fixmap)
>
> Would we be better to use "__always_inline" as same as fix_to_virt?
Ok
> And also, could you add a comment why we need to make it inline?
I've mentioned in comment:
> > BUILD_BUG_ON needs a static defined value, not a dynamic
> > variable with a0 regs.
idx must be a const unsigned int or it will cause compile error with
BUILD_BUG_ON.
/*
* 'index to address' translation. If anyone tries to use the idx
* directly without translation, we catch the bug with a NULL-deference
* kernel oops. Illegal ranges of incoming indices are caught too.
*/
static __always_inline unsigned long fix_to_virt(const unsigned int idx)
{
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
return __fix_to_virt(idx);
}
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [PATCH] modpost: remove use of non-standard strsep() in HOSTCC code
Hi,
> Am 28.06.2020 um 07:51 schrieb Masahiro Yamada :
>
> On Thu, Jun 25, 2020 at 5:47 PM H. Nikolaus Schaller
> wrote:
>>
>> strsep() is neither standard C nor POSIX and used outside
>> the kernel code here. Using it here requires that the
>> build host supports it out of the box which is e.g.
>> not true for a Darwin build host and using a cross-compiler.
>> This leads to:
>>
>> scripts/mod/modpost.c:145:2: warning: implicit declaration of function
>> 'strsep' [-Wimplicit-function-declaration]
>> return strsep(stringp, "\n");
>> ^
>>
>> and a segfault when running MODPOST.
>>
>> See also: https://stackoverflow.com/a/7219504
>>
>> So let's add some lines of code separating the string at the
>> next newline character instead of using strsep(). It does not
>> hurt kernel size or speed since this code is run on the build host.
>>
>> Fixes: ac5100f5432967 ("modpost: add read_text_file() and get_line()
>> helpers")
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> scripts/mod/modpost.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
>> index 6aea65c65745..8fe63989c6e1 100644
>> --- a/scripts/mod/modpost.c
>> +++ b/scripts/mod/modpost.c
>> @@ -138,11 +138,16 @@ char *read_text_file(const char *filename)
>>
>> char *get_line(char **stringp)
>> {
>> + char *p;
>>/* do not return the unwanted extra line at EOF */
>>if (*stringp && **stringp == '\0')
>
> This check does not make sense anymore.
>
> Previously, get_line(NULL) returns NULL.
>
> With your patch, get_line(NULL) crashes
> due to NULL-pointer dereference.
Well, that is original code.
I have only replaced the strsep() function.
But yes, it looks to be better in addition to
my patch.
>
>
>
>>return NULL;
>>
>> - return strsep(stringp, "\n");
>> + p = *stringp;
>> + while (**stringp != '\n')
>> + (*stringp)++;
>
>
> Is this a safe conversion?
>
> If the input file does not contain '\n' at all,
> this while-loop continues running,
> and results in the segmentation fault
> due to buffer over-run.
Ah, yes, you are right.
We should use
+ while (**stringp && **stringp != '\n')
>
>
>
>> + *(*stringp)++ = '\0';
>> + return p;
>> }
>
>
>
> How about this?
>
> char *get_line(char **stringp)
> {
>char *orig = *stringp;
^^^ this still segfaults with get_line(NULL)
>char *next;
>
>/* do not return the unwanted extra line at EOF */
>if (!orig || *orig == '\0')
>return NULL;
>
>next = strchr(orig, '\n');
>if (next)
>*next++ = '\0';
>
>*stringp = next;
Yes, this code is easier to understand than my while loop.
And strchr() is POSIX.
So should I submit an updated patch or do you want to submit
it (with a suggested-by: H. Nikolaus Schaller )
BR and thanks,
Nikolaus Schaller
Re: [PATCH] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM
On 2020/6/25 上午6:25, Michael S. Tsirkin wrote:
Rename the bit to match latest virtio spec.
Add a compat macro to avoid breaking existing userspace.
Signed-off-by: Michael S. Tsirkin
---
arch/um/drivers/virtio_uml.c | 2 +-
drivers/vdpa/ifcvf/ifcvf_base.h| 2 +-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++--
drivers/vhost/net.c| 4 ++--
drivers/vhost/vdpa.c | 2 +-
drivers/virtio/virtio_balloon.c| 2 +-
drivers/virtio/virtio_ring.c | 2 +-
include/linux/virtio_config.h | 2 +-
include/uapi/linux/virtio_config.h | 10 +++---
tools/virtio/linux/virtio_config.h | 2 +-
10 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/um/drivers/virtio_uml.c b/arch/um/drivers/virtio_uml.c
index 351aee52aca6..a6c4bb6c2c01 100644
--- a/arch/um/drivers/virtio_uml.c
+++ b/arch/um/drivers/virtio_uml.c
@@ -385,7 +385,7 @@ static irqreturn_t vu_req_interrupt(int irq, void *data)
}
break;
case VHOST_USER_SLAVE_IOTLB_MSG:
- /* not supported - VIRTIO_F_IOMMU_PLATFORM */
+ /* not supported - VIRTIO_F_ACCESS_PLATFORM */
case VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG:
/* not supported - VHOST_USER_PROTOCOL_F_HOST_NOTIFIER */
default:
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h
index f4554412e607..24af422b5a3e 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -29,7 +29,7 @@
(1ULL << VIRTIO_F_VERSION_1) | \
(1ULL << VIRTIO_NET_F_STATUS)| \
(1ULL << VIRTIO_F_ORDER_PLATFORM)| \
-(1ULL << VIRTIO_F_IOMMU_PLATFORM)| \
+(1ULL << VIRTIO_F_ACCESS_PLATFORM) | \
(1ULL << VIRTIO_NET_F_MRG_RXBUF))
/* Only one queue pair for now. */
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index c7334cc65bb2..a9bc5e0fb353 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -55,7 +55,7 @@ struct vdpasim_virtqueue {
static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
(1ULL << VIRTIO_F_VERSION_1) |
- (1ULL << VIRTIO_F_IOMMU_PLATFORM);
+ (1ULL << VIRTIO_F_ACCESS_PLATFORM);
/* State of each vdpasim device */
struct vdpasim {
@@ -450,7 +450,7 @@ static int vdpasim_set_features(struct vdpa_device *vdpa,
u64 features)
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
/* DMA mapping must be done by driver */
- if (!(features & (1ULL << VIRTIO_F_IOMMU_PLATFORM)))
+ if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
return -EINVAL;
vdpasim->features = features & vdpasim_features;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index e992decfec53..8e0921d3805d 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -73,7 +73,7 @@ enum {
VHOST_NET_FEATURES = VHOST_FEATURES |
(1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
(1ULL << VIRTIO_NET_F_MRG_RXBUF) |
-(1ULL << VIRTIO_F_IOMMU_PLATFORM)
+(1ULL << VIRTIO_F_ACCESS_PLATFORM)
};
enum {
@@ -1653,7 +1653,7 @@ static int vhost_net_set_features(struct vhost_net *n,
u64 features)
!vhost_log_access_ok(>dev))
goto out_unlock;
- if ((features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))) {
+ if ((features & (1ULL << VIRTIO_F_ACCESS_PLATFORM))) {
if (vhost_init_device_iotlb(>dev, true))
goto out_unlock;
}
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index a54b60d6623f..18869a35d408 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -31,7 +31,7 @@ enum {
(1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) |
(1ULL << VIRTIO_F_ANY_LAYOUT) |
(1ULL << VIRTIO_F_VERSION_1) |
- (1ULL << VIRTIO_F_IOMMU_PLATFORM) |
+ (1ULL << VIRTIO_F_ACCESS_PLATFORM) |
(1ULL << VIRTIO_F_RING_PACKED) |
(1ULL << VIRTIO_F_ORDER_PLATFORM) |
(1ULL << VIRTIO_RING_F_INDIRECT_DESC) |
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 1f157d2f4952..fc7301406540 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -1120,7 +1120,7 @@ static int virtballoon_validate(struct virtio_device
*vdev)
else if (!virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON))
__virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
- __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
+ __virtio_clear_bit(vdev, VIRTIO_F_ACCESS_PLATFORM);
return 0;
}
diff --git
Re: [PATCH v2 2/2] virtio: virtio_has_iommu_quirk -> virtio_has_dma_quirk
On 2020/6/25 上午7:21, Michael S. Tsirkin wrote:
Now that the corresponding feature bit has been renamed,
rename the quirk too - it's about special ways to
do DMA, not necessarily about the IOMMU.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
drivers/virtio/virtio_ring.c| 2 +-
include/linux/virtio_config.h | 4 ++--
tools/virtio/linux/virtio_config.h | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01cd888..e8799ab0c753 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -141,7 +141,7 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_mem_entry **ents,
unsigned int *nents)
{
- bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+ bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
struct scatterlist *sg;
int si, ret;
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5d9952..53af60d484a4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -599,7 +599,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]);
struct virtio_gpu_transfer_to_host_2d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
- bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+ bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
if (use_dma_api)
@@ -1015,7 +1015,7 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]);
struct virtio_gpu_transfer_host_3d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
- bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+ bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
if (use_dma_api)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index a1a5c2a91426..34253cb69cb8 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -240,7 +240,7 @@ static inline bool virtqueue_use_indirect(struct virtqueue
*_vq,
static bool vring_use_dma_api(struct virtio_device *vdev)
{
- if (!virtio_has_iommu_quirk(vdev))
+ if (!virtio_has_dma_quirk(vdev))
return true;
/* Otherwise, we are left to guess. */
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index f2cc2a0df174..3b4eae5ac5e3 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -162,10 +162,10 @@ static inline bool virtio_has_feature(const struct
virtio_device *vdev,
}
/**
- * virtio_has_iommu_quirk - determine whether this device has the iommu quirk
+ * virtio_has_dma_quirk - determine whether this device has the DMA quirk
* @vdev: the device
*/
-static inline bool virtio_has_iommu_quirk(const struct virtio_device *vdev)
+static inline bool virtio_has_dma_quirk(const struct virtio_device *vdev)
{
/*
* Note the reverse polarity of the quirk feature (compared to most
diff --git a/tools/virtio/linux/virtio_config.h
b/tools/virtio/linux/virtio_config.h
index f99ae42668e0..f2640e505c4e 100644
--- a/tools/virtio/linux/virtio_config.h
+++ b/tools/virtio/linux/virtio_config.h
@@ -42,10 +42,10 @@ static inline void __virtio_clear_bit(struct virtio_device
*vdev,
(__virtio_test_bit((dev), feature))
/**
- * virtio_has_iommu_quirk - determine whether this device has the iommu quirk
+ * virtio_has_dma_quirk - determine whether this device has the DMA quirk
* @vdev: the device
*/
-static inline bool virtio_has_iommu_quirk(const struct virtio_device *vdev)
+static inline bool virtio_has_dma_quirk(const struct virtio_device *vdev)
{
/*
* Note the reverse polarity of the quirk feature (compared to most
Acked-by: Jason Wang
Re: [RFC PATCH 1/2] 9p: retrieve fid from file when file instance exist.
Jianyong Wu wrote on Sun, Jun 28, 2020:
> In the current setattr implementation in 9p, fid will always retrieved from
> dentry no matter file instance exist or not when setattr. There will
> be some info related to open file instance dropped. so it's better
> to retrieve fid from file instance if file instance is passed to setattr.
>
> for example:
> fd=open("tmp", O_RDWR);
> ftruncate(fd, 10);
>
> the file context related with fd info will lost as fid will always be
> retrieved from dentry, then the backend can't get the info of file context.
> it is against the original intention of user and may lead to bug.
I agree on principle, this makes more sense to use the file's fid.
Just a comment below, but while I'm up in commit message I'll also be
annoying with it -- please try to fix grammar mistakes for next
patches/version (mostly missing some 'be' for future passive form; but I
don't understand why you use future at all and some passive forms could
probably be made active to simplify... Anyway we're not here to discuss
English grammar but words missing out is sloppy and that gives a bad
impression for no good reason)
>
> Signed-off-by: Jianyong Wu
> ---
> fs/9p/vfs_inode.c | 5 -
> fs/9p/vfs_inode_dotl.c | 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
> index c9255d399917..010869389523 100644
> --- a/fs/9p/vfs_inode.c
> +++ b/fs/9p/vfs_inode.c
> @@ -1100,7 +1100,10 @@ static int v9fs_vfs_setattr(struct dentry *dentry,
> struct iattr *iattr)
>
> retval = -EPERM;
> v9ses = v9fs_dentry2v9ses(dentry);
> - fid = v9fs_fid_lookup(dentry);
> + if (iattr->ia_valid & ATTR_FILE)
> + fid = iattr->ia_file->private_data;
hmm, normally setattr cannot happen on a file that hasn't been opened so
private_data should always be set, but it doesn't cost much to play safe
and check? e.g. something like this is more conservative:
struct p9_fid *fid = NULL;
...
if (iattr->ia_valid & ATTR_FILE) {
fid = iattr->ia_file->private_data;
WARN_ON(!fid);
}
if (!fid)
fid = v9fs_fid_lookup(dentry);
What do you think?
--
Dominique
Re: [PATCH] ARM: dts: zx: Align L2 cache-controller nodename with dtschema
Krzysztof Kozlowski 于2020年6月26日周五 下午4:05写道： > > Fix dtschema validator warnings like: > l2-cache-controller@c0: $nodename:0: > 'l2-cache-controller@c0' does not match > '^(cache-controller|cpu)(@[0-9a-f,]+)*$' > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/boot/dts/zx296702.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Jun Nie
Re: [PATCH] sched: fix build with GCC_PLUGIN_RANDSTRUCT
On Sat, Jun 27, 2020 at 06:12:14PM -0400, Steven Rostedt wrote:
> On Sat, 20 Jun 2020 13:41:36 +0300
> Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > Since the commit a148866489fb ("sched: Replace rq::wake_list")
> > task_struct and CSD_TYPE_TTWU objects can be on the same queue and this
> > requires that have "layout similar enough".
> >
> > This assumption is broken when CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled:
>
> You forgot to Cc Kees, who's the one that is probably the most
> concerned about randomizing structures!
I was not concerned about randomizing, I was troubled by failing
allyesconfig builds :)
> > /*
> > * This begins the randomizable portion of task_struct. Only
> > * scheduling-critical items should be added above here.
> > @@ -654,8 +663,6 @@ struct task_struct {
> > unsigned intptrace;
> >
> > #ifdef CONFIG_SMP
> > - struct llist_node wake_entry;
> > - unsigned intwake_entry_type;
>
> What about instead just create an anonymous structure of the two. That
> way they can still be randomized within the task struct and not be a
> target of attacks?
>
> struct {
> struct llist_node wake_entry;
> unsigned intwake_entry_type;
> };
>
> Would that work?
Yep, thanks, this works.
Will send v2 soon.
> -- Steve
>
>
> > int on_cpu;
> > #ifdef CONFIG_THREAD_INFO_IN_TASK
> > /* Current CPU: */
>
--
Sincerely yours,
Mike.
RE: [RFC PATCH 1/2] 9p: retrieve fid from file when file instance exist.
Hi Dominique,
> -Original Message-
> From: Dominique Martinet
> Sent: Sunday, June 28, 2020 2:28 PM
> To: Jianyong Wu
> Cc: eri...@gmail.com; lu...@ionkov.net; v9fs-
> develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org; Steve
> Capper ; Kaly Xin ; Justin He
> ; Wei Chen
> Subject: Re: [RFC PATCH 1/2] 9p: retrieve fid from file when file instance
> exist.
>
> Jianyong Wu wrote on Sun, Jun 28, 2020:
> > In the current setattr implementation in 9p, fid will always retrieved
> > from dentry no matter file instance exist or not when setattr. There
> > will be some info related to open file instance dropped. so it's
> > better to retrieve fid from file instance if file instance is passed to
> > setattr.
> >
> > for example:
> > fd=open("tmp", O_RDWR);
> > ftruncate(fd, 10);
> >
> > the file context related with fd info will lost as fid will always be
> > retrieved from dentry, then the backend can't get the info of file context.
> > it is against the original intention of user and may lead to bug.
>
> I agree on principle, this makes more sense to use the file's fid.
>
Thanks!
> Just a comment below, but while I'm up in commit message I'll also be
> annoying with it -- please try to fix grammar mistakes for next
> patches/version (mostly missing some 'be' for future passive form; but I don't
> understand why you use future at all and some passive forms could probably
> be made active to simplify... Anyway we're not here to discuss English
> grammar but words missing out is sloppy and that gives a bad impression for
> no good reason)
>
Sorry to my poor English and thanks to point out the grammar mistakes, I'll
fix it.
> >
> > Signed-off-by: Jianyong Wu
> > ---
> > fs/9p/vfs_inode.c | 5 -
> > fs/9p/vfs_inode_dotl.c | 5 -
> > 2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c index
> > c9255d399917..010869389523 100644
> > --- a/fs/9p/vfs_inode.c
> > +++ b/fs/9p/vfs_inode.c
> > @@ -1100,7 +1100,10 @@ static int v9fs_vfs_setattr(struct dentry
> > *dentry, struct iattr *iattr)
> >
> > retval = -EPERM;
> > v9ses = v9fs_dentry2v9ses(dentry);
> > -fid = v9fs_fid_lookup(dentry);
> > +if (iattr->ia_valid & ATTR_FILE)
> > +fid = iattr->ia_file->private_data;
>
> hmm, normally setattr cannot happen on a file that hasn't been opened so
> private_data should always be set, but it doesn't cost much to play safe and
> check? e.g. something like this is more conservative:
>
> struct p9_fid *fid = NULL;
> ...
> if (iattr->ia_valid & ATTR_FILE) {
> fid = iattr->ia_file->private_data;
> WARN_ON(!fid);
> }
> if (!fid)
> fid = v9fs_fid_lookup(dentry);
>
>
>
> What do you think?
>
Thanks, I think it's better. I'll take it.
Thanks
Jianyong
> --
> Dominique
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
Re: [PATCH v3 13/15] mm,hwpoison: Refactor soft_offline_huge_page and __soft_offline_page
On Fri, Jun 26, 2020 at 10:23:43PM +0530, Naresh Kamboju wrote:
> On Wed, 24 Jun 2020 at 20:32, wrote:
> >
> > From: Oscar Salvador
> >
> > Merging soft_offline_huge_page and __soft_offline_page let us get rid of
> > quite some duplicated code, and makes the code much easier to follow.
> >
> > Now, __soft_offline_page will handle both normal and hugetlb pages.
> >
> > Note that move put_page() block to the beginning of page_handle_poison()
> > with drain_all_pages() in order to make sure that the target page is
> > freed and sent into free list to make take_page_off_buddy() work properly.
> >
> > Signed-off-by: Oscar Salvador
> > Signed-off-by: Naoya Horiguchi
> > ---
> > ChangeLog v2 -> v3:
> > - use page_is_file_lru() instead of page_is_file_cache(),
> > - add description about put_page() and drain_all_pages().
> > - fix coding style warnings by checkpatch.pl
> > ---
> > mm/memory-failure.c | 185
> > 1 file changed, 86 insertions(+), 99 deletions(-)
> >
> > diff --git v5.8-rc1-mmots-2020-06-20-21-44/mm/memory-failure.c
> > v5.8-rc1-mmots-2020-06-20-21-44_patched/mm/memory-failure.c
> > index f744eb90c15c..22c904f6d17a 100644
> > --- v5.8-rc1-mmots-2020-06-20-21-44/mm/memory-failure.c
> > +++ v5.8-rc1-mmots-2020-06-20-21-44_patched/mm/memory-failure.c
> > @@ -78,14 +78,36 @@ EXPORT_SYMBOL_GPL(hwpoison_filter_dev_minor);
> > EXPORT_SYMBOL_GPL(hwpoison_filter_flags_mask);
> > EXPORT_SYMBOL_GPL(hwpoison_filter_flags_value);
> >
> > -static void page_handle_poison(struct page *page, bool release)
> > +static bool page_handle_poison(struct page *page, bool
> > hugepage_or_freepage, bool release)
> > {
> > + if (release) {
> > + put_page(page);
> > + drain_all_pages(page_zone(page));
> > + }
> > +
> > + if (hugepage_or_freepage) {
> > + /*
> > +* Doing this check for free pages is also fine since
> > dissolve_free_huge_page
> > +* returns 0 for non-hugetlb pages as well.
> > +*/
> > + if (dissolve_free_huge_page(page) ||
> > !take_page_off_buddy(page))
> > + /*
> > +* The hugetlb page can end up being enqueued back into
> > +* the freelists by means of:
> > +* unmap_and_move_huge_page
> > +* putback_active_hugepage
> > +* put_page->free_huge_page
> > +*enqueue_huge_page
> > +* If this happens, we might lose the race against an
> > allocation.
> > +*/
> > + return false;
> > + }
> >
> > SetPageHWPoison(page);
> > - if (release)
> > - put_page(page);
> > page_ref_inc(page);
> > num_poisoned_pages_inc();
> > +
> > + return true;
> > }
> >
> > static int hwpoison_filter_dev(struct page *p)
> > @@ -1718,63 +1740,52 @@ static int get_any_page(struct page *page, unsigned
> > long pfn)
> > return ret;
> > }
> >
> > -static int soft_offline_huge_page(struct page *page)
> > +static bool isolate_page(struct page *page, struct list_head *pagelist)
> > {
> > - int ret;
> > - unsigned long pfn = page_to_pfn(page);
> > - struct page *hpage = compound_head(page);
> > - LIST_HEAD(pagelist);
> > + bool isolated = false;
> > + bool lru = PageLRU(page);
> > +
> > + if (PageHuge(page)) {
> > + isolated = isolate_huge_page(page, pagelist);
> > + } else {
> > + if (lru)
> > + isolated = !isolate_lru_page(page);
> > + else
> > + isolated = !isolate_movable_page(page,
> > ISOLATE_UNEVICTABLE);
> > +
> > + if (isolated)
> > + list_add(>lru, pagelist);
> >
> > - /*
> > -* This double-check of PageHWPoison is to avoid the race with
> > -* memory_failure(). See also comment in __soft_offline_page().
> > -*/
> > - lock_page(hpage);
> > - if (PageHWPoison(hpage)) {
> > - unlock_page(hpage);
> > - put_page(hpage);
> > - pr_info("soft offline: %#lx hugepage already poisoned\n",
> > pfn);
> > - return -EBUSY;
> > }
> > - unlock_page(hpage);
> >
> > - ret = isolate_huge_page(hpage, );
> > + if (isolated && lru)
> > + inc_node_page_state(page, NR_ISOLATED_ANON +
> > + page_is_file_lru(page));
> > +
> > /*
> > -* get_any_page() and isolate_huge_page() takes a refcount each,
> > -* so need to drop one here.
> > +* If we succeed to isolate the page, we grabbed another refcount on
> > +* the page, so we can safely drop the one we got from
> > get_any_pages().
> > +* If we failed to isolate the page, it means that we cannot go
> > further
> > +
Re: [PATCH 9/8] mm: Account PMD tables like PTE tables
On Sat, Jun 27, 2020 at 07:46:42PM +0100, Matthew Wilcox wrote:
> We account the PTE level of the page tables to the process in order to
> make smarter OOM decisions and help diagnose why memory is fragmented.
> For these same reasons, we should account pages allocated for PMDs.
> With larger process address spaces and ASLR, the number of PMDs in use
> is higher than it used to be so the inaccuracy is starting to matter.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Reviewed-by: Mike Rapoport
> ---
> include/linux/mm.h | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index dc7b87310c10..b283e25fcffa 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2271,7 +2271,7 @@ static inline spinlock_t *pmd_lockptr(struct mm_struct
> *mm, pmd_t *pmd)
> return ptlock_ptr(pmd_to_page(pmd));
> }
>
> -static inline bool pgtable_pmd_page_ctor(struct page *page)
> +static inline bool pmd_ptlock_init(struct page *page)
> {
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> page->pmd_huge_pte = NULL;
> @@ -2279,7 +2279,7 @@ static inline bool pgtable_pmd_page_ctor(struct page
> *page)
> return ptlock_init(page);
> }
>
> -static inline void pgtable_pmd_page_dtor(struct page *page)
> +static inline void pmd_ptlock_free(struct page *page)
> {
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> VM_BUG_ON_PAGE(page->pmd_huge_pte, page);
> @@ -2296,8 +2296,8 @@ static inline spinlock_t *pmd_lockptr(struct mm_struct
> *mm, pmd_t *pmd)
> return >page_table_lock;
> }
>
> -static inline bool pgtable_pmd_page_ctor(struct page *page) { return true; }
> -static inline void pgtable_pmd_page_dtor(struct page *page) {}
> +static inline bool pmd_ptlock_init(struct page *page) { return true; }
> +static inline void pmd_ptlock_free(struct page *page) {}
>
> #define pmd_huge_pte(mm, pmd) ((mm)->pmd_huge_pte)
>
> @@ -2310,6 +2310,22 @@ static inline spinlock_t *pmd_lock(struct mm_struct
> *mm, pmd_t *pmd)
> return ptl;
> }
>
> +static inline bool pgtable_pmd_page_ctor(struct page *page)
> +{
> + if (!pmd_ptlock_init(page))
> + return false;
> + __SetPageTable(page);
> + inc_zone_page_state(page, NR_PAGETABLE);
> + return true;
> +}
> +
> +static inline void pgtable_pmd_page_dtor(struct page *page)
> +{
> + pmd_ptlock_free(page);
> + __ClearPageTable(page);
> + dec_zone_page_state(page, NR_PAGETABLE);
> +}
> +
> /*
> * No scalability reason to split PUD locks yet, but follow the same pattern
> * as the PMD locks to make it easier if we decide to. The VM should not be
> --
> 2.27.0
>
--
Sincerely yours,
Mike.
[PATCH] reiserfs: only call unlock_new_inode() if I_NEW
From: Eric Biggers unlock_new_inode() is only meant to be called after a new inode has already been inserted into the hash table. But reiserfs_new_inode() can call it even before it has inserted the inode, triggering the WARNING in unlock_new_inode(). Fix this by only calling unlock_new_inode() if the inode has the I_NEW flag set, indicating that it's in the table. This addresses the syzbot report "WARNING in unlock_new_inode" (https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7). Reported-by: syzbot+187510916eb6a1459...@syzkaller.appspotmail.com Signed-off-by: Eric Biggers --- fs/reiserfs/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c index 1509775da040..e3af44c61524 100644 --- a/fs/reiserfs/inode.c +++ b/fs/reiserfs/inode.c @@ -2163,7 +2163,8 @@ int reiserfs_new_inode(struct reiserfs_transaction_handle *th, out_inserted_sd: clear_nlink(inode); th->t_trans_id = 0; /* so the caller can't use this handle later */ - unlock_new_inode(inode); /* OK to do even if we hadn't locked it */ + if (inode->i_state & I_NEW) + unlock_new_inode(inode); iput(inode); return err; } -- 2.27.0
[PATCH] nilfs2: only call unlock_new_inode() if I_NEW
From: Eric Biggers unlock_new_inode() is only meant to be called after a new inode has already been inserted into the hash table. But nilfs_new_inode() can call it even before it has inserted the inode, triggering the WARNING in unlock_new_inode(). Fix this by only calling unlock_new_inode() if the inode has the I_NEW flag set, indicating that it's in the table. Signed-off-by: Eric Biggers --- fs/nilfs2/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c index 28009ec54420..3318dd1350b2 100644 --- a/fs/nilfs2/inode.c +++ b/fs/nilfs2/inode.c @@ -388,7 +388,8 @@ struct inode *nilfs_new_inode(struct inode *dir, umode_t mode) failed_after_creation: clear_nlink(inode); - unlock_new_inode(inode); + if (inode->i_state & I_NEW) + unlock_new_inode(inode); iput(inode); /* * raw_inode will be deleted through * nilfs_evict_inode(). -- 2.27.0
Re: [PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels
Hi Dmitry,
On Sun, Jun 28, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote:
> 27.06.2020 23:43, Laurent Pinchart пишет:
> > On Mon, Jun 22, 2020 at 01:27:42AM +0300, Dmitry Osipenko wrote:
> >> This patch adds missing BUS fields to the display panel descriptions of
> >> the panels which are found on NVIDIA Tegra devices:
> >>
> >> 1. AUO B101AW03
> >> 2. Chunghwa CLAA070WP03XG
> >> 3. Chunghwa CLAA101WA01A
> >> 4. Chunghwa CLAA101WB01
> >> 5. Innolux N156BGE L21
> >> 6. Samsung LTN101NT05
> >>
> >> Suggested-by: Laurent Pinchart
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/gpu/drm/panel/panel-simple.c | 12
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> >> b/drivers/gpu/drm/panel/panel-simple.c
> >> index 87edd2bdf09a..986df9937650 100644
> >> --- a/drivers/gpu/drm/panel/panel-simple.c
> >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> >> @@ -698,6 +698,8 @@ static const struct panel_desc auo_b101aw03 = {
> >>.width = 223,
> >>.height = 125,
> >>},
> >> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> >> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> >
> > Does DRM_BUS_FLAG_PIXDATA_DRIVE_* make sense for LVDS ?
>
> To be honest I don't know whether it make sense or not for LVDS. I saw
> that other LVDS panels in panel-simple.c use the PIXDATA flag and then
> looked at what timing diagrams in the datasheets show.
I think we should drop DRM_BUS_FLAG_PIXDATA_DRIVE_* for LVDS panels.
I'll submit a patch.
> > The rest looks good, except the Samsung panel for which I haven't been
> > able to locate a datasheet.
> >
> > Reviewed-by: Laurent Pinchart
>
> Thanks to you and Sam!
--
Regards,
Laurent Pinchart
Re: Passing NULL dev to dma_alloc_coherent() allowed or not?
You can't pass NULL. The synclink case is dead code as we stopped supporting non-PCI adapters a while ago. I had a patch to remove the !PCI code a while ago, but it seems like it never made it upstream. The staging code is, well .. staging code.
Re: [PATCH 4/8] asm-generic: pgalloc: provide generic pmd_alloc_one() and pmd_free_one()
On Sat, Jun 27, 2020 at 08:03:04PM +0100, Matthew Wilcox wrote: > On Sat, Jun 27, 2020 at 05:34:49PM +0300, Mike Rapoport wrote: > > More elaborate versions on arm64 and x86 account memory for the user page > > tables and call to pgtable_pmd_page_ctor() as the part of PMD page > > initialization. > > > > Move the arm64 version to include/asm-generic/pgalloc.h and use the generic > > version on several architectures. > > > > The pgtable_pmd_page_ctor() is a NOP when ARCH_ENABLE_SPLIT_PMD_PTLOCK is > > not enabled, so there is no functional change for most architectures except > > of the addition of __GFP_ACCOUNT for allocation of user page tables. > > Thanks for including this line; it reminded me that we're not setting > the PageTable flag on the page, nor accounting it to the zone page stats. > Hope you don't mind me tagging a patch to do that on as 9/8. > > We could also do with a pud_page_[cd]tor and maybe even p4d/pgd versions. > But that brings me to the next question -- could/should some of this > be moved over to asm-generic/pgalloc.h? The ctor/dtor aren't called > from anywhere else, and there's value to reducing the total amount of > code in mm.h, but then there's also value to keeping all the ifdef > ARCH_ENABLE_SPLIT_PMD_PTLOCK code together too. So I'm a bit torn. > What do you think? There are arhcitectures that don't use asm-generic/pgalloc.h but rather have their own, sometimes completely different, versoins of these funcitons. I've tried adding linux/pgalloc.h, but I've ended up with contradicting need to include asm/pgalloc.h before the generic code for some architecures or after the generic code for others :) I think let's leave it in mm.h for now, maybe after several more cleaups we could do better. -- Sincerely yours, Mike.
[PATCH] ext4: fix direct I/O read error
From: jiangying8582
Date: Wed, 24 Jun 2020 19:02:34 +0800
Subject: [PATCH] ext4: fix direct I/O read error
This patch is used to fix ext4 direct I/O read error when
the read size is not alignment with block size. Compare the
size between read offset with file size, if read offset is
greater than file size, then return 0.
Then, I will use a test to explain the error.
(1) Make the file that is not alignment wiht block size:
$dd if=/dev/zero of=./test.jar bs=1000 count=3
(2) I wrote a test script named "direct_io_read_file.c" s following:
#include
#include
#include
#include
#include
#include
#include
#define BUF_SIZE 1024
int main()
{
int fd;
int ret;
unsigned char *buf;
ret = posix_memalign((void **), 512, BUF_SIZE);
if (ret) {
perror("posix_memalign failed");
exit(1);
}
fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
if (fd < 0){
perror("open ./test.jar failed");
exit(1);
}
do {
ret = read(fd, buf, BUF_SIZE);
printf("ret=%d\n",ret);
if (ret < 0) {
perror("write test.jar failed");
}
} while (ret > 0);
free(buf);
close(fd);
}
(3) Compiling the script:
$gcc direct_io_read_file.c -D_GNU_SOURCE
(4) Exec the script:
$./a.out
The result is as following:
ret=1024
ret=1024
ret=952
ret=-1
write rts-segmenter-0.3.7.2.jar failed: Invalid argument
I have tested this script on XFS filesystem, XFS does not have
this problem, because XFS use iomap_dio_rw() to do direct I/O
read. And the comparing between read offset and file size is done
is iomap_dio_rw(), the code is as following:
if (pos < size) {
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
}
...
}
Only when "pos < size", direct I/O can be done, or 0 will be return.
I have tested my fix patch, it is up to the mustard of EINVAL in
man2(read) as following:
#include
ssize_t read(int fd, void *buf, size_t count);
EINVAL
fd is attached to an object which is unsuitable for reading;
or the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.
So I think this patch can be applied to fix ext4 direct I/O problem.
Why this problem can happen? I think
commit <9fe55eea7e4b> ("Fix race when checking i_size on direct i/o read")
caused.
However Ext4 introduces direct I/O read using iomap infrastructure
on kernel 5.5, the patch is commit
("ext4: introduce direct I/O read using iomap infrastructure"),
then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
I/O read. So this problem does not exist on kernel 5.5 for Ext4.
From above description, we can see this problem exists on all the kernel
versions between kernel 3.14 and kernel 5.4. Please apply this patch
on these kernel versions, or please use the method on kernel 5.5 to fix
this problem. Thanks.
Signed-off-by: jiangying8582
---
fs/ext4/inode.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 516faa2..d514ff5 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3821,6 +3821,12 @@ static ssize_t ext4_direct_IO_read(struct kiocb *iocb,
struct iov_iter *iter)
struct inode *inode = mapping->host;
size_t count = iov_iter_count(iter);
ssize_t ret;
+ loff_t offset = iocb->ki_pos;
+ loff_t size;
+
+ size = i_size_read(inode);
+ if (offset >= size)
+ return 0;
/*
* Shared inode_lock is enough for us - it protects against concurrent
--
1.8.3.1
[PATCH v2] serial: samsung: Re-factors UART IRQ resource for various Samsung SoC
In few older Samsung SoCs like s3c2410, s3c2412
and s3c2440, UART IP is having 2 interrupt lines.
However, in other SoCs like s3c6400, s5pv210,
exynos5433, and exynos4210 UART is having only 1
interrupt line. Due to this, "platform_get_irq(platdev, 1)"
call in the driver gives the following warning:
"IRQ index 1 not found" on recent platforms.
This patch re-factors the IRQ resources handling for
each platform and hence fixing the above warnings seen
on some platforms.
Signed-off-by: Tamseel Shams
---
Removed the RFC tag and using 'platform_get_irq_optional'
instead of 'platform_get_irq' as per comment received from
Robin Murphy.
drivers/tty/serial/samsung_tty.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 6ef614d8648c..60554f42e208 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -60,6 +60,7 @@ struct s3c24xx_uart_info {
char*name;
unsigned inttype;
unsigned intfifosize;
+ unsigned intirq_cnt;
unsigned long rx_fifomask;
unsigned long rx_fifoshift;
unsigned long rx_fifofull;
@@ -1908,10 +1909,13 @@ static int s3c24xx_serial_init_port(struct
s3c24xx_uart_port *ourport,
else {
port->irq = ret;
ourport->rx_irq = ret;
- ourport->tx_irq = ret + 1;
+ if (ourport->info->irq_cnt == 1)
+ ourport->tx_irq = ret;
+ else
+ ourport->tx_irq = ret + 1;
}
- ret = platform_get_irq(platdev, 1);
+ ret = platform_get_irq_optional(platdev, 1);
if (ret > 0)
ourport->tx_irq = ret;
/*
@@ -2387,6 +2391,7 @@ static struct s3c24xx_serial_drv_data
s3c2410_serial_drv_data = {
.name = "Samsung S3C2410 UART",
.type = PORT_S3C2410,
.fifosize = 16,
+ .irq_cnt= 2,
.rx_fifomask= S3C2410_UFSTAT_RXMASK,
.rx_fifoshift = S3C2410_UFSTAT_RXSHIFT,
.rx_fifofull= S3C2410_UFSTAT_RXFULL,
@@ -2414,6 +2419,7 @@ static struct s3c24xx_serial_drv_data
s3c2412_serial_drv_data = {
.name = "Samsung S3C2412 UART",
.type = PORT_S3C2412,
.fifosize = 64,
+ .irq_cnt= 2,
.has_divslot= 1,
.rx_fifomask= S3C2440_UFSTAT_RXMASK,
.rx_fifoshift = S3C2440_UFSTAT_RXSHIFT,
@@ -2443,6 +2449,7 @@ static struct s3c24xx_serial_drv_data
s3c2440_serial_drv_data = {
.name = "Samsung S3C2440 UART",
.type = PORT_S3C2440,
.fifosize = 64,
+ .irq_cnt= 2,
.has_divslot= 1,
.rx_fifomask= S3C2440_UFSTAT_RXMASK,
.rx_fifoshift = S3C2440_UFSTAT_RXSHIFT,
@@ -2471,6 +2478,7 @@ static struct s3c24xx_serial_drv_data
s3c6400_serial_drv_data = {
.name = "Samsung S3C6400 UART",
.type = PORT_S3C6400,
.fifosize = 64,
+ .irq_cnt= 1,
.has_divslot= 1,
.rx_fifomask= S3C2440_UFSTAT_RXMASK,
.rx_fifoshift = S3C2440_UFSTAT_RXSHIFT,
@@ -2498,6 +2506,7 @@ static struct s3c24xx_serial_drv_data
s5pv210_serial_drv_data = {
.info = &(struct s3c24xx_uart_info) {
.name = "Samsung S5PV210 UART",
.type = PORT_S3C6400,
+ .irq_cnt= 1,
.has_divslot= 1,
.rx_fifomask= S5PV210_UFSTAT_RXMASK,
.rx_fifoshift = S5PV210_UFSTAT_RXSHIFT,
@@ -2526,6 +2535,7 @@ static struct s3c24xx_serial_drv_data
s5pv210_serial_drv_data = {
.info = &(struct s3c24xx_uart_info) { \
.name = "Samsung Exynos UART",\
.type = PORT_S3C6400, \
+ .irq_cnt= 1,\
.has_divslot= 1,\
.rx_fifomask= S5PV210_UFSTAT_RXMASK,\
.rx_fifoshift = S5PV210_UFSTAT_RXSHIFT, \
--
2.17.1
Re: [RFC] stop using ->read and ->write for kernel access v2
On Sat, Jun 27, 2020 at 03:15:00PM -0700, Linus Torvalds wrote:
> > as part of removing set_fs entirely (for which I have a working
> > prototype), we need to stop calling ->read and ->write with kernel
> > pointers under set_fs.
> >
> > My previous "clean up kernel_{read,write} & friends v5" series, on which
> > this one builds, consolidate those calls into the __ḵernel_{read,write}
> > helpers. This series goes further and removes the option to call
> > ->read and ->write with kernel pointers entirely.
>
> Ack. I scanned through these and didn't find anything odd.
>
> Which either means that it's all good, or that my scanning was too
> limited. But this does feel like the right way to go about things.
Thanks. If we move forward with this I'd like to get it merge soon
so that we get an as long as possible exposure in linux-next to find
the occasional candidate that needs to be converted to the iter ops.
[PATCH] sparse: use static inline for __chk_{user,io}_ptr()
__chk_user_ptr() & __chk_io_ptr() are dummy extern functions which
only exist to enforce the typechecking of __user or __iomem pointers
in macros when using sparse.
This typechecking is done by inserting a call to these functions.
But the presence of these calls can inhibit some simplifications
and so influence the result of sparse's analysis of context/locking.
Fix this by changing these calls into static inline calls with
an empty body.
Signed-off-by: Luc Van Oostenryck
---
include/linux/compiler_types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index b67930216e45..a9b6699f3934 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -11,8 +11,8 @@
# define __iomem __attribute__((noderef, address_space(__iomem)))
# define __percpu __attribute__((noderef, address_space(__percpu)))
# define __rcu __attribute__((noderef, address_space(__rcu)))
-extern void __chk_user_ptr(const volatile void __user *);
-extern void __chk_io_ptr(const volatile void __iomem *);
+static inline void __chk_user_ptr(const volatile void __user *ptr) { }
+static inline void __chk_io_ptr(const volatile void __iomem *ptr) { }
/* context/locking */
# define __must_hold(x)__attribute__((context(x,1,1)))
# define __acquires(x) __attribute__((context(x,0,1)))
--
2.27.0
[tip:master] BUILD SUCCESS deda15a7ef44d5dab81aa6bf140a98feefef4e00
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: deda15a7ef44d5dab81aa6bf140a98feefef4e00 Merge branch 'linus' elapsed time: 724m configs tested: 111 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig powerpc mpc5200_defconfig m68kq40_defconfig arm tegra_defconfig mipsvocore2_defconfig arm simpad_defconfig arm cm_x300_defconfig sh microdev_defconfig m68k allmodconfig powerpc ppc64_defconfig m68k alldefconfig nios2 10m50_defconfig mips decstation_defconfig arm versatile_defconfig mips ath25_defconfig mipsnlm_xlp_defconfig sparcallyesconfig arm netwinder_defconfig mipsmaltaup_xpa_defconfig powerpcgamecube_defconfig powerpc pasemi_defconfig riscv allnoconfig h8300h8300h-sim_defconfig nds32 allnoconfig sparc64 allmodconfig h8300 h8s-sim_defconfig sh landisk_defconfig sh kfr2r09_defconfig mips maltasmvp_eva_defconfig sh apsh4a3a_defconfig openriscor1ksim_defconfig mips jazz_defconfig x86_64 alldefconfig arm s3c2410_defconfig powerpc mpc512x_defconfig openrisc simple_smp_defconfig sh cayman_defconfig i386 allyesconfig i386defconfig i386 debian-10.3 i386 allnoconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig umallnoconfig um defconfig um
Re: [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU
On Sat, Jun 27, 2020 at 08:01:17PM -0500, Rob Landley wrote: > On 6/26/20 3:07 AM, Christoph Hellwig wrote: > > The code handling non-coherent DMA depends on being able to remap code > > as non-cached. But that can't be done without an MMU, so using this > > option on NOMMU builds is broken. > > I'm working on a nommu j-core board that's doing DMA behind the OS's back at > the > moment, which I have a todo item to teach the kernel about. The DMA does not > go > through the cache, there's currently a cache flush before looking at the > result > instead. > > How should this be wired up after your patch? The problem with nommu and non-coherent dma is the dma_alloc_coherent calls. Most platforms with an mmu set a nocache bit through the page tables (including sh), but that option obviously doesn't exist for nommu. Some hardware has an uncached window where access is uncached automatically if access through specific kernel virtual addresses, for that the architecture needs to impement the arch_dma_set_uncached helper and select CONFIG_ARCH_HAS_DMA_SET_UNCACHED. If that also doesn't exist you'll need some sort of pool of always uncached memory (set by the firmware or early startup code). That currently doesn't exist in generic code, but we have a bunch of architectures implementing that in arch_dma_alloc. I plan to have a common implementation of the pool soon hopefully. Streaming DMA just works if you reuse the existing arch_sync_dma_for_device implementation.
Re: [PATCH v5 2/2] drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support
Hi Miquel,
On Thu, Jan 09, 2020 at 07:40:37PM +0100, Miquel Raynal wrote:
> Add support for the Satoz SAT050AT40H12R2 panel.
>
> Signed-off-by: Miquel Raynal
> ---
>
> Changes since v4:
> * None.
>
> Changes since v3:
> * Added connector type.
>
> Changes since v2:
> * Dropped two uneeded lines which would fail the build.
>
> Changes since v1:
> * Switched to display_timing's instead of display_mode.
>
> drivers/gpu/drm/panel/panel-simple.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index aaa08beac13c..1aa6622abc49 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2577,6 +2577,30 @@ static const struct panel_desc samsung_ltn140at29_301
> = {
> },
> };
>
> +static const struct display_timing satoz_sat050at40h12r2_timing = {
> + .pixelclock = {3330, 3330, 5000},
> + .hactive = {800, 800, 800},
> + .hfront_porch = {16, 210, 354},
> + .hback_porch = {46, 46, 46},
> + .hsync_len = {1, 1, 40},
> + .vactive = {480, 480, 480},
> + .vfront_porch = {7, 22, 147},
> + .vback_porch = {23, 23, 23},
> + .vsync_len = {1, 1, 20},
> +};
> +
> +static const struct panel_desc satoz_sat050at40h12r2 = {
> + .timings = _sat050at40h12r2_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 108,
> + .height = 65,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
I'm trying to fix inconsistencies in the panel-simple driver, and this
caught my eyes. MEDIA_BUS_FMT_RGB888_1X24 isn't a correct format for
LVDS panels. MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
should be used instead. As I couldn't find documentation for the panel,
I can't tell which format is correct. Could you please help ?
> +};
> +
> static const struct drm_display_mode sharp_ld_d5116z01b_mode = {
> .clock = 168480,
> .hdisplay = 1920,
> @@ -3377,6 +3401,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "samsung,ltn140at29-301",
> .data = _ltn140at29_301,
> + }, {
> + .compatible = "satoz,sat050at40h12r2",
> + .data = _sat050at40h12r2,
> }, {
> .compatible = "sharp,ld-d5116z01b",
> .data = _ld_d5116z01b,
--
Regards,
Laurent Pinchart
[PATCH v2] sched: fix build with GCC_PLUGIN_RANDSTRUCT
From: Mike Rapoport
Since the commit a148866489fb ("sched: Replace rq::wake_list")
task_struct and CSD_TYPE_TTWU objects can be on the same queue and this
requires that have layout similar enough.
This assumption is broken when CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled:
CHK include/generated/compile.h
CC kernel/smp.o
In file included from arch/x86/include/asm/atomic.h:5,
from include/linux/atomic.h:7,
from include/linux/llist.h:51,
from include/linux/irq_work.h:5,
from kernel/smp.c:10:
kernel/smp.c: In function ‘smp_init’:
include/linux/compiler.h:392:38: error: call to ‘__compiletime_assert_157’
declared with attribute error: BUILD_BUG_ON failed: offsetof(struct
task_struct, wake_entry_type) - offsetof(struct task_struct, wake_entry) !=
offsetof(struct __call_single_data, flags) - offsetof(struct
__call_single_data, llist)
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler.h:373:4: note: in definition of macro
‘__compiletime_assert’
373 |prefix ## suffix();\
|^~
include/linux/compiler.h:392:2: note: in expansion of macro
‘_compiletime_assert’
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~
kernel/smp.c:687:2: note: in expansion of macro ‘BUILD_BUG_ON’
687 | BUILD_BUG_ON(offsetof(struct task_struct, wake_entry_type) -
offsetof(struct task_struct, wake_entry) !=
| ^~~~
Wrap 'wake_entry' and 'wake_entry_type' fiels of task_struct in an
anonymous struct to keep their relative layout intact during
randomization.
Suggested-by: Steven Rostedt
Signed-off-by: Mike Rapoport
---
v2: use anonymous struct as Steven suggested.
include/linux/sched.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b62e6aaf28f0..7e30a09df616 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -654,8 +654,15 @@ struct task_struct {
unsigned intptrace;
#ifdef CONFIG_SMP
- struct llist_node wake_entry;
- unsigned intwake_entry_type;
+ /*
+* The layout of these fields must match the layout of CSD_TYPE_TTWU
+* so they can be on the same @call_single_queue
+*/
+ struct {
+ struct llist_node wake_entry;
+ unsigned intwake_entry_type;
+ };
+
int on_cpu;
#ifdef CONFIG_THREAD_INFO_IN_TASK
/* Current CPU: */
--
2.25.4
Re: [PATCH v2 2/5] drm: panel: Add Starry KR070PE2T
Hi Pascal,
On Fri, Mar 20, 2020 at 12:21:33PM +0100, Pascal Roeleven wrote:
> The KR070PE2T is a 7" panel with a resolution of 800x480.
>
> KR070PE2T is the marking present on the ribbon cable. As this panel is
> probably available under different brands, this marking will catch
> most devices.
>
> As I can't find a datasheet for this panel, the bus_flags are instead
> from trial-and-error. The flags seem to be common for these kind of
> panels as well.
>
> Signed-off-by: Pascal Roeleven
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac6..b3d257257 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2842,6 +2842,32 @@ static const struct panel_desc shelly_sca07010_bfn_lnn
> = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode starry_kr070pe2t_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 209,
> + .hsync_end = 800 + 209 + 1,
> + .htotal = 800 + 209 + 1 + 45,
> + .vdisplay = 480,
> + .vsync_start = 480 + 22,
> + .vsync_end = 480 + 22 + 1,
> + .vtotal = 480 + 22 + 1 + 22,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc starry_kr070pe2t = {
> + .modes = _kr070pe2t_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 152,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
I'm trying to fix inconsistencies in the panel-simple driver, and this
caught my eyes. MEDIA_BUS_FMT_RGB888_1X24 isn't a correct format for
LVDS panels. MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
should be used instead. As I couldn't find documentation for the panel,
I can't tell which format is correct. Could you please help ?
> +};
> +
> static const struct drm_display_mode starry_kr122ea0sra_mode = {
> .clock = 147000,
> .hdisplay = 1920,
> @@ -3474,6 +3500,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "shelly,sca07010-bfn-lnn",
> .data = _sca07010_bfn_lnn,
> + }, {
> + .compatible = "starry,kr070pe2t",
> + .data = _kr070pe2t,
> }, {
> .compatible = "starry,kr122ea0sra",
> .data = _kr122ea0sra,
--
Regards,
Laurent Pinchart
[PATCH v2] staging: rtl8188eu: remove unnecessary comments in hal8188e_phy_cfg.h
Remove unnecessary comments in hal8188e_phy_cfg.h to improve
readability and clear multiple blank lines checkpatch issues.
CHECK: Please don't use multiple blank lines
Signed-off-by: Michael Straube
---
v1 -> v2
Remove one more line as suggested by Dan Carpenter.
.../rtl8188eu/include/hal8188e_phy_cfg.h | 25 ---
1 file changed, 25 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/hal8188e_phy_cfg.h
b/drivers/staging/rtl8188eu/include/hal8188e_phy_cfg.h
index 0c5b2b0948f5..a1055ceb7206 100644
--- a/drivers/staging/rtl8188eu/include/hal8188e_phy_cfg.h
+++ b/drivers/staging/rtl8188eu/include/hal8188e_phy_cfg.h
@@ -7,8 +7,6 @@
#ifndef __INC_HAL8188EPHYCFG_H__
#define __INC_HAL8188EPHYCFG_H__
-
-/*--Define Parameters---*/
#define LOOP_LIMIT 5
#define MAX_STALL_TIME 50 /* us */
#define AntennaDiversityValue 0x80
@@ -17,11 +15,6 @@
#define MAX_AGGR_NUM 0x07
-
-/*--Define Parameters---*/
-
-
-/*--Define structure*/
enum sw_chnl_cmd_id {
CmdID_End,
CmdID_SetTxPowerLevel,
@@ -145,22 +138,6 @@ struct bb_reg_def {
*/
};
-/*--Define structure*/
-
-
-/*Export global variable*/
-/*Export global variable*/
-
-
-/*Export Marco Definition---*/
-/*Export Marco Definition---*/
-
-
-/*--Exported Function prototype-*/
-/* */
-/* BB and RF register read/write */
-/* */
-
/* Read initi reg value for tx power setting. */
void rtl8192c_PHY_GetHWRegOriginalValue(struct adapter *adapter);
@@ -181,8 +158,6 @@ void PHY_EnableHostClkReq(struct adapter *adapter);
bool SetAntennaConfig92C(struct adapter *adapter, u8 defaultant);
-/*--Exported Function prototype-*/
-
#define PHY_SetMacReg PHY_SetBBReg
#defineSIC_HW_SUPPORT 0
--
2.27.0
RE: [RFC PATCH 2/2] 9p: remove unused code in 9p
Hi Dominique, > -Original Message- > From: Dominique Martinet > Sent: Sunday, June 28, 2020 1:52 PM > To: Jianyong Wu > Cc: eri...@gmail.com; lu...@ionkov.net; v9fs- > develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org; Steve > Capper ; Kaly Xin ; Justin He > ; Wei Chen > Subject: Re: [RFC PATCH 2/2] 9p: remove unused code in 9p > > Jianyong Wu wrote on Sun, Jun 28, 2020: > > These code has been commented out since 2007 and lied in kernel since > > then. it's time to remove thest no used code. > > Good point, happy to take this - please resend without RFC separately (the > two commits aren't related) after fixing the commit message (lie/lay is > complicated and I'm not sure what should be used there but lied definitely > isn't correct, the qualification doesn't really matter though so probably > simpler to remove; and 'thest no used code' does not > parse) > Thanks, I think "lay" is right. I will fix it and resend. Thanks Jianyong > -- > Dominique IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH 1/2] thermal: qcom: tsens-v0_1: Add support for MSM8939
On Fri, May 01, 2020 at 10:33:10PM +0200, Konrad Dybcio wrote:
> Signed-off-by: Konrad Dybcio
For the record, I'm working my version of msm8939 tsens driver support,
and I would highlight the things that differ from this patch.
> ---
> drivers/thermal/qcom/tsens-v0_1.c | 142 +-
> drivers/thermal/qcom/tsens.c | 3 +
> drivers/thermal/qcom/tsens.h | 2 +-
> 3 files changed, 145 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-v0_1.c
> b/drivers/thermal/qcom/tsens-v0_1.c
> index 959a9371d205c..29b95886273b7 100644
> --- a/drivers/thermal/qcom/tsens-v0_1.c
> +++ b/drivers/thermal/qcom/tsens-v0_1.c
> @@ -48,6 +48,64 @@
> #define MSM8916_CAL_SEL_MASK 0xe000
> #define MSM8916_CAL_SEL_SHIFT29
>
> +/* eeprom layout data for 8939 */
> +#define MSM8939_BASE0_MASK 0x00ff
Tabs rather than spaces are used for indentation.
> +#define MSM8939_BASE1_MASK 0xff00
> +#define MSM8939_BASE0_SHIFT
This shift is 0.
> +#define MSM8939_BASE1_SHIFT 24
> +
> +#define MSM8939_S0_P1_MASK 0x01f8
> +#define MSM8939_S1_P1_MASK 0x001f8000
> +#define MSM8939_S2_P1_MASK_0_4 0xf800
> +#define MSM8939_S2_P1_MASK_5 0x0001
This mask define is contradicting to MSM8939_S2_P1_SHIFT_5, and needs to
be confirmed.
> +#define MSM8939_S3_P1_MASK 0x1f80
> +#define MSM8939_S4_P1_MASK 0x01f8
> +#define MSM8939_S5_P1_MASK 0x3f00
> +#define MSM8939_S6_P1_MASK 0x03f0
> +#define MSM8939_S7_P1_MASK 0x003f
> +#define MSM8939_S8_P1_MASK 0x0003f000
> +#define MSM8939_S9_P1_MASK 0x07e0
> +
> +#define MSM8939_S0_P2_MASK 0x7e00
> +#define MSM8939_S1_P2_MASK 0x07e0
> +#define MSM8939_S2_P2_MASK 0x007e
> +#define MSM8939_S3_P2_MASK 0x0007e000
> +#define MSM8939_S4_P2_MASK 0x7e00
> +#define MSM8939_S5_P2_MASK 0x000fc000
> +#define MSM8939_S6_P2_MASK 0xfc00
> +#define MSM8939_S7_P2_MASK 0x0fc0
> +#define MSM8939_S8_P2_MASK 0x00fc
> +#define MSM8939_S9_P2_MASK_0_4 0xf800
> +#define MSM8939_S9_P2_MASK_5 0x2000
It's contradicting to MSM8939_S9_P2_SHIFT_5, and needs to be confirmed.
> +
> +#define MSM8939_CAL_SEL_MASK 0xc000
Per downstream kernel, this mask is 0x7.
https://source.codeaurora.org/quic/la/kernel/msm-3.10/tree/drivers/thermal/msm8974-tsens.c?h=LA.BR.1.2.9.1_rb1.5#n370
> +#define MSM8939_CAL_SEL_SHIFT0
> +
> +
> +#define MSM8939_S0_P1_SHIFT3
> +#define MSM8939_S1_P1_SHIFT15
> +#define MSM8939_S2_P1_SHIFT_0_427
> +#define MSM8939_S2_P1_SHIFT_5 5
> +#define MSM8939_S3_P1_SHIFT7
> +#define MSM8939_S4_P1_SHIFT19
> +#define MSM8939_S5_P1_SHIFT8
> +#define MSM8939_S6_P1_SHIFT20
> +//yes, 7 is missing in downstream
The shift is not missing but just 0.
> +#define MSM8939_S8_P1_SHIFT12
> +#define MSM8939_S9_P1_SHIFT21
> +
> +#define MSM8939_S0_P2_SHIFT9
> +#define MSM8939_S1_P2_SHIFT21
> +#define MSM8939_S2_P2_SHIFT1
> +#define MSM8939_S3_P2_SHIFT13
> +#define MSM8939_S4_P2_SHIFT25
> +#define MSM8939_S5_P2_SHIFT14
> +#define MSM8939_S6_P2_SHIFT26
> +#define MSM8939_S7_P2_SHIFT6
> +#define MSM8939_S8_P2_SHIFT18
> +#define MSM8939_S9_P2_SHIFT_0_427
> +#define MSM8939_S9_P2_SHIFT_5 8
> +
> /* eeprom layout data for 8974 */
> #define BASE1_MASK 0xff
> #define S0_P1_MASK 0x3f00
> @@ -189,6 +247,73 @@ static int calibrate_8916(struct tsens_priv *priv)
> return 0;
> }
>
> +static int calibrate_8939(struct tsens_priv *priv)
> +{
> + int base0 = 0, base1 = 0, i;
> + u32 p1[11], p2[11];
MSM8939 gets 10 sensors, so the arrays should be [10].
> + int mode = 0;
> + u32 *qfprom_cdata, *qfprom_csel;
> +
> + qfprom_cdata = (u32 *)qfprom_read(priv->dev, "calib");
> + if (IS_ERR(qfprom_cdata))
> + return PTR_ERR(qfprom_cdata);
> +
> + qfprom_csel = (u32 *)qfprom_read(priv->dev, "calib_sel");
> + if (IS_ERR(qfprom_csel)) {
> + kfree(qfprom_cdata);
> + return PTR_ERR(qfprom_csel);
> + }
'calib_sel' is not separate from 'calib' bits on MSM8939. I chose to
read nvmem out as one go and map them to calibration data as below, per
downstream kernel.
/* Mapping between qfprom nvmem and calibration data */
cdata[0] = qfprom_cdata[12];
cdata[1] = qfprom_cdata[13];
cdata[2] = qfprom_cdata[0];
cdata[3] = qfprom_cdata[1];
cdata[4] = qfprom_cdata[22];
cdata[5] = qfprom_cdata[21];
mode = (cdata[0] & MSM8939_CAL_SEL_MASK) >> MSM8939_CAL_SEL_SHIFT;
https://source.codeaurora.org/quic/la/kernel/msm-3.10/tree/drivers/thermal/msm8974-tsens.c?h=LA.BR.1.2.9.1_rb1.5#n1286
We should support MSM8939 v3, as
Re: kbuild: separate kerneldoc warnings from compiler warnings
On Tue, Jun 23, 2020 at 11:27 AM Valdis Klētnieks wrote: > > On Mon, 22 Jun 2020 14:10:13 +0900, Masahiro Yamada said: > > > > This patch introduces a new build flag 'K=1' which controls whether > > > kerneldoc > > > warnings should be issued, separating them from the compiler warnings > > > that W= > > > controls. > > > I do not understand why this change is needed. > > > IIRC, our goal was to enable this check by default. > > https://patchwork.kernel.org/patch/10030521/ > > but there are so many warnings. > > So are we getting any closer to actually achieving that goal? > I've done a fair number of cleanup patches to make the kernel > safe(r) to build with W=1, but there's still quite the pile. > > And actually, if you want people to actually fix up the kerneldoc > issues, making it easier helps the chances of getting patches. If > somebody is in the mood to do kerneldoc clean-ups, having an easy > way to get just the kerneldoc messages rather than having to find > them mixed in with all the rest helps... > > So I ran some numbers... > > A plain "make" for an arm allmodconfig weighs in at 40,184 lines. > > Building with K=1 produces 10,358 additional lines of output - that's what > needs patching if you want the kerneldocs cleaned up. > > Building with W=1 (w/ this patch) adds 155,773 lines. Not A Typo. Of those, a > whole whopping 116,699 are complaints from DTS issues, and 39,074 for all > other > gcc warnings. (Though I have 2 patches that I'll send later that will knock > about 3,000 off the "all other gcc warnings" numbers). > > (And for completeness, building with C=1 for sparse adds 18,936 lines that say > 'CHECK', and 56,915 lines of sparse warnings) > > > Meanwhile, this is checked only when W= is given > > because 0-day bot tests with W=1 to > > block new kerneldoc warnings. > > Looking at the numbers, I really need to say "So how is that working out for > us, anyhow?" > > In particular, is it just flagging them, or do we have an actual procedure > that > stops patches from being accepted if they add new kerneldoc warnings? > > Another issue that needs to be considered is how high-quality a fix for a > kerneldoc warning is. Getting rid of a warning by adding a comment line that > says the 3rd parameter is a pointer to a 'struct wombat' does nobody any good > if looking at the formal parameter list clearly states that the third > parameter > is a 'struct wombat *foo'. Heck, I could probably create a Perl script that > automates that level of fixing. > > But making an *informative* comment requires doing a bunch of research so that > you understand why *this* struct wombat is the one we care about (and whether > we care *so* much that somebody better be holding a lock) > > > K=1 ? Do people need to learn this new switch? In my understanding, the intel 0-day bot tests with W=1, and sends an alert for new warnings. For example, https://lkml.org/lkml/2020/6/27/328 This is a warning with W=1 builds. So, new W=1 warnings will be blocked (unless people ignore the 0-day bot). Actually, the number of kernel-doc warnings are decreasing, but we still have so many. The progress depends on how much effort people will make. It does not make much difference if you separate out particular warnings into a different switch. One more thing, there is no need to add a new syntax to separate out kernel-doc warnings. W=1, W=2, W=3 can be combined. Adding a new warning group, W=d, is enough. The following should work. diff --git a/Makefile b/Makefile index ac2c61c37a73..1e8428ca8f10 100644 --- a/Makefile +++ b/Makefile @@ -1597,11 +1597,12 @@ help: @echo ' (sparse by default)' @echo ' make C=2 [targets] Force check of all c source with $$CHECK' @echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections' - @echo ' make W=n [targets] Enable extra build checks, n=1,2,3 where' + @echo ' make W=n [targets] Enable extra build checks, n=1,2,3,d where' @echo '1: warnings which may be relevant and do not occur too often' @echo '2: warnings which occur quite often but may still be relevant' @echo '3: more obscure warnings, can most likely be ignored' - @echo 'Multiple levels can be combined with W=12 or W=123' + @echo 'd: warnings from kernel-doc' + @echo 'Multiple levels can be combined with W=12 or W=123d' @echo '' @echo 'Execute "make" or "make all" to build all targets marked with [*] ' @echo 'For further info see the ./README file' diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 2e8810b7e5ed..1781b6ff16f0 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -100,7 +100,7 @@ else ifeq ($(KBUILD_CHECKSRC),2) cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< endif -ifneq
[PATCH] 9p: remove unused code in 9p
These codes have been commented out since 2007 and lay in kernel
since then. So, it's better to remove them.
Signed-off-by: Jianyong Wu
---
fs/9p/vfs_inode.c | 53 ---
1 file changed, 53 deletions(-)
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 010869389523..23aed9047efe 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -368,59 +368,6 @@ struct inode *v9fs_get_inode(struct super_block *sb,
umode_t mode, dev_t rdev)
return inode;
}
-/*
-static struct v9fs_fid*
-v9fs_clone_walk(struct v9fs_session_info *v9ses, u32 fid, struct dentry
*dentry)
-{
- int err;
- int nfid;
- struct v9fs_fid *ret;
- struct v9fs_fcall *fcall;
-
- nfid = v9fs_get_idpool(>fidpool);
- if (nfid < 0) {
- eprintk(KERN_WARNING, "no free fids available\n");
- return ERR_PTR(-ENOSPC);
- }
-
- err = v9fs_t_walk(v9ses, fid, nfid, (char *) dentry->d_name.name,
- );
-
- if (err < 0) {
- if (fcall && fcall->id == RWALK)
- goto clunk_fid;
-
- PRINT_FCALL_ERROR("walk error", fcall);
- v9fs_put_idpool(nfid, >fidpool);
- goto error;
- }
-
- kfree(fcall);
- fcall = NULL;
- ret = v9fs_fid_create(v9ses, nfid);
- if (!ret) {
- err = -ENOMEM;
- goto clunk_fid;
- }
-
- err = v9fs_fid_insert(ret, dentry);
- if (err < 0) {
- v9fs_fid_destroy(ret);
- goto clunk_fid;
- }
-
- return ret;
-
-clunk_fid:
- v9fs_t_clunk(v9ses, nfid);
-
-error:
- kfree(fcall);
- return ERR_PTR(err);
-}
-*/
-
-
/**
* v9fs_clear_inode - release an inode
* @inode: inode to release
--
2.17.1
[PATCH] mm/cma.c: use exact_nid true to fix possible per-numa cma leak
Calling cma_declare_contiguous_nid() with false exact_nid for per-numa
reservation can easily cause cma leak and various confusion.
For example, mm/hugetlb.c is trying to reserve per-numa cma for gigantic
pages. But it can easily leak cma and make users confused when system has
memoryless nodes.
In case the system has 4 numa nodes, and only numa node0 has memory.
if we set hugetlb_cma=4G in bootargs, mm/hugetlb.c will get 4 cma areas
for 4 different numa nodes. since exact_nid=false in current code, all
4 numa nodes will get cma successfully from node0, but hugetlb_cma[1 to 3]
will never be available to hugepage will only allocate memory from
hugetlb_cma[0].
In case the system has 4 numa nodes, both numa node0&2 has memory, other
nodes have no memory.
if we set hugetlb_cma=4G in bootargs, mm/hugetlb.c will get 4 cma areas
for 4 different numa nodes. since exact_nid=false in current code, all
4 numa nodes will get cma successfully from node0 or 2, but hugetlb_cma[1]
and [3] will never be available to hugepage as mm/hugetlb.c will only
allocate memory from hugetlb_cma[0] and hugetlb_cma[2].
This causes permanent leak of the cma areas which are supposed to be
used by memoryless node.
Of cource we can workaround the issue by letting mm/hugetlb.c scan all
cma areas in alloc_gigantic_page() even node_mask includes node0 only.
that means when node_mask includes node0 only, we can get page from
hugetlb_cma[1] to hugetlb_cma[3]. But this will cause kernel crash in
free_gigantic_page() while it wants to free page by:
cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order)
On the other hand, exact_nid=false won't consider numa distance, it
might be not that useful to leverage cma areas on remote nodes.
I feel it is much simpler to make exact_nid true to make everything
clear. After that, memoryless nodes won't be able to reserve per-numa
CMA from other nodes which have memory.
Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using
cma")
Cc: Jonathan Cameron
Cc: Aslan Bakirov
Cc: Roman Gushchin
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Andreas Schaufler
Cc: Mike Kravetz
Cc: Rik van Riel
Cc: Joonsoo Kim
Cc: Robin Murphy
Signed-off-by: Barry Song
---
mm/cma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index b24151fa2101..f472f398026f 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -338,13 +338,13 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
*/
if (base < highmem_start && limit > highmem_start) {
addr = memblock_alloc_range_nid(size, alignment,
- highmem_start, limit, nid, false);
+ highmem_start, limit, nid, true);
limit = highmem_start;
}
if (!addr) {
addr = memblock_alloc_range_nid(size, alignment, base,
- limit, nid, false);
+ limit, nid, true);
if (!addr) {
ret = -ENOMEM;
goto err;
--
2.27.0
Re: [PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels
Hi Laurent.
On Sun, Jun 28, 2020 at 10:07:45AM +0300, Laurent Pinchart wrote:
> Hi Dmitry,
>
> On Sun, Jun 28, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote:
> > 27.06.2020 23:43, Laurent Pinchart пишет:
> > > On Mon, Jun 22, 2020 at 01:27:42AM +0300, Dmitry Osipenko wrote:
> > >> This patch adds missing BUS fields to the display panel descriptions of
> > >> the panels which are found on NVIDIA Tegra devices:
> > >>
> > >> 1. AUO B101AW03
> > >> 2. Chunghwa CLAA070WP03XG
> > >> 3. Chunghwa CLAA101WA01A
> > >> 4. Chunghwa CLAA101WB01
> > >> 5. Innolux N156BGE L21
> > >> 6. Samsung LTN101NT05
> > >>
> > >> Suggested-by: Laurent Pinchart
> > >> Signed-off-by: Dmitry Osipenko
> > >> ---
> > >> drivers/gpu/drm/panel/panel-simple.c | 12
> > >> 1 file changed, 12 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > >> b/drivers/gpu/drm/panel/panel-simple.c
> > >> index 87edd2bdf09a..986df9937650 100644
> > >> --- a/drivers/gpu/drm/panel/panel-simple.c
> > >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> > >> @@ -698,6 +698,8 @@ static const struct panel_desc auo_b101aw03 = {
> > >> .width = 223,
> > >> .height = 125,
> > >> },
> > >> +.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> > >> +.bus_flags = DRM_BUS_FLAG_DE_HIGH |
> > >> DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> > >
> > > Does DRM_BUS_FLAG_PIXDATA_DRIVE_* make sense for LVDS ?
> >
> > To be honest I don't know whether it make sense or not for LVDS. I saw
> > that other LVDS panels in panel-simple.c use the PIXDATA flag and then
> > looked at what timing diagrams in the datasheets show.
>
> I think we should drop DRM_BUS_FLAG_PIXDATA_DRIVE_* for LVDS panels.
> I'll submit a patch.
We should also clean up all the DRM_BUS_FLAG_* one day.
No need for the deprecated values, so a few files needs an update.
And we could document what flags makes sense for LVDS etc.
On the TODO list...
Sam
>
> > > The rest looks good, except the Samsung panel for which I haven't been
> > > able to locate a datasheet.
> > >
> > > Reviewed-by: Laurent Pinchart
> >
> > Thanks to you and Sam!
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH] modpost: remove use of non-standard strsep() in HOSTCC code
On Sun, Jun 28, 2020 at 3:17 PM H. Nikolaus Schaller wrote:
>
> Hi,
>
> > Am 28.06.2020 um 07:51 schrieb Masahiro Yamada :
> >
> > On Thu, Jun 25, 2020 at 5:47 PM H. Nikolaus Schaller
> > wrote:
> >>
> >> strsep() is neither standard C nor POSIX and used outside
> >> the kernel code here. Using it here requires that the
> >> build host supports it out of the box which is e.g.
> >> not true for a Darwin build host and using a cross-compiler.
> >> This leads to:
> >>
> >> scripts/mod/modpost.c:145:2: warning: implicit declaration of function
> >> 'strsep' [-Wimplicit-function-declaration]
> >> return strsep(stringp, "\n");
> >> ^
> >>
> >> and a segfault when running MODPOST.
> >>
> >> See also: https://stackoverflow.com/a/7219504
> >>
> >> So let's add some lines of code separating the string at the
> >> next newline character instead of using strsep(). It does not
> >> hurt kernel size or speed since this code is run on the build host.
> >>
> >> Fixes: ac5100f5432967 ("modpost: add read_text_file() and get_line()
> >> helpers")
> >> Signed-off-by: H. Nikolaus Schaller
> >> ---
> >> scripts/mod/modpost.c | 7 ++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> >> index 6aea65c65745..8fe63989c6e1 100644
> >> --- a/scripts/mod/modpost.c
> >> +++ b/scripts/mod/modpost.c
> >> @@ -138,11 +138,16 @@ char *read_text_file(const char *filename)
> >>
> >> char *get_line(char **stringp)
> >> {
> >> + char *p;
> >>/* do not return the unwanted extra line at EOF */
> >>if (*stringp && **stringp == '\0')
> >
> > This check does not make sense anymore.
> >
> > Previously, get_line(NULL) returns NULL.
> >
> > With your patch, get_line(NULL) crashes
> > due to NULL-pointer dereference.
>
> Well, that is original code.
Sorry for confusion.
I meant this:
char *s = NULL;
get_line();
In the current code, get_line() returns NULL.
As 'man strsep' says this:
"If *stringp is NULL, the strsep() function returns NULL
and does nothing else."
With your patch, **stringp will cause
NULL-pointer dereference.
>
> I have only replaced the strsep() function.
> But yes, it looks to be better in addition to
> my patch.
>
> >
> >
> >
> >>return NULL;
> >>
> >> - return strsep(stringp, "\n");
> >> + p = *stringp;
> >> + while (**stringp != '\n')
> >> + (*stringp)++;
> >
> >
> > Is this a safe conversion?
> >
> > If the input file does not contain '\n' at all,
> > this while-loop continues running,
> > and results in the segmentation fault
> > due to buffer over-run.
>
> Ah, yes, you are right.
>
> We should use
>
> + while (**stringp && **stringp != '\n')
>
> >
> >
> >
> >> + *(*stringp)++ = '\0';
> >> + return p;
> >> }
> >
> >
> >
> > How about this?
> >
> > char *get_line(char **stringp)
> > {
> >char *orig = *stringp;
>
> ^^^ this still segfaults with get_line(NULL)
This is OK.
get_line(NULL) should crash because we never expect
the case ' stringp == NULL'.
We need to care about the case ' *stringp == NULL'.
In this case, get_line() should return NULL.
> >char *next;
> >
> >/* do not return the unwanted extra line at EOF */
> >if (!orig || *orig == '\0')
> >return NULL;
> >
> >next = strchr(orig, '\n');
> >if (next)
> >*next++ = '\0';
> >
> >*stringp = next;
>
> Yes, this code is easier to understand than my while loop.
> And strchr() is POSIX.
>
> So should I submit an updated patch or do you want to submit
> it (with a suggested-by: H. Nikolaus Schaller )
Please send a patch.
(Co-developed-by if you want to give some credit to me)
> BR and thanks,
> Nikolaus Schaller
>
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels
Hi Sam,
On Sun, Jun 28, 2020 at 09:52:45AM +0200, Sam Ravnborg wrote:
> On Sun, Jun 28, 2020 at 10:07:45AM +0300, Laurent Pinchart wrote:
> > On Sun, Jun 28, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote:
> >> 27.06.2020 23:43, Laurent Pinchart пишет:
> >>> On Mon, Jun 22, 2020 at 01:27:42AM +0300, Dmitry Osipenko wrote:
> This patch adds missing BUS fields to the display panel descriptions of
> the panels which are found on NVIDIA Tegra devices:
>
> 1. AUO B101AW03
> 2. Chunghwa CLAA070WP03XG
> 3. Chunghwa CLAA101WA01A
> 4. Chunghwa CLAA101WB01
> 5. Innolux N156BGE L21
> 6. Samsung LTN101NT05
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/panel/panel-simple.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 87edd2bdf09a..986df9937650 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -698,6 +698,8 @@ static const struct panel_desc auo_b101aw03 = {
> .width = 223,
> .height = 125,
> },
> +.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> +.bus_flags = DRM_BUS_FLAG_DE_HIGH |
> DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> >>>
> >>> Does DRM_BUS_FLAG_PIXDATA_DRIVE_* make sense for LVDS ?
> >>
> >> To be honest I don't know whether it make sense or not for LVDS. I saw
> >> that other LVDS panels in panel-simple.c use the PIXDATA flag and then
> >> looked at what timing diagrams in the datasheets show.
> >
> > I think we should drop DRM_BUS_FLAG_PIXDATA_DRIVE_* for LVDS panels.
> > I'll submit a patch.
>
> We should also clean up all the DRM_BUS_FLAG_* one day.
> No need for the deprecated values, so a few files needs an update.
> And we could document what flags makes sense for LVDS etc.
Where would you add that documentation ? The hardest part is to find a
place that will be noticed by developers :-)
I've just submitted a patch that adds a WARN_ON to catch similar issues
in the panel-simple driver. It's not ideal as we really shouldn't have
such code in the kernel, this is something that should be caught as part
of the integration process.
> On the TODO list...
>
> >>> The rest looks good, except the Samsung panel for which I haven't been
> >>> able to locate a datasheet.
> >>>
> >>> Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] thermal: qcom: tsens-v0_1: Add support for MSM8939
Hi Shawn, Thanks for your review. >For the record, I'm working my version of msm8939 tsens driver support, >and I would highlight the things that differ from this patch. I would be absolutely happy if you superseded that patch with your one, as I'm currently working on sdm630. Otherwise, thanks for pointing out the stuff I got wrong in the first place. Regards Konrad
Re: [RFC PATCH 04/10] mfd: Add base driver for Netronix embedded controller
On Mon, Jun 22, 2020 at 11:55:44AM +0100, Lee Jones wrote:
> On Sun, 21 Jun 2020, Jonathan Neuschäfer wrote:
>
> Description of the device here please.
>
> > Third-party hardware documentation is available at
>
> '\n'
>
> > https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
>
> Indent this with a couple of spaces.
>
[...]
> > + help
> > + Say yes here if you want to support the embedded controller of
> > + certain e-book readers designed by the ODM Netronix.
>
> s/of certain/found in certain/.
[...]
> > +++ b/drivers/mfd/ntxec.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright 2020 Jonathan Neuschäfer
> > +//
> > +// MFD driver for the usually MSP430-based embedded controller used in
> > certain
> > +// Netronix ebook reader board designs
>
> Only the SPDX line should contain C++ style comments.
>
> Description at the top, copyright after.
>
> An "MFD driver" isn't really a thing. Please describe the device.
[...]
> > +#include
> > +
> > +
>
> No need for double line spacing.
Alright, I'll fix these.
> > +#define NTXEC_VERSION 0x00
> > +#define NTXEC_POWEROFF 0x50
> > +#define NTXEC_POWERKEEP0x70
> > +#define NTXEC_RESET0x90
>
> Are these registers? Might be worth pre/post-fixing with _REG.
Yes, good idea.
>
> > +/* Register access */
> > +
> > +int ntxec_read16(struct ntxec *ec, u8 addr)
> > +{
> > + u8 request[1] = { addr };
> > + u8 response[2];
> > + int res;
> > +
> > + struct i2c_msg msgs[] = {
> > + {
> > + .addr = ec->client->addr,
> > + .flags = ec->client->flags,
> > + .len = sizeof(request),
> > + .buf = request
> > + }, {
> > + .addr = ec->client->addr,
> > + .flags = ec->client->flags | I2C_M_RD,
> > + .len = sizeof(response),
> > + .buf = response
> > + }
> > + };
> > +
> > + res = i2c_transfer(ec->client->adapter, msgs, ARRAY_SIZE(msgs));
> > + if (res < 0)
> > + return res;
> > + if (res != ARRAY_SIZE(msgs))
> > + return -EIO;
> > +
> > + return get_unaligned_be16(response);
> > +}
> > +EXPORT_SYMBOL(ntxec_read16);
> > +
> > +int ntxec_write16(struct ntxec *ec, u8 addr, u16 value)
> > +{
> > + u8 request[3] = { addr, };
> > + int res;
> > +
> > + put_unaligned_be16(value, request + 1);
> > +
> > + res = i2c_transfer_buffer_flags(ec->client, request, sizeof(request),
> > + ec->client->flags);
> > + if (res < 0)
> > + return res;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(ntxec_write16);
> > +
> > +int ntxec_read8(struct ntxec *ec, u8 addr)
> > +{
> > + int res = ntxec_read16(ec, addr);
> > +
> > + if (res < 0)
> > + return res;
> > +
> > + return (res >> 8) & 0xff;
> > +}
> > +EXPORT_SYMBOL(ntxec_read8);
> > +
> > +int ntxec_write8(struct ntxec *ec, u8 addr, u8 value)
> > +{
> > + return ntxec_write16(ec, addr, value << 8);
> > +}
> > +EXPORT_SYMBOL(ntxec_write8);
>
> Why are you hand-rolling your own accessors?
There are registers which only require one byte of data and others which
require two. This didn't quite seem to fit into the regmap API.
It is possible to always use 16-bit accessors directly but that would
push shifts into call sites that only use 8 bits.
(If the 16 bits are interpreted as big endian)
I'm not sure what's ideal here.
> > +/* Reboot/poweroff handling */
>
> These comments seem to be stating the obvious.
>
> Please remove them.
Ok.
> > + ntxec_write8(poweroff_restart_instance, NTXEC_POWEROFF, 0x01);
>
> All magic numbers should be defined?
Alright, I'll move them to the register definitions.
> > + msleep(5000);
>
> Why 5000?
The idea was to avoid returning from the poweroff handler by allowing
enough time until the power is actually off. However:
- I just tested it and the board I have turns off about 80ms after the
I2C command.
- I'm not sure if returning from the poweroff handler is actually bad.
It does seem to be wrong, because I get a lockdep report when I
remove the msleep and the kernel reaches do_exit in the reboot
syscall handler:
Requesting system poweroff
[ 14.465312] cfg80211: failed to load regulatory.db
[ 14.471171] imx-sdma 63fb.sdma: external firmware not found,
using ROM firmware
[ 14.541097] reboot: Power down
[ 14.547296]
[ 14.548840]
[ 14.553477] WARNING: init/156 still has locks held!
[ 14.558521] 5.8.0-rc1-00011-g65740c2d29bee-dirty #329 Not tainted
[ 14.564647]
[ 14.569399] 1 lock held by init/156:
[ 14.573004] #0: c17278a8 (system_transition_mutex){+.+.}-{3:3}, at:
__do_sys_reboot+0x13c/0x1fc
drivers/dma/sun6i-dma.c:244:45: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 916a3b0fc1206f7e7ae8d00a21a3114b1dc67794
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to
define address spaces
date: 10 days ago
config: arm64-randconfig-s032-20200628 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/dma/sun6i-dma.c:244:45: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile *x @@ got
>> void [noderef] __iomem *base @@
drivers/dma/sun6i-dma.c:244:45: sparse: expected void const volatile *x
drivers/dma/sun6i-dma.c:244:45: sparse: got void [noderef] __iomem *base
--
>> sound/soc/mediatek/common/mtk-afe-fe-dai.c:142:9: sparse: sparse: incorrect
>> type in argument 1 (different address spaces) @@ expected void volatile
>> [noderef] __iomem * @@ got unsigned char *dma_area @@
>> sound/soc/mediatek/common/mtk-afe-fe-dai.c:142:9: sparse: expected void
>> volatile [noderef] __iomem *
sound/soc/mediatek/common/mtk-afe-fe-dai.c:142:9: sparse: got unsigned
char *dma_area
--
>> sound/soc/mediatek/common/mtk-btcvsd.c:1365:30: sparse: sparse: incorrect
>> type in assignment (different address spaces) @@ expected unsigned int
>> [usertype] *bt_reg_pkt_r @@ got void [noderef] __iomem * @@
sound/soc/mediatek/common/mtk-btcvsd.c:1365:30: sparse: expected
unsigned int [usertype] *bt_reg_pkt_r
>> sound/soc/mediatek/common/mtk-btcvsd.c:1365:30: sparse: got void
>> [noderef] __iomem *
>> sound/soc/mediatek/common/mtk-btcvsd.c:1367:30: sparse: sparse: incorrect
>> type in assignment (different address spaces) @@ expected unsigned int
>> [usertype] *bt_reg_pkt_w @@ got void [noderef] __iomem * @@
sound/soc/mediatek/common/mtk-btcvsd.c:1367:30: sparse: expected
unsigned int [usertype] *bt_reg_pkt_w
sound/soc/mediatek/common/mtk-btcvsd.c:1367:30: sparse: got void
[noderef] __iomem *
>> sound/soc/mediatek/common/mtk-btcvsd.c:1369:28: sparse: sparse: incorrect
>> type in assignment (different address spaces) @@ expected unsigned int
>> [usertype] *bt_reg_ctl @@ got void [noderef] __iomem * @@
sound/soc/mediatek/common/mtk-btcvsd.c:1369:28: sparse: expected
unsigned int [usertype] *bt_reg_ctl
sound/soc/mediatek/common/mtk-btcvsd.c:1369:28: sparse: got void
[noderef] __iomem *
--
>> drivers/mmc/host/meson-gx-mmc.c:1175:34: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@ expected void *bounce_buf @@
>> got void [noderef] __iomem * @@
drivers/mmc/host/meson-gx-mmc.c:1175:34: sparse: expected void
*bounce_buf
>> drivers/mmc/host/meson-gx-mmc.c:1175:34: sparse: got void [noderef]
>> __iomem *
vim +244 drivers/dma/sun6i-dma.c
555859308723d8 Maxime Ripard 2014-07-17 240
555859308723d8 Maxime Ripard 2014-07-17 241 static inline void
sun6i_dma_dump_chan_regs(struct sun6i_dma_dev *sdev,
555859308723d8 Maxime Ripard 2014-07-17 242
struct sun6i_pchan *pchan)
555859308723d8 Maxime Ripard 2014-07-17 243 {
42c0d54e623695 Vinod Koul2014-07-28 @244phys_addr_t reg =
virt_to_phys(pchan->base);
555859308723d8 Maxime Ripard 2014-07-17 245
555859308723d8 Maxime Ripard 2014-07-17 246dev_dbg(sdev->slave.dev, "Chan
%d reg: %pa\n"
555859308723d8 Maxime Ripard 2014-07-17 247"\t___en(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 248"\tpause(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 249"\tstart(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 250"\t__cfg(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 251"\t__src(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 252"\t__dst(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 253"\tcount(%04x):
\t0x%08x\n"
555859308723d8 Maxime Ripard 2014-07-17 254"\t_para(%04x):
\t0x%08x\n\n",
555859308723d8 Maxime Ripard 2014-07-17 255pchan->idx, ,
555859308723d8 Maxime Ripard 2014-07-17 256DMA_CHAN_ENABLE,
555859308723d8 Maxime Ripard 2014-07-17 257readl(pchan->base +
DMA_CHAN_ENABLE),
5558593087
Re: [PATCH] modpost: remove use of non-standard strsep() in HOSTCC code
> Am 28.06.2020 um 09:52 schrieb Masahiro Yamada :
>
> On Sun, Jun 28, 2020 at 3:17 PM H. Nikolaus Schaller
> wrote:
>>
>> Hi,
>>
>>> Am 28.06.2020 um 07:51 schrieb Masahiro Yamada :
>>>
>>> On Thu, Jun 25, 2020 at 5:47 PM H. Nikolaus Schaller
>>> wrote:
strsep() is neither standard C nor POSIX and used outside
the kernel code here. Using it here requires that the
build host supports it out of the box which is e.g.
not true for a Darwin build host and using a cross-compiler.
This leads to:
scripts/mod/modpost.c:145:2: warning: implicit declaration of function
'strsep' [-Wimplicit-function-declaration]
return strsep(stringp, "\n");
^
and a segfault when running MODPOST.
See also: https://stackoverflow.com/a/7219504
So let's add some lines of code separating the string at the
next newline character instead of using strsep(). It does not
hurt kernel size or speed since this code is run on the build host.
Fixes: ac5100f5432967 ("modpost: add read_text_file() and get_line()
helpers")
Signed-off-by: H. Nikolaus Schaller
---
scripts/mod/modpost.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 6aea65c65745..8fe63989c6e1 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -138,11 +138,16 @@ char *read_text_file(const char *filename)
char *get_line(char **stringp)
{
+ char *p;
/* do not return the unwanted extra line at EOF */
if (*stringp && **stringp == '\0')
>>>
>>> This check does not make sense anymore.
>>>
>>> Previously, get_line(NULL) returns NULL.
>>>
>>> With your patch, get_line(NULL) crashes
>>> due to NULL-pointer dereference.
>>
>> Well, that is original code.
>
>
> Sorry for confusion.
>
> I meant this:
>
> char *s = NULL;
> get_line();
>
>
> In the current code, get_line() returns NULL.
> As 'man strsep' says this:
> "If *stringp is NULL, the strsep() function returns NULL
> and does nothing else."
>
> With your patch, **stringp will cause
> NULL-pointer dereference.
Ah, now I see. strsep() has a special case that is not covered
by my patch.
On the other hand, get_line() is only called as get_line() and
pos = buf can not be NULL because that is checked before in read_dump().
This is why I did not observe a segfault.
But it is wise to make get_line() it more robust than needed. We do
never know who will copy this code fragment... And I am tempted to
handle the get_line(NULL) case as well.
>> I have only replaced the strsep() function.
>> But yes, it looks to be better in addition to
>> my patch.
>>
>>>
>>>
>>>
return NULL;
- return strsep(stringp, "\n");
+ p = *stringp;
+ while (**stringp != '\n')
+ (*stringp)++;
>>>
>>>
>>> Is this a safe conversion?
>>>
>>> If the input file does not contain '\n' at all,
>>> this while-loop continues running,
>>> and results in the segmentation fault
>>> due to buffer over-run.
>>
>> Ah, yes, you are right.
>>
>> We should use
>>
>> + while (**stringp && **stringp != '\n')
>>
>>>
>>>
>>>
+ *(*stringp)++ = '\0';
+ return p;
}
>>>
>>>
>>>
>>> How about this?
>>>
>>> char *get_line(char **stringp)
>>> {
>>> char *orig = *stringp;
>>
>> ^^^ this still segfaults with get_line(NULL)
>
>
> This is OK.
>
> get_line(NULL) should crash because we never expect
> the case ' stringp == NULL'.
>
> We need to care about the case ' *stringp == NULL'.
> In this case, get_line() should return NULL.
>
>
>
>
>>> char *next;
>>>
>>> /* do not return the unwanted extra line at EOF */
>>> if (!orig || *orig == '\0')
>>> return NULL;
>>>
>>> next = strchr(orig, '\n');
>>> if (next)
>>> *next++ = '\0';
>>>
>>> *stringp = next;
>>
>> Yes, this code is easier to understand than my while loop.
>> And strchr() is POSIX.
>>
>> So should I submit an updated patch or do you want to submit
>> it (with a suggested-by: H. Nikolaus Schaller )
>
> Please send a patch.
> (Co-developed-by if you want to give some credit to me)
Yes, I will do in the next days.
BR and thanks,
Nikolaus Schaller
Re: [RFC PATCH 04/10] mfd: Add base driver for Netronix embedded controller
On Sat, Jun 27, 2020 at 10:17:38AM +0200, Andreas Kemnade wrote:
> On Sun, 21 Jun 2020 00:42:15 +0200
> Jonathan Neuschäfer wrote:
>
> > Third-party hardware documentation is available at
> > https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
> >
> > The EC supports interrupts, but the driver doesn't make use of them so
> > far.
> >
> > Known problems:
> > - The reboot handler is installed in such a way that it directly calls
> > into the i2c subsystem to send the reboot command to the EC. This
> > means that the reboot handler may sleep, which is not allowed.
> >
> see
> https://patchwork.ozlabs.org/project/linux-i2c/patch/20190415213432.8972-3-cont...@stefanchrist.eu/
>
> for a fix of such problems.
So far, regmap isn't involved here, but I'll remember it when I switch
to regmap.
Between when I first wrote this driver and now, the I2C has added
support for transfers in atomic contexts very late in the system's life
(exactly what happens when you reset a system via PMIC/EC), so this
problem seems to be gone from my driver, for now.
(See commit 63b96983a5ddf ("i2c: core: introduce callbacks for atomic
transfers"))
[...]
> > +int ntxec_write8(struct ntxec *ec, u8 addr, u8 value)
> > +{
> > + return ntxec_write16(ec, addr, value << 8);
> > +}
> > +EXPORT_SYMBOL(ntxec_write8);
> > +
>
> do we really need both 16bit and 8bit accessors?
No, the hardware/firmware doesn't care.
> If not, then simply use regmap_i2c_init and set val_bits accordingly.
> Maybe just doing the << 8 in the constants?
Thanks, I'll try this approach.
The values are not always constants, for example in the PWM driver:
res |= ntxec_write8(pwm->ec, NTXEC_PERIOD_HIGH, period >> 8);
res |= ntxec_write8(pwm->ec, NTXEC_PERIOD_LOW, period);
res |= ntxec_write8(pwm->ec, NTXEC_DUTY_HIGH, duty >> 8);
res |= ntxec_write8(pwm->ec, NTXEC_DUTY_LOW, duty);
Jonathan
signature.asc
Description: PGP signature
[PATCH v9 0/5] support reserving crashkernel above 4G on arm64 kdump
This patch series enable reserving crashkernel above 4G in arm64.
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are required, crash dump kernel
will boot failure because there is no low memory available for allocation.
3. commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32") broken
the arm64 kdump. 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.
To solve these issues, introduce crashkernel=X,low to reserve specified
size low memory.
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.
When crashkernel is reserved above 4G in memory and crashkernel=X,low
is specified simultaneously, kernel should reserve specified size low memory
for crash dump kernel devices. So there may be two crash kernel regions, one
is below 4G, the other is above 4G.
In order to distinct from the high region and make no effect to the use of
kexec-tools, rename the low region as "Crash kernel (low)", and pass the
low region by reusing DT property "linux,usable-memory-range". We made the low
memory region as the last range of "linux,usable-memory-range" to keep
compatibility with existing user-space and older kdump kernels.
Besides, we need to modify kexec-tools:
arm64: support more than one crash kernel regions(see [1])
Another update is document about DT property 'linux,usable-memory-range':
schemas: update 'linux,usable-memory-range' node schema(see [2])
The previous changes and discussions can be retrieved from:
Changes since [v8]
- Reuse DT property "linux,usable-memory-range".
Suggested by Rob, reuse DT property "linux,usable-memory-range" to pass the low
memory region.
- Fix kdump broken with ZONE_DMA reintroduced.
- Update chosen schema.
Changes since [v7]
- Move x86 CRASH_ALIGN to 2M
Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
- Update Documentation/devicetree/bindings/chosen.txt.
Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt
suggested by Arnd.
- Add Tested-by from Jhon and pk.
Changes since [v6]
- Fix build errors reported by kbuild test robot.
Changes since [v5]
- Move reserve_crashkernel_low() into kernel/crash_core.c.
- Delete crashkernel=X,high.
- Modify crashkernel=X,low.
If crashkernel=X,low is specified simultaneously, reserve spcified size low
memory for crash kdump kernel devices firstly and then reserve memory above 4G.
In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
pass to crash dump kernel by DT property "linux,low-memory-range".
- Update Documentation/admin-guide/kdump/kdump.rst.
Changes since [v4]
- Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
Changes since [v3]
- Add memblock_cap_memory_ranges back for multiple ranges.
- Fix some compiling warnings.
Changes since [v2]
- Split patch "arm64: kdump: support reserving crashkernel above 4G" as
two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
patch.
Changes since [v1]:
- Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
- Remove memblock_cap_memory_ranges() i added in v1 and implement that
in fdt_enforce_memory_region().
There are at most two crash kernel regions, for two crash kernel regions
case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
and then remove the memory range in the middle.
[1]: http://lists.infradead.org/pipermail/kexec/2020-June/020737.html
[2]: https://github.com/robherring/dt-schema/pull/19
[v1]: https://lkml.org/lkml/2019/4/2/1174
[v2]: https://lkml.org/lkml/2019/4/9/86
[v3]: https://lkml.org/lkml/2019/4/9/306
[v4]: https://lkml.org/lkml/2019/4/15/273
[v5]: https://lkml.org/lkml/2019/5/6/1360
[v6]: https://lkml.org/lkml/2019/8/30/142
[v7]: https://lkml.org/lkml/2019/12/23/411
[v8]: https://lkml.org/lkml/2020/5/21/213
Chen Zhou (5):
x86: kdump: move reserve_crashkernel_low() into crash_core.c
arm64: kdump: reserve crashkenel above 4G for crash dump kernel
arm64: kdump: add memory for devices by DT property
linux,usable-memory-range
arm64: kdump: fix kdump broken with ZONE_DMA reintroduced
kdump: update Documentation about crashkernel on arm64
Documentation/admin-guide/kdump/kdump.rst | 13 ++-
.../admin-guide/kernel-parameters.txt | 17 +++-
arch/arm64/kernel/setup.c | 8 +-
arch/arm64/mm/init.c | 74 ---
arch/x86/kernel/setup.c | 66 ++
include/linux/crash_core.h| 3 +
include/linux/kexec.h | 2 -
[PATCH v9 3/5] arm64: kdump: add memory for devices by DT property linux,usable-memory-range
If we want to reserve crashkernel above 4G, we could use parameters
"crashkernel=X crashkernel=Y,low", in this case, specified size low
memory is reserved for crash dump kernel devices and never mapped by
the first kernel. This memory range is advertised to crash dump kernel
via DT property under /chosen,
linux,usable-memory-range =
We reused the DT property linux,usable-memory-range and made the low
memory region as the second range "BASE2 SIZE2", which keeps compatibility
with existing user-space and older kdump kernels.
Crash dump kernel reads this property at boot time and call memblock_add()
to add the low memory region after memblock_cap_memory_range() has been
called.
Signed-off-by: Chen Zhou
Tested-by: John Donnelly
Tested-by: Prabhakar Kushwaha
---
arch/arm64/mm/init.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index ce7ced85f5fb..f5b31e8f1f34 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -69,6 +69,15 @@ EXPORT_SYMBOL(vmemmap);
phys_addr_t arm64_dma_phys_limit __ro_after_init;
static phys_addr_t arm64_dma32_phys_limit __ro_after_init;
+/*
+ * The main usage of linux,usable-memory-range is for crash dump kernel.
+ * Originally, the number of usable-memory regions is one. Now crash dump
+ * kernel support at most two regions, low region and high region.
+ * To make compatibility with existing user-space and older kdump, the low
+ * region is always the last range of linux,usable-memory-range if exist.
+ */
+#define MAX_USABLE_RANGES 2
+
#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
@@ -272,9 +281,9 @@ early_param("mem", early_mem);
static int __init early_init_dt_scan_usablemem(unsigned long node,
const char *uname, int depth, void *data)
{
- struct memblock_region *usablemem = data;
- const __be32 *reg;
- int len;
+ struct memblock_region *usable_rgns = data;
+ const __be32 *reg, *endp;
+ int len, nr = 0;
if (depth != 1 || strcmp(uname, "chosen") != 0)
return 0;
@@ -283,22 +292,36 @@ static int __init early_init_dt_scan_usablemem(unsigned
long node,
if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
return 1;
- usablemem->base = dt_mem_next_cell(dt_root_addr_cells, );
- usablemem->size = dt_mem_next_cell(dt_root_size_cells, );
+ endp = reg + (len / sizeof(__be32));
+ while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+ usable_rgns[nr].base = dt_mem_next_cell(dt_root_addr_cells,
);
+ usable_rgns[nr].size = dt_mem_next_cell(dt_root_size_cells,
);
+
+ if (++nr >= MAX_USABLE_RANGES)
+ break;
+ }
return 1;
}
static void __init fdt_enforce_memory_region(void)
{
- struct memblock_region reg = {
- .size = 0,
+ struct memblock_region usable_rgns[MAX_USABLE_RANGES] = {
+ { .size = 0 },
+ { .size = 0 }
};
- of_scan_flat_dt(early_init_dt_scan_usablemem, );
+ of_scan_flat_dt(early_init_dt_scan_usablemem, _rgns);
- if (reg.size)
- memblock_cap_memory_range(reg.base, reg.size);
+ /*
+* The first range of usable-memory regions is for crash dump
+* kernel with only one region or for high region with two regions,
+* the second range is dedicated for low region if exist.
+*/
+ if (usable_rgns[0].size)
+ memblock_cap_memory_range(usable_rgns[0].base,
usable_rgns[0].size);
+ if (usable_rgns[1].size)
+ memblock_add(usable_rgns[1].base, usable_rgns[1].size);
}
void __init arm64_memblock_init(void)
--
2.20.1
[PATCH v9 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=X,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.
Suggested by James, just introduced crashkernel=X,low to arm64. As memtioned
above, if crashkernel=X,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G, which is much simpler.
Signed-off-by: Chen Zhou
Tested-by: John Donnelly
Tested-by: Prabhakar Kushwaha
---
arch/arm64/kernel/setup.c | 8 +++-
arch/arm64/mm/init.c | 31 +--
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 93b3844cf442..4dc51a2ac012 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -238,7 +238,13 @@ static void __init request_standard_resources(void)
kernel_data.end <= res->end)
request_resource(res, _data);
#ifdef CONFIG_KEXEC_CORE
- /* Userspace will find "Crash kernel" region in /proc/iomem. */
+ /*
+* Userspace will find "Crash kernel" region in /proc/iomem.
+* Note: the low region is renamed as Crash kernel (low).
+*/
+ if (crashk_low_res.end && crashk_low_res.start >= res->start &&
+ crashk_low_res.end <= res->end)
+ request_resource(res, _low_res);
if (crashk_res.end && crashk_res.start >= res->start &&
crashk_res.end <= res->end)
request_resource(res, _res);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 1e93cfc7c47a..ce7ced85f5fb 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -81,6 +81,7 @@ static void __init reserve_crashkernel(void)
{
unsigned long long crash_base, crash_size;
int ret;
+ phys_addr_t crash_max = arm64_dma32_phys_limit;
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
_size, _base);
@@ -88,12 +89,38 @@ static void __init reserve_crashkernel(void)
if (ret || !crash_size)
return;
+ ret = reserve_crashkernel_low();
+ if (!ret && crashk_low_res.end) {
+ /*
+* If crashkernel=X,low specified, there may be two regions,
+* we need to make some changes as follows:
+*
+* 1. rename the low region as "Crash kernel (low)"
+* In order to distinct from the high region and make no effect
+* to the use of existing kexec-tools, rename the low region as
+* "Crash kernel (low)".
+*
+* 2. change the upper bound for crash memory
+* Set MEMBLOCK_ALLOC_ACCESSIBLE upper bound for crash memory.
+*
+* 3. mark the low region as "nomap"
+* The low region is intended to be used for crash dump kernel
+* devices, just mark the low region as "nomap" simply.
+*/
+ const char *rename = "Crash kernel (low)";
+
+ crashk_low_res.name = rename;
+ crash_max = MEMBLOCK_ALLOC_ACCESSIBLE;
+ memblock_mark_nomap(crashk_low_res.start,
+ resource_size(_low_res));
+ }
+
crash_size = PAGE_ALIGN(crash_size);
if (crash_base == 0) {
/* Current arm64 boot protocol requires 2MB alignment */
- crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit,
- crash_size, SZ_2M);
+ crash_base = memblock_find_in_range(0, crash_max, crash_size,
+ SZ_2M);
if (crash_base == 0) {
pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
crash_size);
--
2.20.1
[PATCH v9 5/5] kdump: update Documentation about crashkernel on arm64
Now we support crashkernel=X,[low] on arm64, update the Documentation. We could use parameters "crashkernel=X crashkernel=Y,low" to reserve memory above 4G. Signed-off-by: Chen Zhou Tested-by: John Donnelly Tested-by: Prabhakar Kushwaha --- Documentation/admin-guide/kdump/kdump.rst | 13 +++-- Documentation/admin-guide/kernel-parameters.txt | 17 +++-- 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 2da65fef2a1c..6ba294d425c9 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -299,7 +299,13 @@ Boot into System Kernel "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory starting at physical address 0x0100 (16MB) for the dump-capture kernel. - On x86 and x86_64, use "crashkernel=64M@16M". + On x86 use "crashkernel=64M@16M". + + On x86_64, use "crashkernel=Y[@X]" to select a region under 4G first, and + fall back to reserve region above 4G when '@offset' hasn't been specified. + We can also use "crashkernel=X,high" to select a region above 4G, which + also tries to allocate at least 256M below 4G automatically and + "crashkernel=Y,low" can be used to allocate specified size low memory. On ppc64, use "crashkernel=128M@32M". @@ -316,8 +322,11 @@ Boot into System Kernel kernel will automatically locate the crash kernel image within the first 512MB of RAM if X is not given. - On arm64, use "crashkernel=Y[@X]". Note that the start address of + On arm64, use "crashkernel=Y[@X]". Note that the start address of the kernel, X if explicitly specified, must be aligned to 2MiB (0x20). + If crashkernel=Z,low is specified simultaneously, reserve spcified size + low memory for crash kdump kernel devices firstly and then reserve memory + above 4G. Load the Dump-capture Kernel diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index fb95fad81c79..335431a351c0 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -722,6 +722,9 @@ [KNL, x86_64] select a region under 4G first, and fall back to reserve region above 4G when '@offset' hasn't been specified. + [KNL, arm64] If crashkernel=X,low is specified, reserve + spcified size low memory for crash kdump kernel devices + firstly, and then reserve memory above 4G. See Documentation/admin-guide/kdump/kdump.rst for further details. crashkernel=range1:size1[,range2:size2,...][@offset] @@ -746,13 +749,23 @@ requires at least 64M+32K low memory, also enough extra low memory is needed to make sure DMA buffers for 32-bit devices won't run out. Kernel would try to allocate at - at least 256M below 4G automatically. + least 256M below 4G automatically. This one let user to specify own low range under 4G for second kernel instead. 0: to disable low allocation. It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. - + [KNL, arm64] range under 4G. + This one let user to specify own low range under 4G + for crash dump kernel instead. + Different with x86_64, kernel allocates specified size + physical memory region only when this parameter is specified + instead of trying to allocate at least 256M below 4G + automatically. + This parameter is used along with crashkernel=X when we + want to reserve crashkernel above 4G. If there are devices + need to use ZONE_DMA in crash dump kernel, it is also + a good choice. cryptomgr.notests [KNL] Disable crypto self-tests -- 2.20.1
[PATCH v9 4/5] arm64: kdump: fix kdump broken with ZONE_DMA reintroduced
commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
broken the arm64 kdump. 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.
This patch addressed the above issue based on "reserving crashkernel
above 4G". Originally, we reserve low memory below 4G, and now just need
to adjust memory limit to arm64_dma_phys_limit in reserve_crashkernel_low
if ZONE_DMA is enabled. That is, if there are devices need to use ZONE_DMA
in crash dump kernel, it is a good choice to use parameters
"crashkernel=X crashkernel=Y,low".
Signed-off-by: Chen Zhou
---
kernel/crash_core.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index a7580d291c37..e8ecbbc761a3 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -320,6 +320,7 @@ int __init reserve_crashkernel_low(void)
unsigned long long base, low_base = 0, low_size = 0;
unsigned long total_low_mem;
int ret;
+ phys_addr_t crash_max = 1ULL << 32;
total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
@@ -352,7 +353,11 @@ int __init reserve_crashkernel_low(void)
return 0;
}
- low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
+#ifdef CONFIG_ARM64
+ if (IS_ENABLED(CONFIG_ZONE_DMA))
+ crash_max = arm64_dma_phys_limit;
+#endif
+ low_base = memblock_find_in_range(0, crash_max, low_size, CRASH_ALIGN);
if (!low_base) {
pr_err("Cannot reserve %ldMB crashkernel low memory, please try
smaller size.\n",
(unsigned long)(low_size >> 20));
--
2.20.1
[PATCH v9 1/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c
In preparation for supporting reserve_crashkernel_low in arm64 as
x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
BTW, move x86_64 CRASH_ALIGN to 2M suggested by Dave. CONFIG_PHYSICAL_ALIGN
can be selected from 2M to 16M, move to the same as arm64.
Note, in arm64, we reserve low memory if and only if crashkernel=X,low
is specified. Different with x86_64, don't set low memory automatically.
Reported-by: kbuild test robot
Signed-off-by: Chen Zhou
Tested-by: John Donnelly
Tested-by: Prabhakar Kushwaha
---
arch/x86/kernel/setup.c| 66 -
include/linux/crash_core.h | 3 ++
include/linux/kexec.h | 2 -
kernel/crash_core.c| 85 ++
kernel/kexec_core.c| 17
5 files changed, 96 insertions(+), 77 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a3767e74c758..33db99ae3035 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -401,8 +401,8 @@ static void __init
memblock_x86_reserve_range_setup_data(void)
#ifdef CONFIG_KEXEC_CORE
-/* 16M alignment for crash kernel regions */
-#define CRASH_ALIGNSZ_16M
+/* 2M alignment for crash kernel regions */
+#define CRASH_ALIGNSZ_2M
/*
* Keep the crash kernel below this limit.
@@ -425,59 +425,6 @@ static void __init
memblock_x86_reserve_range_setup_data(void)
# define CRASH_ADDR_HIGH_MAX SZ_64T
#endif
-static int __init reserve_crashkernel_low(void)
-{
-#ifdef CONFIG_X86_64
- unsigned long long base, low_base = 0, low_size = 0;
- unsigned long total_low_mem;
- int ret;
-
- total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
-
- /* crashkernel=Y,low */
- ret = parse_crashkernel_low(boot_command_line, total_low_mem,
_size, );
- if (ret) {
- /*
-* two parts from kernel/dma/swiotlb.c:
-* -swiotlb size: user-specified with swiotlb= or default.
-*
-* -swiotlb overflow buffer: now hardcoded to 32k. We round it
-* to 8M for other buffers that may need to stay low too. Also
-* make sure we allocate enough extra low memory so that we
-* don't run out of DMA buffers for 32-bit devices.
-*/
- low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL
<< 20);
- } else {
- /* passed with crashkernel=0,low ? */
- if (!low_size)
- return 0;
- }
-
- low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
- if (!low_base) {
- pr_err("Cannot reserve %ldMB crashkernel low memory, please try
smaller size.\n",
- (unsigned long)(low_size >> 20));
- return -ENOMEM;
- }
-
- ret = memblock_reserve(low_base, low_size);
- if (ret) {
- pr_err("%s: Error reserving crashkernel low memblock.\n",
__func__);
- return ret;
- }
-
- pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System
low RAM: %ldMB)\n",
- (unsigned long)(low_size >> 20),
- (unsigned long)(low_base >> 20),
- (unsigned long)(total_low_mem >> 20));
-
- crashk_low_res.start = low_base;
- crashk_low_res.end = low_base + low_size - 1;
- insert_resource(_resource, _low_res);
-#endif
- return 0;
-}
-
static void __init reserve_crashkernel(void)
{
unsigned long long crash_size, crash_base, total_mem;
@@ -541,9 +488,12 @@ static void __init reserve_crashkernel(void)
return;
}
- if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
- memblock_free(crash_base, crash_size);
- return;
+ if (crash_base >= (1ULL << 32)) {
+ if (reserve_crashkernel_low()) {
+ memblock_free(crash_base, crash_size);
+ return;
+ }
+ insert_resource(_resource, _low_res);
}
pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System
RAM: %ldMB)\n",
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 525510a9f965..4df8c0bff03e 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -63,6 +63,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
+extern struct resource crashk_res;
+extern struct resource crashk_low_res;
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
@@ -74,5 +76,6 @@ int parse_crashkernel_high(char *cmdline, unsigned long long
system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
int parse_crashkernel_low(char
Re: [RESEND PATCH v10 2/2] phy: samsung-ufs: add UFS PHY driver for samsung SoC
Hi Alim,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on soc/for-next linus/master v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Alim-Akhtar/dt-bindings-phy-Document-Samsung-UFS-PHY-bindings/20200625-081802
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r014-20200628 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
8cd117c24f48428e01f88cf18480e5af7eb20c0c)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/phy/samsung/phy-samsung-ufs.c:47:5: warning: no previous prototype
>> for function 'samsung_ufs_phy_wait_for_lock_acq' [-Wmissing-prototypes]
int samsung_ufs_phy_wait_for_lock_acq(struct phy *phy)
^
drivers/phy/samsung/phy-samsung-ufs.c:47:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int samsung_ufs_phy_wait_for_lock_acq(struct phy *phy)
^
static
>> drivers/phy/samsung/phy-samsung-ufs.c:77:5: warning: no previous prototype
>> for function 'samsung_ufs_phy_calibrate' [-Wmissing-prototypes]
int samsung_ufs_phy_calibrate(struct phy *phy)
^
drivers/phy/samsung/phy-samsung-ufs.c:77:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int samsung_ufs_phy_calibrate(struct phy *phy)
^
static
2 warnings generated.
vim +/samsung_ufs_phy_wait_for_lock_acq +47
drivers/phy/samsung/phy-samsung-ufs.c
46
> 47 int samsung_ufs_phy_wait_for_lock_acq(struct phy *phy)
48 {
49 struct samsung_ufs_phy *ufs_phy = get_samsung_ufs_phy(phy);
50 const unsigned int timeout_us = 10;
51 const unsigned int sleep_us = 10;
52 u32 val;
53 int err;
54
55 err = readl_poll_timeout(
56 ufs_phy->reg_pma +
PHY_APB_ADDR(PHY_PLL_LOCK_STATUS),
57 val, (val & PHY_PLL_LOCK_BIT), sleep_us,
timeout_us);
58 if (err) {
59 dev_err(ufs_phy->dev,
60 "failed to get phy pll lock acquisition %d\n",
err);
61 goto out;
62 }
63
64 err = readl_poll_timeout(
65 ufs_phy->reg_pma +
PHY_APB_ADDR(PHY_CDR_LOCK_STATUS),
66 val, (val & PHY_CDR_LOCK_BIT), sleep_us,
timeout_us);
67 if (err) {
68 dev_err(ufs_phy->dev,
69 "failed to get phy cdr lock acquisition %d\n",
err);
70 goto out;
71 }
72
73 out:
74 return err;
75 }
76
> 77 int samsung_ufs_phy_calibrate(struct phy *phy)
78 {
79 struct samsung_ufs_phy *ufs_phy = get_samsung_ufs_phy(phy);
80 struct samsung_ufs_phy_cfg **cfgs = ufs_phy->cfg;
81 const struct samsung_ufs_phy_cfg *cfg;
82 int i;
83 int err = 0;
84
85 if (unlikely(ufs_phy->ufs_phy_state < CFG_PRE_INIT ||
86 ufs_phy->ufs_phy_state >= CFG_TAG_MAX)) {
87 dev_err(ufs_phy->dev, "invalid phy config index %d\n",
88
ufs_phy->ufs_phy_state);
89 return -EINVAL;
90 }
91
92 if (ufs_phy->is_pre_init)
93 ufs_phy->is_pre_init = false;
94 if (ufs_phy->is_post_init) {
95 ufs_phy->is_post_init = false;
96 ufs_phy->ufs_phy_state = CFG_POST_INIT;
97 }
98 if (ufs_phy->is_pre_pmc) {
99 ufs_phy->is_pre_pmc = false;
100 ufs_phy->ufs_phy_state = CFG_PRE_PWR_HS;
101 }
102 if (ufs_phy->is_post_pmc) {
103 ufs_phy->is_post_pmc = false;
104 ufs_phy->ufs_phy_state = CFG_POST_PWR_HS;
Re: Search function in xconfig is partially broken after recent changes
On Thu, 2020-06-25 at 17:05 +0200, Mauro Carvalho Chehab wrote: > Em Thu, 25 Jun 2020 15:53:46 +0300 > Maxim Levitsky escreveu: > > > On Thu, 2020-06-25 at 13:17 +0200, Mauro Carvalho Chehab wrote: > > > Em Thu, 25 Jun 2020 12:59:15 +0200 > > > Mauro Carvalho Chehab escreveu: > > > > > > > Hi Maxim, > > > > > > > > Em Thu, 25 Jun 2020 12:25:10 +0300 > > > > Maxim Levitsky escreveu: > > > > > > > > > Hi! > > > > > > > > > > I noticed that on recent kernels the search function in xconfig is > > > > > partially broken. > > > > > This means that when you select a found entry, it is not selected in > > > > > the main window, > > > > > something that I often do to find some entry near the area I would > > > > > like to modify, > > > > > and then use main window to navigate/explore that area. > > > > > > > > > > Reverting these commits helps restore the original behavier: > > > > > > > > > > b311142fcfd37b58dfec72e040ed04949eb1ac86 - kconfig: qconf: fix > > > > > support for the split view mode > > > > > cce1faba82645fee899ccef5b7d3050fed3a3d10 - kconfig: qconf: fix the > > > > > content of the main widget > > > > > > > > > > I have Qt5 5.13.2 from fedora 31 (5.13.2-1.fc31) > > > > > > > > > > Could you explain what these commits are supposed to fix? > > > > > I mostly use the split view mode too and it does appear to work for > > > > > me with these commits reverted as well. > > > > > > > > > > > > > There are three view modes for qconf: > > > > > > > > - Single > > > > - Split > > > > - Full > > > > > > > > those got broken when gconf was converted to use Qt5, back on Kernel > > > > 3.14. > > > > Those patches restore the original behavior. > > You mean xconfig/qconf? (gconf is another program that is GTK based as far > > as I know). > > Yeah, I meant the Qt one (qconfig). > > > Could you expalin though what was broken? What exactly didn't work? > > Try to switch between the several modes and switch back. There used to > have several broken things there, because the Qt5 port was incomplete. > > One of the things that got fixed on the Qt5 fixup series is the helper > window at the bottom. It should now have the same behavior as with the > old Qt3/Qt4 version. > > Basically, on split mode, it should have 3 screen areas: > > ++---+ > || | > | Config | menu | > || | > ++---+ > || > | Config description + > || > ++ > > The contents of the config description should follow up any changes at > the "menu" part of the split mode, when an item is selected from "menu", > or follow what's selected at "config", when the active window is "config". Dunno. with the 2 b311142fcfd37b58dfec72e040ed04949eb1ac86 and cce1faba82645fee899ccef5b7d3050fed3a3d10, in split view, I wasn't able to make the 'config description' show anything wrong, in regard to currently selected item in 'config' and in 'menu' At that point this is mostly an academic interset for me since, the patch that you sent fixes search. Thank you very much! BTW, I re-discovered another bug (I have seen it already but it didn't bother me that much), while trying to break the version with these commits reverted (but it happens with them not reverted as well): When I enable 'show debug info' to understand why I can't enable/disable some config option, the hyperlinks in the config description don't work - they make the config window to be empty. Best regards and thanks again, Maxim Levitsky > > The Kernel 3.14 conversion broke the "config description", and caused > several other issues. > > When the config description area got fixed, I had to fix each of the > modes, for all of them to update the right area at the screen, as they > were pointing to the wrong places on several parts of the code. > > > I do seem to be able to select menus on the left and the config items to > > the right, > > change the config item values, etc, in the split mode at least with these > > commits reverted. > > You should also be able to see the helper window at the bottom changing > as modes change. > > Anyway, the patch I just sent should fix it. > > > Could you check that you also have the issue with search in qconf/xconfig? > > Yeah, before that patch, search was working only on the two other > modes. > > Btw, I'm also using Fedora here (Fedora 32). So, I should have a > result close to what you would be experiencing. > > Thanks, > Mauro >
Re: [PATCH] kconfig: qconf: Fix find on split mode
On Thu, 2020-06-25 at 16:52 +0200, Mauro Carvalho Chehab wrote:
> The logic handling find on split mode is currently broken.
> Fix it, making it work again as expected.
I tested this patch and it works well.
There is one really small cosmetic issue:
If you select search result, and then select another search result
which happens not to update the 'menu', then both the results are
selected (that is the old one doesn't clear its selection)
Best regards,
Maxim Levitsky
>
> Reported-by: Maxim Levitsky
> Signed-off-by: Mauro Carvalho Chehab
> ---
> scripts/kconfig/qconf.cc | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> index c0ac8f7b5f1a..b8f577c6e8aa 100644
> --- a/scripts/kconfig/qconf.cc
> +++ b/scripts/kconfig/qconf.cc
> @@ -1645,22 +1645,21 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
> return;
> list->setRootMenu(parent);
> break;
> - case symbolMode:
> + case menuMode:
> if (menu->flags & MENU_ROOT) {
> - configList->setRootMenu(menu);
> + menuList->setRootMenu(menu);
> configList->clearSelection();
> - list = menuList;
> - } else {
> list = configList;
> + } else {
> + configList->setRootMenu(menu);
> + configList->clearSelection();
> +
> parent = menu_get_parent_menu(menu->parent);
> if (!parent)
> return;
> - item = menuList->findConfigItem(parent);
> - if (item) {
> - item->setSelected(true);
> - menuList->scrollToItem(item);
> - }
> - list->setRootMenu(parent);
> + menuList->setRootMenu(parent);
> +
> + list = menuList;
> }
> break;
> case fullMode:
Re: [PATCH] 9p: remove unused code in 9p
Jianyong Wu wrote on Sun, Jun 28, 2020: > These codes have been commented out since 2007 and lay in kernel > since then. So, it's better to remove them. > > Signed-off-by: Jianyong Wu Thanks, queued for 5.9 -- Dominique
Re: [PATCH] efi: avoid error message when booting under Xen
Ping?
On 10.06.20 16:10, Juergen Gross wrote:
efifb_probe() will issue an error message in case the kernel is booted
as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
isn't set.
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping
the FB")
Signed-off-by: Juergen Gross
---
drivers/video/fbdev/efifb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 65491ae74808..f5eccd1373e9 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
info->apertures->ranges[0].base = efifb_fix.smem_start;
info->apertures->ranges[0].size = size_remap;
- if (efi_enabled(EFI_BOOT) &&
+ if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) &&
!efi_mem_desc_lookup(efifb_fix.smem_start, )) {
if ((efifb_fix.smem_start + efifb_fix.smem_len) >
(md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
[RFC 1/2] KVM: VMX: Convert vcpu_vmx.exit_reason to a union
From: Sean Christopherson
Convert vcpu_vmx.exit_reason from a u32 to a union (of size u32). The
full VM_EXIT_REASON field is comprised of a 16-bit basic exit reason in
bits 15:0, and single-bit modifiers in bits 31:16.
Historically, KVM has only had to worry about handling the "failed
VM-Entry" modifier, which could only be set in very specific flows and
required dedicated handling. I.e. manually stripping the FAILED_VMENTRY
bit was a somewhat viable approach. But even with only a single bit to
worry about, KVM has had several bugs related to comparing a basic exit
reason against the full exit reason store in vcpu_vmx.
Upcoming Intel features, e.g. SGX, will add new modifier bits that can
be set on more or less any VM-Exit, as opposed to the significantly more
restricted FAILED_VMENTRY, i.e. correctly handling everything in one-off
flows isn't scalable. Tracking exit reason in a union forces code to
explicitly choose between consuming the full exit reason and the basic
exit, and is a convenient way to document and access the modifiers.
No functional change intended.
Cc: Xiaoyao Li
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/nested.c | 42 -
arch/x86/kvm/vmx/vmx.c| 64 ---
arch/x86/kvm/vmx/vmx.h| 25 ++-
3 files changed, 84 insertions(+), 47 deletions(-)
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index d1af20b050a8..77f732ad6085 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -3255,7 +3255,11 @@ enum nvmx_vmentry_status
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
enum vm_entry_failure_code entry_failure_code;
bool evaluate_pending_interrupts;
- u32 exit_reason, failed_index;
+ union vmx_exit_reason exit_reason = {
+ .basic = EXIT_REASON_INVALID_STATE,
+ .failed_vmentry = 1,
+ };
+ u32 failed_index;
if (kvm_check_request(KVM_REQ_TLB_FLUSH_CURRENT, vcpu))
kvm_vcpu_flush_tlb_current(vcpu);
@@ -3305,7 +3309,7 @@ enum nvmx_vmentry_status
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
if (nested_vmx_check_guest_state(vcpu, vmcs12,
_failure_code)) {
- exit_reason = EXIT_REASON_INVALID_STATE;
+ exit_reason.basic = EXIT_REASON_INVALID_STATE;
vmcs12->exit_qualification = entry_failure_code;
goto vmentry_fail_vmexit;
}
@@ -3316,7 +3320,7 @@ enum nvmx_vmentry_status
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
vcpu->arch.tsc_offset += vmcs12->tsc_offset;
if (prepare_vmcs02(vcpu, vmcs12, _failure_code)) {
- exit_reason = EXIT_REASON_INVALID_STATE;
+ exit_reason.basic = EXIT_REASON_INVALID_STATE;
vmcs12->exit_qualification = entry_failure_code;
goto vmentry_fail_vmexit_guest_mode;
}
@@ -3326,7 +3330,7 @@ enum nvmx_vmentry_status
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
vmcs12->vm_entry_msr_load_addr,
vmcs12->vm_entry_msr_load_count);
if (failed_index) {
- exit_reason = EXIT_REASON_MSR_LOAD_FAIL;
+ exit_reason.basic = EXIT_REASON_MSR_LOAD_FAIL;
vmcs12->exit_qualification = failed_index;
goto vmentry_fail_vmexit_guest_mode;
}
@@ -3394,7 +3398,7 @@ enum nvmx_vmentry_status
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
return NVMX_VMENTRY_VMEXIT;
load_vmcs12_host_state(vcpu, vmcs12);
- vmcs12->vm_exit_reason = exit_reason | VMX_EXIT_REASONS_FAILED_VMENTRY;
+ vmcs12->vm_exit_reason = exit_reason.full;
if (enable_shadow_vmcs || vmx->nested.hv_evmcs)
vmx->nested.need_vmcs12_to_shadow_sync = true;
return NVMX_VMENTRY_VMEXIT;
@@ -5449,7 +5453,12 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu)
return kvm_skip_emulated_instruction(vcpu);
fail:
- nested_vmx_vmexit(vcpu, vmx->exit_reason,
+ /*
+* This is effectively a reflected VM-Exit, as opposed to a synthesized
+* nested VM-Exit. Pass the original exit reason, i.e. don't hardcode
+* EXIT_REASON_VMFUNC as the exit reason.
+*/
+ nested_vmx_vmexit(vcpu, vmx->exit_reason.full,
vmx_get_intr_info(vcpu),
vmx_get_exit_qual(vcpu));
return 1;
@@ -5517,7 +5526,8 @@ static bool nested_vmx_exit_handled_io(struct kvm_vcpu
*vcpu,
* MSR bitmap. This may be the case even when L0 doesn't use MSR bitmaps.
*/
static bool nested_vmx_exit_handled_msr(struct kvm_vcpu
[RFC 2/2] KVM: VMX: Enable bus lock VM exit
Virtual Machine can exploit bus locks to degrade the performance of
system. Bus lock can be caused by split locked access to writeback(WB)
memory or by using locks on uncacheable(UC) memory. The bus lock is
typically >1000 cycles slower than an atomic operation within a cache
line. It also disrupts performance on other cores (which must wait for
the bus lock to be released before their memory operations can
complete).
To address the threat, bus lock VM exit is introduced to notify the VMM
when a bus lock was acquired, allowing it to enforce throttling or other
policy based mitigations.
A VMM can enable VM exit due to bus locks by setting a new "Bus Lock
Detection" VM-execution control(bit 30 of Secondary Processor-based VM
execution controls). If delivery of this VM exit was pre-empted by a
higher priority VM exit, bit 26 of exit-reason is set to 1.
In current implementation, it only records every bus lock acquired in
non-root mode in vcpu->stat.bus_locks and exposes the data through
debugfs. It doesn't implement any further handling but leave it to user.
Document for Bus Lock VM exit is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".
Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
Co-developed-by: Xiaoyao Li
Signed-off-by: Xiaoyao Li
Signed-off-by: Chenyi Qiang
---
arch/x86/include/asm/kvm_host.h| 1 +
arch/x86/include/asm/vmx.h | 1 +
arch/x86/include/asm/vmxfeatures.h | 1 +
arch/x86/include/uapi/asm/vmx.h| 4 +++-
arch/x86/kvm/vmx/vmx.c | 17 -
arch/x86/kvm/vmx/vmx.h | 2 +-
arch/x86/kvm/x86.c | 1 +
7 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f852ee350beb..efb5a117e11a 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1051,6 +1051,7 @@ struct kvm_vcpu_stat {
u64 req_event;
u64 halt_poll_success_ns;
u64 halt_poll_fail_ns;
+ u64 bus_locks;
};
struct x86_instruction_info;
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index cd7de4b401fe..93a880bc31a7 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -73,6 +73,7 @@
#define SECONDARY_EXEC_PT_USE_GPA VMCS_CONTROL_BIT(PT_USE_GPA)
#define SECONDARY_EXEC_TSC_SCALING VMCS_CONTROL_BIT(TSC_SCALING)
#define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE VMCS_CONTROL_BIT(USR_WAIT_PAUSE)
+#define SECONDARY_EXEC_BUS_LOCK_DETECTION
VMCS_CONTROL_BIT(BUS_LOCK_DETECTION)
#define PIN_BASED_EXT_INTR_MASK VMCS_CONTROL_BIT(INTR_EXITING)
#define PIN_BASED_NMI_EXITING VMCS_CONTROL_BIT(NMI_EXITING)
diff --git a/arch/x86/include/asm/vmxfeatures.h
b/arch/x86/include/asm/vmxfeatures.h
index 9915990fd8cf..d9a74681a77d 100644
--- a/arch/x86/include/asm/vmxfeatures.h
+++ b/arch/x86/include/asm/vmxfeatures.h
@@ -83,5 +83,6 @@
#define VMX_FEATURE_TSC_SCALING( 2*32+ 25) /* Scale hardware
TSC when read in guest */
#define VMX_FEATURE_USR_WAIT_PAUSE ( 2*32+ 26) /* Enable TPAUSE, UMONITOR,
UMWAIT in guest */
#define VMX_FEATURE_ENCLV_EXITING ( 2*32+ 28) /* "" VM-Exit on ENCLV
(leaf dependent) */
+#define VMX_FEATURE_BUS_LOCK_DETECTION ( 2*32+ 30) /* "" VM-Exit when bus lock
caused */
#endif /* _ASM_X86_VMXFEATURES_H */
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index b8ff9e8ac0d5..6bddfd7b87be 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -88,6 +88,7 @@
#define EXIT_REASON_XRSTORS 64
#define EXIT_REASON_UMWAIT 67
#define EXIT_REASON_TPAUSE 68
+#define EXIT_REASON_BUS_LOCK 74
#define VMX_EXIT_REASONS \
{ EXIT_REASON_EXCEPTION_NMI, "EXCEPTION_NMI" }, \
@@ -148,7 +149,8 @@
{ EXIT_REASON_XSAVES,"XSAVES" }, \
{ EXIT_REASON_XRSTORS, "XRSTORS" }, \
{ EXIT_REASON_UMWAIT,"UMWAIT" }, \
- { EXIT_REASON_TPAUSE,"TPAUSE" }
+ { EXIT_REASON_TPAUSE,"TPAUSE" }, \
+ { EXIT_REASON_BUS_LOCK, "BUS_LOCK" }
#define VMX_EXIT_REASON_FLAGS \
{ VMX_EXIT_REASONS_FAILED_VMENTRY, "FAILED_VMENTRY" }
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 647ee9a1b4e6..9622d7486f6d 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2463,7 +2463,8 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf,
SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE |
SECONDARY_EXEC_PT_USE_GPA |
SECONDARY_EXEC_PT_CONCEAL_VMX |
- SECONDARY_EXEC_ENABLE_VMFUNC;
+
[RFC 0/2] Add support for bus lock VM exit
This serial adds the support for bus lock VM exit, which is a sub-feature of bus lock detection in KVM. The left part concerning bus lock debug exception support will be sent out once the kernel part is ready. The first patch applies Sean's refactor to vcpu_vmx.exit_reason at https://patchwork.kernel.org/patch/11500659 It is necessary as bus lock VM exit adds a new modifier bit(bit 26) in exit_reason field in VMCS. The second patch is the enabling work for bus lock VM exit. Document for Bus Lock VM exit is now available at the latest "Intel Architecture Instruction Set Extensions Programming Reference". Document Link: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html Chenyi Qiang (1): KVM: VMX: Enable bus lock VM exit Sean Christopherson (1): KVM: VMX: Convert vcpu_vmx.exit_reason to a union arch/x86/include/asm/kvm_host.h| 1 + arch/x86/include/asm/vmx.h | 1 + arch/x86/include/asm/vmxfeatures.h | 1 + arch/x86/include/uapi/asm/vmx.h| 4 +- arch/x86/kvm/vmx/nested.c | 42 ++-- arch/x86/kvm/vmx/vmx.c | 81 ++ arch/x86/kvm/vmx/vmx.h | 25 - arch/x86/kvm/x86.c | 1 + 8 files changed, 107 insertions(+), 49 deletions(-) -- 2.17.1
Re: [PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels
On Sun, Jun 28, 2020 at 11:02:53AM +0300, Laurent Pinchart wrote: > Hi Sam, > > > We should also clean up all the DRM_BUS_FLAG_* one day. > > No need for the deprecated values, so a few files needs an update. > > And we could document what flags makes sense for LVDS etc. > > Where would you add that documentation ? The hardest part is to find a > place that will be noticed by developers :-) I will try to extend drm_bus_flags documentation in drm_connector.h And then add a few comments in panel-simple as well. Sam > > I've just submitted a patch that adds a WARN_ON to catch similar issues > in the panel-simple driver. It's not ideal as we really shouldn't have > such code in the kernel, this is something that should be caught as part > of the integration process. > > > On the TODO list... > > > > >>> The rest looks good, except the Samsung panel for which I haven't been > > >>> able to locate a datasheet. > > >>> > > >>> Reviewed-by: Laurent Pinchart > > -- > Regards, > > Laurent Pinchart
Re: [PATCH v2 1/2] dma-direct: provide the ability to reserve per-numa CMA
Hi Barry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc2 next-20200625]
[cannot apply to arm64/for-next/core hch-configfs/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Barry-Song/make-dma_alloc_coherent-NUMA-aware-by-per-NUMA-CMA/20200625-154656
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
8be3a53e18e0e1a98f288f6c7f5e9da3adbe9c49
config: x86_64-randconfig-s022-20200624 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> kernel/dma/contiguous.c:283:50: sparse: sparse: invalid access below
>> 'dma_contiguous_pernuma_area' (-8 8)
#
https://github.com/0day-ci/linux/commit/d6930169a3364418b985c2d19c31ecf1c4c3d4a9
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout d6930169a3364418b985c2d19c31ecf1c4c3d4a9
vim +/dma_contiguous_pernuma_area +283 kernel/dma/contiguous.c
de9e14eebf33a6 drivers/base/dma-contiguous.c Marek Szyprowski 2014-10-13 253
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 254
/**
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 255
* dma_alloc_contiguous() - allocate contiguous pages
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 256
* @dev: Pointer to device for which the allocation is performed.
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 257
* @size: Requested allocation size.
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 258
* @gfp: Allocation flags.
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 259
*
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 260
* This function allocates contiguous memory buffer for specified device. It
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 261
* tries to use device specific contiguous memory area if available, or it
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 262
* tries to use per-numa cma, if the allocation fails, it will fallback to
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 263
* try default global one.
bd2e75633c8012 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 264
*
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 265
* Note that it bypass one-page size of allocations from the per-numa and
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 266
* global area as the addresses within one page are always contiguous, so
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 267
* there is no need to waste CMA pages for that kind; it also helps reduce
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 268
* fragmentations.
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 269
*/
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 270
struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 271
{
90ae409f9eb3bc kernel/dma/contiguous.c Christoph Hellwig 2019-08-20 272
size_t count = size >> PAGE_SHIFT;
b1d2dc009dece4 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 273
struct page *page = NULL;
bd2e75633c8012 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 274
struct cma *cma = NULL;
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 275
int nid = dev ? dev_to_node(dev) : NUMA_NO_NODE;
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 276
bool alloc_from_pernuma = false;
bd2e75633c8012 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 277
bd2e75633c8012 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 278
if (dev && dev->cma_area)
bd2e75633c8012 kernel/dma/contiguous.c Nicolin Chen 2019-05-23 279
cma = dev->cma_area;
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 280
else if ((nid != NUMA_NO_NODE) && dma_contiguous_pernuma_area[nid]
d6930169a33644 kernel/dma/contiguous.c Barry Song2020-06-25 281
[PATCH net-next] sctp: use list_is_singular in sctp_list_single_entry
Use list_is_singular() instead of open-coding.
Signed-off-by: Geliang Tang
---
include/net/sctp/sctp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index f8bcb75bb044..e3bd198b00ae 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -412,7 +412,7 @@ static inline void sctp_skb_set_owner_r(struct sk_buff
*skb, struct sock *sk)
/* Tests if the list has one and only one entry. */
static inline int sctp_list_single_entry(struct list_head *head)
{
- return (head->next != head) && (head->next == head->prev);
+ return list_is_singular(head);
}
static inline bool sctp_chunk_pending(const struct sctp_chunk *chunk)
--
2.17.1
Re: [PATCH] doc: update URL for sparse's tarballs
On Fri, Jun 26, 2020 at 11:23:49AM -0600, Jonathan Corbet wrote: > > I've applied this, but it also seems like we're losing some information by > going from a wiki straight to a directory listing. It seems maybe we need > a link to the new documentation site in here as well? Yes. I hesitated to do this because: - the wiki contained very very few useful informations - the new documentation doesn't contain for a user / kernel dev perspective. I'm sending a new patch that can be applied separately or be squashed with this one if you prefer so. Thanks, -- Luc
[PATCH] doc: add link to sparse's home page/internal docs
Sparse's home page used to be a wiki (sparse.wiki.kernel.org) but this wiki only contained a short intro and the release notes. But nowadays, sparse's main page is sparse.docs.kernel.org, which contains all what was in the wiki but also other documentation, mainly oriented about sparse's internals. So, add a link to this in the kernel documentation. Signed-off-by: Luc Van Oostenryck --- Documentation/dev-tools/sparse.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/dev-tools/sparse.rst b/Documentation/dev-tools/sparse.rst index 6f4870528226..e20b8b8b78ed 100644 --- a/Documentation/dev-tools/sparse.rst +++ b/Documentation/dev-tools/sparse.rst @@ -9,6 +9,8 @@ Sparse is a semantic checker for C programs; it can be used to find a number of potential problems with kernel code. See https://lwn.net/Articles/689907/ for an overview of sparse; this document contains some kernel-specific sparse information. +More information on sparse, mainly about its internals, can be found in +its official pages at https://sparse.docs.kernl.org. Using sparse for typechecking -- 2.27.0
Re: [PATCH RFC 4/5] vhost-vdpa: support IOTLB batching hints
On Thu, Jun 18, 2020 at 01:56:25PM +0800, Jason Wang wrote:
> This patches extend the vhost IOTLB API to accept batch updating hints
> form userspace. When userspace wants update the device IOTLB in a
> batch, it may do:
>
> 1) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_BEGIN flag
> 2) Perform a batch of IOTLB updating via VHOST_IOTLB_UPDATE/INVALIDATE
> 3) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_END flag
As long as we are extending the interface,
is there some way we could cut down the number of system calls needed
here?
>
> Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when
> vDPA device support set_map() ops. This is useful for the vDPA device
> that want to know all the mappings to tweak their own DMA translation
> logic.
>
> For vDPA device that doesn't require set_map(), no behavior changes.
>
> This capability is advertised via VHOST_BACKEND_F_IOTLB_BATCH capability.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/vdpa.c | 30 +++---
> include/uapi/linux/vhost.h | 2 ++
> include/uapi/linux/vhost_types.h | 7 +++
> 3 files changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index 453057421f80..8f624bbafee7 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -56,7 +56,9 @@ enum {
> };
>
> enum {
> - VHOST_VDPA_BACKEND_FEATURES = (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2)
> + VHOST_VDPA_BACKEND_FEATURES =
> + (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2) |
> + (1ULL << VHOST_BACKEND_F_IOTLB_BATCH),
> };
>
> /* Currently, only network backend w/o multiqueue is supported. */
> @@ -77,6 +79,7 @@ struct vhost_vdpa {
> int virtio_id;
> int minor;
> struct eventfd_ctx *config_ctx;
> + int in_batch;
> };
>
> static DEFINE_IDA(vhost_vdpa_ida);
> @@ -125,6 +128,7 @@ static void vhost_vdpa_reset(struct vhost_vdpa *v)
> const struct vdpa_config_ops *ops = vdpa->config;
>
> ops->set_status(vdpa, 0);
> + v->in_batch = 0;
> }
>
> static long vhost_vdpa_get_device_id(struct vhost_vdpa *v, u8 __user *argp)
> @@ -540,9 +544,10 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
>
> if (ops->dma_map)
> r = ops->dma_map(vdpa, iova, size, pa, perm);
> - else if (ops->set_map)
> - r = ops->set_map(vdpa, dev->iotlb);
> - else
> + else if (ops->set_map) {
> + if (!v->in_batch)
> + r = ops->set_map(vdpa, dev->iotlb);
> + } else
> r = iommu_map(v->domain, iova, pa, size,
> perm_to_iommu_flags(perm));
>
> @@ -559,9 +564,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64
> iova, u64 size)
>
> if (ops->dma_map)
> ops->dma_unmap(vdpa, iova, size);
> - else if (ops->set_map)
> - ops->set_map(vdpa, dev->iotlb);
> - else
> + else if (ops->set_map) {
> + if (!v->in_batch)
> + ops->set_map(vdpa, dev->iotlb);
> + } else
> iommu_unmap(v->domain, iova, size);
> }
>
> @@ -655,6 +661,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev
> *dev,
> struct vhost_iotlb_msg *msg)
> {
> struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
> + struct vdpa_device *vdpa = v->vdpa;
> + const struct vdpa_config_ops *ops = vdpa->config;
> int r = 0;
>
> r = vhost_dev_check_owner(dev);
> @@ -668,6 +676,14 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev
> *dev,
> case VHOST_IOTLB_INVALIDATE:
> vhost_vdpa_unmap(v, msg->iova, msg->size);
> break;
> + case VHOST_IOTLB_BATCH_BEGIN:
> + v->in_batch = true;
> + break;
> + case VHOST_IOTLB_BATCH_END:
> + if (v->in_batch && ops->set_map)
> + ops->set_map(vdpa, dev->iotlb);
> + v->in_batch = false;
> + break;
> default:
> r = -EINVAL;
> break;
> diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
> index 0c2349612e77..565da96f55d5 100644
> --- a/include/uapi/linux/vhost.h
> +++ b/include/uapi/linux/vhost.h
> @@ -91,6 +91,8 @@
>
> /* Use message type V2 */
> #define VHOST_BACKEND_F_IOTLB_MSG_V2 0x1
> +/* IOTLB can accpet batching hints */
typo
> +#define VHOST_BACKEND_F_IOTLB_BATCH 0x2
>
> #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
> #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
> diff --git a/include/uapi/linux/vhost_types.h
> b/include/uapi/linux/vhost_types.h
> index 669457ce5c48..5c12faffdde9 100644
> --- a/include/uapi/linux/vhost_types.h
> +++ b/include/uapi/linux/vhost_types.h
> @@ -60,6 +60,13 @@ struct vhost_iotlb_msg {
> #define VHOST_IOTLB_UPDATE 2
> #define VHOST_IOTLB_INVALIDATE 3
> #define
[PATCH net-next] liquidio: use list_empty_careful in lio_list_delete_head
Use list_empty_careful() instead of open-coding.
Signed-off-by: Geliang Tang
---
drivers/net/ethernet/cavium/liquidio/octeon_network.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_network.h
b/drivers/net/ethernet/cavium/liquidio/octeon_network.h
index 50201fc86dcf..ebe56bd8849b 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_network.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_network.h
@@ -612,7 +612,7 @@ static inline struct list_head *lio_list_delete_head(struct
list_head *root)
{
struct list_head *node;
- if (root->prev == root && root->next == root)
+ if (list_empty_careful(root))
node = NULL;
else
node = root->next;
--
2.17.1
[PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations
Reduce data usage about 1KB by using const.
Signed-off-by: Joe Perches
---
.../net/wireless/realtek/rtlwifi/rtl8188ee/dm.c| 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c| 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c| 98 --
3 files changed, 56 insertions(+), 50 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
index dceb04a9b3f5..1ffa188a65c9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
@@ -870,11 +870,11 @@ static void dm_txpower_track_cb_therm(struct ieee80211_hw
*hw)
/*0.1 the following TWO tables decide the
*final index of OFDM/CCK swing table
*/
- s8 delta_swing_table_idx[2][15] = {
+ static const s8 delta_swing_table_idx[2][15] = {
{0, 0, 2, 3, 4, 4, 5, 6, 7, 7, 8, 9, 10, 10, 11},
{0, 0, -1, -2, -3, -4, -4, -4, -4, -5, -7, -8, -9, -9, -10}
};
- u8 thermal_threshold[2][15] = {
+ static const u8 thermal_threshold[2][15] = {
{0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 27},
{0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 25, 25, 25}
};
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
index b13fd3c0c832..c9b3d9d09c48 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
@@ -736,11 +736,11 @@ static void
rtl8723be_dm_txpower_tracking_callback_thermalmeter(
u8 ofdm_min_index = 6;
u8 index_for_channel = 0;
- s8 delta_swing_table_idx_tup_a[TXSCALE_TABLE_SIZE] = {
+ static const s8 delta_swing_table_idx_tup_a[TXSCALE_TABLE_SIZE] = {
0, 0, 1, 2, 2, 2, 3, 3, 3, 4, 5,
5, 6, 6, 7, 7, 8, 8, 9, 9, 9, 10,
10, 11, 11, 12, 12, 13, 14, 15};
- s8 delta_swing_table_idx_tdown_a[TXSCALE_TABLE_SIZE] = {
+ static const s8 delta_swing_table_idx_tdown_a[TXSCALE_TABLE_SIZE] = {
0, 0, 1, 2, 2, 2, 3, 3, 3, 4, 5,
5, 6, 6, 6, 6, 7, 7, 7, 8, 8, 9,
9, 10, 10, 11, 12, 13, 14, 15};
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
index f57e8794f0ec..b8e653eb8817 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
@@ -115,47 +115,47 @@ static const u32 edca_setting_ul[PEER_MAX] = {
0x5ea44f, /* 7 MARV */
};
-static u8 rtl8818e_delta_swing_table_idx_24gb_p[] = {
+static const u8 rtl8818e_delta_swing_table_idx_24gb_p[] = {
0, 0, 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 4, 4, 4,
4, 4, 4, 5, 5, 7, 7, 8, 8, 8, 9, 9, 9, 9, 9};
-static u8 rtl8818e_delta_swing_table_idx_24gb_n[] = {
+static const u8 rtl8818e_delta_swing_table_idx_24gb_n[] = {
0, 0, 0, 2, 2, 3, 3, 4, 4, 4, 4, 5, 5, 6, 6,
7, 7, 7, 7, 8, 8, 9, 9, 10, 10, 10, 11, 11, 11, 11};
-static u8 rtl8812ae_delta_swing_table_idx_24gb_n[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24gb_n[] = {
0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 5, 6,
6, 6, 7, 8, 9, 9, 9, 9, 10, 10, 10, 10, 11, 11};
-static u8 rtl8812ae_delta_swing_table_idx_24gb_p[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24gb_p[] = {
0, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 6,
6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 9, 9, 9, 9};
-static u8 rtl8812ae_delta_swing_table_idx_24ga_n[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24ga_n[] = {
0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 5, 6,
6, 6, 7, 8, 8, 9, 9, 9, 10, 10, 10, 10, 11, 11};
-static u8 rtl8812ae_delta_swing_table_idx_24ga_p[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24ga_p[] = {
0, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 6,
6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 9, 9, 9, 9};
-static u8 rtl8812ae_delta_swing_table_idx_24gcckb_n[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24gcckb_n[] = {
0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 5, 6,
6, 6, 7, 8, 9, 9, 9, 9, 10, 10, 10, 10, 11, 11};
-static u8 rtl8812ae_delta_swing_table_idx_24gcckb_p[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24gcckb_p[] = {
0, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 6,
6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 9, 9, 9, 9};
-static u8 rtl8812ae_delta_swing_table_idx_24gccka_n[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24gccka_n[] = {
0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 5, 6,
6, 6, 7, 8, 8, 9, 9, 9, 10, 10, 10, 10, 11, 11};
-static u8 rtl8812ae_delta_swing_table_idx_24gccka_p[] = {
+static const u8 rtl8812ae_delta_swing_table_idx_24gccka_p[] = {
0, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4, 5, 5, 6,
6, 6, 7, 7, 7, 8,
arch/nios2/include/asm/irqflags.h:12:9: sparse: sparse: context imbalance in 'snd_pcm_group_unlock_irq' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 916a3b0fc1206f7e7ae8d00a21a3114b1dc67794 commit: 80591e61a0f7e88deaada69844e4a31280c4a38f kbuild: tell sparse about the $ARCH date: 8 months ago config: nios2-randconfig-s032-20200628 (attached as .config) compiler: nios2-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-dirty git checkout 80591e61a0f7e88deaada69844e4a31280c4a38f # save the attached .config to linux build tree make W=1 C=1 ARCH=nios2 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) sound/core/pcm_native.c:544:51: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted snd_pcm_state_t [usertype] state @@ got int state @@ sound/core/pcm_native.c:544:51: sparse: expected restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:544:51: sparse: got int state sound/core/pcm_native.c:709:38: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:709:38: sparse: expected int state sound/core/pcm_native.c:709:38: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:721:38: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:721:38: sparse: expected int state sound/core/pcm_native.c:721:38: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:770:38: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:770:38: sparse: expected int state sound/core/pcm_native.c:770:38: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1229:32: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted snd_pcm_state_t [usertype] state @@ got int state @@ sound/core/pcm_native.c:1229:32: sparse: expected restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:1229:32: sparse: got int state sound/core/pcm_native.c:1253:31: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:1253:31: sparse: expected int state sound/core/pcm_native.c:1253:31: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1260:40: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:1260:40: sparse: expected int state sound/core/pcm_native.c:1260:40: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1286:28: sparse: sparse: restricted snd_pcm_state_t degrades to integer sound/core/pcm_native.c:1288:40: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted snd_pcm_state_t [usertype] state @@ got int state @@ sound/core/pcm_native.c:1288:40: sparse: expected restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:1288:40: sparse: got int state sound/core/pcm_native.c:1312:64: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] state @@ sound/core/pcm_native.c:1312:64: sparse: expected int state sound/core/pcm_native.c:1312:64: sparse: got restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:1328:38: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:1328:38: sparse: expected int state sound/core/pcm_native.c:1328:38: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1697:38: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:1697:38: sparse: expected int state sound/core/pcm_native.c:1697:38: sparse: got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1763:61: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected int state @@ got restricted snd_pcm_state_t [usertype] @@ sound/core/pcm_native.c:1763:61: sparse: expected int state sound/core/pcm_native.c:1763:61: sparse: got restricted snd_pcm_state_t [us
[RFC PATCH] nvme-pci: Move the sg table allocation/free into init/exit_request
Move the sg table allocation and free into the init_request() and
exit_request(), instead of allocating sg table when queuing requests,
which can benefit the IO performance.
Signed-off-by: Baolin Wang
---
drivers/nvme/host/pci.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index b1d18f0..cf7c997 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -410,9 +410,25 @@ static int nvme_init_request(struct blk_mq_tag_set *set,
struct request *req,
iod->nvmeq = nvmeq;
nvme_req(req)->ctrl = >ctrl;
+
+ iod->sg = mempool_alloc(dev->iod_mempool, GFP_ATOMIC);
+ if (!iod->sg)
+ return -ENOMEM;
+
+ sg_init_table(iod->sg, NVME_MAX_SEGS);
return 0;
}
+static void nvme_exit_request(struct blk_mq_tag_set *set, struct request *req,
+ unsigned int hctx_idx)
+{
+ struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
+ struct nvme_dev *dev = set->driver_data;
+
+ mempool_free(iod->sg, dev->iod_mempool);
+ iod->sg = NULL;
+}
+
static int queue_irq_offset(struct nvme_dev *dev)
{
/* if we have more than 1 vec, admin queue offsets us by 1 */
@@ -557,8 +573,6 @@ static void nvme_unmap_data(struct nvme_dev *dev, struct
request *req)
dma_pool_free(dev->prp_page_pool, addr, dma_addr);
dma_addr = next_dma_addr;
}
-
- mempool_free(iod->sg, dev->iod_mempool);
}
static void nvme_print_sgl(struct scatterlist *sgl, int nents)
@@ -808,10 +822,6 @@ static blk_status_t nvme_map_data(struct nvme_dev *dev,
struct request *req,
}
iod->dma_len = 0;
- iod->sg = mempool_alloc(dev->iod_mempool, GFP_ATOMIC);
- if (!iod->sg)
- return BLK_STS_RESOURCE;
- sg_init_table(iod->sg, blk_rq_nr_phys_segments(req));
iod->nents = blk_rq_map_sg(req->q, req, iod->sg);
if (!iod->nents)
goto out;
@@ -1557,6 +1567,7 @@ static int nvme_create_queue(struct nvme_queue *nvmeq,
int qid, bool polled)
.complete = nvme_pci_complete_rq,
.init_hctx = nvme_admin_init_hctx,
.init_request = nvme_init_request,
+ .exit_request = nvme_exit_request,
.timeout= nvme_timeout,
};
@@ -1566,6 +1577,7 @@ static int nvme_create_queue(struct nvme_queue *nvmeq,
int qid, bool polled)
.commit_rqs = nvme_commit_rqs,
.init_hctx = nvme_init_hctx,
.init_request = nvme_init_request,
+ .exit_request = nvme_exit_request,
.map_queues = nvme_pci_map_queues,
.timeout= nvme_timeout,
.poll = nvme_poll,
--
1.8.3.1
Re: KASAN: slab-out-of-bounds Read in qrtr_endpoint_post
Hi Bjorn, On Sat, Jun 27, 2020 at 01:57:13PM -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit:1590a2e1 Merge tag 'acpi-5.8-rc3' of git://git.kernel.org/.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=14b2b50310 > kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569 > dashboard link: https://syzkaller.appspot.com/bug?extid=b8fe393f999a291a9ea6 > compiler: gcc (GCC) 10.1.0-syz 20200507 > userspace arch: i386 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=109e6b5510 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13671a3d10 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+b8fe393f999a291a9...@syzkaller.appspotmail.com > > == > BUG: KASAN: slab-out-of-bounds in qrtr_endpoint_post+0xeeb/0x1010 > net/qrtr/qrtr.c:462 > Read of size 2 at addr 88809de50c48 by task syz-executor531/6806 > > CPU: 0 PID: 6806 Comm: syz-executor531 Not tainted 5.8.0-rc2-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x18f/0x20d lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383 > __kasan_report mm/kasan/report.c:513 [inline] > kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 > qrtr_endpoint_post+0xeeb/0x1010 net/qrtr/qrtr.c:462 > qrtr_tun_write_iter+0xf5/0x180 net/qrtr/tun.c:92 Hmm. Is this due to the fact that we are not checking the length of the kbuf allocated in qrtr_tun_write_iter()? The length derived from 'iov_iter_count(from)' gets used directly and that might be causing the out of bound access error here. Thanks, Mani > call_write_iter include/linux/fs.h:1907 [inline] > do_iter_readv_writev+0x567/0x780 fs/read_write.c:694 > do_iter_write+0x188/0x5f0 fs/read_write.c:999 > compat_writev+0x1ea/0x390 fs/read_write.c:1352 > do_compat_pwritev64+0x180/0x1b0 fs/read_write.c:1401 > do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:403 > __do_fast_syscall_32 arch/x86/entry/common.c:448 [inline] > do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:474 > entry_SYSENTER_compat+0x6d/0x7c arch/x86/entry/entry_64_compat.S:138 > RIP: 0023:0xf7f8f569 > Code: Bad RIP value. > RSP: 002b:ffda5ffc EFLAGS: 0292 ORIG_RAX: 014e > RAX: ffda RBX: 0003 RCX: 2440 > RDX: 0001 RSI: RDI: 080bb528 > RBP: 0012 R08: R09: > R10: R11: R12: > R13: R14: R15: > > Allocated by task 6806: > save_stack+0x1b/0x40 mm/kasan/common.c:48 > set_track mm/kasan/common.c:56 [inline] > __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 > __do_kmalloc mm/slab.c:3656 [inline] > __kmalloc+0x17a/0x340 mm/slab.c:3665 > kmalloc include/linux/slab.h:560 [inline] > kzalloc include/linux/slab.h:669 [inline] > qrtr_tun_write_iter+0x8a/0x180 net/qrtr/tun.c:83 > call_write_iter include/linux/fs.h:1907 [inline] > do_iter_readv_writev+0x567/0x780 fs/read_write.c:694 > do_iter_write+0x188/0x5f0 fs/read_write.c:999 > compat_writev+0x1ea/0x390 fs/read_write.c:1352 > do_compat_pwritev64+0x180/0x1b0 fs/read_write.c:1401 > do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:403 > __do_fast_syscall_32 arch/x86/entry/common.c:448 [inline] > do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:474 > entry_SYSENTER_compat+0x6d/0x7c arch/x86/entry/entry_64_compat.S:138 > > Freed by task 1: > save_stack+0x1b/0x40 mm/kasan/common.c:48 > set_track mm/kasan/common.c:56 [inline] > kasan_set_free_info mm/kasan/common.c:316 [inline] > __kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455 > __cache_free mm/slab.c:3426 [inline] > kfree+0x103/0x2c0 mm/slab.c:3757 > tomoyo_path_perm+0x234/0x3f0 security/tomoyo/file.c:842 > security_inode_getattr+0xcf/0x140 security/security.c:1278 > vfs_getattr fs/stat.c:121 [inline] > vfs_statx+0x170/0x390 fs/stat.c:206 > vfs_lstat include/linux/fs.h:3301 [inline] > __do_sys_newlstat+0x91/0x110 fs/stat.c:374 > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > The buggy address belongs to the object at 88809de50c40 > which belongs to the cache kmalloc-32 of size 32 > The buggy address is located 8 bytes inside of > 32-byte region [88809de50c40, 88809de50c60) > The buggy address belongs to the page: > page:ea0002779400 refcount:1 mapcount:0 mapping: > index:0x88809de50fc1 > flags: 0xfffe000200(slab) > raw: 00fffe000200 ea000277e008 ea0002761c88 8880aa0001c0 > raw: 88809de50fc1 88809de5
drivers/net/hamradio/dmascc.c:1238:56: sparse: sparse: non size-preserving pointer to integer cast
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 916a3b0fc1206f7e7ae8d00a21a3114b1dc67794
commit: 80591e61a0f7e88deaada69844e4a31280c4a38f kbuild: tell sparse about the
$ARCH
date: 8 months ago
config: alpha-randconfig-s031-20200628 (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
git checkout 80591e61a0f7e88deaada69844e4a31280c4a38f
# save the attached .config to linux build tree
make W=1 C=1 ARCH=alpha CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/net/hamradio/dmascc.c:1238:56: sparse: sparse: non size-preserving
>> pointer to integer cast
drivers/net/hamradio/dmascc.c:978:48: sparse: sparse: non size-preserving
pointer to integer cast
drivers/net/hamradio/dmascc.c:1025:48: sparse: sparse: non size-preserving
pointer to integer cast
drivers/net/hamradio/dmascc.c:1025:48: sparse: sparse: non size-preserving
pointer to integer cast
vim +1238 drivers/net/hamradio/dmascc.c
^1da177e4c3f41 Linus Torvalds2005-04-16 1180
^1da177e4c3f41 Linus Torvalds2005-04-16 1181
^1da177e4c3f41 Linus Torvalds2005-04-16 1182 static void
special_condition(struct scc_priv *priv, int rc)
^1da177e4c3f41 Linus Torvalds2005-04-16 1183 {
^1da177e4c3f41 Linus Torvalds2005-04-16 1184 int cb;
^1da177e4c3f41 Linus Torvalds2005-04-16 1185 unsigned long flags;
^1da177e4c3f41 Linus Torvalds2005-04-16 1186
^1da177e4c3f41 Linus Torvalds2005-04-16 1187 /* See Figure 2-15.
Only overrun and EOF need to be checked. */
^1da177e4c3f41 Linus Torvalds2005-04-16 1188
^1da177e4c3f41 Linus Torvalds2005-04-16 1189 if (rc & Rx_OVR) {
^1da177e4c3f41 Linus Torvalds2005-04-16 1190 /* Receiver
overrun */
^1da177e4c3f41 Linus Torvalds2005-04-16 1191 priv->rx_over =
1;
^1da177e4c3f41 Linus Torvalds2005-04-16 1192 if
(priv->param.dma < 0)
^1da177e4c3f41 Linus Torvalds2005-04-16 1193
write_scc(priv, R0, ERR_RES);
^1da177e4c3f41 Linus Torvalds2005-04-16 1194 } else if (rc & END_FR)
{
^1da177e4c3f41 Linus Torvalds2005-04-16 1195 /* End of
frame. Get byte count */
^1da177e4c3f41 Linus Torvalds2005-04-16 1196 if
(priv->param.dma >= 0) {
^1da177e4c3f41 Linus Torvalds2005-04-16 1197 flags =
claim_dma_lock();
^1da177e4c3f41 Linus Torvalds2005-04-16 1198 cb =
BUF_SIZE - get_dma_residue(priv->param.dma) -
^1da177e4c3f41 Linus Torvalds2005-04-16 1199 2;
^1da177e4c3f41 Linus Torvalds2005-04-16 1200
release_dma_lock(flags);
^1da177e4c3f41 Linus Torvalds2005-04-16 1201 } else {
^1da177e4c3f41 Linus Torvalds2005-04-16 1202 cb =
priv->rx_ptr - 2;
^1da177e4c3f41 Linus Torvalds2005-04-16 1203 }
^1da177e4c3f41 Linus Torvalds2005-04-16 1204 if
(priv->rx_over) {
^1da177e4c3f41 Linus Torvalds2005-04-16 1205 /* We
had an overrun */
13c0582d91ab63 Stephen Hemminger 2009-01-09 1206
priv->dev->stats.rx_errors++;
^1da177e4c3f41 Linus Torvalds2005-04-16 1207 if
(priv->rx_over == 2)
13c0582d91ab63 Stephen Hemminger 2009-01-09 1208
priv->dev->stats.rx_length_errors++;
^1da177e4c3f41 Linus Torvalds2005-04-16 1209 else
13c0582d91ab63 Stephen Hemminger 2009-01-09 1210
priv->dev->stats.rx_fifo_errors++;
^1da177e4c3f41 Linus Torvalds2005-04-16 1211
priv->rx_over = 0;
^1da177e4c3f41 Linus Torvalds2005-04-16 1212 } else if (rc &
CRC_ERR) {
^1da177e4c3f41 Linus Torvalds2005-04-16 1213 /*
Count invalid CRC only if packet length >= minimum */
^1da177e4c3f41 Linus Torvalds2005-04-16 1214 if (cb
>= 15) {
13c0582d91ab63 Stephen Hemminger 2009-01-09 1215
priv->dev->stats.rx_errors++;
13c0582d91ab63 Stephen Hemminger 2009-01-09 1216
priv->dev->stats.rx_crc_errors++;
^1da177e4c3f41 Linus Torvalds2005-04-16 1217 }
^1da177e4c3f41 Linus Torvalds2005-04-16 1218 } else {
^1da177e4c3f41 Linus Torvalds2005-04-16 1219 if (cb
>= 15) {
^1da177e4c3f41 Linus Torvalds2005-04-16 1220
if (priv->rx_count < NUM_RX_BUF - 1) {
^1da177e4
Re: Search function in xconfig is partially broken after recent changes
Em Sun, 28 Jun 2020 11:37:08 +0300 Maxim Levitsky escreveu: > On Thu, 2020-06-25 at 17:05 +0200, Mauro Carvalho Chehab wrote: > > Em Thu, 25 Jun 2020 15:53:46 +0300 > > Maxim Levitsky escreveu: > > > > > On Thu, 2020-06-25 at 13:17 +0200, Mauro Carvalho Chehab wrote: > > > > Em Thu, 25 Jun 2020 12:59:15 +0200 > > > > Mauro Carvalho Chehab escreveu: > > > > > > > > > Hi Maxim, > > > > > > > > > > Em Thu, 25 Jun 2020 12:25:10 +0300 > > > > > Maxim Levitsky escreveu: > > > > > > > > > > > Hi! > > > > > > > > > > > > I noticed that on recent kernels the search function in xconfig is > > > > > > partially broken. > > > > > > This means that when you select a found entry, it is not selected > > > > > > in the main window, > > > > > > something that I often do to find some entry near the area I would > > > > > > like to modify, > > > > > > and then use main window to navigate/explore that area. > > > > > > > > > > > > Reverting these commits helps restore the original behavier: > > > > > > > > > > > > b311142fcfd37b58dfec72e040ed04949eb1ac86 - kconfig: qconf: fix > > > > > > support for the split view mode > > > > > > cce1faba82645fee899ccef5b7d3050fed3a3d10 - kconfig: qconf: fix the > > > > > > content of the main widget > > > > > > > > > > > > I have Qt5 5.13.2 from fedora 31 (5.13.2-1.fc31) > > > > > > > > > > > > Could you explain what these commits are supposed to fix? > > > > > > I mostly use the split view mode too and it does appear to work for > > > > > > me with these commits reverted as well. > > > > > > > > > > > > > > > > There are three view modes for qconf: > > > > > > > > > > - Single > > > > > - Split > > > > > - Full > > > > > > > > > > those got broken when gconf was converted to use Qt5, back on Kernel > > > > > 3.14. > > > > > Those patches restore the original behavior. > > > You mean xconfig/qconf? (gconf is another program that is GTK based as > > > far as I know). > > > > Yeah, I meant the Qt one (qconfig). > > > > > Could you expalin though what was broken? What exactly didn't work? > > > > Try to switch between the several modes and switch back. There used to > > have several broken things there, because the Qt5 port was incomplete. > > > > One of the things that got fixed on the Qt5 fixup series is the helper > > window at the bottom. It should now have the same behavior as with the > > old Qt3/Qt4 version. > > > > Basically, on split mode, it should have 3 screen areas: > > > > ++---+ > > || | > > | Config | menu | > > || | > > ++---+ > > || > > | Config description + > > || > > ++ > > > > The contents of the config description should follow up any changes at > > the "menu" part of the split mode, when an item is selected from "menu", > > or follow what's selected at "config", when the active window is "config". > > Dunno. with the 2 b311142fcfd37b58dfec72e040ed04949eb1ac86 and > cce1faba82645fee899ccef5b7d3050fed3a3d10, > in split view, I wasn't able to make the 'config description' show anything > wrong, > in regard to currently selected item in 'config' and in 'menu' Well, the problem was related to how the code calls those 3 areas internally: configView, menuView and configInfoView. When it is outside the split view, it should hide the menuView, in order to show just the configView and the configInfoView. There were lots of weird stuff there. I suspect that, after the half-done Qt5 conversion (that handled badly the menuView hiding logic), some hacks were added, assuming the wrong window hiding logic. When I fixed it, other things stopped working. So, additional fixup patches were needed. > At that point this is mostly an academic interset for me since, > the patch that you sent fixes search. Thank you very much! Anytime! > BTW, I re-discovered another bug (I have seen it already but it didn't bother > me that much), > while trying to break the version with these commits reverted (but it happens > with them not reverted as well): > > When I enable 'show debug info' to understand why I can't enable/disable some > config > option, the hyperlinks in the config description don't work - they make the > config > window to be empty. It sounds that the creation of the search list for the QTextBrowser instantiated class (e. g. configInfoView) is not fine. It sounds that it was supposed to call either setInfo() or setMenuLink() when a debug info hyperlink is clicked: info = new ConfigInfoView(split, name); connect(list->list, SIGNAL(menuChanged(struct menu *)), info, SLOT(setInfo(struct menu *))); But this is not happening. Perhaps this also broke with the Qt5 conversion? I suspect it should, instead, use a different signal to handle it. See, with the enclosed patch, clicking on a link will
[PATCH v3 2/2] arm64: mm: reserve per-numa CMA to localize coherent dma buffers
Right now, smmu is using dma_alloc_coherent() to get memory to save queues and tables. Typically, on ARM64 server, there is a default CMA located at node0, which could be far away from node2, node3 etc. with this patch, smmu will get memory from local numa node to save command queues and page tables. that means dma_unmap latency will be shrunk much. Meanwhile, when iommu.passthrough is on, device drivers which call dma_ alloc_coherent() will also get local memory and avoid the travel between numa nodes. Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Will Deacon Cc: Robin Murphy Cc: Ganapatrao Kulkarni Cc: Catalin Marinas Cc: Nicolas Saenz Julienne Cc: Steve Capper Cc: Andrew Morton Cc: Mike Rapoport Signed-off-by: Barry Song --- -v3: * move dma_pernuma_cma_reserve() after hugetlb_cma_reserve() to reuse the comment before hugetlb_cma_reserve() with respect to Robin's comment arch/arm64/mm/init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 1e93cfc7c47a..a01eeb829372 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -429,6 +429,8 @@ void __init bootmem_init(void) hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); #endif + dma_pernuma_cma_reserve(); + /* * Sparsemem tries to allocate bootmem in memory_present(), so must be * done after the fixed reservations. -- 2.27.0
[PATCH v3 0/2] make dma_alloc_coherent NUMA-aware by per-NUMA CMA
Ganapatrao Kulkarni has put some effort on making arm-smmu-v3 use local memory to save command queues[1]. I also did similar job in patch "iommu/arm-smmu-v3: allocate the memory of queues in local numa node" [2] while not realizing Ganapatrao has done that before. But it seems it is much better to make dma_alloc_coherent() to be inherently NUMA-aware on NUMA-capable systems. Right now, smmu is using dma_alloc_coherent() to get memory to save queues and tables. Typically, on ARM64 server, there is a default CMA located at node0, which could be far away from node2, node3 etc. Saving queues and tables remotely will increase the latency of ARM SMMU significantly. For example, when SMMU is at node2 and the default global CMA is at node0, after sending a CMD_SYNC in an empty command queue, we have to wait more than 550ns for the completion of the command CMD_SYNC. However, if we save them locally, we only need to wait for 240ns. with per-numa CMA, smmu will get memory from local numa node to save command queues and page tables. that means dma_unmap latency will be shrunk much. Meanwhile, when iommu.passthrough is on, device drivers which call dma_ alloc_coherent() will also get local memory and avoid the travel between numa nodes. [1] https://lists.linuxfoundation.org/pipermail/iommu/2017-October/024455.html [2] https://www.spinics.net/lists/iommu/msg44767.html -v3: * move to use page_to_nid() while freeing cma with respect to Robin's comment, but this will only work after applying my below patch: "mm/cma.c: use exact_nid true to fix possible per-numa cma leak" https://marc.info/?l=linux-mm=159333034726647=2 * handle the case count <= 1 more properly according to Robin's comment; * add pernuma_cma parameter to support dynamic setting of per-numa cma size; ideally we can leverage the CMA_SIZE_MBYTES, CMA_SIZE_PERCENTAGE and "cma=" kernel parameter and avoid a new paramter separately for per- numa cma. Practically, it is really too complicated considering the below problems: (1) if we leverage the size of default numa for per-numa, we have to avoid creating two cma with same size in node0 since default cma is probably on node0. (2) default cma can consider the address limitation for old devices while per-numa cma doesn't support GFP_DMA and GFP_DMA32. all allocations with limitation flags will fallback to default one. (3) hard to apply CMA_SIZE_PERCENTAGE to per-numa. it is hard to decide if the percentage should apply to the whole memory size or only apply to the memory size of a specific numa node. (4) default cma size has CMA_SIZE_SEL_MIN and CMA_SIZE_SEL_MAX, it makes things even more complicated to per-numa cma. I haven't figured out a good way to leverage the size of default cma for per-numa cma. it seems a separate parameter for per-numa could make life easier. * move dma_pernuma_cma_reserve() after hugetlb_cma_reserve() to reuse the comment before hugetlb_cma_reserve() with respect to Robin's comment -v2: * fix some issues reported by kernel test robot * fallback to default cma while allocation fails in per-numa cma free memory properly Barry Song (2): dma-direct: provide the ability to reserve per-numa CMA arm64: mm: reserve per-numa CMA to localize coherent dma buffers .../admin-guide/kernel-parameters.txt | 9 ++ arch/arm64/mm/init.c | 2 + include/linux/dma-contiguous.h| 4 + kernel/dma/Kconfig| 10 ++ kernel/dma/contiguous.c | 98 +-- 5 files changed, 114 insertions(+), 9 deletions(-) -- 2.27.0
[PATCH v3 1/2] dma-direct: provide the ability to reserve per-numa CMA
This is useful for at least two scenarios:
1. ARM64 smmu will get memory from local numa node, it can save its
command queues and page tables locally. Tests show it can decrease
dma_unmap latency at lot. For example, without this patch, smmu on
node2 will get memory from node0 by calling dma_alloc_coherent(),
typically, it has to wait for more than 560ns for the completion of
CMD_SYNC in an empty command queue; with this patch, it needs 240ns
only.
2. when we set iommu passthrough, drivers will get memory from CMA,
local memory means much less latency.
Cc: Jonathan Cameron
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Will Deacon
Cc: Robin Murphy
Cc: Ganapatrao Kulkarni
Cc: Catalin Marinas
Cc: Nicolas Saenz Julienne
Cc: Steve Capper
Cc: Andrew Morton
Cc: Mike Rapoport
Signed-off-by: Barry Song
---
-v3:
* move to use page_to_nid() while freeing cma with respect to Robin's
comment, but this will only work after applying my below patch:
"mm/cma.c: use exact_nid true to fix possible per-numa cma leak"
https://marc.info/?l=linux-mm=159333034726647=2
* handle the case count <= 1 more properly according to Robin's
comment;
* add pernuma_cma parameter to support dynamic setting of per-numa
cma size;
ideally we can leverage the CMA_SIZE_MBYTES, CMA_SIZE_PERCENTAGE and
"cma=" kernel parameter and avoid a new paramter separately for per-
numa cma. Practically, it is really too complicated considering the
below problems:
(1) if we leverage the size of default numa for per-numa, we have to
avoid creating two cma with same size in node0 since default cma is
probably on node0.
(2) default cma can consider the address limitation for old devices
while per-numa cma doesn't support GFP_DMA and GFP_DMA32. all
allocations with limitation flags will fallback to default one.
(3) hard to apply CMA_SIZE_PERCENTAGE to per-numa. it is hard to
decide if the percentage should apply to the whole memory size
or only apply to the memory size of a specific numa node.
(4) default cma size has CMA_SIZE_SEL_MIN and CMA_SIZE_SEL_MAX, it
makes things even more complicated to per-numa cma.
I haven't figured out a good way to leverage the size of default cma
for per-numa cma. it seems a separate parameter for per-numa could
make life easier.
.../admin-guide/kernel-parameters.txt | 9 ++
include/linux/dma-contiguous.h| 4 +
kernel/dma/Kconfig| 10 ++
kernel/dma/contiguous.c | 98 +--
4 files changed, 112 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index fb95fad81c79..c52c22fa6de6 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -599,6 +599,15 @@
altogether. For more information, see
include/linux/dma-contiguous.h
+ pernuma_cma=nn[MG]@[start[MG][-end[MG]]]
+ [ARM,X86,KNL]
+ Sets the size of kernel per-numa memory area for
+ contiguous memory allocations. A value of 0 disables
+ per-numa CMA altogether. DMA users on node nid will
+ first try to allocate buffer from the pernuma area
+ which is located in node nid, if the allocation fails,
+ they will fallback to the global default memory area.
+
cmo_free_hint= [PPC] Format: { yes | no }
Specify whether pages are marked as being inactive
when they are freed. This is used in CMO environments
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 03f8e98e3bcc..278a80a40456 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -79,6 +79,8 @@ static inline void dma_contiguous_set_default(struct cma *cma)
void dma_contiguous_reserve(phys_addr_t addr_limit);
+void dma_pernuma_cma_reserve(void);
+
int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
phys_addr_t limit, struct cma **res_cma,
bool fixed);
@@ -128,6 +130,8 @@ static inline void dma_contiguous_set_default(struct cma
*cma) { }
static inline void dma_contiguous_reserve(phys_addr_t limit) { }
+static inline void dma_pernuma_cma_reserve(void) { }
+
static inline int dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t
base,
phys_addr_t limit, struct cma **res_cma,
bool fixed)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index d006668c0027..aeb976b1d21c 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -104,6 +104,16 @@ config DMA_CMA
if DMA_CMA
comment "Default contiguous memory area size:"
Re: [PATCH] mm: Free unused pages in kmalloc_order()
> kmalloc(1024, GFP_HIGHUSER) can allocate memory normally, > kmalloc(64*1024, GFP_HIGHUSER) will cause a memory leak, Would you like to explain the influence of the selected allocation size in a different way? > because alloc_pages returns highmem physical pages, but it cannot be directly > converted into a virtual address and return NULL, the pages has not > been released. Usually driver developers will not use the > GFP_HIGHUSER flag to allocate memory in kmalloc, but I think this > memory leak is not perfect, it is best to be fixed. I suggest to improve this change description. * Did you apply any special analysis tools? * How do you think about to split the text into more sentences? * Would you like to extend any software documentation? > This is the first time I have posted a patch, I find this information irrelevant for the proposed commit message. > there may be something wrong. There are usual risks to consider also for such software development. Will it become helpful to add the tag “Fixes”? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=719fdd32921fb7e3208db8832d32ae1c2d68900f#n183 Regards, Markus
Re: Search function in xconfig is partially broken after recent changes
On Sun, 2020-06-28 at 12:54 +0200, Mauro Carvalho Chehab wrote: > Em Sun, 28 Jun 2020 11:37:08 +0300 > Maxim Levitsky escreveu: > > > On Thu, 2020-06-25 at 17:05 +0200, Mauro Carvalho Chehab wrote: > > > Em Thu, 25 Jun 2020 15:53:46 +0300 > > > Maxim Levitsky escreveu: > > > > > > > On Thu, 2020-06-25 at 13:17 +0200, Mauro Carvalho Chehab wrote: > > > > > Em Thu, 25 Jun 2020 12:59:15 +0200 > > > > > Mauro Carvalho Chehab escreveu: > > > > > > > > > > > Hi Maxim, > > > > > > > > > > > > Em Thu, 25 Jun 2020 12:25:10 +0300 > > > > > > Maxim Levitsky escreveu: > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > I noticed that on recent kernels the search function in xconfig > > > > > > > is partially broken. > > > > > > > This means that when you select a found entry, it is not selected > > > > > > > in the main window, > > > > > > > something that I often do to find some entry near the area I > > > > > > > would like to modify, > > > > > > > and then use main window to navigate/explore that area. > > > > > > > > > > > > > > Reverting these commits helps restore the original behavier: > > > > > > > > > > > > > > b311142fcfd37b58dfec72e040ed04949eb1ac86 - kconfig: qconf: fix > > > > > > > support for the split view mode > > > > > > > cce1faba82645fee899ccef5b7d3050fed3a3d10 - kconfig: qconf: fix > > > > > > > the content of the main widget > > > > > > > > > > > > > > I have Qt5 5.13.2 from fedora 31 (5.13.2-1.fc31) > > > > > > > > > > > > > > Could you explain what these commits are supposed to fix? > > > > > > > I mostly use the split view mode too and it does appear to work > > > > > > > for me with these commits reverted as well. > > > > > > > > > > > > > > > > > > > There are three view modes for qconf: > > > > > > > > > > > > - Single > > > > > > - Split > > > > > > - Full > > > > > > > > > > > > those got broken when gconf was converted to use Qt5, back on > > > > > > Kernel 3.14. > > > > > > Those patches restore the original behavior. > > > > You mean xconfig/qconf? (gconf is another program that is GTK based as > > > > far as I know). > > > > > > Yeah, I meant the Qt one (qconfig). > > > > > > > Could you expalin though what was broken? What exactly didn't work? > > > > > > Try to switch between the several modes and switch back. There used to > > > have several broken things there, because the Qt5 port was incomplete. > > > > > > One of the things that got fixed on the Qt5 fixup series is the helper > > > window at the bottom. It should now have the same behavior as with the > > > old Qt3/Qt4 version. > > > > > > Basically, on split mode, it should have 3 screen areas: > > > > > > ++---+ > > > || | > > > | Config | menu | > > > || | > > > ++---+ > > > || > > > | Config description + > > > || > > > ++ > > > > > > The contents of the config description should follow up any changes at > > > the "menu" part of the split mode, when an item is selected from "menu", > > > or follow what's selected at "config", when the active window is > > > "config". > > > > Dunno. with the 2 b311142fcfd37b58dfec72e040ed04949eb1ac86 and > > cce1faba82645fee899ccef5b7d3050fed3a3d10, > > in split view, I wasn't able to make the 'config description' show anything > > wrong, > > in regard to currently selected item in 'config' and in 'menu' > > Well, the problem was related to how the code calls those 3 areas > internally: configView, menuView and configInfoView. > > When it is outside the split view, it should hide the > menuView, in order to show just the configView and the configInfoView. > > There were lots of weird stuff there. I suspect that, after the > half-done Qt5 conversion (that handled badly the menuView hiding > logic), some hacks were added, assuming the wrong window hiding > logic. When I fixed it, other things stopped working. So, additional > fixup patches were needed. > > > At that point this is mostly an academic interset for me since, > > the patch that you sent fixes search. Thank you very much! > > Anytime! > > > BTW, I re-discovered another bug (I have seen it already but it didn't > > bother me that much), > > while trying to break the version with these commits reverted (but it > > happens > > with them not reverted as well): > > > > When I enable 'show debug info' to understand why I can't enable/disable > > some config > > option, the hyperlinks in the config description don't work - they make the > > config > > window to be empty. > > It sounds that the creation of the search list for the QTextBrowser > instantiated class (e. g. configInfoView) is not fine. > > It sounds that it was supposed to call either setInfo() or > setMenuLink() when a debug info hyperlink is clicked: > > info = new ConfigInfoView(split, name); > connect(list->list,
Re: Kernel issues with Radeon Pro WX4100 and DP->HDMI dongles
On Thu, 2020-06-25 at 10:14 +0300, Maxim Levitsky wrote: > Hi, > > I recently tried to connect my TV and WX4100 via two different DP->HDMI > dongles. > One of them makes my main monitor to go dark, and system to lockup (I haven't > yet debugged this futher), and the other one seems to work, > most of the time, but sometimes causes a kernel panic on 5.8.0-rc1: > > > [ +0.00] ---[ end trace 0ce8685fac3db6b5 ]--- > [ +2.142125] [drm:dc_link_detect_helper [amdgpu]] *ERROR* No EDID read. > [ +0.065348] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.001002] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.006310] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.102119] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.000679] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +22.037707] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +16.202833] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.000685] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.053875] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.000351] [drm] amdgpu_dm_irq_schedule_work FAILED src 8 > [ +0.031764] [ cut here ] > [ +0.01] WARNING: CPU: 58 PID: 504 at > drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_base.c:66 > dal_gpio_open_ex+0x1b/0x40 [amdgpu] > [ +0.01] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio > xfs rfcomm xt_MASQUERADE xt_conntrack ipt_REJECT iptable_mangle iptable_nat > nf_nat ebtable_filter ebtables ip6table_filter > ip6_tables tun bridge pmbus cmac pmbus_core ee1004 jc42 bnep sunrpc vfat fat > dm_mirror dm_region_hash dm_log iwlmvm wmi_bmof mac80211 kvm_amd kvm libarc4 > uvcvideo iwlwifi btusb btrtl btbcm btintel > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_hda_codec_hdmi > videobuf2_common snd_usb_audio bluetooth videodev input_leds snd_hda_intel > cfg80211 snd_usbmidi_lib joydev snd_intel_dspcfg > snd_rawmidi mc snd_hda_codec xpad ff_memless snd_hwdep thunderbolt > ecdh_generic snd_seq ecc snd_hda_core irqbypass rfkill i2c_nvidia_gpu > efi_pstore pcspkr snd_seq_device bfq snd_pcm snd_timer zenpower > snd i2c_piix4 rtc_cmos tpm_crb tpm_tis tpm_tis_core tpm wmi button > binfmt_misc dm_crypt sd_mod uas usb_storage hid_generic usbhid hid ext4 > mbcache jbd2 amdgpu gpu_sched ttm drm_kms_helper syscopyarea > sysfillrect > [ +0.18] sysimgblt crc32_pclmul ahci crc32c_intel fb_sys_fops libahci > igb ccp cec xhci_pci libata i2c_algo_bit rng_core nvme xhci_hcd drm nvme_core > t10_pi nbd usbmon it87 hwmon_vid fuse i2c_dev > i2c_core ipv6 autofs4 [last unloaded: nvidia] > [ +0.05] CPU: 58 PID: 504 Comm: kworker/58:1 Tainted: PW O > 5.8.0-rc1.stable #118 > [ +0.01] Hardware name: Gigabyte Technology Co., Ltd. TRX40 > DESIGNARE/TRX40 DESIGNARE, BIOS F4c 03/05/2020 > [ +0.00] Workqueue: events dm_irq_work_func [amdgpu] > [ +0.01] RIP: 0010:dal_gpio_open_ex+0x1b/0x40 [amdgpu] > [ +0.01] Code: 08 89 47 10 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 > 00 48 83 7f 08 00 75 0f 48 83 7f 18 00 74 15 89 77 20 e9 65 07 00 00 <0f> 0b > e8 ae 5b 8a e0 b8 05 00 00 00 c3 0f 0b e8 a1 > 5b 8a e0 b8 06 > [ +0.00] RSP: 0018:c90002e93b90 EFLAGS: 00010282 > [ +0.01] RAX: RBX: 889fa4736ca0 RCX: > > [ +0.00] RDX: RSI: 0003 RDI: > 889fa011ff00 > [ +0.01] RBP: 0003 R08: 0001 R09: > 0231 > [ +0.00] R10: 017f R11: 889fbeea4b84 R12: > c90002e93c74 > [ +0.00] R13: R14: 889fa4736ca0 R15: > 889fb0e2c100 > [ +0.01] FS: () GS:889fbee8() > knlGS: > [ +0.00] CS: 0010 DS: ES: CR0: 80050033 > [ +0.01] CR2: 1ee62a52b000 CR3: 00174d175000 CR4: > 00340ea0 > [ +0.00] Call Trace: > [ +0.00] dal_ddc_open+0x2d/0xe0 [amdgpu] > [ +0.01] ? dm_read_reg_func+0x33/0xa0 [amdgpu] > [ +0.00] dce_aux_transfer_raw+0xb4/0xa30 [amdgpu] > [ +0.00] ? hrtimer_try_to_cancel+0x28/0x100 > [ +0.01] dm_dp_aux_transfer+0x8f/0xf0 [amdgpu] > [ +0.00] drm_dp_dpcd_access+0x6b/0x110 [drm_kms_helper] > [ +0.00] drm_dp_dpcd_read+0xb6/0xf0 [drm_kms_helper] > [ +0.01] dm_helpers_dp_read_dpcd+0x28/0x50 [amdgpu] > [ +0.00] core_link_read_dpcd.part.0+0x1f/0x30 [amdgpu] > [ +0.00] read_hpd_rx_irq_data+0x39/0x90 [amdgpu] > [ +0.01] dc_link_handle_hpd_rx_irq+0x74/0x7c0 [amdgpu] > [ +0.00] handle_hpd_rx_irq+0x62/0x2e0 [amdgpu] > [ +0.00] ? __schedule+0x252/0x6a0 > [ +0.01] ? finish_task_switch+0x18d/0x280 > [ +0.00] dm_irq_work_func+0x43/0x50 [amdgpu] > [ +0.00] process_one_work+0x1d2/0x390 > [ +0.00] worker_thread+0x225/0x3b0 > [ +0.01] ? process_one_work+0x390/0x390 > [ +0.00] kthread+0xf9/0x130 > [ +0.00] ?
[PATCH] random: get rid of dead codes from credit_entropy_bits
After commit 90ea1c6436d2 ("random: remove the blocking pool"),
has_initialized is zero always, and initialized of struct
entropy_store is not used
Signed-off-by: Li RongQing
---
drivers/char/random.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index a7cf6aa65908..288cc4464a69 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -500,7 +500,6 @@ struct entropy_store {
unsigned short add_ptr;
unsigned short input_rotate;
int entropy_count;
- unsigned int initialized:1;
unsigned int last_data_init:1;
__u8 last_data[EXTRACT_SIZE];
};
@@ -660,7 +659,7 @@ static void process_random_ready_list(void)
*/
static void credit_entropy_bits(struct entropy_store *r, int nbits)
{
- int entropy_count, orig, has_initialized = 0;
+ int entropy_count, orig;
const int pool_size = r->poolinfo->poolfracbits;
int nfrac = nbits << ENTROPY_SHIFT;
@@ -717,11 +716,6 @@ static void credit_entropy_bits(struct entropy_store *r,
int nbits)
if (cmpxchg(>entropy_count, orig, entropy_count) != orig)
goto retry;
- if (has_initialized) {
- r->initialized = 1;
- kill_fasync(, SIGIO, POLL_IN);
- }
-
trace_credit_entropy_bits(r->name, nbits,
entropy_count >> ENTROPY_SHIFT, _RET_IP_);
--
2.16.2
Re: [PATCH v3 00/14 RESEND] irqchip: Fix potential resource leaks
сре, 24. јун 2020. у 10:40 Marc Zyngier је написао/ла: > > On 2020-06-24 08:44, Tiezhu Yang wrote: > > [git send-email failed due to too many commands, > > so only cc the major related email and resend it, > > sorry for that] > > This is becoming majorly annoying. I don't think this is the right vocabulary to welcome newcomers, however "terrible" thinks they did. Rather, patience, calmness and clear and detailed explanations would work much better - and certainly be much more helpful and useful to the community in the long run. Regards, Aleksandar > Please fix your git setup > *before* dumping 57 emails for just 14 patches. You have done > the same thing yesterday, and I would hope you learned from your > mistakes. > > Also, do not repost a series more than once per week. You have > already exceeded your quota by quite a margin. > > M. > -- > Jazz is not dead. It just smells funny...
WARNING in tracepoint_add_func
Hello, syzbot found the following crash on: HEAD commit:7a64135f libbpf: Adjust SEC short cut for expected attach .. git tree: bpf console output: https://syzkaller.appspot.com/x/log.txt?x=142782e310 kernel config: https://syzkaller.appspot.com/x/.config?x=dcc6334acae363d4 dashboard link: https://syzkaller.appspot.com/bug?extid=721aa903751db87aa244 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+721aa903751db87aa...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 16762 at kernel/tracepoint.c:243 tracepoint_add_func+0x254/0x880 kernel/tracepoint.c:243 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 16762 Comm: syz-executor.4 Not tainted 5.8.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:231 __warn.cold+0x20/0x45 kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 exc_invalid_op+0x24d/0x400 arch/x86/kernel/traps.c:235 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:563 RIP: 0010:tracepoint_add_func+0x254/0x880 kernel/tracepoint.c:243 Code: 44 24 20 48 8b 5b 08 80 38 00 0f 85 6b 05 00 00 48 8b 44 24 08 48 3b 58 08 0f 85 2d ff ff ff 41 bc ef ff ff ff e8 4c 78 fe ff <0f> 0b e8 45 78 fe ff 44 89 e0 48 83 c4 38 5b 5d 41 5c 41 5d 41 5e RSP: 0018:c90001497a98 EFLAGS: 00010216 RAX: 199a RBX: 89b99040 RCX: c90011df4000 RDX: 0004 RSI: 8174d824 RDI: 8880979adb30 RBP: 814f1b80 R08: R09: 89bf9867 R10: 000a R11: R12: ffef R13: 0001 R14: dc00 R15: 8880979adb10 tracepoint_probe_register_prio kernel/tracepoint.c:315 [inline] tracepoint_probe_register+0x9c/0xe0 kernel/tracepoint.c:335 trace_event_reg+0x28f/0x350 kernel/trace/trace_events.c:304 perf_trace_event_reg kernel/trace/trace_event_perf.c:129 [inline] perf_trace_event_init+0x532/0x9a0 kernel/trace/trace_event_perf.c:204 perf_trace_init+0x176/0x240 kernel/trace/trace_event_perf.c:228 perf_tp_event_init+0xa2/0x120 kernel/events/core.c:9330 perf_try_init_event+0x12a/0x560 kernel/events/core.c:10782 perf_init_event kernel/events/core.c:10834 [inline] perf_event_alloc.part.0+0xdee/0x36f0 kernel/events/core.c:0 perf_event_alloc kernel/events/core.c:11489 [inline] __do_sys_perf_event_open+0x72c/0x2b50 kernel/events/core.c:11605 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45cb19 Code: Bad RIP value. RSP: 002b:7f2d99608c78 EFLAGS: 0246 ORIG_RAX: 012a RAX: ffda RBX: 004fa640 RCX: 0045cb19 RDX: RSI: RDI: 2100 RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: R13: 0841 R14: 004cb320 R15: 7f2d996096d4 Kernel Offset: disabled --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[RFC PATCH 0/2] i2c: check correct size of maximum RECV_LEN packet
I am preparing to add RECV_LEN support to Renesas I2C drivers. On my way, I found these two peculiarities. Let's discuss them. Wolfram Sang (2): i2c: mlxcpld: check correct size of maximum RECV_LEN packet i2c: octeon: check correct size of maximum RECV_LEN packet drivers/i2c/busses/i2c-mlxcpld.c | 4 ++-- drivers/i2c/busses/i2c-octeon-core.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.20.1
[RFC PATCH 1/2] i2c: mlxcpld: check correct size of maximum RECV_LEN packet
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. I don't see a reason to add 1 here. Also, fix the errno
to what is suggested for this error.
Fixes: c9bfdc7c16cb ("i2c: mlxcpld: Add support for smbus block read
transaction")
Signed-off-by: Wolfram Sang
---
Only build tested, I don't have the HW. Please let me know if I
overlooked something, but to the best of my knowledge, this +1 is wrong.
drivers/i2c/busses/i2c-mlxcpld.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mlxcpld.c b/drivers/i2c/busses/i2c-mlxcpld.c
index 2fd717d8dd30..71d7bae2cbca 100644
--- a/drivers/i2c/busses/i2c-mlxcpld.c
+++ b/drivers/i2c/busses/i2c-mlxcpld.c
@@ -337,9 +337,9 @@ static int mlxcpld_i2c_wait_for_tc(struct mlxcpld_i2c_priv
*priv)
if (priv->smbus_block && (val & MLXCPLD_I2C_SMBUS_BLK_BIT)) {
mlxcpld_i2c_read_comm(priv, MLXCPLD_LPCI2C_NUM_DAT_REG,
, 1);
- if (unlikely(datalen > (I2C_SMBUS_BLOCK_MAX + 1))) {
+ if (unlikely(datalen > I2C_SMBUS_BLOCK_MAX)) {
dev_err(priv->dev, "Incorrect smbus block read
message len\n");
- return -E2BIG;
+ return -EPROTO;
}
} else {
datalen = priv->xfer.data_len;
--
2.20.1
[RFC PATCH 2/2] i2c: octeon: check correct size of maximum RECV_LEN packet
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. I don't see a reason to add 1 here.
Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN")
Signed-off-by: Wolfram Sang
---
Only build tested, I don't have the HW. Please let me know if I
overlooked something, but to the best of my knowledge, this +1 is wrong.
drivers/i2c/busses/i2c-octeon-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-octeon-core.c
b/drivers/i2c/busses/i2c-octeon-core.c
index d9607905dc2f..845eda70b8ca 100644
--- a/drivers/i2c/busses/i2c-octeon-core.c
+++ b/drivers/i2c/busses/i2c-octeon-core.c
@@ -347,7 +347,7 @@ static int octeon_i2c_read(struct octeon_i2c *i2c, int
target,
if (result)
return result;
if (recv_len && i == 0) {
- if (data[i] > I2C_SMBUS_BLOCK_MAX + 1)
+ if (data[i] > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
length += data[i];
}
--
2.20.1
Re: Search function in xconfig is partially broken after recent changes
Em Sun, 28 Jun 2020 14:20:41 +0300
Maxim Levitsky escreveu:
> > But this is not happening. Perhaps this also broke with the Qt5
> > conversion?
> >
> > I suspect it should, instead, use a different signal to handle it.
> >
> > See, with the enclosed patch, clicking on a link will now show:
> >
> > Clicked on URL QUrl("s0x21c3f10")
> > QTextBrowser: No document for s0x21c3f10
> >
> > Which helps to explain what's happening here.
> >
> > See, when debug is turned on, it will create hyperlinks like:
> >
> > head += QString().sprintf("", sym);
> >
> > It seems that the code needs something like:
> >
> > connect (helpText, SIGNAL (anchorClicked (const QUrl &)),
> > helpText, SLOT (clicked (const QUrl &)) );
> >
> > and a handler for this signal that would translate "s%p"
> > back into sym, using such value to update the menus.
> >
> > Do you know if this used to work after Kernel 3.14?
>
> I don't know yet, but I can test it.
>
> I didn't do much kernel developement for lot of time, so I only vaguely
> remember that once upon a time it did work. I don't use this feature much,
> so it might as well be broken back when conversion to Qt5 happened.
> Also worth noting that I probably used Qt4 untill recently when I updated
> to fedora 31, which looks like dropped Qt4 developement packages.
>
> I used to know a thing or two about Qt, long long ago, so on next weekend or
> so,
> I can also take a look at this.
Yeah, I suspect you probably tried it before the Qt5 conversion
patches then.
The enclosed patch is one step further fixing this bug. It still
needs to implement the part of the code which starts using the
selected menu or item.
The first hunk won't apply cleanly, because I added a patch
before it, in order to sort out the include mess, but solving
the conflict is trivial (just add an include for QDebug).
Thanks,
Mauro
diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 631e19659504..b989b6543d7a 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1012,7 +1013,7 @@ ConfigInfoView::ConfigInfoView(QWidget* parent, const
char *name)
: Parent(parent), sym(0), _menu(0)
{
setObjectName(name);
-
+ setOpenLinks(false);
if (!objectName().isEmpty()) {
configSettings->beginGroup(objectName());
@@ -1224,6 +1225,36 @@ void ConfigInfoView::expr_print_help(void *data, struct
symbol *sym, const char
*text += str2;
}
+void ConfigInfoView::clicked(const QUrl )
+{
+ QByteArray str = url.toEncoded();
+ const std::size_t count = str.size();
+ char *hex = new char[count];
+ unsigned long p;
+ struct symbol *sym;
+ struct menu *menu;
+
+ if (count < 1)
+ return;
+
+ memcpy(hex, str.constData(), count);
+ p = (int)strtol(hex + 1, NULL, 16);
+
+ if (!p)
+ return;
+
+ qInfo() << "Clicked on URL" << url;
+
+ if (hex[0] == 's') {
+ sym = (struct symbol *)p;
+
+ qInfo() << "symbol name:" << sym->name;
+ } else {
+ menu = (struct menu *)p;
+ qInfo() << "menu:" << qgettext(menu_get_prompt(menu));
+ }
+}
+
QMenu* ConfigInfoView::createStandardContextMenu(const QPoint & pos)
{
QMenu* popup = Parent::createStandardContextMenu(pos);
@@ -1497,6 +1528,9 @@ ConfigMainWindow::ConfigMainWindow(void)
helpMenu->addAction(showIntroAction);
helpMenu->addAction(showAboutAction);
+ connect (helpText, SIGNAL (anchorClicked (const QUrl &)),
+helpText, SLOT (clicked (const QUrl &)) );
+
connect(configList, SIGNAL(menuChanged(struct menu *)),
helpText, SLOT(setInfo(struct menu *)));
connect(configList, SIGNAL(menuSelected(struct menu *)),
@@ -1601,6 +1635,9 @@ void ConfigMainWindow::searchConfig(void)
void ConfigMainWindow::changeItens(struct menu *menu)
{
+ if (menu->flags & MENU_ROOT)
+ qInfo() << "Wrong type when changing item";
+
configList->setRootMenu(menu);
if (configList->rootEntry->parent == )
@@ -1611,6 +1648,9 @@ void ConfigMainWindow::changeItens(struct menu *menu)
void ConfigMainWindow::changeMenu(struct menu *menu)
{
+ if (!(menu->flags & MENU_ROOT))
+ qInfo() << "Wrong type when changing menu";
+
menuList->setRootMenu(menu);
if (menuList->rootEntry->parent == )
diff --git a/scripts/kconfig/qconf.h b/scripts/kconfig/qconf.h
index d913a02967ae..a193137f2314 100644
--- a/scripts/kconfig/qconf.h
+++ b/scripts/kconfig/qconf.h
@@ -250,6 +250,7 @@ public slots:
void setInfo(struct menu *menu);
void saveSettings(void);
void setShowDebug(bool);
+ void clicked (const QUrl );
signals:
void showDebugChanged(bool);
[PATCH] kconfig: qconf: Fix find on split mode
The logic handling find on split mode is currently broken.
Fix it, making it work again as expected.
Reported-by: Maxim Levitsky
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kconfig/qconf.cc | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index c0ac8f7b5f1a..b8f577c6e8aa 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1645,22 +1645,21 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
return;
list->setRootMenu(parent);
break;
- case symbolMode:
+ case menuMode:
if (menu->flags & MENU_ROOT) {
- configList->setRootMenu(menu);
+ menuList->setRootMenu(menu);
configList->clearSelection();
- list = menuList;
- } else {
list = configList;
+ } else {
+ configList->setRootMenu(menu);
+ configList->clearSelection();
+
parent = menu_get_parent_menu(menu->parent);
if (!parent)
return;
- item = menuList->findConfigItem(parent);
- if (item) {
- item->setSelected(true);
- menuList->scrollToItem(item);
- }
- list->setRootMenu(parent);
+ menuList->setRootMenu(parent);
+
+ list = menuList;
}
break;
case fullMode:
--
2.26.2
Re: [PATCH v3 00/14 RESEND] irqchip: Fix potential resource leaks
On 2020-06-28 12:25, Aleksandar Markovic wrote: сре, 24. јун 2020. у 10:40 Marc Zyngier је написао/ла: On 2020-06-24 08:44, Tiezhu Yang wrote: > [git send-email failed due to too many commands, > so only cc the major related email and resend it, > sorry for that] This is becoming majorly annoying. I don't think this is the right vocabulary to welcome newcomers, however "terrible" thinks they did. Rather, patience, calmness and clear and detailed explanations would work much better - and certainly be much more helpful and useful to the community in the long run. Pray tell how you would have handled this. I expressed *my* personal frustration at a SNR hovering below the 25% mark. I have only indicated that the current course of action was becoming a problem. And instead of taking the moral high ground, maybe you could actually share your wisdom with Teizhu and help him becoming a better contributor? Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH] kconfig: qconf: Fix find on split mode
> The logic handling find on split mode is currently broken. * Is there a word missing in this change description? * Can any information become clearer another bit? > Fix it, … Please replace the beginning of this sentence with the tag “Fixes”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=719fdd32921fb7e3208db8832d32ae1c2d68900f#n183 Regards, Markus
[PATCH] kconfig: qconf: make debug links work again
The Qt5 conversion broke support for debug info links.
Restore the behaviour added by changeset
ab45d190fd4a ("kconfig: create links in info window").
Reported-by: Maxim Levitsky
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kconfig/qconf.cc | 35 ++-
scripts/kconfig/qconf.h | 1 +
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 631e19659504..03cadf27a376 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1012,7 +1012,7 @@ ConfigInfoView::ConfigInfoView(QWidget* parent, const
char *name)
: Parent(parent), sym(0), _menu(0)
{
setObjectName(name);
-
+ setOpenLinks(false);
if (!objectName().isEmpty()) {
configSettings->beginGroup(objectName());
@@ -1224,6 +1224,36 @@ void ConfigInfoView::expr_print_help(void *data, struct
symbol *sym, const char
*text += str2;
}
+void ConfigInfoView::clicked(const QUrl )
+{
+ QByteArray str = url.toEncoded();
+ const std::size_t count = str.size();
+ char *hex = new char[count];
+ unsigned long p;
+
+ if (count < 1)
+ return;
+
+ memcpy(hex, str.constData(), count);
+ p = (int)strtol(hex + 1, NULL, 16);
+
+ if (!p)
+ return;
+
+ if (hex[0] == 's') {
+ struct symbol *s = (struct symbol *)p;
+
+ sym = s;
+ symbolInfo();
+ } else {
+ struct menu *m = (struct menu *)p;
+
+ _menu = m;
+ menuInfo();
+ }
+ emit showDebugChanged(true);
+}
+
QMenu* ConfigInfoView::createStandardContextMenu(const QPoint & pos)
{
QMenu* popup = Parent::createStandardContextMenu(pos);
@@ -1497,6 +1527,9 @@ ConfigMainWindow::ConfigMainWindow(void)
helpMenu->addAction(showIntroAction);
helpMenu->addAction(showAboutAction);
+ connect (helpText, SIGNAL (anchorClicked (const QUrl &)),
+helpText, SLOT (clicked (const QUrl &)) );
+
connect(configList, SIGNAL(menuChanged(struct menu *)),
helpText, SLOT(setInfo(struct menu *)));
connect(configList, SIGNAL(menuSelected(struct menu *)),
diff --git a/scripts/kconfig/qconf.h b/scripts/kconfig/qconf.h
index d913a02967ae..a193137f2314 100644
--- a/scripts/kconfig/qconf.h
+++ b/scripts/kconfig/qconf.h
@@ -250,6 +250,7 @@ public slots:
void setInfo(struct menu *menu);
void saveSettings(void);
void setShowDebug(bool);
+ void clicked (const QUrl );
signals:
void showDebugChanged(bool);
--
2.26.2
Re: [PATCH] kconfig: qconf: make debug links work again
On Sun, 2020-06-28 at 14:21 +0200, Mauro Carvalho Chehab wrote:
> The Qt5 conversion broke support for debug info links.
>
> Restore the behaviour added by changeset
> ab45d190fd4a ("kconfig: create links in info window").
>
> Reported-by: Maxim Levitsky
> Signed-off-by: Mauro Carvalho Chehab
> ---
> scripts/kconfig/qconf.cc | 35 ++-
> scripts/kconfig/qconf.h | 1 +
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> index 631e19659504..03cadf27a376 100644
> --- a/scripts/kconfig/qconf.cc
> +++ b/scripts/kconfig/qconf.cc
> @@ -1012,7 +1012,7 @@ ConfigInfoView::ConfigInfoView(QWidget* parent, const
> char *name)
> : Parent(parent), sym(0), _menu(0)
> {
> setObjectName(name);
> -
> + setOpenLinks(false);
>
> if (!objectName().isEmpty()) {
> configSettings->beginGroup(objectName());
> @@ -1224,6 +1224,36 @@ void ConfigInfoView::expr_print_help(void *data,
> struct symbol *sym, const char
> *text += str2;
> }
>
> +void ConfigInfoView::clicked(const QUrl )
> +{
> + QByteArray str = url.toEncoded();
> + const std::size_t count = str.size();
> + char *hex = new char[count];
> + unsigned long p;
> +
> + if (count < 1)
> + return;
> +
> + memcpy(hex, str.constData(), count);
> + p = (int)strtol(hex + 1, NULL, 16);
> +
> + if (!p)
> + return;
> +
> + if (hex[0] == 's') {
> + struct symbol *s = (struct symbol *)p;
> +
> + sym = s;
> + symbolInfo();
> + } else {
> + struct menu *m = (struct menu *)p;
> +
> + _menu = m;
> + menuInfo();
> + }
> + emit showDebugChanged(true);
> +}
> +
> QMenu* ConfigInfoView::createStandardContextMenu(const QPoint & pos)
> {
> QMenu* popup = Parent::createStandardContextMenu(pos);
> @@ -1497,6 +1527,9 @@ ConfigMainWindow::ConfigMainWindow(void)
> helpMenu->addAction(showIntroAction);
> helpMenu->addAction(showAboutAction);
>
> + connect (helpText, SIGNAL (anchorClicked (const QUrl &)),
> + helpText, SLOT (clicked (const QUrl &)) );
> +
> connect(configList, SIGNAL(menuChanged(struct menu *)),
> helpText, SLOT(setInfo(struct menu *)));
> connect(configList, SIGNAL(menuSelected(struct menu *)),
> diff --git a/scripts/kconfig/qconf.h b/scripts/kconfig/qconf.h
> index d913a02967ae..a193137f2314 100644
> --- a/scripts/kconfig/qconf.h
> +++ b/scripts/kconfig/qconf.h
> @@ -250,6 +250,7 @@ public slots:
> void setInfo(struct menu *menu);
> void saveSettings(void);
> void setShowDebug(bool);
> + void clicked (const QUrl );
>
> signals:
> void showDebugChanged(bool);
Just tested it and it works well. Thank you very much!
Best regards,
Maxim Levitsky
Re: [RFC PATCH v3 0/5] scsi: ufs: Add Host Performance Booster Support
Hi Daejun Seems you intentionally ignored to give you comments on my suggestion. let me provide the reason. Before submitting your next version patch, please check your L2P mapping HPB reqeust submission logical algorithem. I have did performance comparison testing on 4KB, there are about 13% performance drop. Also the hit count is lower. I don't know if this is related to your current work queue scheduling, since you didn't add the timer for each HPB request. Thanks, Bean On Tue, 2020-06-23 at 10:02 +0900, Daejun Park wrote: > Changelog: > > v2 -> v3 > 1. Add checking input module parameter value. > 2. Change base commit from 5.8/scsi-queue to 5.9/scsi-queue. > 3. Cleanup for unused variables and label. > > v1 -> v2 > 1. Change the full boilerplate text to SPDX style. > 2. Adopt dynamic allocation for sub-region data structure. > 3. Cleanup. > > NAND flash memory-based storage devices use Flash Translation Layer > (FTL) > to translate logical addresses of I/O requests to corresponding flash > memory addresses. Mobile storage devices typically have RAM with > constrained size, thus lack in memory to keep the whole mapping > table. > Therefore, mapping tables are partially retrieved from NAND flash on > demand, causing random-read performance degradation. > > To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB > (Host Performance Booster) which uses host system memory as a cache > for the > FTL mapping table. By using HPB, FTL data can be read from host > memory > faster than from NAND flash memory. > > The current version only supports the DCM (device control mode). > This patch consists of 4 parts to support HPB feature. > > 1) UFS-feature layer > 2) HPB probe and initialization process > 3) READ -> HPB READ using cached map information > 4) L2P (logical to physical) map management > > The UFS-feature is an additional layer to avoid the structure in > which the > UFS-core driver and the UFS-feature are entangled with each other in > a > single module. > By adding the layer, UFS-features composed of various combinations > can be > supported. Also, even if a new feature is added, modification of the > UFS-core driver can be minimized. > > In the HPB probe and init process, the device information of the UFS > is > queried. After checking supported features, the data structure for > the HPB > is initialized according to the device information. > > A read I/O in the active sub-region where the map is cached is > changed to > HPB READ by the HPB module. > > The HPB module manages the L2P map using information received from > the > device. For active sub-region, the HPB module caches through > ufshpb_map > request. For the in-active region, the HPB module discards the L2P > map. > When a write I/O occurs in an active sub-region area, associated > dirty > bitmap checked as dirty for preventing stale read. > > HPB is shown to have a performance improvement of 58 - 67% for random > read > workload. [1] > > This series patches are based on the 5.9/scsi-queue branch. > > [1]: > https://www.usenix.org/conference/hotstorage17/program/presentation/jeong > > Daejun park (5): > scsi: ufs: Add UFS feature related parameter > scsi: ufs: Add UFS feature layer > scsi: ufs: Introduce HPB module > scsi: ufs: L2P map management for HPB read > scsi: ufs: Prepare HPB read for cached sub-region > > drivers/scsi/ufs/Kconfig |9 + > drivers/scsi/ufs/Makefile |3 +- > drivers/scsi/ufs/ufs.h| 12 + > drivers/scsi/ufs/ufsfeature.c | 148 +++ > drivers/scsi/ufs/ufsfeature.h | 69 ++ > drivers/scsi/ufs/ufshcd.c | 23 +- > drivers/scsi/ufs/ufshcd.h |3 + > drivers/scsi/ufs/ufshpb.c | 1996 > > drivers/scsi/ufs/ufshpb.h | 234 + > 9 files changed, 2494 insertions(+), 3 deletions(-) > created mode 100644 drivers/scsi/ufs/ufsfeature.c > created mode 100644 drivers/scsi/ufs/ufsfeature.h > created mode 100644 drivers/scsi/ufs/ufshpb.c > created mode 100644 drivers/scsi/ufs/ufshpb.h
Re: [PATCH] kconfig: qconf: Fix find on split mode
Em Sun, 28 Jun 2020 14:18:22 +0200 Markus Elfring escreveu: > > The logic handling find on split mode is currently broken. > > * Is there a word missing in this change description? > > * Can any information become clearer another bit? > > > > Fix it, … > > Please replace the beginning of this sentence with the tag “Fixes”. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=719fdd32921fb7e3208db8832d32ae1c2d68900f#n183 > > Regards, > Markus Please ignore this one. I ended re-submitting a previously merged patch. Thanks, Mauro
[PATCH] kconfig: qconf: cleanup includes
The usage of c-like includes are deprecated on modern Qt versions. So, use the c++ style ones, as described at Qt4/Qt5 documentation. While here, remove uneeded and redundant ones, sorting them on alphabetic order. Signed-off-by: Mauro Carvalho Chehab --- scripts/kconfig/qconf.cc | 27 +-- scripts/kconfig/qconf.h | 14 +++--- 2 files changed, 16 insertions(+), 25 deletions(-) diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc index cf93d3eb09d3..03cadf27a376 100644 --- a/scripts/kconfig/qconf.cc +++ b/scripts/kconfig/qconf.cc @@ -4,27 +4,18 @@ * Copyright (C) 2015 Boris Barbulovski */ -#include - -#include -#include -#include #include +#include +#include +#include #include +#include +#include +#include #include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include +#include +#include +#include #include diff --git a/scripts/kconfig/qconf.h b/scripts/kconfig/qconf.h index 0dc667f0f7cb..a193137f2314 100644 --- a/scripts/kconfig/qconf.h +++ b/scripts/kconfig/qconf.h @@ -3,17 +3,17 @@ * Copyright (C) 2002 Roman Zippel */ -#include -#include -#include +#include +#include #include -#include +#include +#include #include #include -#include #include -#include -#include +#include +#include + #include "expr.h" class ConfigView; -- 2.26.2
[PATCH 2/3] f2fs: support to trace f2fs_bmap()
to show f2fs_bmap()'s result as below:
f2fs_bmap: dev = (251,0), ino = 7, lblock:0, pblock:396800
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 14 +++---
include/trace/events/f2fs.h | 27 +++
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 91dc7b598961..c07a50e4d967 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3713,18 +3713,26 @@ static sector_t f2fs_bmap_compress(struct inode *inode,
sector_t block)
static sector_t f2fs_bmap(struct address_space *mapping, sector_t block)
{
struct inode *inode = mapping->host;
+ struct buffer_head tmp = {
+ .b_size = i_blocksize(inode),
+ };
+ sector_t blknr = 0;
if (f2fs_has_inline_data(inode))
- return 0;
+ goto out;
/* make sure allocating whole blocks */
if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
filemap_write_and_wait(mapping);
if (f2fs_compressed_file(inode))
- return f2fs_bmap_compress(inode, block);
+ blknr = f2fs_bmap_compress(inode, block);
- return generic_block_bmap(mapping, block, get_data_block_bmap);
+ if (!get_data_block_bmap(inode, block, , 0))
+ blknr = tmp.b_blocknr;
+out:
+ trace_f2fs_bmap(inode, block, blknr);
+ return blknr;
}
#ifdef CONFIG_MIGRATION
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
index 8639ab962a71..3d844c51d283 100644
--- a/include/trace/events/f2fs.h
+++ b/include/trace/events/f2fs.h
@@ -1891,6 +1891,33 @@ TRACE_EVENT(f2fs_iostat,
__entry->fs_cdrio, __entry->fs_nrio, __entry->fs_mrio)
);
+TRACE_EVENT(f2fs_bmap,
+
+ TP_PROTO(struct inode *inode, sector_t lblock, sector_t pblock),
+
+ TP_ARGS(inode, lblock, pblock),
+
+ TP_STRUCT__entry(
+ __field(dev_t, dev)
+ __field(ino_t, ino)
+ __field(sector_t, lblock)
+ __field(sector_t, pblock)
+ ),
+
+ TP_fast_assign(
+ __entry->dev= inode->i_sb->s_dev;
+ __entry->ino= inode->i_ino;
+ __entry->lblock = lblock;
+ __entry->pblock = pblock;
+ ),
+
+ TP_printk("dev = (%d,%d), ino = %lu, lblock:%lld, pblock:%lld",
+ show_dev(__entry->dev),
+ __entry->ino,
+ (unsigned long long)__entry->lblock,
+ (unsigned long long)__entry->pblock)
+);
+
#endif /* _TRACE_F2FS_H */
/* This part must be outside protection */
--
2.26.2
[PATCH 3/3] f2fs: support to trace f2fs_fiemap()
to show f2fs_fiemap()'s result as below:
f2fs_fiemap: dev = (251,0), ino = 7, lblock:0, pblock:1625292800, len:2097152,
flags:0, ret:0
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 6 +-
fs/f2fs/inline.c| 2 ++
include/trace/events/f2fs.h | 38 +
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c07a50e4d967..995cf78b23c5 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1813,6 +1813,7 @@ static int f2fs_xattr_fiemap(struct inode *inode,
flags |= FIEMAP_EXTENT_LAST;
err = fiemap_fill_next_extent(fieinfo, 0, phys, len, flags);
+ trace_f2fs_fiemap(inode, 0, phys, len, flags, err);
if (err || err == 1)
return err;
}
@@ -1836,8 +1837,10 @@ static int f2fs_xattr_fiemap(struct inode *inode,
flags = FIEMAP_EXTENT_LAST;
}
- if (phys)
+ if (phys) {
err = fiemap_fill_next_extent(fieinfo, 0, phys, len, flags);
+ trace_f2fs_fiemap(inode, 0, phys, len, flags, err);
+ }
return (err < 0 ? err : 0);
}
@@ -1931,6 +1934,7 @@ int f2fs_fiemap(struct inode *inode, struct
fiemap_extent_info *fieinfo,
ret = fiemap_fill_next_extent(fieinfo, logical,
phys, size, flags);
+ trace_f2fs_fiemap(inode, logical, phys, size, flags, ret);
if (ret)
goto out;
size = 0;
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index dbade310dc79..def4b8481883 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -12,6 +12,7 @@
#include "f2fs.h"
#include "node.h"
+#include
bool f2fs_may_inline_data(struct inode *inode)
{
@@ -776,6 +777,7 @@ int f2fs_inline_data_fiemap(struct inode *inode,
byteaddr += (char *)inline_data_addr(inode, ipage) -
(char *)F2FS_INODE(ipage);
err = fiemap_fill_next_extent(fieinfo, start, byteaddr, ilen, flags);
+ trace_f2fs_fiemap(inode, start, byteaddr, ilen, flags, err);
out:
f2fs_put_page(ipage, 1);
return err;
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
index 3d844c51d283..67202963ef82 100644
--- a/include/trace/events/f2fs.h
+++ b/include/trace/events/f2fs.h
@@ -1918,6 +1918,44 @@ TRACE_EVENT(f2fs_bmap,
(unsigned long long)__entry->pblock)
);
+TRACE_EVENT(f2fs_fiemap,
+
+ TP_PROTO(struct inode *inode, sector_t lblock, sector_t pblock,
+ unsigned long long len, unsigned int flags, int ret),
+
+ TP_ARGS(inode, lblock, pblock, len, flags, ret),
+
+ TP_STRUCT__entry(
+ __field(dev_t, dev)
+ __field(ino_t, ino)
+ __field(sector_t, lblock)
+ __field(sector_t, pblock)
+ __field(unsigned long long, len)
+ __field(unsigned int, flags)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ __entry->dev= inode->i_sb->s_dev;
+ __entry->ino= inode->i_ino;
+ __entry->lblock = lblock;
+ __entry->pblock = pblock;
+ __entry->len= len;
+ __entry->flags = flags;
+ __entry->ret= ret;
+ ),
+
+ TP_printk("dev = (%d,%d), ino = %lu, lblock:%lld, pblock:%lld, "
+ "len:%llu, flags:%u, ret:%d",
+ show_dev(__entry->dev),
+ __entry->ino,
+ (unsigned long long)__entry->lblock,
+ (unsigned long long)__entry->pblock,
+ __entry->len,
+ __entry->flags,
+ __entry->ret)
+);
+
#endif /* _TRACE_F2FS_H */
/* This part must be outside protection */
--
2.26.2
[PATCH 1/3] f2fs: fix wrong return value of f2fs_bmap_compress()
If compression is disable, we should return zero rather than -EOPNOTSUPP to indicate f2fs_bmap() is not supported. Signed-off-by: Chao Yu --- fs/f2fs/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index dfd322515357..91dc7b598961 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -3703,10 +3703,9 @@ static sector_t f2fs_bmap_compress(struct inode *inode, sector_t block) } f2fs_put_dnode(); - return blknr; #else - return -EOPNOTSUPP; + return 0; #endif } -- 2.26.2
[PATCH net-next v4 0/5] hinic: add some ethtool ops support
patch #1: support to set and get pause params with "ethtool -A/a" cmd patch #2: support to set and get irq coalesce params with "ethtool -C/c" cmd patch #3: support to do self test with "ethtool -t" cmd patch #4: support to identify physical device with "ethtool -p" cmd patch #5: support to get eeprom information with "ethtool -m" cmd Luo bin (5): hinic: add support to set and get pause params hinic: add support to set and get irq coalesce hinic: add self test support hinic: add support to identify physical device hinic: add support to get eeprom information drivers/net/ethernet/huawei/hinic/hinic_dev.h | 14 + .../net/ethernet/huawei/hinic/hinic_ethtool.c | 600 +- .../net/ethernet/huawei/hinic/hinic_hw_dev.c | 66 ++ .../net/ethernet/huawei/hinic/hinic_hw_dev.h | 31 + .../net/ethernet/huawei/hinic/hinic_hw_io.h | 10 + .../net/ethernet/huawei/hinic/hinic_hw_mgmt.h | 7 +- .../net/ethernet/huawei/hinic/hinic_main.c| 128 +++- .../net/ethernet/huawei/hinic/hinic_port.c| 194 ++ .../net/ethernet/huawei/hinic/hinic_port.h| 94 +++ drivers/net/ethernet/huawei/hinic/hinic_rx.c | 58 +- .../net/ethernet/huawei/hinic/hinic_sriov.c | 4 +- drivers/net/ethernet/huawei/hinic/hinic_tx.c | 80 +++ drivers/net/ethernet/huawei/hinic/hinic_tx.h | 2 + 13 files changed, 1273 insertions(+), 15 deletions(-) -- 2.17.1
