Re: [PATCH -next] ACPI: HMAT: Release platform device in case of platform_device_add_data() fails
kindly ping
在 2022/9/14 11:37, Lin Yujun 写道:
The platform device is not released when platform_device_add_data()
fails. And platform_device_put() perfom one more pointer check than
put_device() to check for errors in the 'pdev' pointer.
Use platform_device_put() to release platform device in
platform_device_add()/platform_device_add_data()/
platform_device_add_resources() error case.
Fixes: c01044cc8191 ("ACPI: HMAT: refactor hmat_register_target_device to
hmem_register_device")
Signed-off-by: Lin Yujun
---
drivers/dax/hmem/device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c
index cb6401c9e9a4..f87ae005431a 100644
--- a/drivers/dax/hmem/device.c
+++ b/drivers/dax/hmem/device.c
@@ -47,7 +47,7 @@ void hmem_register_device(int target_nid, struct resource *r)
rc = platform_device_add_data(pdev, , sizeof(info));
if (rc < 0) {
pr_err("hmem memregion_info allocation failure for %pr\n",
);
- goto out_pdev;
+ goto out_resource;
}
rc = platform_device_add_resources(pdev, , 1);
@@ -65,7 +65,7 @@ void hmem_register_device(int target_nid, struct resource *r)
return;
out_resource:
- put_device(>dev);
+ platform_device_put(pdev);
out_pdev:
memregion_free(id);
}
[no subject]
https://bit.ly/3x8LDhsWill
Re: [PATCH 3/3] mtd: phram: Fix error return code in phram_setup()
On 2021/04/08 20:46, Miquel Raynal wrote:
Hi Yu,
Yu Kuai wrote on Thu, 8 Apr 2021 19:15:14 +0800:
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Reported-by: Hulk Robot
Signed-off-by: Yu Kuai
---
drivers/mtd/devices/phram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index 5b04ae6c3057..6ed6c51fac69 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -270,6 +270,7 @@ static int phram_setup(const char *val)
if (len == 0 || erasesize == 0 || erasesize > len
|| erasesize > UINT_MAX || rem) {
parse_err("illegal erasesize or len\n");
+ ret = -EINVAL;
goto error;
}
It looks like you're doing the opposite of what you say.
Hi,
sorry about that, I misunderstood 'fix to'.
Thanks
Yu Kuai
Thanks,
Miquèl
.
Re: [PATCH 2/2] powerpc: make 'boot_text_mapped' static
On 2021/04/08 13:04, Christophe Leroy wrote:
Le 08/04/2021 à 03:18, Yu Kuai a écrit :
The sparse tool complains as follow:
arch/powerpc/kernel/btext.c:48:5: warning:
symbol 'boot_text_mapped' was not declared. Should it be static?
This symbol is not used outside of btext.c, so this commit make
it static.
Signed-off-by: Yu Kuai
---
arch/powerpc/kernel/btext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index 359d0f4ca532..8df9230be6fa 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -45,7 +45,7 @@ unsigned long disp_BAT[2] __initdata = {0, 0};
static unsigned char vga_font[cmapsz];
-int boot_text_mapped __force_data = 0;
+static int boot_text_mapped __force_data;
Are you sure the initialisation to 0 can be removed ? Usually
initialisation to 0 is not needed because not initialised variables go
in the BSS section which is zeroed at startup. But here the variable is
flagged with __force_data so it is not going in the BSS section.
Hi,
I removed the initialisation to 0 because checkpatch complained about
it, I do not familiar with '__force_data', thanks for pointing it out.
Thanks,
Yu Kuai
extern void rmci_on(void);
extern void rmci_off(void);
.
Re: [PATCH 1/2] powerpc: remove set but not used variable 'force_printk_to_btext'
On 2021/04/08 13:01, Christophe Leroy wrote:
Le 08/04/2021 à 03:18, Yu Kuai a écrit :
Fixes gcc '-Wunused-but-set-variable' warning:
arch/powerpc/kernel/btext.c:49:12: error: 'force_printk_to_btext'
defined but not used.
You don't get this error as it is now.
You will get this error only if you make it 'static', which is what you
did in your first patch based on the 'sparse' report.
When removing a non static variable, you should explain that you can
remove it after you have verifier that it is nowhere used, neither in
that file nor in any other one.
Hi,
I do use 'git grep force_printk_to_btext' to confirm that
'force_printk_to_btext' is not used anywhere. Maybe it's better to
metion it in commit message?
Thanks
Yu Kuai
It is never used, and so can be removed.
Signed-off-by: Yu Kuai
---
arch/powerpc/kernel/btext.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index 803c2a45b22a..359d0f4ca532 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -46,7 +46,6 @@ unsigned long disp_BAT[2] __initdata = {0, 0};
static unsigned char vga_font[cmapsz];
int boot_text_mapped __force_data = 0;
-int force_printk_to_btext = 0;
extern void rmci_on(void);
extern void rmci_off(void);
.
Re: [PATCH] powerpc: Make some symbols static
On 2021/04/08 0:57, kernel test robot wrote: Hi Yu, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v5.12-rc6 next-20210407] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Yu-Kuai/powerpc-Make-some-symbols-static/20210407-205258 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc64-defconfig (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/7c0f3f68006b9b42ce944b02a2059128cc5826ec git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Yu-Kuai/powerpc-Make-some-symbols-static/20210407-205258 git checkout 7c0f3f68006b9b42ce944b02a2059128cc5826ec # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arch/powerpc/kernel/btext.c:49:12: error: 'force_printk_to_btext' defined but not used [-Werror=unused-variable] 49 | static int force_printk_to_btext; |^ cc1: all warnings being treated as errors vim +/force_printk_to_btext +49 arch/powerpc/kernel/btext.c 47 48 static int boot_text_mapped __force_data; > 49 static int force_printk_to_btext; 50 Will remove this variable in another patch. Thanks Yu Kuai --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[ANNOUNCE] Git v2.31.1
The latest maintenance release Git v2.31.1 is now available at the usual places. Nothing extraordinary. Just to fix known issues in v2.31 and backport some clean-ups already made for the next feature release. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.31.1' tag and the 'maint' branch that the tag points at: url = https://git.kernel.org/pub/scm/git/git url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git Git 2.31.1 Release Notes Fixes since v2.31 - * The fsmonitor interface read from its input without making sure there is something to read from. This bug is new in 2.31 timeframe. * The data structure used by fsmonitor interface was not properly duplicated during an in-core merge, leading to use-after-free etc. * "git bisect" reimplemented more in C during 2.30 timeframe did not take an annotated tag as a good/bad endpoint well. This regression has been corrected. * Fix macros that can silently inject unintended null-statements. * CALLOC_ARRAY() macro replaces many uses of xcalloc(). * Update insn in Makefile comments to run fuzz-all target. * Fix a corner case bug in "git mv" on case insensitive systems, which was introduced in 2.29 timeframe. Also contains various documentation updates and code clean-ups. Changes since v2.31.0 are as follows: Andrzej Hunt (2): Makefile: update 'make fuzz-all' docs to reflect modern clang fsmonitor: avoid global-buffer-overflow READ when checking trivial response Jeff King (1): bisect: peel annotated tags to commits Johannes Schindelin (2): fsmonitor: fix memory corruption in some corner cases fsmonitor: do not forget to release the token in `discard_index()` Jonathan Tan (1): t5606: run clone branch name test with protocol v2 Junio C Hamano (3): xcalloc: use CALLOC_ARRAY() when applicable cocci: allow xcalloc(1, size) Git 2.31.1 Kyle Meyer (1): config.txt: add missing period René Scharfe (6): fix xcalloc() argument order git-compat-util.h: drop trailing semicolon from macro definition use CALLOC_ARRAY vcs-svn: remove header files as well block-sha1: drop trailing semicolon from macro definition mem-pool: drop trailing semicolon from macro definition Torsten Bögershausen (1): git mv foo FOO ; git mv foo bar gave an assert
[ANNOUNCE] Git v2.31.0
The latest feature release Git v2.31.0 is now available at the
usual places. It is comprised of 679 non-merge commits since
v2.30.0, contributed by 85 people, 23 of which are new faces [*].
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.31.0'
tag and the 'master' branch that the tag points at:
url = https://git.kernel.org/pub/scm/git/git
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.30.0 are as follows.
Welcome to the Git development community!
Aleksey Kliger, Andreas Bühmann, Andrew Klotz, Andrzej Hunt,
Antonio Russo, Arnaud Morin, Bagas Sanjaya, Christian Walther,
Clement Moyroud, Daniel Levin, Daniel Troger, Harold Kim,
Jacob Vosmaer, LeSeulArtichaut, Mikhail Klyushin, Neeraj Singh,
Sangeeta Jain, Seth House, Shubham Verma, Utku Gultopu, Vasyl
Vavrychuk, Vojtěch Knyttl, and ZheNing Hu.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Adam Dinwoodie, Ævar Arnfjörð Bjarmason,
Alexander Shopov, Alex Henrie, Arusekk, brian m. carlson,
Christian Couder, Christopher Diaz Riveros, Dana Dahlstrom,
Daniel Santos, Denton Liu, Derrick Stolee, Dimitriy Ryazantcev,
Elijah Newren, Emir Sarı, Eric Sunshine, Eric Wong, Felipe
Contreras, Han-Wen Nienhuys, Hariom Verma, Heba Waly, Jean-Noël
Avila, Jeff Hostetler, Jeff King, Jiang Xin, Joey Salazar,
Johannes Schindelin, Johannes Sixt, Jonathan Nieder, Jonathan
Tan, Jordi Mas, Junio C Hamano, Kevin Daudt, Kevin Willford,
Lars Schneider, Martin Ågren, Martin von Zweigbergk, Matheus
Tavares, Matthias Rüster, Michael Haggerty, Patrick Steinhardt,
Paul Jolly, Peter Kaestle, Peter Krefting, Phil Hord, Philippe
Blain, Phillip Szelat, Phillip Wood, Pranit Bauva, Pratyush
Yadav, Rafael Silva, Ralf Thielow, René Scharfe, Ross Light,
Sergey Organov, SZEDER Gábor, Taylor Blau, Thomas Ackermann,
Torsten Bögershausen, Trần Ngọc Quân, and Yi-Jyun Pan.
[*] We are counting not just the authorship contribution but
issue reporting, testing and reviewing that are recorded
in the commit trailers.
Git 2.31 Release Notes
==
Updates since v2.30
---
Backward incompatible and other important changes
* The "pack-redundant" command, which has been left stale with almost
unusable performance issues, now warns loudly when it gets used, as
we no longer want to recommend its use (instead just "repack -d"
instead).
* The development community has adopted Contributor Covenant v2.0 to
update from v1.4 that we have been using.
* The support for deprecated PCRE1 library has been dropped.
* Fixes for CVE-2021-21300 in Git 2.30.2 (and earlier) is included.
UI, Workflows & Features
* The "--format=%(trailers)" mechanism gets enhanced to make it
easier to design output for machine consumption.
* When a user does not tell "git pull" to use rebase or merge, the
command gives a loud message telling a user to choose between
rebase or merge but creates a merge anyway, forcing users who would
want to rebase to redo the operation. Fix an early part of this
problem by tightening the condition to give the message---there is
no reason to stop or force the user to choose between rebase or
merge if the history fast-forwards.
* The configuration variable 'core.abbrev' can be set to 'no' to
force no abbreviation regardless of the hash algorithm.
* "git rev-parse" can be explicitly told to give output as absolute
or relative path with the `--path-format=(absolute|relative)` option.
* Bash completion (in contrib/) update to make it easier for
end-users to add completion for their custom "git" subcommands.
* "git maintenance" learned to drive scheduled maintenance on
platforms whose native scheduling methods are not 'cron'.
* After expiring a reflog and making a single commit, the reflog for
the branch would record a single entry that knows both @{0} and
@{1}, but we failed to answer "what commit were we on?", i.e. @{1}
* "git bundle" learns "--stdin" option to read its refs from the
standard input. Also, it now does not lose refs whey they point
at the same object.
* "git log" learned a new "--diff-merges=" option.
* "git ls-files" can and does show multiple entries when the index is
unmerged, which is a source for confusion unless -s/-u option is in
use. A new option --deduplicate has been introduced.
* `git worktree list` now annotates worktrees as prunable, shows
locked and prunable attributes in --porcelain mode, and gained
a -
[PATCH] drivers: android: binder.c: Fix indentation of multi-line comment
Fixed alignment of multi-line comment.
Added a * for each line of the comment.
Signed-off-by: Abhishek C
---
drivers/android/binder.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index c119736ca56a..700719c58147 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4617,8 +4617,9 @@ static long binder_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
unsigned int size = _IOC_SIZE(cmd);
void __user *ubuf = (void __user *)arg;
- /*pr_info("binder_ioctl: %d:%d %x %lx\n",
- proc->pid, current->pid, cmd, arg);*/
+ /* pr_info("binder_ioctl: %d:%d %x %lx\n",
+* proc->pid, current->pid, cmd, arg);
+*/
binder_selftest_alloc(>alloc);
@@ -5750,8 +5751,8 @@ static int __init binder_init(void)
if (!IS_ENABLED(CONFIG_ANDROID_BINDERFS) &&
strcmp(binder_devices_param, "") != 0) {
/*
- * Copy the module_parameter string, because we don't want to
- * tokenize it in-place.
+* Copy the module_parameter string, because we don't want to
+* tokenize it in-place.
*/
device_names = kstrdup(binder_devices_param, GFP_KERNEL);
if (!device_names) {
--
2.25.1
[ANNOUNCE] Git v2.31.0-rc2
A release candidate Git v2.31.0-rc2 is now available for testing at
the usual places. It is comprised of 655 non-merge commits since
v2.30.0, contributed by 68 people, 22 of which are new faces [*].
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.31.0-rc2' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.30.0 are as follows.
Welcome to the Git development community!
Aleksey Kliger, Andreas Bühmann, Andrew Klotz, Andrzej
Hunt, Antonio Russo, Arnaud Morin, Christian Walther, Clement
Moyroud, Daniel Levin, Daniel Troger, Harold Kim, Jacob Vosmaer,
LeSeulArtichaut, Mikhail Klyushin, Neeraj Singh, Sangeeta Jain,
Seth House, Shubham Verma, Utku Gultopu, Vasyl Vavrychuk,
Vojtěch Knyttl, and ZheNing Hu.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Adam Dinwoodie, Ævar Arnfjörð Bjarmason,
Alex Henrie, brian m. carlson, Christian Couder, Denton Liu,
Derrick Stolee, Elijah Newren, Eric Sunshine, Eric Wong,
Felipe Contreras, Han-Wen Nienhuys, Hariom Verma, Heba Waly,
Jeff Hostetler, Jeff King, Jiang Xin, Joey Salazar, Johannes
Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano,
Kevin Daudt, Kevin Willford, Lars Schneider, Martin Ågren,
Martin von Zweigbergk, Matheus Tavares, Michael Haggerty,
Patrick Steinhardt, Paul Jolly, Peter Kaestle, Phil Hord,
Philippe Blain, Phillip Wood, Pranit Bauva, Pratyush Yadav,
Rafael Silva, René Scharfe, Ross Light, Sergey Organov, SZEDER
Gábor, Taylor Blau, Thomas Ackermann, and Torsten Bögershausen.
[*] We are counting not just the authorship contribution but
issue reporting, testing and reviewing that are recorded
in the commit trailers.
Git 2.31 Release Notes (draft)
==
Updates since v2.30
---
Backward incompatible and other important changes
* The "pack-redundant" command, which has been left stale with almost
unusable performance issues, now warns loudly when it gets used, as
we no longer want to recommend its use (instead just "repack -d"
instead).
* The development community has adopted Contributor Covenant v2.0 to
update from v1.4 that we have been using.
* The support for deprecated PCRE1 library has been dropped.
* Fixes for CVE-2021-21300 in Git 2.30.2 (and earlier) is included.
UI, Workflows & Features
* The "--format=%(trailers)" mechanism gets enhanced to make it
easier to design output for machine consumption.
* When a user does not tell "git pull" to use rebase or merge, the
command gives a loud message telling a user to choose between
rebase or merge but creates a merge anyway, forcing users who would
want to rebase to redo the operation. Fix an early part of this
problem by tightening the condition to give the message---there is
no reason to stop or force the user to choose between rebase or
merge if the history fast-forwards.
* The configuration variable 'core.abbrev' can be set to 'no' to
force no abbreviation regardless of the hash algorithm.
* "git rev-parse" can be explicitly told to give output as absolute
or relative path with the `--path-format=(absolute|relative)` option.
* Bash completion (in contrib/) update to make it easier for
end-users to add completion for their custom "git" subcommands.
* "git maintenance" learned to drive scheduled maintenance on
platforms whose native scheduling methods are not 'cron'.
* After expiring a reflog and making a single commit, the reflog for
the branch would record a single entry that knows both @{0} and
@{1}, but we failed to answer "what commit were we on?", i.e. @{1}
* "git bundle" learns "--stdin" option to read its refs from the
standard input. Also, it now does not lose refs whey they point
at the same object.
* "git log" learned a new "--diff-merges=" option.
* "git ls-files" can and does show multiple entries when the index is
unmerged, which is a source for confusion unless -s/-u option is in
use. A new option --deduplicate has been introduced.
* `git worktree list` now annotates worktrees as prunable, shows
locked and prunable attributes in --porcelain mode, and gained
a --verbose option.
* "git clone" tries to locally check out the branch pointed at by
HEAD of the remote repository after it is done, but the protocol
did not convey the information necessary to do so when copying an
empty repository. The protocol v2 learned how
[ANNOUNCE] Git v2.30.2 and below for CVE-2021-21300
The latest maintenance release Git v2.30.2, together with releases for older maintenance tracks v2.17.6, v2.18.5, v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4, v2.25.5, v2.26.3, v2.27.1, v2.28.1 and v2.29.3, is now available at the usual places. These maintenance releases are to addresses the security issues CVE-2021-21300. Please update. The credit for these releases all goes to Matheus Tavares and Johannes Schindelin. I didn't have to do anything but tagging their result, cutting releases, and sending out this announcement. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.30.2' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git Git v2.30.2 Release Notes = This release merges up the fixes that appear in v2.17.6, v2.18.5, v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4, v2.25.5, v2.26.3, v2.27.1, v2.28.1 and v2.29.3 to address the security issue CVE-2021-21300; see the release notes for these versions for details. Git v2.17.6 Release Notes = This release addresses the security issues CVE-2021-21300. Fixes since v2.17.5 --- * CVE-2021-21300: On case-insensitive file systems with support for symbolic links, if Git is configured globally to apply delay-capable clean/smudge filters (such as Git LFS), Git could be fooled into running remote code during a clone. Credit for finding and fixing this vulnerability goes to Matheus Tavares, helped by Johannes Schindelin.
Re: A note on the 5.12-rc1 tag
Josh Triplett writes: >> It is trivial for you to fetch the refs/notes/do-not--checkout notes >> tree from me and merge it into your refs/notes/do-not--checkout >> notes tree, I would think; "git notes merge" may have room for >> improvement, but essentially it would just want a union of two >> sets, no? > > My primary concern about notes is that they require manual > action/configuration in order to share. I was looking for a solution > that would automatically protect anyone who pulled from linux.git > (directly or indirectly), without them having to specifically take a > separate step to sync this information. If "without any configuration" is a hard requirement, then by definition you'd need to live with what you get from "git clone" and "git pull" alone, so be it the notes or any other mechanism, there currently is nothing that lets you do the "skip this part while bisection".
Re: A note on the 5.12-rc1 tag
Christian Couder writes: >> (git notes would be nice for this, but they're hard to share reliably; >> the above mechanism to accumulate entries from a file in the repo seems >> simpler. I can imagine other possibilities.) > > If the notes are created automatically from the `/.git-bisect-skip` > files and stored in `refs/notes/skip`, then they might not need to be > shared. If people already share notes, they would just need to stop > sharing those in `refs/notes/skip`. Ehh, doesn't Josh _want_ to share them, though? I do not know if a single "refs/notes/bisect-skip" notes would do, or you'd need one notes tree per the kind of bisection (iow, people may be chasing different set of bugs, and the commits that need to be skipped while chasing one bug may be OK to test while chasing another one), but I would imagine that for this particular use case of marking "these commits are dangerous to check out and build on", it does not depend on what you are bisecting to find at all, so sharing would be a sensible thing to do. It is trivial for you to fetch the refs/notes/do-not--checkout notes tree from me and merge it into your refs/notes/do-not--checkout notes tree, I would think; "git notes merge" may have room for improvement, but essentially it would just want a union of two sets, no?
Re: [ANNOUNCE] Git v2.31.0-rc1
Eric Sunshine writes:
> On Wed, Mar 3, 2021 at 7:23 PM Junio C Hamano wrote:
>> Pratyush Yadav (1):
>> git-gui: remove lines starting with the comment character
>
> Is there some way that this can be removed from v2.31.0 before final
> release? It badly breaks git-gui on macOS[1,2] to the point of making
> it unusable (Tcl throws errors at launch time and when trying to
> commit, and committing is 100% broken).
Thanks.
I could revert the merge with the problematic changes to git-gui,
i.e. 0917373 (Merge https://github.com/prati0100/git-gui,
2021-03-01), but if possible, I'd rather merge a revert made on the
git-gui side. If b1056f60 (Merge branch 'py/commit-comments',
2021-02-22) is the tip of git-gui repository, and b9a43869 (git-gui:
remove lines starting with the comment character, 2021-02-03) is
what breaks, perhaps
$ git checkout b1056f60^2 &&
git revert b9a43869 &&
git checkout b1056f60 &&
git merge @{-1}
would be what we want to have at the tip of git-gui until the
breakage gets sorted out.
Pratyush?
[ANNOUNCE] Git v2.31.0-rc1
A release candidate Git v2.31.0-rc1 is now available for testing
at the usual places. It is comprised of 631 non-merge commits
since v2.30.0, contributed by 67 people, 21 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.31.0-rc1' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.30.0 are as follows.
Welcome to the Git development community!
Andreas Bühmann, Andrew Klotz, Andrzej Hunt, Antonio Russo,
Arnaud Morin, Christian Walther, Clement Moyroud, Daniel Levin,
Daniel Troger, Harold Kim, Jacob Vosmaer, LeSeulArtichaut,
Mikhail Klyushin, Neeraj Singh, Sangeeta Jain, Seth House,
Shubham Verma, Utku Gultopu, Vasyl Vavrychuk, Vojtěch Knyttl,
and ZheNing Hu.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Adam Dinwoodie, Ævar Arnfjörð Bjarmason,
Alex Henrie, brian m. carlson, Christian Couder, Denton Liu,
Derrick Stolee, Elijah Newren, Eric Sunshine, Eric Wong,
Felipe Contreras, Han-Wen Nienhuys, Hariom Verma, Heba Waly,
Jeff Hostetler, Jeff King, Jiang Xin, Joey Salazar, Johannes
Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano,
Kevin Daudt, Kevin Willford, Lars Schneider, Martin Ågren,
Martin von Zweigbergk, Matheus Tavares, Michael Haggerty,
Patrick Steinhardt, Paul Jolly, Peter Kaestle, Phil Hord,
Philippe Blain, Phillip Wood, Pranit Bauva, Pratyush Yadav,
Rafael Silva, René Scharfe, Ross Light, Sergey Organov, SZEDER
Gábor, Taylor Blau, Thomas Ackermann, and Torsten Bögershausen.
[*] We are counting not just the authorship contribution but
issue reporting, testing and reviewing that are recorded
in the commit trailers.
Git 2.31 Release Notes (draft)
==
Updates since v2.30
---
Backward incompatible and other important changes
* The "pack-redundant" command, which has been left stale with almost
unusable performance issues, now warns loudly when it gets used, as
we no longer want to recommend its use (instead just "repack -d"
instead).
* The development community has adopted Contributor Covenant v2.0 to
update from v1.4 that we have been using.
* The support for deprecated PCRE1 library has been dropped.
UI, Workflows & Features
* The "--format=%(trailers)" mechanism gets enhanced to make it
easier to design output for machine consumption.
* When a user does not tell "git pull" to use rebase or merge, the
command gives a loud message telling a user to choose between
rebase or merge but creates a merge anyway, forcing users who would
want to rebase to redo the operation. Fix an early part of this
problem by tightening the condition to give the message---there is
no reason to stop or force the user to choose between rebase or
merge if the history fast-forwards.
* The configuration variable 'core.abbrev' can be set to 'no' to
force no abbreviation regardless of the hash algorithm.
* "git rev-parse" can be explicitly told to give output as absolute
or relative path with the `--path-format=(absolute|relative)` option.
* Bash completion (in contrib/) update to make it easier for
end-users to add completion for their custom "git" subcommands.
* "git maintenance" learned to drive scheduled maintenance on
platforms whose native scheduling methods are not 'cron'.
* After expiring a reflog and making a single commit, the reflog for
the branch would record a single entry that knows both @{0} and
@{1}, but we failed to answer "what commit were we on?", i.e. @{1}
* "git bundle" learns "--stdin" option to read its refs from the
standard input. Also, it now does not lose refs whey they point
at the same object.
* "git log" learned a new "--diff-merges=" option.
* "git ls-files" can and does show multiple entries when the index is
unmerged, which is a source for confusion unless -s/-u option is in
use. A new option --deduplicate has been introduced.
* `git worktree list` now annotates worktrees as prunable, shows
locked and prunable attributes in --porcelain mode, and gained
a --verbose option.
* "git clone" tries to locally check out the branch pointed at by
HEAD of the remote repository after it is done, but the protocol
did not convey the information necessary to do so when copying an
empty repository. The protocol v2 learned how to do so.
* There are other ways than ".." for a single token to denote a
"commit
[ANNOUNCE] Git v2.31.0-rc0
An early preview release Git v2.31.0-rc0 is now available for
testing at the usual places. It is comprised of 568 non-merge
commits since v2.30.0, contributed by 58 people, 18 of which are
new faces [*].
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.31.0-rc0' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.30.0 are as follows.
Welcome to the Git development community!
Andreas Bühmann, Andrew Klotz, Andrzej Hunt, Antonio Russo,
Arnaud Morin, Christian Walther, Clement Moyroud, Daniel Levin,
Daniel Troger, Harold Kim, Jacob Vosmaer, LeSeulArtichaut,
Sangeeta Jain, Seth House, Utku Gultopu, Vasyl Vavrychuk,
Vojtěch Knyttl, and ZheNing Hu.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Adam Dinwoodie, Ævar Arnfjörð Bjarmason,
Alex Henrie, brian m. carlson, Christian Couder, Denton Liu,
Derrick Stolee, Elijah Newren, Eric Sunshine, Eric Wong,
Felipe Contreras, Jeff King, Jiang Xin, Joey Salazar, Johannes
Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano, Kevin
Daudt, Lars Schneider, Martin Ågren, Martin von Zweigbergk,
Matheus Tavares, Michael Haggerty, Patrick Steinhardt, Paul
Jolly, Peter Kaestle, Phil Hord, Philippe Blain, Phillip Wood,
Pranit Bauva, Rafael Silva, René Scharfe, Ross Light, Sergey
Organov, SZEDER Gábor, Taylor Blau, Thomas Ackermann, and
Torsten Bögershausen.
[*] We are counting not just the authorship contribution but
mention for issue reporting, testing and reviewing in the
commits added during this cycle are all counted.
Git 2.31 Release Notes (draft)
==
Updates since v2.30
---
Backward incompatible and other important changes
* The "pack-redundant" command, which has been left stale with almost
unusable performance issues, now warns loudly when it gets used, as
we no longer want to recommend its use (instead just "repack -d"
instead).
* The development community has adopted Contributor Covenant v2.0 to
update from v1.4 that we have been using.
* The support for deprecated PCRE1 library has been dropped.
UI, Workflows & Features
* The "--format=%(trailers)" mechanism gets enhanced to make it
easier to design output for machine consumption.
* When a user does not tell "git pull" to use rebase or merge, the
command gives a loud message telling a user to choose between
rebase or merge but creates a merge anyway, forcing users who would
want to rebase to redo the operation. Fix an early part of this
problem by tightening the condition to give the message---there is
no reason to stop or force the user to choose between rebase or
merge if the history fast-forwards.
* The configuration variable 'core.abbrev' can be set to 'no' to
force no abbreviation regardless of the hash algorithm.
* "git rev-parse" can be explicitly told to give output as absolute
or relative path with the `--path-format=(absolute|relative)` option.
* Bash completion (in contrib/) update to make it easier for
end-users to add completion for their custom "git" subcommands.
* "git maintenance" learned to drive scheduled maintenance on
platforms whose native scheduling methods are not 'cron'.
* After expiring a reflog and making a single commit, the reflog for
the branch would record a single entry that knows both @{0} and
@{1}, but we failed to answer "what commit were we on?", i.e. @{1}
* "git bundle" learns "--stdin" option to read its refs from the
standard input. Also, it now does not lose refs whey they point
at the same object.
* "git log" learned a new "--diff-merges=" option.
* "git ls-files" can and does show multiple entries when the index is
unmerged, which is a source for confusion unless -s/-u option is in
use. A new option --deduplicate has been introduced.
* `git worktree list` now annotates worktrees as prunable, shows
locked and prunable attributes in --porcelain mode, and gained
a --verbose option.
* "git clone" tries to locally check out the branch pointed at by
HEAD of the remote repository after it is done, but the protocol
did not convey the information necessary to do so when copying an
empty repository. The protocol v2 learned how to do so.
* There are other ways than ".." for a single token to denote a
"commit range", namely "^!" and "^-", but "git
range-diff" did not under
[ANNOUNCE] Git v2.30.1
The latest maintenance release Git v2.30.1 is now available at the
usual places. This is to propagate obvious fixes that have
accumulated on the 'master' front down to the 2.30.x series.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.30.1'
tag and the 'maint' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
Git v2.30.1 Release Notes
=
This release is primarily to merge fixes accumulated on the 'master'
front to prepare for 2.31 release that are still relevant to 2.30.x
maintenance track.
Fixes since v2.30
-
* "git fetch --recurse-submodules" failed to update a submodule
when it has an uninitialized (hence of no interest to the user)
sub-submodule, which has been corrected.
* Command line error of "git rebase" are diagnosed earlier.
* "git stash" did not work well in a sparsely checked out working
tree.
* Some tests expect that "ls -l" output has either '-' or 'x' for
group executable bit, but setgid bit can be inherited from parent
directory and make these fields 'S' or 's' instead, causing test
failures.
* "git for-each-repo --config= " should not run for
any repository when the configuration variable is not defined
even once.
* "git mergetool --tool-help" was broken in 2.29 and failed to list
all the available tools.
* Fix for procedure to building CI test environment for mac.
* Newline characters in the host and path part of git:// URL are
now forbidden.
* When more than one commit with the same patch ID appears on one
side, "git log --cherry-pick A...B" did not exclude them all when a
commit with the same patch ID appears on the other side. Now it
does.
* Documentation for "git fsck" lost stale bits that has become
incorrect.
* Doc for packfile URI feature has been clarified.
* The implementation of "git branch --sort" wrt the detached HEAD
display has always been hacky, which has been cleaned up.
* Our setting of GitHub CI test jobs were a bit too eager to give up
once there is even one failure found. Tweak the knob to allow
other jobs keep running even when we see a failure, so that we can
find more failures in a single run.
Also contains minor documentation updates and code clean-ups.
Changes since v2.30.0 are as follows:
Adam Dinwoodie (1):
t4129: fix setfacl-related permissions failure
Antonio Russo (1):
t6016: move to lib-log-graph.sh framework
Daniel Levin (1):
git-p4: fix syncing file types with pattern
Derrick Stolee (1):
for-each-repo: do nothing on empty config
Elijah Newren (3):
t7012: add a testcase demonstrating stash apply bugs in sparse checkouts
stash: remove unnecessary process forking
stash: fix stash application in sparse-checkouts
Felipe Contreras (1):
test: bisect-porcelain: fix location of files
Jeff King (5):
git_connect_git(): forbid newlines in host and path
fsck: reject .gitmodules git:// urls with newlines
t5516: loosen "not our ref" error check
patch-ids: handle duplicate hashmap entries
p5303: avoid sed GNU-ism
Johannes Schindelin (1):
SKIP_DASHED_BUILT_INS: respect `config.mak`
Johannes Sixt (1):
annotate-tests: quote variable expansions containing path names
Jonathan Tan (1):
Doc: clarify contents of packfile sent as URI
Junio C Hamano (5):
parse-options: format argh like error messages
SubmittingPatches: tighten wording on "sign-off" procedure
ci/install-depends: attempt to fix "brew cask" stuff
Prepare for 2.30.1
Git 2.30.1
Martin Ågren (9):
t1300: remove duplicate test for `--file ../foo`
t1300: remove duplicate test for `--file no-such-file`
t1300: don't needlessly work with `core.foo` configs
pack-format.txt: document sizes at start of delta data
builtin/gc: don't peek into `struct lock_file`
commit-graph: don't peek into `struct lock_file`
midx: don't peek into `struct lock_file`
refs/files-backend: don't peek into `struct lock_file`
read-cache: try not to peek into `struct {lock_,temp}file`
Matheus Tavares (1):
t4129: don't fail if setgid is set in the test directory
Peter Kaestle (1):
submodules: fix of regression on fetching of non-init subsub-repo
Philippe Blain (3):
gitmodules.txt: fix 'GIT_WORK_TREE' variable name
mergetool--lib: fix '--tool-help' to correctly show available tools
ci: do not cancel all jobs of a matrix if one fails
René Scharfe (1):
RE: [PATCH v4 32/34] dt-bindings: misc: hddl_dev: Add hddl device management documentation
> On Fri, 29 Jan 2021 18:21:22 -0800, mgr...@linux.intel.com wrote: > > From: "C, Udhayakumar" > > > > Add hddl device management documentation > > > > The HDDL client driver acts as an software RTC to sync with network time. > > It abstracts xlink protocol to communicate with remote IA host. > > This driver exports the details about sensors available in the > > platform to remote IA host as xlink packets. > > This driver also handles device connect/disconnect events and > > identifies board id and soc id using gpio's based on platform configuration. > > > > Cc: Rob Herring > > Cc: devicet...@vger.kernel.org > > Signed-off-by: C Udhayakumar > > Signed-off-by: Mark Gross > > --- > > .../bindings/misc/intel,hddl-client.yaml | 114 ++ > > 1 file changed, 114 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/misc/intel,hddl-client.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt- > review/Documentation/devicetree/bindings/misc/intel,hddl- > client.example.dt.yaml: example-0: hddl@2032:reg:0: [0, 540147712, 0, > 2048] is too long > From schema: /usr/local/lib/python3.8/dist- > packages/dtschema/schemas/reg.yaml > > See https://patchwork.ozlabs.org/patch/1433603 > This lint warning is due to missing address-cells and size-cells fields. make dt_binding_check dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/misc/intel,hddl-client.yaml SCHEMA Documentation/devicetree/bindings/processed-schema.yaml CHKDT Documentation/devicetree/bindings/misc/intel,hddl-client.yaml DTC Documentation/devicetree/bindings/misc/intel,hddl-client.example.dt.yaml CHECK Documentation/devicetree/bindings/misc/intel,hddl-client.example.dt.yaml Will update the fix in next patch version. --- Thanks, Udhay > This check can fail if there are any dependencies. The base for a patch series > is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above error(s), > then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit.
RE: [PATCH v4 26/34] dt-bindings: misc: intel_tsens: Add tsens thermal bindings documentation
> On Fri, 29 Jan 2021 18:21:16 -0800, mgr...@linux.intel.com wrote: > > From: "C, Udhayakumar" > > > > Add device tree bindings for local host thermal sensors Intel Edge.AI > > Computer Vision platforms. > > > > The tsens module enables reading of on chip sensors present in the > > Intel Bay series SoC. In the tsens module various junction temperature > > and SoC temperature are reported using thermal subsystem and i2c > > subsystem. > > > > Temperature data reported using thermal subsystem will be used for > > various cooling agents such as DVFS, fan control and shutdown the > > system in case of critical temperature. > > > > Temperature data reported using i2c subsytem will be used by platform > > manageability software running in remote host. > > > > Cc: Rob Herring > > Cc: devicet...@vger.kernel.org > > Acked-by: mark gross > > Signed-off-by: C Udhayakumar > > Signed-off-by: Mark Gross > > --- > > .../bindings/misc/intel,intel-tsens.yaml | 118 ++ > > 1 file changed, 118 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt- > review/Documentation/devicetree/bindings/misc/intel,intel- > tsens.example.dt.yaml: example-0: tsens@2026:reg:0: [0, 539361280, 0, > 256] is too long > From schema: /usr/local/lib/python3.8/dist- > packages/dtschema/schemas/reg.yaml > > See https://patchwork.ozlabs.org/patch/1433609 > This lint warning is due to missing address-cells and size-cells fields. make dt_binding_check dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml CHKDT Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml DTC Documentation/devicetree/bindings/misc/intel,intel-tsens.example.dt.yaml CHECK Documentation/devicetree/bindings/misc/intel,intel-tsens.example.dt.yaml Will update the fix in next patch version. --- Thanks, Udhay > This check can fail if there are any dependencies. The base for a patch series > is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above error(s), > then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit.
RE: [PATCH v3 28/34] misc: Intel tsens IA host driver.
> On Fri, 2021-01-29 at 18:20 -0800, mgr...@linux.intel.com wrote:
> > From: "C, Udhayakumar"
> >
> > Add Intel tsens IA host driver for Intel Edge.AI Computer Vision
> > platforms.
> []
> > diff --git a/drivers/misc/intel_tsens/intel_tsens_host.c
> > b/drivers/misc/intel_tsens/intel_tsens_host.c
> []
> > +static int tsens_i2c_smbus_read_byte_data(struct i2c_client *i2c, u8
> command,
> > + u8 *i2c_val)
> > +{
> > + union i2c_smbus_data data;
> > + int status;
> > +
> > + status = i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
> > + I2C_SMBUS_READ, command,
> > + I2C_SMBUS_BYTE_DATA, );
>
> this can fail
>
> > + *i2c_val = data.byte;
>
> Is it appropriate to set the value if it failed and data was not initialized?
>
Thanks for the feedback, I will update as below in next patch version.
if (!status)
*i2c_val = data.byte;
> > + return status;
> > +}
> > +
> > +/**
> > + * intel_tsens_get_temp - get updated temperatue
>
> Might want to use codespell on all files.
Yes we have ran codespell before submitting, looks like codespell dictionary
doesn't have replacement for ' temperatue'.
It has only below words.
temerature->temperature
tempertaure->temperature
temperture->temperature
--
udhay
>
My Dearest Beloved in Christ ,
My Dearest Beloved in Christ , Happy new year 2021. How are you today? I hope all is well with you and your family to the glory of Almighty God. My name is Mrs. Rosemary C. Williams, I am married to Late MR. C. Williams,who works in SAUDI ARABIA Embassy in Africa for nine years and also a Gold Merchant before he died in the year 2010. My dear I am divinely touched in my heart to offer my inheritance fund through you for Charity work to help the less privileges, orphans and motherless children. My dear I am written you this message because I am suffering from esophageal Liver Cancer for years now and I have undergone series of cancer treatments but no avail. Recently I went for a medical check up and my doctor privately told me that I might not survive this cancer illness for the next 3 weeks because the cancer has damage my Liver. Having known to my condition,I have decided to donate my inheritance fund to you the sum of (US$3.250.000) Three Million Two Hundred and fifty Thousand United States Dollars.My dear I want you to use this fund for Charity work in helping the less privileges, orphans and motherless children.My dear I have decided to hand over this fund to you so that you will conduct a vastly charity work and dispense the fund to the glory of God in helping the less privileges and orphans around. My dear immediately I hear from you I will give you all the information about this Fund with our Bank contact detail.I pray that God will be with you in as you desire to do this Charity work. I'm waiting to receive your reply. Best Regards, Your sister in Christ.
RE: [PATCH v2 29/34] Intel tsens i2c slave driver.
> On Tue, Jan 26, 2021 at 12:39 AM mark gross > wrote: > > > > On Mon, Jan 11, 2021 at 11:15:06PM -0800, Randy Dunlap wrote: > > > On 1/8/21 1:25 PM, mgr...@linux.intel.com wrote: > > > > diff --git a/drivers/misc/intel_tsens/Kconfig > > > > b/drivers/misc/intel_tsens/Kconfig > > > > index 8b263fdd80c3..c2138339bd89 100644 > > > > --- a/drivers/misc/intel_tsens/Kconfig > > > > +++ b/drivers/misc/intel_tsens/Kconfig > > > > @@ -14,6 +14,20 @@ config INTEL_TSENS_LOCAL_HOST > > > > Say Y if using a processor that includes the Intel VPU such as > > > > Keem Bay. If unsure, say N. > > > > > > > > +config INTEL_TSENS_I2C_SLAVE > > > > + bool "I2C slave driver for intel tsens" > > > > > > Why bool instead of tristate? > > Becuase the I2C driver depends on a file scoped global i2c_plat_data > > instanciated in the INTELL_TSENS_LOCAL_HOST DRIVER > > (intel_tsens_thermal.[ch]) > > > > Udhaya, would you care to comment further? > > > > > + depends on INTEL_TSENS_LOCAL_HOST > > > > + select I2C > > > > + select I2C_SLAVE > > Please make this 'depends on I2C=y && I2C_SLAVE' instead of 'select' > in this case. A random driver should never force-enable another subsystem. > Will update in v2 version of patch. Thanks for feedback. > Arnd
RE: [PATCH v2 29/34] Intel tsens i2c slave driver.
> On Mon, Jan 11, 2021 at 11:15:06PM -0800, Randy Dunlap wrote: > > On 1/8/21 1:25 PM, mgr...@linux.intel.com wrote: > > > diff --git a/drivers/misc/intel_tsens/Kconfig > > > b/drivers/misc/intel_tsens/Kconfig > > > index 8b263fdd80c3..c2138339bd89 100644 > > > --- a/drivers/misc/intel_tsens/Kconfig > > > +++ b/drivers/misc/intel_tsens/Kconfig > > > @@ -14,6 +14,20 @@ config INTEL_TSENS_LOCAL_HOST > > > Say Y if using a processor that includes the Intel VPU such as > > > Keem Bay. If unsure, say N. > > > > > > +config INTEL_TSENS_I2C_SLAVE > > > + bool "I2C slave driver for intel tsens" > > > > Why bool instead of tristate? > Becuase the I2C driver depends on a file scoped global i2c_plat_data > instanciated in the INTELL_TSENS_LOCAL_HOST DRIVER > (intel_tsens_thermal.[ch]) > > Udhaya, would you care to comment further? > > --mark > As Mark mentioned above, i2c_plat_data from intel_tsens_thermal.[ch] will be used by tsens_i2c client driver. > > > > > > + depends on INTEL_TSENS_LOCAL_HOST > > > + select I2C > > > + select I2C_SLAVE > > > + help > > > + This option enables tsens i2c slave driver. > > > > I2C > > Will update in v2 version of patch. Thanks for feedback. > > > + > > > + This driver is used for reporting thermal data via I2C > > > + SMBUS to remote host. > > > + Enable this option if you want to have support for thermal > > > + management controller > > > > controller. > > Will update in v2 version of patch. Thanks for feedback. > > > + Say Y if using a processor that includes the Intel VPU such as > > > + Keem Bay. If unsure, say N. > > > > > > -- > > ~Randy > >
Re: [PATCH 1/3] blk-mq: allow hardware queue to get more tag while sharing a tag set
Hi On 2020/12/29 9:15, Ming Lei wrote: Just wondering why you try to set 128 via sysfs for all disks? If you do that, you should know the potential result given the whole tags queue depth is just 128. It's just a extreme example to show the unexpected result of "always return true from hctx_may_queue()". Thanks, Yu Kuai
[ANNOUNCE] Git v2.30.0
The latest feature release Git v2.30.0 is now available at the usual places. It comprises 495 non-merge commits since v2.29.0, contributed by 83 people, 29 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.30.0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose patches weren't in v2.29.0 are as follows. Welcome to the Git development community! Alexey, Amanda Shafack, Arusekk, Baptiste Fontaine, Bradley M. Kuhn, Caleb Tillman, Charvi Mendiratta, Daniel Duvall, Daniel Gurney, Dennis Ameling, Javier Spagnoletti, Jinoh Kang, Joey Salazar, Konrad Borowski, m4sk1n, Marlon Rac Cambasis, Martin Schön, Michał Kępień, Nate Avers, Nipunn Koorapati, Rafael Silva, Robert Karszniewicz, Samuel Čavoj, Sean Barag, Sibo Dong, Simão Afonso, Sohom Datta, Thomas Koutcher, and Victor Engmark. Returning contributors who helped this release are as follows. Thanks for your continued support. Adam Spiers, Ævar Arnfjörð Bjarmason, Alexander Shopov, Alex Vandiver, Arnout Engelen, brian m. carlson, Christian Couder, Chris. Webster, David Aguilar, Denton Liu, Derrick Stolee, Dimitriy Ryazantcev, Đoàn Trần Công Danh, Drew DeVault, Elijah Newren, Emily Shaffer, Emir Sarı, Eric Sunshine, Felipe Contreras, Han-Wen Nienhuys, Jean-Noël Avila, Jeff Hostetler, Jeff King, Jiang Xin, Johannes Berg, Johannes Schindelin, Jonathan Tan, Jordi Mas, Josh Steadmon, Junio C Hamano, Kyle Meyer, Martin Ågren, Matheus Tavares, Matthias Rüster, Nicolas Morey-Chaisemartin, Patrick Steinhardt, Peter Kaestle, Peter Krefting, Philippe Blain, Phillip Wood, Pranit Bauva, Pratyush Yadav, Ramsay Jones, Randall S. Becker, René Scharfe, Sergey Organov, Serg Tereshchenko, Srinidhi Kaushik, Stefan Haller, Štěpán Němec, SZEDER Gábor, Taylor Blau, Trần Ngọc Quân, and Yi-Jyun Pan. Git 2.30 Release Notes == Updates since v2.29 --- UI, Workflows & Features * Userdiff for PHP update. * Userdiff for Rust update. * Userdiff for CSS update. * The command line completion script (in contrib/) learned that "git stash show" takes the options "git diff" takes. * "git worktree list" now shows if each worktree is locked. This possibly may open us to show other kinds of states in the future. * "git maintenance", an extended big brother of "git gc", continues to evolve. * "git push --force-with-lease[=]" can easily be misused to lose commits unless the user takes good care of their own "git fetch". A new option "--force-if-includes" attempts to ensure that what is being force-pushed was created after examining the commit at the tip of the remote ref that is about to be force-replaced. * "git clone" learned clone.defaultremotename configuration variable to customize what nickname to use to call the remote the repository was cloned from. * "git checkout" learned to use checkout.guess configuration variable and enable/disable its "--[no-]guess" option accordingly. * "git resurrect" script (in contrib/) learned that the object names may be longer than 40-hex depending on the hash function in use. * "git diff A...B" learned "git diff --merge-base A B", which is a longer short-hand to say the same thing. * A sample 'push-to-checkout' hook, that performs the same as what the built-in default action does, has been added. * "git diff" family of commands learned the "-I" option to ignore hunks whose changed lines all match the given pattern. * The userdiff pattern learned to identify the function definition in POSIX shells and bash. * "git checkout-index" did not consistently signal an error with its exit status, but now it does. * A commit and tag object may have CR at the end of each and every line (you can create such an object with hash-object or using --cleanup=verbatim to decline the default clean-up action), but it would make it impossible to have a blank line to separate the title from the body of the message. We are now more lenient and accept a line with lone CR on it as a blank line, too. * Exit codes from "git remote add" etc. were not usable by scripted callers, but now they are. * "git archive" now allows compression level higher than "-9" when generating tar.gz output. * Zsh autocompletion (in contrib/) update. * The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64
Re: [PATCH 1/3] blk-mq: allow hardware queue to get more tag while sharing a tag set
Hi On 2020/12/28 16:28, Ming Lei wrote: Another candidate solution may be to always return true from hctx_may_queue() for this kind of queue because queue_depth has provided fair allocation for each LUN, and looks not necessary to do that again. If always return true from hctx_may_queue() in this case, for example, we set queue_depth to 128(if can't, the biggger, the better) for all disks, and test with numjobs=64. The result should be one disk with high iops, and the rest very low. So I think it's better to ensure the max tags a disk can get in this case. Thanks! Yu Kuai
Re: [PATCH 1/3] blk-mq: allow hardware queue to get more tag while sharing a tag set
Hi, On 2020/12/27 19:58, Ming Lei wrote: Hi Yu Kuai, On Sat, Dec 26, 2020 at 06:28:06PM +0800, Yu Kuai wrote: When sharing a tag set, if most disks are issuing small amount of IO, and only a few is issuing a large amount of IO. Current approach is to limit the max amount of tags a disk can get equally to the average of total tags. Thus the few heavy load disk can't get enough tags while many tags are still free in the tag set. Yeah, current approach just allocates same share for each active queue which is evaluated in each timeout period. That said you are trying to improve the following case: - heavy IO on one or several disks, and the average share for these disks become bottleneck of IO performance - small amount IO on other disks attached to the same host, and all IOs are submitted to disk in <30 second period. Just wondering if you may share the workload you are trying to optimize, or it is just one improvement in theory? And what is the disk(hdd, ssd or nvme) and host? And how many disks in your setting? And how deep the tagset depth is? The details of the environment that we found the problem are as follows: total driver tags: 128 number of disks: 13 (network drive, and they form a dm-multipath) default queue_depth: 32 disk performance: when test with 4k randread and single thread, iops is 300. And can up to 4000 with 32 thread. test cmd: fio -ioengine=psync -numjobs=32 ... We found that mpath will issue sg_io periodically(about 15s)，which lead to active_queues setting to 13 for about 5s in every 15s. By the way, I'm not sure this is a common scenario, however, sq don't have such problem, Thanks Yu Kuai
Re: [ANNOUNCE] Git v2.30.0-rc2
Thanks.
[ANNOUNCE] Git v2.30.0-rc2
on, Development Support etc. * Use "git archive" more to produce the release tarball. * GitHub Actions automated test improvement to skip tests on a tree identical to what has already been tested. * Test-coverage for running commit-graph task "git maintenance" has been extended. * Our test scripts can be told to run only individual pieces while skipping others with the "--run=..." option; they were taught to take a substring of test title, in addition to numbers, to name the test pieces to run. * Adjust tests so that they won't scream when the default initial branch name is changed to 'main'. * Rewriting "git bisect" in C continues. * More preliminary tests have been added to document desired outcome of various "directory rename" situations. * Micro clean-up of a couple of test scripts. * "git diff" and other commands that share the same machinery to compare with working tree files have been taught to take advantage of the fsmonitor data when available. * The code to detect premature EOF in the sideband demultiplexer has been cleaned up. * Test scripts are being prepared to transition of the default branch name to 'main'. * "git fetch --depth=" over the stateless RPC / smart HTTP transport handled EOF from the client poorly at the server end. * A specialization of hashmap that uses a string as key has been introduced. Hopefully it will see wider use over time. * "git bisect start/next" in a large span of history spends a lot of time trying to come up with exactly the half-way point; this can be optimized by stopping when we see a commit that is close enough to the half-way point. * A lazily defined test prerequisite can now be defined in terms of another lazily defined test prerequisite. * Expectation for the original contributor after responding to a review comment to use the explanation in a patch update has been described. * Multiple "credential-store" backends can race to lock the same file, causing everybody else but one to fail---reattempt locking with some timeout to reduce the rate of the failure. * "git-parse-remote" shell script library outlived its usefulness. * Like die() and error(), a call to warning() will also trigger a trace2 event. * Use of non-reentrant localtime() has been removed. * Non-reentrant time-related library functions and ctime/asctime with awkward calling interfaces are banned from the codebase. Fixes since v2.29 - * In 2.29, "--committer-date-is-author-date" option of "rebase" and "am" subcommands lost the e-mail address by mistake, which has been corrected. (merge 5f35edd9d7 jk/committer-date-is-author-date-fix later to maint). * "git checkout -p A...B [-- ]" did not work, even though the same command without "-p" correctly used the merge-base between commits A and B. (merge 35166b1fb5 dl/checkout-p-merge-base later to maint). * The side-band status report can be sent at the same time as the primary payload multiplexed, but the demultiplexer on the receiving end incorrectly split a single status report into two, which has been corrected. (merge 712b0377db js/avoid-split-sideband-message later to maint). * "git fast-import" wasted a lot of memory when many marks were in use. (merge 3f018ec716 jk/fast-import-marks-alloc-fix later to maint). * A test helper "test_cmp A B" was taught to diagnose missing files A or B as a bug in test, but some tests legitimately wanted to notice a failure to even create file B as an error, in addition to leaving the expected result in it, and were misdiagnosed as a bug. This has been corrected. (merge 262d5ad5a5 es/test-cmp-typocatcher later to maint). * When "git commit-graph" detects the same commit recorded more than once while it is merging the layers, it used to die. The code now ignores all but one of them and continues. (merge 85102ac71b ds/commit-graph-merging-fix later to maint). * The meaning of a Signed-off-by trailer can vary from project to project; this and also what it means to this project has been clarified in the documentation. (merge 3abd4a67d9 bk/sob-dco later to maint). * "git credential' didn't honor the core.askPass configuration variable (among other things), which has been corrected. (merge 567ad2c0f9 tk/credential-config later to maint). * Dev support to catch a tentative definition of a variable in our C code as an error. (merge 5539183622 jk/no-common later to maint). * "git rebase --rebase-merges" did not correctly pass --gpg-sign command line option to underlying "git merge" when replaying a merge using non-default merge strategy or when replaying an octopus merge (because repl
Re: k10temp: ZEN3 readings are broken
Am Mi., 23. Dez. 2020 um 11:41 Uhr schrieb Jan Engelhardt : > > > On Tuesday 2020-12-22 04:58, Guenter Roeck wrote: > >On 12/21/20 5:45 PM, Gabriel C wrote: > >> Hello Guenter, > >> > >> while trying to add ZEN3 support for zenpower out of tree modules, I find > >> out > >> the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even > >> ). > > > >[...] since I do not have time to actively maintain > >the driver, since each chip variant seems to use different addresses and > >scales, > >and since the information about voltages and currents is unpublished by AMD, > >I'll remove support for voltage/current readings from the upstream driver. > > I support that decision. > > /proc/cpuinfo::AMD Ryzen 7 3700X 8-Core Processor, fam 23 model 113 step 0 > > A synthetic load (perl -e '1 while 1') x 16 shows: > Adapter: PCI adapter > Vcore:+1.28 V > Vsoc: +1.02 V > Tctl: +94.8°C > Tdie: +94.8°C > Tccd1:+94.8°C > Icore: +76.00 A > Isoc: +6.75 A > > A BOINC workload on average: > k10temp-pci-00c3 > Adapter: PCI adapter > Vcore:+1.17 V > Vsoc: +1.02 V > Tctl: +94.9°C > Tdie: +94.9°C > Tccd1:+95.0°C > Icore: +88.00 A > Isoc: +8.00 A > > The BOINC workload, when it momentarily spikes: > Adapter: PCI adapter > Vcore:+1.32 V > Vsoc: +1.02 V > Tctl: +94.1°C > Tdie: +94.1°C > Tccd1:+96.0°C > Icore: +105.00 A > Isoc: +7.75 A > > For a processor sold as a 65 W part, observing reported sensors as > 88 A x 1.17 V + 8 A x 1.02 V = 111.12 W just can't be. We are off by a > factor of about 2. Just before I forget, even with 100% correct code you could still be off by a factor of 2 with a broken BIOS or a vendor who is trying to bypass AMD spec limits. See as an example this topic: https://cutt.ly/7h1bT48 Best Regards, Gabriel C
Re: k10temp: ZEN3 readings are broken
Am Mi., 23. Dez. 2020 um 11:41 Uhr schrieb Jan Engelhardt : > > > On Tuesday 2020-12-22 04:58, Guenter Roeck wrote: > >On 12/21/20 5:45 PM, Gabriel C wrote: > >> Hello Guenter, > >> > >> while trying to add ZEN3 support for zenpower out of tree modules, I find > >> out > >> the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even > >> ). > > > >[...] since I do not have time to actively maintain > >the driver, since each chip variant seems to use different addresses and > >scales, > >and since the information about voltages and currents is unpublished by AMD, > >I'll remove support for voltage/current readings from the upstream driver. > > I support that decision. > > /proc/cpuinfo::AMD Ryzen 7 3700X 8-Core Processor, fam 23 model 113 step 0 > > A synthetic load (perl -e '1 while 1') x 16 shows: > Adapter: PCI adapter > Vcore:+1.28 V > Vsoc: +1.02 V > Tctl: +94.8°C > Tdie: +94.8°C > Tccd1:+94.8°C > Icore: +76.00 A > Isoc: +6.75 A > > A BOINC workload on average: > k10temp-pci-00c3 > Adapter: PCI adapter > Vcore:+1.17 V > Vsoc: +1.02 V > Tctl: +94.9°C > Tdie: +94.9°C > Tccd1:+95.0°C > Icore: +88.00 A > Isoc: +8.00 A > > The BOINC workload, when it momentarily spikes: > Adapter: PCI adapter > Vcore:+1.32 V > Vsoc: +1.02 V > Tctl: +94.1°C > Tdie: +94.1°C > Tccd1:+96.0°C > Icore: +105.00 A > Isoc: +7.75 A > > For a processor sold as a 65 W part, observing reported sensors as > 88 A x 1.17 V + 8 A x 1.02 V = 111.12 W just can't be. We are off by a > factor of about 2. Yes, those are wrong, bc the code is wrong. ZEN2 desktop is mixed with ZEN2 Server/TR code. Best Reagrds, Gabriel C
Re: k10temp: ZEN3 readings are broken
Am Di., 22. Dez. 2020 um 07:16 Uhr schrieb Guenter Roeck : > > On Tue, Dec 22, 2020 at 05:33:17AM +0100, Gabriel C wrote: > [ ... ] > > At least is what the weird amd_energy driver added and since is only > > supporting > > fam 17h model 0x31 which is TR 3000 & SP3 Rome, I guess fam 19h 0x1 is > > TR/SP3 ZEN3. > > The limited model support is because people nowadays are not willing to > accept that reported values may not always be perfect ... and the reported > energy for non-server parts is known to be not always perfect. Kind of an > odd situation: If we support non-server parts, we have people complain > that values are not perfect. If we only support server parts, we have > people complain that only server parts are supported. For us, that is > a lose-lose situation. I used to think that is is better to report > _something_, but the (sometimes loud) complaints about lack of perfection > teached me a lesson. So now my reaction is to drop support if I get > complaints about lack of perfection. > I agree it is an odd situation with these modules, but having something is better than nothing. As for the amd_energy driver, yes it is off on some platforms by 2%-5% or alike but without having that support in the kernel, regardless of the module, we cannot ever come to perfection or near it. For both k10temp & amd_energy driver I suggest to not drop the support but add kernel modules options disabled by default, much like a lot laptop platform drivers have for different reasons. The amd_energy driver could have some any_ryzen option which turned off by default. That way people may decide if they want to use it even when not 100% perfect and can report back on platforms the reporting is accurate. Waiting for AMD to give us ID of what may be in their eyes accurate is like waiting for pigs to fly. The k10temp module much like the same, some experimental_voltage_report module option will be fine for now, I think. I'm also sure owner of AMD HW will help out optimizing and maintaining the code. > Guenter Best Regards, Gabriel C.
Re: k10temp: ZEN3 readings are broken
Am Di., 22. Dez. 2020 um 05:33 Uhr schrieb Wei Huang :
>
>
>
> On 12/21/20 9:58 PM, Guenter Roeck wrote:
> > Hi,
> >
> > On 12/21/20 5:45 PM, Gabriel C wrote:
> >> Hello Guenter,
> >>
> >> while trying to add ZEN3 support for zenpower out of tree modules, I find
> >> out
> >> the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even
> >> ).
> >>
> >> commit 55163a1c00fcb526e2aa9f7f952fb38d3543da5e added:
> >>
> >> case 0x0 ... 0x1: /* Zen3 */
> >>
> >> however, this is wrong, we look for a model which is 0x21 for ZEN3,
> >> these seem to
> >> be steppings?
>
> These are model numbers for server CPUs. I believe 0x21 is for desktop
> CPUs. In other words, current upstream code doesn't support your CPUs.
> You are welcomed to add support for 0x21, but it is wrong to remove
> support for 0x00/0x01.
I figured that myself after seeing what was committed to amd_energy driver.
Would be better you as the author of the patch to have a better commit
message to start with.
commit 55163a1c00fcb526e2aa9f7f952fb38d3543da5e
Author: Wei Huang
Date: Mon Sep 14 15:07:15 2020 -0500
hwmon: (k10temp) Add support for Zen3 CPUs
Which you didn't. That should read:
"Added support for NOT yet released SP3 ZEN3 CPU"
Right?
>
> >>
> >> Also, PLANE0/1 are wrong too, Icore has zero readouts even when fixing
> >> the model.
> >>
> >> Looking at these ( there is something missing for 0x71 ZEN2 Ryzens
> >> also ) that should be:
> >>
> >> PLANE0 (ZEN_SVI_BASE + 0x10)
> >> PLANE1 (ZEN_SVI_BASE + 0xc)
>
> Same problem here with model 0x71. 0x31 is for server CPUs.
Yes, is why I split both in my 'guess what the eff is this about' patch.
0x31 is TR 3000/ Sp3 ZEN2 , while 0x71 is ZEN2 Desktop.
>
> >>
> >> Which is the same as for ZEN2 >= 0x71. Since this is not really
> >> documented and I have some
> >> confirmations of these numbers from *somewhere* :-) I created a demo patch
> >> only.
> >>
> >> I would like AMD people to really have a look at the driver and
> >> confirm the changes, since
> >> getting information from *somewhere*, dosen't mean they are 100%
> >> correct. However, the driver
> >> is working with these changes.
> >>
> >> In any way the model needs changing to 0x21 even if we let the other
> >> readings broken.
> >>
> >> There is my demo patch:
> >>
> >> https://crazy.dev.frugalware.org/fix-ZEN2-ZEN3-test1.patch
>
> For family 19h, the patch should look like. But this might not matter
> anymore as suggested by Guenter below.
>
> /* F19h thermal registers through SMN */
> #define F19H_M01_SVI_TEL_PLANE0 (ZEN_SVI_BASE + 0x14)
> #define F19H_M01_SVI_TEL_PLANE1 (ZEN_SVI_BASE + 0x10)
> +/* Zen3 Ryzen */
> +#define F19H_M21H_SVI_TEL_PLANE0 (ZEN_SVI_BASE + 0x10)
> +#define F19H_M21H_SVI_TEL_PLANE1 (ZEN_SVI_BASE + 0xc)
>
> Then add the following change:
>
> switch (boot_cpu_data.x86_model) {
> case 0x0 ... 0x1: /* Zen3 */
> data->show_current = true;
> data->svi_addr[0] = F19H_M01_SVI_TEL_PLANE0;
> data->svi_addr[1] = F19H_M01_SVI_TEL_PLANE1;
> data->cfactor[0] = F19H_M01H_CFACTOR_ICORE;
> data->cfactor[1] = F19H_M01H_CFACTOR_ISOC;
> k10temp_get_ccd_support(pdev, data, 8);
> + case 0x21: /* Zen3 */
> + data->show_current = true;
> + data->svi_addr[0] = F19H_M21H_SVI_TEL_PLANE0;
> + data->svi_addr[1] = F19H_M21H_SVI_TEL_PLANE1;
> + data->cfactor[0] = F19H_M01H_CFACTOR_ICORE;
> + data->cfactor[1] = F19H_M01H_CFACTOR_ISOC;
> + k10temp_get_ccd_support(pdev, data, 8);
>
> >>
You are a really funny guy.
After _all_ these are YOUR Company CPUs, and want me to fix these without docs?
Sure I can, but the confusion started with your wrong commit message.
Besides, is that how AMD operates now?
Let the customer pay thousands of euros for HW and then tell
him to fix or add drivers support himself? Very interesting.
And yes it matters even after removing these.
case 0x0 ... 0x1: /* Zen3 SP3 ( NOT YET RELEASED ) */
case 0x21: /* Zen3 Ryzen Desktop */
Right?
> >> Also, there is some discuss and testing for both dri
Re: k10temp: ZEN3 readings are broken
Am Di., 22. Dez. 2020 um 04:58 Uhr schrieb Guenter Roeck : > > Hi, > > On 12/21/20 5:45 PM, Gabriel C wrote: > > Hello Guenter, > > > > while trying to add ZEN3 support for zenpower out of tree modules, I find > > out > > the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even > > ). > > > > commit 55163a1c00fcb526e2aa9f7f952fb38d3543da5e added: > > > > case 0x0 ... 0x1: /* Zen3 */ > > > > however, this is wrong, we look for a model which is 0x21 for ZEN3, > > these seem to > > be steppings? > > > > Also, PLANE0/1 are wrong too, Icore has zero readouts even when fixing > > the model. > > > > Looking at these ( there is something missing for 0x71 ZEN2 Ryzens > > also ) that should be: > > > > PLANE0 (ZEN_SVI_BASE + 0x10) > > PLANE1 (ZEN_SVI_BASE + 0xc) > > > > Which is the same as for ZEN2 >= 0x71. Since this is not really > > documented and I have some > > confirmations of these numbers from *somewhere* :-) I created a demo patch > > only. > > > > I would like AMD people to really have a look at the driver and > > confirm the changes, since > > getting information from *somewhere*, dosen't mean they are 100% > > correct. However, the driver > > is working with these changes. > > > > In any way the model needs changing to 0x21 even if we let the other > > readings broken. > > > > There is my demo patch: > > > > https://crazy.dev.frugalware.org/fix-ZEN2-ZEN3-test1.patch > > > > Also, there is some discuss and testing for both drivers: > > > > https://github.com/ocerman/zenpower/issues/39 > > > > Thanks for the information. However, since I do not have time to actively > maintain > the driver, since each chip variant seems to use different addresses and > scales, > and since the information about voltages and currents is unpublished by AMD, > I'll remove support for voltage/current readings from the upstream driver. > I plan to send the patch doing that to Linus shortly after the commit window > closes (or even before that). Yes I saw that commit, and it is a shame how AMD is unwilling to support 'sensors' in their CPUs in 2020. I can understand why you can't maintain that mess, but I don't understand AMD. However, it is not only about the Voltage, ZEN3 Ryzen Desktop CPUs, have a model ID of 0x21, meaning while only 0x0 & 0x1 is here now we only hit the else code and shows some weird temps, and no info about CCD's. See: smpboot: CPU0: AMD Ryzen 7 5800X 8-Core Processor (family: 0x19, model: 0x21, stepping: 0x0) smpboot: CPU0: AMD Ryzen 9 5900X 12-Core Processor (family: 0x19, model: 0x21, stepping: 0x0) etc... So we need at least: ... case 0x0 ... 0x1: /* ZEN3 SP3 ?!? */ case 0x21: /* ZEN3 Ryzen Desktop */ ... I believe 0x0 & 0x1 are NOT yet released EPYC/TR CPUs based on ZEN3. At least is what the weird amd_energy driver added and since is only supporting fam 17h model 0x31 which is TR 3000 & SP3 Rome, I guess fam 19h 0x1 is TR/SP3 ZEN3. ( BTW off-topic this amd_energ driver should be removed or depend on BROKEN, since is working as root only and breaks the sensors command output ) If that is the case, even if you remove the code, I think I understand how the PLANEX registers are working and can at least help the out of tree driver with these. Maybe one day AMD is getting serious, who knows. > > Thanks, > Guenter Best Regards, Gabriel C.
k10temp: ZEN3 readings are broken
Hello Guenter, while trying to add ZEN3 support for zenpower out of tree modules, I find out the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even ). commit 55163a1c00fcb526e2aa9f7f952fb38d3543da5e added: case 0x0 ... 0x1: /* Zen3 */ however, this is wrong, we look for a model which is 0x21 for ZEN3, these seem to be steppings? Also, PLANE0/1 are wrong too, Icore has zero readouts even when fixing the model. Looking at these ( there is something missing for 0x71 ZEN2 Ryzens also ) that should be: PLANE0 (ZEN_SVI_BASE + 0x10) PLANE1 (ZEN_SVI_BASE + 0xc) Which is the same as for ZEN2 >= 0x71. Since this is not really documented and I have some confirmations of these numbers from *somewhere* :-) I created a demo patch only. I would like AMD people to really have a look at the driver and confirm the changes, since getting information from *somewhere*, dosen't mean they are 100% correct. However, the driver is working with these changes. In any way the model needs changing to 0x21 even if we let the other readings broken. There is my demo patch: https://crazy.dev.frugalware.org/fix-ZEN2-ZEN3-test1.patch Also, there is some discuss and testing for both drivers: https://github.com/ocerman/zenpower/issues/39 Best Regards, Gabriel C
[ANNOUNCE] Git v2.30.0-rc1
A release candidate Git v2.30.0-rc1 is now available for testing at the usual places. It is comprised of 455 non-merge commits since v2.29.0, contributed by 72 people, 26 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.30.0-rc1' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.29.0 are as follows. Welcome to the Git development community! Alexey, Amanda Shafack, Bradley M. Kuhn, Caleb Tillman, Charvi Mendiratta, Daniel Duvall, Daniel Gurney, Dennis Ameling, Javier Spagnoletti, Jinoh Kang, Joey Salazar, Konrad Borowski, Marlon Rac Cambasis, Martin Schön, Michał Kępień, Nate Avers, Nipunn Koorapati, Rafael Silva, Robert Karszniewicz, Samuel Čavoj, Sean Barag, Sibo Dong, Simão Afonso, Sohom Datta, Thomas Koutcher, and Victor Engmark. Returning contributors who helped this release are as follows. Thanks for your continued support. Adam Spiers, Ævar Arnfjörð Bjarmason, Alex Vandiver, Arnout Engelen, brian m. carlson, Christian Couder, Chris. Webster, David Aguilar, Denton Liu, Derrick Stolee, Dimitriy Ryazantcev, Đoàn Trần Công Danh, Drew DeVault, Elijah Newren, Emily Shaffer, Eric Sunshine, Felipe Contreras, Han-Wen Nienhuys, Jeff Hostetler, Jeff King, Jiang Xin, Johannes Berg, Johannes Schindelin, Jonathan Tan, Josh Steadmon, Junio C Hamano, Kyle Meyer, Martin Ågren, Matheus Tavares, Nicolas Morey-Chaisemartin, Patrick Steinhardt, Peter Kaestle, Philippe Blain, Phillip Wood, Pranit Bauva, Pratyush Yadav, Ramsay Jones, Randall S. Becker, René Scharfe, Sergey Organov, Serg Tereshchenko, Srinidhi Kaushik, Stefan Haller, Štěpán Němec, SZEDER Gábor, and Taylor Blau. Git 2.30 Release Notes (draft) == Updates since v2.29 --- UI, Workflows & Features * Userdiff for PHP update. * Userdiff for Rust update. * Userdiff for CSS update. * The command line completion script (in contrib/) learned that "git stash show" takes the options "git diff" takes. * "git worktree list" now shows if each worktree is locked. This possibly may open us to show other kinds of states in the future. * "git maintenance", an extended big brother of "git gc", continues to evolve. * "git push --force-with-lease[=]" can easily be misused to lose commits unless the user takes good care of their own "git fetch". A new option "--force-if-includes" attempts to ensure that what is being force-pushed was created after examining the commit at the tip of the remote ref that is about to be force-replaced. * "git clone" learned clone.defaultremotename configuration variable to customize what nickname to use to call the remote the repository was cloned from. * "git checkout" learned to use checkout.guess configuration variable and enable/disable its "--[no-]guess" option accordingly. * "git resurrect" script (in contrib/) learned that the object names may be longer than 40-hex depending on the hash function in use. * "git diff A...B" learned "git diff --merge-base A B", which is a longer short-hand to say the same thing. * A sample 'push-to-checkout' hook, that performs the same as what the built-in default action does, has been added. * "git diff" family of commands learned the "-I" option to ignore hunks whose changed lines all match the given pattern. * The userdiff pattern learned to identify the function definition in POSIX shells and bash. * "git checkout-index" did not consistently signal an error with its exit status, but now it does. * A commit and tag object may have CR at the end of each and every line (you can create such an object with hash-object or using --cleanup=verbatim to decline the default clean-up action), but it would make it impossible to have a blank line to separate the title from the body of the message. We are now more lenient and accept a line with lone CR on it as a blank line, too. * Exit codes from "git remote add" etc. were not usable by scripted callers, but now they are. * "git archive" now allows compression level higher than "-9" when generating tar.gz output. * Zsh autocompletion (in contrib/) update. * The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64). * "git rev-parse" learned the "--end-of-options" to help scripts to safely take a param
Re: [PATCH v2] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/12/15 2:58, Eric Farman wrote:
>
>
> On 12/10/20 8:56 AM, xuxiaoyang (C) wrote:
>>
>>
>> On 2020/12/9 22:42, Eric Farman wrote:
>>>
>>>
>>> On 12/9/20 6:54 AM, Cornelia Huck wrote:
>>>> On Tue, 8 Dec 2020 21:55:53 +0800
>>>> "xuxiaoyang (C)" wrote:
>>>>
>>>>> On 2020/11/21 15:58, xuxiaoyang (C) wrote:
>>>>>> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
>>>>>> each to return the physical pfn. When dealing with large arrays of
>>>>>> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
>>>>>> it is processed page by page.In this case, we can divide the iova pfn
>>>>>> array into multiple continuous ranges and optimize them. For example,
>>>>>> when the iova pfn array is {1,5,6,7,9}, it will be divided into three
>>>>>> groups {1}, {5,6,7}, {9} for processing. When processing {5,6,7}, the
>>>>>> number of calls to pin_user_pages_remote is reduced from 3 times to once.
>>>>>> For single page or large array of discontinuous iovas, we still use
>>>>>> vfio_pin_page_external to deal with it to reduce the performance loss
>>>>>> caused by refactoring.
>>>>>>
>>>>>> Signed-off-by: Xiaoyang Xu
>>>>
>>>> (...)
>>>>
>>>>>
>>>>> hi Cornelia Huck, Eric Farman, Zhenyu Wang, Zhi Wang
>>>>>
>>>>> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
>>>>> each to return the physical pfn. When dealing with large arrays of
>>>>> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
>>>>> it is processed page by page. In this case, we can divide the iova pfn
>>>>> array into multiple continuous ranges and optimize them. I have a set
>>>>> of performance test data for reference.
>>>>>
>>>>> The patch was not applied
>>>>> 1 page 512 pages
>>>>> no huge pages： 1638ns 223651ns
>>>>> THP： 1668ns 222330ns
>>>>> HugeTLB： 1526ns 208151ns
>>>>>
>>>>> The patch was applied
>>>>> 1 page 512 pages
>>>>> no huge pages 1735ns 167286ns
>>>>> THP： 1934ns 126900ns
>>>>> HugeTLB： 1713ns 102188ns
>>>>>
>>>>> As Alex Williamson said, this patch lacks proof that it works in the
>>>>> real world. I think you will have some valuable opinions.
>>>>
>>>> Looking at this from the vfio-ccw angle, I'm not sure how much this
>>>> would buy us, as we deal with IDAWs, which are designed so that they
>>>> can be non-contiguous. I guess this depends a lot on what the guest
>>>> does.
>>>
>>> This would be my concern too, but I don't have data off the top of my head
>>> to say one way or another...
>>>
>>>>
>>>> Eric, any opinion? Do you maybe also happen to have a test setup that
>>>> mimics workloads actually seen in the real world?
>>>>
>>>
>>> ...I do have some test setups, which I will try to get some data from in a
>>> couple days. At the moment I've broken most of those setups trying to
>>> implement some other stuff, and can't revert back at the moment. Will get
>>> back to this.
>>>
>>> Eric
>>> .
>>
>> Thank you for your reply. Looking forward to your test data.
>
> Xu,
>
> The scenario I ran was a host kernel 5.10.0-rc7 with qemu 5.2.0, with a
> Fedora 32 guest with 4 VCPU and 4GB memory. I tried this a handful of times
> across a couple different hosts, so the likelihood that these numbers are
> outliers are pretty low. The histograms below come from a simple bpftrace,
> recording the number of pages asked to be pinned, and the length of time (in
> nanoseconds) it took to pin all those pages. I separated out the length of
> time for a request of one page versus a request of multiple pages, because as
> you will see the former far outnumbers the latter.
>
> The first thing I tried was simply to boot the guest via vfio-ccw, to see how
> the patch itself behaved:
>
> @1_page_ns BASE +PATCH
> 256, 512 12531 42.50% 1274
[ANNOUNCE] Git v2.30.0-rc0
An early preview release Git v2.30.0-rc0 is now available for testing at the usual places. It is comprised of 413 non-merge commits since v2.29.0, contributed by 60 people, 25 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.30.0-rc0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.29.0 are as follows. Welcome to the Git development community! Alexey, Amanda Shafack, Bradley M. Kuhn, Caleb Tillman, Charvi Mendiratta, Daniel Duvall, Daniel Gurney, Dennis Ameling, Javier Spagnoletti, Jinoh Kang, Joey Salazar, Konrad Borowski, Marlon Rac Cambasis, Michał Kępień, Nate Avers, Nipunn Koorapati, Rafael Silva, Robert Karszniewicz, Samuel Čavoj, Sean Barag, Sibo Dong, Simão Afonso, Sohom Datta, Thomas Koutcher, and Victor Engmark. Returning contributors who helped this release are as follows. Thanks for your continued support. Adam Spiers, Ævar Arnfjörð Bjarmason, Alex Vandiver, Arnout Engelen, brian m. carlson, Christian Couder, Chris. Webster, Denton Liu, Derrick Stolee, Drew DeVault, Elijah Newren, Emily Shaffer, Felipe Contreras, Han-Wen Nienhuys, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Tan, Josh Steadmon, Junio C Hamano, Kyle Meyer, Martin Ågren, Matheus Tavares, Nicolas Morey-Chaisemartin, Patrick Steinhardt, Peter Kaestle, Philippe Blain, Phillip Wood, Pranit Bauva, René Scharfe, Sergey Organov, Srinidhi Kaushik, Štěpán Němec, SZEDER Gábor, and Taylor Blau. Git 2.30 Release Notes (draft) == Updates since v2.29 --- UI, Workflows & Features * Userdiff for PHP update. * Userdiff for Rust update. * Userdiff for CSS update. * The command line completion script (in contrib/) learned that "git stash show" takes the options "git diff" takes. * "git worktree list" now shows if each worktree is locked. This possibly may open us to show other kinds of states in the future. * "git maintenance", an extended big brother of "git gc", continues to evolve. * "git push --force-with-lease[=]" can easily be misused to lose commits unless the user takes good care of their own "git fetch". A new option "--force-if-includes" attempts to ensure that what is being force-pushed was created after examining the commit at the tip of the remote ref that is about to be force-replaced. * "git clone" learned clone.defaultremotename configuration variable to customize what nickname to use to call the remote the repository was cloned from. * "git checkout" learned to use checkout.guess configuration variable and enable/disable its "--[no-]guess" option accordingly. * "git resurrect" script (in contrib/) learned that the object names may be longer than 40-hex depending on the hash function in use. * "git diff A...B" learned "git diff --merge-base A B", which is a longer short-hand to say the same thing. * A sample 'push-to-checkout' hook, that performs the same as what the built-in default action does, has been added. * "git diff" family of commands learned the "-I" option to ignore hunks whose changed lines all match the given pattern. * The userdiff pattern learned to identify the function definition in POSIX shells and bash. * "git checkout-index" did not consistently signal an error with its exit status, but now it does. * A commit and tag object may have CR at the end of each and every line (you can create such an object with hash-object or using --cleanup=verbatim to decline the default clean-up action), but it would make it impossible to have a blank line to separate the title from the body of the message. We are now more lenient and accept a line with lone CR on it as a blank line, too. * Exit codes from "git remote add" etc. were not usable by scripted callers, but now they are. * "git archive" now allows compression level higher than "-9" when generating tar.gz output. * Zsh autocompletion (in contrib/) update. * The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64). * "git rev-parse" learned the "--end-of-options" to help scripts to safely take a parameter that is supposed to be a revision, e.g. "git rev-parse --verify -q --end-of-options $rev". * The command line completion script (in contrib/) learned to expand commands th
Re: [PATCH v2] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/12/9 22:42, Eric Farman wrote:
>
>
> On 12/9/20 6:54 AM, Cornelia Huck wrote:
>> On Tue, 8 Dec 2020 21:55:53 +0800
>> "xuxiaoyang (C)" wrote:
>>
>>> On 2020/11/21 15:58, xuxiaoyang (C) wrote:
>>>> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
>>>> each to return the physical pfn. When dealing with large arrays of
>>>> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
>>>> it is processed page by page.In this case, we can divide the iova pfn
>>>> array into multiple continuous ranges and optimize them. For example,
>>>> when the iova pfn array is {1,5,6,7,9}, it will be divided into three
>>>> groups {1}, {5,6,7}, {9} for processing. When processing {5,6,7}, the
>>>> number of calls to pin_user_pages_remote is reduced from 3 times to once.
>>>> For single page or large array of discontinuous iovas, we still use
>>>> vfio_pin_page_external to deal with it to reduce the performance loss
>>>> caused by refactoring.
>>>>
>>>> Signed-off-by: Xiaoyang Xu
>>
>> (...)
>>
>>>
>>> hi Cornelia Huck, Eric Farman, Zhenyu Wang, Zhi Wang
>>>
>>> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
>>> each to return the physical pfn. When dealing with large arrays of
>>> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
>>> it is processed page by page. In this case, we can divide the iova pfn
>>> array into multiple continuous ranges and optimize them. I have a set
>>> of performance test data for reference.
>>>
>>> The patch was not applied
>>> 1 page 512 pages
>>> no huge pages： 1638ns 223651ns
>>> THP： 1668ns 222330ns
>>> HugeTLB： 1526ns 208151ns
>>>
>>> The patch was applied
>>> 1 page 512 pages
>>> no huge pages 1735ns 167286ns
>>> THP： 1934ns 126900ns
>>> HugeTLB： 1713ns 102188ns
>>>
>>> As Alex Williamson said, this patch lacks proof that it works in the
>>> real world. I think you will have some valuable opinions.
>>
>> Looking at this from the vfio-ccw angle, I'm not sure how much this
>> would buy us, as we deal with IDAWs, which are designed so that they
>> can be non-contiguous. I guess this depends a lot on what the guest
>> does.
>
> This would be my concern too, but I don't have data off the top of my head to
> say one way or another...
>
>>
>> Eric, any opinion? Do you maybe also happen to have a test setup that
>> mimics workloads actually seen in the real world?
>>
>
> ...I do have some test setups, which I will try to get some data from in a
> couple days. At the moment I've broken most of those setups trying to
> implement some other stuff, and can't revert back at the moment. Will get
> back to this.
>
> Eric
> .
Thank you for your reply. Looking forward to your test data.
Regards,
Xu
Re: [PATCH v2] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/12/9 19:54, Cornelia Huck wrote:
> On Tue, 8 Dec 2020 21:55:53 +0800
> "xuxiaoyang (C)" wrote:
>
>> On 2020/11/21 15:58, xuxiaoyang (C) wrote:
>>> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
>>> each to return the physical pfn. When dealing with large arrays of
>>> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
>>> it is processed page by page.In this case, we can divide the iova pfn
>>> array into multiple continuous ranges and optimize them. For example,
>>> when the iova pfn array is {1,5,6,7,9}, it will be divided into three
>>> groups {1}, {5,6,7}, {9} for processing. When processing {5,6,7}, the
>>> number of calls to pin_user_pages_remote is reduced from 3 times to once.
>>> For single page or large array of discontinuous iovas, we still use
>>> vfio_pin_page_external to deal with it to reduce the performance loss
>>> caused by refactoring.
>>>
>>> Signed-off-by: Xiaoyang Xu
>
> (...)
>
>>
>> hi Cornelia Huck, Eric Farman, Zhenyu Wang, Zhi Wang
>>
>> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
>> each to return the physical pfn. When dealing with large arrays of
>> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
>> it is processed page by page. In this case, we can divide the iova pfn
>> array into multiple continuous ranges and optimize them. I have a set
>> of performance test data for reference.
>>
>> The patch was not applied
>> 1 page 512 pages
>> no huge pages： 1638ns 223651ns
>> THP： 1668ns 222330ns
>> HugeTLB： 1526ns 208151ns
>>
>> The patch was applied
>> 1 page 512 pages
>> no huge pages 1735ns 167286ns
>> THP： 1934ns 126900ns
>> HugeTLB： 1713ns 102188ns
>>
>> As Alex Williamson said, this patch lacks proof that it works in the
>> real world. I think you will have some valuable opinions.
>
> Looking at this from the vfio-ccw angle, I'm not sure how much this
> would buy us, as we deal with IDAWs, which are designed so that they
> can be non-contiguous. I guess this depends a lot on what the guest
> does.
>
> Eric, any opinion? Do you maybe also happen to have a test setup that
> mimics workloads actually seen in the real world?
>
> .
>
Thank you for your reply. The iova array constructed using
pfn_array_alloc is continuous, and I think there will be
some performance improvements here.
Regards,
Xu
Re: [PATCH] net: dsa: sja1105: Remove an unprofessional word from the code comments
Hello. Thank you very much for the reply. Firstly, yes, it's my first contribution and apologies for making some mistakes and I'd like to thank you for being kind and pointing it out. I came to know about this driver in a casual discussion among my peers when one of them pointed out the presence of this particular word on the driver. I just thought that I'd try to help and get rid of that, if possible. Nothing more. As you mentioned, I ran my eyes over drivers/net/dsa/sja1105/sja1105_tas.c and the other files. Other than a very minor spelling error, I didn't come across wording conventions like the one we are discussing about. And yes, as you mentioned, "poorly organized" sounds perfect, too. I believe that not signing off and not sending it to all maintainers is all, in the things I did wrong. So, I hope I can fix them and send the patch as a reply to this thread. Thank you. ‐‐‐ Original Message ‐‐‐ On Tuesday, December 8, 2020 6:05 PM, Vladimir Oltean wrote: Hi Aswin, On Tue, Dec 08, 2020 at 04:03:32PM +0530, Aswin C wrote: Remove the word 'retarded' from the code comments with a more professional word 'erroneous' to make it less profane. - drivers/net/dsa/sja1105/sja1105_dynamic_config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c index b777d3f37..7a76180f3 100644 --- a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c +++ b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c @@ -250,7 +250,7 @@ sja1105pqrs_l2_lookup_cmd_packing(void *buf, struct sja1105_dyn_cmd *cmd, SJA1105PQRS_SIZE_L2_LOOKUP_ENTRY, op); } -/* The switch is so retarded that it makes our command/entry abstraction +/* The switch is so erroneous that it makes our command/entry abstraction - crumble apart. - - On P/Q/R/S, the switch tries to say whether a FDB entry -- 2.29.2 Thank you for the patch and for what looks like your first contribution to the kernel. First of all, when you submit a patch, you should follow the development process at: https://www.kernel.org/doc/html/latest/process/submitting-patches.html https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.rst You should use ./scripts/get_maintainer.pl and send the email to all maintainers that get listed there, plus the mailing list. I don't feel that "erroneous" is the right replacement. Maybe "poorly organized". Although I am not sure that "professional" is something that I was going for when I wrote this driver. This makes me curious what exactly motivated you to make the change? Do you feel offended by the use of profanity when used to describe hardware? How did you even pick the sja1105 driver. I can think of two possibilities: - You are working with it. But in this case, I do wonder how you feel by the larger amount of profanity in drivers/net/dsa/sja1105/sja1105_tas.c. Are you planning further patches for that? - You just searched the kernel sources for profanity, or, putting it differently, you were actively trying to be offended.
Re: [PATCH v2] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/11/21 15:58, xuxiaoyang (C) wrote:
> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
> each to return the physical pfn. When dealing with large arrays of
> contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
> it is processed page by page.In this case, we can divide the iova pfn
> array into multiple continuous ranges and optimize them. For example,
> when the iova pfn array is {1,5,6,7,9}, it will be divided into three
> groups {1}, {5,6,7}, {9} for processing. When processing {5,6,7}, the
> number of calls to pin_user_pages_remote is reduced from 3 times to once.
> For single page or large array of discontinuous iovas, we still use
> vfio_pin_page_external to deal with it to reduce the performance loss
> caused by refactoring.
>
> Signed-off-by: Xiaoyang Xu
> ---
> v1 -> v2:
> * make vfio_iommu_type1_pin_contiguous_pages use vfio_pin_page_external
> to pin single page when npage=1
> * make vfio_pin_contiguous_pages_external use set npage to mark
> consecutive pages as dirty. simplify the processing logic of unwind
> * remove unnecessary checks in vfio_get_contiguous_pages_length, put
> the least costly judgment logic at the top, and replace
> vfio_iova_get_vfio_pfn with vfio_find_vpfn
>
> drivers/vfio/vfio_iommu_type1.c | 231
> 1 file changed, 204 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 67e827638995..080727b531c6 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -628,6 +628,196 @@ static int vfio_unpin_page_external(struct vfio_dma
> *dma, dma_addr_t iova,
> return unlocked;
> }
>
> +static int contiguous_vaddr_get_pfn(struct mm_struct *mm, unsigned long
> vaddr,
> + int prot, long npage, unsigned long
> *phys_pfn)
> +{
> + struct page **pages = NULL;
> + unsigned int flags = 0;
> + int i, ret;
> +
> + pages = kvmalloc_array(npage, sizeof(struct page *), GFP_KERNEL);
> + if (!pages)
> + return -ENOMEM;
> +
> + if (prot & IOMMU_WRITE)
> + flags |= FOLL_WRITE;
> +
> + mmap_read_lock(mm);
> + ret = pin_user_pages_remote(mm, vaddr, npage, flags | FOLL_LONGTERM,
> + pages, NULL, NULL);
> + mmap_read_unlock(mm);
> +
> + for (i = 0; i < ret; i++)
> + *(phys_pfn + i) = page_to_pfn(pages[i]);
> +
> + kvfree(pages);
> +
> + return ret;
> +}
> +
> +static int vfio_pin_contiguous_pages_external(struct vfio_iommu *iommu,
> + struct vfio_dma *dma,
> + unsigned long *user_pfn,
> + int npage, unsigned long *phys_pfn,
> + bool do_accounting)
> +{
> + int ret, i, j, lock_acct = 0;
> + unsigned long remote_vaddr;
> + dma_addr_t iova;
> + struct mm_struct *mm;
> + struct vfio_pfn *vpfn;
> +
> + mm = get_task_mm(dma->task);
> + if (!mm)
> + return -ENODEV;
> +
> + iova = user_pfn[0] << PAGE_SHIFT;
> + remote_vaddr = dma->vaddr + iova - dma->iova;
> + ret = contiguous_vaddr_get_pfn(mm, remote_vaddr, dma->prot,
> + npage, phys_pfn);
> + mmput(mm);
> + if (ret <= 0)
> + return ret;
> +
> + npage = ret;
> + for (i = 0; i < npage; i++) {
> + iova = user_pfn[i] << PAGE_SHIFT;
> + ret = vfio_add_to_pfn_list(dma, iova, phys_pfn[i]);
> + if (ret)
> + goto unwind;
> +
> + if (!is_invalid_reserved_pfn(phys_pfn[i]))
> + lock_acct++;
> + }
> +
> + if (do_accounting) {
> + ret = vfio_lock_acct(dma, lock_acct, true);
> + if (ret) {
> + if (ret == -ENOMEM)
> + pr_warn("%s: Task %s (%d) RLIMIT_MEMLOCK (%ld)
> exceeded\n",
> + __func__, dma->task->comm,
> task_pid_nr(dma->task),
> + task_rlimit(dma->task, RLIMIT_MEMLOCK));
> + goto unwind;
> + }
> + }
> +
> + if (iommu->dirty_page_tracking) {
> + unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
> +
> + /*
> + * Bitmap populated with the smallest supported page
> + * size
> + */
> +
[PATCH] net: dsa: sja1105: Remove an unprofessional word from the code comments
Remove the word 'retarded' from the code comments with a more professional word 'erroneous' to make it less profane. --- drivers/net/dsa/sja1105/sja1105_dynamic_config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c index b777d3f37..7a76180f3 100644 --- a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c +++ b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c @@ -250,7 +250,7 @@ sja1105pqrs_l2_lookup_cmd_packing(void *buf, struct sja1105_dyn_cmd *cmd, SJA1105PQRS_SIZE_L2_LOOKUP_ENTRY, op); } -/* The switch is so retarded that it makes our command/entry abstraction +/* The switch is so erroneous that it makes our command/entry abstraction * crumble apart. * * On P/Q/R/S, the switch tries to say whether a FDB entry -- 2.29.2
Re: [RFC PATCH] blk-cgroup: prevent rcu_sched detected stalls warnings in blkg_destroy_all()
On 2020/11/25 20:32, Tejun Heo wrote:
Hello,
Thanks for the fix. A couple comments below.
On Sat, Nov 21, 2020 at 04:34:20PM +0800, Yu Kuai wrote:
+#define BLKG_DESTROY_BATH 4096
I think you meant BLKG_DESTROY_BATCH.
static void blkg_destroy_all(struct request_queue *q)
{
struct blkcg_gq *blkg, *n;
+ int count = BLKG_DESTROY_BATH;
But might as well just write 4096 here.
spin_lock_irq(>queue_lock);
list_for_each_entry_safe(blkg, n, >blkg_list, q_node) {
struct blkcg *blkcg = blkg->blkcg;
+ /*
+* If the list is too long, the loop can took a long time,
+* thus relese the lock for a while when a batch of blkcg
+* were destroyed.
+*/
+ if (!(--count)) {
+ count = BLKG_DESTROY_BATH;
+ spin_unlock_irq(>queue_lock);
+ cond_resched();
+ spin_lock_irq(>queue_lock);
You can't continue iteration after dropping both locks. You'd have to jump
out of loop and start list_for_each_entry_safe() again.
Thanks for your review, it's right. On the other hand
blkcg_activate_policy() and blkcg_deactivate_policy() might have the
same issue. My idea is that inserting a bookmark to the list, and
restard from here.
By the way, I found that blk_throtl_update_limit_valid() is called from
throtl_pd_offline(). If CONFIG_BLK_DEV_THROTTLING_LOW is off, lower
limit will always be zero, therefor a lot of time will be wasted to
iterate descendants to find a nonzero lower limit.
Do you think it's ok to do such modification:
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index b771c4299982..d52cac9f3a7c 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -587,6 +587,7 @@ static void throtl_pd_online(struct blkg_policy_data
*pd)
tg_update_has_rules(tg);
}
+#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
static void blk_throtl_update_limit_valid(struct throtl_data *td)
{
struct cgroup_subsys_state *pos_css;
@@ -607,6 +608,11 @@ static void blk_throtl_update_limit_valid(struct
throtl_data *td)
td->limit_valid[LIMIT_LOW] = low_valid;
}
+#else
+static inline void blk_throtl_update_limit_valid(struct throtl_data *td)
+{
+}
+#endif
static void throtl_upgrade_state(struct throtl_data *td);
static void throtl_pd_offline(struct blkg_policy_data *pd)
Thanks!
Yu Kuai
[PATCH v2] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
vfio_pin_pages() accepts an array of unrelated iova pfns and processes
each to return the physical pfn. When dealing with large arrays of
contiguous iovas, vfio_iommu_type1_pin_pages is very inefficient because
it is processed page by page.In this case, we can divide the iova pfn
array into multiple continuous ranges and optimize them. For example,
when the iova pfn array is {1,5,6,7,9}, it will be divided into three
groups {1}, {5,6,7}, {9} for processing. When processing {5,6,7}, the
number of calls to pin_user_pages_remote is reduced from 3 times to once.
For single page or large array of discontinuous iovas, we still use
vfio_pin_page_external to deal with it to reduce the performance loss
caused by refactoring.
Signed-off-by: Xiaoyang Xu
---
v1 -> v2:
* make vfio_iommu_type1_pin_contiguous_pages use vfio_pin_page_external
to pin single page when npage=1
* make vfio_pin_contiguous_pages_external use set npage to mark
consecutive pages as dirty. simplify the processing logic of unwind
* remove unnecessary checks in vfio_get_contiguous_pages_length, put
the least costly judgment logic at the top, and replace
vfio_iova_get_vfio_pfn with vfio_find_vpfn
drivers/vfio/vfio_iommu_type1.c | 231
1 file changed, 204 insertions(+), 27 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 67e827638995..080727b531c6 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -628,6 +628,196 @@ static int vfio_unpin_page_external(struct vfio_dma *dma,
dma_addr_t iova,
return unlocked;
}
+static int contiguous_vaddr_get_pfn(struct mm_struct *mm, unsigned long vaddr,
+ int prot, long npage, unsigned long
*phys_pfn)
+{
+ struct page **pages = NULL;
+ unsigned int flags = 0;
+ int i, ret;
+
+ pages = kvmalloc_array(npage, sizeof(struct page *), GFP_KERNEL);
+ if (!pages)
+ return -ENOMEM;
+
+ if (prot & IOMMU_WRITE)
+ flags |= FOLL_WRITE;
+
+ mmap_read_lock(mm);
+ ret = pin_user_pages_remote(mm, vaddr, npage, flags | FOLL_LONGTERM,
+ pages, NULL, NULL);
+ mmap_read_unlock(mm);
+
+ for (i = 0; i < ret; i++)
+ *(phys_pfn + i) = page_to_pfn(pages[i]);
+
+ kvfree(pages);
+
+ return ret;
+}
+
+static int vfio_pin_contiguous_pages_external(struct vfio_iommu *iommu,
+ struct vfio_dma *dma,
+ unsigned long *user_pfn,
+ int npage, unsigned long *phys_pfn,
+ bool do_accounting)
+{
+ int ret, i, j, lock_acct = 0;
+ unsigned long remote_vaddr;
+ dma_addr_t iova;
+ struct mm_struct *mm;
+ struct vfio_pfn *vpfn;
+
+ mm = get_task_mm(dma->task);
+ if (!mm)
+ return -ENODEV;
+
+ iova = user_pfn[0] << PAGE_SHIFT;
+ remote_vaddr = dma->vaddr + iova - dma->iova;
+ ret = contiguous_vaddr_get_pfn(mm, remote_vaddr, dma->prot,
+ npage, phys_pfn);
+ mmput(mm);
+ if (ret <= 0)
+ return ret;
+
+ npage = ret;
+ for (i = 0; i < npage; i++) {
+ iova = user_pfn[i] << PAGE_SHIFT;
+ ret = vfio_add_to_pfn_list(dma, iova, phys_pfn[i]);
+ if (ret)
+ goto unwind;
+
+ if (!is_invalid_reserved_pfn(phys_pfn[i]))
+ lock_acct++;
+ }
+
+ if (do_accounting) {
+ ret = vfio_lock_acct(dma, lock_acct, true);
+ if (ret) {
+ if (ret == -ENOMEM)
+ pr_warn("%s: Task %s (%d) RLIMIT_MEMLOCK (%ld)
exceeded\n",
+ __func__, dma->task->comm,
task_pid_nr(dma->task),
+ task_rlimit(dma->task, RLIMIT_MEMLOCK));
+ goto unwind;
+ }
+ }
+
+ if (iommu->dirty_page_tracking) {
+ unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
+
+ /*
+* Bitmap populated with the smallest supported page
+* size
+*/
+ bitmap_set(dma->bitmap,
+ ((user_pfn[0] << PAGE_SHIFT) - dma->iova) >>
pgshift, npage);
+ }
+
+ return i;
+unwind:
+ for (j = 0; j < npage; j++) {
+ if (j < i) {
+ iova = user_pfn[j] << PAGE_SHIFT;
+ vpfn = vfio_find_vpfn(dma, iova);
+ vfio_iova_put_vfio_pfn(dma, vpfn);
+ } else {
+ put_pfn(phys_pfn[j], dma->prot);
Re: [PATCH] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/11/17 0:33, Alex Williamson wrote:
> On Mon, 16 Nov 2020 21:47:33 +0800
> "xuxiaoyang (C)" wrote:
>
>> On 2020/11/14 0:44, Alex Williamson wrote:
>>> On Tue, 10 Nov 2020 21:42:33 +0800
>>> "xuxiaoyang (C)" wrote:
>>>
>>>> vfio_iommu_type1_pin_pages is very inefficient because
>>>> it is processed page by page when calling vfio_pin_page_external.
>>>> Added contiguous_vaddr_get_pfn to process continuous pages
>>>> to reduce the number of loops, thereby improving performance.
>>>>
>>>> Signed-off-by: Xiaoyang Xu
>>>> ---
>>>> drivers/vfio/vfio_iommu_type1.c | 241
>>>> 1 file changed, 214 insertions(+), 27 deletions(-)
>>>
>>> Sorry for my previous misunderstanding of the logic here. Still, this
>>> adds a lot of complexity, can you quantify the performance improvement
>>> you're seeing? Would it instead be more worthwhile to support an
>>> interface that pins based on an iova and range? Further comments below.
>>>
>> Thank you for your reply. I have a set of performance test data for
>> reference.
>> The host kernel version of my test environment is 4.19.36, and the test cases
>> are for pin one page and 512 pages. When pin 512pages, the input is a
>> continuous iova address. At the same time increase the measurement factor of
>> whether the mem backend uses large pages. The following is the average of
>> multiple tests.
>>
>> The patch was not applied
>> 1 page 512 pages
>> no huge pages： 1638ns 223651ns
>> THP： 1668ns 222330ns
>> HugeTLB： 1526ns 208151ns
>>
>> The patch was applied
>> 1 page 512 pages
>> no huge pages 1735ns 167286ns
>> THP： 1934ns 126900ns
>> HugeTLB： 1713ns 102188ns
>>
>> The performance will be reduced when the page is fixed with a single pin,
>> while the page time of continuous pins can be reduced to half of the
>> original.
>> If you have other suggestions for testing methods, please let me know.
>
> These are artificial test results, which in fact show a performance
> decrease for the single page use cases. What do we see in typical real
> world scenarios? Do those real world scenarios tend more towards large
> arrays of contiguous IOVAs or single pages, or large arrays of
> discontiguous IOVAs? What's the resulting change in device
> performance? Are pages pinned at a high enough frequency that pinning
> latency results in a measurable benefit at the device or to the
> overhead on the host?
>
Thank you for your reply. It is difficult for me to construct these
use cases. When the device is performing DMA, frequent calls to
pin/unpin pages are a big overhead, so we will pin a large part of
the memory to create a memory pool at the beginning. Therefore, we
pay more attention to the performance of pin continuous pages.
Single page is processed in contiguous_vaddr_get_pfn, which will
reduce performance. We can keep the previous code processing path
in vfio_pin_page_external. As long as vfio_get_contiguous_pages_length
can return fast enough, the performance loss of single page processing
will be minimized.
>>>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>>>> b/drivers/vfio/vfio_iommu_type1.c
>>>> index 67e827638995..935f80807527 100644
>>>> --- a/drivers/vfio/vfio_iommu_type1.c
>>>> +++ b/drivers/vfio/vfio_iommu_type1.c
>>>> @@ -628,6 +628,206 @@ static int vfio_unpin_page_external(struct vfio_dma
>>>> *dma, dma_addr_t iova,
>>>>return unlocked;
>>>> }
>>>>
>>>> +static int contiguous_vaddr_get_pfn(struct mm_struct *mm, unsigned long
>>>> vaddr,
>>>> + int prot, long npage, unsigned long
>>>> *phys_pfn)
>>>> +{
>>>> + struct page **pages = NULL;
>>>> + unsigned int flags = 0;
>>>> + int i, ret;
>>>> +
>>>> + pages = kvmalloc_array(npage, sizeof(struct page *), GFP_KERNEL);
>>>> + if (!pages)
>>>> + return -ENOMEM;
>>>> +
>>>> + if (prot & IOMMU_WRITE)
>>>> + flags |= FOLL_WRITE;
>>>> +
>>>> + mmap_read_lock(mm);
>>>> + ret = pin_user_pages_remote(mm, vaddr, npage, flags | FOLL_LONGTERM,
>>>> +
Re: [PATCH] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/11/14 0:44, Alex Williamson wrote:
> On Tue, 10 Nov 2020 21:42:33 +0800
> "xuxiaoyang (C)" wrote:
>
>> vfio_iommu_type1_pin_pages is very inefficient because
>> it is processed page by page when calling vfio_pin_page_external.
>> Added contiguous_vaddr_get_pfn to process continuous pages
>> to reduce the number of loops, thereby improving performance.
>>
>> Signed-off-by: Xiaoyang Xu
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 241
>> 1 file changed, 214 insertions(+), 27 deletions(-)
>
> Sorry for my previous misunderstanding of the logic here. Still, this
> adds a lot of complexity, can you quantify the performance improvement
> you're seeing? Would it instead be more worthwhile to support an
> interface that pins based on an iova and range? Further comments below.
>
Thank you for your reply. I have a set of performance test data for reference.
The host kernel version of my test environment is 4.19.36, and the test cases
are for pin one page and 512 pages. When pin 512pages, the input is a
continuous iova address. At the same time increase the measurement factor of
whether the mem backend uses large pages. The following is the average of
multiple tests.
The patch was not applied
1 page 512 pages
no huge pages： 1638ns 223651ns
THP： 1668ns 222330ns
HugeTLB： 1526ns 208151ns
The patch was applied
1 page 512 pages
no huge pages 1735ns 167286ns
THP： 1934ns 126900ns
HugeTLB： 1713ns 102188ns
The performance will be reduced when the page is fixed with a single pin,
while the page time of continuous pins can be reduced to half of the original.
If you have other suggestions for testing methods, please let me know.
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index 67e827638995..935f80807527 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -628,6 +628,206 @@ static int vfio_unpin_page_external(struct vfio_dma
>> *dma, dma_addr_t iova,
>> return unlocked;
>> }
>>
>> +static int contiguous_vaddr_get_pfn(struct mm_struct *mm, unsigned long
>> vaddr,
>> +int prot, long npage, unsigned long
>> *phys_pfn)
>> +{
>> +struct page **pages = NULL;
>> +unsigned int flags = 0;
>> +int i, ret;
>> +
>> +pages = kvmalloc_array(npage, sizeof(struct page *), GFP_KERNEL);
>> +if (!pages)
>> +return -ENOMEM;
>> +
>> +if (prot & IOMMU_WRITE)
>> +flags |= FOLL_WRITE;
>> +
>> +mmap_read_lock(mm);
>> +ret = pin_user_pages_remote(mm, vaddr, npage, flags | FOLL_LONGTERM,
>> +pages, NULL, NULL);
>
> This is essentially the root of the performance improvement claim,
> right? ie. we're pinning a range of pages rather than individually.
> Unfortunately it means we also add a dynamic memory allocation even
> when npage=1.
>
Yes, when npage = 1, I should keep the previous scheme of the scene
and use local variables to save time in allocated memory
>
>> +mmap_read_unlock(mm);
>> +
>> +for (i = 0; i < ret; i++)
>> +*(phys_pfn + i) = page_to_pfn(pages[i]);
>> +
>> +kvfree(pages);
>> +
>> +return ret;
>> +}
>> +
>> +static int vfio_pin_contiguous_pages_external(struct vfio_iommu *iommu,
>> +struct vfio_dma *dma,
>> +unsigned long *user_pfn,
>> +int npage, unsigned long *phys_pfn,
>> +bool do_accounting)
>> +{
>> +int ret, i, j, lock_acct = 0;
>> +unsigned long remote_vaddr;
>> +dma_addr_t iova;
>> +struct mm_struct *mm;
>> +struct vfio_pfn *vpfn;
>> +
>> +mm = get_task_mm(dma->task);
>> +if (!mm)
>> +return -ENODEV;
>> +
>> +iova = user_pfn[0] << PAGE_SHIFT;
>> +remote_vaddr = dma->vaddr + iova - dma->iova;
>> +ret = contiguous_vaddr_get_pfn(mm, remote_vaddr, dma->prot,
>> +npage, phys_pfn);
>> +mmput(mm);
>> +if (ret <= 0)
>> +return ret;
>> +
>> +npage = ret;
>> +for (i = 0; i < npage; i++) {
>> +iova = user_pfn[i] << PAGE_SHIFT;
>> +ret = vfio_
Re: [PATCH] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
On 2020/11/11 23:56, Alex Williamson wrote:
> On Tue, 10 Nov 2020 21:42:33 +0800
> "xuxiaoyang (C)" wrote:
>
>> vfio_iommu_type1_pin_pages is very inefficient because
>> it is processed page by page when calling vfio_pin_page_external.
>> Added contiguous_vaddr_get_pfn to process continuous pages
>> to reduce the number of loops, thereby improving performance.
>
> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
> each to return the physical pfn. AFAICT this proposal makes an
> unfounded and unverified assumption that the caller is asking for a
> range of contiguous iova pfns. That's not the semantics of the call.
> This is wrong. Thanks,
>
> Alex
>
> .
>
Thank you for your reply. Sorry that the comment is too simple
and not clear enough.
We did not change the external behavior of the function. What we
have to do is to divide the iova pfn array into multiple continuous
ranges and optimize them. For example, when the iova pfn array is
{1,5,6,7,9}, it will be divided into three groups {1}, {5,6,7}, {9}
for processing. When processing {5,6,7}, the number of calls to
pin_user_pages_remote is reduced from 3 times to once. The more
continuous the iova pfn array, the greater the performance improvement.
I see that most of the iova pfn arrays processed by callers are
continuous, such as pfn_array_pin, gvt_pin_guest_page. For them,
performance will be improved.
Regards,
Xu
Re: [PATCH V3] memory: tegra: add missing put_device() call in error path of tegra_emc_probe()
On 2020/11/10 23:21, Krzysztof Kozlowski wrote:
On Tue, Nov 10, 2020 at 09:33:11AM +0800, Yu Kuai wrote:
The reference to device obtained with of_find_device_by_node() should
be dropped. Thus add jump target to fix the exception handling for this
function implementation.
Fixes: 73a7f0a90641("memory: tegra: Add EMC (external memory controller)
driver")
Signed-off-by: Yu Kuai
---
drivers/memory/tegra/tegra124-emc.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
I think you missed my previous comment about the issue being fixed
already. Are you sure you rebased this on top of latest next?
Hi,
It's true the issue was fixed.
Thanks,
Yu Kuai
Best regards,
Krzysztof
.
[PATCH] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
vfio_iommu_type1_pin_pages is very inefficient because
it is processed page by page when calling vfio_pin_page_external.
Added contiguous_vaddr_get_pfn to process continuous pages
to reduce the number of loops, thereby improving performance.
Signed-off-by: Xiaoyang Xu
---
drivers/vfio/vfio_iommu_type1.c | 241
1 file changed, 214 insertions(+), 27 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 67e827638995..935f80807527 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -628,6 +628,206 @@ static int vfio_unpin_page_external(struct vfio_dma *dma,
dma_addr_t iova,
return unlocked;
}
+static int contiguous_vaddr_get_pfn(struct mm_struct *mm, unsigned long vaddr,
+ int prot, long npage, unsigned long
*phys_pfn)
+{
+ struct page **pages = NULL;
+ unsigned int flags = 0;
+ int i, ret;
+
+ pages = kvmalloc_array(npage, sizeof(struct page *), GFP_KERNEL);
+ if (!pages)
+ return -ENOMEM;
+
+ if (prot & IOMMU_WRITE)
+ flags |= FOLL_WRITE;
+
+ mmap_read_lock(mm);
+ ret = pin_user_pages_remote(mm, vaddr, npage, flags | FOLL_LONGTERM,
+ pages, NULL, NULL);
+ mmap_read_unlock(mm);
+
+ for (i = 0; i < ret; i++)
+ *(phys_pfn + i) = page_to_pfn(pages[i]);
+
+ kvfree(pages);
+
+ return ret;
+}
+
+static int vfio_pin_contiguous_pages_external(struct vfio_iommu *iommu,
+ struct vfio_dma *dma,
+ unsigned long *user_pfn,
+ int npage, unsigned long *phys_pfn,
+ bool do_accounting)
+{
+ int ret, i, j, lock_acct = 0;
+ unsigned long remote_vaddr;
+ dma_addr_t iova;
+ struct mm_struct *mm;
+ struct vfio_pfn *vpfn;
+
+ mm = get_task_mm(dma->task);
+ if (!mm)
+ return -ENODEV;
+
+ iova = user_pfn[0] << PAGE_SHIFT;
+ remote_vaddr = dma->vaddr + iova - dma->iova;
+ ret = contiguous_vaddr_get_pfn(mm, remote_vaddr, dma->prot,
+ npage, phys_pfn);
+ mmput(mm);
+ if (ret <= 0)
+ return ret;
+
+ npage = ret;
+ for (i = 0; i < npage; i++) {
+ iova = user_pfn[i] << PAGE_SHIFT;
+ ret = vfio_add_to_pfn_list(dma, iova, phys_pfn[i]);
+ if (ret)
+ goto unwind;
+
+ if (!is_invalid_reserved_pfn(phys_pfn[i]))
+ lock_acct++;
+
+ if (iommu->dirty_page_tracking) {
+ unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
+
+ /*
+* Bitmap populated with the smallest supported page
+* size
+*/
+ bitmap_set(dma->bitmap,
+ (iova - dma->iova) >> pgshift, 1);
+ }
+ }
+
+ if (do_accounting) {
+ ret = vfio_lock_acct(dma, lock_acct, true);
+ if (ret) {
+ if (ret == -ENOMEM)
+ pr_warn("%s: Task %s (%d) RLIMIT_MEMLOCK (%ld)
exceeded\n",
+ __func__, dma->task->comm,
task_pid_nr(dma->task),
+ task_rlimit(dma->task, RLIMIT_MEMLOCK));
+ goto unwind;
+ }
+ }
+
+ return i;
+unwind:
+ for (j = 0; j < npage; j++) {
+ put_pfn(phys_pfn[j], dma->prot);
+ phys_pfn[j] = 0;
+ }
+
+ for (j = 0; j < i; j++) {
+ iova = user_pfn[j] << PAGE_SHIFT;
+ vpfn = vfio_find_vpfn(dma, iova);
+ if (vpfn)
+ vfio_remove_from_pfn_list(dma, vpfn);
+ }
+
+ return ret;
+}
+
+static int vfio_iommu_type1_pin_contiguous_pages(struct vfio_iommu *iommu,
+ struct vfio_dma *dma,
+ unsigned long *user_pfn,
+ int npage, unsigned long *phys_pfn,
+ bool do_accounting)
+{
+ int ret, i, j;
+ unsigned long remote_vaddr;
+ dma_addr_t iova;
+
+ ret = vfio_pin_contiguous_pages_external(iommu, dma, user_pfn, npage,
+ phys_pfn, do_accounting);
+ if (ret == npage)
+ return ret;
+
+ if (ret < 0)
+ ret = 0;
+
+ for (i = ret; i < npage; i++) {
+ iova = user_pfn[i] << PAGE_SHIFT;
+ remote_vaddr =
Re: [PATCH] mtd: rawnand: ingenic: remove redundant get_device() in ingenic_ecc_get()
ping..
On 2020/10/31 18:54, Yu Kuai wrote:
of_find_device_by_node() already takes a reference to the device, and
ingenic_ecc_release() will drop the reference. So, the get_device() in
ingenic_ecc_get() is redundand.
Fixes: 15de8c6efd0e("mtd: rawnand: ingenic: Separate top-level and SoC specific
code")
Signed-off-by: Yu Kuai
---
drivers/mtd/nand/raw/ingenic/ingenic_ecc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
b/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
index 8e22cd6ec71f..efe0ffe4f1ab 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
@@ -71,8 +71,6 @@ static struct ingenic_ecc *ingenic_ecc_get(struct device_node
*np)
if (!pdev || !platform_get_drvdata(pdev))
return ERR_PTR(-EPROBE_DEFER);
- get_device(>dev);
-
ecc = platform_get_drvdata(pdev);
clk_prepare_enable(ecc->clk);
Re: [PATCH V3] fsl/fman: add missing put_devcie() call in fman_port_probe()
在 2020/11/08 6:09, Jakub Kicinski 写道:
On Sat, 7 Nov 2020 17:09:25 +0800 Yu Kuai wrote:
if of_find_device_by_node() succeed, fman_port_probe() doesn't have a
corresponding put_device(). Thus add jump target to fix the exception
handling for this function implementation.
Fixes: 0572054617f3 ("fsl/fman: fix dereference null return value")
Signed-off-by: Yu Kuai
@@ -1792,20 +1792,20 @@ static int fman_port_probe(struct platform_device
*of_dev)
if (!fm_node) {
dev_err(port->dev, "%s: of_get_parent() failed\n", __func__);
err = -ENODEV;
- goto return_err;
+ goto free_port;
And now you no longer put port_node if jumping from here...
Sincerely apologize for that stupid mistake...
Also does the reference to put_device() not have to be released when
this function succeeds?
I'm not sure about that, since fman_port_driver doesn't define other
interface, maybe it reasonable to release it here.
}
@@ -1896,7 +1895,9 @@ static int fman_port_probe(struct platform_device *of_dev)
return 0;
-return_err:
+put_device:
+ put_device(_pdev->dev);
+put_node:
of_node_put(port_node);
free_port:
kfree(port);
.
Re: [PATCH -next v3 1/2] watchdog: Fix potential dereferencing of null pointer
在 2020/11/5 22:26, Guenter Roeck 写道:
> On Thu, Nov 05, 2020 at 12:38:47PM +, Wang Wensheng wrote:
>> A reboot notifier, which stops the WDT by calling the stop hook without
>> any check, would be registered when we set WDOG_STOP_ON_REBOOT flag.
>>
>> Howerer we allow the WDT driver to omit the stop hook since commit
>> "d0684c8a93549" ("watchdog: Make stop function optional") and provide
>> a module parameter for user that controls the WDOG_STOP_ON_REBOOT flag
>> in commit 9232c80659e94 ("watchdog: Add stop_on_reboot parameter to
>> control reboot policy"). Together that commits make user potential to
>> insert a watchdog driver that don't provide a stop hook but with the
>> stop_on_reboot parameter set, then dereferencing of null pointer occurs
>> on system reboot.
>>
>> Check the stop hook before registering the reboot notifier to fix the
>> issue.
>>
>> Fixes: d0684c8a9354 ("watchdog: Make stop function optional")
>> Signed-off-by: Wang Wensheng
>> ---
>> drivers/watchdog/watchdog_core.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/watchdog/watchdog_core.c
>> b/drivers/watchdog/watchdog_core.c
>> index 423844757812..945ab38b14b8 100644
>> --- a/drivers/watchdog/watchdog_core.c
>> +++ b/drivers/watchdog/watchdog_core.c
>> @@ -267,8 +267,15 @@ static int __watchdog_register_device(struct
>> watchdog_device *wdd)
>> }
>>
>> if (test_bit(WDOG_STOP_ON_REBOOT, >status)) {
>> -wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
>> +if (!wdd->ops->stop) {
>> +pr_err("watchdog%d: Cannot support stop_on_reboot\n",
>> +wdd->id);
>> +watchdog_dev_unregister(wdd);
>> +ida_simple_remove(_ida, id);
>> +return -EINVAL;
>> +}
>
> The problem with this is that setting the "stop_on_reboot" module parameter
> would now prevent the watchdog from being loaded, which isn't really
> desirable and might go unnoticed. I think the initial check should be
> above, with the "Mandatory operations" check, and
> if (stop_on_reboot != -1) {
> should be extended to
> if (stop_on_reboot != -1 && wdd->ops->stop) {
>
> or possibly more fancy:
>
> if (stop_on_reboot != -1) {
> if (stop_on_reboot) {
> if (!wdd->ops->stop)
> pr_warn("watchdog%d: stop_on_reboot not
> supported\n", wdd->id);
> else
> set_bit(WDOG_STOP_ON_REBOOT, >status);
> } else {
> clear_bit(WDOG_STOP_ON_REBOOT, >status);
> }
> }
>
> Thanks,
> Guenter
Now the divergence is that should we stop the registering process and
return error when the STOP_ON_REBOOT flag is set but the driver doesn't
support it. The flag is set in two scenes.
Firstly,the driver that should provide the stop hook may set the flag
staticlly, and it is a bug of the driver if it set the flag but without
a stop hook. Then giving an error shall be more striking.
Secondly, the user can change the flag using module parameter. Is it
reasonable to just ignore the STOP_ON_REBOOT flag and give a warning
when the user truely want it? And under this circumstance a warning is
easier to get unnoticed than an error.
I prefer to stop the registering process and return an error in those
two scenes.
Thanks
>
>>
>> +wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
>> ret = register_reboot_notifier(>reboot_nb);
>> if (ret) {
>> pr_err("watchdog%d: Cannot register reboot notifier
>> (%d)\n",
>> --
>> 2.25.0
>>
>
Re: [PATCH] fsl/fman: add missing put_devcie() call in fman_port_probe()
On 2020/11/03 9:30, Jakub Kicinski wrote:
On Sat, 31 Oct 2020 18:54:18 +0800 Yu Kuai wrote:
if of_find_device_by_node() succeed, fman_port_probe() doesn't have a
corresponding put_device(). Thus add jump target to fix the exception
handling for this function implementation.
Fixes: 0572054617f3 ("fsl/fman: fix dereference null return value")
Signed-off-by: Yu Kuai
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c
b/drivers/net/ethernet/freescale/fman/fman_port.c
index d9baac0dbc7d..576ce6df3fce 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.c
+++ b/drivers/net/ethernet/freescale/fman/fman_port.c
@@ -1799,13 +1799,13 @@ static int fman_port_probe(struct platform_device
*of_dev)
of_node_put(fm_node);
if (!fm_pdev) {
err = -EINVAL;
- goto return_err;
+ goto put_device;
}
@@ -1898,6 +1898,8 @@ static int fman_port_probe(struct platform_device *of_dev)
return_err:
of_node_put(port_node);
+put_device:
+ put_device(_pdev->dev);
free_port:
kfree(port);
return err;
This does not look right. You're jumping to put_device() when fm_pdev
is NULL?
Hi,
oops, it's a silly mistake. Will fix it in V2 patch.
Thanks,
Yu Kuai
The order of error handling should be the reverse of the order of
execution of the function.
.
Re: [PATCH] iommu/rockchip: check return value of of_find_device_by_node() in rk_iommu_of_xlate()
On 2020/10/29 21:51, Robin Murphy wrote: On 2020-10-29 13:19, yukuai (C) wrote: On 2020/10/29 18:08, Robin Murphy wrote: On 2020-10-29 09:22, Yu Kuai wrote: If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer dereference will be triggered. Thus return error code if of_find_device_by_node() failed. How can that happen? (Given that ".suppress_bind_attrs = true") Robin. I'm not sure if that could happen... My thought is that it's better to do such checking to aviod any possible problem. ->of_xlate() is only invoked on the specific set of ops returned by iommu_ops_from_fwnode(). In turn, iommu_ops_from_fwnode() will only return those ops if the driver has successfully probed and called iommu_register_device() with the relevant DT node. For the driver to have been able to probe at all, a platform device associated with that DT node must have been created, and therefore of_find_device_by_node() cannot fail. If there ever were some problem serious enough to break that fundamental assumption, then I *want* these drivers to crash right here, with a nice clear stack trace to start debugging from. So no, I firmly disagree that adding redundant code, which will never do anything except attempt to paper over catastrophic memory corruption, is "better". Sorry :) Sounds reasonable, thanks for your explanation Yu Kuai
[ANNOUNCE] Git v2.29.2
The latest maintenance release Git v2.29.2 is now available at the usual places. This is to fix the "--committer-date-is-author-date" feature of "rebase" that was completely broken in v2.29.0 release. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.29.2' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git Git v2.29.2 Release Notes = This release is primarily to fix brown-paper-bag breakages in the 2.29.0 release. Fixes since v2.29.1 --- * In 2.29, "--committer-date-is-author-date" option of "rebase" and "am" subcommands lost the e-mail address by mistake, which has been corrected. Changes since v2.29.1 are as follows: Christian Couder (1): filter-branch doc: fix filter-repo typo Jeff King (3): t3436: check --committer-date-is-author-date result more carefully am: fix broken email with --committer-date-is-author-date rebase: fix broken email with --committer-date-is-author-date Junio C Hamano (1): Git 2.29.2
Re: [PATCH] iommu/rockchip: check return value of of_find_device_by_node() in rk_iommu_of_xlate()
On 2020/10/29 18:08, Robin Murphy wrote: On 2020-10-29 09:22, Yu Kuai wrote: If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer dereference will be triggered. Thus return error code if of_find_device_by_node() failed. How can that happen? (Given that ".suppress_bind_attrs = true") Robin. I'm not sure if that could happen... My thought is that it's better to do such checking to aviod any possible problem. Thanks! Yu Kuai
[ANNOUNCE] Git v2.29.1
The latest maintenance release Git v2.29.1 is now available at the usual places. The change in this release affects only those who build from the source *and* install with a non-standard SKIP_DASHED_BUILT_INS option turned on. With the option turned on, Git 2.29 forgot to install a few programs in /usr/bin that made it unusable as the server side to accept pushes and fetches. To everybody else, this release is irrelevant and ignorable. We know about at least one other brown-paper-bag regression we are going to fix with another maintenance release, so it may be a better idea to wait for 2.29.2 for most people. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.29.1' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git Git v2.29.1 Release Notes = This is to fix the build procedure change in 2.29 where we failed to install a few programs that should be installed in /usr/bin (namely, receive-pack, upload-archive and upload-pack) when the non-default SKIP_DASHED_BUILT_INS installation option is in effect. A minor glitch in a non-default installation may usually not deserve a hotfix, but I think Git for Windows ship binaries built with this option, so let's make an exception. Changes since v2.29.0 are as follows: Johannes Schindelin (1): SKIP_DASHED_BUILT_INS: do not skip the bin/ programs Junio C Hamano (1): Git 2.29.1
[ANNOUNCE] Git v2.29.0
The latest feature release Git v2.29.0 is now available at the usual places. It is comprised of 627 non-merge commits since v2.28.0, contributed by 89 people, 24 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.29.0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.28.0 are as follows. Welcome to the Git development community! Aaron Lipman, Adrian Moennich, Ákos Uzonyi, Antti Keränen, Christian Schlack, Conor Davis, Daniel Santos, Eric Huber, Evan Gates, Han Xin, Hugo Locurcio, Kyohei Kadota, Lin Sun, Nikita Leonov, Noam Yorav-Raphael, pudinha, Raymond E. Pasco, Ryan Zoeller, Samanta Navarro, Serg Tereshchenko, Sibi Siddharthan, Simon Legner, Steve Kemp, and Theodore Dubois. Returning contributors who helped this release are as follows. Thanks for your continued support. Ævar Arnfjörð Bjarmason, Alban Gruin, Alessandro Menti, Alexander Shopov, Alex Henrie, Alex Riesen, Andrei Rybak, Beat Bolli, Ben Wijen, brian m. carlson, Christian Couder, Chris Torek, Danny Lin, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Drew DeVault, Edmundo Carmona Antoranz, Elijah Newren, Emily Shaffer, Emir Sarı, Eric Sunshine, Han-Wen Nienhuys, Hariom Verma, Jacob Keller, Jean-Noël Avila, Jeff Hostetler, Jeff King, Jiang Xin, Johannes Berg, Johannes Schindelin, Johannes Sixt, Jonathan Tan, Jordi Mas, Junio C Hamano, Kazuhiro Kato, Luke Diamand, Martin Ågren, Matheus Tavares, Matthew Rogers, Matthias Rüster, Michael Forney, Michal Privoznik, Miriam Rubio, Orgad Shaneh, Patrick Steinhardt, Paul Mackerras, Peter Krefting, Philippe Blain, Phillip Wood, Pranit Bauva, Prathamesh Chavan, Pratyush Yadav, René Scharfe, Rohit Ashiwal, Sergey Organov, Shourya Shukla, Stefan Dotterweich, Stefan Haller, SZEDER Gábor, Taylor Blau, Thomas Guyot-Sionnest, Trần Ngọc Quân, Yi-Jyun Pan, and Роман Донченко. Git 2.29 Release Notes == Updates since v2.28 --- UI, Workflows & Features * "git help log" has been enhanced by sharing more material from the documentation for the underlying "git rev-list" command. * "git for-each-ref --format=<>" learned %(contents:size). * "git merge" learned to selectively omit " into " at the end of the title of default merge message with merge.suppressDest configuration. * The component to respond to "git fetch" request is made more configurable to selectively allow or reject object filtering specification used for partial cloning. * Stop when "sendmail.*" configuration variables are defined, which could be a mistaken attempt to define "sendemail.*" variables. * The existing backends for "git mergetool" based on variants of vim have been refactored and then support for "nvim" has been added. * "git bisect" learns the "--first-parent" option to find the first breakage along the first-parent chain. * "git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. * The commit labels used to explain each side of conflicted hunks placed by the sequencer machinery have been made more readable by humans. * The "--batch-size" option of "git multi-pack-index repack" command is now used to specify that very small packfiles are collected into one until the total size roughly exceeds it. * The recent addition of SHA-256 support is marked as experimental in the documentation. * "git fetch" learned --no-write-fetch-head option to avoid writing the FETCH_HEAD file. * Command line completion (in contrib/) usually omits redundant, deprecated and/or dangerous options from its output; it learned to optionally include all of them. * The output from the "diff" family of the commands had abbreviated object names of blobs involved in the patch, but its length was not affected by the --abbrev option. Now it is. * "git worktree" gained a "repair" subcommand to help users recover after moving the worktrees or repository manually without telling Git. Also, "git init --separate-git-dir" no longer corrupts administrative data related to linked worktrees. * The "--format=" option to the "for-each-ref" command and friends learned a few more tri
[PATCH] vfio iommu type1: Fix memory leak in vfio_iommu_type1_pin_pages
>From 099744c26513e386e707faecb3f17726e236d9bc Mon Sep 17 00:00:00 2001
From: Xiaoyang Xu
Date: Fri, 16 Oct 2020 15:32:02 +0800
Subject: [PATCH] vfio iommu type1: Fix memory leak in
vfio_iommu_type1_pin_pages
pfn is not added to pfn_list when vfio_add_to_pfn_list fails.
vfio_unpin_page_external will exit directly without calling
vfio_iova_put_vfio_pfn.This will lead to a memory leak.
Signed-off-by: Xiaoyang Xu
---
drivers/vfio/vfio_iommu_type1.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c255a6683f31..26f518b02c81 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -640,6 +640,7 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
unsigned long remote_vaddr;
struct vfio_dma *dma;
bool do_accounting;
+ int unlocked;
if (!iommu || !user_pfn || !phys_pfn)
return -EINVAL;
@@ -693,7 +694,9 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
ret = vfio_add_to_pfn_list(dma, iova, phys_pfn[i]);
if (ret) {
- vfio_unpin_page_external(dma, iova, do_accounting);
+ unlocked = put_pfn(phys_pfn[i], dma->prot);
+ if (do_accounting)
+ vfio_lock_acct(dma, -unlocked, true);
goto pin_unwind;
}
--
2.19.1
[ANNOUNCE] Git v2.29.0-rc2
The transport protocol v2 has become the default again. * The installation procedure learned to optionally omit "git-foo" executable files for each 'foo' built-in subcommand, which are only required by old timers that still rely on the age old promise that prepending "git --exec-path" output to PATH early in their script will keep the "git-foo" calls they wrote working. * The command line completion (in contrib/) learned that "git restore -s " is often followed by a refname. * "git shortlog" has been taught to group commits by the contents of the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc. * "git archive" learns the "--add-file" option to include untracked files into a snapshot from a tree-ish. * "git fetch" and "git push" support negative refspecs. * "git format-patch" learns to take "whenAble" as a possible value for the format.useAutoBase configuration variable to become no-op when the automatically computed base does not make sense. * Credential helpers are now allowed to terminate lines with CRLF line ending, as well as LF line ending. Performance, Internal Implementation, Development Support etc. * The changed-path Bloom filter is improved using ideas from an independent implementation. * Updates to the changed-paths bloom filter. * The test framework has been updated so that most tests will run with predictable (artificial) timestamps. * Preliminary clean-up of the refs API in preparation for adding a new refs backend "reftable". * Dev support to limit the use of test_must_fail to only git commands. * While packing many objects in a repository with a promissor remote, lazily fetching missing objects from the promissor remote one by one may be inefficient---the code now attempts to fetch all the missing objects in batch (obviously this won't work for a lazy clone that lazily fetches tree objects as you cannot even enumerate what blobs are missing until you learn which trees are missing). * The pretend-object mechanism checks if the given object already exists in the object store before deciding to keep the data in-core, but the check would have triggered lazy fetching of such an object from a promissor remote. * The argv_array API is useful for not just managing argv but any "vector" (NULL-terminated array) of strings, and has seen adoption to a certain degree. It has been renamed to "strvec" to reduce the barrier to adoption. * The final leg of SHA-256 transition plus doc updates. Note that there is no interoperability between SHA-1 and SHA-256 repositories yet. * CMake support to build with MSVC for Windows bypassing the Makefile. * A new helper function has_object() has been introduced to make it easier to mark object existence checks that do and don't want to trigger lazy fetches, and a few such checks are converted using it. * A no-op replacement function implemented as a C preprocessor macro does not perform as good a job as one implemented as a "static inline" function in catching errors in parameters; replace the former with the latter in header. * Test framework update. (merge d572f52a64 es/test-cmp-typocatcher later to maint). * Updates to "git merge" tests, in preparation for a new merge strategy backend. * midx and commit-graph files now use the byte defined in their file format specification for identifying the hash function used for object names. * The FETCH_HEAD is now always read from the filesystem regardless of the ref backend in use, as its format is much richer than the normal refs, and written directly by "git fetch" as a plain file.. * An unused binary has been discarded, and and a bunch of commands have been turned into into built-in. * A handful of places in in-tree code still relied on being able to execute the git subcommands, especially built-ins, in "git-foo" form, which have been corrected. * When a packfile is removed by "git repack", multi-pack-index gets cleared; the code was taught to do so less aggressively by first checking if the midx actually refers to a pack that no longer exists. * Internal API clean-up to handle two options "diff-index" and "log" have, which happen to share the same short form, more sensibly. * The "add -i/-p" machinery has been written in C but it is not used by default yet. It is made default to those who are participating in feature.experimental experiment. * Allow maintainers to tweak $(TAR) invocations done while making distribution tarballs. * "git index-pack" learned to resolve deltified objects with greater parallelism. * "diff-highlight" (in contrib/) had a logi
zram NULL pointer dereference (zs_malloc)
I found a serious bug about kernel NULL pointer dereference when using zram (in my case zram+btrfs) that makes system unstable and usually ends in a forced unclean reboot like powering off power source. This issue is present since >5.8.0 version (this one seems not affected) and still present in 5.9.0 and reported in https://bugzilla.kernel.org/show_bug.cgi?id=209153 Since this issue seems major enough, can someone please review this issue? Thanks. OpenPGP_0x2D7138D2C33652B5.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[ANNOUNCE] Git v2.29.0-rc1
A release candidate Git v2.29.0-rc1 is now available for testing at the usual places. It is comprised of 605 non-merge commits since v2.28.0, contributed by 77 people, 22 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.29.0-rc1' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.28.0 are as follows. Welcome to the Git development community! Aaron Lipman, Adrian Moennich, Ákos Uzonyi, Antti Keränen, Christian Schlack, Conor Davis, Eric Huber, Evan Gates, Han Xin, Hugo Locurcio, Kyohei Kadota, Lin Sun, Nikita Leonov, Noam Yorav-Raphael, pudinha, Raymond E. Pasco, Ryan Zoeller, Samanta Navarro, Sibi Siddharthan, Simon Legner, Steve Kemp, and Theodore Dubois. Returning contributors who helped this release are as follows. Thanks for your continued support. Ævar Arnfjörð Bjarmason, Alban Gruin, Alex Henrie, Alex Riesen, Andrei Rybak, Beat Bolli, Ben Wijen, brian m. carlson, Christian Couder, Chris Torek, Danny Lin, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Drew DeVault, Edmundo Carmona Antoranz, Elijah Newren, Emily Shaffer, Eric Sunshine, Han-Wen Nienhuys, Hariom Verma, Jacob Keller, Jean-Noël Avila, Jeff Hostetler, Jeff King, Jiang Xin, Johannes Berg, Johannes Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano, Kazuhiro Kato, Luke Diamand, Martin Ågren, Matheus Tavares, Matthew Rogers, Michael Forney, Michal Privoznik, Miriam Rubio, Orgad Shaneh, Patrick Steinhardt, Paul Mackerras, Philippe Blain, Phillip Wood, Pranit Bauva, Prathamesh Chavan, René Scharfe, Rohit Ashiwal, Sergey Organov, Shourya Shukla, Stefan Dotterweich, SZEDER Gábor, Taylor Blau, Thomas Guyot-Sionnest, and Роман Донченко. Git 2.29 Release Notes (draft) == Updates since v2.28 --- UI, Workflows & Features * "git help log" has been enhanced by sharing more material from the documentation for the underlying "git rev-list" command. * "git for-each-ref --format=<>" learned %(contents:size). * "git merge" learned to selectively omit " into " at the end of the title of default merge message with merge.suppressDest configuration. * The component to respond to "git fetch" request is made more configurable to selectively allow or reject object filtering specification used for partial cloning. * Stop when "sendmail.*" configuration variables are defined, which could be a mistaken attempt to define "sendemail.*" variables. * The existing backends for "git mergetool" based on variants of vim have been refactored and then support for "nvim" has been added. * "git bisect" learns the "--first-parent" option to find the first breakage along the first-parent chain. * "git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. * The commit labels used to explain each side of conflicted hunks placed by the sequencer machinery have been made more readable by humans. * The "--batch-size" option of "git multi-pack-index repack" command is now used to specify that very small packfiles are collected into one until the total size roughly exceeds it. * The recent addition of SHA-256 support is marked as experimental in the documentation. * "git fetch" learned --no-write-fetch-head option to avoid writing the FETCH_HEAD file. * Command line completion (in contrib/) usually omits redundant, deprecated and/or dangerous options from its output; it learned to optionally include all of them. * The output from the "diff" family of the commands had abbreviated object names of blobs involved in the patch, but its length was not affected by the --abbrev option. Now it is. * "git worktree" gained a "repair" subcommand to help users recover after moving the worktrees or repository manually without telling Git. Also, "git init --separate-git-dir" no longer corrupts administrative data related to linked worktrees. * The "--format=" option to the "for-each-ref" command and friends learned a few more tricks, e.g. the ":short" suffix that applies to "objectname" now also can be used for "parent", "tree", etc.
Re: [ANNOUNCE] Git v2.29.0-rc0
Martin Ågren writes: > Minor comments follow. > ... > s/used // (without 'g' flag!) Thanks.
[ANNOUNCE] Git v2.29.0-rc0
An early preview release Git v2.29.0-rc0 is now available for testing at the usual places. It is comprised of 588 non-merge commits since v2.28.0, contributed by 76 people, 22 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.29.0-rc0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.28.0 are as follows. Welcome to the Git development community! Aaron Lipman, Adrian Moennich, Ákos Uzonyi, Antti Keränen, Christian Schlack, Conor Davis, Eric Huber, Evan Gates, Han Xin, Hugo Locurcio, Kyohei Kadota, Lin Sun, Nikita Leonov, Noam Yorav-Raphael, pudinha, Raymond E. Pasco, Ryan Zoeller, Samanta Navarro, Sibi Siddharthan, Simon Legner, Steve Kemp, and Theodore Dubois. Returning contributors who helped this release are as follows. Thanks for your continued support. Ævar Arnfjörð Bjarmason, Alban Gruin, Alex Henrie, Alex Riesen, Andrei Rybak, Beat Bolli, Ben Wijen, brian m. carlson, Christian Couder, Chris Torek, Danny Lin, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Drew DeVault, Edmundo Carmona Antoranz, Elijah Newren, Emily Shaffer, Eric Sunshine, Han-Wen Nienhuys, Hariom Verma, Jacob Keller, Jeff Hostetler, Jeff King, Jiang Xin, Johannes Berg, Johannes Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano, Kazuhiro Kato, Luke Diamand, Martin Ågren, Matheus Tavares, Matthew Rogers, Michael Forney, Michal Privoznik, Miriam Rubio, Orgad Shaneh, Patrick Steinhardt, Paul Mackerras, Philippe Blain, Phillip Wood, Pranit Bauva, Prathamesh Chavan, René Scharfe, Rohit Ashiwal, Sergey Organov, Shourya Shukla, Stefan Dotterweich, SZEDER Gábor, Taylor Blau, Thomas Guyot-Sionnest, and Роман Донченко. Git 2.29 Release Notes (draft) == Updates since v2.28 --- UI, Workflows & Features * "git help log" has been enhanced by sharing more material from the documentation for the underlying "git rev-list" command. * "git for-each-ref --format=<>" learned %(contents:size). * "git merge" learned to selectively omit " into " at the end of the title of default merge message with merge.suppressDest configuration. * The component to respond to "git fetch" request is made more configurable to selectively allow or reject object filtering specification used for partial cloning. * Stop when "sendmail.*" configuration variables are defined, which could be a mistaken attempt to define "sendemail.*" variables. * The existing backends for "git mergetool" based on variants of vim have been refactored and then support for "nvim" has been added. * "git bisect" learns the "--first-parent" option to find the first breakage along the first-parent chain. * "git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. * The commit labels used to explain each side of conflicted hunks placed by the sequencer machinery have been made more readable by humans. * The "--batch-size" option of "git multi-pack-index repack" command is now used to specify that very small packfiles are collected into one until the total size roughly exceeds it. * The recent addition of SHA-256 support is marked as experimental in the documentation. * "git fetch" learned --no-write-fetch-head option to avoid writing the FETCH_HEAD file. * Command line completion (in contrib/) usually omits redundant, deprecated and/or dangerous options from its output; it learned to optionally include all of them. * The output from the "diff" family of the commands had abbreviated object names of blobs involved in the patch, but its length was not affected by the --abbrev option. Now it is. * "git worktree" gained a "repair" subcommand to help users recover after moving the worktrees or repository manually without telling Git. Also, "git init --separate-git-dir" no longer corrupts administrative data related to linked worktrees. * The "--format=" option to the "for-each-ref" command and friends learned a few more tricks, e.g. the ":short" suffix that applies to "objectname" now also can be used for "parent", "tree", etc. * "git wor
Re: Linux 5.9-rc7
Am Mo., 28. Sept. 2020 um 00:00 Uhr schrieb Linus Torvalds : Hello, > Shortlog appended, but what I really hope you all will do is to give > it a nice good testing. One extra week or rc kernels will help, but > only if people actually try this out. > > So.. Please? I'm a bit late testing, but the first thing I noticed is this warning: ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text' ld: warning: creating DT_TEXTREL in a PIE The compiler is gcc 9.2.1 20200215, with default PIE enabled, ld version 2.35.1. The config used is the 64bit defconfig. Best Regards, Gabriel C.
Re: [PATCH] iommu/qcom: add missing put_device() call in qcom_iommu_of_xlate()
On 2020/09/29 7:08, Will Deacon wrote: On Mon, Sep 21, 2020 at 09:45:57PM +0100, Will Deacon wrote: On Tue, Sep 22, 2020 at 03:13:53AM +0800, kernel test robot wrote: Thank you for the patch! Perhaps something to improve: [auto build test WARNING on iommu/next] [also build test WARNING on linus/master v5.9-rc6 next-20200921] [cannot apply to robclark/msm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Yu-Kuai/iommu-qcom-add-missing-put_device-call-in-qcom_iommu_of_xlate/20200918-091341 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: arm64-randconfig-r023-20200920 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 4e8c028158b56d9c2142a62464e8e0686bde3584) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/iommu/arm/arm-smmu/qcom_iommu.c:601:4: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] return -EINVAL; ^ drivers/iommu/arm/arm-smmu/qcom_iommu.c:599:3: note: previous statement is here if (WARN_ON(qcom_iommu != dev_iommu_priv_get(dev))) Oh, this looks like a nasty bug. Seems we're missing some braces. Yu Kuai: please could you send a v2 of this? Hi, Will Thanks for your notice, will send a V2 soon. Yu Kuai
Re: [RFC PATCH V4] iomap: add support to track dirty state of sub pages
On 2020/09/11 20:05, Matthew Wilcox wrote: @@ -683,7 +736,7 @@ static size_t __iomap_write_end(struct inode *inode, loff_t pos, size_t len, if (unlikely(copied < len && !PageUptodate(page))) return 0; iomap_set_range_uptodate(page, offset_in_page(pos), len); - iomap_set_page_dirty(page); + iomap_set_range_dirty(page, offset_in_page(pos), len); I_think_ the call to set_range_uptodate here is now unnecessary. The blocks should already have been set uptodate in write_begin. But please check! Hi, Matthew Sorry it took me so long to get back to this. I found that set_range_uptodate() might be skipped in write_begin() in this case: if (!(flags & IOMAP_WRITE_F_UNSHARE) && ┊ (from <= poff || from >= poff + plen) && ┊ (to <= poff || to >= poff + plen)) continue; And iomap_adjust_read_range() can set 'poff' greater than 'from' and 'poff + len' less than 'to'. Thanks Yu Kuai
Re: [RFC PATCH V4] iomap: add support to track dirty state of sub pages
Hi,
Sorry that after copy and paste, the content of the patch somehow
changed and looks strange.
Best regards,
Yu Kuai
On 2020/09/11 16:27, yukuai (C) wrote:
On 2020/08/21 20:44, Matthew Wilcox wrote:
On Fri, Aug 21, 2020 at 08:33:06PM +0800, Yu Kuai wrote:
changes from v3: - add IOMAP_STATE_ARRAY_SIZE - replace set_bit /
clear_bit with bitmap_set / bitmap_clear - move
iomap_set_page_dirty() out of 'iop->state_lock' - merge
iomap_set/clear_range_dirty() and iomap_iop_clear/clear_range_dirty()
I'm still working on the iomap parts of the THP series (fixing up
invalidatepage right now), but here are some of the relevant bits
(patch series to follow)
Hi, Matthew
Since your THP iomap patches were reviewed, I made some modifications
based on these patches.
Best regards,
Yu Kuai
---
fs/iomap/buffered-io.c | 92 +-
1 file changed, 74 insertions(+), 18 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index edf5eea56cf5..bc7f57748be8 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -23,13 +23,17 @@
/*
* Structure allocated for each page or THP when block size < page size
- * to track sub-page uptodate status and I/O completions.
+ * to track sub-page status and I/O completions.
*/
struct iomap_page {
atomic_t read_bytes_pending;
atomic_t write_bytes_pending;
- spinlock_t uptodate_lock;
- unsigned long uptodate[];
+ spinlock_t state_lock;
+ /*
+ * The first half bits are used to track sub-page uptodate status,
+ * the second half bits are for dirty status.
+ */
+ unsigned long state[];
};
static inline struct iomap_page *to_iomap_page(struct page *page)
@@ -57,9 +61,9 @@ iomap_page_create(struct inode *inode, struct page *page)
if (iop || nr_blocks <= 1)
return iop;
- iop = kzalloc(struct_size(iop, uptodate, BITS_TO_LONGS(nr_blocks)),
+ iop = kzalloc(struct_size(iop, state, BITS_TO_LONGS(2 * nr_blocks)),
GFP_NOFS | __GFP_NOFAIL);
- spin_lock_init(>uptodate_lock);
+ spin_lock_init(>state_lock);
attach_page_private(page, iop);
return iop;
}
@@ -74,7 +78,7 @@ iomap_page_release(struct page *page)
return;
WARN_ON_ONCE(atomic_read(>read_bytes_pending));
WARN_ON_ONCE(atomic_read(>write_bytes_pending));
- WARN_ON_ONCE(bitmap_full(iop->uptodate, nr_blocks) !=
+ WARN_ON_ONCE(bitmap_full(iop->state, nr_blocks) !=
PageUptodate(page));
kfree(iop);
}
@@ -105,7 +109,7 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
/* move forward for each leading block marked uptodate */
for (i = first; i <= last; i++) {
- if (!test_bit(i, iop->uptodate))
+ if (!test_bit(i, iop->state))
break;
*pos += block_size;
poff += block_size;
@@ -115,7 +119,7 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
/* truncate len if we find any trailing uptodate block(s) */
for ( ; i <= last; i++) {
- if (test_bit(i, iop->uptodate)) {
+ if (test_bit(i, iop->state)) {
plen -= (last - i + 1) * block_size;
last = i - 1;
break;
@@ -139,6 +143,55 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
*lenp = plen;
}
+static void
+iomap_set_range_dirty(struct page *page, unsigned int off,
+ unsigned int len)
+{
+ struct inode *inode = page->mapping->host;
+ unsigned int blocks_per_page = i_blocks_per_page(inode, page);
+ unsigned int first = (off >> inode->i_blkbits) + blocks_per_page;
+ unsigned int last = ((off + len - 1) >> inode->i_blkbits) +
blocks_per_page;
+ unsigned long flags;
+ struct iomap_page *iop;
+
+ if (PageError(page))
+ return;
+
+ if (len)
+ iomap_set_page_dirty(page);
+
+ if (!page_has_private(page))
+ return;
+
+ iop = to_iomap_page(page);
+ spin_lock_irqsave(>state_lock, flags);
+ bitmap_set(iop->state, first, last - first + 1);
+ spin_unlock_irqrestore(>state_lock, flags);
+}
+
+static void
+iomap_clear_range_dirty(struct page *page, unsigned int off,
+ unsigned int len)
+{
+ struct inode *inode = page->mapping->host;
+ unsigned int blocks_per_page = i_blocks_per_page(inode, page);
+ unsigned int first = (off >> inode->i_blkbits) + blocks_per_page;
+ unsigned int last = ((off + len - 1) >> inode->i_blkbits) +
blocks_per_page;
+ unsigned long flags;
+ struct iomap_page *iop;
+
+ if (PageError(page))
+ return;
+
+ if (!page_has_private(page))
+ return;
+
+ iop = to_iomap_page(page);
+ spin_lock_irqsave(>state_lock, flags);
+ bitmap_clear(
Re: [RFC PATCH V4] iomap: add support to track dirty state of sub pages
On 2020/08/21 20:44, Matthew Wilcox wrote:
On Fri, Aug 21, 2020 at 08:33:06PM +0800, Yu Kuai wrote:
changes from v3: - add IOMAP_STATE_ARRAY_SIZE - replace set_bit /
clear_bit with bitmap_set / bitmap_clear - move
iomap_set_page_dirty() out of 'iop->state_lock' - merge
iomap_set/clear_range_dirty() and
iomap_iop_clear/clear_range_dirty()
I'm still working on the iomap parts of the THP series (fixing up
invalidatepage right now), but here are some of the relevant bits
(patch series to follow)
Hi, Matthew
Since your THP iomap patches were reviewed, I made some modifications
based on these patches.
Best regards,
Yu Kuai
---
fs/iomap/buffered-io.c | 92 +-
1 file changed, 74 insertions(+), 18 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index edf5eea56cf5..bc7f57748be8 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -23,13 +23,17 @@
/*
* Structure allocated for each page or THP when block size < page size
- * to track sub-page uptodate status and I/O completions.
+ * to track sub-page status and I/O completions.
*/
struct iomap_page {
atomic_tread_bytes_pending;
atomic_twrite_bytes_pending;
- spinlock_t uptodate_lock;
- unsigned long uptodate[];
+ spinlock_t state_lock;
+ /*
+* The first half bits are used to track sub-page uptodate status,
+* the second half bits are for dirty status.
+*/
+ unsigned long state[];
};
static inline struct iomap_page *to_iomap_page(struct page *page)
@@ -57,9 +61,9 @@ iomap_page_create(struct inode *inode, struct page *page)
if (iop || nr_blocks <= 1)
return iop;
- iop = kzalloc(struct_size(iop, uptodate, BITS_TO_LONGS(nr_blocks)),
+ iop = kzalloc(struct_size(iop, state, BITS_TO_LONGS(2 * nr_blocks)),
GFP_NOFS | __GFP_NOFAIL);
- spin_lock_init(>uptodate_lock);
+ spin_lock_init(>state_lock);
attach_page_private(page, iop);
return iop;
}
@@ -74,7 +78,7 @@ iomap_page_release(struct page *page)
return;
WARN_ON_ONCE(atomic_read(>read_bytes_pending));
WARN_ON_ONCE(atomic_read(>write_bytes_pending));
- WARN_ON_ONCE(bitmap_full(iop->uptodate, nr_blocks) !=
+ WARN_ON_ONCE(bitmap_full(iop->state, nr_blocks) !=
PageUptodate(page));
kfree(iop);
}
@@ -105,7 +109,7 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
/* move forward for each leading block marked uptodate */
for (i = first; i <= last; i++) {
- if (!test_bit(i, iop->uptodate))
+ if (!test_bit(i, iop->state))
break;
*pos += block_size;
poff += block_size;
@@ -115,7 +119,7 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
/* truncate len if we find any trailing uptodate block(s) */
for ( ; i <= last; i++) {
- if (test_bit(i, iop->uptodate)) {
+ if (test_bit(i, iop->state)) {
plen -= (last - i + 1) * block_size;
last = i - 1;
break;
@@ -139,6 +143,55 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
*lenp = plen;
}
+static void
+iomap_set_range_dirty(struct page *page, unsigned int off,
+ unsigned int len)
+{
+ struct inode *inode = page->mapping->host;
+ unsigned int blocks_per_page = i_blocks_per_page(inode, page);
+ unsigned int first = (off >> inode->i_blkbits) + blocks_per_page;
+ unsigned int last = ((off + len - 1) >> inode->i_blkbits) +
blocks_per_page;
+ unsigned long flags;
+ struct iomap_page *iop;
+
+ if (PageError(page))
+ return;
+
+ if (len)
+ iomap_set_page_dirty(page);
+
+ if (!page_has_private(page))
+ return;
+
+ iop = to_iomap_page(page);
+ spin_lock_irqsave(>state_lock, flags);
+ bitmap_set(iop->state, first, last - first + 1);
+ spin_unlock_irqrestore(>state_lock, flags);
+}
+
+static void
+iomap_clear_range_dirty(struct page *page, unsigned int off,
+ unsigned int len)
+{
+ struct inode *inode = page->mapping->host;
+ unsigned int blocks_per_page = i_blocks_per_page(inode, page);
+ unsigned int first = (off >> inode->i_blkbits) + blocks_per_page;
+ unsigned int last = ((off + len - 1) >> inode->i_blkbits) +
blocks_per_page;
+ unsigned long flags;
+ struct iomap_page *iop;
+
+ if (PageError(page))
+ return;
+
+ if (!page_has_private(page))
+ return;
+
+ iop =
Re: [PATCH] drm/mediatek: add missing put_device() call in mtk_ddp_comp_init()
On 2020/09/08 6:56, Chun-Kuang Hu wrote: Hi Yu Kuai: Yu Kuai 於 2020年9月5日 週六 下午4:31寫道： if of_find_device_by_node() succeed, mtk_ddp_comp_init() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. This patch looks good to me, but I find another thing related to this. mtk_ddp_comp_init() is called in a loop in mtk_drm_probe(), when this component init fail, I think we should uninitialize previous successive init component and put their device. Would you like to make this patch more complete? Hi, Of course, thank you for your review. Best regards, Yu Kuai
Re: Kernel 5.9-rc Regression: Boot failure with nvme
Am Sa., 29. Aug. 2020 um 19:57 Uhr schrieb Christoph Hellwig : > > On Sat, Aug 29, 2020 at 10:54:47AM -0700, Linus Torvalds wrote: > > Just adding Christoph to the participants list, since at a guess it's > > due to his changes whether they came from the nvme side or the dma > > side.. > > > > Christoph? > > This kinda looks like the sqsize regression we had in earlier 5.9-rc, > but that should have been fixed in -rc2 with git tag --contains 7442ddcedc344b6fa073692f165dffdd1889e780 returns nothing, that commit only exits in master, so probably in -rc3. > > 7442ddcedc344b6fa073692f165dffdd1889e780 > Author: John Garry > Date: Fri Aug 14 23:34:25 2020 +0800 > > nvme-pci: Use u32 for nvme_dev.q_depth and nvme_queue.q_depth > > Daniel, can you double check that you don't have that commit? > > > > > Linus > > > > On Sat, Aug 29, 2020 at 10:06 AM Daniel Exner wrote: > > > > > > Hi, > > > > > > (please keep me in the loop, as I'm currently not suscribed) > > > > > > both 5.9-rc1 and -rc2 fail to boot with my TOSHIBA-RD400 NVME: > > > > > > [1.015590] [ cut here ] > > > [1.015594] WARNING: CPU: 7 PID: 99 at mm/page_alloc.c:4864 > > > __alloc_pages_nodemask+0x299/0x330 > > > [1.015594] Modules linked in: syscopyarea xhci_pci(+) > > > xhci_pci_renesas sysfillrect xhci_hcd nvme aesni_intel(+) crypto_simd > > > sysimgblt fb_sys_fops cryptd nvme_core t10_pi glue_helper drm hwmon > > > scsi_mod agpgart i2c_core usbcore video wmi button dm_mirror > > > dm_region_hash dm_log dm_mod unix ipv6 autofs4 > > > [1.015602] CPU: 7 PID: 99 Comm: kworker/u16:1 Not tainted > > > 5.9.0-rc2-dirty #12 > > > [1.015603] Hardware name: To Be Filled By O.E.M. To Be Filled By > > > O.E.M./Z170 Gaming K6, BIOS P7.50 10/18/2018 > > > [1.015607] Workqueue: nvme-reset-wq nvme_reset_work [nvme] > > > [1.015608] RIP: 0010:__alloc_pages_nodemask+0x299/0x330 > > > [1.015609] Code: 66 0f 85 46 ff ff ff e8 24 46 dd ff e9 3c ff ff ff > > > e8 4b 4f fc ff 48 89 c7 e9 ad fe ff ff 81 e5 00 20 00 00 0f 85 7b ff ff > > > ff <0f> 0b e9 74 ff ff ff 31 c0 e9 1b fe ff ff 65 48 8b 04 25 00 6d 01 > > > [1.015610] RSP: :b3ed002abcb8 EFLAGS: 00010246 > > > [1.015611] RAX: RBX: 9c8e827c4118 RCX: > > > > > > [1.015611] RDX: RSI: 0034 RDI: > > > 0cc0 > > > [1.015612] RBP: R08: R09: > > > > > > [1.015612] R10: 0006 R11: b3ee002abb97 R12: > > > > > > [1.015613] R13: R14: 9c8e921060b0 R15: > > > 0cc0 > > > [1.015614] FS: () GS:9c8e96bc() > > > knlGS: > > > [1.015615] CS: 0010 DS: ES: CR0: 80050033 > > > [1.015615] CR2: 559988e2f4d8 CR3: 0008433e4004 CR4: > > > 003706e0 > > > [1.015616] DR0: DR1: DR2: > > > > > > [1.015617] DR3: DR6: fffe0ff0 DR7: > > > 0400 > > > [1.015617] Call Trace: > > > [1.015621] dma_direct_alloc_pages+0x1e9/0x2c0 > > > [1.015623] ? pci_alloc_irq_vectors_affinity+0xa5/0x100 > > > [1.015626] nvme_alloc_queue+0x10a/0x170 [nvme] > > > [1.015629] nvme_reset_work+0x70b/0x12b0 [nvme] > > > [1.015631] ? nvme_irq_check+0x30/0x30 [nvme] > > > [1.015634] process_one_work+0x1da/0x3d0 > > > [1.015636] worker_thread+0x4a/0x3c0 > > > [1.015637] ? process_one_work+0x3d0/0x3d0 > > > [1.015638] kthread+0x114/0x160 > > > [1.015640] ? kthread_park+0x90/0x90 > > > [1.015641] ret_from_fork+0x22/0x30 > > > [1.015643] ---[ end trace 268d4f4db1ef121e ]--- > > > > > > > > > Resulting in: > > > [1.015644] nvme nvme0: Removing after probe failure status: -12 > > > > > > If you need more infos I can try to provide them. > > > > > > Greetings > > > Daniel > > > > > > > > > > ---end quoted text---
Re: [PATCH] drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()
On 2020/08/25 21:38, Maxime Ripard wrote:
Hi,
On Tue, Aug 25, 2020 at 07:44:03PM +0800, Yu Kuai wrote:
If sun8i_r40_tcon_tv_set_mux() succeed, at_dma_xlate() doesn't have a
corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
Signed-off-by: Yu Kuai
That doesn't sound right, we're not using at_dma_xlate at all in that
driver?
Hi!
sry about that, should be sun8i_r40_tcon_tv_set_mux(), same as the
title said.
Best regards,
Yu Kuai
Re: [PATCH 1/2] ASoC: fsl: imx-es8328: add missing kfree() call in imx_es8328_probe()
On 2020/08/25 20:11, Mark Brown wrote:
On Tue, Aug 25, 2020 at 08:05:30PM +0800, Yu Kuai wrote:
If memory allocation for 'data' or 'comp' succeed, imx_es8328_probe()
doesn't have corresponding kfree() in exception handling. Thus add
kfree() for this function implementation.
@@ -151,7 +151,7 @@ static int imx_es8328_probe(struct platform_device *pdev)
comp = devm_kzalloc(dev, 3 * sizeof(*comp), GFP_KERNEL);
if (!comp) {
The allocation is being done using devm_ which means no explicit kfree()
is needed, the allocation will be automatically unwound when the device
is unbound.
Hi,
Thanks for pointing it out, I'll remove this patch.
Best regards,
Yu Kuai
Re: [RFC PATCH V3] iomap: add support to track dirty state of sub pages
On 2020/8/19 20:56, Gao Xiang wrote:
On Wed, Aug 19, 2020 at 08:05:42PM +0800, Yu Kuai wrote:
...
+static void
+iomap_iop_set_range_dirty(struct page *page, unsigned int off,
+ unsigned int len)
+{
+ struct iomap_page *iop = to_iomap_page(page);
+ struct inode *inode = page->mapping->host;
+ unsigned int first = DIRTY_BITS(off >> inode->i_blkbits);
+ unsigned int last = DIRTY_BITS((off + len - 1) >> inode->i_blkbits);
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(>state_lock, flags);
+ for (i = first; i <= last; i++)
+ set_bit(i, iop->state);
+
+ if (last >= first)
+ iomap_set_page_dirty(page);
set_page_dirty() in the atomic context?
Hi,
You'are right, this shouldn't be inside spin_lock.
+
+ spin_unlock_irqrestore(>state_lock, flags);
+}
+
+static void
+iomap_set_range_dirty(struct page *page, unsigned int off,
+ unsigned int len)
+{
+ if (PageError(page))
+ return;
+
+ if (page_has_private(page))
+ iomap_iop_set_range_dirty(page, off, len);
I vaguely remembered iomap doesn't always set up PagePrivate.
If so, maybe I should move iomap_set_page_dirty() to
ioamp_set_range_dirty().
Thanks,
Yu Kuai
@@ -705,7 +770,7 @@ __iomap_write_end(struct inode *inode, loff_t pos, unsigned
len,
if (unlikely(copied < len && !PageUptodate(page)))
return 0;
iomap_set_range_uptodate(page, offset_in_page(pos), len);
- iomap_set_page_dirty(page);
+ iomap_set_range_dirty(page, offset_in_page(pos), len);
return copied;
}
so here could be suspectable, but I might be wrong here since
I just take a quick look.
Thanks,
Gao Xiang
.
RE: [PATCH 2/2][RFC] tools/power turbostat: Introduce reliable RAPL display
Hi Len, > From: Len Brown > Sent: Friday, August 14, 2020 5:51 AM > To: Chen, Yu C > Cc: Linux PM list ; Linux Kernel Mailing List > ker...@vger.kernel.org>; Zhang, Rui > Subject: Re: [PATCH 2/2][RFC] tools/power turbostat: Introduce reliable RAPL > display > > why not simply use nanosleep(2) > > Do you mean, use nanosleep rather than the timer to accumulate the RAPL data? After thinking for a while, it looks like if we use nanosleep we might need to create a new thread within the turbostat and sleep every few seconds (according to the RAPL register timeout) to accumulate the running RAPL. And might need to deal with some race conditions between new thread and the main turbostat thread. But yes, it can be switched to nanosleep() to check if the code would look simpler. BTW, we have a v3 of the patch at https://lore.kernel.org/patchwork/project/lkml/list/?series=439330 Thanks, Chenyu > -- > Len Brown, Intel Open Source Technology Center
Re: [RFC PATCH] iomap: add support to track dirty state of sub pages
On 2020/7/30 11:19, Matthew Wilcox wrote: Maybe let the discussion on removing the ->uptodate array finish before posting another patch for review? Hi, Matthew! Of course, I missed the discussion thread before sending this path. And thanks for your suggestions. Best regards, Yu Kuai
Re: [RFC PATCH] iomap: add support to track dirty state of sub pages
On 2020/7/30 10:27, Gao Xiang wrote:
Hi Kuai,
On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
commit 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O
without buffer heads") replace the per-block structure buffer_head with
the per-page structure iomap_page. However, iomap_page can't track the
dirty state of sub pages, which will cause performance issue since sub
pages will be writeback even if they are not dirty.
For example, if block size is 4k and page size is 64k:
dd if=/dev/zero of=testfile bs=4k count=16 oflag=sync
With buffer_head implementation, the above dd cmd will writeback 4k in
each round. However, with iomap_page implementation, the range of
writeback in each round is from the start of the page to the end offset
we just wrote.
Thus add support to track dirty state for sub pages in iomap_page.
AFAIK, the current focus is also on the numbers in the original
discussion thread, so it'd be better to show some numbers with
large PAGE_SIZE on this with some workloads as well.
https://lore.kernel.org/r/20200729230503.ga2...@dread.disaster.area
Hi, Xiang!
The problem was found by iozone to test 4k sequintail write in my
case, thanks for pointing out the discussion thread. I'll test it if
this patch have any effect on that situation.
Thanks,
Yu Kuai
e.g. My guess is if the dirty blocks in the page are highly fragmented, maybe
it'd be better to writeback the whole page in an IO rather than individual
blocks.
At a very quick glance, the approach looks good to me.
Thanks,
Gao Xiang
Signed-off-by: Yu Kuai
---
fs/iomap/buffered-io.c | 51 +-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index bcfc288dba3f..ac2676146b98 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -29,7 +29,9 @@ struct iomap_page {
atomic_tread_count;
atomic_twrite_count;
spinlock_t uptodate_lock;
+ spinlock_t dirty_lock;
DECLARE_BITMAP(uptodate, PAGE_SIZE / 512);
+ DECLARE_BITMAP(dirty, PAGE_SIZE / 512);
};
static inline struct iomap_page *to_iomap_page(struct page *page)
@@ -53,7 +55,9 @@ iomap_page_create(struct inode *inode, struct page *page)
atomic_set(>read_count, 0);
atomic_set(>write_count, 0);
spin_lock_init(>uptodate_lock);
+ spin_lock_init(>dirty_lock);
bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE);
+ bitmap_zero(iop->dirty, PAGE_SIZE / SECTOR_SIZE);
/*
* migrate_page_move_mapping() assumes that pages with private data have
@@ -135,6 +139,44 @@ iomap_adjust_read_range(struct inode *inode, struct
iomap_page *iop,
*lenp = plen;
}
+static void
+iomap_iop_set_or_clear_range_dirty(
+ struct page *page,
+ unsigned int off,
+ unsigned int len,
+ bool is_set)
+{
+ struct iomap_page *iop = to_iomap_page(page);
+ struct inode *inode = page->mapping->host;
+ unsigned int first = off >> inode->i_blkbits;
+ unsigned int last = (off + len - 1) >> inode->i_blkbits;
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(>dirty_lock, flags);
+ for (i = first; i <= last; i++)
+ if (is_set)
+ set_bit(i, iop->dirty);
+ else
+ clear_bit(i, iop->dirty);
+ spin_unlock_irqrestore(>dirty_lock, flags);
+}
+
+static void
+iomap_set_or_clear_range_dirty(
+ struct page *page,
+ unsigned int off,
+ unsigned int len,
+ bool is_set)
+{
+ if (PageError(page))
+ return;
+
+ if (page_has_private(page))
+ iomap_iop_set_or_clear_range_dirty(
+ page, off, len, is_set);
3> +}
+
static void
iomap_iop_set_range_uptodate(struct page *page, unsigned off, unsigned len)
{
@@ -705,6 +747,8 @@ __iomap_write_end(struct inode *inode, loff_t pos, unsigned
len,
if (unlikely(copied < len && !PageUptodate(page)))
return 0;
iomap_set_range_uptodate(page, offset_in_page(pos), len);
+ iomap_set_or_clear_range_dirty(
+ page, offset_in_page(pos), len, true);
iomap_set_page_dirty(page);
return copied;
}
@@ -1030,6 +1074,8 @@ iomap_page_mkwrite_actor(struct inode *inode, loff_t pos,
loff_t length,
WARN_ON_ONCE(!PageUptodate(page));
iomap_page_create(inode, page);
set_page_dirty(page);
+ iomap_set_or_clear_range_dirty(
+ page, offset_in_page(pos), length, true);
}
return length;
@@ -1386,7 +1432,8 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc,
for (i = 0, file_offset = page_offset(page);
i < (PAGE_SIZE >> inode->i_blkbits) && file_offset < end_offset;
i++, file_offset +=
[ANNOUNCE] Git v2.28.0
The latest feature release Git v2.28.0 is now available at the
usual places. It is comprised of 317 non-merge commits since
v2.27.0, contributed by 58 people, 13 of which are new faces.
It is smaller than the releases in our recent past, mostly due to
the development cycle was near the shorter end of the spectrum (our
cycles last 8-12 weeks and this was a rare 8-week cycle).
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.28.0'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.27.0 are as follows.
Welcome to the Git development community!
Andrew Ng, Bojun Chen, Chris Torek, David J. Malan, Don
Goodman-Wilson, Jiuyang Xie, Luc Van Oostenryck, Marco Trevisan
(Treviño), Mikhail Terekhov, Miroslav Koškár, Rafael Aquini,
Srinidhi Kaushik, and Trygve Aaberge.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Alessandro Menti, Ben Keene, brian m. carlson,
Carlo Marcelo Arenas Belón, Christian Couder, Christopher
Diaz Riveros, Denton Liu, Derrick Stolee, Đoàn Trần Công
Danh, Elijah Newren, Emily Shaffer, Emir Sarı, Eric Sunshine,
Han-Wen Nienhuys, Jacob Keller, Jean-Noël Avila, Jeff King,
Jiang Xin, Johannes Schindelin, John Lin, Jonathan Nieder,
Jonathan Tan, Jordi Mas, Josh Steadmon, Junio C Hamano, Laurent
Arnoud, Martin Ågren, Matheus Tavares, Matthias Rüster, Paolo
Bonzini, Patrick Steinhardt, Peter Krefting, Pratyush Yadav,
Ralf Thielow, Ramsay Jones, Randall S. Becker, René Scharfe,
Shourya Shukla, SZEDER Gábor, Taylor Blau, Trần Ngọc Quân,
Ville Skyttä, Xin Li, and Yi-Jyun Pan.
Git 2.28 Release Notes
==
Updates since v2.27
---
Backward compatibility notes
* "fetch.writeCommitGraph" is deemed to be still a bit too risky and
is no longer part of the "feature.experimental" set.
UI, Workflows & Features
* The commands in the "diff" family learned to honor "diff.relative"
configuration variable.
* The check in "git fsck" to ensure that the tree objects are sorted
still had corner cases it missed unsorted entries.
* The interface to redact sensitive information in the trace output
has been simplified.
* The command line completion (in contrib/) learned to complete
options that the "git switch" command takes.
* "git diff" used to take arguments in random and nonsense range
notation, e.g. "git diff A..B C", "git diff A..B C...D", etc.,
which has been cleaned up.
* "git diff-files" has been taught to say paths that are marked as
intent-to-add are new files, not modified from an empty blob.
* "git status" learned to report the status of sparse checkout.
* "git difftool" has trouble dealing with paths added to the index
with the intent-to-add bit.
* "git fast-export --anonymize" learned to take customized mapping to
allow its users to tweak its output more usable for debugging.
* The command line completion support (in contrib/) used to be
prepared to work with "set -u" but recent changes got a bit more
sloppy. This has been corrected.
* "git gui" now allows opening work trees from the start-up dialog.
Performance, Internal Implementation, Development Support etc.
* Code optimization for a common case.
(merge 8777616e4d an/merge-single-strategy-optim later to maint).
* We've adopted a convention that any on-stack structure can be
initialized to have zero values in all fields with "= { 0 }",
even when the first field happens to be a pointer, but sparse
complained that a null pointer should be spelled NULL for a long
time. Start using -Wno-universal-initializer option to squelch
it (the latest sparse has it on by default).
* "git log -L..." now takes advantage of the "which paths are touched
by this commit?" info stored in the commit-graph system.
* As FreeBSD is not the only platform whose regexp library reports
a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
automatically and skip the affected tests.
* "git bugreport" learns to report what shell is in use.
* Support for GIT_CURL_VERBOSE has been rewritten in terms of
GIT_TRACE_CURL.
* Preliminary clean-ups around refs API, plus file format
specification documentation for the reftable backend.
* Workaround breakage in MSVC build, where "curl-config --cflags"
gives settings appropriate for GCC build.
* Code clean-up of "git clean" resulted
[ANNOUNCE] Git v2.28.0-rc2
A release candidate Git v2.28.0-rc2 is now available for testing
at the usual places. It is comprised of 301 non-merge commits
since v2.27.0, contributed by 46 people, 12 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.28.0-rc2' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.27.0 are as follows.
Welcome to the Git development community!
Andrew Ng, Chris Torek, David J. Malan, Don Goodman-Wilson,
Jiuyang Xie, Luc Van Oostenryck, Marco Trevisan (Treviño),
Mikhail Terekhov, Miroslav Koškár, Rafael Aquini, Srinidhi
Kaushik, and Trygve Aaberge.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Ben Keene, brian m. carlson, Carlo Marcelo
Arenas Belón, Christian Couder, Denton Liu, Derrick Stolee,
Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer,
Eric Sunshine, Han-Wen Nienhuys, Jacob Keller, Jeff King,
Johannes Schindelin, John Lin, Jonathan Nieder, Jonathan Tan,
Josh Steadmon, Junio C Hamano, Laurent Arnoud, Martin Ågren,
Matheus Tavares, Paolo Bonzini, Patrick Steinhardt, Pratyush
Yadav, Ramsay Jones, Randall S. Becker, René Scharfe, Shourya
Shukla, SZEDER Gábor, Taylor Blau, Ville Skyttä, and Xin Li.
Git 2.28 Release Notes (draft)
==
Updates since v2.27
---
Backward compatibility notes
* "fetch.writeCommitGraph" is deemed to be still a bit too risky and
is no longer part of the "feature.experimental" set.
UI, Workflows & Features
* The commands in the "diff" family learned to honor "diff.relative"
configuration variable.
* The check in "git fsck" to ensure that the tree objects are sorted
still had corner cases it missed unsorted entries.
* The interface to redact sensitive information in the trace output
has been simplified.
* The command line completion (in contrib/) learned to complete
options that the "git switch" command takes.
* "git diff" used to take arguments in random and nonsense range
notation, e.g. "git diff A..B C", "git diff A..B C...D", etc.,
which has been cleaned up.
* "git diff-files" has been taught to say paths that are marked as
intent-to-add are new files, not modified from an empty blob.
* "git status" learned to report the status of sparse checkout.
* "git difftool" has trouble dealing with paths added to the index
with the intent-to-add bit.
* "git fast-export --anonymize" learned to take customized mapping to
allow its users to tweak its output more usable for debugging.
* The command line completion support (in contrib/) used to be
prepared to work with "set -u" but recent changes got a bit more
sloppy. This has been corrected.
* "git gui" now allows opening work trees from the start-up dialog.
Performance, Internal Implementation, Development Support etc.
* Code optimization for a common case.
(merge 8777616e4d an/merge-single-strategy-optim later to maint).
* We've adopted a convention that any on-stack structure can be
initialized to have zero values in all fields with "= { 0 }",
even when the first field happens to be a pointer, but sparse
complained that a null pointer should be spelled NULL for a long
time. Start using -Wno-universal-initializer option to squelch
it (the latest sparse has it on by default).
* "git log -L..." now takes advantage of the "which paths are touched
by this commit?" info stored in the commit-graph system.
* As FreeBSD is not the only platform whose regexp library reports
a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
automatically and skip the affected tests.
* "git bugreport" learns to report what shell is in use.
* Support for GIT_CURL_VERBOSE has been rewritten in terms of
GIT_TRACE_CURL.
* Preliminary clean-ups around refs API, plus file format
specification documentation for the reftable backend.
* Workaround breakage in MSVC build, where "curl-config --cflags"
gives settings appropriate for GCC build.
* Code clean-up of "git clean" resulted in a fix of recent
performance regression.
* Code clean-up in the codepath that serves "git fetch" continues.
* "git merge-base --is-ancestor" is taught to take advantage of the
commit graph.
* Rewrite of parts of the scripted "git submodule" Porcelain command
continues; this time it is "git sub
Re: [PATCH] ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()
On 2020/7/18 6:55, Alexandre Belloni wrote: A better fix would have been to also factorize imx_suspend_alloc_ocram, imx6q_suspend_init, socfpga_setup_ocram_self_refresh and at91_pm_sram_init as they were all copied from pm-imx6.c imx_suspend_alloc_ocram and imx6q_suspend_init are done areadly, socfpga_setup_ocram_self_refresh and at91_pm_sram_init still need to fix. Thanks for pointing out! Yu Kuai
[ANNOUNCE] Git v2.28.0-rc1
A release candidate Git v2.28.0-rc1 is now available for testing
at the usual places. It is comprised of 295 non-merge commits
since v2.27.0, contributed by 43 people, 10 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.28.0-rc1' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.27.0 are as follows.
Welcome to the Git development community!
Andrew Ng, Chris Torek, Don Goodman-Wilson, Jiuyang Xie, Luc
Van Oostenryck, Marco Trevisan (Treviño), Miroslav Koškár,
Rafael Aquini, Srinidhi Kaushik, and Trygve Aaberge.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Ben Keene, brian m. carlson, Carlo Marcelo Arenas
Belón, Christian Couder, Denton Liu, Derrick Stolee, Đoàn
Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine,
Han-Wen Nienhuys, Jacob Keller, Jeff King, Johannes Schindelin,
John Lin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C
Hamano, Laurent Arnoud, Martin Ågren, Matheus Tavares, Paolo
Bonzini, Patrick Steinhardt, Ramsay Jones, Randall S. Becker,
René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau,
Ville Skyttä, and Xin Li.
Git 2.28 Release Notes (draft)
==
Updates since v2.27
---
Backward compatibility notes
* "fetch.writeCommitGraph" is deemed to be still a bit too risky and
is no longer part of the "feature.experimental" set.
UI, Workflows & Features
* The commands in the "diff" family learned to honor "diff.relative"
configuration variable.
* The check in "git fsck" to ensure that the tree objects are sorted
still had corner cases it missed unsorted entries.
* The interface to redact sensitive information in the trace output
has been simplified.
* The command line completion (in contrib/) learned to complete
options that the "git switch" command takes.
* "git diff" used to take arguments in random and nonsense range
notation, e.g. "git diff A..B C", "git diff A..B C...D", etc.,
which has been cleaned up.
* "git diff-files" has been taught to say paths that are marked as
intent-to-add are new files, not modified from an empty blob.
* "git status" learned to report the status of sparse checkout.
* "git difftool" has trouble dealing with paths added to the index
with the intent-to-add bit.
* "git fast-export --anonymize" learned to take customized mapping to
allow its users to tweak its output more usable for debugging.
* The command line completion support (in contrib/) used to be
prepared to work with "set -u" but recent changes got a bit more
sloppy. This has been corrected.
Performance, Internal Implementation, Development Support etc.
* Code optimization for a common case.
(merge 8777616e4d an/merge-single-strategy-optim later to maint).
* We've adopted a convention that any on-stack structure can be
initialized to have zero values in all fields with "= { 0 }",
even when the first field happens to be a pointer, but sparse
complained that a null pointer should be spelled NULL for a long
time. Start using -Wno-universal-initializer option to squelch
it (the latest sparse has it on by default).
* "git log -L..." now takes advantage of the "which paths are touched
by this commit?" info stored in the commit-graph system.
* As FreeBSD is not the only platform whose regexp library reports
a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
automatically and skip the affected tests.
* "git bugreport" learns to report what shell is in use.
* Support for GIT_CURL_VERBOSE has been rewritten in terms of
GIT_TRACE_CURL.
* Preliminary clean-ups around refs API, plus file format
specification documentation for the reftable backend.
* Workaround breakage in MSVC build, where "curl-config --cflags"
gives settings appropriate for GCC build.
* Code clean-up of "git clean" resulted in a fix of recent
performance regression.
* Code clean-up in the codepath that serves "git fetch" continues.
* "git merge-base --is-ancestor" is taught to take advantage of the
commit graph.
* Rewrite of parts of the scripted "git submodule" Porcelain command
continues; this time it is "git submodule set-branch" subcommand's
turn.
* The "fetch/clone" protocol has been updated to allow the server to
in
Re: [ANNOUNCE] Git v2.28.0-rc0
Derrick Stolee writes: > On 7/9/2020 5:40 PM, Junio C Hamano wrote: >> An early preview release Git v2.28.0-rc0 is now available for >> testing at the usual places. > > This might be part of your new process, or it might be an > oversight. It seems that GIT-VERSION-GEN did not update with > this RC, so the built version will still have a 2.27 start [1]. > > This differs from previous rc's [2]. Sorry, I screwed up. Thanks for a set of sharp eyes. I however think that there is no practical problem other than for those who "grep DEF_VER GIT-VERSION-GEN" and base their action on the result. If somebody is building from the tarball created by "make dist" (be it done by me and uploaded to k.org or done by somebody else from a clone of my repository), there would be the "version" file included in the tarball that would override the DEF_VER setting in GIT_VERION_GEN. If somebody is building from a clone of my repository, GIT_VERSION_GEN runs "git describe" to find out which version it is, without using DEF_VER. The only three unrealistic classes of users that may be affected are: - The ones that single-branch cloned from me _with_ --no-tags, so that "git describe" is run but cannot find what version it is. - The ones that _somehow_ cloned from me _without_ having any version of git that can run "git describe" in the repository. - The ones that receives a tarball that was created by running "make dist" in the directory that resulted from extracting the official tarball and then removed the ./version file included in the official tarball. For the people in the first two classes, GIT-VERSION-GEN would fail to use "git describe" to find which version it is building, and end up using DEF_VER. We can call the third kind a crippled/sabotaged tarball---without the involvement of the person who extracted the official tarball, munged the resulting directory and then made a different tarball by running "make dist" in it, the builders would not see DEF_VAR being wrong. Thanks anyway. I'll try to be more careful when tagging -rc1
[ANNOUNCE] Git v2.28.0-rc0
An early preview release Git v2.28.0-rc0 is now available for
testing at the usual places. It is comprised of 284 non-merge
commits since v2.27.0, contributed by 42 people, 9 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.28.0-rc0' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.27.0 are as follows.
Welcome to the Git development community!
Andrew Ng, Chris Torek, Don Goodman-Wilson, Jiuyang Xie, Luc
Van Oostenryck, Marco Trevisan (Treviño), Miroslav Koškár,
Rafael Aquini, and Srinidhi Kaushik.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Abhishek Kumar, Ben Keene, brian m. carlson, Carlo Marcelo Arenas
Belón, Christian Couder, Denton Liu, Derrick Stolee, Đoàn
Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine,
Han-Wen Nienhuys, Jacob Keller, Jeff King, Johannes Schindelin,
John Lin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C
Hamano, Laurent Arnoud, Martin Ågren, Matheus Tavares, Paolo
Bonzini, Patrick Steinhardt, Ramsay Jones, Randall S. Becker,
René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau,
Ville Skyttä, and Xin Li.
Git 2.28 Release Notes (draft)
==
Updates since v2.27
---
Backward compatibility notes
* "fetch.writeCommitGraph" is deemed to be still a bit too risky and
is no longer part of the "feature.experimental" set.
* It used to be that setting extensions.* configuration variables
alone, while leaving core.repositoryFormatVersion=0, made these
settings effective, which was a wrong thing to do. In version 0,
there was no special meaning in extensions.* configuration
variables. This has been corrected. If you need these repository
extensions to be effective, the core.repositoryFormatVersion
variable needs to be updated to 1 after vetting these extensions.*
variables are set correctly.
UI, Workflows & Features
* The commands in the "diff" family learned to honor "diff.relative"
configuration variable.
* The check in "git fsck" to ensure that the tree objects are sorted
still had corner cases it missed unsorted entries.
* The interface to redact sensitive information in the trace output
has been simplified.
* The command line completion (in contrib/) learned to complete
options that the "git switch" command takes.
* "git diff" used to take arguments in random and nonsense range
notation, e.g. "git diff A..B C", "git diff A..B C...D", etc.,
which has been cleaned up.
* "git diff-files" has been taught to say paths that are marked as
intent-to-add are new files, not modified from an empty blob.
* "git status" learned to report the status of sparse checkout.
* "git difftool" has trouble dealing with paths added to the index
with the intent-to-add bit.
* "git fast-export --anonymize" learned to take customized mapping to
allow its users to tweak its output more usable for debugging.
* The command line completion support (in contrib/) used to be
prepared to work with "set -u" but recent changes got a bit more
sloppy. This has been corrected.
Performance, Internal Implementation, Development Support etc.
* Code optimization for a common case.
(merge 8777616e4d an/merge-single-strategy-optim later to maint).
* We've adopted a convention that any on-stack structure can be
initialized to have zero values in all fields with "= { 0 }",
even when the first field happens to be a pointer, but sparse
complained that a null pointer should be spelled NULL for a long
time. Start using -Wno-universal-initializer option to squelch
it (the latest sparse has it on by default).
* "git log -L..." now takes advantage of the "which paths are touched
by this commit?" info stored in the commit-graph system.
* As FreeBSD is not the only platform whose regexp library reports
a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
automatically and skip the affected tests.
* "git bugreport" learns to report what shell is in use.
* Support for GIT_CURL_VERBOSE has been rewritten in terms of
GIT_TRACE_CURL.
* Preliminary clean-ups around refs API, plus file format
specification documentation for the reftable backend.
* Workaround breakage in MSVC build, where "curl-config --cflags"
gives settings appropriate for GCC build.
* Code clean-up of "git clean"
Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)
Am Fr., 3. Juli 2020 um 19:45 Uhr schrieb Peter Zijlstra : > > On Fri, Jul 03, 2020 at 07:07:39PM +0200, Gabriel C wrote: > > > I boot all the boxes restricting the cores to the correct count on the > > command line. > > This, because you're right about the wasted memory. > > > Wasted resource or not, this is still a bug IMO. > > Yeah, but not one we can do much about I think. It is the BIOS saying it > wants more because it expects someone to come along and stick another > CPU in. > > Possible we could say that for single socket machines overprovisioning > is 'silly', but then, I've no idea how to detect that. You'll need to > find an ACPI person. I know the EPYC box got that problem too initially, it reported twice the cores and twice the sockets, but got fixed in some kernel versions. https://lkml.org/lkml/2018/5/20/102 I never really looked at how this is calculated but I still believe there is a bug somewhere.
Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)
Am Fr., 3. Juli 2020 um 17:58 Uhr schrieb Uladzislau Rezki : > > Hello, folk. Hello, > > I have a system based on AMD 3970x CPUs. It has 32 physical cores > and 64 threads. It seems that "nr_cpu_ids" variable is not correctly > set on latest 5.8-rc3 kernel. Please have a look below on dmesg output: > > > urezki@pc638:~$ sudo dmesg | grep 128 > [0.00] IOAPIC[0]: apic_id 128, version 33, address 0xfec0, GSI > 0-23 > [0.00] smpboot: Allowing 128 CPUs, 64 hotplug CPUs > [0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:128 > nr_node_ids:1 > ... > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=128, Nodes=1 > [0.00] rcu: RCU restricting CPUs from NR_CPUS=512 to > nr_cpu_ids=128. > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=128 > urezki@pc638:~$ > > > For example SLUB thinks that it deals with 128 CPUs in the system what is > wrong if i do not miss something. Since nr_cpu_ids is broken(?), thus the > "cpu_possible_mask" does not correspond to reality as well. > > Any thoughts? This is not a 5.8-rc3 problem. Almost all AMD CPUs and APUs are looking like this. The only CPUs I own are getting that right is a dual EPYC box, everything else is broken regarding the right C/T & socket(s) count, and that probably bc is using NUAM code to have the info. I reported that a while back and no-one ever cared. There is even a comment in the hotplug code saying setting the wrong CPU count is a waste of resources. I have a 2200G is reporting 48Cores. AMD Ryzen 7 3750H reporting twice the cores and twice the socket. ... [0.040578] smpboot: Allowing 16 CPUs, 8 hotplug CPUs ... [0.382122] smpboot: Max logical packages: 2 .. I boot all the boxes restricting the cores to the correct count on the command line. Wasted resource or not, this is still a bug IMO. Best Regards, Gabriel C
Re: [PATCH] ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()
On 2020/7/3 4:09, Alexandre Belloni wrote:
Hi,
On 04/06/2020 20:33:01+0800, yu kuai wrote:
if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have
a corresponding put_device(). Thus add a jump target to fix the exception
handling for this function implementation.
Fixes: d2e467905596 ("ARM: at91: pm: use the mmio-sram pool to access SRAM")
Signed-off-by: yu kuai
---
arch/arm/mach-at91/pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 074bde64064e..2aab043441e8 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -592,13 +592,13 @@ static void __init at91_pm_sram_init(void)
sram_pool = gen_pool_get(>dev, NULL);
Isn't the best solution to simply have put_device hereHi, Alexandre !
I think put_device() is supposed to be called in the exception handling
path.
if (!sram_pool) {
pr_warn("%s: sram pool unavailable!\n", __func__);
- return;
+ goto out_put_device;
}
sram_base = gen_pool_alloc(sram_pool, at91_pm_suspend_in_sram_sz);
if (!sram_base) {
pr_warn("%s: unable to alloc sram!\n", __func__);
- return;
+ goto out_put_device;
}
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
@@ -606,12 +606,17 @@ static void __init at91_pm_sram_init(void)
at91_pm_suspend_in_sram_sz, false);
if (!at91_suspend_sram_fn) {
pr_warn("SRAM: Could not map\n");
- return;
+ goto out_put_device;
}
/* Copy the pm suspend handler to SRAM */
at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
If nothing is wrong, maybe put_device shounld't be called?
Thanks!
Yu Kuai
+ return;
+
+out_put_device:
+ put_device(>dev);
+ return;
}
static bool __init at91_is_pm_mode_active(int pm_mode)
--
2.25.4
Re: ath9k broken [was: Linux 5.7.3]
Am Fr., 26. Juni 2020 um 15:51 Uhr schrieb Gabriel C
:
>
> Am Fr., 26. Juni 2020 um 15:40 Uhr schrieb Greg Kroah-Hartman
> :
> >
> > On Fri, Jun 26, 2020 at 01:48:59PM +0200, Gabriel C wrote:
> > > Am Do., 25. Juni 2020 um 12:52 Uhr schrieb Gabriel C
> > > :
> > > >
> > > > Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C
> > > > :
> > > > >
> > > > > Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby
> > > > > :
> > > > > >
> > > > > > On 25. 06. 20, 0:05, Gabriel C wrote:
> > > > > > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman
> > > > > > > :
> > > > > > >>
> > > > > > >> I'm announcing the release of the 5.7.3 kernel.
> > > > > > >>
> > > > > > >
> > > > > > > Hello Greg,
> > > > > > >
> > > > > > >> Qiujun Huang (5):
> > > > > > >> ath9k: Fix use-after-free Read in htc_connect_service
> > > > > > >> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
> > > > > > >> ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
> > > > > > >> ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
> > > > > > >> ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > > > > > >>
> > > > > > >
> > > > > > > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi
> > > > > > > Dongle,
> > > > > > > while working fine on <5.7.3.
> > > > > > >
> > > > > > > I don't have myself such HW, and the reported doesn't have any
> > > > > > > experience
> > > > > > > in bisecting the kernel, so we build kernels, each with one of the
> > > > > > > above commits reverted,
> > > > > > > to find the bad commit.
> > > > > > >
> > > > > > > The winner is:
> > > > > > >
> > > > > > > commit 6602f080cb28745259e2fab1a4cf55eeb5894f93
> > > > > > > Author: Qiujun Huang
> > > > > > > Date: Sat Apr 4 12:18:38 2020 +0800
> > > > > > >
> > > > > > > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > > > > > >
> > > > > > > commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
> > > > > > > ...
> > > > > > >
> > > > > > > Reverting this one fixed his problem.
> > > > > >
> > > > > > Obvious question: is 5.8-rc1 (containing the commit) broken too?
> > > > >
> > > > > Yes, it does, just checked.
> > > > >
> > > > > git tag --contains 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05
> > > > > v5.8-rc1
> > > > > v5.8-rc2
> > > > >
> > > >
> > > > Sorry, I read the wrong, I just woke up.
> > > >
> > > > We didn't test 5.8-rc{1,2} yet but we will today and let you know.
> > > >
> > >
> > > We tested 5.8-rc2 and it is broken too.
> > >
> > > The exact HW name is:
> > >
> > > TP-link tl-wn722n (Atheros AR9271 chip)
> >
> > Great!
> >
> > Can you work with the developers to fix this in Linus's tree first?
>
> I'm the man in the middle, but sure we will try patches or any suggestions
> from developers to identify and fix the problem.
>
> >
> > I bet they want to see the output of 'lsusb -v' for this device to see
> > if the endpoint calculations are correct...
> >
>
> Working on it. As soon the reporter gives me the output, I will post it here.
> I've told him to run it on a broken and one working kernel.
That is from a good kernel with reverted commit
https://gist.github.com/AngryPenguinPL/07c8e2abd3b103eaf8978a39ad8577d1
That is from the broken kernel without the commit reverted
https://gist.github.com/AngryPenguinPL/5cdc0dd16ce5e59ff3c32c048e2f5111
This is from 5.7.5 kernel, I don't have yet a 5.8-rc2 package with the
reverted commit.
Re: ath9k broken [was: Linux 5.7.3]
Am Fr., 26. Juni 2020 um 15:40 Uhr schrieb Greg Kroah-Hartman
:
>
> On Fri, Jun 26, 2020 at 01:48:59PM +0200, Gabriel C wrote:
> > Am Do., 25. Juni 2020 um 12:52 Uhr schrieb Gabriel C
> > :
> > >
> > > Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C
> > > :
> > > >
> > > > Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby
> > > > :
> > > > >
> > > > > On 25. 06. 20, 0:05, Gabriel C wrote:
> > > > > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman
> > > > > > :
> > > > > >>
> > > > > >> I'm announcing the release of the 5.7.3 kernel.
> > > > > >>
> > > > > >
> > > > > > Hello Greg,
> > > > > >
> > > > > >> Qiujun Huang (5):
> > > > > >> ath9k: Fix use-after-free Read in htc_connect_service
> > > > > >> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
> > > > > >> ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
> > > > > >> ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
> > > > > >> ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > > > > >>
> > > > > >
> > > > > > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi
> > > > > > Dongle,
> > > > > > while working fine on <5.7.3.
> > > > > >
> > > > > > I don't have myself such HW, and the reported doesn't have any
> > > > > > experience
> > > > > > in bisecting the kernel, so we build kernels, each with one of the
> > > > > > above commits reverted,
> > > > > > to find the bad commit.
> > > > > >
> > > > > > The winner is:
> > > > > >
> > > > > > commit 6602f080cb28745259e2fab1a4cf55eeb5894f93
> > > > > > Author: Qiujun Huang
> > > > > > Date: Sat Apr 4 12:18:38 2020 +0800
> > > > > >
> > > > > > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > > > > >
> > > > > > commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
> > > > > > ...
> > > > > >
> > > > > > Reverting this one fixed his problem.
> > > > >
> > > > > Obvious question: is 5.8-rc1 (containing the commit) broken too?
> > > >
> > > > Yes, it does, just checked.
> > > >
> > > > git tag --contains 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05
> > > > v5.8-rc1
> > > > v5.8-rc2
> > > >
> > >
> > > Sorry, I read the wrong, I just woke up.
> > >
> > > We didn't test 5.8-rc{1,2} yet but we will today and let you know.
> > >
> >
> > We tested 5.8-rc2 and it is broken too.
> >
> > The exact HW name is:
> >
> > TP-link tl-wn722n (Atheros AR9271 chip)
>
> Great!
>
> Can you work with the developers to fix this in Linus's tree first?
I'm the man in the middle, but sure we will try patches or any suggestions
from developers to identify and fix the problem.
>
> I bet they want to see the output of 'lsusb -v' for this device to see
> if the endpoint calculations are correct...
>
Working on it. As soon the reporter gives me the output, I will post it here.
I've told him to run it on a broken and one working kernel.
> thanks,
>
> greg k-h
Best Regards,
Gabriel C
Re: ath9k broken [was: Linux 5.7.3]
Am Do., 25. Juni 2020 um 12:52 Uhr schrieb Gabriel C
:
>
> Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C
> :
> >
> > Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby
> > :
> > >
> > > On 25. 06. 20, 0:05, Gabriel C wrote:
> > > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman
> > > > :
> > > >>
> > > >> I'm announcing the release of the 5.7.3 kernel.
> > > >>
> > > >
> > > > Hello Greg,
> > > >
> > > >> Qiujun Huang (5):
> > > >> ath9k: Fix use-after-free Read in htc_connect_service
> > > >> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
> > > >> ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
> > > >> ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
> > > >> ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > > >>
> > > >
> > > > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi Dongle,
> > > > while working fine on <5.7.3.
> > > >
> > > > I don't have myself such HW, and the reported doesn't have any
> > > > experience
> > > > in bisecting the kernel, so we build kernels, each with one of the
> > > > above commits reverted,
> > > > to find the bad commit.
> > > >
> > > > The winner is:
> > > >
> > > > commit 6602f080cb28745259e2fab1a4cf55eeb5894f93
> > > > Author: Qiujun Huang
> > > > Date: Sat Apr 4 12:18:38 2020 +0800
> > > >
> > > > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > > >
> > > > commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
> > > > ...
> > > >
> > > > Reverting this one fixed his problem.
> > >
> > > Obvious question: is 5.8-rc1 (containing the commit) broken too?
> >
> > Yes, it does, just checked.
> >
> > git tag --contains 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05
> > v5.8-rc1
> > v5.8-rc2
> >
>
> Sorry, I read the wrong, I just woke up.
>
> We didn't test 5.8-rc{1,2} yet but we will today and let you know.
>
We tested 5.8-rc2 and it is broken too.
The exact HW name is:
TP-link tl-wn722n (Atheros AR9271 chip)
> > >
> > > I fail to see how the commit could cause an issue like this. Is this
> > > really reproducibly broken with the commit and irreproducible without
> > > it?
> >
> > I can't see something obvious wrong either, but yes it's reproducible on
> > his HW.
> > Kernel with this commit breaks the dongle, with the commit reverted it
> > works.
> >
> > >As it looks like a USB/wiring problem:
> > > usb 1-2: USB disconnect, device number 2
> > > ath: phy0: Reading Magic # failed
> > > ath: phy0: Unable to initialize hardware; initialization status: -5
> > > ...
> > > usb 1-2: device descriptor read/64, error -110
> > > usb 1-2: device descriptor read/64, error -71
> > >
> > > Ccing ath9k maintainers too.
> > >
> > > > I don't have so much info about the HW, besides a dmesg showing the
> > > > phy breaking.
> > > > I also added the reporter to CC too.
> > > >
> > > > https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea
> > > >
> > > > If you need more info, please let me know and I'll try my best to get
> > > > it as fast as possible for you.
> > >
Best Regards,
Gabriel C
Re: ath9k broken [was: Linux 5.7.3]
Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C
:
>
> Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby :
> >
> > On 25. 06. 20, 0:05, Gabriel C wrote:
> > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman
> > > :
> > >>
> > >> I'm announcing the release of the 5.7.3 kernel.
> > >>
> > >
> > > Hello Greg,
> > >
> > >> Qiujun Huang (5):
> > >> ath9k: Fix use-after-free Read in htc_connect_service
> > >> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
> > >> ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
> > >> ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
> > >> ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > >>
> > >
> > > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi Dongle,
> > > while working fine on <5.7.3.
> > >
> > > I don't have myself such HW, and the reported doesn't have any experience
> > > in bisecting the kernel, so we build kernels, each with one of the
> > > above commits reverted,
> > > to find the bad commit.
> > >
> > > The winner is:
> > >
> > > commit 6602f080cb28745259e2fab1a4cf55eeb5894f93
> > > Author: Qiujun Huang
> > > Date: Sat Apr 4 12:18:38 2020 +0800
> > >
> > > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
> > >
> > > commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
> > > ...
> > >
> > > Reverting this one fixed his problem.
> >
> > Obvious question: is 5.8-rc1 (containing the commit) broken too?
>
> Yes, it does, just checked.
>
> git tag --contains 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05
> v5.8-rc1
> v5.8-rc2
>
Sorry, I read the wrong, I just woke up.
We didn't test 5.8-rc{1,2} yet but we will today and let you know.
> >
> > I fail to see how the commit could cause an issue like this. Is this
> > really reproducibly broken with the commit and irreproducible without
> > it?
>
> I can't see something obvious wrong either, but yes it's reproducible on his
> HW.
> Kernel with this commit breaks the dongle, with the commit reverted it works.
>
> >As it looks like a USB/wiring problem:
> > usb 1-2: USB disconnect, device number 2
> > ath: phy0: Reading Magic # failed
> > ath: phy0: Unable to initialize hardware; initialization status: -5
> > ...
> > usb 1-2: device descriptor read/64, error -110
> > usb 1-2: device descriptor read/64, error -71
> >
> > Ccing ath9k maintainers too.
> >
> > > I don't have so much info about the HW, besides a dmesg showing the
> > > phy breaking.
> > > I also added the reporter to CC too.
> > >
> > > https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea
> > >
> > > If you need more info, please let me know and I'll try my best to get
> > > it as fast as possible for you.
> >
>
> Best Regards,
>
> Gabriel C
Re: ath9k broken [was: Linux 5.7.3]
Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby : > > On 25. 06. 20, 0:05, Gabriel C wrote: > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman > > : > >> > >> I'm announcing the release of the 5.7.3 kernel. > >> > > > > Hello Greg, > > > >> Qiujun Huang (5): > >> ath9k: Fix use-after-free Read in htc_connect_service > >> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx > >> ath9k: Fix use-after-free Write in ath9k_htc_rx_msg > >> ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb > >> ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb > >> > > > > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi Dongle, > > while working fine on <5.7.3. > > > > I don't have myself such HW, and the reported doesn't have any experience > > in bisecting the kernel, so we build kernels, each with one of the > > above commits reverted, > > to find the bad commit. > > > > The winner is: > > > > commit 6602f080cb28745259e2fab1a4cf55eeb5894f93 > > Author: Qiujun Huang > > Date: Sat Apr 4 12:18:38 2020 +0800 > > > > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb > > > > commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. > > ... > > > > Reverting this one fixed his problem. > > Obvious question: is 5.8-rc1 (containing the commit) broken too? Yes, it does, just checked. git tag --contains 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 v5.8-rc1 v5.8-rc2 > > I fail to see how the commit could cause an issue like this. Is this > really reproducibly broken with the commit and irreproducible without > it? I can't see something obvious wrong either, but yes it's reproducible on his HW. Kernel with this commit breaks the dongle, with the commit reverted it works. >As it looks like a USB/wiring problem: > usb 1-2: USB disconnect, device number 2 > ath: phy0: Reading Magic # failed > ath: phy0: Unable to initialize hardware; initialization status: -5 > ... > usb 1-2: device descriptor read/64, error -110 > usb 1-2: device descriptor read/64, error -71 > > Ccing ath9k maintainers too. > > > I don't have so much info about the HW, besides a dmesg showing the > > phy breaking. > > I also added the reporter to CC too. > > > > https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea > > > > If you need more info, please let me know and I'll try my best to get > > it as fast as possible for you. > Best Regards, Gabriel C
Re: Linux 5.7.3
Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman : > > I'm announcing the release of the 5.7.3 kernel. > Hello Greg, > Qiujun Huang (5): > ath9k: Fix use-after-free Read in htc_connect_service > ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx > ath9k: Fix use-after-free Write in ath9k_htc_rx_msg > ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi Dongle, while working fine on <5.7.3. I don't have myself such HW, and the reported doesn't have any experience in bisecting the kernel, so we build kernels, each with one of the above commits reverted, to find the bad commit. The winner is: commit 6602f080cb28745259e2fab1a4cf55eeb5894f93 Author: Qiujun Huang Date: Sat Apr 4 12:18:38 2020 +0800 ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. ... Reverting this one fixed his problem. I don't have so much info about the HW, besides a dmesg showing the phy breaking. I also added the reporter to CC too. https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea If you need more info, please let me know and I'll try my best to get it as fast as possible for you. Best Regards, Gabriel C
Re: [PATCH] drivers: staging: vt6655: replace CamelCase names on function s_uGetRTSCTSRsvTime
On Wed, Jun 24, 2020 at 12:05:49PM +0200, Julia Lawall wrote:
>
>
> On Wed, 24 Jun 2020, Rodolfo C. Villordo wrote:
>
> > Replace function and variables name from CamelCase style to snake_case
> > style.
> > Remove Hungarian notation.
> >
> > Signed-off-by: Rodolfo C. Villordo
> > ---
> > drivers/staging/vt6655/rxtx.c | 80 +--
> > 1 file changed, 38 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
> > index cfab64d2b312..4778439e8757 100644
> > --- a/drivers/staging/vt6655/rxtx.c
> > +++ b/drivers/staging/vt6655/rxtx.c
> > @@ -21,7 +21,7 @@
> > * s_uGetDataDuration - get tx data required duration
> > * s_uFillDataHead- fulfill tx data duration header
> > * s_uGetRTSCTSDuration- get rtx/cts required duration
> > - * s_uGetRTSCTSRsvTime- get rts/cts reserved time
> > + * get_rtscts_time- get rts/cts reserved time
> > * s_uGetTxRsvTime- get frame reserved time
> > * s_vFillCTSHead- fulfill CTS ctl header
> > * s_vFillFragParameter- Set fragment ctl parameter.
>
> Why is only one of these done?
>
Hi Julia,
I intend to do it on all of those functions. However, I'm avoiding big
patch sets for now. To fix all then it will require at least 18 patches
in a set:
* Functions:
0 * s_vGenerateTxParameter - Generate tx dma required parameter.
1 * vGenerateMACHeader - Translate 802.3 to 802.11 header
2 * cbGetFragCount - Calculate fragment number count
3 * csBeacon_xmit - beacon tx function
4 * csMgmt_xmit - management tx function
5 * s_cbFillTxBufHead - fulfill tx dma buffer header
6 * s_uGetDataDuration - get tx data required duration
7 * s_uFillDataHead- fulfill tx data duration header
8 * s_uGetRTSCTSDuration- get rtx/cts required duration
9 * get_rtscts_time- get rts/cts reserved time
10 * s_uGetTxRsvTime- get frame reserved time
11 * s_vFillCTSHead- fulfill CTS ctl header
12 * s_vFillFragParameter- Set fragment ctl parameter.
13 * s_vFillRTSHead- fulfill RTS ctl header
14 * s_vFillTxKey- fulfill tx encrypt key
15 * s_vSWencryption- Software encrypt header
16 * vDMA0_tx_80211- tx 802.11 frame via dma0
17 * vGenerateFIFOHeader- Generate tx FIFO ctl header
18 *
19 * Revision History:
Thanks.
> julia
>
> > @@ -190,45 +190,41 @@ static __le16 vnt_rxtx_rsvtime_le16(struct
> > vnt_private *priv, u8 pkt_type,
> > }
> >
> > /* byFreqType: 0=>5GHZ 1=>2.4GHZ */
> > -static
> > -__le16
> > -s_uGetRTSCTSRsvTime(
> > - struct vnt_private *pDevice,
> > - unsigned char byRTSRsvType,
> > - unsigned char byPktType,
> > - unsigned int cbFrameLength,
> > - unsigned short wCurrentRate
> > -)
> > +static __le16 get_rtscts_time(struct vnt_private *priv,
> > + unsigned char rts_rsvtype,
> > + unsigned char pkt_type,
> > + unsigned int frame_length,
> > + unsigned short current_rate)
> > {
> > - unsigned int uRrvTime = 0;
> > - unsigned int uRTSTime = 0;
> > - unsigned int uCTSTime = 0;
> > - unsigned int uAckTime = 0;
> > - unsigned int uDataTime = 0;
> > -
> > - uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType,
> > cbFrameLength, wCurrentRate);
> > - if (byRTSRsvType == 0) { /* RTSTxRrvTime_bb */
> > - uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 20, pDevice->byTopCCKBasicRate);
> > - uAckTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 14, pDevice->byTopCCKBasicRate);
> > - uCTSTime = uAckTime;
> > - } else if (byRTSRsvType == 1) { /* RTSTxRrvTime_ba, only in 2.4GHZ */
> > - uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 20, pDevice->byTopCCKBasicRate);
> > - uCTSTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 14, pDevice->byTopCCKBasicRate);
> > - uAckTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 14, pDevice->byTopOFDMBasicRate);
> > - } else if (byRTSRsvType == 2) { /* RTSTxRrvTime_aa */
> > - uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 20, pDevice->byTopOFDMBasicRate);
> > - uAckTime = bb_get_frame_time(pDevice->byPreambleType,
> > byPktType, 14, pDevice->byTopOFDMBasicRate);
> > - uCTSTime =
[PATCH] drivers: staging: vt6655: replace CamelCase names on function s_uGetRTSCTSRsvTime
Replace function and variables name from CamelCase style to snake_case style.
Remove Hungarian notation.
Signed-off-by: Rodolfo C. Villordo
---
drivers/staging/vt6655/rxtx.c | 80 +--
1 file changed, 38 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index cfab64d2b312..4778439e8757 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -21,7 +21,7 @@
* s_uGetDataDuration - get tx data required duration
* s_uFillDataHead- fulfill tx data duration header
* s_uGetRTSCTSDuration- get rtx/cts required duration
- * s_uGetRTSCTSRsvTime- get rts/cts reserved time
+ * get_rtscts_time- get rts/cts reserved time
* s_uGetTxRsvTime- get frame reserved time
* s_vFillCTSHead- fulfill CTS ctl header
* s_vFillFragParameter- Set fragment ctl parameter.
@@ -190,45 +190,41 @@ static __le16 vnt_rxtx_rsvtime_le16(struct vnt_private
*priv, u8 pkt_type,
}
/* byFreqType: 0=>5GHZ 1=>2.4GHZ */
-static
-__le16
-s_uGetRTSCTSRsvTime(
- struct vnt_private *pDevice,
- unsigned char byRTSRsvType,
- unsigned char byPktType,
- unsigned int cbFrameLength,
- unsigned short wCurrentRate
-)
+static __le16 get_rtscts_time(struct vnt_private *priv,
+ unsigned char rts_rsvtype,
+ unsigned char pkt_type,
+ unsigned int frame_length,
+ unsigned short current_rate)
{
- unsigned int uRrvTime = 0;
- unsigned int uRTSTime = 0;
- unsigned int uCTSTime = 0;
- unsigned int uAckTime = 0;
- unsigned int uDataTime = 0;
-
- uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType,
cbFrameLength, wCurrentRate);
- if (byRTSRsvType == 0) { /* RTSTxRrvTime_bb */
- uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 20, pDevice->byTopCCKBasicRate);
- uAckTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, pDevice->byTopCCKBasicRate);
- uCTSTime = uAckTime;
- } else if (byRTSRsvType == 1) { /* RTSTxRrvTime_ba, only in 2.4GHZ */
- uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 20, pDevice->byTopCCKBasicRate);
- uCTSTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, pDevice->byTopCCKBasicRate);
- uAckTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, pDevice->byTopOFDMBasicRate);
- } else if (byRTSRsvType == 2) { /* RTSTxRrvTime_aa */
- uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 20, pDevice->byTopOFDMBasicRate);
- uAckTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, pDevice->byTopOFDMBasicRate);
- uCTSTime = uAckTime;
- } else if (byRTSRsvType == 3) { /* CTSTxRrvTime_ba, only in 2.4GHZ */
- uCTSTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, pDevice->byTopCCKBasicRate);
- uAckTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, pDevice->byTopOFDMBasicRate);
- uRrvTime = uCTSTime + uAckTime + uDataTime + 2 * pDevice->uSIFS;
- return cpu_to_le16((u16)uRrvTime);
+ unsigned int rrv_time = 0;
+ unsigned int rts_time = 0;
+ unsigned int cts_time = 0;
+ unsigned int ack_time = 0;
+ unsigned int data_time = 0;
+
+ data_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
frame_length, current_rate);
+ if (rts_rsvtype == 0) { /* RTSTxRrvTime_bb */
+ rts_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
20, priv->byTopCCKBasicRate);
+ ack_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
14, priv->byTopCCKBasicRate);
+ cts_time = ack_time;
+ } else if (rts_rsvtype == 1) { /* RTSTxRrvTime_ba, only in 2.4GHZ */
+ rts_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
20, priv->byTopCCKBasicRate);
+ cts_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
14, priv->byTopCCKBasicRate);
+ ack_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
14, priv->byTopOFDMBasicRate);
+ } else if (rts_rsvtype == 2) { /* RTSTxRrvTime_aa */
+ rts_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
20, priv->byTopOFDMBasicRate);
+ ack_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
14, priv->byTopOFDMBasicRate);
+ cts_time = ack_time;
+ } else if (rts_rsvtype == 3) { /* CTSTxRrvTime_ba, only in 2.4GHZ */
+ cts_time = bb_get_frame_time(priv->byPreambleType, pkt_type,
14, priv->byTopCCKBasicRate);
+ ack_time =
Re: [PATCH] ARM: socfpga: add missing put_device() call in socfpga_setup_ocram_self_refresh()
ping?
On 2020/6/4 21:10, yu kuai wrote:
if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh()
doesn't have a corresponding put_device(). Thus add a jump target to fix
the exception handling for this function implementation.
Fixes: 44fd8c7d4005 ("ARM: socfpga: support suspend to ram")
Signed-off-by: yu kuai
---
arch/arm/mach-socfpga/pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-socfpga/pm.c b/arch/arm/mach-socfpga/pm.c
index 6ed887cf8dc9..7267f5da15a4 100644
--- a/arch/arm/mach-socfpga/pm.c
+++ b/arch/arm/mach-socfpga/pm.c
@@ -49,14 +49,14 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!ocram_pool) {
pr_warn("%s: ocram pool unavailable!\n", __func__);
ret = -ENODEV;
- goto put_node;
+ goto put_device;
}
ocram_base = gen_pool_alloc(ocram_pool, socfpga_sdram_self_refresh_sz);
if (!ocram_base) {
pr_warn("%s: unable to alloc ocram!\n", __func__);
ret = -ENOMEM;
- goto put_node;
+ goto put_device;
}
ocram_pbase = gen_pool_virt_to_phys(ocram_pool, ocram_base);
@@ -67,7 +67,7 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!suspend_ocram_base) {
pr_warn("%s: __arm_ioremap_exec failed!\n", __func__);
ret = -ENOMEM;
- goto put_node;
+ goto put_device;
}
/* Copy the code that puts DDR in self refresh to ocram */
@@ -80,7 +80,12 @@ static int socfpga_setup_ocram_self_refresh(void)
"could not copy function to ocram");
if (!socfpga_sdram_self_refresh_in_ocram)
ret = -EFAULT;
+
+ if (!ret)
+ goto put_node;
+put_device:
+ put_device(>dev);
put_node:
of_node_put(np);
Re: [PATCH] ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()
ping?
On 2020/6/4 20:33, yu kuai wrote:
if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have
a corresponding put_device(). Thus add a jump target to fix the exception
handling for this function implementation.
Fixes: d2e467905596 ("ARM: at91: pm: use the mmio-sram pool to access SRAM")
Signed-off-by: yu kuai
---
arch/arm/mach-at91/pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 074bde64064e..2aab043441e8 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -592,13 +592,13 @@ static void __init at91_pm_sram_init(void)
sram_pool = gen_pool_get(>dev, NULL);
if (!sram_pool) {
pr_warn("%s: sram pool unavailable!\n", __func__);
- return;
+ goto out_put_device;
}
sram_base = gen_pool_alloc(sram_pool, at91_pm_suspend_in_sram_sz);
if (!sram_base) {
pr_warn("%s: unable to alloc sram!\n", __func__);
- return;
+ goto out_put_device;
}
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
@@ -606,12 +606,17 @@ static void __init at91_pm_sram_init(void)
at91_pm_suspend_in_sram_sz, false);
if (!at91_suspend_sram_fn) {
pr_warn("SRAM: Could not map\n");
- return;
+ goto out_put_device;
}
/* Copy the pm suspend handler to SRAM */
at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+ return;
+
+out_put_device:
+ put_device(>dev);
+ return;
}
static bool __init at91_is_pm_mode_active(int pm_mode)
Re: [PATCH] ARM: imx6: add missing put_device() call in imx6q_suspend_init()
On 2020/6/23 20:11, Shawn Guo wrote: On Thu, Jun 04, 2020 at 08:54:49PM +0800, yu kuai wrote: if of_find_device_by_node() succeed, imx6q_suspend_init() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Signed-off-by: yu kuai Applied, thanks. Hi, Shawn How about this patch: https://lkml.org/lkml/2020/6/4/428 The patch fix the similar issure. Thanks! Yu Kuai
[PATCH v2] staging: gasket: replace symbolic permissions
WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal
permissions '0444'.
+ .attr = __ATTR(_name, S_IRUGO, _show_function, NULL), \
warning detected by checkpatch.pl
Unable to use __ATTR_RO(). Driver has multiple files using the same show
function:
$ grep GASKET_SYSFS_RO drivers/staging/gasket/*
drivers/staging/gasket/apex_driver.c:
GASKET_SYSFS_RO(node_0_page_table_entries, sysfs_show,
drivers/staging/gasket/apex_driver.c:
GASKET_SYSFS_RO(node_0_simple_page_table_entries, sysfs_show,
drivers/staging/gasket/apex_driver.c:
GASKET_SYSFS_RO(node_0_num_mapped_pages, sysfs_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(bar_offsets,
gasket_sysfs_data_show, ATTR_BAR_OFFSETS),
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(bar_sizes,
gasket_sysfs_data_show, ATTR_BAR_SIZES),
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(driver_version,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(framework_version,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(device_type,
gasket_sysfs_data_show, ATTR_DEVICE_TYPE),
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(revision,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(pci_address,
gasket_sysfs_data_show, ATTR_PCI_ADDRESS),
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(status,
gasket_sysfs_data_show, ATTR_STATUS),
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(is_device_owned,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(device_owner,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(write_open_count,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(reset_count,
gasket_sysfs_data_show, ATTR_RESET_COUNT),
drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(user_mem_ranges,
gasket_sysfs_data_show,
drivers/staging/gasket/gasket_interrupt.c:
GASKET_SYSFS_RO(interrupt_counts, interrupt_sysfs_show,
Signed-off-by: Rodolfo C. Villordo
---
drivers/staging/gasket/gasket_sysfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_sysfs.h
b/drivers/staging/gasket/gasket_sysfs.h
index ab5aa351d555..d5e167dfbe76 100644
--- a/drivers/staging/gasket/gasket_sysfs.h
+++ b/drivers/staging/gasket/gasket_sysfs.h
@@ -71,7 +71,7 @@ struct gasket_sysfs_attribute {
#define GASKET_SYSFS_RO(_name, _show_function, _attr_type)
\
{ \
- .attr = __ATTR(_name, S_IRUGO, _show_function, NULL), \
+ .attr = __ATTR(_name, 0444, _show_function, NULL), \
.data.attr_type = _attr_type \
}
--
2.17.1
Re: [PATCH] staging: gasket: replace symbolic permissions
On Fri, Jun 19, 2020 at 10:32:24AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 19, 2020 at 08:27:14AM +, Rodolfo C Villordo wrote:
> > On Thu, Jun 18, 2020 at 09:47:50AM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Jun 01, 2020 at 12:52:40AM +, Rodolfo C. Villordo wrote:
> > > > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider
> > > > using octal permissions '0444'.
> > > > + .attr = __ATTR(_name, S_IRUGO, _show_function, NULL),
> > > >\
> > > > warning detected by checkpatch.pl
> > > >
> > > > Signed-off-by: Rodolfo C. Villordo
> > > > ---
> > > > drivers/staging/gasket/gasket_sysfs.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/gasket/gasket_sysfs.h
> > > > b/drivers/staging/gasket/gasket_sysfs.h
> > > > index ab5aa351d555..d5e167dfbe76 100644
> > > > --- a/drivers/staging/gasket/gasket_sysfs.h
> > > > +++ b/drivers/staging/gasket/gasket_sysfs.h
> > > > @@ -71,7 +71,7 @@ struct gasket_sysfs_attribute {
> > > >
> > > > #define GASKET_SYSFS_RO(_name, _show_function, _attr_type)
> > > > \
> > > > {
> > > >\
> > > > - .attr = __ATTR(_name, S_IRUGO, _show_function, NULL),
> > > >\
> > > > + .attr = __ATTR(_name, 0444, _show_function, NULL),
> > > > \
> > >
> > > What about using __ATTR_RO() instead?
> > >
> >
> > I'm not sure if __ATTR_RO() is a good match here. The
> > GASKET_SYSFS_RO() is invoked with different show functions across the
> > code. These functions don't follow the name pattern attr_name_show
> > used in __ATTR_RO(). Please correct me if I misunderstood anything.
> >
> > ### from include/linux/sysfs.h ###
> > #define __ATTR_RO(_name) { \
> > .attr = { .name = __stringify(_name), .mode = 0444 }, \
> > .show = _name##_show, \
> > }
> > ###
> >
> > ### macro usage across the driver: ###
> > $ grep GASKET_SYSFS_RO drivers/staging/gasket/*
> > drivers/staging/gasket/apex_driver.c:
> > GASKET_SYSFS_RO(node_0_page_table_entries, sysfs_show,
> > drivers/staging/gasket/apex_driver.c:
> > GASKET_SYSFS_RO(node_0_simple_page_table_entries, sysfs_show,
> > drivers/staging/gasket/apex_driver.c:
> > GASKET_SYSFS_RO(node_0_num_mapped_pages, sysfs_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(bar_offsets,
> > gasket_sysfs_data_show, ATTR_BAR_OFFSETS),
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(bar_sizes,
> > gasket_sysfs_data_show, ATTR_BAR_SIZES),
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(driver_version,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(framework_version,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(device_type,
> > gasket_sysfs_data_show, ATTR_DEVICE_TYPE),
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(revision,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(pci_address,
> > gasket_sysfs_data_show, ATTR_PCI_ADDRESS),
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(status,
> > gasket_sysfs_data_show, ATTR_STATUS),
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(is_device_owned,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(device_owner,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(write_open_count,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(reset_count,
> > gasket_sysfs_data_show, ATTR_RESET_COUNT),
> > drivers/staging/gasket/gasket_core.c: GASKET_SYSFS_RO(user_mem_ranges,
> > gasket_sysfs_data_show,
> > drivers/staging/gasket/gasket_interrupt.c:
> > GASKET_SYSFS_RO(interrupt_counts, interrupt_sysfs_show,
> > ###
>
> Ugh, you are right, that's a mess. Your original patch is fine, can you
> resend it and say in the changelog why it's not ok to use __ATTR_RO()?
>
Sure, doing it now.
Thanks
> thanks,
>
> greg k-h
