Fix frequency range for SI2157 Tuner #240

koshkoshka · 2015-12-30T13:19:38Z

Si2157 supports from 42 to 870 mhz

try_to_unmap_one() should be able to handle hugetlb, but page_remove_rmap() in that function takes false as a compound flag, which breaks hugepage migration with the following message. Soft offlining page 0x1d4a00 at 0x7ff634a00000 soft offline: 0x1d4a00: migration failed 1, type 60000000000401c BUG: Bad page state in process sysctl pfn:1d4a00 page:ffffea0007528000 count:0 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 10 flags: 0x600000000004008(uptodate|head) page dumped because: nonzero mapcount Modules linked in: cfg80211 rfkill crc32c_intel virtio_balloon serio_raw i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi CPU: 3 PID: 11882 Comm: sysctl Tainted: G W 4.3.0-mmotm-2015-11-10-15-53-151112-1812-00015-53+ torvalds#240 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffffffff81a1a124 ffff8800da047bd0 ffffffff81340adf ffffea0007528000 ffff8800da047bf8 ffffffff8116e206 0000000000000009 ffffffff81f72538 ffffea0007528000 ffff8800da047c48 ffffffff8116e6d6 0000020000000000 Call Trace: [<ffffffff81340adf>] dump_stack+0x44/0x55 [<ffffffff8116e206>] bad_page+0xc6/0x110 [<ffffffff8116e6d6>] free_pages_prepare+0x486/0x500 [<ffffffff81170f9a>] __free_pages_ok+0x1a/0xb0 [<ffffffff81171af1>] __free_pages+0x21/0x40 [<ffffffff811b5d79>] update_and_free_page+0xa9/0x230 [<ffffffff811b6641>] free_pool_huge_page+0xc1/0xe0 [<ffffffff811b6d02>] set_max_huge_pages+0x382/0x4d0 [<ffffffff811b7002>] hugetlb_sysctl_handler_common+0xa2/0xd0 [<ffffffff811b823e>] hugetlb_sysctl_handler+0x1e/0x20 [<ffffffff812535fe>] proc_sys_call_handler+0xae/0xc0 [<ffffffff81253624>] proc_sys_write+0x14/0x20 [<ffffffff811e8758>] __vfs_write+0x28/0xe0 [<ffffffff810d1864>] ? percpu_down_read+0x14/0x60 [<ffffffff811e8d29>] vfs_write+0xa9/0x190 [<ffffffff811e9646>] SyS_write+0x46/0xb0 [<ffffffff8163d797>] entry_SYSCALL_64_fastpath+0x12/0x6a This patch simply fixes this by giving the compound flag via PageHuge. Fixes: "rmap: add argument to charge compound page". Signed-off-by: Naoya Horiguchi <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

ticki · 2016-01-03T16:48:01Z

Pull request sent through the Github web interface are not accepted in this
repository. You should send them to the kernel mailing list instead.

try_to_unmap_one() should be able to handle hugetlb, but page_remove_rmap() in that function takes false as a compound flag, which breaks hugepage migration with the following message. Soft offlining page 0x1d4a00 at 0x7ff634a00000 soft offline: 0x1d4a00: migration failed 1, type 60000000000401c BUG: Bad page state in process sysctl pfn:1d4a00 page:ffffea0007528000 count:0 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 10 flags: 0x600000000004008(uptodate|head) page dumped because: nonzero mapcount Modules linked in: cfg80211 rfkill crc32c_intel virtio_balloon serio_raw i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi CPU: 3 PID: 11882 Comm: sysctl Tainted: G W 4.3.0-mmotm-2015-11-10-15-53-151112-1812-00015-53+ torvalds#240 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffffffff81a1a124 ffff8800da047bd0 ffffffff81340adf ffffea0007528000 ffff8800da047bf8 ffffffff8116e206 0000000000000009 ffffffff81f72538 ffffea0007528000 ffff8800da047c48 ffffffff8116e6d6 0000020000000000 Call Trace: [<ffffffff81340adf>] dump_stack+0x44/0x55 [<ffffffff8116e206>] bad_page+0xc6/0x110 [<ffffffff8116e6d6>] free_pages_prepare+0x486/0x500 [<ffffffff81170f9a>] __free_pages_ok+0x1a/0xb0 [<ffffffff81171af1>] __free_pages+0x21/0x40 [<ffffffff811b5d79>] update_and_free_page+0xa9/0x230 [<ffffffff811b6641>] free_pool_huge_page+0xc1/0xe0 [<ffffffff811b6d02>] set_max_huge_pages+0x382/0x4d0 [<ffffffff811b7002>] hugetlb_sysctl_handler_common+0xa2/0xd0 [<ffffffff811b823e>] hugetlb_sysctl_handler+0x1e/0x20 [<ffffffff812535fe>] proc_sys_call_handler+0xae/0xc0 [<ffffffff81253624>] proc_sys_write+0x14/0x20 [<ffffffff811e8758>] __vfs_write+0x28/0xe0 [<ffffffff810d1864>] ? percpu_down_read+0x14/0x60 [<ffffffff811e8d29>] vfs_write+0xa9/0x190 [<ffffffff811e9646>] SyS_write+0x46/0xb0 [<ffffffff8163d797>] entry_SYSCALL_64_fastpath+0x12/0x6a This patch simply fixes this by giving the compound flag via PageHuge. Fixes: "rmap: add argument to charge compound page". Signed-off-by: Naoya Horiguchi <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

@offset

On Wed, 13 Jan 2016 16:00:09 +0100, Dmitry Vyukov wrote: > > Hello, > > The following program triggers use-after-free in snd_timer_interrupt: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include <unistd.h> > #include <sys/syscall.h> > #include <string.h> > #include <stdint.h> > #include <pthread.h> > > long r[84]; > > void *thr(void *arg) > { > switch ((long)arg) { > case 0: > r[0] = syscall(SYS_mmap, 0x20000000ul, 0xe000ul, > 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul); > break; > case 1: > memcpy((void*)0x20000990, > "\x2f\x64\x65\x76\x2f\x73\x6e\x64\x2f\x74\x69\x6d\x65\x72", 14); > r[2] = syscall(SYS_open, 0x20000990ul, 0x1ul, 0x0ul, 0, 0, 0); > break; > case 2: > *(uint32_t*)0x20000000 = (uint32_t)0x1; > *(uint32_t*)0x20000004 = (uint32_t)0x7; > *(uint32_t*)0x20000008 = (uint32_t)0x3; > *(uint32_t*)0x2000000c = (uint32_t)0x0; > *(uint32_t*)0x20000010 = (uint32_t)0x0; > *(uint8_t*)0x20000014 = (uint8_t)0x0; > *(uint8_t*)0x20000015 = (uint8_t)0x0; > *(uint8_t*)0x20000016 = (uint8_t)0x0; > *(uint8_t*)0x20000017 = (uint8_t)0x0; > *(uint8_t*)0x20000018 = (uint8_t)0x0; > *(uint8_t*)0x20000019 = (uint8_t)0x0; > *(uint8_t*)0x2000001a = (uint8_t)0x0; > *(uint8_t*)0x2000001b = (uint8_t)0x0; > *(uint8_t*)0x2000001c = (uint8_t)0x0; > *(uint8_t*)0x2000001d = (uint8_t)0x0; > *(uint8_t*)0x2000001e = (uint8_t)0x0; > *(uint8_t*)0x2000001f = (uint8_t)0x0; > *(uint8_t*)0x20000020 = (uint8_t)0x0; > *(uint8_t*)0x20000021 = (uint8_t)0x0; > *(uint8_t*)0x20000022 = (uint8_t)0x0; > *(uint8_t*)0x20000023 = (uint8_t)0x0; > *(uint8_t*)0x20000024 = (uint8_t)0x0; > *(uint8_t*)0x20000025 = (uint8_t)0x0; > *(uint8_t*)0x20000026 = (uint8_t)0x0; > *(uint8_t*)0x20000027 = (uint8_t)0x0; > *(uint8_t*)0x20000028 = (uint8_t)0x0; > *(uint8_t*)0x20000029 = (uint8_t)0x0; > *(uint8_t*)0x2000002a = (uint8_t)0x0; > *(uint8_t*)0x2000002b = (uint8_t)0x0; > *(uint8_t*)0x2000002c = (uint8_t)0x0; > *(uint8_t*)0x2000002d = (uint8_t)0x0; > *(uint8_t*)0x2000002e = (uint8_t)0x0; > *(uint8_t*)0x2000002f = (uint8_t)0x0; > *(uint8_t*)0x20000030 = (uint8_t)0x0; > *(uint8_t*)0x20000031 = (uint8_t)0x0; > *(uint8_t*)0x20000032 = (uint8_t)0x0; > *(uint8_t*)0x20000033 = (uint8_t)0x0; > r[40] = syscall(SYS_ioctl, r[2], 0x40345410ul, > 0x20000000ul, 0, 0, 0); > break; > case 3: > r[41] = syscall(SYS_ioctl, r[2], 0x54a2ul, 0, 0, 0, 0); > break; > case 4: > r[42] = syscall(SYS_mmap, 0x2000e000ul, 0x1000ul, > 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul); > break; > case 5: > *(uint32_t*)0x2000efcc = (uint32_t)0x7; > *(uint32_t*)0x2000efd0 = (uint32_t)0x9; > *(uint32_t*)0x2000efd4 = (uint32_t)0x4513; > *(uint32_t*)0x2000efd8 = (uint32_t)0x9; > *(uint32_t*)0x2000efdc = (uint32_t)0x5; > *(uint8_t*)0x2000efe0 = (uint8_t)0x0; > *(uint8_t*)0x2000efe1 = (uint8_t)0x0; > *(uint8_t*)0x2000efe2 = (uint8_t)0x0; > *(uint8_t*)0x2000efe3 = (uint8_t)0x0; > *(uint8_t*)0x2000efe4 = (uint8_t)0x0; > *(uint8_t*)0x2000efe5 = (uint8_t)0x0; > *(uint8_t*)0x2000efe6 = (uint8_t)0x0; > *(uint8_t*)0x2000efe7 = (uint8_t)0x0; > *(uint8_t*)0x2000efe8 = (uint8_t)0x0; > *(uint8_t*)0x2000efe9 = (uint8_t)0x0; > *(uint8_t*)0x2000efea = (uint8_t)0x0; > *(uint8_t*)0x2000efeb = (uint8_t)0x0; > *(uint8_t*)0x2000efec = (uint8_t)0x0; > *(uint8_t*)0x2000efed = (uint8_t)0x0; > *(uint8_t*)0x2000efee = (uint8_t)0x0; > *(uint8_t*)0x2000efef = (uint8_t)0x0; > *(uint8_t*)0x2000eff0 = (uint8_t)0x0; > *(uint8_t*)0x2000eff1 = (uint8_t)0x0; > *(uint8_t*)0x2000eff2 = (uint8_t)0x0; > *(uint8_t*)0x2000eff3 = (uint8_t)0x0; > *(uint8_t*)0x2000eff4 = (uint8_t)0x0; > *(uint8_t*)0x2000eff5 = (uint8_t)0x0; > *(uint8_t*)0x2000eff6 = (uint8_t)0x0; > *(uint8_t*)0x2000eff7 = (uint8_t)0x0; > *(uint8_t*)0x2000eff8 = (uint8_t)0x0; > *(uint8_t*)0x2000eff9 = (uint8_t)0x0; > *(uint8_t*)0x2000effa = (uint8_t)0x0; > *(uint8_t*)0x2000effb = (uint8_t)0x0; > *(uint8_t*)0x2000effc = (uint8_t)0x0; > *(uint8_t*)0x2000effd = (uint8_t)0x0; > *(uint8_t*)0x2000effe = (uint8_t)0x0; > *(uint8_t*)0x2000efff = (uint8_t)0x0; > r[80] = syscall(SYS_ioctl, r[2], 0x40345410ul, > 0x2000efccul, 0, 0, 0); > break; > case 6: > r[81] = syscall(SYS_ioctl, r[2], 0x54a0ul, 0, 0, 0, 0); > break; > case 7: > r[82] = syscall(SYS_mmap, 0x2000f000ul, 0x1000ul, > 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul); > break; > case 8: > r[83] = syscall(SYS_ioctl, r[2], 0x80e85411ul, > 0x2000ffd4ul, 0, 0, 0); > break; > } > return 0; > } > > int main() > { > long i; > pthread_t th[9]; > > memset(r, -1, sizeof(r)); > for (i = 0; i < 9; i++) { > pthread_create(&th[i], 0, thr, (void*)i); > usleep(10000); > } > for (i = 0; i < 9; i++) { > pthread_create(&th[i], 0, thr, (void*)i); > if (i%2==0) > usleep(10000); > } > usleep(100000); > return 0; > } > > > ================================================================== > BUG: KASAN: use-after-free in snd_timer_interrupt+0xb11/0xbf0 at addr > ffff88002fd230d8 > Read of size 8 by task syz-executor/8301 > ============================================================================= > BUG kmalloc-256 (Not tainted): kasan: bad access detected > ----------------------------------------------------------------------------- > > INFO: Allocated in snd_timer_instance_new+0x52/0x3a0 age=2 cpu=1 pid=8283 > [< none >] ___slab_alloc+0x486/0x4e0 mm/slub.c:2468 > [< none >] __slab_alloc+0x66/0xc0 mm/slub.c:2497 > [< inline >] slab_alloc_node mm/slub.c:2560 > [< inline >] slab_alloc mm/slub.c:2602 > [< none >] kmem_cache_alloc_trace+0x284/0x310 mm/slub.c:2619 > [< inline >] kmalloc include/linux/slab.h:458 > [< inline >] kzalloc include/linux/slab.h:602 > [< none >] snd_timer_instance_new+0x52/0x3a0 sound/core/timer.c:105 > [< none >] snd_timer_open+0x522/0xc90 sound/core/timer.c:286 > [< inline >] snd_timer_user_tselect sound/core/timer.c:1527 > [< none >] snd_timer_user_ioctl+0x89f/0x2540 sound/core/timer.c:1809 > [< inline >] vfs_ioctl fs/ioctl.c:43 > [< none >] do_vfs_ioctl+0x18c/0xfa0 fs/ioctl.c:674 > [< inline >] SYSC_ioctl fs/ioctl.c:689 > [< none >] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680 > [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a > arch/x86/entry/entry_64.S:185 > > INFO: Freed in snd_timer_close+0x354/0x5f0 age=1 cpu=1 pid=8283 > [< none >] __slab_free+0x1fc/0x320 mm/slub.c:2678 > [< inline >] slab_free mm/slub.c:2833 > [< none >] kfree+0x2a8/0x2d0 mm/slub.c:3662 > [< none >] snd_timer_close+0x354/0x5f0 sound/core/timer.c:364 > [< inline >] snd_timer_user_tselect sound/core/timer.c:1517 > [< none >] snd_timer_user_ioctl+0x784/0x2540 sound/core/timer.c:1809 > [< inline >] vfs_ioctl fs/ioctl.c:43 > [< none >] do_vfs_ioctl+0x18c/0xfa0 fs/ioctl.c:674 > [< inline >] SYSC_ioctl fs/ioctl.c:689 > [< none >] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680 > [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a > arch/x86/entry/entry_64.S:185 > > INFO: Slab 0xffffea0000bf4800 objects=22 used=2 fp=0xffff88002fd23058 > flags=0x1fffc0000004080 > INFO: Object 0xffff88002fd23058 @offset=12376 fp=0xffff88002fd227d0 > CPU: 2 PID: 8301 Comm: syz-executor Tainted: G B 4.4.0+ torvalds#240 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > 00000000ffffffff ffff88006d607b08 ffffffff82926eed ffff88003e807000 > ffff88002fd23058 ffff88002fd20000 ffff88006d607b38 ffffffff81740ca4 > ffff88003e807000 ffffea0000bf4800 ffff88002fd23058 ffff88002fd230d8 > > Call Trace: > [<ffffffff8174a1fe>] __asan_report_load8_noabort+0x3e/0x40 > mm/kasan/report.c:295 > [<ffffffff84ebe841>] snd_timer_interrupt+0xb11/0xbf0 sound/core/timer.c:680 > [<ffffffff84ebe9dd>] snd_timer_s_function+0xbd/0x130 sound/core/timer.c:963 > [<ffffffff814b8c56>] call_timer_fn+0x176/0x550 kernel/time/timer.c:1178 > [< inline >] __run_timers kernel/time/timer.c:1254 > [<ffffffff814ba175>] run_timer_softirq+0x5c5/0x9f0 kernel/time/timer.c:1437 > [<ffffffff813606a8>] __do_softirq+0x268/0x920 kernel/softirq.c:273 > [< inline >] invoke_softirq kernel/softirq.c:350 > [<ffffffff813610ef>] irq_exit+0x18f/0x1d0 kernel/softirq.c:391 > [< inline >] exiting_irq ./arch/x86/include/asm/apic.h:659 > [<ffffffff8125157b>] smp_apic_timer_interrupt+0x7b/0xa0 > arch/x86/kernel/apic/apic.c:932 > [<ffffffff86273dec>] apic_timer_interrupt+0x8c/0xa0 > arch/x86/entry/entry_64.S:520 > <EOI> [<ffffffff813ac59d>] ? alloc_pid+0x5d/0xc90 kernel/pid.c:306 > [< inline >] slab_alloc_node mm/slub.c:2560 > [< inline >] slab_alloc mm/slub.c:2602 > [<ffffffff817446e1>] kmem_cache_alloc+0x261/0x2e0 mm/slub.c:2607 > [<ffffffff813ac59d>] alloc_pid+0x5d/0xc90 kernel/pid.c:306 > [<ffffffff8134ca2e>] copy_process.part.35+0x374e/0x5770 kernel/fork.c:1463 > [< inline >] copy_process kernel/fork.c:1275 > [<ffffffff8134ed7c>] _do_fork+0x1bc/0xcb0 kernel/fork.c:1724 > [< inline >] SYSC_clone kernel/fork.c:1833 > [<ffffffff8134f947>] SyS_clone+0x37/0x50 kernel/fork.c:1827 > [<ffffffff86272ff6>] entry_SYSCALL_64_fastpath+0x16/0x7a > arch/x86/entry/entry_64.S:185 > ================================================================== > > On commit 6799060 (Jan 12). This and your other relevant reports seem pointing the race of timer ioctls. Although snd_timer_close() itself calls snd_timer_stop(), there is no other protection against the concurrent execution. If my guess is correct, a simplistic fix like below should work. It basically serializes the timer ioctl by using a new mutex (and replacing the old tread_sem mutex). They are no longtime blocking calls, so this shouldn't be a big problem. But certainly there can be a less intrusive way to paper over this if this really matters. In this case for timer.c, I'd leave the final decision rather to Jaroslav. Jaroslav, what do you think? thanks, Takashi

try_to_unmap_one() should be able to handle hugetlb, but page_remove_rmap() in that function takes false as a compound flag, which breaks hugepage migration with the following message. Soft offlining page 0x1d4a00 at 0x7ff634a00000 soft offline: 0x1d4a00: migration failed 1, type 60000000000401c BUG: Bad page state in process sysctl pfn:1d4a00 page:ffffea0007528000 count:0 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 10 flags: 0x600000000004008(uptodate|head) page dumped because: nonzero mapcount Modules linked in: cfg80211 rfkill crc32c_intel virtio_balloon serio_raw i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi CPU: 3 PID: 11882 Comm: sysctl Tainted: G W 4.3.0-mmotm-2015-11-10-15-53-151112-1812-00015-53+ torvalds#240 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffffffff81a1a124 ffff8800da047bd0 ffffffff81340adf ffffea0007528000 ffff8800da047bf8 ffffffff8116e206 0000000000000009 ffffffff81f72538 ffffea0007528000 ffff8800da047c48 ffffffff8116e6d6 0000020000000000 Call Trace: [<ffffffff81340adf>] dump_stack+0x44/0x55 [<ffffffff8116e206>] bad_page+0xc6/0x110 [<ffffffff8116e6d6>] free_pages_prepare+0x486/0x500 [<ffffffff81170f9a>] __free_pages_ok+0x1a/0xb0 [<ffffffff81171af1>] __free_pages+0x21/0x40 [<ffffffff811b5d79>] update_and_free_page+0xa9/0x230 [<ffffffff811b6641>] free_pool_huge_page+0xc1/0xe0 [<ffffffff811b6d02>] set_max_huge_pages+0x382/0x4d0 [<ffffffff811b7002>] hugetlb_sysctl_handler_common+0xa2/0xd0 [<ffffffff811b823e>] hugetlb_sysctl_handler+0x1e/0x20 [<ffffffff812535fe>] proc_sys_call_handler+0xae/0xc0 [<ffffffff81253624>] proc_sys_write+0x14/0x20 [<ffffffff811e8758>] __vfs_write+0x28/0xe0 [<ffffffff810d1864>] ? percpu_down_read+0x14/0x60 [<ffffffff811e8d29>] vfs_write+0xa9/0x190 [<ffffffff811e9646>] SyS_write+0x46/0xb0 [<ffffffff8163d797>] entry_SYSCALL_64_fastpath+0x12/0x6a This patch simply fixes this by giving the compound flag via PageHuge. Fixes: "rmap: add argument to charge compound page". Signed-off-by: Naoya Horiguchi <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

koshkoshka · 2016-01-18T01:04:44Z

When it will be added to git?

ghost · 2016-01-18T15:39:50Z

Hi koshkoshka! For this to be considered you will need to send it in as a patch to the kernel mailing list. linux doesn't use PR:s. There is a system for it and a tutorial here: http://kernelnewbies.org/FirstKernelPatch

ticki · 2016-01-18T15:53:58Z

Linux does use PRs, it just use the git request-pull instead of Github's own
PR system.

ghost · 2016-01-18T16:01:21Z

Yes, what I meant was of course that Linux does not use Github's PRs

ticki · 2016-01-18T16:24:57Z

Yeah, you have to deliver your patches through the mailing list.

philipperemy · 2016-03-23T08:51:40Z

Please close this PR @koshkoshka .

manushaurya · 2016-03-23T11:33:59Z

I'm a newbie.Here I learnt that Linux doesn't support PRs.

ticki · 2016-03-23T12:51:48Z

It is not due to the lack of support, it is a deliberate choice,
which mr. Torvalds have made.

(1) use cpu id from bl31 delivers; (2) sp_el0 should point to kernel address in EL1 mode. On ARM64, kernel uses sp_el0 to store current_thread_info(), we see a problem: when fiq occurs, cpu is EL1 mode but sp_el0 point to userspace address. At this moment, if we read 'current_thread_info()->cpu' or other, it leads an error. We find above situation happens when save/restore cpu context between system mode and user mode under heavy load. Like 'ret_fast_syscall()', kernel restore context of user mode, but fiq occurs before the instruction 'eret', so this causes the above situation. Assembly code: ffffff80080826c8 <ret_fast_syscall>: ...skipping... ffffff80080826fc: d503201f nop ffffff8008082700: d5384100 mrs x0, sp_el0 ffffff8008082704: f9400c00 ldr x0, [x0,torvalds#24] ffffff8008082708: d5182000 msr ttbr0_el1, x0 ffffff800808270c: d5033fdf isb ffffff8008082710: f9407ff7 ldr x23, [sp,torvalds#248] ffffff8008082714: d5184117 msr sp_el0, x23 ffffff8008082718: d503201f nop ffffff800808271c: d503201f nop ffffff8008082720: d5184035 msr elr_el1, x21 ffffff8008082724: d5184016 msr spsr_el1, x22 ffffff8008082728: a94007e0 ldp x0, x1, [sp] ffffff800808272c: a9410fe2 ldp x2, x3, [sp,torvalds#16] ffffff8008082730: a94217e4 ldp x4, x5, [sp,torvalds#32] ffffff8008082734: a9431fe6 ldp x6, x7, [sp,torvalds#48] ffffff8008082738: a94427e8 ldp x8, x9, [sp,torvalds#64] ffffff800808273c: a9452fea ldp x10, x11, [sp,torvalds#80] ffffff8008082740: a94637ec ldp x12, x13, [sp,torvalds#96] ffffff8008082744: a9473fee ldp x14, x15, [sp,torvalds#112] ffffff8008082748: a94847f0 ldp x16, x17, [sp,torvalds#128] ffffff800808274c: a9494ff2 ldp x18, x19, [sp,torvalds#144] ffffff8008082750: a94a57f4 ldp x20, x21, [sp,torvalds#160] ffffff8008082754: a94b5ff6 ldp x22, x23, [sp,torvalds#176] ffffff8008082758: a94c67f8 ldp x24, x25, [sp,torvalds#192] ffffff800808275c: a94d6ffa ldp x26, x27, [sp,torvalds#208] ffffff8008082760: a94e77fc ldp x28, x29, [sp,torvalds#224] ffffff8008082764: f9407bfe ldr x30, [sp,torvalds#240] ffffff8008082768: 9104c3ff add sp, sp, #0x130 ffffff800808276c: d69f03e0 eret Change-Id: I071e899f8a407764e166ca0403199c9d87d6ce78 Signed-off-by: chenjh <[email protected]>

When building the kernel as Thumb-2 with binutils 2.29 or newer, if the assembler has seen the .type directive (via ENDPROC()) for a symbol, it automatically handles the setting of the lowest bit when the symbol is used with ADR. The badr macro on the other hand handles this lowest bit manually. This leads to a jump to a wrong address in the wrong state in the syscall return path: Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2 Modules linked in: CPU: 0 PID: 652 Comm: modprobe Tainted: G D 4.18.0-rc3+ #8 PC is at ret_fast_syscall+0x4/0x62 LR is at sys_brk+0x109/0x128 pc : [<80101004>] lr : [<801c8a35>] psr: 60000013 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 50c5387d Table: 9e82006a DAC: 00000051 Process modprobe (pid: 652, stack limit = 0x(ptrval)) 80101000 <ret_fast_syscall>: 80101000: b672 cpsid i 80101002: f8d9 2008 ldr.w r2, [r9, #8] 80101006: f1b2 4ffe cmp.w r2, #2130706432 ; 0x7f000000 80101184 <local_restart>: 80101184: f8d9 a000 ldr.w sl, [r9] 80101188: e92d 0030 stmdb sp!, {r4, r5} 8010118c: f01a 0ff0 tst.w sl, #240 ; 0xf0 80101190: d117 bne.n 801011c2 <__sys_trace> 80101192: 46ba mov sl, r7 80101194: f5ba 7fc8 cmp.w sl, #400 ; 0x190 80101198: bf28 it cs 8010119a: f04f 0a00 movcs.w sl, #0 8010119e: f3af 8014 nop.w {20} 801011a2: f2af 1ea2 subw lr, pc, #418 ; 0x1a2 To fix this, add a new symbol name which doesn't have ENDPROC used on it and use that with badr. We can't remove the badr usage since that would would cause breakage with older binutils. Signed-off-by: Vincent Whitchurch <[email protected]> Signed-off-by: Russell King <[email protected]>

When building the kernel as Thumb-2 with binutils 2.29 or newer, if the assembler has seen the .type directive (via ENDPROC()) for a symbol, it automatically handles the setting of the lowest bit when the symbol is used with ADR. The badr macro on the other hand handles this lowest bit manually. This leads to a jump to a wrong address in the wrong state in the syscall return path: Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2 Modules linked in: CPU: 0 PID: 652 Comm: modprobe Tainted: G D 4.18.0-rc3+ torvalds#8 PC is at ret_fast_syscall+0x4/0x62 LR is at sys_brk+0x109/0x128 pc : [<80101004>] lr : [<801c8a35>] psr: 60000013 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 50c5387d Table: 9e82006a DAC: 00000051 Process modprobe (pid: 652, stack limit = 0x(ptrval)) 80101000 <ret_fast_syscall>: 80101000: b672 cpsid i 80101002: f8d9 2008 ldr.w r2, [r9, torvalds#8] 80101006: f1b2 4ffe cmp.w r2, #2130706432 ; 0x7f000000 80101184 <local_restart>: 80101184: f8d9 a000 ldr.w sl, [r9] 80101188: e92d 0030 stmdb sp!, {r4, r5} 8010118c: f01a 0ff0 tst.w sl, torvalds#240 ; 0xf0 80101190: d117 bne.n 801011c2 <__sys_trace> 80101192: 46ba mov sl, r7 80101194: f5ba 7fc8 cmp.w sl, torvalds#400 ; 0x190 80101198: bf28 it cs 8010119a: f04f 0a00 movcs.w sl, #0 8010119e: f3af 8014 nop.w {20} 801011a2: f2af 1ea2 subw lr, pc, torvalds#418 ; 0x1a2 To fix this, add a new symbol name which doesn't have ENDPROC used on it and use that with badr. We can't remove the badr usage since that would would cause breakage with older binutils. Signed-off-by: Vincent Whitchurch <[email protected]> Signed-off-by: Russell King <[email protected]>

[ Upstream commit afc9f65 ] When building the kernel as Thumb-2 with binutils 2.29 or newer, if the assembler has seen the .type directive (via ENDPROC()) for a symbol, it automatically handles the setting of the lowest bit when the symbol is used with ADR. The badr macro on the other hand handles this lowest bit manually. This leads to a jump to a wrong address in the wrong state in the syscall return path: Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2 Modules linked in: CPU: 0 PID: 652 Comm: modprobe Tainted: G D 4.18.0-rc3+ torvalds#8 PC is at ret_fast_syscall+0x4/0x62 LR is at sys_brk+0x109/0x128 pc : [<80101004>] lr : [<801c8a35>] psr: 60000013 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 50c5387d Table: 9e82006a DAC: 00000051 Process modprobe (pid: 652, stack limit = 0x(ptrval)) 80101000 <ret_fast_syscall>: 80101000: b672 cpsid i 80101002: f8d9 2008 ldr.w r2, [r9, torvalds#8] 80101006: f1b2 4ffe cmp.w r2, #2130706432 ; 0x7f000000 80101184 <local_restart>: 80101184: f8d9 a000 ldr.w sl, [r9] 80101188: e92d 0030 stmdb sp!, {r4, r5} 8010118c: f01a 0ff0 tst.w sl, torvalds#240 ; 0xf0 80101190: d117 bne.n 801011c2 <__sys_trace> 80101192: 46ba mov sl, r7 80101194: f5ba 7fc8 cmp.w sl, torvalds#400 ; 0x190 80101198: bf28 it cs 8010119a: f04f 0a00 movcs.w sl, #0 8010119e: f3af 8014 nop.w {20} 801011a2: f2af 1ea2 subw lr, pc, torvalds#418 ; 0x1a2 To fix this, add a new symbol name which doesn't have ENDPROC used on it and use that with badr. We can't remove the badr usage since that would would cause breakage with older binutils. Signed-off-by: Vincent Whitchurch <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit afc9f65 ] When building the kernel as Thumb-2 with binutils 2.29 or newer, if the assembler has seen the .type directive (via ENDPROC()) for a symbol, it automatically handles the setting of the lowest bit when the symbol is used with ADR. The badr macro on the other hand handles this lowest bit manually. This leads to a jump to a wrong address in the wrong state in the syscall return path: Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2 Modules linked in: CPU: 0 PID: 652 Comm: modprobe Tainted: G D 4.18.0-rc3+ #8 PC is at ret_fast_syscall+0x4/0x62 LR is at sys_brk+0x109/0x128 pc : [<80101004>] lr : [<801c8a35>] psr: 60000013 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 50c5387d Table: 9e82006a DAC: 00000051 Process modprobe (pid: 652, stack limit = 0x(ptrval)) 80101000 <ret_fast_syscall>: 80101000: b672 cpsid i 80101002: f8d9 2008 ldr.w r2, [r9, #8] 80101006: f1b2 4ffe cmp.w r2, #2130706432 ; 0x7f000000 80101184 <local_restart>: 80101184: f8d9 a000 ldr.w sl, [r9] 80101188: e92d 0030 stmdb sp!, {r4, r5} 8010118c: f01a 0ff0 tst.w sl, torvalds#240 ; 0xf0 80101190: d117 bne.n 801011c2 <__sys_trace> 80101192: 46ba mov sl, r7 80101194: f5ba 7fc8 cmp.w sl, torvalds#400 ; 0x190 80101198: bf28 it cs 8010119a: f04f 0a00 movcs.w sl, #0 8010119e: f3af 8014 nop.w {20} 801011a2: f2af 1ea2 subw lr, pc, torvalds#418 ; 0x1a2 To fix this, add a new symbol name which doesn't have ENDPROC used on it and use that with badr. We can't remove the badr usage since that would would cause breakage with older binutils. Signed-off-by: Vincent Whitchurch <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

In order to create an internal vport, internal_dev_create() is used and that calls register_netdevice() internally. If register_netdevice() fails, it calls dev->priv_destructor() to free private data of netdev. actually, a private data of this is a vport. Hence internal_dev_create() should not free and use a vport after failure of register_netdevice(). Test command ovs-dpctl add-dp bonding_masters Splat looks like: [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G B 5.2.0-rc3+ torvalds#240 [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch] [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4 [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206 [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704 [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560 [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881 [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000 [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698 [ 1035.777709] FS: 00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000 [ 1035.777709] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0 [ 1035.777709] Call Trace: [ 1035.777709] ovs_vport_add+0x267/0x4f0 [openvswitch] [ 1035.777709] new_vport+0x15/0x1e0 [openvswitch] [ 1035.777709] ovs_vport_cmd_new+0x567/0xd10 [openvswitch] [ 1035.777709] ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch] [ 1035.777709] ? __kmalloc+0x131/0x2e0 [ 1035.777709] ? genl_family_rcv_msg+0xa54/0x1030 [ 1035.777709] genl_family_rcv_msg+0x63a/0x1030 [ 1035.777709] ? genl_unregister_family+0x630/0x630 [ 1035.841681] ? debug_show_all_locks+0x2d0/0x2d0 [ ... ] Fixes: cf124db ("net: Fix inconsistent teardown and release of private netdev state.") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Greg Rose <[email protected]> Signed-off-by: David S. Miller <[email protected]>

[ Upstream commit 309b669 ] In order to create an internal vport, internal_dev_create() is used and that calls register_netdevice() internally. If register_netdevice() fails, it calls dev->priv_destructor() to free private data of netdev. actually, a private data of this is a vport. Hence internal_dev_create() should not free and use a vport after failure of register_netdevice(). Test command ovs-dpctl add-dp bonding_masters Splat looks like: [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G B 5.2.0-rc3+ torvalds#240 [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch] [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4 [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206 [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704 [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560 [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881 [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000 [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698 [ 1035.777709] FS: 00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000 [ 1035.777709] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0 [ 1035.777709] Call Trace: [ 1035.777709] ovs_vport_add+0x267/0x4f0 [openvswitch] [ 1035.777709] new_vport+0x15/0x1e0 [openvswitch] [ 1035.777709] ovs_vport_cmd_new+0x567/0xd10 [openvswitch] [ 1035.777709] ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch] [ 1035.777709] ? __kmalloc+0x131/0x2e0 [ 1035.777709] ? genl_family_rcv_msg+0xa54/0x1030 [ 1035.777709] genl_family_rcv_msg+0x63a/0x1030 [ 1035.777709] ? genl_unregister_family+0x630/0x630 [ 1035.841681] ? debug_show_all_locks+0x2d0/0x2d0 [ ... ] Fixes: cf124db ("net: Fix inconsistent teardown and release of private netdev state.") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Greg Rose <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 309b669 ] In order to create an internal vport, internal_dev_create() is used and that calls register_netdevice() internally. If register_netdevice() fails, it calls dev->priv_destructor() to free private data of netdev. actually, a private data of this is a vport. Hence internal_dev_create() should not free and use a vport after failure of register_netdevice(). Test command ovs-dpctl add-dp bonding_masters Splat looks like: [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G B 5.2.0-rc3+ #240 [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch] [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4 [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206 [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704 [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560 [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881 [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000 [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698 [ 1035.777709] FS: 00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000 [ 1035.777709] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0 [ 1035.777709] Call Trace: [ 1035.777709] ovs_vport_add+0x267/0x4f0 [openvswitch] [ 1035.777709] new_vport+0x15/0x1e0 [openvswitch] [ 1035.777709] ovs_vport_cmd_new+0x567/0xd10 [openvswitch] [ 1035.777709] ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch] [ 1035.777709] ? __kmalloc+0x131/0x2e0 [ 1035.777709] ? genl_family_rcv_msg+0xa54/0x1030 [ 1035.777709] genl_family_rcv_msg+0x63a/0x1030 [ 1035.777709] ? genl_unregister_family+0x630/0x630 [ 1035.841681] ? debug_show_all_locks+0x2d0/0x2d0 [ ... ] Fixes: cf124db ("net: Fix inconsistent teardown and release of private netdev state.") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Greg Rose <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 309b669 ] In order to create an internal vport, internal_dev_create() is used and that calls register_netdevice() internally. If register_netdevice() fails, it calls dev->priv_destructor() to free private data of netdev. actually, a private data of this is a vport. Hence internal_dev_create() should not free and use a vport after failure of register_netdevice(). Test command ovs-dpctl add-dp bonding_masters Splat looks like: [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G B 5.2.0-rc3+ torvalds#240 [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch] [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4 [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206 [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704 [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560 [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881 [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000 [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698 [ 1035.777709] FS: 00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000 [ 1035.777709] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0 [ 1035.777709] Call Trace: [ 1035.777709] ovs_vport_add+0x267/0x4f0 [openvswitch] [ 1035.777709] new_vport+0x15/0x1e0 [openvswitch] [ 1035.777709] ovs_vport_cmd_new+0x567/0xd10 [openvswitch] [ 1035.777709] ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch] [ 1035.777709] ? __kmalloc+0x131/0x2e0 [ 1035.777709] ? genl_family_rcv_msg+0xa54/0x1030 [ 1035.777709] genl_family_rcv_msg+0x63a/0x1030 [ 1035.777709] ? genl_unregister_family+0x630/0x630 [ 1035.841681] ? debug_show_all_locks+0x2d0/0x2d0 [ ... ] Fixes: cf124db ("net: Fix inconsistent teardown and release of private netdev state.") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Greg Rose <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Add a big batch of test coverage to assert all aspects of the tcx opts attach, detach and query API: # ./vmtest.sh -- ./test_progs -t tc_opts [...] torvalds#238 tc_opts_after:OK torvalds#239 tc_opts_append:OK torvalds#240 tc_opts_basic:OK torvalds#241 tc_opts_before:OK torvalds#242 tc_opts_chain_classic:OK torvalds#243 tc_opts_demixed:OK torvalds#244 tc_opts_detach:OK torvalds#245 tc_opts_detach_after:OK torvalds#246 tc_opts_detach_before:OK torvalds#247 tc_opts_dev_cleanup:OK torvalds#248 tc_opts_invalid:OK torvalds#249 tc_opts_mixed:OK torvalds#250 tc_opts_prepend:OK torvalds#251 tc_opts_replace:OK torvalds#252 tc_opts_revision:OK Summary: 15/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]>

Add a big batch of test coverage to assert all aspects of the tcx opts attach, detach and query API: # ./vmtest.sh -- ./test_progs -t tc_opts [...] torvalds#238 tc_opts_after:OK torvalds#239 tc_opts_append:OK torvalds#240 tc_opts_basic:OK torvalds#241 tc_opts_before:OK torvalds#242 tc_opts_chain_classic:OK torvalds#243 tc_opts_demixed:OK torvalds#244 tc_opts_detach:OK torvalds#245 tc_opts_detach_after:OK torvalds#246 tc_opts_detach_before:OK torvalds#247 tc_opts_dev_cleanup:OK torvalds#248 tc_opts_invalid:OK torvalds#249 tc_opts_mixed:OK torvalds#250 tc_opts_prepend:OK torvalds#251 tc_opts_replace:OK torvalds#252 tc_opts_revision:OK Summary: 15/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>

[...] torvalds#234 tc_links_after:OK torvalds#235 tc_links_append:OK torvalds#236 tc_links_basic:OK torvalds#237 tc_links_before:OK torvalds#238 tc_links_chain_classic:OK torvalds#239 tc_links_chain_mixed:OK torvalds#240 tc_links_dev_cleanup:OK torvalds#241 tc_links_ingress:OK torvalds#242 tc_links_invalid:OK torvalds#243 tc_links_prepend:OK torvalds#244 tc_links_replace:OK torvalds#245 tc_links_revision:OK torvalds#246 tc_opts_after:OK torvalds#247 tc_opts_append:OK torvalds#248 tc_opts_basic:OK torvalds#249 tc_opts_before:OK torvalds#250 tc_opts_chain_classic:OK torvalds#251 tc_opts_chain_mixed:OK torvalds#252 tc_opts_delete_empty:OK torvalds#253 tc_opts_demixed:OK torvalds#254 tc_opts_detach:OK torvalds#255 tc_opts_detach_after:OK torvalds#256 tc_opts_detach_before:OK torvalds#257 tc_opts_dev_cleanup:OK torvalds#258 tc_opts_invalid:OK torvalds#259 tc_opts_mixed:OK torvalds#260 tc_opts_prepend:OK torvalds#261 tc_opts_replace:OK torvalds#262 tc_opts_revision:OK [...] Signed-off-by: Daniel Borkmann <[email protected]>

Add several new tcx test cases to improve test coverage. This also includes a few new tests with ingress instead of clsact qdisc, to cover the fix from commit dc644b5 ("tcx: Fix splat in ingress_destroy upon tcx_entry_free"). # ./test_progs -t tc [...] torvalds#234 tc_links_after:OK torvalds#235 tc_links_append:OK torvalds#236 tc_links_basic:OK torvalds#237 tc_links_before:OK torvalds#238 tc_links_chain_classic:OK torvalds#239 tc_links_chain_mixed:OK torvalds#240 tc_links_dev_cleanup:OK torvalds#241 tc_links_dev_mixed:OK torvalds#242 tc_links_ingress:OK torvalds#243 tc_links_invalid:OK torvalds#244 tc_links_prepend:OK torvalds#245 tc_links_replace:OK torvalds#246 tc_links_revision:OK torvalds#247 tc_opts_after:OK torvalds#248 tc_opts_append:OK torvalds#249 tc_opts_basic:OK torvalds#250 tc_opts_before:OK torvalds#251 tc_opts_chain_classic:OK torvalds#252 tc_opts_chain_mixed:OK torvalds#253 tc_opts_delete_empty:OK torvalds#254 tc_opts_demixed:OK torvalds#255 tc_opts_detach:OK torvalds#256 tc_opts_detach_after:OK torvalds#257 tc_opts_detach_before:OK torvalds#258 tc_opts_dev_cleanup:OK torvalds#259 tc_opts_invalid:OK torvalds#260 tc_opts_mixed:OK torvalds#261 tc_opts_prepend:OK torvalds#262 tc_opts_replace:OK torvalds#263 tc_opts_revision:OK [...] Summary: 44/38 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]>

Add several new tcx test cases to improve test coverage. This also includes a few new tests with ingress instead of clsact qdisc, to cover the fix from commit dc644b5 ("tcx: Fix splat in ingress_destroy upon tcx_entry_free"). # ./test_progs -t tc [...] torvalds#234 tc_links_after:OK torvalds#235 tc_links_append:OK torvalds#236 tc_links_basic:OK torvalds#237 tc_links_before:OK torvalds#238 tc_links_chain_classic:OK torvalds#239 tc_links_chain_mixed:OK torvalds#240 tc_links_dev_cleanup:OK torvalds#241 tc_links_dev_mixed:OK torvalds#242 tc_links_ingress:OK torvalds#243 tc_links_invalid:OK torvalds#244 tc_links_prepend:OK torvalds#245 tc_links_replace:OK torvalds#246 tc_links_revision:OK torvalds#247 tc_opts_after:OK torvalds#248 tc_opts_append:OK torvalds#249 tc_opts_basic:OK torvalds#250 tc_opts_before:OK torvalds#251 tc_opts_chain_classic:OK torvalds#252 tc_opts_chain_mixed:OK torvalds#253 tc_opts_delete_empty:OK torvalds#254 tc_opts_demixed:OK torvalds#255 tc_opts_detach:OK torvalds#256 tc_opts_detach_after:OK torvalds#257 tc_opts_detach_before:OK torvalds#258 tc_opts_dev_cleanup:OK torvalds#259 tc_opts_invalid:OK torvalds#260 tc_opts_mixed:OK torvalds#261 tc_opts_prepend:OK torvalds#262 tc_opts_replace:OK torvalds#263 tc_opts_revision:OK [...] Summary: 44/38 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/8699efc284b75ccdc51ddf7062fa2370330dc6c0.1692029283.git.daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <[email protected]>

Fix frequency range

514d878

Si2157 supports from 42 to 870 mhz

koshkoshka changed the title ~~Fix frequency range~~ Fix frequency range for SI2157 Tuner Jan 4, 2016

koshkoshka closed this Mar 23, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix frequency range for SI2157 Tuner #240

Fix frequency range for SI2157 Tuner #240

koshkoshka commented Dec 30, 2015

ticki commented Jan 3, 2016

koshkoshka commented Jan 18, 2016

ghost commented Jan 18, 2016

ticki commented Jan 18, 2016

ghost commented Jan 18, 2016

ticki commented Jan 18, 2016

philipperemy commented Mar 23, 2016

manushaurya commented Mar 23, 2016

ticki commented Mar 23, 2016

Fix frequency range for SI2157 Tuner #240

Fix frequency range for SI2157 Tuner #240

Conversation

koshkoshka commented Dec 30, 2015

ticki commented Jan 3, 2016

koshkoshka commented Jan 18, 2016

ghost commented Jan 18, 2016

ticki commented Jan 18, 2016

ghost commented Jan 18, 2016

ticki commented Jan 18, 2016

philipperemy commented Mar 23, 2016

manushaurya commented Mar 23, 2016

ticki commented Mar 23, 2016