Re: [PATCH v6] modules: introduce the MODULE_SCMVERSION config

2021-02-08 Thread Will McVicker
wrote: > > +++ Will McVicker [21/01/21 21:36 +]: > > > Config MODULE_SCMVERSION introduces a new module attribute -- > > > `scmversion` -- which can be used to identify a given module's SCM > > > version. This is very useful for developers that update their kernel > > >

Re: [PATCH v6] modules: introduce the MODULE_SCMVERSION config

2021-02-02 Thread Will McVicker
Hi Christoph, Did you see Saravana's response to you in version 5? I'd love to hear your thoughts. Thanks, Will On Mon, Feb 1, 2021 at 11:42 PM Christoph Hellwig wrote: > > Just to deposit my opposition again: I don't think this hack for your > out of tree builds has any place in the kernel

Re: [PATCH v6] modules: introduce the MODULE_SCMVERSION config

2021-02-01 Thread Will McVicker
Hi Jessica and Masahiro, Could I get a final look at the latest patchset please? All the issues have been addressed thus far. Thanks, Will On Thu, Jan 21, 2021 at 1:36 PM Will McVicker wrote: > > Config MODULE_SCMVERSION introduces a new module attribute -- > `scmversion` -- which ca

[PATCH v6] modules: introduce the MODULE_SCMVERSION config

2021-01-21 Thread Will McVicker
module/MODULENAME/scmversion Signed-off-by: Will McVicker --- Changelog since v5: - Simplified scripts/Makefile.modpost to not check for a relative M= path - Added space between -v and $(module_scmversion) - Updated modpost.c to not check for a missing argument to -v Documentation/ABI/stable/sysfs-

Re: [PATCH] kbuild: warn a relative path used for M= in out-of-tree builds

2021-01-20 Thread Will McVicker
and create objects in foo/bar/baz. > > Currently, it works like that because of the presence of VPATH and > --include-dir=$(abs_srctree), but this behavior is subtle and cannot > be guaranteed in the future. I do not know if it was even officially > supported ever. > > I do

Re: [PATCH v5] modules: introduce the MODULE_SCMVERSION config

2021-01-19 Thread Will McVicker
ure everything was defined as expected. Thanks, Will On Tue, Jan 19, 2021 at 1:48 PM Will McVicker wrote: > > Thanks for the review Masahiro! I'll upload v6 shortly. > > --Will > > On Sun, Jan 17, 2021 at 7:21 AM Masahiro Yamada wrote: > > > > On Fri, Jan 8, 2021 at

Re: [PATCH v5] modules: introduce the MODULE_SCMVERSION config

2021-01-19 Thread Will McVicker
Thanks for the review Masahiro! I'll upload v6 shortly. --Will On Sun, Jan 17, 2021 at 7:21 AM Masahiro Yamada wrote: > > On Fri, Jan 8, 2021 at 9:30 AM Will McVicker wrote: > > > > Config MODULE_SCMVERSION introduces a new module attribute -- > > `scmversion` -- which

Re: [PATCH v5] modules: introduce the MODULE_SCMVERSION config

2021-01-14 Thread Will McVicker
Thanks Jessica for the reviews! --Will On Tue, Jan 12, 2021 at 7:55 AM Jessica Yu wrote: > > +++ Will McVicker [08/01/21 00:30 +]: > >Config MODULE_SCMVERSION introduces a new module attribute -- > >`scmversion` -- which can be used to identify a given module's SCM > &g

Re: [PATCH v1] HID: make arrays usage and value to be the same

2021-01-14 Thread Will McVicker
Hi Jiri, I noticed this hasn't merged yet. So just sending a friendly reminder. Thanks, Will On Thu, Dec 17, 2020 at 10:42 AM Will McVicker wrote: > > Great! Thanks for the reply. > > --Will > > On Thu, Dec 17, 2020 at 2:19 AM Jiri Kosina wrote: > > > > On M

[PATCH v5] modules: introduce the MODULE_SCMVERSION config

2021-01-07 Thread Will McVicker
module/MODULENAME/scmversion Signed-off-by: Will McVicker --- Documentation/ABI/stable/sysfs-module | 18 ++ include/linux/module.h| 1 + init/Kconfig | 14 ++ kernel/module.c | 2 ++ scripts/Makefile.m

Re: [PATCH v4] modules: introduce the MODULE_SCMVERSION config

2021-01-07 Thread Will McVicker
the Documentation in v5. Thanks, Will On Thu, Jan 7, 2021 at 6:31 AM Jessica Yu wrote: > > +++ Will McVicker [06/01/21 10:44 -0800]: > >Thanks for the vacation notice Jessica! I'm just letting you know I'm > >back as well and am happy to respond to any concerns regarding v4 w

Re: [PATCH v4] modules: introduce the MODULE_SCMVERSION config

2021-01-06 Thread Will McVicker
Thanks for the vacation notice Jessica! I'm just letting you know I'm back as well and am happy to respond to any concerns regarding v4 when you get all caught up. I hope you had a relaxing holiday :) Thanks, Will On Fri, Dec 18, 2020 at 4:01 AM Jessica Yu wrote: > > +++ Will McVicker

Re: [PATCH v1] HID: make arrays usage and value to be the same

2020-12-17 Thread Will McVicker
Great! Thanks for the reply. --Will On Thu, Dec 17, 2020 at 2:19 AM Jiri Kosina wrote: > > On Mon, 14 Dec 2020, Will McVicker wrote: > > > > The HID subsystem allows an "HID report field" to have a different > > > number of "values" and "usa

[PATCH v4] modules: introduce the MODULE_SCMVERSION config

2020-12-16 Thread Will McVicker
module/MODULENAME/scmversion Signed-off-by: Will McVicker --- Changelog since v3: - Dropped [PATCH v2 1/2] scripts/setlocalversion: allow running in a subdir Documentation/ABI/stable/sysfs-module | 18 ++ include/linux/module.h| 1 + init/K

Re: [PATCH v3 1/2] scripts/setlocalversion: allow running in a subdir

2020-12-16 Thread Will McVicker
On Fri, Dec 11, 2020 at 04:33:59PM +0100, Jessica Yu wrote: > Hi Will, > > +++ Will McVicker [08/12/20 20:05 +]: > > Getting the scmversion using scripts/setlocalversion currently only > > works when run at the root of a git or mecurial project. This was > > introd

Re: [PATCH v1] HID: make arrays usage and value to be the same

2020-12-14 Thread Will McVicker
On Sat, Dec 05, 2020 at 12:48:48AM +, Will McVicker wrote: > The HID subsystem allows an "HID report field" to have a different > number of "values" and "usages" when it is allocated. When a field > struct is created, the size of the usage array

[PATCH v3 2/2] modules: introduce the MODULE_SCMVERSION config

2020-12-08 Thread Will McVicker
module/MODULENAME/scmversion Signed-off-by: Will McVicker --- Documentation/ABI/stable/sysfs-module | 18 ++ include/linux/module.h| 1 + init/Kconfig | 12 kernel/module.c | 2 ++ scripts/Makefile.m

[PATCH v3 0/2] modules: add scmversion field

2020-12-08 Thread Will McVicker
found. Thanks, Will Will McVicker (2): scripts/setlocalversion: allow running in a subdir modules: introduce the MODULE_SCMVERSION config Documentation/ABI/stable/sysfs-module | 18 ++ include/linux/module.h| 1 + init/Kconfig | 12

[PATCH v3 1/2] scripts/setlocalversion: allow running in a subdir

2020-12-08 Thread Will McVicker
AUTO is not set" arch/* | wc -l 89 So let's bring back this functionality so that we can use scripts/setlocalversion to capture the SCM version of external modules that reside within subdirectories of an SCM project. Signed-off-by: Will McVicker --- scripts/setlocalversion | 5 ++--- 1 file c

Re: [PATCH v1] HID: make arrays usage and value to be the same

2020-12-07 Thread Will McVicker
On Mon, Dec 07, 2020 at 07:24:16PM +0100, Greg KH wrote: > On Mon, Dec 07, 2020 at 09:55:48AM -0800, Will McVicker wrote: > > On Sat, Dec 05, 2020 at 09:59:57AM +0100, Greg KH wrote: > > > On Sat, Dec 05, 2020 at 12:48:48AM +0000, Will McVicker wrote: > > > > Th

Re: [PATCH v1] HID: make arrays usage and value to be the same

2020-12-07 Thread Will McVicker
On Sat, Dec 05, 2020 at 09:59:57AM +0100, Greg KH wrote: > On Sat, Dec 05, 2020 at 12:48:48AM +, Will McVicker wrote: > > The HID subsystem allows an "HID report field" to have a different > > number of "values" and "usages" when it is allocated.

[PATCH v1] HID: make arrays usage and value to be the same

2020-12-04 Thread Will McVicker
This leads to a potential out-of-bounds write in __hidinput_change_resolution_multipliers() and an out-of-bounds read in hidinput_count_leds(). To fix this, let's make sure that both the usage and value arrays are the same size. Signed-off-by: Will McVicker --- drivers/hid/hid-core.c | 6 +++--- 1 fi

Re: [PATCH v2 0/2] Adds support to capture module's SCM version

2020-12-04 Thread Will McVicker
On Fri, Dec 04, 2020 at 06:18:08PM +, Christoph Hellwig wrote: > On Fri, Dec 04, 2020 at 10:13:56AM -0800, Will McVicker wrote: > > On Fri, Dec 04, 2020 at 07:51:59AM +, Christoph Hellwig wrote: > > > I think your decription still shows absolutely no benefit for the >

Re: [PATCH v2 0/2] Adds support to capture module's SCM version

2020-12-04 Thread Will McVicker
On Fri, Dec 04, 2020 at 07:51:59AM +, Christoph Hellwig wrote: > I think your decription still shows absolutely no benefit for the > kernel, so I'not sure why anyone would want to waste time on this. Hi Christoph, Did you get a chance to read my earlier responses regarding the uses for

Re: [PATCH v2 0/2] Adds support to capture module's SCM version

2020-12-03 Thread William Mcvicker
On Wed, Nov 25, 2020 at 01:05:39AM +, Will McVicker wrote: > Hi All, > > I have updated the patchset to: > > *) Include Documentation. > *) Use a consistent output pattern for the SCM version. > > In my debugging, I found that the vermagic reported by modinfo c

[PATCH v1 1/1] gpiolib: Don't free if pin ranges are not defined

2020-11-30 Thread Will McVicker
anges") Signed-off-by: Edmond Chung Signed-off-by: Andrew Chant Signed-off-by: Will McVicker --- drivers/gpio/gpiolib.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 089ddcaa9bc6..6e3c4d7a7d14 100644 --- a/drivers/gpio/gpiolib.c +++

[PATCH v1 0/1] gpiolib: Don't free if pin ranges are not defined

2020-11-30 Thread Will McVicker
This patch fixes commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") where an imbalance of requests and frees to the pinctrl driver were introduced. Edmond Chung (1): gpiolib: Don't free if pin ranges are not defined drivers/gpio/gpiolib.c | 5 + 1 file changed, 5

Re: [PATCH v2 1/5] USB: gadget: f_rndis: fix bitrate for SuperSpeed and above

2020-11-30 Thread William Mcvicker
On Mon, Nov 30, 2020 at 06:24:40AM +, Peter Chen wrote: > On 20-11-27 15:05:55, Greg Kroah-Hartman wrote: > > From: Will McVicker > > > > Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate > > defined by commit 1650113888fe ("us

Re: Potential Issue in Tracing Ring Buffer

2020-11-30 Thread William Mcvicker
sted-by from someone on the Google team, so that I can send > this upstream? It already passed all my internal testing, but I want to > make sure this is the fix for the issue I reference in the change log. > > -- Steve > > -- > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. > Hi Steve, Thanks for the quick turnaround! Daniel and I have both tested your patch and verified it's working on our end. Feel free to include: Tested-by: Daniel Mentz Tested-by: Will McVicker --Will

[PATCH v2 2/2] modules: add scmversion field

2020-11-24 Thread Will McVicker
t; cat /sys/module//scmversion Signed-off-by: Will McVicker --- Documentation/ABI/stable/sysfs-module | 17 + include/linux/module.h| 1 + kernel/module.c | 2 ++ scripts/Makefile.modpost | 20 scrip

[PATCH v2 1/2] scripts/setlocalversion: allow running in a subdir

2020-11-24 Thread Will McVicker
AUTO is not set" arch/* | wc -l 89 So let's bring back this functionality so that we can use scripts/setlocalversion to capture the SCM version of external modules that reside within subdirectories of an SCM project. Signed-off-by: Will McVicker --- scripts/setlocalversion | 5 ++--- 1 file c

[PATCH v2 0/2] Adds support to capture module's SCM version

2020-11-24 Thread Will McVicker
loaded. With that being said, adding this scmversion attribute ensures that you can *always* get the correct SCM version of the module that loaded. Please take a look at the updated patch and provide any comments you find. Thanks, Will Will McVicker (2): scripts/setlocalversion: allow running

Re: [PATCH v1 0/2] Add support to capture external module's SCM version

2020-11-24 Thread William Mcvicker
On Tue, Nov 24, 2020 at 09:24:26PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 24, 2020 at 10:31:39AM -0800, William Mcvicker wrote: > > On Tue, Nov 24, 2020 at 07:12:40PM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Nov 24, 2020 at 10:05:16AM -0800, William Mcvicker wro

Re: [PATCH v1 0/2] Add support to capture external module's SCM version

2020-11-24 Thread William Mcvicker
On Tue, Nov 24, 2020 at 07:12:40PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 24, 2020 at 10:05:16AM -0800, William Mcvicker wrote: > > On Tue, Nov 24, 2020 at 10:31:18AM +0100, Jessica Yu wrote: > > > +++ William Mcvicker [23/11/20 14:13 -0800]: > > > > On M

Re: [PATCH v1 0/2] Add support to capture external module's SCM version

2020-11-24 Thread William Mcvicker
On Tue, Nov 24, 2020 at 10:31:18AM +0100, Jessica Yu wrote: > +++ William Mcvicker [23/11/20 14:13 -0800]: > > On Mon, Nov 23, 2020 at 09:02:57AM +, Christoph Hellwig wrote: > > > On Sat, Nov 21, 2020 at 01:16:49AM +0000, Will McVicker wrote: > > > > These

Re: [PATCH v1 0/2] Add support to capture external module's SCM version

2020-11-23 Thread William Mcvicker
On Mon, Nov 23, 2020 at 09:02:57AM +, Christoph Hellwig wrote: > On Sat, Nov 21, 2020 at 01:16:49AM +, Will McVicker wrote: > > These two patches add module support to capture an external module's SCM > > version as a MODULE_INFO() attribute. This allows users to i

[PATCH v1 0/2] Add support to capture external module's SCM version

2020-11-20 Thread Will McVicker
-rc4-00110-gd83461f36865 SMP mod_unload $ modinfo simple_module.ko | egrep 'scmversion|vermagic' scmversion: svn1 vermagic: 5.10.0-rc4-00110-gd83461f36865 SMP mod_unload Will McVicker (2): scripts/setlocalversion: allow running in a subdir modules: add scmversion field include

[PATCH v1 1/2] scripts/setlocalversion: allow running in a subdir

2020-11-20 Thread Will McVicker
AUTO is not set" arch/* | wc -l 89 So let's bring back this functionality so that we can use scripts/setlocalversion to capture the SCM version of external modules that reside within subdirectories of an SCM project. Signed-off-by: Will McVicker --- scripts/setlocalversion | 5 ++--- 1 file c

[PATCH v1 2/2] modules: add scmversion field

2020-11-20 Thread Will McVicker
t; cat /sys/module//scmversion Signed-off-by: Will McVicker --- include/linux/module.h | 1 + kernel/module.c | 20 scripts/Makefile.modpost | 19 +-- scripts/mod/modpost.c| 28 +++- 4 files changed, 65 insertions

Re: [PATCH] arm64: Fix off-by-one vdso trampoline return value

2020-11-16 Thread William Mcvicker
tps://reviews.llvm.org/D86263. So for kernels that use ld.lld and the VDSO compat sigreturn trampoline, they need to make sure to upgrade their toolchain. I hope this thread helps anyone running into this issue in the future. Thanks, Will On 11/12/2020, William Mcvicker wrote: > Hi Nick, > &g

Re: [PATCH] arm64: Fix off-by-one vdso trampoline return value

2020-11-12 Thread William Mcvicker
14:22AM +, Will McVicker wrote: > > Depending on your host nm version, the generated header > > `include/generated/vdso32-offsets.h` may have the bottom bit set for the > > thumb vdso offset addresses (as observed when using llvm-nm). This > > results in an additional +1 fo

[PATCH] arm64: Fix off-by-one vdso trampoline return value

2020-11-11 Thread Will McVicker
eturn trampolines from vDSO") Signed-off-by: Will McVicker --- arch/arm64/include/asm/vdso.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/vdso.h b/arch/arm64/include/asm/vdso.h index f99dcb94b438..a7384379e8e1 100644 --- a/arch/arm64/include/asm/vd

Re: [PATCH v2 1/1] netfilter: nat: add a range check for l3/l4 protonum

2020-09-01 Thread William Mcvicker
ll > > > > On Mon, Aug 03, 2020 at 06:31:56PM +, William Mcvicker wrote: > > [...] > > > diff --git a/net/netfilter/nf_conntrack_netlink.c > > > b/net/netfilter/nf_conntrack_netlink.c > > > index 31fa94064a62..56d310f8b29a 100644 > > > --- a/net

[PATCH v3 0/1] netfilter: nat: add a range check for l3/l4 protonum

2020-08-24 Thread Will McVicker
Hi Pablo, > This patch is much smaller and if you confirm this is address the > issue, then this is awesome. Yes, I can confirm the updated patch does fix the kernel panic. I have retested on the Pixel 4 XL with version 4.14.180. Please see the updated patchset v3. Thanks, Will Will Mc

[PATCH v3 1/1] netfilter: nat: add a range check for l3/l4 protonum

2020-08-24 Thread Will McVicker
/0x4d4 netlink_rcv_skb+0x100/0x184 nfnetlink_rcv+0xf4/0x180 netlink_unicast+0x360/0x770 netlink_sendmsg+0x5a0/0x6a4 ___sys_sendmsg+0x314/0x46c SyS_sendmsg+0xb4/0x108 el0_svc_naked+0x34/0x38 Fixes: c1d10adb4a521 ("[NETFILTER]: Add ctnetlink port for nf_conntrack") Signed-off-by: Wil

Re: [PATCH v2 1/1] netfilter: nat: add a range check for l3/l4 protonum

2020-08-03 Thread William Mcvicker
Hi, I have attached the follow up fix that checks for the proto index during conntrack creation. Thanks, Will On 07/31/2020, William Mcvicker wrote: > Hi Pablo, > > > Note that this code does not exist in the tree anymore. I'm not sure > > if this problem still exists upstrea

Re: [PATCH 1/1] netfilter: nat: add range checks for access to nf_nat_l[34]protos[]

2020-07-31 Thread William Mcvicker
his thread with the re-worked patch. Thanks, Will On 07/31/2020, Pablo Neira Ayuso wrote: > Hi William, > > On Fri, Jul 31, 2020 at 12:26:11AM +, William Mcvicker wrote: > > Hi Pablo, > > > > Yes, I believe this oops is only triggered by userspace when the user >

Re: [PATCH 1/1] netfilter: nat: add range checks for access to nf_nat_l[34]protos[]

2020-07-30 Thread William Mcvicker
On Mon, Jul 27, 2020 at 05:57:20PM +, Will McVicker wrote: > > The indexes to the nf_nat_l[34]protos arrays come from userspace. So we > > need to make sure that before indexing the arrays, we verify the index > > is within the array bounds in order to prevent an OOB memory acce

[PATCH 1/1] netfilter: nat: add range checks for access to nf_nat_l[34]protos[]

2020-07-27 Thread Will McVicker
nfnetlink_rcv_msg+0x31c/0x4d4 netlink_rcv_skb+0x100/0x184 nfnetlink_rcv+0xf4/0x180 netlink_unicast+0x360/0x770 netlink_sendmsg+0x5a0/0x6a4 ___sys_sendmsg+0x314/0x46c SyS_sendmsg+0xb4/0x108 el0_svc_naked+0x34/0x38 Signed-off-by: Will McVicker --- net/ipv4/netfilter/nf_nat_l3proto_ipv4.c | 6

[PATCH 0/1] Netfilter OOB memory access security patch

2020-07-27 Thread Will McVicker
ove l3proto struct"), but the 4.19 and below LTS branches remain vulnerable. I have verifed the OOB kernel panic is fixed with this patch on both the 4.19 and 4.14 kernels using the approariate hardware. Please review the fix and apply to branches 4.19.y, 4.14.y, 4.9.y and 4.4.y. Thanks, Will Will Mc