Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not
On Thu, Jan 23, 2020 at 10:03 AM Linus Torvalds wrote: > We used to have a read/write argument to the old "verify_area()" and > "access_ok()" model, and it was a mistake. It was due to odd i386 user > access issues. We got rid of it. I'm not convinced this is any better > - it looks very similar and for odd ppc access issues. If the mode (read or write) were made visible to the trap handler, I'd find that useful for machine check recovery. If I'm in the middle of a copy_from_user() and I get a machine check reading poison from a user address ... then I could try to recover in the same way as for the user accessing the poison (offline the page, SIGBUS the task). But if the poison is in kernel memory and we are doing a copy_to_user(), then we are hosed (or would need some more complex recovery plan). [Note that we only get recoverable machine checks on loads... writes are posted, so if something goes wrong it isn't synchronous with the store instruction that initiated it] -Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Wed, May 25, 2011 at 7:12 AM, Boaz Harrosh wrote: > So if you combine all the above: > > D. Y. N > D - Is the decade since birth (1991 not 1990) > Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and > so on > Nice incremental number. > N - The Linus release of this Year. So this 3rd one goes up to 4 most > probably. > > Linus always likes, and feels very poetic about the Christmas version release. > He hates it when once it slipped into the next year. So now he gets to > increment > the second digit as a bonus. > > The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to > symbolize > the 1991 birth. And we never have .zero quality, right? > > The first Digit gets incremented on decade from 1991 so on 2011 and not 2010 This is clearly the best suggestion so far - small numbers, somewhat date related (but without stuffing a "2011." on the front). No ".0" releases, ever. But best of all it defines now when we will switch to 4.x.y and 5.x.y so we don't have to keep having this discussion whenever someone thinks that the numbers are getting "too big" (well perhaps when we get to the tenth decade or so :-) So the only thing left to argue is whether the upcoming release should be numbered "3.1.1" as the first release in the first year of the 3rd decade ... or whether we should count 2.6.37 .. 2.6.39 as the first three releases this year and thus we ought to start with "3.1.4" (so we start with "pi"!). Linus: If you go with this, you should let Boaz set the new "NAME" as a prize for such an inspired solution. -Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
On Wed, May 25, 2011 at 7:12 AM, Boaz Harrosh wrote: > So if you combine all the above: > > D. Y. N > D - Is the decade since birth (1991 not 1990) > Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and > so on > ? ?Nice incremental number. > N - The Linus release of this Year. So this 3rd one goes up to 4 most > probably. > > Linus always likes, and feels very poetic about the Christmas version release. > He hates it when once it slipped into the next year. So now he gets to > increment > the second digit as a bonus. > > The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to > symbolize > the 1991 birth. And we never have .zero quality, right? > > The first Digit gets incremented on decade from 1991 so on 2011 and not 2010 This is clearly the best suggestion so far - small numbers, somewhat date related (but without stuffing a "2011." on the front). No ".0" releases, ever. But best of all it defines now when we will switch to 4.x.y and 5.x.y so we don't have to keep having this discussion whenever someone thinks that the numbers are getting "too big" (well perhaps when we get to the tenth decade or so :-) So the only thing left to argue is whether the upcoming release should be numbered "3.1.1" as the first release in the first year of the 3rd decade ... or whether we should count 2.6.37 .. 2.6.39 as the first three releases this year and thus we ought to start with "3.1.4" (so we start with "pi"!). Linus: If you go with this, you should let Boaz set the new "NAME" as a prize for such an inspired solution. -Tony
Re: [PATCH v5 0/7] drm/mgag200: Implement VBLANK support
My system threw out a bunch of stack traces while booting v6.12-rc1 and hung. First of these looks like this: [ 33.639799] fbcon: mgag200drmfb (fb0) is primary device [ 33.651573] ixgbe :03:00.0: Intel(R) 10 Gigabit Network Connection [ 33.652092] ixgbe :03:00.1: enabling device (0100 -> 0102) [ 33.818328] [ cut here ] [ 33.818362] [CRTC:34:crtc-0] vblank wait timed out [ 33.818422] WARNING: CPU: 44 PID: 1815 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x245/0x250 [drm_kms_helper] [ 33.818447] Modules linked in: crct10dif_pclmul mgag200(+) crc32_pclmul i2c_algo_bit crc32c_intel drm_shmem_helper ghash_clmulni_intel sha512_ssse3 drm_kms_helper sha256_ssse3 sha1_ssse3 ixgbe(+) mpt3sas mdio drm raid_class dca scsi_transport_sas wmi fuse [ 33.818475] CPU: 44 PID: 1815 Comm: systemd-udevd Not tainted 6.10.0-rc1+ #168 [ 33.818478] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRBDXSD1.86B.0338.V01.1603162127 03/16/2016 [ 33.818481] RIP: 0010:drm_atomic_helper_wait_for_vblanks.part.0+0x245/0x250 [drm_kms_helper] [ 33.818490] Code: 00 48 8d 7b 08 e8 2b 7e 61 da 45 85 ff 0f 85 d3 fe ff ff 49 8b 56 20 41 8b b6 d8 00 00 00 48 c7 c7 38 52 ba c0 e8 8b 53 59 da <0f> 0b e9 b5 fe ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 [ 33.818493] RSP: 0018:bf61a3faf690 EFLAGS: 00010282 [ 33.818496] RAX: 0026 RBX: 99be04ad3028 RCX: [ 33.818499] RDX: 0002 RSI: 9c9fd7c8 RDI: [ 33.818501] RBP: 99be08a76c00 R08: 0001 R09: [ 33.818503] R10: 0001 R11: 99f1011fffe8 R12: [ 33.818504] R13: R14: 99be0bcf93f8 R15: [ 33.818506] FS: 7fbe18e7db40() GS:99ca61c0() knlGS: [ 33.818509] CS: 0010 DS: ES: CR0: 80050033 [ 33.818510] CR2: 55b77636c1f8 CR3: 0e486004 CR4: 003706f0 [ 33.818513] DR0: DR1: DR2: [ 33.818514] DR3: DR6: fffe0ff0 DR7: 0400 [ 33.818516] Call Trace: [ 33.818519] [ 33.818521] ? __warn+0x8b/0x190 [ 33.818535] ? drm_atomic_helper_wait_for_vblanks.part.0+0x245/0x250 [drm_kms_helper] [ 33.818545] ? report_bug+0x1c3/0x1d0 [ 33.818559] ? handle_bug+0x42/0x70 [ 33.818571] ? exc_invalid_op+0x14/0x70 [ 33.818575] ? asm_exc_invalid_op+0x16/0x20 [ 33.818589] ? drm_atomic_helper_wait_for_vblanks.part.0+0x245/0x250 [drm_kms_helper] [ 33.818602] ? __pfx_autoremove_wake_function+0x10/0x10 [ 33.818614] drm_atomic_helper_commit_tail+0x71/0x80 [drm_kms_helper] [ 33.818625] mgag200_mode_config_helper_atomic_commit_tail+0x28/0x40 [mgag200] [ 33.818633] commit_tail+0x94/0x130 [drm_kms_helper] [ 33.818644] drm_atomic_helper_commit+0x13e/0x170 [drm_kms_helper] [ 33.818655] drm_atomic_commit+0x97/0xb0 [drm] [ 33.818717] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 33.818750] drm_client_modeset_commit_atomic+0x207/0x250 [drm] [ 33.818783] drm_client_modeset_commit_locked+0x5b/0x190 [drm] [ 33.818807] drm_client_modeset_commit+0x24/0x50 [drm] [ 33.818829] __drm_fb_helper_restore_fbdev_mode_unlocked+0x92/0xc0 [drm_kms_helper] [ 33.818841] drm_fb_helper_set_par+0x2e/0x40 [drm_kms_helper] [ 33.818850] fbcon_init+0x2a8/0x560 [ 33.818860] visual_init+0xc4/0x120 [ 33.818867] do_bind_con_driver.isra.0+0x1a1/0x3d0 [ 33.818875] do_take_over_console+0x10b/0x1a0 [ 33.818880] do_fbcon_takeover+0x5c/0xc0 [ 33.818883] fbcon_fb_registered+0x49/0x70 [ 33.818886] register_framebuffer+0x190/0x250 [ 33.818896] __drm_fb_helper_initial_config_and_unlock+0x345/0x590 [drm_kms_helper] [ 33.818906] ? drm_client_register+0x33/0xc0 [drm] [ 33.818934] drm_fbdev_shmem_client_hotplug+0x6c/0xc0 [drm_shmem_helper] [ 33.818939] drm_client_register+0x7b/0xc0 [drm] [ 33.818963] mgag200_pci_probe+0x90/0x180 [mgag200] [ 33.818970] local_pci_probe+0x46/0xa0 [ 33.818978] pci_device_probe+0xb5/0x230 [ 33.818986] really_probe+0xd9/0x380 [ 33.818993] __driver_probe_device+0x78/0x150 [ 33.818997] driver_probe_device+0x1e/0x90 [ 33.819000] __driver_attach+0xd6/0x1d0 [ 33.819003] ? __pfx___driver_attach+0x10/0x10 [ 33.819005] bus_for_each_dev+0x66/0xa0 [ 33.819012] bus_add_driver+0x111/0x240 [ 33.819018] driver_register+0x5c/0x120 [ 33.819021] ? __pfx_mgag200_pci_driver_init+0x10/0x10 [mgag200] [ 33.819026] do_one_initcall+0x62/0x3a0 [ 33.819035] ? kmalloc_trace_noprof+0x2a0/0x340 [ 33.819048] do_init_module+0x64/0x240 [ 33.819058] init_module_from_file+0x7a/0xa0 [ 33.819072] idempotent_init_module+0x15a/0x210 [ 33.819079] ? __startup_64+0x70/0x3f0 [ 33.819086] __x64_sys_finit_module+0x5a/0xb0 [ 33.819092] do_syscall_64+0x73/0x190 [ 33.819098] entry_SYSCALL_64_
