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

Re: [Linaro-mm-sig] [PATCH] udmabuf: put dmabuf in case of get fd failed

by kernel test robot

Hi Xianting, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.16-rc6 next-20211217] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-i… base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a7904a538933c525096ca2ccde1e60d0ee62c08e config: x86_64-randconfig-r032-20211220 (https://download.01.org/0day-ci/archive/20211220/202112202144.R9IV6eP2-lkp@…) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/322781a4da9de4a3057afd933108d23ca7f… git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433 git checkout 322781a4da9de4a3057afd933108d23ca7f5282e # save the config file to linux build tree mkdir build_dir make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/dma-buf/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All warnings (new ones prefixed by >>): drivers/dma-buf/udmabuf.c: In function 'udmabuf_create': drivers/dma-buf/udmabuf.c:292:13: error: invalid storage class for function 'udmabuf_ioctl_create' 292 | static long udmabuf_ioctl_create(struct file *filp, unsigned long arg) | ^~~~~~~~~~~~~~~~~~~~ >> drivers/dma-buf/udmabuf.c:292:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 292 | static long udmabuf_ioctl_create(struct file *filp, unsigned long arg) | ^~~~~~ drivers/dma-buf/udmabuf.c:311:13: error: invalid storage class for function 'udmabuf_ioctl_create_list' 311 | static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) | ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/dma-buf/udmabuf.c:332:13: error: invalid storage class for function 'udmabuf_ioctl' 332 | static long udmabuf_ioctl(struct file *filp, unsigned int ioctl, | ^~~~~~~~~~~~~ drivers/dma-buf/udmabuf.c:353:20: error: initializer element is not constant 353 | .unlocked_ioctl = udmabuf_ioctl, | ^~~~~~~~~~~~~ drivers/dma-buf/udmabuf.c:353:20: note: (near initialization for 'udmabuf_fops.unlocked_ioctl') drivers/dma-buf/udmabuf.c:355:20: error: initializer element is not constant 355 | .compat_ioctl = udmabuf_ioctl, | ^~~~~~~~~~~~~ drivers/dma-buf/udmabuf.c:355:20: note: (near initialization for 'udmabuf_fops.compat_ioctl') drivers/dma-buf/udmabuf.c:365:19: error: invalid storage class for function 'udmabuf_dev_init' 365 | static int __init udmabuf_dev_init(void) | ^~~~~~~~~~~~~~~~ drivers/dma-buf/udmabuf.c:370:20: error: invalid storage class for function 'udmabuf_dev_exit' 370 | static void __exit udmabuf_dev_exit(void) | ^~~~~~~~~~~~~~~~ In file included from include/linux/init.h:5, from include/linux/cred.h:12, from drivers/dma-buf/udmabuf.c:2: include/linux/compiler.h:244:46: error: initializer element is not constant 244 | __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym; | ^ include/linux/init.h:236:2: note: in expansion of macro '__ADDRESSABLE' 236 | __ADDRESSABLE(fn) | ^~~~~~~~~~~~~ include/linux/init.h:241:2: note: in expansion of macro '__define_initcall_stub' 241 | __define_initcall_stub(__stub, fn) \ | ^~~~~~~~~~~~~~~~~~~~~~ include/linux/init.h:254:2: note: in expansion of macro '____define_initcall' 254 | ____define_initcall(fn, \ | ^~~~~~~~~~~~~~~~~~~ include/linux/init.h:260:2: note: in expansion of macro '__unique_initcall' 260 | __unique_initcall(fn, id, __sec, __initcall_id(fn)) | ^~~~~~~~~~~~~~~~~ include/linux/init.h:262:35: note: in expansion of macro '___define_initcall' 262 | #define __define_initcall(fn, id) ___define_initcall(fn, id, .initcall##id) | ^~~~~~~~~~~~~~~~~~ include/linux/init.h:291:30: note: in expansion of macro '__define_initcall' 291 | #define device_initcall(fn) __define_initcall(fn, 6) | ^~~~~~~~~~~~~~~~~ include/linux/init.h:296:24: note: in expansion of macro 'device_initcall' 296 | #define __initcall(fn) device_initcall(fn) | ^~~~~~~~~~~~~~~ include/linux/module.h:88:24: note: in expansion of macro '__initcall' 88 | #define module_init(x) __initcall(x); | ^~~~~~~~~~ drivers/dma-buf/udmabuf.c:375:1: note: in expansion of macro 'module_init' 375 | module_init(udmabuf_dev_init) | ^~~~~~~~~~~ In file included from include/linux/container_of.h:5, from include/linux/list.h:5, from include/linux/key.h:14, from include/linux/cred.h:13, from drivers/dma-buf/udmabuf.c:2: >> include/linux/build_bug.h:78:41: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) | ^~~~~~~~~~~~~~ include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert' 77 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr) | ^~~~~~~~~~~~~~~ include/linux/init.h:246:2: note: in expansion of macro 'static_assert' 246 | static_assert(__same_type(initcall_t, &fn)); | ^~~~~~~~~~~~~ include/linux/init.h:254:2: note: in expansion of macro '____define_initcall' 254 | ____define_initcall(fn, \ | ^~~~~~~~~~~~~~~~~~~ include/linux/init.h:260:2: note: in expansion of macro '__unique_initcall' 260 | __unique_initcall(fn, id, __sec, __initcall_id(fn)) | ^~~~~~~~~~~~~~~~~ include/linux/init.h:262:35: note: in expansion of macro '___define_initcall' 262 | #define __define_initcall(fn, id) ___define_initcall(fn, id, .initcall##id) | ^~~~~~~~~~~~~~~~~~ include/linux/init.h:291:30: note: in expansion of macro '__define_initcall' 291 | #define device_initcall(fn) __define_initcall(fn, 6) | ^~~~~~~~~~~~~~~~~ include/linux/init.h:296:24: note: in expansion of macro 'device_initcall' 296 | #define __initcall(fn) device_initcall(fn) | ^~~~~~~~~~~~~~~ include/linux/module.h:88:24: note: in expansion of macro '__initcall' 88 | #define module_init(x) __initcall(x); | ^~~~~~~~~~ drivers/dma-buf/udmabuf.c:375:1: note: in expansion of macro 'module_init' 375 | module_init(udmabuf_dev_init) | ^~~~~~~~~~~ In file included from include/linux/cred.h:12, from drivers/dma-buf/udmabuf.c:2: drivers/dma-buf/udmabuf.c:376:13: error: initializer element is not constant 376 | module_exit(udmabuf_dev_exit) | ^~~~~~~~~~~~~~~~ include/linux/init.h:299:50: note: in definition of macro '__exitcall' 299 | static exitcall_t __exitcall_##fn __exit_call = fn | ^~ drivers/dma-buf/udmabuf.c:376:1: note: in expansion of macro 'module_exit' 376 | module_exit(udmabuf_dev_exit) | ^~~~~~~~~~~ include/linux/init.h:299:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 299 | static exitcall_t __exitcall_##fn __exit_call = fn | ^~~~~~ include/linux/module.h:100:24: note: in expansion of macro '__exitcall' 100 | #define module_exit(x) __exitcall(x); | ^~~~~~~~~~ drivers/dma-buf/udmabuf.c:376:1: note: in expansion of macro 'module_exit' 376 | module_exit(udmabuf_dev_exit) | ^~~~~~~~~~~ drivers/dma-buf/udmabuf.c:379:1: error: expected declaration or statement at end of input 379 | MODULE_LICENSE("GPL v2"); | ^~~~~~~~~~~~~~ vim +292 drivers/dma-buf/udmabuf.c fbb0de79507819 Gerd Hoffmann 2018-08-27 291 fbb0de79507819 Gerd Hoffmann 2018-08-27 @292 static long udmabuf_ioctl_create(struct file *filp, unsigned long arg) fbb0de79507819 Gerd Hoffmann 2018-08-27 293 { fbb0de79507819 Gerd Hoffmann 2018-08-27 294 struct udmabuf_create create; fbb0de79507819 Gerd Hoffmann 2018-08-27 295 struct udmabuf_create_list head; fbb0de79507819 Gerd Hoffmann 2018-08-27 296 struct udmabuf_create_item list; fbb0de79507819 Gerd Hoffmann 2018-08-27 297 fbb0de79507819 Gerd Hoffmann 2018-08-27 298 if (copy_from_user(&create, (void __user *)arg, 33f35429fc49c0 Gerd Hoffmann 2018-09-11 299 sizeof(create))) fbb0de79507819 Gerd Hoffmann 2018-08-27 300 return -EFAULT; fbb0de79507819 Gerd Hoffmann 2018-08-27 301 fbb0de79507819 Gerd Hoffmann 2018-08-27 302 head.flags = create.flags; fbb0de79507819 Gerd Hoffmann 2018-08-27 303 head.count = 1; fbb0de79507819 Gerd Hoffmann 2018-08-27 304 list.memfd = create.memfd; fbb0de79507819 Gerd Hoffmann 2018-08-27 305 list.offset = create.offset; fbb0de79507819 Gerd Hoffmann 2018-08-27 306 list.size = create.size; fbb0de79507819 Gerd Hoffmann 2018-08-27 307 c1bbed66899726 Gurchetan Singh 2019-12-02 308 return udmabuf_create(filp->private_data, &head, &list); fbb0de79507819 Gerd Hoffmann 2018-08-27 309 } fbb0de79507819 Gerd Hoffmann 2018-08-27 310 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Daniel Vetter

On Tue, Dec 07, 2021 at 09:46:47PM +0100, Thomas Hellström wrote: > > On 12/7/21 19:08, Daniel Vetter wrote: > > Once more an entire week behind on mails, but this looked interesting > > enough. > > > > On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote: > > > On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote: > > > > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel): > > > > > On 12/1/21 12:25, Christian König wrote: > > > > > > And why do you use dma_fence_chain to generate a timeline for > > > > > > TTM? > > > > > > That should come naturally because all the moves must be ordered. > > > > > Oh, in this case because we're looking at adding stuff at the end > > > > > of > > > > > migration (like coalescing object shared fences and / or async > > > > > unbind > > > > > fences), which may not complete in order. > > > > Well that's ok as well. My question is why does this single dma_fence > > > > then shows up in the dma_fence_chain representing the whole > > > > migration? > > > What we'd like to happen during eviction is that we > > > > > > 1) await any exclusive- or moving fences, then schedule the migration > > > blit. The blit manages its own GPU ptes. Results in a single fence. > > > 2) Schedule unbind of any gpu vmas, resulting possibly in multiple > > > fences. > > This sounds like over-optimizing for nothing. We only really care about > > pipeling moves on dgpu, and on dgpu we only care about modern userspace > > (because even gl moves in that direction). > Hmm. It's not totally clear what you mean with over-optimizing for nothing, > is it the fact that we want to start the blit before all shared fences have > signaled or the fact that we're doing async unbinding to avoid a > synchronization point that stops us from fully pipelining evictions? Yup. Least because that breaks vulkan, so you really can't do this optimizations :-) In general I meant that unless you really, really understand everything all the time (which frankly no one does), then trying to be clever just isn't worth it. We have access pending in the dma_resv, we wait for it is dumb, simple, no surprises. > > And modern means that usually even write access is only setting a read > > fence, because in vk/compute we only set write fences for object which > > need implicit sync, and _only_ when actually needed. > > > > So ignoring read fences for movings "because it's only reads" is actually > > busted. > > I'm fine with awaiting also shared fences before we start the blit, as > mentioned also later in the thread, but that is just a matter of when we > coalesce the shared fences. So since difference in complexity is minimal, > what's viewed as optimizing for nothing can also be conversely be viewed as > unneccesarily waiting for nothing, blocking the migration context timeline > from progressing with unrelated blits. (Unless there are correctness issues > of course, see below). > > But not setting a write fence after write seems to conflict with dma-buf > rules as also discussed later in the thread. Perhaps some clarity is needed > here. How would a writer or reader that implicitly *wants* to wait for > previous writers go about doing that? > > Note that what we're doing is not "moving" in the sense that we're giving up > or modifying the old storage but rather start a blit assuming that the > contents of the old storage is stable, or the writer doesn't care. Yeah that's not how dma-buf works, and which is what Christian is trying to rectify with his huge refactoring/doc series to give a bit clearer meaning to what a fence in a dma_resv means. > > I think for buffer moves we should document and enforce (in review) the > > rule that you have to wait for all fences, otherwise boom. Same really > > like before freeing backing storage. Otherwise there's just too many gaps > > and surprises. > > > > And yes with Christian's rework of dma_resv this will change, and we'll > > allow multiple write fences (because that's what amdgpu encoded into their > > uapi). Still means that you cannot move a buffer without waiting for read > > fences (or kernel fences or anything really). > > Sounds like some agreement is needed here what rules we actually should > obey. As mentioned above I'm fine with either. I think it would be good to comment on the doc patch in Christian's series for that. But essentially read/write don't mean actual read/write to memory, but only read/write access in terms of implicit sync. Buffers which do not partake in implicit sync (driver internal stuff) or access which is not implicitly synced (anything vk does) do _not_ need to set a write fence. They will (except amdgpu, until they fix their CS uapi) _only_ set a read fence. Christian and me had a multi-month discussion on this, so it's a bit tricky. > > The other thing is this entire spinlock recursion topic for dma_fence, and > > I'm deeply unhappy about the truckload of tricks i915 plays and hence in > > favour of avoiding recursion in this area as much as possible. > > TBH I think the i915 corresponding container manages to avoid both the deep > recursive calls and lock nesting simply by early enable_signaling() and not > storing the fence pointers of the array fences, which to me appears to be a > simple and clean approach. No tricks there. > > > > > If we really can't avoid it then irq_work to get a new clean context gets > > the job done. Making this messy and work is imo a feature, lock nesting of > > same level locks is just not a good&robust engineering idea. > > For the dma-fence-chain and dma-fence-array there are four possibilities > moving forward: > > 1) Keeping the current same-level locking nesting order of container-first > containee later. This is fully annotated, but fragile and blows up if users > attempt to nest containers in different orders. > > 2) Establishing a reverse-signaling locking order. Not annotatable. blows up > on signal-on-any. > > 3) Early enable-signaling, no lock nesting, low latency but possibly > unnecessary enable_signaling calls. > > 4) irq_work in enable_signaling(). High latency. > > The tread finally agreed the solution would be to keep 1), add early > warnings for the pitfalls and if possible provide helpers to flatten to > avoid container recursion. Hm ok seems ok. It's definitely an area where we don't have great solutions :-/ -Daniel > > /Thomas > > > > > > /me back to being completely burried > > > > I do hope I can find some more time to review a few more of Christian's > > patches this week though :-/ > > > > Cheers, Daniel > > > > > 3) Most but not all of the remaining resv shared fences will have been > > > finished in 2) We can't easily tell which so we have a couple of shared > > > fences left. > > > 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type > > > dma-fence-chain. > > > 5) hand the resulting dma-fence-chain representing the end of migration > > > over to ttm's resource manager. > > > > > > Now this means we have a dma-fence-chain disguised as a dma-fence out > > > in the wild, and it could in theory reappear as a 3) fence for another > > > migration unless a very careful audit is done, or as an input to the > > > dma-fence-array used for that single dependency. > > > > > > > That somehow doesn't seem to make sense because each individual step > > > > of > > > > the migration needs to wait for those dependencies as well even when > > > > it > > > > runs in parallel. > > > > > > > > > But that's not really the point, the point was that an (at least to > > > > > me) seemingly harmless usage pattern, be it real or fictious, ends > > > > > up > > > > > giving you severe internal- or cross-driver headaches. > > > > Yeah, we probably should document that better. But in general I don't > > > > see much reason to allow mixing containers. The dma_fence_array and > > > > dma_fence_chain objects have some distinct use cases and and using > > > > them > > > > to build up larger dependency structures sounds really questionable. > > > Yes, I tend to agree to some extent here. Perhaps add warnings when > > > adding a chain or array as an input to array and when accidently > > > joining chains, and provide helpers for flattening if needed. > > > > > > /Thomas > > > > > > > > > > Christian. > > > > > > > > > /Thomas > > > > > > > > > > > > > > > > Regards, > > > > > > Christian. > > > > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Jason Gunthorpe

