RE: [PATCH v2 1/3] configs: aspeed: enable UHCI driver in defconfig
> -Original Message- > From: Greg KH > Sent: Friday, October 9, 2020 1:47 PM > To: Joel Stanley > Cc: Ryan Chen ; Andrew Jeffery > ; Linux ARM ; > linux-aspeed ; Linux Kernel Mailing List > ; linux-...@vger.kernel.org; BMC-SW > ; Alan Stern > Subject: Re: [PATCH v2 1/3] configs: aspeed: enable UHCI driver in defconfig > > On Fri, Oct 09, 2020 at 04:55:19AM +, Joel Stanley wrote: > > On Fri, 9 Oct 2020 at 04:45, Greg KH wrote: > > > > > > On Fri, Oct 09, 2020 at 10:49:35AM +0800, Ryan Chen wrote: > > > > v2: > > > > -Changed : Add SCSI, BLK_DEV_SD, USB_STORAGE support. > > > > v1: > > > > -Enable UHCI driver in aspeed_g5_defconfig. > > > > > > > > Signed-off-by: Ryan Chen > > > > > > Why do you need this in a defconfig? > > > > I would prefer configurations that are being used to be present in the > > defconfig so we can test it. I think this is a sensible change. > > Then it needs to be described in the changelog, otherwise we have no idea > why this is happening :) > Ok, will send new version describe it.
Re: [PATCH 5/5] i2c: geni: sdm845: dont perform DMA for the oneplus6
On Fri, Oct 09, 2020 at 10:56:15AM +0530, Akash Asthana wrote: > On 10/7/2020 11:19 PM, Caleb Connolly wrote: > > The OnePlus 6/T has the same issues as the c630 causing a crash when DMA > > is used for i2c, so disable it. > > > > https://patchwork.kernel.org/patch/11133827 > > Reviewed-by: Akash Asthana Thanks! Acked-by: Wolfram Sang So, this patch can go in via whatever tree seems apropriate. Let me know if I should take this patch individually. signature.asc Description: PGP signature
[gustavoars-linux:for-next/clang-ft 1/3] drivers/mtd/chips/cfi_cmdset_0002.c:981:1: warning: non-void function does not return a value in all control paths
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
for-next/clang-ft
head: de6b606b07e40c037ed4f83b53ee541692a78c6e
commit: 19be9a9946b4bf79ad752f4d1376509fb69e9250 [1/3] treewide: Fix
fall-through warnings for Clang
config: riscv-randconfig-r004-20201009 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
4cfc4025cc1433ca5ef1c526053fc9c4bfe64109)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=19be9a9946b4bf79ad752f4d1376509fb69e9250
git remote add gustavoars-linux
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
git fetch --no-tags gustavoars-linux for-next/clang-ft
git checkout 19be9a9946b4bf79ad752f4d1376509fb69e9250
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/mtd/chips/cfi_cmdset_0002.c:981:1: warning: non-void function does
>> not return a value in all control paths [-Wreturn-type]
}
^
1 warning generated.
vim +981 drivers/mtd/chips/cfi_cmdset_0002.c
fb4a90bfcd6d86 Eric W. Biedermann 2005-05-20 877
^1da177e4c3f41 Linus Torvalds 2005-04-16 878 static int get_chip(struct
map_info *map, struct flchip *chip, unsigned long adr, int mode)
^1da177e4c3f41 Linus Torvalds 2005-04-16 879 {
^1da177e4c3f41 Linus Torvalds 2005-04-16 880 DECLARE_WAITQUEUE(wait,
current);
^1da177e4c3f41 Linus Torvalds 2005-04-16 881 struct cfi_private *cfi
= map->fldrv_priv;
^1da177e4c3f41 Linus Torvalds 2005-04-16 882 unsigned long timeo;
^1da177e4c3f41 Linus Torvalds 2005-04-16 883 struct cfi_pri_amdstd
*cfip = (struct cfi_pri_amdstd *)cfi->cmdset_priv;
^1da177e4c3f41 Linus Torvalds 2005-04-16 884
^1da177e4c3f41 Linus Torvalds 2005-04-16 885 resettime:
^1da177e4c3f41 Linus Torvalds 2005-04-16 886 timeo = jiffies + HZ;
^1da177e4c3f41 Linus Torvalds 2005-04-16 887 retry:
^1da177e4c3f41 Linus Torvalds 2005-04-16 888 switch (chip->state) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 889
^1da177e4c3f41 Linus Torvalds 2005-04-16 890 case FL_STATUS:
^1da177e4c3f41 Linus Torvalds 2005-04-16 891 for (;;) {
4844ef80305d01 Vignesh Raghavendra 2019-06-25 892 if
(chip_ready(map, chip, adr))
^1da177e4c3f41 Linus Torvalds 2005-04-16 893
break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 894
^1da177e4c3f41 Linus Torvalds 2005-04-16 895 if
(time_after(jiffies, timeo)) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 896
printk(KERN_ERR "Waiting for chip to be ready timed out.\n");
^1da177e4c3f41 Linus Torvalds 2005-04-16 897
return -EIO;
^1da177e4c3f41 Linus Torvalds 2005-04-16 898 }
c4e773764cead9 Stefani Seibold 2010-04-18 899
mutex_unlock(>mutex);
^1da177e4c3f41 Linus Torvalds 2005-04-16 900
cfi_udelay(1);
c4e773764cead9 Stefani Seibold 2010-04-18 901
mutex_lock(>mutex);
^1da177e4c3f41 Linus Torvalds 2005-04-16 902 /*
Someone else might have been playing with it. */
^1da177e4c3f41 Linus Torvalds 2005-04-16 903 goto
retry;
^1da177e4c3f41 Linus Torvalds 2005-04-16 904 }
19be9a9946b4bf Gustavo A. R. Silva 2020-10-08 905 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 906
^1da177e4c3f41 Linus Torvalds 2005-04-16 907 case FL_READY:
^1da177e4c3f41 Linus Torvalds 2005-04-16 908 case FL_CFI_QUERY:
^1da177e4c3f41 Linus Torvalds 2005-04-16 909 case FL_JEDEC_QUERY:
^1da177e4c3f41 Linus Torvalds 2005-04-16 910 return 0;
^1da177e4c3f41 Linus Torvalds 2005-04-16 911
^1da177e4c3f41 Linus Torvalds 2005-04-16 912 case FL_ERASING:
2695eab964efaa Joakim Tjernlund2009-11-19 913 if (!cfip ||
!(cfip->EraseSuspend & (0x1|0x2)) ||
2695eab964efaa Joakim Tjernlund2009-11-19 914 !(mode ==
FL_READY || mode == FL_POINT ||
2695eab964efaa Joakim Tjernlund2009-11-19 915 (mode ==
FL_WRITING && (cfip->EraseSuspend & 0x2
^1da177e4c3f41 Linus Torvalds 2005-04-16 916 goto
sleep;
^1da177e4c3f41 Linus Torvalds 2005-04-16 917
[gustavoars-linux:for-next/clang-ft 2/3] drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:6318:2: warning: unannotated fall-through between switch labels
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git for-next/clang-ft head: de6b606b07e40c037ed4f83b53ee541692a78c6e commit: 7d30604536de43168b1eae0a4a938bcbca7786d2 [2/3] Revert "kbuild: Do not enable -Wimplicit-fallthrough for clang for now" config: x86_64-randconfig-a005-20201009 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 4cfc4025cc1433ca5ef1c526053fc9c4bfe64109) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=7d30604536de43168b1eae0a4a938bcbca7786d2 git remote add gustavoars-linux https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git git fetch --no-tags gustavoars-linux for-next/clang-ft git checkout 7d30604536de43168b1eae0a4a938bcbca7786d2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:31: In file included from include/linux/pci.h:1439: In file included from include/linux/dmapool.h:14: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:679: In file included from include/linux/huge_mm.h:8: In file included from include/linux/fs.h:33: In file included from include/linux/percpu-rwsem.h:7: In file included from include/linux/rcuwait.h:6: In file included from include/linux/sched/signal.h:6: include/linux/signal.h:241:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:241:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:241:2: note: insert 'break;' to avoid fall-through case 1: ; ^ break; include/linux/signal.h:253:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:253:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:253:2: note: insert 'break;' to avoid fall-through case 1: ; ^ break; In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:47: In file included from include/net/ip.h:25: include/linux/jhash.h:102:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 0: /* Nothing left to add */ ^ include/linux/jhash.h:102:2: note: insert 'break;' to avoid fall-through case 0: /* Nothing left to add */ ^ break; include/linux/jhash.h:139:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 0: /* Nothing left to add */ ^ include/linux/jhash.h:139:2: note: insert 'break;' to avoid fall-through case 0: /* Nothing left to add */ ^ break; >> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:6318:2: warning: >> unannotated fall-through between switch labels [-Wimplicit-fallthrough] case FW_MSG_CODE_DRV_LOAD_PORT: ^ drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:6318:2: note: insert 'break;' to avoid fall-through case FW_MSG_CODE_DRV_LOAD_PORT: ^ break; 5 warnings generated. -- In file included from drivers/net/ethernet/broadcom/bnxt/bnxt.c:21: In file included from include/linux/pci.h:1439: In file included from include/linux/dmapool.h:14: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:679: In file included from include/linux/huge_mm.h:8: In file included from include/linux/fs.h:33: In file included from include/linux/percpu-rwsem.h:7: In file included from include/linux/rcuwait.h:6: In file included from include/linux/sched/signal.h:6: include/linux/signal.h:241:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:241:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:241:2: note: insert 'break;' to avoid fall-through case 1:
Re: [PATCH] docs: Make automarkup ready for Sphinx 3.1+
Em Thu, 08 Oct 2020 13:54:59 + Nícolas F. R. A. Prado escreveu: > On Thu Oct 8, 2020 at 2:27 AM -03, Mauro Carvalho Chehab wrote: > > > > Hi Nícolas, > > > > Em Wed, 07 Oct 2020 23:12:25 + > > Nícolas F. R. A. Prado escreveu: > > > > > While Sphinx 2 used a single c:type role for struct, union, enum and > > > typedef, Sphinx 3 uses a specific role for each one. > > > To keep backward compatibility, detect the Sphinx version and use the > > > correct roles for that version. > > > > > > Also, Sphinx 3 is more strict with its C domain and generated warnings, > > > exposing issues in the parsing. > > > To fix the warnings, make the C regexes use ASCII, ensure the > > > expressions only match the beginning of words and skip trying to > > > cross-reference C reserved words. > > > > > > Signed-off-by: Nícolas F. R. A. Prado > > > --- > > > > > > Hi, > > > > > > after Mauro's series making everything ready for Sphinx 3.1, only the > > > automarkup > > > was left to be ported. > > > This patch makes the needed changes to automarkup so that we can soon > > > flip the > > > switch to Sphinx 3.1. > > > > > > This change was tested both with Sphinx 2.4.4 and Sphinx 3.1. > > > > > > This change doesn't add any warnings to the Documentation build. > > > I tested it with Mauro's series but later rebased it to docs-next, and it > > > can be > > > accepted independently of that series. > > > > > > I ended up doing more than one thing in this single patch, but since it > > > was all > > > changing the same lines and for the same purpose, I felt it would be > > > better to > > > keep it as a single commit. > > > > > > > Thanks for doing this! That was the last missing part on fully > > supporting > > Sphinx 3.1+. > > > > > Mauro, > > > if this patch is ok, the 3rd patch in your series, which disables > > > automarkup for > > > sphinx 3, should be dropped. > > > > Yeah, sure. > > > > > Although I'm not sure what the implications of your patches adding > > > namespaces > > > and using the c:macro for functions are. > > > > With regards to namespaces: > > > > Currently, only the media docs use namespaces, and it declares it at the > > beginning of each file that needs it, without overriding it later[1]. > > > > [1] btw, the cdomain.py backward compat code doesn't support namespace > > changes - as it parses namespaces before handling the C domain tags. > > I doubt that we'll need to have a single .rst file using more than > > one namespace anyway. > > > > The main usage is to avoid conflicts for uAPI documentation for > > syscalls - actually for libc userspace wrappers to syscalls. It > > documents > > things like: open, close, read, write, ioctl, poll, select. > > If it's mainly for that, I think automarkup could skip handling namespaces. > From automarkup.py: > > # > # Many places in the docs refer to common system calls. It is > # pointless to try to cross-reference them and, as has been known > # to happen, somebody defining a function by these names can lead > # to the creation of incorrect and confusing cross references. So > # just don't even try with these names. > # > Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap', > 'select', 'poll', 'fork', 'execve', 'clone', 'ioctl', > 'socket' ] > > So unless I'm confusing things and the namespaces actually sidestep that > issue, > the namespace handling could be left out of automarkup. Maybe I didn't express well enough. We need namespaces due to the syscals. Yet, if a .rst file uses it, *all* functions, structs, ... declared there will be under the namespace. In other words, looking at the V4L docs, for instance, all functions there will be under "V4L" namespace. It should be noticed that a side effect of this change is that we may need to use namespaces on *all* (or almost all) uAPI media documents. I'll double-check this for v5.11. If automarkup would try to generate a cross-reference for one of the many V4L2 API structs without using the "V4L" namespace, it will fail. Btw, considering that the namespace will solve the issues with those functions, I suspect that we can avoid skipping them, at least with Sphinx 3+. > > > > I'm not sure if the automarkup should be aware of it, or if the c.py > > code > > at Sphinx 3.x will add the namespace automatically, but I suspect that > > automarkup will need to handle it as well. > > > > One file you could use for checking it is this one: > > > > Documentation/userspace-api/media/v4l/hist-v4l2.rst > > > > It contains a namespace directive and documents what changed without > > using any explicit reference (after my patch series + linux-next). > > > > With regards to c:macro vs c:function: > > > > I suspect that automarkup should test both when trying to do > > cross-references for function-like calls. E. g. test first if > > there is a :c:function, falling back to check for :c:macro. > > > > I would add a "sphinx3_c_func_ref" function that would
Re: [PATCH v3 7/8] mm/mempolicy: use a standard migration target allocation callback
On Thu, 8 Oct 2020, Mike Kravetz wrote:
> On 10/7/20 8:21 PM, Hugh Dickins wrote:
> >
> > Mike, j'accuse... your 5.7 commit c0d0381ade79 ("hugetlbfs:
> > use i_mmap_rwsem for more pmd sharing synchronization"), in which
> > unmap_and_move_huge_page() now passes the TTU_RMAP_LOCKED flag to
> > try_to_unmap(), because it's already holding mapping->i_mmap_rwsem:
> > but that is not the right lock to secure an anon_vma lookup.
>
> Thanks Hugh! Your analysis is correct and the code in that commit is
> not correct. I was so focused on the file mapping case, I overlooked
> (actually introduced) this issue for anon mappings.
>
> Let me verify that this indeed is the root cause. However, since
> move_pages12 migrated anon hugetlb pages it certainly does look to be
> the case.
>
> > I intended to send a patch, passing TTU_RMAP_LOCKED only in the
> > !PageAnon case (and, see vma_adjust(), anon_vma lock conveniently
> > nests inside i_mmap_rwsem); but then wondered if i_mmap_rwsem was
> > needed in that case or not, so looked deeper into c0d0381ade79.
> >
> > Hmm, not even you liked it! But the worst of it looks simply
> > unnecessary to me, and I hope can be deleted - but better by you
> > than by me (in particular, you were trying to kill 1) and 2) birds
> > with one stone, and I've always given up on understanding hugetlb's
> > reservations: I suspect that side of it is irrelevant here,
> > but I wouldn't pretend to be sure).
> >
> > How could you ever find a PageAnon page in a vma_shareable() area?
> >
> > It is all rather confusing (vma_shareable() depending on VM_MAYSHARE,
> > whereas is_cow_mapping() on VM_SHARED and VM_MAYWRITE: they have to
> > be studied together with do_mmap()'s
> > vm_flags |= VM_SHARED | VM_MAYSHARE;
> > if (!(file->f_mode & FMODE_WRITE))
> > vm_flags &= ~(VM_MAYWRITE | VM_SHARED);
> >
> > (And let me add to the confusion by admitting that, prior to 3.15's
> > cda540ace6a1 "mm: get_user_pages(write,force) refuse to COW in
> > shared areas", maybe it was possible to find a PageAnon there.)
> >
> > But my belief (best confirmed by you running your tests with a
> > suitably placed BUG_ON or WARN_ON) is that you'll never find a
> > PageAnon in a vma_shareable() area, so will never need try_to_unmap()
> > to unshare a pagetable in the PageAnon case, so won't need i_mmap_rwsem
> > for PageAnon there, and _get_hugetlb_page_mapping() (your function that
> > deduces an address_space from an anon_vma) can just be deleted.
>
> Yes, it is confusing. Let me look into this. I would be really happy
> to delete that ugly function.
>
> > (And in passing, may I ask what hugetlb_page_mapping_lock_write()'s
> > hpage->_mapcount inc and dec are for? You comment it as a hack,
> > but don't explain what needs that hack, and I don't see it.)
>
> We are trying to lock the mapping (mapping->i_mmap_rwsem). We know
> mapping is valid, because we obtained it from page_mapping() and it
> will remain valid because we have the page locked. Page needs to be
> unlocked to unmap. However, we have to drop page lock in order to
> acquire i_mmap_rwsem. Once we drop page lock, mapping could become
> invalid. So, the code code artifically incs mapcount so that mapping
> will remain valid when upmapping page.
No, unless you can point me to some other hugetlbfs-does-it-differently
(and I didn't see it there in that commit), raising _mapcount does not
provide any such protection; but does add the possiblility of a
"BUG: Bad page cache" and leak from unaccount_page_cache_page().
Earlier in the day I was trying to work out what to recommend instead,
but had to turn aside to something else: I'll try again tomorrow.
It's a problem I've faced before in tmpfs, keeping a hold on the
mapping while page lock is dropped. Quite awkward: igrab() looks as
if it's the right thing to use, but turns out to give no protection
against umount. Last time around, I ended up with a stop_eviction
count in the shmem inode, which shmem_evict_inode() waits on if
necessary. Something like that could be done for hugetlbfs too,
but I'd prefer to do it without adding extra, if there is a way.
>
> As mentioned above, I hope all this can be removed.
If you continue to nest page lock inside i_mmap_rwsem for hugetlbfs,
then I think that part of hugetlb_page_mapping_lock_write() has to
remain. I'd much prefer that hugetlbfs did not reverse the usual
nesting, but accept that you had reasons for doing it that way.
Hugh
Re: [PATCH v2 1/3] configs: aspeed: enable UHCI driver in defconfig
On Fri, Oct 09, 2020 at 04:55:19AM +, Joel Stanley wrote: > On Fri, 9 Oct 2020 at 04:45, Greg KH wrote: > > > > On Fri, Oct 09, 2020 at 10:49:35AM +0800, Ryan Chen wrote: > > > v2: > > > -Changed : Add SCSI, BLK_DEV_SD, USB_STORAGE support. > > > v1: > > > -Enable UHCI driver in aspeed_g5_defconfig. > > > > > > Signed-off-by: Ryan Chen > > > > Why do you need this in a defconfig? > > I would prefer configurations that are being used to be present in the > defconfig so we can test it. I think this is a sensible change. Then it needs to be described in the changelog, otherwise we have no idea why this is happening :) thanks, greg k-h
Re: [PATCH v3 seccomp 2/5] seccomp/cache: Add "emulator" to check if filter is constant allow
On Thu, Oct 08, 2020 at 11:47:17PM -0500, YiFei Zhu wrote:
> On Wed, Sep 30, 2020 at 10:20 AM YiFei Zhu wrote:
> > @@ -544,7 +577,8 @@ static struct seccomp_filter
> > *seccomp_prepare_filter(struct sock_fprog *fprog)
> > {
> > struct seccomp_filter *sfilter;
> > int ret;
> > - const bool save_orig = IS_ENABLED(CONFIG_CHECKPOINT_RESTORE);
> > + const bool save_orig = IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) ||
> > + IS_ENABLED(CONFIG_SECCOMP_CACHE_NR_ONLY);
> >
> > if (fprog->len == 0 || fprog->len > BPF_MAXINSNS)
> > return ERR_PTR(-EINVAL);
>
> I'm trying to use __is_defined(SECCOMP_ARCH_NATIVE) here, and got this
> message:
>
> kernel/seccomp.c: In function ‘seccomp_prepare_filter’:
> ././include/linux/kconfig.h:44:44: error: pasting "__ARG_PLACEHOLDER_"
> and "(" does not give a valid preprocessing token
>44 | #define ___is_defined(val) is_defined(__ARG_PLACEHOLDER_##val)
> |^~
> ././include/linux/kconfig.h:43:27: note: in expansion of macro ‘___is_defined’
>43 | #define __is_defined(x) ___is_defined(x)
> | ^
> kernel/seccomp.c:629:11: note: in expansion of macro ‘__is_defined’
> 629 | __is_defined(SECCOMP_ARCH_NATIVE);
> | ^~~~
>
> Looking at the implementation of __is_defined, it is:
>
> #define __ARG_PLACEHOLDER_1 0,
> #define __take_second_arg(__ignored, val, ...) val
> #define __is_defined(x) ___is_defined(x)
> #define ___is_defined(val) is_defined(__ARG_PLACEHOLDER_##val)
> #define is_defined(arg1_or_junk) __take_second_arg(arg1_or_junk 1, 0)
>
> Hence, when FOO is defined to be 1, then the expansion would be
> __is_defined(FOO) -> ___is_defined(1) ->
> is_defined(__ARG_PLACEHOLDER_1) -> __take_second_arg(0, 1, 0) ->
> 1,
> and when FOO is not defined, the expansion would be __is_defined(FOO)
> -> ___is_defined(FOO) -> is_defined(__ARG_PLACEHOLDER_FOO) ->
> __take_second_arg(__ARG_PLACEHOLDER_FOO 1, 0) -> 0
>
> However, here SECCOMP_ARCH_NATIVE is an expression from an OR of some
> bits, and __is_defined(SECCOMP_ARCH_NATIVE) would not expand to
> __ARG_PLACEHOLDER_1 during any stage in the preprocessing.
>
> Is there any better way to do this? I'm thinking of just doing #if
> defined(CONFIG_CHECKPOINT_RESTORE) || defined(SECCOMP_ARCH_NATIVE)
> like in Kee's patch.
Yeah, I think that's simplest.
--
Kees Cook
Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
On 08-10-20, 17:00, Nicola Mazzucato wrote: > On 10/8/20 4:03 PM, Ionela Voinescu wrote: > > Hi Viresh, > > > > On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote: > >> On 07-10-20, 13:58, Nicola Mazzucato wrote: > >>> Hi Viresh, > >>> > >>> performance controls is what is exposed by the firmware through a > >>> protocol that > >>> is not capable of describing hardware (say SCMI). For example, the > >>> firmware can > >>> tell that the platform has N controls, but it can't say to which hardware > >>> they > >>> are "wired" to. This is done in dt, where, for example, we map these > >>> controls > >>> to cpus, gpus, etc. > >>> > >>> Let's focus on cpus. > >>> > >>> Normally we would have N of performance controls (what comes from f/w) > >>> that that correspond to hardware clock/dvfs domains. > >>> > >>> However, some firmware implementations might benefit from having finer > >>> grained information about the performance requirements (e.g. > >>> per-CPU) and therefore choose to present M performance controls to the > >>> OS. DT would be adjusted accordingly to "wire" these controls to cpus > >>> or set of cpus. > >>> In this scenario, the f/w will make aggregation decisions based on the > >>> requests it receives on these M controls. > >>> > >>> Here we would have M cpufreq policies which do not necessarily reflect the > >>> underlying clock domains, thus some s/w components will underperform > >>> (EAS and thermal, for example). > >>> > >>> A real example would be a platform in which the firmware describes the > >>> system > >>> having M per-cpu control, and the cpufreq subsystem will have M policies > >>> while > >>> in fact these cpus are "performance-dependent" each other (e.g. are in > >>> the same > >>> clock domain). > >> > >> If the CPUs are in the same clock domain, they must be part of the > >> same cpufreq policy. > > > > But cpufreq does not currently support HW_ALL (I'm using the ACPI > > coordination type to describe the generic scenario of using hardware > > aggregation and coordination when establishing the clock rate of CPUs). > > > > Adding support for HW_ALL* will involve either bypassing some > > assumptions around cpufreq policies or making core cpufreq changes. > > > > In the way I see it, support for HW_ALL involves either: > > > > - (a) Creating per-cpu policies in order to allow each of the CPUs to > >send their own frequency request to the hardware which will do > >aggregation and clock rate decision at the level of the clock > >domain. The PSD domains (ACPI) and the new DT binding will tell > >which CPUs are actually in the same clock domain for whomever is > >interested, despite those CPUs not being in the same policy. > >This requires the extra mask that Nicola introduced. > > > > - (b) Making deep changes to cpufreq (core/governors/drivers) to allow: > >- Governors to stop aggregating (usually max) the information > > for each of the CPUs in the policy and convey to the core > > information for each CPU. > >- Cpufreq core to be able to receive and pass this information > > down to the drivers. > >- Drivers to be able to have some per cpu structures to hold > > frequency control (let's say SCP fast channel addresses) for > > each of the CPUs in the policy. Or have these structures in the > > cpufreq core/policy, to avoid code duplication in drivers. > > > > Therefore (a) is the least invasive but we'll be bypassing the rule > > above. But to make that rule stick we'll have to make invasive cpufreq > > changes (b). > > Regarding the 'rule' above of one cpufreq policy per clock domain, I would > like > to share my understanding on it. Perhaps it's a good opportunity to shed some > light. > > Looking back in the history of CPUFreq, related_cpus was originally designed > to hold the map of cpus within the same clock. Later on, the meaning of this > cpumask changed [1]. > This led to the introduction of a new cpumask 'freqdomain_cpus' > within acpi-cpufreq to keep the knowledge of hardware clock domains for > sysfs consumers since related_cpus was not suitable anymore for this. > Further on, this cpumask was assigned to online+offline cpus within the same > clk > domain when sw coordination is in use [2]. > > My interpretation is that there is no guarantee that related_cpus holds the > 'real' hardware clock implementation. As a consequence, it is not true anymore > that cpus that are in the same clock domain will be part of the same > policy. > > This guided me to think it would be better to have a cpumask which always > holds > the real hw clock domains in the policy. > > > > > This is my current understanding and I'm leaning towards (a). What do > > you think? > > > > *in not so many words, this is what these patches are trying to propose, > > while also making sure it's supported for both ACPI and DT. > > > > BTW, thank you for your effort in making sense of this! > > > >
[PATCH] powerpc/8xx: Fix instruction TLB miss exception with perf enabled
When perf is enabled, r11 must also be restored when CONFIG_HUGETLBFS
is selected.
Fixes: a891c43b97d3 ("powerpc/8xx: Prepare handlers for _PAGE_HUGE for 512k
pages.")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_8xx.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 9f359d3fba74..32d85387bdc5 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -268,7 +268,7 @@ InstructionTLBMiss:
addir10, r10, 1
stw r10, (itlb_miss_counter - PAGE_OFFSET)@l(0)
mfspr r10, SPRN_SPRG_SCRATCH0
-#if defined(ITLB_MISS_KERNEL) || defined(CONFIG_SWAP)
+#if defined(ITLB_MISS_KERNEL) || defined(CONFIG_SWAP) ||
defined(CONFIG_HUGETLBFS)
mfspr r11, SPRN_SPRG_SCRATCH1
#endif
rfi
--
2.25.0
Re: [PATCH v3 seccomp 3/5] seccomp/cache: Lookup syscall allowlist for fast path
On Thu, Oct 08, 2020 at 07:17:39PM -0500, YiFei Zhu wrote:
> On Wed, Sep 30, 2020 at 4:32 PM Kees Cook wrote:
> >
> > On Wed, Sep 30, 2020 at 10:19:14AM -0500, YiFei Zhu wrote:
> > > From: YiFei Zhu
> > >
> > > The fast (common) path for seccomp should be that the filter permits
> > > the syscall to pass through, and failing seccomp is expected to be
> > > an exceptional case; it is not expected for userspace to call a
> > > denylisted syscall over and over.
> > >
> > > This first finds the current allow bitmask by iterating through
> > > syscall_arches[] array and comparing it to the one in struct
> > > seccomp_data; this loop is expected to be unrolled. It then
> > > does a test_bit against the bitmask. If the bit is set, then
> > > there is no need to run the full filter; it returns
> > > SECCOMP_RET_ALLOW immediately.
> > >
> > > Co-developed-by: Dimitrios Skarlatos
> > > Signed-off-by: Dimitrios Skarlatos
> > > Signed-off-by: YiFei Zhu
> >
> > I'd like the content/ordering of this and the emulator patch to be
> > reorganized a bit.
> > I'd like to see the infrastructure of the cache added first (along with
> > the "always allow" test logic in this patch), with the emulator missing:
> > i.e. the patch is a logical no-op: no behavior changes because nothing
> > ever changes the cache bits, but all the operational logic, structure
> > changes, etc, is in place. Then the next patch would be replacing the
> > no-op with the emulator.
> >
> > > ---
> > > kernel/seccomp.c | 52
> > > 1 file changed, 52 insertions(+)
> > >
> > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > index f09c9e74ae05..bed3b2a7f6c8 100644
> > > --- a/kernel/seccomp.c
> > > +++ b/kernel/seccomp.c
> > > @@ -172,6 +172,12 @@ struct seccomp_cache_filter_data { };
> > > static inline void seccomp_cache_prepare(struct seccomp_filter *sfilter)
> > > {
> > > }
> > > +
> > > +static inline bool seccomp_cache_check(const struct seccomp_filter
> > > *sfilter,
> >
> > bikeshedding: "cache check" doesn't tell me anything about what it's
> > actually checking for. How about calling this seccomp_is_constant_allow() or
> > something that reflects both the "bool" return ("is") and what that bool
> > means ("should always be allowed").
>
> We have a naming conflict here. I'm about to rename
> seccomp_emu_is_const_allow to seccomp_is_const_allow. Adding another
> seccomp_is_constant_allow is confusing. Suggestions?
>
> I think I would prefer to change seccomp_cache_check to
> seccomp_cache_check_allow. While in this patch set seccomp_cache_check
> does imply the filter is "constant" allow, argument-processing cache
> may change this, and specifying an "allow" in the name specifies the
> 'what that bool means ("should always be allowed")'.
Yeah, that seems good.
--
Kees Cook
xfrm:fragmented ipv4 tunnel packets in inner interface
In esp's tunnel mode,if inner interface is ipv4,outer is ipv4,one big
packet which travels through tunnel will be fragmented with outer
interface's mtu,peer server will remove tunnelled esp header and assemble
them in big packet.After forwarding such packet to next endpoint,it will
be dropped because of exceeding mtu or be returned ICMP(packet-too-big).
When inner interface is ipv4,outer is ipv6,the flag of xfrm state in tunnel
mode is af-unspec, thing is different.One big packet through tunnel will be
fragmented with outer interface's mtu minus tunneled header, then two or
more less fragmented packets will be tunneled and transmitted in outer
interface,that is what xfrm6_output has done. If peer server receives such
packets, it will forward successfully to next because length is valid.
This patch has followed up xfrm6_output's logic,which includes two changes,
one is choosing suitable mtu value which considering innner/outer
interface's mtu and dst path, the other is if packet is too big, calling
ip_fragment first,then tunnelling fragmented packets in outer interface and
transmitting finally.
Signed-off-by: Lina Wang
---
include/net/ip.h| 3 +++
net/ipv4/ip_output.c| 10 +++---
net/ipv4/xfrm4_output.c | 37 +
3 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index b09c48d862cc..05f9c6454ff5 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -163,6 +163,9 @@ int ip_output(struct net *net, struct sock *sk, struct
sk_buff *skb);
int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb);
int ip_do_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
int (*output)(struct net *, struct sock *, struct sk_buff
*));
+int ip_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
+ unsigned int mtu,
+ int (*output)(struct net *, struct sock *, struct sk_buff *));
struct ip_fraglist_iter {
struct sk_buff *frag;
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 61f802d5350c..f99249132a76 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -82,10 +82,6 @@
#include
#include
-static int
-ip_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
- unsigned int mtu,
- int (*output)(struct net *, struct sock *, struct sk_buff *));
/* Generate a checksum for an outgoing IP datagram. */
void ip_send_check(struct iphdr *iph)
@@ -569,9 +565,9 @@ static void ip_copy_metadata(struct sk_buff *to, struct
sk_buff *from)
skb_copy_secmark(to, from);
}
-static int ip_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
- unsigned int mtu,
- int (*output)(struct net *, struct sock *, struct
sk_buff *))
+int ip_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
+ unsigned int mtu,
+ int (*output)(struct net *, struct sock *, struct sk_buff *))
{
struct iphdr *iph = ip_hdr(skb);
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index 3cff51ba72bb..1488b79186ad 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -14,8 +14,27 @@
#include
#include
+static int __xfrm4_output_finish(struct net *net, struct sock *sk,
+struct sk_buff *skb)
+{
+ return xfrm_output(sk, skb);
+}
+
+static inline int ip4_skb_dst_mtu(struct sk_buff *skb)
+{
+ struct inet_sock *np = skb->sk && !dev_recursion_level() ?
+ inet_sk(skb->sk) : NULL;
+
+ return (np & np->pmtudisc >= IP_PMTUDISC_PROBE) ?
+ skb_dst(skb)->dev->mtu : dst_mtu(skb_dst(skb));
+}
+
static int __xfrm4_output(struct net *net, struct sock *sk, struct sk_buff
*skb)
{
+ int mtu;
+ bool toobig;
+ struct xfrm_state *x = skb_dst(skb)->xfrm;
+
#ifdef CONFIG_NETFILTER
struct xfrm_state *x = skb_dst(skb)->xfrm;
@@ -25,6 +44,24 @@ static int __xfrm4_output(struct net *net, struct sock *sk,
struct sk_buff *skb)
}
#endif
+ if (x->props.mode != XFRM_MODE_TUNNEL)
+ goto skip_frag;
+
+ if (skb->protocol == htons(ETH_P_IP))
+ mtu = ip4_skb_dst_mtu(skb);
+ else
+ goto skip_frag;
+
+ toobig = skb->len > mtu && !skb_is_gso(skb);
+ if (!skb->ignore_df && toobig && skb->sk) {
+ xfrm_local_error(skb, mtu);
+ return -EMSGSIZE;
+ }
+
+ if (toobig || dst_allfrag(skb_dst(skb)))
+ return ip_fragment(net, sk, skb, mtu, __xfrm4_output_finish);
+
+skip_frag:
return xfrm_output(sk, skb);
}
--
2.18.0
Re: drivers/crypto/chelsio/chcr_ktls.c:1078: undefined reference to `tls_get_record'
On 8/7/20 9:16 AM, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 86cfccb66937dd6cbf26ed619958b9e587e6a115 commit: 5a4b9fe7fece62ecab6fb28fe92362f83b41c33e cxgb4/chcr: complete record tx handling date: 5 months ago config: parisc-randconfig-r013-20200807 (attached as .config) compiler: hppa-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 5a4b9fe7fece62ecab6fb28fe92362f83b41c33e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa-linux-ld: drivers/crypto/chelsio/chcr_ktls.o: in function `chcr_ktls_xmit': drivers/crypto/chelsio/chcr_ktls.c:1078: undefined reference to `tls_get_record' hppa-linux-ld: drivers/crypto/chelsio/chcr_ktls.o: in function `.LC10': chcr_ktls.c:(.rodata.cst4+0x0): undefined reference to `tls_validate_xmit_skb' Hi, Has anyone tried to fix this build error? It still fails on v5.9-rc8. CONFIG_TLS=m but CONFIG_CRYPTO_DEV_CHELSIO=y CONFIG_CHELSIO_TLS_DEVICE=y so the builtin driver cannot reach the TLS loadable module symbols. -- ~Randy
Re: [PATCH v3 5/5] platform/surface: Move Surface Pro 3 Button driver to platform/surface
On Thu, Oct 08, 2020 at 04:34:55PM +0200, Maximilian Luz wrote: > Move the Surface Pro 3 Button driver from platform/x86 to the newly > created platform/surface directory. > > Signed-off-by: Maximilian Luz > Acked-by: Chen Yu Thanks! best, Chenyu
Re: [PATCH 5/5] i2c: geni: sdm845: dont perform DMA for the oneplus6
On 10/7/2020 11:19 PM, Caleb Connolly wrote:
The OnePlus 6/T has the same issues as the c630 causing a crash when DMA
is used for i2c, so disable it.
https://patchwork.kernel.org/patch/11133827
Reviewed-by: Akash Asthana
Signed-off-by: Caleb Connolly
---
drivers/i2c/busses/i2c-qcom-geni.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index dead5db3315a..50a0674a6553 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -358,7 +358,8 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
struct geni_se *se = >se;
size_t len = msg->len;
- if (!of_machine_is_compatible("lenovo,yoga-c630"))
+ if (!of_machine_is_compatible("lenovo,yoga-c630") &&
+ !of_machine_is_compatible("oneplus,oneplus6"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
if (dma_buf)
@@ -400,7 +401,8 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
struct geni_se *se = >se;
size_t len = msg->len;
- if (!of_machine_is_compatible("lenovo,yoga-c630"))
+ if (!of_machine_is_compatible("lenovo,yoga-c630") &&
+ !of_machine_is_compatible("oneplus,oneplus6"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
if (dma_buf)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
Re: [PATCH v2] ARM: kprobes: Avoid fortify_panic() when copying optprobe template
On Thu, 1 Oct 2020 at 04:30, Andrew Jeffery wrote:
>
> Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads
> to a panic in memcpy() when injecting a kprobe despite the fixes found
> in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
> FORTIFY_SOURCE") and commit 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes:
> optimized kprobes illegal instruction").
>
> arch/arm/include/asm/kprobes.h effectively declares
> the target type of the optprobe_template_entry assembly label as a u32
> which leads memcpy()'s __builtin_object_size() call to determine that
> the pointed-to object is of size four. However, the symbol is used as a handle
> for the optimised probe assembly template that is at least 96 bytes in size.
> The symbol's use despite its type blows up the memcpy() in ARM's
> arch_prepare_optimized_kprobe() with a false-positive fortify_panic() when it
> should instead copy the optimised probe template into place:
>
> ```
> $ sudo perf probe -a aspeed_g6_pinctrl_probe
> [ 158.457252] detected buffer overflow in memcpy
> [ 158.458069] [ cut here ]
> [ 158.458283] kernel BUG at lib/string.c:1153!
> [ 158.458436] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [ 158.458768] Modules linked in:
> [ 158.459043] CPU: 1 PID: 99 Comm: perf Not tainted
> 5.9.0-rc7-00038-gc53ebf8167e9 #158
> [ 158.459296] Hardware name: Generic DT based system
> [ 158.459529] PC is at fortify_panic+0x18/0x20
> [ 158.459658] LR is at __irq_work_queue_local+0x3c/0x74
> [ 158.459831] pc : [<8047451c>]lr : [<8020ecd4>]psr: 6013
> [ 158.460032] sp : be2d1d50 ip : be2d1c58 fp : be2d1d5c
> [ 158.460174] r10: 0006 r9 : r8 : 0060
> [ 158.460348] r7 : 8011e434 r6 : b9e0b800 r5 : 7f00 r4 : b9fe4f0c
> [ 158.460557] r3 : 80c04cc8 r2 : r1 : be7c03cc r0 : 0022
> [ 158.460801] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> none
> [ 158.461037] Control: 10c5387d Table: b9cd806a DAC: 0051
> [ 158.461251] Process perf (pid: 99, stack limit = 0x81c71a69)
> [ 158.461472] Stack: (0xbe2d1d50 to 0xbe2d2000)
> [ 158.461757] 1d40: be2d1d84 be2d1d60
> 8011e724 80474510
> [ 158.462104] 1d60: b9e0b800 b9fe4f0c b9fe4f14 80c8ec80 be235000
> be2d1d9c be2d1d88
> [ 158.462436] 1d80: 801cee44 8011e57c b9fe4f0c be2d1dc4 be2d1da0
> 801d0ad0 801cedec
> [ 158.462742] 1da0: b9fe4f00 ffea be235000
> be2d1de4 be2d1dc8
> [ 158.463087] 1dc0: 80204604 801d0738 b9fe4004 ffea
> be2d1e94 be2d1de8
> [ 158.463428] 1de0: 80205434 80204570 00385c00
> be2d1e14 be2d1e08
> [ 158.463880] 1e00: 802ba014 b9fe4f00 b9e718c0 b9fe4f84 b9e71ec8 be2d1e24
> 00385c00
> [ 158.464365] 1e20: 626f7270 0065 802b905c be2d1e94 002e
> 802b9914
> [ 158.464829] 1e40: be2d1e84 be2d1e50 802b9914 8028ff78 804629d0 b9e71ec0
> 002e b9e71ec0
> [ 158.465141] 1e60: be2d1ea8 80c04cc8 0cc0 b9e713c4 0002 80205834
> 80205834 002e
> [ 158.465488] 1e80: be235000 be235000 be2d1ea4 be2d1e98 80205854 80204e94
> be2d1ecc be2d1ea8
> [ 158.465806] 1ea0: 801ee4a0 80205840 0002 80c04cc8 002e
> 002e
> [ 158.466110] 1ec0: be2d1f0c be2d1ed0 801ee5c8 801ee428 be2d
> 006b1fd0 0051
> [ 158.466398] 1ee0: b9eedf00 002e 80204410 006b1fd0 be2d1f60
> 0004
> [ 158.466763] 1f00: be2d1f24 be2d1f10 8020442c 801ee4c4 80205834 802c613c
> be2d1f5c be2d1f28
> [ 158.467102] 1f20: 802c60ac 8020441c be2d1fac be2d1f38 8010c764 802e9888
> be2d1f5c b9eedf00
> [ 158.467447] 1f40: b9eedf00 006b1fd0 002e be2d1f94 be2d1f60
> 802c634c 802c5fec
> [ 158.467812] 1f60: 80c04cc8 006b1fd0 0003
> 76f7a610 0004
> [ 158.468155] 1f80: 80100284 be2d be2d1fa4 be2d1f98 802c63ec 802c62e8
> be2d1fa8
> [ 158.468508] 1fa0: 80100080 802c63e0 006b1fd0 0003 0003 006b1fd0
> 002e
> [ 158.468858] 1fc0: 006b1fd0 0003 76f7a610 0004 006b1fb0 0026d348
> 0017 7ef2738c
> [ 158.469202] 1fe0: 76f3431c 7ef272d8 0014ec50 76f34338 6010 0003
>
> [ 158.469461] Backtrace:
> [ 158.469683] [<80474504>] (fortify_panic) from [<8011e724>]
> (arch_prepare_optimized_kprobe+0x1b4/0x1f8)
> [ 158.470021] [<8011e570>] (arch_prepare_optimized_kprobe) from [<801cee44>]
> (alloc_aggr_kprobe+0x64/0x70)
> [ 158.470287] r9:be235000 r8:80c8ec80 r7:b9fe4f14 r6: r5:b9fe4f0c
> r4:b9e0b800
> [ 158.470478] [<801cede0>] (alloc_aggr_kprobe) from [<801d0ad0>]
> (register_kprobe+0x3a4/0x5a0)
> [ 158.470685] r5: r4:b9fe4f0c
> [ 158.470790] [<801d072c>] (register_kprobe) from [<80204604>]
> (__register_trace_kprobe+0xa0/0xa4)
> [ 158.471001] r9:be235000 r8: r7:ffea r6:b9fe4f00 r5:
> r4:
> [
[gustavoars-linux:for-next/clang-ft 2/3] drivers/media/dvb-frontends/m88ds3103.c:910:2: warning: unannotated fall-through between switch labels
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git for-next/clang-ft head: de6b606b07e40c037ed4f83b53ee541692a78c6e commit: 7d30604536de43168b1eae0a4a938bcbca7786d2 [2/3] Revert "kbuild: Do not enable -Wimplicit-fallthrough for clang for now" config: x86_64-randconfig-a003-20201009 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 4cfc4025cc1433ca5ef1c526053fc9c4bfe64109) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=7d30604536de43168b1eae0a4a938bcbca7786d2 git remote add gustavoars-linux https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git git fetch --no-tags gustavoars-linux for-next/clang-ft git checkout 7d30604536de43168b1eae0a4a938bcbca7786d2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/media/dvb-frontends/m88ds3103.c:8: In file included from drivers/media/dvb-frontends/m88ds3103_priv.h:11: In file included from include/media/dvb_frontend.h:48: In file included from include/media/dvbdev.h:23: In file included from include/linux/poll.h:10: In file included from include/linux/fs.h:33: In file included from include/linux/percpu-rwsem.h:7: In file included from include/linux/rcuwait.h:6: In file included from include/linux/sched/signal.h:6: include/linux/signal.h:241:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:241:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:241:2: note: insert 'break;' to avoid fall-through case 1: ; ^ break; include/linux/signal.h:253:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:253:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:253:2: note: insert 'break;' to avoid fall-through case 1: ; ^ break; >> drivers/media/dvb-frontends/m88ds3103.c:910:2: warning: unannotated >> fall-through between switch labels [-Wimplicit-fallthrough] default: ^ drivers/media/dvb-frontends/m88ds3103.c:910:2: note: insert '__attribute__((fallthrough));' to silence this warning default: ^ __attribute__((fallthrough)); drivers/media/dvb-frontends/m88ds3103.c:910:2: note: insert 'break;' to avoid fall-through default: ^ break; 3 warnings generated. -- In file included from drivers/media/cec/core/cec-pin.c:10: In file included from include/media/cec-pin.h:12: In file included from include/media/cec.h:11: In file included from include/linux/poll.h:10: In file included from include/linux/fs.h:33: In file included from include/linux/percpu-rwsem.h:7: In file included from include/linux/rcuwait.h:6: In file included from include/linux/sched/signal.h:6: include/linux/signal.h:241:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:241:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:241:2: note: insert 'break;' to avoid fall-through case 1: ; ^ break; include/linux/signal.h:253:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 1: ; ^ include/linux/signal.h:253:2: note: insert '__attribute__((fallthrough));' to silence this warning case 1: ; ^ __attribute__((fallthrough)); include/linux/signal.h:253:2: note: insert 'break;' to avoid fall-through case 1: ; ^ break; >> drivers/media/cec/core/cec-pin.c:421:2: warning: unannotated fall-through >> between switch labels [-Wimplicit-fallthrough] case CEC_ST_TX_DATA_BIT_0_HIGH: ^ drivers/media/cec/core/cec-pin.c:421:2: note: insert '__attribute__((fallthrough));' to silence this warning
Re: [PATCH v1 1/1] cpufreq: mediatek-hw: Register EM power table
On 09-10-20, 12:42, Hector Yuan wrote: > On Fri, 2020-10-09 at 09:49 +0530, Viresh Kumar wrote: > > On 08-10-20, 20:13, Hector Yuan wrote: > > > From: "Hector.Yuan" > > > > > > Register CPU power table to energy model framework > > > > > > Signed-off-by: Hector.Yuan > > > --- > > > drivers/cpufreq/mediatek-cpufreq-hw.c | 50 > > > + > > > 1 file changed, 38 insertions(+), 12 deletions(-) > > > > I don't see this file in mainline. What am I missing ? > > > Hi, Viresh: > > Yes, I base on my patches which is currently reviewed by Rob for the > Device tree part. > As I mentioned in cover letter. > > This patch depends on Mediatek cpufreq HW driver patch submitted by > Hector Yuan. > https://lkml.org/lkml/2020/9/10/13 > > I have asked your approval for sending my new patches based on it and > you said it's okay to you. > I will stop sending new patches if you have any concerns. > Thank you so much. Sorry about that, I failed to see the details in the cover-letter. -- viresh
Re: [RFC V2] dt-bindings: mailbox : arm,mhuv2: Add bindings
On 08-10-20, 09:30, Rob Herring wrote: > On Wed, Oct 7, 2020 at 10:28 AM Viresh Kumar wrote: > > + clock-names: > > +items: > > + - const: apb_pclk > > Just 'maxItems: 1' is fine here as the name is already defined. > > > + > > + arm-mhuv2-mode: > > arm,mhuv2-mode. This is what I did initially but was getting errors with it... > Needs a type reference. And this fixed it. > > +description: | > > + The MHUv2 controller may contain up to 124 channel windows (each > > 32-bit > > + wide). The hardware and the DT bindings allows any combination of > > those to > > + be used for various transport protocols. > > + > > + This property allows a platform to describe how these channel > > windows are > > + used in various transport protocols. The entries in this property > > shall be > > + present as an array of tuples, where each tuple describes details > > about > > + one of the transport protocol being implemented over some channel > > + window(s). > > + > > + The first field of a tuple signifies the transfer protocol, 0 is > > reserved > > + for doorbell protocol, 1 is reserved for single-word protocol and 2 > > is > > + reserved for multi-word protocol. Using any other value in the first > > field > > + of a tuple makes it invalid. > > + > > + The second field of a tuple signifies the number of channel windows > > where > > + the protocol would be used. For doorbell protocol this field > > signifies the > > + number of 32-bit channel windows that implement the doorbell > > protocol. For > > + single-word protocol this field signifies the number of 32-bit > > channel > > + windows that implement separate single-word protocol mailbox > > channels. For > > + multi-word protocol this field signifies the number of channel > > windows > > + used for a multi-word protocol, it should be 2 or more. > > These are based on IP configuration or a software decision? Software/firmware. The platform only fixes the total number of 32-bit registers available (channel windows) for use, how we use them is left to us. I tried to make it as generic as possible so any combinations of protocols can be used here. > > + The total number of channel windows specified here shouldn't be more > > than > > + the ones implemented by the platform. > > But can be less? Then do you need this to be a mask or range? Yes, we don't need to use all the windows that are available to us. I am not sure why we would need a mask/range here. Just to clarify a little, as it took me some time to come to this understanding, the maximum number of channel windows (these aren't necessarily mailbox channels) supported by the hardware is 124, i.e. 124 32-bit registers. Though a platform may implement only 8 of them, for example and the OS may want to use only 4 of them. If we use the entire thing in: - multi-word mode, we can create a single mailbox channel which is capable of transferring 124 words in one go. - single-word mode, we will end up having 124 mailbox channels, each 32 bit wide. - doorbell mode, we will end up having 124 * 32 mailbox channels. -- viresh
linux-next: manual merge of the rcu tree with the tip tree
Hi all,
Today's linux-next merge of the rcu tree got a conflict in:
include/linux/lockdep.h
between commit:
a046a86082cc ("lockdep: Fix lockdep recursion")
from the tip tree and commit:
0eb8743dc570 ("lockdep: Cleanup PREEMPT_COUNT leftovers")
from the rcu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/lockdep.h
index f5594879175a,8555fd128ebf..
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@@ -580,18 -566,16 +586,16 @@@ do {
#define lockdep_assert_preemption_enabled() \
do { \
- WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
-__lockdep_enabled && \
- WARN_ON_ONCE(debug_locks&& \
++ WARN_ON_ONCE(__lockdep_enabled && \
(preempt_count() != 0 || \
-!raw_cpu_read(hardirqs_enabled)));\
+!this_cpu_read(hardirqs_enabled))); \
} while (0)
#define lockdep_assert_preemption_disabled() \
do { \
- WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
-__lockdep_enabled && \
- WARN_ON_ONCE(debug_locks&& \
++ WARN_ON_ONCE(__lockdep_enabled && \
(preempt_count() == 0 && \
-raw_cpu_read(hardirqs_enabled))); \
+this_cpu_read(hardirqs_enabled)));\
} while (0)
#else
pgprorzzazXn5.pgp
Description: OpenPGP digital signature
Re: [PATCH] char: ppdev: check if ioctl argument is present and valid
On Thu, Oct 08, 2020 at 11:57:13PM +0530, Harshal Chaudhari wrote: > Checking the argument passed to the ioctl is valid > or not. if not then return -EINVAL. Along the the comments that Arnd made, this is not the correct value to be returning from an ioctl when you don't pass in the correct command. And it doesn't match what your patch says, please be consistent. And do you have this device to be able to test your changes? thanks, greg k-h
Re: [PATCH v2 1/3] configs: aspeed: enable UHCI driver in defconfig
On Fri, 9 Oct 2020 at 04:45, Greg KH wrote: > > On Fri, Oct 09, 2020 at 10:49:35AM +0800, Ryan Chen wrote: > > v2: > > -Changed : Add SCSI, BLK_DEV_SD, USB_STORAGE support. > > v1: > > -Enable UHCI driver in aspeed_g5_defconfig. > > > > Signed-off-by: Ryan Chen > > Why do you need this in a defconfig? I would prefer configurations that are being used to be present in the defconfig so we can test it. I think this is a sensible change. Ryan, I gave you my Reviewed-by for the last version of the patch. As you did not change the contents of this patch it is fine for you to leave my Reviewed-by on it. Cheers, Joel
Re: [PATCH v9 3/3] Wire UFFD up to SELinux
On Wed, Sep 23, 2020 at 12:33:24PM -0700, Lokesh Gidra wrote: > > [PATCH v9 3/3] Wire UFFD up to SELinux Seems that this isn't a very good description of the patch, since it isn't SELinux-specific? - Eric
Re: [PATCH v3 seccomp 2/5] seccomp/cache: Add "emulator" to check if filter is constant allow
On Wed, Sep 30, 2020 at 10:20 AM YiFei Zhu wrote:
> @@ -544,7 +577,8 @@ static struct seccomp_filter
> *seccomp_prepare_filter(struct sock_fprog *fprog)
> {
> struct seccomp_filter *sfilter;
> int ret;
> - const bool save_orig = IS_ENABLED(CONFIG_CHECKPOINT_RESTORE);
> + const bool save_orig = IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) ||
> + IS_ENABLED(CONFIG_SECCOMP_CACHE_NR_ONLY);
>
> if (fprog->len == 0 || fprog->len > BPF_MAXINSNS)
> return ERR_PTR(-EINVAL);
I'm trying to use __is_defined(SECCOMP_ARCH_NATIVE) here, and got this message:
kernel/seccomp.c: In function ‘seccomp_prepare_filter’:
././include/linux/kconfig.h:44:44: error: pasting "__ARG_PLACEHOLDER_"
and "(" does not give a valid preprocessing token
44 | #define ___is_defined(val) is_defined(__ARG_PLACEHOLDER_##val)
|^~
././include/linux/kconfig.h:43:27: note: in expansion of macro ‘___is_defined’
43 | #define __is_defined(x) ___is_defined(x)
| ^
kernel/seccomp.c:629:11: note: in expansion of macro ‘__is_defined’
629 | __is_defined(SECCOMP_ARCH_NATIVE);
| ^~~~
Looking at the implementation of __is_defined, it is:
#define __ARG_PLACEHOLDER_1 0,
#define __take_second_arg(__ignored, val, ...) val
#define __is_defined(x) ___is_defined(x)
#define ___is_defined(val) is_defined(__ARG_PLACEHOLDER_##val)
#define is_defined(arg1_or_junk) __take_second_arg(arg1_or_junk 1, 0)
Hence, when FOO is defined to be 1, then the expansion would be
__is_defined(FOO) -> ___is_defined(1) ->
is_defined(__ARG_PLACEHOLDER_1) -> __take_second_arg(0, 1, 0) ->
1,
and when FOO is not defined, the expansion would be __is_defined(FOO)
-> ___is_defined(FOO) -> is_defined(__ARG_PLACEHOLDER_FOO) ->
__take_second_arg(__ARG_PLACEHOLDER_FOO 1, 0) -> 0
However, here SECCOMP_ARCH_NATIVE is an expression from an OR of some
bits, and __is_defined(SECCOMP_ARCH_NATIVE) would not expand to
__ARG_PLACEHOLDER_1 during any stage in the preprocessing.
Is there any better way to do this? I'm thinking of just doing #if
defined(CONFIG_CHECKPOINT_RESTORE) || defined(SECCOMP_ARCH_NATIVE)
like in Kee's patch.
YiFei Zhu
Re: [PATCH v9 1/3] Add a new LSM-supporting anonymous inode interface
On Wed, Sep 23, 2020 at 12:33:22PM -0700, Lokesh Gidra wrote:
> +static struct file *_anon_inode_getfile(const char *name,
> + const struct file_operations *fops,
> + void *priv, int flags,
> + const struct inode *context_inode,
> + bool secure)
> +{
Nit: in Linux kernel code, using double underscore function prefixes is much
more common than single underscores.
> +/**
> + * Like anon_inode_getfd(), but adds the @context_inode argument to
> + * allow security modules to control creation of the new file. Once the
> + * security module makes the decision, this inode is no longer needed
> + * and hence reference to it is not held.
> + */
> +int anon_inode_getfd_secure(const char *name, const struct file_operations
> *fops,
> + void *priv, int flags,
> + const struct inode *context_inode)
> +{
> + return _anon_inode_getfd(name, fops, priv, flags, context_inode, true);
> +}
> +EXPORT_SYMBOL_GPL(anon_inode_getfd_secure);
This new function has two callers, one of which passes context_inode=NULL.
But from the comment, it sounds like the purpose of this function is just to add
the context_inode argument. So one would expect anon_inode_getfd() to be
equivalent to anon_inode_getfd_secure(..., NULL).
Apparently, that's not actually the case though. Can you fix the comment to
describe what the function actually does?
- Eric
Re: [PATCH v2 1/3] configs: aspeed: enable UHCI driver in defconfig
On Fri, Oct 09, 2020 at 10:49:35AM +0800, Ryan Chen wrote: > v2: > -Changed : Add SCSI, BLK_DEV_SD, USB_STORAGE support. > v1: > -Enable UHCI driver in aspeed_g5_defconfig. > > Signed-off-by: Ryan Chen Why do you need this in a defconfig?
Re: [PATCH v2 2/3] usb: host: add uhci compatible support for ast2600-uhci
On Fri, Oct 09, 2020 at 10:49:36AM +0800, Ryan Chen wrote: > v2: > - Fix continuation lines, align with "of_device" > v1: > - Add support for AST2600 SOC UHCI driver. These all go below the --- line, as the kernel documentation asks for. > Signed-off-by: Ryan Chen You have no changelog text here at all, and I can't take that, sorry. Please fix this up and resend with a proper changelog text. thanks, greg k-h
Re: [PATCH v1 1/1] cpufreq: mediatek-hw: Register EM power table
On Fri, 2020-10-09 at 09:49 +0530, Viresh Kumar wrote: > On 08-10-20, 20:13, Hector Yuan wrote: > > From: "Hector.Yuan" > > > > Register CPU power table to energy model framework > > > > Signed-off-by: Hector.Yuan > > --- > > drivers/cpufreq/mediatek-cpufreq-hw.c | 50 > > + > > 1 file changed, 38 insertions(+), 12 deletions(-) > > I don't see this file in mainline. What am I missing ? > Hi, Viresh: Yes, I base on my patches which is currently reviewed by Rob for the Device tree part. As I mentioned in cover letter. This patch depends on Mediatek cpufreq HW driver patch submitted by Hector Yuan. https://lkml.org/lkml/2020/9/10/13 I have asked your approval for sending my new patches based on it and you said it's okay to you. I will stop sending new patches if you have any concerns. Thank you so much.
Re: [f2fs-dev] [f2fs bug] infinite loop in f2fs_get_meta_page_nofail()
On 10/09, Chao Yu wrote: > On 2020/10/9 9:50, jaeg...@kernel.org wrote: > > On 10/09, Chao Yu wrote: > > > On 2020/10/8 5:53, jaeg...@kernel.org wrote: > > > > On 10/07, Eric Biggers wrote: > > > > > [moved linux-fsdevel to Bcc] > > > > > > > > > > On Wed, Oct 07, 2020 at 02:18:19AM -0700, syzbot wrote: > > > > > > Hello, > > > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > > > HEAD commit:a804ab08 Add linux-next specific files for 20201006 > > > > > > git tree: linux-next > > > > > > console output: > > > > > > https://syzkaller.appspot.com/x/log.txt?x=17fe30bf90 > > > > > > kernel config: > > > > > > https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb > > > > > > dashboard link: > > > > > > https://syzkaller.appspot.com/bug?extid=ee250ac8137be41d7b13 > > > > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > > > syz repro: > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=1336413b90 > > > > > > C reproducer: > > > > > > https://syzkaller.appspot.com/x/repro.c?x=12f7392b90 > > > > > > > > > > > > The issue was bisected to: > > > > > > > > > > > > commit eede846af512572b1f30b34f9889d7df64c017d4 > > > > > > Author: Jaegeuk Kim > > > > > > Date: Fri Oct 2 21:17:35 2020 + > > > > > > > > > > > > f2fs: f2fs_get_meta_page_nofail should not be failed > > > > > > > > > > > > > > > > Jaegeuk, it looks like the loop you added in the above commit doesn't > > > > > terminate > > > > > if the requested page is beyond the end of the device. > > > > > > > > Yes, that will go infinite loop. Otherwise, it will trigger a panic > > > > during > > > > the device reboot. Let me think how to avoid that before trying to get > > > > the > > > > wrong lba access. > > > > > > Delivering f2fs_get_sum_page()'s return value needs a lot of codes > > > change, I think > > > we can just zeroing sum_page in error case, as we have already shutdown > > > f2fs via > > > calling f2fs_stop_checkpoint(), then f2fs_cp_error() will stop all > > > updates to > > > filesystem data including summary pages. > > > > That sounds like one solution tho, I'm afraid of getting another panic by > > wrong zero'ed summary page. > > What case do you mean? maybe I missed some corner cases? I sent v2 to fix syzbot issue, which fixes wrong use of f2fs_get_meta_page_nofail. > > Thanks, > > > > > > > > > Thoughts? > > > > > > Thanks, > > > > > > > > > > > > > > > > > - Eric > > > > > > > > > > > > ___ > > > > Linux-f2fs-devel mailing list > > > > linux-f2fs-de...@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > > . > > > > > > . > >
Re: [PATCH v2] f2fs: f2fs_get_meta_page_nofail should not be failed
Otherwise, f2fs can break the the consistency.
(e.g., BUG_ON in f2fs_get_sum_page)
Then, this reveals another issue where we go into an infinite loop on normal
error case. It turns out we abused f2fs_get_meta_page_nofail() in this path.
- f2fs_fill_super
- f2fs_build_segment_manager
- build_sit_entries
- get_current_sit_page
Actually, we didn't have to use _nofail in this case, since we could return
error to mount(2) already with the error handler.
This was caught by syzbot as follows.
INFO: task syz-executor178:6870 can't die for more than 143 seconds.
task:syz-executor178 state:R
stack:26960 pid: 6870 ppid: 6869 flags:0x4006
Call Trace:
Showing all locks held in the system:
1 lock held by khungtaskd/1179:
#0: 8a554da0 (rcu_read_lock){}-{1:2}, at:
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6242
1 lock held by systemd-journal/3920:
1 lock held by in:imklog/6769:
#0: 88809eebc130 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100
fs/file.c:930
1 lock held by syz-executor178/6870:
#0: 8880925120e0 (>s_umount_key#47/1){+.+.}-{3:3}, at:
alloc_super+0x201/0xaf0 fs/super.c:229
Reported-by: syzbot+ee250ac8137be41d7...@syzkaller.appspotmail.com
Signed-off-by: Jaegeuk Kim
---
v2 log:
- fix syzbot issue
fs/f2fs/checkpoint.c | 9 +++--
fs/f2fs/f2fs.h | 2 --
fs/f2fs/segment.c| 2 +-
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index f18386d30f031..7bb3a741a8f16 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -110,15 +110,12 @@ struct page *f2fs_get_meta_page(struct f2fs_sb_info *sbi,
pgoff_t index)
struct page *f2fs_get_meta_page_nofail(struct f2fs_sb_info *sbi, pgoff_t index)
{
struct page *page;
- int count = 0;
-
retry:
page = __get_meta_page(sbi, index, true);
if (IS_ERR(page)) {
- if (PTR_ERR(page) == -EIO &&
- ++count <= DEFAULT_RETRY_IO_COUNT)
- goto retry;
- f2fs_stop_checkpoint(sbi, false);
+ f2fs_flush_merged_writes(sbi);
+ congestion_wait(BLK_RW_ASYNC, DEFAULT_IO_TIMEOUT);
+ goto retry;
}
return page;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ae46d44bd5211..ce79b9b5b1eff 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -593,8 +593,6 @@ enum {
*/
};
-#define DEFAULT_RETRY_IO_COUNT 8 /* maximum retry read IO count */
-
/* congestion wait timeout value, default: 20ms */
#defineDEFAULT_IO_TIMEOUT (msecs_to_jiffies(20))
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 13ecd2c2c361b..40001d80fa86d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -3964,7 +3964,7 @@ int f2fs_lookup_journal_in_cursum(struct f2fs_journal
*journal, int type,
static struct page *get_current_sit_page(struct f2fs_sb_info *sbi,
unsigned int segno)
{
- return f2fs_get_meta_page_nofail(sbi, current_sit_addr(sbi, segno));
+ return f2fs_get_meta_page(sbi, current_sit_addr(sbi, segno));
}
static struct page *get_next_sit_page(struct f2fs_sb_info *sbi,
--
2.28.0.1011.ga647a8990f-goog
Re: [PATCH v1 1/1] cpufreq: mediatek-hw: Register EM power table
On Thu, 2020-10-08 at 13:55 +0100, Lukasz Luba wrote:
> Hi Hector,
>
> On 10/8/20 1:13 PM, Hector Yuan wrote:
> > From: "Hector.Yuan"
> >
> > Register CPU power table to energy model framework
> >
> > Signed-off-by: Hector.Yuan
> > ---
> > drivers/cpufreq/mediatek-cpufreq-hw.c | 50
> > +
> > 1 file changed, 38 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c
> > b/drivers/cpufreq/mediatek-cpufreq-hw.c
> > index 8fa12e5..3808ea0 100644
> > --- a/drivers/cpufreq/mediatek-cpufreq-hw.c
> > +++ b/drivers/cpufreq/mediatek-cpufreq-hw.c
> > @@ -5,6 +5,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -17,9 +18,10 @@
> > #define LUT_ROW_SIZE 0x4
> >
> > enum {
> > - REG_LUT_TABLE,
> > - REG_ENABLE,
> > - REG_PERF_STATE,
> > + REG_FREQ_LUT_TABLE,
> > + REG_FREQ_ENABLE,
> > + REG_FREQ_PERF_STATE,
> > + REG_EM_POWER_TBL,
> >
> > REG_ARRAY_SIZE,
> > };
> > @@ -27,23 +29,44 @@ enum {
> > struct cpufreq_mtk {
> > struct cpufreq_frequency_table *table;
> > void __iomem *reg_bases[REG_ARRAY_SIZE];
> > + int nr_opp;
> > cpumask_t related_cpus;
> > };
> >
> > static const u16 cpufreq_mtk_offsets[REG_ARRAY_SIZE] = {
> > - [REG_LUT_TABLE] = 0x0,
> > - [REG_ENABLE]= 0x84,
> > - [REG_PERF_STATE]= 0x88,
> > + [REG_FREQ_LUT_TABLE]= 0x0,
> > + [REG_FREQ_ENABLE] = 0x84,
> > + [REG_FREQ_PERF_STATE] = 0x88,
> > + [REG_EM_POWER_TBL] = 0x3D0,
> > };
> >
> > static struct cpufreq_mtk *mtk_freq_domain_map[NR_CPUS];
> >
> > +static int mtk_cpufreq_get_cpu_power(unsigned long *mW,
> > +unsigned long *KHz, int cpu)
> > +{
> > + struct cpufreq_mtk *c = mtk_freq_domain_map[cpu];
> > + int i;
> > +
> > + for (i = 0; i < c->nr_opp; i++) {
> > + if (c->table[i].frequency < *KHz)
> > + break;
> > + }
> > + i--;
> > +
> > + *KHz = c->table[i].frequency;
> > + *mW = readl_relaxed(c->reg_bases[REG_EM_POWER_TBL] +
> > + i * LUT_ROW_SIZE) / 1000;
> > +
> > + return 0;
> > +}
> > +
> > static int mtk_cpufreq_hw_target_index(struct cpufreq_policy *policy,
> >unsigned int index)
> > {
> > struct cpufreq_mtk *c = policy->driver_data;
> >
> > - writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
> > + writel_relaxed(index, c->reg_bases[REG_FREQ_PERF_STATE]);
> >
> > return 0;
> > }
> > @@ -55,7 +78,7 @@ static unsigned int mtk_cpufreq_hw_get(unsigned int cpu)
> >
> > c = mtk_freq_domain_map[cpu];
> >
> > - index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
> > + index = readl_relaxed(c->reg_bases[REG_FREQ_PERF_STATE]);
> > index = min(index, LUT_MAX_ENTRIES - 1);
> >
> > return c->table[index].frequency;
> > @@ -64,6 +87,7 @@ static unsigned int mtk_cpufreq_hw_get(unsigned int cpu)
> > static int mtk_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
> > {
> > struct cpufreq_mtk *c;
> > + struct em_data_callback em_cb = EM_DATA_CB(mtk_cpufreq_get_cpu_power);
> >
> > c = mtk_freq_domain_map[policy->cpu];
> > if (!c) {
> > @@ -77,7 +101,8 @@ static int mtk_cpufreq_hw_cpu_init(struct cpufreq_policy
> > *policy)
> > policy->driver_data = c;
> >
> > /* HW should be in enabled state to proceed now */
> > - writel_relaxed(0x1, c->reg_bases[REG_ENABLE]);
> > + writel_relaxed(0x1, c->reg_bases[REG_FREQ_ENABLE]);
> > + em_register_perf_domain(policy->cpus, c->nr_opp, _cb);
>
>
> The function name has changed recently (v5.9-rc1) to:
> em_dev_register_perf_domain()
>
> Please check your base kernel tree and update.
>
> Regards,
> Lukasz
>
OK, will check my base kernel and update this.
Thank you.
Re: [PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled
On Fri, Oct 9, 2020 at 1:13 AM Hans Verkuil wrote: > > On 08/10/2020 16:02, Alexandre Courbot wrote: > > Hi Hans, thanks for taking the time to look at this! > > > > On Thu, Oct 8, 2020 at 10:12 PM Hans Verkuil > > wrote: > >> > >> On 08/10/2020 15:07, Hans Verkuil wrote: > >>> Hi Alexandre, > >>> > >>> On 04/10/2020 14:22, Alexandre Courbot wrote: > The addition of MT8183 support added a dependency on the SCP remoteproc > module. However the initial patch used the "select" Kconfig directive, > which may result in the SCP module to not be compiled if remoteproc was > disabled. In such a case, mtk-vcodec would try to link against > non-existent SCP symbols. "select" was clearly misused here as explained > in kconfig-language.txt. > > Replace this by a "depends" directive on at least one of the VPU and > SCP modules, to allow the driver to be compiled as long as one of these > is enabled, and adapt the code to support this new scenario. > > Also adapt the Kconfig text to explain the extra requirements for MT8173 > and MT8183. > > Reported-by: Sakari Ailus > Signed-off-by: Alexandre Courbot > Acked-by: Randy Dunlap # build-tested > --- > drivers/media/platform/Kconfig| 10 +-- > .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 72 --- > 2 files changed, 54 insertions(+), 28 deletions(-) > > diff --git a/drivers/media/platform/Kconfig > b/drivers/media/platform/Kconfig > index a3cb104956d5..98eb62e49ec2 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -253,14 +253,16 @@ config VIDEO_MEDIATEK_VCODEC > depends on MTK_IOMMU || COMPILE_TEST > depends on VIDEO_DEV && VIDEO_V4L2 > depends on ARCH_MEDIATEK || COMPILE_TEST > +depends on VIDEO_MEDIATEK_VPU || MTK_SCP > >>> > >>> Close, but no cigar. > >>> > >>> If VIDEO_MEDIATEK_VPU=y and MTK_SCP=m, then VIDEO_MEDIATEK_VCODEC can be > >>> configured > >>> to y, and then it won't be able to find the scp_ functions. > >>> > >>> To be honest, I'm not sure how to solve this. > >> > >> Found it. Add this: > >> > >> depends on MTK_SCP || !MTK_SCP > >> depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU > >> > >> Ugly as hell, but it appears to be the correct incantation for this. > > > > But doesn't it mean that the driver can be compiled if !MTK_SCP and > > !VIDEO_MEDIATEK_VPU? That's the one case we want to avoid. > > No, because you still have: > > depends on VIDEO_MEDIATEK_VPU || MTK_SCP > > So at least one of these must be set. > > Just try it :-) Aha, I misread your message and thought you suggested replacing the dependencies with these two lines. In this case it would certainly work! Thanks for the suggestion, I'll send a v3 soon. > > Regards, > > Hans
Re: [PATCH] irqbypass: fix error handle when irq_bypass_register_producer() return fails
Alex Williamson 于2020年9月30日周三 下午10:09写道：
>
>
> Please version your postings so we know which one to consider as the
> current proposal.
>
> On Wed, 30 Sep 2020 20:54:39 +0800
> guomin_c...@sina.com wrote:
>
> > From: guomin chen
> >
> > When the producer object registration fails,In the future, due to
> > incorrect matching when unregistering, list_del(>node)
> > may still be called, then trigger a BUG:
> >
> > vfio-pci :db:00.0: irq bypass producer (token 60c8cda5)
> > registration fails: -16
> > vfio-pci :db:00.0: irq bypass producer (token 60c8cda5)
> > registration fails: -16
> > vfio-pci :db:00.0: irq bypass producer (token 60c8cda5)
> > registration fails: -16
> > ...
> > list_del corruption, 8f7fb8ba0828->next is LIST_POISON1
> > (dead0100)
> > [ cut here ]
> > kernel BUG at lib/list_debug.c:47!
> > invalid opcode: [#1] SMP NOPTI
> > CPU: 29 PID: 3914 Comm: qemu-kvm Kdump: loaded Tainted: G E
> > - -4.18.0-193.6.3.el8.x86_64 #1
> > Hardware name: Lenovo ThinkSystem SR650 -[7X06CTO1WW]-/-[7X06CTO1WW]-,
> > BIOS -[IVE636Z-2.13]- 07/18/2019
> > RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c
> > Code: ce ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 40 85 4d 88 e8 8c bc
> > ce ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 d0 85 4d 88 e8 78 bc
> > ce ff <0f> 0b 48 c7 c7 80 86 4d 88 e8 6a bc ce ff 0f 0b 48
> > 89 f2 48 89 fe
> > RSP: 0018:aa9d60197d20 EFLAGS: 00010246
> > RAX: 004e RBX: 8f7fb8ba0828 RCX:
> > RDX: RSI: 8f7fbf4d6a08 RDI: 8f7fbf4d6a08
> > RBP: R08: 084b R09: 005d
> > R10: R11: aa9d60197bd0 R12: 8f4fbe863000
> > R13: 00c2 R14: R15:
> > FS: 7f7cb97fa700() GS:8f7fbf4c()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 7fcf31da4000 CR3: 005f6d404001 CR4: 007626e0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > PKRU: 5554
> > Call Trace:
> > irq_bypass_unregister_producer+0x9b/0xf0 [irqbypass]
> > vfio_msi_set_vector_signal+0x8c/0x290 [vfio_pci]
> > ? load_fixmap_gdt+0x22/0x30
> > vfio_msi_set_block+0x6e/0xd0 [vfio_pci]
> > vfio_pci_ioctl+0x218/0xbe0 [vfio_pci]
> > ? kvm_vcpu_ioctl+0xf2/0x5f0 [kvm]
> > do_vfs_ioctl+0xa4/0x630
> > ? syscall_trace_enter+0x1d3/0x2c0
> > ksys_ioctl+0x60/0x90
> > __x64_sys_ioctl+0x16/0x20
> > do_syscall_64+0x5b/0x1a0
> > entry_SYSCALL_64_after_hwframe+0x65/0xca
> >
> > Cc: Alex Williamson
> > Cc: Cornelia Huck
> > Cc: Jiang Yi
> > Cc: Marc Zyngier
> > Cc: Peter Xu
> > Cc: Eric Auger
> > Cc: "Michael S. Tsirkin"
> > Cc: Jason Wang
> > Cc: k...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: guomin chen
> > ---
> > drivers/vfio/pci/vfio_pci_intrs.c | 13 +++--
> > drivers/vhost/vdpa.c | 7 +++
> > 2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
> > b/drivers/vfio/pci/vfio_pci_intrs.c
> > index 1d9fb25..c371943 100644
> > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > @@ -352,12 +352,21 @@ static int vfio_msi_set_vector_signal(struct
> > vfio_pci_device *vdev,
> > vdev->ctx[vector].producer.token = trigger;
> > vdev->ctx[vector].producer.irq = irq;
> > ret = irq_bypass_register_producer(>ctx[vector].producer);
> > - if (unlikely(ret))
> > + if (unlikely(ret)) {
> > dev_info(>dev,
> > "irq bypass producer (token %p) registration fails: %d\n",
> > vdev->ctx[vector].producer.token, ret);
> >
> > - vdev->ctx[vector].trigger = trigger;
> > + kfree(vdev->ctx[vector].name);
> > + eventfd_ctx_put(trigger);
> > +
> > + cmd = vfio_pci_memory_lock_and_enable(vdev);
> > + free_irq(irq, trigger);
> > + vfio_pci_memory_unlock_and_restore(vdev, cmd);
> > +
> > + vdev->ctx[vector].trigger = NULL;
> > + } else
> > + vdev->ctx[vector].trigger = trigger;
> >
> > return 0;
> > }
>
> Once again, the irq bypass registration cannot cause the vector setup
> to fail, either by returning an error code or failing to configure the
> vector while returning success. It's my assertion that we simply need
> to set the producer.token to NULL on failure such that unregistering
> the producer will not generate a match, as you've done below. The
> vector still works even if this registration fails.
>
Yes, the irq bypass
[git pull] drm amdgpu fixes for 5.9 final
Hi Linus, Fixes trickling in this week, Alex had a final fix for the newest GPU they introduced in rc1, along with one build regression and one crasher fix. Cross my fingers that's it for 5.9. Dave. drm-fixes-2020-10-09: drm amdgpu fixes for 5.9 final amdgpu: - Fix a crash on renoir if you override the IP discovery parameter - Fix the build on ARC platforms - Display fix for Sienna Cichlid The following changes since commit d10285a25e29f13353bbf7760be8980048c1ef2f: drm/nouveau/mem: guard against NULL pointer access in mem_del (2020-10-07 15:33:09 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-09 for you to fetch changes up to dded93ffbb8c4a578adf13b54cd62519908a23f8: Merge tag 'amd-drm-fixes-5.9-2020-10-08' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-10-09 13:02:49 +1000) drm amdgpu fixes for 5.9 final amdgpu: - Fix a crash on renoir if you override the IP discovery parameter - Fix the build on ARC platforms - Display fix for Sienna Cichlid Alex Deucher (1): drm/amdgpu/swsmu: fix ARC build errors Dave Airlie (1): Merge tag 'amd-drm-fixes-5.9-2020-10-08' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Dirk Gouders (1): drm/amdgpu: fix NULL pointer dereference for Renoir Yongqiang Sun (1): drm/amd/display: Change ABM config init interface drivers/gpu/drm/amd/amdgpu/soc15.c| 10 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- .../gpu/drm/amd/display/modules/power/power_helpers.c | 19 +++ .../gpu/drm/amd/display/modules/power/power_helpers.h | 4 +++- drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 14 -- drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c| 14 -- 6 files changed, 48 insertions(+), 15 deletions(-)
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (perf) failed
like this:
In file included from tools/include/linux/build_bug.h:5,
from tools/include/linux/kernel.h:8,
from util/intel-pt-decoder/intel-pt-insn-decoder.c:7:
util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function
'__insn_get_emulate_prefix':
tools/include/linux/compiler.h:37:38: error: nested extern declaration of
'__compiletime_assert_0' [-Werror=nested-externs]
37 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
tools/include/linux/compiler.h:16:15: note: in definition of macro
'__compiletime_assert'
16 | extern void prefix ## suffix(void) __compiletime_error(msg); \
| ^~
tools/include/linux/compiler.h:37:2: note: in expansion of macro
'_compiletime_assert'
37 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~
tools/include/linux/build_bug.h:39:37: note: in expansion of macro
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
tools/include/linux/build_bug.h:59:21: note: in expansion of macro
'BUILD_BUG_ON_MSG'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:27:3: note: in expansion of
macro 'BUILD_BUG'
27 | BUILD_BUG(); break; \
| ^
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:40:41: note: in expansion of
macro 'leXX_to_cpu'
40 | ({ t r = *(t*)((insn)->next_byte + n); leXX_to_cpu(t, r); })
| ^~~
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:46:61: note: in expansion of
macro '__peek_nbyte_next'
46 | ({ if (unlikely(!validate_next(t, insn, n))) goto err_out;
__peek_nbyte_next(t, insn, n); })
|
^
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:86:7: note: in expansion of
macro 'peek_nbyte_next'
86 | if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i])
| ^~~
Caused by commit
2a522b53c470 ("x86/insn: Support big endian cross-compiles")
I have reverted commits
a23b701ae9b3 objtool: Rework header include paths
1b4998c364bc objtool: Fix x86 orc generation on big endian cross compiles
317664a7fcc9 objtool: Fix reloc generation on big endian cross compiles
2a522b53c470 x86/insn: Support big endian cross-compiles
2486baae2cf6 objtool: Allow nested externs to enable BUILD_BUG()
for today.
This is a PowerPC LE native build of tools/perf.
--
Cheers,
Stephen Rothwell
pgpW4NysEpBgh.pgp
Description: OpenPGP digital signature
[PATCH] spi: imx: Revert "spi: imx: enable runtime pm support"
This reverts commit 525c9e5a32bd7951eae3f06d9d077fea51718a6c.
If CONFIG_PM is disabled, the system completely freezes on probe as
nothing enables the clock of the SPI peripheral.
Signed-off-by: Christian Eggers
---
drivers/spi/spi-imx.c | 121 --
1 file changed, 33 insertions(+), 88 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 38a5f1304cec..fdc25f549378 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -13,9 +13,7 @@
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
@@ -32,8 +30,6 @@ static bool use_dma = true;
module_param(use_dma, bool, 0644);
MODULE_PARM_DESC(use_dma, "Enable usage of DMA when available (default)");
-#define MXC_RPM_TIMEOUT2000 /* 2000ms */
-
#define MXC_CSPIRXDATA 0x00
#define MXC_CSPITXDATA 0x04
#define MXC_CSPICTRL 0x08
@@ -1534,16 +1530,20 @@ spi_imx_prepare_message(struct spi_master *master,
struct spi_message *msg)
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
int ret;
- ret = pm_runtime_get_sync(spi_imx->dev);
- if (ret < 0) {
- dev_err(spi_imx->dev, "failed to enable clock\n");
+ ret = clk_enable(spi_imx->clk_per);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(spi_imx->clk_ipg);
+ if (ret) {
+ clk_disable(spi_imx->clk_per);
return ret;
}
ret = spi_imx->devtype_data->prepare_message(spi_imx, msg);
if (ret) {
- pm_runtime_mark_last_busy(spi_imx->dev);
- pm_runtime_put_autosuspend(spi_imx->dev);
+ clk_disable(spi_imx->clk_ipg);
+ clk_disable(spi_imx->clk_per);
}
return ret;
@@ -1554,8 +1554,8 @@ spi_imx_unprepare_message(struct spi_master *master,
struct spi_message *msg)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
- pm_runtime_mark_last_busy(spi_imx->dev);
- pm_runtime_put_autosuspend(spi_imx->dev);
+ clk_disable(spi_imx->clk_ipg);
+ clk_disable(spi_imx->clk_per);
return 0;
}
@@ -1674,15 +1674,13 @@ static int spi_imx_probe(struct platform_device *pdev)
goto out_master_put;
}
- pm_runtime_enable(spi_imx->dev);
- pm_runtime_set_autosuspend_delay(spi_imx->dev, MXC_RPM_TIMEOUT);
- pm_runtime_use_autosuspend(spi_imx->dev);
+ ret = clk_prepare_enable(spi_imx->clk_per);
+ if (ret)
+ goto out_master_put;
- ret = pm_runtime_get_sync(spi_imx->dev);
- if (ret < 0) {
- dev_err(spi_imx->dev, "failed to enable clock\n");
- goto out_runtime_pm_put;
- }
+ ret = clk_prepare_enable(spi_imx->clk_ipg);
+ if (ret)
+ goto out_put_per;
spi_imx->spi_clk = clk_get_rate(spi_imx->clk_per);
/*
@@ -1692,7 +1690,7 @@ static int spi_imx_probe(struct platform_device *pdev)
if (spi_imx->devtype_data->has_dmamode) {
ret = spi_imx_sdma_init(>dev, spi_imx, master);
if (ret == -EPROBE_DEFER)
- goto out_runtime_pm_put;
+ goto out_clk_put;
if (ret < 0)
dev_err(>dev, "dma setup error %d, use pio\n",
@@ -1707,20 +1705,19 @@ static int spi_imx_probe(struct platform_device *pdev)
ret = spi_bitbang_start(_imx->bitbang);
if (ret) {
dev_err(>dev, "bitbang start failed with %d\n", ret);
- goto out_runtime_pm_put;
+ goto out_clk_put;
}
dev_info(>dev, "probed\n");
- pm_runtime_mark_last_busy(spi_imx->dev);
- pm_runtime_put_autosuspend(spi_imx->dev);
-
+ clk_disable(spi_imx->clk_ipg);
+ clk_disable(spi_imx->clk_per);
return ret;
-out_runtime_pm_put:
- pm_runtime_dont_use_autosuspend(spi_imx->dev);
- pm_runtime_put_sync(spi_imx->dev);
- pm_runtime_disable(spi_imx->dev);
+out_clk_put:
+ clk_disable_unprepare(spi_imx->clk_ipg);
+out_put_per:
+ clk_disable_unprepare(spi_imx->clk_per);
out_master_put:
spi_master_put(master);
@@ -1735,82 +1732,30 @@ static int spi_imx_remove(struct platform_device *pdev)
spi_bitbang_stop(_imx->bitbang);
- ret = pm_runtime_get_sync(spi_imx->dev);
- if (ret < 0) {
- dev_err(spi_imx->dev, "failed to enable clock\n");
- return ret;
- }
-
- writel(0, spi_imx->base + MXC_CSPICTRL);
-
- pm_runtime_dont_use_autosuspend(spi_imx->dev);
- pm_runtime_put_sync(spi_imx->dev);
- pm_runtime_disable(spi_imx->dev);
-
- spi_imx_sdma_exit(spi_imx);
- spi_master_put(master);
-
- return 0;
-}
-
-static int __maybe_unused spi_imx_runtime_resume(struct device *dev)
-{
- struct spi_master *master =
Re: linux-next: Fixes tag needs some work in the powerpc tree
Stephen Rothwell writes:
> Hi all,
>
> In commit
>
> a2d0230b91f7 ("cpufreq: powernv: Fix frame-size-overflow in
> powernv_cpufreq_reboot_notifier")
>
> Fixes tag
>
> Fixes: cf30af76 ("cpufreq: powernv: Set the cpus to nominal frequency
> during reboot/kexec")
Gah.
I've changed my scripts to make this a hard error when I'm applying
patches.
cheers
Re: [PATCH] MAINTAINERS: Update entry for st7703 driver after the rename
On Wed, 1 Jul 2020, Ondrej Jirman wrote: > The driver was renamed, change the path in the MAINTAINERS file. > > Signed-off-by: Ondrej Jirman This minor non-urgent cleanup patch has not been picked up yet by anyone. Hence, ./scripts/get_maintainers.pl --self-test=patterns continues to complain: warning: no file matches F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt warning: no file matches F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c This patch cleanly applies on next-20201008 and resolves the issue above. Reviewed-by: Lukas Bulwahn Lukas > --- > MAINTAINERS | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5f186a661a9b..f5183eae08df 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5487,12 +5487,13 @@ S:Maintained > F: Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml > F: drivers/gpu/drm/panel/panel-raydium-rm67191.c > > -DRM DRIVER FOR ROCKTECH JH057N00900 PANELS > +DRM DRIVER FOR SITRONIX ST7703 PANELS > M: Guido Günther > R: Purism Kernel Team > +R: Ondrej Jirman > S: Maintained > -F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > -F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c > +F: > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +F: drivers/gpu/drm/panel/panel-sitronix-st7703.c > > DRM DRIVER FOR SAVAGE VIDEO CARDS > S: Orphan / Obsolete > -- > 2.27.0 > >
[tip:perf/core] BUILD SUCCESS 84ad70320241566e028ada955c694ab92f3351e3
xway_defconfig sh ul2_defconfig sh lboxre2_defconfig arm davinci_all_defconfig powerpc allyesconfig mips decstation_64_defconfig powerpc kmeter1_defconfig powerpc obs600_defconfig mips capcella_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig arc allyesconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20201008 x86_64 randconfig-a003-20201008 x86_64 randconfig-a005-20201008 x86_64 randconfig-a001-20201008 x86_64 randconfig-a002-20201008 x86_64 randconfig-a006-20201008 i386 randconfig-a006-20201008 i386 randconfig-a005-20201008 i386 randconfig-a001-20201008 i386 randconfig-a004-20201008 i386 randconfig-a002-20201008 i386 randconfig-a003-20201008 i386 randconfig-a006-20201009 i386 randconfig-a005-20201009 i386 randconfig-a001-20201009 i386 randconfig-a004-20201009 i386 randconfig-a002-20201009 i386 randconfig-a003-20201009 x86_64 randconfig-a012-20201009 x86_64 randconfig-a015-20201009 x86_64 randconfig-a013-20201009 x86_64 randconfig-a014-20201009 x86_64 randconfig-a011-20201009 x86_64 randconfig-a016-20201009 i386 randconfig-a015-20201009 i386 randconfig-a013-20201009 i386 randconfig-a014-20201009 i386 randconfig-a016-20201009 i386 randconfig-a011-20201009 i386 randconfig-a012-20201009 i386 randconfig-a015-20201008 i386 randconfig-a013-20201008 i386 randconfig-a014-20201008 i386 randconfig-a016-20201008 i386 randconfig-a011-20201008 i386 randconfig-a012-20201008 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 kexec x86_64 rhel-8.3 clang tested configs: x86_64 randconfig-a012-20201008 x86_64 randconfig-a015-20201008 x86_64 randconfig-a013-20201008 x86_64 randconfig-a014-20201008 x86_64 randconfig-a011-20201008 x86_64 randconfig-a016-20201008 x86_64 randconfig-a004-20201009 x86_64 randconfig-a003-20201009 x86_64 randconfig-a005-20201009 x86_64 randconfig-a001-20201009 x86_64 randconfig-a002-20201009 x86_64 randconfig-a006-20201009 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH] mm: mmap: Fix general protection fault in unlink_file_vma()
On Thu, 8 Oct 2020 07:17:18 + linmiaohe wrote:
> Andrew Morton wrote:
> > On Wed, 16 Sep 2020 05:07:33 -0400 Miaohe Lin wrote:
> >
> >> The syzbot reported the below general protection fault:
> >>
> >> general protection fault, probably for non-canonical address
> >> 0xe00eeaee003b: [#1] PREEMPT SMP KASAN
> >> KASAN: maybe wild-memory-access in range
> >> [0x007001d8-0x007001df]
> >> CPU: 1 PID: 10488 Comm: syz-executor721 Not tainted
> >> 5.9.0-rc3-syzkaller #0
> >> Trace:
> >> free_pgtables+0x1b3/0x2f0 mm/memory.c:415
> >> exit_mmap+0x2c0/0x530 mm/mmap.c:3184
> >> __mmput+0x122/0x470 kernel/fork.c:1076
> >>
> >> It's because the ->mmap() callback can change vma->vm_file and fput
> >> the original file. But the commit d70cec898324 ("mm: mmap: merge vma
> >> after
> >> call_mmap() if possible") failed to catch this case and always fput()
> >> the original file, hence add an extra fput().
> >>
>
> ...
>
> >
> >is this using the correct file? I think it is, but please do check.
> >
>
> Many thanks for your reply.
>
> Yes, I think so too. We do deny_write_access and mapping_map_writable on
> @file, so we should undo all of this on @file.
> Since @file is unchanged over the second vma_merge() time, we'are using the
> correct @file to undo our temporary denial count.
>
> But how should I check this explicitly ? I can't find out a way to do this.
> Could you please figure it out for me?
I meant "please check (review) the code as it now is", not "please add
a check" ;)
Re: [PATCH v2 0/4] mailbox: arm_mhu: Add ARM MHU doorbell controller driver
On 08-10-20, 20:14, Sudeep Holla wrote: > Hi, > > These series adds ARM MHU doorbell controller driver based on the > discussion[1]. The DT patches are just repost from Viresh's last posting[2] > > Regards, > Sudeep > > v1[3]->v2: > - No updates to binding patches(1-2) > - Fixed memory leak and improved logic to find free channel reusing > mhu_db_mbox_to_channel as suggested by Jassi > > [1] https://lore.kernel.org/r/20200909044618.deyx37pzocxiga7u@vireshk-i7 > [2] > https://lore.kernel.org/r/3874de094d193a08624a00a35067a3237e0b42b1.1600249102.git.viresh.ku...@linaro.org > [3] https://lore.kernel.org/r/20200928114445.19689-1-sudeep.ho...@arm.com > > Sudeep Holla (3): > dt-bindings: mailbox: add doorbell support to ARM MHU > mailbox: arm_mhu: Match only if compatible is "arm,mhu" > mailbox: arm_mhu: Add ARM MHU doorbell driver > > Viresh Kumar (1): > dt-bindings: mailbox : arm,mhu: Convert to Json-schema > > .../devicetree/bindings/mailbox/arm,mhu.yaml | 135 +++ > .../devicetree/bindings/mailbox/arm-mhu.txt | 43 --- > drivers/mailbox/Makefile | 2 +- > drivers/mailbox/arm_mhu.c | 3 + > drivers/mailbox/arm_mhu_db.c | 354 ++ > 5 files changed, 493 insertions(+), 44 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhu.yaml > delete mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt > create mode 100644 drivers/mailbox/arm_mhu_db.c MAINTAINERS ? -- viresh
Re: [PATCH v1 1/1] cpufreq: mediatek-hw: Register EM power table
On 08-10-20, 20:13, Hector Yuan wrote: > From: "Hector.Yuan" > > Register CPU power table to energy model framework > > Signed-off-by: Hector.Yuan > --- > drivers/cpufreq/mediatek-cpufreq-hw.c | 50 > + > 1 file changed, 38 insertions(+), 12 deletions(-) I don't see this file in mainline. What am I missing ? -- viresh
Re: [PATCH 5/5] dmaengine: owl-dma: fix kernel-doc style for enum
On 08-10-20, 19:34, Manivannan Sadhasivam wrote: > On Wed, Oct 07, 2020 at 02:01:13PM +0530, Vinod Koul wrote: > > Driver doesn't use keyword enum for enum owl_dmadesc_offsets resulting > > in warning: > > > > drivers/dma/owl-dma.c:139: warning: cannot understand function prototype: > > 'enum owl_dmadesc_offsets ' > > > > So add the keyword to fix it and also add documentation for missing > > OWL_DMADESC_SIZE > > > > Do we really need to document the max value? Does it produce any warning? It does.. Once you add the enum, it will treat is as such and look at members and complain that the OWL_DMADESC_SIZE is not documented ;) -- ~Vinod
Re: [PATCH] module: statically initialize init section freeing data
On Thu, Oct 08, 2020 at 01:32:20PM -0400, Daniel Jordan wrote:
> Corentin hit the following workqueue warning when running with
> CRYPTO_MANAGER_EXTRA_TESTS:
>
> WARNING: CPU: 2 PID: 147 at kernel/workqueue.c:1473 __queue_work+0x3b8/0x3d0
> Modules linked in: ghash_generic
> CPU: 2 PID: 147 Comm: modprobe Not tainted
> 5.6.0-rc1-next-20200214-00068-g166c9264f0b1-dirty #545
> Hardware name: Pine H64 model A (DT)
> pc : __queue_work+0x3b8/0x3d0
> Call trace:
>__queue_work+0x3b8/0x3d0
>queue_work_on+0x6c/0x90
>do_init_module+0x188/0x1f0
>load_module+0x1d00/0x22b0
>
> I wasn't able to reproduce on x86 or rpi 3b+.
>
> This is
>
> WARN_ON(!list_empty(>entry))
>
> from __queue_work(), and it happens because the init_free_wq work item
> isn't initialized in time for a crypto test that requests the gcm
> module. Some crypto tests were recently moved earlier in boot as
> explained in commit c4741b230597 ("crypto: run initcalls for generic
> implementations earlier"), which went into mainline less than two weeks
> before the Fixes commit.
>
> Avoid the warning by statically initializing init_free_wq and the
> corresponding llist.
>
> Link: https://lore.kernel.org/lkml/20200217204803.GA13479@Red/
> Fixes: 1a7b7d922081 ("modules: Use vmalloc special flag")
> Reported-by: Corentin Labbe
> Tested-by: Corentin Labbe
> Tested-on: sun50i-h6-pine-h64
> Tested-on: imx8mn-ddr4-evk
> Tested-on: sun50i-a64-bananapi-m64
> Signed-off-by: Daniel Jordan
Looks good,
Reviewed-by: Eric Biggers
[PATCH] MAINTAINERS: rectify ZR36067 VIDEO FOR LINUX DRIVER section
Commit 754f0f1ba8d9 ("media: MAINTAINERS: change maintainer of the zoran
driver") added a new section in MAINTAINERS with an invalid file entry
and at the wrong place for alphabetic ordering.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: Documentation/media/v4l-drivers/zoran.rst
Point the file entry to the right location and move the section to the
right place in MAINTAINERS.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20201008
Corentin, please ack.
Mauro, please pick this minor non-urgent cleanup patch into your -next tree.
MAINTAINERS | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 239ae2425cf8..6879ca545677 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19412,6 +19412,13 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs.git
F: Documentation/filesystems/zonefs.rst
F: fs/zonefs/
+ZPOOL COMPRESSED PAGE STORAGE API
+M: Dan Streetman
+L: linux...@kvack.org
+S: Maintained
+F: include/linux/zpool.h
+F: mm/zpool.c
+
ZR36067 VIDEO FOR LINUX DRIVER
M: Corentin Labbe
L: mjpeg-us...@lists.sourceforge.net
@@ -19419,16 +19426,9 @@ L: linux-me...@vger.kernel.org
S: Maintained
W: http://mjpeg.sourceforge.net/driver-zoran/
Q: https://patchwork.linuxtv.org/project/linux-media/list/
-F: Documentation/media/v4l-drivers/zoran.rst
+F: Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
F: drivers/staging/media/zoran/
-ZPOOL COMPRESSED PAGE STORAGE API
-M: Dan Streetman
-L: linux...@kvack.org
-S: Maintained
-F: include/linux/zpool.h
-F: mm/zpool.c
-
ZRAM COMPRESSED RAM BLOCK DEVICE DRVIER
M: Minchan Kim
M: Nitin Gupta
--
2.17.1
Re: [External] Re: [RFC PATCH 00/24] mm/hugetlb: Free some vmemmap pages of hugetlb page
On Thu, Oct 8, 2020 at 5:15 AM Mike Kravetz wrote: > > On 9/29/20 2:58 PM, Mike Kravetz wrote: > > On 9/15/20 5:59 AM, Muchun Song wrote: > >> Hi all, > >> > >> This patch series will free some vmemmap pages(struct page structures) > >> associated with each hugetlbpage when preallocated to save memory. > > ... > >> The mapping of the first page(index 0) and the second page(index 1) is > >> unchanged. The remaining 6 pages are all mapped to the same page(index > >> 1). So we only need 2 pages for vmemmap area and free 6 pages to the > >> buddy system to save memory. Why we can do this? Because the content > >> of the remaining 7 pages are usually same except the first page. > >> > >> When a hugetlbpage is freed to the buddy system, we should allocate 6 > >> pages for vmemmap pages and restore the previous mapping relationship. > >> > >> If we uses the 1G hugetlbpage, we can save 4095 pages. This is a very > >> substantial gain. On our server, run some SPDK applications which will > >> use 300GB hugetlbpage. With this feature enabled, we can save 4797MB > >> memory. > > I had a hard time going through the patch series as it is currently > structured, and instead examined all the code together. Muchun put in > much effort and the code does reduce memory usage. > - For 2MB hugetlb pages, we save 5 pages of struct pages > - For 1GB hugetlb pages, we save 4086 pages of struct pages > > Code is even in pace to handle poisoned pages, although I have not looked > at this closely. The code survives the libhugetlbfs and ltp huge page tests. > > To date, nobody has asked the important question "Is the added complexity > worth the memory savings?". I suppose it all depends on one's use case. > Obviously, the savings are more significant when one uses 1G huge pages but > that may not be the common case today. > > > At a high level this seems like a reasonable optimization for hugetlb > > pages. It is possible because hugetlb pages are 'special' and mostly > > handled differently than pages in normal mm paths. > > Such an optimization only makes sense for something like hugetlb pages. One > reason is the 'special' nature of hugetlbfs as stated above. The other is > that this optimization mostly makes sense for huge pages that are created > once and stick around for a long time. hugetlb pool pages are a perfect > example. This is because manipulation of struct page mappings is done when > a huge page is created or destroyed. Yeah, in our cloud server, we have some application scenarios(e.g. SPDK, DPDK, QEMU and jemalloc). These applications may use a lot of hugetlb pages. > > > The majority of the new code is hugetlb specific, so it should not be > > of too much concern for the general mm code paths. > > It is true that much of the code in this series was put in hugetlb.c. > However, > I would argue that there is a bunch of code that only deals with remapping > the memmap which should more generic and added to sparse-vmemmap.c. This > would at least allow for easier reuse. I agree with you. > > Before Muchun and myself put more effort into this series, I would really > like to get feedback on the whether or not this should move forward. > Specifically, is the memory savings worth added complexity? Is the removing > of struct pages going to come back and cause issues for future features? Some users do need this optimization to save memory. But if some users do not need this optimization, they also can disable it by using a kernel boot parameter 'hugetlb_free_vmemmap=off' or not configuring CONFIG_HUGETLB_PAGE_FREE_VMEMMAP. I have no idea about "cause issues for future features". Is there any feature ongoing or planned? -- Yours, Muchun
Re: [PATCH v1 1/1] PCI/ERR: don't clobber status after reset_link()
On Fri, Oct 09, 2020 at 05:09 Hedi Berriche wrote:
On Fri, Oct 09, 2020 at 04:46 Raj, Ashok wrote:
Hi Ashok,
Thanks for looking into this.
On Fri, Oct 09, 2020 at 03:52:51AM +0100, Hedi Berriche wrote:
Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
changed pcie_do_recovery() so that status is updated with the return
value from reset_link(); this was to fix the problem where we would
wrongly report recovery failure, despite a successful reset_link(),
whenever the initial error status is PCI_ERS_RESULT_DISCONNECT or
PCI_ERS_RESULT_NO_AER_DRIVER.
Unfortunately this breaks the flow of pcie_do_recovery() as it prevents
What is the reference to "this breaks" above?
The code change introduced by commit 6d2c89441571; would
"this code change" instead of "this breaks"
work better? If not, I can also rephrase the whole paragraph along the
following lines:
Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()") breaks
the flow
of pcie_do_recovery() as it prevents the actions needed when the initial error
is
PCI_ERS_RESULT_CAN_RECOVER or PCI_ERS_RESULT_NEED_RESET from taking place which
causes
error recovery to fail.
... and do away with the first paragraph.
the actions needed when the initial error is PCI_ERS_RESULT_CAN_RECOVER
or PCI_ERS_RESULT_NEED_RESET from taking place which causes error
recovery to fail.
Don't clobber status after reset_link() to restore the intended flow in
pcie_do_recovery().
Fix the original problem by saving the return value from reset_link()
and use it later on to decide whether error recovery should be deemed
successful in the scenarios where the initial error status is
PCI_ERS_RESULT_{DISCONNECT,NO_AER_DRIVER}.
I would rather rephrase the above to make it clear what is being proposed.
Since the description seems to talk about the old problem and new solution
all mixed up.
OK; will do that to clarify that what's being proposed here is:
1. fix the regression introduced by commit 6d2c89441571
2. address the problem that commit 6d2c89441571 aimed to fix
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Hedi Berriche
Cc: Russ Anderson
Cc: Kuppuswamy Sathyanarayanan
Cc: Bjorn Helgaas
Cc: Ashok Raj
Cc: Keith Busch
Cc: Joerg Roedel
Cc: sta...@kernel.org # v5.7+
---
drivers/pci/pcie/err.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index c543f419d8f9..dbd0b56bd6c1 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -150,7 +150,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_channel_state_t state,
pci_ers_result_t (*reset_link)(struct pci_dev *pdev))
{
- pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
+ pci_ers_result_t post_reset_status, status = PCI_ERS_RESULT_CAN_RECOVER;
why call it post_reset_status?
Perhaps post_reset_status is not a great choice; would reset_result or
reset_link_result be better?
... or just do this with a boolean instead as I had it in an earlier iteration
of the patch before I
eventually opted to use an pci_ers_result_t.
Cheers,
Hedi.
Cheers,
Hedi.
struct pci_bus *bus;
/*
@@ -165,8 +165,8 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, );
- status = reset_link(dev);
- if (status != PCI_ERS_RESULT_RECOVERED) {
+ post_reset_status = reset_link(dev);
+ if (post_reset_status != PCI_ERS_RESULT_RECOVERED) {
pci_warn(dev, "link reset failed\n");
goto failed;
}
@@ -174,6 +174,13 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_walk_bus(bus, report_normal_detected, );
}
+ if ((status == PCI_ERS_RESULT_DISCONNECT ||
+status == PCI_ERS_RESULT_NO_AER_DRIVER) &&
+post_reset_status == PCI_ERS_RESULT_RECOVERED) {
+ /* error recovery succeeded thanks to reset_link() */
+ status = PCI_ERS_RESULT_RECOVERED;
+ }
+
if (status == PCI_ERS_RESULT_CAN_RECOVER) {
status = PCI_ERS_RESULT_RECOVERED;
pci_dbg(dev, "broadcast mmio_enabled message\n");
--
2.28.0
--
Be careful of reading health books, you might die of a misprint.
-- Mark Twain
--
Be careful of reading health books, you might die of a misprint.
-- Mark Twain
Re: [PATCH v1 1/1] PCI/ERR: don't clobber status after reset_link()
On Fri, Oct 09, 2020 at 04:46 Raj, Ashok wrote:
Hi Ashok,
Thanks for looking into this.
On Fri, Oct 09, 2020 at 03:52:51AM +0100, Hedi Berriche wrote:
Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
changed pcie_do_recovery() so that status is updated with the return
value from reset_link(); this was to fix the problem where we would
wrongly report recovery failure, despite a successful reset_link(),
whenever the initial error status is PCI_ERS_RESULT_DISCONNECT or
PCI_ERS_RESULT_NO_AER_DRIVER.
Unfortunately this breaks the flow of pcie_do_recovery() as it prevents
What is the reference to "this breaks" above?
The code change introduced by commit 6d2c89441571; would
"this code change" instead of "this breaks"
work better? If not, I can also rephrase the whole paragraph along the
following lines:
Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()") breaks
the flow
of pcie_do_recovery() as it prevents the actions needed when the initial error
is
PCI_ERS_RESULT_CAN_RECOVER or PCI_ERS_RESULT_NEED_RESET from taking place which
causes
error recovery to fail.
... and do away with the first paragraph.
the actions needed when the initial error is PCI_ERS_RESULT_CAN_RECOVER
or PCI_ERS_RESULT_NEED_RESET from taking place which causes error
recovery to fail.
Don't clobber status after reset_link() to restore the intended flow in
pcie_do_recovery().
Fix the original problem by saving the return value from reset_link()
and use it later on to decide whether error recovery should be deemed
successful in the scenarios where the initial error status is
PCI_ERS_RESULT_{DISCONNECT,NO_AER_DRIVER}.
I would rather rephrase the above to make it clear what is being proposed.
Since the description seems to talk about the old problem and new solution
all mixed up.
OK; will do that to clarify that what's being proposed here is:
1. fix the regression introduced by commit 6d2c89441571
2. address the problem that commit 6d2c89441571 aimed to fix
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Hedi Berriche
Cc: Russ Anderson
Cc: Kuppuswamy Sathyanarayanan
Cc: Bjorn Helgaas
Cc: Ashok Raj
Cc: Keith Busch
Cc: Joerg Roedel
Cc: sta...@kernel.org # v5.7+
---
drivers/pci/pcie/err.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index c543f419d8f9..dbd0b56bd6c1 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -150,7 +150,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_channel_state_t state,
pci_ers_result_t (*reset_link)(struct pci_dev *pdev))
{
- pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
+ pci_ers_result_t post_reset_status, status = PCI_ERS_RESULT_CAN_RECOVER;
why call it post_reset_status?
Perhaps post_reset_status is not a great choice; would reset_result or
reset_link_result be better?
Cheers,
Hedi.
struct pci_bus *bus;
/*
@@ -165,8 +165,8 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, );
- status = reset_link(dev);
- if (status != PCI_ERS_RESULT_RECOVERED) {
+ post_reset_status = reset_link(dev);
+ if (post_reset_status != PCI_ERS_RESULT_RECOVERED) {
pci_warn(dev, "link reset failed\n");
goto failed;
}
@@ -174,6 +174,13 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_walk_bus(bus, report_normal_detected, );
}
+ if ((status == PCI_ERS_RESULT_DISCONNECT ||
+status == PCI_ERS_RESULT_NO_AER_DRIVER) &&
+post_reset_status == PCI_ERS_RESULT_RECOVERED) {
+ /* error recovery succeeded thanks to reset_link() */
+ status = PCI_ERS_RESULT_RECOVERED;
+ }
+
if (status == PCI_ERS_RESULT_CAN_RECOVER) {
status = PCI_ERS_RESULT_RECOVERED;
pci_dbg(dev, "broadcast mmio_enabled message\n");
--
2.28.0
--
Be careful of reading health books, you might die of a misprint.
-- Mark Twain
Re: general protection fault in percpu_ref_exit
On Thu, Oct 08, 2020 at 07:23:02PM -0600, Jens Axboe wrote:
> On 10/8/20 2:28 PM, syzbot wrote:
> > syzbot has bisected this issue to:
> >
> > commit 2b0d3d3e4fcfb19d10f9a82910b8f0f05c56ee3e
> > Author: Ming Lei
> > Date: Thu Oct 1 15:48:41 2020 +
> >
> > percpu_ref: reduce memory footprint of percpu_ref in fast path
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=126930d050
> > start commit: 8b787da7 Add linux-next specific files for 20201007
> > git tree: linux-next
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=116930d050
> > console output: https://syzkaller.appspot.com/x/log.txt?x=166930d050
> > kernel config: https://syzkaller.appspot.com/x/.config?x=aac055e9c8fbd2b8
> > dashboard link: https://syzkaller.appspot.com/bug?extid=fd15ff734dace9e16437
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119a056850
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=106c0a8b90
> >
> > Reported-by: syzbot+fd15ff734dace9e16...@syzkaller.appspotmail.com
> > Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in
> > fast path")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> Ming, this looks like a call of percpu_ref_exit() on a zeroed refs (that
> hasn't been initialized). Really a caller error imho, but might make sense
> to be a bit safer there.
Hello Jens,
The fix is sent out as:
https://lore.kernel.org/linux-block/20201009040356.43802-1-ming@redhat.com/T/#u
Sorry for making the trouble.
Thanks,
Ming
Re: [PATCH v2] vringh: fix __vringh_iov() when riov and wiov are different
On 2020/10/9 上午4:42, Stefano Garzarella wrote:
If riov and wiov are both defined and they point to different
objects, only riov is initialized. If the wiov is not initialized
by the caller, the function fails returning -EINVAL and printing
"Readable desc 0x... after writable" error message.
This issue happens when descriptors have both readable and writable
buffers (eg. virtio-blk devices has virtio_blk_outhdr in the readable
buffer and status as last byte of writable buffer) and we call
__vringh_iov() to get both type of buffers in two different iovecs.
Let's replace the 'else if' clause with 'if' to initialize both
riov and wiov if they are not NULL.
As checkpatch pointed out, we also avoid crashing the kernel
when riov and wiov are both NULL, replacing BUG() with WARN_ON()
and returning -EINVAL.
It looks like I met the exact similar issue when developing ctrl vq
support (which requires both READ and WRITE descriptor).
While I was trying to fix the issue I found the following comment:
* Note that you may need to clean up riov and wiov, even on error!
*/
int vringh_getdesc_iotlb(struct vringh *vrh,
I saw some driver call vringh_kiov_cleanup().
So I just follow to use that.
I'm not quite sure which one is better.
Thanks
Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.")
Cc: sta...@vger.kernel.org
Signed-off-by: Stefano Garzarella
---
drivers/vhost/vringh.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index e059a9a47cdf..8bd8b403f087 100644
--- a/drivers/vhost/vringh.c
+++ b/drivers/vhost/vringh.c
@@ -284,13 +284,14 @@ __vringh_iov(struct vringh *vrh, u16 i,
desc_max = vrh->vring.num;
up_next = -1;
+ /* You must want something! */
+ if (WARN_ON(!riov && !wiov))
+ return -EINVAL;
+
if (riov)
riov->i = riov->used = 0;
- else if (wiov)
+ if (wiov)
wiov->i = wiov->used = 0;
- else
- /* You must want something! */
- BUG();
for (;;) {
void *addr;
Re: [PATCH 0/6] KVM: x86: KVM_SET_SREGS.CR4 bug fixes and cleanup
On Thu, Oct 08, 2020 at 09:18:18PM +0300, stsp wrote: > 08.10.2020 20:59, Sean Christopherson пишет: > >On Thu, Oct 08, 2020 at 07:00:13PM +0300, stsp wrote: > >>07.10.2020 04:44, Sean Christopherson пишет: > >>>Two bug fixes to handle KVM_SET_SREGS without a preceding KVM_SET_CPUID2. > >>Hi Sean & KVM devs. > >> > >>I tested the patches, and wherever I > >>set VMXE in CR4, I now get > >>KVM: KVM_SET_SREGS: Invalid argument > >>Before the patch I was able (with many > >>problems, but still) to set VMXE sometimes. > >> > >>So its a NAK so far, waiting for an update. :) > >IIRC, you said you were going to test on AMD? Assuming that's correct, > > Yes, that is true. > > > > -EINVAL > >is the expected behavior. KVM was essentially lying before; it never > >actually > >set CR4.VMXE in hardware, it just didn't properply detect the error and so > >VMXE > >was set in KVM's shadow of the guest's CR4. > > Hmm. But at least it was lying > similarly on AMD and Intel CPUs. :) > So I was able to reproduce the problems > myself. > Do you mean, any AMD tests are now useless, and we need to proceed with Intel > tests only? For anything VMXE related, yes. > Then additional question. > On old Intel CPUs we needed to set VMXE in guest to make it to work in > nested-guest mode. > Is it still needed even with your patches? > Or the nested-guest mode will work now even on older Intel CPUs and KVM will > set VMXE for us itself, when needed? I'm struggling to even come up with a theory as to how setting VMXE from userspace would have impacted KVM with unrestricted_guest=n, let alone fixed anything. CR4.VMXE must always be 1 in _hardware_ when VMX is on, including when running the guest. But KVM forces vmcs.GUEST_CR4.VMXE=1 at all times, regardless of the guest's actual value (the guest sees a shadow value when it reads CR4). And unless I grossly misunderstand dosemu2, it's not doing anything related to nested virtualization, i.e. the stuffing VMXE=1 for the guest's shadow value should have absolutely zero impact. More than likely, VMXE was a red herring. Given that the reporter is also seeing the same bug on bare metal after moving to kernel 5.4, odds are good the issue is related to unrestricted_guest=n and has nothing to do with nVMX.
Re: [RFC PATCH 18/24] vhost-vdpa: support ASID based IOTLB API
On 2020/9/28 下午11:44, Eugenio Perez Martin wrote:
-u64 iova, u64 size)
+static int vhost_vdpa_unmap(struct vhost_vdpa *v,
+ struct vhost_iotlb *iotlb,
+ u64 iova, u64 size)
{
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
+ u32 asid = (iotlb);
+
+ if (!iotlb)
+ return -EINVAL;
This should be reorder to check for (!iotlb) before use at `asid =
iotlb_to_asid()`, isn't it?
Thanks!
Yes, will fix in the next version.
Thanks
Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
On 10/8/20 2:43 PM, Ard Biesheuvel wrote:
(+ Lorenzo)
On Thu, 8 Oct 2020 at 12:14, Catalin Marinas wrote:
On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4602e467ca8b..cd0d115ef329 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include /* for zone_dma_bits */
#include /* for COMMAND_LINE_SIZE */
#include
@@ -1198,6 +1199,14 @@ void __init early_init_dt_scan_nodes(void)
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
+void __init early_init_dt_update_zone_dma_bits(void)
+{
+ unsigned long dt_root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(dt_root, "brcm,bcm2711"))
+ zone_dma_bits = 30;
+}
I think we could keep this entirely in the arm64 setup_machine_fdt() and
not pollute the core code with RPi4-specific code.
Actually, even better, could we not move the check to
arm64_memblock_init() when we initialise zone_dma_bits?
I did it this way as I vaguely remembered Rob saying he wanted to centralise
all early boot fdt code in one place. But I'll be happy to move it there.
I can see Rob replied and I'm fine if that's his preference. However,
what I don't particularly like is that in the arm64 code, if
zone_dma_bits == 24, we set it to 32 assuming that it wasn't touched by
the early_init_dt_update_zone_dma_bits(). What if at some point we'll
get a platform that actually needs 24 here (I truly hope not, but just
the principle of relying on magic values)?
So rather than guessing, I'd prefer if the arch code can override
ZONE_DMA_BITS_DEFAULT. Then, in arm64, we'll just set it to 32 and no
need to explicitly touch the zone_dma_bits variable.
Yes, sonds like the way to go. TBH I wasn't happy with that solution either,
but couldn't think of a nicer alternative.
Sadly I just realised that the series is incomplete, we have RPi4 users that
want to boot unsing ACPI, and this series would break things for them. I'll
have a word with them to see what we can do for their use-case.
Is there a way to get some SoC information from ACPI?
This is unfortunate. We used ACPI _DMA methods as they were designed
to communicate the DMA limit of the XHCI controller to the OS.
It shouldn't be too hard to match the OEM id field in the DSDT, and
switch to the smaller mask. But it sucks to have to add a quirk like
that.
It also requires delaying setting the arm64_dma_phy_limit a bit, but
that doesn't appear to be causing a problem. I've been boot/compiling
with a patch like:
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index cada0b816c8a..9dfe776c1c75 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -168,6 +169,11 @@ static int __init acpi_fadt_sanity_check(void)
ret = -EINVAL;
}
+ if (!strncmp(table->oem_id, "RPIFDN", ACPI_OEM_ID_SIZE) &&
+ !strncmp(table->oem_table_id, "RPI4",
ACPI_OEM_TABLE_ID_SIZE) &&
+ table->oem_revision <= 0x200) {
+ zone_dma_bits = 30;
+ }
out:
/*
* acpi_get_table() creates FADT table mapping that
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index cd5caca8a929..6c8aaf1570ce 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -195,6 +195,7 @@ static void __init zone_sizes_init(unsigned long
min, unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
@@ -393,7 +394,6 @@ void __init arm64_memblock_init(void)
*/
if (zone_dma_bits == ZONE_DMA_BITS_DEFAULT)
zone_dma_bits = 32;
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
}
if (IS_ENABLED(CONFIG_ZONE_DMA32))
Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
On 2020/10/1 下午9:29, Eli Cohen wrote:
On Thu, Sep 24, 2020 at 11:21:11AM +0800, Jason Wang wrote:
This patch introduces a new bus operation to allow the vDPA bus driver
to associate an ASID to a virtqueue group.
So in case of virtio_net, I would expect that all the data virtqueues
will be associated with the same address space identifier.
Right.
I will add the codes to do this in the next version. It should be more
explicit than have this assumption by default.
Moreover,
this assignment should be provided before the set_map call that provides
the iotlb for the address space, correct?
I think it's better not have this limitation, note that set_map() now
takes a asid argument.
So for hardware if the associated as is changed, the driver needs to
program the hardware to switch to the new mapping.
Does this work for mlx5?
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 1e1163daa352..e2394995a3cd 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -160,6 +160,12 @@ struct vdpa_device {
* @get_generation: Get device config generation (optional)
*@vdev: vdpa device
*Returns u32: device generation
+ * @set_group_asid:Set address space identifier for a
+ * virtqueue group
+ * @vdev: vdpa device
+ * @group: virtqueue group
+ * @asid: address space id for this group
+ * Returns integer: success (0) or error (< 0)
* @set_map: Set device memory mapping (optional)
*Needed for device that using device
*specific DMA translation (on-chip IOMMU)
@@ -237,6 +243,10 @@ struct vdpa_config_ops {
u64 iova, u64 size, u64 pa, u32 perm);
int (*dma_unmap)(struct vdpa_device *vdev, unsigned int asid,
u64 iova, u64 size);
+ int (*set_group_asid)(struct vdpa_device *vdev, unsigned int group,
+ unsigned int asid);
+
+
Extra space
Will fix.
Thanks
/* Free device resources */
void (*free)(struct vdpa_device *vdev);
--
2.20.1
Re: [RFC PATCH 09/24] vdpa: multiple address spaces support
On 2020/10/1 下午9:23, Eli Cohen wrote: + /* Only support 1 address space */ + if (vdpa->ngroups != 1) + return -ENOTSUPP; Checkpatch warning: prefer EOPNOTSUPP Will fix. Thanks
Re: [RFC PATCH 09/24] vdpa: multiple address spaces support
On 2020/10/1 下午9:21, Eli Cohen wrote:
On Thu, Sep 24, 2020 at 11:21:10AM +0800, Jason Wang wrote:
This patches introduces the multiple address spaces support for vDPA
device. This idea is to identify a specific address space via an
dedicated identifier - ASID.
During vDPA device allocation, vDPA device driver needs to report the
number of address spaces supported by the device then the DMA mapping
ops of the vDPA device needs to be extended to support ASID.
This helps to isolate the DMA among the virtqueues. E.g in the case of
virtio-net, the control virtqueue will not be assigned directly to
guest.
This RFC patch only converts for the device that wants its own
IOMMU/DMA translation logic. So it will rejects the device with more
that 1 address space that depends on platform IOMMU. The plan to
This is not apparent from the code. Instead you enforce number of groups
to 1.
Yes, will fix.
moving all the DMA mapping logic to the vDPA device driver instead of
doing it in vhost-vDPA (otherwise it could result a very complicated
APIs and actually vhost-vDPA doesn't care about how the actual
composition/emulation were done in the device driver).
Signed-off-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_main.c | 2 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 5 +++--
drivers/vdpa/vdpa.c | 4 +++-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 10 ++
drivers/vhost/vdpa.c | 14 +-
include/linux/vdpa.h | 23 ---
6 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index e6a0be374e51..86cdf5f8bcae 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -440,7 +440,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
dev, _vdpa_ops,
- IFCVF_MAX_QUEUE_PAIRS * 2, 1);
+ IFCVF_MAX_QUEUE_PAIRS * 2, 1, 1);
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 4e480f4f754e..db7404e121bf 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1788,7 +1788,8 @@ static u32 mlx5_vdpa_get_generation(struct vdpa_device
*vdev)
return mvdev->generation;
}
-static int mlx5_vdpa_set_map(struct vdpa_device *vdev, struct vhost_iotlb *iotlb)
+static int mlx5_vdpa_set_map(struct vdpa_device *vdev, unsigned int asid,
+struct vhost_iotlb *iotlb)
{
struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
@@ -1931,7 +1932,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev->device, _vdpa_ops,
-2 * mlx5_vdpa_max_qps(max_vqs), 1);
+2 * mlx5_vdpa_max_qps(max_vqs), 1, 1);
if (IS_ERR(ndev))
return ndev;
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index 46399746ec7c..05195fa7865d 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -63,6 +63,7 @@ static void vdpa_release_dev(struct device *d)
* @config: the bus operations that is supported by this device
* @nvqs: number of virtqueues supported by this device
* @ngroups: number of groups supported by this device
+ * @nas: number of address spaces supported by this device
* @size: size of the parent structure that contains private data
*
* Driver should use vdpa_alloc_device() wrapper macro instead of
@@ -74,7 +75,7 @@ static void vdpa_release_dev(struct device *d)
struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
int nvqs, unsigned int ngroups,
- size_t size)
+ unsigned int nas, size_t size)
{
struct vdpa_device *vdev;
int err = -EINVAL;
@@ -102,6 +103,7 @@ struct vdpa_device *__vdpa_alloc_device(struct device
*parent,
vdev->features_valid = false;
vdev->nvqs = nvqs;
vdev->ngroups = ngroups;
+ vdev->nas = nas;
err = dev_set_name(>dev, "vdpa%u", vdev->index);
if (err)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 6669c561bc6e..5dc04ec271bb 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -354,7 +354,7 @@ static struct vdpasim *vdpasim_create(void)
ops = _net_config_ops;
vdpasim = vdpa_alloc_device(struct
Re: [PATCH 2/2] dt: Remove booting-without-of.rst
Rob Herring writes: > booting-without-of.rstt is an ancient document that first outlined ^ nit > Flattened DeviceTree on PowerPC initially. The DT world has evolved a > lot in the 15 years since and booting-without-of.rst is pretty stale. > The name of the document itself is confusing if you don't understand the > evolution from real 'OpenFirmware'. Most of what booting-without-of.rst > contains is now in the DT specification (which evolved out of the > ePAPR). The few things that weren't documented in the DT specification > are now. > > All that remains is the boot entry details, so let's move these to arch > specific documents. The exception is arm which already has the same > details documented. > > Cc: Frank Rowand > Cc: Mauro Carvalho Chehab > Cc: Geert Uytterhoeven > Cc: Michael Ellerman > Cc: Thomas Bogendoerfer > Cc: Jonathan Corbet > Cc: Paul Mackerras > Cc: Yoshinori Sato > Cc: Rich Felker > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > Cc: x...@kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-m...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Acked-by: Benjamin Herrenschmidt > Signed-off-by: Rob Herring > --- > .../devicetree/booting-without-of.rst | 1585 - > Documentation/devicetree/index.rst|1 - > Documentation/mips/booting.rst| 28 + > Documentation/mips/index.rst |1 + > Documentation/powerpc/booting.rst | 110 ++ LGTM. Acked-by: Michael Ellerman (powerpc) cheers
Re: [RFC PATCH 08/24] vdpa: introduce virtqueue groups
On 2020/9/28 下午11:44, Eugenio Perez Martin wrote:
On Thu, Sep 24, 2020 at 5:23 AM Jason Wang wrote:
This patch introduces virtqueue groups to vDPA device. The virtqueue
group is the minimal set of virtqueues that must share an address
space. And the adddress space identifier could only be attached to
a specific virtqueue group.
A new mandated bus operation is introduced to get the virtqueue group
ID for a specific virtqueue.
All the vDPA device drivers were converted to simply support a single
virtqueue group.
Signed-off-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_main.c | 9 -
drivers/vdpa/mlx5/net/mlx5_vnet.c | 8 +++-
drivers/vdpa/vdpa.c | 4 +++-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 11 ++-
include/linux/vdpa.h | 12 +---
5 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 076d7ac5e723..e6a0be374e51 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -327,6 +327,11 @@ static u32 ifcvf_vdpa_get_vq_align(struct vdpa_device
*vdpa_dev)
return IFCVF_QUEUE_ALIGNMENT;
}
+static u32 ifcvf_vdpa_get_vq_group(struct vdpa_device *vdpa, u16 idx)
+{
+ return 0;
+}
+
static void ifcvf_vdpa_get_config(struct vdpa_device *vdpa_dev,
unsigned int offset,
void *buf, unsigned int len)
@@ -387,6 +392,7 @@ static const struct vdpa_config_ops ifc_vdpa_ops = {
.get_device_id = ifcvf_vdpa_get_device_id,
.get_vendor_id = ifcvf_vdpa_get_vendor_id,
.get_vq_align = ifcvf_vdpa_get_vq_align,
+ .get_vq_group = ifcvf_vdpa_get_vq_group,
.get_config = ifcvf_vdpa_get_config,
.set_config = ifcvf_vdpa_set_config,
.set_config_cb = ifcvf_vdpa_set_config_cb,
@@ -434,7 +440,8 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
dev, _vdpa_ops,
- IFCVF_MAX_QUEUE_PAIRS * 2);
+ IFCVF_MAX_QUEUE_PAIRS * 2, 1);
+
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
return -ENOMEM;
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 9df69d5efe8c..4e480f4f754e 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1428,6 +1428,11 @@ static u32 mlx5_vdpa_get_vq_align(struct vdpa_device
*vdev)
return PAGE_SIZE;
}
+static u32 mlx5_vdpa_get_vq_group(struct vdpa_device *vdpa, u16 idx)
+{
+ return 0;
+}
+
enum { MLX5_VIRTIO_NET_F_GUEST_CSUM = 1 << 9,
MLX5_VIRTIO_NET_F_CSUM = 1 << 10,
MLX5_VIRTIO_NET_F_HOST_TSO6 = 1 << 11,
@@ -1838,6 +1843,7 @@ static const struct vdpa_config_ops mlx5_vdpa_ops = {
.get_vq_notification = mlx5_get_vq_notification,
.get_vq_irq = mlx5_get_vq_irq,
.get_vq_align = mlx5_vdpa_get_vq_align,
+ .get_vq_group = mlx5_vdpa_get_vq_group,
.get_features = mlx5_vdpa_get_features,
.set_features = mlx5_vdpa_set_features,
.set_config_cb = mlx5_vdpa_set_config_cb,
@@ -1925,7 +1931,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev->device,
_vdpa_ops,
-2 * mlx5_vdpa_max_qps(max_vqs));
+2 * mlx5_vdpa_max_qps(max_vqs), 1);
if (IS_ERR(ndev))
return ndev;
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index a69ffc991e13..46399746ec7c 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -62,6 +62,7 @@ static void vdpa_release_dev(struct device *d)
* @parent: the parent device
* @config: the bus operations that is supported by this device
* @nvqs: number of virtqueues supported by this device
+ * @ngroups: number of groups supported by this device
Hi!
Maybe the description of "ngroups" could be "number of*virtqueue*
groups supported by this device"? I think that it could be needed in
some contexts reading the code.
Exactly.
Will fix.
Thanks
Thanks!
Re: [PATCH v1 1/1] PCI/ERR: don't clobber status after reset_link()
On Fri, Oct 09, 2020 at 03:52:51AM +0100, Hedi Berriche wrote:
> Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
> changed pcie_do_recovery() so that status is updated with the return
> value from reset_link(); this was to fix the problem where we would
> wrongly report recovery failure, despite a successful reset_link(),
> whenever the initial error status is PCI_ERS_RESULT_DISCONNECT or
> PCI_ERS_RESULT_NO_AER_DRIVER.
>
> Unfortunately this breaks the flow of pcie_do_recovery() as it prevents
What is the reference to "this breaks" above?
> the actions needed when the initial error is PCI_ERS_RESULT_CAN_RECOVER
> or PCI_ERS_RESULT_NEED_RESET from taking place which causes error
> recovery to fail.
>
> Don't clobber status after reset_link() to restore the intended flow in
> pcie_do_recovery().
>
> Fix the original problem by saving the return value from reset_link()
> and use it later on to decide whether error recovery should be deemed
> successful in the scenarios where the initial error status is
> PCI_ERS_RESULT_{DISCONNECT,NO_AER_DRIVER}.
I would rather rephrase the above to make it clear what is being proposed.
Since the description seems to talk about the old problem and new solution
all mixed up.
>
> Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
> Signed-off-by: Hedi Berriche
> Cc: Russ Anderson
> Cc: Kuppuswamy Sathyanarayanan
> Cc: Bjorn Helgaas
> Cc: Ashok Raj
> Cc: Keith Busch
> Cc: Joerg Roedel
>
> Cc: sta...@kernel.org # v5.7+
> ---
> drivers/pci/pcie/err.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
> index c543f419d8f9..dbd0b56bd6c1 100644
> --- a/drivers/pci/pcie/err.c
> +++ b/drivers/pci/pcie/err.c
> @@ -150,7 +150,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
> pci_channel_state_t state,
> pci_ers_result_t (*reset_link)(struct pci_dev *pdev))
> {
> - pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
> + pci_ers_result_t post_reset_status, status = PCI_ERS_RESULT_CAN_RECOVER;
why call it post_reset_status?
> struct pci_bus *bus;
>
> /*
> @@ -165,8 +165,8 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
> pci_dbg(dev, "broadcast error_detected message\n");
> if (state == pci_channel_io_frozen) {
> pci_walk_bus(bus, report_frozen_detected, );
> - status = reset_link(dev);
> - if (status != PCI_ERS_RESULT_RECOVERED) {
> + post_reset_status = reset_link(dev);
> + if (post_reset_status != PCI_ERS_RESULT_RECOVERED) {
> pci_warn(dev, "link reset failed\n");
> goto failed;
> }
> @@ -174,6 +174,13 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
> pci_walk_bus(bus, report_normal_detected, );
> }
>
> + if ((status == PCI_ERS_RESULT_DISCONNECT ||
> + status == PCI_ERS_RESULT_NO_AER_DRIVER) &&
> + post_reset_status == PCI_ERS_RESULT_RECOVERED) {
> + /* error recovery succeeded thanks to reset_link() */
> + status = PCI_ERS_RESULT_RECOVERED;
> + }
> +
> if (status == PCI_ERS_RESULT_CAN_RECOVER) {
> status = PCI_ERS_RESULT_RECOVERED;
> pci_dbg(dev, "broadcast mmio_enabled message\n");
> --
> 2.28.0
>
Re: [RFC PATCH 06/24] vhost-vdpa: switch to use vhost-vdpa specific IOTLB
On 2020/9/30 下午8:02, Eli Cohen wrote:
On Thu, Sep 24, 2020 at 11:21:07AM +0800, Jason Wang wrote:
To ease the implementation of per group ASID support for vDPA
device. This patch switches to use a vhost-vdpa specific IOTLB to
avoid the unnecessary refactoring of the vhost core.
Signed-off-by: Jason Wang
---
drivers/vhost/vdpa.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 74bef1c15a70..ec3c94f706c1 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -40,6 +40,7 @@ struct vhost_vdpa {
struct vhost_virtqueue *vqs;
struct completion completion;
struct vdpa_device *vdpa;
+ struct vhost_iotlb *iotlb;
struct device dev;
struct cdev cdev;
atomic_t opened;
@@ -514,12 +515,11 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v,
static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
{
- struct vhost_dev *dev = >vdev;
- struct vhost_iotlb *iotlb = dev->iotlb;
+ struct vhost_iotlb *iotlb = v->iotlb;
vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1);
- kfree(dev->iotlb);
- dev->iotlb = NULL;
+ kfree(v->iotlb);
+ v->iotlb = NULL;
}
static int perm_to_iommu_flags(u32 perm)
@@ -681,7 +681,7 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev
*dev,
struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
- struct vhost_iotlb *iotlb = dev->iotlb;
+ struct vhost_iotlb *iotlb = v->iotlb;
int r = 0;
r = vhost_dev_check_owner(dev);
@@ -812,12 +812,14 @@ static int vhost_vdpa_open(struct inode *inode, struct
file *filep)
r = vhost_vdpa_alloc_domain(v);
if (r)
- goto err_init_iotlb;
+ goto err_alloc_domain;
You're still using this:
dev->iotlb = vhost_iotlb_alloc(0, 0);
Shouldn't you use
v->iotlb = host_iotlb_alloc(0, 0);
to set the vdpa device iotlb field?
Yes, you're right.
Will fix.
Thanks
filep->private_data = v;
return 0;
+err_alloc_domain:
+ vhost_vdpa_iotlb_free(v);
err_init_iotlb:
vhost_vdpa_cleanup(v);
err:
--
2.20.1
Re: [PATCH v2 3/4] powercap: Add AMD Fam17h RAPL support
On Wed, 2020-10-07 at 11:14 -0500, Kim Phillips wrote:
> From: Victor Ding
>
> This patch enables AMD Fam17h RAPL support for the power capping
> framework. The support is as per AMD Fam17h Model31h (Zen2) and
> model 00-ffh (Zen1) PPR.
>
> Tested by comparing the results of following two sysfs entries and
> the
> values directly read from corresponding MSRs via /dev/cpu/[x]/msr:
> /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
> /sys/class/powercap/intel-rapl/intel-rapl:0/intel-
> rapl:0:0/energy_uj
>
> Signed-off-by: Victor Ding
> Acked-by: Kim Phillips
> Cc: Victor Ding
> Cc: Alexander Shishkin
> Cc: Borislav Petkov
> Cc: Daniel Lezcano
> Cc: "H. Peter Anvin"
> Cc: Ingo Molnar
> Cc: Josh Poimboeuf
> Cc: Pawan Gupta
> Cc: "Peter Zijlstra (Intel)"
> Cc: "Rafael J. Wysocki"
> Cc: Sean Christopherson
> Cc: Thomas Gleixner
> Cc: Tony Luck
> Cc: Vineela Tummalapalli
> Cc: LKML
> Cc: linux...@vger.kernel.org
> Cc: x...@kernel.org
> ---
> Kim's changes from Victor's original submission:
>
>
https://lore.kernel.org/lkml/20200729205144.3.I01b89fb23d7498521c84cfdf417450cbbfca46bb@changeid/
>
> - Added my Acked-by.
> - Added Daniel Lezcano to Cc.
>
> arch/x86/include/asm/msr-index.h | 1 +
> drivers/powercap/intel_rapl_common.c | 2 ++
> drivers/powercap/intel_rapl_msr.c| 27
> ++-
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index f1b24f1b774d..c0646f69d2a5 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -324,6 +324,7 @@
> #define MSR_PP1_POLICY 0x0642
>
> #define MSR_AMD_RAPL_POWER_UNIT 0xc0010299
> +#define MSR_AMD_CORE_ENERGY_STATUS 0xc001029a
> #define MSR_AMD_PKG_ENERGY_STATUS0xc001029b
>
> /* Config TDP MSRs */
> diff --git a/drivers/powercap/intel_rapl_common.c
> b/drivers/powercap/intel_rapl_common.c
> index 983d75bd5bd1..6905ccffcec3 100644
> --- a/drivers/powercap/intel_rapl_common.c
> +++ b/drivers/powercap/intel_rapl_common.c
> @@ -1054,6 +1054,8 @@ static const struct x86_cpu_id rapl_ids[]
> __initconst = {
>
> X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,_defaults_hsw_se
> rver),
> X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,_defaults_hsw_se
> rver),
> +
> + X86_MATCH_VENDOR_FAM(AMD, 0x17, _defaults_core),
I double if we can use rapl_defaults_core here.
static const struct rapl_defaults rapl_defaults_core = {
.floor_freq_reg_addr = 0,
.check_unit = rapl_check_unit_core,
.set_floor_freq = set_floor_freq_default,
.compute_time_window = rapl_compute_time_window_core,
};
.floor_freq_reg_addr = 0,
is redundant here, even for rapl_defaults_core, we can remove it.
.check_unit = rapl_check_unit_core,
the Intel UNIT MSR supports three units including Energy/Power/Time.
>From the change below, only the energy counter is supported, so you may
need to confirm if all the three units are supported or not.
.set_floor_freq = set_floor_freq_default,this function sets PL1_CLAMP
bit on RAPL_DOMAIN_REG_LIMIT, but RAPL_DOMAIN_REG_LIMIT is not supported on the
AMD cpus.
.compute_time_window = rapl_compute_time_window_core,
this is used for setting the power limits, which is not supported on
the AMD cpus.
IMO, it's better to use a new rapl_defaults that contains valid
callbacks for AMD cpus.
> {}
> };
> MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
> diff --git a/drivers/powercap/intel_rapl_msr.c
> b/drivers/powercap/intel_rapl_msr.c
> index c68ef5e4e1c4..dcaef917f79d 100644
> --- a/drivers/powercap/intel_rapl_msr.c
> +++ b/drivers/powercap/intel_rapl_msr.c
> @@ -48,6 +48,21 @@ static struct rapl_if_priv rapl_msr_priv_intel = {
> .limits[RAPL_DOMAIN_PACKAGE] = 2,
> };
>
> +static struct rapl_if_priv rapl_msr_priv_amd = {
> + .reg_unit = MSR_AMD_RAPL_POWER_UNIT,
> + .regs[RAPL_DOMAIN_PACKAGE] = {
> + 0, MSR_AMD_PKG_ENERGY_STATUS, 0, 0, 0 },
> + .regs[RAPL_DOMAIN_PP0] = {
> + 0, MSR_AMD_CORE_ENERGY_STATUS, 0, 0, 0 },
> + .regs[RAPL_DOMAIN_PP1] = {
> + 0, 0, 0, 0, 0 },
> + .regs[RAPL_DOMAIN_DRAM] = {
> + 0, 0, 0, 0, 0 },
> + .regs[RAPL_DOMAIN_PLATFORM] = {
> + 0, 0, 0, 0, 0},
I don't think you need to set the PP1/DRAM/PLATFORM registers to 0 explicitly
if they are not supported.
> + .limits[RAPL_DOMAIN_PACKAGE] = 1,
Is Pkg Domain PL1 really supported?
At least according to this patch, I don't think so. So if power limit
is supported, it is better to add the support in this patch altogether.
If no, we're actually exposing energy counters only. If this is the
case, I'm not sure if it is proper to do this in powercap class because
we can not do powercap actually. Or at least, if we want to support
power zones with no power limits, we should enhance the code to
Re: [PATCH v2 1/2] perf vendor events: Update CascadelakeX events to v1.08
Hi Arnaldo,
On 9/26/2020 2:05 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Sep 23, 2020 at 09:25:06AM +0800, Jin, Yao escreveu:
On 9/23/2020 3:42 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Sep 22, 2020 at 11:19:17AM +0800, Jin Yao escreveu:
- Update CascadelakeX events to v1.08.
- Update CascadelakeX JSON metrics from TMAM 4.0.
Other fixes:
- Add NO_NMI_WATCHDOG metric constraint to Backend_Bound
- Change 'MB/sec' to 'MB' in UNC_M_PMM_BANDWIDTH.
[acme@five perf]$ am /wb/1.patch
Applying: perf vendor events: Update CascadelakeX events to v1.08
error: patch fragment without header at line 283: @@ -213,14 +220,14 @@
Patch failed at 0001 perf vendor events: Update CascadelakeX events to v1.08
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
[acme@five perf]$ git am --abort
[acme@five perf]$ set -o vi
[acme@five perf]$ patch -p1 < /wb/1.patch
patching file tools/perf/pmu-events/arch/x86/cascadelakex/cache.json
patching file tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json
Hunk #7 FAILED at 87.
1 out of 7 hunks FAILED -- saving rejects to file
tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json.rej
patching file tools/perf/pmu-events/arch/x86/cascadelakex/frontend.json
patching file tools/perf/pmu-events/arch/x86/cascadelakex/memory.json
patching file tools/perf/pmu-events/arch/x86/cascadelakex/other.json
patching file tools/perf/pmu-events/arch/x86/cascadelakex/pipeline.json
patching file tools/perf/pmu-events/arch/x86/cascadelakex/uncore-memory.json
patching file tools/perf/pmu-events/arch/x86/cascadelakex/uncore-other.json
[acme@five perf]$
[acme@five perf]$ head
tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json.rej
--- tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json
+++ tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json
@@ -87,86 +70,110 @@
"MetricName": "CLKS"
},
{
-"BriefDescription": "Total issue-pipeline slots (per-Physical Core)",
+"BriefDescription": "Total issue-pipeline slots (per-Physical Core till
ICL; per-Logical Processor ICL onward)",
"MetricExpr": "4 * cycles",
"MetricGroup": "TopDownL1",
[acme@five perf]$ wc -l
tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json.rej
133 tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json.rej
[acme@five perf]$
Can you please check?
I applied the patch on latest perf/core, it seemed OK.
# git log --oneline
4cbdb1c21926 (HEAD -> perf/core) perf vendor events: Update CascadelakeX events
to v1.08
b1f815c479c1 (tag: perf-tools-tests-v5.10-2020-09-10, origin/perf/core) perf
vendor events power9:
Add hv_24x7 core level metric events
f5a489dc8189 perf metricgroup: Pass pmu_event structure as a parameter for
arch_get_runtimeparam() 560ccbc4a52c perf jevents: Add support for parsing
perchip/percore events ...
I strongly suspect that part of patch content is truncated by mail system.
Let me resend the patch as attachment. Sorry about that!
Thanks, it now works, but then... You forgot to add the Cc: entries for
all the people in your actual e-mail Cc: list, and also the
Reviewed-by: from Andy, I had to do it all manually, so when I applied
your attachments with 'git am' I needed to go on and manually collect
all the Cc, Reviewed-by and Acked-by tags.
Sorry for replying so late!
I realized I forgot to add CC/To list in the attached patches. Very sorry about
that! :(
This complicates things, slows me down, doesn't scale. While I do all
this manual stuff normally, I don't think this can continue, and its not
something specific to you, submitters have to pay attention to these
details. Or tools.
Sorry for bringing troubles to you.
Things like b4 help with this and probably have to take into account
attachments as well, that is why I'm adding Konstantin to the Cc: list
of this message.
Let me learn b4... but as Konstantin said in another thread, it's complicated
too.
Anyway, for this case, I will take care in future. At least, I will check and add CC/To list to the
attached patch.
Thanks
Jin Yao
Konstantin, is this case covered? I.e. patches that get botched and then
require attachments to be sent to then gets processed?
Thanks, applied.
- Arnaldo
Re: [v5,2/4] dt-binding: mediatek: mt8192: update mtk-wdt document
On Fri, 2020-10-02 at 17:28 +0800, Matthias Brugger wrote: > > On 29/09/2020 05:20, Crystal Guo wrote: > > update mtk-wdt document for MT8192 platform > > > > Signed-off-by: Crystal Guo > > Reviewed-by: Matthias Brugger > > Reviewed-by: Guenter Roeck > > You added Guenters Reviewed-by in v4 of this series, but I don't see that on > Guenter provided this tag. In the future please make sure that you don't add > tags to your patches that were not provided. This creates great confusion. > > Regards, > Matthias > Hi Guenter, Should I remove the "Reviewed-by:Guenter" tag, and re-submit this patch for your review, or keeping the status quo and wait for Wim's comment? Thanks Crystal > > --- > > Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > index 45eedc2c3141..e36ba60de829 100644 > > --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > @@ -12,6 +12,7 @@ Required properties: > > "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > > "mediatek,mt8183-wdt": for MT8183 > > "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 > > + "mediatek,mt8192-wdt": for MT8192 > > > > - reg : Specifies base physical address and size of the registers. > > > >
[RFC][PATCH] cpufreq: intel_pstate: Delete intel_pstate sysfs if failed to register the driver
There is a corner case that if the intel_pstate driver failed to be
registered(might be due to invalid MSR access) and with the acpi_cpufreq
loaded, the intel_pstate sysfs might still be created, which makes the
user confusing(turbostat for example):
grep . /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq
grep . /sys/devices/system/cpu/intel_pstate/*
/sys/devices/system/cpu/intel_pstate/max_perf_pct:0
/sys/devices/system/cpu/intel_pstate/min_perf_pct:0
grep: /sys/devices/system/cpu/intel_pstate/no_turbo: Resource temporarily
unavailable
grep: /sys/devices/system/cpu/intel_pstate/num_pstates: Resource temporarily
unavailable
/sys/devices/system/cpu/intel_pstate/status:off
grep: /sys/devices/system/cpu/intel_pstate/turbo_pct: Resource temporarily
unavailable
The existing of intel_pstate sysfs does not mean that the intel_pstate driver
has been successfully loaded(for example, echo off to status), but the
intel_pstate sysfs should not co-exist when acpi-cpufreq is also present.
Fix this issue by deleting the intel_pstate sysfs if the driver failed
to be loaded during bootup.
Reported-by: Wendy Wang
Suggested-by: Zhang Rui
Signed-off-by: Chen Yu
---
drivers/cpufreq/intel_pstate.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 9a515c460a00..8c5f9680de83 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1420,6 +1420,26 @@ static void __init intel_pstate_sysfs_expose_params(void)
}
}
+static void __init intel_pstate_sysfs_clean(void)
+{
+ if (!intel_pstate_kobject)
+ return;
+
+ sysfs_remove_group(intel_pstate_kobject, _pstate_attr_group);
+
+ if (per_cpu_limits)
+ goto release_kobj;
+
+ sysfs_remove_file(intel_pstate_kobject, _perf_pct.attr);
+ sysfs_remove_file(intel_pstate_kobject, _perf_pct.attr);
+
+ if (x86_match_cpu(intel_pstate_cpu_ee_disable_ids))
+ sysfs_remove_file(intel_pstate_kobject,
_efficiency.attr);
+
+release_kobj:
+ kobject_put(intel_pstate_kobject);
+}
+
static void intel_pstate_sysfs_expose_hwp_dynamic_boost(void)
{
int rc;
@@ -3063,8 +3083,10 @@ static int __init intel_pstate_init(void)
mutex_lock(_pstate_driver_lock);
rc = intel_pstate_register_driver(default_driver);
mutex_unlock(_pstate_driver_lock);
- if (rc)
+ if (rc) {
+ intel_pstate_sysfs_clean();
return rc;
+ }
if (hwp_active) {
const struct x86_cpu_id *id;
--
2.17.1
[PATCH v2] KVM: x86: Add tracepoint for dr_write/dr_read
From: Haiwei Li
When vmexit occurs caused by accessing dr, there is no tracepoint to track
this action. Add tracepoint for this on x86 kvm.
Signed-off-by: Haiwei Li
---
v1 -> v2:
* Improve the changelog
arch/x86/kvm/svm/svm.c | 2 ++
arch/x86/kvm/trace.h | 27 +++
arch/x86/kvm/vmx/vmx.c | 10 --
arch/x86/kvm/x86.c | 1 +
4 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 4f401fc6a05d..52c69551aea4 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2423,12 +2423,14 @@ static int dr_interception(struct vcpu_svm *svm)
if (!kvm_require_dr(>vcpu, dr - 16))
return 1;
val = kvm_register_read(>vcpu, reg);
+ trace_kvm_dr_write(dr - 16, val);
kvm_set_dr(>vcpu, dr - 16, val);
} else {
if (!kvm_require_dr(>vcpu, dr))
return 1;
kvm_get_dr(>vcpu, dr, );
kvm_register_write(>vcpu, reg, val);
+ trace_kvm_dr_read(dr, val);
}
return kvm_skip_emulated_instruction(>vcpu);
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index aef960f90f26..b3bf54405862 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -405,6 +405,33 @@ TRACE_EVENT(kvm_cr,
#define trace_kvm_cr_read(cr, val) trace_kvm_cr(0, cr, val)
#define trace_kvm_cr_write(cr, val)trace_kvm_cr(1, cr, val)
+/*
+ * Tracepoint for guest DR access.
+ */
+TRACE_EVENT(kvm_dr,
+ TP_PROTO(unsigned int rw, unsigned int dr, unsigned long val),
+ TP_ARGS(rw, dr, val),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, rw )
+ __field(unsigned int, dr )
+ __field(unsigned long, val )
+ ),
+
+ TP_fast_assign(
+ __entry->rw = rw;
+ __entry->dr = dr;
+ __entry->val= val;
+ ),
+
+ TP_printk("dr_%s %x = 0x%lx",
+ __entry->rw ? "write" : "read",
+ __entry->dr, __entry->val)
+);
+
+#define trace_kvm_dr_read(dr, val) trace_kvm_dr(0, dr, val)
+#define trace_kvm_dr_write(dr, val)trace_kvm_dr(1, dr, val)
+
TRACE_EVENT(kvm_pic_set_irq,
TP_PROTO(__u8 chip, __u8 pin, __u8 elcr, __u8 imr, bool coalesced),
TP_ARGS(chip, pin, elcr, imr, coalesced),
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 4551a7e80ebc..f78fd297d51e 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -5091,10 +5091,16 @@ static int handle_dr(struct kvm_vcpu *vcpu)
if (kvm_get_dr(vcpu, dr, ))
return 1;
+ trace_kvm_dr_read(dr, val);
kvm_register_write(vcpu, reg, val);
- } else
- if (kvm_set_dr(vcpu, dr, kvm_register_readl(vcpu, reg)))
+ } else {
+ unsigned long val;
+
+ val = kvm_register_readl(vcpu, reg);
+ trace_kvm_dr_write(dr, val);
+ if (kvm_set_dr(vcpu, dr, val))
return 1;
+ }
return kvm_skip_emulated_instruction(vcpu);
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c4015a43cc8a..68cb7b331324 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11153,6 +11153,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_msr);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_cr);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_dr);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmrun);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmexit);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmexit_inject);
--
2.18.4
Re: [v5,0/4] watchdog: mt8192: add wdt support
On Fri, 2020-10-02 at 22:41 +0800, Guenter Roeck wrote: > On 10/2/20 2:51 AM, Matthias Brugger wrote: > > > > > > On 01/10/2020 17:16, Guenter Roeck wrote: > >> On Thu, Oct 01, 2020 at 04:23:02PM +0200, Matthias Brugger wrote: > >>> Hi Crystal, > >>> > >>> It seems you forgot to send the email to one of the maintainers, Wim. > >>> Please make sure you add all the maintainers from get_maintainers.pl when > >>> you send a series. > >>> > >>> Regards, > >>> Matthias > >>> > >>> On 29/09/2020 05:20, Crystal Guo wrote: > v5 changes: > fix typos on: > https://patchwork.kernel.org/patch/11697493/ > > v4 changes: > revise commit messages. > > v3 changes: > https://patchwork.kernel.org/patch/11692731/ > https://patchwork.kernel.org/patch/11692767/ > https://patchwork.kernel.org/patch/11692729/ > https://patchwork.kernel.org/patch/11692771/ > https://patchwork.kernel.org/patch/11692733/ > >> > >> This is less than helpful. It doesn't tell me anything. It expects me to > >> go back to the earlier versions, download them, and run a diff, to figure > >> out what changed. That means the patch or patch series ends at the bottom > >> of my pile of patches to review. Which, as it happens, is quite deep. > >> > >> I will review this and similar patches without change log after (and only > >> after) I have reviewed all other patches in my queue. > >> > > > > I understand your comments on hard to understand change log. But I think > > you acted to quick to put this series to the end of your queue. I'll try to > > explain: > > > > In v4 you gave your Acked-by and Reviewed-by for the patches that in this > > series are 3/4 [1] and 4/4 [2] respectively. You also gave your Reviewed-by > > for 1/4 [3]. > > > > In v4 you stated that you wanted to wait for a review from Rob for the > > binding changes. Obviously it's up to you to handle that the way you want. > > From my point of view these are rather trivial changes. > > > > That may be correct, but I am not a DT expert, and it happened often enough > that I approved a DT change and Rob later raised concerns that I don't do it > anymore. > > > In 1/4 are deleting compatible fallbacks in the bindings, as the driver > > provides SoC specific platform data, which you reviewed. > > > > One can argue that this will break older devicetree bindings because the > > driver using the fallback would work except for the topgru reset > > controller. But I think this is the job of the maintainer of the driver as > > Rob won't be able to look into all the driver code to decide if any change > > to the bindings is backward compatible. With your Reviewed-by I understand > > that you are OK with this change. As SoC maintainer I'm fine with the > > change. MT2701 is a SoC that's not available to the general public. MT8183 > > is available, but only on chromebooks and I don't expect anybody to use an > > older kernel without watchdog driver support for mt8183 (enablement is > > still ongoing). Actually I took the DTS counter part already through my > > tree, which was an error, as we now have a DTS which does not hold to the > > binding description (until and if you accept 1/4). > > > > The only patch missing patch is now 2/4, where Crystal added your > > Reviewed-by which you never gave. But it just adds the compatible to the > > binding for a driver you already gave your Reviewed-by. So I think this the > > series actually just fall through the cracks. > > > > Sorry for the long mail, but if you got until here, I hope I was able to > > convince you to just merge the series :) > > > > If my Reviewed-by is indeed in all patches, as you state, even if I didn't > give it > to some of those and the submitter just added it (is that acceptable nowadays > ?), > there should be no problem and Wim should pick up the series. And if the > submitter > had bothered to write a proper change log instead of expecting me to do the > work > I would have noticed right away. > > No, this was very appropriately put to the end of my review queue. > > Guenter Sorry to cause you trouble, I will pay attention to these points in the future. Crystal
[PATCH v1 1/1] PCI/ERR: don't clobber status after reset_link()
Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
changed pcie_do_recovery() so that status is updated with the return
value from reset_link(); this was to fix the problem where we would
wrongly report recovery failure, despite a successful reset_link(),
whenever the initial error status is PCI_ERS_RESULT_DISCONNECT or
PCI_ERS_RESULT_NO_AER_DRIVER.
Unfortunately this breaks the flow of pcie_do_recovery() as it prevents
the actions needed when the initial error is PCI_ERS_RESULT_CAN_RECOVER
or PCI_ERS_RESULT_NEED_RESET from taking place which causes error
recovery to fail.
Don't clobber status after reset_link() to restore the intended flow in
pcie_do_recovery().
Fix the original problem by saving the return value from reset_link()
and use it later on to decide whether error recovery should be deemed
successful in the scenarios where the initial error status is
PCI_ERS_RESULT_{DISCONNECT,NO_AER_DRIVER}.
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Hedi Berriche
Cc: Russ Anderson
Cc: Kuppuswamy Sathyanarayanan
Cc: Bjorn Helgaas
Cc: Ashok Raj
Cc: Keith Busch
Cc: Joerg Roedel
Cc: sta...@kernel.org # v5.7+
---
drivers/pci/pcie/err.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index c543f419d8f9..dbd0b56bd6c1 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -150,7 +150,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_channel_state_t state,
pci_ers_result_t (*reset_link)(struct pci_dev *pdev))
{
- pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
+ pci_ers_result_t post_reset_status, status = PCI_ERS_RESULT_CAN_RECOVER;
struct pci_bus *bus;
/*
@@ -165,8 +165,8 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, );
- status = reset_link(dev);
- if (status != PCI_ERS_RESULT_RECOVERED) {
+ post_reset_status = reset_link(dev);
+ if (post_reset_status != PCI_ERS_RESULT_RECOVERED) {
pci_warn(dev, "link reset failed\n");
goto failed;
}
@@ -174,6 +174,13 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_walk_bus(bus, report_normal_detected, );
}
+ if ((status == PCI_ERS_RESULT_DISCONNECT ||
+status == PCI_ERS_RESULT_NO_AER_DRIVER) &&
+post_reset_status == PCI_ERS_RESULT_RECOVERED) {
+ /* error recovery succeeded thanks to reset_link() */
+ status = PCI_ERS_RESULT_RECOVERED;
+ }
+
if (status == PCI_ERS_RESULT_CAN_RECOVER) {
status = PCI_ERS_RESULT_RECOVERED;
pci_dbg(dev, "broadcast mmio_enabled message\n");
--
2.28.0
Re: [PATCH v8 2/6] PCI/DPC: define a function to check and wait till port finish DPC handling
On Thu, Oct 8, 2020 at 2:16 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > Once root port DPC capability is enabled and triggered, at the beginning
> > of DPC is triggered, the DPC status bits are set by hardware and then
> > sends DPC/DLLSC/PDC interrupts to OS DPC and pciehp drivers, it will
> > take the port and software DPC interrupt handler 10ms to 50ms (test data
> > on ICS(Ice Lake SP platform, see
> > https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server)
> > & stable 5.9-rc6) to complete the DPC containment procedure
> This data is based on one particular architecture. So using this
> to create a timed loop in pci_wait_port_outdpc() looks incorrect.
To clarify there, it is not random to wait for specific 1000ms for
specific architecture.
Though there is no specification to say how many ms totally cost by
hardware DPC containment,
plus its interrupt handling. but you could read the whole PCIe
specification to know how
many ms cost at most by power state transition, link training etc, you
may know the max single delay
in hardware state transition is 200ms. Other small delay in hardware
state transition is 100ms,
48ms, 32ms etc.
If the DPC containment hardware procedure is pure resetting (or cold
power on) without
software access configuration as the worst case. we wait its handling
process from 10ms
(actually 20ms is the minimum delay we could do with msleep() ) till
1000ms timeout is a
reasonable value.
Thanks,
Ethan
>
> I still recommend looking for some locking model to fix this
> issue (may be atomic state flag or lock).
> > till the DPC status is cleared at the end of the DPC interrupt handler.
> >
> > We use this function to check if the root port is in DPC handling status
> > and wait till the hardware and software completed the procedure.
> >
> > Signed-off-by: Ethan Zhao
> > Tested-by: Wen Jin
> > Tested-by: Shanshan Zhang
> > ---
> > changes:
> > v2：align ICS code name to public doc.
> > v3: no change.
> > v4: response to Christoph's (Christoph Hellwig )
> > tip, move pci_wait_port_outdpc() to DPC driver and its declaration
> > to pci.h.
> > v5: fix building issue reported by l...@intel.com with some config.
> > v6: move from [1/5] to [2/5].
> > v7: no change.
> > v8: no change.
> >
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/pcie/dpc.c | 27 +++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index fa12f7cbc1a0..455b32187abd 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -455,10 +455,12 @@ void pci_restore_dpc_state(struct pci_dev *dev);
> > void pci_dpc_init(struct pci_dev *pdev);
> > void dpc_process_error(struct pci_dev *pdev);
> > pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
> > +bool pci_wait_port_outdpc(struct pci_dev *pdev);
> > #else
> > static inline void pci_save_dpc_state(struct pci_dev *dev) {}
> > static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
> > static inline void pci_dpc_init(struct pci_dev *pdev) {}
> > +static inline bool pci_wait_port_outdpc(struct pci_dev *pdev) { return
> > false; }
> > #endif
> >
> > #ifdef CONFIG_PCI_ATS
> > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> > index daa9a4153776..2e0e091ce923 100644
> > --- a/drivers/pci/pcie/dpc.c
> > +++ b/drivers/pci/pcie/dpc.c
> > @@ -71,6 +71,33 @@ void pci_restore_dpc_state(struct pci_dev *dev)
> > pci_write_config_word(dev, dev->dpc_cap + PCI_EXP_DPC_CTL, *cap);
> > }
> >
> > +bool pci_wait_port_outdpc(struct pci_dev *pdev)
> > +{
> > + u16 cap = pdev->dpc_cap, status;
> > + u16 loop = 0;
> > +
> > + if (!cap) {
> > + pci_WARN_ONCE(pdev, !cap, "No DPC capability initiated\n");
> > + return false;
> > + }
> > + pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
> > + pci_dbg(pdev, "DPC status %x, cap %x\n", status, cap);
> > +
> > + while (status & PCI_EXP_DPC_STATUS_TRIGGER && loop < 100) {
> > + msleep(10);
> > + loop++;
> > + pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
> > + }
> > +
> > + if (!(status & PCI_EXP_DPC_STATUS_TRIGGER)) {
> > + pci_dbg(pdev, "Out of DPC %x, cost %d ms\n", status, loop*10);
> > + return true;
> > + }
> > +
> > + pci_dbg(pdev, "Timeout to wait port out of DPC status\n");
> > + return false;
> > +}
> > +
> > static int dpc_wait_rp_inactive(struct pci_dev *pdev)
> > {
> > unsigned long timeout = jiffies + HZ;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
>
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:968:31: warning: variable 'num_dspp' set but not used
Hi Kalyan,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 583090b1b8232e6eae243a9009699666153a13a9
commit: e47616df008b1059c57892fb34883403a6933231 drm/msm/dpu: add support for
color processing blocks in dpu driver
date: 5 months ago
config: arm-randconfig-r002-20201009 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e47616df008b1059c57892fb34883403a6933231
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e47616df008b1059c57892fb34883403a6933231
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function
'dpu_encoder_virt_mode_set':
>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:968:31: warning: variable
>> 'num_dspp' set but not used [-Wunused-but-set-variable]
968 | int num_lm, num_ctl, num_pp, num_dspp;
| ^~~~
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:963:30: warning: variable
'topology' set but not used [-Wunused-but-set-variable]
963 | struct msm_display_topology topology;
| ^~~~
vim +/num_dspp +968 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
950
951 static void dpu_encoder_virt_mode_set(struct drm_encoder *drm_enc,
952struct drm_display_mode *mode,
953struct drm_display_mode *adj_mode)
954 {
955 struct dpu_encoder_virt *dpu_enc;
956 struct msm_drm_private *priv;
957 struct dpu_kms *dpu_kms;
958 struct list_head *connector_list;
959 struct drm_connector *conn = NULL, *conn_iter;
960 struct drm_crtc *drm_crtc;
961 struct dpu_crtc_state *cstate;
962 struct dpu_global_state *global_state;
963 struct msm_display_topology topology;
964 struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
965 struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
966 struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
967 struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
> 968 int num_lm, num_ctl, num_pp, num_dspp;
969 int i, j;
970
971 if (!drm_enc) {
972 DPU_ERROR("invalid encoder\n");
973 return;
974 }
975
976 dpu_enc = to_dpu_encoder_virt(drm_enc);
977 DPU_DEBUG_ENC(dpu_enc, "\n");
978
979 priv = drm_enc->dev->dev_private;
980 dpu_kms = to_dpu_kms(priv->kms);
981 connector_list = _kms->dev->mode_config.connector_list;
982
983 global_state = dpu_kms_get_existing_global_state(dpu_kms);
984 if (IS_ERR_OR_NULL(global_state)) {
985 DPU_ERROR("Failed to get global state");
986 return;
987 }
988
989 trace_dpu_enc_mode_set(DRMID(drm_enc));
990
991 list_for_each_entry(conn_iter, connector_list, head)
992 if (conn_iter->encoder == drm_enc)
993 conn = conn_iter;
994
995 if (!conn) {
996 DPU_ERROR_ENC(dpu_enc, "failed to find attached
connector\n");
997 return;
998 } else if (!conn->state) {
999 DPU_ERROR_ENC(dpu_enc, "invalid connector state\n");
1000 return;
1001 }
1002
1003 drm_for_each_crtc(drm_crtc, drm_enc->dev)
1004 if (drm_crtc->state->encoder_mask &
drm_encoder_mask(drm_enc))
1005 break;
1006
1007 topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
1008
1009 /* Query resource that have been reserved in atomic check step.
*/
1010 num_pp = dpu_rm_get_assigned_resources(_kms->rm,
global_state,
1011 drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
1012 ARRAY_SIZE(hw_pp));
1013 num_ctl = dpu_rm_get_assigned_resources(_kms->rm,
global_state,
1014 drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl,
ARRAY_SIZE(hw_ctl));
1015 num_lm = dpu_rm_get_assigned_resources(_kms->rm,
global_state,
1016
Re: [PATCH v2 10/11] soc: ti: k3-ringacc: Use correct device for allocation in RING mode
On 14:52-20201008, Peter Ujfalusi wrote: > - ring->ring_mem_virt = dma_alloc_coherent(ringacc->dev, > + ring->ring_mem_virt = dma_alloc_coherent(ring->dma_dev, > ring->size * (4 << ring->elm_size), > >ring_mem_dma, GFP_KERNEL); Any chance of getting a cleanup of the file for 5.11? I know this series has'nt introduced this warning or set of warnings, but I am starting to get concerned that we are carrying over too much of a debt now? https://pastebin.ubuntu.com/p/tT2kPDsCWD/ Checkpatch does point this: --- /tmp/kernel-patch-verify.25812/ptest_check-start2020-10-08 19:33:31.025898581 + +++ /tmp/kernel-patch-verify.25812/ptest_check-end 2020-10-08 19:33:31.593893830 + @@ -0,0 +1,6 @@ +CHECK: Alignment should match open parenthesis +#84: FILE: drivers/soc/ti/k3-ringacc.c:657: ++ ring->ring_mem_virt = dma_alloc_coherent(ring->dma_dev, + ring->size * (4 << ring->elm_size), -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2] MIPS: replace add_memory_region with memblock
在 2020/10/8 23:20, Serge Semin 写道: [...] - add_memory_region(LOONGSON_HIGHMEM_START, - highmemsize << 20, BOOT_MEM_RAM); - - add_memory_region(LOONGSON_PCI_MEM_END + 1, LOONGSON_HIGHMEM_START - - LOONGSON_PCI_MEM_END - 1, BOOT_MEM_RESERVED); - + memblock_add(LOONGSON_HIGHMEM_START, highmemsize << 20); The same question. Is it ok to discard the [LOONGSON_PCI_MEM_END+1:LOONGSON_HIGHMEM_START-LOONGSON_PCI_MEM_END-1] region removal operation? Hi all, I can confirm this reservation can be removed. It was used to ensure HIGHMEM won't overlap PCI MMIO region when firmware was unreliable. But I do think we shouldn't care this case as an unreliable firmware shouldn't ship with any devices for end users. Also it won't affect display of /proc/iomem, now we're on age of DeviceTree :-) Thanks. - Jiaxun -Sergey #endif /* !CONFIG_64BIT */ }
RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue
> -Original Message-
> From: ChiYuan Huang
> Sent: Wednesday, October 7, 2020 1:39 AM
> To: Jun Li
> Cc: Guenter Roeck ; Greg KH
> ; Heikki Krogerus
> ; Linux USB List
> ; lkml ;
> cy_huang ; Jun Li
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
>
> Jun Li 於 2020年10月7日 週三 上午12:52寫道：
> >
> > ChiYuan Huang 于2020年10月6日周二 下午12:38写道：
> > >
> > > Guenter Roeck 於 2020年10月5日 週一 下午11:30寫
> 道：
> > > >
> > > > On 10/5/20 4:08 AM, Greg KH wrote:
> > > > [ ... ]
> > > > >>> What ever happened with this patch, is there still disagreement?
> > > > >>>
> > > > >>
> > > > >> Yes, there is. I wouldn't have added the conditional without
> > > > >> reason, and I am concerned that removing it entirely will open
> > > > >> another
> problem.
> > > > >> Feel free to apply, though - I can't prove that my concern is
> > > > >> valid, and after all we'll get reports from the field later if it
> is.
> > > > >
> > > > > Ok, can I get an ack so I know who to come back to in the future
> > > > > if there are issues? :)
> > > > >
> > > >
> > > > Not from me, for the reasons I stated. I would be ok with something
> like:
> > > >
> > > > - if (tcpm_port_is_disconnected(port))
> > > > + if (tcpm_port_is_disconnected(port) ||
> > > > + (tcpm_cc_is_open(port->cc1) &&
> > > > + tcpm_cc_is_open(port->cc2)))
> > > >
> > > > to narrow down the condition.
> > >
> > > I have tried the above comment and It doesn't work.
> > > How about to change the judgement like as below
> > >
> > > - if (tcpm_port_is_disconnected(port))
> > > + if (tcpm_port_is_disconnected(port) || !port->vbus_present)
> > >
> > > The hard_reset_count not reset issue is following by the below order
> > > 1. VBUS off ( at the same time, cc is still detected as attached)
> > > port->attached become false and cc is not open
> > > 2. After that, cc detached.
> > > due to port->attached is false, tcpm_detach() directly return.
> >
> > If tcpm_detach() return directly, then how your patch can reset
> > hard_reset_count?
> >
> Yes, it can. We know vbus_present change from true to false and cc detach
> both trigger tcpm_detach.
> My change is whenever tcpm_detach to be called, hard_reset_count will be
> reset to zero.
Your patch is based on the assumption that tcpm_detach() is called with
port->attached is true, but tcpm_reset_port() may happen before that,
in that case, tcpm_reset_port() clear port->attached flag so tcpm_detach
will return directly.
>
> > I am seeing the same issue on my platform, the proposed change:
> > - if (tcpm_port_is_disconnected(port))
> > - port->hard_reset_count = 0;
> > + port->hard_reset_count = 0;
> > can't resolve it on my platform.
> >
> I'm not sure what's your condition. Could you directly paste the tcpm log
> for the check?
[ 47.127729] Setting voltage/current limit 0 mV 0 mA
[ 47.127739] polarity 0
[ 47.129333] Requesting mux state 0, usb-role 0, orientation 0
[ 47.130516] state change SNK_READY -> SNK_UNATTACHED
[ 47.131181] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_UNATTACHED, polarity 0,
disconnected]
[ 47.131194] state change SNK_UNATTACHED -> PORT_RESET
[ 47.134701] Setting voltage/current limit 0 mV 0 mA
[ 47.134709] polarity 0
[ 47.136291] Requesting mux state 0, usb-role 0, orientation 0
[ 47.136873] cc:=0
[ 47.137446] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms
[ 47.138084] CC1: 0 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0,
disconnected]
[ 47.239143] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[ 47.239151] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED
[ 47.239154] Entering tcpm_detach directly return here <
[ 47.239157] Start toggling
[ 47.240150] state change SNK_UNATTACHED -> TOGGLING
Li Jun
> > How about reset hard_reset_count in SNK_READY?
> > @@ -3325,6 +3329,7 @@ static void run_state_machine(struct tcpm_port
> *port)
> > case SNK_READY:
> > port->try_snk_count = 0;
> > port->update_sink_caps = false;
> > + port->hard_reset_count = 0;
> > if (port->explicit_contract) {
> > typec_set_pwr_opmode(port->typec_port,
> > TYPEC_PWR_MODE_PD);
> >
> > can this resolve your problem?
> I'm not sure. It need to have a try, then I can answer you.
> But from USBPD spec, the hard_reset_count need to reset zero only when 1.
> At src state, pe_src_send_cap and receive GoodCRC 2. At snk state,
> pe_snk_evaluate_cap need to reset hard_reset_count
> >
> > Li Jun
> > >
> > > And that's why hard_reset_count is not reset to 0.
> > > >
> > > > Guenter
Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps
On Thu, Oct 08, 2020 at 03:38:58PM -0700, Josh Triplett wrote: > On Thu, Oct 08, 2020 at 10:54:48AM -0700, Darrick J. Wong wrote: > > IMO, the prominent free software filesystem projects offer (at least) > > four layers of social structures to keep everyone on the same page, > > including people writing competing implementations. > > (I certainly hope that this isn't a *competing* implementation. It's > more that it serves a different purpose than the existing tools.) I hope so too, but external implementations tend to have staying power once people starting using them. You'd think e2fsdroid would have been merged into mke2fs by now, but no... > > The first is "Does > > everything we write still work with the kernel", which I guess you > > clearly did since you're complaining about this change in 5.9-rc2. > > Right. > > > The second layer is "Does it pass fsck?" which, given that you're asking > > for changes to e2fsck elsewhere in this thread and I couldn't figure out > > how to generate a shared-bitmaps ext4 fs that didn't also cause e2fsck > > to complain about the overlap doesn't make me confident that you went > > beyond the first step before shipping something. > > I did ensure that, other than the one top-level complaint that the > bitmaps overlapped, I got no complaints from e2fsck. I also confirmed > that with a patch to that one item, e2fsck passed with no issues. even a single top level complaint still means it doesn't pass. > > The third layer is consulting the ondisk format documentation to see if > > it points out anything that the kernel or fsck didn't notice. That > > one's kind of on Ted for not updating Documentation/ to spell out what > > SHARED_BLOCKS actually means, but that just leads me to the fourth thing. > > I've been making *extensive* use of Documentation/filesystems/ext4 by > the way, and I greatly appreciate it. I know you've done a ton of work > in that area. > > > The fourth layer is emailing the list to ask "Hey, I was thinking of > > ___, does anyone see a problem with my interpretation?". That clearly > > hasn't been done for shared bitmaps until now, which is all the more > > strange since you /did/ ask linux-ext4 about the inline data topic > > months ago. > > That one was on me, you're right. Because Ted is the maintainer of > e2fsprogs in Debian, and conversations about ext4 often happen in the > Debian BTS, reporting a bug on e2fsprogs there felt like starting an > upstream conversation. That was my mistake; in the future, I'll make > sure that things make it to linux-ext4. I already did so for > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971014 , and I > *should* have gone back and done so for the shared bitmap blocks issue. Thanks. > > ext* and XFS have been around for 25 years. The software validation of > > both is imperfect and incomplete because the complexity of the ondisk > > formats is vast and we haven't caught up with the technical debt that > > resulted from not writing rigorous checks that would have been very > > difficult with mid-90s hardware. I know, because I've been writing > > online checking for XFS and have seen the wide the gap between what the > > existing software looks for and what the ondisk format documentation > > allows. > > > > The only chance that we as a community have at managing the complexity > > of a filesystem is to use those four tools I outlined above to try to > > keep the mental models of everyone who participates in close enough > > alignment. That's how we usually avoid discussions that end in rancor > > and confusion. > > > > That was a very long way of reiterating "If you're going to interpret > > aspects of the software, please come talk to us before you start writing > > code". That is key to ext4's long history of compatibility, because a > > project cannot maintain continuity when actors develop conflicting code > > in the shadows. Look at all the mutations FAT and UFS that have > > appeared over the years-- the codebases became a mess as a result. > > Understood, agreed, and acknowledged. I'll make sure that any future > potentially "adventurous" filesystem experiments get discussed on > linux-ext4 first, not just in a distro bugtracker with a limited > audience. > > > > > the head", and continued with the notion that anything other than > > > > e2fsprogs making something to be mounted by mount(2) and handled by > > > > fs/ext4 is being "inflicted", and if the goal didn't still seem to be > > > > "how do we make it go away so that only e2fsprogs and the kernel ever > > > > touch ext4". I started this thread because I'd written some userspace > > > > code, a new version of the kernel made that userspace code stop working, > > > > so I wanted to report that the moment I'd discovered that, along with a > > > > potential way to address it with as little disrupton to ext4 as > > > > possible. > > > > Ted: I don't think it's a good idea to make SHARED_BLOCKS disable block > > validity
[PATCH v2 2/3] usb: host: add uhci compatible support for ast2600-uhci
v2:
- Fix continuation lines, align with "of_device"
v1:
- Add support for AST2600 SOC UHCI driver.
Signed-off-by: Ryan Chen
---
drivers/usb/host/uhci-platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
index 70dbd95c3f06..be9e9db7cad1 100644
--- a/drivers/usb/host/uhci-platform.c
+++ b/drivers/usb/host/uhci-platform.c
@@ -113,7 +113,8 @@ static int uhci_hcd_platform_probe(struct platform_device
*pdev)
num_ports);
}
if (of_device_is_compatible(np, "aspeed,ast2400-uhci") ||
- of_device_is_compatible(np, "aspeed,ast2500-uhci")) {
+ of_device_is_compatible(np, "aspeed,ast2500-uhci") ||
+ of_device_is_compatible(np, "aspeed,ast2600-uhci")) {
uhci->is_aspeed = 1;
dev_info(>dev,
"Enabled Aspeed implementation workarounds\n");
--
2.17.1
[PATCH v2 0/3] Enable USB host for AST2600
v2: -[1/3]: Add SCSI,BLK_DEV_SD,USB_STORAGE in defconfig. -[2/3]: Fix continuation lines. v1: -The patches enable UHCI driver in AST2600 and also enable USB host in aspeed-ast2600-evb.dts. Ryan Chen (3): configs: aspeed: enable UHCI driver in defconfig usb: host: add uhci compatible support for ast2600-uhci ARM: dts: add ehci uhci enable in evb dts arch/arm/boot/dts/aspeed-ast2600-evb.dts | 8 arch/arm/configs/aspeed_g5_defconfig | 4 drivers/usb/host/uhci-platform.c | 3 ++- 3 files changed, 14 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH v2 3/3] ARM: dts: add ehci uhci enable in evb dts
Add EHCI UHCI enable build in aspeed-ast2600-evb.dts
Signed-off-by: Ryan Chen
---
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
index 89be13197780..2772796e215e 100644
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -237,3 +237,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
2.17.1
[PATCH v2 1/3] configs: aspeed: enable UHCI driver in defconfig
v2: -Changed : Add SCSI, BLK_DEV_SD, USB_STORAGE support. v1: -Enable UHCI driver in aspeed_g5_defconfig. Signed-off-by: Ryan Chen --- arch/arm/configs/aspeed_g5_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index 2bacd8c90f4b..7a6b0b79be9f 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/configs/aspeed_g5_defconfig @@ -90,6 +90,8 @@ CONFIG_BLK_DEV_NBD=y CONFIG_MCTP_LPC=y CONFIG_EEPROM_AT24=y CONFIG_EEPROM_AT25=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y CONFIG_MD=y CONFIG_BLK_DEV_DM=y CONFIG_DM_VERITY=y @@ -212,6 +214,8 @@ CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_UHCI_HCD=y +CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_ASPEED_VHUB=y CONFIG_USB_CONFIGFS=y -- 2.17.1
Re: [RFC PATCH v1 21/26] docs: reporting-bugs: details on writing and sending the report
On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Outline how to write the report. Give instructions that hopefully will
> make people write better reports that ideally are also quick to evaluate
> for kernel developers.
>
> At the same time put some more faith into the readers to make them
> provide all relevant data. That's a bit different to the old approach,
> which told people to always send contents of files like /proc/ioports or
> /proc/iomem, which in a lot of cases won't be needed and make reports
> unnecessarily big.
>
> That's also why this commit removes scripts/ver_linux as well: the
> details it collects are only needed in some situations and make reports
> bigger and harder to compile without good reason. Additionally, some
> distributions do not ship it; a better, more modern script would likely
> resist in tools/, then distros might start shipping it in packages like
> "linux-tools".
>
> Signed-off-by: Thorsten Leemhuis
> ---
> Documentation/admin-guide/reporting-bugs.rst | 247 +++
> scripts/ver_linux| 81 --
> 2 files changed, 198 insertions(+), 130 deletions(-)
> delete mode 100755 scripts/ver_linux
>
> diff --git a/Documentation/admin-guide/reporting-bugs.rst
> b/Documentation/admin-guide/reporting-bugs.rst
> index 71c49347c544..b06935cad880 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -845,6 +845,204 @@ freshly to each newer kernel version you try.
> Afterwards run
> enabling any new feature, as those are allowed to cause regressions.
>
>
> +Write and send the report
> +-
> +
> +*Start to compile the report by writing a detailed description about the
> +issue. Always mentions a few things: the latest kernel version you
> installed
mention
> +for reproducing, the Linux Distribution used, and your notes how to
notes {of,on} how
to
> +reproduce the issue. Ideally, make the kernels build configuration
> (.config)
kernel's
> +and the output from ``dmesg`` available somewhere on the net and link to
> it.
> +Include or upload all other information that might be relevant, like the
> +output/screenshot of an Oops or the output from ``lspci``. Once you wrote
> +this main part insert a normal length paragraph on top of it outlining
> the
> +issue and the impact quickly. On top of this add one sentence that
> briefly
> +describes the problem and gets people to read on. Now give the thing a
> +descriptive title or subject that yet again is shorter. Then you're
> ready to
> +send or file the report like the MAINTAINERS file told you, unless you
> are
> +dealing with one of those 'issues of high priority': they need special
> care
> +which is explained in 'Special handling for high priority issues' below.*
> +
> +Now that you have prepared everything it's time to write your report. How to
> do
> +that is partly explained by the two documents linked to in the preface above.
> +
> +This text will only mention a few of the essentials as well as things
> apecific
specific
> +to the Linux kernel. There is one thing that fits both categories: the most
> +crucial parts of your report are the title/subject, the first sentence and
> the
> +first paragraph. Developers often get quite a lot of mail and have to quickly
> +decide if one is really worth reading. Developer sometimes take just a few
> +seconds to skim a mail before deciding if it's worth a closer look. Thus: the
> +better the top section of your report, the higher are the chances that
> someone
> +will look into it and help you. And that why you should ignore them for now
that is why
> +and write the detailed report first. ;-)
> +
> +Things each report should mention
> +~
> +
> +Describe in detail how your issue happens with the fresh vanilla kernel you
> +installed. Try to include the step-by-step instructions you wrote and
> optimized
> +earlier that descibe how you and ideally others can reproduce the issue; in
describe
> +those rare cases where that's impossible try to describe what you did to
> trigger
> +it.
> +
> +Also include all the relevant information others might need to understand the
> +issue and its environment. What's actually needed depends a lot on the issue,
> +but there are some things you should include always:
> +
> + * the output from ``cat /proc/version``, which contains the Linux kernel
> + version number and the compiler it was built with.
> +
> + * the Linux distribution the machine is running (``hostnamectl | grep
> + "Operating System"``)
> +
> + * the architecture of the CPU and the operating
[PATCH] xfrm:ignore big packets when tunnel mode
From: Lina Wang
In tunnel mode, when inner interface is ipv4,outer interface is ipv6, flags
of tunnel mode's xfrm state is af-unspec, if a larger packet who is bigger
than mtu goes through tunnel interface, it enters ip6_fragment, goes to
fail_toobig, and ICMPV6(ICMPV6_PKT_TOOBIG) will be sent. It is unnecessary
to do so. Ip6_fragment will fragment such packet with outer interface's mtu
minus tunnelled esp header,it wonot be too big.
The same things happen, when a larger fragmented packet whose frag_max_size
is larger than mtu.
When a larger fragmented packet is forwarded, it also meets the same
scenary.
This patch has handled three above scenaries, if it is tunnel mode,just
ignore skb_len or frag_max_size, keep going.
Signed-off-by: Lina Wang
---
net/ipv6/ip6_output.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index c78e67d7747f..0e1e6fcd7a5d 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -402,12 +402,14 @@ static inline int ip6_forward_finish(struct net *net,
struct sock *sk,
static bool ip6_pkt_too_big(const struct sk_buff *skb, unsigned int mtu)
{
+ struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
if (skb->len <= mtu)
return false;
/* ipv6 conntrack defrag sets max_frag_size + ignore_df */
if (IP6CB(skb)->frag_max_size && IP6CB(skb)->frag_max_size > mtu)
- return true;
+ if (rt && !(rt->dst.flags & DST_XFRM_TUNNEL))
+ return true;
if (skb->ignore_df)
return false;
@@ -787,16 +789,19 @@ int ip6_fragment(struct net *net, struct sock *sk, struct
sk_buff *skb,
* or if the skb it not generated by a local socket.
*/
if (unlikely(!skb->ignore_df && skb->len > mtu))
- goto fail_toobig;
-
- if (IP6CB(skb)->frag_max_size) {
- if (IP6CB(skb)->frag_max_size > mtu)
+ if (rt && (rt->dst.flags & DST_XFRM_TUNNEL))
goto fail_toobig;
- /* don't send fragments larger than what we received */
- mtu = IP6CB(skb)->frag_max_size;
- if (mtu < IPV6_MIN_MTU)
- mtu = IPV6_MIN_MTU;
+ if (IP6CB(skb)->frag_max_size) {
+ if (IP6CB(skb)->frag_max_size > mtu) {
+ if (rt && !(rt->dst.flags & DST_XFRM_TUNNEL))
+ goto fail_toobig;
+ } else {
+ /* don't send fragments larger than what we received */
+ mtu = IP6CB(skb)->frag_max_size;
+ if (mtu < IPV6_MIN_MTU)
+ mtu = IPV6_MIN_MTU;
+ }
}
if (np && np->frag_size < mtu) {
--
2.18.0
[PATCH] f2fs: fix to set SBI_NEED_FSCK flag for inconsistent inode
If compressed inode has inconsistent fields on i_compress_algorithm,
i_compr_blocks and i_log_cluster_size, we missed to set SBI_NEED_FSCK
to notice fsck to repair the inode, fix it.
Signed-off-by: Chao Yu
---
fs/f2fs/inode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index d5664bc7d6c6..657db2fb6739 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -299,6 +299,7 @@ static bool sanity_check_inode(struct inode *inode, struct
page *node_page)
F2FS_FITS_IN_INODE(ri, fi->i_extra_isize,
i_log_cluster_size)) {
if (ri->i_compress_algorithm >= COMPRESS_MAX) {
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
f2fs_warn(sbi, "%s: inode (ino=%lx) has unsupported "
"compress algorithm: %u, run fsck to fix",
__func__, inode->i_ino,
@@ -307,6 +308,7 @@ static bool sanity_check_inode(struct inode *inode, struct
page *node_page)
}
if (le64_to_cpu(ri->i_compr_blocks) >
SECTOR_TO_BLOCK(inode->i_blocks)) {
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
f2fs_warn(sbi, "%s: inode (ino=%lx) has inconsistent "
"i_compr_blocks:%llu, i_blocks:%llu, run fsck
to fix",
__func__, inode->i_ino,
@@ -316,6 +318,7 @@ static bool sanity_check_inode(struct inode *inode, struct
page *node_page)
}
if (ri->i_log_cluster_size < MIN_COMPRESS_LOG_SIZE ||
ri->i_log_cluster_size > MAX_COMPRESS_LOG_SIZE) {
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
f2fs_warn(sbi, "%s: inode (ino=%lx) has unsupported "
"log cluster size: %u, run fsck to fix",
__func__, inode->i_ino,
--
2.26.2
Re: general protection fault in utf8_casefold
syzbot has bisected this issue to:
commit 91db9311945f01901ddb9813ce11364de214a156
Author: Su Sung Chung
Date: Mon Jul 8 15:31:39 2019 +
drm/amd/display: refactor gpio to allocate hw_container in constructor
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1012ee8b90
start commit: c85fb28b Merge tag 'arm64-fixes' of git://git.kernel.org/p..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1212ee8b90
console output: https://syzkaller.appspot.com/x/log.txt?x=1412ee8b90
kernel config: https://syzkaller.appspot.com/x/.config?x=de7f697da23057c7
dashboard link: https://syzkaller.appspot.com/bug?extid=05139c4039d0679e19ff
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12316e0050
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e8042050
Reported-by: syzbot+05139c4039d0679e1...@syzkaller.appspotmail.com
Fixes: 91db9311945f ("drm/amd/display: refactor gpio to allocate hw_container
in constructor")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [f2fs-dev] [f2fs bug] infinite loop in f2fs_get_meta_page_nofail()
On 2020/10/9 9:50, jaeg...@kernel.org wrote: On 10/09, Chao Yu wrote: On 2020/10/8 5:53, jaeg...@kernel.org wrote: On 10/07, Eric Biggers wrote: [moved linux-fsdevel to Bcc] On Wed, Oct 07, 2020 at 02:18:19AM -0700, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:a804ab08 Add linux-next specific files for 20201006 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=17fe30bf90 kernel config: https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb dashboard link: https://syzkaller.appspot.com/bug?extid=ee250ac8137be41d7b13 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1336413b90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12f7392b90 The issue was bisected to: commit eede846af512572b1f30b34f9889d7df64c017d4 Author: Jaegeuk Kim Date: Fri Oct 2 21:17:35 2020 + f2fs: f2fs_get_meta_page_nofail should not be failed Jaegeuk, it looks like the loop you added in the above commit doesn't terminate if the requested page is beyond the end of the device. Yes, that will go infinite loop. Otherwise, it will trigger a panic during the device reboot. Let me think how to avoid that before trying to get the wrong lba access. Delivering f2fs_get_sum_page()'s return value needs a lot of codes change, I think we can just zeroing sum_page in error case, as we have already shutdown f2fs via calling f2fs_stop_checkpoint(), then f2fs_cp_error() will stop all updates to filesystem data including summary pages. That sounds like one solution tho, I'm afraid of getting another panic by wrong zero'ed summary page. What case do you mean? maybe I missed some corner cases? Thanks, Thoughts? Thanks, - Eric ___ Linux-f2fs-devel mailing list linux-f2fs-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel . .
[PATCH v8 7/7] perf diff: Support hot streams comparison
This patch enables perf-diff with "--stream" option. "--stream": Enable hot streams comparison Now let's see example. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 hot chain 2: cycles: 29, hits: 2.78% -- compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:39 [ Hot streams in new perf data only ] hot chain 1: cycles: 4, hits: 4.54% -- main div.c:42 compute_flag div.c:28 hot chain 2: cycles: 5, hits: 3.51% -- main div.c:39 main div.c:44 main div.c:42 compute_flag div.c:28 Signed-off-by: Jin Yao --- v8: - No change v7: - Use new struct evlist_streams in data__file. - Free the streams in data__free. v6: - Rebase to perf/core v5: - Remove enum stream_type - Rebase to perf/core v4: - Remove the "--before" and "--after" options since they are for source line based comparison. In this patchset, we will not support
[PATCH v8 5/7] perf util: Calculate the sum of total streams hits
We have used callchain_node->hit to measure the hot level of one
stream. This patch calculates the sum of hits of total streams.
Thus in next patch, we can use following formula to report hot
percent for one stream.
hot percent = callchain_node->hit / sum of total hits
Signed-off-by: Jin Yao
---
v7/v8:
- No change
v6:
- Rebase to perf/core
v5:
- Rebase to perf/core
v4:
- No functional change.
v2:
- Combine the variable decl line with its initial assignment
in total_callchain_hits().
tools/perf/util/callchain.c | 32
tools/perf/util/callchain.h | 3 +++
tools/perf/util/stream.c| 2 ++
tools/perf/util/stream.h| 1 +
4 files changed, 38 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index d356e73c5622..4f824bfcc072 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1667,3 +1667,35 @@ bool callchain_cnode_matched(struct callchain_node
*base_cnode,
return match;
}
+
+static u64 count_callchain_hits(struct hist_entry *he)
+{
+ struct rb_root *root = >sorted_chain;
+ struct rb_node *rb_node = rb_first(root);
+ struct callchain_node *node;
+ u64 chain_hits = 0;
+
+ while (rb_node) {
+ node = rb_entry(rb_node, struct callchain_node, rb_node);
+ chain_hits += node->hit;
+ rb_node = rb_next(rb_node);
+ }
+
+ return chain_hits;
+}
+
+u64 callchain_total_hits(struct hists *hists)
+{
+ struct rb_node *next = rb_first_cached(>entries);
+ u64 chain_hits = 0;
+
+ while (next) {
+ struct hist_entry *he = rb_entry(next, struct hist_entry,
+rb_node);
+
+ chain_hits += count_callchain_hits(he);
+ next = rb_next(>rb_node);
+ }
+
+ return chain_hits;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index ad27fc8c7948..ac5bea9c1eb7 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -13,6 +13,7 @@ struct ip_callchain;
struct map;
struct perf_sample;
struct thread;
+struct hists;
#define HELP_PAD "\t\t\t\t"
@@ -302,4 +303,6 @@ void callchain_param_setup(u64 sample_type);
bool callchain_cnode_matched(struct callchain_node *base_cnode,
struct callchain_node *pair_cnode);
+u64 callchain_total_hits(struct hists *hists);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 0d6a7452320a..47c5956b3378 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -121,6 +121,8 @@ static void init_hot_callchain(struct hists *hists, struct
evsel_streams *es)
update_hot_callchain(he, es);
next = rb_next(>rb_node);
}
+
+ es->streams_hits = callchain_total_hits(hists);
}
static int evlist__init_callchain_streams(struct evlist *evlist,
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index cb131f41f5b1..a61072eda64d 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -14,6 +14,7 @@ struct evsel_streams {
int nr_streams_max;
int nr_streams;
int evsel_idx;
+ u64 streams_hits;
};
struct evlist_streams {
--
2.17.1
[PATCH v8 3/7] perf util: Compare two streams
Stream is the branch history which is aggregated by the branch
records from perf samples. Now we support the callchain as
stream.
If the callchain entries of one stream are fully matched with
the callchain entries of another stream, we think two streams
are matched.
For example,
cycles: 1, hits: 26.80% cycles: 1, hits: 27.30%
--- ---
main div.c:39 main div.c:39
main div.c:44 main div.c:44
Above two streams are matched (we don't consider the case that
source code is changed).
The matching logic is, compare the chain string first. If it's not
matched, fallback to dso address comparison.
Signed-off-by: Jin Yao
---
v7/v8:
- No change
v6:
- Rebase to perf/core
v5:
- Remove enum stream_type
- Rebase to perf/core
v4:
- Remove original source line comparison code.
tools/perf/util/callchain.c | 54 +
tools/perf/util/callchain.h | 4 +++
2 files changed, 58 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 2775b752f2fa..d356e73c5622 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1613,3 +1613,57 @@ void callchain_param_setup(u64 sample_type)
callchain_param.record_mode = CALLCHAIN_FP;
}
}
+
+static bool chain_match(struct callchain_list *base_chain,
+ struct callchain_list *pair_chain)
+{
+ enum match_result match;
+
+ match = match_chain_strings(base_chain->srcline,
+ pair_chain->srcline);
+ if (match != MATCH_ERROR)
+ return match == MATCH_EQ;
+
+ match = match_chain_dso_addresses(base_chain->ms.map,
+ base_chain->ip,
+ pair_chain->ms.map,
+ pair_chain->ip);
+
+ return match == MATCH_EQ;
+}
+
+bool callchain_cnode_matched(struct callchain_node *base_cnode,
+struct callchain_node *pair_cnode)
+{
+ struct callchain_list *base_chain, *pair_chain;
+ bool match = false;
+
+ pair_chain = list_first_entry(_cnode->val,
+ struct callchain_list,
+ list);
+
+ list_for_each_entry(base_chain, _cnode->val, list) {
+ if (_chain->list == _cnode->val)
+ return false;
+
+ if (!base_chain->srcline || !pair_chain->srcline) {
+ pair_chain = list_next_entry(pair_chain, list);
+ continue;
+ }
+
+ match = chain_match(base_chain, pair_chain);
+ if (!match)
+ return false;
+
+ pair_chain = list_next_entry(pair_chain, list);
+ }
+
+ /*
+* Say chain1 is ABC, chain2 is ABCD, we consider they are
+* not fully matched.
+*/
+ if (pair_chain && (_chain->list != _cnode->val))
+ return false;
+
+ return match;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index fe36a9e5ccd1..ad27fc8c7948 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -298,4 +298,8 @@ int callchain_branch_counts(struct callchain_root *root,
u64 *abort_count, u64 *cycles_count);
void callchain_param_setup(u64 sample_type);
+
+bool callchain_cnode_matched(struct callchain_node *base_cnode,
+struct callchain_node *pair_cnode);
+
#endif /* __PERF_CALLCHAIN_H */
--
2.17.1
[PATCH v8 2/7] perf util: Get the evsel_streams by evsel_idx
In previous patch, we have created evsel_streams array
This patch returns the specified evsel_streams according to the
evsel_idx.
Signed-off-by: Jin Yao
---
v8:
- No change
v7:
- Rename functions:
evsel_streams__entry
v6:
- Rebase to perf/core
v5:
- Rebase to perf/core
v4:
- Rename the patch from 'perf util: Return per-event callchain
streams' to 'perf util: Get the evsel_streams by evsel_idx'
tools/perf/util/stream.c | 13 +
tools/perf/util/stream.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 31efe4ae0f55..e1c7d6c6126b 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -162,3 +162,16 @@ struct evlist_streams *evlist__create_streams(struct
evlist *evlist,
return els;
}
+
+struct evsel_streams *evsel_streams__entry(struct evlist_streams *els,
+ int evsel_idx)
+{
+ struct evsel_streams *es = els->ev_streams;
+
+ for (int i = 0; i < els->nr_evsel; i++) {
+ if (es[i].evsel_idx == evsel_idx)
+ return [i];
+ }
+
+ return NULL;
+}
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index 35bc64df554c..f01335677479 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -27,4 +27,7 @@ void evlist_streams__delete(struct evlist_streams *els);
struct evlist_streams *evlist__create_streams(struct evlist *evlist,
int nr_streams_max);
+struct evsel_streams *evsel_streams__entry(struct evlist_streams *els,
+ int evsel_idx);
+
#endif /* __PERF_STREAM_H */
--
2.17.1
[PATCH v8 4/7] perf util: Link stream pair
In previous patch, we have created an evsel_streams for one event,
and top N hottest streams will be saved in a stream array in
evsel_streams.
This patch compares total streams among two evsel_streams.
Once two streams are fully matched, they will be linked as
a pair. From the pair, we can know which streams are matched.
Signed-off-by: Jin Yao
---
v8:
- No change
v7:
- Rename functions with 'stream__' prefix.
v6:
- Rebase to perf/core
v5:
- Remove enum stream_type
v4:
- New patch in v4.
tools/perf/util/stream.c | 40
tools/perf/util/stream.h | 4
2 files changed, 44 insertions(+)
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index e1c7d6c6126b..0d6a7452320a 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -175,3 +175,43 @@ struct evsel_streams *evsel_streams__entry(struct
evlist_streams *els,
return NULL;
}
+
+static struct stream *stream__callchain_match(struct stream *base_stream,
+ struct evsel_streams *es_pair)
+{
+ for (int i = 0; i < es_pair->nr_streams; i++) {
+ struct stream *pair_stream = _pair->streams[i];
+
+ if (callchain_cnode_matched(base_stream->cnode,
+ pair_stream->cnode)) {
+ return pair_stream;
+ }
+ }
+
+ return NULL;
+}
+
+static struct stream *stream__match(struct stream *base_stream,
+ struct evsel_streams *es_pair)
+{
+ return stream__callchain_match(base_stream, es_pair);
+}
+
+static void stream__link(struct stream *base_stream, struct stream
*pair_stream)
+{
+ base_stream->pair_cnode = pair_stream->cnode;
+ pair_stream->pair_cnode = base_stream->cnode;
+}
+
+void evsel_streams__match(struct evsel_streams *es_base,
+ struct evsel_streams *es_pair)
+{
+ for (int i = 0; i < es_base->nr_streams; i++) {
+ struct stream *base_stream = _base->streams[i];
+ struct stream *pair_stream;
+
+ pair_stream = stream__match(base_stream, es_pair);
+ if (pair_stream)
+ stream__link(base_stream, pair_stream);
+ }
+}
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index f01335677479..cb131f41f5b1 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -6,6 +6,7 @@
struct stream {
struct callchain_node *cnode;
+ struct callchain_node *pair_cnode;
};
struct evsel_streams {
@@ -30,4 +31,7 @@ struct evlist_streams *evlist__create_streams(struct evlist
*evlist,
struct evsel_streams *evsel_streams__entry(struct evlist_streams *els,
int evsel_idx);
+void evsel_streams__match(struct evsel_streams *es_base,
+ struct evsel_streams *es_pair);
+
#endif /* __PERF_STREAM_H */
--
2.17.1
[PATCH v8 0/7] perf: Stream comparison
Sometimes, a small change in a hot function reducing the cycles of this function, but the overall workload doesn't get faster. It is interesting where the cycles are moved to. What it would like is to diff before/after streams. The stream is the branch history which is aggregated by the branch records from perf samples. For example, the callchains aggregated from the branch records. By browsing the hot stream, we can understand the hot code path. By browsing the hot streams, we can understand the hot code path. By comparing the cycles variation of same streams between old perf data and new perf data, we can understand if the cycles are moved to other codes. The before stream is the stream in perf.data.old. The after stream is the stream in perf.data. Diffing before/after streams compares top N hottest streams between two perf data files. If all entries of one stream in perf.data.old are fully matched with all entries of another stream in perf.data, we think two streams are matched, otherwise the streams are not matched. For example, cycles: 1, hits: 26.80% cycles: 1, hits: 27.30% -- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 The above streams are matched and we can see for the same streams the cycles (1) are equal and the callchain hit percents are slightly changed (26.80% vs. 27.30%). That's expected. Now let's see example. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 hot chain 2: cycles: 29,
[PATCH v8 1/7] perf util: Create streams
We define the stream is the branch history which is aggregated by
the branch records from perf samples. For example, the callchains
aggregated from the branch records are considered as streams.
By browsing the hot stream, we can understand the hot code path.
Now we only support the callchain for stream. For measuring the
hot level for a stream, we use the callchain_node->hit, higher
is hotter.
There may be many callchains sampled so we only focus on the top
N hottest callchains. N is a user defined parameter or predefined
default value (nr_streams_max).
This patch creates an evsel_streams array per event, and saves
the top N hottest streams in a stream array.
So now we can get the per-event top N hottest streams.
Signed-off-by: Jin Yao
---
v8:
- Rebase to perf/core
v7:
- Create a new struct evlist_streams.
- Rename functions with appropriate prefix
v6:
- Rebase to perf/core
v5:
- Remove enum stram_type
- Rebase to perf/core
v4:
- Refactor the code
- Rename patch name from 'perf util: Create streams for managing
top N hottest callchains' to 'perf util: Create streams'
v2:
- Use zfree in free_evsel_streams().
tools/perf/util/Build| 1 +
tools/perf/util/stream.c | 164 +++
tools/perf/util/stream.h | 30 +++
3 files changed, 195 insertions(+)
create mode 100644 tools/perf/util/stream.c
create mode 100644 tools/perf/util/stream.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index eebbd5223cae..e2563d0154eb 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -102,6 +102,7 @@ perf-y += rwsem.o
perf-y += thread-stack.o
perf-y += spark.o
perf-y += topdown.o
+perf-y += stream.o
perf-$(CONFIG_AUXTRACE) += auxtrace.o
perf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
perf-$(CONFIG_AUXTRACE) += intel-pt.o
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
new file mode 100644
index ..31efe4ae0f55
--- /dev/null
+++ b/tools/perf/util/stream.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Compare and figure out the top N hottest streams
+ * Copyright (c) 2020, Intel Corporation.
+ * Author: Jin Yao
+ */
+
+#include
+#include
+#include
+#include "debug.h"
+#include "hist.h"
+#include "sort.h"
+#include "stream.h"
+#include "evlist.h"
+
+static void evsel_streams__delete(struct evsel_streams *es, int nr_evsel)
+{
+ for (int i = 0; i < nr_evsel; i++)
+ zfree([i].streams);
+
+ free(es);
+}
+
+void evlist_streams__delete(struct evlist_streams *els)
+{
+ evsel_streams__delete(els->ev_streams, els->nr_evsel);
+ free(els);
+}
+
+static struct evlist_streams *evlist_streams__new(int nr_evsel,
+ int nr_streams_max)
+{
+ struct evlist_streams *els;
+ struct evsel_streams *es;
+
+ els = zalloc(sizeof(*els));
+ if (!els)
+ return NULL;
+
+ es = calloc(nr_evsel, sizeof(struct evsel_streams));
+ if (!es) {
+ free(els);
+ return NULL;
+ }
+
+ for (int i = 0; i < nr_evsel; i++) {
+ struct evsel_streams *s = [i];
+
+ s->streams = calloc(nr_streams_max, sizeof(struct stream));
+ if (!s->streams)
+ goto err;
+
+ s->nr_streams_max = nr_streams_max;
+ s->evsel_idx = -1;
+ }
+
+ els->ev_streams = es;
+ els->nr_evsel = nr_evsel;
+ return els;
+
+err:
+ evsel_streams__delete(es, nr_evsel);
+ return NULL;
+}
+
+/*
+ * The cnodes with high hit number are hot callchains.
+ */
+static void evsel_streams__set_hot_cnode(struct evsel_streams *es,
+struct callchain_node *cnode)
+{
+ int i, idx = 0;
+ u64 hit;
+
+ if (es->nr_streams < es->nr_streams_max) {
+ i = es->nr_streams;
+ es->streams[i].cnode = cnode;
+ es->nr_streams++;
+ return;
+ }
+
+ /*
+* Considering a few number of hot streams, only use simple
+* way to find the cnode with smallest hit number and replace.
+*/
+ hit = (es->streams[0].cnode)->hit;
+ for (i = 1; i < es->nr_streams; i++) {
+ if ((es->streams[i].cnode)->hit < hit) {
+ hit = (es->streams[i].cnode)->hit;
+ idx = i;
+ }
+ }
+
+ if (cnode->hit > hit)
+ es->streams[idx].cnode = cnode;
+}
+
+static void update_hot_callchain(struct hist_entry *he,
+struct evsel_streams *es)
+{
+ struct rb_root *root = >sorted_chain;
+ struct rb_node *rb_node = rb_first(root);
+ struct callchain_node *cnode;
+
+ while (rb_node) {
+ cnode = rb_entry(rb_node, struct callchain_node, rb_node);
+ evsel_streams__set_hot_cnode(es, cnode);
+
[PATCH v8 6/7] perf util: Report hot streams
We show the streams separately. They are divided into different sections.
1. "Matched hot streams"
2. "Hot streams in old perf data only"
3. "Hot streams in new perf data only".
For each stream, we report the cycles and hot percent (hits%).
For example,
cycles: 2, hits: 4.08%
--
main div.c:42
compute_flag div.c:28
Signed-off-by: Jin Yao
---
v8:
- No change
v7:
- Rename functions with 'evsel_streams__' prefix
v6:
- Rebase to perf/core
v5:
- Rebase to perf/core
v4:
- Remove "Hot chains in old perf data but source line changed
in new perf data"
tools/perf/util/callchain.c | 13
tools/perf/util/callchain.h | 2 +
tools/perf/util/stream.c| 123
tools/perf/util/stream.h| 3 +
4 files changed, 141 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 4f824bfcc072..1b60985690bb 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1699,3 +1699,16 @@ u64 callchain_total_hits(struct hists *hists)
return chain_hits;
}
+
+s64 callchain_avg_cycles(struct callchain_node *cnode)
+{
+ struct callchain_list *chain;
+ s64 cycles = 0;
+
+ list_for_each_entry(chain, >val, list) {
+ if (chain->srcline && chain->branch_count)
+ cycles += chain->cycles_count / chain->branch_count;
+ }
+
+ return cycles;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index ac5bea9c1eb7..5824134f983b 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -305,4 +305,6 @@ bool callchain_cnode_matched(struct callchain_node
*base_cnode,
u64 callchain_total_hits(struct hists *hists);
+s64 callchain_avg_cycles(struct callchain_node *cnode);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 47c5956b3378..4bd5e5a00aa5 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -217,3 +217,126 @@ void evsel_streams__match(struct evsel_streams *es_base,
stream__link(base_stream, pair_stream);
}
}
+
+static void print_callchain_pair(struct stream *base_stream, int idx,
+struct evsel_streams *es_base,
+struct evsel_streams *es_pair)
+{
+ struct callchain_node *base_cnode = base_stream->cnode;
+ struct callchain_node *pair_cnode = base_stream->pair_cnode;
+ struct callchain_list *base_chain, *pair_chain;
+ char buf1[512], buf2[512], cbuf1[256], cbuf2[256];
+ char *s1, *s2;
+ double pct;
+
+ printf("\nhot chain pair %d:\n", idx);
+
+ pct = (double)base_cnode->hit / (double)es_base->streams_hits;
+ scnprintf(buf1, sizeof(buf1), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(base_cnode), pct * 100.0);
+
+ pct = (double)pair_cnode->hit / (double)es_pair->streams_hits;
+ scnprintf(buf2, sizeof(buf2), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(pair_cnode), pct * 100.0);
+
+ printf("%35s\t%35s\n", buf1, buf2);
+
+ printf("%35s\t%35s\n",
+ "---",
+ "--");
+
+ pair_chain = list_first_entry(_cnode->val,
+ struct callchain_list,
+ list);
+
+ list_for_each_entry(base_chain, _cnode->val, list) {
+ if (_chain->list == _cnode->val)
+ return;
+
+ s1 = callchain_list__sym_name(base_chain, cbuf1, sizeof(cbuf1),
+ false);
+ s2 = callchain_list__sym_name(pair_chain, cbuf2, sizeof(cbuf2),
+ false);
+
+ scnprintf(buf1, sizeof(buf1), "%35s\t%35s", s1, s2);
+ printf("%s\n", buf1);
+ pair_chain = list_next_entry(pair_chain, list);
+ }
+}
+
+static void print_stream_callchain(struct stream *stream, int idx,
+ struct evsel_streams *es, bool pair)
+{
+ struct callchain_node *cnode = stream->cnode;
+ struct callchain_list *chain;
+ char buf[512], cbuf[256], *s;
+ double pct;
+
+ printf("\nhot chain %d:\n", idx);
+
+ pct = (double)cnode->hit / (double)es->streams_hits;
+ scnprintf(buf, sizeof(buf), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(cnode), pct * 100.0);
+
+ if (pair) {
+ printf("%35s\t%35s\n", "", buf);
+ printf("%35s\t%35s\n",
+ "", "--");
+ } else {
+ printf("%35s\n", buf);
+ printf("%35s\n", "--");
+ }
+
+ list_for_each_entry(chain, >val, list) {
+ s
[PATCH] HID: ghlive: support for ghlive ps3/wii u dongles
This commit introduces the Guitar Hero Live driver which adds support
for the PS3 and Wii U dongles.
These dongles require a "magic" USB control message [1] to be sent
approximately every 10 seconds otherwise the dongle will not report
events where the strumbar is hit while a fret is being held.
Also, inspired by a patch sent on linux-input by Sanjay Govind [2], the
accelerometer is mapped to ABS_RY for tilt.
Interestingly, the Wii U and PS3 dongles share the same VID and PID.
[1] https://github.com/ghlre/GHLtarUtility/
[2] https://marc.info/?l=linux-input=157242835928542=2
Signed-off-by: Pascal Giard
---
drivers/hid/Kconfig | 6 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-ghlive.c | 220 +++
drivers/hid/hid-ids.h| 3 +
4 files changed, 230 insertions(+)
create mode 100644 drivers/hid/hid-ghlive.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 34f07371716d..0bf8dd1629f7 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -362,6 +362,12 @@ config HID_GFRM
---help---
Support for Google Fiber TV Box remote controls
+config HID_GHLIVE
+ tristate "Guitar Hero Live PS3/Wii U support"
+ depends on HID
+ help
+ Support for the Guitar Hero Live PS3 and Wii U guitar devices.
+
config HID_GLORIOUS
tristate "Glorious PC Gaming Race mice"
depends on HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index d8ea4b8c95af..6394f5bbf8a5 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
+obj-$(CONFIG_HID_GHLIVE) += hid-ghlive.o
obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
obj-$(CONFIG_HID_GOOGLE_HAMMER)+= hid-google-hammer.o
obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
diff --git a/drivers/hid/hid-ghlive.c b/drivers/hid/hid-ghlive.c
new file mode 100644
index ..db5814aff17f
--- /dev/null
+++ b/drivers/hid/hid-ghlive.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HID driver for Guitar Hero Live PS3 and Wii U Guitar devices.
+ *
+ * Copyright (c) 2020 Pascal Giard
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hid-ids.h"
+
+MODULE_AUTHOR("Pascal Giard ");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("HID driver for Activision GH Live PS3 and Wii U Guitar
devices");
+
+#define GHL_GUITAR_PS3WIIU BIT(2)
+#define GHL_GUITAR_CONTROLLER BIT(1)
+
+#define GHL_GUITAR_POKE_INTERVAL 10 /* In seconds */
+
+#define GHL_GUITAR_TILT_USAGE 44
+
+/* Magic value and data taken from GHLtarUtility:
+ * https://github.com/ghlre/GHLtarUtility/blob/master/PS3Guitar.cs
+ * Note: The Wii U and PS3 dongles happen to share the same!
+ */
+static const u16 ghl_ps3wiiu_magic_value = 0x201;
+static const char ghl_ps3wiiu_magic_data[] = {
+ 0x02, 0x08, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+
+struct ghlive_sc {
+ struct hid_device *hdev;
+ struct usb_device *usbdev;
+ unsigned long quirks;
+ int device_id;
+ unsigned int poke_current;
+ struct timer_list poke_timer;
+};
+
+static void ghl_magic_poke_cb(struct urb *urb)
+{
+ if (urb) {
+ /* Free cr and databuf allocated in ghl_magic_poke() */
+ kfree(urb->setup_packet);
+ kfree(urb->transfer_buffer);
+ }
+}
+
+static void ghl_magic_poke(struct timer_list *t)
+{
+ struct ghlive_sc *sc = from_timer(sc, t, poke_timer);
+
+ int ret;
+ unsigned int pipe;
+ struct urb *urb;
+ struct usb_ctrlrequest *cr;
+ const u16 poke_size =
+ ARRAY_SIZE(ghl_ps3wiiu_magic_data);
+ u8 *databuf;
+
+ pipe = usb_sndctrlpipe(sc->usbdev, 0);
+
+ cr = kzalloc(sizeof(*cr), GFP_ATOMIC);
+ if (!cr)
+ goto resched;
+
+ databuf = kzalloc(poke_size, GFP_ATOMIC);
+ if (!databuf) {
+ kfree(cr);
+ goto resched;
+ }
+
+ urb = usb_alloc_urb(0, GFP_ATOMIC);
+ if (!urb) {
+ kfree(databuf);
+ kfree(cr);
+ goto resched;
+ }
+
+ if (sc->quirks & (GHL_GUITAR_CONTROLLER | GHL_GUITAR_PS3WIIU)) {
+ cr->bRequestType =
+ USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_OUT;
+ cr->bRequest = USB_REQ_SET_CONFIGURATION;
+ cr->wValue = cpu_to_le16(ghl_ps3wiiu_magic_value);
+ cr->wIndex = 0;
+ cr->wLength = cpu_to_le16(poke_size);
+ memcpy(databuf, ghl_ps3wiiu_magic_data, poke_size);
+
+ usb_fill_control_urb(
+ urb, sc->usbdev, pipe,
+ (unsigned char *) cr, databuf, poke_size,
+ ghl_magic_poke_cb, NULL);
+
Re: [net-next PATCH v1] net: phy: Move of_mdio from drivers/of to drivers/net/mdio
On 10/8/2020 7:20 PM, Calvin Johnson wrote:
Hi Rob,
On Thu, Oct 08, 2020 at 11:35:07AM -0500, Rob Herring wrote:
On Thu, Oct 8, 2020 at 9:47 AM Calvin Johnson
wrote:
Better place for of_mdio.c is drivers/net/mdio.
Move of_mdio.c from drivers/of to drivers/net/mdio
One thing off my todo list. I'd started this ages ago[1].
Signed-off-by: Calvin Johnson
---
MAINTAINERS| 2 +-
drivers/net/mdio/Kconfig | 8
drivers/net/mdio/Makefile | 2 ++
drivers/{of => net/mdio}/of_mdio.c | 0
drivers/of/Kconfig | 7 ---
drivers/of/Makefile| 1 -
6 files changed, 11 insertions(+), 9 deletions(-)
rename drivers/{of => net/mdio}/of_mdio.c (100%)
of_mdio.c is really a combination of mdio and phylib functions, so it
should be split up IMO. With that, I think you can get rid of
CONFIG_OF_MDIO. See my branch[1] for what I had in mind. But that can
be done after this if the net maintainers prefer.
Acked-by: Rob Herring
Rob
[1] git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/move-net
Makes sense to me to split of_mdio.c. I can work on it once my current task
completes.
If you could take Rob's patches, given then a round of randconfig build
tests and update the MAINTAINERS file (no more drivers/of/of_mdio.c),
then this looks like the right approach to me. Thanks!
--
Florian
Re: [net-next PATCH v1] net: phy: Move of_mdio from drivers/of to drivers/net/mdio
Hi Rob,
On Thu, Oct 08, 2020 at 11:35:07AM -0500, Rob Herring wrote:
> On Thu, Oct 8, 2020 at 9:47 AM Calvin Johnson
> wrote:
> >
> > Better place for of_mdio.c is drivers/net/mdio.
> > Move of_mdio.c from drivers/of to drivers/net/mdio
>
> One thing off my todo list. I'd started this ages ago[1].
>
> >
> > Signed-off-by: Calvin Johnson
> > ---
> >
> > MAINTAINERS| 2 +-
> > drivers/net/mdio/Kconfig | 8
> > drivers/net/mdio/Makefile | 2 ++
> > drivers/{of => net/mdio}/of_mdio.c | 0
> > drivers/of/Kconfig | 7 ---
> > drivers/of/Makefile| 1 -
> > 6 files changed, 11 insertions(+), 9 deletions(-)
> > rename drivers/{of => net/mdio}/of_mdio.c (100%)
>
> of_mdio.c is really a combination of mdio and phylib functions, so it
> should be split up IMO. With that, I think you can get rid of
> CONFIG_OF_MDIO. See my branch[1] for what I had in mind. But that can
> be done after this if the net maintainers prefer.
>
> Acked-by: Rob Herring
>
> Rob
>
> [1] git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/move-net
Makes sense to me to split of_mdio.c. I can work on it once my current task
completes.
Regards
Calvin
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:959:30: warning: variable 'topology' set but not used
Hi Drew,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c85fb28b6f999db9928b841f63f1beeb3074eeca
commit: de3916c70a24e3e1bdbf6b0a77d75b069d8953d9 drm/msm/dpu: Track resources
in global state
date: 7 months ago
config: arm-randconfig-r002-20201009 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de3916c70a24e3e1bdbf6b0a77d75b069d8953d9
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout de3916c70a24e3e1bdbf6b0a77d75b069d8953d9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function
'dpu_encoder_virt_mode_set':
>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:959:30: warning: variable
>> 'topology' set but not used [-Wunused-but-set-variable]
959 | struct msm_display_topology topology;
| ^~~~
vim +/topology +959 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 946
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 947 static void
dpu_encoder_virt_mode_set(struct drm_encoder *drm_enc,
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 948
struct drm_display_mode *mode,
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 949
struct drm_display_mode *adj_mode)
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 950 {
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 951 struct dpu_encoder_virt
*dpu_enc;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 952 struct msm_drm_private
*priv;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 953 struct dpu_kms *dpu_kms;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 954 struct list_head
*connector_list;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 955 struct drm_connector
*conn = NULL, *conn_iter;
c2ab55a68a33746 Jeykumar Sankaran 2019-02-13 956 struct drm_crtc
*drm_crtc;
b107603b4ad0f26 Jeykumar Sankaran 2019-02-13 957 struct dpu_crtc_state
*cstate;
de3916c70a24e3e Drew Davenport2020-02-19 958 struct dpu_global_state
*global_state;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 @959 struct
msm_display_topology topology;
b954fa6baaca7ac Drew Davenport2020-02-19 960 struct dpu_hw_blk
*hw_pp[MAX_CHANNELS_PER_ENC];
b954fa6baaca7ac Drew Davenport2020-02-19 961 struct dpu_hw_blk
*hw_ctl[MAX_CHANNELS_PER_ENC];
b954fa6baaca7ac Drew Davenport2020-02-19 962 struct dpu_hw_blk
*hw_lm[MAX_CHANNELS_PER_ENC];
b954fa6baaca7ac Drew Davenport2020-02-19 963 int num_lm, num_ctl,
num_pp;
de3916c70a24e3e Drew Davenport2020-02-19 964 int i, j;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 965
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 966 if (!drm_enc) {
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 967
DPU_ERROR("invalid encoder\n");
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 968 return;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 969 }
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 970
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 971 dpu_enc =
to_dpu_encoder_virt(drm_enc);
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 972 DPU_DEBUG_ENC(dpu_enc,
"\n");
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 973
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 974 priv =
drm_enc->dev->dev_private;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 975 dpu_kms =
to_dpu_kms(priv->kms);
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 976 connector_list =
_kms->dev->mode_config.connector_list;
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 977
de3916c70a24e3e Drew Davenport2020-02-19 978 global_state =
dpu_kms_get_existing_global_state(dpu_kms);
de3916c70a24e3e Drew Davenport2020-02-19 979 if
(IS_ERR_OR_NULL(global_state)) {
de3916c70a24e3e Drew Davenport2020-02-19 980
DPU_ERROR("Failed to get global state");
de3916c70a24e3e Drew Davenport2020-02-19 981 return;
de3916c70a24e3e Drew Davenport2020-02-19 982 }
de3916c70a24e3e Drew Davenport2020-02-19 983
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 984
trace_dpu_enc_mode_set(DRMID(drm_enc));
25fdd5933e4c0f5 Jeykumar Sankaran 2018-06-27 985
25fdd5933e4c0f5 Jeykumar Sankaran
RE: [PATCH V2 0/7] remoteproc: imx_rproc: support iMX8MQ/M
> Subject: Re: [PATCH V2 0/7] remoteproc: imx_rproc: support iMX8MQ/M > > On Wed, 7 Oct 2020 at 18:52, Peng Fan wrote: > > > > Mathieu, Oleksij > > > > > Subject: [PATCH V2 0/7] remoteproc: imx_rproc: support iMX8MQ/M > > > > Do you have time to give a look at this patchset? > > I will review your patchset after you have reviewed mine[1]. Fair enough:) I not follow the mailing list tightly, will read your patchset soon. Thanks, Peng. > > [1]. > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.kernel.org%2Fproject%2Flinux-remoteproc%2Flist%2F%3Fseries%3D33 > 9079data=02%7C01%7Cpeng.fan%40nxp.com%7C7ed3771fc6254908c > 7e308d86b981d7b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C > 637377648356263771sdata=Po67f7yqLuoTSZ6lcALKqoxt0Wpwxk6MW > qNiPx%2B%2BVX8%3Dreserved=0 > > > > > Thanks, > > Peng. > > > > > > > > V2: > > > Rebased on linux-next > > > Dropped early boot feature to make patchset simple. > > > Drop rsc-da > > > > > > V1: > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.kernel.org%2Fcover%2F11682461%2Fdata=02%7C01%7Cpeng.fa > n%40nxp.com%7C7ed3771fc6254908c7e308d86b981d7b%7C686ea1d3bc2b > 4c6fa92cd99c5c301635%7C0%7C0%7C637377648356263771sdata=AI > XXzRj%2F8mv%2BLLOIB1yIQHbDJ7myt%2BN3bJYrunPALms%3Dreserv > ed=0 > > > > > > This patchset is to support i.MX8MQ/M coproc. > > > The early boot feature was dropped to make the patchset small in V2. > > > > > > Since i.MX specific TCM memory requirement, add elf platform hook. > > > Several patches have got reviewed by Oleksij and Mathieu in v1. > > > > > > Peng Fan (7): > > > remoteproc: elf: support platform specific memory hook > > > remoteproc: imx_rproc: add elf memory hooks > > > remoteproc: imx_rproc: correct err message > > > remoteproc: imx_rproc: use devm_ioremap > > > remoteproc: imx_rproc: add i.MX specific parse fw hook > > > remoteproc: imx_rproc: support i.MX8MQ/M > > > remoteproc: imx_proc: enable virtio/mailbox > > > > > > drivers/remoteproc/imx_rproc.c | 273 > > > - > > > drivers/remoteproc/remoteproc_elf_loader.c | 20 +- > > > include/linux/remoteproc.h | 2 + > > > 3 files changed, 287 insertions(+), 8 deletions(-) > > > > > > -- > > > 2.28.0 > >
Re: [RFC PATCH 05/24] vhost-vdpa: passing iotlb to IOMMU mapping helpers
On 2020/9/30 下午7:26, Eli Cohen wrote:
On Thu, Sep 24, 2020 at 11:21:06AM +0800, Jason Wang wrote:
To prepare for the ASID support for vhost-vdpa, try to pass IOTLB
object to dma helpers.
Maybe it's worth mentioning here that this patch does not change any
functionality and is presented as a preparation for passing different
iotlb's instead of using dev->iotlb
Right, let me add them in the next version.
Thanks
Signed-off-by: Jason Wang
---
drivers/vhost/vdpa.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 9c641274b9f3..74bef1c15a70 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -489,10 +489,11 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
return r;
}
-static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v,
+ struct vhost_iotlb *iotlb,
+ u64 start, u64 last)
{
struct vhost_dev *dev = >vdev;
- struct vhost_iotlb *iotlb = dev->iotlb;
struct vhost_iotlb_map *map;
struct page *page;
unsigned long pfn, pinned;
@@ -514,8 +515,9 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v,
u64 start, u64 last)
static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
{
struct vhost_dev *dev = >vdev;
+ struct vhost_iotlb *iotlb = dev->iotlb;
- vhost_vdpa_iotlb_unmap(v, 0ULL, 0ULL - 1);
+ vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1);
kfree(dev->iotlb);
dev->iotlb = NULL;
}
@@ -542,15 +544,14 @@ static int perm_to_iommu_flags(u32 perm)
return flags | IOMMU_CACHE;
}
-static int vhost_vdpa_map(struct vhost_vdpa *v,
+static int vhost_vdpa_map(struct vhost_vdpa *v, struct vhost_iotlb *iotlb,
u64 iova, u64 size, u64 pa, u32 perm)
{
- struct vhost_dev *dev = >vdev;
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
int r = 0;
- r = vhost_iotlb_add_range(dev->iotlb, iova, iova + size - 1,
+ r = vhost_iotlb_add_range(iotlb, iova, iova + size - 1,
pa, perm);
if (r)
return r;
@@ -559,7 +560,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
r = ops->dma_map(vdpa, iova, size, pa, perm);
} else if (ops->set_map) {
if (!v->in_batch)
- r = ops->set_map(vdpa, dev->iotlb);
+ r = ops->set_map(vdpa, iotlb);
} else {
r = iommu_map(v->domain, iova, pa, size,
perm_to_iommu_flags(perm));
@@ -568,29 +569,30 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
return r;
}
-static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
+static void vhost_vdpa_unmap(struct vhost_vdpa *v,
+struct vhost_iotlb *iotlb,
+u64 iova, u64 size)
{
- struct vhost_dev *dev = >vdev;
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
- vhost_vdpa_iotlb_unmap(v, iova, iova + size - 1);
+ vhost_vdpa_iotlb_unmap(v, iotlb, iova, iova + size - 1);
if (ops->dma_map) {
ops->dma_unmap(vdpa, iova, size);
} else if (ops->set_map) {
if (!v->in_batch)
- ops->set_map(vdpa, dev->iotlb);
+ ops->set_map(vdpa, iotlb);
} else {
iommu_unmap(v->domain, iova, size);
}
}
static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
+ struct vhost_iotlb *iotlb,
struct vhost_iotlb_msg *msg)
{
struct vhost_dev *dev = >vdev;
- struct vhost_iotlb *iotlb = dev->iotlb;
struct page **page_list;
unsigned long list_size = PAGE_SIZE / sizeof(struct page *);
unsigned int gup_flags = FOLL_LONGTERM;
@@ -644,7 +646,7 @@ static int vhost_vdpa_process_iotlb_update(struct
vhost_vdpa *v,
if (last_pfn && (this_pfn != last_pfn + 1)) {
/* Pin a contiguous chunk of memory */
csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
- if (vhost_vdpa_map(v, iova, csize,
+ if (vhost_vdpa_map(v, iotlb, iova, csize,
map_pfn << PAGE_SHIFT,
msg->perm))
goto out;
@@ -660,11 +662,12 @@ static int vhost_vdpa_process_iotlb_update(struct
vhost_vdpa *v,
}
/* Pin the rest chunk */
- ret = vhost_vdpa_map(v,
[PATCH] Input: joystick/analog - mips has get_cycles()
Fixes:
drivers/input/joystick/analog.c:160:2: warning: #warning Precise timer not
defined for this architecture. [-Wcpp]
Signed-off-by: Pujin Shi
---
drivers/input/joystick/analog.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index 2b625ebef914..cdf54b5f519b 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -147,7 +147,8 @@ static unsigned int get_time_pit(void)
#define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "TSC"
-#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) ||
defined(CONFIG_PPC) || defined(CONFIG_RISCV)
+#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || \
+ defined(CONFIG_PPC) || defined(CONFIG_RISCV) || defined(CONFIG_MIPS)
#define GET_TIME(x)do { x = get_cycles(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "get_cycles"
--
2.18.1
Re: [PATCH 2/2] riscv: Fixup static_obj() fail v2
On Thu, Oct 8, 2020 at 11:54 AM Palmer Dabbelt wrote:
>
> On Wed, 07 Oct 2020 08:08:33 PDT (-0700), guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > v1 is commit: 6184358da0004c8fd940afda6c0a0fa4027dc911 which has
> > been reverted.
> >
> > When enable LOCKDEP, static_obj() will cause error:
> >
> > [0.067192] INFO: trying to register non-static key.
> > [0.067325] the code is fine but needs lockdep annotation.
> > [0.067449] turning off the locking correctness validator.
> > [0.067718] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7-dirty #44
> > [0.067945] Call Trace:
> > [0.068369] [] walk_stackframe+0x0/0xa4
> > [0.068506] [] show_stack+0x2a/0x34
> > [0.068631] [] dump_stack+0x94/0xca
> > [0.068757] [] register_lock_class+0x5b8/0x5bc
> > [0.068969] [] __lock_acquire+0x6c/0x1d5c
> > [0.069101] [] lock_acquire+0xae/0x312
> > [0.069228] [] _raw_spin_lock_irqsave+0x40/0x5a
> > [0.069357] [] complete+0x1e/0x50
> > [0.069479] [] rest_init+0x1b0/0x28a
> > [0.069660] [] 0xffe016a2
> > [0.069779] [] 0xffe01b84
> > [0.069953] [] 0xffe01092
> >
> > Because some __initdata static variables is before _stext:
> >
> > static int static_obj(const void *obj)
> > {
> > unsigned long start = (unsigned long) &_stext,
> > end = (unsigned long) &_end,
> > addr = (unsigned long) obj;
> >
> > /*
> > * static variable?
> > */
> > if ((addr >= start) && (addr < end))
> > return 1;
> >
> > if (arch_is_kernel_data(addr))
> > return 1;
> >
> > We could implement arch_is_kernel_data to fixup it.
> >
> > Link:
> > https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guo...@kernel.org/T/#t
> > Signed-off-by: Guo Ren
> > Reported-by: Aurelien Jarno
> > Cc: Palmer Dabbelt
> > Cc: Atish Patra
> > Cc: Andreas Schwab
> > Cc: Aurelien Jarno
> > ---
> > arch/riscv/include/asm/sections.h | 20
> > arch/riscv/kernel/setup.c | 9 +
> > 2 files changed, 29 insertions(+)
> > create mode 100644 arch/riscv/include/asm/sections.h
> >
> > diff --git a/arch/riscv/include/asm/sections.h
> > b/arch/riscv/include/asm/sections.h
> > new file mode 100644
> > index ..2317b9e
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/sections.h
> > @@ -0,0 +1,20 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +#ifndef _ASM_RISCV_SECTIONS_H
> > +#define _ASM_RISCV_SECTIONS_H
> > +
> > +#define arch_is_kernel_data arch_is_kernel_data
> > +
> > +#include
> > +
> > +extern bool init_mem_is_free;
> > +
> > +static inline int arch_is_kernel_data(unsigned long addr)
> > +{
> > + if (init_mem_is_free)
> > + return 0;
> > +
> > + return addr >= (unsigned long)__init_begin &&
> > + addr < (unsigned long)__init_end;
> > +}
> > +#endif /* _ASM_RISCV_SECTIONS_H */
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 2c6dd32..9ebd5eb4 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -112,3 +113,11 @@ static int __init topology_init(void)
> > return 0;
> > }
> > subsys_initcall(topology_init);
> > +
> > +bool init_mem_is_free = false;
> > +
> > +void free_initmem(void)
> > +{
> > + free_initmem_default(POISON_FREE_INITMEM);
> > + init_mem_is_free = true;
> > +}
>
> I'm a bit confused as to what you're trying to do here. Yesterday I got
> another version of this patch set that moves init data around, today a
> different one. Yesterday's is tested and simpler, and given it's so late in
> the process I'm inclined to take that as I don't want to break anything.
>
> Right now I have
>
> 84814460eef9 ("riscv: Fixup bootup failure with HARDENED_USERCOPY")
> a78c6f5956a9 ("RISC-V: Make sure memblock reserves the memory containing DT")
> 549738f15da0 ("Linux 5.9-rc8")
>
> Unless there's some functional bug, that's what I'm going to send out for 5.9
> -- I'm not all that worried about lacking the ability to free init data. The
> above seems like fine 5.10 material.
>
> Let me know if I'm missing something here.
84814460eef9 could resolve the problem and Atish ask for any other
idea? So It's another choice, I forgot RFC in prefix.
6184358da0004c8fd940afda6c0a0fa4027dc911("riscv: Fixup static_obj()
fail") is a sloppy patch that introduces another problem. Sorry about
that.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [f2fs-dev] [f2fs bug] infinite loop in f2fs_get_meta_page_nofail()
On 10/09, Chao Yu wrote: > On 2020/10/8 5:53, jaeg...@kernel.org wrote: > > On 10/07, Eric Biggers wrote: > > > [moved linux-fsdevel to Bcc] > > > > > > On Wed, Oct 07, 2020 at 02:18:19AM -0700, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit:a804ab08 Add linux-next specific files for 20201006 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=17fe30bf90 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=ee250ac8137be41d7b13 > > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > syz repro: > > > > https://syzkaller.appspot.com/x/repro.syz?x=1336413b90 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12f7392b90 > > > > > > > > The issue was bisected to: > > > > > > > > commit eede846af512572b1f30b34f9889d7df64c017d4 > > > > Author: Jaegeuk Kim > > > > Date: Fri Oct 2 21:17:35 2020 + > > > > > > > > f2fs: f2fs_get_meta_page_nofail should not be failed > > > > > > > > > > Jaegeuk, it looks like the loop you added in the above commit doesn't > > > terminate > > > if the requested page is beyond the end of the device. > > > > Yes, that will go infinite loop. Otherwise, it will trigger a panic during > > the device reboot. Let me think how to avoid that before trying to get the > > wrong lba access. > > Delivering f2fs_get_sum_page()'s return value needs a lot of codes change, I > think > we can just zeroing sum_page in error case, as we have already shutdown f2fs > via > calling f2fs_stop_checkpoint(), then f2fs_cp_error() will stop all updates to > filesystem data including summary pages. That sounds like one solution tho, I'm afraid of getting another panic by wrong zero'ed summary page. > > Thoughts? > > Thanks, > > > > > > > > > - Eric > > > > > > ___ > > Linux-f2fs-devel mailing list > > linux-f2fs-de...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > >
Re: [PATCH v4 01/17] docs: acrn: Introduce ACRN
On 9/22/20 4:42 AM, shuo.a@intel.com wrote: > From: Shuo Liu > > Add documentation on the following aspects of ACRN: > > 1) A brief introduction on the architecture of ACRN. > 2) I/O request handling in ACRN. > > To learn more about ACRN, please go to ACRN project website > https://projectacrn.org, or the documentation page > https://projectacrn.github.io/. > > Signed-off-by: Shuo Liu > Reviewed-by: Zhi Wang > Reviewed-by: Reinette Chatre > Cc: Dave Hansen > Cc: Sen Christopherson > Cc: Dan Williams > Cc: Fengwei Yin > Cc: Zhi Wang > Cc: Zhenyu Wang > Cc: Yu Wang > Cc: Reinette Chatre > Cc: Greg Kroah-Hartman > --- > Documentation/virt/acrn/index.rst| 11 +++ > Documentation/virt/acrn/introduction.rst | 40 ++ > Documentation/virt/acrn/io-request.rst | 97 > Documentation/virt/index.rst | 1 + > MAINTAINERS | 7 ++ > 5 files changed, 156 insertions(+) > create mode 100644 Documentation/virt/acrn/index.rst > create mode 100644 Documentation/virt/acrn/introduction.rst > create mode 100644 Documentation/virt/acrn/io-request.rst > > diff --git a/Documentation/virt/acrn/io-request.rst > b/Documentation/virt/acrn/io-request.rst > new file mode 100644 > index ..019dc5978f7c > --- /dev/null > +++ b/Documentation/virt/acrn/io-request.rst > @@ -0,0 +1,97 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +I/O request handling > + > + > +An I/O request of a User VM, which is constructed by the hypervisor, is > +distributed by the ACRN Hypervisor Service Module to an I/O client > +corresponding to the address range of the I/O request. Details of I/O request > +handling are described in the following sections. > + > +1. I/O request > +-- > + ... > + > +2. I/O clients > +-- > + ... > + > +3. I/O request state transition > +--- > + > +The state transitions of a ACRN I/O request are as follows. of an ACRN > + > +:: > + > + FREE -> PENDING -> PROCESSING -> COMPLETE -> FREE -> ... > + > +- FREE: this I/O request slot is empty > +- PENDING: a valid I/O request is pending in this slot > +- PROCESSING: the I/O request is being processed > +- COMPLETE: the I/O request has been processed > + > +An I/O request in COMPLETE or FREE state is owned by the hypervisor. HSM and > +ACRN userspace are in charge of processing the others. > + > +4. Processing flow of I/O requests > +--- > + ... thanks. -- ~Randy
