[nouveau] WARNING: possible circular locking dependency detected in linux-next

: init failed, -2 [ 358.920523] nouveau :01:00.0: Direct firmware load for nouveau/nv84_xuc103 failed with error -2 [ 358.920556] nouveau :01:00.0: bsp: unable to load firmware nouveau/nv84_xuc103 [ 358.920565] nouveau :01:00.0: bsp: init failed, -2 Thanks. Alexander Kapshuk

Re: [PATCH] ver_linux: Eliminate duplicate code in ldconfig processing logic

On Fri, Jan 8, 2021 at 1:26 PM Alexander Kapshuk wrote: > > The code that acquires the version strings for libc and libcpp is > identical, as is the printversion call. The only difference being the > name of the library being printed. > > Refactor the code by unifying the bi

[PATCH] ver_linux: Eliminate duplicate code in ldconfig processing logic

The code that acquires the version strings for libc and libcpp is identical, as is the printversion call. The only difference being the name of the library being printed. Refactor the code by unifying the bits that are common to both libraries. Signed-off-by: Alexander Kapshuk --- scripts

Re: [PATCH v2] drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth

On Tue, Oct 13, 2020 at 3:47 PM Alexander Kapshuk wrote: > > This oops manifests itself on the following hardware: > 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] > (rev a1) > > Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer deref

[PATCH v2] drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth

Fix this by setting edid to the value of the just acquired nv_connector->edid and executing the body of nouveau_connector_set_edid only if nv_connector->edid and edid point to different memory addresses thus preventing nv_connector->edid from being turned into a dangling pointer. Fixes: f28e32d3906e ("drm/nou

[PATCH] drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth

setting edid to the value of the just acquired nv_connector->edid and call nouveau_connector_set_edid in the out label only if nv_connector->edid and edid point to different memory addresses thus preventing nv_connector->edid from being turned into a dangling pointer. Fixes: f28e32d3906e ("d

Re: nouveau PUSHBUFFER_ERR on 5.9.0-rc2-next-20200824

On Mon, Aug 31, 2020 at 7:30 AM Ben Skeggs wrote: > > On Tue, 25 Aug 2020 at 17:21, Alexander Kapshuk > wrote: > > > > Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have > > had my mouse pointer disappear soon after logging in, and I have >

nouveau PUSHBUFFER_ERR on 5.9.0-rc2-next-20200824

Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have had my mouse pointer disappear soon after logging in, and I have observed the system freezing temporarily when clicking on objects and when typing text. I have also found records of push buffer errors in dmesg output: [

Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand

On Mon, Jun 22, 2020 at 11:40 AM Christian Brauner wrote: > > On Sun, Jun 21, 2020 at 03:54:37PM +0200, Dominique Martinet wrote: > > Alexander Kapshuk wrote on Sun, Jun 21, 2020: > > > Export symbol __lock_task_sighand, so it is accessible from code compiled > > >

Re: [PATCH] net/9p: Validate current->sighand in client.c

On Sun, Jun 21, 2020 at 4:56 PM Dominique Martinet wrote: > > Alexander Kapshuk wrote on Sun, Jun 21, 2020: > > Fix rcu not being dereferenced cleanly by using the task > > helpers (un)lock_task_sighand instead of spin_lock_irqsave and > > spin_unlock_irqrestore to

[PATCH] net/9p: Validate current->sighand in client.c

Fix rcu not being dereferenced cleanly by using the task helpers (un)lock_task_sighand instead of spin_lock_irqsave and spin_unlock_irqrestore to ensure current->sighand is a valid pointer as suggested in the email referenced below. Signed-off-by: Alexander Kapshuk Link: https://lore.kernel.

[PATCH] kernel/signal.c: Export symbol __lock_task_sighand

See https://lore.kernel.org/lkml/20200620201456.14304-1-alexander.kaps...@gmail.com/. Signed-off-by: Alexander Kapshuk Reported-by: kernel test robot Link: https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/TMTLPYU6A522JH2VCN3PNZVAP6EE5MDF/ --- kernel/signal.c | 1 + 1 file changed, 1 insertio

Re: [PATCH] net/9p: Validate current->sighand in client.c

On Sun, Jun 21, 2020 at 1:57 PM Dominique Martinet wrote: > > Alexander Kapshuk wrote on Sun, Jun 21, 2020: > > Thanks for your feedback. > > Shall I simply resend the v2 patch with the commit message reworded as > > you suggested, or should I make it a v3 patch instea

Re: [PATCH] net/9p: Validate current->sighand in client.c

On Sun, Jun 21, 2020 at 11:45 AM Dominique Martinet wrote: > > Alexander Kapshuk wrote on Sat, Jun 20, 2020: > > Use (un)lock_task_sighand instead of spin_lock_irqsave and > > spin_unlock_irqrestore to ensure current->sighand is a valid pointer as > > suggested in

[PATCH] net/9p: Validate current->sighand in client.c

Use (un)lock_task_sighand instead of spin_lock_irqsave and spin_unlock_irqrestore to ensure current->sighand is a valid pointer as suggested in the email referenced below. Signed-off-by: Alexander Kapshuk Link: https://lore.kernel.org/lkml/20200618190807.GA20699@nautica/ --- net/9p/clien

Re: [PATCH] net/9p: Fix sparse rcu warnings in client.c

On Thu, Jun 18, 2020 at 10:08 PM Dominique Martinet wrote: > > Alexander Kapshuk wrote on Thu, Jun 18, 2020: > > Address sparse nonderef rcu warnings: > > net/9p/client.c:790:17: warning: incorrect type in argument 1 (different > > address spaces) > > net/9p/clien

Re: [PATCH] net/9p: Fix sparse endian warning in trans_fd.c

On Thu, Jun 18, 2020 at 10:09 PM Dominique Martinet wrote: > > Alexander Kapshuk wrote on Thu, Jun 18, 2020: > > Address sparse endian warning: > > net/9p/trans_fd.c:932:28: warning: incorrect type in assignment (different > > base types) > > net/9p/trans_fd.c:

[PATCH] net/9p: Fix sparse endian warning in trans_fd.c

Address sparse endian warning: net/9p/trans_fd.c:932:28: warning: incorrect type in assignment (different base types) net/9p/trans_fd.c:932:28:expected restricted __be32 [addressable] [assigned] [usertype] s_addr net/9p/trans_fd.c:932:28:got unsigned long Signed-off-by: Alexander

[PATCH] net/9p: Fix sparse rcu warnings in client.c

spinlock [noderef] * Signed-off-by: Alexander Kapshuk --- net/9p/client.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/net/9p/client.c b/net/9p/client.c index fc1f3635e5dd..807e0e2e2e5a 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -787,9 +787,15

[tip: core/objtool] x86/insn: Fix awk regexp warnings

The following commit has been merged into the core/objtool branch of tip: Commit-ID: 700c1018b86d0d4b3f1f2d459708c0cdf42b521d Gitweb: https://git.kernel.org/tip/700c1018b86d0d4b3f1f2d459708c0cdf42b521d Author:Alexander Kapshuk AuthorDate:Tue, 24 Sep 2019 07:46:59 +03:00

Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings

On Mon, Sep 30, 2019 at 8:35 AM Borislav Petkov wrote: > > On Tue, Sep 24, 2019 at 07:46:59AM +0300, Alexander Kapshuk wrote: > > gawk 5.0.1 generates the regexp warnings shown below: > > GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c > > awk: ..

[PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings

pe' them. https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html Running diff on the output generated by the script before and after applying the patch reported no differences. Signed-off-by: Alexander Kapshuk Reported-by: kbuild test robot Reviewed-by: Borislav Petkov Acked-by

Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings

On Mon, Sep 23, 2019 at 1:31 PM Borislav Petkov wrote: > > + Masami. > > On Sun, Sep 22, 2019 at 06:03:28PM +0300, Alexander Kapshuk wrote: > > This patch fixes the regexp warnings shown below: > > Avoid having "This patch" or "This commit" in the co

Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings

On Mon, Sep 23, 2019 at 12:19 PM Borislav Petkov wrote: > > On Sun, Sep 22, 2019 at 06:03:28PM +0300, Alexander Kapshuk wrote: > > This patch fixes the regexp warnings shown below: > > GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c > > awk: ../arch

[PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings

tables.c; echo $? 0 [Debugging output] DBG:ext:(66) DBG:match(ext, ...):(66) DBG:match(..., lprefix3_expr):\((F2|!F3|66)\) Signed-off-by: Alexander Kapshuk Reported-by: kbuild test robot --- arch/x86/tools/gen-insn-attr-x86.awk | 4 ++-- tools/arch/x86/tools/gen-insn-attr-x86.awk | 4

[PATCH] gen-insn-attr-x86.awk: Fix regexp warnings

)\) Signed-off-by: Alexander Kapshuk --- arch/x86/tools/gen-insn-attr-x86.awk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/tools/gen-insn-attr-x86.awk b/arch/x86/tools/gen-insn-attr-x86.awk index b02a36b2c14f..a42015b305f4 100644 --- a/arch/x86/tools/gen-insn-a

Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903

On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell wrote: > > Hi, > > On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell > wrote: > > > > If you are bisecting linux-next, I will suggest bisecting between the > > stable branch on linux-next (which is just Linus' tree when I started > > that day)

Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903

On Sat, Sep 07, 2019 at 12:32:41PM +0200, Daniel Vetter wrote: > On Sat, Sep 7, 2019 at 11:05 AM Alexander Kapshuk > wrote: > > > > To Whom It May Concern > > > > Every kernel I have built since 5.3.0-rc2-next-20190730 and up to > > 5.3.0-rc7-next-20190

Re: [PATCH AUTOSEL 4.19 06/42] scripts/sphinx-pre-install: fix script for RHEL/CentOS

On Sat, Aug 3, 2019 at 1:37 PM Mauro Carvalho Chehab wrote: > > Em Sat, 3 Aug 2019 13:31:30 +0300 > Alexander Kapshuk escreveu: > > > > - if (! $system_release =~ /Fedora/) { > > > + if (!($system_release =~ /Fedora/)) { > > >

Re: [PATCH AUTOSEL 4.19 06/42] scripts/sphinx-pre-install: fix script for RHEL/CentOS

On Sat, Aug 3, 2019 at 11:19 AM Sasha Levin wrote: > > From: Mauro Carvalho Chehab > > [ Upstream commit b308467c916aa7acc5069802ab76a9f657434701 ] > > There's a missing parenthesis at the script, with causes it to > fail to detect non-Fedora releases (e. g. RHEL/CentOS). > > Tested with Centos

Re: Linux 5.2-rc1 - module name conflict

On Tue, May 21, 2019 at 4:01 AM Shuah Khan wrote: > > Hi all, > > I am seeing the following warning on Linux 5.2-rc1 > > warning: same basename if the following are built as modules: >drivers/regulator/88pm800.ko >drivers/mfd/88pm800.ko > > My config has: > > CONFIG_MFD_88PM800=m > >

Re: [PATCH v2] kbuild: check uniqueness of module names

On Fri, May 17, 2019 at 11:58 AM Bernd Petrovitsch wrote: > > On 17/05/2019 10:16, Alexander Kapshuk wrote: > [...] > > The 'xargs' '-r' flag is a GNU extension. > > If POSIX compliance is important here, the use of 'cat', 'xargs' and > > 'basename' may be su

Re: [PATCH v2] kbuild: check uniqueness of module names

On Fri, May 17, 2019 at 8:33 AM Masahiro Yamada wrote: > > In the recent build test of linux-next, Stephen saw a build error > caused by a broken .tmp_versions/*.mod file: > > https://lkml.org/lkml/2019/5/13/991 > > drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same > basename,

[PATCH] ver_linux: Assign constant RE to variable name for clarity

about the details of implementation. Signed-off-by: Alexander Kapshuk --- scripts/ver_linux | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/scripts/ver_linux b/scripts/ver_linux index a6c728db05ce..810e608baa24 100755 --- a/scripts/ver_linux +++ b/scripts/ver_linux

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Tue, Nov 13, 2018 at 8:32 PM Brian Norris wrote: > > Hi Alexander, > > On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk > wrote: > > > > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris > > wrote: > > > > > > On Mon, Nov 12, 2018 at 10:42:2

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Tue, Nov 13, 2018 at 8:32 PM Brian Norris wrote: > > Hi Alexander, > > On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk > wrote: > > > > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris > > wrote: > > > > > > On Mon, Nov 12, 2018 at 10:42:2

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Tue, Nov 13, 2018 at 2:09 AM Brian Norris wrote: > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote: > > An even simpler approach would be: > > > > { > > git --no-optional-locks status -uno --porcelain 2>/dev/null || > >

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Tue, Nov 13, 2018 at 2:09 AM Brian Norris wrote: > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote: > > An even simpler approach would be: > > > > { > > git --no-optional-locks status -uno --porcelain 2>/dev/null || > >

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sun, Nov 11, 2018 at 9:59 PM Alexander Kapshuk wrote: > > On Sun, Nov 11, 2018 at 7:41 PM Genki Sky wrote: > > > > Hi Alexander, > > > > On Sun, 11 Nov 2018 16:48:38 +0200, Alexander Kapshuk > > wrote: > > > Piping the output of the gi

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sun, Nov 11, 2018 at 9:59 PM Alexander Kapshuk wrote: > > On Sun, Nov 11, 2018 at 7:41 PM Genki Sky wrote: > > > > Hi Alexander, > > > > On Sun, 11 Nov 2018 16:48:38 +0200, Alexander Kapshuk > > wrote: > > > Piping the output of the gi

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sun, Nov 11, 2018 at 7:41 PM Genki Sky wrote: > > Hi Alexander, > > On Sun, 11 Nov 2018 16:48:38 +0200, Alexander Kapshuk > wrote: > > Piping the output of the git command to grep and using the return status > > of grep as the test condition within the if

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sun, Nov 11, 2018 at 7:41 PM Genki Sky wrote: > > Hi Alexander, > > On Sun, 11 Nov 2018 16:48:38 +0200, Alexander Kapshuk > wrote: > > Piping the output of the git command to grep and using the return status > > of grep as the test condition within the if

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sun, Nov 11, 2018 at 4:48 PM Alexander Kapshuk wrote: > > On Sat, Nov 10, 2018 at 10:12 PM Genki Sky wrote: > > > > Hi Andreas, > > > > On Sat, 10 Nov 2018 11:42:11 +0100, Andreas Schwab > > wrote: > > > On Nov 10 2018, Genki Sky wrote: >

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sun, Nov 11, 2018 at 4:48 PM Alexander Kapshuk wrote: > > On Sat, Nov 10, 2018 at 10:12 PM Genki Sky wrote: > > > > Hi Andreas, > > > > On Sat, 10 Nov 2018 11:42:11 +0100, Andreas Schwab > > wrote: > > > On Nov 10 2018, Genki Sky wrote: >

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sat, Nov 10, 2018 at 10:12 PM Genki Sky wrote: > > Hi Andreas, > > On Sat, 10 Nov 2018 11:42:11 +0100, Andreas Schwab > wrote: > > On Nov 10 2018, Genki Sky wrote: > > > On Fri, 9 Nov 2018 10:34:37 -0800, Brian Norris > > > wrote: > > >> + git_status="$(git --no-optional-locks

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

On Sat, Nov 10, 2018 at 10:12 PM Genki Sky wrote: > > Hi Andreas, > > On Sat, 10 Nov 2018 11:42:11 +0100, Andreas Schwab > wrote: > > On Nov 10 2018, Genki Sky wrote: > > > On Fri, 9 Nov 2018 10:34:37 -0800, Brian Norris > > > wrote: > > >> + git_status="$(git --no-optional-locks

Re: Inclusion of commit e54192b48da7 into stable tree?

On Sun, Sep 16, 2018 at 10:11 PM Rob Herring wrote: > > On Sat, Sep 15, 2018 at 8:35 AM Alexander Kapshuk > wrote: > > > > Is this commit queued up for inclusion into the stable tree? > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/driver

Re: Inclusion of commit e54192b48da7 into stable tree?

On Sun, Sep 16, 2018 at 10:11 PM Rob Herring wrote: > > On Sat, Sep 15, 2018 at 8:35 AM Alexander Kapshuk > wrote: > > > > Is this commit queued up for inclusion into the stable tree? > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/driver

Inclusion of commit e54192b48da7 into stable tree?

Is this commit queued up for inclusion into the stable tree? https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/of/base.c?h=next-20180913=e54192b48da75f025ae4b277925eaf6aca1d13bd Applying the patch on top of v4.18.8 fixes the booting problem for me. The contents of

Inclusion of commit e54192b48da7 into stable tree?

Is this commit queued up for inclusion into the stable tree? https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/of/base.c?h=next-20180913=e54192b48da75f025ae4b277925eaf6aca1d13bd Applying the patch on top of v4.18.8 fixes the booting problem for me. The contents of

Re: please revert commit ce8556cca6 "kbuild: verify that $DEPMOD is installed" introduced in v4.18.4.

On Thu, Aug 23, 2018 at 05:38:27PM +0900, Masahiro Yamada wrote: > Hi Randy, > > > 2018-08-23 8:33 GMT+09:00 Randy Dunlap : > > On 08/22/2018 11:53 AM, H. Nikolaus Schaller wrote: > >> This patch requires that /sbin/depmod is installed and installable on > >> the build host. > >> > >> But not

Re: please revert commit ce8556cca6 "kbuild: verify that $DEPMOD is installed" introduced in v4.18.4.

On Thu, Aug 23, 2018 at 05:38:27PM +0900, Masahiro Yamada wrote: > Hi Randy, > > > 2018-08-23 8:33 GMT+09:00 Randy Dunlap : > > On 08/22/2018 11:53 AM, H. Nikolaus Schaller wrote: > >> This patch requires that /sbin/depmod is installed and installable on > >> the build host. > >> > >> But not

[tip:perf/urgent] perf tools: Fix check-headers.sh AND list path of execution

Commit-ID: 51d8aac236493833acf60d9c3b6c42437a18da36 Gitweb: https://git.kernel.org/tip/51d8aac236493833acf60d9c3b6c42437a18da36 Author: Alexander Kapshuk AuthorDate: Sat, 11 Aug 2018 11:39:15 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 13 Aug 2018 15:46:19 -0300 perf

[tip:perf/urgent] perf tools: Fix check-headers.sh AND list path of execution

Commit-ID: 51d8aac236493833acf60d9c3b6c42437a18da36 Gitweb: https://git.kernel.org/tip/51d8aac236493833acf60d9c3b6c42437a18da36 Author: Alexander Kapshuk AuthorDate: Sat, 11 Aug 2018 11:39:15 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 13 Aug 2018 15:46:19 -0300 perf

Re: [PATCH] perf tools: Fix check-headers.sh AND list path of execution

On Mon, Aug 13, 2018 at 9:58 PM Arnaldo Carvalho de Melo wrote: > Thanks, applied the three patches to acme/perf/core. > > - Arnaldo Thanks.

Re: [PATCH] perf tools: Fix check-headers.sh AND list path of execution

On Mon, Aug 13, 2018 at 9:58 PM Arnaldo Carvalho de Melo wrote: > Thanks, applied the three patches to acme/perf/core. > > - Arnaldo Thanks.

Re: [PATCH] perf tools: Fix check-headers.sh AND list path of execution

On Mon, Aug 13, 2018 at 2:16 PM Jiri Olsa wrote: > > On Sat, Aug 11, 2018 at 11:39:15AM +0300, Alexander Kapshuk wrote: > > The '||' path of execution in the 'test' block of the check_2() function > > may also be taken if file2 does not exist, in which case the warning > &g

Re: [PATCH] perf tools: Fix check-headers.sh AND list path of execution

On Mon, Aug 13, 2018 at 2:16 PM Jiri Olsa wrote: > > On Sat, Aug 11, 2018 at 11:39:15AM +0300, Alexander Kapshuk wrote: > > The '||' path of execution in the 'test' block of the check_2() function > > may also be taken if file2 does not exist, in which case the warning > &g

[PATCH] perf tools: Fix check-headers.sh AND list path of execution

he code following the '&&' operator into a compound list to be executed in the current process environment only if file2 does exist. Should the files being compared differ, a diff command to compare the files concerned is printed on standard output. E.g. diff -u tools/arch/x86/lib/memcpy_64.S arch/x8

[PATCH] perf tools: Fix check-headers.sh AND list path of execution

he code following the '&&' operator into a compound list to be executed in the current process environment only if file2 does exist. Should the files being compared differ, a diff command to compare the files concerned is printed on standard output. E.g. diff -u tools/arch/x86/lib/memcpy_64.S arch/x8

Re: [PATCH 3/4] perf tools: Fix check-headers.sh output file variables

On Mon, Jul 23, 2018, 08:01 Jiri Olsa wrote: > On Fri, Jul 20, 2018 at 06:22:49PM +0300, Alexander Kapshuk wrote: > > On Fri, Jul 20, 2018 at 6:16 PM Jiri Olsa wrote: > > > > > > On Fri, Jul 20, 2018 at 11:57:45AM -0300, Arnaldo Carvalho de Melo > wrote: > &g

Re: [PATCH 3/4] perf tools: Fix check-headers.sh output file variables

On Mon, Jul 23, 2018, 08:01 Jiri Olsa wrote: > On Fri, Jul 20, 2018 at 06:22:49PM +0300, Alexander Kapshuk wrote: > > On Fri, Jul 20, 2018 at 6:16 PM Jiri Olsa wrote: > > > > > > On Fri, Jul 20, 2018 at 11:57:45AM -0300, Arnaldo Carvalho de Melo > wrote: > &g

Re: [PATCH 3/4] perf tools: Fix check-headers.sh output file variables

On Fri, Jul 20, 2018 at 6:16 PM Jiri Olsa wrote: > > On Fri, Jul 20, 2018 at 11:57:45AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jul 20, 2018 at 01:00:35PM +0200, Jiri Olsa escreveu: > > > The warning message in check_w function uses wrongly > > > the $file variable instead of $file1

Re: [PATCH 3/4] perf tools: Fix check-headers.sh output file variables

On Fri, Jul 20, 2018 at 6:16 PM Jiri Olsa wrote: > > On Fri, Jul 20, 2018 at 11:57:45AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jul 20, 2018 at 01:00:35PM +0200, Jiri Olsa escreveu: > > > The warning message in check_w function uses wrongly > > > the $file variable instead of $file1

[PATCH 2/2] ver_linux: Do not check for ver_linux pattern in version function

pattern being found in the output being parsed may thus be safely omitted. Signed-off-by: Alexander Kapshuk --- scripts/ver_linux | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/ver_linux b/scripts/ver_linux index e1dc041f903f..a6c728db05ce 100755 --- a/scripts/ver_linux

[PATCH 2/2] ver_linux: Do not check for ver_linux pattern in version function

pattern being found in the output being parsed may thus be safely omitted. Signed-off-by: Alexander Kapshuk --- scripts/ver_linux | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/ver_linux b/scripts/ver_linux index e1dc041f903f..a6c728db05ce 100755 --- a/scripts/ver_linux

[PATCH 1/2] ver_linux: Process input coming from procmaps that matches libc only

Currently, input coming from /proc/self/maps is split into fields without checking whether or not it matches libc.so. This is not efficient. All text processing should only be performed on lines of input that match libc.so. Signed-off-by: Alexander Kapshuk --- scripts/ver_linux | 12

[PATCH 1/2] ver_linux: Process input coming from procmaps that matches libc only

Currently, input coming from /proc/self/maps is split into fields without checking whether or not it matches libc.so. This is not efficient. All text processing should only be performed on lines of input that match libc.so. Signed-off-by: Alexander Kapshuk --- scripts/ver_linux | 12

[PATCH 2/2] ver_linux: Drop redundant calls to system() to test if file is readable

not be. Instead of testing if a file is accessible and readable via calls to system("test -r " file), rely on the value returned by getline to perform this kind of testing. Getline returns -1 on error, with the code within the while loops not being run. Signed-off-by: Alexander Kapshuk <a

[PATCH 2/2] ver_linux: Drop redundant calls to system() to test if file is readable

not be. Instead of testing if a file is accessible and readable via calls to system("test -r " file), rely on the value returned by getline to perform this kind of testing. Getline returns -1 on error, with the code within the while loops not being run. Signed-off-by: Alexander Kapshuk --

[PATCH 1/2] ver_linux: Move stderr redirection from function parameter to function body

Remove stderr redirection to stdout from all the parameters to the version() function, and put it with the body of the version() function instead. This improves code readability. Signed-off-by: Alexander Kapshuk <alexander.kaps...@gmail.com> --- scripts/ver_linu

[PATCH 1/2] ver_linux: Move stderr redirection from function parameter to function body

Remove stderr redirection to stdout from all the parameters to the version() function, and put it with the body of the version() function instead. This improves code readability. Signed-off-by: Alexander Kapshuk --- scripts/ver_linux | 53 --- 1 file

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

On Thu, Mar 1, 2018 at 11:06 PM, Tobin C. Harding wrote: > On Tue, Feb 27, 2018 at 03:45:09PM +1100, Tobin C. Harding wrote: >> When the system is idle it is likely that most files under /proc/PID >> will be identical for various processes. Scanning _all_ the PIDs under >> /proc

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

On Thu, Mar 1, 2018 at 11:06 PM, Tobin C. Harding wrote: > On Tue, Feb 27, 2018 at 03:45:09PM +1100, Tobin C. Harding wrote: >> When the system is idle it is likely that most files under /proc/PID >> will be identical for various processes. Scanning _all_ the PIDs under >> /proc is unnecessary

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

On Tue, Feb 27, 2018 at 6:45 AM, Tobin C. Harding wrote: > When the system is idle it is likely that most files under /proc/PID > will be identical for various processes. Scanning _all_ the PIDs under > /proc is unnecessary and implies that we are thoroughly scanning /proc. > This

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

On Tue, Feb 27, 2018 at 6:45 AM, Tobin C. Harding wrote: > When the system is idle it is likely that most files under /proc/PID > will be identical for various processes. Scanning _all_ the PIDs under > /proc is unnecessary and implies that we are thoroughly scanning /proc. > This is _not_ the

Re: [PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Sat, Jan 6, 2018 at 10:00 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 06-01-18 20:56, Alexander Kapshuk wrote: >> >> On Sat, Jan 6, 2018 at 9:43 PM, Hans de Goede <hdego...@redhat.com> wrote: >>> >>> HI,

Re: [PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Sat, Jan 6, 2018 at 10:00 PM, Hans de Goede wrote: > Hi, > > > On 06-01-18 20:56, Alexander Kapshuk wrote: >> >> On Sat, Jan 6, 2018 at 9:43 PM, Hans de Goede wrote: >>> >>> HI, >>> >>> >>> On 06-01-18 20:30, Alexander

Re: [PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Sat, Jan 6, 2018 at 9:43 PM, Hans de Goede <hdego...@redhat.com> wrote: > HI, > > > On 06-01-18 20:30, Alexander Kapshuk wrote: >> >> On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede <hdego...@redhat.com> wrote: >>> >>> Hi,

Re: [PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Sat, Jan 6, 2018 at 9:43 PM, Hans de Goede wrote: > HI, > > > On 06-01-18 20:30, Alexander Kapshuk wrote: >> >> On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede wrote: >>> >>> Hi, >>> >>> >>> On 06-01-18 15:20, Alexander K

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 06-01-18 15:20, Alexander Kapshuk wrote: >> >> On Mon, Dec 25, 2017 at 04:42:59PM +0200, Alexander Kapshuk wrote: >>> >>> Sparse emitted the following warning

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede wrote: > Hi, > > > On 06-01-18 15:20, Alexander Kapshuk wrote: >> >> On Mon, Dec 25, 2017 at 04:42:59PM +0200, Alexander Kapshuk wrote: >>> >>> Sparse emitted the following warning: >>> ../drivers/sta

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Mon, Dec 25, 2017 at 04:42:59PM +0200, Alexander Kapshuk wrote: > Sparse emitted the following warning: > ../drivers/staging/vboxvideo/vbox_fb.c:173:27: warning: incorrect type in > assignment (different address spaces) > ../drivers/staging/vboxvideo/vbox_fb.c:173:27:expected c

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

On Mon, Dec 25, 2017 at 04:42:59PM +0200, Alexander Kapshuk wrote: > Sparse emitted the following warning: > ../drivers/staging/vboxvideo/vbox_fb.c:173:27: warning: incorrect type in > assignment (different address spaces) > ../drivers/staging/vboxvideo/vbox_fb.c:173:27:expected c

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

ment to vbva to fix the warning. Signed-off-by: Alexander Kapshuk <alexander.kaps...@gmail.com> --- drivers/staging/vboxvideo/vbox_fb.c | 2 +- drivers/staging/vboxvideo/vbox_main.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_fb.c

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning

ment to vbva to fix the warning. Signed-off-by: Alexander Kapshuk --- drivers/staging/vboxvideo/vbox_fb.c | 2 +- drivers/staging/vboxvideo/vbox_main.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_fb.c b/drivers/staging/vboxvideo/vbo

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Mon, Dec 4, 2017 at 12:20 PM, wrote: > On Mon, 2017-12-04 at 19:21 +1100, Tobin C. Harding wrote: >> On Mon, Dec 04, 2017 at 10:51:53AM +0530, Kaiwan N Billimoria wrote: >> > > --- >> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl >> >

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Mon, Dec 4, 2017 at 12:20 PM, wrote: > On Mon, 2017-12-04 at 19:21 +1100, Tobin C. Harding wrote: >> On Mon, Dec 04, 2017 at 10:51:53AM +0530, Kaiwan N Billimoria wrote: >> > > --- >> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl >> > index

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Wed, Nov 29, 2017 at 12:16 PM, Tobin C. Harding <m...@tobin.cc> wrote: > On Wed, Nov 29, 2017 at 09:59:59AM +0200, Alexander Kapshuk wrote: >> On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding <m...@tobin.cc> wrote: >> > On Tue, Nov 28, 2017 at 03:16:24PM

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Wed, Nov 29, 2017 at 12:16 PM, Tobin C. Harding wrote: > On Wed, Nov 29, 2017 at 09:59:59AM +0200, Alexander Kapshuk wrote: >> On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding wrote: >> > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote: >> >>

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding <m...@tobin.cc> wrote: > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote: >> On Tue, Nov 28, 2017 at 8:32 AM, Tobin C. Harding <m...@tobin.cc> wrote: >> > Currently, leaking_addresses.pl

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding wrote: > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote: >> On Tue, Nov 28, 2017 at 8:32 AM, Tobin C. Harding wrote: >> > Currently, leaking_addresses.pl only supports scanning 64 bit >> > archit

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Tue, Nov 28, 2017 at 8:32 AM, Tobin C. Harding wrote: > Currently, leaking_addresses.pl only supports scanning 64 bit > architectures. This is due to how the regular expressions are formed. We > can do better than this. 32 architectures can be supported if we take > into

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Tue, Nov 28, 2017 at 8:32 AM, Tobin C. Harding wrote: > Currently, leaking_addresses.pl only supports scanning 64 bit > architectures. This is due to how the regular expressions are formed. We > can do better than this. 32 architectures can be supported if we take > into consideration the

Re: [PATCH] rtl8188eu: Correcting macro ROUND macro defination

TE1(s##2) ^ TE2(s##3) ^ TE3(s##0) ^ rk[4 * i + 1]; > \ > d##2 = TE0(s##2) ^ TE1(s##3) ^ TE2(s##0) ^ TE3(s##1) ^ rk[4 * i + 2]; > \ > d##3 = TE0(s##3) ^ TE1(s##0) ^ TE2(s##1) ^ TE3(s##2) ^ rk[4 * i + 3]; > \ > } while (0) > > On Tue, Mar 14, 2017 at 5:02 PM, Al

Re: [PATCH] rtl8188eu: Correcting macro ROUND macro defination

s##0) ^ rk[4 * i + 1]; > \ > d##2 = TE0(s##2) ^ TE1(s##3) ^ TE2(s##0) ^ TE3(s##1) ^ rk[4 * i + 2]; > \ > d##3 = TE0(s##3) ^ TE1(s##0) ^ TE2(s##1) ^ TE3(s##2) ^ rk[4 * i + 3]; > \ > } while (0) > > On Tue, Mar 14, 2017 at 5:02 PM, Alexander Kapshuk > wr

Re: [PATCH] rtl8188eu: Correcting macro ROUND macro defination

On Tue, Mar 14, 2017 at 1:26 PM, Pushkar Jambhlekar wrote: > Description: > There should not be ';' after do ... while(0) in macro defination > > Signed-off-by: Pushkar Jambhlekar > --- > drivers/staging/rtl8188eu/core/rtw_security.c | 2 +- > 1

Re: [PATCH] rtl8188eu: Correcting macro ROUND macro defination

On Tue, Mar 14, 2017 at 1:26 PM, Pushkar Jambhlekar wrote: > Description: > There should not be ';' after do ... while(0) in macro defination > > Signed-off-by: Pushkar Jambhlekar > --- > drivers/staging/rtl8188eu/core/rtw_security.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: Linux 4.10.2

On Sun, Mar 12, 2017 at 10:11 PM, Ilia Mirkin wrote: > On Sun, Mar 12, 2017 at 3:05 PM, Greg KH wrote: >> On Sun, Mar 12, 2017 at 01:51:24PM -0500, Robert Nelson wrote: >>> On Sun, Mar 12, 2017 at 8:05 AM, Greg KH

Re: Linux 4.10.2

On Sun, Mar 12, 2017 at 10:11 PM, Ilia Mirkin wrote: > On Sun, Mar 12, 2017 at 3:05 PM, Greg KH wrote: >> On Sun, Mar 12, 2017 at 01:51:24PM -0500, Robert Nelson wrote: >>> On Sun, Mar 12, 2017 at 8:05 AM, Greg KH wrote: >>> > I'm announcing the release of the 4.10.2 kernel. >>> > >>> > All

  1   2   3   4   >