From nobody Fri Jan 19 18:40:32 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TGpMl1bjPz576ch; Fri, 19 Jan 2024 18:40:35 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TGpMk4BBTz4ggH; Fri, 19 Jan 2024 18:40:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5955a4a9b23so623852eaf.1; Fri, 19 Jan 2024 10:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705689633; x=1706294433; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uTG3reCpZh3CO3F+kLnQjfwofNc9g256sOEYi5UpQYQ=; b=ktwK15y5fi/lghsclVBNgBOr2NaMpK6fQuDhAAudJ5LwTV1vN8fZOcS1gNOM9Z9gRR lCWpnnQfs8rBuSXYqvX/Ju2QTDPzzORJSGtP/RKOjXMzJjL7zVv3FZkVFjIZvnVJqjuG JKkFkvs1L3UJwSrbTLtOM0dofnnJSSuk9t7/hxQQsW2ECZgq9rJ2MBeeS0CMmf5V9pb9 bOTksW70oIFB3rD3zYCYyrVn1/TKyzCOKX+TxpRsNwrQ4pfYA0DK7hmj53q/p2Yv8+s/ a2XHBKjg8xrWlpM7lZWhmEEJu0TYtRCgKEiKDxxZkZOAbAYLFkqAnBCPlXy/p4OPX296 GlnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705689633; x=1706294433; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uTG3reCpZh3CO3F+kLnQjfwofNc9g256sOEYi5UpQYQ=; b=hlxwTr61Z6EX8ZW05C7aE27SVCeRBp/YkFz6lIVv7fUfskKgJtViQ9kYcmHoBRwCjR rPpA/32QrrJN+ir7nCKJYJVO6HwQOBZiTH5/GoU0hVNZblQojjMBfmWAjKht8e3qh0TR CRuZ/fLXzxzKNYVFVf70xpxjMJYJMx5OQzZMWBtBn/dup1dRsbeeDo7tSD2akKS8EfsR lqer/aMN+4HyrCu4OPn1lb4vs1hwTRrqEt5vxJ0tnl5uviXe8Fa248E+/6ZRi86GaQun 4z+At8ttmUxRTGGbpCxsYWSww1dPDQY+rKajvOl9fESPwQO8tcdb/3OHX8MhgBFms7Rx Yleg== X-Gm-Message-State: AOJu0YyHNT3fnmjSMYnPB1n7R3HwCF2LkBUi7NxFo4Bm66HvAhl/dfrb DUxVvxb5/EqYGS3P+PXTmCmHmXrUDQ+sJwYXB6hSOX05A2hkNpTGD2wgoo6JqNlqyiFjPZBw61p 1vayCp0MYCY3H/H2aLXlISRdCK4M= X-Google-Smtp-Source: AGHT+IHxoxTS2q62/LAXnuTz7TywckD8vpPkCSBgJ6bAV+NKDKkkSasgdYQmEvJVs3TxR1D2JkjXvzPofn/jBqYSm90= X-Received: by 2002:a4a:a7c9:0:b0:591:b9ce:4f8f with SMTP id n9-20020a4aa7c9000000b00591b9ce4f8fmr120257oom.19.1705689633458; Fri, 19 Jan 2024 10:40:33 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a8a:e8b:0:b0:512:723e:b179 with HTTP; Fri, 19 Jan 2024 10:40:32 -0800 (PST) In-Reply-To: References: <20240119131047.6975f574@rimwks.local> From: Mateusz Guzik Date: Fri, 19 Jan 2024 19:40:32 +0100 Message-ID: Subject: Re: kcmp implementation for mesa To: Michael Zhilin Cc: Rozhuk Ivan , FreeBSD Hackers , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4TGpMk4BBTz4ggH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] instead of messing with code like this it's probably time to implement kcmp in the kernel On 1/19/24, Michael Zhilin wrote: > Hi Ivan, > > Looks good. Could you please put patch on reviews.freebsd.org? > > Thx, > Michael > > On Fri, 19 Jan 2024, 14:11 Rozhuk Ivan, wrote: > >> Hi! >> >> >> graphics/mesa-* uses SYS_kcmp [1] to compare two fds: >> >> int >> os_same_file_description(int fd1, int fd2) >> { >> pid_t pid = getpid(); >> >> /* Same file descriptor trivially implies same file description */ >> if (fd1 == fd2) >> return 0; >> >> return syscall(SYS_kcmp, pid, pid, KCMP_FILE, fd1, fd2); >> } >> >> FreeBSD does not implemet this and we got in terminal: >> "amdgpu: os_same_file_description couldn't determine if two DRM fds >> reference the same file description." >> >> >> Mesa say: >> /* DRM file descriptors, file descriptions and buffer sharing. >> * >> * amdgpu_device_initialize first argument is a file descriptor (fd) >> * representing a specific GPU. >> * If a fd is duplicated using os_dupfd_cloexec, >> * the file description will remain the same (os_same_file_description >> will >> * return 0). >> * But if the same device is re-opened, the fd and the file description >> will >> * be different. >> * >> * amdgpu_screen_winsys's fd tracks the file description which was >> * given to amdgpu_winsys_create. This is the fd used by the application >> * using the driver and may be used in other ioctl (eg: drmModeAddFB) >> * >> * amdgpu_winsys's fd is the file description used to initialize the >> * device handle in libdrm_amdgpu. >> * >> * The 2 fds can be different, even in systems with a single GPU, eg: if >> * radv is initialized before radeonsi. >> * >> * This fd tracking is useful for buffer sharing because KMS/GEM handles >> are >> * specific to a DRM file description, i.e. the same handle value may >> refer >> * to different underlying BOs in different DRM file descriptions. >> * As an example, if an app wants to use drmModeAddFB it'll need a KMS >> handle >> * valid for its fd (== amdgpu_screen_winsys::fd). >> * If both fds are identical, there's nothing to do: >> bo->u.real.kms_handle >> * can be used directly (see amdgpu_bo_get_handle). >> * If they're different, the BO has to be exported from the device fd as >> * a dma-buf, then imported from the app fd as a KMS handle. >> */ >> >> >> >> I do few checks with dup() and os_dupfd_cloexec() and code show that fd >> equal. >> >> Does this implementation will do that mesa expects? >> >> >> #include >> #include >> >> int >> os_same_file_description(int fd1, int fd2) { >> struct kinfo_file kif1, kif2; >> >> /* Same file descriptor trivially implies same file description >> */ >> if (fd1 == fd2) >> return (0); >> >> kif1.kf_structsize = sizeof(kif1); >> kif2.kf_structsize = sizeof(kif2); >> if (-1 == fcntl(fd1, F_KINFO, &kif1) || >> -1 == fcntl(fd2, F_KINFO, &kif2)) >> return (-1); >> >> if (kif1.kf_type != kif2.kf_type || >> 0 != memcmp(&kif1.kf_path, &kif2.kf_path, >> sizeof(kif1.kf_path))) >> return (3); >> >> switch (kif1.kf_type) { >> case KF_TYPE_VNODE: >> if (0 == memcmp(&kif1.kf_un.kf_file, &kif2.kf_un.kf_file, >> sizeof(kif1.kf_un.kf_file))) >> return (0); >> return (3); >> case KF_TYPE_SOCKET: >> if (0 == memcmp(&kif1.kf_un.kf_sock, &kif2.kf_un.kf_sock, >> sizeof(kif1.kf_un.kf_sock))) >> return (0); >> return (3); >> case KF_TYPE_PIPE: >> if (0 == memcmp(&kif1.kf_un.kf_pipe, &kif2.kf_un.kf_pipe, >> sizeof(kif1.kf_un.kf_pipe))) >> return (0); >> return (3); >> //case KF_TYPE_FIFO: >> case KF_TYPE_KQUEUE: >> if (0 == memcmp(&kif1.kf_un.kf_kqueue, >> &kif2.kf_un.kf_kqueue, >> sizeof(kif1.kf_un.kf_kqueue))) >> return (0); >> return (3); >> //case KF_TYPE_MQUEUE: >> //case KF_TYPE_SHM: >> case KF_TYPE_SEM: >> if (0 == memcmp(&kif1.kf_un.kf_sem, &kif2.kf_un.kf_sem, >> sizeof(kif1.kf_un.kf_sem))) >> return (0); >> return (3); >> case KF_TYPE_PTS: >> if (0 == memcmp(&kif1.kf_un.kf_pts, &kif2.kf_un.kf_pts, >> sizeof(kif1.kf_un.kf_pts))) >> return (0); >> return (3); >> case KF_TYPE_PROCDESC: >> if (0 == memcmp(&kif1.kf_un.kf_proc, &kif2.kf_un.kf_proc, >> sizeof(kif1.kf_un.kf_proc))) >> return (0); >> return (3); >> //case KF_TYPE_DEV: >> case KF_TYPE_EVENTFD: >> if (0 == memcmp(&kif1.kf_un.kf_eventfd, >> &kif2.kf_un.kf_eventfd, >> sizeof(kif1.kf_un.kf_eventfd))) >> return (0); >> return (3); >> case KF_TYPE_TIMERFD: >> if (0 == memcmp(&kif1.kf_un.kf_timerfd, >> &kif2.kf_un.kf_timerfd, >> sizeof(kif1.kf_un.kf_timerfd))) >> return (0); >> return (3); >> } >> /* Otherwise we can't tell */ >> return (-1); >> } >> >> >> Refs: >> 1. https://man7.org/linux/man-pages/man2/kcmp.2.html >> >> >> > -- Mateusz Guzik