[PATCH trivial] xtensa: fix Kconfig typo
From: Randy Dunlap
Correct trivial typo (ful -> full).
Fixes: 76743c0e0915 ("xtensa: move kernel memory layout to platform options")
Signed-off-by: Randy Dunlap
Cc: Chris Zankel
Cc: Max Filippov
Cc: linux-xte...@linux-xtensa.org
Cc: Jiri Kosina
---
arch/xtensa/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200828.orig/arch/xtensa/Kconfig
+++ linux-next-20200828/arch/xtensa/Kconfig
@@ -537,7 +537,7 @@ config MEMMAP_CACHEATTR
2: cache bypass,
4: WB cached,
f: illegal.
- For ful MMU:
+ For full MMU:
bit 0: executable,
bit 1: writable,
bits 2..3:
[gustavoars-linux:testing/fallthrough] BUILD SUCCESS a66bf6afaf6c7977c8e64e77bafb9761fd42ac4c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git testing/fallthrough branch HEAD: a66bf6afaf6c7977c8e64e77bafb9761fd42ac4c arm64/cpuinfo: Remove unnecessary fallthrough annotation elapsed time: 720m configs tested: 96 configs skipped: 7 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig mips ip28_defconfig mips pic32mzda_defconfig m68kmac_defconfig arm omap2plus_defconfig nds32 defconfig xtensa common_defconfig arm spear13xx_defconfig ia64 alldefconfig powerpc ps3_defconfig mipsmalta_kvm_guest_defconfig arm rpc_defconfig powerpc wii_defconfig armu300_defconfig mipsvocore2_defconfig powerpc holly_defconfig mipsgpr_defconfig mips decstation_r4k_defconfig arcnsim_700_defconfig shmigor_defconfig arm pxa168_defconfig x86_64 alldefconfig arm nhk8815_defconfig m68km5307c3_defconfig mips cu1000-neo_defconfig arm palmz72_defconfig h8300alldefconfig arm viper_defconfig mips tb0287_defconfig arm davinci_all_defconfig powerpc ep88xc_defconfig arm aspeed_g5_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20200830 i386 randconfig-a002-20200830 i386 randconfig-a004-20200830 i386 randconfig-a006-20200830 i386 randconfig-a005-20200830 i386 randconfig-a003-20200830 i386 randconfig-a013-20200830 i386 randconfig-a011-20200830 i386 randconfig-a012-20200830 i386 randconfig-a015-20200830 i386 randconfig-a016-20200830 i386 randconfig-a014-20200830 x86_64 randconfig-a002-20200830 x86_64 randconfig-a005-20200830 x86_64 randconfig-a001-20200830 x86_64 randconfig-a006-20200830 x86_64 randconfig-a004-20200830 x86_64 randconfig-a003-20200830 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] igb: read PBA number from flash
Fixed flash presence check for 82576 controllers so the part
number string is read and displayed correctly.
Signed-off-by: Gal Hammer
---
drivers/net/ethernet/intel/igb/igb_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index d9c3a6b169f9..245e62b0a97e 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3388,7 +3388,9 @@ static int igb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
"Width x1" : "unknown"), netdev->dev_addr);
}
- if ((hw->mac.type >= e1000_i210 ||
+ if ((hw->mac.type == e1000_82576 &&
+rd32(E1000_EECD) & E1000_EECD_PRES) ||
+ (hw->mac.type >= e1000_i210 ||
igb_get_flash_presence_i210(hw))) {
ret_val = igb_read_part_string(hw, part_str,
E1000_PBANUM_LENGTH);
--
2.26.2
Re: [PATCH] USB: integrate macro definitions into include/linux/usb.h
I just think it is a clear up to make these macros get togather which have the samilar attributes. That's why :) Thanks, Yanfei On 8/28/20 3:48 PM, Greg KH wrote: On Tue, Aug 25, 2020 at 11:44:21PM +0800, yanfei...@windriver.com wrote: From: Yanfei Xu include/linux/usb.h also contains 'Hard limit' and 'Arbitrary limit' macro definitions in it, hence we can integrate these from config.c into include/linux/usb.h Why? No one uses these values outside of this .c file, so why put a value in a global .h file? Who else wants to use these values? If something else needs it, then sure, it could be moved, but until then, there's nothing wrong with the existing code as-is from what I can tell. thanks, greg k-h
Re: [PATCH 02/11] kconfig: qconf: update the intro message to match to the current code
On 8/29/20 1:14 AM, Masahiro Yamada wrote: > I do not think "Although there is no cross reference yet ..." is valid > any longer. > > The cross reference is supported via hyperlinks enabled by the > "show Debug Info" option. > > Update the message. > > Signed-off-by: Masahiro Yamada > --- > > scripts/kconfig/qconf.cc | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Tested-by: Randy Dunlap thanks. -- ~Randy
Re: [PATCH 01/11] kconfig: qconf: reformat the intro message
On 8/29/20 1:14 AM, Masahiro Yamada wrote: > The introduction message displayed by 'Help -> Introduction' does not > look nice due to excessive new lines. > > Reformat the message. > > Signed-off-by: Masahiro Yamada > --- > > scripts/kconfig/qconf.cc | 29 ++--- > 1 file changed, 18 insertions(+), 11 deletions(-) Tested-by: Randy Dunlap thanks. -- ~Randy
Re: [PATCH 11/11] kconfig: qconf: create QApplication after option checks
On 8/29/20 1:14 AM, Masahiro Yamada wrote: > 'scripts/kconfig/qconf -h' just calls usage() and exits, with > QApplication unused. > > There is no need to construct QApplication so early. Do it after > the parse stage. > > Signed-off-by: Masahiro Yamada > --- > > scripts/kconfig/qconf.cc | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Tested-by: Randy Dunlap thanks. -- ~Randy
Re: [PATCH 05/11] kconfig: qconf: show data column all the time
On 8/29/20 1:14 AM, Masahiro Yamada wrote: > The next commit will allow users to edit "int", "hex", "string" > menus in-place from the data column. > > The data column should be always displayed. > > Signed-off-by: Masahiro Yamada > --- > > scripts/kconfig/qconf.cc | 29 + > scripts/kconfig/qconf.h | 5 + > 2 files changed, 2 insertions(+), 32 deletions(-) > I am trying to edit LOG_BUF_SHIFT, which has a value of 17 (this is x86_64). I want to change the 7 to 9, making it 19, so I double-click on the "17" (single-click won't give me an edit cursor). The edit cursor is immediately after the "17", so it's like 17| with the | cursor blinking. What I expect to be able to do is Backspace, enter 9, press Enter, and the new value is 19. But Backspace does nothing. I just have to enter the complete new value: 19. So IMO it does not act like an edit box so much as a replacement box. Also, the new value that I enter is displayed/written over the old value, so I see 17 in white-on-blue and over that I see 19 in black until I press Enter, then I see only 19 in white-on-blue. BTW, if I edit DEFAULT_HOSTNAME, which begins as "(none)" and I change it to "xyz" and then change it to , it becomes CONFIG_DEFAULT_HOSTNAME="" Should I have to enter "(none)" to get it back to (none)? I guess so. -- ~Randy
Re: [PATCH 06/11] kconfig: qconf: allow to edit "int", "hex", "string" menus in-place
On 8/29/20 1:14 AM, Masahiro Yamada wrote: > Previously, when you double-clicked the "int", "hex", or "string" menus, > a line-edit gadget showed up to allow you to input the value, which > looked clumsy. > > Also, it was buggy; the editor opened even if the config option was not > editable. For example, just try to double-click CC_VERSION_TEXT, which > has no prompt. > > This commit sub-classes QStyleItemDelegate to allow users to edit > "int", "hex", "string" menus in-place. Just double-click (or press > the F2 key) in the data column. Then, an editor widget is placed on > top of the item view. The F2 key doesn't work for me. I guess that's a desktop environment issue (I am using Xfce). > The two methods are overridden: > > createEditor - process only when the data column is being accessed > and the menu is visible. Otherwise, return nullptr to disallow editing. > > setModelData - take the new data from the editor, and set it to the > addressed symbol. If it was successful, update all the list windows. > Otherwise, (the reason for the failure is possibly the input data was > out of range), set the old value back to the editor. > > Signed-off-by: Masahiro Yamada > --- > > scripts/kconfig/qconf.cc | 93 > scripts/kconfig/qconf.h | 15 +++ > 2 files changed, 91 insertions(+), 17 deletions(-) > -- ~Randy
Re: ptrace_syscall_32 is failing
On Sat, Aug 29, 2020 at 12:52 PM Andy Lutomirski wrote:
>
> Seems to be a recent regression, maybe related to entry/exit work changes.
>
> # ./tools/testing/selftests/x86/ptrace_syscall_32
> [RUN]Check int80 return regs
> [OK]getpid() preserves regs
> [OK]kill(getpid(), SIGUSR1) preserves regs
> [RUN]Check AT_SYSINFO return regs
> [OK]getpid() preserves regs
> [OK]kill(getpid(), SIGUSR1) preserves regs
> [RUN]ptrace-induced syscall restart
> Child will make one syscall
> [RUN]SYSEMU
> [FAIL]Initial args are wrong (nr=224, args=10 11 12 13 14 4289172732)
> [RUN]Restart the syscall (ip = 0xf7f3b549)
> [OK]Restarted nr and args are correct
> [RUN]Change nr and args and restart the syscall (ip = 0xf7f3b549)
> [OK]Replacement nr and args are correct
> [OK]Child exited cleanly
> [RUN]kernel syscall restart under ptrace
> Child will take a nap until signaled
> [RUN]SYSCALL
> [FAIL]Initial args are wrong (nr=29, args=0 0 0 0 0 4289172732)
> [RUN]SYSCALL
> [OK]Args after SIGUSR1 are correct (ax = -514)
> [OK]Child got SIGUSR1
> [RUN]Step again
> [OK]pause(2) restarted correctly
Bisected to commit 0b085e68f407 ("x86/entry: Consolidate 32/64 bit
syscall entry").
It looks like it is because syscall_enter_from_user_mode() is called
before reading the 6th argument from the user stack.
--
Brian Gerst
[PATCH] KVM: fix memory leak in kvm_io_bus_unregister_dev()
when kmalloc() fails in kvm_io_bus_unregister_dev(), before removing
the bus, we should iterate over all other devices linked to it and call
kvm_iodevice_destructor() for them
Reported-and-tested-by: syzbot+f196caa45793d6374...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f196caa45793d6374707
Signed-off-by: Rustam Kovhaev
---
virt/kvm/kvm_main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 67cd0b88a6b6..646aa7b82548 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -4332,7 +4332,7 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus
bus_idx, gpa_t addr,
void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
struct kvm_io_device *dev)
{
- int i;
+ int i, j;
struct kvm_io_bus *new_bus, *bus;
bus = kvm_get_bus(kvm, bus_idx);
@@ -4351,6 +4351,11 @@ void kvm_io_bus_unregister_dev(struct kvm *kvm, enum
kvm_bus bus_idx,
GFP_KERNEL_ACCOUNT);
if (!new_bus) {
pr_err("kvm: failed to shrink bus, removing it completely\n");
+ for (j = 0; j < bus->dev_count; j++) {
+ if (j == i)
+ continue;
+ kvm_iodevice_destructor(bus->range[j].dev);
+ }
goto broken;
}
--
2.28.0
Re: [PATCH] fat: Avoid oops when bdi->io_pages==0
On Sun, Aug 30, 2020 at 10:54:35AM +0900, OGAWA Hirofumi wrote: > Matthew Wilcox writes: > > > On Sun, Aug 30, 2020 at 09:59:41AM +0900, OGAWA Hirofumi wrote: > >> On one system, there was bdi->io_pages==0. This seems to be the bug of > >> a driver somewhere, and should fix it though. Anyway, it is better to > >> avoid the divide-by-zero Oops. > >> > >> So this check it. > >> > >> Signed-off-by: OGAWA Hirofumi > >> Cc: > >> --- > >> fs/fat/fatent.c |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c > >> index f7e3304..98a1c4f 100644 > >> --- a/fs/fat/fatent.c 2020-08-30 06:52:47.251564566 +0900 > >> +++ b/fs/fat/fatent.c 2020-08-30 06:54:05.838319213 +0900 > >> @@ -660,7 +660,7 @@ static void fat_ra_init(struct super_blo > >>if (fatent->entry >= ent_limit) > >>return; > >> > >> - if (ra_pages > sb->s_bdi->io_pages) > >> + if (sb->s_bdi->io_pages && ra_pages > sb->s_bdi->io_pages) > >>ra_pages = rounddown(ra_pages, sb->s_bdi->io_pages); > > > > Wait, rounddown? ->io_pages is supposed to be the maximum number of > > pages to readahead. Shouldn't this be max() instead of rounddown()? Sorry, I meant 'min', not 'max'. > Hm, io_pages is limited by driver setting too, and io_pages can be lower > than ra_pages, e.g. usb storage. > > Assuming ra_pages is user intent of readahead window. So if io_pages is > lower than ra_pages, this try ra_pages to align of io_pages chunk, but > not bigger than ra_pages. Because if block layer splits I/O requests to > hard limit, then I/O is not optimal. > > So it is intent, I can be misunderstanding though. Looking at this some more, I'm not sure it makes sense to consult ->io_pages at all. I see how it gets set to 0 -- the admin can write '1' to /sys/block//queue/max_sectors_kb and that gets turned into 0 in ->io_pages. But I'm not sure it makes any sense to respect that. Looking at mm/readahead.c, all it does is limit the size of a read request which exceeds the current readahead window. It's not used to limit the readahead window itself. For example: unsigned long max_pages = ra->ra_pages; ... if (req_size > max_pages && bdi->io_pages > max_pages) max_pages = min(req_size, bdi->io_pages); Setting io_pages below ra_pages has no effect. So maybe fat should also disregard it?
Re: [f2fs-dev] [PATCH] f2fs: prevent compressed file from being disabled after releasing cblocks
On 2020-8-28 13:46, Daeho Jeong wrote:
From: Daeho Jeong
After releasing cblocks, the compressed file can be accidentally
disabled in compression mode, since it has zero cblocks. As we are
using IMMUTABLE flag to present released cblocks state, we can add
IMMUTABLE state check when considering the compressed file disabling.
Signed-off-by: Daeho Jeong
---
fs/f2fs/f2fs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 02811ce15059..14d30740ba03 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3936,6 +3936,8 @@ static inline u64 f2fs_disable_compressed_file(struct
inode *inode)
if (!f2fs_compressed_file(inode))
return 0;
if (S_ISREG(inode->i_mode)) {
+ if (IS_IMMUTABLE(inode))
+ return 1;
It looks most of callers are from ioctl, should we add immutable check in f2fs
ioctl interfaces if necessary? or I missed existed check.
Thanks,
if (get_dirty_pages(inode))
return 1;
if (fi->i_compr_blocks)
Re: [PATCH] f2fs: Simplify SEEK_DATA implementation
On 2020-8-25 5:48, Matthew Wilcox (Oracle) wrote: Instead of finding the first dirty page and then seeing if it matches the index of a block that is NEW_ADDR, delay the lookup of the dirty bit until we've actually found a block that's NEW_ADDR. Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Chao Yu Thanks,
Re: {standard input}:1174: Error: inappropriate arguments for opcode 'mpydu'
This looks like a buggy compiler to me.
On Sun, 30 Aug 2020, kernel test robot wrote:
> Hi Nicolas,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: e77aee1326f7691763aa968eee2f57db37840b9d
> commit: 602828c1aade576ac5f3fbd59b4eb014c5fc2414 __div64_const32(): improve
> the generic C version
> date: 12 months ago
> config: arc-allmodconfig (attached as .config)
> compiler: arceb-elf-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 602828c1aade576ac5f3fbd59b4eb014c5fc2414
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=arc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All errors (new ones prefixed by >>):
>
>{standard input}: Assembler messages:
> >> {standard input}:1174: Error: inappropriate arguments for opcode 'mpydu'
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
Re: [RFC/RFT PATCH 3/6] arm64, numa: Move pcibus_to_node definition to generic numa code
On Fri, Aug 28, 2020 at 06:11:50PM -0700, Atish Patra wrote:
> On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas wrote:
> > On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> > > On Fri, 14 Aug 2020 14:47:22 -0700
> > > Atish Patra wrote:
> > >
> > > > pcibus_to_node is used only when numa is enabled and does not depend
> > > > on ISA. Thus, it can be moved the generic numa implementation.
> > > >
> > > > Signed-off-by: Atish Patra
> > >
> > > From a more general unification point of view, there seem to
> > > be two ways architectures implement this.
> > > Either
> > >
> > > bus->sysdata.node
> > >
> > > Or as here.
> > > There are weird other options, but let us ignore those :)
> > >
> > > That is going to take a bit of unwinding should we
> > > want to take this unification further and perhaps we want to think
> > > about doing this in pci generic code rather than here?
> > >
> > > Perhaps this is one we are better keeping architecture specific for
> > > now?
> > >
> > > +CC Bjorn and Linux-pci
> > >
> > >
> > > > ---
> > > > arch/arm64/kernel/pci.c | 10 --
> > > > drivers/base/arch_numa.c | 11 +++
> > > > 2 files changed, 11 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > > index 1006ed2d7c60..07c122946c11 100644
> > > > --- a/arch/arm64/kernel/pci.c
> > > > +++ b/arch/arm64/kernel/pci.c
> > > > @@ -54,16 +54,6 @@ int raw_pci_write(unsigned int domain, unsigned int
> > > > bus,
> > > > return b->ops->write(b, devfn, reg, len, val);
> > > > }
> > > >
> > > > -#ifdef CONFIG_NUMA
> > > > -
> > > > -int pcibus_to_node(struct pci_bus *bus)
> > > > -{
> > > > - return dev_to_node(>dev);
> > > > -}
> > > > -EXPORT_SYMBOL(pcibus_to_node);
> > > > -
> > > > -#endif
> > > > -
> > > > #ifdef CONFIG_ACPI
> > > >
> > > > struct acpi_pci_generic_root_info {
> > > > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
> > > > index 83341c807240..4ab1b20a615d 100644
> > > > --- a/drivers/base/arch_numa.c
> > > > +++ b/drivers/base/arch_numa.c
> > > > @@ -11,6 +11,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > >
> > > > #ifdef CONFIG_ARM64
> > > > @@ -60,6 +61,16 @@ EXPORT_SYMBOL(cpumask_of_node);
> > > >
> > > > #endif
> > > >
> > > > +#ifdef CONFIG_PCI
> > > > +
> > > > +int pcibus_to_node(struct pci_bus *bus)
> > > > +{
> > > > + return dev_to_node(>dev);
> > > > +}
> > > > +EXPORT_SYMBOL(pcibus_to_node);
> > > > +
> > > > +#endif
> >
> > I certainly agree that this should not be arch-specific, but I'm not
> > really in favor of adding this PCI gunk in drivers/base.
> >
> > I think we can do better (eventually) by getting rid of
> > pcibus_to_node() completely. It's not used very much except by
> > cpumask_of_pcibus(), which itself is hardly used at all.
> >
> I am a bit confused here. A quick grep suggested that pcibus_to_node()
> is also called from generic pci probe,
> controller and few drivers(block, infiniband) as well. Maybe I am
> missing something here ?
I didn't say it was *only* used by cpumask_of_pcibus(). 13 of the 29
calls are from cpumask_of_pcibus().
As you point out, there are a few drivers that use it. They typically
have a pci_dev, so they do the equivalent of pcibus_to_node(pdev->bus).
That seems silly; they should just do dev_to_node(>dev) instead.
I looked at this once, and it seems like there might have been a
wrinkle like the pdev->dev node not being set correctly or something.
If that's the case, I think it should be fixed.
> We can move the pcibus_to_node to arch specific code for now if that's
> what is preferred.
Now I'm the one who's confused :) Most arches, including arm64,
already have arch-specific implementations of pcibus_to_node(). I
didn't look at the rest of the series to see if there's a reason you
need to move pcibus_to_node() from arch/arm64/kernel/pci.c to
drivers//base/arch_numa.c. If you don't need to, I would just leave
it where it is.
> > > > static void numa_update_cpu(unsigned int cpu, bool remove)
> > > > {
> > > > int nid = cpu_to_node(cpu);
Re: ERROR: modpost: "max_low_pfn" undefined!
On 8/29/20 7:32 PM, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 1127b219ce9481c84edad9711626d856127d5e51 > commit: f23efcbcc523b09c2ee359a35eb3897dc1764fd3 crypto: ctr - no longer > needs CRYPTO_SEQIV > date: 4 months ago > config: ia64-randconfig-s031-20200830 (attached as .config) > compiler: ia64-linux-gcc (GCC) 9.3.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # apt-get install sparse > # sparse version: v0.6.2-191-g10164920-dirty > git checkout f23efcbcc523b09c2ee359a35eb3897dc1764fd3 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 > CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>, old ones prefixed by <<): > > ERROR: modpost: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] > undefined! > ERROR: modpost: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] > undefined! > ERROR: modpost: "min_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! > ERROR: modpost: "max_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! > ERROR: modpost: "max_low_pfn" [drivers/tty/serial/fsl_lpuart.ko] undefined! > ERROR: modpost: "min_low_pfn" [drivers/tty/serial/fsl_lpuart.ko] undefined! > ERROR: modpost: "max_low_pfn" [crypto/tcrypt.ko] undefined! > ERROR: modpost: "min_low_pfn" [crypto/tcrypt.ko] undefined! >>> ERROR: modpost: "max_low_pfn" [crypto/drbg.ko] undefined! >>> ERROR: modpost: "min_low_pfn" [crypto/drbg.ko] undefined! > > --- > 0-DAY CI Kernel Test Service, Intel Corporation > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org > Hello kernel test robot, Please test with this patch applied: https://lore.kernel.org/lkml/20200829000126.2463-1-rdun...@infradead.org/ thanks. -- ~Randy
ERROR: modpost: "max_low_pfn" undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1127b219ce9481c84edad9711626d856127d5e51 commit: f23efcbcc523b09c2ee359a35eb3897dc1764fd3 crypto: ctr - no longer needs CRYPTO_SEQIV date: 4 months ago config: ia64-randconfig-s031-20200830 (attached as .config) compiler: ia64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-191-g10164920-dirty git checkout f23efcbcc523b09c2ee359a35eb3897dc1764fd3 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! ERROR: modpost: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! ERROR: modpost: "min_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! ERROR: modpost: "max_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! ERROR: modpost: "max_low_pfn" [drivers/tty/serial/fsl_lpuart.ko] undefined! ERROR: modpost: "min_low_pfn" [drivers/tty/serial/fsl_lpuart.ko] undefined! ERROR: modpost: "max_low_pfn" [crypto/tcrypt.ko] undefined! ERROR: modpost: "min_low_pfn" [crypto/tcrypt.ko] undefined! >> ERROR: modpost: "max_low_pfn" [crypto/drbg.ko] undefined! >> ERROR: modpost: "min_low_pfn" [crypto/drbg.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH AUTOSEL 5.4 10/58] mips: vdso: fix 'jalr t9' crash in vdso code
On Sat, Aug 29, 2020 at 04:37:32PM +0200, Hauke Mehrtens wrote: On 8/29/20 3:56 PM, Sasha Levin wrote: On Sat, Aug 29, 2020 at 03:08:01PM +0200, Hauke Mehrtens wrote: On 3/5/20 6:13 PM, Sasha Levin wrote: From: Victor Kamensky [ Upstream commit d3f703c4359ff06619b2322b91f69710453e6b6d ] Observed that when kernel is built with Yocto mips64-poky-linux-gcc, and mips64-poky-linux-gnun32-gcc toolchain, resulting vdso contains 'jalr t9' instructions in its code and since in vdso case nobody sets GOT table code crashes when instruction reached. On other hand observed that when kernel is built mips-poky-linux-gcc toolchain, the same 'jalr t9' instruction are replaced with PC relative function calls using 'bal' instructions. The difference boils down to -mrelax-pic-calls and -mexplicit-relocs gcc options that gets different default values depending on gcc target triplets and corresponding binutils. -mrelax-pic-calls got enabled by default only in mips-poky-linux-gcc case. MIPS binutils ld relies on R_MIPS_JALR relocation to convert 'jalr t9' into 'bal' and such relocation is generated only if -mrelax-pic-calls option is on. Please note 'jalr t9' conversion to 'bal' can happen only to static functions. These static PIC calls use mips local GOT entries that are supposed to be filled with start of DSO value by run-time linker (missing in VDSO case) and they do not have dynamic relocations. Global mips GOT entries must have dynamic relocations and they should be prevented by cmd_vdso_check Makefile rule. Solution call out -mrelax-pic-calls and -mexplicit-relocs options explicitly while compiling MIPS vdso code. That would get correct and consistent between different toolchains behaviour. Reported-by: Bruce Ashfield Signed-off-by: Victor Kamensky Signed-off-by: Paul Burton Cc: linux-m...@vger.kernel.org Cc: Ralf Baechle Cc: James Hogan Cc: Vincenzo Frascino Cc: richard.pur...@linuxfoundation.org Signed-off-by: Sasha Levin --- arch/mips/vdso/Makefile | 1 + 1 file changed, 1 insertion(+) Hi Sasha, Why was this not added to the 5.4 stable branch? Some OpenWrt users ran into this problem with kernel 5.4 on MIPS64 [0]. We backported this patch on our own in OpenWrt [1], but it should be added to the sable branch in my opinion as it fixes a real problem. @Sasha: Can you add it to the 5.4 stable branch or should I send some special email? It failed building on 5.4. If you'd like it included, please send me a tested backport for 5.4. I successfully compiled a kernel 5.4.61 with this patch on top with GCC 8.4 for MIPS 64 big and little Endian. What was broken in your compile test? See https://lore.kernel.org/stable/bfdce3ef-5fe9-8dab-1695-be3d33727...@roeck-us.net/ -- Thanks, Sasha
Re: [PATCH] fat: Avoid oops when bdi->io_pages==0
Matthew Wilcox writes: > On Sun, Aug 30, 2020 at 09:59:41AM +0900, OGAWA Hirofumi wrote: >> On one system, there was bdi->io_pages==0. This seems to be the bug of >> a driver somewhere, and should fix it though. Anyway, it is better to >> avoid the divide-by-zero Oops. >> >> So this check it. >> >> Signed-off-by: OGAWA Hirofumi >> Cc: >> --- >> fs/fat/fatent.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c >> index f7e3304..98a1c4f 100644 >> --- a/fs/fat/fatent.c2020-08-30 06:52:47.251564566 +0900 >> +++ b/fs/fat/fatent.c2020-08-30 06:54:05.838319213 +0900 >> @@ -660,7 +660,7 @@ static void fat_ra_init(struct super_blo >> if (fatent->entry >= ent_limit) >> return; >> >> -if (ra_pages > sb->s_bdi->io_pages) >> +if (sb->s_bdi->io_pages && ra_pages > sb->s_bdi->io_pages) >> ra_pages = rounddown(ra_pages, sb->s_bdi->io_pages); > > Wait, rounddown? ->io_pages is supposed to be the maximum number of > pages to readahead. Shouldn't this be max() instead of rounddown()? Hm, io_pages is limited by driver setting too, and io_pages can be lower than ra_pages, e.g. usb storage. Assuming ra_pages is user intent of readahead window. So if io_pages is lower than ra_pages, this try ra_pages to align of io_pages chunk, but not bigger than ra_pages. Because if block layer splits I/O requests to hard limit, then I/O is not optimal. So it is intent, I can be misunderstanding though. Thanks. -- OGAWA Hirofumi
Re: [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs
> > > You could make a good guess at matching to two together, but it is > > > error prone. Phys are low level things which the user is not really > > > involved in. They interact with interface names. ethtool, ip, etc, all > > > use interface names. In fact, i don't know of any tool which uses > > > phydev names. > > > > So... proposal: > > > > Users should not be dealing with sysfs interface directly, anyway. We > > should have a tool for that. It can live in kernel/tools somewhere, I > > guess. > > We already have one, ethtool(1). > > > > > Would we name leds phy0:... (with simple incrementing number), and > > expose either interface name or phydev name as a attribute? > > > > So user could do > > > > cat /sys/class/leds/phy14:green:foobar/netdev > > lan5@eth1: I forgot about network name spaces. There can be multiple interfaces with the name eth0, each in its own network namespace. For your proposal to work, /sys/class/leds/phy14:green:foobar needs to be in the network namespace, so it is only visible to other processes in the same name space, and lan5@eth1 is then unique to that namespace. > Which is the wrong way around. ethtool will be passed the interface > name and an PHY descriptor of some sort, and it has to go search > through all the LEDs to find the one with this attribute. I would be > much more likely to add a sysfs link from > /sys/class/net/lan5/phy:left:green to > /sys/class/leds/phy14:left:green. I need to test a bit, but i think this works. Everything under /sys/class/net is network namespace aware. You only see /sys/class/net/lan5 if there is a lan5 is in the current name space, and you see the current namespaces version of lan5.. A sysfs symlink out of namespace to /sys/class/led should work, assuming /sys/class/led is namespace unaware, and phy14 is unique across all network name spaces. But you cannot have a link in the opposite direction from /sys/class/led/phy14 to /sys/class/net/lan5, since it has no idea which lan5 to symlink to. Andrew
Re: [PATCH 1/3] arm64: dts: imx8mm-evk: remove orphaned pinctrl-names property
On Sun, Aug 23, 2020 at 11:05:03AM +0200, Krzysztof Kozlowski wrote: > The "pinctrl-names" property in iomux node does not make sense on its > own (without "pinctrl-X"). > > Signed-off-by: Krzysztof Kozlowski Applied all, thanks.
Re: [PATCH] ARM: dts: imx6q-kontron-samx6i: Remove old fsl,spi-num-chipselects
On Sun, Aug 23, 2020 at 10:49:20AM +0200, Krzysztof Kozlowski wrote:
> The property "fsl,spi-num-chipselects" is gone since commit 790739c4417c
> ("dt-bindings: spi: Convert imx cspi to json-schema").
>
> Signed-off-by: Krzysztof Kozlowski
Applied, thanks.
[PATCH] iomap: fix WARN_ON_ONCE() from unprivileged users
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert it to
pr_warn_ratelimited() to let users know their workloads are racing.
Thanks Dave Chinner for the initial analysis of the racing reproducers.
Signed-off-by: Qian Cai
---
fs/iomap/direct-io.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index c1aafb2ab990..6a6b4bc13269 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -389,7 +389,14 @@ iomap_dio_actor(struct inode *inode, loff_t pos, loff_t
length,
case IOMAP_INLINE:
return iomap_dio_inline_actor(inode, pos, length, dio, iomap);
default:
- WARN_ON_ONCE(1);
+ /*
+* DIO is not serialised against mmap() access at all, and so
+* if the page_mkwrite occurs between the writeback and the
+* iomap_apply() call in the DIO path, then it will see the
+* DELALLOC block that the page-mkwrite allocated.
+*/
+ pr_warn_ratelimited("page_mkwrite() is racing with DIO read
(iomap->type = %u).\n",
+ iomap->type);
return -EIO;
}
}
--
2.18.4
Re: [PATCH RFC 0/2] simple sysfs wrappers for single values
On Sat, 2020-08-29 at 17:28 -0700, Joe Perches wrote: > On Sun, 2020-08-30 at 00:37 +0100, Alex Dewar wrote: > > Hi all, > > > > I've noticed there seems to have been a fair amount of discussion around > > the subject of possible helper methods for use in the context of sysfs > > show methods (which I haven't had a chance to go through in detail yet > > -- sorry!), so I thought I'd send out a couple of patches I've been > > working on for this, in case it's of any interest to anyone. > > If you really want to do this, I suggest you get use > wrappers like sysfs_emit_string, sysfs_emit_int, sysfs_emit_u64 > though I don't see _that_ much value. Just fyi: the treewide converted sysfs_emit uses end up with these integer outputs: $ git grep -P -oh 'sysfs_emit\(buf, "%\d*[luixd]*\\n"' | \ sort | uniq -c | sort -rn 1482 sysfs_emit(buf, "%d\n" 549 sysfs_emit(buf, "%u\n" 118 sysfs_emit(buf, "%ld\n" 100 sysfs_emit(buf, "%lu\n" 78 sysfs_emit(buf, "%llu\n" 62 sysfs_emit(buf, "%i\n" 47 sysfs_emit(buf, "%x\n" 24 sysfs_emit(buf, "%lld\n" 12 sysfs_emit(buf, "%llx\n" 12 sysfs_emit(buf, "%08x\n" 12 sysfs_emit(buf, "%02x\n" 10 sysfs_emit(buf, "%016llx\n" 8 sysfs_emit(buf, "%04x\n" 6 sysfs_emit(buf, "%lx\n" 5 sysfs_emit(buf, "%02d\n" 4 sysfs_emit(buf, "%04d\n" 2 sysfs_emit(buf, "%08lx\n" 1 sysfs_emit(buf, "%li\n" 1 sysfs_emit(buf, "%4x\n" 1 sysfs_emit(buf, "%0x\n" 1 sysfs_emit(buf, "%06x\n" 1 sysfs_emit(buf, "%03x\n" 1 sysfs_emit(buf, "%01x\n" >
Re: [PATCH] fat: Avoid oops when bdi->io_pages==0
On Sun, Aug 30, 2020 at 09:59:41AM +0900, OGAWA Hirofumi wrote: > On one system, there was bdi->io_pages==0. This seems to be the bug of > a driver somewhere, and should fix it though. Anyway, it is better to > avoid the divide-by-zero Oops. > > So this check it. > > Signed-off-by: OGAWA Hirofumi > Cc: > --- > fs/fat/fatent.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c > index f7e3304..98a1c4f 100644 > --- a/fs/fat/fatent.c 2020-08-30 06:52:47.251564566 +0900 > +++ b/fs/fat/fatent.c 2020-08-30 06:54:05.838319213 +0900 > @@ -660,7 +660,7 @@ static void fat_ra_init(struct super_blo > if (fatent->entry >= ent_limit) > return; > > - if (ra_pages > sb->s_bdi->io_pages) > + if (sb->s_bdi->io_pages && ra_pages > sb->s_bdi->io_pages) > ra_pages = rounddown(ra_pages, sb->s_bdi->io_pages); Wait, rounddown? ->io_pages is supposed to be the maximum number of pages to readahead. Shouldn't this be max() instead of rounddown()?
[PATCH] fat: Avoid oops when bdi->io_pages==0
On one system, there was bdi->io_pages==0. This seems to be the bug of a driver somewhere, and should fix it though. Anyway, it is better to avoid the divide-by-zero Oops. So this check it. Signed-off-by: OGAWA Hirofumi Cc: --- fs/fat/fatent.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c index f7e3304..98a1c4f 100644 --- a/fs/fat/fatent.c 2020-08-30 06:52:47.251564566 +0900 +++ b/fs/fat/fatent.c 2020-08-30 06:54:05.838319213 +0900 @@ -660,7 +660,7 @@ static void fat_ra_init(struct super_blo if (fatent->entry >= ent_limit) return; - if (ra_pages > sb->s_bdi->io_pages) + if (sb->s_bdi->io_pages && ra_pages > sb->s_bdi->io_pages) ra_pages = rounddown(ra_pages, sb->s_bdi->io_pages); reada_blocks = ra_pages << (PAGE_SHIFT - sb->s_blocksize_bits + 1); _ -- OGAWA Hirofumi
[PATCH] block: Set default value to bdi->io_pages instead of zero
This may not enough to guarantee ->io_pages is not zero though, instead of leaving ->io_pages as zero, this initializing ->io_pages to sane value. (maybe some part of NVMe driver seems to be) Signed-off-by: OGAWA Hirofumi --- block/blk-core.c |1 + 1 file changed, 1 insertion(+) diff --git a/block/blk-core.c b/block/blk-core.c index 03252af..619a3dc 100644 --- a/block/blk-core.c 2020-08-30 06:47:21.221530450 +0900 +++ b/block/blk-core.c 2020-08-30 06:48:05.805875540 +0900 @@ -526,6 +526,7 @@ struct request_queue *__blk_alloc_queue( goto fail_stats; q->backing_dev_info->ra_pages = VM_READAHEAD_PAGES; + q->backing_dev_info->io_pages = VM_READAHEAD_PAGES; q->backing_dev_info->capabilities = BDI_CAP_CGROUP_WRITEBACK; q->node = node_id; _ -- OGAWA Hirofumi
Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
On 2020-08-24 15:10, Khazhismel Kumykov wrote:
> CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping.
>
> Retain CAP_SYS_ADMIN permission for backwards compatibility.
>
> Signed-off-by: Khazhismel Kumykov
> ---
> block/ioprio.c | 2 +-
> include/uapi/linux/capability.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> v2: fix embarrassing logic mistake
> diff --git a/block/ioprio.c b/block/ioprio.c
> index 77bcab11dce5..276496246fe9 100644
> --- a/block/ioprio.c
> +++ b/block/ioprio.c
> @@ -69,7 +69,7 @@ int ioprio_check_cap(int ioprio)
>
> switch (class) {
> case IOPRIO_CLASS_RT:
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_NICE) && !capable(CAP_SYS_ADMIN))
> return -EPERM;
> /* fall through */
> /* rt has prio field too */
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 395dd0df8d08..c6ca33034147 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -288,6 +288,8 @@ struct vfs_ns_cap_data {
> processes and setting the scheduling algorithm used by another
> process. */
> /* Allow setting cpu affinity on other processes */
> +/* Allow setting realtime ioprio class */
> +/* Allow setting ioprio class on other processes */
>
> #define CAP_SYS_NICE 23
>From https://www.kernel.org/doc/man-pages/linux-api-ml.html:
"all Linux kernel patches that change userspace interfaces should be CCed
to linux-...@vger.kernel.org"
So I have added the linux-api mailing list to the Cc-list. Anyway:
Reviewed-by: Bart Van Assche
arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:258: undefined reference to `__ubsan_handle_type_mismatch_v1'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1127b219ce9481c84edad9711626d856127d5e51 commit: 8d58f222e85f01da0c0e1fc1e77986c86de889e2 ubsan: disable UBSAN_ALIGNMENT under COMPILE_TEST date: 4 months ago config: mips-randconfig-r025-20200829 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 8d58f222e85f01da0c0e1fc1e77986c86de889e2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `zlib_inflate_table': >> arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:258: >> undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:258: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:240: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:240: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:240: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:240: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:96: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:96: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:94: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:94: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:101: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:96: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:101: undefined reference to `__ubsan_handle_type_mismatch_v1' >> mipsel-linux-ld: >> arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:258: >> undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:258: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:133: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:133: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:133: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:113: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:113: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:129: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:129: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:129: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:129: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:129: undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:129: undefined reference to `__ubsan_handle_type_mismatch_v1' mipsel-linux-ld: arch/mips/boot/compressed/../../../../lib/zlib_inflate/inftrees.c:120: undefined reference to `__ubsan_handle_type_mismatch_v1'
Re: [PATCH V2] sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
On Sat, 2020-08-29 at 16:48 -0700, Joe Perches wrote:
> Output defects can exist in sysfs content using sprintf and snprintf.
>
> sprintf does not know the PAGE_SIZE maximum of the temporary buffer
> used for outputting sysfs content and it's possible to overrun the
> PAGE_SIZE buffer length.
>
> Add a generic sysfs_emit function that knows that the size of the
> temporary buffer and ensures that no overrun is done.
>
> Add a generic sysfs_emit_at function that can be used in multiple
> call situations that also ensures that no overrun is done.
This preliminary coccinelle script converts ~5000 instances treewide.
There are still many remaining instances that could be converted.
$ git grep -w sysfs_emit -- '*.[ch]'|wc -l
4702
$ git grep -w sysfs_emit_at -- '*.[ch]'|wc -l
229
$ cat sysfs_emit.cocci
@@
identifier d_show =~ "^.*show.*$";
identifier arg1, arg2, arg3;
@@
ssize_t d_show(struct device *
- arg1
+ dev
, struct device_attribute *
- arg2
+ attr
, char *
- arg3
+ buf
)
{
...
(
- arg1
+ dev
|
- arg2
+ attr
|
- arg3
+ buf
)
...
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
expression chr;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- strcpy(buf, chr);
+ sysfs_emit(buf, chr);
...>
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
- len += scnprintf(buf + len, PAGE_SIZE - len,
+ len += sysfs_emit_at(buf, len,
...);
...>
return len;
}
@@
identifier d_show =~ "^.*show.*$";
identifier dev, attr, buf;
expression chr;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
- strcpy(buf, chr);
- return strlen(buf);
+ return sysfs_emit(buf, chr);
}
@@
identifier k_show =~ "^.*show.*$";
identifier arg1, arg2, arg3;
@@
ssize_t k_show(struct kobject *
- arg1
+ kobj
, struct kobj_attribute *
- arg2
+ attr
, char *
- arg3
+ buf
)
{
...
(
- arg1
+ kobj
|
- arg2
+ attr
|
- arg3
+ buf
)
...
}
@@
identifier k_show =~ "^.*show.*$";
identifier kobj, attr, buf;
@@
ssize_t k_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
{
<...
return
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier k_show =~ "^.*show.*$";
identifier kobj, attr, buf;
@@
ssize_t k_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
{
<...
return
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier k_show =~ "^.*show.*$";
identifier kobj, attr, buf;
@@
ssize_t k_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
{
<...
return
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier k_show =~ "^.*show.*$";
identifier kobj, attr, buf;
expression chr;
@@
ssize_t k_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
{
<...
return
-
Re: possible deadlock in __lock_task_sighand
This is already fixed, and it went upstream yesterday. #syz fix: io_uring: don't recurse on tsk->sighand->siglock with signalfd -- Jens Axboe
[PATCH] MAINTAINERS: IA64: mark Status as Odd Fixes only
From: Randy Dunlap IA64 isn't really being maintained, so mark it as Odd Fixes only. Cc: Tony Luck Cc: Fenghua Yu Cc: linux-i...@vger.kernel.org Signed-off-by: Randy Dunlap --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200828.orig/MAINTAINERS +++ linux-next-20200828/MAINTAINERS @@ -8316,7 +8316,7 @@ IA64 (Itanium) PLATFORM M: Tony Luck M: Fenghua Yu L: linux-i...@vger.kernel.org -S: Maintained +S: Odd Fixes T: git git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git F: Documentation/ia64/ F: arch/ia64/
Re: [PATCH RFC 0/2] simple sysfs wrappers for single values
On Sun, 2020-08-30 at 00:37 +0100, Alex Dewar wrote: > Hi all, > > I've noticed there seems to have been a fair amount of discussion around > the subject of possible helper methods for use in the context of sysfs > show methods (which I haven't had a chance to go through in detail yet > -- sorry!), so I thought I'd send out a couple of patches I've been > working on for this, in case it's of any interest to anyone. If you really want to do this, I suggest you get use wrappers like sysfs_emit_string, sysfs_emit_int, sysfs_emit_u64 though I don't see _that_ much value.
possible deadlock in __lock_task_sighand
Hello,
syzbot found the following issue on:
HEAD commit:abb3438d Merge tag 'm68knommu-for-v5.9-rc3' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10bb510590
kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
dashboard link: https://syzkaller.appspot.com/bug?extid=6e8f5b555cce8fac0423
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123a399690
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=158b8eb690
The issue was bisected to:
commit 0ba9c9edcd152158a0e321a4c13ac1dfc571ff3d
Author: Jens Axboe
Date: Fri Aug 7 01:41:50 2020 +
io_uring: use TWA_SIGNAL for task_work uncondtionally
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1672c54990
final oops: https://syzkaller.appspot.com/x/report.txt?x=1572c54990
console output: https://syzkaller.appspot.com/x/log.txt?x=1172c54990
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6e8f5b555cce8fac0...@syzkaller.appspotmail.com
Fixes: 0ba9c9edcd15 ("io_uring: use TWA_SIGNAL for task_work uncondtionally")
WARNING: possible recursive locking detected
5.9.0-rc2-syzkaller #0 Not tainted
syz-executor339/7010 is trying to acquire lock:
888094030058 (>siglock){}-{2:2}, at:
__lock_task_sighand+0x106/0x2d0 kernel/signal.c:1390
but task is already holding lock:
888094030058 (>siglock){}-{2:2}, at:
force_sig_info_to_task+0x6c/0x3a0 kernel/signal.c:1316
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>siglock);
lock(>siglock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by syz-executor339/7010:
#0: 888094030058 (>siglock){}-{2:2}, at:
force_sig_info_to_task+0x6c/0x3a0 kernel/signal.c:1316
#1: 8880940300a0 (>signalfd_wqh){}-{2:2}, at:
__wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:122
#2: 89bd6900 (rcu_read_lock){}-{1:2}, at:
__lock_task_sighand+0x0/0x2d0 kernel/signal.c:1352
stack backtrace:
CPU: 1 PID: 7010 Comm: syz-executor339 Not tainted 5.9.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_deadlock_bug kernel/locking/lockdep.c:2391 [inline]
check_deadlock kernel/locking/lockdep.c:2432 [inline]
validate_chain kernel/locking/lockdep.c:3202 [inline]
__lock_acquire.cold+0x115/0x396 kernel/locking/lockdep.c:4426
lock_acquire+0x1f1/0xad0 kernel/locking/lockdep.c:5005
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x8c/0xc0 kernel/locking/spinlock.c:159
__lock_task_sighand+0x106/0x2d0 kernel/signal.c:1390
lock_task_sighand include/linux/sched/signal.h:687 [inline]
task_work_add+0x1d7/0x290 kernel/task_work.c:51
io_req_task_work_add fs/io_uring.c:1765 [inline]
__io_async_wake+0x415/0x980 fs/io_uring.c:4589
__wake_up_common+0x147/0x650 kernel/sched/wait.c:93
__wake_up_common_lock+0xd0/0x130 kernel/sched/wait.c:123
signalfd_notify include/linux/signalfd.h:22 [inline]
__send_signal+0x75b/0xf90 kernel/signal.c:1163
force_sig_info_to_task+0x2a0/0x3a0 kernel/signal.c:1333
force_sig_fault_to_task kernel/signal.c:1672 [inline]
force_sig_fault+0xb0/0xf0 kernel/signal.c:1679
__bad_area_nosemaphore+0x32a/0x480 arch/x86/mm/fault.c:778
do_user_addr_fault+0x852/0xbf0 arch/x86/mm/fault.c:1257
handle_page_fault arch/x86/mm/fault.c:1351 [inline]
exc_page_fault+0xa8/0x160 arch/x86/mm/fault.c:1404
asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:538
RIP: 0033:0x4013f9
Code: 00 20 00 c6 04 25 3d 02 00 20 00 c6 04 25 3e 02 00 20 00 c6 04 25 3f 02
00 20 00 48 8b 15 a7 ac 2d 00 48 8b 34 25 00 02 00 20 <8b> 8a 0c 01 00 00 48 89
30 48 8b 34 25 08 02 00 20 c1 e1 04 48 89
RSP: 002b:7f8507d67d10 EFLAGS: 00010246
RAX: RBX: 006f0038 RCX:
RDX: RSI: 00060002 RDI:
RBP: 006f0030 R08: R09:
R10: R11: 0246 R12: 006f003c
R13: 7f8507d67d10 R14: 7f8507d67d10 R15: 0001
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v9 4/4] scsi: ufs: Prepare HPB read for cached sub-region
On 2020-08-28 00:19, Daejun Park wrote: > This patch changes the read I/O to the HPB read I/O. Reviewed-by: Bart Van Assche
Re: [PATCH] sysfs: Add sysfs_emit to replace sprintf to PAGE_SIZE buffers.
On Sun, 2020-08-30 at 00:53 +0300, Denis Efremov wrote: > > Anyway, this will need updating, likely with better examples. [] > I think it's good to reflect in docs that sysfs_emit_at/sysfs_emit_pos is > only for "legacy" code and should not be used in new code (checkpatch.pl > warning?) > because of sysfs design principles. sysfs_emit_at is also used for arrays.
[PATCH V2] sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
Output defects can exist in sysfs content using sprintf and snprintf.
sprintf does not know the PAGE_SIZE maximum of the temporary buffer
used for outputting sysfs content and it's possible to overrun the
PAGE_SIZE buffer length.
Add a generic sysfs_emit function that knows that the size of the
temporary buffer and ensures that no overrun is done.
Add a generic sysfs_emit_at function that can be used in multiple
call situations that also ensures that no overrun is done.
Signed-off-by: Joe Perches
---
V2: Simplify sysfs_emit and add sysfs_emit_at
Include Documentation change
Documentation/filesystems/sysfs.rst | 8 ++---
fs/sysfs/file.c | 49 +
include/linux/sysfs.h | 15 +
3 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/sysfs.rst
b/Documentation/filesystems/sysfs.rst
index ab0f7795792b..d44249050f4a 100644
--- a/Documentation/filesystems/sysfs.rst
+++ b/Documentation/filesystems/sysfs.rst
@@ -242,12 +242,10 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
- buffer. This is the return value of scnprintf().
+ buffer.
-- show() must not use snprintf() when formatting the value to be
- returned to user space. If you can guarantee that an overflow
- will never happen you can use sprintf() otherwise you must use
- scnprintf().
+- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
+ the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index eb6897ab78e7..e8c6d20bab8e 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -707,3 +707,52 @@ int sysfs_change_owner(struct kobject *kobj, kuid_t kuid,
kgid_t kgid)
return 0;
}
EXPORT_SYMBOL_GPL(sysfs_change_owner);
+
+/**
+ * sysfs_emit - scnprintf equivalent, aware of PAGE_SIZE buffer.
+ * @buf: start of PAGE_SIZE buffer.
+ * @fmt: format
+ * @...: optional arguments to @format
+ *
+ *
+ * Returns number of characters written to @buf.
+ */
+int sysfs_emit(char *buf, const char *fmt, ...)
+{
+ va_list args;
+ int len;
+
+ va_start(args, fmt);
+ len = vscnprintf(buf, PAGE_SIZE, fmt, args);
+ va_end(args);
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(sysfs_emit);
+
+/**
+ * sysfs_emit_at - scnprintf equivalent, aware of PAGE_SIZE buffer.
+ * @buf: start of PAGE_SIZE buffer.
+ * @at:offset in @buf to start write in bytes
+ * @at must be >= 0 && < PAGE_SIZE
+ * @fmt: format
+ * @...: optional arguments to @fmt
+ *
+ *
+ * Returns number of characters written starting at &@buf[@at].
+ */
+int sysfs_emit_at(char *buf, int at, const char *fmt, ...)
+{
+ va_list args;
+ int len;
+
+ if (WARN(at < 0 || at >= PAGE_SIZE, "invalid sysfs_emit_at: %d\n", at))
+ return 0;
+
+ va_start(args, fmt);
+ len = vscnprintf(buf + at, PAGE_SIZE - at, fmt, args);
+ va_end(args);
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(sysfs_emit_at);
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 34e84122f635..2caa34c1ca1a 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -329,6 +329,10 @@ int sysfs_groups_change_owner(struct kobject *kobj,
int sysfs_group_change_owner(struct kobject *kobj,
const struct attribute_group *groups, kuid_t kuid,
kgid_t kgid);
+__printf(2, 3)
+int sysfs_emit(char *buf, const char *fmt, ...);
+__printf(3, 4)
+int sysfs_emit_at(char *buf, int at, const char *fmt, ...);
#else /* CONFIG_SYSFS */
@@ -576,6 +580,17 @@ static inline int sysfs_group_change_owner(struct kobject
*kobj,
return 0;
}
+__printf(2, 3)
+static inline int sysfs_emit(char *buf, const char *fmt, ...)
+{
+ return 0;
+}
+
+__printf(3, 4)
+static inline int sysfs_emit_at(char *buf, int at, const char *fmt, ...)
+{
+ return 0;
+}
#endif /* CONFIG_SYSFS */
static inline int __must_check sysfs_create_file(struct kobject *kobj,
--
2.26.0
Re: [PATCH v9 3/4] scsi: ufs: L2P map management for HPB read
On 2020-08-28 00:19, Daejun Park wrote:
> +static unsigned int ufshpb_host_map_kbytes = 1024;
A comment that explains where this value comes from would be welcome.
> +static struct ufshpb_req *ufshpb_get_map_req(struct ufshpb_lu *hpb,
> + struct ufshpb_subregion *srgn)
> +{
> + struct ufshpb_req *map_req;
> + struct request *req;
> + struct bio *bio;
> +
> + map_req = kmem_cache_alloc(hpb->map_req_cache, GFP_KERNEL);
> + if (!map_req)
> + return NULL;
> +
> + req = blk_get_request(hpb->sdev_ufs_lu->request_queue,
> + REQ_OP_SCSI_IN, BLK_MQ_REQ_PREEMPT);
Why BLK_MQ_REQ_PREEMPT? Since this code is only executed while medium access
commands are processed and since none of these commands have the PREEMPT flag
set I think that the PREEMPT flag should be left out. Otherwise there probably
will be weird interactions with runtime suspended devices.
Is it acceptable that the above blk_get_request() call blocks if a UFS device
has been runtime suspended? If not, consider using the flag BLK_MQ_REQ_NOWAIT
instead.
> + bio = bio_alloc(GFP_KERNEL, hpb->pages_per_srgn);
> + if (!bio) {
> + blk_put_request(req);
> + goto free_map_req;
> + }
If the blk_get_request() would be modified such that it doesn't wait, this
call may have to be modified too (GFP_NOWAIT?).
> + if (rgn->rgn_state == HPB_RGN_INACTIVE) {
> + if (atomic_read(_info->active_cnt)
> + == lru_info->max_lru_active_cnt) {
When splitting a line, please put comparison operators at the end of the line
instead of at the start, e.g. as follows:
if (atomic_read(_info->active_cnt) ==
lru_info->max_lru_active_cnt) {
> + pool_size = DIV_ROUND_UP(ufshpb_host_map_kbytes * 1024, PAGE_SIZE);
Please use PAGE_ALIGN() to align to the next page boundary.
Thanks,
Bart.
Re: [f2fs-dev] [PATCH] f2fs: make fibmap consistent with fiemap for compression chunk
On 2020-8-28 11:49, Daeho Jeong wrote:
From: Daeho Jeong
Currently fibmap returns zero address for compression chunk. But it
is not consistent with the output of fiemap, since fiemap returns
real pysical block address related to the compression chunk. Therefore
I suggest fibmap returns the same output with fiemap.
We can return real physical block address in fiemap, because we have set
FIEMAP_EXTENT_ENCODED flag in extent.fe_flags, then user can be noticed that he
can not just read/write that block address for access/update in-there data.
Quoted from Documentation/filesystems/fiemap.rst
"
FIEMAP_EXTENT_ENCODED
This extent does not consist of plain filesystem blocks but is
encoded (e.g. encrypted or compressed). Reading the data in this
extent via I/O to the block device will have undefined results.
"
However, there is no such flag in fibmap interface, so I just return block
address for those logical pages in non-compressed cluster.
Thanks,
Signed-off-by: Daeho Jeong
---
fs/f2fs/data.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c1b676be67b9..8c26c5d0c778 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3708,36 +3708,6 @@ static int f2fs_set_data_page_dirty(struct page *page)
return 0;
}
-
-static sector_t f2fs_bmap_compress(struct inode *inode, sector_t block)
-{
-#ifdef CONFIG_F2FS_FS_COMPRESSION
- struct dnode_of_data dn;
- sector_t start_idx, blknr = 0;
- int ret;
-
- start_idx = round_down(block, F2FS_I(inode)->i_cluster_size);
-
- set_new_dnode(, inode, NULL, NULL, 0);
- ret = f2fs_get_dnode_of_data(, start_idx, LOOKUP_NODE);
- if (ret)
- return 0;
-
- if (dn.data_blkaddr != COMPRESS_ADDR) {
- dn.ofs_in_node += block - start_idx;
- blknr = f2fs_data_blkaddr();
- if (!__is_valid_data_blkaddr(blknr))
- blknr = 0;
- }
-
- f2fs_put_dnode();
- return blknr;
-#else
- return 0;
-#endif
-}
-
-
static sector_t f2fs_bmap(struct address_space *mapping, sector_t block)
{
struct inode *inode = mapping->host;
@@ -3753,9 +3723,6 @@ static sector_t f2fs_bmap(struct address_space *mapping,
sector_t block)
if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
filemap_write_and_wait(mapping);
- if (f2fs_compressed_file(inode))
- blknr = f2fs_bmap_compress(inode, block);
-
if (!get_data_block_bmap(inode, block, , 0))
blknr = tmp.b_blocknr;
out:
{standard input}:1174: Error: inappropriate arguments for opcode 'mpydu'
Hi Nicolas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e77aee1326f7691763aa968eee2f57db37840b9d
commit: 602828c1aade576ac5f3fbd59b4eb014c5fc2414 __div64_const32(): improve the
generic C version
date: 12 months ago
config: arc-allmodconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 602828c1aade576ac5f3fbd59b4eb014c5fc2414
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:1174: Error: inappropriate arguments for opcode 'mpydu'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH RFC 1/2] sysfs: add helpers for safely showing simple strings
Add a helper, sysfs_strscpy(), which simply copies a string and
appends a newline and NUL char to the end, making sure not to overflow
the destination buffer, which MUST be PAGE_SIZE bytes (which is true for
buffers in this context). It includes a compile time check for the
specified destination buffer size.
Also add a helper macro, sysfs_strcpy(), which calls sysfs_strscpy() with
count == PAGE_SIZE, for use with regular NUL-terminated strings. If the
src buffer is a fixed-size array, guarantee that we don't copy beyond its
end by only copying a maximum of sizeof(src) bytes.
Signed-off-by: Alex Dewar
---
fs/sysfs/file.c | 14 ++
include/linux/sysfs.h | 35 +++
2 files changed, 49 insertions(+)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index eb6897ab78e7..2a60e5c6392d 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -707,3 +707,17 @@ int sysfs_change_owner(struct kobject *kobj, kuid_t kuid,
kgid_t kgid)
return 0;
}
EXPORT_SYMBOL_GPL(sysfs_change_owner);
+
+ssize_t __sysfs_strscpy(char *dest, const char *src, size_t count)
+{
+ ssize_t written;
+
+ if (count > PAGE_SIZE)
+ return -EINVAL;
+
+ written = strscpy(dest, src, count - 1);
+ dest[written++] = '\n';
+ dest[written] = '\0';
+ return written;
+}
+EXPORT_SYMBOL_GPL(__sysfs_strscpy);
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 34e84122f635..26e7d9f69dfd 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -162,6 +162,41 @@ static const struct attribute_group _name##_group = {
\
}; \
__ATTRIBUTE_GROUPS(_name)
+/**
+ * sysfs_strscpy - return a string from a show method with terminating
+ * newline to a maximum of count bytes
+ * @dest: destination buffer
+ * @src: string to be emitted
+ * @count: maximum number of bytes to be written to dest
+ */
+#define sysfs_strscpy(dest, src, count) \
+({\
+ BUILD_BUG_ON(__builtin_constant_p(count) && (count) > PAGE_SIZE); \
+ __sysfs_strscpy((dest), (src), (count)); \
+})
+
+ssize_t __sysfs_strscpy(char *dest, const char *src, size_t count);
+
+/**
+ * sysfs_strcpy - return a string from a show method with terminating
+ * newline
+ * @dest: destination buffer
+ * @src: string to be emitted
+ *
+ * This method will only write a maximum of PAGE_SIZE bytes to dest,
+ * ensuring that the output buffer is not overflown. If src is a
+ * fixed-size array, a maximum of sizeof(src) bytes will be copied,
+ * ensuring that memory is not read beyond the end of the array.
+ */
+#define sysfs_strcpy(dest, src) \
+sysfs_strscpy((dest), (src), \
+ __builtin_choose_expr(\
+ __same_type((src), &(src)[0]),\
+ PAGE_SIZE,\
+ min(sizeof(src) + 2, PAGE_SIZE) \
+ ) \
+)
+
struct file;
struct vm_area_struct;
--
2.28.0
[PATCH RFC 2/2] sysfs: add helper macro for showing simple integer values
sysfs attributes are supposed to be only single values, which are
printed into a buffer of PAGE_SIZE. Accordingly, for many simple
attributes, sprintf() can be used like so:
static ssize_t my_show(..., char *buf)
{
...
return sprintf("%d\n", my_integer);
}
The problem is that whilst this use of sprintf() is memory safe, other
cases where e.g. a possibly unterminated string is passed as input, are
not and so use of sprintf() here might make it more difficult to
identify these problematic cases.
Define a macro, sysfs_sprinti(), which outputs the value of a single
integer to a buffer (with terminating "\n\0") and returns the size written.
This way, we can convert over the some of the trivially correct users of
sprintf() and decrease its usage in the kernel source tree.
Another advantage of this approach is that we can now statically check
the type of the integer so that e.g. an unsigned long long will be
formatted as %llu. This will fix cases where the wrong format string has
been passed to sprintf().
Signed-off-by: Alex Dewar
---
include/linux/sysfs.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 26e7d9f69dfd..763316788153 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -197,6 +197,37 @@ sysfs_strscpy((dest), (src),
\
) \
)
+/**
+ * sysfs_sprinti - emit an integer-type value from a sysfs show method
+ * @buf: destination buffer
+ * @x: the variable whose value is to be shown
+ *
+ * The appropriate format is passed to sprintf() according to the type of
+ * x, preventing accidental misuse of format strings.
+ */
+#define sysfs_sprinti(buf, x)
\
+({
\
+ BUILD_BUG_ON(!__builtin_types_compatible_p(typeof(x), unsigned int) &&
\
+ !__builtin_types_compatible_p(typeof(x), unsigned long)
&& \
+ !__builtin_types_compatible_p(typeof(x), unsigned long
long) && \
+ !__builtin_types_compatible_p(typeof(x), int) &&
\
+ !__builtin_types_compatible_p(typeof(x), short) &&
\
+ !__builtin_types_compatible_p(typeof(x), unsigned
short)); \
+ __builtin_choose_expr(
\
+ __builtin_types_compatible_p(typeof(x), unsigned int),
\
+ sprintf(buf, "%u\n", (unsigned int)(x)),
\
+ __builtin_choose_expr(
\
+ __builtin_types_compatible_p(typeof(x), unsigned long),
\
+ sprintf(buf, "%lu\n", (unsigned long)(x)),
\
+ __builtin_choose_expr(
\
+ __builtin_types_compatible_p(typeof(x),
unsigned long long), \
+ sprintf(buf, "%llu\n", (unsigned long
long)(x)), \
+ sprintf(buf, "%d\n", (int)(x))
\
+ )
\
+ )
\
+ );
\
+})
+
struct file;
struct vm_area_struct;
--
2.28.0
[PATCH RFC 0/2] simple sysfs wrappers for single values
Hi all, I've noticed there seems to have been a fair amount of discussion around the subject of possible helper methods for use in the context of sysfs show methods (which I haven't had a chance to go through in detail yet -- sorry!), so I thought I'd send out a couple of patches I've been working on for this, in case it's of any interest to anyone. My idea was to have a few simple wrappers for returning single values via sysfs, as in theory that's how sysfs should be being used. This isn't going to be usable for more complicated cases, but at least by doing this we should be able to make it easier to direct the attention of code checkers (either automated or the flesh-and-blood kind) towards the potentially more problematic cases. Hopefully we should be able to convert over many of the more trivial cases to these helpers using Coccinelle. For the number helper (sysfs_sprinti), I opted to go for a macro which can handle short, int, ULL etc., though equally we could go for differently named inline functions instead. Either way, I think enforcing the type of input arguments and not allowing users to pass format strings is the way to go. Even for e.g. "sprintf(buf, "%llu\n", my_number)", there is the possibility that my_number could be of type int and so mishandle negative values. Let's make it easy for maintainers to review at a glance, without having to remember what type my_number was declared as. With the string helpers we can make sure that we aren't overflowing the destination buffer, but I've also put in a check so that we don't read beyond the end of the source buffer either, in the case that it's a fixed-size array. So if we do have an automated changeover with Coccinelle then we should make things safer too :-) Anyway, I'm off to bed now but I'll check for messages in the morning. Any feedback gratefully received! Best, Alex
Re: [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs
On Sun, Aug 30, 2020 at 12:43:51AM +0200, Pavel Machek wrote: > Hi! > > > > > And no, I don't want phydev name there. > > > > > > Ummm. Can we get little more explanation on that? I fear that LED > > > device renaming will be tricky and phydev would work around that > > > nicely. > > > > Hi Pavel > > > > The phydev name is not particularly nice: > > > > !mdio-mux!mdio@1!switch@0!mdio:00 > > !mdio-mux!mdio@1!switch@0!mdio:01 > > !mdio-mux!mdio@1!switch@0!mdio:02 > > !mdio-mux!mdio@2!switch@0!mdio:00 > > !mdio-mux!mdio@2!switch@0!mdio:01 > > !mdio-mux!mdio@2!switch@0!mdio:02 > > !mdio-mux!mdio@4!switch@0!mdio:00 > > !mdio-mux!mdio@4!switch@0!mdio:01 > > !mdio-mux!mdio@4!switch@0!mdio:02 > > 400d.ethernet-1:00 > > 400d.ethernet-1:01 > > fixed-0:00 > > Not nice, I see. In particular, it contains ":"... which would be a > problem. > > > The interface name are: > > > > 1: lo: > > 2: eth0: > > 3: eth1: > > 4: lan0@eth1: > > 5: lan1@eth1: > > 6: lan2@eth1: > > 7: lan3@eth1: > > 8: lan4@eth1: > > 9: lan5@eth1: > > 10: lan6@eth1: > > 11: lan7@eth1: > > 12: lan8@eth1: > > 13: optical3@eth1: > > 14: optical4@eth1: > > OTOH... renaming LEDs when interface is renamed... sounds like a > disaster, too. I don't think it is. The stack has all the needed support. There is a notification before the rename, and another notification after the rename. Things like bonding, combing two interfaces into one and load balancing, etc. hook these notifiers. There is plenty of examples to follow. What i don't know about is the lifetime of files under /sys/class/led, does the destroying of an LED block while one of the files is open?. > > You could make a good guess at matching to two together, but it is > > error prone. Phys are low level things which the user is not really > > involved in. They interact with interface names. ethtool, ip, etc, all > > use interface names. In fact, i don't know of any tool which uses > > phydev names. > > So... proposal: > > Users should not be dealing with sysfs interface directly, anyway. We > should have a tool for that. It can live in kernel/tools somewhere, I > guess. We already have one, ethtool(1). > > Would we name leds phy0:... (with simple incrementing number), and > expose either interface name or phydev name as a attribute? > > So user could do > > cat /sys/class/leds/phy14:green:foobar/netdev > lan5@eth1: Which is the wrong way around. ethtool will be passed the interface name and an PHY descriptor of some sort, and it has to go search through all the LEDs to find the one with this attribute. I would be much more likely to add a sysfs link from /sys/class/net/lan5/phy:left:green to /sys/class/leds/phy14:left:green. Andrew
[PATCH 1/1] ARM: dts: bcm2711: Enable ddr modes on emmc2 controller
This patch enables ddr modes for eMMC and SD storage on emmc2,
doubling transfer speed. Previously only single data rate modes were
used, wasting half the available throughput.
The bcm2711 supports both SD and eMMC storage using ddr modes. Testing
show that pcb layout of the Raspberry Pi 4 can support them, too.
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 222d7825e1ab..8b61e258e906 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -191,6 +191,8 @@ {
vqmmc-supply = <_io_1v8_reg>;
vmmc-supply = <_vcc_reg>;
broken-cd;
+ mmc-ddr-3_3v;
+ sd-uhs-ddr50;
status = "okay";
};
--
2.28.0
[PATCH 0/1] Enable ddr modes on emmc2 of Raspberry Pi 4 B
Currently both micro SD cards and eMMC storage attached to a Pi 4 are running in single data rate mode only. However the controller used supports dual data rate modes. This patch enables ddr modes for both sd and mmc storage. I've verified that there are no issues transferring data in ddr mode using multiple micro SD cards and eMMC modules from different vendors. Additionally I've checked signal integrity on the data lines at the micro SD card slot and did not find any issues there either. Tobias Schramm (1): ARM: dts: bcm2711: Enable ddr modes on emmc2 controller arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++ 1 file changed, 2 insertions(+) -- 2.28.0
Re: [PATCH v9 1/4] scsi: ufs: Add HPB feature related parameters
On 2020-08-28 00:17, Daejun Park wrote: > This is a patch for parameters to be used for HPB feature. Reviewed-by: Bart Van Assche
Re: [PATCH v9 2/4] scsi: ufs: Introduce HPB feature
On 2020-08-28 00:18, Daejun Park wrote:
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 618b253e5ec8..df30622a2b67 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -588,6 +588,24 @@ struct ufs_hba_variant_params {
> u16 hba_enable_delay_us;
> u32 wb_flush_threshold;
> };
> +#ifdef CONFIG_SCSI_UFS_HPB
> +/**
> + * struct ufshpb_dev_info - UFSHPB device related info
> + * @num_lu: the number of user logical unit to check whether all lu finished
> + * initialization
> + * @rgn_size: device reported HPB region size
> + * @srgn_size: device reported HPB sub-region size
> + * @slave_conf_cnt: counter to check all lu finished initialization
> + * @hpb_disabled: flag to check if HPB is disabled
> + */
> +struct ufshpb_dev_info {
> + int num_lu;
> + int rgn_size;
> + int srgn_size;
> + atomic_t slave_conf_cnt;
> + bool hpb_disabled;
> +};
> +#endif
Please insert a blank line above "#ifdef CONFIG_SCSI_UFS_HPB"
> +/* HPB enabled lu list */
> +static LIST_HEAD(lh_hpb_lu);
Is it necessary to maintain this list? Or in other words, is it possible to
change all list_for_each_entry(hpb, _hpb_lu, list_hpb_lu) calls into
shost_for_each_device() calls?
> +/* SYSFS functions */
> +#define ufshpb_sysfs_attr_show_func(__name) \
> +static ssize_t __name##_show(struct device *dev, \
> + struct device_attribute *attr, char *buf) \
> +{\
> + struct scsi_device *sdev = to_scsi_device(dev); \
> + struct ufshpb_lu *hpb = sdev->hostdata; \
> + if (!hpb) \
> + return -ENOENT; \
> + return snprintf(buf, PAGE_SIZE, "%d\n", \
> + atomic_read(>stats.__name)); \
> +}\
> +static DEVICE_ATTR_RO(__name)
Please leave a blank line after declarations (between the "hpb" declaration
and "if (!hpb)").
> +#ifndef CONFIG_SCSI_UFS_HPB
> +[...]
> +static struct attribute *hpb_dev_attrs[] = { NULL,};
> +static struct attribute_group ufs_sysfs_hpb_stat_group = {.attrs =
> hpb_dev_attrs,};
> +#else
> +[...]
> +extern struct attribute_group ufs_sysfs_hpb_stat_group;
> +#endif
Defining static variables or arrays in header files is questionable because
the definition of these variables will be duplicated in each source file that
header file is included in. Although the general rule for kernel code is to
confine #ifdefs to header files, for ufs_sysfs_hpb_stat_group I think that
it is better to surround its use with #ifndef CONFIG_SCSI_UFS_HPB / #endif
instead of defining a dummy structure as static variable in a header file if
HPB support is disabled.
Otherwise this patch looks good to me.
Thanks,
Bart.
Re: [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs
Hi! > > > And no, I don't want phydev name there. > > > > Ummm. Can we get little more explanation on that? I fear that LED > > device renaming will be tricky and phydev would work around that > > nicely. > > Hi Pavel > > The phydev name is not particularly nice: > > !mdio-mux!mdio@1!switch@0!mdio:00 > !mdio-mux!mdio@1!switch@0!mdio:01 > !mdio-mux!mdio@1!switch@0!mdio:02 > !mdio-mux!mdio@2!switch@0!mdio:00 > !mdio-mux!mdio@2!switch@0!mdio:01 > !mdio-mux!mdio@2!switch@0!mdio:02 > !mdio-mux!mdio@4!switch@0!mdio:00 > !mdio-mux!mdio@4!switch@0!mdio:01 > !mdio-mux!mdio@4!switch@0!mdio:02 > 400d.ethernet-1:00 > 400d.ethernet-1:01 > fixed-0:00 Not nice, I see. In particular, it contains ":"... which would be a problem. > The interface name are: > > 1: lo: > 2: eth0: > 3: eth1: > 4: lan0@eth1: > 5: lan1@eth1: > 6: lan2@eth1: > 7: lan3@eth1: > 8: lan4@eth1: > 9: lan5@eth1: > 10: lan6@eth1: > 11: lan7@eth1: > 12: lan8@eth1: > 13: optical3@eth1: > 14: optical4@eth1: OTOH... renaming LEDs when interface is renamed... sounds like a disaster, too. > You could make a good guess at matching to two together, but it is > error prone. Phys are low level things which the user is not really > involved in. They interact with interface names. ethtool, ip, etc, all > use interface names. In fact, i don't know of any tool which uses > phydev names. So... proposal: Users should not be dealing with sysfs interface directly, anyway. We should have a tool for that. It can live in kernel/tools somewhere, I guess. Would we name leds phy0:... (with simple incrementing number), and expose either interface name or phydev name as a attribute? So user could do cat /sys/class/leds/phy14:green:foobar/netdev lan5@eth1: and we'd have tool hiding that complexity... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: [PATCH] fs: allow do_renameat2() over bind mounts of the same filesystem.
Matthew Wilcox writes: > On Sat, Aug 29, 2020 at 11:23:34PM +0200, Florian Margaine wrote: >> Al Viro writes: >> >> > On Fri, Aug 28, 2020 at 10:40:35PM +0200, Florian Margaine wrote: >> >> There's currently this seemingly unnecessary limitation that rename() >> >> cannot work over bind mounts of the same filesystem, >> > >> > ... is absolutely deliberate - that's how you set a boundary in the >> > tree, preventing both links and renames across it. >> >> Sorry, I'm not not sure I understand what you're saying. > > Al's saying this is the way an administrator can intentionally prevent > renames. Ah, ok. Thanks! > >> /* >> * FICLONE/FICLONERANGE ioctls enforce that src and dest files are on >> * the same mount. Practically, they only need to be on the same file >> * system. >> */ >> if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb) >> return -EXDEV; > > clone doesn't change the contents of a file, merely how they're laid out > on storage. There's no particular reason for an administrator to > prohibit clone across mount points. signature.asc Description: PGP signature
[PATCH 8/8] regulator: tps65910: Constify static regulator_ops
The only usage of these is to assign their address to the ops field in
the regulator_desc struct, which is a const pointer. Make them const to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps65910-regulator.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/tps65910-regulator.c
b/drivers/regulator/tps65910-regulator.c
index 4eb5b19d2344..faa5b3538167 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -757,7 +757,7 @@ static int tps65911_list_voltage(struct regulator_dev *dev,
unsigned selector)
}
/* Regulator ops (except VRTC) */
-static struct regulator_ops tps65910_ops_dcdc = {
+static const struct regulator_ops tps65910_ops_dcdc = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -770,7 +770,7 @@ static struct regulator_ops tps65910_ops_dcdc = {
.map_voltage= regulator_map_voltage_ascend,
};
-static struct regulator_ops tps65910_ops_vdd3 = {
+static const struct regulator_ops tps65910_ops_vdd3 = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -781,7 +781,7 @@ static struct regulator_ops tps65910_ops_vdd3 = {
.map_voltage= regulator_map_voltage_ascend,
};
-static struct regulator_ops tps65910_ops_vbb = {
+static const struct regulator_ops tps65910_ops_vbb = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -793,7 +793,7 @@ static struct regulator_ops tps65910_ops_vbb = {
.map_voltage= regulator_map_voltage_iterate,
};
-static struct regulator_ops tps65910_ops = {
+static const struct regulator_ops tps65910_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -805,7 +805,7 @@ static struct regulator_ops tps65910_ops = {
.map_voltage= regulator_map_voltage_ascend,
};
-static struct regulator_ops tps65911_ops = {
+static const struct regulator_ops tps65911_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
--
2.28.0
[PATCH 6/8] regulator: tps6586x: Constify static regulator_ops
The only usage of these are to assign their address to the ops field in
the regulator_desc struct, which is a const pointer. Make them const to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps6586x-regulator.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/tps6586x-regulator.c
b/drivers/regulator/tps6586x-regulator.c
index 09e994e1f9a9..18bf4b885b08 100644
--- a/drivers/regulator/tps6586x-regulator.c
+++ b/drivers/regulator/tps6586x-regulator.c
@@ -60,7 +60,7 @@ struct tps6586x_regulator {
int enable_reg[2];
};
-static struct regulator_ops tps6586x_rw_regulator_ops = {
+static const struct regulator_ops tps6586x_rw_regulator_ops = {
.list_voltage = regulator_list_voltage_table,
.map_voltage = regulator_map_voltage_ascend,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
@@ -71,7 +71,7 @@ static struct regulator_ops tps6586x_rw_regulator_ops = {
.disable = regulator_disable_regmap,
};
-static struct regulator_ops tps6586x_rw_linear_regulator_ops = {
+static const struct regulator_ops tps6586x_rw_linear_regulator_ops = {
.list_voltage = regulator_list_voltage_linear,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
@@ -81,7 +81,7 @@ static struct regulator_ops tps6586x_rw_linear_regulator_ops
= {
.disable = regulator_disable_regmap,
};
-static struct regulator_ops tps6586x_ro_regulator_ops = {
+static const struct regulator_ops tps6586x_ro_regulator_ops = {
.list_voltage = regulator_list_voltage_table,
.map_voltage = regulator_map_voltage_ascend,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
@@ -91,7 +91,7 @@ static struct regulator_ops tps6586x_ro_regulator_ops = {
.disable = regulator_disable_regmap,
};
-static struct regulator_ops tps6586x_sys_regulator_ops = {
+static const struct regulator_ops tps6586x_sys_regulator_ops = {
};
static const unsigned int tps6586x_ldo0_voltages[] = {
--
2.28.0
[PATCH 5/8] regulator: tps65090: constify static regulator_ops
The only usages of these are to assign their address to the ops field in
the regulator_desc struct, which is a const pointer. Make them const to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps65090-regulator.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index f0b660e9f15f..1d2e04f452d4 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -47,7 +47,7 @@ struct tps65090_regulator {
int overcurrent_wait;
};
-static struct regulator_ops tps65090_ext_control_ops = {
+static const struct regulator_ops tps65090_ext_control_ops = {
};
/**
@@ -167,19 +167,19 @@ static int tps65090_fet_enable(struct regulator_dev *rdev)
return ret;
}
-static struct regulator_ops tps65090_reg_control_ops = {
+static const struct regulator_ops tps65090_reg_control_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
};
-static struct regulator_ops tps65090_fet_control_ops = {
+static const struct regulator_ops tps65090_fet_control_ops = {
.enable = tps65090_fet_enable,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
};
-static struct regulator_ops tps65090_ldo_ops = {
+static const struct regulator_ops tps65090_ldo_ops = {
};
#define tps65090_REG_DESC(_id, _sname, _en_reg, _en_bits, _nvolt, _volt, _ops)
\
--
2.28.0
[PATCH 4/8] regulator: tps65086: Constify static regulator_ops
The only usage of reg_ops and switch_ops is to assign their addresses to
the ops field in the regulator_desc struct, which is a const pointer.
Make them const to allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps65086-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/tps65086-regulator.c
b/drivers/regulator/tps65086-regulator.c
index 23528475a962..070c956216b0 100644
--- a/drivers/regulator/tps65086-regulator.c
+++ b/drivers/regulator/tps65086-regulator.c
@@ -101,7 +101,7 @@ static const struct linear_range tps65086_ldoa23_ranges[] =
{
};
/* Operations permitted on regulators */
-static struct regulator_ops reg_ops = {
+static const struct regulator_ops reg_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -112,7 +112,7 @@ static struct regulator_ops reg_ops = {
};
/* Operations permitted on load switches */
-static struct regulator_ops switch_ops = {
+static const struct regulator_ops switch_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
--
2.28.0
[PATCH 2/8] regulator: tps6105x: Constify tps6105x_regulator_ops
The only usage of tps6105x_regulator_ops is to assign its address to the
ops field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps6105x-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps6105x-regulator.c
b/drivers/regulator/tps6105x-regulator.c
index f8939af0bd2c..a6469fe05635 100644
--- a/drivers/regulator/tps6105x-regulator.c
+++ b/drivers/regulator/tps6105x-regulator.c
@@ -26,7 +26,7 @@ static const unsigned int tps6105x_voltages[] = {
500, /* There is an additional 5V */
};
-static struct regulator_ops tps6105x_regulator_ops = {
+static const struct regulator_ops tps6105x_regulator_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
--
2.28.0
Re: [PATCH] fs: allow do_renameat2() over bind mounts of the same filesystem.
On Sat, Aug 29, 2020 at 11:23:34PM +0200, Florian Margaine wrote: > Al Viro writes: > > > On Fri, Aug 28, 2020 at 10:40:35PM +0200, Florian Margaine wrote: > >> There's currently this seemingly unnecessary limitation that rename() > >> cannot work over bind mounts of the same filesystem, > > > > ... is absolutely deliberate - that's how you set a boundary in the > > tree, preventing both links and renames across it. > > Sorry, I'm not not sure I understand what you're saying. Al's saying this is the way an administrator can intentionally prevent renames. > /* > * FICLONE/FICLONERANGE ioctls enforce that src and dest files are on > * the same mount. Practically, they only need to be on the same file > * system. > */ > if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb) > return -EXDEV; clone doesn't change the contents of a file, merely how they're laid out on storage. There's no particular reason for an administrator to prohibit clone across mount points.
[PATCH 0/8] regulator/tps*: Constify static regulator ops
Constify static instances of struct regulator_ops to allow the compiler to put them in read-only memory. Patches are independent. Compile-tested only. Rikard Falkeborn (8): regulator: tps51632: Constify tps51632_dcdc_ops regulator: tps6105x: Constify tps6105x_regulator_ops regulator: tps62360: Constify tps62360_dcdc_ops regulator: tps65086: Constify static regulator_ops regulator: tps65090: constify static regulator_ops regulator: tps6586x: Constify static regulator_ops regulator: tps65912: Constify static regulator_ops regulator: tps65910: Constify static regulator_ops drivers/regulator/tps51632-regulator.c | 2 +- drivers/regulator/tps6105x-regulator.c | 2 +- drivers/regulator/tps62360-regulator.c | 2 +- drivers/regulator/tps65086-regulator.c | 4 ++-- drivers/regulator/tps65090-regulator.c | 8 drivers/regulator/tps6586x-regulator.c | 8 drivers/regulator/tps65910-regulator.c | 10 +- drivers/regulator/tps65912-regulator.c | 4 ++-- 8 files changed, 20 insertions(+), 20 deletions(-) -- 2.28.0
[PATCH 7/8] regulator: tps65912: Constify static regulator_ops
The only usage of tps65912_ops_dcdc and tps65912_ops_ldo is to assign
their address to the ops field in the regulator_desc struct, which is a
const pointer. Make them const to allow the compiler to put them in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps65912-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/tps65912-regulator.c
b/drivers/regulator/tps65912-regulator.c
index 63d6bbd4969b..b52d4f2874b7 100644
--- a/drivers/regulator/tps65912-regulator.c
+++ b/drivers/regulator/tps65912-regulator.c
@@ -57,7 +57,7 @@ static const struct linear_range tps65912_ldo_ranges[] = {
};
/* Operations permitted on DCDCx */
-static struct regulator_ops tps65912_ops_dcdc = {
+static const struct regulator_ops tps65912_ops_dcdc = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -67,7 +67,7 @@ static struct regulator_ops tps65912_ops_dcdc = {
};
/* Operations permitted on LDOx */
-static struct regulator_ops tps65912_ops_ldo = {
+static const struct regulator_ops tps65912_ops_ldo = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
--
2.28.0
[PATCH 3/8] regulator: tps62360: Constify tps62360_dcdc_ops
The only usage of tps62360_dcdc_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps62360-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps62360-regulator.c
b/drivers/regulator/tps62360-regulator.c
index f6a6d36a6533..315cd5daf480 100644
--- a/drivers/regulator/tps62360-regulator.c
+++ b/drivers/regulator/tps62360-regulator.c
@@ -233,7 +233,7 @@ static unsigned int tps62360_get_mode(struct regulator_dev
*rdev)
REGULATOR_MODE_FAST : REGULATOR_MODE_NORMAL;
}
-static struct regulator_ops tps62360_dcdc_ops = {
+static const struct regulator_ops tps62360_dcdc_ops = {
.get_voltage_sel= tps62360_dcdc_get_voltage_sel,
.set_voltage_sel= tps62360_dcdc_set_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
--
2.28.0
[PATCH 1/8] regulator: tps51632: Constify tps51632_dcdc_ops
The only usage of tps51632_dcdc_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/regulator/tps51632-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps51632-regulator.c
b/drivers/regulator/tps51632-regulator.c
index c139890c1514..a15e415e61d5 100644
--- a/drivers/regulator/tps51632-regulator.c
+++ b/drivers/regulator/tps51632-regulator.c
@@ -108,7 +108,7 @@ static int tps51632_dcdc_set_ramp_delay(struct
regulator_dev *rdev,
return ret;
}
-static struct regulator_ops tps51632_dcdc_ops = {
+static const struct regulator_ops tps51632_dcdc_ops = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear,
--
2.28.0
Re: [PATCH v2 3/3] bio: convert get_user_pages_fast() --> pin_user_pages_fast()
On 8/29/20 8:02 AM, Christoph Hellwig wrote: - size = iov_iter_get_pages(iter, pages, LONG_MAX, nr_pages, ); + size = iov_iter_pin_user_pages(iter, pages, LONG_MAX, nr_pages, ); This is really a comment to the previous patch, but I only spotted it here: I think the right name is iov_iter_pin_pages, as bvec, kvec and pipe aren't usually user pages. Same as iov_iter_get_pages vs get_user_pages. Same for the _alloc variant. Yes, it is clearly misnamed now! Will fix. + * here on. It will run one unpin_user_page() against each page + * and will run one bio_put() against the BIO. Nit: the ant and the will still fit on the previous line. Sorry about that, *usually* my text editor does the Right Thing for those, I must have interfered with the natural flow of things. :) thanks, -- John Hubbard NVIDIA
Re: [PATCH v2 2/3] iov_iter: introduce iov_iter_pin_user_pages*() routines
On 8/29/20 7:58 AM, Christoph Hellwig wrote:
On Sat, Aug 29, 2020 at 01:08:52AM -0700, John Hubbard wrote:
...
@@ -1280,7 +1281,11 @@ static inline ssize_t __pipe_get_pages(struct iov_iter
*i,
maxsize = n;
n += *start;
while (n > 0) {
- get_page(*pages++ = pipe->bufs[iter_head & p_mask].page);
+ if (use_pup)
+ pin_user_page(*pages++ = pipe->bufs[iter_head &
p_mask].page);
+ else
+ get_page(*pages++ = pipe->bufs[iter_head &
p_mask].page);
Maybe this would become a little more readable with a local variable
and a little more verbosity:
struct page *page = pipe->bufs[iter_head & p_mask].page;
if (use_pup)
pin_user_page(page);
else
get_page(page);
*pages++ = page;
Yes, that is cleaner, I'll change to that, thanks.
thanks,
--
John Hubbard
NVIDIA
Re: [PATCH v2 1/3] mm/gup: introduce pin_user_page()
On 8/29/20 7:54 AM, Christoph Hellwig wrote: On Sat, Aug 29, 2020 at 01:08:51AM -0700, John Hubbard wrote: pin_user_page() is the FOLL_PIN equivalent of get_page(). This was always a missing piece of the pin/unpin API calls (early reviewers of pin_user_pages() asked about it, in fact), but until now, it just wasn't needed. Finally though, now that the Direct IO pieces in block/bio are about to be converted to use FOLL_PIN, it turns out that there are some cases in which get_page() and get_user_pages_fast() were both used. Converting those sites requires a drop-in replacement for get_page(), which this patch supplies. I find the name really confusing vs pin_user_pages*, as it suggests as single version of the same. It also seems partially wrong, at least in the direct I/O case as the only thing pinned here is the zero page. So maybe pin_kernel_page is a better name together with an explanation? Or just pin_page? Yes. Both its behavior and use are closer to get_page() than it is to get_user_pages(). So pin_page() is just right. thanks, -- John Hubbard NVIDIA
Re: [PATCH] sysfs: Add sysfs_emit to replace sprintf to PAGE_SIZE buffers.
> > Anyway, this will need updating, likely with better examples. > > diff --git a/Documentation/filesystems/sysfs.rst > b/Documentation/filesystems/sysfs.rst > index ab0f7795792b..13c7a86fa6c8 100644 > --- a/Documentation/filesystems/sysfs.rst > +++ b/Documentation/filesystems/sysfs.rst > @@ -242,12 +242,9 @@ Other notes: >is 4096. > > - show() methods should return the number of bytes printed into the > - buffer. This is the return value of scnprintf(). > + buffer. This is the return value of sysfs_emit(). > > -- show() must not use snprintf() when formatting the value to be > - returned to user space. If you can guarantee that an overflow > - will never happen you can use sprintf() otherwise you must use > - scnprintf(). > +- show() methods should only use sysfs_emit to format output. > I think it's good to reflect in docs that sysfs_emit_at/sysfs_emit_pos is only for "legacy" code and should not be used in new code (checkpatch.pl warning?) because of sysfs design principles. And something about newlines "General rule is to add newlines at the end of output." Thanks, Denis
ATTN: YOUR LATE RELATIVE!!!
- Good day, I do apologize if the content here under are contrary to your moral ETHICS,but please treat it with absolute secrecy and personal courtesy. I am writing following an opportunity in my office that will be of immense benefit to both of us. It's about my late client who had some huge fund deposited with a bank in Austria before he died in April 2014 (my late client) bears the same surname with you. Since his death I have received several letters from his Bank,requesting me to provide his next of kin or any of his relatives who can make claim before the end of the year or they will be left with no option than to confiscate everything. I have conducted my personal search to see if I can make contact with any of his relatives but without success, it is in the course of my effort that I have to contact you. I have closely checked and since you bear the same surname with my deceased client it will be better to present you as the next of kin and the right beneficiary of the fund in the account with the bank. I will provide you with all the necessary legal backup that is required until this money is paid out to you by the bank, and then we both shall share it base on our agreement. Do respond quick if you are interested or should you need further clarification because we have no much time left.Get back to me via: bar.kwamejoneschamb...@yahoo.com Thanks and God bless. Regards, Barrister Kwame Jones ---
Re: [PATCH] ia64: fix min_low_pfn/max_low_pfn build errors
On Fri, 28 Aug 2020, Randy Dunlap wrote: > Fix min_low_pfn/max_low_pfn build errors for arch/ia64/: (e.g.) > > ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! > ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! > ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! > ERROR: "max_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! > ERROR: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! > ERROR: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! > ERROR: "max_low_pfn" [drivers/md/dm-integrity.ko] undefined! > ERROR: "min_low_pfn" [drivers/md/dm-integrity.ko] undefined! > ERROR: "max_low_pfn" [crypto/tcrypt.ko] undefined! > ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined! > ERROR: "min_low_pfn" [security/keys/encrypted-keys/encrypted-keys.ko] > undefined! > ERROR: "max_low_pfn" [security/keys/encrypted-keys/encrypted-keys.ko] > undefined! > ERROR: "min_low_pfn" [arch/ia64/kernel/mca_recovery.ko] undefined! > ERROR: "max_low_pfn" [arch/ia64/kernel/mca_recovery.ko] undefined! > > David suggested just exporting min_low_pfn & max_low_pfn in > mm/memblock.c: > https://lore.kernel.org/lkml/alpine.deb.2.22.394.2006291911220.1118...@chino.kir.corp.google.com/ > > Reported-by: kernel test robot > Signed-off-by: Randy Dunlap > Cc: linux...@kvack.org > Cc: Andrew Morton > Cc: David Rientjes > Cc: Mike Rapoport > Cc: Tony Luck > Cc: Fenghua Yu > Cc: linux-i...@vger.kernel.org Acked-by: David Rientjes Thanks Randy!
Re: [PATCH] microblaze: fix min_low_pfn/max_low_pfn build errors
On Fri, 28 Aug 2020, Randy Dunlap wrote: > Fix min_low_pfn/max_low_pfn build errors for arch/microblaze/: (e.g.) > > ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! > ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu_sink.ko] > undefined! > ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! > ERROR: "min_low_pfn" [drivers/mmc/core/mmc_core.ko] undefined! > ERROR: "min_low_pfn" [drivers/md/dm-crypt.ko] undefined! > ERROR: "min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko] > undefined! > ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined! > ERROR: "min_low_pfn" [crypto/asymmetric_keys/asym_tpm.ko] undefined! > > Mike had/has an alternate patch for Microblaze: > https://lore.kernel.org/lkml/20200630111519.ga1951...@linux.ibm.com/ > > David suggested just exporting min_low_pfn & max_low_pfn in > mm/memblock.c: > https://lore.kernel.org/lkml/alpine.deb.2.22.394.2006291911220.1118...@chino.kir.corp.google.com/ > > Reported-by: kernel test robot > Signed-off-by: Randy Dunlap > Cc: linux...@kvack.org > Cc: Andrew Morton > Cc: David Rientjes > Cc: Mike Rapoport > Cc: Michal Simek > Cc: Michal Simek Acked-by: David Rientjes Thanks Randy!
Re: Kernel 5.9-rc Regression: Boot failure with nvme
On Sat, 29 Aug 2020, Christoph Hellwig wrote: > > Just adding Christoph to the participants list, since at a guess it's > > due to his changes whether they came from the nvme side or the dma > > side.. > > > > Christoph? > > This kinda looks like the sqsize regression we had in earlier 5.9-rc, > but that should have been fixed in -rc2 with > > 7442ddcedc344b6fa073692f165dffdd1889e780 > Author: John Garry > Date: Fri Aug 14 23:34:25 2020 +0800 > > nvme-pci: Use u32 for nvme_dev.q_depth and nvme_queue.q_depth > > Daniel, can you double check that you don't have that commit? > Looks like Daniel has confirmed that this indeed does fix his issue -- great! Christoph, re the plan to backport the atomic DMA pool support to 5.4 LTS for the purposes of fixing the AMD SEV allocation issues, I've composed the following list: e860c299ac0d dma-remap: separate DMA atomic pools from direct remap code c84dc6e68a1d dma-pool: add additional coherent pools to map to gfp mask 54adadf9b085 dma-pool: dynamically expanding atomic pools 76a19940bd62 dma-direct: atomic allocations must come from atomic coherent pools 2edc5bb3c5cc dma-pool: add pool sizes to debugfs 1d659236fb43 dma-pool: scale the default DMA coherent pool size with memory capacity 3ee06a6d532f dma-pool: fix too large DMA pools on medium memory size systems dbed452a078d dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL ** 633d5fce78a6 dma-direct: always align allocation size in dma_direct_alloc_pages() ** 96a539fa3bb7 dma-direct: re-encrypt memory if dma_direct_alloc_pages() fails ** 56fccf21d196 dma-direct: check return value when encrypting or decrypting memory ** 1a2b3357e860 dma-direct: add missing set_memory_decrypted() for coherent mapping d07ae4c48690 dma-mapping: DMA_COHERENT_POOL should select GENERIC_ALLOCATOR 71cdec4fab76 dma-mapping: warn when coherent pool is depleted 567f6a6eba0c dma-direct: provide function to check physical memory area validity 23e469be6239 dma-pool: get rid of dma_in_atomic_pool() 48b6703858dd dma-pool: introduce dma_guess_pool() 81e9d894e03f dma-pool: make sure atomic pool suits device d9765e41d8e9 dma-pool: do not allocate pool memory from CMA 9420139f516d dma-pool: fix coherent pool allocations for IOMMU mappings d7e673ec2c8e dma-pool: Only allocate from CMA when in same memory zone [ The commits prefixed with ** are not absolutely required for atomic DMA but rather fix other issues with SEV in the DMA layer that I found along the way. They are likely deserving of their own stable backports, but added them here because it's probably best to backport in order to minimize conflicts. We'll simply make a note of that in the cover letter for the stable backport series. ] Do you know of any others to add? NVMe specific fixes, perhaps John Garry's fix above, Intel IOMMU fixes maybe?
Re: [PATCH v2] usb: dwc3: Stop active transfers before halting the controller
Wesley Cheng wrote:
> In the DWC3 databook, for a device initiated disconnect or bus reset, the
> driver is required to send dependxfer commands for any pending transfers.
> In addition, before the controller can move to the halted state, the SW
> needs to acknowledge any pending events. If the controller is not halted
> properly, there is a chance the controller will continue accessing stale or
> freed TRBs and buffers.
>
> Signed-off-by: Wesley Cheng
>
> ---
> Changes in v2:
> - Moved cleanup code to the pullup() API to differentiate between device
>disconnect and hibernation.
> - Added cleanup code to the bus reset case as well.
> - Verified the move to pullup() did not reproduce the problen using the
>same test sequence.
>
> Verified fix by adding a check for ETIMEDOUT during the run stop call.
> Shell script writing to the configfs UDC file to trigger disconnect and
> connect. Batch script to have PC execute data transfers over adb (ie adb
> push) After a few iterations, we'd run into a scenario where the
> controller wasn't halted. With the following change, no failed halts after
> many iterations.
> ---
> drivers/usb/dwc3/ep0.c| 2 +-
> drivers/usb/dwc3/gadget.c | 52 ++-
> 2 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 59f2e8c31bd1..456aa87e8778 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -197,7 +197,7 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct
> usb_request *request,
> int ret;
>
> spin_lock_irqsave(>lock, flags);
> - if (!dep->endpoint.desc) {
> + if (!dep->endpoint.desc || !dwc->pullups_connected) {
> dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
> dep->name);
> ret = -ESHUTDOWN;
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 3ab6f118c508..df8d89d6bdc9 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1516,7 +1516,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
> struct dwc3_request *req)
> {
> struct dwc3 *dwc = dep->dwc;
>
> - if (!dep->endpoint.desc) {
> + if (!dep->endpoint.desc || !dwc->pullups_connected) {
> dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
> dep->name);
> return -ESHUTDOWN;
> @@ -1926,6 +1926,24 @@ static int dwc3_gadget_set_selfpowered(struct
> usb_gadget *g,
> return 0;
> }
>
> +static void dwc3_stop_active_transfers(struct dwc3 *dwc)
> +{
> + u32 epnum;
> +
> + for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
> + struct dwc3_ep *dep;
> +
> + dep = dwc->eps[epnum];
> + if (!dep)
> + continue;
> +
> + if (!(dep->flags & DWC3_EP_ENABLED))
> + continue;
Don't do the enabled check here. Let the dwc3_stop_active_transfer() do
that checking.
> +
> + dwc3_remove_requests(dwc, dep);
> + }
> +}
> +
> static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
> {
> u32 reg;
> @@ -1994,9 +2012,39 @@ static int dwc3_gadget_pullup(struct usb_gadget *g,
> int is_on)
> }
> }
>
> + /*
> + * Synchronize and disable any further event handling while controller
> + * is being enabled/disabled.
> + */
> + disable_irq(dwc->irq_gadget);
I think it's better to do dwc3_gadget_disable_irq(). This only stops
handling events. Although it's unlikely, the controller may still
generate events before it's halted.
> spin_lock_irqsave(>lock, flags);
> +
> + /* Controller is not halted until pending events are acknowledged */
> + if (!is_on) {
> + u32 reg;
> +
> + __dwc3_gadget_ep_disable(dwc->eps[0]);
> + __dwc3_gadget_ep_disable(dwc->eps[1]);
You can just do __dwc3_gadget_stop(), and do that after
dwc3_stop_active_transfers().
> +
> + /*
> + * The databook explicitly mentions for a device-initiated
> + * disconnect sequence, the SW needs to ensure that it ends any
> + * active transfers.
> + */
> + dwc3_stop_active_transfers(dwc);
> +
> + reg = dwc3_readl(dwc->regs, DWC3_GEVNTCOUNT(0));
> + reg &= DWC3_GEVNTCOUNT_MASK;
Can we use another variable "count" instead of reusing reg to make it a
little clearer?
> + if (reg > 0) {
> + dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), reg);
> + dwc->ev_buf->lpos = (dwc->ev_buf->lpos + reg) %
> + dwc->ev_buf->length;
> + }
> + }
> +
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
> spin_unlock_irqrestore(>lock,
Re: [PATCH v5 2/2] drm: panel: Add novatek nt36672a panel driver
Hi Sumit. On Wed, Aug 26, 2020 at 09:33:08PM +0530, Sumit Semwal wrote: > Novatek NT36672a is a generic DSI IC that drives command and video mode > panels. Add the driver for it. > > Right now adding support for some Poco F1 phones that have an LCD panel > from Tianma connected with this IC, with a resolution of 1080x2246 that > operates in DSI video mode. > > During testing, Benni Steini helped us fix > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > to work on Android. > > With current AOSP, we need to increase it to 200ms - this seems to be a > safe high value to avoid a white screen occasionally. > > Signed-off-by: Sumit Semwal > Cc: Benni Steini > > --- > v2: increase reset sequence timing to a safe 200ms > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > vrefresh on demand. Update for it. > v5: Fixed review comments from Sam: > - rebased on top of drm-misc-next >remove return of drm_panel_add() >remove drm_panel_detach() > - renamed the panel driver file to reflect that this is a novatek >nt36672a display driver and not only for tianma panels. >Adjusted some internal names also to reflect the same. > - corrected changelog to add info about the generic Novatek DSI IC > - corrected compatible string accordingly > - removed pinctrl > - used drm_panel* API for prepare/unprepare/disable/remove Thanks for the detailed follow-up - very nice. A few things slipped thought last review and we have gained support for dv_err_probe() now. Also dev_err() and friends are now the right choice for panel drivers. Sam > --- > MAINTAINERS | 7 + > drivers/gpu/drm/panel/Kconfig | 10 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++ > 4 files changed, 785 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01fb9ee6b951..aeecade2d65f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: Documentation/devicetree/bindings/display/ste,mcde.txt > F: drivers/gpu/drm/mcde/ > > +DRM DRIVER FOR TIANMA NT36672A PANELS > +M: Sumit Semwal > +S: Maintained > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: > Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml > +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c > + > DRM DRIVER FOR TDFX VIDEO CARDS > S: Orphan / Obsolete > F: drivers/gpu/drm/tdfx/ > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 8d97d07c5871..02600f12a063 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 > around the Novatek NT35510 display controller, such as some > Hydis panels. > > +config DRM_PANEL_NOVATEK_NT36672A > + tristate "Novatek NT36672A DSI panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y here if you want to enable support for the panels built > + around the Novatek NT36672A display controller, such as some > + Tianma panels used in a few Xiaomi Poco F1 mobile phone. > + > config DRM_PANEL_NOVATEK_NT39016 > tristate "Novatek NT39016 RGB/SPI panel" > depends on OF && SPI > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 15a4e7752951..4a36eb45f670 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o > +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o > obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > new file mode 100644 > index ..3f0c18e46818 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > @@ -0,0 +1,767 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2020 Linaro Ltd > + * Author: Sumit Semwal > + * > + * This driver is for the DSI interface to panels using the NT36672A display > driver IC > + * from Novatek. > + * Currently supported are the Tianma FHD+ panels found in some Xiaomi > phones, including > + * some variants of the Poco F1 phone. > + *
Re: [PATCH v3 18/18] iio: multiplexer: iio-mux: Simplify with dev_err_probe()
On 2020-08-29 08:47, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Andy Shevchenko Acked-by: Peter Rosin Cheers, Peter
Re: [PATCH v3 12/18] iio: dac: dpot-dac: Simplify with dev_err_probe()
On 2020-08-29 08:47, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Andy Shevchenko Acked-by: Peter Rosin Cheers, Peter
Re: [PATCH v3 09/18] iio: afe: iio-rescale: Simplify with dev_err_probe()
On 2020-08-29 08:47, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Andy Shevchenko Acked-by: Peter Rosin Cheers, Peter
Re: [PATCH v3 03/18] iio: adc: envelope-detector: Simplify with dev_err_probe()
On 2020-08-29 08:47, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Andy Shevchenko Thanks for the re-spin. Acked-by: Peter Rosin Cheers, Peter
Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()
On Sat, Aug 29, 2020 at 08:16:00PM +0300, Laurent Pinchart wrote:
> On Sat, Aug 29, 2020 at 02:10:20PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > The value av7110->debi_virt is stored in DMA memory, and it is assigned
> > > to data, and thus data[0] can be modified at any time by malicious
> > > hardware. In this case, "if (data[0] < 2)" can be passed, but then
> > > data[0] can be changed into a large number, which may cause buffer
> > > overflow when the code "av7110->ci_slot[data[0]]" is used.
> > >
> > > To fix this possible bug, data[0] is assigned to a local variable, which
> > > replaces the use of data[0].
> >
> > I'm pretty sure hardware capable of manipulating memory can work
> > around any such checks, but...
> >
> > > +++ b/drivers/media/pci/ttpci/av7110.c
> > > @@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
> > > case DATA_CI_GET:
> > > {
> > > u8 *data = av7110->debi_virt;
> > > + u8 data_0 = data[0];
> > >
> > > - if ((data[0] < 2) && data[2] == 0xff) {
> > > + if (data_0 < 2 && data[2] == 0xff) {
> > > int flags = 0;
> > > if (data[5] > 0)
> > > flags |= CA_CI_MODULE_PRESENT;
> > > if (data[5] > 5)
> > > flags |= CA_CI_MODULE_READY;
> > > - av7110->ci_slot[data[0]].flags = flags;
> > > + av7110->ci_slot[data_0].flags = flags;
> >
> > This does not even do what it says. Compiler is still free to access
> > data[0] multiple times. It needs READ_ONCE() to be effective.
>
> Yes, it seems quite dubious to me. If we *really* want to guard against
> rogue hardware here, the whole DMA buffer should be copied. I don't
> think it's worth it, a rogue PCI device can do much more harm.
That is a good point. I'm not sure what the kernel could do to protect
against a malicious PCI device (that can do dma) so this patch is totally
pointless.
Thanks
Sean
Re: [PATCH] fs: allow do_renameat2() over bind mounts of the same filesystem.
Al Viro writes: > On Fri, Aug 28, 2020 at 10:40:35PM +0200, Florian Margaine wrote: >> There's currently this seemingly unnecessary limitation that rename() >> cannot work over bind mounts of the same filesystem, > > ... is absolutely deliberate - that's how you set a boundary in the > tree, preventing both links and renames across it. Sorry, I'm not not sure I understand what you're saying. As I understand it, the tree is the superblock there, not the mount. As in, the dentries are relative to the superblock, and the mountpoint is no more than a pointer to a superblock's dentry. In addition, I noticed this snippet in fs/read_write.c: /* * FICLONE/FICLONERANGE ioctls enforce that src and dest files are on * the same mount. Practically, they only need to be on the same file * system. */ if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb) return -EXDEV; Which seems to confirm my understanding. What am I getting wrong there? > > Incidentally, doing that would have fun effects for anyone with current > directory inside the subtree you'd moved - try and see. signature.asc Description: PGP signature
Re: [GIT PULL] fallthrough fixes for 5.9-rc3
The pull request you sent on Sat, 29 Aug 2020 12:37:02 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git > tags/fallthrough-fixes-5.9-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1127b219ce9481c84edad9711626d856127d5e51 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] fsldma: fsl_ioread64*() do not need lower_32_bits()
On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck wrote:
>
> Except for
>
> CHECK: spaces preferred around that '+' (ctx:VxV)
> #29: FILE: drivers/dma/fsldma.h:223:
> + u32 val_lo = in_be32((u32 __iomem *)addr+1);
Added spaces.
> I don't see anything wrong with it either, so
>
> Reviewed-by: Guenter Roeck
>
> Since I didn't see the real problem with the original code,
> I'd take that with a grain of salt, though.
Well, honestly, the old code was so confused that just making it build
is clearly already an improvement even if everything else were to be
wrong.
So I committed my "fix". If it turns out there's more wrong in there
and somebody tests it, we can fix it again. But now it hopefully
compiles, at least.
My bet is that if that driver ever worked on ppc32, it will continue
to work whatever we do to that function.
I _think_ the old code happened to - completely by mistake - get the
value right for the case of "little endian access, with dma_addr_t
being 32-bit". Because then it would still read the upper bits wrong,
but the cast to dma_addr_t would then throw those bits away. And the
lower bits would be right.
But for big-endian accesses or for ARCH_DMA_ADDR_T_64BIT it really
looks like it always returned a completely incorrect value.
And again - the driver may have worked even with that completely
incorrect value, since the use of it seems to be very incidental.
In either case ("it didn't work before" or "it worked because the
value doesn't really matter"), I don't think I could possibly have
made things worse.
Famous last words.
Linus
Re: [PATCH v5 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Hi Sumit.
On Wed, Aug 26, 2020 at 09:33:07PM +0530, Sumit Semwal wrote:
> Novatek nt36672a is a display driver IC that can drive DSI panel. It
> is also present in the Tianma video mode panel, which is a FHD+ panel
> with a resolution of 1080x2246 and 6.18 inches size. It is found in
> some of the Poco F1 phones.
>
> This patch adds the display driver for the IC, with support added for
> this tianma fhd video mode panel.
>
> Signed-off-by: Sumit Semwal
> Reviewed-by: Rob Herring
Looks fine, just a few comments in the following.
Should be easy to fix.
Sam
>
> ---
> v2: remove ports node, making port@0 directly under panel@0 node.
> v3: updated to replace port@0 to just 'port'.
> v5: renamed to novatek,nt36672a, since the binding is for the IC and not
> the panel.
> ---
> .../display/panel/novatek,nt36672a.yaml | 81 +++
> 1 file changed, 81 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> new file mode 100644
> index ..7f8d1097bee0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Novatek NT36672A based DSI display Panels
> +
> +maintainers:
> + - Sumit Semwal
> +
> +description: |
> + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
> + panels.
> + Right now, support is added only for a Tianma FHD+ LCD display panel with a
> + resolution of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - const: tianma,fhd-video
> + - const: novatek,nt36672a
Similar bindings uses following pattaern:
properties:
compatible:
items:
- enum:
- dlink,dir-685-panel
- const: ilitek,ili9322
See ow an "- enum" is used for the part where we expect to add more
compatible in the future. And const for the fixed part.
Notice the indent - this is right.
> +description: This indicates the panel manufacturer of the panel that is
> + in turn using the NT36672A panel driver. This compatible string
> + determines how the NT36672A panel driver is configured for the
> indicated
> + panel. The novatek,nt36672a compatible shall always be provided as a
> fallback.
> +
> + reg: true
> + reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> + can be configured using mux, pinctrl, pinctrl-names (active high)
add empty line, or rely on the generic description in panel-common.
> + vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> + Power IC supply
add empty line
> + vddpos-supply:
> +description: phandle of the positive boost supply regulator
add empty line
> + vddneg-supply:
> +description: phandle of the negative boost supply regulator
add empty line
> + port: true
Maybe group all the ": true" properties.
> +
> +required:
> + - compatible
> + - reg
> + - vddi0-supply
> + - vddpos-supply
> + - vddneg-supply
> + - reset-gpios
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |+
> +#include
empty line
> +dsi0 {
My personal preference is indent examples with 4 spaces - it increased
readability.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel@0 {
> +compatible = "tianma,fhd-video", "novatek,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port {
> + tianma_nt36672a_in_0: endpoint {
> +remote-endpoint = <_out>;
> + };
> +};
> + };
> +};
> +
> +...
> --
> 2.28.0
Re: [PATCH v3 4/5] fpga manager: xilinx-spi: add error checking after gpiod_get_value()
Hi,
On 29/08/20 05:30, kernel test robot wrote:
> Hi Luca,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on v5.9-rc2]
> [also build test WARNING on next-20200828]
> [cannot apply to xlnx/master]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Luca-Ceresoli/fpga-manager-xilinx-spi-remove-stray-comment/20200829-040041
> base:d012a7190fc1fd72ed48911e77ca97ba4521bccd
> compiler: nds32le-linux-gcc (GCC) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> cppcheck warnings: (new ones prefixed by >>)
>
>>> drivers/fpga/xilinx-spi.c:183:10: warning: Uninitialized variable: expired
>>> [uninitvar]
> while (!expired) {
> ^
Oh dear, Please ignore this patch, v4 will be coming with this fixed.
--
Luca
Re: [PATCH v2 2/2] drm/ingenic: Fix driver not probing when IPU port is missing
On Thu, Aug 27, 2020 at 01:44:04PM +0200, Paul Cercueil wrote:
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
>
> Fix the driver so that it will probe even if the IPU node is not present
> in devicetree (but then IPU support is disabled of course).
>
> v2: Take a different approach
>
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index c1bcb93aed2d..b7074161ccf0 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -673,7 +673,7 @@ static void ingenic_drm_unbind_all(void *d)
> component_unbind_all(priv->dev, >drm);
> }
>
> -static int ingenic_drm_bind(struct device *dev)
> +static int ingenic_drm_bind(struct device *dev, bool has_components)
> {
> struct platform_device *pdev = to_platform_device(dev);
> const struct jz_soc_info *soc_info;
> @@ -808,7 +808,7 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> - if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
> + if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && has_components) {
> ret = component_bind_all(dev, drm);
> if (ret) {
> if (ret != -EPROBE_DEFER)
> @@ -939,6 +939,11 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> +static int ingenic_drm_bind_with_components(struct device *dev)
> +{
> + return ingenic_drm_bind(dev, true);
> +}
> +
> static int compare_of(struct device *dev, void *data)
> {
> return dev->of_node == data;
> @@ -957,7 +962,7 @@ static void ingenic_drm_unbind(struct device *dev)
> }
>
> static const struct component_master_ops ingenic_master_ops = {
> - .bind = ingenic_drm_bind,
> + .bind = ingenic_drm_bind_with_components,
> .unbind = ingenic_drm_unbind,
> };
>
> @@ -968,14 +973,12 @@ static int ingenic_drm_probe(struct platform_device
> *pdev)
> struct device_node *np;
>
> if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
> - return ingenic_drm_bind(dev);
> + return ingenic_drm_bind(dev, false);
>
> /* IPU is at port address 8 */
> np = of_graph_get_remote_node(dev->of_node, 8, 0);
> - if (!np) {
> - dev_err(dev, "Unable to get IPU node\n");
> - return -EINVAL;
> - }
> + if (!np)
> + return ingenic_drm_bind(dev, false);
>
> drm_of_component_match_add(dev, , compare_of, np);
> of_node_put(np);
> --
> 2.28.0
Re: [PATCH v2 1/2] drm/ingenic: Fix leak of device_node pointer
On Thu, Aug 27, 2020 at 01:44:03PM +0200, Paul Cercueil wrote:
> of_graph_get_remote_node() requires of_node_put() to be called on the
> device_node pointer when it's no more in use.
>
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index ada990a7f911..c1bcb93aed2d 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -978,6 +978,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
> }
>
> drm_of_component_match_add(dev, , compare_of, np);
> + of_node_put(np);
>
> return component_master_add_with_match(dev, _master_ops, match);
> }
> --
> 2.28.0
Re: [PATCH 1/4] dt-bindings: display: samsung,amoled-mipi-dsi: Do not require enable-gpios on samsung,s6e63j0x03
On Sat, Aug 29, 2020 at 07:25:29PM +0200, Krzysztof Kozlowski wrote: > The samsung,s6e63j0x03 does not have enable GPIO, so do not require it. > This fixes dtbs_check warning: > > arch/arm/boot/dts/exynos3250-rinato.dt.yaml: panel@0: 'enable-gpios' is a > required property > > Signed-off-by: Krzysztof Kozlowski Acked-by: Sam Ravnborg I expect this patch is picked up with the dts fixes. Sam > --- > .../display/panel/samsung,amoled-mipi-dsi.yaml | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > > b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > index 96bdde9298e0..ccc482570d6a 100644 > --- > a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > @@ -12,6 +12,17 @@ maintainers: > allOf: >- $ref: panel-common.yaml# > > + - if: > + properties: > +compatible: > + contains: > +enum: > + - samsung,s6e3ha2 > + - samsung,s6e3hf2 > +then: > + required: > +- enable-gpios > + > properties: >compatible: > enum: > @@ -39,7 +50,6 @@ required: >- vdd3-supply >- vci-supply >- reset-gpios > - - enable-gpios > > additionalProperties: false > > -- > 2.17.1
Re: [PATCH v2 1/2] dt-bindings: display: simple: Add AM-1280800N3TZQW-T00H
Hi Jagan. On Sat, Aug 29, 2020 at 10:03:27PM +0530, Jagan Teki wrote: > Add dt-bindings for 10.1" TFT LCD module from Ampire Co. Ltd. > as part of panel-simple. > > Signed-off-by: Jagan Teki Thanks for the quick update. Applied both patches to drm-misc-next. Sam > --- > Changes for v2: > - none > > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index d6cca1479633..f629d04f7737 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -29,6 +29,8 @@ properties: > # compatible must be listed in alphabetical order, ordered by compatible. > # The description in the comment is mandatory for each compatible. > > +# Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel > + - ampire,am-1280800n3tzqw-t00h > # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel >- ampire,am-480272h3tmqw-t01h > # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel > -- > 2.25.1
Re: [PATCH] drm/panel: rm67191: Remove CLOCK_NON_CONTINUOUS flag
On Fri, Aug 28, 2020 at 05:58:33PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras
>
> The flag MIPI_DSI_CLOCK_NON_CONTINUOUS was wrong used in the DSI driver,
> so it was added to this panel, but not necessary.
> So, remove this flag since it is not needed.
>
> Signed-off-by: Robert Chiras
Thanks, applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> index 23b6208..572547d 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -552,8 +552,7 @@ static int rad_panel_probe(struct mipi_dsi_device *dsi)
> panel->dsi = dsi;
>
> dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO |
> -MIPI_DSI_CLOCK_NON_CONTINUOUS;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO;
>
> ret = of_property_read_u32(np, "video-mode", _mode);
> if (!ret) {
> --
> 2.7.4
Re: [PATCH] drm/bridge: Fix the dsi remote end-points
On Fri, Aug 28, 2020 at 01:12:50PM +0530, Vinod Koul wrote:
> DSI end-points are supposed to be at node 0 and node 1 as per binding.
> So fix this and use node 0 and node 1 for dsi.
>
> Reported-by: Dmitry Baryshkov
> Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
> Signed-off-by: Vinod Koul
Thanks, applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index 1009fc4ed4ed..d734d9402c35 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -960,13 +960,13 @@ static const struct drm_bridge_funcs
> lt9611_bridge_funcs = {
> static int lt9611_parse_dt(struct device *dev,
> struct lt9611 *lt9611)
> {
> - lt9611->dsi0_node = of_graph_get_remote_node(dev->of_node, 1, -1);
> + lt9611->dsi0_node = of_graph_get_remote_node(dev->of_node, 0, -1);
> if (!lt9611->dsi0_node) {
> dev_err(lt9611->dev, "failed to get remote node for primary
> dsi\n");
> return -ENODEV;
> }
>
> - lt9611->dsi1_node = of_graph_get_remote_node(dev->of_node, 2, -1);
> + lt9611->dsi1_node = of_graph_get_remote_node(dev->of_node, 1, -1);
>
> lt9611->ac_mode = of_property_read_bool(dev->of_node, "lt,ac-mode");
>
> --
> 2.26.2
Boot failure on gru-scarlet-inx with 5.9-rc2
Hi, The patch "of: address: Work around missing device_type property in pcie nodes" by Marc Zyngier, d1ac0002dd297069bb8448c2764c9c31c4668441, causes the "DUMO" variant of the gru-scarlet-inx, at the very least, to not boot. A gru-kevin reportedly had no issues booting (further), though it most likely had a different kernel configuration. Using a SuzyQ cable, there is absolutely no serial output at boot, while reverting the commit (and this commit alone) on top of v5.9-rc2 works just as it did with v5.9-rc1. From this point on, I don't know what's the usual process, so bear with me if I forgot to provide relevant information, or made a faux-pas by CC-ing too many people or not enough. Thanks.
Re: [PATCH] fsldma: fsl_ioread64*() do not need lower_32_bits()
On 8/29/20 10:29 AM, Linus Torvalds wrote:
> On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
> wrote:
>>
>> But the pointer is already 32-bit, so simply cast the pointer to u32.
>
> Yeah, that code was completely pointless. If the pointer had actually
> been 64-bit, the old code would have warned too.
>
> The odd thing is that the fsl_iowrite64() functions make sense. It's
> only the fsl_ioread64() functions that seem to be written by somebody
> who is really confused.
>
> That said, this patch only humors the confusion. The cast to 'u32' is
> completely pointless. In fact, it seems to be actively wrong, because
> it means that the later "fsl_addr + 1" is done entirely incorrectly -
> it now literally adds "1" to an integer value, while the iowrite()
> functions will add one to a "u32 __iomem *" pointer (so will do
> pointer arithmetic, and add 4).
>
Outch.
> So this code has never ever worked correctly to begin with, but the
> patches to fix the warning miss the point. The problem isn't the
> warning, the problem is that the code is broken and completely wrong
> to begin with.
>
> And the "lower_32_bits()" thing has always been pure and utter
> confusion and complete garbage.
>
> I *think* the right patch is the one attached, but since this code is
> clearly utterly broken, I'd want somebody to test it.
>
> It has probably never ever worked on 32-bit powerpc, or did so purely
> by mistake (perhaps because nobody really cares - the only 64-bit use
> is this:
>
> static dma_addr_t get_cdar(struct fsldma_chan *chan)
> {
> return FSL_DMA_IN(chan, >regs->cdar, 64) & ~FSL_DMA_SNEN;
> }
>
> and there are two users of that: one which ignores the return value,
> and one that looks like it might end up half-way working even if the
> value read was garbage (it's used only to compare against a "current
> descriptor" value).
>
> Anyway, the fix is definitely not to just shut up the warning. The
> warning is only a sign of utter confusion in that driver.
>
> Can somebody with the hardware test this on 32-bit ppc?
>
> And if not (judging by just how broken those functions are, maybe it
> never did work), can somebody with a ppc32 setup at least compile-test
> this patch and look at whether it makes sense, in ways the old code
> did not.
>
A bit more careful this time. For the attached patch:
Compile-tested-by: Guenter Roeck
Except for
CHECK: spaces preferred around that '+' (ctx:VxV)
#29: FILE: drivers/dma/fsldma.h:223:
+ u32 val_lo = in_be32((u32 __iomem *)addr+1);
I don't see anything wrong with it either, so
Reviewed-by: Guenter Roeck
Since I didn't see the real problem with the original code,
I'd take that with a grain of salt, though.
Guenter
Re: sysfs output without newlines
On Sat, 2020-08-29 at 23:23 +0300, Denis Efremov wrote: > Hi, > > On 8/29/20 9:23 PM, Joe Perches wrote: > > While doing an investigation for a possible treewide conversion of > > sysfs output using sprintf/snprintf/scnprintf, I discovered > > several instances of sysfs output without terminating newlines. > > > > It seems likely all of these should have newline terminations > > or have the \n\r termination changed to a single newline. > > I think that it could break badly written scripts in rare cases. Maybe. Is sysfs output a nominally unchangeable api like seq_? Dunno. seq_ output is extended all the time. I think whitespace isn't generally considered part of sscanf type input content awareness. > > Anyone have any objection to patches adding newlines to these > > in their original forms using sprintf/snprintf/scnprintf? > > I'm not sure about existing cases, but I think it's a good > checkpatch.pl warning for new patches. It should be > possible to check sysfs_emit() calls. Eventually, yes. cheers, Joe
Re: [PATCH v2 2/7] arm64: dts: rockchip: px30: Add Engicam EDIMM2.2 Starter Kit
Hi Jagan,
On 8/29/20 5:58 PM, Jagan Teki wrote:
> Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
> Evaluation Board.
>
> Genaral features:
> - LCD 7" C.Touch
> - microSD slot
> - Ethernet 1Gb
> - Wifi/BT
> - 2x LVDS Full HD interfaces
> - 3x USB 2.0
> - 1x USB 3.0
> - HDMI Out
> - Mini PCIe
> - MIPI CSI
> - 2x CAN
> - Audio Out
>
> SOM's like PX30.Core needs to mount on top of this Evaluation board
> for creating complete PX30.Core EDIMM2.2 Starter Kit.
>
> Add support for it.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - move carrier enablement nodes in carrier dtsi
>
> .../dts/rockchip/px30-engicam-common.dtsi | 39 +++
> .../dts/rockchip/px30-engicam-edimm2.2.dtsi | 7
> 2 files changed, 46 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
> create mode 100644 arch/arm64/boot/dts/rockchip/px30-engicam-edimm2.2.dtsi
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
> b/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
> new file mode 100644
> index ..4e85c1a690e5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutions(India)
> + */
> +
> +/ {
> + vcc5v0_sys: vcc5v0-sys {
> + compatible = "regulator-fixed";
Just one of the exceptions to the sort rule...
regulator-name = "vcc5v0_sys"; /* +5V */
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-name = "vcc5v0_sys"; /* +5V */
Move on top of the other regulator properties.
Same goes for the regulators in px30-px30-core.dtsi.
> + };
> +};
> +
> + {
> + clock_in_out = "output";
> + phy-supply = <_3v3>;/* +3V3_SOM */
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 5 5>;
> + snps,reset-gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> + {
> + cap-mmc-highspeed;
Remove.
Board only has a micro-SD card.
> + cap-sd-highspeed;
> + card-detect-delay = <800>;
> + vqmmc-supply = <_3v3>;
> + vmmc-supply = <_3v3>; /* +3V3_SOM */
sort
> + status = "okay";
> +};
> +
> + {
> + pinctrl-0 = <_xfer>;
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/px30-engicam-edimm2.2.dtsi
> b/arch/arm64/boot/dts/rockchip/px30-engicam-edimm2.2.dtsi
> new file mode 100644
> index ..cb00988953e9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/px30-engicam-edimm2.2.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutions(India)
> + */
> +
> +#include "px30-engicam-common.dtsi"
>
Re: [RFC PATCH] coccinelle: misc: add uninitialized_var.cocci script
On Sat, 29 Aug 2020, Denis Efremov wrote:
>
>
> On 8/29/20 10:48 PM, Julia Lawall wrote:
> >
> >
> > On Sat, 29 Aug 2020, Joe Perches wrote:
> >
> >> On Sat, 2020-08-29 at 21:36 +0200, Julia Lawall wrote:
> >>>
> >>> On Wed, 12 Aug 2020, Denis Efremov wrote:
> >>>
> Commit 63a0895d960a ("compiler: Remove uninitialized_var() macro") and
> commit 4b19bec97c88 ("docs: deprecated.rst: Add uninitialized_var()")
> removed uninitialized_var() and deprecated it.
>
> The purpose of this script is to prevent new occurrences of open-coded
> variants of uninitialized_var().
> >>
> Cc: Kees Cook
> Cc: Gustavo A. R. Silva
> Signed-off-by: Denis Efremov
> >>>
> >>> Applied, without the commented out part.
> >>>
> >>> I only got three warnings, though. Perhaps the others have been fixed?
> >>
> >> uninitialized_var does not exist in -next
>
> Yes, and this rule checks for not introducing these initializations once
> again.
>
> i.e, checks for:
>
> int a = a;
>
> int a = *();
>
> >
> > OK, if it seems better, I can remove it. Out of the threee reported, one
> > was a completely unnecessary initialization.
> >
>
> I would like send v2 with better description and link to the documentation
> because it's
> now available online:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#uninitialized-var
OK, thanks.
julia
Re: sysfs output without newlines
Hi, On 8/29/20 9:23 PM, Joe Perches wrote: > While doing an investigation for a possible treewide conversion of > sysfs output using sprintf/snprintf/scnprintf, I discovered > several instances of sysfs output without terminating newlines. > > It seems likely all of these should have newline terminations > or have the \n\r termination changed to a single newline. I think that it could break badly written scripts in rare cases. > > Anyone have any objection to patches adding newlines to these > in their original forms using sprintf/snprintf/scnprintf? I'm not sure about existing cases, but I think it's a good checkpatch.pl warning for new patches. It should be possible to check sysfs_emit() calls. Thanks, Denis
Re: [PULL REQUEST] i2c for v5.9
The pull request you sent on Sat, 29 Aug 2020 17:53:07 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e77aee1326f7691763aa968eee2f57db37840b9d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] hwmon fixes for v5.9-rc3
The pull request you sent on Sat, 29 Aug 2020 03:13:29 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > hwmon-for-v5.9-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e4cad138aa4f73cd88c624a88cfd63ddcdd1c098 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] s390 updates for 5.9-rc3
The pull request you sent on Sat, 29 Aug 2020 12:51:15 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.9-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1b46b921b0b92bfc507d29a39f1b265c48ed45be Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] xen: branch for v5.9-rc3
The pull request you sent on Sat, 29 Aug 2020 12:04:05 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.9-rc3-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c8b5563abe02c5e9abdd6a74043c651a9ec31e9e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [RFC PATCH] coccinelle: misc: add uninitialized_var.cocci script
On 8/29/20 10:48 PM, Julia Lawall wrote:
>
>
> On Sat, 29 Aug 2020, Joe Perches wrote:
>
>> On Sat, 2020-08-29 at 21:36 +0200, Julia Lawall wrote:
>>>
>>> On Wed, 12 Aug 2020, Denis Efremov wrote:
>>>
Commit 63a0895d960a ("compiler: Remove uninitialized_var() macro") and
commit 4b19bec97c88 ("docs: deprecated.rst: Add uninitialized_var()")
removed uninitialized_var() and deprecated it.
The purpose of this script is to prevent new occurrences of open-coded
variants of uninitialized_var().
>>
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
>>>
>>> Applied, without the commented out part.
>>>
>>> I only got three warnings, though. Perhaps the others have been fixed?
>>
>> uninitialized_var does not exist in -next
Yes, and this rule checks for not introducing these initializations once again.
i.e, checks for:
int a = a;
int a = *();
>
> OK, if it seems better, I can remove it. Out of the threee reported, one
> was a completely unnecessary initialization.
>
I would like send v2 with better description and link to the documentation
because it's
now available online:
https://www.kernel.org/doc/html/latest/process/deprecated.html#uninitialized-var
Thanks,
Denis
Re: [RFC PATCH] coccinelle: misc: add uninitialized_var.cocci script
On Sat, 29 Aug 2020, Joe Perches wrote:
> On Sat, 2020-08-29 at 21:36 +0200, Julia Lawall wrote:
> >
> > On Wed, 12 Aug 2020, Denis Efremov wrote:
> >
> > > Commit 63a0895d960a ("compiler: Remove uninitialized_var() macro") and
> > > commit 4b19bec97c88 ("docs: deprecated.rst: Add uninitialized_var()")
> > > removed uninitialized_var() and deprecated it.
> > >
> > > The purpose of this script is to prevent new occurrences of open-coded
> > > variants of uninitialized_var().
>
> > > Cc: Kees Cook
> > > Cc: Gustavo A. R. Silva
> > > Signed-off-by: Denis Efremov
> >
> > Applied, without the commented out part.
> >
> > I only got three warnings, though. Perhaps the others have been fixed?
>
> uninitialized_var does not exist in -next
OK, if it seems better, I can remove it. Out of the threee reported, one
was a completely unnecessary initialization.
julia
drivers/android/binder.c:3779: Error: unrecognized keyword/register name `l.addi
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4d41ead6ead97c3730bbd186a601a64828668f01
commit: 4b836a1426cb0f1ef2a6e211d7e553221594f8fc binder: Prevent context
manager from incrementing ref 0
date: 4 weeks ago
config: openrisc-randconfig-r016-20200830 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4b836a1426cb0f1ef2a6e211d7e553221594f8fc
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=openrisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/android/binder.c: Assembler messages:
drivers/android/binder.c:3774: Error: unrecognized keyword/register name
`l.lwz ?ap,4(r25)'
>> drivers/android/binder.c:3779: Error: unrecognized keyword/register name
>> `l.addi ?ap,r0,0'
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b836a1426cb0f1ef2a6e211d7e553221594f8fc
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4b836a1426cb0f1ef2a6e211d7e553221594f8fc
vim +3779 drivers/android/binder.c
44d8047f1d87ad drivers/android/binder.c Todd Kjos
2018-08-28 3600
fb07ebc3e82a98 drivers/staging/android/binder.c Bojan Prtvar
2013-09-02 3601 static int binder_thread_write(struct binder_proc *proc,
fb07ebc3e82a98 drivers/staging/android/binder.c Bojan Prtvar
2013-09-02 3602 struct binder_thread *thread,
da49889deb34d3 drivers/staging/android/binder.c Arve Hjønnevåg
2014-02-21 3603 binder_uintptr_t binder_buffer, size_t
size,
da49889deb34d3 drivers/staging/android/binder.c Arve Hjønnevåg
2014-02-21 3604 binder_size_t *consumed)
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3605 {
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3606 uint32_t cmd;
342e5c90b60134 drivers/android/binder.c Martijn Coenen
2017-02-03 3607 struct binder_context *context = proc->context;
da49889deb34d3 drivers/staging/android/binder.c Arve Hjønnevåg
2014-02-21 3608 void __user *buffer = (void __user
*)(uintptr_t)binder_buffer;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3609 void __user *ptr = buffer + *consumed;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3610 void __user *end = buffer + size;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3611
26549d17741035 drivers/android/binder.c Todd Kjos
2017-06-29 3612 while (ptr < end && thread->return_error.cmd == BR_OK)
{
372e3147df7016 drivers/android/binder.c Todd Kjos
2017-06-29 3613 int ret;
372e3147df7016 drivers/android/binder.c Todd Kjos
2017-06-29 3614
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3615 if (get_user(cmd, (uint32_t __user *)ptr))
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3616 return -EFAULT;
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3617 ptr += sizeof(uint32_t);
975a1ac9a9fe65 drivers/staging/android/binder.c Arve Hjønnevåg
2012-10-16 3618 trace_binder_command(cmd);
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3619 if (_IOC_NR(cmd) <
ARRAY_SIZE(binder_stats.bc)) {
0953c7976c36ce drivers/android/binder.c Badhri Jagan Sridharan
2017-06-29 3620
atomic_inc(_stats.bc[_IOC_NR(cmd)]);
0953c7976c36ce drivers/android/binder.c Badhri Jagan Sridharan
2017-06-29 3621
atomic_inc(>stats.bc[_IOC_NR(cmd)]);
0953c7976c36ce drivers/android/binder.c Badhri Jagan Sridharan
2017-06-29 3622
atomic_inc(>stats.bc[_IOC_NR(cmd)]);
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3623 }
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3624 switch (cmd) {
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3625 case BC_INCREFS:
355b0502f6efea drivers/staging/android/binder.c Greg Kroah-Hartman
2011-11-30 3626 case BC_ACQUIRE:
355b0502f6efea
