RE: Expense of read_iter

2021-01-20 Thread David Laight
From: Mikulas Patocka > Sent: 20 January 2021 15:12 > > On Wed, 20 Jan 2021, Jan Kara wrote: > > > Yeah, I agree. I'm against ext4 private solution for this read problem. And > > I'm also against duplicating ->read_iter functionatily in ->read handler. > > The maintenance burden of this code dupl

RE: Expense of read_iter

2021-01-12 Thread David Laight
From: Zhongwei Cai > Sent: 12 January 2021 13:45 .. > The overhead mainly consists of two parts. The first is constructing > struct iov_iter and iterating it (i.e., new_sync, _copy_mc_to_iter and > iov_iter_init). The second is the dax io mechanism provided by VFS (i.e., > dax_iomap_rw, iomap_apply

RE: [RFC v2] nvfs: a filesystem for persistent memory

2021-01-11 Thread David Laight
From: Al Viro On Behalf Of Al Viro > Sent: 11 January 2021 14:44 > On Mon, Jan 11, 2021 at 11:57:08AM +, David Laight wrote: > > > > > size = copy_to_iter(to, ptr, size); > > > > > if (unlikely(!size)) { > &g

RE: [RFC v2] nvfs: a filesystem for persistent memory

2021-01-11 Thread David Laight
From: Mikulas Patocka > Sent: 11 January 2021 11:44 > On Mon, 11 Jan 2021, David Laight wrote: > > > From: Al Viro On Behalf Of Al Viro > > > Sent: 10 January 2021 16:20 ... ... > > > while (iov_iter_count(to)) { ... > > > size = copy_

RE: [RFC v2] nvfs: a filesystem for persistent memory

2021-01-11 Thread David Laight
From: Al Viro On Behalf Of Al Viro > Sent: 10 January 2021 16:20 > > On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote: > > Hi > > > > I announce a new version of NVFS - a filesystem for persistent memory. > > http://people.redhat.com/~mpatocka/nvfs/ > Utilities, AFAICS > > >

RE: Expense of read_iter

2021-01-11 Thread David Laight
From: Matthew Wilcox > Sent: 10 January 2021 06:13 ... > nvfs_rw_iter_locked() looks very complicated. I suspect it can > be simplified. Of course new_sync_read() needs to be improved too, > as do the other functions here, but fully a third of the difference > between read() and read_iter() is th

RE: [PATCH v2 2/9] fs: Introduce i_blocks_per_page

2020-09-15 Thread David Laight
From: Matthew Wilcox (Oracle) > Sent: 11 September 2020 00:47 > This helper is useful for both THPs and for supporting block size larger > than page size. Convert all users that I could find (we have a few > different ways of writing this idiom, and I may have missed some). > ... > diff --git a/f

RE: [PATCH v3 1/2] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

2020-05-20 Thread David Laight
> From: Dan Williams > > Sent: 20 May 2020 16:26 > ... > > > > +#ifdef CONFIG_ARCH_HAS_COPY_MC > > > > +extern unsigned long __must_check > > > > > > We try not to add extern in headers anymore. > > > > Ok, I was doing the copy-pasta dance, but I'll remove this. > > It is data not code, it needs t

RE: [PATCH v3 1/2] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

2020-05-20 Thread David Laight
From: Dan Williams > Sent: 20 May 2020 16:26 ... > > > +#ifdef CONFIG_ARCH_HAS_COPY_MC > > > +extern unsigned long __must_check > > > > We try not to add extern in headers anymore. > > Ok, I was doing the copy-pasta dance, but I'll remove this. It is data not code, it needs the extern to not be '

RE: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

2020-05-03 Thread David Laight
From: Linus Torvalds > Sent: 01 May 2020 19:29 ... > And as DavidL pointed out - if you ever have "iomem" as a source or > destination, you need yet another case. Not because they can take > another kind of fault (although on some platforms you have the machine > checks for that too), but because t

RE: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

2020-05-01 Thread David Laight
From: Andy Lutomirski > Sent: 30 April 2020 19:42 ... > I suppose there could be a consistent naming like this: > > copy_from_user() > copy_to_user() > > copy_from_unchecked_kernel_address() [what probe_kernel_read() is] > copy_to_unchecked_kernel_address() [what probe_kernel_write() is] > > cop

RE: [PATCH] libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overhead

2019-05-17 Thread David Laight
From: Kees Cook > Sent: 17 May 2019 16:54 ... > > I've changed some of our code to use __get_user() to avoid > > these stupid overheads. > > __get_user() skips even access_ok() checking too, so that doesn't seem > like a good idea. Did you run access_ok() checks separately? (This > generally isn't

RE: [PATCH] libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overhead

2019-05-17 Thread David Laight
From: Jan Kara > Sent: 17 May 2019 09:48 ... > So this last paragraph is not obvious to me as check_copy_size() does a lot > of various checks in CONFIG_HARDENED_USERCOPY case. I agree that some of > those checks don't make sense for PMEM pages but I'd rather handle that by > refining check_copy_si

RE: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

2018-03-14 Thread David Laight
From: Logan Gunthorpe > Sent: 13 March 2018 23:46 ... > As Stephen pointed out, it's a requirement of the PCIe spec that a > switch supports P2P. If you want to sell a switch that does P2P with bad > performance then that's on you to deal with. That surprises me (unless I missed something last tim

RE: Enabling peer to peer device transactions for PCIe devices

2017-10-24 Thread David Laight
Please don't top post, write shorter lines, and add the odd blank line. Big blocks of text are hard to read quickly. > From: Petrosyan, Ludwig [mailto:ludwig.petros...@desy.de] > Yes I agree it has to be started with the write transaction, according of > PCIe standard all write > transaction are

RE: Enabling peer to peer device transactions for PCIe devices

2017-10-23 Thread David Laight
From: Petrosyan Ludwig > Sent: 22 October 2017 07:14 > Could be I have done is stupid... > But at first sight it has to be simple: > The PCIe Write transactions are address routed, so if in the packet header > the other endpoint address > is written the TLP has to be routed (by PCIe Switch to the

RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

2017-04-18 Thread David Laight
From: Logan Gunthorpe > Sent: 13 April 2017 23:05 > Straightforward conversion to the new helper, except due to > the lack of error path, we have to warn if unmapable memory > is ever present in the sgl. > > Signed-off-by: Logan Gunthorpe > --- > drivers/block/xen-blkfront.c | 33 +++