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 &mm->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 **)&buf, 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 al
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 = &satoz_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 = &samsung_ltn140at29_301,
> + }, {
> + .compatible = "satoz,sat050at40h12r2",
> + .data = &satoz_sat050at40h12r2,
> }, {
> .compatible = "sharp,ld-d5116z01b",
> .data = &sharp_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 = &starry_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 = &shelly_sca07010_bfn_lnn,
> + }, {
> + .compatible = "starry,kr070pe2t",
> + .data = &starry_kr070pe2t,
> }, {
> .compatible = "starry,kr122ea0sra",
> .data = &starry_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 that'
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 ($(KBUILD_EXTRA_WA
[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(&v9ses->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,
- &fcall);
-
- if (err < 0) {
- if (fcall && fcall->id == RWALK)
- goto clunk_fid;
-
- PRINT_FCALL_ERROR("walk error", fcall);
- v9fs_put_idpool(nfid, &v9ses->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(&s);
In the current code, get_line(&s) 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),
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(&s);
>
>
> In the current code, get_line(&s) 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(&pos) 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 -
kernel/crash_
[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, &usable_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, &kernel_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, &crashk_low_res);
if (crashk_res.end && crashk_res.start >= res->start &&
crashk_res.end <= res->end)
request_resource(res, &crashk_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(),
&crash_size, &crash_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(&crashk_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,
&low_size, &base);
- 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(&iomem_resource, &crashk_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(&iomem_resource, &crashk_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);
i
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-
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, &md)) {
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,
&entry_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, &entry_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
[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;
+ S
[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 VHOST_IOTLB_ACCESS_F
[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_st
[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 = &dev->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 0001
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) {
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 n
[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&m=159333034726647&w=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&m=159333034726647&w=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 siz
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] ? kthread_park
[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(&r->entropy_count, orig, entropy_count) != orig)
goto retry;
- if (has_initialized) {
- r->initialized = 1;
- kill_fasync(&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,
&datalen, 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 &url)
+{
+ 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 == &rootmenu)
@@ -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 == &rootmenu)
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 &url);
signals:
void showDebugChang
[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 &url)
+{
+ 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 &url);
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 &url)
> +{
> + 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 &url);
>
> 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, &tmp, 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(&dn); - 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
[PATCH net-next v4 4/5] hinic: add support to identify physical device
add support to identify physical device by flashing an LED
attached to it with ethtool -p cmd.
Signed-off-by: Luo bin
---
.../net/ethernet/huawei/hinic/hinic_ethtool.c | 34
.../net/ethernet/huawei/hinic/hinic_hw_dev.c | 2 +
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 1 +
.../net/ethernet/huawei/hinic/hinic_hw_mgmt.h | 4 +-
.../net/ethernet/huawei/hinic/hinic_port.c| 55 +++
.../net/ethernet/huawei/hinic/hinic_port.h| 35
.../net/ethernet/huawei/hinic/hinic_sriov.c | 4 +-
7 files changed, 132 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index 2c94b48692c9..f012d136b7b6 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -1684,6 +1684,39 @@ static void hinic_diag_test(struct net_device *netdev,
netif_carrier_on(netdev);
}
+static int hinic_set_phys_id(struct net_device *netdev,
+enum ethtool_phys_id_state state)
+{
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+ int err = 0;
+ u8 port;
+
+ port = nic_dev->hwdev->port_id;
+
+ switch (state) {
+ case ETHTOOL_ID_ACTIVE:
+ err = hinic_set_led_status(nic_dev->hwdev, port,
+ HINIC_LED_TYPE_LINK,
+ HINIC_LED_MODE_FORCE_2HZ);
+ if (err)
+ netif_err(nic_dev, drv, netdev,
+ "Set LED blinking in 2HZ failed\n");
+ break;
+
+ case ETHTOOL_ID_INACTIVE:
+ err = hinic_reset_led_status(nic_dev->hwdev, port);
+ if (err)
+ netif_err(nic_dev, drv, netdev,
+ "Reset LED to original status failed\n");
+ break;
+
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return err;
+}
+
static const struct ethtool_ops hinic_ethtool_ops = {
.supported_coalesce_params = ETHTOOL_COALESCE_RX_USECS |
ETHTOOL_COALESCE_RX_MAX_FRAMES |
@@ -1714,6 +1747,7 @@ static const struct ethtool_ops hinic_ethtool_ops = {
.get_ethtool_stats = hinic_get_ethtool_stats,
.get_strings = hinic_get_strings,
.self_test = hinic_diag_test,
+ .set_phys_id = hinic_set_phys_id,
};
static const struct ethtool_ops hinicvf_ethtool_ops = {
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
index 4de50e4ba4df..45c137827a16 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
@@ -83,6 +83,8 @@ static int parse_capability(struct hinic_hwdev *hwdev,
nic_cap->max_vf_qps = dev_cap->max_vf_sqs + 1;
}
+ hwdev->port_id = dev_cap->port_id;
+
return 0;
}
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
index c92c39a50b81..01fe94f2d4bc 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
@@ -312,6 +312,7 @@ struct hinic_hwdev {
struct hinic_mbox_func_to_func *func_to_func;
struct hinic_capnic_cap;
+ u8 port_id;
};
struct hinic_nic_cb {
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.h
b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.h
index a3349ae30ff3..919d2c6ffc35 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.h
@@ -81,7 +81,9 @@ enum hinic_comm_cmd {
HINIC_COMM_CMD_MSI_CTRL_REG_WR_BY_UP,
HINIC_COMM_CMD_MSI_CTRL_REG_RD_BY_UP,
- HINIC_COMM_CMD_L2NIC_RESET = 0x4b,
+ HINIC_COMM_CMD_SET_LED_STATUS = 0x4a,
+
+ HINIC_COMM_CMD_L2NIC_RESET = 0x4b,
HINIC_COMM_CMD_PAGESIZE_SET = 0x50,
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.c
b/drivers/net/ethernet/huawei/hinic/hinic_port.c
index 98ea3f781611..116ca1c877f2 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.c
@@ -1268,3 +1268,58 @@ int hinic_set_loopback_mode(struct hinic_hwdev *hwdev,
u32 mode, u32 enable)
return 0;
}
+
+static int _set_led_status(struct hinic_hwdev *hwdev, u8 port,
+ enum hinic_led_type type,
+ enum hinic_led_mode mode, u8 reset)
+{
+ struct hinic_led_info led_info = {0};
+ u16 out_size = sizeof(led_info);
+ struct hinic_pfhwdev *pfhwdev;
+ int err;
+
+ pfhwdev = container_of(hwdev, struct hinic_pfhwdev, hwdev);
+
+ led_info.port = port;
+ led_info.reset = reset;
+
+ led_in
[PATCH net-next v4 5/5] hinic: add support to get eeprom information
add support to get eeprom information from the plug-in module
with ethtool -m cmd.
Signed-off-by: Luo bin
---
.../net/ethernet/huawei/hinic/hinic_ethtool.c | 69 ++
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 4 ++
.../net/ethernet/huawei/hinic/hinic_port.c| 72 +++
.../net/ethernet/huawei/hinic/hinic_port.h| 30
4 files changed, 175 insertions(+)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index f012d136b7b6..a4a2a2d68f5c 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "hinic_hw_qp.h"
#include "hinic_hw_dev.h"
@@ -1717,6 +1718,72 @@ static int hinic_set_phys_id(struct net_device *netdev,
return err;
}
+static int hinic_get_module_info(struct net_device *netdev,
+struct ethtool_modinfo *modinfo)
+{
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+ u8 sfp_type_ext;
+ u8 sfp_type;
+ int err;
+
+ err = hinic_get_sfp_type(nic_dev->hwdev, &sfp_type, &sfp_type_ext);
+ if (err)
+ return err;
+
+ switch (sfp_type) {
+ case SFF8024_ID_SFP:
+ modinfo->type = ETH_MODULE_SFF_8472;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
+ break;
+ case SFF8024_ID_QSFP_8438:
+ modinfo->type = ETH_MODULE_SFF_8436;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8436_MAX_LEN;
+ break;
+ case SFF8024_ID_QSFP_8436_8636:
+ if (sfp_type_ext >= 0x3) {
+ modinfo->type = ETH_MODULE_SFF_8636;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8636_MAX_LEN;
+
+ } else {
+ modinfo->type = ETH_MODULE_SFF_8436;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8436_MAX_LEN;
+ }
+ break;
+ case SFF8024_ID_QSFP28_8636:
+ modinfo->type = ETH_MODULE_SFF_8636;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8636_MAX_LEN;
+ break;
+ default:
+ netif_warn(nic_dev, drv, netdev,
+ "Optical module unknown: 0x%x\n", sfp_type);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int hinic_get_module_eeprom(struct net_device *netdev,
+ struct ethtool_eeprom *ee, u8 *data)
+{
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+ u8 sfp_data[STD_SFP_INFO_MAX_SIZE];
+ u16 len;
+ int err;
+
+ if (!ee->len || ((ee->len + ee->offset) > STD_SFP_INFO_MAX_SIZE))
+ return -EINVAL;
+
+ memset(data, 0, ee->len);
+
+ err = hinic_get_sfp_eeprom(nic_dev->hwdev, sfp_data, &len);
+ if (err)
+ return err;
+
+ memcpy(data, sfp_data + ee->offset, ee->len);
+
+ return 0;
+}
+
static const struct ethtool_ops hinic_ethtool_ops = {
.supported_coalesce_params = ETHTOOL_COALESCE_RX_USECS |
ETHTOOL_COALESCE_RX_MAX_FRAMES |
@@ -1748,6 +1815,8 @@ static const struct ethtool_ops hinic_ethtool_ops = {
.get_strings = hinic_get_strings,
.self_test = hinic_diag_test,
.set_phys_id = hinic_set_phys_id,
+ .get_module_info = hinic_get_module_info,
+ .get_module_eeprom = hinic_get_module_eeprom,
};
static const struct ethtool_ops hinicvf_ethtool_ops = {
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
index 01fe94f2d4bc..958ea1a6a60d 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
@@ -130,9 +130,13 @@ enum hinic_port_cmd {
HINIC_PORT_CMD_SET_AUTONEG = 219,
+ HINIC_PORT_CMD_GET_STD_SFP_INFO = 240,
+
HINIC_PORT_CMD_SET_LRO_TIMER= 244,
HINIC_PORT_CMD_SET_VF_MAX_MIN_RATE = 249,
+
+ HINIC_PORT_CMD_GET_SFP_ABS = 251,
};
/* cmd of mgmt CPU message for HILINK module */
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.c
b/drivers/net/ethernet/huawei/hinic/hinic_port.c
index 116ca1c877f2..ba358bbb74a2 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.c
@@ -1323,3 +1323,75 @@ int hinic_reset_led_status(struct hinic_hwdev *hwdev, u8
port)
return err;
}
+
+static bool hinic_if_sfp_absent(struct hinic_hwdev *hwdev)
+{
+ struct hinic_cmd_get_light_module_abs sfp_abs = {0};
+ u16 out_size = sizeof(sfp_abs);
+ u8 port_id = hwdev->port_id;
+ int err;
+
+ sfp_abs.port_id = port_id;
+ err = hinic_port_msg_cmd(hwdev, HINIC_PORT_CMD_GET_SFP_ABS,
+&sfp_abs, sizeof(sfp_abs), &sfp_abs,
+
[PATCH net-next v4 2/5] hinic: add support to set and get irq coalesce
add support to set TX/RX irq coalesce params with ethtool -C and
get these params with ethtool -c.
Signed-off-by: Luo bin
---
drivers/net/ethernet/huawei/hinic/hinic_dev.h | 8 +
.../net/ethernet/huawei/hinic/hinic_ethtool.c | 234 ++
.../net/ethernet/huawei/hinic/hinic_hw_dev.c | 62 +
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 21 ++
.../net/ethernet/huawei/hinic/hinic_hw_mgmt.h | 3 +
.../net/ethernet/huawei/hinic/hinic_main.c| 53
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 19 +-
drivers/net/ethernet/huawei/hinic/hinic_tx.c | 19 ++
8 files changed, 418 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
index 48b40be3e84d..75d6dee948f5 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
@@ -49,6 +49,12 @@ enum hinic_rss_hash_type {
HINIC_RSS_HASH_ENGINE_TYPE_MAX,
};
+struct hinic_intr_coal_info {
+ u8 pending_limt;
+ u8 coalesce_timer_cfg;
+ u8 resend_timer_cfg;
+};
+
struct hinic_dev {
struct net_device *netdev;
struct hinic_hwdev *hwdev;
@@ -82,6 +88,8 @@ struct hinic_dev {
struct hinic_rss_type rss_type;
u8 *rss_hkey_user;
s32 *rss_indir_user;
+ struct hinic_intr_coal_info *rx_intr_coalesce;
+ struct hinic_intr_coal_info *tx_intr_coalesce;
struct hinic_sriov_info sriov_info;
};
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index edd60c892ab2..8e5c326c7687 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -49,6 +49,13 @@
#define ETHTOOL_ADD_ADVERTISED_LINK_MODE(ecmd, mode) \
((ecmd)->advertising |= ADVERTISED_##mode)
+#define COALESCE_PENDING_LIMIT_UNIT8
+#defineCOALESCE_TIMER_CFG_UNIT 9
+#define COALESCE_ALL_QUEUE 0x
+#define COALESCE_MAX_PENDING_LIMIT (255 * COALESCE_PENDING_LIMIT_UNIT)
+#define COALESCE_MAX_TIMER_CFG (255 * COALESCE_TIMER_CFG_UNIT)
+#define OBJ_STR_MAX_LEN32
+
struct hw2ethtool_link_mode {
enum ethtool_link_mode_bit_indices link_mode_bit;
u32 speed;
@@ -614,6 +621,215 @@ static int hinic_set_ringparam(struct net_device *netdev,
return 0;
}
+static int __hinic_get_coalesce(struct net_device *netdev,
+ struct ethtool_coalesce *coal, u16 queue)
+{
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+ struct hinic_intr_coal_info *rx_intr_coal_info;
+ struct hinic_intr_coal_info *tx_intr_coal_info;
+
+ if (queue == COALESCE_ALL_QUEUE) {
+ /* get tx/rx irq0 as default parameters */
+ rx_intr_coal_info = &nic_dev->rx_intr_coalesce[0];
+ tx_intr_coal_info = &nic_dev->tx_intr_coalesce[0];
+ } else {
+ if (queue >= nic_dev->num_qps) {
+ netif_err(nic_dev, drv, netdev,
+ "Invalid queue_id: %d\n", queue);
+ return -EINVAL;
+ }
+ rx_intr_coal_info = &nic_dev->rx_intr_coalesce[queue];
+ tx_intr_coal_info = &nic_dev->tx_intr_coalesce[queue];
+ }
+
+ /* coalesce_timer is in unit of 9us */
+ coal->rx_coalesce_usecs = rx_intr_coal_info->coalesce_timer_cfg *
+ COALESCE_TIMER_CFG_UNIT;
+ /* coalesced_frames is in unit of 8 */
+ coal->rx_max_coalesced_frames = rx_intr_coal_info->pending_limt *
+ COALESCE_PENDING_LIMIT_UNIT;
+ coal->tx_coalesce_usecs = tx_intr_coal_info->coalesce_timer_cfg *
+ COALESCE_TIMER_CFG_UNIT;
+ coal->tx_max_coalesced_frames = tx_intr_coal_info->pending_limt *
+ COALESCE_PENDING_LIMIT_UNIT;
+
+ return 0;
+}
+
+static int is_coalesce_exceed_limit(const struct ethtool_coalesce *coal)
+{
+ if (coal->rx_coalesce_usecs > COALESCE_MAX_TIMER_CFG ||
+ coal->rx_max_coalesced_frames > COALESCE_MAX_PENDING_LIMIT ||
+ coal->tx_coalesce_usecs > COALESCE_MAX_TIMER_CFG ||
+ coal->tx_max_coalesced_frames > COALESCE_MAX_PENDING_LIMIT)
+ return -ERANGE;
+
+ return 0;
+}
+
+static int set_queue_coalesce(struct hinic_dev *nic_dev, u16 q_id,
+ struct hinic_intr_coal_info *coal,
+ bool set_rx_coal)
+{
+ struct hinic_intr_coal_info *intr_coal = NULL;
+ struct hinic_msix_config interrupt_info = {0};
+ struct net_device *netdev = nic_dev->netdev;
+ u16 msix_idx;
+ int err;
+
+ intr_coal = set_rx_coal ? &nic_dev->rx_intr_
[PATCH net-next v4 1/5] hinic: add support to set and get pause params
add support to set pause params with ethtool -A and get pause
params with ethtool -a. Also remove set_link_ksettings ops for VF
and enable pause by default.
Signed-off-by: Luo bin
---
.../net/ethernet/huawei/hinic/hinic_ethtool.c | 86 ++-
.../net/ethernet/huawei/hinic/hinic_hw_dev.c | 2 +
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 +
.../net/ethernet/huawei/hinic/hinic_hw_io.h | 10 +++
.../net/ethernet/huawei/hinic/hinic_main.c| 75 +---
.../net/ethernet/huawei/hinic/hinic_port.c| 40 +
.../net/ethernet/huawei/hinic/hinic_port.h| 13 +++
7 files changed, 217 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index efb02e03e7da..edd60c892ab2 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -613,6 +613,64 @@ static int hinic_set_ringparam(struct net_device *netdev,
return 0;
}
+
+static void hinic_get_pauseparam(struct net_device *netdev,
+struct ethtool_pauseparam *pause)
+{
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+ struct hinic_pause_config pause_info = {0};
+ struct hinic_nic_cfg *nic_cfg;
+ int err;
+
+ nic_cfg = &nic_dev->hwdev->func_to_io.nic_cfg;
+
+ err = hinic_get_hw_pause_info(nic_dev->hwdev, &pause_info);
+ if (!err) {
+ pause->autoneg = pause_info.auto_neg;
+ if (nic_cfg->pause_set || !pause_info.auto_neg) {
+ pause->rx_pause = nic_cfg->rx_pause;
+ pause->tx_pause = nic_cfg->tx_pause;
+ } else {
+ pause->rx_pause = pause_info.rx_pause;
+ pause->tx_pause = pause_info.tx_pause;
+ }
+ }
+}
+
+static int hinic_set_pauseparam(struct net_device *netdev,
+ struct ethtool_pauseparam *pause)
+{
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+ struct hinic_pause_config pause_info = {0};
+ struct hinic_port_cap port_cap = {0};
+ int err;
+
+ err = hinic_port_get_cap(nic_dev, &port_cap);
+ if (err)
+ return -EIO;
+
+ if (pause->autoneg != port_cap.autoneg_state)
+ return -EOPNOTSUPP;
+
+ pause_info.auto_neg = pause->autoneg;
+ pause_info.rx_pause = pause->rx_pause;
+ pause_info.tx_pause = pause->tx_pause;
+
+ mutex_lock(&nic_dev->hwdev->func_to_io.nic_cfg.cfg_mutex);
+ err = hinic_set_hw_pause_info(nic_dev->hwdev, &pause_info);
+ if (err) {
+ mutex_unlock(&nic_dev->hwdev->func_to_io.nic_cfg.cfg_mutex);
+ return err;
+ }
+ nic_dev->hwdev->func_to_io.nic_cfg.pause_set = true;
+ nic_dev->hwdev->func_to_io.nic_cfg.auto_neg = pause->autoneg;
+ nic_dev->hwdev->func_to_io.nic_cfg.rx_pause = pause->rx_pause;
+ nic_dev->hwdev->func_to_io.nic_cfg.tx_pause = pause->tx_pause;
+ mutex_unlock(&nic_dev->hwdev->func_to_io.nic_cfg.cfg_mutex);
+
+ return 0;
+}
+
static void hinic_get_channels(struct net_device *netdev,
struct ethtool_channels *channels)
{
@@ -1241,6 +1299,27 @@ static const struct ethtool_ops hinic_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_ringparam = hinic_get_ringparam,
.set_ringparam = hinic_set_ringparam,
+ .get_pauseparam = hinic_get_pauseparam,
+ .set_pauseparam = hinic_set_pauseparam,
+ .get_channels = hinic_get_channels,
+ .set_channels = hinic_set_channels,
+ .get_rxnfc = hinic_get_rxnfc,
+ .set_rxnfc = hinic_set_rxnfc,
+ .get_rxfh_key_size = hinic_get_rxfh_key_size,
+ .get_rxfh_indir_size = hinic_get_rxfh_indir_size,
+ .get_rxfh = hinic_get_rxfh,
+ .set_rxfh = hinic_set_rxfh,
+ .get_sset_count = hinic_get_sset_count,
+ .get_ethtool_stats = hinic_get_ethtool_stats,
+ .get_strings = hinic_get_strings,
+};
+
+static const struct ethtool_ops hinicvf_ethtool_ops = {
+ .get_link_ksettings = hinic_get_link_ksettings,
+ .get_drvinfo = hinic_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_ringparam = hinic_get_ringparam,
+ .set_ringparam = hinic_set_ringparam,
.get_channels = hinic_get_channels,
.set_channels = hinic_set_channels,
.get_rxnfc = hinic_get_rxnfc,
@@ -1256,5 +1335,10 @@ static const struct ethtool_ops hinic_ethtool_ops = {
void hinic_set_ethtool_ops(struct net_device *netdev)
{
- netdev->ethtool_ops = &hinic_ethtool_ops;
+ struct hinic_dev *nic_dev = netdev_priv(netdev);
+
+ if (!HINIC_IS_VF(nic_dev->hwdev->hwif))
+ netdev->ethtool_ops = &hinic_ethtool_ops;
+ else
+ netdev->ethtool_ops = &hinicvf_ethtool_ops;
}
diff --git a/drivers/net/ethernet/huawei/hinic
[PATCH net-next v4 3/5] hinic: add self test support
add support to excute internal and external loopback test with
ethtool -t cmd.
Signed-off-by: Luo bin
---
drivers/net/ethernet/huawei/hinic/hinic_dev.h | 6 +
.../net/ethernet/huawei/hinic/hinic_ethtool.c | 177 ++
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 3 +
.../net/ethernet/huawei/hinic/hinic_port.c| 27 +++
.../net/ethernet/huawei/hinic/hinic_port.h| 16 ++
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 39
drivers/net/ethernet/huawei/hinic/hinic_tx.c | 61 ++
drivers/net/ethernet/huawei/hinic/hinic_tx.h | 2 +
8 files changed, 331 insertions(+)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
index 75d6dee948f5..9adb755f0820 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
@@ -20,11 +20,14 @@
#define HINIC_DRV_NAME "hinic"
+#define LP_PKT_CNT 64
+
enum hinic_flags {
HINIC_LINK_UP = BIT(0),
HINIC_INTF_UP = BIT(1),
HINIC_RSS_ENABLE = BIT(2),
HINIC_LINK_DOWN = BIT(3),
+ HINIC_LP_TEST = BIT(4),
};
struct hinic_rx_mode_work {
@@ -91,6 +94,9 @@ struct hinic_dev {
struct hinic_intr_coal_info *rx_intr_coalesce;
struct hinic_intr_coal_info *tx_intr_coalesce;
struct hinic_sriov_info sriov_info;
+ int lb_test_rx_idx;
+ int lb_pkt_len;
+ u8 *lb_test_rx_buf;
};
#endif
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index 8e5c326c7687..2c94b48692c9 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -133,6 +133,16 @@ static struct hw2ethtool_link_mode
},
};
+#define LP_DEFAULT_TIME 5 /* seconds */
+#define LP_PKT_LEN 1514
+
+#define PORT_DOWN_ERR_IDX 0
+enum diag_test_index {
+ INTERNAL_LP_TEST = 0,
+ EXTERNAL_LP_TEST = 1,
+ DIAG_TEST_MAX = 2,
+};
+
static void set_link_speed(struct ethtool_link_ksettings *link_ksettings,
enum hinic_speed speed)
{
@@ -1244,6 +1254,11 @@ static struct hinic_stats hinic_function_stats[] = {
HINIC_FUNC_STAT(rx_err_vport),
};
+static char hinic_test_strings[][ETH_GSTRING_LEN] = {
+ "Internal lb test (on/offline)",
+ "External lb test (external_lb)",
+};
+
#define HINIC_PORT_STAT(_stat_item) { \
.name = #_stat_item, \
.size = sizeof_field(struct hinic_phy_port_stats, _stat_item), \
@@ -1453,6 +1468,8 @@ static int hinic_get_sset_count(struct net_device
*netdev, int sset)
int count, q_num;
switch (sset) {
+ case ETH_SS_TEST:
+ return ARRAY_LEN(hinic_test_strings);
case ETH_SS_STATS:
q_num = nic_dev->num_qps;
count = ARRAY_LEN(hinic_function_stats) +
@@ -1475,6 +1492,9 @@ static void hinic_get_strings(struct net_device *netdev,
u16 i, j;
switch (stringset) {
+ case ETH_SS_TEST:
+ memcpy(data, *hinic_test_strings, sizeof(hinic_test_strings));
+ return;
case ETH_SS_STATS:
for (i = 0; i < ARRAY_LEN(hinic_function_stats); i++) {
memcpy(p, hinic_function_stats[i].name,
@@ -1508,6 +1528,162 @@ static void hinic_get_strings(struct net_device *netdev,
}
}
+static int hinic_run_lp_test(struct hinic_dev *nic_dev, u32 test_time)
+{
+ u8 *lb_test_rx_buf = nic_dev->lb_test_rx_buf;
+ struct net_device *netdev = nic_dev->netdev;
+ struct sk_buff *skb_tmp = NULL;
+ struct sk_buff *skb = NULL;
+ u32 cnt = test_time * 5;
+ u8 *test_data = NULL;
+ u32 i;
+ u8 j;
+
+ skb_tmp = alloc_skb(LP_PKT_LEN, GFP_ATOMIC);
+ if (!skb_tmp)
+ return -ENOMEM;
+
+ test_data = __skb_put(skb_tmp, LP_PKT_LEN);
+
+ memset(test_data, 0xFF, 2 * ETH_ALEN);
+ test_data[ETH_ALEN] = 0xFE;
+ test_data[2 * ETH_ALEN] = 0x08;
+ test_data[2 * ETH_ALEN + 1] = 0x0;
+
+ for (i = ETH_HLEN; i < LP_PKT_LEN; i++)
+ test_data[i] = i & 0xFF;
+
+ skb_tmp->queue_mapping = 0;
+ skb_tmp->ip_summed = CHECKSUM_COMPLETE;
+ skb_tmp->dev = netdev;
+
+ for (i = 0; i < cnt; i++) {
+ nic_dev->lb_test_rx_idx = 0;
+ memset(lb_test_rx_buf, 0, LP_PKT_CNT * LP_PKT_LEN);
+
+ for (j = 0; j < LP_PKT_CNT; j++) {
+ skb = pskb_copy(skb_tmp, GFP_ATOMIC);
+ if (!skb) {
+ dev_kfree_skb_any(skb_tmp);
+ netif_err(nic_dev, drv, netdev,
+ "Copy skb failed for loopback
test\n");
+
Re: [PATCH] ext4: fix direct I/O read error
> Signed-off-by: jiangying8582 Please use the real name for your contributions. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=719fdd32921fb7e3208db8832d32ae1c2d68900f#n431 Would you like to add the tag “Fixes” to the commit message? Regards, Markus
Re: [PATCH v3 00/14 RESEND] irqchip: Fix potential resource leaks
нед, 28. јун 2020. у 14:06 Marc Zyngier је написао/ла: > > 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? > He will improve. This initial clumsiness is normal. It could have been avoided, true - for example, if he had had someone more experienced at hand, preferably a co-worker. He obviously acts alone. It will be better. > Thanks, > > M. > -- > Jazz is not dead. It just smells funny...
Re: Commit 'fs: Do not check if there is a fsnotify watcher on pseudo inodes' breaks chromium here
On Sun, Jun 28, 2020 at 2:14 PM Maxim Levitsky wrote: > > Hi, > > I just did usual kernel update and now chromium crashes on startup. > It happens both in a KVM's VM (with virtio-gpu if that matters) and natively > with amdgpu driver. > Most likely not GPU related although I initially suspected that it is. > > Chromium starts as a white rectangle, shows few white rectangles > that resemble its notifications and then crashes. > > The stdout output from chromium: > [...] > Received signal 6 > #0 0x55f6da0120d9 base::debug::CollectStackTrace() > #1 0x55f6d9f75246 base::debug::StackTrace::StackTrace() > #2 0x55f6da01170a base::debug::(anonymous namespace)::StackDumpSignalHandler() > #3 0x55f6da011cfe base::debug::(anonymous namespace)::StackDumpSignalHandler() > #4 0x7ff46643ab20 (/usr/lib64/libpthread-2.30.so+0x14b1f) > #5 0x7ff462d87625 __GI_raise > #6 0x7ff462d708d9 __GI_abort > #7 0x55f6da0112d5 base::debug::BreakDebugger() > #8 0x55f6d9f86405 logging::LogMessage::~LogMessage() > #9 0x55f6d7ed5488 content::(anonymous > namespace)::IntentionallyCrashBrowserForUnusableGpuProcess() > #10 0x55f6d7ed8479 content::GpuDataManagerImplPrivate::FallBackToNextGpuMode() > #11 0x55f6d7ed4eef content::GpuDataManagerImpl::FallBackToNextGpuMode() > #12 0x55f6d7ee0f41 content::GpuProcessHost::RecordProcessCrash() > #13 0x55f6d7ee105d content::GpuProcessHost::OnProcessCrashed() > #14 0x55f6d7cbe308 content::BrowserChildProcessHostImpl::OnChildDisconnected() > #15 0x55f6da8b511a IPC::ChannelMojo::OnPipeError() > #16 0x55f6da13cd62 mojo::InterfaceEndpointClient::NotifyError() > #17 0x55f6da8c1f9d IPC::(anonymous > namespace)::ChannelAssociatedGroupController::OnPipeError() > #18 0x55f6da138968 mojo::Connector::HandleError() > #19 0x55f6da15bce7 mojo::SimpleWatcher::OnHandleReady() > #20 0x55f6da15c0fb mojo::SimpleWatcher::Context::CallNotify() > #21 0x55f6d78eaa73 mojo::core::WatcherDispatcher::InvokeWatchCallback() > #22 0x55f6d78ea38f mojo::core::Watch::InvokeCallback() > #23 0x55f6d78e6efa mojo::core::RequestContext::~RequestContext() > #24 0x55f6d78db76a mojo::core::NodeChannel::OnChannelError() > #25 0x55f6d78f232a mojo::core::(anonymous > namespace)::ChannelPosix::OnFileCanReadWithoutBlocking() > #26 0x55f6da03345e base::MessagePumpLibevent::OnLibeventNotification() > #27 0x55f6da0f9b2d event_base_loop > #28 0x55f6da03316d base::MessagePumpLibevent::Run() > #29 0x55f6d9fd79c9 > base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run() > #30 0x55f6d9fada7a base::RunLoop::Run() > #31 0x55f6d7ce6324 content::BrowserProcessSubThread::IOThreadRun() > #32 0x55f6d9fe0cb8 base::Thread::ThreadMain() > #33 0x55f6da024705 base::(anonymous namespace)::ThreadFunc() > #34 0x7ff46642f4e2 start_thread > #35 0x7ff462e4c6a3 __GI___clone > r8: r9: 7ff44e6a58d0 r10: 0008 r11: > 0246 > r12: 7ff44e6a6b40 r13: 7ff44e6a6d00 r14: 006d r15: > 7ff44e6a6b30 > di: 0002 si: 7ff44e6a58d0 bp: 7ff44e6a5b20 bx: > 7ff44e6a9700 > dx: ax: cx: 7ff462d87625 sp: > 7ff44e6a58d0 > ip: 7ff462d87625 efl: 0246 cgf: 002b0033 erf: > > trp: msk: cr2: > [end of stack trace] > Calling _exit(1). Core file will not be generated. > > I guess this answers our question whether we could disable fsnoitfy watches on pseudo inodes >From comments like these in chromium code: https://chromium.googlesource.com/chromium/src/+/master/mojo/core/watcher_dispatcher.cc#77 https://chromium.googlesource.com/chromium/src/+/master/base/files/file_descriptor_watcher_posix.cc#176 https://chromium.googlesource.com/chromium/src/+/master/ipc/ipc_channel_mojo.cc#240 I am taking a wild guess that the missing FS_CLOSE event on anonymous pipes is the cause for regression. The motivation for the patch "fs: Do not check if there is a fsnotify watcher on pseudo inodes" was performance, but actually, FS_CLOSE and FS_OPEN events probably do not impact performance as FS_MODIFY and FS_ACCESS. Mel, Do your perf results support the claim above? Jan/Linus, Do you agree that dropping FS_MODIFY/FS_ACCESS events for FMODE_STREAM files as a general rule should be safe? Maxim, can you try if the attached patch fixes the chromium regression. It is expected to leave the FS_OPEN/FS_CLOSE events on anonymous pipes but drop the FS_MODIFY/FS_ACCESS events. Thanks, Amir. From a81c729a5c52ddb2d8d98220478e492b71956574 Mon Sep 17 00:00:00 2001 From: Amir Goldstein Date: Sun, 28 Jun 2020 15:36:56 +0300 Subject: [PATCH] fsnotify: suppress access/modify events on stream files We wanted to suppress all fsnotify events on anonymous pipes/sockets, but chromioum seems to be relying on some of those events. Let's try to suppress only access/modify events on stream files. Reported-by: Maxim Levitsky Link: https://lore.kernel.org/lkml/7b4aa1e98
Re: [PATCH v2 2/2] PCI/ERR: Add reset support for non fatal errors
Hi Sathy, one minor comments below. On 2020/6/5 5:50, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > PCI_ERS_RESULT_NEED_RESET error status implies the device is > requesting a slot reset and a notification about slot reset > completion via ->slot_reset() callback. > > But in non-fatal errors case, if report_error_detected() or > report_mmio_enabled() functions requests PCI_ERS_RESULT_NEED_RESET > then current pcie_do_recovery() implementation does not do the > requested explicit slot reset, instead just calls the ->slot_reset() > callback on all affected devices. Notifying about the slot reset > completion without resetting it incorrect. So add this support. > > Signed-off-by: Kuppuswamy Sathyanarayanan > > --- > drivers/pci/pcie/err.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c > index 5fe8561c7185..94d1c2ff7b40 100644 > --- a/drivers/pci/pcie/err.c > +++ b/drivers/pci/pcie/err.c > @@ -206,6 +206,9 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, >* functions to reset slot before calling >* drivers' slot_reset callbacks? >*/ > + if (state != pci_channel_io_frozen) > + pci_reset_bus(dev); > + If it's the implementation to reset the slot, should we remove the TODO comments? JYI. Thanks, Yicong > status = PCI_ERS_RESULT_RECOVERED; > pci_dbg(dev, "broadcast slot_reset message\n"); > pci_walk_bus(bus, report_slot_reset, &status);
Re: [PATCH net-next v3 0/2] bridge: mrp: Extend MRP netlink interface with IFLA_BRIDGE_MRP_CLEAR
The 06/26/2020 13:00, David Miller wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > From: Horatiu Vultur > Date: Fri, 26 Jun 2020 09:33:47 +0200 > > > This patch series extends MRP netlink interface with IFLA_BRIDGE_MRP_CLEAR. > > To allow the userspace to clear all MRP instances when is started. The > > second patch in the series fix different sparse warnings. > > > > v3: > > - add the second patch to fix sparse warnings Hi, > > These changes are completely unrelated. > > The sparse stuff should probably be submitted to 'net'. I will send a patch for this to 'net'. > > And I have to ask why you really need a clear operation. Because we didn't have any way for the userspace to know what ports are part of the MRP ring. I thought the easiest way would be for the daemon to clear everything when is started. > Routing > daemons come up and see what routes are installed, and update their > internal SW tables to match. This not only allows efficient restart > after a crash, but it also allows multiple daemons to work > cooperatively as an agent for the same forwarding/routing table. I think it would be possible to have something similar for the MRP daemon. But I still have problems to see how to have multiple MRP daemons running at the same time. Because each deamon implements MRP state machine. So for example if the link of one of the MRP ports is changing then each daemon is notified about this change so then each daemon will send some frames, and that would mean that we have duplicate frames in the network. > > Your usage model limits one daemon to manage the table and that > limitation is completely unnecessary. > > Furthermore, even in a one-daemon scenerio, it's wasteful to throw > away all the work the previous daemon did to load the MRP entries into > the bridge. > > Thanks. > -- /Horatiu
Re: [PATCH v2 1/2] PCI/ERR: Fix fatal error recovery for non-hotplug capable devices
Hi Jay,
I've tested the patches on my board, and they work well.
Thanks,
Yicong
On 2020/6/25 2:52, Jay Vosburgh wrote:
> Jay Vosburgh wrote:
>
>> sathyanarayanan.kuppusw...@linux.intel.com wrote:
>>
>> From: Kuppuswamy Sathyanarayanan
>>> Fatal (DPC) error recovery is currently broken for non-hotplug
>>> capable devices. With current implementation, after successful
>>> fatal error recovery, non-hotplug capable device state won't be
>>> restored properly. You can find related issues in following links.
>>>
>>> https://lkml.org/lkml/2020/5/27/290
>>> https://lore.kernel.org/linux-pci/12115.1588207324@famine/
>>> https://lkml.org/lkml/2020/3/28/328
>>>
>>> Current fatal error recovery implementation relies on hotplug handler
>>> for detaching/re-enumerating the affected devices/drivers on DLLSC
>>> state changes. So when dealing with non-hotplug capable devices,
>>> recovery code does not restore the state of the affected devices
>>> correctly. Correct implementation should call report_slot_reset()
>>> function after resetting the link to restore the state of the
>>> device/driver.
>>>
>>> So use PCI_ERS_RESULT_NEED_RESET as error status for successful
>>> reset_link() operation and use PCI_ERS_RESULT_DISCONNECT for failure
>>> case. PCI_ERS_RESULT_NEED_RESET error state will ensure slot_reset()
>>> is called after reset link operation which will also fix the above
>>> mentioned issue.
>>>
>>> [original patch is from jay.vosbu...@canonical.com]
>>> [original patch link
>>> https://lore.kernel.org/linux-pci/12115.1588207324@famine/]
>>> Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
>>> Signed-off-by: Jay Vosburgh
>>> Signed-off-by: Kuppuswamy Sathyanarayanan
>>>
>> I've tested this patch set on one of our test machines, and it
>> resolves the issue. I plan to test with other systems tomorrow.
> I've done testing on two different systems that exhibit the
> original issue and this patch set appears to behave as expected.
>
> Has anyone else (Yicong?) had an opportunity to test this?
>
> Can this be considered for acceptance, or is additional feedback
> or review needed?
>
> -J
>
>>> ---
>>> drivers/pci/pcie/err.c | 24 ++--
>>> 1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
>>> index 14bb8f54723e..5fe8561c7185 100644
>>> --- a/drivers/pci/pcie/err.c
>>> +++ b/drivers/pci/pcie/err.c
>>> @@ -165,8 +165,28 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
>>> pci_dbg(dev, "broadcast error_detected message\n");
>>> if (state == pci_channel_io_frozen) {
>>> pci_walk_bus(bus, report_frozen_detected, &status);
>>> - status = reset_link(dev);
>>> - if (status != PCI_ERS_RESULT_RECOVERED) {
>>> + /*
>>> +* After resetting the link using reset_link() call, the
>>> +* possible value of error status is either
>>> +* PCI_ERS_RESULT_DISCONNECT (failure case) or
>>> +* PCI_ERS_RESULT_NEED_RESET (success case).
>>> +* So ignore the return value of report_error_detected()
>>> +* call for fatal errors. Instead use
>>> +* PCI_ERS_RESULT_NEED_RESET as initial status value.
>>> +*
>>> +* Ignoring the status return value of report_error_detected()
>>> +* call will also help in case of EDR mode based error
>>> +* recovery. In EDR mode AER and DPC Capabilities are owned by
>>> +* firmware and hence report_error_detected() call will possibly
>>> +* return PCI_ERS_RESULT_NO_AER_DRIVER. So if we don't ignore
>>> +* the return value of report_error_detected() then
>>> +* pcie_do_recovery() would report incorrect status after
>>> +* successful recovery. Ignoring PCI_ERS_RESULT_NO_AER_DRIVER
>>> +* in non EDR case should not have any functional impact.
>>> +*/
>>> + status = PCI_ERS_RESULT_NEED_RESET;
>>> + if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED) {
>>> + status = PCI_ERS_RESULT_DISCONNECT;
>>> pci_warn(dev, "link reset failed\n");
>>> goto failed;
>>> }
>>> --
>>> 2.17.1
> ---
> -Jay Vosburgh, jay.vosbu...@canonical.com
> .
>
Re: [PATCH v2] sched: fix build with GCC_PLUGIN_RANDSTRUCT
There's patches in tip/sched/urgent for this...
Re: [PATCH] scsi: sd: add runtime pm to open / release
On Sat, Jun 27, 2020 at 07:37:54PM -0700, Bart Van Assche wrote:
> On 2020-06-26 08:44, Alan Stern wrote:
> > On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
> >> As far as I know runtime power management support in the sd driver is
> >> working
> >> fine and is being used intensively by the UFS driver. The following commit
> >> was
> >> submitted to fix a bug encountered by an UFS developer: 05d18ae1cc8a
> >> ("scsi:
> >> pm: Balance pm_only counter of request queue during system resume") # v5.7.
> >
> > I just looked at that commit for the first time.
> >
> > Instead of making the SCSI driver do the work of deciding what routine to
> > call, why not redefine blk_set_runtime_active(q) to simply call
> > blk_post_runtime_resume(q, 0)? Or vice versa: if err == 0 have
> > blk_post_runtime_resume call blk_set_runtime_active?
> >
> > After all, the two routines do almost the same thing -- and the bug
> > addressed by this commit was caused by the difference in their behaviors.
> >
> > If the device was already runtime-active during the system suspend, doing
> > an extra clear of the pm_only counter won't hurt anything.
>
> Hi Alan,
>
> Do you want to submit a patch that implements this change or do you
> perhaps expect me to do that?
I'll submit a patch in a few days. I just wanted to check first that the
idea was sound.
Alan Stern
REPLY ME URGENTLY
Greeting Please forgive me for stressing you with my predicaments and I sorry to approach you through this media it is because it serves the fastest means of communication. I came across your E-mail from my personal search and I decided to contact you believing you will be honest to fulfill my final wish before I die. I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I am suffering from a pro-long critical cancer, my doctors confirmed I may not live beyond two months from now as my ill health has defiled all forms of medical treatment. Since my days are numbered, I’ve decided willingly to fulfill my long-time promise to donate you the sum ($5.000.000.00) million dollars I inherited from my late husband Mr. Edward Herbart, foreign bank account over years. I need a very honest person who can assist in transfer of this money to his or her account and use the funds for charities work of God while you use 50% for yourself. I want you to know there are no risk involved, it is 100% hitch free & safe. If you will be interesting to assist in getting this fund into your account for charity project to fulfill my promise before I die please let me know immediately. I will appreciate your utmost confidentiality as I wait for your reply. Best Regards Mrs. Elizabeth Edward
Re: Commit 'fs: Do not check if there is a fsnotify watcher on pseudo inodes' breaks chromium here
On Sun, 2020-06-28 at 15:53 +0300, Amir Goldstein wrote: > On Sun, Jun 28, 2020 at 2:14 PM Maxim Levitsky wrote: > > Hi, > > > > I just did usual kernel update and now chromium crashes on startup. > > It happens both in a KVM's VM (with virtio-gpu if that matters) and > > natively with amdgpu driver. > > Most likely not GPU related although I initially suspected that it is. > > > > Chromium starts as a white rectangle, shows few white rectangles > > that resemble its notifications and then crashes. > > > > The stdout output from chromium: > > > [...] > > > Received signal 6 > > #0 0x55f6da0120d9 base::debug::CollectStackTrace() > > #1 0x55f6d9f75246 base::debug::StackTrace::StackTrace() > > #2 0x55f6da01170a base::debug::(anonymous > > namespace)::StackDumpSignalHandler() > > #3 0x55f6da011cfe base::debug::(anonymous > > namespace)::StackDumpSignalHandler() > > #4 0x7ff46643ab20 (/usr/lib64/libpthread-2.30.so+0x14b1f) > > #5 0x7ff462d87625 __GI_raise > > #6 0x7ff462d708d9 __GI_abort > > #7 0x55f6da0112d5 base::debug::BreakDebugger() > > #8 0x55f6d9f86405 logging::LogMessage::~LogMessage() > > #9 0x55f6d7ed5488 content::(anonymous > > namespace)::IntentionallyCrashBrowserForUnusableGpuProcess() > > #10 0x55f6d7ed8479 > > content::GpuDataManagerImplPrivate::FallBackToNextGpuMode() > > #11 0x55f6d7ed4eef content::GpuDataManagerImpl::FallBackToNextGpuMode() > > #12 0x55f6d7ee0f41 content::GpuProcessHost::RecordProcessCrash() > > #13 0x55f6d7ee105d content::GpuProcessHost::OnProcessCrashed() > > #14 0x55f6d7cbe308 > > content::BrowserChildProcessHostImpl::OnChildDisconnected() > > #15 0x55f6da8b511a IPC::ChannelMojo::OnPipeError() > > #16 0x55f6da13cd62 mojo::InterfaceEndpointClient::NotifyError() > > #17 0x55f6da8c1f9d IPC::(anonymous > > namespace)::ChannelAssociatedGroupController::OnPipeError() > > #18 0x55f6da138968 mojo::Connector::HandleError() > > #19 0x55f6da15bce7 mojo::SimpleWatcher::OnHandleReady() > > #20 0x55f6da15c0fb mojo::SimpleWatcher::Context::CallNotify() > > #21 0x55f6d78eaa73 mojo::core::WatcherDispatcher::InvokeWatchCallback() > > #22 0x55f6d78ea38f mojo::core::Watch::InvokeCallback() > > #23 0x55f6d78e6efa mojo::core::RequestContext::~RequestContext() > > #24 0x55f6d78db76a mojo::core::NodeChannel::OnChannelError() > > #25 0x55f6d78f232a mojo::core::(anonymous > > namespace)::ChannelPosix::OnFileCanReadWithoutBlocking() > > #26 0x55f6da03345e base::MessagePumpLibevent::OnLibeventNotification() > > #27 0x55f6da0f9b2d event_base_loop > > #28 0x55f6da03316d base::MessagePumpLibevent::Run() > > #29 0x55f6d9fd79c9 > > base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run() > > #30 0x55f6d9fada7a base::RunLoop::Run() > > #31 0x55f6d7ce6324 content::BrowserProcessSubThread::IOThreadRun() > > #32 0x55f6d9fe0cb8 base::Thread::ThreadMain() > > #33 0x55f6da024705 base::(anonymous namespace)::ThreadFunc() > > #34 0x7ff46642f4e2 start_thread > > #35 0x7ff462e4c6a3 __GI___clone > > r8: r9: 7ff44e6a58d0 r10: 0008 r11: > > 0246 > > r12: 7ff44e6a6b40 r13: 7ff44e6a6d00 r14: 006d r15: > > 7ff44e6a6b30 > > di: 0002 si: 7ff44e6a58d0 bp: 7ff44e6a5b20 bx: > > 7ff44e6a9700 > > dx: ax: cx: 7ff462d87625 sp: > > 7ff44e6a58d0 > > ip: 7ff462d87625 efl: 0246 cgf: 002b0033 erf: > > > > trp: msk: cr2: > > [end of stack trace] > > Calling _exit(1). Core file will not be generated. > > > > > > I guess this answers our question whether we could disable fsnoitfy > watches on pseudo inodes > > From comments like these in chromium code: > https://chromium.googlesource.com/chromium/src/+/master/mojo/core/watcher_dispatcher.cc#77 > https://chromium.googlesource.com/chromium/src/+/master/base/files/file_descriptor_watcher_posix.cc#176 > https://chromium.googlesource.com/chromium/src/+/master/ipc/ipc_channel_mojo.cc#240 > > I am taking a wild guess that the missing FS_CLOSE event on anonymous pipes is > the cause for regression. > > The motivation for the patch "fs: Do not check if there is a fsnotify > watcher on pseudo inodes" > was performance, but actually, FS_CLOSE and FS_OPEN events probably do > not impact > performance as FS_MODIFY and FS_ACCESS. > > Mel, > > Do your perf results support the claim above? > > Jan/Linus, > > Do you agree that dropping FS_MODIFY/FS_ACCESS events for FMODE_STREAM > files as a general rule should be safe? > > Maxim, can you try if the attached patch fixes the chromium regression. > It is expected to leave the FS_OPEN/FS_CLOSE events on anonymous pipes > but drop the FS_MODIFY/FS_ACCESS events. Tested this (in the VM this time) and it works. Best regards, Maxim Levitsky > > Thanks, > Amir.
Re: [PATCH v3] media: venus: core: Fix runtime PM imbalance in venus_probe()
> when it returns an error code. Thus a pairing decrement is needed on * I find it more appropriate to use the word “corresponding” here (if you do still not like previous wording suggestions). * Will it become helpful to add the tag “Fixes” to the commit message? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=719fdd32921fb7e3208db8832d32ae1c2d68900f#n183 * Would you like to improve the change description any more? > --- > drivers/media/platform/qcom/venus/core.c | 5 - I suggest replace the triple dashes before this diffstat by a blank line. Regards, Markus
Re: Commit 'fs: Do not check if there is a fsnotify watcher on pseudo inodes' breaks chromium here
On Sun, 2020-06-28 at 16:14 +0300, Maxim Levitsky wrote: > On Sun, 2020-06-28 at 15:53 +0300, Amir Goldstein wrote: > > On Sun, Jun 28, 2020 at 2:14 PM Maxim Levitsky wrote: > > > Hi, > > > > > > I just did usual kernel update and now chromium crashes on startup. > > > It happens both in a KVM's VM (with virtio-gpu if that matters) and > > > natively with amdgpu driver. > > > Most likely not GPU related although I initially suspected that it is. > > > > > > Chromium starts as a white rectangle, shows few white rectangles > > > that resemble its notifications and then crashes. > > > > > > The stdout output from chromium: > > > > > [...] > > > > > Received signal 6 > > > #0 0x55f6da0120d9 base::debug::CollectStackTrace() > > > #1 0x55f6d9f75246 base::debug::StackTrace::StackTrace() > > > #2 0x55f6da01170a base::debug::(anonymous > > > namespace)::StackDumpSignalHandler() > > > #3 0x55f6da011cfe base::debug::(anonymous > > > namespace)::StackDumpSignalHandler() > > > #4 0x7ff46643ab20 (/usr/lib64/libpthread-2.30.so+0x14b1f) > > > #5 0x7ff462d87625 __GI_raise > > > #6 0x7ff462d708d9 __GI_abort > > > #7 0x55f6da0112d5 base::debug::BreakDebugger() > > > #8 0x55f6d9f86405 logging::LogMessage::~LogMessage() > > > #9 0x55f6d7ed5488 content::(anonymous > > > namespace)::IntentionallyCrashBrowserForUnusableGpuProcess() > > > #10 0x55f6d7ed8479 > > > content::GpuDataManagerImplPrivate::FallBackToNextGpuMode() > > > #11 0x55f6d7ed4eef content::GpuDataManagerImpl::FallBackToNextGpuMode() > > > #12 0x55f6d7ee0f41 content::GpuProcessHost::RecordProcessCrash() > > > #13 0x55f6d7ee105d content::GpuProcessHost::OnProcessCrashed() > > > #14 0x55f6d7cbe308 > > > content::BrowserChildProcessHostImpl::OnChildDisconnected() > > > #15 0x55f6da8b511a IPC::ChannelMojo::OnPipeError() > > > #16 0x55f6da13cd62 mojo::InterfaceEndpointClient::NotifyError() > > > #17 0x55f6da8c1f9d IPC::(anonymous > > > namespace)::ChannelAssociatedGroupController::OnPipeError() > > > #18 0x55f6da138968 mojo::Connector::HandleError() > > > #19 0x55f6da15bce7 mojo::SimpleWatcher::OnHandleReady() > > > #20 0x55f6da15c0fb mojo::SimpleWatcher::Context::CallNotify() > > > #21 0x55f6d78eaa73 mojo::core::WatcherDispatcher::InvokeWatchCallback() > > > #22 0x55f6d78ea38f mojo::core::Watch::InvokeCallback() > > > #23 0x55f6d78e6efa mojo::core::RequestContext::~RequestContext() > > > #24 0x55f6d78db76a mojo::core::NodeChannel::OnChannelError() > > > #25 0x55f6d78f232a mojo::core::(anonymous > > > namespace)::ChannelPosix::OnFileCanReadWithoutBlocking() > > > #26 0x55f6da03345e base::MessagePumpLibevent::OnLibeventNotification() > > > #27 0x55f6da0f9b2d event_base_loop > > > #28 0x55f6da03316d base::MessagePumpLibevent::Run() > > > #29 0x55f6d9fd79c9 > > > base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run() > > > #30 0x55f6d9fada7a base::RunLoop::Run() > > > #31 0x55f6d7ce6324 content::BrowserProcessSubThread::IOThreadRun() > > > #32 0x55f6d9fe0cb8 base::Thread::ThreadMain() > > > #33 0x55f6da024705 base::(anonymous namespace)::ThreadFunc() > > > #34 0x7ff46642f4e2 start_thread > > > #35 0x7ff462e4c6a3 __GI___clone > > > r8: r9: 7ff44e6a58d0 r10: 0008 r11: > > > 0246 > > > r12: 7ff44e6a6b40 r13: 7ff44e6a6d00 r14: 006d r15: > > > 7ff44e6a6b30 > > > di: 0002 si: 7ff44e6a58d0 bp: 7ff44e6a5b20 bx: > > > 7ff44e6a9700 > > > dx: ax: cx: 7ff462d87625 sp: > > > 7ff44e6a58d0 > > > ip: 7ff462d87625 efl: 0246 cgf: 002b0033 erf: > > > > > > trp: msk: cr2: > > > [end of stack trace] > > > Calling _exit(1). Core file will not be generated. > > > > > > > > > > I guess this answers our question whether we could disable fsnoitfy > > watches on pseudo inodes > > > > From comments like these in chromium code: > > https://chromium.googlesource.com/chromium/src/+/master/mojo/core/watcher_dispatcher.cc#77 > > https://chromium.googlesource.com/chromium/src/+/master/base/files/file_descriptor_watcher_posix.cc#176 > > https://chromium.googlesource.com/chromium/src/+/master/ipc/ipc_channel_mojo.cc#240 > > > > I am taking a wild guess that the missing FS_CLOSE event on anonymous pipes > > is > > the cause for regression. > > > > The motivation for the patch "fs: Do not check if there is a fsnotify > > watcher on pseudo inodes" > > was performance, but actually, FS_CLOSE and FS_OPEN events probably do > > not impact > > performance as FS_MODIFY and FS_ACCESS. > > > > Mel, > > > > Do your perf results support the claim above? > > > > Jan/Linus, > > > > Do you agree that dropping FS_MODIFY/FS_ACCESS events for FMODE_STREAM > > files as a general rule should be safe? > > > > Maxim, can you try if the attached patch fixes the chromium regression. > > It is expected to leave the FS_OPEN/FS_CLOSE event
Re: wait_on_page_bit_common(TASK_KILLABLE, EXCLUSIVE) can miss wakeup?
On Sat, Jun 27, 2020 at 10:39:20PM -0700, Linus Torvalds wrote: > Ugh. Heh, I was afraid of that.. > So how about the attached trivial two-liner? We solve the problem by > simply marking ourselves TASK_RUNNING, which means that we won't be > counted as an exclusive wakeup. > > Ok, so the "one" line to do that is that is actually two lines: > > __set_current_state(TASK_RUNNING); > smp_mb__before_atomic(); > > and there's four lines of comments to go with it, but it really is > very simple: if we do that before we do the test_and_set_bit_lock(), > no wakeups will be lost, because we won't be sleeping for that wakeup. > > I'm not entirely happy about that "smp_mb__before_atomic()". I think > it's right in practice that test_and_set_bit_lock() (when it actually > does a write) has at LEAST atomic seqmantics, so I think it's good. > But it's not pretty. Hurm... yes. I think I agree this solves it. However... the wait loop is 'weird'. It isn't shaped like our other loops. On the one hand, who cares, that's just my OCD, on the other hand, it does mean you have to think harder every time you look at this thing.
Re: Commit 'fs: Do not check if there is a fsnotify watcher on pseudo inodes' breaks chromium here
On Sun, Jun 28, 2020 at 4:17 PM Maxim Levitsky wrote: > > On Sun, 2020-06-28 at 16:14 +0300, Maxim Levitsky wrote: > > On Sun, 2020-06-28 at 15:53 +0300, Amir Goldstein wrote: > > > On Sun, Jun 28, 2020 at 2:14 PM Maxim Levitsky > > > wrote: > > > > Hi, > > > > > > > > I just did usual kernel update and now chromium crashes on startup. > > > > It happens both in a KVM's VM (with virtio-gpu if that matters) and > > > > natively with amdgpu driver. > > > > Most likely not GPU related although I initially suspected that it is. > > > > > > > > Chromium starts as a white rectangle, shows few white rectangles > > > > that resemble its notifications and then crashes. > > > > > > > > The stdout output from chromium: > > > > > > > [...] > > > > > > > Received signal 6 > > > > #0 0x55f6da0120d9 base::debug::CollectStackTrace() > > > > #1 0x55f6d9f75246 base::debug::StackTrace::StackTrace() > > > > #2 0x55f6da01170a base::debug::(anonymous > > > > namespace)::StackDumpSignalHandler() > > > > #3 0x55f6da011cfe base::debug::(anonymous > > > > namespace)::StackDumpSignalHandler() > > > > #4 0x7ff46643ab20 (/usr/lib64/libpthread-2.30.so+0x14b1f) > > > > #5 0x7ff462d87625 __GI_raise > > > > #6 0x7ff462d708d9 __GI_abort > > > > #7 0x55f6da0112d5 base::debug::BreakDebugger() > > > > #8 0x55f6d9f86405 logging::LogMessage::~LogMessage() > > > > #9 0x55f6d7ed5488 content::(anonymous > > > > namespace)::IntentionallyCrashBrowserForUnusableGpuProcess() > > > > #10 0x55f6d7ed8479 > > > > content::GpuDataManagerImplPrivate::FallBackToNextGpuMode() > > > > #11 0x55f6d7ed4eef content::GpuDataManagerImpl::FallBackToNextGpuMode() > > > > #12 0x55f6d7ee0f41 content::GpuProcessHost::RecordProcessCrash() > > > > #13 0x55f6d7ee105d content::GpuProcessHost::OnProcessCrashed() > > > > #14 0x55f6d7cbe308 > > > > content::BrowserChildProcessHostImpl::OnChildDisconnected() > > > > #15 0x55f6da8b511a IPC::ChannelMojo::OnPipeError() > > > > #16 0x55f6da13cd62 mojo::InterfaceEndpointClient::NotifyError() > > > > #17 0x55f6da8c1f9d IPC::(anonymous > > > > namespace)::ChannelAssociatedGroupController::OnPipeError() > > > > #18 0x55f6da138968 mojo::Connector::HandleError() > > > > #19 0x55f6da15bce7 mojo::SimpleWatcher::OnHandleReady() > > > > #20 0x55f6da15c0fb mojo::SimpleWatcher::Context::CallNotify() > > > > #21 0x55f6d78eaa73 mojo::core::WatcherDispatcher::InvokeWatchCallback() > > > > #22 0x55f6d78ea38f mojo::core::Watch::InvokeCallback() > > > > #23 0x55f6d78e6efa mojo::core::RequestContext::~RequestContext() > > > > #24 0x55f6d78db76a mojo::core::NodeChannel::OnChannelError() > > > > #25 0x55f6d78f232a mojo::core::(anonymous > > > > namespace)::ChannelPosix::OnFileCanReadWithoutBlocking() > > > > #26 0x55f6da03345e base::MessagePumpLibevent::OnLibeventNotification() > > > > #27 0x55f6da0f9b2d event_base_loop > > > > #28 0x55f6da03316d base::MessagePumpLibevent::Run() > > > > #29 0x55f6d9fd79c9 > > > > base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run() > > > > #30 0x55f6d9fada7a base::RunLoop::Run() > > > > #31 0x55f6d7ce6324 content::BrowserProcessSubThread::IOThreadRun() > > > > #32 0x55f6d9fe0cb8 base::Thread::ThreadMain() > > > > #33 0x55f6da024705 base::(anonymous namespace)::ThreadFunc() > > > > #34 0x7ff46642f4e2 start_thread > > > > #35 0x7ff462e4c6a3 __GI___clone > > > > r8: r9: 7ff44e6a58d0 r10: 0008 r11: > > > > 0246 > > > > r12: 7ff44e6a6b40 r13: 7ff44e6a6d00 r14: 006d r15: > > > > 7ff44e6a6b30 > > > > di: 0002 si: 7ff44e6a58d0 bp: 7ff44e6a5b20 bx: > > > > 7ff44e6a9700 > > > > dx: ax: cx: 7ff462d87625 sp: > > > > 7ff44e6a58d0 > > > > ip: 7ff462d87625 efl: 0246 cgf: 002b0033 erf: > > > > > > > > trp: msk: cr2: > > > > [end of stack trace] > > > > Calling _exit(1). Core file will not be generated. > > > > > > > > > > > > > > I guess this answers our question whether we could disable fsnoitfy > > > watches on pseudo inodes > > > > > > From comments like these in chromium code: > > > https://chromium.googlesource.com/chromium/src/+/master/mojo/core/watcher_dispatcher.cc#77 > > > https://chromium.googlesource.com/chromium/src/+/master/base/files/file_descriptor_watcher_posix.cc#176 > > > https://chromium.googlesource.com/chromium/src/+/master/ipc/ipc_channel_mojo.cc#240 > > > > > > I am taking a wild guess that the missing FS_CLOSE event on anonymous > > > pipes is > > > the cause for regression. > > > > > > The motivation for the patch "fs: Do not check if there is a fsnotify > > > watcher on pseudo inodes" > > > was performance, but actually, FS_CLOSE and FS_OPEN events probably do > > > not impact > > > performance as FS_MODIFY and FS_ACCESS. > > > > > > Mel, > > > > > > Do your perf results support the claim above? > > > > > > Jan/Linus, > > > >
