Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

30 participants
6617 discussions

Living a Thousand Lives: Exploring the Quirky World of BitLife

by vast.stoat.yach＠hidingmail.net

Have you ever wondered what your life would look like if you made entirely different choices? Life simulation games have always been a fascinating genre for gamers, but few capture the unpredictable, hilarious, and sometimes chaotic nature of existence quite like Bitlife. Instead of relying on heavy 3D graphics, it is a text-based simulator that focuses entirely on the ripple effects of your decisions. It’s perfect for casual gaming sessions, so let's dive into how to play and get the most out of this quirky experience. https://bitlifefree.io/ Gameplay: Growing Up, One Year at a Time The premise of the game is incredibly simple but highly addictive. You are born with a random set of basic stats—Happiness, Health, Smarts, and Looks—in a random country to random parents. From there, you control your character's life year by year simply by tapping the "Age" button. In your early years, your choices are understandably limited to things like interacting with your parents, going to the doctor, or playing with pets. But as you grow into a teenager and an adult, the world completely opens up. You can choose to study hard, drop out, date, travel the world, buy real estate, or even turn to a life of crime. Every year, the game throws random scenarios at you: a classmate might insult you, you might be offered a questionable substance at a party, or you might find a wallet on the street. How you react directly impacts your stats and future opportunities. You might even have to pass mini-games, like navigating a maze for your driving test or escaping from prison. The ultimate goal is simply to live your life until your character passes away, leaving behind a unique legacy and a tombstone summarizing your deeds. Tips for a Great Experience If you are just starting out, here are a few tips to make your virtual life more successful—or at least more entertaining: Keep an eye on your core stats: Your Health and Happiness are crucial. If they drop too low, your character might face early health issues. Go to the gym, meditate, go to the movies, or spend time with family to keep these bars in the green. Education pays off (usually): If you want a high-paying, stable career like a doctor, judge, or CEO, use the "Study harder" option every year during school. Read books at the library to passively boost your Smarts stat. Hunt for Ribbons: At the end of every life, you are awarded a ribbon based on how you lived (e.g., "Hero," "Scandalous," "Lazy," or "Rich"). Trying to collect all the different ribbons is a great way to give yourself specific goals. Don't be afraid of the absurd: The real charm of the game is in its wild unpredictability. Sometimes, making terrible choices, trying to become a famous actor, or buying a crazy exotic pet leads to the most memorable playthroughs. Don't always play it safe! Conclusion Ultimately, the beauty of this simulator lies in its endless replayability. Every time you hit the button to start a new life, it is a completely blank slate. You can be a saint in one lifetime and an absolute menace to society in the next. Whether you have five minutes to kill on a bus commute or an hour to craft a sprawling, multi-generational family dynasty, diving into Bitlife offers a fun, lighthearted escape into a world where you pull all the strings. Give it a try, and see exactly where your choices take you!

27 minutes

Re: [PATCH net-next 2/4] udmabuf: emit one sg entry per pinned folio

by Christian König

On 6/5/26 20:44, Bobby Eshleman wrote: > On Fri, Jun 05, 2026 at 11:30:07AM +0200, Christian König wrote: >> On 6/4/26 02:42, Bobby Eshleman wrote: >>> From: Bobby Eshleman <bobbyeshleman(a)meta.com> >>> >>> get_sg_table() emitted one PAGE_SIZE sg entry per page even when the >>> underlying folio was larger. >>> >>> Instead, walk folios[] and emit one sg entry per folio. When folios >>> represent large pages (as is for MFD_HUGETLB), each sg entry is a large >>> page. Normal PAGE_SIZE sg tables are unchanged. >>> >>> Required by net/core/devmem to support rx-buf-size > PAGE_SIZE with >>> udmabuf. >> >> That doesn't explain why this is required. > > Sure, can definitely add. Devmem currently requires dmabuf sg entries to > be length and size aligned when it allocates niovs for NIC page pools. > Though udmabuf is not violating any dmabuf contract by emitting > PAGE_SIZE entries and the above restriction is probably more a > shortfalling of devmem, by emitting a single entry per folio this patch > allows udmabuf to be used by devmem for large pages. > >> >> Please note that accessing the pages/folio of an sg-table returned by DMA-buf is illegal and strictly forbidden! >> >> Regards, >> Christian. > > It seems both devmem and io_uring zcrx at least introspect through to > the sg-table to build NIC page pools (not accessing the memory itself, > however). Is there a better way? That's an absolute NO-GO! We need to stop that immediately. Touching the underlying struct page of an DMA-buf exported sg-table is strictly forbidden. We even have code to wrap the sg_table and hide the struct pages on debug builds to catch those issues, see function dma_buf_wrap_sg_table(). My last status is that the NIC page pools are build directly from the DMA addresses exposed by the sg_table. Was there any change I'm not aware of? Regards, Christian. > > Best, > Bobby > >> >>> Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> >>> --- >>> drivers/dma-buf/udmabuf.c | 47 ++++++++++++++++++++++++++++++++++++++++++----- >>> 1 file changed, 42 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c >>> index 94b8ecb892bb..f28dd3788ada 100644 >>> --- a/drivers/dma-buf/udmabuf.c >>> +++ b/drivers/dma-buf/udmabuf.c >>> @@ -141,26 +141,63 @@ static void vunmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) >>> vm_unmap_ram(map->vaddr, ubuf->pagecount); >>> } >>> >>> +/* Return the number of contiguous pages backed by the folio at @i. >>> + * A udmabuf may map only part of a folio, or reference the same folio >>> + * in multiple non-contiguous runs, so folio_nr_pages() can't be used. >>> + */ >>> +static pgoff_t udmabuf_folio_nr_pages(struct udmabuf *ubuf, pgoff_t i) >>> +{ >>> + struct folio *f = ubuf->folios[i]; >>> + pgoff_t j; >>> + >>> + for (j = 1; i + j < ubuf->pagecount; j++) { >>> + if (ubuf->folios[i + j] != f) >>> + break; >>> + /* Same folio, but not a sequential offset within it. */ >>> + if (ubuf->offsets[i + j] != ubuf->offsets[i] + j * PAGE_SIZE) >>> + break; >>> + } >>> + return j; >>> +} >>> + >>> +/* Count the contiguous folio runs in @ubuf, one sg entry per run. */ >>> +static unsigned int udmabuf_sg_nents(struct udmabuf *ubuf) >>> +{ >>> + unsigned int nents = 0; >>> + pgoff_t i; >>> + >>> + for (i = 0; i < ubuf->pagecount; i += udmabuf_folio_nr_pages(ubuf, i)) >>> + nents++; >>> + return nents; >>> +} >>> + >>> static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, >>> enum dma_data_direction direction) >>> { >>> struct udmabuf *ubuf = buf->priv; >>> - struct sg_table *sg; >>> struct scatterlist *sgl; >>> - unsigned int i = 0; >>> + struct sg_table *sg; >>> + pgoff_t i, run; >>> + unsigned int nents; >>> int ret; >>> >>> + nents = udmabuf_sg_nents(ubuf); >>> + >>> sg = kzalloc_obj(*sg); >>> if (!sg) >>> return ERR_PTR(-ENOMEM); >>> >>> - ret = sg_alloc_table(sg, ubuf->pagecount, GFP_KERNEL); >>> + ret = sg_alloc_table(sg, nents, GFP_KERNEL); >>> if (ret < 0) >>> goto err_alloc; >>> >>> - for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) >>> - sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, >>> + sgl = sg->sgl; >>> + for (i = 0; i < ubuf->pagecount; i += run) { >>> + run = udmabuf_folio_nr_pages(ubuf, i); >>> + sg_set_folio(sgl, ubuf->folios[i], run << PAGE_SHIFT, >>> ubuf->offsets[i]); >>> + sgl = sg_next(sgl); >>> + } >>> >>> ret = dma_map_sgtable(dev, sg, direction, 0); >>> if (ret < 0) >>> >>> -- >>> 2.53.0-Meta >>> >>

2 hours, 13 minutes

Re: [PATCH v18 0/4] Rust bindings for gem shmem

by Miguel Ojeda

On Sun, Jun 7, 2026 at 2:17 PM Gary Guo <gary(a)garyguo.net> wrote: > > IMO we really shouldn't use Clippy to generate code. We spent too much effort in > fixing codegen issues that are only present when driven by clippy. > > We should just run a check phase with clippy to get the lints only, and then use > rustc to generate actual code. Yeah, given the trouble it is giving, I think that will probably be a better approach medium term. I don't love it, because the original idea was to avoid such an extra phase, but it is definitely better vs. random source code changes... We could also increase the symbol size-related variables (`KSYM_NAME_LEN`, `SZ` in `modpost`...) only for Clippy builds to a ludicrous value. The extra phase approach would avoid surprises more generally though, so I like it in that sense, and has the implicit advantage of avoiding someone using a Clippy kernel in production by mistake. Ok, I can take a look at that. For now, I will pick the other patch. Cheers, Miguel

18 hours, 5 minutes

Re: [PATCH v18 0/4] Rust bindings for gem shmem

by Miguel Ojeda

On Sun, Jun 7, 2026 at 4:08 AM Alexandre Courbot <acourbot(a)nvidia.com> wrote: > > This is fixed by [1]. Maybe we should merge that one patch separately > and before the rest? I seem to be seeing these long symbol problems more > often recently. > > [1] https://lore.kernel.org/all/20260605-nova-exports-v4-1-e948c287407c@nvidia.… I can take that one via `rust-next` unless someone shouts -- Ack's appreciated. Cheers, Miguel

21 hours, 25 minutes

[PATCH v5] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `size_t` for `nents` and checking against `UINT_MAX` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v5: - Removed WARN_ON_ONCE from calc_sg_nents() to avoid log noise (Jason). - Added explicit check for `!nents` in dma_buf_phys_vec_to_sgt() to cleanly return -EINVAL on overflow (Jason). Changes in v4: - Added WARN_ON_ONCE() to the nents overflow check to prevent silent failures (Claude Bot). Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). drivers/dma-buf/dma-buf-mapping.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..607b7998463d 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -10,7 +10,7 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -36,7 +36,7 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, struct phys_vec *phys_vec, size_t nr_ranges, size_t size) { - unsigned int nents = 0; + size_t nents = 0; size_t i; if (!state || !dma_use_iova(state)) { @@ -51,6 +51,9 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, nents = DIV_ROUND_UP(size, UINT_MAX); } + if (nents > UINT_MAX) + return 0; + return nents; } @@ -95,9 +98,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; @@ -133,6 +137,11 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, } nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size); + if (!nents) { + ret = -EINVAL; + goto err_free_state; + } + ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO); if (ret) goto err_free_state; -- 2.54.0.929.g9b7fa37559-goog

1 day

Re: [PATCH net-next 2/4] udmabuf: emit one sg entry per pinned folio

by Christian König

On 6/4/26 02:42, Bobby Eshleman wrote: > From: Bobby Eshleman <bobbyeshleman(a)meta.com> > > get_sg_table() emitted one PAGE_SIZE sg entry per page even when the > underlying folio was larger. > > Instead, walk folios[] and emit one sg entry per folio. When folios > represent large pages (as is for MFD_HUGETLB), each sg entry is a large > page. Normal PAGE_SIZE sg tables are unchanged. > > Required by net/core/devmem to support rx-buf-size > PAGE_SIZE with > udmabuf. That doesn't explain why this is required. Please note that accessing the pages/folio of an sg-table returned by DMA-buf is illegal and strictly forbidden! Regards, Christian. > Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> > --- > drivers/dma-buf/udmabuf.c | 47 ++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 42 insertions(+), 5 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index 94b8ecb892bb..f28dd3788ada 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -141,26 +141,63 @@ static void vunmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) > vm_unmap_ram(map->vaddr, ubuf->pagecount); > } > > +/* Return the number of contiguous pages backed by the folio at @i. > + * A udmabuf may map only part of a folio, or reference the same folio > + * in multiple non-contiguous runs, so folio_nr_pages() can't be used. > + */ > +static pgoff_t udmabuf_folio_nr_pages(struct udmabuf *ubuf, pgoff_t i) > +{ > + struct folio *f = ubuf->folios[i]; > + pgoff_t j; > + > + for (j = 1; i + j < ubuf->pagecount; j++) { > + if (ubuf->folios[i + j] != f) > + break; > + /* Same folio, but not a sequential offset within it. */ > + if (ubuf->offsets[i + j] != ubuf->offsets[i] + j * PAGE_SIZE) > + break; > + } > + return j; > +} > + > +/* Count the contiguous folio runs in @ubuf, one sg entry per run. */ > +static unsigned int udmabuf_sg_nents(struct udmabuf *ubuf) > +{ > + unsigned int nents = 0; > + pgoff_t i; > + > + for (i = 0; i < ubuf->pagecount; i += udmabuf_folio_nr_pages(ubuf, i)) > + nents++; > + return nents; > +} > + > static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > enum dma_data_direction direction) > { > struct udmabuf *ubuf = buf->priv; > - struct sg_table *sg; > struct scatterlist *sgl; > - unsigned int i = 0; > + struct sg_table *sg; > + pgoff_t i, run; > + unsigned int nents; > int ret; > > + nents = udmabuf_sg_nents(ubuf); > + > sg = kzalloc_obj(*sg); > if (!sg) > return ERR_PTR(-ENOMEM); > > - ret = sg_alloc_table(sg, ubuf->pagecount, GFP_KERNEL); > + ret = sg_alloc_table(sg, nents, GFP_KERNEL); > if (ret < 0) > goto err_alloc; > > - for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) > - sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, > + sgl = sg->sgl; > + for (i = 0; i < ubuf->pagecount; i += run) { > + run = udmabuf_folio_nr_pages(ubuf, i); > + sg_set_folio(sgl, ubuf->folios[i], run << PAGE_SHIFT, > ubuf->offsets[i]); > + sgl = sg_next(sgl); > + } > > ret = dma_map_sgtable(dev, sg, direction, 0); > if (ret < 0) > > -- > 2.53.0-Meta >

2 days, 23 hours

Re: [PATCH 3/4] rust: Add dma_fence abstractions

by Boris Brezillon

On Wed, 3 Jun 2026 21:43:05 -0300 Daniel Almeida <dwlsalmeida(a)gmail.com> wrote: > > On 3 Jun 2026, at 14:14, Boris Brezillon <boris.brezillon(a)collabora.com> wrote: > > > > On Wed, 3 Jun 2026 13:41:02 -0300 > > Daniel Almeida <dwlsalmeida(a)gmail.com> wrote: > > > >>> + /// Called when the fence is signaled. > >>> + /// > >>> + /// This is called from the fence signaling path, which may be in interrupt > >>> + /// context or with locks held, which is why `self` is only borrowed, so that > >>> + /// it cannot drop. Implementations must not sleep or perform > >>> + /// long-running operations. > >>> + /// > >>> + /// An implementation likely wants to inform itself (e.g., through a work item) > >>> + /// within this callback that the associated [`FenceCbRegistration`] can now be > >>> + /// dropped. > >>> + fn called(&mut self); > >> > >> This is a central point. We ideally would want this to consume self, because we > >> may want to move things out of the callback. > > > > This one comes from me. The rationale being that ::called() is called > > from an atomic context, and the resources attached to the callback data > > might require acquiring other sleeping locks to be released, and > > sometimes you don't even notice immediately because said resources are > > refcounted, and the lock is only acquired when you happen to be the > > last owner. Yes, those can be caught at runtime if the C side is > > properly annotated with might_sleep(), but that's not always the case. > > > > If we defer the drop of the data only when the FenceCb is > > dropped/recycled, we're at least not constrained by this "runs in > > atomic context" thing. > > > > This design does not solve it, because one can quite trivially get around this > restriction using Option<T> as I said. If your point is “don’t run any drop() here”, > then &mut self doesn’t do it. My bad, I thought you were talking about some Option<T> in FenceCbRegistration<T> (there was one at some point, but it's gone now), but you're talking about having an Option<X> inside the T. Yes, there's indeed nothing preventing a drop on X in that path, and it's just as bad as passing the fence back as value to the callback in that case. > > >> > >> Consider a fence design where signal() consumes self. Now consider this: > >> > >> ``` > >> impl FenceCb for MyCallback { > >> fn called(&mut self) { > >> // Can't move the fence out, so we have to put an Option<T> just to be able > >> // to move. > >> if let Some(f) = self.some_fence.take() { > >> f.signal(); > >> } > >> } > >> ``` > >> > >> This used to be the case when our version of the job queue used the "proxy > >> fence" design: > >> > >> > >> ``` > >> // Callback on the hw fence > >> impl FenceCb for MyCallback { > >> fn called(&mut self) { > >> if let Some(f) = self.submit_fence.take() { > >> f.signal(); > >> } > > > > I'm pretty sure lockdep won't like it anyway, because this is nested > > locking of the same lock class. For such proxies, we'll need to teach > > lockdep about the nesting like has been recently done on > > dma_fence_array & co. But I'm digressing. > > Yeah, but this is more about resource transfer in general, not > this pattern specifically. > > I agree that this has issues, and yes, lockdep complained back > then :) The thing is, there's so many aspects that could go wrong because of the context this callback is called in. Nested locking is one of them, the fact we can't sleep is another. And with rust it's even worse, because of the implicit drops that will happen when you take ownership of resources (taking sleeping locks to remove resources from a dataset for instance). So, by passing self by value to the ::callback(), you're basically telling users "hey, BTW, don't forget to defer the drop to some workqueue if you think it's not atomic-safe". And how can users know that the thing they're about to drop can be dropped in atomic context? They basically have to audit the ::drop() of all the resources they embed in their type implementing FenceCb. Not only that, but they also have to design the thing so the deferral of this ::drop() doesn't allocate, because, obviously, allocating in atomic context is tricky/fallible. AFAIK, none of this can be spot at compile-time (I remember Gary/Danilo mentioning that we could teach the klint about some of these rules). This would leave us with runtime checks like might_sleep(), but most of the C putters (xxx_put(object)) don't have might_sleep() in the path where the decref doesn't lead to a refcnt=0 situation. TLDR; Call this PTSD if you want, but this is the sort of bugs I struggled with on the C side, and I can predict that the exact same will happen in rust drivers if we expose the FenceCb as it is designed here and we don't have a way to check the soundness of the FenceCb implementations at compile time. The other option (the one I've been advocating for from the start), is to not let drivers implement FenceCb (make it private), but instead have a bunch of implementations that we know are safe. Here's a list of implementations that I think would unblock most of the drivers use cases: - wakeup a thread - complete a completion object - schedule a WorkItem - schedule a kthread_worker (once we get a proper rust abstraction for that) It doesn't mean we can't have optimized FenceCb implementations that do a lot more in the callback() path instead of deferring to a workqueue/thread, but at least those would have to be implemented in dma_fence.rs, and the dma_fence.rs maintainers can then carefully audit the code as part of the review process, which we know is not really the case when changes touch drivers code only. FWIW, I think the FenceProxy design you were describing falls into this "must be carefully audited" bucket, and should be implemented in dma_fence.rs. > > > > >> } > >> ``` > >> > >> Although this is not the case anymore, since we phased out this design given > >> Christian's recent work. Still, we should ideally not require Option<T> here in > >> general just to make resource transfer possible. > > > > I see. OTOH, don't we need to make this inner data movable if we want > > to cancel the FenceCb before the fence is signaled anyway? And that's > > most certainly a case we have in the teardown path. > > Can you expand a bit on what you mean here? Never mind, I was confusing two different iterations of the code here. I thought the Option<T> you were mentioning was in FenceCbRegistration<T>, with some explicit ::cancel() function that would return Option<T> so the user can get its resources back when it cancels the registration, and also know whether the callback was called or not. But this is all gone now, and all we can do is drop the registration, which will automatically drop the inner T.

3 days

[PATCH v3 0/2] libfs: set SB_I_NOEXEC and SB_I_NODEV in init_pseudo()

by John Hubbard

This began as a one-line dma-buf fix for a path_noexec() warning added by commit 1e7ab6f67824 ("anon_inode: rework assertions"). Christoph pointed out that the fix belongs higher up: a pseudo filesystem has no reason not to set SB_I_NOEXEC by default. This series does that. * Patch 1 sets both flags in init_pseudo(), so every pseudo filesystem gets them. This is the only patch that changes a flag, and the only one with Fixes:/Cc: stable. * Patch 2 drops the assignments that are now redundant in the callers that set them by hand. Most callers already set one or both flags. I audited every init_pseudo() caller. Here is what patch 1 actually changes for each. The only visible effect is on dma-buf, where SB_I_NOEXEC silences the warning. SB_I_NODEV is never consulted on these SB_NOUSER mounts, and none of the callers that gain SB_I_NOEXEC are executed from. caller had patch 1 adds --------------------------- -------- -------------- fs/anon_inodes.c both nothing new mm/secretmem.c both nothing new virt/kvm/guest_memfd.c both nothing new fs/nsfs.c both nothing new fs/pidfs.c both nothing new fs/aio.c NOEXEC NODEV drivers/dma-buf/dma-buf.c neither NOEXEC + NODEV net/socket.c neither NOEXEC + NODEV fs/pipe.c neither NOEXEC + NODEV kernel/resource.c neither NOEXEC + NODEV fs/erofs/super.c neither NOEXEC + NODEV fs/btrfs/tests/... neither NOEXEC + NODEV drivers/vfio/vfio_main.c neither NOEXEC + NODEV drivers/gpu/drm/drm_drv.c neither NOEXEC + NODEV drivers/dax/super.c neither NOEXEC + NODEV block/bdev.c neither NOEXEC + NODEV John Hubbard (2): libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo() libfs: drop redundant SB_I_NOEXEC/SB_I_NODEV in init_pseudo() callers fs/aio.c | 1 - fs/anon_inodes.c | 2 -- fs/libfs.c | 1 + fs/nsfs.c | 1 - fs/pidfs.c | 2 -- mm/secretmem.c | 2 -- virt/kvm/guest_memfd.c | 2 -- 7 files changed, 1 insertion(+), 10 deletions(-) base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8 -- 2.54.0

3 days, 2 hours

[PATCH v18 0/4] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Patch-series wide changes since V15: * Fix some major rebasing errors I somehow didn't notice :( * Drop the dependency on LazyInit, use the trick that Alice suggested instead. * Fix dependency ordering so that Tyr can get the vmap stuff first without the other bits. Patch-series wide changes since V16: * Fix ordering one more time (SetOnce::reset() doesn't need to come before adding vmap functions) * Rebase against the latest DeviceContext changes from me that got pushed. Lyude Paul (4): rust: drm: gem: shmem: Add DmaResvGuard helper rust: drm: gem: shmem: Add vmap functions rust: faux: Allow retrieving a bound Device rust: drm: gem: Introduce shmem::Object::sg_table() rust/kernel/drm/gem/shmem.rs | 511 ++++++++++++++++++++++++++++++++++- rust/kernel/faux.rs | 16 +- 2 files changed, 512 insertions(+), 15 deletions(-) base-commit: fea3a2dd7d3fc1936211ced5f84420e610435730 -- 2.54.0

3 days, 13 hours

[PATCH v17 0/6] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Patch-series wide changes since V15: * Fix some major rebasing errors I somehow didn't notice :( * Drop the dependency on LazyInit, use the trick that Alice suggested instead. * Fix dependency ordering so that Tyr can get the vmap stuff first without the other bits. Patch-series wide changes since V16: * Fix ordering one more time (SetOnce::reset() doesn't need to come before adding vmap functions) * Rebase against the latest DeviceContext changes from me that got pushed. Lyude Paul (6): rust: drm: gem: shmem: Fix Default implementation for ObjectConfig rust: drm: gem: shmem: Add DmaResvGuard helper rust: drm: gem: shmem: Add vmap functions rust: faux: Allow retrieving a bound Device rust: sync: Add SetOnce::reset() rust: drm: gem: Introduce shmem::Object::sg_table() rust/kernel/drm/gem/shmem.rs | 518 ++++++++++++++++++++++++++++++++++- rust/kernel/faux.rs | 7 +- rust/kernel/sync/set_once.rs | 60 +++- 3 files changed, 563 insertions(+), 22 deletions(-) base-commit: 723bd79ca9e492cc91850094a2892bde0345c51a -- 2.54.0

3 days, 14 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig