- Linaro-mm-sig - lists.linaro.org

Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

by Christian König

Am 18.04.24 um 03:33 schrieb zhiguojiang: > 在 2024/4/15 19:57, Christian König 写道: >> [Some people who received this message don't often get email from >> christian.koenig(a)amd.com. Learn why this is important at >> https://aka.ms/LearnAboutSenderIdentification ] >> >> Am 15.04.24 um 12:35 schrieb zhiguojiang: >>> 在 2024/4/12 14:39, Christian König 写道: >>>> [Some people who received this message don't often get email from >>>> christian.koenig(a)amd.com. Learn why this is important at >>>> https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> Am 12.04.24 um 08:19 schrieb zhiguojiang: >>>>> [SNIP] >>>>> -> Here task 2220 do epoll again where internally it will get/put >>>>> then >>>>> start to free twice and lead to final crash. >>>>> >>>>> Here is the basic flow: >>>>> >>>>> 1. Thread A install the dma_buf_fd via dma_buf_export, the fd >>>>> refcount >>>>> is 1 >>>>> >>>>> 2. Thread A add the fd to epoll list via epoll_ctl(EPOLL_CTL_ADD) >>>>> >>>>> 3. After use the dma buf, Thread A close the fd, then here fd >>>>> refcount >>>>> is 0, >>>>> and it will run __fput finally to release the file >>>> >>>> Stop, that isn't correct. >>>> >>>> The fs layer which calls dma_buf_poll() should make sure that the file >>>> can't go away until the function returns. >>>> >>>> Then inside dma_buf_poll() we add another reference to the file while >>>> installing the callback: >>>> >>>> /* Paired with fput in dma_buf_poll_cb */ >>>> get_file(dmabuf->file); >>> Hi, >>> >>> The problem may just occurred here. >>> >>> Is it possible file reference count already decreased to 0 and fput >>> already being in progressing just before calling >>> get_file(dmabuf->file) in dma_buf_poll()? >> >> No, exactly that isn't possible. >> >> If a function gets a dma_buf pointer or even more general any reference >> counted pointer which has already decreased to 0 then that is a major >> bug in the caller of that function. >> >> BTW: It's completely illegal to work around such issues by using >> file_count() or RCU functions. So when you suggest stuff like that it >> will immediately face rejection. >> >> Regards, >> Christian. > Hi, > > Thanks for your kind comment. > > 'If a function gets a dma_buf pointer or even more general any reference > > counted pointer which has already decreased to 0 then that is a major > > bug in the caller of that function.' > > According to the issue log, we can see the dma buf file close and > epoll operation running in parallel. > > Apparently at the moment caller calls epoll, although another task > caller already called close on the same fd, but this fd was still in > progress to close, so fd is still valid, thus no EBADF returned to > caller. No, exactly that can't happen either. As far as I can see the EPOLL holds a reference to the files it contains. So it is perfectly valid to add the file descriptor to EPOLL and then close it. In this case the file won't be closed, but be kept alive by it's reference in the EPOLL file descriptor. > > Then the two task contexts operate on same dma buf fd(one is close, > another is epoll) in kernel space. > > Please kindly help to comment whether above scenario is possible. > > If there is some bug in the caller logic, Can u help to point it out? :) Well what could be is that the EPOLL implementation is broken somehow, but I have really doubts on that. As I said before the most likely explanation is that you have a broken device driver which messes up the DMA-buf file reference count somehow. Regards, Christian. > > Regards, > Zhiguo >> >>> >>>> >>>> This reference is only dropped after the callback is completed in >>>> dma_buf_poll_cb(): >>>> >>>> /* Paired with get_file in dma_buf_poll */ >>>> fput(dmabuf->file); >>>> >>>> So your explanation for the issue just seems to be incorrect. >>>> >>>>> >>>>> 4. Here Thread A not do epoll_ctl(EPOLL_CTL_DEL) manunally, so it >>>>> still resides in one epoll_list. >>>>> Although __fput will call eventpoll_release to remove the file from >>>>> binded epoll list, >>>>> but it has small time window where Thread B jumps in. >>>> >>>> Well if that is really the case then that would then be a bug in >>>> epoll_ctl(). >>>> >>>>> >>>>> 5. During the small window, Thread B do the poll action for >>>>> dma_buf_fd, where it will fget/fput for the file, >>>>> this means the fd refcount will be 0 -> 1 -> 0, and it will call >>>>> __fput again. >>>>> This will lead to __fput twice for the same file. >>>>> >>>>> 6. So the potenial fix is use get_file_rcu which to check if file >>>>> refcount already zero which means under free. >>>>> If so, we just return and no need to do the dma_buf_poll. >>>> >>>> Well to say it bluntly as far as I can see this suggestion is >>>> completely >>>> nonsense. >>>> >>>> When the reference to the file goes away while dma_buf_poll() is >>>> executed then that's a massive bug in the caller of that function. >>>> >>>> Regards, >>>> Christian. >>>> >>>>> >>>>> Here is the race condition: >>>>> >>>>> Thread A Thread B >>>>> dma_buf_export >>>>> fd_refcount is 1 >>>>> epoll_ctl(EPOLL_ADD) >>>>> add dma_buf_fd to epoll list >>>>> close(dma_buf_fd) >>>>> fd_refcount is 0 >>>>> __fput >>>>> dma_buf_poll >>>>> fget >>>>> fput >>>>> fd_refcount is zero again >>>>> >>>>> Thanks >>>>> >>>> >>> >> >

1 year, 9 months

6
12
0 0

Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

by Christian König

Am 08.05.24 um 10:23 schrieb Christian Brauner: > On Tue, May 07, 2024 at 07:45:02PM +0200, Christian König wrote: >> Am 07.05.24 um 18:46 schrieb Linus Torvalds: >>> On Tue, 7 May 2024 at 04:03, Daniel Vetter <daniel(a)ffwll.ch> wrote: >>>> It's really annoying that on some distros/builds we don't have that, and >>>> for gpu driver stack reasons we _really_ need to know whether a fd is the >>>> same as another, due to some messy uniqueness requirements on buffer >>>> objects various drivers have. >>> It's sad that such a simple thing would require two other horrid >>> models (EPOLL or KCMP). >>> >>> There'[s a reason that KCMP is a config option - *some* of that is >>> horrible code - but the "compare file descriptors for equality" is not >>> that reason. >>> >>> Note that KCMP really is a broken mess. It's also a potential security >>> hole, even for the simple things, because of how it ends up comparing >>> kernel pointers (ie it doesn't just say "same file descriptor", it >>> gives an ordering of them, so you can use KCMP to sort things in >>> kernel space). >>> >>> And yes, it orders them after obfuscating the pointer, but it's still >>> not something I would consider sane as a baseline interface. It was >>> designed for checkpoint-restore, it's the wrong thing to use for some >>> "are these file descriptors the same". >>> >>> The same argument goes for using EPOLL for that. Disgusting hack. >>> >>> Just what are the requirements for the GPU stack? Is one of the file >>> descriptors "trusted", IOW, you know what kind it is? >>> >>> Because dammit, it's *so* easy to do. You could just add a core DRM >>> ioctl for it. Literally just >>> >>> struct fd f1 = fdget(fd1); >>> struct fd f2 = fdget(fd2); >>> int same; >>> >>> same = f1.file && f1.file == f2.file; >>> fdput(fd1); >>> fdput(fd2); >>> return same; >>> >>> where the only question is if you also woudl want to deal with O_PATH >>> fd's, in which case the "fdget()" would be "fdget_raw()". >>> >>> Honestly, adding some DRM ioctl for this sounds hacky, but it sounds >>> less hacky than relying on EPOLL or KCMP. >>> >>> I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl >>> too, if this is possibly a more common thing. and not just DRM wants >>> it. >>> >>> Would something like that work for you? >> Well the generic approach yes, the DRM specific one maybe. IIRC we need to >> be able to compare both DRM as well as DMA-buf file descriptors. >> >> The basic problem userspace tries to solve is that drivers might get the >> same fd through two different code paths. >> >> For example application using OpenGL/Vulkan for rendering and VA-API for >> video decoding/encoding at the same time. >> >> Both APIs get a fd which identifies the device to use. It can be the same, >> but it doesn't have to. >> >> If it's the same device driver connection (or in kernel speak underlying >> struct file) then you can optimize away importing and exporting of buffers >> for example. >> >> Additional to that it makes cgroup accounting much easier because you don't >> count things twice because they are shared etc... > One thing to keep in mind is that a generic VFS level comparing function > will only catch the obvious case where you have dup() equivalency as > outlined above by Linus. That's what most people are interested in and > that could easily replace most kcmp() use-cases for comparing fds. > > But, of course there's the case where you have two file descriptors > referring to two different files that reference the same underlying > object (usually stashed in file->private_data). > > For most cases that problem can ofc be solved by comparing the > underlying inode. But that doesn't work for drivers using the generic > anonymous inode infrastructure because it uses the same inode for > everything or for cases where the same underlying object can even be > represented by different inodes. > > So for such cases a driver specific ioctl() to compare two fds will > be needed in addition to the generic helper. At least for the DRM we already have some solution for that, see drmGetPrimaryDeviceNameFromFd() for an example. Basically the file->private_data is still something different, but we use this to figure out if we have two file descriptors (with individual struct files underneath) pointing to the same hw driver. This is important if you need to know if just importing/exporting of DMA-buf handles between the two file descriptors is enough or if you deal with two different hw devices and need to do stuff like format conversion etc... Regards, Christian.

1 year, 9 months

1
0
0 0

Re: get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove)

by Linus Torvalds

On Mon, 6 May 2024 at 10:46, Stefan Metzmacher <metze(a)samba.org> wrote: > > I think it's a very important detail that epoll does not take > real references. Otherwise an application level 'close()' on a socket > would not trigger a tcp disconnect, when an fd is still registered with > epoll. Yes, exactly. epoll() ends up actually wanting the lifetime of the ep item be the lifetime of the file _descriptor_, not the lifetime of the file itself. We approximate that - badly - with epoll not taking a reference on the file pointer, and then at final fput() it tears things down. But that has two real issues, and one of them is that "oh, now epoll has file pointers that are actually dead" that caused this thread. The other issue is that "approximates" thing, where it means that duplicating the file pointer (dup*() and fork() end unix socket file sending etc) will not mean that the epoll ref is also out of sync with the lifetime of the file descriptor. That's why I suggested that "clean up epoll references at file_close_fd() time instead: https://lore.kernel.org/all/CAHk-=wj6XL9MGCd_nUzRj6SaKeN0TsyTTZDFpGdW34R+zM… because it would actually really *fix* the lifetime issue of ep items. In the process, it would make it possible to actually take a f_count reference at EPOLL_CTL_ADD time, since now the lifetime of the EP wouldn't be tied to the lifetime of the 'struct file *' pointer, it would be properly tied to the lifetime of the actual file descriptor that you are adding. So it would be a huge conceptual cleanup too. (Of course - at that point EPOLL_CTL_ADD still doesn't actually _need_ a reference to the file, since the file being open in itself is already that reference - but the point here being that there would *be* a reference that the epoll code would effectively have, and you'd never be in the situation we were in where there would be stale "dead" file pointers that just haven't gone through the cleanup yet). But I'd rather not touch the epoll code more than I have to. Which is why I applied the minimal patch for just "refcount over vfs_poll()", and am just mentioning my suggestion in the hope that some eager beaver would like to see how painful it would do to make the bigger surgery... Linus

1 year, 9 months

2
1
0 0

Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

by David Laight

From: Christian Brauner > Sent: 06 May 2024 09:45 > > > The fact is, it's not dma-buf that is violating any rules. It's epoll. > > I agree that epoll() not taking a reference on the file is at least > unexpected and contradicts the usual code patterns for the sake of > performance and that it very likely is the case that most callers of > f_op->poll() don't know this. > > Note, I cleary wrote upthread that I'm ok to do it like you suggested > but raised two concerns a) there's currently only one instance of > prolonged @file lifetime in f_op->poll() afaict and b) that there's > possibly going to be some performance impact on epoll(). > > So it's at least worth discussing what's more important because epoll() > is very widely used and it's not that we haven't favored performance > before. > > But you've already said that you aren't concerned with performance on > epoll() upthread. So afaict then there's really not a lot more to > discuss other than take the patch and see whether we get any complaints. Surely there isn't a problem with epoll holding a reference to the file structure - it isn't really any different to a dup(). 'All' that needs to happen is that the 'magic' that makes epoll() remove files on the last fput happen when the close is done. I'm sure there are horrid locking issues it that code (separate from it calling ->poll() after ->release()) eg if you call close() concurrently with EPOLL_CTL_ADD. I'm not at all sure it would have mattered if epoll kept the file open. But it can't do that because it is documented not to. As well as poll/select holding a reference to all their fd for the duration of the system call, a successful mmap() holds a reference until the pages are all unmapped - usually by process exit. We (dayjob) have code that uses epoll() to monitor large numbers of UDP sockets. I was doing some tests (trying to) receive RTP (audio) data concurrently on 10000 sockets with typically one packet every 20ms. There are 10000 associated RCTP sockets that are usually idle. A more normal limit would be 1000 RTP sockets. All the data needs to go into a single (multithreaded) process. Just getting all the packets queued on the sockets was non-trivial. epoll is about the only way to actually read the data. (That needed multiple epoll fd so each thread could process all the events from one epoll fd then look for another unprocessed fd.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

1 year, 9 months

1
0
0 0

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

by Daniel Vetter

On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote: > Hi, > > On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote: > > Hi dma-buf maintainers, et.al., > > > > Various people have been working on making complex/MIPI cameras work OOTB > > with mainline Linux kernels and an opensource userspace stack. > > > > The generic solution adds a software ISP (for Debayering and 3A) to > > libcamera. Libcamera's API guarantees that buffers handed to applications > > using it are dma-bufs so that these can be passed to e.g. a video encoder. > > > > In order to meet this API guarantee the libcamera software ISP allocates > > dma-bufs from userspace through one of the /dev/dma_heap/* heaps. For > > the Fedora COPR repo for the PoC of this: > > https://hansdegoede.dreamwidth.org/28153.html > > For the record, we're also considering using them for ARM KMS devices, > so it would be better if the solution wasn't only considering v4l2 > devices. > > > I have added a simple udev rule to give physically present users access > > to the dma_heap-s: > > > > KERNEL=="system", SUBSYSTEM=="dma_heap", TAG+="uaccess" > > > > (and on Rasperry Pi devices any users in the video group get access) > > > > This was just a quick fix for the PoC. Now that we are ready to move out > > of the PoC phase and start actually integrating this into distributions > > the question becomes if this is an acceptable solution; or if we need some > > other way to deal with this ? > > > > Specifically the question is if this will have any negative security > > implications? I can certainly see this being used to do some sort of > > denial of service attack on the system (1). This is especially true for > > the cma heap which generally speaking is a limited resource. > > There's plenty of other ways to exhaust CMA, like allocating too much > KMS or v4l2 buffers. I'm not sure we should consider dma-heaps > differently than those if it's part of our threat model. So generally for an arm soc where your display needs cma, your render node doesn't. And user applications only have access to the later, while only the compositor gets a kms fd through logind. At least in drm aside from vc4 there's really no render driver that just gives you access to cma and allows you to exhaust that, you need to be a compositor with drm master access to the display. Which means we're mostly protected against bad applications, and that's not a threat the "user physically sits in front of the machine accounts for", and which giving cma access to everyone would open up. And with flathub/snaps/... this is very much an issue. So you need more, either: - cgroups limits on dma-buf and dma-buf heaps. This has been bikeshedded for years and is just not really moving. - An allocator service which checks whether you're allowed to allocate these special buffers. Android does that through binder. Probably also some way to nuke applications that refuse to release buffers when they're no longer the right application. cgroups is a lot more convenient for that. -Sima > > But devices tagged for uaccess are only opened up to users who are > > physcially present behind the machine and those can just hit > > the powerbutton, so I don't believe that any *on purpose* DOS is part of > > the thread model. > > How would that work for headless devices? > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 year, 9 months

2
1
0 0

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

by Daniel Vetter

On Tue, May 07, 2024 at 04:15:05PM +0100, Bryan O'Donoghue wrote: > On 07/05/2024 16:09, Dmitry Baryshkov wrote: > > Ah, I see. Then why do you require the DMA-ble buffer at all? If you are > > providing data to VPU or DRM, then you should be able to get the buffer > > from the data-consuming device. > > Because we don't necessarily know what the consuming device is, if any. Well ... that's an entirely different issue. And it's unsolved. Currently the approach is to allocate where the constraints are usually most severe (like display, if you need that, or the camera module for input) and then just pray the stack works out without too much copying. All userspace (whether the generic glue or the userspace driver depends a bit upon the exact api) does need to have a copy fallback for these sharing cases, ideally with the copying accelerated by hw. If you try to solve this by just preemptive allocating everything as cma buffers, then you'll make the situation substantially worse (because now you're wasting tons of cma memory where you might not even need it). And without really solving the problem, since for some gpus that memory might be unusable (because you cannot scan that out on any discrete gpu, and sometimes not even on an integrated one). -Sima > Could be VPU, could be Zoom/Hangouts via pipewire, could for argument sake > be GPU or DSP. > > Also if we introduce a dependency on another device to allocate the output > buffers - say always taking the output buffer from the GPU, then we've added > another dependency which is more difficult to guarantee across different > arches. > > --- > bod -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 year, 9 months

2
1
0 0

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

by Dmitry Baryshkov

On Tue, May 07, 2024 at 04:34:24PM +0200, Hans de Goede wrote: > Hi Dmitry, > > On 5/7/24 3:32 PM, Dmitry Baryshkov wrote: > > On Mon, May 06, 2024 at 01:49:17PM +0200, Hans de Goede wrote: > >> Hi dma-buf maintainers, et.al., > >> > >> Various people have been working on making complex/MIPI cameras work OOTB > >> with mainline Linux kernels and an opensource userspace stack. > >> > >> The generic solution adds a software ISP (for Debayering and 3A) to > >> libcamera. Libcamera's API guarantees that buffers handed to applications > >> using it are dma-bufs so that these can be passed to e.g. a video encoder. > >> > >> In order to meet this API guarantee the libcamera software ISP allocates > >> dma-bufs from userspace through one of the /dev/dma_heap/* heaps. For > >> the Fedora COPR repo for the PoC of this: > >> https://hansdegoede.dreamwidth.org/28153.html > > > > Is there any reason for allocating DMA buffers for libcamera through > > /dev/dma_heap/ rather than allocating them via corresponding media > > device and then giving them away to DRM / VPU / etc? > > > > At least this should solve the permission usecase: if the app can open > > camera device, it can allocate a buffer. > > This is with a software ISP, the input buffers with raw bayer data > come from a v4l2 device, but the output buffers with the processed > data are purely userspace managed in this case. Ah, I see. Then why do you require the DMA-ble buffer at all? If you are providing data to VPU or DRM, then you should be able to get the buffer from the data-consuming device. If the data is further processed by a userspace app, then it should not require DMA memory at all. My main concern is that dma-heaps is both too generic and too limiting for the generic library implementation. -- With best wishes Dmitry

1 year, 9 months

1
0
0 0

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

by Dmitry Baryshkov

On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote: > Hi Sima, > > On 5/6/24 3:38 PM, Daniel Vetter wrote: > > On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote: > >> Hi, > >> > >> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote: > >>> Hi dma-buf maintainers, et.al., > >>> > >>> Various people have been working on making complex/MIPI cameras work OOTB > >>> with mainline Linux kernels and an opensource userspace stack. > >>> > >>> The generic solution adds a software ISP (for Debayering and 3A) to > >>> libcamera. Libcamera's API guarantees that buffers handed to applications > >>> using it are dma-bufs so that these can be passed to e.g. a video encoder. > >>> > >>> In order to meet this API guarantee the libcamera software ISP allocates > >>> dma-bufs from userspace through one of the /dev/dma_heap/* heaps. For > >>> the Fedora COPR repo for the PoC of this: > >>> https://hansdegoede.dreamwidth.org/28153.html > >> > >> For the record, we're also considering using them for ARM KMS devices, > >> so it would be better if the solution wasn't only considering v4l2 > >> devices. > >> > >>> I have added a simple udev rule to give physically present users access > >>> to the dma_heap-s: > >>> > >>> KERNEL=="system", SUBSYSTEM=="dma_heap", TAG+="uaccess" > >>> > >>> (and on Rasperry Pi devices any users in the video group get access) > >>> > >>> This was just a quick fix for the PoC. Now that we are ready to move out > >>> of the PoC phase and start actually integrating this into distributions > >>> the question becomes if this is an acceptable solution; or if we need some > >>> other way to deal with this ? > >>> > >>> Specifically the question is if this will have any negative security > >>> implications? I can certainly see this being used to do some sort of > >>> denial of service attack on the system (1). This is especially true for > >>> the cma heap which generally speaking is a limited resource. > >> > >> There's plenty of other ways to exhaust CMA, like allocating too much > >> KMS or v4l2 buffers. I'm not sure we should consider dma-heaps > >> differently than those if it's part of our threat model. > > > > So generally for an arm soc where your display needs cma, your render node > > doesn't. And user applications only have access to the later, while only > > the compositor gets a kms fd through logind. At least in drm aside from > > vc4 there's really no render driver that just gives you access to cma and > > allows you to exhaust that, you need to be a compositor with drm master > > access to the display. > > > > Which means we're mostly protected against bad applications, and that's > > not a threat the "user physically sits in front of the machine accounts > > for", and which giving cma access to everyone would open up. And with > > flathub/snaps/... this is very much an issue. > > I agree that bad applications are an issue, but not for the flathub / snaps > case. Flatpacks / snaps run sandboxed and don't have access to a full /dev > so those should not be able to open /dev/dma_heap/* independent of > the ACLs on /dev/dma_heap/*. The plan is for cameras using the > libcamera software ISP to always be accessed through pipewire and > the camera portal, so in this case pipewere is taking the place of > the compositor in your kms vs render node example. > > So this reduces the problem to bad apps packaged by regular distributions > and if any of those misbehave the distros should fix that. > > So I think that for the denial of service side allowing physical > present users (but not sandboxed apps running as those users) to > access /dev/dma_heap/* should be ok. What about an app built by the user? The machines can still be multi-seat or have multiple users. > My bigger worry is if dma_heap (u)dma-bufs can be abused in other > ways then causing a denial of service. > > I guess that the answer there is that causing other security issues > should not be possible ? > > Regards, > > Hans > -- With best wishes Dmitry

1 year, 9 months

1
0
0 0

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

by Dmitry Baryshkov

On Mon, May 06, 2024 at 01:49:17PM +0200, Hans de Goede wrote: > Hi dma-buf maintainers, et.al., > > Various people have been working on making complex/MIPI cameras work OOTB > with mainline Linux kernels and an opensource userspace stack. > > The generic solution adds a software ISP (for Debayering and 3A) to > libcamera. Libcamera's API guarantees that buffers handed to applications > using it are dma-bufs so that these can be passed to e.g. a video encoder. > > In order to meet this API guarantee the libcamera software ISP allocates > dma-bufs from userspace through one of the /dev/dma_heap/* heaps. For > the Fedora COPR repo for the PoC of this: > https://hansdegoede.dreamwidth.org/28153.html Is there any reason for allocating DMA buffers for libcamera through /dev/dma_heap/ rather than allocating them via corresponding media device and then giving them away to DRM / VPU / etc? At least this should solve the permission usecase: if the app can open camera device, it can allocate a buffer. > I have added a simple udev rule to give physically present users access > to the dma_heap-s: > > KERNEL=="system", SUBSYSTEM=="dma_heap", TAG+="uaccess" > > (and on Rasperry Pi devices any users in the video group get access) > > This was just a quick fix for the PoC. Now that we are ready to move out > of the PoC phase and start actually integrating this into distributions > the question becomes if this is an acceptable solution; or if we need some > other way to deal with this ? > > Specifically the question is if this will have any negative security > implications? I can certainly see this being used to do some sort of > denial of service attack on the system (1). This is especially true for > the cma heap which generally speaking is a limited resource. > > But devices tagged for uaccess are only opened up to users who are > physcially present behind the machine and those can just hit > the powerbutton, so I don't believe that any *on purpose* DOS is part of > the thread model. Any accidental DOS would be a userspace stack bug. > > Do you foresee any other negative security implications from allowing > physically present non root users to create (u)dma-bufs ? > > Regards, > > Hans > > > 1) There are some limits in drivers/dma-buf/udmabuf.c and distributions > could narrow these. > > -- With best wishes Dmitry

1 year, 9 months

1
0
0 0

Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

by Daniel Vetter

On Mon, May 06, 2024 at 04:46:54PM +0200, Christian Brauner wrote: > On Mon, May 06, 2024 at 02:47:23PM +0200, Daniel Vetter wrote: > > On Sun, May 05, 2024 at 01:53:48PM -0700, Linus Torvalds wrote: > > > On Sun, 5 May 2024 at 13:30, Al Viro <viro(a)zeniv.linux.org.uk> wrote: > > > > > > > > 0. special-cased ->f_count rule for ->poll() is a wart and it's > > > > better to get rid of it. > > > > > > > > 1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see > > > > git rm taken to it. Short of that, by all means, let's grab reference > > > > in there around the call of vfs_poll() (see (0)). > > > > > > Agreed on 0/1. > > > > > > > 2. having ->poll() instances grab extra references to file passed > > > > to them is not something that should be encouraged; there's a plenty > > > > of potential problems, and "caller has it pinned, so we are fine with > > > > grabbing extra refs" is nowhere near enough to eliminate those. > > > > > > So it's not clear why you hate it so much, since those extra > > > references are totally normal in all the other VFS paths. > > > > > > I mean, they are perhaps not the *common* case, but we have a lot of > > > random get_file() calls sprinkled around in various places when you > > > end up passing a file descriptor off to some asynchronous operation > > > thing. > > > > > > Yeah, I think most of them tend to be special operations (eg the tty > > > TIOCCONS ioctl to redirect the console), but it's not like vfs_ioctl() > > > is *that* different from vfs_poll. Different operation, not somehow > > > "one is more special than the other". > > > > > > cachefiles and backing-file does it for regular IO, and drop it at IO > > > completion - not that different from what dma-buf does. It's in > > > ->read_iter() rather than ->poll(), but again: different operations, > > > but not "one of them is somehow fundamentally different". > > > > > > > 3. dma-buf uses of get_file() are probably safe (epoll shite aside), > > > > but they do look fishy. That has nothing to do with epoll. > > > > > > Now, what dma-buf basically seems to do is to avoid ref-counting its > > > own fundamental data structure, and replaces that by refcounting the > > > 'struct file' that *points* to it instead. > > > > > > And it is a bit odd, but it actually makes some amount of sense, > > > because then what it passes around is that file pointer (and it allows > > > passing it around from user space *as* that file). > > > > > > And honestly, if you look at why it then needs to add its refcount to > > > it all, it actually makes sense. dma-bufs have this notion of > > > "fences" that are basically completion points for the asynchronous > > > DMA. Doing a "poll()" operation will add a note to the fence to get > > > that wakeup when it's done. > > > > > > And yes, logically it takes a ref to the "struct dma_buf", but because > > > of how the lifetime of the dma_buf is associated with the lifetime of > > > the 'struct file', that then turns into taking a ref on the file. > > > > > > Unusual? Yes. But not illogical. Not obviously broken. Tying the > > > lifetime of the dma_buf to the lifetime of a file that is passed along > > > makes _sense_ for that use. > > > > > > I'm sure dma-bufs could add another level of refcounting on the > > > 'struct dma_buf' itself, and not make it be 1:1 with the file, but > > > it's not clear to me what the advantage would really be, or why it > > > would be wrong to re-use a refcount that is already there. > > > > So there is generally another refcount, because dma_buf is just the > > cross-driver interface to some kind of real underlying buffer object from > > the various graphics related subsystems we have. > > > > And since it's a pure file based api thing that ceases to serve any > > function once the fd/file is gone we tied all the dma_buf refcounting to > > the refcount struct file already maintains. But the underlying buffer > > object can easily outlive the dma_buf, and over the lifetime of an > > underlying buffer object you might actually end up creating different > > dma_buf api wrappers for it (but at least in drm we guarantee there's at > > most one, hence why vmwgfx does the atomic_inc_unless_zero trick, which I > > don't particularly like and isn't really needed). > > > > But we could add another refcount, it just means we have 3 of those then > > when only really 2 are needed. > > Fwiw, the TTM thing described upthread and in the other thread really > tries hard to work around the dma_buf == file lifetime choice by hooking > into the dma-buf specific release function so it can access the dmabuf > and then the file. All that seems like a pretty error prone thing to me. > So a separate refcount for dma_buf wouldn't be the worst as that would > allow that TTM thing to benefit and remove that nasty hacking into your > generic dma_buf ops. But maybe I'm the only one who sees it that way and > I'm certainly not familiar enough with dma-buf. So the tricky part is the uniqueness requirement drm has for buffer objects (and hence dma_buf wrappers), which together with the refcounting makes dma_buf quite tricky: - dma_buf needs to hold some reference onto the underlying object, or it wont work - but you're not allowed to just create a new dma_buf every time someone exports an underlying object to a dma_buf, because that would break the uniqueness requirement. Which means the underlying object must also hold some kind of reference to its dma_buf, if it exists. So that on buffer export it can just increment the refcount for that and return it, instead of creating a new one. Which would be a reference loop that never gets freed, so you need one of two tricks: - Either a weak reference, i.e. just a pointer plus atomic_inc_unless_zero trickery like ttm does. Splitting that refcount into more refcounts doesn't fundamentally solve the problem, it just adds even more refcounts. - Or you do what all other drm drivers do in drm_prime.c do and careful clean up the dma_buf re-export cache when the userspace references (but not all kernel internal ones) disappear, to unbreak that reference loop. This needs to be done with extreme care and took a lot of screaming to get right, because if you have a race you might end up breaking the uniqueness requirement and have two dma_buf floating around. So neither of these solutions really are simple, but I agree with you that the atomic_inc_unless_zero trickery is less simple. It's definitely not cool that it's done by digging around in struct file internals. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 year, 9 months

1
0
0 0

get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove)

by Kees Cook

On Fri, May 03, 2024 at 06:54:22PM +0700, Bui Quang Minh wrote: > [...] > Root cause: > AFAIK, eventpoll (epoll) does not increase the registered file's reference. > To ensure the safety, when the registered file is deallocated in __fput, > eventpoll_release is called to unregister the file from epoll. When calling > poll on epoll, epoll will loop through registered files and call vfs_poll on > these files. In the file's poll, file is guaranteed to be alive, however, as > epoll does not increase the registered file's reference, the file may be > dying > and it's not safe the get the file for later use. And dma_buf_poll violates > this. In the dma_buf_poll, it tries to get_file to use in the callback. This > leads to a race where the dmabuf->file can be fput twice. > > Here is the race occurs in the above proof-of-concept > > close(dmabuf->file) > __fput_sync (f_count == 1, last ref) > f_count-- (f_count == 0 now) > __fput > epoll_wait > vfs_poll(dmabuf->file) > get_file(dmabuf->file)(f_count == 1) > eventpoll_release > dmabuf->file deallocation > fput(dmabuf->file) (f_count == 1) > f_count-- > dmabuf->file deallocation > > I am not familiar with the dma_buf so I don't know the proper fix for the > issue. About the rule that don't get the file for later use in poll callback > of > file, I wonder if it is there when only select/poll exist or just after > epoll > appears. > > I hope the analysis helps us to fix the issue. Thanks for doing this analysis! I suspect at least a start of a fix would be this: diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 8fe5aa67b167..15e8f74ee0f2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -267,9 +267,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) if (events & EPOLLOUT) { /* Paired with fput in dma_buf_poll_cb */ - get_file(dmabuf->file); - - if (!dma_buf_poll_add_cb(resv, true, dcb)) + if (!atomic_long_inc_not_zero(&dmabuf->file) && + !dma_buf_poll_add_cb(resv, true, dcb)) /* No callback queued, wake up any other waiters */ dma_buf_poll_cb(NULL, &dcb->cb); else @@ -290,9 +289,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) if (events & EPOLLIN) { /* Paired with fput in dma_buf_poll_cb */ - get_file(dmabuf->file); - - if (!dma_buf_poll_add_cb(resv, false, dcb)) + if (!atomic_long_inc_not_zero(&dmabuf->file) && + !dma_buf_poll_add_cb(resv, false, dcb)) /* No callback queued, wake up any other waiters */ dma_buf_poll_cb(NULL, &dcb->cb); else But this ends up leaving "active" non-zero, and at close time it runs into: BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); But the bottom line is that get_file() is unsafe to use in some places, one of which appears to be in the poll handler. There are maybe some other fragile places too, like in drivers/gpu/drm/vmwgfx/ttm_object.c: static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf) { return atomic_long_inc_not_zero(&dmabuf->file->f_count) != 0L; } Which I also note involves a dmabuf... Due to this issue I've proposed fixing get_file() to detect pathological states: https://lore.kernel.org/lkml/20240502222252.work.690-kees@kernel.org/ But that has run into some push-back. I'm hoping that seeing this epoll example will help illustrate what needs fixing a little better. I think the best current proposal is to just WARN sooner instead of a full refcount_t implementation: diff --git a/include/linux/fs.h b/include/linux/fs.h index 8dfd53b52744..e09107d0a3d6 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1040,7 +1040,8 @@ struct file_handle { static inline struct file *get_file(struct file *f) { - atomic_long_inc(&f->f_count); + long prior = atomic_long_fetch_inc_relaxed(&f->f_count); + WARN_ONCE(!prior, "struct file::f_count incremented from zero; use-after-free condition present!\n"); return f; } What's the right way to deal with the dmabuf situation? (And I suspect it applies to get_dma_buf_unless_doomed() as well...) -Kees -- Kees Cook

1 year, 9 months

4
15
0 0

Re: get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove)

by Kees Cook

