Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use Takashis updated patches to build the kernel packages #10

Closed
heikomat opened this issue May 19, 2019 · 10 comments
Closed

Use Takashis updated patches to build the kernel packages #10

heikomat opened this issue May 19, 2019 · 10 comments
Assignees
@heikomat
Labels
enhancement New feature or request

Comments

@heikomat
Copy link
Owner

heikomat commented May 19, 2019 •
edited
Loading

As described in #8 (comment), @tiwai seems to have updated his cx2072x patches (whose 4.13-variant are the base this fork was built upon).

This means, that his 5.1-patches are probably of higher quality than the ones in this repo, because he actually knows what he's doing (i'm just capable of reading code and error messages, and was lucky to make his 4.13 patches work in newer kernels)

This however doesn't make this repository fully obsolete, as people seem to like the one-command-install-script that configures pulseaudio and installs the required firmware, alsa-ucm-files and prebuild kernel packages.

Because of this, this issue is here to track the following work:

  1. build a debian linux package based solely on Takashis cx2072x-5.1 kernel found here
  2. apply the pulsaudio configuration and install the ucm files and the linux package just like the installer script would
  3. Test if everything works like with our current 5.1-cx2072x (or maybe even better)
  4. If so, merge Takashis cx2072x-5.1-branch into the master of this fork and re-release 5.1

@roethigj Thank you for making me aware, that Takashi has updated patches!
@heikomat heikomat added the enhancement New feature or request label May 19, 2019
@heikomat heikomat self-assigned this May 19, 2019
@7twin 7twin mentioned this issue May 19, 2019
Closed
@heikomat
Copy link
Owner Author

@7twin to answer your question from #8 (comment): Until the release based on Takashis updated patches is proven to work and ready for release, the current 5.1 release i made today will remain where it is.
There is no reason not to test the arch build, as the build method should idealy not change at all after switching to Takashis updated patches.

@7twin
Copy link

7twin commented May 19, 2019

@heikomat Great, then I'll still find the time to check if it works and report back. Should I post in the previous issue or here once I do?

@heikomat
Copy link
Owner Author

@7twin in the previous one please, because this one is about takashis patches, the other one is about arch packages.

@heikomat
Copy link
Owner Author

Also: as discussed here we might eventually have cx2072x patches in the regular linux kernel. Maybe with Kernel 5.3?
When this happens AND alsa gets updated to include the ucm files, then sound on the e200ha should work out of the box. Only time will tell :D

@7twin
Copy link

7twin commented May 19, 2019

@heikomat Sure, I'll post it in the other issue then.
Regarding the 5.3 merge, that'd be actually great, because then we could just keep pulling the kernel and not worry about having to manually patch things in anymore 👍

heikomat pushed a commit that referenced this issue May 21, 2019
@z00467499
cifs: Fix lease buffer length error
b57a55e 
There is a KASAN slab-out-of-bounds:
BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0
Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539

CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
            rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
Call Trace:
 dump_stack+0xdd/0x12a
 print_address_description+0xa7/0x540
 kasan_report+0x1ff/0x550
 check_memory_region+0x2f1/0x310
 memcpy+0x2f/0x80
 _copy_from_iter_full+0x783/0xaa0
 tcp_sendmsg_locked+0x1840/0x4140
 tcp_sendmsg+0x37/0x60
 inet_sendmsg+0x18c/0x490
 sock_sendmsg+0xae/0x130
 smb_send_kvec+0x29c/0x520
 __smb_send_rqst+0x3ef/0xc60
 smb_send_rqst+0x25a/0x2e0
 compound_send_recv+0x9e8/0x2af0
 cifs_send_recv+0x24/0x30
 SMB2_open+0x35e/0x1620
 open_shroot+0x27b/0x490
 smb2_open_op_close+0x4e1/0x590
 smb2_query_path_info+0x2ac/0x650
 cifs_get_inode_info+0x1058/0x28f0
 cifs_root_iget+0x3bb/0xf80
 cifs_smb3_do_mount+0xe00/0x14c0
 cifs_do_mount+0x15/0x20
 mount_fs+0x5e/0x290
 vfs_kern_mount+0x88/0x460
 do_mount+0x398/0x31e0
 ksys_mount+0xc6/0x150
 __x64_sys_mount+0xea/0x190
 do_syscall_64+0x122/0x590
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

It can be reproduced by the following step:
  1. samba configured with: server max protocol = SMB2_10
  2. mount -o vers=default

When parse the mount version parameter, the 'ops' and 'vals'
was setted to smb30,  if negotiate result is smb21, just
update the 'ops' to smb21, but the 'vals' is still smb30.
When add lease context, the iov_base is allocated with smb21
ops, but the iov_len is initiallited with the smb30. Because
the iov_len is longer than iov_base, when send the message,
copy array out of bounds.

we need to keep the 'ops' and 'vals' consistent.

Fixes: 9764c02 ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
Fixes: d5c7076 ("smb3: add smb3.1.1 to default dialect list")

Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
heikomat pushed a commit that referenced this issue May 21, 2019
@olsajiri @acmel
perf tools: Fix map reference counting
b9abbdf 
By calling maps__insert() we assume to get 2 references on the map,
which we relese within maps__remove call.

However if there's already same map name, we currently don't bump the
reference and can crash, like:

  Program received signal SIGABRT, Aborted.
  0x00007ffff75e60f5 in raise () from /lib64/libc.so.6

  (gdb) bt
  #0  0x00007ffff75e60f5 in raise () from /lib64/libc.so.6
  #1  0x00007ffff75d0895 in abort () from /lib64/libc.so.6
  #2  0x00007ffff75d0769 in __assert_fail_base.cold () from /lib64/libc.so.6
  #3  0x00007ffff75de596 in __assert_fail () from /lib64/libc.so.6
  #4  0x00000000004fc006 in refcount_sub_and_test (i=1, r=0x1224e88) at tools/include/linux/refcount.h:131
  #5  refcount_dec_and_test (r=0x1224e88) at tools/include/linux/refcount.h:148
  #6  map__put (map=0x1224df0) at util/map.c:299
  #7  0x00000000004fdb95 in __maps__remove (map=0x1224df0, maps=0xb17d80) at util/map.c:953
  #8  maps__remove (maps=0xb17d80, map=0x1224df0) at util/map.c:959
  #9  0x00000000004f7d8a in map_groups__remove (map=<optimized out>, mg=<optimized out>) at util/map_groups.h:65
  #10 machine__process_ksymbol_unregister (sample=<optimized out>, event=0x7ffff7279670, machine=<optimized out>) at util/machine.c:728
  #11 machine__process_ksymbol (machine=<optimized out>, event=0x7ffff7279670, sample=<optimized out>) at util/machine.c:741
  #12 0x00000000004fffbb in perf_session__deliver_event (session=0xb11390, event=0x7ffff7279670, tool=0x7fffffffc7b0, file_offset=13936) at util/session.c:1362
  #13 0x00000000005039bb in do_flush (show_progress=false, oe=0xb17e80) at util/ordered-events.c:243
  #14 __ordered_events__flush (oe=0xb17e80, how=OE_FLUSH__ROUND, timestamp=<optimized out>) at util/ordered-events.c:322
  torvalds#15 0x00000000005005e4 in perf_session__process_user_event (session=session@entry=0xb11390, event=event@entry=0x7ffff72a4af8,
  ...

Add the map to the list and getting the reference event if we find the
map with same name.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Fixes: 1e62856 ("perf symbols: Fix slowness due to -ffunction-section")
Link: http://lkml.kernel.org/r/20190416160127.30203-10-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
@heikomat
Copy link
Owner Author

ok, the 5.1 kernel is now based on takashis updated patches.
One nice sideeffect is, that it now only differs from the regular linux kernel by 5 commits! (3 with patches from @tiwai, two with the updated ucm files and manual)

Thanks again to @roethigj, the hint regarding the namechange (chtcx2072x -> bytchtcx2072x) saved me a lot of time.

5.1 is now re-released, based on the updated patches from @tiwai 🎉

@heikomat heikomat mentioned this issue May 23, 2019
Closed
@heikomat
Copy link
Owner Author

@7twin see heikomat/linux_cx2072x_build@7b70a07 for the changes in the dockerized build (just some config changes). Would be super nice, if you could adjust and test your dockerized arch build!

@7twin
Copy link

7twin commented May 23, 2019

@heikomat ah that's for the touchpad fix I assume. I'll check if my config contains that and test it with docker asap!

@heikomat
Copy link
Owner Author

@7twin yeah, but also the rename of cht -> bytcht

  • CONFIG_SND_SOC_INTEL_CHT_CX2072X_MACH is now CONFIG_SND_SOC_INTEL_BYT_CHT_CX2072X_MACH
  • /usr/share/alsa/usm/chtcx2072x/ is now /usr/share/alsa/usm/bytcht-cx2072x/
  • /usr/share/alsa/usm/chtcx2072x/chtcx2072x is now /usr/share/alsa/usm/bytcht-cx2072x/bytcht-cx2072x
  • in /usr/share/alsa/usm/bytcht-cx2072x/HiFi.conf, every instance of hw:chtcx2072x is now hw:bytchtcx2072x

@7twin
Copy link

7twin commented May 23, 2019

@heikomat not sure if those affect my build (they don't affect the linked docker build either?), except maybe that the zcat'd config I created has to be done again because of the first thing you mentioned?

7twin added a commit to 7twin/arch_sound_e200ha that referenced this issue May 29, 2019
@7twin
Updated for new takashi merge and fixed branch
48bc779 
See: heikomat/linux#10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@heikomat heikomat

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@heikomat @7twin