On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote:
> This is a very subtle change to the exported UAPI header contents:
> On 64-bit architectures, the three unusable numbers are now always
> shown, rather than depending on a user-controlled symbol.
Well, the change is bigger and less
Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants. Another extra define is added for the packing required on
x86.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h | 16
-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h| 4
arch/mips/include/asm/compat.h | 4
arch/mips/include/uapi/asm/fcntl.h | 2 --
arch/powerpc/include/asm/compat.h | 4
arch/s390/include/asm/compat.h | 4
arch/sparc/include/asm/compat.h
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index ecd0f5bdfc1d6..caa482e3b01af 100644
Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/uapi/asm/fcntl.h | 26 +++---
include/uapi/asm-generic/fcntl.h
Hi all,
currenty the compat fcnt definitions are duplicate for all compat
architectures, and the native fcntl64 definitions aren't even usable
from userspace due to a bogus CONFIG_64BIT ifdef. This series tries
to sort out all that.
Diffstat:
arch/arm64/include/asm/compat.h| 20
Don't bother to define the symbols empty, just don't use them. That
makes the intent a little more clear.
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 12
tools/include/uapi/asm-generic/fcntl.h | 12
2 files changed, 8 insertions
On Mon, Jan 10, 2022 at 02:35:19PM +0100, Arnd Bergmann wrote:
> > +#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT)
> > #ifndef F_GETLK64
> > #define F_GETLK64 12 /* using 'struct flock64' */
> > #define F_SETLK64 13
>
> The problem here is that include/uapi/ headers
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Can you check if your tree already includes this commit:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.17/block=3f39d47d7ad858c024bd777f5f2a86fa7f6a9f14
and if not see if that fixes the problem?
Thanks,
applied to nvme-5.16.
65c24b596 ("powerpc: use the generic dma_ops_bypass mode")
> Signed-off-by: Alexey Kardashevskiy
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Sep 28, 2021 at 03:53:47PM +0530, Abdul Haleem wrote:
>
> On 9/1/21 7:06 PM, Christoph Hellwig wrote:
>> On Wed, Sep 01, 2021 at 04:47:26PM +0530, Abdul Haleem wrote:
>>> Greeting's
>>>
>>> multiple task hung while adding the vfc disk back to the
On Thu, Sep 23, 2021 at 10:26:47AM -0700, Ben Widawsky wrote:
> */
> static int siov_find_pci_dvsec(struct pci_dev *pdev)
> {
> + return pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_INTEL, 5);
> }
I hink the siov_find_pci_dvsec helper is pretty pointless now and can be
folded into its
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Because now we get architectures to all subly differ. Look at the mess
for ioremap and the ioremap*
On Wed, Sep 15, 2021 at 03:49:52PM +0200, Jan Beulich wrote:
> But the question remains: Why does the framebuffer need to be mapped
> in a single giant chunk?
More importantly: if you use dynamic dma mappings for your framebuffer
you're doing something wrong.
On Tue, Sep 14, 2021 at 05:29:07PM +0200, Jan Beulich wrote:
> I'm not convinced the swiotlb use describe there falls under "intended
> use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
> the bottom of this page is also confusing, as following "Then we can
> confirm the
On Mon, Aug 23, 2021 at 03:35:53PM +, Christophe Leroy wrote:
> In the same spirit as commit fb05121fd6a2 ("signal: Add
> unsafe_get_compat_sigset()"), implement an 'unsafe' version of
> copy_siginfo_to_user() in order to use it within user access blocks.
>
> For that, also add an 'unsafe'
On Mon, Aug 23, 2021 at 03:35:51PM +, Christophe Leroy wrote:
> Access the function descriptor of the handler within a
> user access block.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/signal_64.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
On Wed, Sep 01, 2021 at 04:47:26PM +0530, Abdul Haleem wrote:
> Greeting's
>
> multiple task hung while adding the vfc disk back to the multipath on my
> powerpc box running linux-next kernel
Can you retry to reproduce this with lockdep enabled to see if there
is anything interesting holding
Are you sure this is the very latest linux-next? This should hav been
fixed by:
"block: add back the bd_holder_dir reference in bd_link_disk_holder"
On Thu, Aug 19, 2021 at 01:33:09PM -0500, Tom Lendacky wrote:
> I did it as inline originally because the presence of the function will be
> decided based on the ARCH_HAS_PROTECTED_GUEST config. For now, that is
> only selected by the AMD memory encryption support, so if I went out of
> line I
On Fri, Aug 13, 2021 at 11:59:23AM -0500, Tom Lendacky wrote:
> +static inline bool prot_guest_has(unsigned int attr)
No reall need to have this inline. In fact I'd suggest we havea the
prototype in a common header so that everyone must implement it out
of line.
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
> While the name suggests this is intended mainly for guests, it will
> also be used for host memory encryption checks in place of sme_active().
Which suggest that the name is not good to start with. Maybe protected
hardware, system
On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
> +#define PATTR_MEM_ENCRYPT0 /* Encrypted memory */
> +#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted
> memory */
> +#define PATTR_GUEST_MEM_ENCRYPT 2 /* Guest encrypted
>
On Thu, Aug 12, 2021 at 10:14:25AM +0200, Uwe Kleine-K??nig wrote:
> dev_driver_string() might return "" (via dev_bus_name()). If that happens
> *drvstr == '\0' becomes true.
>
> Would the following be better?:
>
> const char *drvstr;
>
> if (pdev)
> return "";
>
>
On Wed, Aug 11, 2021 at 10:06:33AM +0200, Uwe Kleine-K??nig wrote:
> static inline const char *eeh_driver_name(struct pci_dev *pdev)
> {
> - return (pdev && pdev->driver) ? pdev->driver->name : "";
> + const char *drvstr = pdev ? dev_driver_string(>dev) : "";
> +
> + if (*drvstr ==
Thanks,
I've applied this to the dma-mapping tree with a few minor cosmetic
tweaks.
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
> Introduce an x86 version of the prot_guest_has() function. This will be
> used in the more generic x86 code to replace vendor specific calls like
> sev_active(), etc.
>
> While the name suggests this is intended mainly for
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky via iommu wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to
finally!
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote:
> Since these patches are now all that remains, it would be nice to
> merge it all through Andrew's Linux-mm tree, which is already based
> on top of linux-next.
Is it?
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bio-integrity.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/t10-pi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git
Rewrite the actual bounce buffering loop in __blk_queue_bounce to that
the memcpy_to_bvec helper can be used to perform the data copies.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bounce.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions
Use memcpy_from_bvec instead of open coding the logic.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/blk-map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-map.c b/block/blk-map.c
index 3743158ddaeb..d1448aaad980 100644
--- a/block
Use memcpy_to_bvec instead of opencoding the logic.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bounce.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/block/bounce.c b/block/bounce.c
index 94081e013c58..7e9e666c04dc
Use the proper helpers instead of open coding the copy.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bio.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 2e436bccb1e2..0c89fa2f7a85
These two helpers are entirely unused now.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
include/linux/bio.h | 42 --
1 file changed, 42 deletions(-)
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 2203b686e1f0
Use the bvec helpers instead of open coding the copy.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
Tested-by: Geoff Levand
---
drivers/block/ps3disk.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/block/ps3disk.c b/drivers
There is no need to disable interrupts in bio_copy_block, and the local
only mappings helps to avoid any sort of problems with stray writes
into the bio data.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
drivers/md/dm-writecache.c | 5 ++---
1
Use memzero_bvec instead of reimplementing it.
Signed-off-by: Christoph Hellwig
Acked-by: Ilya Dryomov
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
drivers/block/rbd.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/block/rbd.c b
Use memzero_bvec to zero each segment in the bio instead of manually
mapping and zeroing the data.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
block/bio.c | 9 ++---
1 file changed, 2 insertions(+), 7
Add helpers to perform common memory operation on a bvec.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 33 +
1 file changed, 33 insertions(+)
diff --git
Add a helper to call kmap_local_page on a bvec. There is no need for
an unmap helper given that kunmap_local accept any address in the mapped
page.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
include/linux
Fix the include guards to match the file naming.
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
There is no need to include genhd.h from a random arch header, and not
doing so prevents the possibility for nasty include loops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
arch/mips/include/asm/mach-rc32434
Hi all,
this series switches the core block layer code and all users of the
existing bvec kmap helpers to use kmap_local_page. Drivers that
currently use open coded kmap_atomic calls will converted in a follow
on series.
To do so a new kunmap variant is added that calls
> +int dma_map_sgtable(struct device *dev, struct sg_table *sgt,
> + enum dma_data_direction dir, unsigned long attrs)
> +{
> + int nents;
> +
> + nents = __dma_map_sg_attrs(dev, sgt->sgl, sgt->orig_nents, dir, attrs);
> + if (nents == 0)
> + return -EIO;
>
On Thu, Jul 22, 2021 at 05:23:51PM -0500, Bjorn Helgaas wrote:
> Marking both of these as "not applicable" for now because I don't
> think we really understand what's going on.
>
> Apparently a DMA occurs during suspend or resume and triggers an ACS
> violation. I don't think think such a DMA
> +
> +/*
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
> + * disables preemption so be careful if you intend to use it for long periods
> + * of time.
> + * TODO: If you intend to use the FPU in irq/softirq you need to check first
> with
> + * irq_fpu_usable()
On Wed, Jul 21, 2021 at 08:29:43AM +0200, Christian K??nig wrote:
> Looks good in general, but question is what about other architectures like
> ARM?
DRM_AMD_DC_DCN currently requires X86 || PPC64.
Maybe a good think would be to add a new KERNEL_FPU_API Kconfig symbol,
selected by x86 and
> #define DC_FP_END() kernel_fpu_end()
> #elif defined(CONFIG_PPC64)
> #include
> +#define DC_FP_START() kernel_fpu_begin()
> +#define DC_FP_END() kernel_fpu_end()
> #endif
Please use the same header as x86 in your first patch and then kill
this ifdefered and the DC_FP_START/DC_FP_END
On Mon, Jul 19, 2021 at 03:52:10PM -0400, Anson Jacob wrote:
> - Add kernel_fpu_begin & kernel_fpu_end API as x86
> - Add logic similar to x86 to ensure fpu
> begin/end call correctness
> - Add kernel_fpu_enabled to know if FPU is enabled
>
> Signed-off-by: Anson Jacob
All the x86 FPU support
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
> @@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
> scatterlist *sg,
> else
> ents = ops->map_sg(dev, sg, nents, dir, attrs);
>
> + WARN_ON_ONCE(ents == 0);
Turns this into a
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
> @@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
> scatterlist *sg, int nents,
> iommu_full(dev, pages << PAGE_SHIFT, dir);
> for_each_sg(sg, s, nents, i)
> s->dma_address =
Careful here. What do all these errors from the low-level code mean
here? I think we need to clearly standardize on what we actually
return from ->map_sg and possibly document what the callers expect and
can do, and enforce that only those error are reported.
On Thu, Jul 15, 2021 at 10:45:29AM -0600, Logan Gunthorpe wrote:
> + * dma_map_sgtable() will return the error code returned and convert
> + * a zero return (for legacy implementations) into -EINVAL.
> + *
> + * dma_map_sg() will always return zero on any negative or zero
> +
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> FWIW I was pondering the question of whether to do something along those
> lines or just scrap the default assignment entirely, so since I hadn't got
> round to saying that I've gone ahead and hacked up the alternative
> (similarly
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
> So at this point, the AMD IOMMU driver does:
>
> swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
>
> where 'swiotlb' is a global variable indicating whether or not swiotlb
> is in use. It's picked up a
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
>
> is_swiotlb_force_bounce() was the new function introduced in this patch here.
>
> +static inline bool is_swiotlb_force_bounce(struct device *dev)
> +{
> +
On Mon, Jun 21, 2021 at 10:59:20AM -0700, Stefano Stabellini wrote:
> Just as a clarification: I was referring to the zeroing of "mem" in
> swiotlb_late_init_with_tbl and swiotlb_init_with_tbl. While it looks
> like Tom and Christoph are talking about the zeroing of "tlb".
Indeed.
>
> The
On Fri, Jun 18, 2021 at 09:09:17AM -0500, Tom Lendacky wrote:
> > swiotlb_init_with_tbl uses memblock_alloc to allocate the io_tlb_mem
> > and memblock_alloc[1] will do memset in memblock_alloc_try_nid[2], so
> > swiotlb_init_with_tbl is also good.
> > I'm happy to add the memset in
On Mon, Jun 14, 2021 at 10:12:28AM +0100, Lee Jones wrote:
> On Mon, 07 Jun 2021, Christoph Hellwig wrote:
>
> > Please don't touch this code as it is about to be removed entirely.
>
> Do you have an ETA for this work?
I just resent the series.
t allocation needs remapping, one must set up
> another device coherent pool by shared-dma-pool and use
> dma_alloc_from_dev_coherent instead for atomic coherent allocation.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
Chang
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Jun 16, 2021 at 01:10:02PM +0800, Claire Chang wrote:
> On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > > Just noticed that after propagating swiotlb_force setting into
> &g
On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> Just noticed that after propagating swiotlb_force setting into
> io_tlb_default_mem->force, the memory allocation behavior for
> swiotlb_force will change (i.e. always skipping arch_dma_alloc and
> dma_direct_alloc_from_pool).
Yes, I
On Tue, Jun 15, 2021 at 05:47:44PM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 02.06.2021 08:53, Christoph Hellwig wrote:
> > Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> > allocation.
> >
> > Signed-off-by: Christoph Hellwig
>
herent allocation. Otherwise might break existing devices.
> + * One must set up another device coherent pool by shared-dma-pool and
> + * use dma_alloc_from_dev_coherent instead for atomic coherent
> + * allocation to avoid mempry remapping.
s/mempry/memory/g
Otherwise looks good:
Reviewed-by: Christoph Hellwig
ed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:06PM +0800, Claire Chang wrote:
> Rename find_slots to swiotlb_find_slots and move the maintenance of
> alloc_size to it for better code reusability later.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
Chang
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:04PM +0800, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:03PM +0800, Claire Chang wrote:
> Update is_swiotlb_buffer to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:01PM +0800, Claire Chang wrote:
> Split the debugfs creation to make the code reusable for supporting
> different bounce buffer pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:00PM +0800, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
Looks good,
Reviewed-by: Christoph Hellwig
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
---
block/bio-integrity.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/block/bio-integrity.c b/block/bio
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
---
block/t10-pi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/block/t10-pi.c b/block/t10-pi.c
index
Rewrite the actual bounce buffering loop in __blk_queue_bounce to that
the memcpy_to_bvec helper can be used to perform the data copies.
Signed-off-by: Christoph Hellwig
---
block/bounce.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/block/bounce.c b
Use memcpy_from_bvec instead of open coding the logic.
Signed-off-by: Christoph Hellwig
---
block/blk-map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-map.c b/block/blk-map.c
index 3743158ddaeb..d1448aaad980 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
Use memcpy_to_bvec instead of opencoding the logic.
Signed-off-by: Christoph Hellwig
---
block/bounce.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/block/bounce.c b/block/bounce.c
index 94081e013c58..7e9e666c04dc 100644
--- a/block/bounce.c
+++ b
Use the proper helpers instead of open coding the copy.
Signed-off-by: Christoph Hellwig
---
block/bio.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 1d7abdb83a39..c14d2e66c084 100644
--- a/block/bio.c
+++ b
These two helpers are entirely unused now.
Signed-off-by: Christoph Hellwig
---
include/linux/bio.h | 42 --
1 file changed, 42 deletions(-)
diff --git a/include/linux/bio.h b/include/linux/bio.h
index d2b98efb5cc5..8070f3f77c14 100644
--- a/include
Use the bvec helpers instead of open coding the copy.
Signed-off-by: Christoph Hellwig
---
drivers/block/ps3disk.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index f374ea2c67ce..b7d4c3efd7a8 100644
There is no need to disable interrupts in bio_copy_block, and the local
only mappings helps to avoid any sort of problems with stray writes
into the bio data.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
---
drivers/md/dm-writecache.c | 5 ++---
1 file changed, 2 insertions(+), 3
Use memzero_bvec instead of reimplementing it.
Signed-off-by: Christoph Hellwig
Acked-by: Ilya Dryomov
Reviewed-by: Ira Weiny
---
drivers/block/rbd.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index
Use memzero_bvec to zero each segment in the bio instead of manually
mapping and zeroing the data.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Ira Weiny
---
block/bio.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/block/bio.c b
Add helpers to perform common memory operation on a bvec.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/include/linux/bvec.h b/include
Add a helper to call kmap_local_page on a bvec. There is no need for
an unmap helper given that kunmap_local accept any address in the mapped
page.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 13 +
1 file
Fix the include guards to match the file naming.
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/bvec.h b
There is no need to include genhd.h from a random arch header, and not
doing so prevents the possibility for nasty include loops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Ira Weiny
---
arch/mips/include/asm/mach-rc32434/rb.h | 2 --
1 file changed, 2
No need for kmap_atomic here.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Ira Weiny
---
include/linux/highmem.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index d0497c0daf80
memcpy_to_page can write to potentially mapped page cache pages, so
use kunmap_local_dirty to make sure flush_kernel_dcache_pages is
called.
Signed-off-by: Christoph Hellwig
---
include/linux/highmem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/highmem.h b
-by: Christoph Hellwig
---
include/linux/highmem-internal.h | 7 +++
include/linux/highmem.h | 4
2 files changed, 11 insertions(+)
diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-internal.h
index 7902c7d8b55f..bd37706db147 100644
--- a/include/linux/highmem-internal.h
Hi all,
this series switches the core block layer code and all users of the
existing bvec kmap helpers to use kmap_local_page. Drivers that
currently use open coded kmap_atomic calls will converted in a follow
on series.
To do so a new kunmap variant is added that calls
301 - 400 of 2680 matches
Mail list logo
