Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

17 participants
7029 discussions

[PATCH] rust: device_id: rename IdTable::as_ptr to as_raw_id_table()

by Alice Ryhl

The current name of `as_ptr` is very generic, and if you attempt to invoke `foo.as_ptr()` on a type for which this method is missing, then an error along these lines will be printed: error[E0599]: no method named `as_ptr` found for reference `&DmaBuf` in the current scope --> linux/rust/kernel/dma_buf/buf.rs:54:38 | 54 | ptr::eq(self.as_ptr(), other.as_ptr()) | ^^^^^^ method not found in `&DmaBuf` | = help: items from traits can only be used if the trait is implemented and in scope note: `device_id::IdTable` defines an item `as_ptr`, perhaps you need to implement it --> linux/rust/kernel/device_id.rs:165:1 | 165 | pub trait IdTable<T: RawDeviceId, U> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Suggesting the IdTable trait when an as_ptr() method is missing is not useful. Renaming it to `as_raw_id_table` makes the method name unique to this trait and avoids these bad suggestions. Assisted-by: Antigravity:Gemini Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- rust/kernel/auxiliary.rs | 2 +- rust/kernel/device_id.rs | 4 ++-- rust/kernel/driver.rs | 8 +++++--- rust/kernel/i2c.rs | 8 ++++---- rust/kernel/pci.rs | 2 +- rust/kernel/platform.rs | 4 ++-- rust/kernel/usb.rs | 2 +- 7 files changed, 16 insertions(+), 14 deletions(-) diff --git a/rust/kernel/auxiliary.rs b/rust/kernel/auxiliary.rs index c42928d5a239..fd6940577e0d 100644 --- a/rust/kernel/auxiliary.rs +++ b/rust/kernel/auxiliary.rs @@ -64,7 +64,7 @@ unsafe fn register( (*adrv.get()).name = name.as_char_ptr(); (*adrv.get()).probe = Some(Self::probe_callback); (*adrv.get()).remove = Some(Self::remove_callback); - (*adrv.get()).id_table = T::ID_TABLE.as_ptr(); + (*adrv.get()).id_table = T::ID_TABLE.as_raw_id_table(); } // SAFETY: `adrv` is guaranteed to be a valid `DriverType`. diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs index 8e9721446014..821da02540b1 100644 --- a/rust/kernel/device_id.rs +++ b/rust/kernel/device_id.rs @@ -164,7 +164,7 @@ impl<T: RawDeviceId + RawDeviceIdIndex, U, const N: usize> IdArray<T, U, N> { /// `IdArray` doesn't matter. pub trait IdTable<T: RawDeviceId, U> { /// Obtain the pointer to the ID table. - fn as_ptr(&self) -> *const T::RawType; + fn as_raw_id_table(&self) -> *const T::RawType; /// Obtain the pointer to the bus specific device ID from an index. fn id(&self, index: usize) -> &T::RawType; @@ -174,7 +174,7 @@ pub trait IdTable<T: RawDeviceId, U> { } impl<T: RawDeviceId, U, const N: usize> IdTable<T, U> for IdArray<T, U, N> { - fn as_ptr(&self) -> *const T::RawType { + fn as_raw_id_table(&self) -> *const T::RawType { // This cannot be `self.ids.as_ptr()`, as the return pointer must have correct provenance // to access the sentinel. core::ptr::from_ref(self).cast() diff --git a/rust/kernel/driver.rs b/rust/kernel/driver.rs index bf5ba0d27553..69068adcbdae 100644 --- a/rust/kernel/driver.rs +++ b/rust/kernel/driver.rs @@ -341,7 +341,8 @@ fn acpi_id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> { // SAFETY: // - `table` has static lifetime, hence it's valid for read, // - `dev` is guaranteed to be valid while it's alive, and so is `dev.as_raw()`. - let raw_id = unsafe { bindings::acpi_match_device(table.as_ptr(), dev.as_raw()) }; + let raw_id = + unsafe { bindings::acpi_match_device(table.as_raw_id_table(), dev.as_raw()) }; if raw_id.is_null() { None @@ -374,7 +375,8 @@ fn of_id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> { // SAFETY: // - `table` has static lifetime, hence it's valid for read, // - `dev` is guaranteed to be valid while it's alive, and so is `dev.as_raw()`. - let raw_id = unsafe { bindings::of_match_device(table.as_ptr(), dev.as_raw()) }; + let raw_id = + unsafe { bindings::of_match_device(table.as_raw_id_table(), dev.as_raw()) }; if !raw_id.is_null() { // SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `struct of_device_id` @@ -404,7 +406,7 @@ fn of_id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> { // - `adev` is a valid pointer to `acpi_device` or is null. It is guaranteed to be // valid as long as `dev` is alive. // - `table` has static lifetime, hence it's valid for read. - if unsafe { acpi_of_match_device(adev, table.as_ptr(), &raw mut raw_id) } { + if unsafe { acpi_of_match_device(adev, table.as_raw_id_table(), &raw mut raw_id) } { // SAFETY: // - the function returns true, therefore `raw_id` has been set to a pointer to a // valid `of_device_id`. diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs index 624b971ca8b0..920794d4089d 100644 --- a/rust/kernel/i2c.rs +++ b/rust/kernel/i2c.rs @@ -116,17 +116,17 @@ unsafe fn register( ); let i2c_table = match T::I2C_ID_TABLE { - Some(table) => table.as_ptr(), + Some(table) => table.as_raw_id_table(), None => core::ptr::null(), }; let of_table = match T::OF_ID_TABLE { - Some(table) => table.as_ptr(), + Some(table) => table.as_raw_id_table(), None => core::ptr::null(), }; let acpi_table = match T::ACPI_ID_TABLE { - Some(table) => table.as_ptr(), + Some(table) => table.as_raw_id_table(), None => core::ptr::null(), }; @@ -208,7 +208,7 @@ fn i2c_id_info(dev: &I2cClient) -> Option<&'static <Self as driver::Adapter>::Id // SAFETY: // - `table` has static lifetime, hence it's valid for reads // - `dev` is guaranteed to be valid while it's alive, and so is `dev.as_raw()`. - let raw_id = unsafe { bindings::i2c_match_id(table.as_ptr(), dev.as_raw()) }; + let raw_id = unsafe { bindings::i2c_match_id(table.as_raw_id_table(), dev.as_raw()) }; if raw_id.is_null() { return None; diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs index 5071cae6543f..311b4716800b 100644 --- a/rust/kernel/pci.rs +++ b/rust/kernel/pci.rs @@ -81,7 +81,7 @@ unsafe fn register( (*pdrv.get()).name = name.as_char_ptr(); (*pdrv.get()).probe = Some(Self::probe_callback); (*pdrv.get()).remove = Some(Self::remove_callback); - (*pdrv.get()).id_table = T::ID_TABLE.as_ptr(); + (*pdrv.get()).id_table = T::ID_TABLE.as_raw_id_table(); } // SAFETY: `pdrv` is guaranteed to be a valid `DriverType`. diff --git a/rust/kernel/platform.rs b/rust/kernel/platform.rs index 9b362e0495d3..f6a48f7750da 100644 --- a/rust/kernel/platform.rs +++ b/rust/kernel/platform.rs @@ -63,12 +63,12 @@ unsafe fn register( module: &'static ThisModule, ) -> Result { let of_table = match T::OF_ID_TABLE { - Some(table) => table.as_ptr(), + Some(table) => table.as_raw_id_table(), None => core::ptr::null(), }; let acpi_table = match T::ACPI_ID_TABLE { - Some(table) => table.as_ptr(), + Some(table) => table.as_raw_id_table(), None => core::ptr::null(), }; diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs index 7aff0c82d0af..14e0602c3f03 100644 --- a/rust/kernel/usb.rs +++ b/rust/kernel/usb.rs @@ -58,7 +58,7 @@ unsafe fn register( (*udrv.get()).name = name.as_char_ptr(); (*udrv.get()).probe = Some(Self::probe_callback); (*udrv.get()).disconnect = Some(Self::disconnect_callback); - (*udrv.get()).id_table = T::ID_TABLE.as_ptr(); + (*udrv.get()).id_table = T::ID_TABLE.as_raw_id_table(); } // SAFETY: `udrv` is guaranteed to be a valid `DriverType`. --- base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482 change-id: 20260702-idtable-rename-asptr-3ea4d9e38287 Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

1 month, 1 week

[PATCH] dma_buf: change unsigned int and int types into size_t

by Shahyan Soltani

The num_fences, count, i, and j variables in dma_fence_dedup_array() and __dma_fence_unwrap_merge() have inconsistent integer types, mixing both unsigned int and int. Use type size_t consistently for these instead, and update the return type of dma_fence_dedup_array() accordingly. Signed-off-by: Shahyan Soltani <shahyan.soltani(a)amd.com> Suggested-by: Philipp Stanner <phasta(a)mailbox.org> --- The rest of the subsystems (dma_resv_reserve_fences, drm_exec, drm_gpuvm, xe, nouveau, etc) uses "unsigned int" for num_fences, for example the amdgpu caller in amdgpu_userq_fence.c. drivers/dma-buf/dma-fence-unwrap.c | 8 ++++---- include/linux/dma-fence-unwrap.h | 6 ++++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fence-unwrap.c index 53bb40e70b27..65e87d263c3a 100644 --- a/drivers/dma-buf/dma-fence-unwrap.c +++ b/drivers/dma-buf/dma-fence-unwrap.c @@ -93,9 +93,9 @@ static int fence_cmp(const void *_a, const void *_b) * * Return: Number of unique fences remaining in the array. */ -int dma_fence_dedup_array(struct dma_fence **fences, int num_fences) +size_t dma_fence_dedup_array(struct dma_fence **fences, size_t num_fences) { - int i, j; + size_t i, j; sort(fences, num_fences, sizeof(*fences), fence_cmp, NULL); @@ -115,14 +115,14 @@ int dma_fence_dedup_array(struct dma_fence **fences, int num_fences) EXPORT_SYMBOL_GPL(dma_fence_dedup_array); /* Implementation for the dma_fence_merge() marco, don't use directly */ -struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, +struct dma_fence *__dma_fence_unwrap_merge(size_t num_fences, struct dma_fence **fences, struct dma_fence_unwrap *iter) { struct dma_fence *tmp, *unsignaled = NULL, **array; struct dma_fence_array *result; ktime_t timestamp; - int i, count; + size_t i, count; count = 0; timestamp = ns_to_ktime(0); diff --git a/include/linux/dma-fence-unwrap.h b/include/linux/dma-fence-unwrap.h index 62df222fe0f1..7bfacdf79de2 100644 --- a/include/linux/dma-fence-unwrap.h +++ b/include/linux/dma-fence-unwrap.h @@ -8,6 +8,8 @@ #ifndef __LINUX_DMA_FENCE_UNWRAP_H #define __LINUX_DMA_FENCE_UNWRAP_H +#include <linux/types.h> + struct dma_fence; /** @@ -48,11 +50,11 @@ struct dma_fence *dma_fence_unwrap_next(struct dma_fence_unwrap *cursor); for (fence = dma_fence_unwrap_first(head, cursor); fence; \ fence = dma_fence_unwrap_next(cursor)) -struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, +struct dma_fence *__dma_fence_unwrap_merge(size_t num_fences, struct dma_fence **fences, struct dma_fence_unwrap *cursors); -int dma_fence_dedup_array(struct dma_fence **array, int num_fences); +size_t dma_fence_dedup_array(struct dma_fence **array, size_t num_fences); /** * dma_fence_unwrap_merge - unwrap and merge fences -- 2.54.0

1 month, 1 week

dma_fence cleanup/rework

by Christian König

In a recent discussion with Philip and Danilo the question came up what was already tried and never finished to cleanup the dma_fence framework. So here are the different ideas I came with but never fully finished, with the patches itself modernized and rebased on top of drm-misc-next. The main goal of those changes is to make it easier to implement dma_fence backends and don't enforce unnecessary constrains on implementations. As first step the locking around the dma_fence_ops.signaled callback is made consistent by removing the dma_fence_is_signaled_locked() function. This was mostly used by backends itself, but if polling the HW is desired the backends can call their own functions for this directly without going through the dma-fence layer. XE actually seems to be the only driver which make use of that for a bit more handling. For all other cases testing the signaled flag should be enough. Then forcefully calling dma_fence_signaled() is removed from the dma-fence layer and moved into the backend implementations. This allows the backend implementations to cleanup after they have signaled the fence. Such cleanup can include removing now signaled fences from lists, dropping references, starting work etc.... Especially nouveau seems to have some really messy workaround because of that involving the DMA_FENCE_FLAG_USER_BITS and installing callbacks because the reference to the context couldn't be dropped directly after signaling. This can now be cleaned up as far as I can see. In the long term this should also allow reworking the error handling, e.g. removing dma_fence_set_error() and instead giving the error as mandatory parameter to dma_fence_signal(). Then the last piece is dropping calling enable_signaling callback with the dma_fence lock held. This makes it possible for backends to acquire locks which are semantically ordered outside of the dma_fence lock. This is necessary to allows using the dma_fence inline lock in more cases, previously backends used some common external lock for their dma_fences to for example make it possible remove fences from linked lists. Please comment and review, Christian.

1 month, 1 week

[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

1 month, 1 week

Wordle Unlimited Game Guide for Endless Word Puzzle Fun

by thoughtless.stork.wxrl＠hidingmail.net

Introduction to Wordle Unlimited Experience Wordle Unlimited is an online word puzzle game that expands the classic word guessing concept into an endless format. Instead of waiting for a daily puzzle, players can enjoy continuous gameplay with unlimited attempts and unlimited rounds. This format makes it appealing for players who enjoy vocabulary challenges, logic thinking, and casual gaming without time restrictions. https://wordleunlimitedgame.org/ The main objective remains simple. Players try to guess a hidden five letter word within a limited number of attempts. After each guess, feedback is provided through color indicators that help narrow down the correct answer. This simple design combined with endless replay value makes Wordle Unlimited highly engaging for both beginners and experienced puzzle players. How Wordle Unlimited Gameplay Works Wordle Unlimited follows a straightforward set of rules that are easy to understand. Each round begins with a hidden word that players must discover. Players enter a five letter word as a guess, and the system responds with color coded hints. Green indicates a correct letter in the correct position. Yellow indicates a correct letter in the wrong position. Gray indicates a letter that is not part of the hidden word. These feedback signals guide players toward the correct answer step by step. Unlike traditional daily word puzzles, Wordle Unlimited allows continuous play without waiting periods. Players can restart instantly after finishing a round, making it suitable for practice, entertainment, or improving vocabulary skills. This unlimited structure also allows experimentation with different guessing strategies. Key Features of Wordle Unlimited One of the most important features of Wordle Unlimited is unlimited gameplay. Players are not restricted to a single puzzle per day, which increases engagement and learning opportunities. This feature is especially useful for users who enjoy repetitive practice or competitive improvement. Another key feature is accessibility. The game runs directly in a web browser, meaning no installation is required. It works on desktop computers, tablets, and mobile devices, making it convenient for users in different environments. Wordle Unlimited also maintains a simple interface. There are no complicated menus or distractions. The focus remains entirely on word solving. This minimal design helps players concentrate and improves the overall puzzle solving experience. Additionally, the game supports learning and vocabulary development. Players are exposed to different word patterns and letter combinations, which can help improve language skills over time. Effective Strategies for Winning Wordle Unlimited A strong strategy in Wordle Unlimited begins with choosing a good starting word. Many players select words that contain common vowels and frequently used consonants. This approach increases the chance of identifying correct letters early in the game. Another effective strategy is to avoid repeating incorrect letters. Once a letter is marked as gray, it is usually best to exclude it from future guesses. This helps narrow down possibilities more efficiently. Players also benefit from analyzing letter placement carefully. When a letter is marked yellow, it should be repositioned in the next guess. This process of elimination is essential for solving puzzles in fewer attempts. It is also helpful to think in word patterns rather than random guesses. English words often follow predictable structures, and recognizing these patterns can significantly improve success rates. Finally, patience plays an important role. Rushing guesses can lead to repeated mistakes. Taking time to evaluate feedback from each attempt leads to more accurate solutions. Benefits of Playing Wordle Unlimited Regularly Playing Wordle Unlimited regularly offers several cognitive benefits. One major advantage is vocabulary improvement. Players are exposed to a wide range of words, which helps expand language knowledge over time. Another benefit is mental exercise. Word puzzle games stimulate logical thinking, pattern recognition, and memory recall. These skills are useful in both academic and professional contexts. Wordle Unlimited also provides stress relief for many players. The simple structure and short gameplay sessions make it a relaxing activity that can be enjoyed during breaks or free time. In addition, the unlimited nature of the game allows continuous practice. This is especially beneficial for players who want to improve performance or challenge themselves with faster solving times. Social interaction is another indirect benefit. Many players enjoy sharing results or competing with friends, which adds a fun and competitive element to the experience. Why Wordle Unlimited Remains Popular The popularity of Wordle Unlimited comes from its balance of simplicity and challenge. It does not require advanced gaming skills, yet it still offers a satisfying mental challenge. This combination makes it accessible to a wide audience. The unlimited format also contributes to its popularity. Players are no longer restricted by daily limits, which means they can engage with the game whenever they want. This flexibility aligns well with modern digital habits. Another reason for its popularity is its quick gameplay loop. Each round can be completed in a short time, making it ideal for casual entertainment. Despite its simplicity, the game continues to offer new challenges with every hidden word. Conclusion on Wordle Unlimited Experience Wordle Unlimited delivers a simple yet highly engaging word puzzle experience that appeals to players of all ages. With unlimited gameplay, easy rules, and strong cognitive benefits, it stands out as an effective and enjoyable word game.

1 month, 1 week

[PATCH] dma-buf/test: add KUnit case for dma_fence_dedup_array() empty input

by Baineng Shou

Add a KUnit case verifying that dma_fence_dedup_array() returns 0, not 1, when called with num_fences == 0. This locks down the contract documented in the kernel-doc and prevents a regression of commit 77a9298741f8 ("dma-fence: Make dma_fence_dedup_array() robust against 0-count input"). Suggested-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> --- drivers/dma-buf/st-dma-fence-unwrap.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c index 4e7ee25372ba..72dea6091d58 100644 --- a/drivers/dma-buf/st-dma-fence-unwrap.c +++ b/drivers/dma-buf/st-dma-fence-unwrap.c @@ -370,6 +370,15 @@ static void test_unwrap_merge_seqno(struct kunit *test) dma_fence_put(f1); } +static void test_dedup_empty(struct kunit *test) +{ + struct dma_fence *fence[1] = { NULL }; + int ret; + + ret = dma_fence_dedup_array(fence, 0); + KUNIT_EXPECT_EQ(test, ret, 0); +} + static void test_unwrap_merge_order(struct kunit *test) { struct dma_fence *fence, *f1, *f2, *a1, *a2, *c1, *c2; @@ -595,6 +604,7 @@ static struct kunit_case dma_fence_unwrap_cases[] = { KUNIT_CASE(test_unwrap_merge_order), KUNIT_CASE(test_unwrap_merge_complex), KUNIT_CASE(test_unwrap_merge_complex_seqno), + KUNIT_CASE(test_dedup_empty), {} }; -- 2.34.1

1 month, 1 week

Bouncing Your Way Through Geometry: What Makes Jump Games So Addictive

by clinical.condor.xuhe＠hidingmail.net

https://geometrydash-pc.com/ Geometry-based jump games have become a phenomenon in casual gaming, and for good reason. There's something deeply satisfying about timing a perfect jump, watching your character soar through geometric obstacles, and finally reaching that "just one more level" feeling at 11 PM on a Tuesday. If you've never experienced this particular brand of digital frustration and joy, let me walk you through what makes these games tick—and why your reflexes might thank you (or curse you) for giving them a try. The Beautiful Simplicity of Jumping Through Shapes At their core, geometry jump games strip gaming down to its essence: move, jump, survive, repeat. Take Geometry Dash as our primary example. The concept sounds almost comically simple—you control a geometric shape (typically a square) and must navigate it through an obstacle course of spikes, platforms, and other hazards, all synchronized to music. That's it. No complex storylines, no resource management, no unnecessary mechanics getting in the way. The genius lies in how this simplicity becomes a foundation for incredible complexity. Early levels ease you in with gentle slopes and straightforward obstacles. But as you progress, the game introduces new mechanics: your shape might transform into a ship that flies and falls with different physics, or a cube that can jump at precise intervals, or a ball that rolls with its own momentum. Each transformation changes how you perceive and interact with the space around you, keeping the experience fresh despite the unchanging core mechanic. What really hooks players is the relationship between gameplay and sound design. In these games, your jumps, movements, and even collisions sync with the background music. This isn't just eye candy—it creates a rhythm that your brain naturally wants to follow. Successfully nailing a sequence of jumps that align with the beat feels almost musical, like you're dancing through geometry rather than simply fighting your way through it. How the Experience Actually Works When you first launch a geometry jump game, you'll notice the visual style leans toward minimalism. Bright colors contrast against dark backgrounds. Obstacles are clearly defined geometric shapes. There's no confusion about what you can and can't touch—a spike is a spike, a platform is a platform. This clarity is crucial because the game demands precision, and it delivers that demand through an uncluttered visual language. The difficulty curve in these games teaches an important lesson about game design. Early levels act as a tutorial without ever pausing to explain things. You learn through doing. You discover that holding the jump button longer makes you jump higher (in certain modes). You realize that some obstacles require split-second timing while others reward patience. The game respects your intelligence enough not to spell everything out, yet supports you enough that progress feels achievable. Progression in these games works differently than traditional level-based structures. Levels often exceed three or four minutes of continuous gameplay. A single mistake near the end sends you back to the beginning. This sounds punishing, and initially it is, but it creates something interesting: players develop the ability to stay focused under pressure. You learn to accept failure as part of the process. That 47th attempt doesn't feel like torture—it feels like you're getting closer. Practical Tips for New Players If you're thinking about diving into a geometry jump experience, here are some things that will make your journey more enjoyable. First, play with sound on (with headphones if possible). The audio design isn't decorative—it's genuinely part of the game. Your brain will start anticipating jumps based on musical cues. Second, accept that you'll fail repeatedly. A lot. This isn't a flaw in game design; it's the entire point. Each failure teaches you something about timing, positioning, or physics. Instead of thinking "I'm bad at this," think "I'm learning." The shift in mindset makes an enormous difference in how frustrating or fun the experience becomes. Third, take breaks when you're stuck. Walk away for 20 minutes, come back fresh, and you'll often breeze through what seemed impossible before. Your muscle memory and spatial reasoning improve even when you're not actively playing—your brain keeps processing those patterns. Finally, don't compare your progress to others immediately. These games feature leaderboards and difficulty ratings that can feel intimidating. Focus on completing the built-in levels first and getting comfortable with the mechanics. Once you're ready, the community has created custom levels at every difficulty level imaginable. The Lasting Appeal What keeps people returning to geometry jump games isn't just the challenge—it's the feeling of growth. You watch your own improvement in real-time. That level that seemed impossible yesterday becomes a warm-up today. Your fingers develop instinctive knowledge of the physics without your brain consciously calculating them. These games also offer something increasingly rare in modern entertainment: they don't demand your attention span be fragmented. They ask for focus, dedication, and patience in exchange for genuine achievement. In a world of endless notifications and distractions, there's something refreshing about a game that simply wants you to jump through some shapes to the beat of good music. Whether you're a casual gamer looking for something satisfying or someone seeking a new challenge, geometry jump games offer an experience that's easy to understand but genuinely difficult to master. And honestly, that's exactly what makes them worth your time.

1 month, 1 week

Geometry Dash Lite: A Rhythm-Based Odyssey in the Palm of Your Hand

by 77nannette＠web-library.net

Ever found yourself yearning for a game that’s easy to pick up but incredibly challenging to master? A game that tests your reflexes, your rhythm, and your patience, all while delivering a surprisingly addictive experience? Look no further than geometry dash lite. This free-to-play mobile sensation, a trimmed-down version of the full Geometry Dash game, offers a fantastic entry point into a world of pulsing electronic music, geometric obstacles, and an almost zen-like focus on timing. Whether you're a seasoned gamer or just looking for a fun way to pass the time, Geometry Dash Lite provides an exhilarating ride. https://geometrylitepc.com/ The Rhythmic Heartbeat: What is Geometry Dash Lite? At its core, Geometry Dash Lite is a rhythm-based platformer. You control a small, customizable icon (usually a square, but you can unlock others) that automatically moves forward through a series of levels. Your sole objective is to navigate these levels, avoiding an onslaught of spikes, sawblades, and other cleverly designed traps, all perfectly synced to an energetic soundtrack. The game's beauty lies in its simplicity: tap to jump. That's it. But within this simple mechanic lies a world of nuanced timing, precise execution, and a surprising amount of strategic thinking. The "Lite" version of the game offers a selection of levels from the full Geometry Dash experience, allowing players to get a taste of what the full game has to offer without any initial commitment. It's a perfect sampler, showcasing the core mechanics, the diverse level design, and the infectious music that defines the series. For those curious to explore further or even play on their PC, you can find more information about Geometry Dash Lite at Geometry Dash Lite Gameplay: A Symphony of Taps and Jumps The gameplay loop of Geometry Dash Lite is incredibly straightforward, yet it offers a satisfying and often frustrating challenge. Your Icon: Your main character is a small geometric shape that continuously moves forward. Its movement speed is constant within a given segment of a level. The Obstacles: Levels are littered with various obstacles, primarily spikes and sawblades, designed to instantly destroy your icon upon contact. The Tap to Jump: Your only control is to tap the screen. A single tap initiates a small jump. Holding down your finger allows for a longer jump. This simple interaction is the key to navigating the complex layouts. Portals and Gravity: As you progress, you'll encounter various portals that change your icon's behavior. These can include: Gravity Portals: These flip your icon's gravity, making it move on the ceiling instead of the floor, or vice versa. Ship Portals: Your icon transforms into a ship, allowing you to fly freely by holding down your finger to ascend and releasing to descend. This introduces a whole new dimension of control. Ball Portals: Your icon becomes a ball, which rolls and can stick to surfaces when you tap, creating unique platforming opportunities. UFO Portals: These transform your icon into a UFO, allowing for a "flappy bird" like tapping mechanic to ascend. Wave Portals: Your icon becomes a wave, moving diagonally up and down with taps, requiring very precise timing. Music Synchronization: Every jump, every obstacle, and every portal change is meticulously synchronized with the background music. This is not just an aesthetic choice; it’s a crucial gameplay element. Learning the rhythm of each level is as important as memorizing its layout. Practice Mode: One of the most player-friendly features is the practice mode. In this mode, you can place checkpoints anywhere in the level, allowing you to repeatedly attempt difficult sections without having to restart from the beginning. This is invaluable for learning and improving. Attempts Counter: A relentless counter at the top of the screen tracks how many attempts it takes you to complete a level. This often fuels a competitive spirit and a desire to achieve fewer attempts. Tips for Conquering the Geometric Gauntlet While Geometry Dash Lite can feel overwhelming at first, a few key strategies can significantly improve your experience and help you conquer even the most daunting levels. 1. Start Slow and Steady: Don't jump into the hardest level immediately. Begin with the introductory levels to get a feel for the controls, the different portal mechanics, and the rhythm. "Stereo Madness" is a classic starting point. 2. Embrace Practice Mode: This cannot be stressed enough. When you hit a wall, switch to practice mode. Break down the level into smaller, manageable segments. Practice each difficult section until you can consistently clear it. 3. Listen to the Music: The music isn't just background noise; it's your guide. Pay close attention to the beats, the drops, and the changes in tempo. Often, the timing of your jumps will align perfectly with the musical cues. 4. Memorization is Key: While reflexes are important, Geometry Dash Lite is also a memory game. As you repeatedly play a level, you'll start to internalize the layout and the sequence of obstacles. 5. Identify Patterns: Many levels feature recurring patterns of obstacles. Once you recognize these patterns, you can apply the same strategy to clear them each time they appear. 6. Don't Get Frustrated (Easily): This game will test your patience. You will die countless times on the same obstacle. Take a break if you feel yourself getting angry. Come back with a fresh perspective. Sometimes, a short break is all it takes to clear a section you were stuck on. 7. Watch Others Play: If you're truly stuck, watching videos of experienced players completing the level can provide valuable insights into optimal timing and strategies. 8. Customize Your Icon: While purely aesthetic, customizing your icon can make the experience feel more personal and enjoyable. Unlock new colors and shapes as you progress. 9. Focus on Small Victories: Don't aim to complete the entire level in one go initially. Celebrate clearing a new section, reaching a further point, or successfully navigating a tricky portal sequence. Conclusion: A Rewarding Test of Skill and Rhythm Geometry Dash Lite is more than just a simple mobile game; it's a testament to the power of straightforward mechanics combined with clever design. It offers a rewarding challenge that, while demanding, never feels truly unfair. The satisfaction of finally completing a difficult level, feeling your fingers dance across the screen in perfect sync with the music, is an experience few other games can replicate. So, if you're looking for a game that will push your reflexes and your rhythm to their limits, all while delivering a surprisingly addictive and fun experience, dive into the world of Geometry Dash Lite. You might just find your next obsession.

1 month, 1 week

kelloliver638@gmail.com

by oliver kell

Assignment help provides students with guidance, resources, and support to complete academic tasks effectively. It improves understanding of subjects, enhances research and writing skills, and helps meet deadlines. Professional assistance can reduce stress, improve grades, and encourage learning by offering clear explanations, structured solutions, and valuable academic insights. https://allassignmenthelper.com/management-assignment-help/

1 month, 1 week

[PATCH v3 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, This series is based on previous RFCs/discussions: Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ The background/rationale is covered in more detail in the RFC cover letters. The TL;DR is: The goal is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) As well as isolation and revocation, another advantage to accessing a BAR through a VMA backed by a DMABUF is that it's straightforward to mmap() the buffer with access attributes, such as write-combining. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE (which isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends). VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. This splits out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first is for a DMABUF VMA fault handler to determine arbitrary-sized PFNs from ranges in DMABUF. Secondly, refactor DMABUF export for use by the existing export feature and add a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke-zap/unrevoke. This makes the "revoke/un-revoke" steps clearer. NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; no mappings or other access can be performed now. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. This commit makes VFIO_PCI_CORE depend on PCI_P2PDMA_CORE (commit 1) to bring in (only) the P2PDMA provider code. vfio/pci: Permanently revoke a DMABUF on request By weight, this is mostly a rename of revoked to an enum, status. There are now 3 states for a buffer, usable and revoked temporary/permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, unchanged, to a common function for use by ..._move() and this new feature. vfio/pci: Add mmap() attributes to DMABUF feature Adds a new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR. After a DMABUF is exported, this feature is used to set a memory attribute that will be used by future mmap()s of the DMABUF fd. It doesn't affect existing maps. The default is UC, and via the feature one can specify CPU access as WC. The attribute is an enum/scalar rather than bitmap/cumulative. The attributes follow a "try-fail" model where a client can request an attribute and either succeed or fail with ENOENT if it's unknown; if future attributes are platform-specific then their support can be probed. (Since it's just UC/WC for now, there is no reservation or numeric structure to the namespace yet, but we could support system/arch-specific values in future by carving out base + arch-specific + IMPDEF ranges.) Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, attribute, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. End === This is based on VFIO next (e.g. at b9285405c5f6). These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/b9285405c5f6...metamev:linux:dev/m… Thanks for reading, Matt ================================================================================ Change log: v3: - Refactor p2pdma.c: split out pcim_p2pdma_provider() into a new p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE. - vfio_pci_dma_buf_find_pfn() cleanups: Rename parameter to priv, remove bad WARN, move unnecessary addition out of inner loop. - vfio_pci_core_mmap_prep_dmabuf() cleanups: Remove uint32_t, remove unnecessary const variable. - Conversion of BAR mmap() to DMABUF: VFIO_PCI_DMABUF depends on VFIO_PCI_CORE. vfio_pci_mmap_huge_fault(): move dev_dbg() outside of lock (argh), remove READ_ONCE(vdev)/move priv->vdev read and improve comment explanation. - On revoke, BAR zap defaults to on if .mmap is overridden by a driver (and implements an opt-out for the hisi_acc_vfio_pci driver, which overrides mmap() with a simple wrapper that ends up using the common DMABUF mmap() rather than custom mappings). - Reworded commit "vfio/pci: Support mmap() of a VFIO DMABUF" message for clarity. Reworded vfio_pci_mmap_huge_fault() comment for accuracy (vdev validity depends on not being revoked). Added comment in mmap() explaining belt-and-braces approach for early detecting a map of a revoked buffer. - Revoke now uses VFIO_DEVICE_FEATURE_DMA_BUF rather than a new ioctl(); instead of the revoke helper taking 'revoked/permanently' bools, it's become vfio_pci_dma_buf_set_status() taking a single status enum. Added a READ_ONCE() for the lockless test of priv->vdev (flags it as intentional, even if it's in practice going to be a single-copy atomic read). - Removed GET on vfio_pci_core_feature_dma_buf_memattr(), removed unnecessary taking of memory_lock, fixed error return values. In particular, removes ENOTSUPP, and uses ENOENT to indicate an unknown attribute enum value was passed to SET. In the discussion here, https://lore.kernel.org/all/20260602131417.41366391@shazbot.org/ we'd agreed on EOPNOTSUPP before I realised that's already used elsewhere. ENOENT uniquely indicates an unknown attribute. v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ - Rebase on VFIO next, picking up Alex's vfio_pci_dma_buf_move()/vfio_pci_dma_buf_cleanup() fixes, and dropping "vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put" - Added "PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE" so that the newly-added vfio-pci hard dependency on the P2PDMA provider instead pulls in the _CORE variant and not the full-fat CONFIG_PCI_P2PDMA. This means that the core of vfio-pci does not need ZONE_DEVICE, but if it's available then enabling P2PDMA in turn enables DMABUF export. Fixes basic VFIO operation on 32b or other platforms without ZONE_DEVICE. - Fixed comment inaccuracy in vfio_pci_dma_buf_revoke() and cleaned up vdev validity test. - vfio_pci_dma_buf_find_pfn(): use PAGE_ALIGN(), better span variable naming, OVF check - Made vm_pgoffs use consistent (keeping the resource index at the top and masking where offset is used). For BAR mmap, use new vma_pgoff_adjust to create the DMABUF with the exact mmap()ed span instead of from the start of the BAR with an invisible portion before the mapping. - Added VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR to set memory attributes, instead of using the export `flags` field. - vfio_pci_ioctl_reset: Moved vfio_pci_zap_revoke_bars() (effectively, vfio_pci_dma_buf_move()) back after D0 transition. Note, if a BAR zap is needed, it's done in this function so now happens after this D0 transition with the _move; it was done before it at the time of the memory_lock taking. - Minimised vfio_pci_dma_buf_mmap() (removed redundant span check), added READ_ONCE for memattr - Misc fixes: comment in DMABUF name generation, removed superfluous READ_ONCE from faulthandler v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ - Cleanup of the common DMABUF-aware VMA vm_ops fault handler and export code. - Fixed a lot of races, particularly faults racing with DMABUF cleanup (if the VFIO device fds close, for example). - Added nicer human-readable names for VFIO mmap() VMAs RFCv2: Respin based on the feedback/suggestions: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ - Transform the existing VFIO BAR mmap path to also use DMABUFs behind the scenes, and then simply share that code for explicitly-mapped DMABUFs. Jason wanted to go that direction to enable iommufd VFIO type 1 emulation to pick up a DMABUF for an IO mapping. - Revoke buffers using a VFIO device fd ioctl RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Matt Evans (9): PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature MAINTAINERS | 2 +- drivers/pci/Kconfig | 10 +- drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 109 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 118 ++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 213 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 564 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 64 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 47 ++ 17 files changed, 958 insertions(+), 272 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

1 month, 2 weeks

← Newer
1
...
9
10
11
12
13
14
15
...
703
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig