Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

29 participants
7092 discussions

Re: [PATCH net-next v6 3/3] selftests/net: devmem.py: add check_rx_large_niov

by Jakub Kicinski

On Thu, 30 Jul 2026 14:39:37 -0700 Bobby Eshleman wrote: > Poking around, it looks like 231.1.167.0 and above should support > everything, so fw should be okay AFAICT. > > Looks like the config is missing CONFIG_NET_DEVMEM and CONFIG_UDMABUF? Ah, damn, you're right. I grepped for DEVMEM and didn't look closely on a hit. Turns out there's a non-NET DEVMEM, too. Could you send a patch to add the missing config options to tools/testing/selftests/drivers/net/hw/config ? Can be separate or part of this series, doesn't matter. > Sorry, took me a while... was certain it was a bug in my code. > > Not the failure here, but wondering if this was on ARM led to seeing > that 16K hardcoded rx_page_size in run_rx_large_niov() may fail on ARM > with 64K pages because it will fail the IS_ALIGN(16K, 64K) check... Ah, good thought. We've been meaning to get an ARM64 server for NIPA (our current server supplier is out). If it's not too hard could be nice to guard against that. But also not a huge deal for HW tests if they fail instead of skipping.

4 weeks, 1 day

+97158 994 3206} Abortion Pills in Dubai | Abu Dhabi | Sharjah

by celik burak

+97158 994 3206} Abortion Pills in Dubai | Abu Dhabi | Sharjah Whatsapp +97158 994 3206 We have Abortion Pills / Cytotec Tablets /mifegest kit Available in Dubai, Sharjah, Abudhabi, Ajman, Alain, Fujairah, Ras Al Khaimah, Umm Al Quwain, UAE, buy cytotec in Dubai +97158 994 3206 “”Abortion Pills near me DUBAI | ABU DHABI|UAE. Price of Misoprostol, Cytotec” +97158 994 3206 Dr.Leen “BUY ABORTION PILLS MIFEGEST KIT, MISOPROTONE, CYTOTEC PILLS IN DUBAI, ABU DHABI,UAE” Contact me now via whatsapp…… abortion Pills Cytotec also available Oman Qatar Doha Saudi Arabia Bahrain Above all, Cytotec Abortion Pills are Available In Dubai / UAE, you will be very happy to do abortion in dubai Buy abortion pills in Dubai Buy abortion pills in Oman Buy abortion pills in Abu Dhabi Buy abortion pills in Sharjah Fujairah Buy abortion pills in Ras Al Khaimah (RAK) Buy abortion pills in Ajman Buy abortion pills in Al Ain Buy abortion pills in Umm Al Quwain (UAQ) Buy abortion pills in Kuwait Abortion Pills Available In Dubai Abortion Pills Available In UAE Abortion Pills Available In Abu Dhabi Abortion Pills Available In Sharjah Abortion Pills Available In Fujairah Abortion Pills Available In Alain Abortion Pills Available In Qatar Cytotec Available In Dubai Cytotec in Dubai Cyotec Pills Dubai Abortion Cytotec Pills In Dubai whatsapp us at ?? +97158 994 3206 ?Buy abortion pills in Dubai, Buy abortion pills in Abudhabi, Buy abortion pills in Sharja, Buy abortion pills in Abu az Zuluf, Buy abortion pills in Ras Al Khaimah (RAK), Buy abortion pills in Ajman, Buy abortion pills in Al Ain, abortion pills in DOHA, abortion pills in Abu Thaylah, abortion pills in kuwait city, abortion pills in muscat, abortion pills in jeddah,abortion pills in qatar,abortion pills in hawally,abortion pills in salmiyah,abortion pills in al wakrah,abortion pills in riyadh,abortion pills in manama,abortion pills in isa town,abortion pills in hamad town, Buy abortion pills in Umm Al Quwain (UAQ), Buy abortion pills in Kuwait, Abortion Pills Available In Dubai, Abortion Pills Available In UAE, Abortion Pills Available In Abu Dhabi, Abortion Pills Available In Sharjah, Abortion Pills Available In Fujairah, Abortion Pills Available In Alain, Abortion Pills Available In Qatar, Cytotec Available In Dubai, Cytotec in Dubai, Cytotec Pills Dubai, Abortion Cytotec Pills In Dubai UAE we are providing cytotec 200mg abortion pill in Dubai, UAE. Medication abortion offers an alternative to Surgical Abortion for women in the early weeks of pregnancy. We only offer abortion pills from 1 week-6 Months. We then advise you to use surgery if its beyond 6 months. Our Abu Dhabi, Ajman, Al Ain, Dubai, Fujairah, Ras Al Khaimah (RAK), Sharjah, Umm Al Quwain (UAQ) United Arab Emirates Abortion Clinic provides the safest and most advanced techniques for providing non-surgical, medical and surgical abortion methods for early through late second trimester, including the Abortion By Pill Procedure (RU 486, Mifeprex, Mifepristone, early options French Abortion Pill), Tamoxifen, Methotrexate and Cytotec (Misoprostol). The Abu Dhabi, United Arab Emirates Abortion Clinic performs Same Day Abortion Procedure using medications that are taken on the first day of the office visit and will cause the abortion to occur generally within 4 to 6 hours (as early as 30 minutes) for patients who are 3 to 12 weeks pregnant. When Mifepristone and Misoprostol are used, 50% of patients complete in 4 to 6 hours; 75% to 80% in 12 hours; and 90% in 24 hours. We use a regimen that allows for completion without the need for surgery 99% of the time. All advanced second trimester and late term pregnancies at our Tampa clinic (17 to 24 weeks or greater) can be completed within 24 hours or less 99% of the time without the need surgery. The procedure is completed with minimal to no complications. Our Women's Health Center located in Abu Dhabi, United Arab Emirates, uses the latest medications for medical abortions (RU486, Mifeprex, Mifegyne, Mifepristone, early options French abortion pill), Methotrexate and Cytotec (Misoprostol). The safety standards of our Abu Dhabi, United Arab Emirates Abortion Doctors remain unparalleled. They consistently maintain the lowest complication rates throughout the nation. Our Physicians and staff are always available to answer questions and care for women in one of the most difficult times in their lives. The decision to have an abortion at the Abortion Clinic in Abu Dhabi, United Arab Emirates, involves moral, ethical, religious, family, financial, health and age considerations. Buy abortion pills in Dubai, Buy abortion pills in Oman, Buy abortion pills in Abu Dhabi, Buy abortion pills in Sharjah Fujairah, Buy abortion pills in Ras Al Khaimah (RAK), Buy abortion pills in Ajman, Buy abortion pills in Al Ain, Buy abortion pills in Umm Al Quwain (UAQ), Buy abortion pills in Kuwait, Abortion Pills Available In Dubai, Abortion Pills Available In UAE, Abortion Pills Available In Abu Dhabi, Abortion Pills Available In Sharjah, Abortion Pills Available In Fujairah, Abortion Pills Available In Alain, Abortion Pills Available In Qatar, Cytotec Available In Dubai Cytotec in Dubai, abortion pills in Dubai for sale. +97158 994 3206 Cytotec Pills Dubai, Abortion Cytotec Pills In Dubai UAE, PRICE OF MIFE-KIT IN UAE HOW TO GET ABORTION PILLS IN DUBAI Safe Abortion in the UAE MIFEPRISTONE IN UAE MIFEPRISTONE IN DUBAI LEVONORGESTRAL IN UAE RU 486 IN DUBAI RU 486 IN ABU DHABI RU 486 IN UAE ABORTION PILLS ONLINE DELIVERY IN DUBAI ABORTION PILLS ON AMAZON IN UAE SURGICAL ABORTION IN DUBAI SURGICAL ABORTION IN ABU DHABI Surgical Abortion in the UAE COST OF SURGICAL ABORTION IN DUBAI/UAE HOW MUCH IS SURGICAL ABORTION IN DUBAI D & C IN DUBAI COST OF D&C IN DUBAI/UAE/ABU DHABI PRICE OF D & C PROCEDURE IN UAE DILATION & CURETTAGE IN DUBAI/UAE COST OF D & C IN DUBAI PRIVATE HOSPITAL Whatsapp +97158 994 3206 Question Tags: +97158 994 3206 “Legit & Safe ABORTION PILLS, ABU DHABI Sharjah Alain RAK city Satwa Jumeirah Al barsha, CYTOTEC, MIFEGEST KIT IN DUBAI, Misoprostol, UAE” Contact me now via whatsapp…………. +97158 994 3206

4 weeks, 1 day

Re: [PATCH net-next v6 3/3] selftests/net: devmem.py: add check_rx_large_niov

by Jakub Kicinski

On Fri, 24 Jul 2026 14:21:17 -0700 Bobby Eshleman wrote: > From: Bobby Eshleman <bobbyeshleman(a)meta.com> > > Add a new devmem test case for binding the dmabuf with rx-page-size=16K. > The test sweeps RX payload sizes straddling the niov boundary to cover > the sub-niov, exact-niov, and multi-niov RX paths. > > Silence pylint invalid-name (`with open() as f`) and too-many-arguments > (ncdevmem_rx grew to 6 args) at file scope. > > Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> > Acked-by: Stanislav Fomichev <sdf(a)fomichev.me> Hm, odd. In NIPA we're getting: TAP version 13 1..1 # timeout set to 0 # selftests: drivers/net/hw: devmem.py # TAP version 13 # 1..5 # ok 1 devmem.check_rx # SKIP marked as disruptive # ok 2 devmem.check_tx # SKIP marked as disruptive # ok 3 devmem.check_tx_chunks # SKIP marked as disruptive # ok 4 devmem.check_rx_hds # SKIP Test requires devmem support # ok 5 devmem.check_rx_large_niov # SKIP Test requires devmem support # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:5 error:0 ok 1 selftests: drivers/net/hw: devmem.py # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 https://netdev.bots.linux.dev/logs/hwksft/BCM57508/results/755681/config driver: bnxt fw: 237.1.148.0 Any idea?

4 weeks, 1 day

Re: [PATCH net-next v6 1/3] net: devmem: allow rx-page-size > PAGE_SIZE per dmabuf binding

by Jakub Kicinski

On Fri, 24 Jul 2026 14:21:15 -0700 Bobby Eshleman wrote: > + value: 0 # dummy: codegen needs a number, real value is the PAGE_SIZE macro (header) yamllint says: 12:81 error line too long (89 > 80 characters) (line-length)

4 weeks, 1 day

Re: [PATCH v7 3/5] rust: sync: Add abstraction for rcu_barrier()

by Gary Guo

On Wed Jul 29, 2026 at 6:18 PM BST, Paul E. McKenney wrote: > On Wed, Jul 29, 2026 at 11:45:40AM +0200, Philipp Stanner wrote: >> rcu_barrier() is a frequently used C function which is always safe to be >> called. > > Just checking... Here "always safe" means only from task level, with BH, > preemption, and interrupts all enabled, correct? > > In contrast, if you do this: > > preempt_disable(); > rcu_barrier(); > preempt_enable(); > > the results won't be safe. This is same for all sleepable functions. In order to avoid having to mark all sleeping function unsafe, we've decided that sleeping from non-preemptable context is "safe", but is a bug regardless. Best, Gary

1 month

Re: [PATCH v4 09/14] nvme-pci: add SGL support for the dmabuf path

by Christoph Hellwig

On Wed, Jul 29, 2026 at 12:45:47PM +0100, Pavel Begunkov wrote: > It was exposed in early version as I was passing a [{dma,len}, ...] > array, but we moved from that. Maybe I should put the minimum > segment size in the map structure, and (possibly over) split using > that for now? Keith had this chunk in his patches: > > + int offset = offset_in_page(bio->bi_iter.bi_bvec_done); > + > + nsegs = ALIGN(bio->bi_iter.bi_size + offset, PAGE_SIZE) >> > + PAGE_SHIFT; > + if (bio->bi_iter.bi_size > max_bytes) { > + bytes = max_bytes; > + nsegs = (bytes + offset) >> PAGE_SHIFT; > + } else if (nsegs > lim->max_segments) { > + nsegs = lim->max_segments; > + bytes = PAGE_SIZE * nsegs - offset; > + } else { > + *segs = nsegs; > + return NULL; > + } This seems very pessimistic, especially for the case of the registration only having a single segment, which I'd expect to be fairly common due to P2P bar mappings, huge pages or IOMMU coalescing. So at very least we'd want to special case that, but in an idea world the caller would be required to provide a useful nr_segments for the I/O.

1 month

Re: [PATCH v4 09/14] nvme-pci: add SGL support for the dmabuf path

by Christoph Hellwig

On Wed, Jul 29, 2026 at 03:47:23PM +0530, Anuj Gupta/Anuj Gupta wrote: > > But I also don't understand what the use case for this function > > is to start with. struct sg_table tells us how many segments > > exist on the DMA side in the nents member, which should be just > > fine for the SGL threshold calculation. > > sg_table->nents covers the entire exported buffer (<=1GiB), while a > request only covers a subrange[bi_offset, bi_offset+payload). Using > nents would overcount the request's segments. Urgg, yes. > >> + if (!entries) > >> + return BLK_STS_IOERR; > >> + if (entries > NVME_MAX_SEGS) > >> + return BLK_STS_AGAIN; > > > > Given that the block layer enforced data in rw/command and the > > max_segments limit, why do we need the extra check here? > > A dmabuf bio reports nsegs=1 (bio_split_io_at) to the block layer, so > max_segments isn't enforced against the SG entries actually spanned by > the request. Hence the explicit check. We'll need to expose the actual nsegs to the block layer and split based on that. Otherwise I/O might work or fail based on the device capabilities.

1 month

Re: [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure

by Christoph Hellwig

On Wed, Jul 29, 2026 at 11:37:19AM +0100, Pavel Begunkov wrote: > On 7/29/26 07:59, Christoph Hellwig wrote: >> The method name feels a bit convoluted, but given all the >> previous discussions I don't care too strongly. I'll leave >> the dma-buf side review to those who understand it. > > I assume you mean this: Yes. > > + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *); > > I agree, and all dma_buf_io_[ctx,map] look clunky, but I don't > see what I can drop out of the name. Suggestions? Maybe I at least > should make the fs op sth like "register_dma_buf". I just remember scares from the last discussion :) register_dma_buf sounds fine to be, but unless I misremember there were objections to that before. > > -- > Pavel Begunkov ---end quoted text---

1 month

Re: [PATCH v4 09/14] nvme-pci: add SGL support for the dmabuf path

by Christoph Hellwig

On Tue, Jul 28, 2026 at 10:29:21PM +0100, Pavel Begunkov wrote: > From: Anuj Gupta <anuj20.g(a)samsung.com> > > Add SGL support in addition to PRP for dmabuf-backed requests, > coalescing the mapping's sg_table into NVMe SGL data descriptors. > > Signed-off-by: Anuj Gupta <anuj20.g(a)samsung.com> > [pavel: rebased] > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/nvme/host/pci.c | 191 +++++++++++++++++++++++++++++++++++++++- > 1 file changed, 187 insertions(+), 4 deletions(-) > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index f1b67c191892..cbb321fb7c50 100644 > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -1287,12 +1287,18 @@ static blk_status_t nvme_pci_setup_data_prp(struct request *req, > return BLK_STS_IOERR; > } > > +static void nvme_pci_sgl_set_data_addr(struct nvme_sgl_desc *sge, > + dma_addr_t addr, u32 len) > +{ > + sge->addr = cpu_to_le64(addr); > + sge->length = cpu_to_le32(len); > + sge->type = NVME_SGL_FMT_DATA_DESC << 4; > +} > + > static void nvme_pci_sgl_set_data(struct nvme_sgl_desc *sge, > struct blk_dma_iter *iter) > { > - sge->addr = cpu_to_le64(iter->addr); > - sge->length = cpu_to_le32(iter->len); > - sge->type = NVME_SGL_FMT_DATA_DESC << 4; > + nvme_pci_sgl_set_data_addr(sge, iter->addr, iter->len); > } The naming is a bit confusing (and me passing the iter to nvme_pci_sgl_set_data is probably at faul for that). So maybe spin out a prep patch to rename the old nvme_pci_sgl_set_data to nvme_pci_dma_iter_set_sgl or so, and then add the new one as nvme_pci_sgl_set_data (as before the dma_iter conversion). > > +static unsigned int nvme_pci_dmabuf_sgl_nents(struct request *req, > + dma_addr_t *first_dma, > + u32 *first_len) This is a really good example why the aligning to the opening braces produces totally unreadble code.. But I also don't understand what the use case for this function is to start with. struct sg_table tells us how many segments exist on the DMA side in the nents member, which should be just fine for the SGL threshold calculation. > +{ > + struct nvme_iod *iod = blk_mq_rq_to_pdu(req); > + struct bio *bio = req->bio; > + struct nvme_dmabuf_map *map = to_nvme_dmabuf_map(bio->bi_dmabuf_map); > + size_t length = blk_rq_payload_bytes(req); > + struct nvme_sgl_desc *sg_list = NULL; > + dma_addr_t sgl_dma = 0, last_end = 0; > + unsigned int mapped = 0; > + unsigned long tmp; > + struct scatterlist *sg; > + size_t offset, remaining; > + bool have = false; > + > + if (!entries) > + return BLK_STS_IOERR; > + if (entries > NVME_MAX_SEGS) > + return BLK_STS_AGAIN; Given that the block layer enforced data in rw/command and the max_segments limit, why do we need the extra check here? > + continue; > + } > + > + addr += offset; > + sg_len -= offset; > + offset = 0; > + > + while (sg_len && remaining) { These can't be false on the first iteration, so maybe turn this into a do {} while loop? > + u32 chunk = min_t(size_t, remaining, sg_len); > + > + if (have && last_end == addr) { > + u32 old = le32_to_cpu(sg_list[mapped - 1].length); > + > + sg_list[mapped - 1].length = cpu_to_le32(old + chunk); Overly long line. > + } else { > + if (WARN_ON_ONCE(mapped == entries)) > + goto err_free; > + nvme_pci_sgl_set_data_addr(&sg_list[mapped++], > + addr, chunk); > + } Why do we need this merging? dma_map_sg should have already done any interesting merging, or am I missing something? > + if (use_sgl != SGL_UNSUPPORTED) { > + dma_addr_t first_dma; > + u32 first_len; > + unsigned int entries; > + > + entries = nvme_pci_dmabuf_sgl_nents(req, &first_dma, > + &first_len); > + > + if (use_sgl == SGL_FORCED) { > + ret = nvme_rq_setup_dmabuf_sgl(req, nvmeq, > + entries, first_dma, first_len); > + return ret == BLK_STS_AGAIN ? BLK_STS_IOERR : ret; > + } > + > + if (sgl_threshold && entries && > + DIV_ROUND_UP(blk_rq_payload_bytes(req), entries) >= > + sgl_threshold) { > + ret = nvme_rq_setup_dmabuf_sgl(req, nvmeq, > + entries, first_dma, first_len); > + if (ret != BLK_STS_AGAIN) > + return ret; > + } > + } Various overly long lines. Please factor out a helper for the decisions to use sgl vs not instead of open coding it here.

1 month

Re: [PATCH v4 08/14] nvme-pci: implement dma_token backed requests

by Christoph Hellwig

> +static int nvme_init_dma_buf_io_ctx(struct block_device *bdev, > + struct dma_buf_io_ctx *ctx) Please stick to two-tab indents for function declaration continuation for the nvme code to keep the code easy to maintain. > +#if defined(CONFIG_DMA_SHARED_BUFFER) This should be good old #ifdef. Same in a few other places over the series. Modulo these minor nits the patch looks good.

1 month

← Newer
1
...
8
9
10
11
12
13
14
...
710
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig