* [PATCH 5.10 67/79] fcntl: make F_GETOWN(EX) return 0 on dead owner task
2022-10-27 16:55 [PATCH 5.10 00/79] 5.10.151-rc1 review Greg Kroah-Hartman
@ 2022-10-27 16:56 ` Greg Kroah-Hartman
2022-10-27 18:10 ` [PATCH 5.10 00/79] 5.10.151-rc1 review Guenter Roeck
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-27 16:56 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jeff Layton, J. Bruce Fields,
Alexander Viro, linux-fsdevel, linux-kernel, Cyrill Gorcunov,
Andrei Vagin, Pavel Tikhomirov, Sasha Levin
From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
[ Upstream commit cc4a3f885e8f2bc3c86a265972e94fef32d68f67 ]
Currently there is no way to differentiate the file with alive owner
from the file with dead owner but pid of the owner reused. That's why
CRIU can't actually know if it needs to restore file owner or not,
because if it restores owner but actual owner was dead, this can
introduce unexpected signals to the "false"-owner (which reused the
pid).
Let's change the api, so that F_GETOWN(EX) returns 0 in case actual
owner is dead already. This comports with the POSIX spec, which
states that a PID of 0 indicates that no signal will be sent.
Cc: Jeff Layton <jlayton@kernel.org>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Andrei Vagin <avagin@gmail.com>
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Stable-dep-of: f671a691e299 ("fcntl: fix potential deadlocks for &fown_struct.lock")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/fcntl.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 71b43538fa44..5a56351f1fc3 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -148,11 +148,15 @@ void f_delown(struct file *filp)
pid_t f_getown(struct file *filp)
{
- pid_t pid;
+ pid_t pid = 0;
read_lock(&filp->f_owner.lock);
- pid = pid_vnr(filp->f_owner.pid);
- if (filp->f_owner.pid_type == PIDTYPE_PGID)
- pid = -pid;
+ rcu_read_lock();
+ if (pid_task(filp->f_owner.pid, filp->f_owner.pid_type)) {
+ pid = pid_vnr(filp->f_owner.pid);
+ if (filp->f_owner.pid_type == PIDTYPE_PGID)
+ pid = -pid;
+ }
+ rcu_read_unlock();
read_unlock(&filp->f_owner.lock);
return pid;
}
@@ -200,11 +204,14 @@ static int f_setown_ex(struct file *filp, unsigned long arg)
static int f_getown_ex(struct file *filp, unsigned long arg)
{
struct f_owner_ex __user *owner_p = (void __user *)arg;
- struct f_owner_ex owner;
+ struct f_owner_ex owner = {};
int ret = 0;
read_lock(&filp->f_owner.lock);
- owner.pid = pid_vnr(filp->f_owner.pid);
+ rcu_read_lock();
+ if (pid_task(filp->f_owner.pid, filp->f_owner.pid_type))
+ owner.pid = pid_vnr(filp->f_owner.pid);
+ rcu_read_unlock();
switch (filp->f_owner.pid_type) {
case PIDTYPE_PID:
owner.type = F_OWNER_TID;
--
2.35.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 16:55 [PATCH 5.10 00/79] 5.10.151-rc1 review Greg Kroah-Hartman
2022-10-27 16:56 ` [PATCH 5.10 67/79] fcntl: make F_GETOWN(EX) return 0 on dead owner task Greg Kroah-Hartman
@ 2022-10-27 18:10 ` Guenter Roeck
2022-10-27 19:25 ` Greg Kroah-Hartman
2022-10-28 10:47 ` Sudip Mukherjee (Codethink)
` (3 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2022-10-27 18:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On 10/27/22 09:55, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.151 release.
> There are 79 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> Anything received after that time might be too late.
>
Building arm64:allmodconfig ... failed
--------------
Error log:
/bin/sh: scripts/pahole-flags.sh: Permission denied
Indeed:
$ ls -l scripts/pahole-flags.sh
-rw-rw-r-- 1 groeck groeck 530 Oct 27 11:08 scripts/pahole-flags.sh
Compared to upstream:
-rwxrwxr-x 1 groeck groeck 585 Oct 20 11:31 scripts/pahole-flags.sh
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 18:10 ` [PATCH 5.10 00/79] 5.10.151-rc1 review Guenter Roeck
@ 2022-10-27 19:25 ` Greg Kroah-Hartman
2022-10-27 19:27 ` Pavel Machek
0 siblings, 1 reply; 14+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-27 19:25 UTC (permalink / raw)
To: Guenter Roeck
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Thu, Oct 27, 2022 at 11:10:18AM -0700, Guenter Roeck wrote:
> On 10/27/22 09:55, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.151 release.
> > There are 79 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> > Anything received after that time might be too late.
> >
>
> Building arm64:allmodconfig ... failed
> --------------
> Error log:
> /bin/sh: scripts/pahole-flags.sh: Permission denied
>
> Indeed:
>
> $ ls -l scripts/pahole-flags.sh
> -rw-rw-r-- 1 groeck groeck 530 Oct 27 11:08 scripts/pahole-flags.sh
>
> Compared to upstream:
>
> -rwxrwxr-x 1 groeck groeck 585 Oct 20 11:31 scripts/pahole-flags.sh
Yeah, this is going to be an odd one. I have to do this by hand as
quilt and git quilt-import doesn't like setting the mode bit.
I wonder if I should just make a single-commit release with this file in
it, set to the proper permission, to get past this hurdle. I'll think
about it in the morning...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 19:25 ` Greg Kroah-Hartman
@ 2022-10-27 19:27 ` Pavel Machek
2022-10-27 19:39 ` Guenter Roeck
2022-10-27 19:49 ` Linus Torvalds
0 siblings, 2 replies; 14+ messages in thread
From: Pavel Machek @ 2022-10-27 19:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
On Thu 2022-10-27 21:25:54, Greg Kroah-Hartman wrote:
> On Thu, Oct 27, 2022 at 11:10:18AM -0700, Guenter Roeck wrote:
> > On 10/27/22 09:55, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.10.151 release.
> > > There are 79 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> > > Anything received after that time might be too late.
> > >
> >
> > Building arm64:allmodconfig ... failed
> > --------------
> > Error log:
> > /bin/sh: scripts/pahole-flags.sh: Permission denied
> >
> > Indeed:
> >
> > $ ls -l scripts/pahole-flags.sh
> > -rw-rw-r-- 1 groeck groeck 530 Oct 27 11:08 scripts/pahole-flags.sh
> >
> > Compared to upstream:
> >
> > -rwxrwxr-x 1 groeck groeck 585 Oct 20 11:31 scripts/pahole-flags.sh
>
> Yeah, this is going to be an odd one. I have to do this by hand as
> quilt and git quilt-import doesn't like setting the mode bit.
>
> I wonder if I should just make a single-commit release with this file in
> it, set to the proper permission, to get past this hurdle. I'll think
> about it in the morning...
Alternatively you can modify the caller to do /bin/sh /scripts/... so
it does not need a +x bit...
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 19:27 ` Pavel Machek
@ 2022-10-27 19:39 ` Guenter Roeck
2022-10-27 19:54 ` Florian Fainelli
2022-10-27 19:49 ` Linus Torvalds
1 sibling, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2022-10-27 19:39 UTC (permalink / raw)
To: Pavel Machek, Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, jonathanh, f.fainelli, sudipm.mukherjee, srw
On 10/27/22 12:27, Pavel Machek wrote:
> On Thu 2022-10-27 21:25:54, Greg Kroah-Hartman wrote:
>> On Thu, Oct 27, 2022 at 11:10:18AM -0700, Guenter Roeck wrote:
>>> On 10/27/22 09:55, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 5.10.151 release.
>>>> There are 79 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Building arm64:allmodconfig ... failed
>>> --------------
>>> Error log:
>>> /bin/sh: scripts/pahole-flags.sh: Permission denied
>>>
>>> Indeed:
>>>
>>> $ ls -l scripts/pahole-flags.sh
>>> -rw-rw-r-- 1 groeck groeck 530 Oct 27 11:08 scripts/pahole-flags.sh
>>>
>>> Compared to upstream:
>>>
>>> -rwxrwxr-x 1 groeck groeck 585 Oct 20 11:31 scripts/pahole-flags.sh
>>
>> Yeah, this is going to be an odd one. I have to do this by hand as
>> quilt and git quilt-import doesn't like setting the mode bit.
>>
>> I wonder if I should just make a single-commit release with this file in
>> it, set to the proper permission, to get past this hurdle. I'll think
>> about it in the morning...
>
> Alternatively you can modify the caller to do /bin/sh /scripts/... so
> it does not need a +x bit...
>
That should be done in mainline, though.
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 19:39 ` Guenter Roeck
@ 2022-10-27 19:54 ` Florian Fainelli
0 siblings, 0 replies; 14+ messages in thread
From: Florian Fainelli @ 2022-10-27 19:54 UTC (permalink / raw)
To: Guenter Roeck, Pavel Machek, Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, jonathanh, sudipm.mukherjee, srw
On 10/27/22 12:39, Guenter Roeck wrote:
> On 10/27/22 12:27, Pavel Machek wrote:
>> On Thu 2022-10-27 21:25:54, Greg Kroah-Hartman wrote:
>>> On Thu, Oct 27, 2022 at 11:10:18AM -0700, Guenter Roeck wrote:
>>>> On 10/27/22 09:55, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.10.151 release.
>>>>> There are 79 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied,
>>>>> please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>
>>>> Building arm64:allmodconfig ... failed
>>>> --------------
>>>> Error log:
>>>> /bin/sh: scripts/pahole-flags.sh: Permission denied
>>>>
>>>> Indeed:
>>>>
>>>> $ ls -l scripts/pahole-flags.sh
>>>> -rw-rw-r-- 1 groeck groeck 530 Oct 27 11:08 scripts/pahole-flags.sh
>>>>
>>>> Compared to upstream:
>>>>
>>>> -rwxrwxr-x 1 groeck groeck 585 Oct 20 11:31 scripts/pahole-flags.sh
>>>
>>> Yeah, this is going to be an odd one. I have to do this by hand as
>>> quilt and git quilt-import doesn't like setting the mode bit.
>>>
>>> I wonder if I should just make a single-commit release with this file in
>>> it, set to the proper permission, to get past this hurdle. I'll think
>>> about it in the morning...
>>
>> Alternatively you can modify the caller to do /bin/sh /scripts/... so
>> it does not need a +x bit...
>>
>
> That should be done in mainline, though.
This is the second time this is reported unfortunately, so while we
could change things in mainline to avoid being dependent upon the file
permissions stored in git, this really seems to be a workflow issue
involving quilt.
Any chance you can run a fixup while you apply a patch Greg?
--
Florian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 19:27 ` Pavel Machek
2022-10-27 19:39 ` Guenter Roeck
@ 2022-10-27 19:49 ` Linus Torvalds
2022-10-28 11:01 ` Greg Kroah-Hartman
1 sibling, 1 reply; 14+ messages in thread
From: Linus Torvalds @ 2022-10-27 19:49 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, Guenter Roeck, stable, patches, linux-kernel,
akpm, shuah, patches, lkft-triage, jonathanh, f.fainelli,
sudipm.mukherjee, srw
On Thu, Oct 27, 2022 at 12:27 PM Pavel Machek <pavel@denx.de> wrote:
>
> Alternatively you can modify the caller to do /bin/sh /scripts/... so
> it does not need a +x bit...
Generally we should be doing both.
Make it have the proper +x bit to show clearly that it's an executable
script and have 'ls' and friends show it that way when people enable
colorization or whatever.
*And* make any Makefiles and tooling use an explicit "sh" or whatever
thing, because we've traditionally let people use tar-files and patch
to generate their trees, and various stupid tools exist and get it
wrong even when we get it right in our git tree.
So belt and suspenders.
But in this case, I think our tools already do the "run shell" part:
Makefile:PAHOLE_FLAGS = $(shell PAHOLE=$(PAHOLE)
$(srctree)/scripts/pahole-flags.sh)
no? And at least in my -git tree, it's already executable.
Maybe one of those "various stipid tools exists" is in the stable
tree. I didn't check.
Linus
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 19:49 ` Linus Torvalds
@ 2022-10-28 11:01 ` Greg Kroah-Hartman
0 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-28 11:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pavel Machek, Guenter Roeck, stable, patches, linux-kernel, akpm,
shuah, patches, lkft-triage, jonathanh, f.fainelli,
sudipm.mukherjee, srw
On Thu, Oct 27, 2022 at 12:49:22PM -0700, Linus Torvalds wrote:
> On Thu, Oct 27, 2022 at 12:27 PM Pavel Machek <pavel@denx.de> wrote:
> >
> > Alternatively you can modify the caller to do /bin/sh /scripts/... so
> > it does not need a +x bit...
>
> Generally we should be doing both.
>
> Make it have the proper +x bit to show clearly that it's an executable
> script and have 'ls' and friends show it that way when people enable
> colorization or whatever.
>
> *And* make any Makefiles and tooling use an explicit "sh" or whatever
> thing, because we've traditionally let people use tar-files and patch
> to generate their trees, and various stupid tools exist and get it
> wrong even when we get it right in our git tree.
>
> So belt and suspenders.
>
> But in this case, I think our tools already do the "run shell" part:
>
> Makefile:PAHOLE_FLAGS = $(shell PAHOLE=$(PAHOLE)
> $(srctree)/scripts/pahole-flags.sh)
>
> no? And at least in my -git tree, it's already executable.
In your tree, yes.
And when I export the patch, we get the proper:
create mode 100755 scripts/pahole-flags.sh
line added to the patch.
But then when importing the patch using:
git quilt-import
that line is totally ignored and the permissions are set to normal.
It's a long-running issue, and I think I'm about the only one that uses
git quilt-import outside of the debian build system, so it's low on my
list of things to fix up with that shell script (speed is my biggest
issue, it's just slow on large amounts of patches and needs to be
rewritten in C).
I'll go fix this up by hand...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 16:55 [PATCH 5.10 00/79] 5.10.151-rc1 review Greg Kroah-Hartman
2022-10-27 16:56 ` [PATCH 5.10 67/79] fcntl: make F_GETOWN(EX) return 0 on dead owner task Greg Kroah-Hartman
2022-10-27 18:10 ` [PATCH 5.10 00/79] 5.10.151-rc1 review Guenter Roeck
@ 2022-10-28 10:47 ` Sudip Mukherjee (Codethink)
2022-10-28 10:58 ` Greg Kroah-Hartman
2022-10-28 11:58 ` Jon Hunter
` (2 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Sudip Mukherjee (Codethink) @ 2022-10-28 10:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli, srw
Hi Greg,
On Thu, Oct 27, 2022 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.151 release.
> There are 79 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> Anything received after that time might be too late.
Build test (gcc version 11.3.1 20221016):
mips: 63 configs -> no failure
arm: 104 configs -> no failure
arm64: 3 configs -> 1 failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Note:
1) arm64 allmodconfig fails to build with the error:
In file included from drivers/cpufreq/tegra194-cpufreq.c:10:
drivers/cpufreq/tegra194-cpufreq.c:245:25: error: 'tegra194_cpufreq_of_match' undeclared here (not in a function); did you mean 'tegra194_cpufreq_data'?
245 | MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:241:15: note: in definition of macro 'MODULE_DEVICE_TABLE'
241 | extern typeof(name) __mod_##type##__##name##_device_table \
| ^~~~
./include/linux/module.h:241:21: error: conflicting types for '__mod_of__tegra194_cpufreq_of_match_device_table'; have 'const struct of_device_id[2]'
241 | extern typeof(name) __mod_##type##__##name##_device_table \
| ^~~~~~
drivers/cpufreq/tegra194-cpufreq.c:380:1: note: in expansion of macro 'MODULE_DEVICE_TABLE'
380 | MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
| ^~~~~~~~~~~~~~~~~~~
./include/linux/module.h:241:21: note: previous declaration of '__mod_of__tegra194_cpufreq_of_match_device_table' with type 'int'
241 | extern typeof(name) __mod_##type##__##name##_device_table \
| ^~~~~~
drivers/cpufreq/tegra194-cpufreq.c:245:1: note: in expansion of macro 'MODULE_DEVICE_TABLE'
245 | MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
| ^~~~~~~~~~~~~~~~~~~
git bisect pointed to a327a52c9930 ("cpufreq: tegra194: Fix module loading")
2) Already reported by others:
scripts/pahole-flags.sh: Permission denied
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/2047
[2]. https://openqa.qa.codethink.co.uk/tests/2053
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
--
Regards
Sudip
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-28 10:47 ` Sudip Mukherjee (Codethink)
@ 2022-10-28 10:58 ` Greg Kroah-Hartman
0 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-28 10:58 UTC (permalink / raw)
To: Sudip Mukherjee (Codethink)
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli, srw
On Fri, Oct 28, 2022 at 11:47:27AM +0100, Sudip Mukherjee (Codethink) wrote:
> Hi Greg,
>
> On Thu, Oct 27, 2022 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.151 release.
> > There are 79 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> > Anything received after that time might be too late.
>
> Build test (gcc version 11.3.1 20221016):
> mips: 63 configs -> no failure
> arm: 104 configs -> no failure
> arm64: 3 configs -> 1 failure
> x86_64: 4 configs -> no failure
> alpha allmodconfig -> no failure
> powerpc allmodconfig -> no failure
> riscv allmodconfig -> no failure
> s390 allmodconfig -> no failure
> xtensa allmodconfig -> no failure
>
> Note:
> 1) arm64 allmodconfig fails to build with the error:
> In file included from drivers/cpufreq/tegra194-cpufreq.c:10:
> drivers/cpufreq/tegra194-cpufreq.c:245:25: error: 'tegra194_cpufreq_of_match' undeclared here (not in a function); did you mean 'tegra194_cpufreq_data'?
> 245 | MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/module.h:241:15: note: in definition of macro 'MODULE_DEVICE_TABLE'
> 241 | extern typeof(name) __mod_##type##__##name##_device_table \
> | ^~~~
> ./include/linux/module.h:241:21: error: conflicting types for '__mod_of__tegra194_cpufreq_of_match_device_table'; have 'const struct of_device_id[2]'
> 241 | extern typeof(name) __mod_##type##__##name##_device_table \
> | ^~~~~~
> drivers/cpufreq/tegra194-cpufreq.c:380:1: note: in expansion of macro 'MODULE_DEVICE_TABLE'
> 380 | MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> | ^~~~~~~~~~~~~~~~~~~
> ./include/linux/module.h:241:21: note: previous declaration of '__mod_of__tegra194_cpufreq_of_match_device_table' with type 'int'
> 241 | extern typeof(name) __mod_##type##__##name##_device_table \
> | ^~~~~~
> drivers/cpufreq/tegra194-cpufreq.c:245:1: note: in expansion of macro 'MODULE_DEVICE_TABLE'
> 245 | MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> | ^~~~~~~~~~~~~~~~~~~
>
> git bisect pointed to a327a52c9930 ("cpufreq: tegra194: Fix module loading")
Now dropped.
> 2) Already reported by others:
> scripts/pahole-flags.sh: Permission denied
Will be fixed up by hand.
I'll be doing a new 5.10.y release in a few minutes and start a new
round of -rc review for it to resolve this...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 16:55 [PATCH 5.10 00/79] 5.10.151-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-10-28 10:47 ` Sudip Mukherjee (Codethink)
@ 2022-10-28 11:58 ` Jon Hunter
2022-10-28 12:21 ` Pavel Machek
2022-10-28 13:59 ` Naresh Kamboju
5 siblings, 0 replies; 14+ messages in thread
From: Jon Hunter @ 2022-10-28 11:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, linux-tegra
On Thu, 27 Oct 2022 18:55:10 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.151 release.
> There are 79 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.151-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
75 tests: 75 pass, 0 fail
Linux version: 5.10.151-rc1-gaa25703d0a7c
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 16:55 [PATCH 5.10 00/79] 5.10.151-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-10-28 11:58 ` Jon Hunter
@ 2022-10-28 12:21 ` Pavel Machek
2022-10-28 13:59 ` Naresh Kamboju
5 siblings, 0 replies; 14+ messages in thread
From: Pavel Machek @ 2022-10-28 12:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi!
> This is the start of the stable review cycle for the 5.10.151 release.
> There are 79 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 5.10 00/79] 5.10.151-rc1 review
2022-10-27 16:55 [PATCH 5.10 00/79] 5.10.151-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2022-10-28 12:21 ` Pavel Machek
@ 2022-10-28 13:59 ` Naresh Kamboju
5 siblings, 0 replies; 14+ messages in thread
From: Naresh Kamboju @ 2022-10-28 13:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw
On Thu, 27 Oct 2022 at 22:35, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.151 release.
> There are 79 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Oct 2022 16:50:35 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.151-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 5.10.151-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: aa25703d0a7c8d3158e3753b710a730892d32a13
* git describe: v5.10.150-80-gaa25703d0a7c
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.150-80-gaa25703d0a7c
## No Test Regressions (compared to v5.10.149-391-gb4f4370de958)
## No Metric Regressions (compared to v5.10.149-391-gb4f4370de958)
## No Test Fixes (compared to v5.10.149-391-gb4f4370de958)
## No Metric Fixes (compared to v5.10.149-391-gb4f4370de958)
## Test result summary
total: 132473, pass: 112534, fail: 2525, skip: 17013, xfail: 401
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 143 total, 142 passed, 1 failed
* arm64: 43 total, 41 passed, 2 failed
* i386: 35 total, 33 passed, 2 failed
* mips: 23 total, 23 passed, 0 failed
* parisc: 5 total, 5 passed, 0 failed
* powerpc: 25 total, 21 passed, 4 failed
* riscv: 10 total, 10 passed, 0 failed
* s390: 10 total, 10 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 36 total, 34 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 14+ messages in thread