On Fri, May 03, 2024 at 01:35:09PM -0600, Jens Axboe wrote: > On 5/3/24 1:22 PM, Kees Cook wrote: > > On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote: > >> On 5/3/24 12:26 PM, Kees Cook wrote: > >>> Thanks for doing this analysis! I suspect at least a start of a fix > >>> would be this: > >>> > >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > >>> index 8fe5aa67b167..15e8f74ee0f2 100644 > >>> --- a/drivers/dma-buf/dma-buf.c > >>> +++ b/drivers/dma-buf/dma-buf.c > >>> @@ -267,9 +267,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > >>> > >>> if (events & EPOLLOUT) { > >>> /* Paired with fput in dma_buf_poll_cb */ > >>> - get_file(dmabuf->file); > >>> - > >>> - if (!dma_buf_poll_add_cb(resv, true, dcb)) > >>> + if (!atomic_long_inc_not_zero(&dmabuf->file) && > >>> + !dma_buf_poll_add_cb(resv, true, dcb)) > >>> /* No callback queued, wake up any other waiters */ > >> > >> Don't think this is sane at all. I'm assuming you meant: > >> > >> atomic_long_inc_not_zero(&dmabuf->file->f_count); > > > > Oops, yes, sorry. I was typed from memory instead of copy/paste. > > Figured :-) > > >> but won't fly as you're not under RCU in the first place. And what > >> protects it from being long gone before you attempt this anyway? This is > >> sane way to attempt to fix it, it's completely opposite of what sane ref > >> handling should look like. > >> > >> Not sure what the best fix is here, seems like dma-buf should hold an > >> actual reference to the file upfront rather than just stash a pointer > >> and then later _hope_ that it can just grab a reference. That seems > >> pretty horrible, and the real source of the issue. > > > > AFAICT, epoll just doesn't hold any references at all. It depends, > > I think, on eventpoll_release() (really eventpoll_release_file()) > > synchronizing with epoll_wait() (but I don't see how this happens, and > > the race seems to be against ep_item_poll() ...?) > > > > I'm really confused about how eventpoll manages the lifetime of polled > > fds. > > epoll doesn't hold any references, and it's got some ugly callback to > deal with that. It's not ideal, nor pretty, but that's how it currently > works. See eventpoll_release() and how it's called. This means that > epoll itself is supposedly safe from the file going away, even though it > doesn't hold a reference to it. Right -- what remains unclear to me is how struct file lifetime is expected to work in the struct file_operations::poll callbacks. Because using get_file() there looks clearly unsafe... > Except that in this case, the file is already gone by the time > eventpoll_release() is called. Which presumably is some interaction with > the somewhat suspicious file reference management that dma-buf is doing. > But I didn't look into that much, outside of noting it looks a bit > suspect. Not yet, though. Here's (one) race state from the analysis. I added lines for the dma_fence_add_callback()/dma_buf_poll_cb() case, since that's the case that would escape any eventpoll_release/epoll_wait synchronization (if it exists?): close(dmabuf->file) __fput_sync (f_count == 1, last ref) f_count-- (f_count == 0 now) __fput epoll_wait vfs_poll(dmabuf->file) get_file(dmabuf->file)(f_count == 1) dma_fence_add_callback() eventpoll_release dmabuf->file deallocation dma_buf_poll_cb() fput(dmabuf->file) (f_count == 1) f_count-- dmabuf->file deallocation Without fences to create a background callback, we just do a double-free: close(dmabuf->file) __fput_sync (f_count == 1, last ref) f_count-- (f_count == 0 now) __fput epoll_wait vfs_poll(dmabuf->file) get_file(dmabuf->file)(f_count == 1) dma_buf_poll_cb() fput(dmabuf->file) (f_count == 1) f_count-- eventpoll_release dmabuf->file deallocation eventpoll_release dmabuf->file deallocation get_file(), via epoll_wait()->vfs_poll()->dma_buf_poll(), has raised f_count again. Then eventpoll_release() is doing things to remove dmabuf->file from the eventpoll lists, but I *think* this is synchronized so that an epoll_wait() will only call .poll handlers with a valid (though possibly f_count==0) file, but I can't figure out where that happens. (If it's not happening, we have a much bigger problem, but I imagine we'd see massive corruption all the time, which we don't.) So, yeah, I can't figure out how eventpoll_release() and epoll_wait() are expected to behave safely for .poll handlers. Regardless, for the simple case: it seems like it's just totally illegal to use get_file() in a poll handler. Is this known/expected? And if so, how can dmabuf possibly deal with that? -- Kees Cook

1 year, 9 months

4
8
0 0

Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

by Linus Torvalds

On Sun, 5 May 2024 at 03:50, Christian Brauner <brauner(a)kernel.org> wrote: > > And I agree with you that for some instances it's valid to take another > reference to a file from f_op->poll() but then they need to use > get_file_active() imho and simply handle the case where f_count is zero. I think this is (a) practically impossible to find (since most f_count updates are in various random helpers) (b) not tenable in the first place, since *EVERYBODY* does a f_count update as part of the bog-standard pollwait So (b) means that the notion of "warn if somebody increments f_count from zero" is broken to begin with - but it's doubly broken because it wouldn't find anything *anyway*, since this never happens in any normal situation. And (a) means that any non-automatic finding of this is practically impossible. > And we need to document that in Documentation/filesystems/file.rst or > locking.rst. WHY? Why cannot you and Al just admit that the problem is in epoll. Always has been, always will be. The fact is, it's not dma-buf that is violating any rules. It's epoll. It's calling out to random driver functions with a file pointer that is no longer valid. It really is that simple. I don't see why you are arguing for "unknown number of drivers - we know at least *one* - have to be fixed for a bug that is in epoll". If it was *easy* to fix, and if it was *easy* to validate, then sure. But that just isn't the case. In contrast, in epoll it's *trivial* to fix the one case where it does a VFS call-out, and just say "you have to follow the rules". So explain to me again why you want to mess up the driver interface and everybody who has a '.poll()' function, and not just fix the ONE clearly buggy piece of code. Because dammit,. epoll is clearly buggy. It's not enough to say "the file allocation isn't going away", and claim that that means that it's not buggy - when the file IS NO LONGER VALID! Linus

1 year, 9 months

3
4
0 0

Re: get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove)

by Kees Cook

On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote: > On 5/3/24 12:26 PM, Kees Cook wrote: > > Thanks for doing this analysis! I suspect at least a start of a fix > > would be this: > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index 8fe5aa67b167..15e8f74ee0f2 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -267,9 +267,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > > > > if (events & EPOLLOUT) { > > /* Paired with fput in dma_buf_poll_cb */ > > - get_file(dmabuf->file); > > - > > - if (!dma_buf_poll_add_cb(resv, true, dcb)) > > + if (!atomic_long_inc_not_zero(&dmabuf->file) && > > + !dma_buf_poll_add_cb(resv, true, dcb)) > > /* No callback queued, wake up any other waiters */ > > Don't think this is sane at all. I'm assuming you meant: > > atomic_long_inc_not_zero(&dmabuf->file->f_count); Oops, yes, sorry. I was typed from memory instead of copy/paste. > but won't fly as you're not under RCU in the first place. And what > protects it from being long gone before you attempt this anyway? This is > sane way to attempt to fix it, it's completely opposite of what sane ref > handling should look like. > > Not sure what the best fix is here, seems like dma-buf should hold an > actual reference to the file upfront rather than just stash a pointer > and then later _hope_ that it can just grab a reference. That seems > pretty horrible, and the real source of the issue. AFAICT, epoll just doesn't hold any references at all. It depends, I think, on eventpoll_release() (really eventpoll_release_file()) synchronizing with epoll_wait() (but I don't see how this happens, and the race seems to be against ep_item_poll() ...?) I'm really confused about how eventpoll manages the lifetime of polled fds. > > Due to this issue I've proposed fixing get_file() to detect pathological states: > > https://lore.kernel.org/lkml/20240502222252.work.690-kees@kernel.org/ > > I don't think this would catch this case, as the memory could just be > garbage at this point. It catches it just fine! :) I tested it against the published PoC. And for cases where further allocations have progressed far enough to corrupt the freed struct file and render the check pointless, nothing different has happened than what happens today. At least now we have a window to catch the situation across the time frame before it is both reallocated _and_ the contents at the f_count offset gets changed to non-zero. -- Kees Cook

1 year, 9 months

1
0
0 0

Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin time

by Thomas Zimmermann

Hi Am 02.05.24 um 14:00 schrieb Boris Brezillon: > On Thu, 2 May 2024 13:59:41 +0200 > Boris Brezillon <boris.brezillon(a)collabora.com> wrote: > >> Hi Thomas, >> >> On Thu, 2 May 2024 13:51:16 +0200 >> Thomas Zimmermann <tzimmermann(a)suse.de> wrote: >> >>> Hi, >>> >>> ignoring my r-b on patch 1, I'd like to rethink the current patches in >>> general. >>> >>> I think drm_gem_shmem_pin() should become the locked version of _pin(), >>> so that drm_gem_shmem_object_pin() can call it directly. The existing >>> _pin_unlocked() would not be needed any longer. Same for the _unpin() >>> functions. This change would also fix the consistency with the semantics >>> of the shmem _vmap() functions, which never take reservation locks. >>> >>> There are only two external callers of drm_gem_shmem_pin(): the test >>> case and panthor. These assume that drm_gem_shmem_pin() acquires the >>> reservation lock. The test case should likely call drm_gem_pin() >>> instead. That would acquire the reservation lock and the test would >>> validate that shmem's pin helper integrates well into the overall GEM >>> framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me. >>> For now, it could receive a wrapper that takes the lock and that's it. >> I do agree that the current inconsistencies in the naming is >> troublesome (sometimes _unlocked, sometimes _locked, with the version >> without any suffix meaning either _locked or _unlocked depending on >> what the suffixed version does), and that's the very reason I asked >> Dmitry to address that in his shrinker series [1]. So, ideally I'd >> prefer if patches from Dmitry's series were applied instead of >> trying to fix that here (IIRC, we had an ack from Maxime). > With the link this time :-). > > [1]https://lore.kernel.org/lkml/20240105184624.508603-1-dmitry.osipenko@coll… Thanks. I remember these patches. Somehow I thought they would have been merged already. I wasn't super happy about the naming changes in patch 5, because the names of the GEM object callbacks do no longer correspond with their implementations. But anyway. If we go that direction, we should here simply push drm_gem_shmem_pin() and drm_gem_shmem_unpin() into panthor and update the shmem tests with drm_gem_pin(). Panfrost and lima would call drm_gem_shmem_pin_locked(). IMHO we should not promote the use of drm_gem_shmem_object_*() functions, as they are meant to be callbacks for struct drm_gem_object_funcs. (Auto-generating them would be nice.) Best regards Thomas > >> Regards, >> >> Boris -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

1 year, 9 months

1
0
0 0

Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin time

by Thomas Zimmermann

Hi, ignoring my r-b on patch 1, I'd like to rethink the current patches in general. I think drm_gem_shmem_pin() should become the locked version of _pin(), so that drm_gem_shmem_object_pin() can call it directly. The existing _pin_unlocked() would not be needed any longer. Same for the _unpin() functions. This change would also fix the consistency with the semantics of the shmem _vmap() functions, which never take reservation locks. There are only two external callers of drm_gem_shmem_pin(): the test case and panthor. These assume that drm_gem_shmem_pin() acquires the reservation lock. The test case should likely call drm_gem_pin() instead. That would acquire the reservation lock and the test would validate that shmem's pin helper integrates well into the overall GEM framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me. For now, it could receive a wrapper that takes the lock and that's it. Best regards Thomas Am 01.05.24 um 08:55 schrieb Adrián Larumbe: > This is v3 of https://lore.kernel.org/dri-devel/20240424090429.57de7d1c@collabora.com/ > > The goal of this patch series is fixing a deadlock upon locking the dma reservation > of a DRM gem object when pinning it, at a prime import operation. > > Changes from v2: > - Removed comment explaining reason why an already-locked > pin function replaced the locked variant inside Panfrost's > object pin callback. > - Moved already-assigned attachment warning into generic > already-locked gem object pin function > > Adrián Larumbe (2): > drm/panfrost: Fix dma_resv deadlock at drm object pin time > drm/gem-shmem: Add import attachment warning to locked pin function > > drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++ > drivers/gpu/drm/lima/lima_gem.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- > 3 files changed, 4 insertions(+), 2 deletions(-) > > > base-commit: 75b68f22e39aafb22f3d8e3071e1aba73560788c -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

1 year, 9 months

1
0
0 0

Re: [PATCH v3 1/2] drm/panfrost: Fix dma_resv deadlock at drm object pin time

by Thomas Zimmermann

Hi Am 01.05.24 um 08:55 schrieb Adrián Larumbe: > When Panfrost must pin an object that is being prepared a dma-buf > attachment for on behalf of another driver, the core drm gem object pinning > code already takes a lock on the object's dma reservation. > > However, Panfrost GEM object's pinning callback would eventually try taking > the lock on the same dma reservation when delegating pinning of the object > onto the shmem subsystem, which led to a deadlock. > > This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws > the following recursive locking situation: > > weston/3440 is trying to acquire lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper] > but task is already holding lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_pin+0x2c/0x80 [drm] > > Fix it by assuming the object's reservation had already been locked by the > time we reach panfrost_gem_pin. Maybe say that the reservation lock has been taken in drm_gem_pin() > > Do the same thing for the Lima driver, as it most likely suffers from the > same issue. Please split this patch into one for panfrost and one for lima. To each patch, you can add Reviewed-by: Thomas Zimmermann <tzimmermann(a)suse.de> Best regards Thomas > > Cc: Thomas Zimmermann <tzimmermann(a)suse.de> > Cc: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: Steven Price <steven.price(a)arm.com> > Fixes: a78027847226 ("drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()") > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drivers/gpu/drm/lima/lima_gem.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c > index 7ea244d876ca..c4e0f9faaa47 100644 > --- a/drivers/gpu/drm/lima/lima_gem.c > +++ b/drivers/gpu/drm/lima/lima_gem.c > @@ -185,7 +185,7 @@ static int lima_gem_pin(struct drm_gem_object *obj) > if (bo->heap_size) > return -EINVAL; > > - return drm_gem_shmem_pin(&bo->base); > + return drm_gem_shmem_object_pin(obj); > } > > static int lima_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map) > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c > index d47b40b82b0b..f268bd5c2884 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c > @@ -192,7 +192,7 @@ static int panfrost_gem_pin(struct drm_gem_object *obj) > if (bo->is_heap) > return -EINVAL; > > - return drm_gem_shmem_pin(&bo->base); > + return drm_gem_shmem_object_pin(obj); > } > > static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object *obj) -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

1 year, 9 months

1
0
0 0

Re: [PATCH v4 05/16] SoC: mediatek: mt8365: support audio clock control

by Mark Brown

On Fri, Apr 26, 2024 at 07:22:34PM +0200, Alexandre Mergnat wrote: > Add audio clock wrapper and audio tuner control. Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone.

1 year, 9 months

1
0
0 0

Re: [PATCH v4 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC

by Krzysztof Kozlowski

On 26/04/2024 19:22, Alexandre Mergnat wrote: > regulators: > type: object > $ref: /schemas/regulator/mediatek,mt6357-regulator.yaml > @@ -83,6 +111,12 @@ examples: > interrupt-controller; > #interrupt-cells = <2>; > > + audio-codec { > + mediatek,micbias0-microvolt = <1700000>; > + mediatek,micbias1-microvolt = <1700000>; > + vaud28-supply = <&mt6357_vaud28_reg>; And now you should see how odd it looks. Supplies are part of entire chip, not subblock, even if they supply dedicated domain within that chip. That's why I asked to put it in the parent node. Best regards, Krzysztof

1 year, 9 months

1
0
0 0

Re: [PATCH v4 02/16] ASoC: dt-bindings: mediatek,mt8365-mt6357: Add audio sound card document

by Krzysztof Kozlowski

On 26/04/2024 19:22, Alexandre Mergnat wrote: > + link-name: > + description: Indicates dai-link name and PCM stream name > + enum: > + - I2S_IN_BE > + - I2S_OUT_BE > + - PCM1_BE > + - PDM1_BE > + - PDM2_BE > + - PDM3_BE > + - PDM4_BE > + - SPDIF_IN_BE > + - SPDIF_OUT_BE > + - TDM_IN_BE > + - TDM_OUT_BE Feels like BE is redundant. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Best regards, Krzysztof

1 year, 9 months

1
0
0 0

Re: [PATCH v4 01/16] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document

by Krzysztof Kozlowski

On 26/04/2024 19:22, Alexandre Mergnat wrote: > Add MT8365 audio front-end bindings > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> > --- Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Best regards, Krzysztof

1 year, 9 months

1
0
0 0

Re: [PATCH v3 03/18] ASoC: dt-bindings: mt6357: Add audio codec document

by Krzysztof Kozlowski

On 23/04/2024 19:07, Alexandre Mergnat wrote: > > > On 09/04/2024 17:55, Krzysztof Kozlowski wrote: >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + codec { >>> + mediatek,micbias0-microvolt = <1900000>; >>> + mediatek,micbias1-microvolt = <1700000>; >>> + mediatek,vaud28-supply = <&mt6357_vaud28_reg>; >> Sorry, this does not work. Change voltage to 1111111 and check the results. > > Actually it's worst ! I've removed the required property (vaud28-supply) but the dt check pass. > Same behavior for some other docs like mt6359.yaml Yeah, the schema is not applied. There is nothing selecting it, so this is no-op schema. I don't know what exactly you want to describe, but usually either you miss compatible or this should be just part of parent node. > > The at24.yaml doc works as expected, then I tried compare an find the issue, without success... > > I've replaced "codec" by "audio-codec", according to [1]. > I've tried multiple manner to implement the example code, without success. I'm wondering if what I > try to do is the correct way or parse-able by the dt_check. > > If I drop this file and implement all these new properties into the MFD PMIC documentation directly, > I've the expected dt_check result (function to good or wrong parameters) Yes. Best regards, Krzysztof

1 year, 9 months

1
0
0 0

Re: [PATCH] drm/panfrost: Fix dma_resv deadlock at drm object pin time

by Dmitry Osipenko

On 4/21/24 19:39, Adrián Larumbe wrote: > When Panfrost must pin an object that is being prepared a dma-buf > attachment for on behalf of another driver, the core drm gem object pinning > code already takes a lock on the object's dma reservation. > > However, Panfrost GEM object's pinning callback would eventually try taking > the lock on the same dma reservation when delegating pinning of the object > onto the shmem subsystem, which led to a deadlock. > > This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws > the following recursive locking situation: > > weston/3440 is trying to acquire lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper] > but task is already holding lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_pin+0x2c/0x80 [drm] > > Fix it by assuming the object's reservation had already been locked by the > time we reach panfrost_gem_pin. > > Cc: Thomas Zimmermann <tzimmermann(a)suse.de> > Cc: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: Steven Price <steven.price(a)arm.com> > Fixes: a78027847226 ("drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()") > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drivers/gpu/drm/panfrost/panfrost_gem.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c > index d47b40b82b0b..6c26652d425d 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c > @@ -192,7 +192,12 @@ static int panfrost_gem_pin(struct drm_gem_object *obj) > if (bo->is_heap) > return -EINVAL; > > - return drm_gem_shmem_pin(&bo->base); > + /* > + * Pinning can only happen in response to a prime attachment request from > + * another driver, but that's already being handled by drm_gem_pin > + */ > + drm_WARN_ON(obj->dev, obj->import_attach); > + return drm_gem_shmem_pin_locked(&bo->base); > } Will be better to use drm_gem_shmem_object_pin() to avoid such problem in future Please also fix the Lima driver -- Best regards, Dmitry

1 year, 9 months

1
0
0 0

Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas

by Greg Kroah-Hartman

On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote: > From: Andrew Davis <afd(a)ti.com> > > This new export type exposes to userspace the SRAM area as a DMA-BUF > Heap, > this allows for allocations of DMA-BUFs that can be consumed by various > DMA-BUF supporting devices. > > Signed-off-by: Andrew Davis <afd(a)ti.com> > Tested-by: Pascal Fontain <pascal.fontain(a)bachmann.info> When sending on a patch from someone else, you too must sign off on it as per our documenation. Please read it and understand what you are agreeing to when you do that for a new version please. > --- > drivers/misc/Kconfig | 7 + > drivers/misc/Makefile | 1 + > drivers/misc/sram-dma-heap.c | 246 +++++++++++++++++++++++++++++++++++ > drivers/misc/sram.c | 6 + > drivers/misc/sram.h | 16 +++ > 5 files changed, 276 insertions(+) > create mode 100644 drivers/misc/sram-dma-heap.c > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 9e4ad4d61f06..e6674e913168 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -448,6 +448,13 @@ config SRAM > config SRAM_EXEC > bool > > +config SRAM_DMA_HEAP > + bool "Export on-chip SRAM pools using DMA-Heaps" > + depends on DMABUF_HEAPS && SRAM > + help > + This driver allows the export of on-chip SRAM marked as both pool > + and exportable to userspace using the DMA-Heaps interface. What will use this in userspace? thanks, greg k-h

1 year, 10 months

2
2
0 0

Re: [PATCH v2] doc: dma-buf: fix grammar typo

by Christian König

Well checkpatch.pl still complained: ERROR: trailing whitespace #157: FILE: Documentation/driver-api/dma-buf.rst:80: + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all^M$ That actually looks like you used a Windows line ending. I fixed it up and pushed the patch, but please take a bit more care next time. Thanks, Christian. Am 17.04.24 um 06:59 schrieb Baruch Siach: > Use 'supported' instead of 'support'. 'support' makes no sense in this > context. > > Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> > --- > v2: Add commit log message (Christian König) > --- > Documentation/driver-api/dma-buf.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst > index 0c153d79ccc4..29abf1eebf9f 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -77,7 +77,7 @@ consider though: > the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other > llseek operation will report -EINVAL. > > - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all > + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all > cases. Userspace can use this to detect support for discovering the dma-buf > size using llseek. >

1 year, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig