Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

127 participants
7043 discussions

Bake Your Way to Billions: A Look at the Addictive World of Store Management Games

by hot.meerkat.lloh＠hidingmail.net

Ever dreamed of running your own bustling enterprise, watching your profits soar, and building an empire from humble beginnings? If so, you've likely stumbled upon the fascinating and surprisingly addictive world of store management games. These titles offer a unique blend of strategy, incremental growth, and the satisfying feeling of seeing your hard work pay off. And when it comes to the purest, most delightful form of this genre, one game stands out: https://cookieclickers.io/ The Sweet Simplicity of Cookie Clicker: A Gateway to Management At its heart, Cookie Clicker is incredibly simple. You start with a single, humble cookie, and your goal is to click it to generate more cookies. These initial clicks are crucial, as they fund your first upgrades. Soon, you’ll be able to purchase "grandmas," who automatically bake cookies for you, freeing up your clicking finger. From there, the sky's the limit! You'll acquire farms, factories, mines, and even portals to other dimensions, all dedicated to the singular purpose of baking more and more cookies. What makes Cookie Clicker so captivating is its elegant progression system. Each new upgrade and building provides a tangible boost to your cookie production, creating a satisfying feedback loop. The numbers on your screen grow exponentially, transforming from humble dozens to mind-boggling septillions and beyond. It’s a masterclass in incremental design, making every new purchase feel impactful and exciting. Beyond the Click: Strategic Thinking and Exponential Growth While the initial appeal of Cookie Clicker might be the simple act of clicking, true mastery lies in strategic decision-making. As your cookie empire expands, you'll be faced with choices: Upgrade Prioritization: Should you invest in another Grandma, a new farm, or a powerful upgrade that boosts all your existing structures? Understanding the cost-benefit analysis of each option is key. Synergies: Many upgrades have synergistic effects, meaning they become more powerful when paired with specific buildings. Discovering these combinations is a delightful puzzle. Ascension and Prestige: Eventually, you’ll unlock the ability to “ascend,” resetting your game but granting you powerful "heavenly chips" that provide permanent bonuses. This meta-progression adds a whole new layer of long-term strategy, encouraging you to rethink your approach with each new playthrough. These elements elevate Cookie Clicker from a simple clicking game to a genuinely engaging management simulation. It teaches you about exponential growth, compound interest (in a fun, cookie-filled way!), and the satisfaction of building something from nothing. Tips for Aspiring Cookie Tycoons If you’re ready to dive into the sweet, sweet world of Cookie Clicker, here are a few friendly tips to get you started: Don't Be Afraid to Click! In the early game, your clicks are your most valuable resource. Keep that finger moving! Invest in Grandmas Early: They're your first step towards automation and a steady cookie income. Always Buy Upgrades: The small boosts they provide add up quickly and are often more cost-effective than new buildings in the short term. Look for Golden Cookies: These appear randomly and offer temporary, powerful buffs. Clicking them can drastically boost your production! Consider Ascending: While it seems daunting to reset your progress, the permanent bonuses you gain make future runs much faster and more efficient. The Endless Appeal of Automation Cookie Clicker, and store management games in general, tap into a fundamental human desire: the joy of creation and the satisfaction of watching systems work efficiently. There's a particular kind of quiet pleasure in setting up a well-oiled machine and observing its output multiply. So, if you're looking for a game that's easy to pick up, surprisingly deep, and immensely satisfying, give Cookie Clicker a try. You might just find yourself baking billions before you know it!

7 hours, 29 minutes

WIZARD GEO COORDINATES RECOVERY HACKER

by lf2225258＠gmail.com

RECOVER YOUR STOLEN CRYPTO / BTC / USDT / ETH WITH THE HELP OF "WIZARD GEO COORDINATES RECOVERY HACKER" I am writing to sincerely express my appreciation for your support and assistance during a very difficult time in my life. Your professionalism and dedication in helping me recover my lost bitcoin. Throughout the entire process, they remained professional and respectful. They were also able to explain difficult technical topics in a simple way, which helped me understand what was happening. Thank you once again for your commitment. I am grateful for your help and wish you continued success in all that you do. Highly recommend his services to anyone who needs his services. CONTACT THEM VIA Email: geovcoordinateshacker(a)gmail.com WhatsApp ( +1 ( 318 ) 203-3657 ) Telegram @Geocoordinateshacker Website: https://geovcoordinateshac.wixsite.c...ordinates-hack I never would have imagined that I could recover my stolen bitcoin to my wallet after losing everything to a fake investment platform.

18 hours, 44 minutes

by keepmealive78＠gmail.com

Buy real and fake passport online, Buy ID cards online, (WhatsApp : +49 1575 3756974) Buy driving license, Buy drivers license online, Buy green card, residence permit, IELT, work permit, citizenship, buy Canadian resident permits, apply for Canadian citizenship certificates, buy Canadian ID cards, buy novelty ID cards, buy authentic identity documents. https://buyrealcurrency.com/ https://buyrealcurrency.com/ https://buyrealcurrency.com/product/加拿大居留许可/ https://rushmynewpassport.com/product/buy-canadian-resident-permits/ (WhatsApp : +49 1575 3756974) WeChat ID : Scottbowers44 (Email: authenticnotes5(a)gmail.com) https://counterfeitdocsforsale.com/ Buy fake US dollars (USD), buy fake Chinese yuan (CNY), buy fake RMB/RMB, buy fake Canadian dollars (CAD), buy fake Australian dollars (AUD) Buy fake British pounds (GBP), buy fake Euros (EUR), buy fake Hong Kong dollars ($HK). buy fake US dollars/Australian dollars/Canadian dollars/CNY/Euros/CNY, buy fake Euro banknotes, buy fake Australian dollars, buy fake Canadian dollars, buy fake US dollars, buy fake RMB online, buy fake RMB https://globaltraveldocs.com/ https://rushmynewpassport.com/ We offer all types of visas, travel documents, and passports at the best prices and with exceptional quality. We handle passports for small countries, multinational passports, entry and exit assistance for Southeast Asia, passport activation, expedited naturalization, and second identity planning, giving you an alternative. (WhatsApp : +49 1575 3756974) Email: authenticnotes5(a)gmail.com https://rushmynewpassport.com/ Buy passports online (Email: authenticnotes5(a)gmail.com) buy USA passports, buy Chinese passports, buy Hong Kong passports, buy Taiwan passports, buy diplomatic passports, Buy China travel documents People's Republic of China (PRC) https://rushmynewpassport.com/ https://buyrealcurrency.com/product/buy-real-and-fake-passport/ https://rushmynewpassport.com/buy-real-usa-passport-online/ (WhatsApp : +49 1575 3756974 )

1 day, 8 hours

Prepare to Rage Quit (and Maybe Love It): Diving into Level Devil

by graceful.earthworm.hsos＠hidingmail.com

So, you're looking for a new game to sink your teeth into? Something challenging, maybe a little bit infuriating, and definitely memorable? Look no further than Level Devil. This deceptively simple platformer is a masterclass in trickery, constantly changing the rules and keeping you on your toes. But don't be intimidated! With a little patience (and maybe a stress ball), you can conquer its devilish design. https://leveldevilfull.com Gameplay: Expect the Unexpected At its core, Level Devil is a 2D platformer. You control a little pixelated character tasked with reaching the exit door in each level. Sounds easy, right? Wrong. The beauty (and the frustration) lies in the unpredictable nature of the environment. Platforms crumble beneath your feet, spikes appear out of nowhere, and the ground itself can vanish unexpectedly. Each level introduces new challenges, forcing you to adapt your strategy on the fly. You'll encounter moving platforms, disappearing blocks, and even gravity-defying puzzles. The real kicker? The layout of the levels often changes on each attempt, meaning memorization alone won't cut it. You need to be quick-witted and reactive. The charm of Level Devil is its lack of hand-holding. There are no tutorials, no hints, and no mercy. You're thrown straight into the deep end, forced to learn from your mistakes (and trust me, there will be plenty). That feeling of finally overcoming a particularly difficult section is incredibly rewarding. It's a game that demands your full attention and rewards persistence. Tips for Taming the Devil While Level Devil thrives on its unpredictability, here are a few tips to help you navigate its treacherous landscape: • Patience is Key: This game is designed to test your limits. Don't get discouraged by frequent deaths. Treat each attempt as a learning experience. • Observe Carefully: Before making a move, take a moment to scan the environment. Look for subtle cues that might indicate impending danger. • Embrace Failure: You will die. A lot. Embrace it as part of the learning process. Each death provides valuable insight into the level's design. • Don't Overthink It: Sometimes, the solution is simpler than you think. Avoid overcomplicating your approach. • Take Breaks: If you find yourself getting too frustrated, step away from the game for a while. Come back with a fresh perspective. • Listen to the Sound: The game’s audio cues often hint at upcoming dangers. Pay close attention! Level Devil utilizes sound design to enhance the experience (and sometimes, to cleverly mislead you!). Conclusion: A Test of Skill and Sanity Level Devil isn't for the faint of heart. It's a challenging and often frustrating experience. However, it's also incredibly rewarding. The constant surprises, the need for quick thinking, and the sheer satisfaction of overcoming its devilish design make it a truly unique and memorable game. If you're looking for a platformer that will push you to your limits and leave you feeling accomplished, then Level Devil is definitely worth a try. Just be prepared to rage quit... and then come back for more.

1 day, 12 hours

Re: [PATCH] fix: dma-buf: unwrap_merge_complex: dma_fence_get_stub reference leaked on all paths

by Christian König

On 6/26/26 14:28, WenTao Liang wrote: > dma_fence_get_stub() acquires an extra reference on the global stub > fence, but this reference is never released on any execution path. The > stub fence is filtered out inside dma_fence_unwrap_merge (already > signaled), so the extra reference is never consumed. Both success and > error paths fail to call dma_fence_put on the stub. > > Cc: stable(a)vger.kernel.org > Fixes: 245a4a7b531c ("dma-buf: generalize dma_fence unwrap & merging v3") Just drop that, the stub fence is a global dummy and leaking reference to it is harmless. But just in case somebody uses this code as blueprint for this own implementation we should probably clean it up. > Signed-off-by: WenTao Liang <vulab(a)iscas.ac.cn> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/st-dma-fence-unwrap.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c > index 72ca632e3981..b9ed85570211 100644 > --- a/drivers/dma-buf/st-dma-fence-unwrap.c > +++ b/drivers/dma-buf/st-dma-fence-unwrap.c > @@ -483,7 +483,7 @@ static int unwrap_merge_order(void *arg) > > static int unwrap_merge_complex(void *arg) > { > - struct dma_fence *fence, *f1, *f2, *f3, *f4, *f5; > + struct dma_fence *fence, *f1, *f2, *f3, *f4, *f5, *stub; > struct dma_fence_unwrap iter; > int err = -ENOMEM; > > @@ -508,10 +508,11 @@ static int unwrap_merge_complex(void *arg) > if (!f4) > goto error_put_f3; > > + stub = dma_fence_get_stub(); > /* Signaled fences should be filtered, the two arrays merged. */ > - f5 = dma_fence_unwrap_merge(f3, f4, dma_fence_get_stub()); > + f5 = dma_fence_unwrap_merge(f3, f4, stub); > if (!f5) > - goto error_put_f4; > + goto error_put_stub; > > err = 0; > dma_fence_unwrap_for_each(fence, &iter, f5) { > @@ -532,8 +533,10 @@ static int unwrap_merge_complex(void *arg) > err = -EINVAL; > } > > + dma_fence_put(stub); > dma_fence_put(f5); > -error_put_f4: > +error_put_stub: > + dma_fence_put(stub); > dma_fence_put(f4); > error_put_f3: > dma_fence_put(f3);

2 days, 8 hours

Re: [PATCH] fix: dma-buf: unwrap_merge_order: success path leaks chain and array fence references

by Christian König

On 6/26/26 14:21, WenTao Liang wrote: > The success path only releases a2 via dma_fence_put but does not release > a1, c1, or c2. The dma_fence_get calls at lines 440 and 445 were intended > to pass references to mock_chain, but mock_chain already acquires its own > references internally, making these extra gets surplus and permanently > leaked. > > Cc: stable(a)vger.kernel.org > Fixes: b1cce631e61f ("dma-buf: add selftest for fence order after merge") Please drop that, this is a minor issue in a unit test and not anything which needs backporting. > Signed-off-by: WenTao Liang <vulab(a)iscas.ac.cn> > --- > drivers/dma-buf/st-dma-fence-unwrap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c > index 9c74195f47fd..72ca632e3981 100644 > --- a/drivers/dma-buf/st-dma-fence-unwrap.c > +++ b/drivers/dma-buf/st-dma-fence-unwrap.c > @@ -472,6 +472,8 @@ static int unwrap_merge_order(void *arg) > } > > dma_fence_put(a2); > + dma_fence_put(c2); > + dma_fence_put(a1); That looks correct to me, but the error handler below is incorrect as well. When c2 allocation fails we also need to release c1. Regards, Christian. > return err; > > error_put_a1:

2 days, 8 hours

Re: [PATCH] fix: dma-buf: fence_chains_init: error unwind path leaks enable_sw_signaling reference

by Christian König

On 6/26/26 14:18, WenTao Liang wrote: > dma_fence_enable_sw_signaling acquires an extra reference on each chain > fence. The error unwind loop calls dma_fence_put only once per > chain/fence without first signaling the fence to trigger the callback > that releases the signaling reference. This prevents the chain fence kref > from reaching 0, permanently leaking the chain and its contained fence. > > Cc: stable(a)vger.kernel.org > Fixes: dc2f7e67a28a ("dma-buf: Exercise dma-fence-chain under selftests") Please drop that, this is a minor issue in a unit test and not anything which needs backporting. > Signed-off-by: WenTao Liang <vulab(a)iscas.ac.cn> > --- > drivers/dma-buf/st-dma-fence-chain.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/st-dma-fence-chain.c b/drivers/dma-buf/st-dma-fence-chain.c > index 821023dd34df..7dc18e294387 100644 > --- a/drivers/dma-buf/st-dma-fence-chain.c > +++ b/drivers/dma-buf/st-dma-fence-chain.c > @@ -152,7 +152,10 @@ static int fence_chains_init(struct fence_chains *fc, unsigned int count, > > unwind: > for (i = 0; i < count; i++) { > - dma_fence_put(fc->fences[i]); > + if (fc->fences[i]) { > + dma_fence_signal(fc->fences[i]); > + dma_fence_put(fc->fences[i]); > + } The usual text book idiom for such cleanup cases is: while (i--) { dma_fence_signal(fc->fences[i]); dma_fence_put(fc->chains[i]); } Additional to that we need a different error handling target for the case that the mock_chain() allocation fails (or just do another dma_fence_put there). Regards, Christian. > dma_fence_put(fc->chains[i]); > } > kvfree(fc->fences);

2 days, 8 hours

[PATCH] dma-buf: udmabuf: avoid list copy size overflow

by Yousef Alhouseen

UDMABUF_CREATE_LIST copies an array whose element count comes from userspace. The count is compared against list_limit, but list_limit is a signed module parameter while the count is u32. If the limit is raised too far or made negative, that comparison no longer bounds the count to a range where sizeof(*list) * count fits in the u32 temporary used for the copy length. A wrapped copy length lets memdup_user() copy fewer entries than udmabuf_create() subsequently walks, leading to out-of-bounds reads from the copied list. Take a positive snapshot of the module limit and use memdup_array_user() so the multiplication is checked before copying. Signed-off-by: Yousef Alhouseen <alhouseenyousef(a)gmail.com> --- drivers/dma-buf/udmabuf.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index bced421c0..b4078ec84 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -469,14 +469,15 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - u32 lsize; + int limit; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; - if (head.count > list_limit) + limit = READ_ONCE(list_limit); + if (!head.count || limit <= 0 || head.count > limit) return -EINVAL; - lsize = sizeof(struct udmabuf_create_item) * head.count; - list = memdup_user((void __user *)(arg + sizeof(head)), lsize); + list = memdup_array_user((void __user *)(arg + sizeof(head)), + head.count, sizeof(*list)); if (IS_ERR(list)) return PTR_ERR(list); -- 2.54.0

2 days, 9 hours

[PATCH] dma-buf: dma-fence: Fix potential NULL pointer dereference

by Philipp Stanner

The commit mentioned in the fixes tag below introduced a mechanism through which fence producers can fully decouple from fence consumers. This, desirable, mechanism is based on the fence's signaled-bit as the "decoupling point". A sophisticated interaction between RCU and atomic instructions attempts to ensure that fence consumers can still interact with fence producers through the dma_fence_ops, callback pointers into the producer. This is the desired behavior: to check for decoupling, the signaled-bit is first checked. If it's not yet signaled, RCU ensures that the ops pointer cannot yet be NULL. Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit, and then sets the ops pointer to NULL. Readers first load the ops pointer, and then check through the signaled-bit whether the pointer can legally be accessed. These set and load operations could occur out of order on weakly ordered platforms. Hence, we need to enforce strict ordering all the time. Add the appropriate memory barriers. Cc: stable(a)vger.kernel.org Fixes: f4cc3ab824d6 ("dma-buf: protected fence ops by RCU v8") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- Tested with dmabuf and drm_sched unit tests. Memory barriers are notoriously difficult, so I would appreciate if some of the more experienced folks can check this. Notably, I am not sure whether the smp_wmb() is necessary. The documentation for test_and_set_bit() makes the mysterious statement "This is an atomic fully-ordered operation (implied full memory barrier)", but the kcsan_mb() seems to be some sort of debugging barrier, and in any case the docu doesn't make it obvious to me whether that "full barrier" comes before or after the bit setting takes place. Moreover, in my opinion we should order dma_fence_is_signaled(), too – but if we agree to merge Christian's new series [1] that need should disappear. [1] https://lore.kernel.org/dri-devel/20260624122917.2483-1-christian.koenig@am… --- drivers/dma-buf/dma-fence.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index c7ea1e75d38a..2e80b01499de 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -363,6 +363,18 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, &fence->flags))) return; + /* + * Fully order setting of the bit above with setting of the ops pointer + * to NULL below, so that all parties can use the signaled flag to + * detect that the fence decoupled from its ops in a safe manner. + * + * The counter parts of this barrier are in dma_fence_timeline_name() + * and dma_fence_driver_name(). All other future parties that rely on + * the signaled flag for valid access to the ops pointer will need a + * memory barrier. + */ + smp_wmb(); + trace_dma_fence_signaled(fence); /* @@ -1170,6 +1182,12 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence) /* RCU protection is required for safe access to returned string */ ops = rcu_dereference(fence->ops); + /* + * Fully order the dereference above with the flag check. Otherwise, + * ops could be dereferenced as a NULL pointer. The barrier's + * counterpart is in dma_fence_signal_timestamp_locked(). + */ + smp_rmb(); if (!dma_fence_test_signaled_flag(fence)) return (const char __rcu *)ops->get_driver_name(fence); else @@ -1203,6 +1221,12 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) /* RCU protection is required for safe access to returned string */ ops = rcu_dereference(fence->ops); + /* + * Fully order the dereference above with the flag check. Otherwise, + * ops could be dereferenced as a NULL pointer. The barrier's + * counterpart is in dma_fence_signal_timestamp_locked(). + */ + smp_rmb(); if (!dma_fence_test_signaled_flag(fence)) return (const char __rcu *)ops->get_driver_name(fence); else base-commit: cdeb2ccd993ed8647adbbda2c3b103aa717fd6f7 -- 2.54.0

2 days, 9 hours

[PATCH v2] drm/sched: Protect entity->last_scheduled with spinlock

by Philipp Stanner

The entity->last_scheduled field has always been set and read with special RCU functions in addition to memory barriers. There is no obvious reason for that, since the entity lock is available and taken at all places that evaluate the last_scheduled field. The only exception is drm_sched_entity_error(), which is not performance critical in any way. Improve robustness, readability and maintainability by replacing RCU and barriers with the lock. As a preparational step, while at it, also guard spsc_queue_pop() with the lock, since spsc_queue is deprecated and supposed to be replaced with a locked list. Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- Changes since v1: - Add a helper variable to drop the last_scheduled reference without the entity lock being held; just to be more robust. - Write additional comment to detail the WRITE_ONCE(). --- drivers/gpu/drm/scheduler/sched_entity.c | 58 +++++++++++++----------- include/drm/gpu_scheduler.h | 9 ++-- 2 files changed, 35 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index c51101ec70c1..12fd695c6d46 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -135,7 +135,6 @@ int drm_sched_entity_init(struct drm_sched_entity *entity, entity->num_sched_list = num_sched_list; entity->sched_list = num_sched_list > 1 ? sched_list : NULL; entity->rq = &sched_list[0]->rq; - RCU_INIT_POINTER(entity->last_scheduled, NULL); RB_CLEAR_NODE(&entity->rb_tree_node); init_completion(&entity->entity_idle); @@ -201,10 +200,10 @@ int drm_sched_entity_error(struct drm_sched_entity *entity) struct dma_fence *fence; int r; - rcu_read_lock(); - fence = rcu_dereference(entity->last_scheduled); + spin_lock(&entity->lock); + fence = entity->last_scheduled; r = fence ? fence->error : 0; - rcu_read_unlock(); + spin_unlock(&entity->lock); return r; } @@ -288,8 +287,10 @@ void drm_sched_entity_kill(struct drm_sched_entity *entity) wait_for_completion(&entity->entity_idle); /* The entity is guaranteed to not be used by the scheduler */ - prev = rcu_dereference_check(entity->last_scheduled, true); + spin_lock(&entity->lock); + prev = entity->last_scheduled; dma_fence_get(prev); + spin_unlock(&entity->lock); while ((job = drm_sched_entity_queue_pop(entity))) { struct drm_sched_fence *s_fence = job->s_fence; @@ -381,8 +382,12 @@ void drm_sched_entity_fini(struct drm_sched_entity *entity) entity->dependency = NULL; } - dma_fence_put(rcu_dereference_check(entity->last_scheduled, true)); - RCU_INIT_POINTER(entity->last_scheduled, NULL); + dma_fence_put(entity->last_scheduled); + /* + * Normally all users should be gone now, but since drm_sched has + * experienced many layering violations in the past, better be safe. + */ + WRITE_ONCE(entity->last_scheduled, NULL); drm_sched_entity_stats_put(entity->stats); } EXPORT_SYMBOL(drm_sched_entity_fini); @@ -507,6 +512,10 @@ drm_sched_job_dependency(struct drm_sched_job *job, struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity) { + /* Helper to avoid dropping the reference while the entity lock is held, + * just to have some more robustness. + */ + struct dma_fence *prev_last_scheduled; struct drm_sched_job *sched_job; sched_job = drm_sched_entity_queue_peek(entity); @@ -523,19 +532,20 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity) if (entity->guilty && atomic_read(entity->guilty)) dma_fence_set_error(&sched_job->s_fence->finished, -ECANCELED); - dma_fence_put(rcu_dereference_check(entity->last_scheduled, true)); - rcu_assign_pointer(entity->last_scheduled, - dma_fence_get(&sched_job->s_fence->finished)); + spin_lock(&entity->lock); + prev_last_scheduled = entity->last_scheduled; + entity->last_scheduled = dma_fence_get(&sched_job->s_fence->finished); - /* - * If the queue is empty we allow drm_sched_entity_select_rq() to - * locklessly access ->last_scheduled. This only works if we set the - * pointer before we dequeue and if we a write barrier here. + /* A recent rework required taking the spinlock above. Since spsc_queue + * is scheduled for removal as per the DRM-TODO-list, we access it here + * locked already to prepare for that cleanup. + * + * TODO: Fully replace spsc_queue with a locked (h)list. */ - smp_wmb(); - spsc_queue_pop(&entity->job_queue); + spin_unlock(&entity->lock); + dma_fence_put(prev_last_scheduled); drm_sched_rq_pop_entity(entity); /* Jobs and entities might have different lifecycles. Since we're @@ -561,21 +571,15 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) if (spsc_queue_count(&entity->job_queue)) return; - /* - * Only when the queue is empty are we guaranteed that - * drm_sched_run_job_work() cannot change entity->last_scheduled. To - * enforce ordering we need a read barrier here. See - * drm_sched_entity_pop_job() for the other side. - */ - smp_rmb(); - - fence = rcu_dereference_check(entity->last_scheduled, true); + spin_lock(&entity->lock); + fence = entity->last_scheduled; /* stay on the same engine if the previous job hasn't finished */ - if (fence && !dma_fence_is_signaled(fence)) + if (fence && !dma_fence_is_signaled(fence)) { + spin_unlock(&entity->lock); return; + } - spin_lock(&entity->lock); sched = drm_sched_pick_best(entity->sched_list, entity->num_sched_list); rq = sched ? &sched->rq : NULL; if (rq != entity->rq) { diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h index d61c19e78182..176ff1f936cd 100644 --- a/include/drm/gpu_scheduler.h +++ b/include/drm/gpu_scheduler.h @@ -100,7 +100,8 @@ struct drm_sched_entity { * @lock: * * Lock protecting the run-queue (@rq) to which this entity belongs, - * @priority and the list of schedulers (@sched_list, @num_sched_list). + * @priority, @last_scheduled and the list of schedulers (@sched_list, + * @num_sched_list). */ spinlock_t lock; @@ -202,11 +203,9 @@ struct drm_sched_entity { /** * @last_scheduled: * - * Points to the finished fence of the last scheduled job. Only written - * by drm_sched_entity_pop_job(). Can be accessed locklessly from - * drm_sched_job_arm() if the queue is empty. + * Points to the finished fence of the last scheduled job. */ - struct dma_fence __rcu *last_scheduled; + struct dma_fence *last_scheduled; /** * @last_user: last group leader pushing a job into the entity. -- 2.54.0

2 days, 13 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig