Re: [regression 5.4.97 → 5.10.24]: raid6 avx2x4 speed drops from 18429 MB/s to 6155 MB/s

[Thomas Backlund]

Den 2021-04-02 kl. 17:05, skrev Borislav Petkov:
> On Fri, Apr 02, 2021 at 10:33:51AM +0200, Paul Menzel wrote:
>> Dear Linux folks,
>>
>>
>> On an two socket AMD EPYC 7601, we noticed a decrease in raid6 avx2x4 speed
>> shown at the beginning of the boot.
>>
>> 5.4.955.10.24
>> --
>> raid6: avx2x4 gen()   18429 MB/s 6155 MB/s
>> raid6: avx2x4 xor()6644 MB/s 4274 MB/s
>> raid6: avx2x2 gen()   17894 MB/s18744 MB/s
>> raid6: avx2x2 xor()   11642 MB/s11950 MB/s
>> raid6: avx2x1 gen()   13992 MB/s17112 MB/s
>> raid6: avx2x1 xor()   10855 MB/s11143 MB/s
>
> Looks like those two might help:
>

That would mean only this is missing:
> 49200d17d27d x86/fpu/64: Don't FNINIT in kernel_fpu_begin()


as this one landed in 5.10.11:
> e45122893a98 x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize 
> state
>

--
Thomas

Re: linux-5.10.11 build failure

[Thomas Backlund]

Den 28.1.2021 kl. 12:05, skrev Chris Clayton:
> 
> On 28/01/2021 09:34, Greg Kroah-Hartman wrote:
>> On Thu, Jan 28, 2021 at 09:17:10AM +, Chris Clayton wrote:
>>> Hi,
>>>
>>> Building 5.10.11 fails on my (x86-64) laptop thusly:
>>>
>>> ..
>>>
>>>   AS  arch/x86/entry/thunk_64.o
>>>CC  arch/x86/entry/vsyscall/vsyscall_64.o
>>>AS  arch/x86/realmode/rm/header.o
>>>CC  arch/x86/mm/pat/set_memory.o
>>>CC  arch/x86/events/amd/core.o
>>>CC  arch/x86/kernel/fpu/init.o
>>>CC  arch/x86/entry/vdso/vma.o
>>>CC  kernel/sched/core.o
>>> arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at 
>>> offset 0x3e
>>>
>>>AS  arch/x86/realmode/rm/trampoline_64.o
>>> make[2]: *** [scripts/Makefile.build:360: arch/x86/entry/thunk_64.o] Error 
>>> 255
>>> make[2]: *** Deleting file 'arch/x86/entry/thunk_64.o'
>>> make[2]: *** Waiting for unfinished jobs
>>>
>>> ..
>>>
>>> Compiler is latest snapshot of gcc-10.
>>>
>>> Happy to test the fix but please cc me as I'm not subscribed
>>
>> Can you do 'git bisect' to track down the offending commit?
>>
> 
> Sure, but I'll hold that request for a while. I updated to binutils-2.36 on 
> Monday and I'm pretty sure that is a feature
> of this build fail. I've reverted binutils to 2.35.1, and the build succeeds. 
> Updated to 2.36 again and, surprise,
> surprise, the kernel build fails again.
> 
> I've had a glance at the binutils ML and there are all sorts of issues being 
> reported, but it's beyond my knowledge to
> assess if this build error is related to any of them.
> 
> I'll stick with binutils-2.35.1 for the time being.
> 
>> And what exact gcc version are you using?
>>
> 
>   It's built from the 10-20210123 snapshot tarball.
> 
> I can report this to the binutils folks, but might it be better if the 
> objtool maintainer looks at it first? The
> binutils change might just have opened the gate to a bug in objtool.
> 
>> thanks,
>>
>> greg k-h
>>
> 


AFAIK you need this in stable trees:

 From 1d489151e9f9d1647110277ff77282fe4d96d09b Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf 
Date: Thu, 14 Jan 2021 16:14:01 -0600
Subject: [PATCH] objtool: Don't fail on missing symbol table


--
Thomas

Re: [PATCH] hwmon: corsair-psu: update supported devices

[Thomas Backlund]

Den 01.12.2020 kl. 09:24, skrev Wilken Gottwalt:


Thank you. Hmm yeah, this dongle has no usb hid part. So this driver will not
work with this dongle for sure. I already have an idea how to support all 3
series, though it involves a lot of testing. I would provide a github repo
with tools and test kernel modules if you are interested. But I don't know
yet how long it will take, I work on other stuff which has a higher prio.



Yes, I'm interested...

Just drop me a note when you have something to test.


--

Thomas

Re: [PATCH] hwmon: corsair-psu: update supported devices

[Thomas Backlund]

Den 28.11.2020 kl. 12:35, skrev Wilken Gottwalt:

On Sat, 28 Nov 2020 02:37:38 -0300
Jonas Malaco  wrote:


On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt
 wrote:


Adds support for another Corsair PSUs series: AX760i, AX860i, AX1200i,
AX1500i and AX1600i. The first 3 power supplies are supported through
the Corsair Link USB Dongle which is some kind of USB/Serial/TTL
converter especially made for the COM ports of these power supplies.
There are 3 known revisions of these adapters. The AX1500i power supply
has revision 3 built into the case and AX1600i is the only one in that
series, which has an unique usb hid id like the RM/RX series.


Can I ask what AXi power supplies were tested?

I ask because, based on the user-space implementations I am aware of,
the AXi dongle protocol appears to be different from the RMi/HXi series.


I was not able to test this against the AX power supplies, they are really
hard to find (and are far to expensive). But I went through all these tools
and stuck to the most common commands, which all 3 series support. Not every
series supports all commands (there also seem to be different firmwares in
the micro-conrollers). But this is fine, some sensors will show up as N/A.
Even my HX850i does not support all commands covered in this driver.



What kind of tests do you want / need ?

I have an AX860i here.

--
Regards

Thomas Backlund

Re: perf build error with gcc 10 on arm and aarch64

[Thomas Backlund]

Den 05-05-2020 kl. 07:10, skrev Leo Yan:


Hi Thomas,

[ + Mathieu/Mike/Suzuki ]

On Mon, May 04, 2020 at 10:22:27PM +0300, Thomas Backlund wrote:

This is building perf from kernel-5.6.10 on armv7hl and aarch64:

Compiler is gcc 10.1.0-RC


   LD   perf-in.o
ld: arch/perf-in.o: in function `.LANCHOR0':
/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118:
multiple definition of `traceid_list'; 
util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/cs-etm.h:118:
first defined here
make[3]: *** 
[/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/build/Makefile.build:145:
perf-in.o] Error 1

   LD   perf-in.o
ld: 
arch/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118:
multiple definition of `traceid_list'; 
util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/cs-etm.h:118:
first defined here
make[3]: *** 
[/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/build/Makefile.build:145:
perf-in.o] Error 1
make[2]: *** [Makefile.perf:616: perf-in.o] Error 2
make[1]: *** [Makefile.perf:225: sub-make] Error 2
make: *** [Makefile:70: all] Error 2


The same build succeeds with gcc 9.3.0


Thanks for reporting the issue.

Could you help confirm if below change can resolve this issue?


Yes,

fix confirmed on i586, x86_64, armv7hl and aarch64 builds

so I guess you can add:

Reported-by: Thomas Backlund 
Tested-by: Thomas Backlund 





Thanks,
Leo

---8<---

Subject: [PATCH] perf cs-etm: Move defined of traceid_list

The variable 'traceid_list' is defined in the header file cs-etm.h,
if multiple C files include cs-etm.h the compiler might complaint for
multiple definition of 'traceid_list'.

To fix multiple definition error, move the definition of 'traceid_list'
into cs-etm.c.

Signed-off-by: Leo Yan 
---
  tools/perf/util/cs-etm.c | 3 +++
  tools/perf/util/cs-etm.h | 3 ---
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 62d2f9b9ce1b..381d9708e9bd 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -94,6 +94,9 @@ struct cs_etm_queue {
struct cs_etm_traceid_queue **traceid_queues;
  };

+/* RB tree for quick conversion between traceID and metadata pointers */
+static struct intlist *traceid_list;
+
  static int cs_etm__update_queues(struct cs_etm_auxtrace *etm);
  static int cs_etm__process_queues(struct cs_etm_auxtrace *etm);
  static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm,
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 650ecc2a6349..4ad925d6d799 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -114,9 +114,6 @@ enum cs_etm_isa {
CS_ETM_ISA_T32,
  };

-/* RB tree for quick conversion between traceID and metadata pointers */
-struct intlist *traceid_list;
-
  struct cs_etm_queue;

  struct cs_etm_packet {
--
2.17.1

perf build error with gcc 10 on arm and aarch64

[Thomas Backlund]

This is building perf from kernel-5.6.10 on armv7hl and aarch64:

Compiler is gcc 10.1.0-RC


  LD   perf-in.o
ld: arch/perf-in.o: in function `.LANCHOR0':
/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118: 
multiple definition of `traceid_list'; 
util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/cs-etm.h:118: 
first defined here
make[3]: *** 
[/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/build/Makefile.build:145: 
perf-in.o] Error 1


  LD   perf-in.o
ld: 
arch/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118: 
multiple definition of `traceid_list'; 
util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/cs-etm.h:118: 
first defined here
make[3]: *** 
[/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/build/Makefile.build:145: 
perf-in.o] Error 1

make[2]: *** [Makefile.perf:616: perf-in.o] Error 2
make[1]: *** [Makefile.perf:225: sub-make] Error 2
make: *** [Makefile:70: all] Error 2


The same build succeeds with gcc 9.3.0

--


Thomas

Re: [PATCH 5.2 36/37] vhost: block speculation of translated descriptors

[Thomas Backlund]

Den 14-09-2019 kl. 11:08, skrev Greg Kroah-Hartman:

On Sat, Sep 14, 2019 at 09:15:48AM +0200, Stefan Lippers-Hollmann wrote:

Hi

On 2019-09-14, Greg Kroah-Hartman wrote:

On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote:

On 2019-09-13, Greg Kroah-Hartman wrote:

From: Michael S. Tsirkin 

commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream.

iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.

Userspace address are later validated with array_index_nospec so we can
be sure kernel info does not leak through these addresses, but vhost
must also not leak userspace info outside the allowed memory table to
guests.

Following the defence in depth principle, make sure
the address is not validated out of node range.

[...]

Do you have the same problem with Linus's tree right now?


Actually, yes I do (I had not tested i386 for 5.3~ within the last ~2
weeks, only amd64). Very similar kernel config, same compiler versions
but built in a slightly different environment (built directly on the bare
iron, in a amd64 multilib userspace, rather than a pure-i386 chroot on an
amd64 kernel).

$ git describe
v5.3-rc8-36-ga7f89616b737

$ LANG= make ARCH=x86 -j1 bzImage modules
   CALLscripts/checksyscalls.sh
   CALLscripts/atomic/check-atomics.sh
   CHK include/generated/compile.h
   CHK kernel/kheaders_data.tar.xz
   CC [M]  drivers/vhost/vhost.o
In file included from ./include/linux/export.h:45,
  from ./include/linux/linkage.h:7,
  from ./include/linux/kernel.h:8,
  from ./include/linux/list.h:9,
  from ./include/linux/wait.h:7,
  from ./include/linux/eventfd.h:13,
  from drivers/vhost/vhost.c:13:
drivers/vhost/vhost.c: In function 'translate_desc':
./include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2076' 
declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
   350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
   |  ^
./include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
   331 |prefix ## suffix();\
   |^~
./include/linux/compiler.h:350:2: note: in expansion of macro 
'_compiletime_assert'
   350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
   |  ^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
   | ^~
./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
   |  ^~~~
./include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON'
56 |  BUILD_BUG_ON(sizeof(_s) > sizeof(long));   \
   |  ^~~~
drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
  2076 | array_index_nospec((unsigned long)(addr - node->start),
   | ^~
make[2]: *** [scripts/Makefile.build:281: drivers/vhost/vhost.o] Error 1
make[1]: *** [scripts/Makefile.build:497: drivers/vhost] Error 2
make: *** [Makefile:1083: drivers] Error 2

$ git revert a89db445fbd7f1f8457b03759aa7343fa530ef6b

$ LANG= make ARCH=x86 -j16 bzImage modules
   CALLscripts/atomic/check-atomics.sh
   CALLscripts/checksyscalls.sh
   CHK include/generated/compile.h
   CHK kernel/kheaders_data.tar.xz
   Building modules, stage 2.
Kernel: arch/x86/boot/bzImage is ready  (#1)
   MODPOST 3464 modules

$ echo $?
0

$ find . -name vhost\\.ko
./drivers/vhost/vhost.ko

I've attached the affected kernel config for v5.3~/ i386.


Ok, good, we will be "bug compatible" at the very least now :)

When this gets fixed in Linus's tree we can backport the fix here as
well.  The number of users of that compiler version/configuration is
probably pretty low at the moment to want to hold off on this fix.



This is now reverted upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d4a3f2abbef73b9e5bb5f12213c275565473588

--
Thomas

Re: [PATCH] Partially revert "mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones"

[Thomas Backlund]

Den 24-08-2019 kl. 22:57, skrev Andrew Morton:

On Sat, 17 Aug 2019 19:15:23 + Roman Gushchin  wrote:


Fixes: 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync with the 
hierarchical ones")
Signed-off-by: Roman Gushchin 
Cc: Yafang Shao 
Cc: Johannes Weiner 
---
  mm/memcontrol.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)




This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
 https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.


Oh, I'm sorry, will read and follow next time. Thanks!


766a4c19d880 is not present in 5.2 so no -stable backport is needed, yes?



Unfortunately it got added in 5.2.7, so backport is needed.

--
Thomas

Re: Regression with the latest iwlwifi-9260-*-46.ucode

[Thomas Backlund]

Den 06-08-2019 kl. 16:04, skrev Takashi Iwai:

On Mon, 05 Aug 2019 14:03:55 +0200,



Now we got a feedback from the latest linux-firmware (20190726) and
surprising the result was negative.  The dmesg after the cold boot is
found at:
   https://bugzilla.suse.com/show_bug.cgi?id=1142128#c26

The kernel is 5.2.3, so it should be new enough.

If anything else needed (or something missing), let us know.



I read on some forum that some commented that the "Add support for SAR 
South Korea limitation" fix is needed, but it seemed weird...


Anyway, with theese on top of 5.2.7

39bd984c203e86f3  iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version 
< 41
f5a47fae6aa3eb06  iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT 
support

0c3d7282233c7b02  iwlwifi: Add support for SAR South Korea limitation


We have confirmation from an affected user that its now stable with both 
older and newer firmwares...


And we earlier tried with only the:
39bd984c203e86f3  iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version 
< 41


But that did not help (not that I really expected it since its loading 
version 46 firmwares anyway)


So my guess is that the newer firmware actually subtly expects to get 
the behaviour of the:

0c3d7282233c7b02  iwlwifi: Add support for SAR South Korea limitation



Of course that's still guessing and I assume only Intel fw guys can 
verify that...


--
Thomas

Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n

[Thomas Backlund]

Den 13-06-2019 kl. 10:42, skrev Greg Kroah-Hartman:


I've just reverted it now.

If someone can send me a patch series of all of what needs to be
applied, in a format that I can actually apply them in, I will be glad
to do so.  But for now, I'd like to get people's systems building again.




That would be basically re-adding the b30a43ac7132 commit and adding the 
following patch (also attached in case the inlined version gets mangled):


From 0d91b155a7f9c1f4a2b360bc2b79dc728aee8b48 Mon Sep 17 00:00:00 2001
From: Thomas Backlund 
Date: Sat, 15 Jun 2019 12:22:44 +0300
Subject: [PATCH] nouveau: Fix build with 
CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled


Not-entirely-upstream-sha1-but-equivalent: bed2dd8421
("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")

Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132)
causes the build to fail with:

ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!

This does not happend upstream as the offending code got removed in:
bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")

Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
the drm_legacy_mmap() call.

Also, as Sven Joachim pointed out, we need to make the check in
CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done
for basically all other gpu drivers, especially in upstream kernels
drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421.

NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is
backported as the build error affects nouveau only.

Fixes: b30a43ac7132 ("drm/nouveau: add kconfig option to turn off nouveau
   legacy contexts. (v3)")
Signed-off-by: Thomas Backlund 
Cc: sta...@vger.kernel.org
Cc: Daniel Vetter 
Cc: Sven Joachim 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c

index 1543c2f8d3d3..05d513d54555 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct 
vm_area_struct *vma)

struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);

if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
return drm_legacy_mmap(filp, vma);
+#else
+   return -EINVAL;
+#endif

return ttm_bo_mmap(filp, vma, >ttm.bdev);
 }
--
2.21.0
>From 0d91b155a7f9c1f4a2b360bc2b79dc728aee8b48 Mon Sep 17 00:00:00 2001
From: Thomas Backlund 
Date: Sat, 15 Jun 2019 12:22:44 +0300
Subject: [PATCH] nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled

Not-entirely-upstream-sha1-but-equivalent: bed2dd8421
("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")

Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132)
causes the build to fail with:

ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!

This does not happend upstream as the offending code got removed in:
bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")

Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
the drm_legacy_mmap() call.

Also, as Sven Joachim pointed out, we need to make the check in
CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done
for basically all other gpu drivers, especially in upstream kernels
drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421.

NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is
backported as the build error affects nouveau only.

Fixes: b30a43ac7132 ("drm/nouveau: add kconfig option to turn off nouveau
   legacy contexts. (v3)")
Signed-off-by: Thomas Backlund 
Cc: sta...@vger.kernel.org
Cc: Daniel Vetter 
Cc: Sven Joachim 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3..05d513d54555 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct *vma)
 	struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);
 
 	if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
 		return drm_legacy_mmap(filp, vma);
+#else
+		return -EINVAL;
+#endif
 
 	return ttm_bo_mmap(filp, vma, >ttm.bdev);
 }
-- 
2.21.0

Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set

[Thomas Backlund]

Den 15-06-2019 kl. 08:50, skrev Greg KH:

On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote:

Hey Everyone

On 4/24/19 10:41 AM, Benjamin Tissoires wrote:

For a patch to be picked up by stable, it first needs to go in Linus'
tree. Currently we are working on 5.1, so any stable patches need to
go in 5.1 first. Then, once they hit Linus' tree, the stable team will
pick them and backport them in the appropriate stable tree.


Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from 
the kernel.

Is there anything that we can do about this?


What is the git commit id of the patch in Linus's tree?

As I said before, it can not be backported until it shows up there
first.



That would be:
d43c17ead879ba7c076dc2f5fd80cd76047c9ff4

and

39b3c3a5fbc5d744114e497d35bf0c12f798c134

--
Thomas

Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n

[Thomas Backlund]

Den 11-06-2019 kl. 22:43, skrev Sven Joachim:

On 2019-06-11 22:08 +0300, Thomas Backlund wrote:


Den 11-06-2019 kl. 20:40, skrev Greg Kroah-Hartman:

On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote:

On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
 wrote:

On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote:

Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
legacy contexts. (v3)") has caused a build failure for me when I
actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):

,
| Kernel: arch/x86/boot/bzImage is ready  (#1)
|   Building modules, stage 2.
|   MODPOST 290 modules
| ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
| scripts/Makefile.modpost:91: recipe for target '__modpost' failed
`

Calling drm_legacy_mmap is definitely not a great idea. I think either
we need a custom patch to remove that out on older kernels, or maybe
even #ifdef if you want to be super paranoid about breaking stuff ...


Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
apply in 5.1.9.

Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested
them yet.

They probably are.

Should I just revert this patch in the stable tree, or add some other
patch (like the one pointed out here, which seems an odd patch for
stable...)

... or backport the above patch, that should be save to do too. Not
sure what stable folks prefer?

The above patch does not apply to all of the stable branches, so how
about I just revert this?  People can live with this option not able to
turn off for now, and if they really want it, they can use a newer
kernel, right?


Or add the simple fix suggested by Daniel (if I understand correctly):


From: Thomas Backlund 

Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit:
b30a43ac7132) causes the build to fail with:

ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!

Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
the code using drm_legacy_mmap()

Fixes: b30a43ac7132 drm/nouveau: add kconfig option to turn off
nouveau legacy contexts. (v3)
Signed-off-by: Thomas Backlund 

---
  drivers/gpu/drm/nouveau/nouveau_ttm.c |2 ++
  1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -168,8 +168,10 @@ nouveau_ttm_mmap(struct file *filp, stru
struct drm_file *file_priv = filp->private_data;
struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);

+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return drm_legacy_mmap(filp, vma);
+#endif

return ttm_bo_mmap(filp, vma, >ttm.bdev);
  }

That's not quite correct, I am afraid.  If
CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not defined, you still need to do
the test, but return -EINVAL.  Something along these lines:

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3..05d513d54555 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct 
*vma)
struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);

if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
return drm_legacy_mmap(filp, vma);
+#else
+   return -EINVAL;
+#endif

return ttm_bo_mmap(filp, vma, >ttm.bdev);
  }


At least that builds for me, need to reboot to check whether it works.

Cheers,
Sven



Ah, indeed. thats what basically all other drivers did before bed2dd8421 
("drm/ttm:
Quick-test mmap offset in ttm_bo_mmap()"), and in that commit the same 
check

was moved to drivers/gpu/drm/ttm/ttm_bo_vm.c


--

Thomas

Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n

[Thomas Backlund]

Den 11-06-2019 kl. 20:40, skrev Greg Kroah-Hartman:

On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote:

On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
 wrote:

On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote:

Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
legacy contexts. (v3)") has caused a build failure for me when I
actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):

,
| Kernel: arch/x86/boot/bzImage is ready  (#1)
|   Building modules, stage 2.
|   MODPOST 290 modules
| ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
| scripts/Makefile.modpost:91: recipe for target '__modpost' failed
`


Calling drm_legacy_mmap is definitely not a great idea. I think either
we need a custom patch to remove that out on older kernels, or maybe
even #ifdef if you want to be super paranoid about breaking stuff ...


Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
apply in 5.1.9.

Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested
them yet.


They probably are.

Should I just revert this patch in the stable tree, or add some other
patch (like the one pointed out here, which seems an odd patch for
stable...)


... or backport the above patch, that should be save to do too. Not
sure what stable folks prefer?


The above patch does not apply to all of the stable branches, so how
about I just revert this?  People can live with this option not able to
turn off for now, and if they really want it, they can use a newer
kernel, right?



Or add the simple fix suggested by Daniel (if I understand correctly):


From: Thomas Backlund 

Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: 
b30a43ac7132) causes the build to fail with:


ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!

Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
the code using drm_legacy_mmap()

Fixes: b30a43ac7132 drm/nouveau: add kconfig option to turn off nouveau 
legacy contexts. (v3)

Signed-off-by: Thomas Backlund 

---
 drivers/gpu/drm/nouveau/nouveau_ttm.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -168,8 +168,10 @@ nouveau_ttm_mmap(struct file *filp, stru
struct drm_file *file_priv = filp->private_data;
struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);

+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return drm_legacy_mmap(filp, vma);
+#endif

return ttm_bo_mmap(filp, vma, >ttm.bdev);
 }

Re: [PATCH 5.1 56/85] doc: Cope with the deprecation of AutoReporter

[Thomas Backlund]

Den 10-06-2019 kl. 17:05, skrev Greg Kroah-Hartman:

On Mon, Jun 10, 2019 at 06:33:40AM -0600, Jonathan Corbet wrote:

On Mon, 10 Jun 2019 09:48:40 +0200
Greg Kroah-Hartman  wrote:


Hm, 2.1 here:
Running Sphinx v2.1.0
perhaps Tumbleweed needs to update?  :)


Heh...trying 2.1 is still on my list of things to do ... :)


Anyway, this should not be breaking, if Jon doesn't have any ideas, I'll
just drop these changes.


The fix for that is 551bd3368a7b (drm/i915: Maintain consistent
documentation subsection ordering) which was also marked for stable.  Jiri,
do you somehow not have that one?


It's part of this series, which is probably why it works for me.  Don't
know why it doesn't work for Jiri, unless he is cherry-picking things?



Actualliy it is not.

This patch Jiri responded to / points out to break stuff is part of 
5.1.8, but the fix in in review queue for 5.1.9 :


https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.1/drm-i915-maintain-consistent-documentation-subsection-ordering.patch?id=29167bff7a1c0d79dda104c44c262b0bc4cd6644

--
Thomas

Re: perf build broken in 5.1-rc7

[Thomas Backlund]

Den 01-05-2019 kl. 20:31, skrev Arnaldo Carvalho de Melo:

Em Wed, May 01, 2019 at 05:09:59PM +0300, Thomas Backlund escreveu:

Den 01-05-2019 kl. 16:07, skrev Arnaldo Carvalho de Melo:

Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu:
Can you check the output for
/tmp/build/perf/feature/test-disassembler-four-args.make.output in your
system? And also check what is the prototype for the disassembler()
routine on mageia7?

I guess this is what fails the test:
  

cat /tmp/build/perf/feature/test-disassembler-four-args.make.output
/usr/bin/ld: /usr/lib64/libbfd.a(plugin.o): in function `try_load_plugin':
/home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:243:
undefined reference to `dlopen'
/usr/bin/ld:
/home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:271:
undefined reference to `dlsym'
/usr/bin/ld:
/home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:256:
undefined reference to `dlclose'
/usr/bin/ld:
/home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:246:
undefined reference to `dlerror'
  

as we allow dynamic linking and loading
  

And we use linker flags:
  

rpm --eval %ldflags
  -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id
-Wl,--enable-new-dtags

Would this help?

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index fe3f97e342fa..6d65874e16c3 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -227,7 +227,7 @@ FEATURE_CHECK_LDFLAGS-libpython-version := 
$(PYTHON_EMBED_LDOPTS)
  
  EATURE_CHECK_LDFLAGS-libaio = -lrt
  
-FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes

+FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes -ldl
  
  CFLAGS += -fno-omit-frame-pointer

  CFLAGS += -ggdb3



Yeah, that fixes it

and /tmp/build/perf/feature/test-disassembler-four-args.make.output is now 
empty as wanted.


So I guess:

Reported-by: Thomas Backlund 

Tested-by: Thomas Backlund 



Thanks!


--

Thomas

Re: perf build broken in 5.1-rc7

[Thomas Backlund]

Den 01-05-2019 kl. 17:09, skrev Thomas Backlund:


Den 01-05-2019 kl. 16:07, skrev Arnaldo Carvalho de Melo:

Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu:

Den 30-04-2019 kl. 16:06, skrev Song Liu:
On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund  
wrote:

Den 30-04-2019 kl. 10:26, skrev Thomas Backlund:

Building perf in 5.1-rc5/6/7 fails:
Build start:
    make -s -C tools/perf NO_PERF_READ_VDSO32=1 
NO_PERF_READ_VDSOX32=1

WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1
NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all
 BUILD:   Doing 'make -j32' parallel build
 HOSTCC   fixdep.o
 HOSTLD   fixdep-in.o
 LINK fixdep
Warning: Kernel ABI header at 
'tools/arch/x86/include/uapi/asm/vmx.h'

differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h
arch/x86/include/uapi/asm/vmx.h

Auto-detecting system features:
... dwarf: [ on  ]
...    dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...    libbfd: [ on  ]
...    libelf: [ on  ]
...   libnuma: [ on  ]
...    numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...    libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
...    libaio: [ on  ]
...    disassembler-four-args: [ OFF ]

Makefile.config:473: No sys/sdt.h found, no SDT events are defined,
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' 
CTF
format support, please install 
libbabeltrace-dev[el]/libbabeltrace-ctf-dev



And breaks with:


CC   ui/setup.o
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of
'disassembler'
 disassemble = disassembler(bfdf);
    ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum 
bfd_architecture'

but argument is of type 'bfd *' {aka 'struct bfd *'}
    extern disassembler_ftype disassembler (enum bfd_architecture 
arc,

~~^~~
util/annotate.c:1767:16: error: too few arguments to function
'disassembler'
 disassemble = disassembler(bfdf);
   ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:27: note: declared here
    extern disassembler_ftype disassembler (enum bfd_architecture 
arc,

  ^~~~
 CC   arch/x86/util/header.o
 CC   arch/x86/util/tsc.o
 CC   arch/x86/util/pmu.o
mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
 CC   bench/futex-requeue.o
 CC   arch/x86/util/kvm-stat.o
make[4]: ***
[/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: 


util/annotate.o] Error 1
make[4]: *** Waiting for unfinished jobs
 CC   util/build-id.o




And I forgot...

Reverting:
   From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 
00:00:00 2001

From: Song Liu 
Date: Mon, 11 Mar 2019 22:30:48 -0700
Subject: perf annotate: Enable annotation of BPF programs

Makes it build again.

--
Thomas


Hi Thomas,

Which system are you running this test on? I would like to repro it 
in a VM.


Thanks,
Song


Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month.


Basesystem is:

binutils-2.32-5.mga7
(includes all fixes from upstream binutils-2_32-branch)

gcc-8.3.1-0.20190419.2.mga7

glibc-2.29-7.mga7
(includes all fixes from upstream glibc release/2.29/master branch 
up to

2019-04-15 for now)


kernel-desktop-5.1.0-0.rc7.1.mga7
kernel-userspace-headers-5.1.0-0.rc7.1.mga7

Ok, so the steps are:

1) the feature test, the small C program that we try to build is:

[acme@quaco perf]$ cat tools/build/feature/test-disassembler-four-args.c
// SPDX-License-Identifier: GPL-2.0
#include 
#include 

int main(void)
{
bfd *abfd = bfd_openr(NULL, NULL);

disassembler(bfd_get_arch(abfd),
 bfd_big_endian(abfd),
 bfd_get_mach(abfd),
 abfd);

return 0;
}
[acme@quaco perf]$

And here in my fedora29 system it ends up producing the following file,
when built with:

$ make O=/tmp/build/perf  -C tools/perf install-bin

[acme@quaco perf]$ cat 
/tmp/build/perf/feature/test-disassembler-four-args.make.output

[acme@quaco perf]$
[acme@quaco perf]$ file 
/tmp/build/perf/feature/test-disassembler-four-args.bin
/tmp/build/perf/feature/test

Re: perf build broken in 5.1-rc7

[Thomas Backlund]

Den 01-05-2019 kl. 16:07, skrev Arnaldo Carvalho de Melo:

Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu:

Den 30-04-2019 kl. 16:06, skrev Song Liu:

On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund  wrote:

Den 30-04-2019 kl. 10:26, skrev Thomas Backlund:

Building perf in 5.1-rc5/6/7 fails:
Build start:
make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1
NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all
 BUILD:   Doing 'make -j32' parallel build
 HOSTCC   fixdep.o
 HOSTLD   fixdep-in.o
 LINK fixdep
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h'
differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h
arch/x86/include/uapi/asm/vmx.h

Auto-detecting system features:
... dwarf: [ on  ]
...dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...libbfd: [ on  ]
...libelf: [ on  ]
...   libnuma: [ on  ]
...numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
...libaio: [ on  ]
...disassembler-four-args: [ OFF ]

Makefile.config:473: No sys/sdt.h found, no SDT events are defined,
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF
format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev


And breaks with:


CC   ui/setup.o
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of
'disassembler'
 disassemble = disassembler(bfdf);
^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture'
but argument is of type 'bfd *' {aka 'struct bfd *'}
extern disassembler_ftype disassembler (enum bfd_architecture arc,
~~^~~
util/annotate.c:1767:16: error: too few arguments to function
'disassembler'
 disassemble = disassembler(bfdf);
   ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:27: note: declared here
extern disassembler_ftype disassembler (enum bfd_architecture arc,
  ^~~~
 CC   arch/x86/util/header.o
 CC   arch/x86/util/tsc.o
 CC   arch/x86/util/pmu.o
mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
 CC   bench/futex-requeue.o
 CC   arch/x86/util/kvm-stat.o
make[4]: ***
[/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97:
util/annotate.o] Error 1
make[4]: *** Waiting for unfinished jobs
 CC   util/build-id.o




And I forgot...

Reverting:
   From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001
From: Song Liu 
Date: Mon, 11 Mar 2019 22:30:48 -0700
Subject: perf annotate: Enable annotation of BPF programs

Makes it build again.

--
Thomas


Hi Thomas,

Which system are you running this test on? I would like to repro it in a VM.

Thanks,
Song


Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month.


Basesystem is:

binutils-2.32-5.mga7
(includes all fixes from upstream binutils-2_32-branch)

gcc-8.3.1-0.20190419.2.mga7

glibc-2.29-7.mga7
(includes all fixes from upstream glibc release/2.29/master branch up to
2019-04-15 for now)


kernel-desktop-5.1.0-0.rc7.1.mga7
kernel-userspace-headers-5.1.0-0.rc7.1.mga7

Ok, so the steps are:

1) the feature test, the small C program that we try to build is:

[acme@quaco perf]$ cat tools/build/feature/test-disassembler-four-args.c
// SPDX-License-Identifier: GPL-2.0
#include 
#include 

int main(void)
{
bfd *abfd = bfd_openr(NULL, NULL);

disassembler(bfd_get_arch(abfd),
 bfd_big_endian(abfd),
 bfd_get_mach(abfd),
 abfd);

return 0;
}
[acme@quaco perf]$

And here in my fedora29 system it ends up producing the following file,
when built with:

$ make O=/tmp/build/perf  -C tools/perf install-bin

[acme@quaco perf]$ cat 
/tmp/build/perf/feature/test-disassembler-four-args.make.output
[acme@quaco perf]$
[acme@quaco perf]$ file /tmp/build/perf/feature/test-disassembler-four-args.bin
/tmp/build/perf/feature/test

Re: perf build broken in 5.1-rc7

[Thomas Backlund]

Den 01-05-2019 kl. 06:37, skrev Song Liu:

On Tue, Apr 30, 2019 at 6:31 AM Thomas Backlund  wrote:


Den 30-04-2019 kl. 16:06, skrev Song Liu:

On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund  wrote:

Den 30-04-2019 kl. 10:26, skrev Thomas Backlund:

Building perf in 5.1-rc5/6/7 fails:


Build start:


make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1
NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all
 BUILD:   Doing 'make -j32' parallel build
 HOSTCC   fixdep.o
 HOSTLD   fixdep-in.o
 LINK fixdep
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h'
differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h
arch/x86/include/uapi/asm/vmx.h

Auto-detecting system features:
... dwarf: [ on  ]
...dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...libbfd: [ on  ]
...libelf: [ on  ]
...   libnuma: [ on  ]
...numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
...libaio: [ on  ]
...disassembler-four-args: [ OFF ]

Makefile.config:473: No sys/sdt.h found, no SDT events are defined,
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF
format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev


And breaks with:


CC   ui/setup.o
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of
'disassembler'
 disassemble = disassembler(bfdf);
^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture'
but argument is of type 'bfd *' {aka 'struct bfd *'}
extern disassembler_ftype disassembler (enum bfd_architecture arc,
~~^~~
util/annotate.c:1767:16: error: too few arguments to function
'disassembler'
 disassemble = disassembler(bfdf);
   ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:27: note: declared here
extern disassembler_ftype disassembler (enum bfd_architecture arc,
  ^~~~
 CC   arch/x86/util/header.o
 CC   arch/x86/util/tsc.o
 CC   arch/x86/util/pmu.o
mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
 CC   bench/futex-requeue.o
 CC   arch/x86/util/kvm-stat.o
make[4]: ***
[/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97:
util/annotate.o] Error 1
make[4]: *** Waiting for unfinished jobs
 CC   util/build-id.o




And I forgot...

Reverting:
   From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001
From: Song Liu 
Date: Mon, 11 Mar 2019 22:30:48 -0700
Subject: perf annotate: Enable annotation of BPF programs

Makes it build again.

--
Thomas


Hi Thomas,

Which system are you running this test on? I would like to repro it in a VM.

Thanks,
Song


Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month.


Basesystem is:

binutils-2.32-5.mga7
(includes all fixes from upstream binutils-2_32-branch)

gcc-8.3.1-0.20190419.2.mga7

glibc-2.29-7.mga7
(includes all fixes from upstream glibc release/2.29/master branch up to
2019-04-15 for now)


kernel-desktop-5.1.0-0.rc7.1.mga7
kernel-userspace-headers-5.1.0-0.rc7.1.mga7


--

Thomas



I am trying to install Mageia 7 beta 3, but hit some issue. While I try fix it,
could you please try clean everything under tools/ and retry:

   make -C tools/ clean
   make -C tools/perf -j



Still fails:

util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of 
'disassembler'

  disassemble = disassembler(bfdf);
 ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' 
but argument is of type 'bfd *' {aka 'struct bfd *'}

 extern disassembler_ftype disassembler (enum bfd_architecture arc,
 ~~^~~
util/annotate.c:1767:16: error: too few arguments to function 'disassembler'
  disassemble = disassembler(bfdf

Re: perf build broken in 5.1-rc7

[Thomas Backlund]

Den 30-04-2019 kl. 16:06, skrev Song Liu:

On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund  wrote:

Den 30-04-2019 kl. 10:26, skrev Thomas Backlund:

Building perf in 5.1-rc5/6/7 fails:


Build start:


   make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1
NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all
BUILD:   Doing 'make -j32' parallel build
HOSTCC   fixdep.o
HOSTLD   fixdep-in.o
LINK fixdep
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h'
differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h
arch/x86/include/uapi/asm/vmx.h

Auto-detecting system features:
... dwarf: [ on  ]
...dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...libbfd: [ on  ]
...libelf: [ on  ]
...   libnuma: [ on  ]
...numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
...libaio: [ on  ]
...disassembler-four-args: [ OFF ]

Makefile.config:473: No sys/sdt.h found, no SDT events are defined,
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF
format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev


And breaks with:


CC   ui/setup.o
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of
'disassembler'
disassemble = disassembler(bfdf);
   ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture'
but argument is of type 'bfd *' {aka 'struct bfd *'}
   extern disassembler_ftype disassembler (enum bfd_architecture arc,
   ~~^~~
util/annotate.c:1767:16: error: too few arguments to function
'disassembler'
disassemble = disassembler(bfdf);
  ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:27: note: declared here
   extern disassembler_ftype disassembler (enum bfd_architecture arc,
 ^~~~
CC   arch/x86/util/header.o
CC   arch/x86/util/tsc.o
CC   arch/x86/util/pmu.o
mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
CC   bench/futex-requeue.o
CC   arch/x86/util/kvm-stat.o
make[4]: ***
[/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97:
util/annotate.o] Error 1
make[4]: *** Waiting for unfinished jobs
CC   util/build-id.o





And I forgot...

Reverting:
  From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001
From: Song Liu 
Date: Mon, 11 Mar 2019 22:30:48 -0700
Subject: perf annotate: Enable annotation of BPF programs

Makes it build again.

--
Thomas


Hi Thomas,

Which system are you running this test on? I would like to repro it in a VM.

Thanks,
Song



Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month.


Basesystem is:

binutils-2.32-5.mga7
(includes all fixes from upstream binutils-2_32-branch)

gcc-8.3.1-0.20190419.2.mga7

glibc-2.29-7.mga7
(includes all fixes from upstream glibc release/2.29/master branch up to 
2019-04-15 for now)



kernel-desktop-5.1.0-0.rc7.1.mga7
kernel-userspace-headers-5.1.0-0.rc7.1.mga7


--

Thomas

Re: perf build broken in 5.1-rc7

[Thomas Backlund]

Den 30-04-2019 kl. 10:26, skrev Thomas Backlund:


Building perf in 5.1-rc5/6/7 fails:


Build start:


  make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 
NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all

   BUILD:   Doing 'make -j32' parallel build
   HOSTCC   fixdep.o
   HOSTLD   fixdep-in.o
   LINK fixdep
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' 
differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h 
arch/x86/include/uapi/asm/vmx.h


Auto-detecting system features:
... dwarf: [ on  ]
...    dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...    libbfd: [ on  ]
...    libelf: [ on  ]
...   libnuma: [ on  ]
...    numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...    libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
...    libaio: [ on  ]
...    disassembler-four-args: [ OFF ]

Makefile.config:473: No sys/sdt.h found, no SDT events are defined, 
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF 
format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev



And breaks with:


CC   ui/setup.o
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of 
'disassembler'

   disassemble = disassembler(bfdf);
  ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' 
but argument is of type 'bfd *' {aka 'struct bfd *'}

  extern disassembler_ftype disassembler (enum bfd_architecture arc,
  ~~^~~
util/annotate.c:1767:16: error: too few arguments to function 
'disassembler'

   disassemble = disassembler(bfdf);
     ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:27: note: declared here
  extern disassembler_ftype disassembler (enum bfd_architecture arc,
    ^~~~
   CC   arch/x86/util/header.o
   CC   arch/x86/util/tsc.o
   CC   arch/x86/util/pmu.o
mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
   CC   bench/futex-requeue.o
   CC   arch/x86/util/kvm-stat.o
make[4]: *** 
[/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: 
util/annotate.o] Error 1

make[4]: *** Waiting for unfinished jobs
   CC   util/build-id.o






And I forgot...

Reverting:
From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001
From: Song Liu 
Date: Mon, 11 Mar 2019 22:30:48 -0700
Subject: perf annotate: Enable annotation of BPF programs

Makes it build again.

--
Thomas

perf build broken in 5.1-rc7

[Thomas Backlund]

Building perf in 5.1-rc5/6/7 fails:


Build start:


 make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 
NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all

  BUILD:   Doing 'make -j32' parallel build
  HOSTCC   fixdep.o
  HOSTLD   fixdep-in.o
  LINK fixdep
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' 
differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h 
arch/x86/include/uapi/asm/vmx.h


Auto-detecting system features:
... dwarf: [ on  ]
...    dwarf_getlocations: [ on  ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ on  ]
...    libbfd: [ on  ]
...    libelf: [ on  ]
...   libnuma: [ on  ]
...    numa_num_possible_cpus: [ on  ]
...   libperl: [ on  ]
... libpython: [ on  ]
...  libslang: [ on  ]
... libcrypto: [ on  ]
... libunwind: [ on  ]
...    libdw-dwarf-unwind: [ on  ]
...  zlib: [ on  ]
...  lzma: [ on  ]
... get_cpuid: [ on  ]
...   bpf: [ on  ]
...    libaio: [ on  ]
...    disassembler-four-args: [ OFF ]

Makefile.config:473: No sys/sdt.h found, no SDT events are defined, 
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF 
format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev



And breaks with:


CC   ui/setup.o
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1767:29: error: incompatible type for argument 1 of 
'disassembler'

  disassemble = disassembler(bfdf);
 ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' 
but argument is of type 'bfd *' {aka 'struct bfd *'}

 extern disassembler_ftype disassembler (enum bfd_architecture arc,
 ~~^~~
util/annotate.c:1767:16: error: too few arguments to function 'disassembler'
  disassemble = disassembler(bfdf);
    ^~~~
In file included from util/annotate.c:1689:
/usr/include/dis-asm.h:325:27: note: declared here
 extern disassembler_ftype disassembler (enum bfd_architecture arc,
   ^~~~
  CC   arch/x86/util/header.o
  CC   arch/x86/util/tsc.o
  CC   arch/x86/util/pmu.o
mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
  CC   bench/futex-requeue.o
  CC   arch/x86/util/kvm-stat.o
make[4]: *** 
[/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: 
util/annotate.o] Error 1

make[4]: *** Waiting for unfinished jobs
  CC   util/build-id.o


--

Thomas

Re: [PATCH 5.0 39/93] perf top: Delete the evlist before perf_session, fixing heap-use-after-free issue

[Thomas Backlund]

 fd
 Stack left redzone:  f1
 Stack mid redzone:   f2
 Stack right redzone: f3
 Stack after return:  f5
 Stack use after scope:   f8
 Global redzone:  f9
 Global init order:   f6
 Poisoned by user:f7
 Container overflow:  fc
 Array cookie:ac
 Intra object redzone:bb
 ASan internal:   fe
 Left alloca redzone: ca
 Right alloca redzone:cb
   ==27350==ABORTING

Signed-off-by: Changbin Du 
Reviewed-by: Jiri Olsa 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt (VMware) 
Link: http://lkml.kernel.org/r/20190316080556.3075-8-changbin...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
  tools/perf/builtin-top.c | 42 ++--
  1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index f64e312db787..9b215007924b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1192,23 +1192,19 @@ static int __cmd_top(struct perf_top *top)
pthread_t thread, thread_process;
int ret;
  
-	top->session = perf_session__new(NULL, false, NULL);

-   if (top->session == NULL)
-   return -1;
-
if (!top->annotation_opts.objdump_path) {
ret = perf_env__lookup_objdump(>session->header.env,
   
>annotation_opts.objdump_path);
if (ret)
-   goto out_delete;
+   return ret;
}
  
  	ret = callchain_param__setup_sample_type(_param);

if (ret)
-   goto out_delete;
+   return ret;
  
  	if (perf_session__register_idle_thread(top->session) < 0)

-   goto out_delete;
+   return ret;
  
  	if (top->nr_threads_synthesize > 1)

perf_set_multithreaded();
@@ -1224,13 +1220,18 @@ static int __cmd_top(struct perf_top *top)
  
  	if (perf_hpp_list.socket) {

ret = perf_env__read_cpu_topology_map(_env);
-   if (ret < 0)
-   goto out_err_cpu_topo;
+   if (ret < 0) {
+   char errbuf[BUFSIZ];
+   const char *err = str_error_r(-ret, errbuf, 
sizeof(errbuf));
+
+   ui__error("Could not read the CPU topology map: %s\n", 
err);
+   return ret;
+   }
}
  
  	ret = perf_top__start_counters(top);

if (ret)
-   goto out_delete;
+   return ret;
  
  	ret = perf_evlist__apply_drv_configs(evlist, , _term);

if (ret) {
@@ -1257,7 +1258,7 @@ static int __cmd_top(struct perf_top *top)
ret = -1;
if (pthread_create(_process, NULL, process_thread, top)) {
ui__error("Could not create process thread.\n");
-   goto out_delete;
+   return ret;
}
  
  	if (pthread_create(, NULL, (use_browser > 0 ? display_thread_tui :

@@ -1301,19 +1302,7 @@ static int __cmd_top(struct perf_top *top)
  out_join_thread:
pthread_cond_signal(>qe.cond);
pthread_join(thread_process, NULL);
-out_delete:
-   perf_session__delete(top->session);
-   top->session = NULL;
-
return ret;
-
-out_err_cpu_topo: {
-   char errbuf[BUFSIZ];
-   const char *err = str_error_r(-ret, errbuf, sizeof(errbuf));
-
-   ui__error("Could not read the CPU topology map: %s\n", err);
-   goto out_delete;
-}
  }
  
  static int

@@ -1644,10 +1633,17 @@ int cmd_top(int argc, const char **argv)
signal(SIGWINCH, winch_sig);
}
  
+	top.session = perf_session__new(NULL, false, NULL);

+   if (top.session == NULL) {
+   status = -1;
+   goto out_delete_evlist;
+   }
+
status = __cmd_top();
  
  out_delete_evlist:

perf_evlist__delete(top.evlist);
+   perf_session__delete(top.session);
  
  	return status;

  }




This one breaks perf build like this:

builtin-top.c: In function '__cmd_top':
builtin-top.c:1241:3: error: label 'out_delete' used but not defined
   goto out_delete;


Suggested 5.0 specific fix attached.

Subject: perf top: fix builtin-top build breakage.

In 5.0 -stable queue, backported upstream commit 0dba9e4be95b (perf top: Delete
the evlist before perf_session, fixing heap-use-after-free issue)

causes the perf build to break with:

builtin-top.c: In function '__cmd_top':
builtin-top.c:1241:3: error: label 'out_delete' used but not defined
   goto out_delete;
   ^~~~

This does not happend in upstream linus tree as the affected code is removed
in commit 159b0da50adb (perf pmu: Remove set_drv_config API) that I assume
is not ok to backport in -stable trees.

Fix it up like other code in commit 0dba9e4be95b.

Signed-

Re: [PATCH 5.0 05/93] perf data: Dont store auxtrace index for directory data file

[Thomas Backlund]

Den 18-04-2019 kl. 20:56, skrev Greg Kroah-Hartman:

[ Upstream commit cd3dd8dd8ff62374d90cb3f2e54b8c94106c7810 ]

We can't store the auxtrace index when we store into multiple files,
because we keep only offset for it, not the file.

The auxtrace data will be processed correctly in the 'pipe' mode.

Signed-off-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/20190308134745.5057-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
  tools/perf/builtin-record.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 882285fb9f64..3fd154f1701b 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -386,7 +386,7 @@ static int record__process_auxtrace(struct perf_tool *tool,
size_t padding;
u8 pad[8] = {0};
  
-	if (!perf_data__is_pipe(data)) {

+   if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) {
off_t file_offset;
int fd = perf_data__fd(data);
int err;




This breaks the build with:

builtin-record.c: In function 'record__process_auxtrace':
builtin-record.c:389:36: warning: implicit declaration of function 
'perf_data__is_dir'; did you mean 'perf_data__is_pipe'? 
[-Wimplicit-function-declaration]

  if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) {
^

Looks like it depends atleast on:

commit ec65def1045e4c7817b7f741a86dadae82877a93
Author: Jiri Olsa 
Date:   Fri Mar 8 14:47:35 2019 +0100

perf data: Support having perf.data stored as a directory


Maybe better to drop it.

--
Thomas

Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn

[Thomas Backlund]

Den 23-12-2018 kl. 01:28, skrev Linus Torvalds:

On Sat, Dec 22, 2018 at 3:07 PM Christian Brauner
 wrote:


However, for this case should I resend the revert?


Since I was pointed at the original email thread, I just picked it up
from there directly. It still applied cleanly, nothing had changed in
that area.

 Linus



This should also be picked up for 4.19 lts

Greg, it's now upstream as:

From 94f82008ce30e2624537d240d64ce718255e0b80 Mon Sep 17 00:00:00 2001
From: Christian Brauner 
Date: Thu, 5 Jul 2018 17:51:20 +0200
Subject: Revert "vfs: Allow userns root to call mknod on owned filesystems."

--
Thomas

Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF

[Thomas Backlund]

Den 2018-12-03 kl. 11:22, skrev Sasha Levin:

> 
> This is a case where theory collides with the real world. Yes, our QA is
> lacking, but we don't have the option of not doing the current process.
> If we stop backporting until a future data where our QA problem is
> solved we'll end up with what we had before: users stuck on ancient
> kernels without a way to upgrade.
> 

Sorry, but you seem to be living in a different "real world"...

People stay on "ancient kernels" that "just works" instead of updating
to a newer one that "hopefully/maybe/... works"


> With the current model we're aware that bugs sneak through, but we try
> to deal with it by both improving our QA, and encouraging users to do
> their own extensive QA. If we encourage users to update frequently we
> can keep improving our process and the quality of kernels will keep
> getting better.

And here you want to turn/force users into QA ... good luck with that.

In reality they wont "update frequently", instead they will stop
updating when they have something that works... and start ignoring
updates as they expect something "to break as usual" as they actually
need to get some real work done too...


> 
> We simply can't go back to the "enterprise distro" days.
> 

Maybe so, but we should atleast get back to having "stable" or
"longterm" actually mean something again...

Or what does it say when distros starts thinking about ignoring
(and some already do) stable/longterm trees because there is
_way_ too much questionable changes coming through, even overriding
maintainers to the point where they basically state "we dont care
about monitoring stable trees anymore, as they add whatever they want
anyway"...

And pretending that every fix is important enough to backport,
and saying if you dont take everything you have an "unsecure" kernel
wont help, as reality has shown from time to time that backports
can/will open up a new issue instead for no good reason

Wich for distros starts to mean, switch back to selectively taking fixes
for _known_ security issues are considered way better choice

End result, no-one cares about -stable trees -> no-one uses them -> a
lot of wasted work for nothing...

--
Thomas

Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF

[Thomas Backlund]

Den 2018-12-03 kl. 11:22, skrev Sasha Levin:

> 
> This is a case where theory collides with the real world. Yes, our QA is
> lacking, but we don't have the option of not doing the current process.
> If we stop backporting until a future data where our QA problem is
> solved we'll end up with what we had before: users stuck on ancient
> kernels without a way to upgrade.
> 

Sorry, but you seem to be living in a different "real world"...

People stay on "ancient kernels" that "just works" instead of updating
to a newer one that "hopefully/maybe/... works"


> With the current model we're aware that bugs sneak through, but we try
> to deal with it by both improving our QA, and encouraging users to do
> their own extensive QA. If we encourage users to update frequently we
> can keep improving our process and the quality of kernels will keep
> getting better.

And here you want to turn/force users into QA ... good luck with that.

In reality they wont "update frequently", instead they will stop
updating when they have something that works... and start ignoring
updates as they expect something "to break as usual" as they actually
need to get some real work done too...


> 
> We simply can't go back to the "enterprise distro" days.
> 

Maybe so, but we should atleast get back to having "stable" or
"longterm" actually mean something again...

Or what does it say when distros starts thinking about ignoring
(and some already do) stable/longterm trees because there is
_way_ too much questionable changes coming through, even overriding
maintainers to the point where they basically state "we dont care
about monitoring stable trees anymore, as they add whatever they want
anyway"...

And pretending that every fix is important enough to backport,
and saying if you dont take everything you have an "unsecure" kernel
wont help, as reality has shown from time to time that backports
can/will open up a new issue instead for no good reason

Wich for distros starts to mean, switch back to selectively taking fixes
for _known_ security issues are considered way better choice

End result, no-one cares about -stable trees -> no-one uses them -> a
lot of wasted work for nothing...

--
Thomas

Re: [PATCH 00/39 v7] PTI support for x86-32

[Thomas Backlund]

Den 2018-07-11 kl. 20:28, skrev Jiri Kosina:

On Wed, 11 Jul 2018, Linus Torvalds wrote:


It's the testing that worries me most. Pretty much no developers run
32-bit any more, and I'd be most worried about the odd interactions that
might be hw-specific. Some crazy EFI mapping setup or the similar odd
case that simply requires a particular configuration or setup.

But I guess those issues will never be found until we just spring this
all on the unsuspecting public.


FWIW we shipped Joerg's 32bit KAISER kernel out to our 32bit users (on old
product where we still support it) on Apr 25th already (and some issues
have been identified since then because of that). So it (or its port to
3.0, to be more precise :p) already did receive some crowd-testing.



And Mageia has had v2 since February 13th patched into 4.14 -longterm, 
then updated to v3 at March 5th, and updated to v4 at March 19th and 
been running that since then (since v5 is rebased on v4.17 we stayed 
with v4)



So, here is another "lets merge it upstream" vote :)


--
Thomas

Re: [PATCH 00/39 v7] PTI support for x86-32

[Thomas Backlund]

Den 2018-07-11 kl. 20:28, skrev Jiri Kosina:

On Wed, 11 Jul 2018, Linus Torvalds wrote:


It's the testing that worries me most. Pretty much no developers run
32-bit any more, and I'd be most worried about the odd interactions that
might be hw-specific. Some crazy EFI mapping setup or the similar odd
case that simply requires a particular configuration or setup.

But I guess those issues will never be found until we just spring this
all on the unsuspecting public.


FWIW we shipped Joerg's 32bit KAISER kernel out to our 32bit users (on old
product where we still support it) on Apr 25th already (and some issues
have been identified since then because of that). So it (or its port to
3.0, to be more precise :p) already did receive some crowd-testing.



And Mageia has had v2 since February 13th patched into 4.14 -longterm, 
then updated to v3 at March 5th, and updated to v4 at March 19th and 
been running that since then (since v5 is rebased on v4.17 we stayed 
with v4)



So, here is another "lets merge it upstream" vote :)


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-07 kl. 22:40, skrev Linus Torvalds:

On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund  wrote:

I can work around it for now (or keep the revert in our kernel builds
for now) until it gets properly fixed...

So rather than doing the revert, it's probably better if  your
workaround just does

make ARCH=i386 oldconfig

(or maybe even just a "export ARCH=i386" in the environment)

That should get you to continue to otherwise do the same thing.

And if it turns out that your flow is the *only* one affected by this,
and nobody else complains, maybe we can just say "yeah, slight change
in build rules, easy to work around" and leave it at that.

 Linus


Yeah, I can live with that too :)

I just wanted to point out the regression in case it was not (sort of) 
intentional...


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-07 kl. 22:40, skrev Linus Torvalds:

On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund  wrote:

I can work around it for now (or keep the revert in our kernel builds
for now) until it gets properly fixed...

So rather than doing the revert, it's probably better if  your
workaround just does

make ARCH=i386 oldconfig

(or maybe even just a "export ARCH=i386" in the environment)

That should get you to continue to otherwise do the same thing.

And if it turns out that your flow is the *only* one affected by this,
and nobody else complains, maybe we can just say "yeah, slight change
in build rules, easy to work around" and leave it at that.

 Linus


Yeah, I can live with that too :)

I just wanted to point out the regression in case it was not (sort of) 
intentional...


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-06 kl. 06:30, skrev Masahiro Yamada:

Hi Linus,

2018-06-06 11:19 GMT+09:00 Linus Torvalds :

On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
 wrote:

But once you *have* that particular Kconfig, I do think that "make
oldconfig" should just work. And it apparently used to.

So I think this is a behavioral regression.

That doesn't necessarily mean that he fix should be to revert.


If this is a regression, I am OK with the revert,
and it is the only quick solution.



It is a regression as the same "make oldconfig routine" has been working 
iirc since atleast 2.4 series kernels :)


But I dont see it as needing a "quick solution" revert if the "kconfig: 
only write '# CONFIG_FOO is not set' for visible symbols" is considered 
a "useful thing we want to keep"... I'd rather think waiting/working a 
bit for a proper fix is the better way then...


I can work around it for now (or keep the revert in our kernel builds 
for now) until it gets properly fixed...


Feel free to cc me on suggested fixes to test

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-06 kl. 06:30, skrev Masahiro Yamada:

Hi Linus,

2018-06-06 11:19 GMT+09:00 Linus Torvalds :

On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
 wrote:

But once you *have* that particular Kconfig, I do think that "make
oldconfig" should just work. And it apparently used to.

So I think this is a behavioral regression.

That doesn't necessarily mean that he fix should be to revert.


If this is a regression, I am OK with the revert,
and it is the only quick solution.



It is a regression as the same "make oldconfig routine" has been working 
iirc since atleast 2.4 series kernels :)


But I dont see it as needing a "quick solution" revert if the "kconfig: 
only write '# CONFIG_FOO is not set' for visible symbols" is considered 
a "useful thing we want to keep"... I'd rather think waiting/working a 
bit for a proper fix is the better way then...


I can work around it for now (or keep the revert in our kernel builds 
for now) until it gets properly fixed...


Feel free to cc me on suggested fixes to test

--
Thomas

Re: python errors in tools/testing/selftests/tc-testing - IGNORE

[Thomas Backlund]

Den 2018-06-05 kl. 23:10, skrev Thomas Backlund:
Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py 
...
   File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", 
line 18

     print('This script must be run with root privileges', file=sys.stderr)
   ^
SyntaxError: invalid syntax


Caused by:

commit f6926e85eee9be08d05170af3a2266b8d7f9cdef
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:55 2018 -0500

     tools: tc-testing: rootPlugin

     Move the functionality that checks for root permissions into a plugin.



and:

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py 
...
   File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", 
line 167

     print('', file=sys.stderr)
   ^
SyntaxError: invalid syntax


Caused by:

commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:54 2018 -0500

     tools: tc-testing: Introduce plugin architecture





And this system has:

$ python3 -V
Python 3.5.3

$ python -V
Python 2.7.15




This one on the other hand seems to be a toolchain issue...

rpmbuild calls out to

/usr/lib/rpm/brp-python-bytecompile /usr/bin/python

which basically in this case seems to try to parse python3 code with 
python2 and it falls over...


So I've disabled bytecompiling on kernel builds until I can check the 
toolchain behaviour...


--
Thomas

Re: python errors in tools/testing/selftests/tc-testing - IGNORE

[Thomas Backlund]

Den 2018-06-05 kl. 23:10, skrev Thomas Backlund:
Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py 
...
   File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", 
line 18

     print('This script must be run with root privileges', file=sys.stderr)
   ^
SyntaxError: invalid syntax


Caused by:

commit f6926e85eee9be08d05170af3a2266b8d7f9cdef
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:55 2018 -0500

     tools: tc-testing: rootPlugin

     Move the functionality that checks for root permissions into a plugin.



and:

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py 
...
   File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", 
line 167

     print('', file=sys.stderr)
   ^
SyntaxError: invalid syntax


Caused by:

commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:54 2018 -0500

     tools: tc-testing: Introduce plugin architecture





And this system has:

$ python3 -V
Python 3.5.3

$ python -V
Python 2.7.15




This one on the other hand seems to be a toolchain issue...

rpmbuild calls out to

/usr/lib/rpm/brp-python-bytecompile /usr/bin/python

which basically in this case seems to try to parse python3 code with 
python2 and it falls over...


So I've disabled bytecompiling on kernel builds until I can check the 
toolchain behaviour...


--
Thomas

python errors in tools/testing/selftests/tc-testing (was: Linux 4.17)

[Thomas Backlund]

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py 
...
  File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", 
line 18

print('This script must be run with root privileges', file=sys.stderr)
  ^
SyntaxError: invalid syntax


Caused by:

commit f6926e85eee9be08d05170af3a2266b8d7f9cdef
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:55 2018 -0500

tools: tc-testing: rootPlugin

Move the functionality that checks for root permissions into a plugin.



and:

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py 
...
  File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", 
line 167

print('', file=sys.stderr)
  ^
SyntaxError: invalid syntax


Caused by:

commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:54 2018 -0500

tools: tc-testing: Introduce plugin architecture





And this system has:

$ python3 -V
Python 3.5.3

$ python -V
Python 2.7.15


--

Thomas

python errors in tools/testing/selftests/tc-testing (was: Linux 4.17)

[Thomas Backlund]

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py 
...
  File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", 
line 18

print('This script must be run with root privileges', file=sys.stderr)
  ^
SyntaxError: invalid syntax


Caused by:

commit f6926e85eee9be08d05170af3a2266b8d7f9cdef
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:55 2018 -0500

tools: tc-testing: rootPlugin

Move the functionality that checks for root permissions into a plugin.



and:

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py 
...
  File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", 
line 167

print('', file=sys.stderr)
  ^
SyntaxError: invalid syntax


Caused by:

commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd
Author: Brenda J. Butler 
Date:   Wed Feb 14 14:08:54 2018 -0500

tools: tc-testing: Introduce plugin architecture





And this system has:

$ python3 -V
Python 3.5.3

$ python -V
Python 2.7.15


--

Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 22:13, skrev Linus Torvalds:

On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund  wrote:

but why do you care?

Because without it running the build in the 32bit chroot will get the
initial reported issue:

Ahh. I can re-create that now.

Yes, doing

   make ARCH=i386 allnoconfig

followed by

   make oldconfig

is broken. And doing a trivial "git bisect run" to pinpoint where
CONFIG_64BIT goes away gives us

f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit

which does that

   "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"

and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
because that question is disabled when ARCH != "x86".

 bool "64-bit kernel" if ARCH = "x86"

And the problem with that, is that *next* time around this config file
is used, because we don't have that

   # CONFIG_64BIT is not set

line, we don't turn it into

   CONFIG_64BIT=n

and then the "depends on" in X86_64

   config X86_64
   def_bool y
   depends on 64BIT

no longer hides it.

Hmm. Ulf, Masahiro, comments?

Should we just revert that commit?

Thomas, can you verify that a

 git revert f467c5640c29ad258c3cd8186a776c82fc3b8057

fixes the problem for you?

   Linus


Yep, that fixes it so it works both  in the 32bit chroot and on the 
64bit host


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 22:13, skrev Linus Torvalds:

On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund  wrote:

but why do you care?

Because without it running the build in the 32bit chroot will get the
initial reported issue:

Ahh. I can re-create that now.

Yes, doing

   make ARCH=i386 allnoconfig

followed by

   make oldconfig

is broken. And doing a trivial "git bisect run" to pinpoint where
CONFIG_64BIT goes away gives us

f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit

which does that

   "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"

and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
because that question is disabled when ARCH != "x86".

 bool "64-bit kernel" if ARCH = "x86"

And the problem with that, is that *next* time around this config file
is used, because we don't have that

   # CONFIG_64BIT is not set

line, we don't turn it into

   CONFIG_64BIT=n

and then the "depends on" in X86_64

   config X86_64
   def_bool y
   depends on 64BIT

no longer hides it.

Hmm. Ulf, Masahiro, comments?

Should we just revert that commit?

Thomas, can you verify that a

 git revert f467c5640c29ad258c3cd8186a776c82fc3b8057

fixes the problem for you?

   Linus


Yep, that fixes it so it works both  in the 32bit chroot and on the 
64bit host


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 21:38, skrev Linus Torvalds:

On Tue, Jun 5, 2018 at 11:23 AM Thomas Backlund  wrote:

   #
-# CONFIG_64BIT is not set

So something _does_ strip away the needed config bit

Why do you need it?

I get

   CONFIG_X86_32=y
   CONFIG_X86=y

and CONFIG_64BIT never gets set.

It is true that I don't get the

   # CONFIG_64BIT is not set

line, but why do you care?

 Linus


Because without it running the build in the 32bit chroot will get the 
initial reported issue:



$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)


which breaks our buildbots running in chroots...


Now I can work around it by adding the config bit myself, but I'd like 
to understand what changed and why...


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 21:38, skrev Linus Torvalds:

On Tue, Jun 5, 2018 at 11:23 AM Thomas Backlund  wrote:

   #
-# CONFIG_64BIT is not set

So something _does_ strip away the needed config bit

Why do you need it?

I get

   CONFIG_X86_32=y
   CONFIG_X86=y

and CONFIG_64BIT never gets set.

It is true that I don't get the

   # CONFIG_64BIT is not set

line, but why do you care?

 Linus


Because without it running the build in the 32bit chroot will get the 
initial reported issue:



$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)


which breaks our buildbots running in chroots...


Now I can work around it by adding the config bit myself, but I'd like 
to understand what changed and why...


--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 21:11, skrev Linus Torvalds:

On Tue, Jun 5, 2018 at 10:51 AM Thomas Backlund  wrote:

Is this intentional ? If so, why ? If not, how can I fix it ?

It shouldn't be intentional. And I don't see anythin ghaving changed
in this area. We still have

   config 64BIT
 bool "64-bit kernel" if ARCH = "x86"
 default ARCH != "i386"

which is what it was in 4.16 too.

Of course, we also have (in the main Makefile)

   SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \

and

   ARCH?= $(SUBARCH)

so if you don't set ARCH explicitly, it will always translate "i686"
into "x86", so it will default to 64-bit.

None of this is new to 4.17, though. Are you sure you didn't use to
have an ARCH=i386 somewhere?

Because this works for me:

 make ARCH=i386 oldconfig

and it's how I have done cross-builds before (although honestly, I
don't do them very often).

But adding Masahiro to the cc in case he sees something I've missed.

Of course, doing a bisect on *when* it broke for you would be good
too. You don't need to actually build the kernel, you can just bisect
the configuration phase (and even automate it with "git bisect run" if
you want to).

  Linus



Taking back the earlier " IGNORE " part...

This happends on the 64bit host:

# make ARCH=i386 oldconfig

--- .config.old 2018-06-05 21:17:07.829954548 +0300
+++ .config 2018-06-05 21:17:43.367487580 +0300
@@ -1,8 +1,7 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/i386 4.16.12 Kernel Configuration
+# Linux/i386 4.17.0 Kernel Configuration
 #
-# CONFIG_64BIT is not set




So something _does_ strip away the needed config bit

So any ideas, or should I start bisecting ?

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 21:11, skrev Linus Torvalds:

On Tue, Jun 5, 2018 at 10:51 AM Thomas Backlund  wrote:

Is this intentional ? If so, why ? If not, how can I fix it ?

It shouldn't be intentional. And I don't see anythin ghaving changed
in this area. We still have

   config 64BIT
 bool "64-bit kernel" if ARCH = "x86"
 default ARCH != "i386"

which is what it was in 4.16 too.

Of course, we also have (in the main Makefile)

   SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \

and

   ARCH?= $(SUBARCH)

so if you don't set ARCH explicitly, it will always translate "i686"
into "x86", so it will default to 64-bit.

None of this is new to 4.17, though. Are you sure you didn't use to
have an ARCH=i386 somewhere?

Because this works for me:

 make ARCH=i386 oldconfig

and it's how I have done cross-builds before (although honestly, I
don't do them very often).

But adding Masahiro to the cc in case he sees something I've missed.

Of course, doing a bisect on *when* it broke for you would be good
too. You don't need to actually build the kernel, you can just bisect
the configuration phase (and even automate it with "git bisect run" if
you want to).

  Linus



Taking back the earlier " IGNORE " part...

This happends on the 64bit host:

# make ARCH=i386 oldconfig

--- .config.old 2018-06-05 21:17:07.829954548 +0300
+++ .config 2018-06-05 21:17:43.367487580 +0300
@@ -1,8 +1,7 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/i386 4.16.12 Kernel Configuration
+# Linux/i386 4.17.0 Kernel Configuration
 #
-# CONFIG_64BIT is not set




So something _does_ strip away the needed config bit

So any ideas, or should I start bisecting ?

--
Thomas

Re: building in 32bit chroot on x86_64 host broken - IGNORE

[Thomas Backlund]

Den 2018-06-05 kl. 20:52, skrev Thomas Backlund:


I have a 32bit x86 and a 64bit x86_64 install on the system.

With linux source up to 4.16.x I could do:

setarch i686 (or use command linux32)
chroot /path/to/32bit/
(/dev, /proc, /sys, /run is bind mounted in the chroot)

Then I could build a 32bit kernel in the chroot without booting the 
32bit system...


(host is running a 4.14 longterm kernel)

but building from 4.17 source in the chroot I get:


$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)




So it does not pick up 32bit anymore ...

Is this intentional ? If so, why ? If not, how can I fix it ?




Never mind...

For some reason I seem to have lost this  in the .config update to 4.17:

# CONFIG_64BIT is not set


Re-adding it restores proper behaviour...

Sorry for the noise...

--
Thomas

Re: building in 32bit chroot on x86_64 host broken - IGNORE

[Thomas Backlund]

Den 2018-06-05 kl. 20:52, skrev Thomas Backlund:


I have a 32bit x86 and a 64bit x86_64 install on the system.

With linux source up to 4.16.x I could do:

setarch i686 (or use command linux32)
chroot /path/to/32bit/
(/dev, /proc, /sys, /run is bind mounted in the chroot)

Then I could build a 32bit kernel in the chroot without booting the 
32bit system...


(host is running a 4.14 longterm kernel)

but building from 4.17 source in the chroot I get:


$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)




So it does not pick up 32bit anymore ...

Is this intentional ? If so, why ? If not, how can I fix it ?




Never mind...

For some reason I seem to have lost this  in the .config update to 4.17:

# CONFIG_64BIT is not set


Re-adding it restores proper behaviour...

Sorry for the noise...

--
Thomas

building in 32bit chroot on x86_64 host broken (was: Linux 4.17)

[Thomas Backlund]

I have a 32bit x86 and a 64bit x86_64 install on the system.

With linux source up to 4.16.x I could do:

setarch i686 (or use command linux32)
chroot /path/to/32bit/
(/dev, /proc, /sys, /run is bind mounted in the chroot)

Then I could build a 32bit kernel in the chroot without booting the 
32bit system...


(host is running a 4.14 longterm kernel)

but building from 4.17 source in the chroot I get:


$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)




So it does not pick up 32bit anymore ...

Is this intentional ? If so, why ? If not, how can I fix it ?

--
Thomas

building in 32bit chroot on x86_64 host broken (was: Linux 4.17)

[Thomas Backlund]

I have a 32bit x86 and a 64bit x86_64 install on the system.

With linux source up to 4.16.x I could do:

setarch i686 (or use command linux32)
chroot /path/to/32bit/
(/dev, /proc, /sys, /run is bind mounted in the chroot)

Then I could build a 32bit kernel in the chroot without booting the 
32bit system...


(host is running a 4.14 longterm kernel)

but building from 4.17 source in the chroot I get:


$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)




So it does not pick up 32bit anymore ...

Is this intentional ? If so, why ? If not, how can I fix it ?

--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 18:57, skrev Greg KH:

On Thu, Apr 19, 2018 at 06:16:26PM +0300, Thomas Backlund wrote:

Den 19.04.2018 kl. 17:22, skrev Greg KH:

On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote:

On Thu 19-04-18 15:59:43, Greg KH wrote:

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote:

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin <alexander.le...@microsoft.com> wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug compatible"
_is_ a _regression_ you _really_ _dont_ want in a stable
supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch that
carries "AUTOSEL", follow all the mail threads that comes up about it, then
track if it landed in -stable queue, and read every response and possible
objection to all patches in the -stable queue a second time around... then
check if it still got included in final stable point relase and then either
revert them in distro kernel or go track down all the follow-up fixes
needed...

Just to avoid being "bug compatible with master"


I've done this "bug compatible" "breakage" more than the AUTOSEL stuff
has in the past, so you had better also be reviewing all of my normal
commits as well :)

Anyway, we are trying not to do this, but it does, and will,
occasionally happen.


Sure, that's understood. So this was just misunderstanding. Sasha's
original comment really sounded like "bug compatibility" with current
master is desirable and that made me go "Are you serious?" as well...


As I said before in this thread, yes, sometimes I do this on purpose.



And I guess this is the one that gets people the feeling that
"stable is not as stable as it used to be" ...


It's always been this way, it's just that no one noticed :)



:)



As an specific example, see a recent bluetooth patch that caused a
regression on some chromebook devices.  The chromeos developers
rightfully complainied, and I left the commit in there to provide the
needed "leverage" on the upstream developers to fix this properly.
Otherwise if I had reverted the stable patch, when people move to a
newer kernel version, things break, and no one remembers why.


I do understand what you are trying to do...

But from my distro hat on I have to treat things differently (and I dont
think I'm alone doing it this way...)

Known breakages gets reverted even before it hits QA, so endusers wont see
the issue at all...

So the only ones to see the issue are those building with latest upstream
without own patches applied...



I also wrote a long response as to _why_ I do this, and even though it
does happen, why it still is worth taking the stable updates.  Please
see the archives for the full details.  I don't want to duplicate this
again here.


And we do use latest stable (with some delay as I dont want to overload QA &
endusers with a new kernel every week :))


You need to automate your QA :)



Yeah, some can be automated... but that means having a lot of different 
hw to test on... emulators/vms can only test so much...


users part of QA test on a variety of hw with various installs/setups 
that exposes fun things with some hw :)




We just revert known broken (or add known fixes) before releasing them to
our users


That's great, and is what you should be doing, nothing wrong there.

thanks,

greg k-h



--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 18:57, skrev Greg KH:

On Thu, Apr 19, 2018 at 06:16:26PM +0300, Thomas Backlund wrote:

Den 19.04.2018 kl. 17:22, skrev Greg KH:

On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote:

On Thu 19-04-18 15:59:43, Greg KH wrote:

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote:

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin  wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug compatible"
_is_ a _regression_ you _really_ _dont_ want in a stable
supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch that
carries "AUTOSEL", follow all the mail threads that comes up about it, then
track if it landed in -stable queue, and read every response and possible
objection to all patches in the -stable queue a second time around... then
check if it still got included in final stable point relase and then either
revert them in distro kernel or go track down all the follow-up fixes
needed...

Just to avoid being "bug compatible with master"


I've done this "bug compatible" "breakage" more than the AUTOSEL stuff
has in the past, so you had better also be reviewing all of my normal
commits as well :)

Anyway, we are trying not to do this, but it does, and will,
occasionally happen.


Sure, that's understood. So this was just misunderstanding. Sasha's
original comment really sounded like "bug compatibility" with current
master is desirable and that made me go "Are you serious?" as well...


As I said before in this thread, yes, sometimes I do this on purpose.



And I guess this is the one that gets people the feeling that
"stable is not as stable as it used to be" ...


It's always been this way, it's just that no one noticed :)



:)



As an specific example, see a recent bluetooth patch that caused a
regression on some chromebook devices.  The chromeos developers
rightfully complainied, and I left the commit in there to provide the
needed "leverage" on the upstream developers to fix this properly.
Otherwise if I had reverted the stable patch, when people move to a
newer kernel version, things break, and no one remembers why.


I do understand what you are trying to do...

But from my distro hat on I have to treat things differently (and I dont
think I'm alone doing it this way...)

Known breakages gets reverted even before it hits QA, so endusers wont see
the issue at all...

So the only ones to see the issue are those building with latest upstream
without own patches applied...



I also wrote a long response as to _why_ I do this, and even though it
does happen, why it still is worth taking the stable updates.  Please
see the archives for the full details.  I don't want to duplicate this
again here.


And we do use latest stable (with some delay as I dont want to overload QA &
endusers with a new kernel every week :))


You need to automate your QA :)



Yeah, some can be automated... but that means having a lot of different 
hw to test on... emulators/vms can only test so much...


users part of QA test on a variety of hw with various installs/setups 
that exposes fun things with some hw :)




We just revert known broken (or add known fixes) before releasing them to
our users


That's great, and is what you should be doing, nothing wrong there.

thanks,

greg k-h



--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 18:09, skrev Sasha Levin:

On Thu, Apr 19, 2018 at 06:04:26PM +0300, Thomas Backlund wrote:

Den 19.04.2018 kl. 16:59, skrev Greg KH:

Anyway, we are trying not to do this, but it does, and will,
occasionally happen.  Look, we just did that for one platform for
4.9.94!  And the key to all of this is good testing, which we are now
doing, and hopefully you are also doing as well.


Yeah, but having to test stuff with known breakages is no fun, so we
try to avoid that


Known breakages are easier to deal with than unknown ones :)



well, if a system worked before the update, but not after...
Guess wich one we want...




I think that that "bug compatability" is basically a policy on *which*
regressions you'll see vs *if* you'll see a regression.




No. Intentionally breaking known working code in a stable branch is 
never ok.


As I said before... something that never worked is not a regression,
but breaking a previously working setup is...

That goes for security fixes too... there is not much point in a 
security fix, if it basically turns into a local DOS when the system 
stops working...


People will just boot older code and there you have it...



We'll never pull in a commit that introduces a bug but doesn't fix
another one, right? So if you have to deal with a regression anyway,
might as well deal with a regression that is also seen on mainline, so
that when you upgrade your stable kernel you'll keep the same set of
regressions to deal with.




Here I actually like the comment Linus posted about API breakage earlier 
in this thread...



If you break user workflows, NOTHING ELSE MATTERS.

Even security is secondary to "people don't use the end result,
because it doesn't work for them any more".


_This_ same statement should be aknowledged / enforced in stable trees 
too IMHO...


Because this is what will happend...

simple logic... if it does not work, the enduser will boot an earlier 
kernel... missing "all the good fixes" (including security ones) just

because one fix is bad.

For example in this AUTOSEL round there is 161 fixes of wich the enduser
never gets the 160 "supposedly good ones" when one is "bad"...


How is that a "good thing" ?


And trying to tell those that get hit "this will force upstream to fix 
it faster, so you get a working setup in some days/weeks/months..." is

not going to work...


Heh, This even reminds me that this is just as annoying as when MS
started to "bundle monthly security updates" and you get 95% installed
just to realize that the last 5% does not work (or install at all) and
you have to rollback to something working thus missing the needed
security fixes...

Same flawed logic...

Thnakfully we as distro maintainers can avoid some of the breakage for 
our enduses...


--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 18:09, skrev Sasha Levin:

On Thu, Apr 19, 2018 at 06:04:26PM +0300, Thomas Backlund wrote:

Den 19.04.2018 kl. 16:59, skrev Greg KH:

Anyway, we are trying not to do this, but it does, and will,
occasionally happen.  Look, we just did that for one platform for
4.9.94!  And the key to all of this is good testing, which we are now
doing, and hopefully you are also doing as well.


Yeah, but having to test stuff with known breakages is no fun, so we
try to avoid that


Known breakages are easier to deal with than unknown ones :)



well, if a system worked before the update, but not after...
Guess wich one we want...




I think that that "bug compatability" is basically a policy on *which*
regressions you'll see vs *if* you'll see a regression.




No. Intentionally breaking known working code in a stable branch is 
never ok.


As I said before... something that never worked is not a regression,
but breaking a previously working setup is...

That goes for security fixes too... there is not much point in a 
security fix, if it basically turns into a local DOS when the system 
stops working...


People will just boot older code and there you have it...



We'll never pull in a commit that introduces a bug but doesn't fix
another one, right? So if you have to deal with a regression anyway,
might as well deal with a regression that is also seen on mainline, so
that when you upgrade your stable kernel you'll keep the same set of
regressions to deal with.




Here I actually like the comment Linus posted about API breakage earlier 
in this thread...



If you break user workflows, NOTHING ELSE MATTERS.

Even security is secondary to "people don't use the end result,
because it doesn't work for them any more".


_This_ same statement should be aknowledged / enforced in stable trees 
too IMHO...


Because this is what will happend...

simple logic... if it does not work, the enduser will boot an earlier 
kernel... missing "all the good fixes" (including security ones) just

because one fix is bad.

For example in this AUTOSEL round there is 161 fixes of wich the enduser
never gets the 160 "supposedly good ones" when one is "bad"...


How is that a "good thing" ?


And trying to tell those that get hit "this will force upstream to fix 
it faster, so you get a working setup in some days/weeks/months..." is

not going to work...


Heh, This even reminds me that this is just as annoying as when MS
started to "bundle monthly security updates" and you get 95% installed
just to realize that the last 5% does not work (or install at all) and
you have to rollback to something working thus missing the needed
security fixes...

Same flawed logic...

Thnakfully we as distro maintainers can avoid some of the breakage for 
our enduses...


--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 17:22, skrev Greg KH:

On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote:

On Thu 19-04-18 15:59:43, Greg KH wrote:

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote:

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin <alexander.le...@microsoft.com> wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug compatible"
_is_ a _regression_ you _really_ _dont_ want in a stable
supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch that
carries "AUTOSEL", follow all the mail threads that comes up about it, then
track if it landed in -stable queue, and read every response and possible
objection to all patches in the -stable queue a second time around... then
check if it still got included in final stable point relase and then either
revert them in distro kernel or go track down all the follow-up fixes
needed...

Just to avoid being "bug compatible with master"


I've done this "bug compatible" "breakage" more than the AUTOSEL stuff
has in the past, so you had better also be reviewing all of my normal
commits as well :)

Anyway, we are trying not to do this, but it does, and will,
occasionally happen.


Sure, that's understood. So this was just misunderstanding. Sasha's
original comment really sounded like "bug compatibility" with current
master is desirable and that made me go "Are you serious?" as well...


As I said before in this thread, yes, sometimes I do this on purpose.



And I guess this is the one that gets people the feeling that
"stable is not as stable as it used to be" ...


As an specific example, see a recent bluetooth patch that caused a
regression on some chromebook devices.  The chromeos developers
rightfully complainied, and I left the commit in there to provide the
needed "leverage" on the upstream developers to fix this properly.
Otherwise if I had reverted the stable patch, when people move to a
newer kernel version, things break, and no one remembers why.


I do understand what you are trying to do...

But from my distro hat on I have to treat things differently (and I dont 
think I'm alone doing it this way...)


Known breakages gets reverted even before it hits QA, so endusers wont 
see the issue at all...


So the only ones to see the issue are those building with latest 
upstream without own patches applied...




I also wrote a long response as to _why_ I do this, and even though it
does happen, why it still is worth taking the stable updates.  Please
see the archives for the full details.  I don't want to duplicate this
again here.


And we do use latest stable (with some delay as I dont want to overload 
QA & endusers with a new kernel every week :))


We just revert known broken (or add known fixes) before releasing them 
to our users


--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 17:22, skrev Greg KH:

On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote:

On Thu 19-04-18 15:59:43, Greg KH wrote:

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote:

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin  wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug compatible"
_is_ a _regression_ you _really_ _dont_ want in a stable
supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch that
carries "AUTOSEL", follow all the mail threads that comes up about it, then
track if it landed in -stable queue, and read every response and possible
objection to all patches in the -stable queue a second time around... then
check if it still got included in final stable point relase and then either
revert them in distro kernel or go track down all the follow-up fixes
needed...

Just to avoid being "bug compatible with master"


I've done this "bug compatible" "breakage" more than the AUTOSEL stuff
has in the past, so you had better also be reviewing all of my normal
commits as well :)

Anyway, we are trying not to do this, but it does, and will,
occasionally happen.


Sure, that's understood. So this was just misunderstanding. Sasha's
original comment really sounded like "bug compatibility" with current
master is desirable and that made me go "Are you serious?" as well...


As I said before in this thread, yes, sometimes I do this on purpose.



And I guess this is the one that gets people the feeling that
"stable is not as stable as it used to be" ...


As an specific example, see a recent bluetooth patch that caused a
regression on some chromebook devices.  The chromeos developers
rightfully complainied, and I left the commit in there to provide the
needed "leverage" on the upstream developers to fix this properly.
Otherwise if I had reverted the stable patch, when people move to a
newer kernel version, things break, and no one remembers why.


I do understand what you are trying to do...

But from my distro hat on I have to treat things differently (and I dont 
think I'm alone doing it this way...)


Known breakages gets reverted even before it hits QA, so endusers wont 
see the issue at all...


So the only ones to see the issue are those building with latest 
upstream without own patches applied...




I also wrote a long response as to _why_ I do this, and even though it
does happen, why it still is worth taking the stable updates.  Please
see the archives for the full details.  I don't want to duplicate this
again here.


And we do use latest stable (with some delay as I dont want to overload 
QA & endusers with a new kernel every week :))


We just revert known broken (or add known fixes) before releasing them 
to our users


--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 16:59, skrev Greg KH:

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote:

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin <alexander.le...@microsoft.com> wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug compatible"
_is_ a _regression_ you _really_ _dont_ want in a stable
supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch that
carries "AUTOSEL", follow all the mail threads that comes up about it, then
track if it landed in -stable queue, and read every response and possible
objection to all patches in the -stable queue a second time around... then
check if it still got included in final stable point relase and then either
revert them in distro kernel or go track down all the follow-up fixes
needed...

Just to avoid being "bug compatible with master"


I've done this "bug compatible" "breakage" more than the AUTOSEL stuff
has in the past, so you had better also be reviewing all of my normal
commits as well :)



Yeah, I do... and same goes there ... if there is a known issue, then 
same procedure... Either revert, or try to track down fixes...




Anyway, we are trying not to do this, but it does, and will,
occasionally happen.  Look, we just did that for one platform for
4.9.94!  And the key to all of this is good testing, which we are now
doing, and hopefully you are also doing as well.


Yeah, but having to test stuff with known breakages is no fun, so we try 
to avoid that


--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 19.04.2018 kl. 16:59, skrev Greg KH:

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote:

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin  wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug compatible"
_is_ a _regression_ you _really_ _dont_ want in a stable
supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch that
carries "AUTOSEL", follow all the mail threads that comes up about it, then
track if it landed in -stable queue, and read every response and possible
objection to all patches in the -stable queue a second time around... then
check if it still got included in final stable point relase and then either
revert them in distro kernel or go track down all the follow-up fixes
needed...

Just to avoid being "bug compatible with master"


I've done this "bug compatible" "breakage" more than the AUTOSEL stuff
has in the past, so you had better also be reviewing all of my normal
commits as well :)



Yeah, I do... and same goes there ... if there is a known issue, then 
same procedure... Either revert, or try to track down fixes...




Anyway, we are trying not to do this, but it does, and will,
occasionally happen.  Look, we just did that for one platform for
4.9.94!  And the key to all of this is good testing, which we are now
doing, and hopefully you are also doing as well.


Yeah, but having to test stuff with known breakages is no fun, so we try 
to avoid that


--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin  wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug 
compatible" _is_ a _regression_ you _really_ _dont_ want in a stable

supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch 
that carries "AUTOSEL", follow all the mail threads that comes up about 
it, then track if it landed in -stable queue, and read every response 
and possible objection to all patches in the -stable queue a second time 
around... then check if it still got included in final stable point 
relase and then either revert them in distro kernel or go track down all 
the follow-up fixes needed...


Just to avoid being "bug compatible with master"

--
Thomas

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Thomas Backlund]

Den 16-04-2018 kl. 19:19, skrev Sasha Levin:

On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote:

On Mon, 16 Apr 2018 16:02:03 +
Sasha Levin  wrote:


One of the things Greg is pushing strongly for is "bug compatibility":
we want the kernel to behave the same way between mainline and stable.
If the code is broken, it should be broken in the same way.


Wait! What does that mean? What's the purpose of stable if it is as
broken as mainline?


This just means that if there is a fix that went in mainline, and the
fix is broken somehow, we'd rather take the broken fix than not.

In this scenario, *something* will be broken, it's just a matter of
what. We'd rather have the same thing broken between mainline and
stable.



Yeah, but _intentionally_ breaking existing setups to stay "bug 
compatible" _is_ a _regression_ you _really_ _dont_ want in a stable

supported distro. Because end-users dont care about upstream breaking
stuff... its the distro that takes the heat for that...

Something "already broken" is not a regression...

As distro maintainer that means one now have to review _every_ patch 
that carries "AUTOSEL", follow all the mail threads that comes up about 
it, then track if it landed in -stable queue, and read every response 
and possible objection to all patches in the -stable queue a second time 
around... then check if it still got included in final stable point 
relase and then either revert them in distro kernel or go track down all 
the follow-up fixes needed...


Just to avoid being "bug compatible with master"

--
Thomas

Re: [PATCH 4.14 000/109] 4.14.28-stable review

[Thomas Backlund]

Den 27.03.2018 kl. 09:37, skrev Guenter Roeck:

On 03/26/2018 11:28 PM, Greg Kroah-Hartman wrote:

On Mon, Mar 26, 2018 at 01:54:18PM -0400, Kash Pande wrote:

On 2018-03-19 02:20 PM, Guenter Roeck wrote:

Ryzen and Threadripper are only supported in v4.15+.



Nope, the offset for 1900X is not available in 4.15, I've had to
manually patch all systems otherwise monitoring complains they idle 
at 53C.


I don't understand, what patch are you talking about here?



6509614fdd2d, but you'll also want aef17ca12719 if that isn't queued 
already.


Guenter



And if you ant it to work in 4.14 longterm, you want the series:

68546abf7a3a63f199e53d6dcaa7375df37a6aaa  hwmon: (k10temp) Move chip 
specific code into probe function
9af0a9aecdb945cd5513941ffdcbcc031009b402  hwmon: (k10temp) Add support 
for family 17h
1b50b776355fa6c6d7b3281a63c275d5c18d629d  hwmon: (k10temp) Add support 
for temperature offsets
ab5ee24615f9dd8b0cd199403959f8b13309e7b1  hwmon: (k10temp) Correct model 
name for Ryzen 1600X
6509614fdd2d05c6926d50901a45d5dfb852b715  hwmon: (k10temp) Add 
temperature offset for Ryzen 1900X
aef17ca1271948ee57cc39b2493d31110cc42625  hwmon: (k10temp) Only apply 
temperature offset if result is positive



We have it in Mageia, and I've confirmed it works on a Ryzen 7 1700 and 
ThreadRipper 1950X


--
Thomas

Re: [PATCH 4.14 000/109] 4.14.28-stable review

[Thomas Backlund]

Den 27.03.2018 kl. 09:37, skrev Guenter Roeck:

On 03/26/2018 11:28 PM, Greg Kroah-Hartman wrote:

On Mon, Mar 26, 2018 at 01:54:18PM -0400, Kash Pande wrote:

On 2018-03-19 02:20 PM, Guenter Roeck wrote:

Ryzen and Threadripper are only supported in v4.15+.



Nope, the offset for 1900X is not available in 4.15, I've had to
manually patch all systems otherwise monitoring complains they idle 
at 53C.


I don't understand, what patch are you talking about here?



6509614fdd2d, but you'll also want aef17ca12719 if that isn't queued 
already.


Guenter



And if you ant it to work in 4.14 longterm, you want the series:

68546abf7a3a63f199e53d6dcaa7375df37a6aaa  hwmon: (k10temp) Move chip 
specific code into probe function
9af0a9aecdb945cd5513941ffdcbcc031009b402  hwmon: (k10temp) Add support 
for family 17h
1b50b776355fa6c6d7b3281a63c275d5c18d629d  hwmon: (k10temp) Add support 
for temperature offsets
ab5ee24615f9dd8b0cd199403959f8b13309e7b1  hwmon: (k10temp) Correct model 
name for Ryzen 1600X
6509614fdd2d05c6926d50901a45d5dfb852b715  hwmon: (k10temp) Add 
temperature offset for Ryzen 1900X
aef17ca1271948ee57cc39b2493d31110cc42625  hwmon: (k10temp) Only apply 
temperature offset if result is positive



We have it in Mageia, and I've confirmed it works on a Ryzen 7 1700 and 
ThreadRipper 1950X


--
Thomas

Re: [PATCH 4.14 00/75] 4.14.5-stable review

[Thomas Backlund]

Den 09.12.2017 kl. 19:13, skrev Greg Kroah-Hartman:

On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:

On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
 wrote:

On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:

I saw no problems on 8 of 9 machines, but the last one had a problem
because it used NVIDIA drivers (387); DKMS reported:

FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
symbol 'ex_handler_refcount'
//usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1


Is this a new issue?  Does 4.14.4 have this issue?


I believe it is a new issue, because I have a 4.14.4 build and an
NVIDIA DKMS log for that 4.14.4 showing build success.


Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
section for refcount exceptions") causing this?


That was my guess too, but I did not verify.


That feels really wrong here, I'd like to get some confirmation before I
add this patch...



It's needed.

The reason you hit in 4.14.5 queue is because of:

 [PATCH 4.14 64/75] locking/refcounts, x86/asm: Enable 
CONFIG_ARCH_HAS_REFCOUNT


From foo@baz Wed Dec  6 18:04:41 CET 2017
From: Kees Cook 
Date: Sat, 2 Sep 2017 13:09:46 -0700
Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT


that does this:

-   select ARCH_HAS_REFCOUNTif BROKEN
+   select ARCH_HAS_REFCOUNT



So it exposes previously hidden code

--
Thomas

Re: [PATCH 4.14 00/75] 4.14.5-stable review

[Thomas Backlund]

Den 09.12.2017 kl. 19:13, skrev Greg Kroah-Hartman:

On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:

On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
 wrote:

On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:

I saw no problems on 8 of 9 machines, but the last one had a problem
because it used NVIDIA drivers (387); DKMS reported:

FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
symbol 'ex_handler_refcount'
//usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1


Is this a new issue?  Does 4.14.4 have this issue?


I believe it is a new issue, because I have a 4.14.4 build and an
NVIDIA DKMS log for that 4.14.4 showing build success.


Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
section for refcount exceptions") causing this?


That was my guess too, but I did not verify.


That feels really wrong here, I'd like to get some confirmation before I
add this patch...



It's needed.

The reason you hit in 4.14.5 queue is because of:

 [PATCH 4.14 64/75] locking/refcounts, x86/asm: Enable 
CONFIG_ARCH_HAS_REFCOUNT


From foo@baz Wed Dec  6 18:04:41 CET 2017
From: Kees Cook 
Date: Sat, 2 Sep 2017 13:09:46 -0700
Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT


that does this:

-   select ARCH_HAS_REFCOUNTif BROKEN
+   select ARCH_HAS_REFCOUNT



So it exposes previously hidden code

--
Thomas

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

[Thomas Backlund]

Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman:

4.13-stable review patch.  If anyone has any objections, please let me know.

--

From: Steve French 

commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

Acked-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman 

---
  fs/cifs/smb2pdu.c |3 +++
  1 file changed, 3 insertions(+)

--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1963,6 +1963,9 @@ SMB2_ioctl(const unsigned int xid, struc
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
  
+	/* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */

+   if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+   req->hdr.sync_hdr.Flags |= SMB2_FLAGS_SIGNED;
  
  	rc = SendReceive2(xid, ses, iov, n_iov, _buftype, flags, _iov);

cifs_small_buf_release(req);





This one needs to be backported to all stable kernels as the commit that 
introduced the regression:

'
0603c96f3af50e2f9299fa410c224ab1d465e0f9
SMB: Validate negotiate (to protect against downgrade) even if signing off

is backported in stable trees as of: 4.9.53, 4.4.90, 3.18.73


--
Thomas

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

[Thomas Backlund]

Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman:

4.13-stable review patch.  If anyone has any objections, please let me know.

--

From: Steve French 

commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

Acked-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman 

---
  fs/cifs/smb2pdu.c |3 +++
  1 file changed, 3 insertions(+)

--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1963,6 +1963,9 @@ SMB2_ioctl(const unsigned int xid, struc
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
  
+	/* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */

+   if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+   req->hdr.sync_hdr.Flags |= SMB2_FLAGS_SIGNED;
  
  	rc = SendReceive2(xid, ses, iov, n_iov, _buftype, flags, _iov);

cifs_small_buf_release(req);





This one needs to be backported to all stable kernels as the commit that 
introduced the regression:

'
0603c96f3af50e2f9299fa410c224ab1d465e0f9
SMB: Validate negotiate (to protect against downgrade) even if signing off

is backported in stable trees as of: 4.9.53, 4.4.90, 3.18.73


--
Thomas

Re: [PATCH 1/2] Correct function definition for C++

[Thomas Backlund]

Den 22.02.2017 kl. 09:50, skrev Joakim Tjernlund:

On Wed, 2017-02-22 at 08:10 +0100, Greg KH wrote:

On Tue, Feb 21, 2017 at 04:24:04PM +0100, Joakim Tjernlund wrote:

C++ does does not like the extra extern before asmlinkage, remove it.

Signed-off-by: Joakim Tjernlund 
---
 include/linux/printk.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 3472cc6..be823f5 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h



Why are you building this file with a C++ compiler?


virtualbox uses C++ and includes various kernel headers and the build
fails, virtualbox guest additions has not build for quite some time now and
this is one of the problems.



You need this fix for virtualbox:

https://www.virtualbox.org/changeset/65874/vbox/trunk/configure

--

Thomas

Re: [PATCH 1/2] Correct function definition for C++

[Thomas Backlund]

Den 22.02.2017 kl. 09:50, skrev Joakim Tjernlund:

On Wed, 2017-02-22 at 08:10 +0100, Greg KH wrote:

On Tue, Feb 21, 2017 at 04:24:04PM +0100, Joakim Tjernlund wrote:

C++ does does not like the extra extern before asmlinkage, remove it.

Signed-off-by: Joakim Tjernlund 
---
 include/linux/printk.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 3472cc6..be823f5 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h



Why are you building this file with a C++ compiler?


virtualbox uses C++ and includes various kernel headers and the build
fails, virtualbox guest additions has not build for quite some time now and
this is one of the problems.



You need this fix for virtualbox:

https://www.virtualbox.org/changeset/65874/vbox/trunk/configure

--

Thomas

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Thomas Backlund]

Den 13.11.2016 kl. 17:34, skrev Philip Müller:

Hi Greg,

with inclusion of 'Fix data integrity failure for JBOD (passthrough)
devices' in v4.4.31, we currently have a regression with SCSI and macro
MEGASAS_IS_LOGICAL.

To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2]
reverted until it is merged in mainline.

The other patches seem fine.

kind regards, Philip Müller - Manjaro Project Lead

---

[1]
http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8
[2]
https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/4.4.31/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch




The needed fix is now upstream as:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8

--
Thomas

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Thomas Backlund]

Den 13.11.2016 kl. 17:34, skrev Philip Müller:

Hi Greg,

with inclusion of 'Fix data integrity failure for JBOD (passthrough)
devices' in v4.4.31, we currently have a regression with SCSI and macro
MEGASAS_IS_LOGICAL.

To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2]
reverted until it is merged in mainline.

The other patches seem fine.

kind regards, Philip Müller - Manjaro Project Lead

---

[1]
http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8
[2]
https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/4.4.31/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch




The needed fix is now upstream as:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8

--
Thomas

Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

[Thomas Backlund]

Den 01-07-2016 kl. 12:30, skrev Herbert Xu:

On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote:

Parallel build can sporadically fail because asn1 headers may
not be built yet by the time qat_asym_algs.o is compiled:
  drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: 
qat_rsapubkey-asn1.h: No such file or directory
   #include "qat_rsapubkey-asn1.h"

Signed-off-by: Jan Stancek 
Cc: Tadeusz Struk 
Cc: Herbert Xu 


Jan, Salvatore just posted a patch to delete the qat ASN code
altogether, so your patch won't be needed.

Thanks,



Yeah, but that patch seem to be heading to 4.8 only , so qat build in 
upcoming 4.7 still breaks...


and pulling that fix only to 4.7 breaks too, so I guess more fixes
would be needed for proper backport then...

or are the qat fixes already queued somewhere for 4.7 final ?

--
Thomas

Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

[Thomas Backlund]

Den 01-07-2016 kl. 12:30, skrev Herbert Xu:

On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote:

Parallel build can sporadically fail because asn1 headers may
not be built yet by the time qat_asym_algs.o is compiled:
  drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: 
qat_rsapubkey-asn1.h: No such file or directory
   #include "qat_rsapubkey-asn1.h"

Signed-off-by: Jan Stancek 
Cc: Tadeusz Struk 
Cc: Herbert Xu 


Jan, Salvatore just posted a patch to delete the qat ASN code
altogether, so your patch won't be needed.

Thanks,



Yeah, but that patch seem to be heading to 4.8 only , so qat build in 
upcoming 4.7 still breaks...


and pulling that fix only to 4.7 breaks too, so I guess more fixes
would be needed for proper backport then...

or are the qat fixes already queued somewhere for 4.7 final ?

--
Thomas

Re: [PATCH 4.1 39/46] sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()

[Thomas Backlund]

Den 23.10.2015 kl. 20:46, skrev Greg Kroah-Hartman:

4.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Konstantin Khlebnikov 

commit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream.


This one broke drivers/xen/  build


drivers/xen/preempt.c: In function ”xen_maybe_preempt_hcall”:
drivers/xen/preempt.c:34:11: error: too few arguments to function 
”should_resched”

&& should_resched())) {
   ^


Needed fix is:

From 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf Mon Sep 17 00:00:00 2001
From: Konstantin Khlebnikov 
Date: Wed, 15 Jul 2015 12:52:01 +0300
Subject: [PATCH] sched/preempt, xen: Use need_resched() instead of
 should_resched()


--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 39/46] sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()

[Thomas Backlund]

Den 23.10.2015 kl. 20:46, skrev Greg Kroah-Hartman:

4.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Konstantin Khlebnikov 

commit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream.


This one broke drivers/xen/  build


drivers/xen/preempt.c: In function ”xen_maybe_preempt_hcall”:
drivers/xen/preempt.c:34:11: error: too few arguments to function 
”should_resched”

&& should_resched())) {
   ^


Needed fix is:

From 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf Mon Sep 17 00:00:00 2001
From: Konstantin Khlebnikov 
Date: Wed, 15 Jul 2015 12:52:01 +0300
Subject: [PATCH] sched/preempt, xen: Use need_resched() instead of
 should_resched()


--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.19 176/177] netfilter: x_tables: fix cgroup matching on non-full sks

[Thomas Backlund]

Den 02.05.2015 22:03, Greg Kroah-Hartman skrev:

3.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.

While originally only being intended for outgoing traffic, commit
a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for
LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook
as well, in order to allow for nfacct accounting.

Besides being currently limited to early demuxes only, commit
a00e76349f35 forgot to add a check if we deal with full sockets,
i.e. in this case not with time wait sockets. TCP time wait sockets
do not have the same memory layout as full sockets, a lower memory
footprint and consequently also don't have a sk_classid member;
probing for sk_classid member there could potentially lead to a
crash.

Fixes: a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf 
hooks")
Cc: Alexey Perevalov 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman 

---
  net/netfilter/xt_cgroup.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/netfilter/xt_cgroup.c
+++ b/net/netfilter/xt_cgroup.c
@@ -39,7 +39,7 @@ cgroup_mt(const struct sk_buff *skb, str
  {
const struct xt_cgroup_info *info = par->matchinfo;

-   if (skb->sk == NULL)
+   if (skb->sk == NULL || !sk_fullsock(skb->sk))
return false;

return (info->id == skb->sk->sk_classid) ^ info->invert;





This one breaks the build with:

net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 
'sk_fullsock' [-Werror=implicit-function-declaration]



In order to fix it, you also need to add:

From 1d0ab253872cdd3d8e7913f59c266c7fd01771d0 Mon Sep 17 00:00:00 2001
From: Eric Dumazet 
Date: Sun, 15 Mar 2015 21:12:12 -0700
Subject: [PATCH] net: add sk_fullsock() helper


which in turn needs this one:

From 10feb428a5045d5eb18a5d755fbb8f0cc9645626 Mon Sep 17 00:00:00 2001
From: Eric Dumazet 
Date: Thu, 12 Mar 2015 16:44:04 -0700
Subject: [PATCH] inet: add TCP_NEW_SYN_RECV state

--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.19 176/177] netfilter: x_tables: fix cgroup matching on non-full sks

[Thomas Backlund]

Den 02.05.2015 22:03, Greg Kroah-Hartman skrev:

3.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann dan...@iogearbox.net

commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.

While originally only being intended for outgoing traffic, commit
a00e76349f35 (netfilter: x_tables: allow to use cgroup match for
LOCAL_IN nf hooks) enabled xt_cgroups for the NF_INET_LOCAL_IN hook
as well, in order to allow for nfacct accounting.

Besides being currently limited to early demuxes only, commit
a00e76349f35 forgot to add a check if we deal with full sockets,
i.e. in this case not with time wait sockets. TCP time wait sockets
do not have the same memory layout as full sockets, a lower memory
footprint and consequently also don't have a sk_classid member;
probing for sk_classid member there could potentially lead to a
crash.

Fixes: a00e76349f35 (netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf 
hooks)
Cc: Alexey Perevalov a.pereva...@samsung.com
Signed-off-by: Daniel Borkmann dan...@iogearbox.net
Signed-off-by: Pablo Neira Ayuso pa...@netfilter.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
  net/netfilter/xt_cgroup.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/netfilter/xt_cgroup.c
+++ b/net/netfilter/xt_cgroup.c
@@ -39,7 +39,7 @@ cgroup_mt(const struct sk_buff *skb, str
  {
const struct xt_cgroup_info *info = par-matchinfo;

-   if (skb-sk == NULL)
+   if (skb-sk == NULL || !sk_fullsock(skb-sk))
return false;

return (info-id == skb-sk-sk_classid) ^ info-invert;





This one breaks the build with:

net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 
'sk_fullsock' [-Werror=implicit-function-declaration]



In order to fix it, you also need to add:

From 1d0ab253872cdd3d8e7913f59c266c7fd01771d0 Mon Sep 17 00:00:00 2001
From: Eric Dumazet eduma...@google.com
Date: Sun, 15 Mar 2015 21:12:12 -0700
Subject: [PATCH] net: add sk_fullsock() helper


which in turn needs this one:

From 10feb428a5045d5eb18a5d755fbb8f0cc9645626 Mon Sep 17 00:00:00 2001
From: Eric Dumazet eduma...@google.com
Date: Thu, 12 Mar 2015 16:44:04 -0700
Subject: [PATCH] inet: add TCP_NEW_SYN_RECV state

--
Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 81/94] libata: support the ata host which implements a queue depth less than 32

[Thomas Backlund]

Jiri Slaby skrev den 30.7.2014 15:15:

From: Kevin Hao 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.

The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
("libata/ahci: accommodate tag ordered controllers"). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.

Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
Signed-off-by: Kevin Hao 
Acked-by: Dan Williams 
Signed-off-by: Tejun Heo 
Signed-off-by: Jiri Slaby 


As you have added this to 3.12 branch, you also need to add this to 
avoid SAS breakage:


commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6
Author: Tejun Heo 
Date:   Wed Jul 23 09:05:27 2014 -0400

libata: introduce ata_host->n_tags to avoid oops on SAS controllers

1871ee134b73 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

--

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 81/94] libata: support the ata host which implements a queue depth less than 32

[Thomas Backlund]

Jiri Slaby skrev den 30.7.2014 15:15:

From: Kevin Hao haoke...@gmail.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.

The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
(libata/ahci: accommodate tag ordered controllers). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.

Fixes: 8a4aeec8d2d6 (libata/ahci: accommodate tag ordered controllers)
Signed-off-by: Kevin Hao haoke...@gmail.com
Acked-by: Dan Williams dan.j.willi...@intel.com
Signed-off-by: Tejun Heo t...@kernel.org
Signed-off-by: Jiri Slaby jsl...@suse.cz


As you have added this to 3.12 branch, you also need to add this to 
avoid SAS breakage:


commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6
Author: Tejun Heo t...@kernel.org
Date:   Wed Jul 23 09:05:27 2014 -0400

libata: introduce ata_host-n_tags to avoid oops on SAS controllers

1871ee134b73 (libata: support the ata host which implements a queue
depth less than 32) directly used ata_port-scsi_host-can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize -scsi_host
leading to the following oops.

--

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.13 000/149] 3.13.7-stable review

[Thomas Backlund]

Guenter Roeck skrev 21.3.2014 07:37:

On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.13.7 release.
There are 149 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 Sun Mar 23 00:03:54 UTC 2014.
Anything received after that time might be too late.



Build results:
 total: 126 pass: 120 skipped: 4 fail: 2

qemu tests all passed.

There are two new build failures.

Building powerpc:mpc85xx_defconfig ... failed
Building powerpc:mpc85xx_smp_defconfig ... failed

The failure is the same in both cases.

drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup':
drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of
function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of
function 'of_iomap' [-Werror=implicit-function-declaration]

It appears you picked this up from the latest mainline, where the
same builds fail with the same error. The problem was introduced
in mainline between rc6 and rc7.

I have no immediate idea which patch causes the problem.
I can bisect tomorrow if needed.


Probably this one exposing additional code to be built:


From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001
From: Richard Weinberger 
Date: Sun, 9 Feb 2014 19:47:40 +0100
Subject: i2c: Remove usage of orphaned symbol OF_I2C

From: Richard Weinberger 

commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream.

The symbol is an orphan, don't depend on it anymore.

Signed-off-by: Richard Weinberger 
[wsa: enhanced commit message]
Signed-off-by: Wolfram Sang 
Fixes: 687b81d083c0 (i2c: move OF helpers into the core)
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/i2c/busses/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,7 +387,7 @@ config I2C_CBUS_GPIO

 config I2C_CPM
tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
-   depends on (CPM1 || CPM2) && OF_I2C
+   depends on CPM1 || CPM2
help
  This supports the use of the I2C interface on Freescale
  processors with CPM1 or CPM2.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.13 000/149] 3.13.7-stable review

[Thomas Backlund]

Thomas Backlund skrev 21.3.2014 10:42:

Guenter Roeck skrev 21.3.2014 07:37:

On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.13.7 release.
There are 149 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 Sun Mar 23 00:03:54 UTC 2014.
Anything received after that time might be too late.



Build results:
 total: 126 pass: 120 skipped: 4 fail: 2

qemu tests all passed.

There are two new build failures.

Building powerpc:mpc85xx_defconfig ... failed
Building powerpc:mpc85xx_smp_defconfig ... failed

The failure is the same in both cases.

drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup':
drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of
function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of
function 'of_iomap' [-Werror=implicit-function-declaration]

It appears you picked this up from the latest mainline, where the
same builds fail with the same error. The problem was introduced
in mainline between rc6 and rc7.

I have no immediate idea which patch causes the problem.
I can bisect tomorrow if needed.


Probably this one exposing additional code to be built:


 From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001
From: Richard Weinberger 
Date: Sun, 9 Feb 2014 19:47:40 +0100
Subject: i2c: Remove usage of orphaned symbol OF_I2C

From: Richard Weinberger 

commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream.

The symbol is an orphan, don't depend on it anymore.

Signed-off-by: Richard Weinberger 
[wsa: enhanced commit message]
Signed-off-by: Wolfram Sang 
Fixes: 687b81d083c0 (i2c: move OF helpers into the core)
Signed-off-by: Greg Kroah-Hartman 

---
  drivers/i2c/busses/Kconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,7 +387,7 @@ config I2C_CBUS_GPIO

  config I2C_CPM
 tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
-   depends on (CPM1 || CPM2) && OF_I2C
+   depends on CPM1 || CPM2
 help
   This supports the use of the I2C interface on Freescale
   processors with CPM1 or CPM2.





and the buildfix was posted to upstream and -stable a couple of days ago 
(not in upstream linus tree yet), with subject:


[PATCH] i2c-cpm: Fix build by adding of_address.h and of_irq.h


Fixes a build break due to the undeclared use of irq_of_parse_and_map()
and of_iomap().  This build break was apparently introduced while the
driver was unbuildable due to the bug fixed by
62c19c9d29e65086e5ae76df371ed2e6b23f00cd ("i2c: Remove usage of
orphaned symbol OF_I2C").  When 62c19c was added in v3.14-rc7,
the driver was enabled again, breaking the powerpc mpc85xx_defconfig
and mpc85xx_smp_defconfig.

62c19c is marked for stable, so this should go there as well.

Signed-off-by: Scott Wood 
Reported-by: Geert Uytterhoeven 
Cc: Richard Weinberger 
Cc: sta...@kernel.org
---
There are still warnings in this driver that suggest it is broken with
CONFIG_PHYS_64BIT, but that part does not appear to be a regression.

 drivers/i2c/busses/i2c-cpm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index be7f0a2..f3b89a4 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -39,7 +39,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
--
1.8.3.2


--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.13 000/149] 3.13.7-stable review

[Thomas Backlund]

Thomas Backlund skrev 21.3.2014 10:42:

Guenter Roeck skrev 21.3.2014 07:37:

On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.13.7 release.
There are 149 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 Sun Mar 23 00:03:54 UTC 2014.
Anything received after that time might be too late.



Build results:
 total: 126 pass: 120 skipped: 4 fail: 2

qemu tests all passed.

There are two new build failures.

Building powerpc:mpc85xx_defconfig ... failed
Building powerpc:mpc85xx_smp_defconfig ... failed

The failure is the same in both cases.

drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup':
drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of
function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of
function 'of_iomap' [-Werror=implicit-function-declaration]

It appears you picked this up from the latest mainline, where the
same builds fail with the same error. The problem was introduced
in mainline between rc6 and rc7.

I have no immediate idea which patch causes the problem.
I can bisect tomorrow if needed.


Probably this one exposing additional code to be built:


 From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001
From: Richard Weinberger rich...@nod.at
Date: Sun, 9 Feb 2014 19:47:40 +0100
Subject: i2c: Remove usage of orphaned symbol OF_I2C

From: Richard Weinberger rich...@nod.at

commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream.

The symbol is an orphan, don't depend on it anymore.

Signed-off-by: Richard Weinberger rich...@nod.at
[wsa: enhanced commit message]
Signed-off-by: Wolfram Sang w...@the-dreams.de
Fixes: 687b81d083c0 (i2c: move OF helpers into the core)
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
  drivers/i2c/busses/Kconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,7 +387,7 @@ config I2C_CBUS_GPIO

  config I2C_CPM
 tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
-   depends on (CPM1 || CPM2)  OF_I2C
+   depends on CPM1 || CPM2
 help
   This supports the use of the I2C interface on Freescale
   processors with CPM1 or CPM2.





and the buildfix was posted to upstream and -stable a couple of days ago 
(not in upstream linus tree yet), with subject:


[PATCH] i2c-cpm: Fix build by adding of_address.h and of_irq.h


Fixes a build break due to the undeclared use of irq_of_parse_and_map()
and of_iomap().  This build break was apparently introduced while the
driver was unbuildable due to the bug fixed by
62c19c9d29e65086e5ae76df371ed2e6b23f00cd (i2c: Remove usage of
orphaned symbol OF_I2C).  When 62c19c was added in v3.14-rc7,
the driver was enabled again, breaking the powerpc mpc85xx_defconfig
and mpc85xx_smp_defconfig.

62c19c is marked for stable, so this should go there as well.

Signed-off-by: Scott Wood scottw...@freescale.com
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Richard Weinberger rich...@nod.at
Cc: sta...@kernel.org
---
There are still warnings in this driver that suggest it is broken with
CONFIG_PHYS_64BIT, but that part does not appear to be a regression.

 drivers/i2c/busses/i2c-cpm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index be7f0a2..f3b89a4 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -39,7 +39,9 @@
 #include linux/i2c.h
 #include linux/io.h
 #include linux/dma-mapping.h
+#include linux/of_address.h
 #include linux/of_device.h
+#include linux/of_irq.h
 #include linux/of_platform.h
 #include sysdev/fsl_soc.h
 #include asm/cpm.h
--
1.8.3.2


--
Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.13 000/149] 3.13.7-stable review

[Thomas Backlund]

Guenter Roeck skrev 21.3.2014 07:37:

On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.13.7 release.
There are 149 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 Sun Mar 23 00:03:54 UTC 2014.
Anything received after that time might be too late.



Build results:
 total: 126 pass: 120 skipped: 4 fail: 2

qemu tests all passed.

There are two new build failures.

Building powerpc:mpc85xx_defconfig ... failed
Building powerpc:mpc85xx_smp_defconfig ... failed

The failure is the same in both cases.

drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup':
drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of
function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of
function 'of_iomap' [-Werror=implicit-function-declaration]

It appears you picked this up from the latest mainline, where the
same builds fail with the same error. The problem was introduced
in mainline between rc6 and rc7.

I have no immediate idea which patch causes the problem.
I can bisect tomorrow if needed.


Probably this one exposing additional code to be built:


From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001
From: Richard Weinberger rich...@nod.at
Date: Sun, 9 Feb 2014 19:47:40 +0100
Subject: i2c: Remove usage of orphaned symbol OF_I2C

From: Richard Weinberger rich...@nod.at

commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream.

The symbol is an orphan, don't depend on it anymore.

Signed-off-by: Richard Weinberger rich...@nod.at
[wsa: enhanced commit message]
Signed-off-by: Wolfram Sang w...@the-dreams.de
Fixes: 687b81d083c0 (i2c: move OF helpers into the core)
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 drivers/i2c/busses/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,7 +387,7 @@ config I2C_CBUS_GPIO

 config I2C_CPM
tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
-   depends on (CPM1 || CPM2)  OF_I2C
+   depends on CPM1 || CPM2
help
  This supports the use of the I2C interface on Freescale
  processors with CPM1 or CPM2.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZRAM 3.10.6 Buffer I/O error

[Thomas Backlund]

Minchan Kim skrev 13.8.2013 07:33:

Hello Greg,

On Mon, Aug 12, 2013 at 08:58:02PM -0700, Greg Kroah-Hartman wrote:

On Tue, Aug 13, 2013 at 10:39:00AM +0900, Minchan Kim wrote:

Hello,

On Mon, Aug 12, 2013 at 07:39:46PM +0300, Thomas Backlund wrote:

12.08.2013 17:27, Jordi Pujol skrev:

Hello,

zram shows an error when mounting a swap partition,
current version Linux kernel 3.10.6,
previous versions worked, I suppose that latest zram patches have some
problem,

machine is an AMD64 dual core, 4GB RAM

+ modprobe -qb zram num_devices=2
+ echo 104857600 > /sys/block/zram0/disksize

# mkswap /dev/zram0
Setting up swapspace version 1, size = 102396 KiB
no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d

# pager /var/log/dmesg
(no more errors shown)

# swapon /dev/zram0

# pager /var/log/dmesg
...
[  309.300479] Buffer I/O error on device zram0, logical block 25599
[  309.300491] Buffer I/O error on device zram0, logical block 25599
[  309.300514] Buffer I/O error on device zram0, logical block 25599
[  345.205887] Adding 102396k swap on /dev/zram0.  Priority:-2 extents:1
across:102396k SSFS

full log files and the kernel source are stored in the address:

http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/




I think this one should fix it and belongs in 3.10 stable too:


Very true. Let's Cc Greg, explicitely.


-ENOCONTEXT


https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/staging/zram?id=75c7caf5a052ffd8db3312fa7864ee2d142890c4

It seems you already merge "zram:allow request end to conincide with disksize" 
to stable.
So there is no concern any more.


Nope...

thats master branch wich tracks upstream tree...

it's not in the 3.10 stable as of 3.10.6 (or current stable queue)

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/staging/zram?h=linux-3.10.y

--

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZRAM 3.10.6 Buffer I/O error

[Thomas Backlund]

12.08.2013 17:27, Jordi Pujol skrev:

Hello,

zram shows an error when mounting a swap partition,
current version Linux kernel 3.10.6,
previous versions worked, I suppose that latest zram patches have some
problem,

machine is an AMD64 dual core, 4GB RAM

+ modprobe -qb zram num_devices=2
+ echo 104857600 > /sys/block/zram0/disksize

# mkswap /dev/zram0
Setting up swapspace version 1, size = 102396 KiB
no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d

# pager /var/log/dmesg
(no more errors shown)

# swapon /dev/zram0

# pager /var/log/dmesg
...
[  309.300479] Buffer I/O error on device zram0, logical block 25599
[  309.300491] Buffer I/O error on device zram0, logical block 25599
[  309.300514] Buffer I/O error on device zram0, logical block 25599
[  345.205887] Adding 102396k swap on /dev/zram0.  Priority:-2 extents:1
across:102396k SSFS

full log files and the kernel source are stored in the address:

http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/




I think this one should fix it and belongs in 3.10 stable too:

From 75c7caf5a052ffd8db3312fa7864ee2d142890c4 Mon Sep 17 00:00:00 2001
From: Sergey Senozhatsky 
Date: Sat, 22 Jun 2013 14:21:00 +
Subject: zram: allow request end to coincide with disksize

Pass valid_io_request() checks if request end coincides with disksize
(end equals bound), only fail if we attempt to read beyond the bound.

mkfs.ext2 produces numerous errors:
[ 2164.632747] quiet_error: 1 callbacks suppressed
[ 2164.633260] Buffer I/O error on device zram0, logical block 153599
[ 2164.633265] lost page write due to I/O error on zram0

Signed-off-by: Sergey Senozhatsky 
Signed-off-by: Greg Kroah-Hartman 
---
diff --git a/drivers/staging/zram/zram_drv.c 
b/drivers/staging/zram/zram_drv.c

index 7538774..82c7202 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -180,7 +180,7 @@ static inline int valid_io_request(struct zram 
*zram, struct bio *bio)

end = start + (bio->bi_size >> SECTOR_SHIFT);
bound = zram->disksize >> SECTOR_SHIFT;
/* out of range range */
-   if (unlikely(start >= bound || end >= bound || start > end))
+   if (unlikely(start >= bound || end > bound || start > end))
return 0;

/* I/O request is valid */
--
cgit v0.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZRAM 3.10.6 Buffer I/O error

[Thomas Backlund]

12.08.2013 17:27, Jordi Pujol skrev:

Hello,

zram shows an error when mounting a swap partition,
current version Linux kernel 3.10.6,
previous versions worked, I suppose that latest zram patches have some
problem,

machine is an AMD64 dual core, 4GB RAM

+ modprobe -qb zram num_devices=2
+ echo 104857600  /sys/block/zram0/disksize

# mkswap /dev/zram0
Setting up swapspace version 1, size = 102396 KiB
no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d

# pager /var/log/dmesg
(no more errors shown)

# swapon /dev/zram0

# pager /var/log/dmesg
...
[  309.300479] Buffer I/O error on device zram0, logical block 25599
[  309.300491] Buffer I/O error on device zram0, logical block 25599
[  309.300514] Buffer I/O error on device zram0, logical block 25599
[  345.205887] Adding 102396k swap on /dev/zram0.  Priority:-2 extents:1
across:102396k SSFS

full log files and the kernel source are stored in the address:

http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/




I think this one should fix it and belongs in 3.10 stable too:

From 75c7caf5a052ffd8db3312fa7864ee2d142890c4 Mon Sep 17 00:00:00 2001
From: Sergey Senozhatsky sergey.senozhat...@gmail.com
Date: Sat, 22 Jun 2013 14:21:00 +
Subject: zram: allow request end to coincide with disksize

Pass valid_io_request() checks if request end coincides with disksize
(end equals bound), only fail if we attempt to read beyond the bound.

mkfs.ext2 produces numerous errors:
[ 2164.632747] quiet_error: 1 callbacks suppressed
[ 2164.633260] Buffer I/O error on device zram0, logical block 153599
[ 2164.633265] lost page write due to I/O error on zram0

Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
diff --git a/drivers/staging/zram/zram_drv.c 
b/drivers/staging/zram/zram_drv.c

index 7538774..82c7202 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -180,7 +180,7 @@ static inline int valid_io_request(struct zram 
*zram, struct bio *bio)

end = start + (bio-bi_size  SECTOR_SHIFT);
bound = zram-disksize  SECTOR_SHIFT;
/* out of range range */
-   if (unlikely(start = bound || end = bound || start  end))
+   if (unlikely(start = bound || end  bound || start  end))
return 0;

/* I/O request is valid */
--
cgit v0.9.2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZRAM 3.10.6 Buffer I/O error

[Thomas Backlund]

Minchan Kim skrev 13.8.2013 07:33:

Hello Greg,

On Mon, Aug 12, 2013 at 08:58:02PM -0700, Greg Kroah-Hartman wrote:

On Tue, Aug 13, 2013 at 10:39:00AM +0900, Minchan Kim wrote:

Hello,

On Mon, Aug 12, 2013 at 07:39:46PM +0300, Thomas Backlund wrote:

12.08.2013 17:27, Jordi Pujol skrev:

Hello,

zram shows an error when mounting a swap partition,
current version Linux kernel 3.10.6,
previous versions worked, I suppose that latest zram patches have some
problem,

machine is an AMD64 dual core, 4GB RAM

+ modprobe -qb zram num_devices=2
+ echo 104857600  /sys/block/zram0/disksize

# mkswap /dev/zram0
Setting up swapspace version 1, size = 102396 KiB
no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d

# pager /var/log/dmesg
(no more errors shown)

# swapon /dev/zram0

# pager /var/log/dmesg
...
[  309.300479] Buffer I/O error on device zram0, logical block 25599
[  309.300491] Buffer I/O error on device zram0, logical block 25599
[  309.300514] Buffer I/O error on device zram0, logical block 25599
[  345.205887] Adding 102396k swap on /dev/zram0.  Priority:-2 extents:1
across:102396k SSFS

full log files and the kernel source are stored in the address:

http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/




I think this one should fix it and belongs in 3.10 stable too:


Very true. Let's Cc Greg, explicitely.


-ENOCONTEXT


https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/staging/zram?id=75c7caf5a052ffd8db3312fa7864ee2d142890c4

It seems you already merge zram:allow request end to conincide with disksize 
to stable.
So there is no concern any more.


Nope...

thats master branch wich tracks upstream tree...

it's not in the 3.10 stable as of 3.10.6 (or current stable queue)

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/staging/zram?h=linux-3.10.y

--

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

[Thomas Backlund]

18.07.2013 13:37, Neil Horman skrev:

On Thu, Jul 18, 2013 at 11:02:00AM +0300, Thomas Backlund wrote:

18.07.2013 01:47, Kamal Mostafa skrev:

3.8.13.5 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Neil Horman 

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream.

A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

[ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ]

Signed-off-by: Neil Horman 
CC: Prarit Bhargava 
CC: Don Zickus 
CC: Don Dutile 
CC: Bjorn Helgaas 
CC: Asit Mallick 
CC: David Woodhouse 
CC: linux-...@vger.kernel.org
CC: Joerg Roedel 
CC: Konrad Rzeszutek Wilk 
CC: Arkadiusz Miśkiewicz 
Signed-off-by: Joerg Roedel 
Signed-off-by: Luis Henriques 
---
  arch/x86/include/asm/irq_remapping.h |  2 ++
  arch/x86/kernel/early-quirks.c   | 20 
  drivers/iommu/intel_irq_remapping.c  | 10 ++
  drivers/iommu/irq_remapping.c|  6 ++
  drivers/iommu/irq_remapping.h|  2 ++
  5 files changed, 40 insertions(+)



This patch introduces this warning on 3.8 series kernels:

In file included from arch/x86/kernel/early-quirks.c:21:0:
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10:
varning: ”struct irq_data” deklarerad inuti parameterlista
[aktiverat som standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10:
varning: dess scope-område är endast denna definition eller
deklaration, vilket troligen inte är vad du vill. [aktiverat som
standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17:
varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat
som standard]


You need to add this upstream fix too:

commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd
Author: Joerg Roedel 
Date:   Fri Apr 19 20:34:55 2013 +0200

 iommu: Fix compile warnings with forward declarations


I submited a 3.9 backport that included that fix to -stable over a week ago, you
should just be able to use that if you want.
Neil


Almost, but not enough...

The patch you refer to was:
[3.9 stable PATCH] iommu/vt-d: add quirk for broken interrupt remapping 
on 55XX chipsets


and got merged in 3.9.9.

And that added a missing: "#include " in
arch/x86/include/asm/irq_remapping.h

But using that patch it still spits out:

kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17:
>> varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat
>> som standard]


which is why the additional patch is still needed...

--

Thomas


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

[Thomas Backlund]

18.07.2013 01:47, Kamal Mostafa skrev:

3.8.13.5 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Neil Horman 

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream.

A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

[ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ]

Signed-off-by: Neil Horman 
CC: Prarit Bhargava 
CC: Don Zickus 
CC: Don Dutile 
CC: Bjorn Helgaas 
CC: Asit Mallick 
CC: David Woodhouse 
CC: linux-...@vger.kernel.org
CC: Joerg Roedel 
CC: Konrad Rzeszutek Wilk 
CC: Arkadiusz Miśkiewicz 
Signed-off-by: Joerg Roedel 
Signed-off-by: Luis Henriques 
---
  arch/x86/include/asm/irq_remapping.h |  2 ++
  arch/x86/kernel/early-quirks.c   | 20 
  drivers/iommu/intel_irq_remapping.c  | 10 ++
  drivers/iommu/irq_remapping.c|  6 ++
  drivers/iommu/irq_remapping.h|  2 ++
  5 files changed, 40 insertions(+)



This patch introduces this warning on 3.8 series kernels:

In file included from arch/x86/kernel/early-quirks.c:21:0:
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: 
varning: ”struct irq_data” deklarerad inuti parameterlista [aktiverat 
som standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: 
varning: dess scope-område är endast denna definition eller deklaration, 
vilket troligen inte är vad du vill. [aktiverat som standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: 
varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som 
standard]



You need to add this upstream fix too:

commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd
Author: Joerg Roedel 
Date:   Fri Apr 19 20:34:55 2013 +0200

iommu: Fix compile warnings with forward declarations


--

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

[Thomas Backlund]

18.07.2013 01:47, Kamal Mostafa skrev:

3.8.13.5 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Neil Horman nhor...@tuxdriver.com

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream.

A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

[ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ]

Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Prarit Bhargava pra...@redhat.com
CC: Don Zickus dzic...@redhat.com
CC: Don Dutile ddut...@redhat.com
CC: Bjorn Helgaas bhelg...@google.com
CC: Asit Mallick asit.k.mall...@intel.com
CC: David Woodhouse dw...@infradead.org
CC: linux-...@vger.kernel.org
CC: Joerg Roedel j...@8bytes.org
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: Arkadiusz Miśkiewicz ar...@maven.pl
Signed-off-by: Joerg Roedel j...@8bytes.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
  arch/x86/include/asm/irq_remapping.h |  2 ++
  arch/x86/kernel/early-quirks.c   | 20 
  drivers/iommu/intel_irq_remapping.c  | 10 ++
  drivers/iommu/irq_remapping.c|  6 ++
  drivers/iommu/irq_remapping.h|  2 ++
  5 files changed, 40 insertions(+)



This patch introduces this warning on 3.8 series kernels:

In file included from arch/x86/kernel/early-quirks.c:21:0:
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: 
varning: ”struct irq_data” deklarerad inuti parameterlista [aktiverat 
som standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: 
varning: dess scope-område är endast denna definition eller deklaration, 
vilket troligen inte är vad du vill. [aktiverat som standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: 
varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som 
standard]



You need to add this upstream fix too:

commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd
Author: Joerg Roedel j...@8bytes.org
Date:   Fri Apr 19 20:34:55 2013 +0200

iommu: Fix compile warnings with forward declarations


--

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

[Thomas Backlund]

18.07.2013 13:37, Neil Horman skrev:

On Thu, Jul 18, 2013 at 11:02:00AM +0300, Thomas Backlund wrote:

18.07.2013 01:47, Kamal Mostafa skrev:

3.8.13.5 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Neil Horman nhor...@tuxdriver.com

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream.

A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

[ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ]

Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Prarit Bhargava pra...@redhat.com
CC: Don Zickus dzic...@redhat.com
CC: Don Dutile ddut...@redhat.com
CC: Bjorn Helgaas bhelg...@google.com
CC: Asit Mallick asit.k.mall...@intel.com
CC: David Woodhouse dw...@infradead.org
CC: linux-...@vger.kernel.org
CC: Joerg Roedel j...@8bytes.org
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: Arkadiusz Miśkiewicz ar...@maven.pl
Signed-off-by: Joerg Roedel j...@8bytes.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
  arch/x86/include/asm/irq_remapping.h |  2 ++
  arch/x86/kernel/early-quirks.c   | 20 
  drivers/iommu/intel_irq_remapping.c  | 10 ++
  drivers/iommu/irq_remapping.c|  6 ++
  drivers/iommu/irq_remapping.h|  2 ++
  5 files changed, 40 insertions(+)



This patch introduces this warning on 3.8 series kernels:

In file included from arch/x86/kernel/early-quirks.c:21:0:
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10:
varning: ”struct irq_data” deklarerad inuti parameterlista
[aktiverat som standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10:
varning: dess scope-område är endast denna definition eller
deklaration, vilket troligen inte är vad du vill. [aktiverat som
standard]
/kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17:
varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat
som standard]


You need to add this upstream fix too:

commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd
Author: Joerg Roedel j...@8bytes.org
Date:   Fri Apr 19 20:34:55 2013 +0200

 iommu: Fix compile warnings with forward declarations


I submited a 3.9 backport that included that fix to -stable over a week ago, you
should just be able to use that if you want.
Neil


Almost, but not enough...

The patch you refer to was:
[3.9 stable PATCH] iommu/vt-d: add quirk for broken interrupt remapping 
on 55XX chipsets


and got merged in 3.9.9.

And that added a missing: #include linux/irq.h in
arch/x86/include/asm/irq_remapping.h

But using that patch it still spits out:

kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17:
 varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat
 som standard]


which is why the additional patch is still needed...

--

Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

perf 3.8-rc build failure: undefined reference to `strlcpy'

[Thomas Backlund]

[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 
prefix=%{_prefix} all


...

/tmp/ccJEJv6m.o: In function `main':
:(.text+0x14): undefined reference to `strlcpy'
collect2: ld returned 1 exit status

...

This did not show up in 3.7

--
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/74] perf python: Fix breakage introduced by the test_attr infrastructure

[Thomas Backlund]

Arnaldo Carvalho de Melo skrev 24.1.2013 22:07:

From: Arnaldo Carvalho de Melo 

The test_attr infrastructure hooks on the sys_perf_event_open call,
checking if a variable is set and if so calling a function to intercept
calls and do the checking.

But both the variable and the function aren't on objects that are
linked on the python binding, breaking it:




Atleast this one is 3.8 material as it is a regression since 3.7

[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 
prefix=%{_prefix} all


python_ext_build/tmp/util/evsel.o: In function `sys_perf_event_open':
/mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:183: 
undefined reference to `test_attr__enabled'
/mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:184: 
undefined reference to `test_attr__open'

collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

--
Thomas




   # perf test -v 15
   15: Try 'use perf' in python, checking link problems   :
   --- start ---
   Traceback (most recent call last):
 File "", line 1, in 
   ImportError: /home/acme/git/build/perf//python/perf.so: undefined symbol: 
test_attr__enabled
    end 
   Try 'use perf' in python, checking link problems: FAILED!
   #

Fix it by moving the variable to one of the linked object files and
providing a stub for the function in the python.o object, that is only
linked in the python binding.

Now 'perf test' is happy again:

   # perf test 15
   15: Try 'use perf' in python, checking link problems   : Ok
   #

Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Mike Galbraith 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-0rsca2kn44b38rgdpr3tz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
  tools/perf/tests/attr.c  | 2 --
  tools/perf/util/python.c | 9 +
  tools/perf/util/util.c   | 2 ++
  3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index 25638a9..05b5acb 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -33,8 +33,6 @@

  extern int verbose;

-bool test_attr__enabled;
-
  static char *dir;

  void test_attr__init(void)
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index a2657fd..925e0c3 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -1045,3 +1045,12 @@ error:
if (PyErr_Occurred())
PyErr_SetString(PyExc_ImportError, "perf: Init failed!");
  }
+
+/*
+ * Dummy, to avoid dragging all the test_attr infrastructure in the python
+ * binding.
+ */
+void test_attr__open(struct perf_event_attr *attr, pid_t pid, int cpu,
+ int fd, int group_fd, unsigned long flags)
+{
+}
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 5906e84..252b889 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -12,6 +12,8 @@
   */
  unsigned int page_size;

+bool test_attr__enabled;
+
  bool perf_host  = true;
  bool perf_guest = false;




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

the patch "perf tools: Update Makefile for Android" broke 3.8-rc perf build.

[Thomas Backlund]

Linux Kernel Mailing List skrev 12.12.2012 05:13:

Gitweb: 
http://git.kernel.org/linus/;a=commit;h=d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
Commit: d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
Parent: 78da39faf7c903bb6e3c20a726fde1bf98d10af8
Author: Irina Tirdea 
AuthorDate: Mon Oct 8 09:43:27 2012 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon Oct 8 17:42:16 2012 -0300

 perf tools: Update Makefile for Android

 For cross-compiling on Android, some specific changes are needed in
 the Makefile.



The above patch broke perf build on i586 and x86_64:

[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 
prefix=%{_prefix} all

CHK -fstack-protector-all
CHK -Wstack-protector
CHK -Wvolatile-register-var
CHK bionic
:1:31: fatal error: android/api-level.h: No such file or directory
compilation terminated.


This is a regression since 3.7
--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

the patch perf tools: Update Makefile for Android broke 3.8-rc perf build.

[Thomas Backlund]

Linux Kernel Mailing List skrev 12.12.2012 05:13:

Gitweb: 
http://git.kernel.org/linus/;a=commit;h=d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
Commit: d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
Parent: 78da39faf7c903bb6e3c20a726fde1bf98d10af8
Author: Irina Tirdea irina.tir...@intel.com
AuthorDate: Mon Oct 8 09:43:27 2012 +0300
Committer:  Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon Oct 8 17:42:16 2012 -0300

 perf tools: Update Makefile for Android

 For cross-compiling on Android, some specific changes are needed in
 the Makefile.



The above patch broke perf build on i586 and x86_64:

[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 
prefix=%{_prefix} all

CHK -fstack-protector-all
CHK -Wstack-protector
CHK -Wvolatile-register-var
CHK bionic
stdin:1:31: fatal error: android/api-level.h: No such file or directory
compilation terminated.


This is a regression since 3.7
--
Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/74] perf python: Fix breakage introduced by the test_attr infrastructure

[Thomas Backlund]

Arnaldo Carvalho de Melo skrev 24.1.2013 22:07:

From: Arnaldo Carvalho de Melo a...@redhat.com

The test_attr infrastructure hooks on the sys_perf_event_open call,
checking if a variable is set and if so calling a function to intercept
calls and do the checking.

But both the variable and the function aren't on objects that are
linked on the python binding, breaking it:




Atleast this one is 3.8 material as it is a regression since 3.7

[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 
prefix=%{_prefix} all


python_ext_build/tmp/util/evsel.o: In function `sys_perf_event_open':
/mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:183: 
undefined reference to `test_attr__enabled'
/mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:184: 
undefined reference to `test_attr__open'

collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

--
Thomas




   # perf test -v 15
   15: Try 'use perf' in python, checking link problems   :
   --- start ---
   Traceback (most recent call last):
 File stdin, line 1, in module
   ImportError: /home/acme/git/build/perf//python/perf.so: undefined symbol: 
test_attr__enabled
    end 
   Try 'use perf' in python, checking link problems: FAILED!
   #

Fix it by moving the variable to one of the linked object files and
providing a stub for the function in the python.o object, that is only
linked in the python binding.

Now 'perf test' is happy again:

   # perf test 15
   15: Try 'use perf' in python, checking link problems   : Ok
   #

Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@gmail.com
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-0rsca2kn44b38rgdpr3tz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
  tools/perf/tests/attr.c  | 2 --
  tools/perf/util/python.c | 9 +
  tools/perf/util/util.c   | 2 ++
  3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index 25638a9..05b5acb 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -33,8 +33,6 @@

  extern int verbose;

-bool test_attr__enabled;
-
  static char *dir;

  void test_attr__init(void)
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index a2657fd..925e0c3 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -1045,3 +1045,12 @@ error:
if (PyErr_Occurred())
PyErr_SetString(PyExc_ImportError, perf: Init failed!);
  }
+
+/*
+ * Dummy, to avoid dragging all the test_attr infrastructure in the python
+ * binding.
+ */
+void test_attr__open(struct perf_event_attr *attr, pid_t pid, int cpu,
+ int fd, int group_fd, unsigned long flags)
+{
+}
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 5906e84..252b889 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -12,6 +12,8 @@
   */
  unsigned int page_size;

+bool test_attr__enabled;
+
  bool perf_host  = true;
  bool perf_guest = false;




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

perf 3.8-rc build failure: undefined reference to `strlcpy'

[Thomas Backlund]

[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 
prefix=%{_prefix} all


...

/tmp/ccJEJv6m.o: In function `main':
:(.text+0x14): undefined reference to `strlcpy'
collect2: ld returned 1 exit status

...

This did not show up in 3.7

--
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi

[Thomas Backlund]

Cong Wang skrev 15.1.2013 12:11:

On Tue, 2013-01-15 at 12:03 +0200, Thomas Backlund wrote:

Eric Blake skrev 15.1.2013 01:57:

On 01/13/2013 01:05 PM, Thomas Backlund wrote:

Thomas Backlund skrev 13.1.2013 20:38:

patch both inline and attached as thunderbird tends to mess up ...



-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.



Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...

Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:

config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has
incomplete type


Hmm, just now noticing this thread, after independently hitting and and
having to work around the same problem in libvirt:
https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html
https://bugzilla.redhat.com/show_bug.cgi?id=895141



Yep,

and the commit breaking uapi headers is by using "struct in6_addr ip6" is:


  From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001
From: Cong Wang 
Date: Fri, 7 Dec 2012 00:04:48 +
Subject: [PATCH] bridge: export multicast database via netlink


Does the following patch help?

$ git diff include/uapi/linux/if_bridge.h
diff --git a/include/uapi/linux/if_bridge.h
b/include/uapi/linux/if_bridge.h
index 5db2975..653db23 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -14,6 +14,7 @@
  #define _UAPI_LINUX_IF_BRIDGE_H

  #include 
+#include 

  #define SYSFS_BRIDGE_ATTR  "bridge"
  #define SYSFS_BRIDGE_FDB   "brforward"



Well, I suggested the same fix in the beginning of the thread
on netdev and lkml: "if_bridge.h: include in6.h for struct in6_addr use"

as it seemed to fix the libvirt case

but then asked it to be ignored after I tried to build connman,
and hit this conflict with glibc-2.17:

In file included from /usr/include/arpa/inet.h:22:0,
 from ./include/connman/inet.h:25,
 from src/connman.h:128,
 from src/tethering.c:40:
/usr/include/netinet/in.h:35:5: error: expected identifier before 
numeric constant

/usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr'
In file included from /usr/include/linux/if_bridge.h:17:0,
 from src/tethering.c:38:
/usr/include/linux/in6.h:30:8: note: originally defined here
In file included from /usr/include/arpa/inet.h:22:0,
 from ./include/connman/inet.h:25,
 from src/connman.h:128,
 from src/tethering.c:40:
/usr/include/netinet/in.h:238:8: error: redefinition of 'struct 
sockaddr_in6'

In file included from /usr/include/linux/if_bridge.h:17:0,
 from src/tethering.c:38:
/usr/include/linux/in6.h:46:8: note: originally defined here
In file included from /usr/include/arpa/inet.h:22:0,
 from ./include/connman/inet.h:25,
 from src/connman.h:128,
 from src/tethering.c:40:
/usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq'
In file included from /usr/include/linux/if_bridge.h:17:0,
 from src/tethering.c:38:
/usr/include/linux/in6.h:54:8: note: originally defined here
make[1]: *** [src/src_connmand-tethering.o] Error 1


So I'm not sure it's the right one...


--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi (was: Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use)

[Thomas Backlund]

Eric Blake skrev 15.1.2013 01:57:

On 01/13/2013 01:05 PM, Thomas Backlund wrote:

Thomas Backlund skrev 13.1.2013 20:38:

patch both inline and attached as thunderbird tends to mess up ...



-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.



Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...

Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:

config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has
incomplete type


Hmm, just now noticing this thread, after independently hitting and and
having to work around the same problem in libvirt:
https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html
https://bugzilla.redhat.com/show_bug.cgi?id=895141



Yep,

and the commit breaking uapi headers is by using "struct in6_addr ip6" is:


From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001
From: Cong Wang 
Date: Fri, 7 Dec 2012 00:04:48 +
Subject: [PATCH] bridge: export multicast database via netlink

V5: fix two bugs pointed out by Thomas
remove seq check for now, mark it as TODO

V4: remove some useless #include
some coding style fix

V3: drop debugging printk's
update selinux perm table as well

V2: drop patch 1/2, export ifindex directly
Redesign netlink attributes
Improve netlink seq check
Handle IPv6 addr as well

This patch exports bridge multicast database via netlink
message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).

(Thanks to Thomas for patient reviews)

Cc: Herbert Xu 
Cc: Stephen Hemminger 
Cc: "David S. Miller" 
Cc: Thomas Graf 
Cc: Jesper Dangaard Brouer 
Signed-off-by: Cong Wang 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller 
---
 include/uapi/linux/if_bridge.h |   55 ++
 include/uapi/linux/rtnetlink.h |3 +
 net/bridge/Makefile|2 +-
 net/bridge/br_mdb.c|  163 


 net/bridge/br_multicast.c  |1 +
 net/bridge/br_private.h|1 +
 security/selinux/nlmsgtab.c|1 +
 7 files changed, 225 insertions(+), 1 deletions(-)
 create mode 100644 net/bridge/br_mdb.c

--
Thomas



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

the patch bridge: export multicast database via netlink broke kernel 3.8 uapi (was: Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use)

[Thomas Backlund]

Eric Blake skrev 15.1.2013 01:57:

On 01/13/2013 01:05 PM, Thomas Backlund wrote:

Thomas Backlund skrev 13.1.2013 20:38:

patch both inline and attached as thunderbird tends to mess up ...



-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.



Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...

Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:

config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has
incomplete type


Hmm, just now noticing this thread, after independently hitting and and
having to work around the same problem in libvirt:
https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html
https://bugzilla.redhat.com/show_bug.cgi?id=895141



Yep,

and the commit breaking uapi headers is by using struct in6_addr ip6 is:


From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001
From: Cong Wang amw...@redhat.com
Date: Fri, 7 Dec 2012 00:04:48 +
Subject: [PATCH] bridge: export multicast database via netlink

V5: fix two bugs pointed out by Thomas
remove seq check for now, mark it as TODO

V4: remove some useless #include
some coding style fix

V3: drop debugging printk's
update selinux perm table as well

V2: drop patch 1/2, export ifindex directly
Redesign netlink attributes
Improve netlink seq check
Handle IPv6 addr as well

This patch exports bridge multicast database via netlink
message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).

(Thanks to Thomas for patient reviews)

Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Stephen Hemminger shemmin...@vyatta.com
Cc: David S. Miller da...@davemloft.net
Cc: Thomas Graf tg...@suug.ch
Cc: Jesper Dangaard Brouer bro...@redhat.com
Signed-off-by: Cong Wang amw...@redhat.com
Acked-by: Thomas Graf tg...@suug.ch
Signed-off-by: David S. Miller da...@davemloft.net
---
 include/uapi/linux/if_bridge.h |   55 ++
 include/uapi/linux/rtnetlink.h |3 +
 net/bridge/Makefile|2 +-
 net/bridge/br_mdb.c|  163 


 net/bridge/br_multicast.c  |1 +
 net/bridge/br_private.h|1 +
 security/selinux/nlmsgtab.c|1 +
 7 files changed, 225 insertions(+), 1 deletions(-)
 create mode 100644 net/bridge/br_mdb.c

--
Thomas



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the patch bridge: export multicast database via netlink broke kernel 3.8 uapi

[Thomas Backlund]

Cong Wang skrev 15.1.2013 12:11:

On Tue, 2013-01-15 at 12:03 +0200, Thomas Backlund wrote:

Eric Blake skrev 15.1.2013 01:57:

On 01/13/2013 01:05 PM, Thomas Backlund wrote:

Thomas Backlund skrev 13.1.2013 20:38:

patch both inline and attached as thunderbird tends to mess up ...



-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.



Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...

Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:

config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has
incomplete type


Hmm, just now noticing this thread, after independently hitting and and
having to work around the same problem in libvirt:
https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html
https://bugzilla.redhat.com/show_bug.cgi?id=895141



Yep,

and the commit breaking uapi headers is by using struct in6_addr ip6 is:


  From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001
From: Cong Wang amw...@redhat.com
Date: Fri, 7 Dec 2012 00:04:48 +
Subject: [PATCH] bridge: export multicast database via netlink


Does the following patch help?

$ git diff include/uapi/linux/if_bridge.h
diff --git a/include/uapi/linux/if_bridge.h
b/include/uapi/linux/if_bridge.h
index 5db2975..653db23 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -14,6 +14,7 @@
  #define _UAPI_LINUX_IF_BRIDGE_H

  #include linux/types.h
+#include linux/in6.h

  #define SYSFS_BRIDGE_ATTR  bridge
  #define SYSFS_BRIDGE_FDB   brforward



Well, I suggested the same fix in the beginning of the thread
on netdev and lkml: if_bridge.h: include in6.h for struct in6_addr use

as it seemed to fix the libvirt case

but then asked it to be ignored after I tried to build connman,
and hit this conflict with glibc-2.17:

In file included from /usr/include/arpa/inet.h:22:0,
 from ./include/connman/inet.h:25,
 from src/connman.h:128,
 from src/tethering.c:40:
/usr/include/netinet/in.h:35:5: error: expected identifier before 
numeric constant

/usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr'
In file included from /usr/include/linux/if_bridge.h:17:0,
 from src/tethering.c:38:
/usr/include/linux/in6.h:30:8: note: originally defined here
In file included from /usr/include/arpa/inet.h:22:0,
 from ./include/connman/inet.h:25,
 from src/connman.h:128,
 from src/tethering.c:40:
/usr/include/netinet/in.h:238:8: error: redefinition of 'struct 
sockaddr_in6'

In file included from /usr/include/linux/if_bridge.h:17:0,
 from src/tethering.c:38:
/usr/include/linux/in6.h:46:8: note: originally defined here
In file included from /usr/include/arpa/inet.h:22:0,
 from ./include/connman/inet.h:25,
 from src/connman.h:128,
 from src/tethering.c:40:
/usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq'
In file included from /usr/include/linux/if_bridge.h:17:0,
 from src/tethering.c:38:
/usr/include/linux/in6.h:54:8: note: originally defined here
make[1]: *** [src/src_connmand-tethering.o] Error 1


So I'm not sure it's the right one...


--
Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: if_bridge.h: include in6.h for struct in6_addr use

[Thomas Backlund]

Thomas Backlund skrev 13.1.2013 20:38:

patch both inline and attached as thunderbird tends to mess up ...



-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.



Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...

Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:

config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has 
incomplete type



Reported-by: Colin Guthrie 
Reported-by: Christiaan Welvaart 
Signed-off-by: Thomas Backlund 

--

diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h
linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
--- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13
20:09:54.257271755 +0200
+++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13
20:15:04.153676151 +0200
@@ -14,6 +14,7 @@
  #define _UAPI_LINUX_IF_BRIDGE_H

  #include 
+#include 

  #define SYSFS_BRIDGE_ATTR  "bridge"
  #define SYSFS_BRIDGE_FDB   "brforward"


-
Thomas


--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

if_bridge.h: include in6.h for struct in6_addr use

[Thomas Backlund]

patch both inline and attached as thunderbird tends to mess up ...
-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.

Reported-by: Colin Guthrie 
Reported-by: Christiaan Welvaart 
Signed-off-by: Thomas Backlund 

--

diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h 
linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
--- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 
20:09:54.257271755 +0200
+++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 
20:15:04.153676151 +0200

@@ -14,6 +14,7 @@
 #define _UAPI_LINUX_IF_BRIDGE_H

 #include 
+#include 

 #define SYSFS_BRIDGE_ATTR  "bridge"
 #define SYSFS_BRIDGE_FDB   "brforward"


-
Thomas


if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.

Reported-by: Colin Guthrie 
Reported-by: Christiaan Welvaart 
Signed-off-by: Thomas Backlund 

--

diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h 
linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
--- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 
20:09:54.257271755 +0200
+++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 
20:15:04.153676151 +0200
@@ -14,6 +14,7 @@
 #define _UAPI_LINUX_IF_BRIDGE_H
 
 #include 
+#include 
 
 #define SYSFS_BRIDGE_ATTR  "bridge"
 #define SYSFS_BRIDGE_FDB   "brforward"

if_bridge.h: include in6.h for struct in6_addr use

[Thomas Backlund]

patch both inline and attached as thunderbird tends to mess up ...
-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.

Reported-by: Colin Guthrie co...@mageia.org
Reported-by: Christiaan Welvaart c...@daneel.dyndns.org
Signed-off-by: Thomas Backlund t...@mageia.org

--

diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h 
linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
--- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 
20:09:54.257271755 +0200
+++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 
20:15:04.153676151 +0200

@@ -14,6 +14,7 @@
 #define _UAPI_LINUX_IF_BRIDGE_H

 #include linux/types.h
+#include linux/in6.h

 #define SYSFS_BRIDGE_ATTR  bridge
 #define SYSFS_BRIDGE_FDB   brforward


-
Thomas


if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.

Reported-by: Colin Guthrie co...@mageia.org
Reported-by: Christiaan Welvaart c...@daneel.dyndns.org
Signed-off-by: Thomas Backlund t...@mageia.org

--

diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h 
linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
--- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 
20:09:54.257271755 +0200
+++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 
20:15:04.153676151 +0200
@@ -14,6 +14,7 @@
 #define _UAPI_LINUX_IF_BRIDGE_H
 
 #include linux/types.h
+#include linux/in6.h
 
 #define SYSFS_BRIDGE_ATTR  bridge
 #define SYSFS_BRIDGE_FDB   brforward

Re: if_bridge.h: include in6.h for struct in6_addr use

[Thomas Backlund]

Thomas Backlund skrev 13.1.2013 20:38:

patch both inline and attached as thunderbird tends to mess up ...



-

if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
header.

Found by trying to build libvirt and connman against 3.8-rc3 headers.



Ok,
ignore this patch, it's not the correct fix as it introduces
redefinitions...

Btw, the error that I hit that made me suggest this fix was libvirt
config check bailing out:

config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has 
incomplete type



Reported-by: Colin Guthrie co...@mageia.org
Reported-by: Christiaan Welvaart c...@daneel.dyndns.org
Signed-off-by: Thomas Backlund t...@mageia.org

--

diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h
linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h
--- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13
20:09:54.257271755 +0200
+++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13
20:15:04.153676151 +0200
@@ -14,6 +14,7 @@
  #define _UAPI_LINUX_IF_BRIDGE_H

  #include linux/types.h
+#include linux/in6.h

  #define SYSFS_BRIDGE_ATTR  bridge
  #define SYSFS_BRIDGE_FDB   brforward


-
Thomas


--
Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/