On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: > Hi Jason, > Thank you for replying. > > 2021年12月8日(水) 2:14 Jason Gunthorpe <jgg(a)ziepe.ca>: > > > > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > > > Hi maintainers, > > > > > > Could you please review this patch series? > > > > Why is it RFC? > > > > I'm confused why this is useful? > > > > This can't do copy from MMIO memory, so it shouldn't be compatible > > with things like Gaudi - does something prevent this? > I think if an export of the dma-buf supports vmap, CPU is able to access the > mmio memory. > > Is it wrong? If this is wrong, there is no advantages this changes.. I don't know what the dmabuf folks did, but yes, it is wrong. IOMEM must be touched using only special accessors, some platforms crash if you don't do this. Even x86 will crash if you touch it with something like an XMM optimized memcpy. Christian? If the vmap succeeds what rules must the caller use to access the memory? Jason

3 years, 5 months

3
4
0 0

Re: [Linaro-mm-sig] [PATCH 0/2] Add SMBus features to Tegra I2C

by Dmitry Osipenko

09.12.2021 18:05, Akhil R пишет: > Add support for SMBus Alert and SMBus block read functions to > i2c-tegra driver > > Akhil R (2): > dt-bindings: i2c: tegra: Add SMBus feature properties > i2c: tegra: Add SMBus block read and SMBus alert functions > > .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4 ++ > drivers/i2c/busses/i2c-tegra.c | 54 +++++++++++++++++++++- > 2 files changed, 57 insertions(+), 1 deletion(-) > How this was tested? This series must include the DT patch. If there is no real user in upstream for this feature, then I don't think that we should bother at all about it.

3 years, 5 months

3
2
0 0

Re: [Linaro-mm-sig] [PATCH 1/2] dt-bindings: i2c: tegra: Add SMBus feature properties

by Rob Herring

On Thu, Dec 09, 2021 at 08:35:20PM +0530, Akhil R wrote: > Tegra I2C can use a gpio as an smbus-alert. Document the usage of > the same. > > Signed-off-by: Akhil R <akhilrajeev(a)nvidia.com> > --- > Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt > index 3f2f990..71ee79b 100644 > --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt > +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt > @@ -70,6 +70,10 @@ Required properties: > - rx > - tx > > +optional properties: > +- smbalert-gpio: Must contain an entry for the gpio to be used as smbus alert. > + It will be used only if optional smbus-alert property is present. There's already a standard way to do this with interrupts. And GPIOs can be interrupts usually. > + > Example: > > i2c@7000c000 { > -- > 2.7.4 > >

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Christian König

Am 13.12.21 um 12:18 schrieb Shunsuke Mie: > 2021年12月10日(金) 22:29 Christian König <christian.koenig(a)amd.com>: >> Am 10.12.21 um 14:26 schrieb Jason Gunthorpe: >>> On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote: >>>> Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: >>>>> On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: >>>>>> Hi Jason, >>>>>> Thank you for replying. >>>>>> >>>>>> 2021年12月8日(水) 2:14 Jason Gunthorpe <jgg(a)ziepe.ca>: >>>>>>> On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: >>>>>>>> Hi maintainers, >>>>>>>> >>>>>>>> Could you please review this patch series? >>>>>>> Why is it RFC? >>>>>>> >>>>>>> I'm confused why this is useful? >>>>>>> >>>>>>> This can't do copy from MMIO memory, so it shouldn't be compatible >>>>>>> with things like Gaudi - does something prevent this? >>>>>> I think if an export of the dma-buf supports vmap, CPU is able to access the >>>>>> mmio memory. >>>>>> >>>>>> Is it wrong? If this is wrong, there is no advantages this changes.. >>>>> I don't know what the dmabuf folks did, but yes, it is wrong. >>>>> >>>>> IOMEM must be touched using only special accessors, some platforms >>>>> crash if you don't do this. Even x86 will crash if you touch it with >>>>> something like an XMM optimized memcpy. >>>>> >>>>> Christian? If the vmap succeeds what rules must the caller use to >>>>> access the memory? >>>> See dma-buf-map.h and especially struct dma_buf_map. >>>> >>>> MMIO memory is perfectly supported here and actually the most common case. >>> Okay that looks sane, but this rxe RFC seems to ignore this >>> completely. It stuffs the vaddr directly into a umem which goes to all >>> manner of places in the driver. >>> >>> ?? >> Well, yes that can go boom pretty quickly. > Sorry, I was wrong. The dma_buf_map treats both iomem and vaddr region, but > this RFC only supports vaddr. Advantage of the partial support is we can use the > vaddr dma-buf in RXE without changing a rxe data copy implementation. Well that is most likely not a good idea. For example buffers for GPU drivers can be placed in both MMIO memory and system memory. If you don't want to provoke random failures you *MUST* be able to handle both if you want to use this. Regards, Christian. > > An example of a dma-buf pointing to a vaddr is some gpu drivers use RAM for > VRAM and we can get dma-buf for the region that indicates vaddr regions. > Specifically, the gpu driver using gpu/drm/drm_gem_cma_helper.c is one such > example. > >> Not sure what they want to use this for. > I'd like to use RDMA with RXE for that memory region. > > Best, > Shunsuke >> Christian. >> >>> Jason

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:05, Akhil R пишет: > +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) > +{ > + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; > + struct gpio_desc *alert_gpiod; > + struct i2c_client *ara; > + > + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); > + if (IS_ERR(alert_gpiod)) > + return PTR_ERR(alert_gpiod); > + > + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); > + if (smbalert->alert_data.irq <= 0) > + return smbalert->alert_data.irq; Why GPIO is needed at all if what's actually needed is the interrupt?

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:33, Andy Shevchenko пишет: > On Thu, Dec 9, 2021 at 5:30 PM Dmitry Osipenko <digetx(a)gmail.com> wrote: >> 09.12.2021 18:05, Akhil R пишет: >>> +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) >>> +{ >>> + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; >>> + struct gpio_desc *alert_gpiod; >>> + struct i2c_client *ara; >>> + >>> + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); >>> + if (IS_ERR(alert_gpiod)) >>> + return PTR_ERR(alert_gpiod); >>> + >>> + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); >>> + if (smbalert->alert_data.irq <= 0) >>> + return smbalert->alert_data.irq; >> >> 0 is the error condition. > > I'm not sure what you implied here. gpiod_to_irq() returns 0 if and > only if it goes to the architectures where it might be possible to > have valid vIRQ 0, but this is not the case (at least I never heard of > a such) for GPIO controllers on such platforms. So, looking at the > above code I may tell that the '=' part is redundant. > Yes, removal of the '=' should be enough here.

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:05, Akhil R пишет: > +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) > +{ > + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; > + struct gpio_desc *alert_gpiod; > + struct i2c_client *ara; > + > + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); > + if (IS_ERR(alert_gpiod)) > + return PTR_ERR(alert_gpiod); > + > + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); > + if (smbalert->alert_data.irq <= 0) > + return smbalert->alert_data.irq; 0 is the error condition.

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:05, Akhil R пишет: > Emulate the SMBus block read using ContinueXfer and SMBus using GPIO > interrupt. > > For SMBus block read, the driver reads the first byte with ContinueXfer > set which will help to parse the data count and read the remaining bytes > without stop condition in between. > SMBus alert is implemented using external gpio interrupt. > > Signed-off-by: Akhil R <akhilrajeev(a)nvidia.com> > --- > drivers/i2c/busses/i2c-tegra.c | 54 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 53 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c > index a5be8f0..3b70013 100644 > --- a/drivers/i2c/busses/i2c-tegra.c > +++ b/drivers/i2c/busses/i2c-tegra.c > @@ -14,6 +14,7 @@ > #include <linux/dma-mapping.h> > #include <linux/err.h> > #include <linux/i2c.h> > +#include <linux/i2c-smbus.h> > #include <linux/init.h> > #include <linux/interrupt.h> > #include <linux/io.h> > @@ -226,6 +227,11 @@ struct tegra_i2c_hw_feature { > bool has_interface_timing_reg; > }; > > +struct tegra_i2c_smbalert { smbalert isn't a word, should be smbus_alert. Same for the GPIO name and other places. > + struct i2c_smbus_alert_setup alert_data; > + struct i2c_client *ara; What "ara" stands for? Please use meaningful names, like alert_dev for example. I don't see where this member is used at all, please remove it. > +}; > + > /** > * struct tegra_i2c_dev - per device I2C context > * @dev: device reference for power management > @@ -280,6 +286,8 @@ struct tegra_i2c_dev { > int msg_err; > u8 *msg_buf; > > + struct tegra_i2c_smbalert smbalert; All properties must have doc comment. > struct completion dma_complete; > struct dma_chan *tx_dma_chan; > struct dma_chan *rx_dma_chan; > @@ -1232,6 +1240,11 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev, > return err; > > i2c_dev->msg_buf = msg->buf; > + > + /* The condition true implies smbus block read and len is already read*/ Proper SMBus capitalization in comments. Mussing whitespace in the end of the comment. > + if (msg->flags & I2C_M_RECV_LEN && end_state != MSG_END_CONTINUE) > + i2c_dev->msg_buf = msg->buf + 1; > + > i2c_dev->msg_buf_remaining = msg->len; > i2c_dev->msg_err = I2C_ERR_NONE; > i2c_dev->msg_read = !!(msg->flags & I2C_M_RD); > @@ -1388,6 +1401,15 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], > else > end_type = MSG_END_REPEAT_START; > } > + /* If M_RECV_LEN use ContinueXfer to read the first byte */ > + if (msgs[i].flags & I2C_M_RECV_LEN) { > + ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], MSG_END_CONTINUE); > + if (ret) > + break; > + /* Set the read byte as msg len */ > + msgs[i].len = msgs[i].buf[0]; > + dev_dbg(i2c_dev->dev, "reading %d bytes\n", msgs[i].len); > + } > ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], end_type); > if (ret) > break; > @@ -1415,7 +1437,8 @@ static u32 tegra_i2c_func(struct i2c_adapter *adap) > { > struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap); > u32 ret = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) | > - I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING; > + I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_10BIT_ADDR | > + I2C_FUNC_PROTOCOL_MANGLING; > > if (i2c_dev->hw->has_continue_xfer_support) > ret |= I2C_FUNC_NOSTART; > @@ -1727,6 +1750,29 @@ static int tegra_i2c_init_hardware(struct tegra_i2c_dev *i2c_dev) > return ret; > } > > +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) > +{ > + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; > + struct gpio_desc *alert_gpiod; > + struct i2c_client *ara; > + > + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); > + if (IS_ERR(alert_gpiod)) > + return PTR_ERR(alert_gpiod); > + > + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); > + if (smbalert->alert_data.irq <= 0) > + return smbalert->alert_data.irq; > + > + ara = i2c_new_smbus_alert_device(&i2c_dev->adapter, &smbalert->alert_data); > + if (IS_ERR(ara)) > + return PTR_ERR(ara); > + > + smbalert->ara = ara; > + > + return 0; > +} > + > static int tegra_i2c_probe(struct platform_device *pdev) > { > struct tegra_i2c_dev *i2c_dev; > @@ -1821,6 +1867,12 @@ static int tegra_i2c_probe(struct platform_device *pdev) > if (err) > goto release_rpm; > > + if (device_property_read_bool(i2c_dev->dev, "smbus-alert")) { I'd move this device_property_read_bool() inside of tegra_i2c_setup_smbus_alert(), for consistency with the rest of the code in this driver. Although, you shouldn't need it at all, use devm_gpiod_get_optional(). > + err = tegra_i2c_setup_smbalert(i2c_dev); > + if (err) > + dev_warn(&pdev->dev, "smbus-alert setup failed: %d\n", err); GPIO may probe-defer, must be dev_err_probe() here.

3 years, 5 months

1
0
0 0

[PATCH] drm: Remove duplicate include

by Jiapeng Chong

Clean up the following includecheck warning: ./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 62192411..7915047 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 1.8.3.1

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Daniel Vetter

Once more an entire week behind on mails, but this looked interesting enough. On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote: > On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote: > > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel): > > > > > > On 12/1/21 12:25, Christian König wrote: > > > > And why do you use dma_fence_chain to generate a timeline for > > > > TTM? > > > > That should come naturally because all the moves must be ordered. > > > > > > Oh, in this case because we're looking at adding stuff at the end > > > of > > > migration (like coalescing object shared fences and / or async > > > unbind > > > fences), which may not complete in order. > > > > Well that's ok as well. My question is why does this single dma_fence > > then shows up in the dma_fence_chain representing the whole > > migration? > > What we'd like to happen during eviction is that we > > 1) await any exclusive- or moving fences, then schedule the migration > blit. The blit manages its own GPU ptes. Results in a single fence. > 2) Schedule unbind of any gpu vmas, resulting possibly in multiple > fences. This sounds like over-optimizing for nothing. We only really care about pipeling moves on dgpu, and on dgpu we only care about modern userspace (because even gl moves in that direction). And modern means that usually even write access is only setting a read fence, because in vk/compute we only set write fences for object which need implicit sync, and _only_ when actually needed. So ignoring read fences for movings "because it's only reads" is actually busted. I think for buffer moves we should document and enforce (in review) the rule that you have to wait for all fences, otherwise boom. Same really like before freeing backing storage. Otherwise there's just too many gaps and surprises. And yes with Christian's rework of dma_resv this will change, and we'll allow multiple write fences (because that's what amdgpu encoded into their uapi). Still means that you cannot move a buffer without waiting for read fences (or kernel fences or anything really). The other thing is this entire spinlock recursion topic for dma_fence, and I'm deeply unhappy about the truckload of tricks i915 plays and hence in favour of avoiding recursion in this area as much as possible. If we really can't avoid it then irq_work to get a new clean context gets the job done. Making this messy and work is imo a feature, lock nesting of same level locks is just not a good&robust engineering idea. /me back to being completely burried I do hope I can find some more time to review a few more of Christian's patches this week though :-/ Cheers, Daniel > 3) Most but not all of the remaining resv shared fences will have been > finished in 2) We can't easily tell which so we have a couple of shared > fences left. > 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type > dma-fence-chain. > 5) hand the resulting dma-fence-chain representing the end of migration > over to ttm's resource manager. > > Now this means we have a dma-fence-chain disguised as a dma-fence out > in the wild, and it could in theory reappear as a 3) fence for another > migration unless a very careful audit is done, or as an input to the > dma-fence-array used for that single dependency. > > > > > That somehow doesn't seem to make sense because each individual step > > of > > the migration needs to wait for those dependencies as well even when > > it > > runs in parallel. > > > > > But that's not really the point, the point was that an (at least to > > > me) seemingly harmless usage pattern, be it real or fictious, ends > > > up > > > giving you severe internal- or cross-driver headaches. > > > > Yeah, we probably should document that better. But in general I don't > > see much reason to allow mixing containers. The dma_fence_array and > > dma_fence_chain objects have some distinct use cases and and using > > them > > to build up larger dependency structures sounds really questionable. > > Yes, I tend to agree to some extent here. Perhaps add warnings when > adding a chain or array as an input to array and when accidently > joining chains, and provide helpers for flattening if needed. > > /Thomas > > > > > > Christian. > > > > > > > > /Thomas > > > > > > > > > > > > > > Regards, > > > > Christian. > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Jason Gunthorpe

On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > Hi maintainers, > > Could you please review this patch series? Why is it RFC? I'm confused why this is useful? This can't do copy from MMIO memory, so it shouldn't be compatible with things like Gaudi - does something prevent this? Jason

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 03.12.21 um 15:50 schrieb Thomas Hellström: > > On 12/3/21 15:26, Christian König wrote: >> [Adding Daniel here as well] >> >> Am 03.12.21 um 15:18 schrieb Thomas Hellström: >>> [SNIP] >>>> Well that's ok as well. My question is why does this single dma_fence >>>> then shows up in the dma_fence_chain representing the whole >>>> migration? >>> What we'd like to happen during eviction is that we >>> >>> 1) await any exclusive- or moving fences, then schedule the migration >>> blit. The blit manages its own GPU ptes. Results in a single fence. >>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple >>> fences. >>> 3) Most but not all of the remaining resv shared fences will have been >>> finished in 2) We can't easily tell which so we have a couple of shared >>> fences left. >> >> Stop, wait a second here. We are going a bit in circles. >> >> Before you migrate a buffer, you *MUST* wait for all shared fences to >> complete. This is documented mandatory DMA-buf behavior. >> >> Daniel and I have discussed that quite extensively in the last few >> month. >> >> So how does it come that you do the blit before all shared fences are >> completed? > > Well we don't currently but wanted to... (I haven't consulted Daniel > in the matter, tbh). > > I was under the impression that all writes would add an exclusive > fence to the dma_resv. Yes that's correct. I'm working on to have more than one write fence, but that is currently under review. > If that's not the case or this is otherwise against the mandatory > DMA-buf bevhavior, we can certainly keep that part as is and that > would eliminate 3). Ah, now that somewhat starts to make sense. So your blit only waits for the writes to finish before starting the blit. Yes that's legal as long as you don't change the original content with the blit. But don't you then need to wait for both reads and writes before you unmap the VMAs? Anyway the good news is your problem totally goes away with the DMA-resv rework I've already send out. Basically it is now possible to have more than one fence in the DMA-resv object for migrations and all existing fences are kept around until they are finished. Regards, Christian. > > /Thomas >

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

[Adding Daniel here as well] Am 03.12.21 um 15:18 schrieb Thomas Hellström: > [SNIP] >> Well that's ok as well. My question is why does this single dma_fence >> then shows up in the dma_fence_chain representing the whole >> migration? > What we'd like to happen during eviction is that we > > 1) await any exclusive- or moving fences, then schedule the migration > blit. The blit manages its own GPU ptes. Results in a single fence. > 2) Schedule unbind of any gpu vmas, resulting possibly in multiple > fences. > 3) Most but not all of the remaining resv shared fences will have been > finished in 2) We can't easily tell which so we have a couple of shared > fences left. Stop, wait a second here. We are going a bit in circles. Before you migrate a buffer, you *MUST* wait for all shared fences to complete. This is documented mandatory DMA-buf behavior. Daniel and I have discussed that quite extensively in the last few month. So how does it come that you do the blit before all shared fences are completed? > 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type > dma-fence-chain. > 5) hand the resulting dma-fence-chain representing the end of migration > over to ttm's resource manager. > > Now this means we have a dma-fence-chain disguised as a dma-fence out > in the wild, and it could in theory reappear as a 3) fence for another > migration unless a very careful audit is done, or as an input to the > dma-fence-array used for that single dependency. > >> That somehow doesn't seem to make sense because each individual step >> of >> the migration needs to wait for those dependencies as well even when >> it >> runs in parallel. >> >>> But that's not really the point, the point was that an (at least to >>> me) seemingly harmless usage pattern, be it real or fictious, ends >>> up >>> giving you severe internal- or cross-driver headaches. >> Yeah, we probably should document that better. But in general I don't >> see much reason to allow mixing containers. The dma_fence_array and >> dma_fence_chain objects have some distinct use cases and and using >> them >> to build up larger dependency structures sounds really questionable. > Yes, I tend to agree to some extent here. Perhaps add warnings when > adding a chain or array as an input to array and when accidently > joining chains, and provide helpers for flattening if needed. Yeah, that's probably a really good idea. Going to put it on my todo list. Thanks, Christian. > > /Thomas > > >> Christian. >> >>> /Thomas >>> >>> >>>> Regards, >>>> Christian. >>>> >>>> >

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel): > > On 12/1/21 12:25, Christian König wrote: >> Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel): >>> >>> On 12/1/21 11:32, Christian König wrote: >>>> Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel): >>>>> [SNIP] >>>>>> >>>>>> What we could do is to avoid all this by not calling the callback >>>>>> with the lock held in the first place. >>>>> >>>>> If that's possible that might be a good idea, pls also see below. >>>> >>>> The problem with that is >>>> dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If >>>> we could avoid using that or at least allow it to drop the lock >>>> then we could call the callback without holding it. >>>> >>>> Somebody would need to audit the drivers and see if holding the >>>> lock is really necessary anywhere. >>>> >>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> /Thomas >>>>>>>>> >>>>>>>>> Oh, and a follow up question: >>>>>>>>> >>>>>>>>> If there was a way to break the recursion on final put() >>>>>>>>> (using the same basic approach as patch 2 in this series uses >>>>>>>>> to break recursion in enable_signaling()), so that none of >>>>>>>>> these containers did require any special treatment, would it >>>>>>>>> be worth pursuing? I guess it might be possible by having the >>>>>>>>> callbacks drop the references rather than the loop in the >>>>>>>>> final put. + a couple of changes in code iterating over the >>>>>>>>> fence pointers. >>>>>>>> >>>>>>>> That won't really help, you just move the recursion from the >>>>>>>> final put into the callback. >>>>>>> >>>>>>> How do we recurse from the callback? The introduced fence_put() >>>>>>> of individual fence pointers >>>>>>> doesn't recurse anymore (at most 1 level), and any callback >>>>>>> recursion is broken by the irq_work? >>>>>> >>>>>> Yeah, but then you would need to take another lock to avoid >>>>>> racing with dma_fence_array_signaled(). >>>>>> >>>>>>> >>>>>>> I figure the big amount of work would be to adjust code that >>>>>>> iterates over the individual fence pointers to recognize that >>>>>>> they are rcu protected. >>>>>> >>>>>> Could be that we could solve this with RCU, but that sounds like >>>>>> a lot of churn for no gain at all. >>>>>> >>>>>> In other words even with the problems solved I think it would be >>>>>> a really bad idea to allow chaining of dma_fence_array objects. >>>>> >>>>> Yes, that was really the question, Is it worth pursuing this? I'm >>>>> not really suggesting we should allow this as an intentional >>>>> feature. I'm worried, however, that if we allow these containers >>>>> to start floating around cross-driver (or even internally) >>>>> disguised as ordinary dma_fences, they would require a lot of >>>>> driver special casing, or else completely unexpeced WARN_ON()s and >>>>> lockdep splats would start to turn up, scaring people off from >>>>> using them. And that would be a breeding ground for hairy >>>>> driver-private constructs. >>>> >>>> Well the question is why we would want to do it? >>>> >>>> If it's to avoid inter driver lock dependencies by avoiding to call >>>> the callback with the spinlock held, then yes please. We had tons >>>> of problems with that, resulting in irq_work and work_item >>>> delegation all over the place. >>> >>> Yes, that sounds like something desirable, but in these containers, >>> what's causing the lock dependencies is the enable_signaling() >>> callback that is typically called locked. >>> >>> >>>> >>>> If it's to allow nesting of dma_fence_array instances, then it's >>>> most likely a really bad idea even if we fix all the locking order >>>> problems. >>> >>> Well I think my use-case where I hit a dead end may illustrate what >>> worries me here: >>> >>> 1) We use a dma-fence-array to coalesce all dependencies for ttm >>> object migration. >>> 2) We use a dma-fence-chain to order the resulting dm_fence into a >>> timeline because the TTM resource manager code requires that. >>> >>> Initially seemingly harmless to me. >>> >>> But after a sequence evict->alloc->clear, the dma-fence-chain feeds >>> into the dma-fence-array for the clearing operation. Code still >>> works fine, and no deep recursion, no warnings. But if I were to add >>> another driver to the system that instead feeds a dma-fence-array >>> into a dma-fence-chain, this would give me a lockdep splat. >>> >>> So then if somebody were to come up with the splendid idea of using >>> a dma-fence-chain to initially coalesce fences, I'd hit the same >>> problem or risk illegaly joining two dma-fence-chains together. >>> >>> To fix this, I would need to look at the incoming fences and iterate >>> over any dma-fence-array or dma-fence-chain that is fed into the >>> dma-fence-array to flatten out the input. In fact all >>> dma-fence-array users would need to do that, and even >>> dma-fence-chain users watching out for not joining chains together >>> or accidently add an array that perhaps came as a disguised >>> dma-fence from antother driver. >>> >>> So the purpose to me would be to allow these containers as input to >>> eachother without a lot of in-driver special-casing, be it by >>> breaking recursion on built-in flattening to avoid >>> >>> a) Hitting issues in the future or with existing interoperating >>> drivers. >>> b) Avoid driver-private containers that also might break the >>> interoperability. (For example the i915 currently driver-private >>> dma_fence_work avoid all these problems, but we're attempting to >>> address issues in common code rather than re-inventing stuff >>> internally). >> >> I don't think that a dma_fence_array or dma_fence_chain is the right >> thing to begin with in those use cases. >> >> When you want to coalesce the dependencies for a job you could either >> use an xarray like Daniel did for the scheduler or some hashtable >> like we use in amdgpu. But I don't see the need for exposing the >> dma_fence interface for those. > > This is because the interface to our migration code takes just a > single dma-fence as dependency. Now this is of course something we > need to look at to mitigate this, but see below. Yeah, that's actually fine. >> >> And why do you use dma_fence_chain to generate a timeline for TTM? >> That should come naturally because all the moves must be ordered. > > Oh, in this case because we're looking at adding stuff at the end of > migration (like coalescing object shared fences and / or async unbind > fences), which may not complete in order. Well that's ok as well. My question is why does this single dma_fence then shows up in the dma_fence_chain representing the whole migration? That somehow doesn't seem to make sense because each individual step of the migration needs to wait for those dependencies as well even when it runs in parallel. > But that's not really the point, the point was that an (at least to > me) seemingly harmless usage pattern, be it real or fictious, ends up > giving you severe internal- or cross-driver headaches. Yeah, we probably should document that better. But in general I don't see much reason to allow mixing containers. The dma_fence_array and dma_fence_chain objects have some distinct use cases and and using them to build up larger dependency structures sounds really questionable. Christian. > > /Thomas > > >> >> Regards, >> Christian. >> >>

3 years, 6 months

1
0
0 0

[PATCH] drm/amdkfd: Use max() instead of doing it manually

by Jiapeng Chong

Fix following coccicheck warning: ./drivers/gpu/drm/amd/amdkfd/kfd_svm.c:2193:16-17: WARNING opportunity for max(). Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index f2db49c..4f7e7b1 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -2190,7 +2190,7 @@ void schedule_deferred_list_work(struct svm_range_list *svms) start = mni->interval_tree.start; last = mni->interval_tree.last; - start = (start > range->start ? start : range->start) >> PAGE_SHIFT; + start = max(start, range->start) >> PAGE_SHIFT; last = (last < (range->end - 1) ? last : range->end - 1) >> PAGE_SHIFT; pr_debug("[0x%lx 0x%lx] range[0x%lx 0x%lx] notifier[0x%lx 0x%lx] %d\n", start, last, range->start >> PAGE_SHIFT, -- 1.8.3.1

3 years, 6 months

2
1
0 0

Re: [Linaro-mm-sig] [syzbot] WARNING in __dma_map_sg_attrs

by Christoph Hellwig

This means the virtgpu driver uses dma mapping helpers but has not set up a DMA mask (which most likely suggests it is some kind of virtual device). On Wed, Dec 01, 2021 at 10:18:21AM -0800, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: c5c17547b778 Merge tag 'net-5.16-rc3' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=13a73609b00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=bf85c53718a1e697 > dashboard link: https://syzkaller.appspot.com/bug?extid=10e27961f4da37c443b2 > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com > > ------------[ cut here ]------------ > WARNING: CPU: 2 PID: 17169 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > Modules linked in: > CPU: 0 PID: 17169 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 > RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d 70 6d b1 0d e9 db fe ff ff e8 86 ff 12 00 0f 0b e8 7f ff 12 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 70 ff 12 00 49 8d 7f 50 48 b8 00 > RSP: 0018:ffffc90002c0fb20 EFLAGS: 00010216 > RAX: 0000000000013018 RBX: 0000000000000020 RCX: ffffc900037d4000 > RDX: 0000000000040000 RSI: ffffffff8163d361 RDI: ffff8880182ae4d0 > RBP: ffff8880182ae088 R08: 0000000000000002 R09: ffff888017ba054f > R10: ffffffff8163d242 R11: 000000000008808a R12: 0000000000000000 > R13: ffff888024ca5700 R14: 0000000000000001 R15: 0000000000000000 > FS: 00007fa269e34700(0000) GS:ffff88802cb00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 000000000040c120 CR3: 000000006c77c000 CR4: 0000000000150ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 > drm_gem_map_dma_buf+0x12a/0x1e0 drivers/gpu/drm/drm_prime.c:633 > __map_dma_buf drivers/dma-buf/dma-buf.c:675 [inline] > dma_buf_map_attachment+0x39a/0x5b0 drivers/dma-buf/dma-buf.c:954 > drm_gem_prime_import_dev.part.0+0x85/0x220 drivers/gpu/drm/drm_prime.c:939 > drm_gem_prime_import_dev drivers/gpu/drm/drm_prime.c:982 [inline] > drm_gem_prime_import+0xc8/0x200 drivers/gpu/drm/drm_prime.c:982 > virtgpu_gem_prime_import+0x49/0x150 drivers/gpu/drm/virtio/virtgpu_prime.c:166 > drm_gem_prime_fd_to_handle+0x21d/0x550 drivers/gpu/drm/drm_prime.c:318 > drm_prime_fd_to_handle_ioctl+0x9b/0xd0 drivers/gpu/drm/drm_prime.c:374 > drm_ioctl_kernel+0x27d/0x4e0 drivers/gpu/drm/drm_ioctl.c:782 > drm_ioctl+0x51e/0x9d0 drivers/gpu/drm/drm_ioctl.c:885 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:874 [inline] > __se_sys_ioctl fs/ioctl.c:860 [inline] > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7fa26c8beae9 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fa269e34188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 00007fa26c9d1f60 RCX: 00007fa26c8beae9 > RDX: 00000000200004c0 RSI: 00000000c00c642e RDI: 0000000000000005 > RBP: 00007fa26c918f6d R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > R13: 00007ffc0019c51f R14: 00007fa269e34300 R15: 0000000000022000 > </TASK> > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller(a)googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ---end quoted text---

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel): > > On 12/1/21 11:32, Christian König wrote: >> Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel): >>> [SNIP] >>>> >>>> What we could do is to avoid all this by not calling the callback >>>> with the lock held in the first place. >>> >>> If that's possible that might be a good idea, pls also see below. >> >> The problem with that is >> dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If we >> could avoid using that or at least allow it to drop the lock then we >> could call the callback without holding it. >> >> Somebody would need to audit the drivers and see if holding the lock >> is really necessary anywhere. >> >>>> >>>>>> >>>>>>>> >>>>>>>> /Thomas >>>>>>> >>>>>>> Oh, and a follow up question: >>>>>>> >>>>>>> If there was a way to break the recursion on final put() (using >>>>>>> the same basic approach as patch 2 in this series uses to break >>>>>>> recursion in enable_signaling()), so that none of these >>>>>>> containers did require any special treatment, would it be worth >>>>>>> pursuing? I guess it might be possible by having the callbacks >>>>>>> drop the references rather than the loop in the final put. + a >>>>>>> couple of changes in code iterating over the fence pointers. >>>>>> >>>>>> That won't really help, you just move the recursion from the >>>>>> final put into the callback. >>>>> >>>>> How do we recurse from the callback? The introduced fence_put() of >>>>> individual fence pointers >>>>> doesn't recurse anymore (at most 1 level), and any callback >>>>> recursion is broken by the irq_work? >>>> >>>> Yeah, but then you would need to take another lock to avoid racing >>>> with dma_fence_array_signaled(). >>>> >>>>> >>>>> I figure the big amount of work would be to adjust code that >>>>> iterates over the individual fence pointers to recognize that they >>>>> are rcu protected. >>>> >>>> Could be that we could solve this with RCU, but that sounds like a >>>> lot of churn for no gain at all. >>>> >>>> In other words even with the problems solved I think it would be a >>>> really bad idea to allow chaining of dma_fence_array objects. >>> >>> Yes, that was really the question, Is it worth pursuing this? I'm >>> not really suggesting we should allow this as an intentional >>> feature. I'm worried, however, that if we allow these containers to >>> start floating around cross-driver (or even internally) disguised as >>> ordinary dma_fences, they would require a lot of driver special >>> casing, or else completely unexpeced WARN_ON()s and lockdep splats >>> would start to turn up, scaring people off from using them. And that >>> would be a breeding ground for hairy driver-private constructs. >> >> Well the question is why we would want to do it? >> >> If it's to avoid inter driver lock dependencies by avoiding to call >> the callback with the spinlock held, then yes please. We had tons of >> problems with that, resulting in irq_work and work_item delegation >> all over the place. > > Yes, that sounds like something desirable, but in these containers, > what's causing the lock dependencies is the enable_signaling() > callback that is typically called locked. > > >> >> If it's to allow nesting of dma_fence_array instances, then it's most >> likely a really bad idea even if we fix all the locking order problems. > > Well I think my use-case where I hit a dead end may illustrate what > worries me here: > > 1) We use a dma-fence-array to coalesce all dependencies for ttm > object migration. > 2) We use a dma-fence-chain to order the resulting dm_fence into a > timeline because the TTM resource manager code requires that. > > Initially seemingly harmless to me. > > But after a sequence evict->alloc->clear, the dma-fence-chain feeds > into the dma-fence-array for the clearing operation. Code still works > fine, and no deep recursion, no warnings. But if I were to add another > driver to the system that instead feeds a dma-fence-array into a > dma-fence-chain, this would give me a lockdep splat. > > So then if somebody were to come up with the splendid idea of using a > dma-fence-chain to initially coalesce fences, I'd hit the same problem > or risk illegaly joining two dma-fence-chains together. > > To fix this, I would need to look at the incoming fences and iterate > over any dma-fence-array or dma-fence-chain that is fed into the > dma-fence-array to flatten out the input. In fact all dma-fence-array > users would need to do that, and even dma-fence-chain users watching > out for not joining chains together or accidently add an array that > perhaps came as a disguised dma-fence from antother driver. > > So the purpose to me would be to allow these containers as input to > eachother without a lot of in-driver special-casing, be it by breaking > recursion on built-in flattening to avoid > > a) Hitting issues in the future or with existing interoperating drivers. > b) Avoid driver-private containers that also might break the > interoperability. (For example the i915 currently driver-private > dma_fence_work avoid all these problems, but we're attempting to > address issues in common code rather than re-inventing stuff internally). I don't think that a dma_fence_array or dma_fence_chain is the right thing to begin with in those use cases. When you want to coalesce the dependencies for a job you could either use an xarray like Daniel did for the scheduler or some hashtable like we use in amdgpu. But I don't see the need for exposing the dma_fence interface for those. And why do you use dma_fence_chain to generate a timeline for TTM? That should come naturally because all the moves must be ordered. Regards, Christian.

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel): > [SNIP] >> >> What we could do is to avoid all this by not calling the callback >> with the lock held in the first place. > > If that's possible that might be a good idea, pls also see below. The problem with that is dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If we could avoid using that or at least allow it to drop the lock then we could call the callback without holding it. Somebody would need to audit the drivers and see if holding the lock is really necessary anywhere. >> >>>> >>>>>> >>>>>> /Thomas >>>>> >>>>> Oh, and a follow up question: >>>>> >>>>> If there was a way to break the recursion on final put() (using >>>>> the same basic approach as patch 2 in this series uses to break >>>>> recursion in enable_signaling()), so that none of these containers >>>>> did require any special treatment, would it be worth pursuing? I >>>>> guess it might be possible by having the callbacks drop the >>>>> references rather than the loop in the final put. + a couple of >>>>> changes in code iterating over the fence pointers. >>>> >>>> That won't really help, you just move the recursion from the final >>>> put into the callback. >>> >>> How do we recurse from the callback? The introduced fence_put() of >>> individual fence pointers >>> doesn't recurse anymore (at most 1 level), and any callback >>> recursion is broken by the irq_work? >> >> Yeah, but then you would need to take another lock to avoid racing >> with dma_fence_array_signaled(). >> >>> >>> I figure the big amount of work would be to adjust code that >>> iterates over the individual fence pointers to recognize that they >>> are rcu protected. >> >> Could be that we could solve this with RCU, but that sounds like a >> lot of churn for no gain at all. >> >> In other words even with the problems solved I think it would be a >> really bad idea to allow chaining of dma_fence_array objects. > > Yes, that was really the question, Is it worth pursuing this? I'm not > really suggesting we should allow this as an intentional feature. I'm > worried, however, that if we allow these containers to start floating > around cross-driver (or even internally) disguised as ordinary > dma_fences, they would require a lot of driver special casing, or else > completely unexpeced WARN_ON()s and lockdep splats would start to turn > up, scaring people off from using them. And that would be a breeding > ground for hairy driver-private constructs. Well the question is why we would want to do it? If it's to avoid inter driver lock dependencies by avoiding to call the callback with the spinlock held, then yes please. We had tons of problems with that, resulting in irq_work and work_item delegation all over the place. If it's to allow nesting of dma_fence_array instances, then it's most likely a really bad idea even if we fix all the locking order problems. Christian. > > /Thomas > > >> >> Christian. >> >>> >>> >>> Thanks, >>> >>> /Thomas >>> >>>

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v4] dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow

by John Stultz

On Thu, Nov 25, 2021 at 11:48 PM <guangming.cao(a)mediatek.com> wrote: > > From: Guangming <Guangming.Cao(a)mediatek.com> > > For previous version, it uses 'sg_table.nent's to traverse sg_table in pages > free flow. > However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of > created entries in the DMA adderess space. > So, use 'sg_table.nents' in pages free flow will case some pages can't be freed. > > Here we should use sg_table.orig_nents to free pages memory, but use the > sgtable helper 'for each_sgtable_sg'(, instead of the previous rather common > helper 'for_each_sg' which maybe cause memory leak) is much better. > > Fixes: d963ab0f15fb0 ("dma-buf: system_heap: Allocate higher order pages if available") > Signed-off-by: Guangming <Guangming.Cao(a)mediatek.com> > Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> > Cc: <stable(a)vger.kernel.org> # 5.11.* Thanks so much for catching this and sending in all the revisions! Reviewed-by: John Stultz <john.stultz(a)linaro.org>

3 years, 6 months

2
1
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 01.12.21 um 09:23 schrieb Thomas Hellström (Intel): > [SNIP] >>>>> Jason and I came up with a deep dive iterator for his use case, but I >>>>> think we don't want to use that any more after my dma_resv rework. >>>>> >>>>> In other words when you need to create a new dma_fence_array you >>>>> flatten >>>>> out the existing construct which is at worst case >>>>> dma_fence_chain->dma_fence_array->dma_fence. >>>> Ok, Are there any cross-driver contract here, Like every driver >>>> using a >>>> dma_fence_array need to check for dma_fence_chain and flatten like >>>> above? >> >> So far we only discussed that on the mailing list but haven't made >> any documentation for that. > > OK, one other cross-driver pitfall I see is if someone accidently > joins two fence chains together by creating a fence chain unknowingly > using another fence chain as the @fence argument? That would indeed be illegal and we should probably add a WARN_ON() for that. > > The third cross-driver pitfall IMHO is the locking dependency these > containers add. Other drivers (read at least i915) may have defined > slightly different locking orders and that should also be addressed if > needed, but that requires a cross driver agreement what the locking > orders really are. Patch 1 actually addresses this, while keeping the > container lockdep warnings for deep recursions, so at least I think > that could serve as a discussion starter. No, drivers should never make any assumptions on that. E.g. when you need to take a look from a callback you must guarantee that you never have that lock taken when you call any of the dma_fence functions. Your patch breaks the lockdep annotation for that. What we could do is to avoid all this by not calling the callback with the lock held in the first place. >> >>>> >>>> /Thomas >>> >>> Oh, and a follow up question: >>> >>> If there was a way to break the recursion on final put() (using the >>> same basic approach as patch 2 in this series uses to break >>> recursion in enable_signaling()), so that none of these containers >>> did require any special treatment, would it be worth pursuing? I >>> guess it might be possible by having the callbacks drop the >>> references rather than the loop in the final put. + a couple of >>> changes in code iterating over the fence pointers. >> >> That won't really help, you just move the recursion from the final >> put into the callback. > > How do we recurse from the callback? The introduced fence_put() of > individual fence pointers > doesn't recurse anymore (at most 1 level), and any callback recursion > is broken by the irq_work? Yeah, but then you would need to take another lock to avoid racing with dma_fence_array_signaled(). > > I figure the big amount of work would be to adjust code that iterates > over the individual fence pointers to recognize that they are rcu > protected. Could be that we could solve this with RCU, but that sounds like a lot of churn for no gain at all. In other words even with the problems solved I think it would be a really bad idea to allow chaining of dma_fence_array objects. Christian. > > > Thanks, > > /Thomas > >

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 30.11.21 um 20:27 schrieb Thomas Hellström: > > On 11/30/21 19:12, Thomas Hellström wrote: >> On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote: >>> Am 30.11.21 um 15:35 schrieb Thomas Hellström: >>>> On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote: >>>>> Am 30.11.21 um 13:56 schrieb Thomas Hellström: >>>>>> On 11/30/21 13:42, Christian König wrote: >>>>>>> Am 30.11.21 um 13:31 schrieb Thomas Hellström: >>>>>>>> [SNIP] >>>>>>>>> Other than that, I didn't investigate the nesting fails >>>>>>>>> enough to >>>>>>>>> say I can accurately review this. :) >>>>>>>> Basically the problem is that within enable_signaling() >>>>>>>> which >>>>>>>> is >>>>>>>> called with the dma_fence lock held, we take the dma_fence >>>>>>>> lock >>>>>>>> of >>>>>>>> another fence. If that other fence is a dma_fence_array, or >>>>>>>> a >>>>>>>> dma_fence_chain which in turn tries to lock a >>>>>>>> dma_fence_array >>>>>>>> we hit >>>>>>>> a splat. >>>>>>> Yeah, I already thought that you constructed something like >>>>>>> that. >>>>>>> >>>>>>> You get the splat because what you do here is illegal, you >>>>>>> can't >>>>>>> mix >>>>>>> dma_fence_array and dma_fence_chain like this or you can end >>>>>>> up >>>>>>> in a >>>>>>> stack corruption. >>>>>> Hmm. Ok, so what is the stack corruption, is it that the >>>>>> enable_signaling() will end up with endless recursion? If so, >>>>>> wouldn't >>>>>> it be more usable we break that recursion chain and allow a >>>>>> more >>>>>> general use? >>>>> The problem is that this is not easily possible for >>>>> dma_fence_array >>>>> containers. Just imagine that you drop the last reference to the >>>>> containing fences during dma_fence_array destruction if any of >>>>> the >>>>> contained fences is another container you can easily run into >>>>> recursion >>>>> and with that stack corruption. >>>> Indeed, that would require some deeper surgery. >>>> >>>>> That's one of the major reasons I came up with the >>>>> dma_fence_chain >>>>> container. This one you can chain any number of elements together >>>>> without running into any recursion. >>>>> >>>>>> Also what are the mixing rules between these? Never use a >>>>>> dma-fence-chain as one of the array fences and never use a >>>>>> dma-fence-array as a dma-fence-chain fence? >>>>> You can't add any other container to a dma_fence_array, neither >>>>> other >>>>> dma_fence_array instances nor dma_fence_chain instances. >>>>> >>>>> IIRC at least technically a dma_fence_chain can contain a >>>>> dma_fence_array if you absolutely need that, but Daniel, Jason >>>>> and I >>>>> already had the same discussion a while back and came to the >>>>> conclusion >>>>> to avoid that as well if possible. >>>> Yes, this is actually the use-case. But what I can't easily >>>> guarantee >>>> is that that dma_fence_chain isn't fed into a dma_fence_array >>>> somewhere >>>> else. How do you typically avoid that? >>>> >>>> Meanwhile I guess I need to take a different approach in the driver >>>> to >>>> avoid this altogether. >>> Jason and I came up with a deep dive iterator for his use case, but I >>> think we don't want to use that any more after my dma_resv rework. >>> >>> In other words when you need to create a new dma_fence_array you >>> flatten >>> out the existing construct which is at worst case >>> dma_fence_chain->dma_fence_array->dma_fence. >> Ok, Are there any cross-driver contract here, Like every driver using a >> dma_fence_array need to check for dma_fence_chain and flatten like >> above? So far we only discussed that on the mailing list but haven't made any documentation for that. >> >> /Thomas > > Oh, and a follow up question: > > If there was a way to break the recursion on final put() (using the > same basic approach as patch 2 in this series uses to break recursion > in enable_signaling()), so that none of these containers did require > any special treatment, would it be worth pursuing? I guess it might be > possible by having the callbacks drop the references rather than the > loop in the final put. + a couple of changes in code iterating over > the fence pointers. That won't really help, you just move the recursion from the final put into the callback. What could be possible is to use an work item for any possible operation, e.g. enabling, signaling and destruction. But in the last discussion everybody agreed that it is better to just flatten out the array. Christian. > > > /Thomas > >> >>> Regards, >>> Christian. >>> >>>> /Thomas >>>> >>>> >>>>> Regards, >>>>> Christian. >>>>> >>>>>> /Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> Christian. >>>>>>> >>>>>>>> But I'll update the commit message with a typical splat. >>>>>>>> >>>>>>>> /Thomas

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 30.11.21 um 15:35 schrieb Thomas Hellström: > On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote: >> Am 30.11.21 um 13:56 schrieb Thomas Hellström: >>> On 11/30/21 13:42, Christian König wrote: >>>> Am 30.11.21 um 13:31 schrieb Thomas Hellström: >>>>> [SNIP] >>>>>> Other than that, I didn't investigate the nesting fails >>>>>> enough to >>>>>> say I can accurately review this. :) >>>>> Basically the problem is that within enable_signaling() which >>>>> is >>>>> called with the dma_fence lock held, we take the dma_fence lock >>>>> of >>>>> another fence. If that other fence is a dma_fence_array, or a >>>>> dma_fence_chain which in turn tries to lock a dma_fence_array >>>>> we hit >>>>> a splat. >>>> Yeah, I already thought that you constructed something like that. >>>> >>>> You get the splat because what you do here is illegal, you can't >>>> mix >>>> dma_fence_array and dma_fence_chain like this or you can end up >>>> in a >>>> stack corruption. >>> Hmm. Ok, so what is the stack corruption, is it that the >>> enable_signaling() will end up with endless recursion? If so, >>> wouldn't >>> it be more usable we break that recursion chain and allow a more >>> general use? >> The problem is that this is not easily possible for dma_fence_array >> containers. Just imagine that you drop the last reference to the >> containing fences during dma_fence_array destruction if any of the >> contained fences is another container you can easily run into >> recursion >> and with that stack corruption. > Indeed, that would require some deeper surgery. > >> That's one of the major reasons I came up with the dma_fence_chain >> container. This one you can chain any number of elements together >> without running into any recursion. >> >>> Also what are the mixing rules between these? Never use a >>> dma-fence-chain as one of the array fences and never use a >>> dma-fence-array as a dma-fence-chain fence? >> You can't add any other container to a dma_fence_array, neither other >> dma_fence_array instances nor dma_fence_chain instances. >> >> IIRC at least technically a dma_fence_chain can contain a >> dma_fence_array if you absolutely need that, but Daniel, Jason and I >> already had the same discussion a while back and came to the >> conclusion >> to avoid that as well if possible. > Yes, this is actually the use-case. But what I can't easily guarantee > is that that dma_fence_chain isn't fed into a dma_fence_array somewhere > else. How do you typically avoid that? > > Meanwhile I guess I need to take a different approach in the driver to > avoid this altogether. Jason and I came up with a deep dive iterator for his use case, but I think we don't want to use that any more after my dma_resv rework. In other words when you need to create a new dma_fence_array you flatten out the existing construct which is at worst case dma_fence_chain->dma_fence_array->dma_fence. Regards, Christian. > > /Thomas > > >> Regards, >> Christian. >> >>> /Thomas >>> >>> >>> >>> >>>> Regards, >>>> Christian. >>>> >>>>> But I'll update the commit message with a typical splat. >>>>> >>>>> /Thomas >

3 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 30.11.21 um 13:56 schrieb Thomas Hellström: > > On 11/30/21 13:42, Christian König wrote: >> Am 30.11.21 um 13:31 schrieb Thomas Hellström: >>> [SNIP] >>>> Other than that, I didn't investigate the nesting fails enough to >>>> say I can accurately review this. :) >>> >>> Basically the problem is that within enable_signaling() which is >>> called with the dma_fence lock held, we take the dma_fence lock of >>> another fence. If that other fence is a dma_fence_array, or a >>> dma_fence_chain which in turn tries to lock a dma_fence_array we hit >>> a splat. >> >> Yeah, I already thought that you constructed something like that. >> >> You get the splat because what you do here is illegal, you can't mix >> dma_fence_array and dma_fence_chain like this or you can end up in a >> stack corruption. > > Hmm. Ok, so what is the stack corruption, is it that the > enable_signaling() will end up with endless recursion? If so, wouldn't > it be more usable we break that recursion chain and allow a more > general use? The problem is that this is not easily possible for dma_fence_array containers. Just imagine that you drop the last reference to the containing fences during dma_fence_array destruction if any of the contained fences is another container you can easily run into recursion and with that stack corruption. That's one of the major reasons I came up with the dma_fence_chain container. This one you can chain any number of elements together without running into any recursion. > Also what are the mixing rules between these? Never use a > dma-fence-chain as one of the array fences and never use a > dma-fence-array as a dma-fence-chain fence? You can't add any other container to a dma_fence_array, neither other dma_fence_array instances nor dma_fence_chain instances. IIRC at least technically a dma_fence_chain can contain a dma_fence_array if you absolutely need that, but Daniel, Jason and I already had the same discussion a while back and came to the conclusion to avoid that as well if possible. Regards, Christian. > > /Thomas > > > > >> >> Regards, >> Christian. >> >>> >>> But I'll update the commit message with a typical splat. >>> >>> /Thomas >>

3 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig