Re: [PATCH] PCI: hisi: Fix Section mismatch compilation warning for probe()
On Thu, 12 Nov 2015 13:21:02 +0100
Arnd Bergmann wrote:
> On Thursday 12 November 2015 20:02:08 Jisheng Zhang wrote:
> > Following compilation warning occurs when compiled with:
> > CONFIG_DEBUG_SECTION_MISMATCH=y
> >
> > WARNING: drivers/pci/host/built-in.o(.data+0x308): Section mismatch in
> > reference from the variable hisi_pcie_driver to the function
> > .init.text:hisi_pcie_probe()
> >
> > Fix it by dropping __init from hisi_pcie_probe().
>
> The patch description should ideally say what the impact is here, not
> only what the warning says.
>
> > Signed-off-by: Jisheng Zhang
> > Fixes: 500a1d9a43e0 ("PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver")
> > ---
> > drivers/pci/host/pcie-hisi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
> > index 35457ec..1cc0a21 100644
> > --- a/drivers/pci/host/pcie-hisi.c
> > +++ b/drivers/pci/host/pcie-hisi.c
> > @@ -139,7 +139,7 @@ static int __init hisi_add_pcie_port(struct pcie_port
> > *pp,
> > return 0;
> > }
> >
> > -static int __init hisi_pcie_probe(struct platform_device *pdev)
> > +static int hisi_pcie_probe(struct platform_device *pdev)
> > {
> > struct hisi_pcie *hisi_pcie;
> > struct pcie_port *pp;
>
> This seems incomplete, you now get a new warning about hisi_add_pcie_port().
oops, yes. Thanks.
>
> I did a similar patch yesterday, will follow up with my version.
Your version is completed.
Thanks,
Jisheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Shut up unhandled MSR warnings
On 12/11/2015 13:16, Borislav Petkov wrote: >>> > > Yes, see guest_cpuid_has_* for an example of reading the CPUID values. >>> > > >>> > > But if it's defined for _all_ models starting at family 21, we can just >>> > > do it unconditionally. >> > >> > The thing is, those bits are Reserved again on the next family 22. Lemme >> > take a look at guest_cpuid_has_* and see how ugly it gets. > > Ok, I see there's guest_cpuid_is_amd() but I'd need also family and model. > > How about adding also > > guest_cpuid_family(), guest_cpuid_model(), guest_cpuid_stepping()? Those > could be quite useful in other contexts maybe. Sure, that's what I meant by "for an example". :) Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?
On Thu, Nov 12, 2015 at 02:27:29PM +0800, Mark yao wrote: > On 2015年11月11日 00:56, Thierry Reding wrote: > >On Tue, Nov 10, 2015 at 03:01:03PM +, Liviu Dudau wrote: > >>Hello, > >> > >>When booting my Juno board with the HDLCD driver that I have converted to > >>atomic operations I'm getting the following warning: > >Perhaps you can provide pointers to the source code, that might make it > >easier for people to spot what's going wrong. > > > >Thierry > > > > > >___ > >dri-devel mailing list > >dri-de...@lists.freedesktop.org > >http://lists.freedesktop.org/mailman/listinfo/dri-devel > Hi Thierry > I encountered the same problem as Liviu. > I'm coverting rockchip drm to atomic api, when booting with hdmi > connected, get under warning: > > [1.300156] WARNING: CPU: 0 PID: 26 at > drivers/gpu/drm/drm_atomic_helper.c:674 > drm_atomic_helper_update_legacy_modeset_state+0x3c/0x1f8() > [1.300161] Modules linked in: > [1.300171] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 4.3.0-rc5+ #160 > [1.300174] Hardware name: Rockchip (Device Tree) > [1.300189] Workqueue: events output_poll_execute > [1.300224] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [1.300241] [] (show_stack) from [] > (dump_stack+0x6c/0x88) > [1.300255] [] (dump_stack) from [] > (warn_slowpath_common+0x80/0xa8) > [1.300265] [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x18/0x1c) > [1.300277] [] (warn_slowpath_null) from [] > (drm_atomic_helper_update_legacy_modeset_state+0x3c/0x1f8) > [1.300293] [] (drm_atomic_helper_update_legacy_modeset_state) > from [] (drm_atomic_helper_commit_modeset_disables+0x208/0x364) > [1.300305] [] (drm_atomic_helper_commit_modeset_disables) from > [] (drm_atomic_helper_commit+0xf8/0x140) > [1.300320] [] (drm_atomic_helper_commit) from [] > (drm_atomic_commit+0x50/0x60) > [1.300333] [] (drm_atomic_commit) from [] > (restore_fbdev_mode+0xf4/0x278) > [1.300345] [] (restore_fbdev_mode) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x30/0x68) > [1.300357] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from > [] (drm_fb_helper_set_par+0x3c/0x54) > [1.300368] [] (drm_fb_helper_set_par) from [] > (drm_fb_helper_hotplug_event+0xe4/0xfc) > [1.300382] [] (drm_fb_helper_hotplug_event) from [] > (drm_kms_helper_hotplug_event+0x24/0x28) > [1.300396] [] (drm_kms_helper_hotplug_event) from [] > (output_poll_execute+0x134/0x18c) > [1.300413] [] (output_poll_execute) from [] > (process_one_work+0x1e0/0x318) > [1.300426] [] (process_one_work) from [] > (worker_thread+0x378/0x4c4) > [1.300438] [] (worker_thread) from [] > (kthread+0xdc/0xf0) > [1.300450] [] (kthread) from [] > (ret_from_fork+0x14/0x3c) > > I can't found who can set encoder->crtc value before atomic_commit, what's > going wrong? The explanation here is probably the same as the one I gave to Liviu. Does the below help? Thierry --- >8 --- diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index 56de9f1c95fc..ffef392ccc13 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -1648,8 +1648,6 @@ static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi) drm_connector_init(drm, &hdmi->connector, &dw_hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA); - hdmi->connector.encoder = encoder; - drm_mode_connector_attach_encoder(&hdmi->connector, encoder); return 0; signature.asc Description: PGP signature
Re: [PATCH 0/2] Introduce the request handling for dm-crypt
On Thu 12-11-15 19:46:26, Baolin Wang wrote: > On 12 November 2015 at 19:06, Jan Kara wrote: > > On Thu 12-11-15 17:40:59, Baolin Wang wrote: > >> On 12 November 2015 at 17:17, Jan Kara wrote: > >> > On Thu 12-11-15 10:15:32, Baolin Wang wrote: > >> >> On 11 November 2015 at 17:48, Christoph Hellwig > >> >> wrote: > >> >> > On Wed, Nov 11, 2015 at 05:31:43PM +0800, Baolin Wang wrote: > >> >> >> Now the dm-crypt code only implemented the 'based-bio' method to > >> >> >> encrypt/ > >> >> >> decrypt block data, which can only hanle one bio at one time. As we > >> >> >> know, > >> >> >> one bio must use the sequential physical address and it also has a > >> >> >> limitation > >> >> >> of length. Thus it may limit the big block encyrtion/decryption when > >> >> >> some > >> >> >> hardware support the big block data encryption. > >> >> >> > >> >> >> This patch series introduc the 'based-request' method to handle the > >> >> >> data > >> >> >> encryption/decryption. One request can contain multiple bios, so it > >> >> >> can > >> >> >> handle big block data to improve the efficiency. > >> >> > > >> >> > NAK for more request based stacking or DM drivers. They are a major > >> >> > pain to deal with, and adding more with different requirements then > >> >> > dm-multipath is not helping in actually making that one work properly. > >> >> > >> >> But now many vendors supply the hardware engine to handle the > >> >> encyrtion/decryption. The hardware really need a big block to indicate > >> >> its performance with request based things. Another thing is now the > >> >> request based things is used by many vendors (Qualcomm, Spreadtrum and > >> >> so on) to improve their performance and there's a real performance > >> >> requirement here (I can show the performance result later). > >> > > >> > So you've mentioned several times that hardware needs big blocks. How big > >> > those blocks need to be? Ideally, can you give some numbers on how the > >> > throughput of the encryption hw grows with the block size? > >> > >> It depends on the hardware design. My beaglebone black board's AES > >> engine can handle 1M at one time which is not big. As I know some > >> other AES engine can handle 16M data at one time or more. > > > > Well, one question is "can handle" and other question is how big gain in > > throughput it will bring compared to say 1M chunks. I suppose there's some > > constant overhead to issue a request to the crypto hw and by the time it is > > encrypting 1M it may be that this overhead is well amortized by the cost of > > the encryption itself which is in principle linear in the size of the > > block. That's why I'd like to get idea of the real numbers... > > Please correct me if I misunderstood your point. Let's suppose the AES > engine can handle 16M at one time. If we give the size of data is less > than 16M, the engine can handle it at one time. But if the data size > is 20M (more than 16M), the engine driver will split the data with 16M > and 4M to deal with. I can not say how many numbers, but I think the > engine is like to big chunks than small chunks which is the hardware > engine's advantage. No, I meant something different. I meant that if HW can encrypt 1M in say 1.05 ms and it can encrypt 16M in 16.05 ms, then although using 16 M blocks gives you some advantage it becomes diminishingly small. > >> > You mentioned that you use requests because of size limitations on bios > >> > - I > >> > had a look and current struct bio can easily describe 1MB requests > >> > (that's > >> > assuming 64-bit architecture, 4KB pages) when we have 1 page worth of > >> > struct bio_vec. Is that not enough? > >> > >> Usually one bio does not always use the full 1M, maybe some 1k/2k/8k > >> or some other small chunks. But request can combine some sequential > >> small bios to be a big block and it is better than bio at least. > > > > As Christoph mentions 4.3 should be better in submitting larger bios. Did > > you check it? > > I'm sorry I didn't check it. What's the limitation of one bio on 4.3? On 4.3 it is 1 MB (which should be enough because requests are limited to 512 KB by default anyway). Previously the maximum bio size depended on the queue parameters such as max number of segments etc. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: hisi: fix deferred probing
The hisi_pcie_probe function is incorrectly marked as __init, as Kconfig
tells us:
WARNING: drivers/pci/host/built-in.o(.data+0x7780): Section mismatch in
reference from the variable hisi_pcie_driver to the function
.init.text:hisi_pcie_probe()
If the probe for this device gets deferred past the point where __init
functions are removed, or the device is unbound and then reattached to
the driver, we branch into uninitialized memory, which is bad.
This removes the __init annotation.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 35457ecd8e70..163671a4f798 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -111,7 +111,7 @@ static struct pcie_host_ops hisi_pcie_host_ops = {
.link_up = hisi_pcie_link_up,
};
-static int __init hisi_add_pcie_port(struct pcie_port *pp,
+static int hisi_add_pcie_port(struct pcie_port *pp,
struct platform_device *pdev)
{
int ret;
@@ -139,7 +139,7 @@ static int __init hisi_add_pcie_port(struct pcie_port *pp,
return 0;
}
-static int __init hisi_pcie_probe(struct platform_device *pdev)
+static int hisi_pcie_probe(struct platform_device *pdev)
{
struct hisi_pcie *hisi_pcie;
struct pcie_port *pp;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] efi-pstore: implement efivars_pstore_exit()
On Wed, 11 Nov, at 11:23:15PM, Luck, Tony wrote: > >>> module_init(efivars_pstore_init); > >> > >> Looks OK to me. Kees, are you picking this up? > > > > I can, though usually it goes through Tony. > > Can I count that as "Acked-by" from both of you? Yep, Acked-by: Matt Fleming -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: hisi: Fix Section mismatch compilation warning for probe()
On Thursday 12 November 2015 20:02:08 Jisheng Zhang wrote:
> Following compilation warning occurs when compiled with:
> CONFIG_DEBUG_SECTION_MISMATCH=y
>
> WARNING: drivers/pci/host/built-in.o(.data+0x308): Section mismatch in
> reference from the variable hisi_pcie_driver to the function
> .init.text:hisi_pcie_probe()
>
> Fix it by dropping __init from hisi_pcie_probe().
The patch description should ideally say what the impact is here, not
only what the warning says.
> Signed-off-by: Jisheng Zhang
> Fixes: 500a1d9a43e0 ("PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver")
> ---
> drivers/pci/host/pcie-hisi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
> index 35457ec..1cc0a21 100644
> --- a/drivers/pci/host/pcie-hisi.c
> +++ b/drivers/pci/host/pcie-hisi.c
> @@ -139,7 +139,7 @@ static int __init hisi_add_pcie_port(struct pcie_port *pp,
> return 0;
> }
>
> -static int __init hisi_pcie_probe(struct platform_device *pdev)
> +static int hisi_pcie_probe(struct platform_device *pdev)
> {
> struct hisi_pcie *hisi_pcie;
> struct pcie_port *pp;
This seems incomplete, you now get a new warning about hisi_add_pcie_port().
I did a similar patch yesterday, will follow up with my version.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] virtio DMA API core stuff
On Thu, 2015-11-12 at 13:09 +0200, Michael S. Tsirkin wrote: > On Wed, Nov 11, 2015 at 11:30:27PM +0100, David Woodhouse wrote: > > > > If the IOMMU is exposed, and enabled, and telling the guest kernel that > > it *does* cover the virtio devices, then those virtio devices will > > *not* be in passthrough mode. > > This we need to fix. Because in most configurations if you are > using kernel drivers, then you don't want IOMMU with virtio, > but if you are using VFIO then you do. This is *absolutely* not specific to virtio. There are *plenty* of other users (especially networking) where we only really care about the existence of the IOMMU for VFIO purposes and assigning devices to guests, and we are willing to dispense with the protection that it offers for native in-kernel drivers. For that, boot with iommu=pt. There is no way, currently, to enable the passthrough mode on a per- device basis. Although it has been discussed right here, very recently. Let's not conflate those issues. > > You choosing to use the DMA API in the virtio device drivers instead of > > being buggy, has nothing to do with whether it's actually in > > passthrough mode or not. Whether it's in passthrough mode or not, using > > the DMA API is technically the right thing to do — because it should > > either *do* the translation, or return a 1:1 mapped IOVA, as > > appropriate. > > Right but first we need to actually make DMA API do the right thing > at least on x86,ppc and arm. It already does the right thing on x86, modulo BIOS bugs (including the qemu ACPI table but that you said you're not too worried about). > I'm not worried about qemu bugs that much. I am interested in being > able to use both VFIO and kernel drivers with virtio devices with good > performance and without tweaking kernel parameters. OK, then you are interested in the semi-orthogonal discussion about DMA_ATTR_IOMMU_BYPASS. Either way, device drivers SHALL use the DMA API. > > Having said that, if this were real hardware I'd just be blacklisting > > it and saying "Another BIOS with broken DMAR tables --> IOMMU > > completely disabled". So perhaps we should just do that. > > > Yes, once there is new QEMU where virtio is covered by the IOMMU, > that would be one way to address existing QEMU bugs. No, that's not required. All that's required is to fix the currently- broken ACPI table so that it *admits* that the virtio devices aren't covered by the IOMMU. And I've never waited for a fix to be available before, before blacklisting *other* broken firmwares... The only reason I'm holding off for now is because ARM and PPC also need a quirk for their platform code to realise that certain devices actually *aren't* covered by the IOMMU, and I might be able to just use the same thing and still enable the IOMMU in the offending qemu versions. Although as noted, it would need to cover assigned devices as well as virtio — qemu currently lies to us and tells us that the emulated IOMMU in the guest does cover *those* too. > With virt, each device can have different priveledges: > some are part of hypervisor so with a kernel driver > trying to get protection from them using an IOMMU which is also > part of hypervisor makes no sense > - but when using a > userspace driver then getting protection from the userspace > driver does make sense. Others are real devices so > getting protection from them makes some sense. > > Which is which? It's easiest for the device driver itself to > gain that knowledge. Please note this is *not* the same > question as whether a specific device is covered by an IOMMU. OK. How does your device driver know whether the virtio PCI device it's talking to is actually implemented by the hypervisor, or whether it's one of the real PCI implementations that apparently exist? > Linux doesn't seem to support that usecase at the moment, if this is a > generic problem then we need to teach Linux to solve it, but if virtio > is unique in this requirement, then we should just keep doing virtio > specific things to solve it. It is a generic problem. There is a discussion elsewhere about how (or indeed whether) to solve it. It absolutely isn't virtio-specific, and we absolutely shouldn't be doing virtio-specific things to solve it. Nothing excuses just eschewing the correct DMA API. That's just broken, and only ever worked in conjunction with *other* bugs elsewhere in the platform. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ARM: xip: Use correct symbol for end of ROM marker
On 11/11/2015 09:17 AM, Chris Brandt wrote: > For an XIP build, _edata_loc, not _etext, represents the end of the > binary image that will be programmed into ROM and mapped into the > MODULES_VADDR area. > With an XIP kernel, nothing is loaded into RAM before boot, meaning > you have to take into account the size of the entire binary image > that was programmed, including the init data values that will be copied > to RAM during kernel boot. > > This fixes the bug where you might lose the end of your kernel area > after page table setup is complete. > > > Signed-off-by: Chris Brandt > --- > arch/arm/mm/mmu.c |4 ++-- > include/asm-generic/sections.h |2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > index 4867f5d..dd5a56b 100644 > --- a/arch/arm/mm/mmu.c > +++ b/arch/arm/mm/mmu.c > @@ -1210,7 +1210,7 @@ static inline void prepare_page_table(void) > > #ifdef CONFIG_XIP_KERNEL > /* The XIP kernel is mapped in the module area -- skip over it */ > - addr = ((unsigned long)_etext + PMD_SIZE - 1) & PMD_MASK; > + addr = ((unsigned long)_edata_loc + PMD_SIZE - 1) & PMD_MASK; > #endif > for ( ; addr < PAGE_OFFSET; addr += PMD_SIZE) > pmd_clear(pmd_off_k(addr)); > @@ -1292,7 +1292,7 @@ static void __init devicemaps_init(const struct > machine_desc *mdesc) > #ifdef CONFIG_XIP_KERNEL > map.pfn = __phys_to_pfn(CONFIG_XIP_PHYS_ADDR & SECTION_MASK); > map.virtual = MODULES_VADDR; > - map.length = ((unsigned long)_etext - map.virtual + ~SECTION_MASK) & > SECTION_MASK; > + map.length = ((unsigned long)_edata_loc - map.virtual + ~SECTION_MASK) > & SECTION_MASK; > map.type = MT_ROM; > create_mapping(&map); > #endif > diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h > index b58fd66..195554d 100644 > --- a/include/asm-generic/sections.h > +++ b/include/asm-generic/sections.h > @@ -26,7 +26,7 @@ > * __ctors_start, __ctors_end > */ > extern char _text[], _stext[], _etext[]; > -extern char _data[], _sdata[], _edata[]; > +extern char _data[], _sdata[], _edata[], _edata_loc[]; > extern char __bss_start[], __bss_stop[]; > extern char __init_begin[], __init_end[]; > extern char _sinittext[], _einittext[]; > I think below is required as well. --- a/arch/arm/kernel/module.c +++ b/arch/arm/kernel/module.c @@ -34,7 +36,7 @@ * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off. */ #undef MODULES_VADDR -#define MODULES_VADDR (((unsigned long)_etext + ~PMD_MASK) & PMD_MASK) +#define MODULES_VADDR (((unsigned long)_edata_loc + ~PMD_MASK) & PMD_MASK) #endif Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?
On Wed, Nov 11, 2015 at 04:09:42PM +, Liviu Dudau wrote:
> On Tue, Nov 10, 2015 at 05:56:15PM +0100, Thierry Reding wrote:
> > On Tue, Nov 10, 2015 at 03:01:03PM +, Liviu Dudau wrote:
> > > Hello,
> > >
> > > When booting my Juno board with the HDLCD driver that I have converted to
> > > atomic operations I'm getting the following warning:
> >
> > Perhaps you can provide pointers to the source code, that might make it
> > easier for people to spot what's going wrong.
> >
> > Thierry
>
> Hi Thierry,
>
> I have just pushed to the mailing lists my patch series. [1] [2]
>
> If you want to checkout the code I also have a branch here:
>
> git://git://linux-arm.org/linux-ld testing/hdlcd
Okay, so if I understand correctly you're using the tda998x as encoder/
connector attached to your new HDLCD driver. I think the problem isn't
so much that nothing has set up the CRTC for the encoder, but rather
that the tda998x encoder tries to statically associate the encoder with
the connector. While that might be correct in that it represents the
hardware state (i.e. there is no way to physically route it anywhere
else), the DRM logical state is that it's not connected until a complete
pipeline has been set up, in which case a CRTC would have been assigned
to the encoder.
If your setup were working correctly you'd never reach the WARN_ON
because the
if (connector->encoder) {
conditional (on line 673 in drivers/gpu/drm/drm_atomic_helper.c) would
have evaluated to false already, since logically there'd be no encoder
associated with the connector yet.
Does the patch below help? Let me know and I can produce a proper patch.
Thierry
--- >8 ---
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 896b6aaf8c4d..8b0a402190eb 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1453,7 +1453,6 @@ static int tda998x_bind(struct device *dev, struct device
*master, void *data)
if (ret)
goto err_sysfs;
- priv->connector.encoder = &priv->encoder;
drm_mode_connector_attach_encoder(&priv->connector, &priv->encoder);
return 0;
signature.asc
Description: PGP signature
Re: Shut up unhandled MSR warnings
On Thu, Nov 12, 2015 at 11:59:58AM +0100, Borislav Petkov wrote: > On Thu, Nov 12, 2015 at 11:33:33AM +0100, Paolo Bonzini wrote: > > Yes, see guest_cpuid_has_* for an example of reading the CPUID values. > > > > But if it's defined for _all_ models starting at family 21, we can just > > do it unconditionally. > > The thing is, those bits are Reserved again on the next family 22. Lemme > take a look at guest_cpuid_has_* and see how ugly it gets. Ok, I see there's guest_cpuid_is_amd() but I'd need also family and model. How about adding also guest_cpuid_family(), guest_cpuid_model(), guest_cpuid_stepping()? Those could be quite useful in other contexts maybe. Or, I can do a single function which simply returns CPUID_1_EAX of the guest vcpu and caller can then pick stuff apart... Thoughts? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] arm64: make some functions static
These functions are only called within the its own file, so they could be declared static. Jisheng Zhang (3): arm64: smp: make of_parse_and_init_cpus static arm64: mmu: make split_pud and fixup_executable static arm64: suspend: make hw_breakpoint_restore static arch/arm64/kernel/smp.c | 2 +- arch/arm64/kernel/suspend.c | 2 +- arch/arm64/mm/mmu.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] arm64: smp: make of_parse_and_init_cpus static
of_parse_and_init_cpus is only called from within smp.c, so it can be
declared static.
Signed-off-by: Jisheng Zhang
---
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 2bbdc0e..b1adc51 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -473,7 +473,7 @@ acpi_parse_gic_cpu_interface(struct acpi_subtable_header
*header,
* cpu logical map array containing MPIDR values related to logical
* cpus. Assumes that cpu_logical_map(0) has already been initialized.
*/
-void __init of_parse_and_init_cpus(void)
+static void __init of_parse_and_init_cpus(void)
{
struct device_node *dn = NULL;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] arm64: suspend: make hw_breakpoint_restore static
hw_breakpoint_restore is only used within suspend.c, so it can be
declared static.
Signed-off-by: Jisheng Zhang
---
arch/arm64/kernel/suspend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index 40f7b33..fce95e1 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -41,7 +41,7 @@ void notrace __cpu_suspend_save(struct cpu_suspend_ctx *ptr,
* time the notifier runs debug exceptions might have been enabled already,
* with HW breakpoints registers content still in an unknown state.
*/
-void (*hw_breakpoint_restore)(void *);
+static void (*hw_breakpoint_restore)(void *);
void __init cpu_suspend_set_dbg_restorer(void (*hw_bp_restore)(void *))
{
/* Prevent multiple restore hook initializations */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arm64: mmu: make split_pud and fixup_executable static
split_pud and fixup_executable are only called from within mmu.c, so
they can be declared static.
Signed-off-by: Jisheng Zhang
---
arch/arm64/mm/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index c2fa6b5..02306c3 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -165,7 +165,7 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
} while (addr != end);
}
-void split_pud(pud_t *old_pud, pmd_t *pmd)
+static void split_pud(pud_t *old_pud, pmd_t *pmd)
{
unsigned long addr = pud_pfn(*old_pud) << PAGE_SHIFT;
pgprot_t prot = __pgprot(pud_val(*old_pud) ^ addr);
@@ -447,7 +447,7 @@ static void __init map_mem(void)
memblock_set_current_limit(MEMBLOCK_ALLOC_ANYWHERE);
}
-void __init fixup_executable(void)
+static void __init fixup_executable(void)
{
#ifdef CONFIG_DEBUG_RODATA
/* now that we are actually fully mapped, make the start/end more fine
grained */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10 V2] KVM: x86: MMU: Clean up x86's mmu code for future work
On 12/11/2015 12:48, Takuya Yoshikawa wrote: > v1->v2: > Patch 5 and 7 are added based on Paolo's suggestions. > Patch 8-10 are new. > > Patch 1/2/3/4: no change. > Patch 5: Needed a bit more work than I had expected. > Patch 6: Removed extra comment of v1 (patch 5 made it inappropriate). > Patch 7: As expected, many places needed to be converted. > Patch 8: This is new, but only a small change. > > Patch 9: Kind of an RFC (though I have checked it to some extent). > Following two places need to be carefully checked: > - in kvm_mmu_get_page: "if (!direct)" block after kvm_mmu_alloc_page() > - in FNAME(fetch): "if (FNAME(gpte_changed)(vcpu, gw, it.level - 1))" case > Patch 10: Trivial cleanup, assuming that patch 9 is correct. > > > In summary: patch 1-7 is the result of updating v1 based on the suggestions. > Although patch 5 does not look so nice than expected, this is the most > conservative approach, and patch 8-10 try to alleviate the sadness. If it works, it's actually better than what we have now. I'll review it in a few days. Marcelo, can you look at this as well? You are still king of MMU. :) Thanks, Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v7 4/7] PCI/ACPI: Add interface acpi_pci_root_create()
On Wed, Nov 11, 2015 at 09:55:37PM +0100, Arnd Bergmann wrote: > On Wednesday 11 November 2015 17:46:47 Lorenzo Pieralisi wrote: > > On Tue, Nov 10, 2015 at 01:50:46PM +0800, Jiang Liu wrote: > > If we go with this approach though, you are not adding the offset to > > the resource when parsing the memory spaces in acpi_decode_space(), are we > > sure that's what we really want ? > > > > In DT, a host bridge range has a: > > > > - CPU physical address > > - PCI bus address > > > > We use that to compute the offset between primary bus (ie CPU physical > > address) and secondary bus (ie PCI bus address). > > > > The value ending up in the PCI resource struct (for memory space) is > > the CPU physical address, if you do not add the offset in acpi_decode_space > > that does not hold true on platforms where CPU<->PCI offset != 0 on ACPI, > > am I wrong ? > > Sinan Kaya pointed out that SBSA mandates a 1:1 mapping for memory space. acpi_decode_space() is generic code though, it has to work on all arches, I was worried about triggering regressions on x86 and ia64 here. [...] > > To sum it up for a, say, DWordIo/Memory descriptor: > > > > - AddressMinimum, AddressMaximum represent the PCI bus addresses defining > > the resource start..end > > - AddressTranslation is the offset that has to be added to AddressMinimum > > and AddressMaximum to get the window in CPU physical address space > > > > So: > > > > - Either we go with the patch attached (but please check my comment on > > the memory spaces) > > - Or we patch acpi_pci_root_validate_resources() to amend the way > > IORESOURCE_IO is currently checked against ioport_resource, it can't > > work on arm64 at present, I described why above > > > > Thoughts appreciated it is time we got this sorted and thanks for > > the patch. > > The easiest way would be to assume that nobody is building a server > system that has multiple I/O spaces. SBSA explicitly makes I/O space > optional, and really the only reason anyone includes that feature these > days is for initializing GPUs through the BIOS POST method, so that > is not relevant for servers. Even when you do have multiple PCIe > host controllers that all support I/O space, the most logical implementation > would be to share one common space. > > If that fails, there are still two cases you have to care about, and > it really depends on what hardware makers decide to use here (and whether > we have any influence over them). The easier way for us to do this is > if every hardware sets up the mapping between CPU physical and PCI I/O > in a way that the I/O space numbers are non-overlapping between the > host controllers. That way we can still make Linux ioport_resource > addresses the same as PCI I/O space addresses (using io_offset=0), > with the downside being that only the first PCIe host (as enumerated > by the bootloader) can have I/O space addresses below 1024 that may > be required for ISA compatibility on some hardware. Yes, I think the approach we have in place on arm64 sound, I will work with Jiang to make sure we interpret and manage IO space on arm64 the same way we do with DT, I do not expect any issue on that side, I was more worried about the interpretation of ACPI tables, I really really do not want to end up with ACPI tables that are set-up in a way that can cause regressions, we have to agree (and make it crystal clear in the ACPI specs) what the resource descriptors define and how, then the ACPI kernel resource layer should be made compliant. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: hisi: Fix Section mismatch compilation warning for probe()
Following compilation warning occurs when compiled with:
CONFIG_DEBUG_SECTION_MISMATCH=y
WARNING: drivers/pci/host/built-in.o(.data+0x308): Section mismatch in
reference from the variable hisi_pcie_driver to the function
.init.text:hisi_pcie_probe()
Fix it by dropping __init from hisi_pcie_probe().
Signed-off-by: Jisheng Zhang
Fixes: 500a1d9a43e0 ("PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver")
---
drivers/pci/host/pcie-hisi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 35457ec..1cc0a21 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -139,7 +139,7 @@ static int __init hisi_add_pcie_port(struct pcie_port *pp,
return 0;
}
-static int __init hisi_pcie_probe(struct platform_device *pdev)
+static int hisi_pcie_probe(struct platform_device *pdev)
{
struct hisi_pcie *hisi_pcie;
struct pcie_port *pp;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] Stop Intel Processor Trace logging on panic
Ping, any comments on these patches? Thanks, Takao Indoh On 2015/11/04 14:22, Takao Indoh wrote: > Hi all, > > These patch series provide a feature to stop Intel Processor Trace > (Intel PT) logging and save its registers in the memory on panic. > > Intel PT is a new feature of Intel CPU "Broadwell", it captures > information about program execution flow. Here is a article about Intel > PT. > https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing > > Once Intel PT is enabled, the events which change program flow, like > branch instructions, exceptions, interruptions, traps and so on are > logged in the memory. This is very useful for debugging because we can > know the detailed behavior of software. > > When kernel panic occurs while you are running a perf command with Intel > PT (with -e intel_pt// option), these patches disable Intel PT and save > its registers in the memory. After crash dump is captured by kdump, you > can retrieve Intel PT log buffer from vmcore and investigate kernel > behavior. I have not made a tool yet to salvage Intel PT log buffer from > vmcore, but I'll do once these patches are accepted. > > changelog: > v2: > - Define function in intel_pt.h with static inline > > v1: > https://lkml.org/lkml/2015/10/28/136 > > > Background: > These patches are a part of patch series I posted before, the original > discussion is bellow. > > x86: Intel Processor Trace Logger > v1: https://lkml.org/lkml/2015/7/29/6 > v2: https://lkml.org/lkml/2015/9/8/24 > > The purpose of the original patches is introducing in-kernel logger > using Intel PT. To implement it I need to add some APIs to control perf > counter and ring buffer in kernel. Alexander Shishkin is working on such > APIs for his work to make use of Intel PT for process core dump. Apart > from such APIs, the feature to save Intel PT registers on panic is > helpful for normal perf command user as I described above, therefore I > separate the feature from original patches. > > Takao Indoh (2): >perf/x86/intel/pt: Add interface to stop Intel PT logging >x86: Stop Intel PT before kdump starts > > arch/x86/include/asm/intel_pt.h | 10 ++ > arch/x86/kernel/cpu/perf_event_intel_pt.c |9 + > arch/x86/kernel/crash.c | 11 +++ > 3 files changed, 30 insertions(+), 0 deletions(-) > create mode 100644 arch/x86/include/asm/intel_pt.h > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: firmware: psci: drop duplicate const from psci_of_match
This is to fix below sparse warning:
drivers/firmware/psci.c:427:40: warning: duplicate const
Signed-off-by: Jisheng Zhang
---
drivers/firmware/psci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index d24f35d..ae70d24 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -424,7 +424,7 @@ out_put_node:
return err;
}
-static const struct of_device_id const psci_of_match[] __initconst = {
+static const struct of_device_id psci_of_match[] __initconst = {
{ .compatible = "arm,psci", .data = psci_0_1_init},
{ .compatible = "arm,psci-0.2", .data = psci_0_2_init},
{ .compatible = "arm,psci-1.0", .data = psci_0_2_init},
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next RFC V3 0/3] basic busy polling support for vhost_net
Hi Jason, I understand your busy loop timeout is quite conservative at 50us. Did you try any other values? Also, did you measure how polling affects many VMs talking to each other (e.g. 20 VMs on each host, perhaps with several vNICs each, transmitting to a corresponding VM/vNIC pair on another host)? On a complete separate experiment (busy waiting on storage I/O rings on Xen), I have observed that bigger timeouts gave bigger benefits. On the other hand, all cases that contended for CPU were badly hurt with any sort of polling. The cases that contended for CPU consisted of many VMs generating workload over very fast I/O devices (in that case, several NVMe devices on a single host). And the metric that got affected was aggregate throughput from all VMs. The solution was to determine whether to poll depending on the host's overall CPU utilisation at that moment. That gave me the best of both worlds as polling made everything faster without slowing down any other metric. Thanks, Felipe On 12/11/2015 10:20, "kvm-ow...@vger.kernel.org on behalf of Jason Wang" wrote: > > >On 11/12/2015 06:16 PM, Jason Wang wrote: >> Hi all: >> >> This series tries to add basic busy polling for vhost net. The idea is >> simple: at the end of tx/rx processing, busy polling for new tx added >> descriptor and rx receive socket for a while. The maximum number of >> time (in us) could be spent on busy polling was specified ioctl. >> >> Test were done through: >> >> - 50 us as busy loop timeout >> - Netperf 2.6 >> - Two machines with back to back connected ixgbe >> - Guest with 1 vcpu and 1 queue >> >> Results: >> - For stream workload, ioexits were reduced dramatically in medium >> size (1024-2048) of tx (at most -39%) and almost all rx (at most >> -79%) as a result of polling. This compensate for the possible >> wasted cpu cycles more or less. That porbably why we can still see >> some increasing in the normalized throughput in some cases. >> - Throughput of tx were increased (at most 105%) expect for the huge >> write (16384). And we can send more packets in the case (+tpkts were >> increased). >> - Very minor rx regression in some cases. >> - Improvemnt on TCP_RR (at most 16%). > >Forget to mention, the following test results by order are: > >1) Guest TX >2) Guest RX >3) TCP_RR > >> size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ >>64/ 1/ +9%/ -17%/ +5%/ +10%/ -2% >>64/ 2/ +8%/ -18%/ +6%/ +10%/ -1% >>64/ 4/ +4%/ -21%/ +6%/ +10%/ -1% >>64/ 8/ +9%/ -17%/ +6%/ +9%/ -2% >> 256/ 1/ +20%/ -1%/ +15%/ +11%/ -9% >> 256/ 2/ +15%/ -6%/ +15%/ +8%/ -8% >> 256/ 4/ +17%/ -4%/ +16%/ +8%/ -8% >> 256/ 8/ -61%/ -69%/ +16%/ +10%/ -10% >> 512/ 1/ +15%/ -3%/ +19%/ +18%/ -11% >> 512/ 2/ +19%/0%/ +19%/ +13%/ -10% >> 512/ 4/ +18%/ -2%/ +18%/ +15%/ -10% >> 512/ 8/ +17%/ -1%/ +18%/ +15%/ -11% >> 1024/ 1/ +25%/ +4%/ +27%/ +16%/ -21% >> 1024/ 2/ +28%/ +8%/ +25%/ +15%/ -22% >> 1024/ 4/ +25%/ +5%/ +25%/ +14%/ -21% >> 1024/ 8/ +27%/ +7%/ +25%/ +16%/ -21% >> 2048/ 1/ +32%/ +12%/ +31%/ +22%/ -38% >> 2048/ 2/ +33%/ +12%/ +30%/ +23%/ -36% >> 2048/ 4/ +31%/ +10%/ +31%/ +24%/ -37% >> 2048/ 8/ +105%/ +75%/ +33%/ +23%/ -39% >> 16384/ 1/0%/ -14%/ +2%/0%/ +19% >> 16384/ 2/0%/ -13%/ +19%/ -13%/ +17% >> 16384/ 4/0%/ -12%/ +3%/0%/ +2% >> 16384/ 8/0%/ -11%/ -2%/ +1%/ +1% >> size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ >>64/ 1/ -7%/ -23%/ +4%/ +6%/ -74% >>64/ 2/ -2%/ -12%/ +2%/ +2%/ -55% >>64/ 4/ +2%/ -5%/ +10%/ -2%/ -43% >>64/ 8/ -5%/ -5%/ +11%/ -34%/ -59% >> 256/ 1/ -6%/ -16%/ +9%/ +11%/ -60% >> 256/ 2/ +3%/ -4%/ +6%/ -3%/ -28% >> 256/ 4/0%/ -5%/ -9%/ -9%/ -10% >> 256/ 8/ -3%/ -6%/ -12%/ -9%/ -40% >> 512/ 1/ -4%/ -17%/ -10%/ +21%/ -34% >> 512/ 2/0%/ -9%/ -14%/ -3%/ -30% >> 512/ 4/0%/ -4%/ -18%/ -12%/ -4% >> 512/ 8/ -1%/ -4%/ -1%/ -5%/ +4% >> 1024/ 1/0%/ -16%/ +12%/ +11%/ -10% >> 1024/ 2/0%/ -11%/0%/ +5%/ -31% >> 1024/ 4/0%/ -4%/ -7%/ +1%/ -22% >> 1024/ 8/ -5%/ -6%/ -17%/ -29%/ -79% >> 2048/ 1/0%/ -16%/ +1%/ +9%/ -10% >> 2048/ 2/0%/ -12%/ +7%/ +9%/ -26% >> 2048/ 4/0%/ -7%/ -4%/ +3%/ -64% >> 2048/ 8/ -1%/ -5%/ -6%/ +4%/ -20% >> 16384/ 1/0%/ -12%/ +11%/ +7%/ -20% >> 16384/ 2/0%/ -7%/ +1%/ +5%/ -26% >> 16384/ 4/0%/ -5%/ +12%/ +22%/ -23% >> 16384/ 8/0%/ -1%/ -8%/ +5%/ -3% >> size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ >> 1/ 1/ +9%/ -29%/ +9%/
[PATCH] KVM: arm/arm64: vgic: make vgic_io_ops static
vgic_io_ops is only referenced within vgic.c, so it can be declared
static.
Signed-off-by: Jisheng Zhang
---
virt/kvm/arm/vgic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 5335383..8ef7279 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -878,7 +878,7 @@ static int vgic_handle_mmio_write(struct kvm_vcpu *vcpu,
true);
}
-struct kvm_io_device_ops vgic_io_ops = {
+static struct kvm_io_device_ops vgic_io_ops = {
.read = vgic_handle_mmio_read,
.write = vgic_handle_mmio_write,
};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/2] arm64: Allow changing of attributes outside of modules
On 2015/11/11 9:57, Laura Abbott wrote:
> Currently, the set_memory_* functions that are implemented for arm64
> are restricted to module addresses only. This was mostly done
> because arm64 maps normal zone memory with larger page sizes to
> improve TLB performance. This has the side effect though of making it
> difficult to adjust attributes at the PAGE_SIZE granularity. There are
> an increasing number of use cases related to security where it is
> necessary to change the attributes of kernel memory. Add functionality
> to the page attribute changing code under a Kconfig to let systems
> designers decide if they want to make the trade off of security for TLB
> pressure.
>
> Signed-off-by: Laura Abbott
> ---
> v2: Re-worked to account for the full range of addresses. Will also just
> update the section blocks instead of splitting if the addresses are aligned
> properly.
> ---
> arch/arm64/Kconfig | 12
> arch/arm64/mm/mm.h | 3 +
> arch/arm64/mm/mmu.c | 2 +-
> arch/arm64/mm/pageattr.c | 174
> +--
> 4 files changed, 170 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 851fe11..46725e8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -521,6 +521,18 @@ config ARCH_HAS_CACHE_LINE_SIZE
>
> source "mm/Kconfig"
>
> +config DEBUG_CHANGE_PAGEATTR
> + bool "Allow all kernel memory to have attributes changed"
> + default y
> + help
> + If this option is selected, APIs that change page attributes
> + (RW <-> RO, X <-> NX) will be valid for all memory mapped in
> + the kernel space. The trade off is that there may be increased
> + TLB pressure from finer grained page mapping. Turn on this option
> + if security is more important than performance
> +
> + If in doubt, say Y
> +
> config SECCOMP
> bool "Enable seccomp to safely compute untrusted bytecode"
> ---help---
> diff --git a/arch/arm64/mm/mm.h b/arch/arm64/mm/mm.h
> index ef47d99..7b0dcc4 100644
> --- a/arch/arm64/mm/mm.h
> +++ b/arch/arm64/mm/mm.h
> @@ -1,3 +1,6 @@
> extern void __init bootmem_init(void);
>
> void fixup_init(void);
> +
> +void split_pud(pud_t *old_pud, pmd_t *pmd);
> +void split_pmd(pmd_t *pmd, pte_t *pte);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 496c3fd..9353e3c 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -73,7 +73,7 @@ static void __init *early_alloc(unsigned long sz)
> /*
> * remap a PMD into pages
> */
> -static void split_pmd(pmd_t *pmd, pte_t *pte)
> +void split_pmd(pmd_t *pmd, pte_t *pte)
> {
> unsigned long pfn = pmd_pfn(*pmd);
> unsigned long addr = pfn << PAGE_SHIFT;
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 3571c73..4a95fed 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -15,25 +15,162 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> -struct page_change_data {
> - pgprot_t set_mask;
> - pgprot_t clear_mask;
> -};
> +#include "mm.h"
>
> -static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long
> addr,
> - void *data)
> +static int update_pte_range(struct mm_struct *mm, pmd_t *pmd,
> + unsigned long addr, unsigned long end,
> + pgprot_t clear, pgprot_t set)
> {
> - struct page_change_data *cdata = data;
> - pte_t pte = *ptep;
> + pte_t *pte;
> + int err = 0;
> +
> + if (pmd_sect(*pmd)) {
> + if (!IS_ENABLED(CONFIG_DEBUG_CHANGE_PAGEATTR)) {
> + err = -EINVAL;
> + goto out;
> + }
> + pte = pte_alloc_one_kernel(&init_mm, addr);
> + if (!pte) {
> + err = -ENOMEM;
> + goto out;
> + }
> + split_pmd(pmd, pte);
> + __pmd_populate(pmd, __pa(pte), PMD_TYPE_TABLE);
> + }
> +
> +
> + pte = pte_offset_kernel(pmd, addr);
> + if (pte_none(*pte)) {
> + err = -EFAULT;
> + goto out;
> + }
> +
> + do {
> + pte_t p = *pte;
> +
> + p = clear_pte_bit(p, clear);
> + p = set_pte_bit(p, set);
> + set_pte(pte, p);
> +
> + } while (pte++, addr += PAGE_SIZE, addr != end);
> +
> +out:
> + return err;
> +}
> +
> +
> +static int update_pmd_range(struct mm_struct *mm, pud_t *pud,
> + unsigned long addr, unsigned long end,
> + pgprot_t clear, pgprot_t set)
> +{
> + pmd_t *pmd;
> + unsigned long next;
> + int err = 0;
> +
> + if (pud_sect(*pud)) {
> + if (!IS_ENABLED(CONFIG_DEBUG_CHANGE_PAGEATTR)) {
> + err = -EINVAL;
> + goto out;
> + }
> + pmd = pmd_alloc_one(&init_mm, addr);
>
[PATCH 1/2] FS-Cache: Add missing initialization of ret in cachefiles_write_page()
From: Geert Uytterhoeven
fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’:
fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in
this function
If the jump to label "error" is taken, "ret" will indeed be
uninitialized, and random stack data may be printed by the debug code.
Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately
beyond the EOF marker")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: David Howells
---
fs/cachefiles/rdwr.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index 7a6b02f72787..c0f3da3926a0 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -879,7 +879,7 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
loff_t pos, eof;
size_t len;
void *data;
- int ret;
+ int ret = -ENOBUFS;
ASSERT(op != NULL);
ASSERT(page != NULL);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MAINTAINERS: linux-cach...@redhat.com is moderated for non-subscribers
From: Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven Signed-off-by: David Howells --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 35fe7ae0492e..470605885f01 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2545,7 +2545,7 @@ F:arch/c6x/ CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS M: David Howells -L: linux-cach...@redhat.com +L: linux-cach...@redhat.com (moderated for non-subscribers) S: Supported F: Documentation/filesystems/caching/cachefiles.txt F: fs/cachefiles/ @@ -4558,7 +4558,7 @@ F:include/linux/frontswap.h FS-CACHE: LOCAL CACHING FOR NETWORK FILESYSTEMS M: David Howells -L: linux-cach...@redhat.com +L: linux-cach...@redhat.com (moderated for non-subscribers) S: Supported F: Documentation/filesystems/caching/ F: fs/fscache/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce the request handling for dm-crypt
On 12 November 2015 at 19:06, Jan Kara wrote: > On Thu 12-11-15 17:40:59, Baolin Wang wrote: >> On 12 November 2015 at 17:17, Jan Kara wrote: >> > On Thu 12-11-15 10:15:32, Baolin Wang wrote: >> >> On 11 November 2015 at 17:48, Christoph Hellwig >> >> wrote: >> >> > On Wed, Nov 11, 2015 at 05:31:43PM +0800, Baolin Wang wrote: >> >> >> Now the dm-crypt code only implemented the 'based-bio' method to >> >> >> encrypt/ >> >> >> decrypt block data, which can only hanle one bio at one time. As we >> >> >> know, >> >> >> one bio must use the sequential physical address and it also has a >> >> >> limitation >> >> >> of length. Thus it may limit the big block encyrtion/decryption when >> >> >> some >> >> >> hardware support the big block data encryption. >> >> >> >> >> >> This patch series introduc the 'based-request' method to handle the >> >> >> data >> >> >> encryption/decryption. One request can contain multiple bios, so it can >> >> >> handle big block data to improve the efficiency. >> >> > >> >> > NAK for more request based stacking or DM drivers. They are a major >> >> > pain to deal with, and adding more with different requirements then >> >> > dm-multipath is not helping in actually making that one work properly. >> >> >> >> But now many vendors supply the hardware engine to handle the >> >> encyrtion/decryption. The hardware really need a big block to indicate >> >> its performance with request based things. Another thing is now the >> >> request based things is used by many vendors (Qualcomm, Spreadtrum and >> >> so on) to improve their performance and there's a real performance >> >> requirement here (I can show the performance result later). >> > >> > So you've mentioned several times that hardware needs big blocks. How big >> > those blocks need to be? Ideally, can you give some numbers on how the >> > throughput of the encryption hw grows with the block size? >> >> It depends on the hardware design. My beaglebone black board's AES >> engine can handle 1M at one time which is not big. As I know some >> other AES engine can handle 16M data at one time or more. > > Well, one question is "can handle" and other question is how big gain in > throughput it will bring compared to say 1M chunks. I suppose there's some > constant overhead to issue a request to the crypto hw and by the time it is > encrypting 1M it may be that this overhead is well amortized by the cost of > the encryption itself which is in principle linear in the size of the > block. That's why I'd like to get idea of the real numbers... Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage. > >> > You mentioned that you use requests because of size limitations on bios - I >> > had a look and current struct bio can easily describe 1MB requests (that's >> > assuming 64-bit architecture, 4KB pages) when we have 1 page worth of >> > struct bio_vec. Is that not enough? >> >> Usually one bio does not always use the full 1M, maybe some 1k/2k/8k >> or some other small chunks. But request can combine some sequential >> small bios to be a big block and it is better than bio at least. > > As Christoph mentions 4.3 should be better in submitting larger bios. Did > you check it? I'm sorry I didn't check it. What's the limitation of one bio on 4.3? But I think it is better to choose a bigger one ( one request ) for crypto which is suitable for hardware engine. > > Honza > -- > Jan Kara > SUSE Labs, CR -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] FS-Cache: More miscellany
Attached are another couple of miscellaneous bits in FS-Cache and CacheFiles: (1) Fix an uninitialised error value. (2) In MAINTAINERS, mark the mailing list as being moderated for non-subscribers. These can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache-fixes David --- Geert Uytterhoeven (2): FS-Cache: Add missing initialization of ret in cachefiles_write_page() MAINTAINERS: linux-cach...@redhat.com is moderated for non-subscribers MAINTAINERS |4 ++-- fs/cachefiles/rdwr.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] FS-Cache: More miscellany
Let me resend this with the correct cc list. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] KVM: x86: MMU: Remove unused parameter parent_pte from kvm_mmu_get_page()
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 20 +++-
arch/x86/kvm/paging_tmpl.h | 4 ++--
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 33fe720..101e77d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2072,8 +2072,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
gva_t gaddr,
unsigned level,
int direct,
-unsigned access,
-u64 *parent_pte)
+unsigned access)
{
union kvm_mmu_page_role role;
unsigned quadrant;
@@ -2730,8 +2729,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write,
int map_writable,
base_addr &= PT64_LVL_ADDR_MASK(iterator.level);
pseudo_gfn = base_addr >> PAGE_SHIFT;
sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
- iterator.level - 1,
- 1, ACC_ALL, iterator.sptep);
+ iterator.level - 1, 1, ACC_ALL);
link_shadow_page(vcpu, iterator.sptep, sp, true);
}
@@ -3088,8 +3086,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
if (vcpu->arch.mmu.shadow_root_level == PT64_ROOT_LEVEL) {
spin_lock(&vcpu->kvm->mmu_lock);
make_mmu_pages_available(vcpu);
- sp = kvm_mmu_get_page(vcpu, 0, 0, PT64_ROOT_LEVEL,
- 1, ACC_ALL, NULL);
+ sp = kvm_mmu_get_page(vcpu, 0, 0, PT64_ROOT_LEVEL, 1, ACC_ALL);
++sp->root_count;
spin_unlock(&vcpu->kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = __pa(sp->spt);
@@ -3101,9 +3098,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
spin_lock(&vcpu->kvm->mmu_lock);
make_mmu_pages_available(vcpu);
sp = kvm_mmu_get_page(vcpu, i << (30 - PAGE_SHIFT),
- i << 30,
- PT32_ROOT_LEVEL, 1, ACC_ALL,
- NULL);
+ i << 30, PT32_ROOT_LEVEL, 1, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
spin_unlock(&vcpu->kvm->mmu_lock);
@@ -3140,7 +3135,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
spin_lock(&vcpu->kvm->mmu_lock);
make_mmu_pages_available(vcpu);
sp = kvm_mmu_get_page(vcpu, root_gfn, 0, PT64_ROOT_LEVEL,
- 0, ACC_ALL, NULL);
+ 0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
spin_unlock(&vcpu->kvm->mmu_lock);
@@ -3173,9 +3168,8 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
}
spin_lock(&vcpu->kvm->mmu_lock);
make_mmu_pages_available(vcpu);
- sp = kvm_mmu_get_page(vcpu, root_gfn, i << 30,
- PT32_ROOT_LEVEL, 0,
- ACC_ALL, NULL);
+ sp = kvm_mmu_get_page(vcpu, root_gfn, i << 30, PT32_ROOT_LEVEL,
+ 0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
spin_unlock(&vcpu->kvm->mmu_lock);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index f414ca6..ee9d211 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -587,7 +587,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
if (!is_shadow_present_pte(*it.sptep)) {
table_gfn = gw->table_gfn[it.level - 2];
sp = kvm_mmu_get_page(vcpu, table_gfn, addr, it.level-1,
- false, access, it.sptep);
+ false, access);
}
/*
@@ -617,7 +617,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
direct_gfn = gw->gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
- true, direct_access, it.sptep);
+ true, direct_access);
link_shadow_page(vcpu, it.sptep, sp, PT_GUEST_ACCESSED_MASK);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
[PATCH 1/2] FS-Cache: Add missing initialization of ret in cachefiles_write_page()
From: Geert Uytterhoeven
fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’:
fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in
this function
If the jump to label "error" is taken, "ret" will indeed be
uninitialized, and random stack data may be printed by the debug code.
Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately
beyond the EOF marker")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: David Howells
---
fs/cachefiles/rdwr.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index 7a6b02f72787..c0f3da3926a0 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -879,7 +879,7 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
loff_t pos, eof;
size_t len;
void *data;
- int ret;
+ int ret = -ENOBUFS;
ASSERT(op != NULL);
ASSERT(page != NULL);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10 RFC] KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()
Every time kvm_mmu_get_page() is called with a non-NULL parent_pte
argument, link_shadow_page() follows that to set the parent entry so
that the new mapping will point to the returned page table.
Moving parent_pte handling there allows to clean up the code because
parent_pte is passed to kvm_mmu_get_page() just for mark_unsync() and
mmu_page_add_parent_pte().
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 21 -
arch/x86/kvm/paging_tmpl.h | 6 ++
2 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 9273cd4..33fe720 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2108,14 +2108,9 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
if (sp->unsync_children) {
kvm_make_request(KVM_REQ_MMU_SYNC, vcpu);
kvm_mmu_mark_parents_unsync(sp);
- if (parent_pte)
- mark_unsync(parent_pte);
} else if (sp->unsync) {
kvm_mmu_mark_parents_unsync(sp);
- if (parent_pte)
- mark_unsync(parent_pte);
}
- mmu_page_add_parent_pte(vcpu, sp, parent_pte);
__clear_sp_write_flooding_count(sp);
trace_kvm_mmu_get_page(sp, false);
@@ -2127,7 +2122,6 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
sp = kvm_mmu_alloc_page(vcpu, direct);
sp->parent_ptes.val = 0;
- mmu_page_add_parent_pte(vcpu, sp, parent_pte);
sp->gfn = gfn;
sp->role = role;
@@ -2196,7 +2190,8 @@ static void shadow_walk_next(struct
kvm_shadow_walk_iterator *iterator)
return __shadow_walk_next(iterator, *iterator->sptep);
}
-static void link_shadow_page(u64 *sptep, struct kvm_mmu_page *sp, bool
accessed)
+static void link_shadow_page(struct kvm_vcpu *vcpu, u64 *sptep,
+struct kvm_mmu_page *sp, bool accessed)
{
u64 spte;
@@ -2210,6 +2205,11 @@ static void link_shadow_page(u64 *sptep, struct
kvm_mmu_page *sp, bool accessed)
spte |= shadow_accessed_mask;
mmu_spte_set(sptep, spte);
+
+ if (sp->unsync_children || sp->unsync)
+ mark_unsync(sptep);
+
+ mmu_page_add_parent_pte(vcpu, sp, sptep);
}
static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep,
@@ -2268,11 +2268,6 @@ static void kvm_mmu_page_unlink_children(struct kvm *kvm,
mmu_page_zap_pte(kvm, sp, sp->spt + i);
}
-static void kvm_mmu_put_page(struct kvm_mmu_page *sp, u64 *parent_pte)
-{
- mmu_page_remove_parent_pte(sp, parent_pte);
-}
-
static void kvm_mmu_unlink_parents(struct kvm *kvm, struct kvm_mmu_page *sp)
{
u64 *sptep;
@@ -2738,7 +2733,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write,
int map_writable,
iterator.level - 1,
1, ACC_ALL, iterator.sptep);
- link_shadow_page(iterator.sptep, sp, true);
+ link_shadow_page(vcpu, iterator.sptep, sp, true);
}
}
return emulate;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 9d21b44..f414ca6 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -598,7 +598,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
goto out_gpte_changed;
if (sp)
- link_shadow_page(it.sptep, sp, PT_GUEST_ACCESSED_MASK);
+ link_shadow_page(vcpu, it.sptep, sp,
PT_GUEST_ACCESSED_MASK);
}
for (;
@@ -618,7 +618,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
true, direct_access, it.sptep);
- link_shadow_page(it.sptep, sp, PT_GUEST_ACCESSED_MASK);
+ link_shadow_page(vcpu, it.sptep, sp, PT_GUEST_ACCESSED_MASK);
}
clear_sp_write_flooding_count(it.sptep);
@@ -629,8 +629,6 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
return emulate;
out_gpte_changed:
- if (sp)
- kvm_mmu_put_page(sp, it.sptep);
kvm_release_pfn_clean(pfn);
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MAINTAINERS: linux-cach...@redhat.com is moderated for non-subscribers
From: Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven Signed-off-by: David Howells --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 35fe7ae0492e..470605885f01 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2545,7 +2545,7 @@ F:arch/c6x/ CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS M: David Howells -L: linux-cach...@redhat.com +L: linux-cach...@redhat.com (moderated for non-subscribers) S: Supported F: Documentation/filesystems/caching/cachefiles.txt F: fs/cachefiles/ @@ -4558,7 +4558,7 @@ F:include/linux/frontswap.h FS-CACHE: LOCAL CACHING FOR NETWORK FILESYSTEMS M: David Howells -L: linux-cach...@redhat.com +L: linux-cach...@redhat.com (moderated for non-subscribers) S: Supported F: Documentation/filesystems/caching/ F: fs/fscache/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] KVM: x86: MMU: Move initialization of parent_ptes out from kvm_mmu_alloc_page()
Make kvm_mmu_alloc_page() do just what its name tells to do, and remove
the extra error check at its call site since the allocation cannot fail.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 85f4bbd..9273cd4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1707,8 +1707,7 @@ static void drop_parent_pte(struct kvm_mmu_page *sp,
mmu_spte_clear_no_track(parent_pte);
}
-static struct kvm_mmu_page *kvm_mmu_alloc_page(struct kvm_vcpu *vcpu,
- u64 *parent_pte, int direct)
+static struct kvm_mmu_page *kvm_mmu_alloc_page(struct kvm_vcpu *vcpu, int
direct)
{
struct kvm_mmu_page *sp;
@@ -1724,8 +1723,6 @@ static struct kvm_mmu_page *kvm_mmu_alloc_page(struct
kvm_vcpu *vcpu,
* this feature. See the comments in kvm_zap_obsolete_pages().
*/
list_add(&sp->link, &vcpu->kvm->arch.active_mmu_pages);
- sp->parent_ptes.val = 0;
- mmu_page_add_parent_pte(vcpu, sp, parent_pte);
kvm_mod_used_mmu_pages(vcpu->kvm, +1);
return sp;
}
@@ -2124,10 +2121,14 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
trace_kvm_mmu_get_page(sp, false);
return sp;
}
+
++vcpu->kvm->stat.mmu_cache_miss;
- sp = kvm_mmu_alloc_page(vcpu, parent_pte, direct);
- if (!sp)
- return sp;
+
+ sp = kvm_mmu_alloc_page(vcpu, direct);
+
+ sp->parent_ptes.val = 0;
+ mmu_page_add_parent_pte(vcpu, sp, parent_pte);
+
sp->gfn = gfn;
sp->role = role;
hlist_add_head(&sp->hash_link,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] FS-Cache: More miscellany
Attached are another couple of miscellaneous bits in FS-Cache and CacheFiles: (1) Fix an uninitialised error value. (2) In MAINTAINERS, mark the mailing list as being moderated for non-subscribers. These can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache-fixes David --- Geert Uytterhoeven (2): FS-Cache: Add missing initialization of ret in cachefiles_write_page() MAINTAINERS: linux-cach...@redhat.com is moderated for non-subscribers MAINTAINERS |4 ++-- fs/cachefiles/rdwr.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] KVM: x86: MMU: Encapsulate the type of rmap-chain head in a new struct
New struct kvm_rmap_head makes the code type-safe to some extent.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/include/asm/kvm_host.h | 8 +-
arch/x86/kvm/mmu.c | 169 +---
arch/x86/kvm/mmu_audit.c| 13 ++--
3 files changed, 100 insertions(+), 90 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0535359..c5a0c4a 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -214,6 +214,10 @@ union kvm_mmu_page_role {
};
};
+struct kvm_rmap_head {
+ unsigned long val;
+};
+
struct kvm_mmu_page {
struct list_head link;
struct hlist_node hash_link;
@@ -231,7 +235,7 @@ struct kvm_mmu_page {
bool unsync;
int root_count; /* Currently serving as active root */
unsigned int unsync_children;
- unsigned long parent_ptes; /* Reverse mapping for parent_pte */
+ struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
/* The page is obsolete if mmu_valid_gen != kvm->arch.mmu_valid_gen. */
unsigned long mmu_valid_gen;
@@ -604,7 +608,7 @@ struct kvm_lpage_info {
};
struct kvm_arch_memory_slot {
- unsigned long *rmap[KVM_NR_PAGE_SIZES];
+ struct kvm_rmap_head *rmap[KVM_NR_PAGE_SIZES];
struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
};
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ee7b101..85f4bbd 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -916,24 +916,24 @@ static int mapping_level(struct kvm_vcpu *vcpu, gfn_t
large_gfn,
*
*/
static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte,
- unsigned long *pte_list)
+ struct kvm_rmap_head *rmap_head)
{
struct pte_list_desc *desc;
int i, count = 0;
- if (!*pte_list) {
+ if (!rmap_head->val) {
rmap_printk("pte_list_add: %p %llx 0->1\n", spte, *spte);
- *pte_list = (unsigned long)spte;
- } else if (!(*pte_list & 1)) {
+ rmap_head->val = (unsigned long)spte;
+ } else if (!(rmap_head->val & 1)) {
rmap_printk("pte_list_add: %p %llx 1->many\n", spte, *spte);
desc = mmu_alloc_pte_list_desc(vcpu);
- desc->sptes[0] = (u64 *)*pte_list;
+ desc->sptes[0] = (u64 *)rmap_head->val;
desc->sptes[1] = spte;
- *pte_list = (unsigned long)desc | 1;
+ rmap_head->val = (unsigned long)desc | 1;
++count;
} else {
rmap_printk("pte_list_add: %p %llx many->many\n", spte, *spte);
- desc = (struct pte_list_desc *)(*pte_list & ~1ul);
+ desc = (struct pte_list_desc *)(rmap_head->val & ~1ul);
while (desc->sptes[PTE_LIST_EXT-1] && desc->more) {
desc = desc->more;
count += PTE_LIST_EXT;
@@ -950,8 +950,9 @@ static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte,
}
static void
-pte_list_desc_remove_entry(unsigned long *pte_list, struct pte_list_desc *desc,
- int i, struct pte_list_desc *prev_desc)
+pte_list_desc_remove_entry(struct kvm_rmap_head *rmap_head,
+ struct pte_list_desc *desc, int i,
+ struct pte_list_desc *prev_desc)
{
int j;
@@ -962,43 +963,43 @@ pte_list_desc_remove_entry(unsigned long *pte_list,
struct pte_list_desc *desc,
if (j != 0)
return;
if (!prev_desc && !desc->more)
- *pte_list = (unsigned long)desc->sptes[0];
+ rmap_head->val = (unsigned long)desc->sptes[0];
else
if (prev_desc)
prev_desc->more = desc->more;
else
- *pte_list = (unsigned long)desc->more | 1;
+ rmap_head->val = (unsigned long)desc->more | 1;
mmu_free_pte_list_desc(desc);
}
-static void pte_list_remove(u64 *spte, unsigned long *pte_list)
+static void pte_list_remove(u64 *spte, struct kvm_rmap_head *rmap_head)
{
struct pte_list_desc *desc;
struct pte_list_desc *prev_desc;
int i;
- if (!*pte_list) {
+ if (!rmap_head->val) {
printk(KERN_ERR "pte_list_remove: %p 0->BUG\n", spte);
BUG();
- } else if (!(*pte_list & 1)) {
+ } else if (!(rmap_head->val & 1)) {
rmap_printk("pte_list_remove: %p 1->0\n", spte);
- if ((u64 *)*pte_list != spte) {
+ if ((u64 *)rmap_head->val != spte) {
printk(KERN_ERR "pte_list_remove: %p 1->BUG\n", spte);
BUG();
}
- *pte_list = 0;
+ rmap_head->val = 0;
} else {
rmap_printk("pte_list_remove: %p many->many\n", spte);
-
[PATCH 06/10] KVM: x86: MMU: Consolidate WARN_ON/BUG_ON checks for reverse-mapped sptes
At some call sites of rmap_get_first() and rmap_get_next(), BUG_ON is
placed right after the call to detect unrelated sptes which must not be
found in the reverse-mapping list.
Move this check in rmap_get_first/next() so that all call sites, not
just the users of the for_each_rmap_spte() macro, will be checked the
same way. In addition, change the BUG_ON to WARN_ON since killing the
whole host is the last thing that KVM should try.
One thing to keep in mind is that kvm_mmu_unlink_parents() also uses
rmap_get_first() to handle parent sptes. The change will not break it
because parent sptes are present, at least until drop_parent_pte()
actually unlinks them, and not mmio-sptes.
Signed-off-by: Takuya Yoshikawa
---
Documentation/virtual/kvm/mmu.txt | 4 ++--
arch/x86/kvm/mmu.c| 26 +-
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/Documentation/virtual/kvm/mmu.txt
b/Documentation/virtual/kvm/mmu.txt
index 3a4d681..daf9c0f 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -203,10 +203,10 @@ Shadow pages contain the following information:
page cannot be destroyed. See role.invalid.
parent_ptes:
The reverse mapping for the pte/ptes pointing at this page's spt. If
-parent_ptes bit 0 is zero, only one spte points at this pages and
+parent_ptes bit 0 is zero, only one spte points at this page and
parent_ptes points at this single spte, otherwise, there exists multiple
sptes pointing at this page and (parent_ptes & ~0x1) points at a data
-structure with a list of parent_ptes.
+structure with a list of parent sptes.
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 1691171..ee7b101 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1079,17 +1079,23 @@ struct rmap_iterator {
*/
static u64 *rmap_get_first(unsigned long rmap, struct rmap_iterator *iter)
{
+ u64 *sptep;
+
if (!rmap)
return NULL;
if (!(rmap & 1)) {
iter->desc = NULL;
- return (u64 *)rmap;
+ sptep = (u64 *)rmap;
+ goto out;
}
iter->desc = (struct pte_list_desc *)(rmap & ~1ul);
iter->pos = 0;
- return iter->desc->sptes[iter->pos];
+ sptep = iter->desc->sptes[iter->pos];
+out:
+ WARN_ON(!is_shadow_present_pte(*sptep));
+ return sptep;
}
/*
@@ -1099,14 +1105,14 @@ static u64 *rmap_get_first(unsigned long rmap, struct
rmap_iterator *iter)
*/
static u64 *rmap_get_next(struct rmap_iterator *iter)
{
+ u64 *sptep;
+
if (iter->desc) {
if (iter->pos < PTE_LIST_EXT - 1) {
- u64 *sptep;
-
++iter->pos;
sptep = iter->desc->sptes[iter->pos];
if (sptep)
- return sptep;
+ goto out;
}
iter->desc = iter->desc->more;
@@ -1114,17 +1120,20 @@ static u64 *rmap_get_next(struct rmap_iterator *iter)
if (iter->desc) {
iter->pos = 0;
/* desc->sptes[0] cannot be NULL */
- return iter->desc->sptes[iter->pos];
+ sptep = iter->desc->sptes[iter->pos];
+ goto out;
}
}
return NULL;
+out:
+ WARN_ON(!is_shadow_present_pte(*sptep));
+ return sptep;
}
#define for_each_rmap_spte(_rmap_, _iter_, _spte_) \
for (_spte_ = rmap_get_first(*_rmap_, _iter_); \
- _spte_ && ({BUG_ON(!is_shadow_present_pte(*_spte_)); 1;}); \
- _spte_ = rmap_get_next(_iter_))
+ _spte_; _spte_ = rmap_get_next(_iter_))
static void drop_spte(struct kvm *kvm, u64 *sptep)
{
@@ -1338,7 +1347,6 @@ static bool kvm_zap_rmapp(struct kvm *kvm, unsigned long
*rmapp)
bool flush = false;
while ((sptep = rmap_get_first(*rmapp, &iter))) {
- BUG_ON(!(*sptep & PT_PRESENT_MASK));
rmap_printk("%s: spte %p %llx.\n", __func__, sptep, *sptep);
drop_spte(kvm, sptep);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/20] staging/wilc1000: pass hif operations through initialization
On Thursday 12 November 2015 19:05:41 glen lee wrote:
> Hi arnd,
>
> I appreciate the patches.
> I did test this patch series on h/w which is arm based MCU.
> From this patch wilc is not working properly. After downloading firmware,
> the firmware cannot start and it fails.
> I double check this patch and the previous one(14/20) which works fine.
> I cannot find the problem in this patch at the moment. I will see if I can
> find something,
> and I'd appreciate if you would help with it.
>
I've looked at it some more, but didn't find anything obvious, here are some
possible things I found:
> > -struct wilc_hif_func wilc_hif_sdio = {
> > - sdio_init,
> > - sdio_deinit,
> > - sdio_read_reg,
> > - sdio_write_reg,
> > - sdio_read,
> > - sdio_write,
> > - sdio_sync,
> > - sdio_clear_int,
> > - sdio_read_int,
> > - sdio_clear_int_ext,
> > - sdio_read_size,
> > - sdio_write,
> > - sdio_read,
> > - sdio_sync_ext,
> > -
> > - sdio_set_max_speed,
> > - sdio_set_default_speed,
> > +const struct wilc_hif_func wilc_hif_sdio = {
> > + .hif_init = sdio_init,
> > + .hif_deinit = sdio_deinit,
> > + .hif_read_reg = sdio_read_reg,
> > + .hif_write_reg = sdio_write_reg,
> > + .hif_block_rx = sdio_read,
> > + .hif_block_tx = sdio_write,
> > + .hif_sync = sdio_sync,
> > + .hif_clear_int = sdio_clear_int,
> > + .hif_read_int = sdio_read_int,
> > + .hif_clear_int_ext = sdio_clear_int_ext,
> > + .hif_read_size = sdio_read_size,
> > + .hif_block_rx_ext = sdio_write,
> > + .hif_block_tx_ext = sdio_read,
> > + .hif_sync_ext = sdio_sync_ext,
> > + .hif_set_max_bus_speed = sdio_set_max_speed,
> > + .hif_set_default_bus_speed = sdio_set_default_speed,
> > };
If the callbacks are not in the same order here, something could
in theory go wrong. I've tried to verify them by inspection and
could not find anything here, but you can try reverting this part.
> > memset((void *)&g_wlan, 0, sizeof(wilc_wlan_dev_t));
> > g_wlan.io_type = wilc->io_type;
> > -
> > -#ifdef WILC_SDIO
> > - if (!wilc_hif_sdio.hif_init(wilc, wilc_debug)) {
> > - ret = -EIO;
> > - goto _fail_;
> > - }
> > - memcpy((void *)&g_wlan.hif_func, &wilc_hif_sdio,
> > - sizeof(struct wilc_hif_func));
> > -#else
> > - if (!wilc_hif_spi.hif_init(wilc, wilc_debug)) {
> > + g_wlan.hif_func = *wilc->ops;
> > + if (!g_wlan.hif_func.hif_init(wilc, wilc_debug)) {
> > ret = -EIO;
> > goto _fail_;
> > }
> > - memcpy((void *)&g_wlan.hif_func, &wilc_hif_spi,
> > - sizeof(struct wilc_hif_func));
> > -#endif
This is the most likely part I found:
doing an assigment instead of memcpy should not make a difference,
but my new version also called init after copying over the
operations rather than before. This seemed to be the correct
order when I did it, but it is a change in behavior that might
cause problems if some code relies on the hif_func structure
to be empty at the time that hif_init is called.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk()
kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does
nearly the same as the for_each_rmap_spte macro. The only difference
is that is_shadow_present_pte() checks cannot be placed there because
kvm_mmu_mark_parents_unsync() can be called with a new parent pointer
whose entry is not set yet.
By calling mark_unsync() separately for the parent and adding the parent
pointer to the parent_ptes chain later in kvm_mmu_get_page(), the macro
works with no problem.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index e8cfdc4..1691171 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1007,26 +1007,6 @@ static void pte_list_remove(u64 *spte, unsigned long
*pte_list)
}
}
-typedef void (*pte_list_walk_fn) (u64 *spte);
-static void pte_list_walk(unsigned long *pte_list, pte_list_walk_fn fn)
-{
- struct pte_list_desc *desc;
- int i;
-
- if (!*pte_list)
- return;
-
- if (!(*pte_list & 1))
- return fn((u64 *)*pte_list);
-
- desc = (struct pte_list_desc *)(*pte_list & ~1ul);
- while (desc) {
- for (i = 0; i < PTE_LIST_EXT && desc->sptes[i]; ++i)
- fn(desc->sptes[i]);
- desc = desc->more;
- }
-}
-
static unsigned long *__gfn_to_rmap(gfn_t gfn, int level,
struct kvm_memory_slot *slot)
{
@@ -1741,7 +1721,12 @@ static struct kvm_mmu_page *kvm_mmu_alloc_page(struct
kvm_vcpu *vcpu,
static void mark_unsync(u64 *spte);
static void kvm_mmu_mark_parents_unsync(struct kvm_mmu_page *sp)
{
- pte_list_walk(&sp->parent_ptes, mark_unsync);
+ u64 *sptep;
+ struct rmap_iterator iter;
+
+ for_each_rmap_spte(&sp->parent_ptes, &iter, sptep) {
+ mark_unsync(sptep);
+ }
}
static void mark_unsync(u64 *spte)
@@ -2111,12 +2096,17 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
if (sp->unsync && kvm_sync_page_transient(vcpu, sp))
break;
- mmu_page_add_parent_pte(vcpu, sp, parent_pte);
if (sp->unsync_children) {
kvm_make_request(KVM_REQ_MMU_SYNC, vcpu);
kvm_mmu_mark_parents_unsync(sp);
- } else if (sp->unsync)
+ if (parent_pte)
+ mark_unsync(parent_pte);
+ } else if (sp->unsync) {
kvm_mmu_mark_parents_unsync(sp);
+ if (parent_pte)
+ mark_unsync(parent_pte);
+ }
+ mmu_page_add_parent_pte(vcpu, sp, parent_pte);
__clear_sp_write_flooding_count(sp);
trace_kvm_mmu_get_page(sp, false);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] X.509: Fix the time validation [ver #3]
This fixes CVE-2015-5327. It affects kernels from 4.3-rc1 onwards.
Fix the X.509 time validation to use month number-1 when looking up the
number of days in that month. Also put the month number validation before
doing the lookup so as not to risk overrunning the array.
This can be tested by doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
---
crypto/asymmetric_keys/x509_cert_parser.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 3000ea3b6687..021d39c0ba75 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -531,7 +531,11 @@ int x509_decode_time(time64_t *_t, size_t hdrlen,
if (*p != 'Z')
goto unsupported_time;
- mon_len = month_lengths[mon];
+ if (year < 1970 ||
+ mon < 1 || mon > 12)
+ goto invalid_time;
+
+ mon_len = month_lengths[mon - 1];
if (mon == 2) {
if (year % 4 == 0) {
mon_len = 29;
@@ -543,14 +547,12 @@ int x509_decode_time(time64_t *_t, size_t hdrlen,
}
}
- if (year < 1970 ||
- mon < 1 || mon > 12 ||
- day < 1 || day > mon_len ||
+ if (day < 1 || day > mon_len ||
hour > 23 ||
min > 59 ||
sec > 59)
goto invalid_time;
-
+
*_t = mktime64(year, mon, day, hour, min, sec);
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] KVM: x86: MMU: Remove is_rmap_spte() and use is_shadow_present_pte()
is_rmap_spte(), originally named is_rmap_pte(), was introduced when the
simple reverse mapping was implemented by commit cd4a4e5374110444
("[PATCH] KVM: MMU: Implement simple reverse mapping"). At that point,
its role was clear and only rmap_add() and rmap_remove() were using it
to select sptes that need to be reverse-mapped.
Independently of that, is_shadow_present_pte() was first introduced by
commit c7addb902054195b ("KVM: Allow not-present guest page faults to
bypass kvm") to do bypass_guest_pf optimization, which does not exist
any more.
These two seem to have changed their roles somewhat, and is_rmap_spte()
just calls is_shadow_present_pte() now.
Since using both of them with no clear distinction just makes the code
confusing, remove is_rmap_spte().
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 13 -
arch/x86/kvm/mmu_audit.c | 2 +-
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c229356..e8cfdc4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -311,11 +311,6 @@ static int is_large_pte(u64 pte)
return pte & PT_PAGE_SIZE_MASK;
}
-static int is_rmap_spte(u64 pte)
-{
- return is_shadow_present_pte(pte);
-}
-
static int is_last_spte(u64 pte, int level)
{
if (level == PT_PAGE_TABLE_LEVEL)
@@ -540,7 +535,7 @@ static bool mmu_spte_update(u64 *sptep, u64 new_spte)
u64 old_spte = *sptep;
bool ret = false;
- WARN_ON(!is_rmap_spte(new_spte));
+ WARN_ON(!is_shadow_present_pte(new_spte));
if (!is_shadow_present_pte(old_spte)) {
mmu_spte_set(sptep, new_spte);
@@ -595,7 +590,7 @@ static int mmu_spte_clear_track_bits(u64 *sptep)
else
old_spte = __update_clear_spte_slow(sptep, 0ull);
- if (!is_rmap_spte(old_spte))
+ if (!is_shadow_present_pte(old_spte))
return 0;
pfn = spte_to_pfn(old_spte);
@@ -2575,7 +2570,7 @@ static bool mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep, unsigned pte_access,
pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__,
*sptep, write_fault, gfn);
- if (is_rmap_spte(*sptep)) {
+ if (is_shadow_present_pte(*sptep)) {
/*
* If we overwrite a PTE page pointer with a 2MB PMD, unlink
* the parent of the now unreachable PTE.
@@ -2919,7 +2914,7 @@ static bool fast_page_fault(struct kvm_vcpu *vcpu, gva_t
gva, int level,
* If the mapping has been changed, let the vcpu fault on the
* same address again.
*/
- if (!is_rmap_spte(spte)) {
+ if (!is_shadow_present_pte(spte)) {
ret = true;
goto exit;
}
diff --git a/arch/x86/kvm/mmu_audit.c b/arch/x86/kvm/mmu_audit.c
index 03d518e..90ee420 100644
--- a/arch/x86/kvm/mmu_audit.c
+++ b/arch/x86/kvm/mmu_audit.c
@@ -183,7 +183,7 @@ static void check_mappings_rmap(struct kvm *kvm, struct
kvm_mmu_page *sp)
return;
for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
- if (!is_rmap_spte(sp->spt[i]))
+ if (!is_shadow_present_pte(sp->spt[i]))
continue;
inspect_spte_has_rmap(kvm, sp->spt + i);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] KVM: x86: MMU: Add helper function to clear a bit in unsync child bitmap
Both __mmu_unsync_walk() and mmu_pages_clear_parents() have three line
code which clears a bit in the unsync child bitmap; the former places it
inside a loop block and uses a few goto statements to jump to it.
A new helper function, clear_unsync_child_bit(), makes the code cleaner.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c3bbc82..f3120aa 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1806,6 +1806,13 @@ static int mmu_pages_add(struct kvm_mmu_pages *pvec,
struct kvm_mmu_page *sp,
return (pvec->nr == KVM_PAGE_ARRAY_NR);
}
+static inline void clear_unsync_child_bit(struct kvm_mmu_page *sp, int idx)
+{
+ --sp->unsync_children;
+ WARN_ON((int)sp->unsync_children < 0);
+ __clear_bit(idx, sp->unsync_child_bitmap);
+}
+
static int __mmu_unsync_walk(struct kvm_mmu_page *sp,
struct kvm_mmu_pages *pvec)
{
@@ -1815,8 +1822,10 @@ static int __mmu_unsync_walk(struct kvm_mmu_page *sp,
struct kvm_mmu_page *child;
u64 ent = sp->spt[i];
- if (!is_shadow_present_pte(ent) || is_large_pte(ent))
- goto clear_child_bitmap;
+ if (!is_shadow_present_pte(ent) || is_large_pte(ent)) {
+ clear_unsync_child_bit(sp, i);
+ continue;
+ }
child = page_header(ent & PT64_BASE_ADDR_MASK);
@@ -1825,28 +1834,21 @@ static int __mmu_unsync_walk(struct kvm_mmu_page *sp,
return -ENOSPC;
ret = __mmu_unsync_walk(child, pvec);
- if (!ret)
- goto clear_child_bitmap;
- else if (ret > 0)
+ if (!ret) {
+ clear_unsync_child_bit(sp, i);
+ continue;
+ } else if (ret > 0) {
nr_unsync_leaf += ret;
- else
+ } else
return ret;
} else if (child->unsync) {
nr_unsync_leaf++;
if (mmu_pages_add(pvec, child, i))
return -ENOSPC;
} else
-goto clear_child_bitmap;
-
- continue;
-
-clear_child_bitmap:
- __clear_bit(i, sp->unsync_child_bitmap);
- sp->unsync_children--;
- WARN_ON((int)sp->unsync_children < 0);
+ clear_unsync_child_bit(sp, i);
}
-
return nr_unsync_leaf;
}
@@ -2009,9 +2011,7 @@ static void mmu_pages_clear_parents(struct mmu_page_path
*parents)
if (!sp)
return;
- --sp->unsync_children;
- WARN_ON((int)sp->unsync_children < 0);
- __clear_bit(idx, sp->unsync_child_bitmap);
+ clear_unsync_child_bit(sp, idx);
level++;
} while (level < PT64_ROOT_LEVEL-1 && !sp->unsync_children);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] KVM: x86: MMU: Make mmu_set_spte() return emulate value
mmu_set_spte()'s code is based on the assumption that the emulate
parameter has a valid pointer value if set_spte() returns true and
write_fault is not zero. In other cases, emulate may be NULL, so a
NULL-check is needed.
Stop passing emulate pointer and make mmu_set_spte() return the emulate
value instead to clean up this complex interface. Prefetch functions
can just throw away the return value.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 27 ++-
arch/x86/kvm/paging_tmpl.h | 10 +-
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f3120aa..c229356 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2564,13 +2564,13 @@ done:
return ret;
}
-static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
-unsigned pte_access, int write_fault, int *emulate,
-int level, gfn_t gfn, pfn_t pfn, bool speculative,
-bool host_writable)
+static bool mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned
pte_access,
+int write_fault, int level, gfn_t gfn, pfn_t pfn,
+bool speculative, bool host_writable)
{
int was_rmapped = 0;
int rmap_count;
+ bool emulate = false;
pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__,
*sptep, write_fault, gfn);
@@ -2600,12 +2600,12 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep,
if (set_spte(vcpu, sptep, pte_access, level, gfn, pfn, speculative,
true, host_writable)) {
if (write_fault)
- *emulate = 1;
+ emulate = true;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
- if (unlikely(is_mmio_spte(*sptep) && emulate))
- *emulate = 1;
+ if (unlikely(is_mmio_spte(*sptep)))
+ emulate = true;
pgprintk("%s: setting spte %llx\n", __func__, *sptep);
pgprintk("instantiating %s PTE (%s) at %llx (%llx) addr %p\n",
@@ -2624,6 +2624,8 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep,
}
kvm_release_pfn_clean(pfn);
+
+ return emulate;
}
static pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
@@ -2658,9 +2660,8 @@ static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
return -1;
for (i = 0; i < ret; i++, gfn++, start++)
- mmu_set_spte(vcpu, start, access, 0, NULL,
-sp->role.level, gfn, page_to_pfn(pages[i]),
-true, true);
+ mmu_set_spte(vcpu, start, access, 0, sp->role.level, gfn,
+page_to_pfn(pages[i]), true, true);
return 0;
}
@@ -2721,9 +2722,9 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write,
int map_writable,
for_each_shadow_entry(vcpu, (u64)gfn << PAGE_SHIFT, iterator) {
if (iterator.level == level) {
- mmu_set_spte(vcpu, iterator.sptep, ACC_ALL,
-write, &emulate, level, gfn, pfn,
-prefault, map_writable);
+ emulate = mmu_set_spte(vcpu, iterator.sptep, ACC_ALL,
+ write, level, gfn, pfn, prefault,
+ map_writable);
direct_pte_prefetch(vcpu, iterator.sptep);
++vcpu->stat.pf_fixed;
break;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 3058a22..9d21b44 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -475,8 +475,8 @@ FNAME(prefetch_gpte)(struct kvm_vcpu *vcpu, struct
kvm_mmu_page *sp,
* we call mmu_set_spte() with host_writable = true because
* pte_prefetch_gfn_to_pfn always gets a writable pfn.
*/
- mmu_set_spte(vcpu, spte, pte_access, 0, NULL, PT_PAGE_TABLE_LEVEL,
-gfn, pfn, true, true);
+ mmu_set_spte(vcpu, spte, pte_access, 0, PT_PAGE_TABLE_LEVEL, gfn, pfn,
+true, true);
return true;
}
@@ -556,7 +556,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
struct kvm_mmu_page *sp = NULL;
struct kvm_shadow_walk_iterator it;
unsigned direct_access, access = gw->pt_access;
- int top_level, emulate = 0;
+ int top_level, emulate;
direct_access = gw->pte_access;
@@ -622,8 +622,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
}
clear_sp_write_flooding_count(it.sptep);
- mmu_set_spte(vcpu, it.sptep, gw->pte_access, write_fault, &emulate,
-it.level, gw->gfn, pfn, prefault, map_writable);
+ emulate = mmu_set_spte(vcpu, it.sptep, gw->pte_access
[PATCH 01/10] KVM: x86: MMU: Remove unused parameter of __direct_map()
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index e7c2c14..c3bbc82 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2708,9 +2708,8 @@ static void direct_pte_prefetch(struct kvm_vcpu *vcpu,
u64 *sptep)
__direct_pte_prefetch(vcpu, sp, sptep);
}
-static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, int write,
- int map_writable, int level, gfn_t gfn, pfn_t pfn,
- bool prefault)
+static int __direct_map(struct kvm_vcpu *vcpu, int write, int map_writable,
+ int level, gfn_t gfn, pfn_t pfn, bool prefault)
{
struct kvm_shadow_walk_iterator iterator;
struct kvm_mmu_page *sp;
@@ -3018,11 +3017,9 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t v,
u32 error_code,
make_mmu_pages_available(vcpu);
if (likely(!force_pt_level))
transparent_hugepage_adjust(vcpu, &gfn, &pfn, &level);
- r = __direct_map(vcpu, v, write, map_writable, level, gfn, pfn,
-prefault);
+ r = __direct_map(vcpu, write, map_writable, level, gfn, pfn, prefault);
spin_unlock(&vcpu->kvm->mmu_lock);
-
return r;
out_unlock:
@@ -3531,8 +3528,7 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t
gpa, u32 error_code,
make_mmu_pages_available(vcpu);
if (likely(!force_pt_level))
transparent_hugepage_adjust(vcpu, &gfn, &pfn, &level);
- r = __direct_map(vcpu, gpa, write, map_writable,
-level, gfn, pfn, prefault);
+ r = __direct_map(vcpu, write, map_writable, level, gfn, pfn, prefault);
spin_unlock(&vcpu->kvm->mmu_lock);
return r;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/10 V2] KVM: x86: MMU: Clean up x86's mmu code for future work
v1->v2: Patch 5 and 7 are added based on Paolo's suggestions. Patch 8-10 are new. Patch 1/2/3/4: no change. Patch 5: Needed a bit more work than I had expected. Patch 6: Removed extra comment of v1 (patch 5 made it inappropriate). Patch 7: As expected, many places needed to be converted. Patch 8: This is new, but only a small change. Patch 9: Kind of an RFC (though I have checked it to some extent). Following two places need to be carefully checked: - in kvm_mmu_get_page: "if (!direct)" block after kvm_mmu_alloc_page() - in FNAME(fetch): "if (FNAME(gpte_changed)(vcpu, gw, it.level - 1))" case Patch 10: Trivial cleanup, assuming that patch 9 is correct. In summary: patch 1-7 is the result of updating v1 based on the suggestions. Although patch 5 does not look so nice than expected, this is the most conservative approach, and patch 8-10 try to alleviate the sadness. Takuya Takuya Yoshikawa (10): 01: KVM: x86: MMU: Remove unused parameter of __direct_map() 02: KVM: x86: MMU: Add helper function to clear a bit in unsync child bitmap 03: KVM: x86: MMU: Make mmu_set_spte() return emulate value 04: KVM: x86: MMU: Remove is_rmap_spte() and use is_shadow_present_pte() 05: KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk() 06: KVM: x86: MMU: Consolidate WARN_ON/BUG_ON checks for reverse-mapped sptes 07: KVM: x86: MMU: Encapsulate the type of rmap-chain head in a new struct 08: KVM: x86: MMU: Move initialization of parent_ptes out from kvm_mmu_alloc_page() 09: KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page() 10: KVM: x86: MMU: Remove unused parameter parent_pte from kvm_mmu_get_page() Documentation/virtual/kvm/mmu.txt | 4 +- arch/x86/include/asm/kvm_host.h | 8 +- arch/x86/kvm/mmu.c| 357 ++ arch/x86/kvm/mmu_audit.c | 15 +- arch/x86/kvm/paging_tmpl.h| 20 +-- 5 files changed, 196 insertions(+), 208 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Drivers: hv: utils: fix memory leak on on_msg() failure
inmsg should be freed in case of on_msg() failure to avoid memory leak.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_utils_transport.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 24b2766..1d20451 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -77,6 +77,7 @@ static ssize_t hvt_op_write(struct file *file, const char
__user *buf,
{
struct hvutil_transport *hvt;
u8 *inmsg;
+ ssize_t ret = count;
hvt = container_of(file->f_op, struct hvutil_transport, fops);
@@ -85,10 +86,10 @@ static ssize_t hvt_op_write(struct file *file, const char
__user *buf,
return PTR_ERR(inmsg);
if (hvt->on_msg(inmsg, count))
- return -EFAULT;
+ ret = -EFAULT;
kfree(inmsg);
- return count;
+ return ret;
}
static unsigned int hvt_op_poll(struct file *file, poll_table *wait)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Drivers: hv: utils: prevent crash when a utility driver is disabled host side
I'm observing a crash when a utility driver is disabled host side (e.g. 'Guest services' is disabled live) when we have userspace daemon connected: [ 90.244859] general protection fault: [#1] SMP ... [ 90.800082] CPU: 3 PID: 473 Comm: hypervfcopyd Not tainted 4.3.0-rc7_netvsc_noalloc+ #1053 ... [ 90.800082] Call Trace: [ 90.800082] [] __fput+0xc8/0x1f0 [ 90.800082] [] fput+0xe/0x10 [ 90.800082] [] task_work_run+0x73/0x90 [ 90.800082] [] do_exit+0x335/0xa90 [ 90.800082] [] do_group_exit+0x3f/0xc0 [ 90.800082] [] get_signal+0x25e/0x5e0 [ 90.800082] [] do_signal+0x28/0x580 [ 90.800082] [] ? finish_task_switch+0xa6/0x180 [ 90.800082] [] ? __schedule+0x28f/0x870 [ 90.800082] [] ? hvt_op_read+0x12a/0x140 [hv_utils] [ 90.800082] [] ? wake_atomic_t_function+0x70/0x70 ... [ 90.800082] RIP [] module_put+0x16/0x90 [ 90.800082] RSP [ 95.734261] ---[ end trace 0e09af6a6294a668 ]--- The problem is that hvutil_transport_destroy() which does misc_deregister() freeing the appropriate device is reachable by two paths: module unload and from util_remove(). While module unload path is protected by .owner in struct file_operations util_remove() path is not. Freeing the device while someone holds an open fd for it is a show stopper. In general, it is not possible to revoke an fd from all users so the only way to solve the issue is to defer freeing the hvutil_transport structure asking the daemon to exit gracefully by responding -EBADF to all operations on unload. Patch 1 fixes an unrelated issue I spotted, patch 2 renames outmsg_lock to 'lock' as we're gonna use it to protect test-and-set operations on 'mode', patch 3 introduces HVUTIL_TRANSPORT_DESTROY mode of operation, patch 4 fixes the issue itself. Patches are rebased on previously sent Olaf's fixes. Vitaly Kuznetsov (4): Drivers: hv: utils: fix memory leak on on_msg() failure Drivers: hv: utils: rename outmsg_lock Drivers: hv: utils: introduce HVUTIL_TRANSPORT_DESTROY mode Drivers: hv: utils: fix crash when device is removed from host side drivers/hv/hv_utils_transport.c | 110 +++- drivers/hv/hv_utils_transport.h | 3 +- 2 files changed, 88 insertions(+), 25 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Drivers: hv: utils: rename outmsg_lock
As a preparation to reusing outmsg_lock to protect test-and-set openrations
on 'mode' rename it the more general 'lock'.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_utils_transport.c | 14 +++---
drivers/hv/hv_utils_transport.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 1d20451..5cce2d2 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -27,11 +27,11 @@ static struct list_head hvt_list = LIST_HEAD_INIT(hvt_list);
static void hvt_reset(struct hvutil_transport *hvt)
{
- mutex_lock(&hvt->outmsg_lock);
+ mutex_lock(&hvt->lock);
kfree(hvt->outmsg);
hvt->outmsg = NULL;
hvt->outmsg_len = 0;
- mutex_unlock(&hvt->outmsg_lock);
+ mutex_unlock(&hvt->lock);
if (hvt->on_reset)
hvt->on_reset();
}
@@ -47,7 +47,7 @@ static ssize_t hvt_op_read(struct file *file, char __user
*buf,
if (wait_event_interruptible(hvt->outmsg_q, hvt->outmsg_len > 0))
return -EINTR;
- mutex_lock(&hvt->outmsg_lock);
+ mutex_lock(&hvt->lock);
if (!hvt->outmsg) {
ret = -EAGAIN;
goto out_unlock;
@@ -68,7 +68,7 @@ static ssize_t hvt_op_read(struct file *file, char __user
*buf,
hvt->outmsg_len = 0;
out_unlock:
- mutex_unlock(&hvt->outmsg_lock);
+ mutex_unlock(&hvt->lock);
return ret;
}
@@ -197,7 +197,7 @@ int hvutil_transport_send(struct hvutil_transport *hvt,
void *msg, int len)
return ret;
}
/* HVUTIL_TRANSPORT_CHARDEV */
- mutex_lock(&hvt->outmsg_lock);
+ mutex_lock(&hvt->lock);
if (hvt->outmsg) {
/* Previous message wasn't received */
ret = -EFAULT;
@@ -211,7 +211,7 @@ int hvutil_transport_send(struct hvutil_transport *hvt,
void *msg, int len)
} else
ret = -ENOMEM;
out_unlock:
- mutex_unlock(&hvt->outmsg_lock);
+ mutex_unlock(&hvt->lock);
return ret;
}
@@ -242,7 +242,7 @@ struct hvutil_transport *hvutil_transport_init(const char
*name,
hvt->mdev.fops = &hvt->fops;
init_waitqueue_head(&hvt->outmsg_q);
- mutex_init(&hvt->outmsg_lock);
+ mutex_init(&hvt->lock);
spin_lock(&hvt_list_lock);
list_add(&hvt->list, &hvt_list);
diff --git a/drivers/hv/hv_utils_transport.h b/drivers/hv/hv_utils_transport.h
index 314c76c..bff4c92 100644
--- a/drivers/hv/hv_utils_transport.h
+++ b/drivers/hv/hv_utils_transport.h
@@ -38,7 +38,7 @@ struct hvutil_transport {
u8 *outmsg; /* message to the userspace */
int outmsg_len; /* its length */
wait_queue_head_t outmsg_q; /* poll/read wait queue */
- struct mutex outmsg_lock; /* protects outmsg */
+ struct mutex lock; /* protects struct members */
};
struct hvutil_transport *hvutil_transport_init(const char *name,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Drivers: hv: utils: introduce HVUTIL_TRANSPORT_DESTROY mode
When Hyper-V host asks us to remove some util driver by closing the
appropriate channel there is no easy way to force the current file
descriptor holder to hang up but we can start to respond -EBADF to all
operations asking it to exit gracefully.
As we're setting hvt->mode from two separate contexts now we need to use
a proper locking.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_utils_transport.c | 69 -
drivers/hv/hv_utils_transport.h | 1 +
2 files changed, 56 insertions(+), 14 deletions(-)
diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 5cce2d2..984cba5 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -27,11 +27,9 @@ static struct list_head hvt_list = LIST_HEAD_INIT(hvt_list);
static void hvt_reset(struct hvutil_transport *hvt)
{
- mutex_lock(&hvt->lock);
kfree(hvt->outmsg);
hvt->outmsg = NULL;
hvt->outmsg_len = 0;
- mutex_unlock(&hvt->lock);
if (hvt->on_reset)
hvt->on_reset();
}
@@ -44,10 +42,17 @@ static ssize_t hvt_op_read(struct file *file, char __user
*buf,
hvt = container_of(file->f_op, struct hvutil_transport, fops);
- if (wait_event_interruptible(hvt->outmsg_q, hvt->outmsg_len > 0))
+ if (wait_event_interruptible(hvt->outmsg_q, hvt->outmsg_len > 0 ||
+hvt->mode != HVUTIL_TRANSPORT_CHARDEV))
return -EINTR;
mutex_lock(&hvt->lock);
+
+ if (hvt->mode == HVUTIL_TRANSPORT_DESTROY) {
+ ret = -EBADF;
+ goto out_unlock;
+ }
+
if (!hvt->outmsg) {
ret = -EAGAIN;
goto out_unlock;
@@ -85,6 +90,9 @@ static ssize_t hvt_op_write(struct file *file, const char
__user *buf,
if (IS_ERR(inmsg))
return PTR_ERR(inmsg);
+ if (hvt->mode == HVUTIL_TRANSPORT_DESTROY)
+ return -EBADF;
+
if (hvt->on_msg(inmsg, count))
ret = -EFAULT;
kfree(inmsg);
@@ -99,6 +107,10 @@ static unsigned int hvt_op_poll(struct file *file,
poll_table *wait)
hvt = container_of(file->f_op, struct hvutil_transport, fops);
poll_wait(file, &hvt->outmsg_q, wait);
+
+ if (hvt->mode == HVUTIL_TRANSPORT_DESTROY)
+ return -EBADF;
+
if (hvt->outmsg_len > 0)
return POLLIN | POLLRDNORM;
@@ -108,26 +120,39 @@ static unsigned int hvt_op_poll(struct file *file,
poll_table *wait)
static int hvt_op_open(struct inode *inode, struct file *file)
{
struct hvutil_transport *hvt;
+ int ret = 0;
+ bool issue_reset = false;
hvt = container_of(file->f_op, struct hvutil_transport, fops);
- /*
-* Switching to CHARDEV mode. We switch bach to INIT when device
-* gets released.
-*/
- if (hvt->mode == HVUTIL_TRANSPORT_INIT)
+ mutex_lock(&hvt->lock);
+
+ if (hvt->mode == HVUTIL_TRANSPORT_DESTROY) {
+ ret = -EBADF;
+ } else if (hvt->mode == HVUTIL_TRANSPORT_INIT) {
+ /*
+* Switching to CHARDEV mode. We switch bach to INIT when
+* device gets released.
+*/
hvt->mode = HVUTIL_TRANSPORT_CHARDEV;
+ }
else if (hvt->mode == HVUTIL_TRANSPORT_NETLINK) {
/*
* We're switching from netlink communication to using char
* device. Issue the reset first.
*/
- hvt_reset(hvt);
+ issue_reset = true;
hvt->mode = HVUTIL_TRANSPORT_CHARDEV;
- } else
- return -EBUSY;
+ } else {
+ ret = -EBUSY;
+ }
- return 0;
+ if (issue_reset)
+ hvt_reset(hvt);
+
+ mutex_unlock(&hvt->lock);
+
+ return ret;
}
static int hvt_op_release(struct inode *inode, struct file *file)
@@ -136,12 +161,15 @@ static int hvt_op_release(struct inode *inode, struct
file *file)
hvt = container_of(file->f_op, struct hvutil_transport, fops);
- hvt->mode = HVUTIL_TRANSPORT_INIT;
+ mutex_lock(&hvt->lock);
+ if (hvt->mode != HVUTIL_TRANSPORT_DESTROY)
+ hvt->mode = HVUTIL_TRANSPORT_INIT;
/*
* Cleanup message buffers to avoid spurious messages when the daemon
* connects back.
*/
hvt_reset(hvt);
+ mutex_unlock(&hvt->lock);
return 0;
}
@@ -168,6 +196,7 @@ static void hvt_cn_callback(struct cn_msg *msg, struct
netlink_skb_parms *nsp)
* Switching to NETLINK mode. Switching to CHARDEV happens when someone
* opens the device.
*/
+ mutex_lock(&hvt->lock);
if (hvt->mode == HVUTIL_TRANSPORT_INIT)
hvt->mode = HVUTIL_TRANSPORT_NETLINK;
@@ -175,6 +204,7 @@ static void hvt_cn_callback(struct cn_msg *msg, struct
netl
[PATCH 4/4] Drivers: hv: utils: fix crash when device is removed from host side
The crash is observed when a service is being disabled host side while
userspace daemon is connected to the device:
[ 90.244859] general protection fault: [#1] SMP
...
[ 90.800082] Call Trace:
[ 90.800082] [] __fput+0xc8/0x1f0
[ 90.800082] [] fput+0xe/0x10
...
[ 90.800082] [] do_signal+0x28/0x580
[ 90.800082] [] ? finish_task_switch+0xa6/0x180
[ 90.800082] [] ? __schedule+0x28f/0x870
[ 90.800082] [] ? hvt_op_read+0x12a/0x140 [hv_utils]
...
The problem is that hvutil_transport_destroy() which does misc_deregister()
freeing the appropriate device is reachable by two paths: module unload
and from util_remove(). While module unload path is protected by .owner in
struct file_operations util_remove() path is not. Freeing the device while
someone holds an open fd for it is a show stopper.
In general, it is not possible to revoke an fd from all users so the only
way to solve the issue is to defer freeing the hvutil_transport structure.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_utils_transport.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 984cba5..174c72a 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -155,13 +155,22 @@ static int hvt_op_open(struct inode *inode, struct file
*file)
return ret;
}
+static void hvt_transport_free(struct hvutil_transport *hvt)
+{
+ misc_deregister(&hvt->mdev);
+ kfree(hvt->outmsg);
+ kfree(hvt);
+}
+
static int hvt_op_release(struct inode *inode, struct file *file)
{
struct hvutil_transport *hvt;
+ int mode_old;
hvt = container_of(file->f_op, struct hvutil_transport, fops);
mutex_lock(&hvt->lock);
+ mode_old = hvt->mode;
if (hvt->mode != HVUTIL_TRANSPORT_DESTROY)
hvt->mode = HVUTIL_TRANSPORT_INIT;
/*
@@ -171,6 +180,9 @@ static int hvt_op_release(struct inode *inode, struct file
*file)
hvt_reset(hvt);
mutex_unlock(&hvt->lock);
+ if (mode_old == HVUTIL_TRANSPORT_DESTROY)
+ hvt_transport_free(hvt);
+
return 0;
}
@@ -304,17 +316,25 @@ err_free_hvt:
void hvutil_transport_destroy(struct hvutil_transport *hvt)
{
+ int mode_old;
+
mutex_lock(&hvt->lock);
+ mode_old = hvt->mode;
hvt->mode = HVUTIL_TRANSPORT_DESTROY;
wake_up_interruptible(&hvt->outmsg_q);
mutex_unlock(&hvt->lock);
+ /*
+* In case we were in 'chardev' mode we still have an open fd so we
+* have to defer freeing the device. Netlink interface can be freed
+* now.
+*/
spin_lock(&hvt_list_lock);
list_del(&hvt->list);
spin_unlock(&hvt_list_lock);
if (hvt->cn_id.idx > 0 && hvt->cn_id.val > 0)
cn_del_callback(&hvt->cn_id);
- misc_deregister(&hvt->mdev);
- kfree(hvt->outmsg);
- kfree(hvt);
+
+ if (mode_old != HVUTIL_TRANSPORT_CHARDEV)
+ hvt_transport_free(hvt);
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] null_blk: Register as a LightNVM device
On 11/11/2015 11:11 PM, Jens Axboe wrote:
On 11/11/2015 02:27 PM, Jens Axboe wrote:
On 11/11/2015 03:06 AM, Matias Bjørling wrote:
Add support for registering as a LightNVM device. This allows us to
evaluate the performance of the LightNVM library.
In /drivers/Makefile, LightNVM is moved above block device drivers
to make sure that the LightNVM media managers have been initialized
before drivers under /drivers/block are initialized.
Generally looks ok. One question:
+static void *null_lnvm_create_dma_pool(struct request_queue *q, char
*name)
+{
+mempool_t *virtmem_pool;
+
+ppa_cache = kmem_cache_create(name, PAGE_SIZE, 0, 0, NULL);
+if (!ppa_cache) {
+pr_err("null_nvm: Unable to create kmem cache\n");
+return NULL;
+}
+
+virtmem_pool = mempool_create_slab_pool(64, ppa_cache);
+if (!virtmem_pool) {
+pr_err("null_nvm: Unable to create virtual memory pool\n");
+return NULL;
+}
+
+return virtmem_pool;
+}
Why create a slab cache if it's pages? Why not just have the mempool
alloc/free alloc single pages?
Ala attached. Also fixes a leak of not freeing the ppa_cache slab cache.
Did you try and load/reload the module? I'm thinking it would have crashed.
Good idea. I'll apply it. Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/6] xen/arm: introduce xen_read_wallclock
On Wed, 11 Nov 2015, Arnd Bergmann wrote:
> On Wednesday 11 November 2015 16:51:35 Stefano Stabellini wrote:
> > +static void xen_read_wallclock(struct timespec64 *ts)
> > +{
> > + u32 version;
> > + u64 delta;
> > + struct timespec64 now;
> > + struct shared_info *s = HYPERVISOR_shared_info;
> > + struct pvclock_wall_clock *wall_clock = &(s->wc);
> > +
> > + /* get wallclock at system boot */
> > + do {
> > + version = wall_clock->version;
> > + rmb(); /* fetch version before time */
> > + now.tv_sec = ((uint64_t)wall_clock->sec_hi << 32) |
> > wall_clock->sec;
> > + now.tv_nsec = wall_clock->nsec;
> > + rmb(); /* fetch time before checking version */
> > + } while ((wall_clock->version & 1) || (version !=
> > wall_clock->version));
> > +
> > + /* time since system boot */
> > + delta = ktime_get_ns();
> > + delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
> > +
> > + *ts = ns_to_timespec64(delta);
> > +}
>
> Looks correct to me and better than the previous versions, but you are still
> converting from timespec64 to nanoseconds and back. While I previously
> recommended going all the way to nanoseconds here, I guess this you
> can even avoid the ns_to_timespec64() if you stay within timespec64
> domain and replace the last lines with
>
> ktime_get_ts64(&ts_monotonic);
> *ts = timespec64_add(now, ts_monotonic);
>
> which avoids both the multiplication and division.
Much better, I'll do that. Thanks for the suggestion!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 03/17] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
On Thu, Nov 12, 2015 at 01:32:59PM +0900, Minchan Kim wrote: > From: Chen Gang > > For uapi, need try to let all macros have same value, and MADV_FREE is > added into main branch recently, so need redefine MADV_FREE for it. > > At present, '8' can be shared with all architectures, so redefine it to > '8'. Why not fold the patch into thre previous one? -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] mmc: change to use kmalloc
Use kmalloc instead of kzalloc, zero the memory is not needed.
Signed-off-by: yalin wang
---
drivers/mmc/card/block.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..c3fd4c8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -345,7 +345,7 @@ static struct mmc_blk_ioc_data
*mmc_blk_ioctl_copy_from_user(
struct mmc_blk_ioc_data *idata;
int err;
- idata = kzalloc(sizeof(*idata), GFP_KERNEL);
+ idata = kmalloc(sizeof(*idata), GFP_KERNEL);
if (!idata) {
err = -ENOMEM;
goto out;
@@ -365,7 +365,7 @@ static struct mmc_blk_ioc_data
*mmc_blk_ioctl_copy_from_user(
if (!idata->buf_bytes)
return idata;
- idata->buf = kzalloc(idata->buf_bytes, GFP_KERNEL);
+ idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
if (!idata->buf) {
err = -ENOMEM;
goto idata_err;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: change to use kmalloc
> On Nov 12, 2015, at 05:57, Andy Shevchenko wrote:
>
> On Wed, Nov 11, 2015 at 11:17 PM, Peter Hurley
> wrote:
>> On 11/11/2015 12:02 PM, Alim Akhtar wrote:
>>> Hi Yalin,
>>>
>>> On Wed, Nov 11, 2015 at 9:53 AM, yalin wang
>>> wrote:
Use kmalloc instead of kzalloc, zero the memory is not needed.
>>> why you want to do this? what problem you faces, and how this resolves the
>>> same?
>>
>> The patch fixes an inefficiency: explicitly zeroing memory that is then
>> immediately overwritten 6 lines below is wasteful.
>
> It might fix previous kzalloc as well, though better not to do since
> it's error prone.
>
yeah, i will send a new patch ,
>>
>> Regards,
>> Peter Hurley
>>
Signed-off-by: yalin wang
---
drivers/mmc/card/block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 23b6c8e..975cd3e 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -365,7 +365,7 @@ static struct mmc_blk_ioc_data
*mmc_blk_ioctl_copy_from_user(
if (!idata->buf_bytes)
return idata;
- idata->buf = kzalloc(idata->buf_bytes, GFP_KERNEL);
+ idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
if (!idata->buf) {
err = -ENOMEM;
goto idata_err;
--
1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE)
On Thu, Nov 12, 2015 at 01:32:57PM +0900, Minchan Kim wrote:
> @@ -256,6 +260,125 @@ static long madvise_willneed(struct vm_area_struct *vma,
> return 0;
> }
>
> +static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
> + unsigned long end, struct mm_walk *walk)
> +
> +{
> + struct mmu_gather *tlb = walk->private;
> + struct mm_struct *mm = tlb->mm;
> + struct vm_area_struct *vma = walk->vma;
> + spinlock_t *ptl;
> + pte_t *pte, ptent;
> + struct page *page;
> +
> + split_huge_page_pmd(vma, addr, pmd);
> + if (pmd_trans_unstable(pmd))
> + return 0;
> +
> + pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
> + arch_enter_lazy_mmu_mode();
> + for (; addr != end; pte++, addr += PAGE_SIZE) {
> + ptent = *pte;
> +
> + if (!pte_present(ptent))
> + continue;
> +
> + page = vm_normal_page(vma, addr, ptent);
> + if (!page)
> + continue;
> +
> + if (PageSwapCache(page)) {
Could you put VM_BUG_ON_PAGE(PageTransCompound(page), page) here?
Just in case.
> + if (!trylock_page(page))
> + continue;
> +
> + if (!try_to_free_swap(page)) {
> + unlock_page(page);
> + continue;
> + }
> +
> + ClearPageDirty(page);
> + unlock_page(page);
Hm. Do we handle pages shared over fork() here?
Souldn't we ignore pages with mapcount > 0?
> + }
> +
> + if (pte_young(ptent) || pte_dirty(ptent)) {
> + /*
> + * Some of architecture(ex, PPC) don't update TLB
> + * with set_pte_at and tlb_remove_tlb_entry so for
> + * the portability, remap the pte with old|clean
> + * after pte clearing.
> + */
> + ptent = ptep_get_and_clear_full(mm, addr, pte,
> + tlb->fullmm);
> +
> + ptent = pte_mkold(ptent);
> + ptent = pte_mkclean(ptent);
> + set_pte_at(mm, addr, pte, ptent);
> + tlb_remove_tlb_entry(tlb, pte, addr);
> + }
> + }
> +
> + arch_leave_lazy_mmu_mode();
> + pte_unmap_unlock(pte - 1, ptl);
> + cond_resched();
> + return 0;
> +}
>
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/3] dma: Add Freescale qDMA engine driver support
On Wed, Nov 11, 2015 4:14 PM, Vinod Koul wrote:
> On Fri, Oct 23, 2015 at 09:59:11AM +0800, Yuan Yao wrote:
>
> > +config FSL_QDMA
> > + tristate "Freescale qDMA engine support"
> > + depends on SOC_LS1021A || ARCH_LAYERSCAPE
>
> Where is this ARCH defined, quick grep revealed none
>
This is a generic family naming for freescale a set of ARMv8 based SoCs.
The patch is merged in arm soc but not yet merge into Linux next.
> > +static void fsl_qdma_set_tcd_params(struct fsl_qdma_chan *fsl_chan,
> > + u64 src, u64 dst, u32 nbytes)
> > +{
> > + void __iomem *addr = fsl_chan->qdma->membase;
> > + u32 reg;
> > +
> > + /*
> > +* Source address.
> > +* Represents address bits 31-0 of a 49-bit source address.
> > +*/
> > + qdma_writel(fsl_chan->qdma, (u32)src, addr + FSL_QDMA_DLSAR);
> > + /*
> > +* Source address.
> > +* Represents address bits 47-32 of a 49-bit source address.
> > +*/
> > + reg = qdma_readl(fsl_chan->qdma, addr + FSL_QDMA_DLSATR);
> > + reg |= (u16)(src >> 32) & 0x;
> > + reg |= FSL_QDMA_SRTTYPE_R_N;
> > + qdma_writel(fsl_chan->qdma, reg, addr + FSL_QDMA_DLSATR);
>
> How does this work on systems with enither endieness ?
[Yuan Yao] I'm sorry for confused. Is there any other endianness?
As I know in SOC_LS1021A and ARCH_LAYERSCAPE, there are just 32BE and 32LE for
the register R/W.
>
> Also why not use readq/writeq helpers, registers seem to be contagious
[Yuan Yao] It's hard to use readq/writeq because of the endianness.
>
> > +static enum dma_status fsl_qdma_tx_status(struct dma_chan *chan,
> > + dma_cookie_t cookie, struct dma_tx_state *txstate) {
> > + return dma_cookie_status(chan, cookie, txstate);
>
> No residue ?
[Yuan Yao] The QDMA is a strange DMA that I can't find any hardware interface
to query the data transfer size.
>
> > +static irqreturn_t fsl_qdma_controller_handler_err(int irq, void
> > +*dev_id) {
> > + struct fsl_qdma_engine *fsl_qdma = dev_id;
> > + u32 reg;
> > +
> > + reg = qdma_readl(fsl_qdma, fsl_qdma->membase + FSL_QDMA_DLSR);
> > +
> > + if (reg & FSL_QDMA_DLSR_TE) {
> > + dev_err(fsl_qdma->dma_dev.dev,
> > + "Transfer error. Check your address please!\n");
>
> It would help to print the addresses...
[Yuan Yao] Ok, The bus address or the virtual address?
>
> > + ret = devm_request_irq(&pdev->dev, fsl_qdma-
> >controller_irq,
> > + fsl_qdma_controller_handler, 0,
> > + "qDMA controller", fsl_qdma);
> > + if (ret) {
> > + dev_err(&pdev->dev,
> > + "Can't register qDMA controller IRQ.\n");
> > + return ret;
> > + }
> > +
> > + ret = devm_request_irq(&pdev->dev, fsl_qdma->err_irq,
> > + fsl_qdma_controller_handler_err, 0,
> > + "qDMA err", fsl_qdma);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Can't register qDMA err
> IRQ.\n");
> > + return ret;
> > + }
>
> why do you want devm variant here..?
[Yuan Yao] There is a different err IRQ in some SOCs. So I should do like this
to support those different hardware.
>
> > + dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> > + dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> > +
> > + fsl_qdma->dma_dev.dev = &pdev->dev;
> > + fsl_qdma->dma_dev.device_free_chan_resources
> > + = fsl_qdma_free_chan_resources;
> > + fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> > + fsl_qdma->dma_dev.device_prep_dma_memcpy =
> fsl_qdma_prep_memcpy;
> > + fsl_qdma->dma_dev.device_issue_pending =
> fsl_qdma_issue_pending;
>
> No terminate_all callback?
[Yuan Yao] QDMA is such a strange DMA that I can't find any hardware interface
to stop a in progress transmission.
>
> > +static int fsl_qdma_remove(struct platform_device *pdev) {
> > + struct device_node *np = pdev->dev.of_node;
> > + struct fsl_qdma_engine *fsl_qdma = platform_get_drvdata(pdev);
> > +
> > + of_dma_controller_free(np);
> > + dma_async_device_unregister(&fsl_qdma->dma_dev);
>
> And as i said above, the irq is left enabled, pls free that up
[Yuan Yao] Ok, Thanks.
>
> > +static int __init fsl_qdma_init(void) {
> > + return platform_driver_register(&fsl_qdma_driver);
> > +}
> > +subsys_initcall(fsl_qdma_init);
> > +
> > +static void __exit fsl_qdma_exit(void) {
> > + platform_driver_unregister(&fsl_qdma_driver);
> > +}
> > +module_exit(fsl_qdma_exit);
>
> module_platform_driver please
[Yuan Yao] Ok ,thanks.
>
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] virtio DMA API core stuff
On Wed, Nov 11, 2015 at 11:30:27PM +0100, David Woodhouse wrote: > On Wed, 2015-11-11 at 07:56 -0800, Andy Lutomirski wrote: > > > > Can you flesh out this trick? > > > > On x86 IIUC the IOMMU more-or-less defaults to passthrough. If the > > kernel wants, it can switch it to a non-passthrough mode. My patches > > cause the virtio driver to do exactly this, except that the host > > implementation doesn't actually exist yet, so the patches will instead > > have no particular effect. > > At some level, yes — we're compatible with a 1982 IBM PC and thus the > IOMMU is entirely disabled at boot until the kernel turns it on — > except in TXT mode where we abandon that compatibility. > > But no, the virtio driver has *nothing* to do with switching the device > out of passthrough mode. It is either in passthrough mode, or it isn't. > > If the VMM *doesn't* expose an IOMMU to the guest, obviously the > devices are in passthrough mode. If the guest kernel doesn't have IOMMU > support enabled, then obviously the devices are in passthrough mode. > And if the ACPI tables exposed to the guest kernel *tell* it that the > virtio devices are not actually behind the IOMMU (which qemu gets > wrong), then it'll be in passthrough mode. > > If the IOMMU is exposed, and enabled, and telling the guest kernel that > it *does* cover the virtio devices, then those virtio devices will > *not* be in passthrough mode. This we need to fix. Because in most configurations if you are using kernel drivers, then you don't want IOMMU with virtio, but if you are using VFIO then you do. Intel's iommu can be programmed to still do a kind of passthrough (1:1) mapping, it's just a matter of doing this for virtio devices when not using VFIO. > You choosing to use the DMA API in the virtio device drivers instead of > being buggy, has nothing to do with whether it's actually in > passthrough mode or not. Whether it's in passthrough mode or not, using > the DMA API is technically the right thing to do — because it should > either *do* the translation, or return a 1:1 mapped IOVA, as > appropriate. Right but first we need to actually make DMA API do the right thing at least on x86,ppc and arm. > > On powerpc and sparc, we *already* screwed up. The host already tells > > the guest that there's an IOMMU and that it's *enabled* because those > > platforms don't have selective IOMMU coverage the way that x86 does. > > So we need to work around it. > > No, we need it on x86 too because once we fix the virtio device driver > bug and make it start using the DMA API, then we start to trip up on > the qemu bug where it lies about which devices are covered by the > IOMMU. > > Of course, we still have that same qemu bug w.r.t. assigned devices, > which it *also* claims are behind its IOMMU when they're not... I'm not worried about qemu bugs that much. I am interested in being able to use both VFIO and kernel drivers with virtio devices with good performance and without tweaking kernel parameters. > > I think that, if we want fancy virt-friendly IOMMU stuff like you're > > talking about, then the right thing to do is to create a virtio bus > > instead of pretending to be PCI. That bus could have a virtio IOMMU > > and its own cross-platform enumeration mechanism for devices on the > > bus, and everything would be peachy. > > That doesn't really help very much for the x86 case where the problem > is compatibility with *existing* (arguably broken) qemu > implementations. > > Having said that, if this were real hardware I'd just be blacklisting > it and saying "Another BIOS with broken DMAR tables --> IOMMU > completely disabled". So perhaps we should just do that. > Yes, once there is new QEMU where virtio is covered by the IOMMU, that would be one way to address existing QEMU bugs. > > I still don't understand what trick. If we want virtio devices to be > > assignable, then they should be translated through the IOMMU, and the > > DMA API is the right interface for that. > > The DMA API is the right interface *regardless* of whether there's > actual translation to be done. The device driver itself should not be > involved in any way with that decision. With virt, each device can have different priveledges: some are part of hypervisor so with a kernel driver trying to get protection from them using an IOMMU which is also part of hypervisor makes no sense - but when using a userspace driver then getting protection from the userspace driver does make sense. Others are real devices so getting protection from them makes some sense. Which is which? It's easiest for the device driver itself to gain that knowledge. Please note this is *not* the same question as whether a specific device is covered by an IOMMU. > When you want to access MMIO, you use ioremap() and writel() instead of > doing random crap for yourself. When you want DMA, you use the DMA API > to get a bus address for your device *even* if you expect there to be > no IOMMU and yo
Re: [PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.
On Thu, Nov 12, 2015 at 10:52:25AM +, Jon Medhurst (Tixy) wrote: > On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote: > > > This is on-chip RAM or nornal system RAM? We already have bindings > > for > > > both. > > > > Juno has a set of TLX (ThinLinks) connectors on the board where an > > FPGA can be attached. On r1 > > the code running on FPGA can even participate as an AXI master with > > full coherency. The FPGA > > has local memory that we want to share with the HDLCD to be used as a > > framebuffer. > > The HDLCD on the Juno chip or one implemented in the FPGA? I assume you > mean the latter but just wanted to check. You can have a GPU on the FPGA, and you want to read the framebuffer off the FPGA's memory to render it on screen using the SoC's HDLCD. Hope this makes sense. Best regards, Liviu > > -- > Tixy > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf/x86/intel/pt: Test CPU vendor before loading
On Thu, Nov 12, 2015 at 11:56:12AM +0100, Borislav Petkov wrote:
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c
> b/arch/x86/kernel/cpu/perf_event_intel_pt.c
> index 42169283448b..fa1262b025e7 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
> @@ -1129,6 +1129,9 @@ static __init int pt_init(void)
> {
> int ret, cpu, prior_warn = 0;
>
> + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> + return 0;
> +
Does not apply; conflicts with:
commit 73fdeb66592ee80dffb16fb8a9b7378a00c1a826
Author: Huaitong Han
Date: Mon Aug 31 16:21:02 2015 +0800
perf/x86/intel/pt: Fix KVM warning due to doing rdmsr() before the CPUID
test
If KVM does not support INTEL_PT, guest MSR_IA32_RTIT_CTL reading will
produce host warning like "kvm [2469]: vcpu0 unhandled rdmsr: 0x570".
Guest can determine whether the CPU supports Intel_PT according to CPUID,
so test_cpu_cap function is added before rdmsr,and it is more in line with
the code style.
Signed-off-by: Huaitong Han
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: a...@kernel.org
Link:
http://lkml.kernel.org/r/1441009262-9792-1-git-send-email-huaitong@intel.com
Signed-off-by: Ingo Molnar
diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c
b/arch/x86/kernel/cpu/perf_event_intel_pt.c
index 42169283448b..868e1194337f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -139,9 +139,6 @@ static int __init pt_pmu_hw_init(void)
long i;
attrs = NULL;
- ret = -ENODEV;
- if (!test_cpu_cap(&boot_cpu_data, X86_FEATURE_INTEL_PT))
- goto fail;
for (i = 0; i < PT_CPUID_LEAVES; i++) {
cpuid_count(20, i,
@@ -1130,6 +1127,10 @@ static __init int pt_init(void)
int ret, cpu, prior_warn = 0;
BUILD_BUG_ON(sizeof(struct topa) > PAGE_SIZE);
+
+ if (!test_cpu_cap(&boot_cpu_data, X86_FEATURE_INTEL_PT))
+ return -ENODEV;
+
get_online_cpus();
for_each_online_cpu(cpu) {
u64 ctl;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce the request handling for dm-crypt
On Thu 12-11-15 17:40:59, Baolin Wang wrote: > On 12 November 2015 at 17:17, Jan Kara wrote: > > On Thu 12-11-15 10:15:32, Baolin Wang wrote: > >> On 11 November 2015 at 17:48, Christoph Hellwig wrote: > >> > On Wed, Nov 11, 2015 at 05:31:43PM +0800, Baolin Wang wrote: > >> >> Now the dm-crypt code only implemented the 'based-bio' method to > >> >> encrypt/ > >> >> decrypt block data, which can only hanle one bio at one time. As we > >> >> know, > >> >> one bio must use the sequential physical address and it also has a > >> >> limitation > >> >> of length. Thus it may limit the big block encyrtion/decryption when > >> >> some > >> >> hardware support the big block data encryption. > >> >> > >> >> This patch series introduc the 'based-request' method to handle the data > >> >> encryption/decryption. One request can contain multiple bios, so it can > >> >> handle big block data to improve the efficiency. > >> > > >> > NAK for more request based stacking or DM drivers. They are a major > >> > pain to deal with, and adding more with different requirements then > >> > dm-multipath is not helping in actually making that one work properly. > >> > >> But now many vendors supply the hardware engine to handle the > >> encyrtion/decryption. The hardware really need a big block to indicate > >> its performance with request based things. Another thing is now the > >> request based things is used by many vendors (Qualcomm, Spreadtrum and > >> so on) to improve their performance and there's a real performance > >> requirement here (I can show the performance result later). > > > > So you've mentioned several times that hardware needs big blocks. How big > > those blocks need to be? Ideally, can you give some numbers on how the > > throughput of the encryption hw grows with the block size? > > It depends on the hardware design. My beaglebone black board's AES > engine can handle 1M at one time which is not big. As I know some > other AES engine can handle 16M data at one time or more. Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers... > > You mentioned that you use requests because of size limitations on bios - I > > had a look and current struct bio can easily describe 1MB requests (that's > > assuming 64-bit architecture, 4KB pages) when we have 1 page worth of > > struct bio_vec. Is that not enough? > > Usually one bio does not always use the full 1M, maybe some 1k/2k/8k > or some other small chunks. But request can combine some sequential > small bios to be a big block and it is better than bio at least. As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it? Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shut up unhandled MSR warnings
On Thu, Nov 12, 2015 at 11:33:33AM +0100, Paolo Bonzini wrote: > Yes, see guest_cpuid_has_* for an example of reading the CPUID values. > > But if it's defined for _all_ models starting at family 21, we can just > do it unconditionally. The thing is, those bits are Reserved again on the next family 22. Lemme take a look at guest_cpuid_has_* and see how ugly it gets. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] genirq: Add runtime resume/suspend support for IRQ chips
On 11/11/15 15:41, Grygorii Strashko wrote:
> On 11/11/2015 12:13 PM, Jon Hunter wrote:
>>
>> On 10/11/15 18:07, Lars-Peter Clausen wrote:
>>> On 11/10/2015 05:47 PM, Grygorii Strashko wrote:
>>> [...]
> I was trying to simplify matters by placing the resume call in
> __setup_irq() as opposed to requested_threaded_irq(). However, the would
> mean the resume is inside the bus_lock and may be I should not assume
> that I can sleep here.
>
>> Can you folks please agree on something which is correct and complete?
>
> Soren I am happy to defer to your patch and drop this. My only comment
> would be what about the request_percpu_irq() path in your patch?
>
I have the same comment here as I asked Soren:
1) There are no restrictions to call irq set_irq_type() whenever,
as result HW can be accessed before request_x_irq()/__setup_irq().
And this is used quite widely now :(
>>>
>>> Changing the configuration of a resource that is not owned seems to be
>>> fairly broken. In the worst case this will overwrite the configuration that
>>> was set by owner of the resource.
>>>
>>> Especially those that call irq_set_irq_type() directly before request_irq(),
>>> given that you supply the trigger type to request_irq() which will make sure
>>> that there are no conflicts and the configure.
>>>
>>> This is a bit like calling gpio_set_direction() before you call
>>> gpio_request(), which will also have PM issues.
>>
>> Yes, I agree that this does sound a bit odd, but ...
>>
For example, during OF boot:
[a] irq_create_of_mapping()
- irq_create_fwspec_mapping()
- irq_set_irq_type()
>>
>> The above means that if someone calls of_irq_get() (or
>> platform_get_irq()), before request_irq(), then this will call
>> irq_create_of_mapping() and hence, call irq_set_irq_type. So should
>> irq_create_fwspec_mapping() be setting the type in the first place? I
>> can see it is convenient to do it here.
>
> In general there is another option - save OF-flags and pass them to
> __setup_irq() where they can be processed.
Right, we could look at doing something like this.
or
> [b]
irq_set_irq_type(irq, IRQ_TYPE_LEVEL_HIGH);
irq_set_chained_handler(irq, mx31ads_expio_irq_handler);
>
> option: add "flag" parameter to irq_set_chained_handler
>
or
> [c]
irq_set_irq_type(alarm_irq, IRQ_TYPE_EDGE_BOTH);
err = devm_request_irq(&pdev->dev, alarm_irq, fan_alarm_irq_handler,
(there are ~200 occurrences of irq set_irq_type in Kernel)
2) if i'm not wrong, the same is valid for irq_set_irq_wake() and
irq_set_affinity()
I'm not saying all these code is correct, but that what's now in kernel :(
I've tried to test Soren's patch with omap-gpio and immediately hit case
[a] :.(
>>>
>>> All functions for which are part of the public API and for which it is legal
>>> to call them without calling request_irq() (or similar) first will need to
>>> have pm_get()/pm_put().
>>
>> Right. May be we can look at the various entry points to the chip
>> operators to get a feel for which public APIs need to be handled.
>
>
> Seems yes. But we need to be very careful with this, some of functions could
> be
> called recursively (nested), like:
> [d]
> static int pcf857x_irq_set_wake(struct irq_data *data, unsigned int on)
> {
> ...
> error = irq_set_irq_wake(gpio->irq_parent, on);
>
>
> Personally, I have nothing against irq_pm_(get|put) :) and thought about
> similar things
> when tried to solve the same problem for omap-gpio driver.
> But :(, I have to fall back to irq_bus_lock/sync_unlock, because of [a,b,c] -
> all above
> APIs surrounded by chip_bus_lock/chip_bus_sync_unlock. ([d] - I've not hit it
> just because
> I was lucky).
I had a quick peek at the omap-gpio driver and I see that internally you
are using the gpio ref-count to manage RPM and use the bus-lock hooks to
invoke RPM.
This can definitely be complex when considering all the potential paths,
but I think that we need to a look at this from a chip-ops perspective
because only the chip knows if it is accessible or not. That said, what
we need to assess is:
1. Which chip-ops should ONLY be called after an IRQ has been allocated
(eg, enable/disable, mask/unmask, type, etc). These chip-ops should
not try to control the chip PM, but should possibly WARN if called
when the chip is not accessible.
2. For chip-ops that may be called without allocating an IRQ (eg.
bus_lock, irq_suspend, etc), can these be called from an atomic
context? If they might be called from an atomic context then these
are the chip-ops which will cause problems as we cannot guarantee
that all IRQ chips can support irq-safe RPM.
AFAICT, looking at the chip-ops, it appears to me that ones that should
be called without allocating a IRQ are:
@irq_cpu_online
@irq_cpu_offline
@irq_bus_lock
@irq_bus_sync_unlock
@irq
[PATCH] perf/x86/intel/pt: Test CPU vendor before loading
From: Borislav Petkov
This keeps poking at MSR 0x570 when loading, i.e. MSR_IA32_RTIT_CTL,
which is most likely not present on other vendors. It is using the _safe
variant but there's no need to try it at all, really. Besides, it causes
unhandled rdmsr warnings when booting in a guest:
kvm [4414]: vcpu0 unhandled rdmsr: 0x570
So check CPU vendor before doing anything else.
Signed-off-by: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Paolo Bonzini
Cc: Paul Gortmaker
Cc: "Peter Zijlstra (Intel)"
Cc: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_pt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c
b/arch/x86/kernel/cpu/perf_event_intel_pt.c
index 42169283448b..fa1262b025e7 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -1129,6 +1129,9 @@ static __init int pt_init(void)
{
int ret, cpu, prior_warn = 0;
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ return 0;
+
BUILD_BUG_ON(sizeof(struct topa) > PAGE_SIZE);
get_online_cpus();
for_each_online_cpu(cpu) {
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 00/26] Coresight integration with perf
Mathieu Poirier writes: Hi Mathieu, > Changes since V2: > * Rebased to v4.3. Just tried, does not apply onto v4.3. I also tried Greg's char-misc-next and TIP perf/core. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?
On 2015年11月12日 18:34, Liviu Dudau wrote: Can you switch your email client to text mode and make it do proper reply quoting? It is rather difficult to follow where your reply comes when you don't use HTML MUAs. Best regards, Liviu Hi Liviu I'm sorry about that, now I switch my email into text mode, but I don't known whether it take effect, everything look the same. Thanks. -- Ｍark Yao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.
On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote: > > This is on-chip RAM or nornal system RAM? We already have bindings > for > > both. > > Juno has a set of TLX (ThinLinks) connectors on the board where an > FPGA can be attached. On r1 > the code running on FPGA can even participate as an AXI master with > full coherency. The FPGA > has local memory that we want to share with the HDLCD to be used as a > framebuffer. The HDLCD on the Juno chip or one implemented in the FPGA? I assume you mean the latter but just wanted to check. -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Issue on regmap-mmio
On Thu, Nov 12, 2015 at 08:57:34AM +, Lu Y.B. wrote:
> Hi Mark,
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> May I know whether the regmap APIs support big-endian platforms, lilke
> PowerPC?
> I am a little confused why 'regmap_mmio_read/write' in regmap-mmio.c call
> '{read,write}{b,w,l,q}()'.
Check out the latest regmap code, there was a fix went in for this
recently. See "regmap-mmio: Use native endianness for read/write".
signature.asc
Description: PGP signature
Re: drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?
On 2015年11月12日 18:36, Liviu Dudau wrote: On Thu, Nov 12, 2015 at 04:32:33PM +0800, Mark yao wrote: On 2015年11月10日 23:01, Liviu Dudau wrote: Hello, When booting my Juno board with the HDLCD driver that I have converted to atomic operations I'm getting the following warning: [ cut here ] WARNING: at /work/repositories/kernel/drivers/gpu/drm/drm_atomic_helper.c:674 Modules linked in: hdlcd(+) clk_scpi CPU: 3 PID: 1375 Comm: systemd-udevd Not tainted 4.3.0-next-20151109+ #5 Hardware name: ARM Juno development board (r0) (DT) task: ffc974888b00 ti: ffc9755dc000 task.ti: ffc9755dc000 PC is at drm_atomic_helper_update_legacy_modeset_state+0x204/0x20c LR is at drm_atomic_helper_commit_modeset_disables+0x1c0/0x394 pc : [] lr : [] pstate: 2145 sp : ffc9755df430 x29: ffc9755df430 x28: ffc975703600 x27: x26: ffc976253960 x25: ffc976254040 x24: ffc000819000 x23: ffc000689ea0 x22: ffc976251800 x21: ffc976251800 x20: x19: ffc9766b1f80 x18: 715fe015 x17: 007fb4b855b0 x16: 0220 x15: 0001 x14: 0ffe x13: 0008 x12: 0101010101010101 x11: ffc000964000 x10: ffc0009d2000 x9 : x8 : ffc97ff5f700 x7 : ffc97566cb80 x6 : ffc9766b1700 x5 : ffc975665100 x4 : x3 : ffc976253960 x2 : ffc97566cd00 x1 : ffc976253900 x0 : ---[ end trace 9fe289f798e7178e ]--- Call trace: [] drm_atomic_helper_update_legacy_modeset_state+0x204/0x20c [] drm_atomic_helper_commit_modeset_disables+0x1c0/0x394 [] drm_atomic_helper_commit+0xe0/0x150 [] drm_atomic_commit+0x40/0x6c [] restore_fbdev_mode+0x294/0x2d4 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x8c [] drm_fb_helper_set_par+0x2c/0x58 [] fbcon_init+0x4d4/0x534 [] visual_init+0xac/0x104 [] do_bind_con_driver+0x16c/0x398 [] do_take_over_console+0xd8/0x1f4 [] do_fbcon_takeover+0x74/0xf8 [] fbcon_event_notify+0x8a4/0x8f8 [] notifier_call_chain+0x4c/0x88 [] __blocking_notifier_call_chain+0x44/0x74 [] blocking_notifier_call_chain+0x14/0x1c [] fb_notifier_call_chain+0x1c/0x24 [] register_framebuffer+0x1c0/0x2ac [] drm_fb_helper_initial_config+0x25c/0x3ec [] drm_fbdev_cma_init+0x98/0x134 [] hdlcd_drm_bind+0x180/0x498 [hdlcd] [] try_to_bring_up_master.part.5+0xd4/0x118 [] component_master_add_with_match+0xc4/0x148 [] component_master_add+0x10/0x18 [] hdlcd_probe+0x14/0x28 [hdlcd] [] platform_drv_probe+0x54/0xc0 [] driver_probe_device+0x1ec/0x2e8 [] __driver_attach+0x9c/0xa0 [] bus_for_each_dev+0x58/0x98 [] driver_attach+0x20/0x28 [] bus_add_driver+0x1c8/0x22c [] driver_register+0x68/0x108 [] __platform_driver_register+0x4c/0x54 [] hdlcd_init+0x18/0x30 [hdlcd] [] do_one_initcall+0x90/0x1a8 [] do_init_module+0x60/0x1c8 [] load_module+0x1554/0x1c98 [] SyS_finit_module+0x7c/0x88 [] el0_svc_naked+0x24/0x28 The line that triggers the warning is: 674:WARN_ON(!connector->encoder->crtc); As far as I can see the encoder->crtc value is being set to a non-NULL value only in two places: - in drm_atomic_helper_update_legacy_modeset_state() after WARN_ON() encoder->crtc = connector->state->crtc; - in drm_crtc_helper_set_config(drm_mode_set *set): encoder->crtc = new_crtc; Nothing in the call path from drm_atomic_commit() calls crtc_funcs->set_config() or drm_crtc_helper_set_config() directly, so the question is if this WARN() is actually valid. Call path from drm_atomic_commit: drm_atomic_helper_commit() - drm_atomic_helper_prepare_planes() - drm_atomic_helper_swap_state() - drm_atomic_helper_commit_modeset_disables() - disable_outputs() - drm_atomic_helper_update_legacy_modeset_state() - WARN_ON(!connector->encoder->crtc) Best regards, Liviu Hi Liviu I solved this problem by following change, you can check if your driver do the same things: drivers/gpu/drm/bridge/dw_hdmi.c: - hdmi->connector.encoder = encoder; +// hdmi->connector.encoder = encoder; drm_mode_connector_attach_encoder(&hdmi->connector, encoder); I found some other drivers set connector.encoder before drm_mode_connector_attach_encoder, some are not. drm_mode_connector_attach_encoder already describe the link of connector and encoder, so I think "connector.encoder = encoder" is not needed, is that right? I'll have a look, thanks for pointing this. However, my setup uses the tda998x driver for encoder, so I will have to go look there rather than in my driver. Best regards, Liviu Thanks. -- Ｍark Yao Hi Liviu drivers/gpu/drm/i2c/tda998x_drv.c do the same things: priv->connector.encoder =
Re: samples: livepatch: init reloc list and mark as klp module
On Thu, 12 Nov 2015, Jessica Yu wrote:
> +++ Petr Mladek [11/11/15 16:42 +0100]:
> > On Mon 2015-11-09 23:45:54, Jessica Yu wrote:
> > > Intialize the list of relocation sections in the sample
> > > klp_object (even if the list will be empty in this case).
> > > Also mark module as a livepatch module so that the module
> > > loader can appropriately initialize it.
> > >
> > > Signed-off-by: Jessica Yu
> > > ---
> > > samples/livepatch/livepatch-sample.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/samples/livepatch/livepatch-sample.c
> > > b/samples/livepatch/livepatch-sample.c
> > > index fb8c861..2ef9345 100644
> > > --- a/samples/livepatch/livepatch-sample.c
> > > +++ b/samples/livepatch/livepatch-sample.c
> > > @@ -89,3 +90,4 @@ static void livepatch_exit(void)
> > > module_init(livepatch_init);
> > > module_exit(livepatch_exit);
> > > MODULE_LICENSE("GPL");
> > > +MODULE_INFO(livepatch, "Y");
> >
> > This looks a bit error prone. I wonder if we could detect this
> > information another way. For example, by a check for the
> > livepatch-related elf sections. If it is missing,
> > we do not need to preserve struct load_info even
> > when it is a livepatch.
>
> Yeah, I agree that it is unnecessary for a livepatch module without
> reloc secs to keep a copy of the load_info struct. My justification
> for using MODULE_INFO is that I was trying to be consistent with the
> way how other module "characteristics" are checked in the module
> loader. For example, if the module came from the staging tree, the
> module loader simply checks get_modinfo(info, "staging")). If the
> module is a livepatch module, we check get_modinfo(info,
> "livepatch")). I also thought that it might be useful additional
> information for the user to be able to issue the modinfo command on a
> module to see if it's a livepatch module or not (but maybe this
> information won't be so useful after all, that's quite subjective).
Yup, in my opinion this is a good way to do it. We already impose quite a
lot on a patch module and this does not make a big difference. Easy
identification of a patch module is good bonus as well.
> But if we want to do a more thorough check, we could, like you said,
> check for the livepatch-related elf sections before copying load_info.
I wouldn't do that. It could be even more error prone.
I'd like to think that we can live with load_info struct even for patch
modules which do not use relocations. Don't know.
Miroslav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Nov 10 (8250_mid.c)
On Tue, Nov 10, 2015 at 10:12:26AM -0800, Randy Dunlap wrote: > On 11/09/15 18:19, Stephen Rothwell wrote: > > Hi all, > > > > Please do *not* add any material intended for v4.5 to your linux-next > > included branches until after v4.4-rc1 has been released. > > > > Changes since 20151109: > > > > on x86_64: > > drivers/built-in.o: In function `mid8250_set_termios': > 8250_mid.c:(.text+0x10169a): undefined reference to > `rational_best_approximation' > > CONFIG_RATIONAL is not enabled. Just need to select it I think. Good catch! Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] FS-Cache: Add missing initialization of ret in cachefiles_write_page()
On Thu, Nov 12, 2015 at 11:42 AM, David Howells wrote:
> Geert Uytterhoeven wrote:
>
>> > This isn't quite the right solution. The uninitialised error path needs to
>> > set -ENOBUFS.
>>
>> That's what your commit 102f4d900c9c8f5e ("FS-Cache: Handle a write to the
>> page immediately beyond the EOF marker") does, and is also in its commit
>> description:
>>
>> Whilst we're at it, change the triggered assertion in CacheFiles to just
>> return -ENOBUFS instead.
>>
>> "ret" is used only to print the original error in a debug message.
>
> I'll adjust your patch to set the default value in ret to be -ENOBUFS instead
> of 0.
OK. Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] FS-Cache: Add missing initialization of ret in cachefiles_write_page()
Geert Uytterhoeven wrote:
> > This isn't quite the right solution. The uninitialised error path needs to
> > set -ENOBUFS.
>
> That's what your commit 102f4d900c9c8f5e ("FS-Cache: Handle a write to the
> page immediately beyond the EOF marker") does, and is also in its commit
> description:
>
> Whilst we're at it, change the triggered assertion in CacheFiles to just
> return -ENOBUFS instead.
>
> "ret" is used only to print the original error in a debug message.
I'll adjust your patch to set the default value in ret to be -ENOBUFS instead
of 0.
> > Unfortunately, my compiler doesn't show a warning:-/
>
> Need old gcc (4.1.2 ;-)
Quite possibly - gcc-5.1 does seem to be a bit lacking in detection of such
things.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.
On Wed, Nov 11, 2015 at 12:48:50PM -0600, Rob Herring wrote: > On Wed, Nov 11, 2015 at 04:06:47PM +, Liviu Dudau wrote: > > Cc: Rob Herring > > Cc: Pawel Moll > > Cc: Mark Rutland > > Cc: Ian Campbell > > Cc: Kumar Gala > > > > Signed-off-by: Liviu Dudau > > Looks pretty good, but a few comments. > > > --- > > .../devicetree/bindings/drm/arm/arm,hdlcd.txt | 74 > > ++ > > 1 file changed, 74 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt > > > > diff --git a/Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt > > b/Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt > > new file mode 100644 > > index 000..b57f1b9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt > > @@ -0,0 +1,74 @@ > > +ARM HDLCD > > + > > +This is a display controller found on several development platforms > > produced > > +by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB > > +streamer that reads the data from a framebuffer and sends it to a single > > +digital encoder (DVI or HDMI). > > + > > +Required properties: > > + - compatible: "arm,hdlcd" > > Kind of generic. Something more specific please. "There can be only one!" (hdlcd) :) This is going to be a "one version only" HW part. ARM has now switched to a new display hardware that has more features and a new name, and work on mainlining support for that will start once I get the HDLCD driver accepted. > > > + - reg: Physical base address and length of the controller's registers. > > +If a second pair of address and length values is present this specifies > > +the presence of a DMA coherent memory area that the HDLCD can use as > > +framebuffer instead of normal CMA memory. > > This is on-chip RAM or nornal system RAM? We already have bindings for > both. Juno has a set of TLX (ThinLinks) connectors on the board where an FPGA can be attached. On r1 the code running on FPGA can even participate as an AXI master with full coherency. The FPGA has local memory that we want to share with the HDLCD to be used as a framebuffer. > > > + - interrupts: One interrupt used by the display controller to notify the > > +interrupt controller when any of the interrupt sources programmed in > > +the interrupt mask register have activated. > > + - clocks: A list of phandle + clock-specifier pairs, one for each > > +entry in 'clock-names'. > > + - clock-names: A list of clock names. For HDLD it should contain: > > + - "pxlclk" for the clock feeding the output PLL of the controller. > > + - port: The HDLCD connection to an encoder chip. The connection is > > modelled > > +using the OF graph bindings specified in > > Documentation/devicetree/bindings/graph.txt. > Thanks for reviewing this, Liviu -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 10/12] Drivers: hv: vmbus: channge vmbus_connection.channel_lock to mutex
"K. Y. Srinivasan" writes:
> From: Dexuan Cui
>
> spinlock is unnecessary here.
> mutex is enough.
Hm, mutex is usually required when we need to sleep and a spinlock is
enough otherwise :-)
Or are you trying to say we don't need to disable interrupts here? In
that can maybe we can just switch to spin_lock()/spin_unlock()?
>
> Signed-off-by: Dexuan Cui
> Signed-off-by: K. Y. Srinivasan
> ---
> drivers/hv/channel_mgmt.c | 12 ++--
> drivers/hv/connection.c |7 +++
> drivers/hv/hyperv_vmbus.h |2 +-
> 3 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 9c9da3a..d013171 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -206,9 +206,9 @@ void hv_process_channel_removal(struct vmbus_channel
> *channel, u32 relid)
> }
>
> if (channel->primary_channel == NULL) {
> - spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
> + mutex_lock(&vmbus_connection.channel_mutex);
> list_del(&channel->listentry);
> - spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
> + mutex_unlock(&vmbus_connection.channel_mutex);
>
> primary_channel = channel;
> } else {
> @@ -253,7 +253,7 @@ static void vmbus_process_offer(struct vmbus_channel
> *newchannel)
> unsigned long flags;
>
> /* Make sure this is a new offer */
> - spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
> + mutex_lock(&vmbus_connection.channel_mutex);
>
> list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
> if (!uuid_le_cmp(channel->offermsg.offer.if_type,
> @@ -269,7 +269,7 @@ static void vmbus_process_offer(struct vmbus_channel
> *newchannel)
> list_add_tail(&newchannel->listentry,
> &vmbus_connection.chn_list);
>
> - spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
> + mutex_unlock(&vmbus_connection.channel_mutex);
>
> if (!fnew) {
> /*
> @@ -341,9 +341,9 @@ static void vmbus_process_offer(struct vmbus_channel
> *newchannel)
> err_deq_chan:
> vmbus_release_relid(newchannel->offermsg.child_relid);
>
> - spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
> + mutex_lock(&vmbus_connection.channel_mutex);
> list_del(&newchannel->listentry);
> - spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
> + mutex_unlock(&vmbus_connection.channel_mutex);
>
> if (newchannel->target_cpu != get_cpu()) {
> put_cpu();
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index 4fc2e88..521f48e 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -146,7 +146,7 @@ int vmbus_connect(void)
> spin_lock_init(&vmbus_connection.channelmsg_lock);
>
> INIT_LIST_HEAD(&vmbus_connection.chn_list);
> - spin_lock_init(&vmbus_connection.channel_lock);
> + mutex_init(&vmbus_connection.channel_mutex);
>
> /*
>* Setup the vmbus event connection for channel interrupt
> @@ -282,11 +282,10 @@ struct vmbus_channel *relid2channel(u32 relid)
> {
> struct vmbus_channel *channel;
> struct vmbus_channel *found_channel = NULL;
> - unsigned long flags;
> struct list_head *cur, *tmp;
> struct vmbus_channel *cur_sc;
>
> - spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
> + mutex_lock(&vmbus_connection.channel_mutex);
> list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
> if (channel->offermsg.child_relid == relid) {
> found_channel = channel;
> @@ -305,7 +304,7 @@ struct vmbus_channel *relid2channel(u32 relid)
> }
> }
> }
> - spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
> + mutex_unlock(&vmbus_connection.channel_mutex);
>
> return found_channel;
> }
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 64950d8..0af6dce 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -688,7 +688,7 @@ struct vmbus_connection {
>
> /* List of channels */
> struct list_head chn_list;
> - spinlock_t channel_lock;
> + struct mutex channel_mutex;
>
> struct workqueue_struct *work_queue;
> };
--
Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] KVM: X86: Migration is supported
On 2015/11/12 17:00, Paolo Bonzini wrote: On 12/11/2015 08:06, Jian Zhou wrote: I think you can just do this in kvm_x86_ops->set_msr. The old implementation for DEBUGCTL MSR can be moved to svm.c. I think you mean "moved to vmx.c"? No, the old implementation is moved from x86.c to svm.c. The new implementation you have in vmx.c is then called from vmx_set_msr. I got it, thanks. Jian Paolo . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Thu, Nov 12, 2015 at 11:32 AM, Andy Shevchenko
wrote:
> On Thu, 2015-11-12 at 10:18 +0530, punnaiah choudary kalluri wrote:
>> On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko
>> wrote:
>> > On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote:
>> > > Added the basic driver for Arasan Nand Flash Controller used in
>> > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
>> > > correction.
>> > >
>> >
>> > > +config MTD_NAND_ARASAN
>> > > + tristate "Support for Arasan Nand Flash controller"
>> > > + depends on MTD_NAND
>> >
>> > This looks useless since you can't see the item without MTD_NAND is
>> > chosen.
>> >
>> > > + help
>> > > + Enables the driver for the Arasan Nand Flash controller
>> > > on
>> > > + Zynq UltraScale+ MPSoC.
>> > > +
>> > > endif # MTD_NAND
>> > >
>> >
>> > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o
>> >
>> > "nfc" part a bit ambiguous since NFC might be Near Field
>> > Communication.
>>
>> This driver is under mtd/nand so, there is no point of confusion and
>> in this context nfc is nand flash controller.
>
> Imagine that at some point arasan (whatever) releases NFC chip, and
> someone puts the driver under corresponding folder but with the same
> file name (and driver name). Do you see a problem? I see two:
> - if you built-in both how you supply command line parameters?
> - some platform code may do request_module() or
> platform_driver_register() with the name you provided as DRIVER_NAME.
#3: Module filenames must be unique, too. "modprobe arasan_nfc.ko" won't
know which module to load.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X.509: Fix the time validation [ver #2]
On Thu, 2015-11-12 at 09:36 +, David Howells wrote: > If it works, it emit a key ID; if it fails, it should give a bad > message error. In this sentence, failure is good, yes? This is a malformed key so we *expect* the failure? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
RE: [f2fs-dev] [PATCH] f2fs: optimize __find_rev_next_bit
Hi Fan,
> -Original Message-
> From: Fan Li [mailto:fanofcode...@samsung.com]
> Sent: Thursday, November 12, 2015 8:43 AM
> To: 'Jaegeuk Kim'
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH] f2fs: optimize __find_rev_next_bit
>
> 1. Skip __reverse_ulong if the bitmap is empty.
> 2. Reduce branches and codes.
> According to my test, the performance of this new version is 5% higher on
> an empty bitmap of 64bytes, and remains about the same in the worst scenario.
Good catch!
IMO, it's better to optimize __find_rev_next_{,zero}bit together. :)
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS: BMIPS: Enable GZIP ramdisk and timed printks
On Thu, Nov 12, 2015 at 11:18:30AM +0100, Andreas Ziegler wrote: > Hi Florian, > > your patch "MIPS: BMIPS: Enable GZIP ramdisk and timed printks" > showed up as commit fb9e5642aa9e in linux-next today (that is, > next-20151112). I noticed it because we (a research group from > Erlangen[0]) are running daily checks on linux-next. > > Your commit adds two entries to arch/mips/configs/bmips_stb_defconfig, > but one of them has a typo (line 37): > > CONFIG_PRINK_TIME=y > > which should instead say (notice the missing 'T'): > > CONFIG_PRINTK_TIME=y > > Not sure how this got two Reviewed-by's, as this simple mistake could > have been easily spotted by running scripts/checkkconfigsymbols.py on > the patch. Sigh, fixed. Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?
On Thu, Nov 12, 2015 at 04:32:33PM +0800, Mark yao wrote: >On 2015年11月10日 23:01, Liviu Dudau wrote: > > Hello, > > When booting my Juno board with the HDLCD driver that I have converted to > atomic operations I'm getting the following warning: > > [ cut here ] > WARNING: at /work/repositories/kernel/drivers/gpu/drm/drm_atomic_helper.c:674 > Modules linked in: hdlcd(+) clk_scpi > > CPU: 3 PID: 1375 Comm: systemd-udevd Not tainted 4.3.0-next-20151109+ #5 > Hardware name: ARM Juno development board (r0) (DT) > task: ffc974888b00 ti: ffc9755dc000 task.ti: ffc9755dc000 > PC is at drm_atomic_helper_update_legacy_modeset_state+0x204/0x20c > LR is at drm_atomic_helper_commit_modeset_disables+0x1c0/0x394 > pc : [] lr : [] pstate: 2145 > sp : ffc9755df430 > x29: ffc9755df430 x28: ffc975703600 > x27: x26: ffc976253960 > x25: ffc976254040 x24: ffc000819000 > x23: ffc000689ea0 x22: ffc976251800 > x21: ffc976251800 x20: > x19: ffc9766b1f80 x18: 715fe015 > x17: 007fb4b855b0 x16: 0220 > x15: 0001 x14: 0ffe > x13: 0008 x12: 0101010101010101 > x11: ffc000964000 x10: ffc0009d2000 > x9 : x8 : ffc97ff5f700 > x7 : ffc97566cb80 x6 : ffc9766b1700 > x5 : ffc975665100 x4 : > x3 : ffc976253960 x2 : ffc97566cd00 > x1 : ffc976253900 x0 : > > ---[ end trace 9fe289f798e7178e ]--- > Call trace: > [] > drm_atomic_helper_update_legacy_modeset_state+0x204/0x20c > [] drm_atomic_helper_commit_modeset_disables+0x1c0/0x394 > [] drm_atomic_helper_commit+0xe0/0x150 > [] drm_atomic_commit+0x40/0x6c > [] restore_fbdev_mode+0x294/0x2d4 > [] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x8c > [] drm_fb_helper_set_par+0x2c/0x58 > [] fbcon_init+0x4d4/0x534 > [] visual_init+0xac/0x104 > [] do_bind_con_driver+0x16c/0x398 > [] do_take_over_console+0xd8/0x1f4 > [] do_fbcon_takeover+0x74/0xf8 > [] fbcon_event_notify+0x8a4/0x8f8 > [] notifier_call_chain+0x4c/0x88 > [] __blocking_notifier_call_chain+0x44/0x74 > [] blocking_notifier_call_chain+0x14/0x1c > [] fb_notifier_call_chain+0x1c/0x24 > [] register_framebuffer+0x1c0/0x2ac > [] drm_fb_helper_initial_config+0x25c/0x3ec > [] drm_fbdev_cma_init+0x98/0x134 > [] hdlcd_drm_bind+0x180/0x498 [hdlcd] > [] try_to_bring_up_master.part.5+0xd4/0x118 > [] component_master_add_with_match+0xc4/0x148 > [] component_master_add+0x10/0x18 > [] hdlcd_probe+0x14/0x28 [hdlcd] > [] platform_drv_probe+0x54/0xc0 > [] driver_probe_device+0x1ec/0x2e8 > [] __driver_attach+0x9c/0xa0 > [] bus_for_each_dev+0x58/0x98 > [] driver_attach+0x20/0x28 > [] bus_add_driver+0x1c8/0x22c > [] driver_register+0x68/0x108 > [] __platform_driver_register+0x4c/0x54 > [] hdlcd_init+0x18/0x30 [hdlcd] > [] do_one_initcall+0x90/0x1a8 > [] do_init_module+0x60/0x1c8 > [] load_module+0x1554/0x1c98 > [] SyS_finit_module+0x7c/0x88 > [] el0_svc_naked+0x24/0x28 > > > The line that triggers the warning is: > > 674:WARN_ON(!connector->encoder->crtc); > > As far as I can see the encoder->crtc value is being set to a non-NULL value > only > in two places: > - in drm_atomic_helper_update_legacy_modeset_state() after WARN_ON() > encoder->crtc = connector->state->crtc; > - in drm_crtc_helper_set_config(drm_mode_set *set): > encoder->crtc = new_crtc; > > Nothing in the call path from drm_atomic_commit() calls > crtc_funcs->set_config() or > drm_crtc_helper_set_config() directly, so the question is if this WARN() is > actually > valid. > > Call path from drm_atomic_commit: > > drm_atomic_helper_commit() >- drm_atomic_helper_prepare_planes() >- drm_atomic_helper_swap_state() >- drm_atomic_helper_commit_modeset_disables() > - disable_outputs() > - drm_atomic_helper_update_legacy_modeset_state() > - WARN_ON(!connector->encoder->crtc) > > Best regards, > Liviu > > >Hi Liviu > I solved this problem by following change, you can check if your > driver do the same things: > drivers/gpu/drm/bridge/dw_hdmi.c: > - hdmi->connector.encoder = encoder; > +// hdmi->connector.encoder = encoder; > > drm_mode_connector_attach_encoder(&hdmi->connector, > encoder); > > I found some other drivers set connector.encoder before > drm_mode_connector_attach_encoder, some are not. > > drm_mode_connector_attach_encoder already describe the link of > connector and encoder, >so I think "connector.encoder = encoder" is not needed, is that right? I'll have a look, thanks for pointing this. However, my setup uses the tda998x driver for encoder, so I will have to go look there rather than in my driver. Best regards, Liviu > >Thanks. > > -- >
Re: drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?
On Thu, Nov 12, 2015 at 02:34:57PM +0800, Mark yao wrote: Mark, >On 2015年11月12日 14:27, Mark yao wrote: > > On 2015年11月11日 00:56, Thierry Reding wrote: > > On Tue, Nov 10, 2015 at 03:01:03PM +, Liviu Dudau wrote: > > Hello, > > When booting my Juno board with the HDLCD driver that I have converted to > atomic operations I'm getting the following warning: > > Perhaps you can provide pointers to the source code, that might make it > easier for people to spot what's going wrong. > > Thierry > Can you switch your email client to text mode and make it do proper reply quoting? It is rather difficult to follow where your reply comes when you don't use HTML MUAs. Best regards, Liviu > ___ > dri-devel mailing list > [1]dri-de...@lists.freedesktop.org > [2]http://lists.freedesktop.org/mailman/listinfo/dri-devel > > Hi Thierry > I encountered the same problem as Liviu. > I'm coverting rockchip drm to atomic api, when booting with hdmi > connected, get under warning: > > [ 1.300156] WARNING: CPU: 0 PID: 26 at > drivers/gpu/drm/drm_atomic_helper.c:674 > drm_atomic_helper_update_legacy_modeset_state+0x3c/0x1f8() > [ 1.300161] Modules linked in: > [ 1.300171] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 4.3.0-rc5+ > #160 > [ 1.300174] Hardware name: Rockchip (Device Tree) > [ 1.300189] Workqueue: events output_poll_execute > [ 1.300224] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 1.300241] [] (show_stack) from [] > (dump_stack+0x6c/0x88) > [ 1.300255] [] (dump_stack) from [] > (warn_slowpath_common+0x80/0xa8) > [ 1.300265] [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x18/0x1c) > [ 1.300277] [] (warn_slowpath_null) from [] > (drm_atomic_helper_update_legacy_modeset_state+0x3c/0x1f8) > [ 1.300293] [] > (drm_atomic_helper_update_legacy_modeset_state) from [] > (drm_atomic_helper_commit_modeset_disables+0x208/0x364) > [ 1.300305] [] (drm_atomic_helper_commit_modeset_disables) > from [] (drm_atomic_helper_commit+0xf8/0x140) > [ 1.300320] [] (drm_atomic_helper_commit) from [] > (drm_atomic_commit+0x50/0x60) > [ 1.300333] [] (drm_atomic_commit) from [] > (restore_fbdev_mode+0xf4/0x278) > [ 1.300345] [] (restore_fbdev_mode) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x30/0x68) > [ 1.300357] [] (drm_fb_helper_restore_fbdev_mode_unlocked) > from [] (drm_fb_helper_set_par+0x3c/0x54) > [ 1.300368] [] (drm_fb_helper_set_par) from [] > (drm_fb_helper_hotplug_event+0xe4/0xfc) > [ 1.300382] [] (drm_fb_helper_hotplug_event) from > [] (drm_kms_helper_hotplug_event+0x24/0x28) > [ 1.300396] [] (drm_kms_helper_hotplug_event) from > [] (output_poll_execute+0x134/0x18c) > [ 1.300413] [] (output_poll_execute) from [] > (process_one_work+0x1e0/0x318) > [ 1.300426] [] (process_one_work) from [] > (worker_thread+0x378/0x4c4) > [ 1.300438] [] (worker_thread) from [] > (kthread+0xdc/0xf0) > [ 1.300450] [] (kthread) from [] > (ret_from_fork+0x14/0x3c) > > I can't found who can set encoder->crtc value before atomic_commit, > what's going wrong? > > -- > Ｍark Yao > >Hi > here is the message before warning happen (filtering by "dmesg | grep > drm"), Hope this helps: > >[ 1.245700] [drm:drm_minor_register] >[ 1.245925] [drm:drm_minor_register] new minor registered 64 >[ 1.245934] [drm:drm_minor_register] >[ 1.245942] [drm:drm_minor_register] >[ 1.246099] [drm:drm_minor_register] new minor registered 0 >[ 1.272968] rockchip-drm display-subsystem: bound ff94.vop (ops > vop_component_ops) >[ 1.294790] rockchip-drm display-subsystem: bound ff93.vop (ops > vop_component_ops) >[ 1.295086] rockchip-drm display-subsystem: bound ff98.hdmi (ops > dw_hdmi_rockchip_ops) >[ 1.295218] [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs >[ 1.295222] [drm:drm_sysfs_hotplug_event] generating hotplug event >[ 1.295268] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >[ 1.295270] [drm] No driver support for vblank timestamp query. >[ 1.295290] [drm:drm_helper_probe_single_connector_modes_merge_bits] > [CONNECTOR:29:HDMI-A-1] >[ 1.295304] [drm:drm_helper_probe_single_connector_modes_merge_bits] > [CONNECTOR:29:HDMI-A-1] status updated from 3 to 1 >[ 1.295470] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent > adapter rk3x-i2c >[ 1.295513] [drm:drm_mode_debug_printmodeline] Modeline 30:"640x480" 0 > 25175 640 656 752 800 480 490 492 525 0x40 0xa >[ 1.295518] [drm:drm_mode_prune_invalid] Not using 640x480 mode: BAD >[ 1.295531] [drm:drm_mode_debug_printmodeline] Modeline 33:"848x480" 0 > 33750 848 864 976 1088 480 486 494 517 0x40 0x5 >[
Re: Shut up unhandled MSR warnings
On 12/11/2015 11:13, Borislav Petkov wrote: > Hey Paolo, > > do we apply stuff like that below? If we really need to, we do. > When booting guests all the time here, dmesg gets filled up with those > "unhandled rdmsr" useless warnings. The patch below shuts them up. > > The only problem is that the IC CFG MSR has those fields > defined starting from F15h and I don't see a way to check the > family/model/stepping of the guest CPU in kvm. Is there? Yes, see guest_cpuid_has_* for an example of reading the CPUID values. But if it's defined for _all_ models starting at family 21, we can just do it unconditionally. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] perf/core: rcu fixes
On Thu, Nov 12, 2015 at 11:00:02AM +0100, Stephane Eranian wrote: > > This short patch series fixes some issues with RCU locking in the generic > perf layer. > > Patch 1 fixes cgroup switching rcu issues related to the fact that > perf_cgroup_sched_out() and perf_cgroup_sched_in() were missing some > rcu read lock to protect the reference to the cgroup. Consequently, > we moved the rcu readlock out of perf_cgroup_switch() to avoid double > calls. > > Patch 2 reinforces the testing for the rcu locking in perf cgorup code. > Either we have to hold the rcu read lock or we must have the ctx->lock > which guarantees the task cannot leave the cgroup. > > Thanks to Peter and Eric from their suggestions on how to fix this correctly. > > Stephane Eranian (2): > perf/core: fix RCU problem with cgroup context switching code > perf/core: robustify perf_cgroup_from_task rcu checks Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Thu, 2015-11-12 at 10:18 +0530, punnaiah choudary kalluri wrote:
> On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko
> wrote:
> > On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote:
> > > Added the basic driver for Arasan Nand Flash Controller used in
> > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
> > > correction.
> > >
> >
> > > +config MTD_NAND_ARASAN
> > > + tristate "Support for Arasan Nand Flash controller"
> > > + depends on MTD_NAND
> >
> > This looks useless since you can't see the item without MTD_NAND is
> > chosen.
> >
> > > + help
> > > + Enables the driver for the Arasan Nand Flash controller
> > > on
> > > + Zynq UltraScale+ MPSoC.
> > > +
> > > endif # MTD_NAND
> > >
> >
> > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o
> >
> > "nfc" part a bit ambiguous since NFC might be Near Field
> > Communication.
>
> This driver is under mtd/nand so, there is no point of confusion and
> in this context nfc is nand flash controller.
Imagine that at some point arasan (whatever) releases NFC chip, and
someone puts the driver under corresponding folder but with the same
file name (and driver name). Do you see a problem? I see two:
- if you built-in both how you supply command line parameters?
- some platform code may do request_module() or
platform_driver_register() with the name you provided as DRIVER_NAME.
So, I just suggest distinguishable name. But it's a call of NAND
subsystem maintainer.
> >
> > Perhaps "nand_fc" or something like that?
> >
> > > +#include
> > > +
> > > +#define DRIVER_NAME "arasan_nfc"
> >
> > Ditto.
> >
> > > +static int anfc_device_ready(struct mtd_info *mtd,
> > > + struct nand_chip *chip)
> > > +{
> > > + u8 status;
> > > + unsigned long timeout = jiffies + STATUS_TIMEOUT;
> > > +
> > > + do {
> > > + chip->cmdfunc(mtd, NAND_CMD_STATUS, 0, 0);
> > > + status = chip->read_byte(mtd);
> > > + if (status & ONFI_STATUS_READY) {
> >
> > > + if (status & ONFI_STATUS_FAIL)
> > > + return NAND_STATUS_FAIL;
> >
> > This is invariant to the loop, perhaps move outside.
>
> Nand device is ready means it is ready to accept next command and
> it is done with previous command. It doesn't mean that previous
> command is success, it can fail also.
This is style and logic comment. I do not object how NAND works.
> >
> > > + break;
> > > + }
> > > + cpu_relax();
> > > + } while (!time_after_eq(jiffies, timeout));
Just move it here. It will be the same, but unload busy loop.
Did I miss something?
> > > +
> > > + if (time_after_eq(jiffies, timeout)) {
> > > + pr_err("%s timed out\n", __func__);
> >
> > dev_err?
> >
> > > +static void anfc_read_buf(struct mtd_info *mtd, uint8_t *buf,
> > > int
> > > len)
> > > +{
> > > + u32 i, pktcount, buf_rd_cnt = 0, pktsize;
> >
> > Type for i looks unsigned int, why u32? Same question for all
> > variables
> > that are not used to directly program HW.
> >
u32 and other derivatives mostly common when you program HW. Here for
simple stuff better to use plain types, therefore unsigned int.
> > > int len)
> > > +{
> > > + u32 buf_wr_cnt = 0, pktcount = 1, i, pktsize;
> >
> > Useless assignment of pktcount. Check all your definition blocks
> > for
> > similar thing.
>
> what is the problem with u32 here ? may be i am missing something
> here but
> i really want to know the reason.
Ditto.
> > > + writel(lower_32_bits(paddr), nfc->base +
> > > DMA_ADDR0_OFST);
> > > + writel(upper_32_bits(paddr), nfc->base +
> > > DMA_ADDR1_OFST);
> >
> > lo_hi_writeq();
>
> Ok. let me check if this function is available across all
> the platforms.
The same spread as for writel().
If your HW allows you to do 64-bit writes on 64-bit platforms, just
use writeq(), but still include io-64-nonatomic-lo-hi.h (or how it's
called nowadays).
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCIe host controller behind IOMMU on ARM
On Thu, Nov 12, 2015 at 09:26:33AM +, Phil Edworthy wrote: > Hi Liviu, Arnd, > > On 11 November 2015 18:25, LIviu wrote: > > On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote: > > > Hi Liviu, Will, > > > > > > On 04 November 2015 15:19, Phil wrote: > > > > On 04 November 2015 15:02, Liviu wrote: > > > > > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote: > > > > > > Hi Liviu, > > > > > > > > > > > > On 04 November 2015 14:24, Liviu wrote: > > > > > > > On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am trying to hook up a PCIe host controller that sits behind > > > > > > > > an > > IOMMU, > > > > > > > > but having some problems. > > > > > > > > > > > > > > > > I'm using the pcie-rcar PCIe host controller and it works fine > > > > > > > > without > > > > > > > > the IOMMU, and I can attach the IOMMU to the controller such > > > > > > > > that > > any > > > > > calls > > > > > > > > to dma_alloc_coherent made by the controller driver uses the > > > > iommu_ops > > > > > > > > version of dma_ops. > > > > > > > > > > > > > > > > However, I can't see how to make the endpoints to utilise the > > dma_ops > > > > that > > > > > > > > the controller uses. Shouldn't the endpoints inherit the > > > > > > > > dma_ops from > > the > > > > > > > > controller? > > > > > > > > > > > > > > No, not directly. > > > > > > > > > > > > > > > Any pointers for this? > > > > > > > > > > > > > > You need to understand the process through which a driver for > > endpoint > > > > get > > > > > > > an address to be passed down to the device. Have a look at > > > > > > > Documentation/DMA-API-HOWTO.txt, there is a nice explanation > > > > > > > there. > > > > > > > (Hint: EP driver needs to call dma_map_single). > > > > > > > > > > > > > > Also, you need to make sure that the bus address that ends up > > > > > > > being set > > > > into > > > > > > > the endpoint gets translated correctly by the host controller > > > > > > > into an > > address > > > > > > > that the IOMMU can then translate into physical address. > > > > > > Sure, though since this is bog standard Intel PCIe ethernet card > > > > > > which > > works > > > > > > fine when the IOMMU is effectively unused, I don’t think there is a > > problem > > > > > > with that. > > > > > > > > > > > > The driver for the PCIe controller sets up the IOMMU mapping ok > > > > > > when I > > > > > > do a test call to dma_alloc_coherent() in the controller's driver. > > > > > > i.e. when I > > > > > > do this, it ends up in arm_iommu_alloc_attrs(), which calls > > > > > > __iommu_alloc_buffer() and __alloc_iova(). > > > > > > > > > > > > When an endpoint driver allocates and maps a dma coherent buffer it > > > > > > also needs to end up in arm_iommu_alloc_attrs(), but it doesn't. > > > > > > > > > > Why do you think that? Remember that the only thing attached to the > > IOMMU > > > > is > > > > > the > > > > > host controller. The endpoint is on the PCIe bus, which gets a > > > > > different > > > > > translation > > > > > that the IOMMU knows nothing about. If it helps you to visualise it > > > > > better, > > think > > > > > of the host controller as another IOMMU device. It's the ops of the > > > > > host > > > > > controller > > > > > that should be invoked, not the IOMMU's. > > > > Ok, that makes sense. I'll have a think and poke it a bit more... > > > > Hi Phil, > > > > Not trying to ignore your email, but I thought this is more in Will's > > backyard. > > > > > Somewhat related to this, since our PCIe controller HW is limited to > > > 32-bit AXI address range, before trying to hook up the IOMMU I have > > > tried to limit the dma_mask for PCI cards to DMA_BIT_MASK(32). The > > > reason being that Linux uses a 1 to 1 mapping between PCI addresses > > > and cpu (phys) addresses when there isn't an IOMMU involved, so I > > > think that we need to limit the PCI address space used. > > > > I think you're mixing things a bit or not explaining them very well. Having > > the > > PCIe controller limited to 32-bit AXI does not mean that the PCIe bus cannot > > carry 64-bit addresses. It depends on how they get translated by the host > > bridge > > or its associated ATS block. I can't see why you can't have a setup where > > the CPU addresses are 32-bit but the PCIe bus addresses are all 64-bit. > > You just have to be careful on how you setup your mem64 ranges so that they > > don't > > overlap with the 32-bit ranges when translated. > From a HW point of view I agree that we can setup the PCI host bridge such > that > it uses 64-bit PCI address, with 32-bit cpu addresses. Though in practice > doesn't > this mean that the dma ops used by card drivers has to be provided by our PCI > host bridge driver so we can apply the translation to those PCI addresses? I thought all addresses that are set into the cards go through pcibios_resource_to_bus() which give you the PCI address
Re: [PATCH 0/4] dm verity: add support for error correction
On 11/09/2015 08:19 PM, Sami Tolvanen wrote: ... > We don't see actual I/O errors very often. Most corruption we've seen > is caused by flaky hardware that doesn't return errors. However, I can > certainly change to code to attempt recovery in this case too. So if I understand it correctly, there is a simplified flash controller that can send data with bit flips without detection? (IOW in "real" SSD this kind of error should be detected internally by some bad block management?) This is why I asked about some statistics of real visible types of errors. For this use case it makes sense to have error correction here but then we should clearly said that it makes no sense to switch it on for "real" hw that does internal integrity check or error correction (but not authenticated integrity check as dm-verity). ... >> If this error correction feature is going to go upstream we really >> should see any associated userspace enablement also included in >> veritysetup. > > I can look into this. Yes, please, patches do not to be production ready (I can integrate it to veritysetup upstream myself) but it would be very nice that released veritysetup can configure all dm-verity features in the same time the mainline kernel is marked stable. (The same applies for dm-crypt & cryptsetup.) Thanks, Milan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] locking: Introduce smp_cond_acquire()
On Thu, Nov 12, 2015 at 03:14:51PM +0800, Boqun Feng wrote: > Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock() > only guarantees that the memory operations following spin_lock() can't > be reorder before the *LOAD* part of spin_lock() not the *STORE* part, > i.e. the case below can happen(assuming the spin_lock() is implemented > as ll/sc loop) > > spin_lock(&lock): > r1 = *lock; // LL, r1 == 0 > o = READ_ONCE(object); // could be reordered here. > *lock = 1; // SC > > This could happen because of the ACQUIRE semantics of spin_lock(), and > the current implementation of spin_lock() on PPC allows this happen. Urgh, you just _had_ to send an email like this, didn't you ;-) I think AARGH64 does the same thing. They either use LDAXR/STXR, which also places the ACQUIRE on the load, or use LDADDA (v8.1) which I suspect does the same, but I'm not entirely sure how to decode these 8.1 atomics yet. Let me think a little more on this.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: module: save load_info for livepatch modules
On Thu 2015-11-12 00:33:12, Jessica Yu wrote:
> +++ Miroslav Benes [11/11/15 15:17 +0100]:
> >On Mon, 9 Nov 2015, Jessica Yu wrote:
> >
> >>diff --git a/include/linux/module.h b/include/linux/module.h
> >>index 3a19c79..c8680b1 100644
> >>--- a/include/linux/module.h
> >>+++ b/include/linux/module.h
> >
> >[...]
> >
> >>+#ifdef CONFIG_LIVEPATCH
> >>+extern void klp_prepare_patch_module(struct module *mod,
> >>+struct load_info *info);
> >>+extern int
> >>+apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
> >>+ unsigned int symindex, unsigned int relsec,
> >>+ struct module *me);
> >>+#endif
> >>+
> >> #else /* !CONFIG_MODULES... */
> >
> >apply_relocate_add() is already in include/linux/moduleloader.h (guarded
> >by CONFIG_MODULES_USE_ELF_RELA), so maybe we can just include that where
> >we need it. As for the klp_prepare_patch_module() wouldn't it be better to
> >have it in our livepatch.h and include that in kernel/module.c?
>
> Yeah, Petr pointed this out as well :-) I will just include
> moduleloader.h for the apply_relocate_add() declaration.
>
> It also looks like we have some disagreement over where to put
> klp_prepare_patch_module(), either in livepatch/core.c (and add the
> function declaration in livepatch.h, and have module.c include
> livepatch.h) or in kernel/module.c, keeping the
> klp_prepare_patch_module() declaration in module.h. Maybe Rusty can
> provide some input.
>
> >> /* Given an address, look for it in the exception tables. */
> >>diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> >>index 6e53441..087a8c7 100644
> >>--- a/kernel/livepatch/core.c
> >>+++ b/kernel/livepatch/core.c
> >>@@ -1001,6 +1001,23 @@ static struct notifier_block klp_module_nb = {
> >>.priority = INT_MIN+1, /* called late but before ftrace notifier */
> >> };
> >>
> >>+/*
> >>+ * Save necessary information from info in order to be able to
> >>+ * patch modules that might be loaded later
> >>+ */
> >>+void klp_prepare_patch_module(struct module *mod, struct load_info *info)
> >>+{
> >>+ Elf_Shdr *symsect;
> >>+
> >>+ symsect = info->sechdrs + info->index.sym;
> >>+ /* update sh_addr to point to symtab */
> >>+ symsect->sh_addr = (unsigned long)info->hdr + symsect->sh_offset;
> >>+
> >>+ mod->info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>+ memcpy(mod->info, info, sizeof(*info));
> >>+
> >>+}
> >
> >What about arch-specific 'struct mod_arch_specific'? We need to preserve
> >it somewhere as well for s390x and other non-x86 architectures.
>
> Ah! Thank you for catching this, I overlooked this important detail.
> Yes, we do need to save the arch-specific struct. We would be in
> trouble for s390 relocs if we didn't. I am trying to think of a way to
> save this information for s390, since s390's module_finalize() frees
> mod->arch.syminfo, which we definitely need in order for the call to
> apply_relocate_add() to work. Maybe we can add an extra call right
> before module_finalize() that will do some livepatch-specific
> processing and copy this information (this would be in
> post_relocation() in kernel/module.c). Perhaps this patchset cannot be
> entirely free of arch-specific code after all :-( Still thinking.
I think about adding a flag somewhere, e.g. mod->preserve_relocs.
It might be set in simplify_symbols() when SHN_LIVEPATCH is found.
It might be checked when freeing the needed structures in both
the generic and arch-specific code.
> >>+#ifdef CONFIG_LIVEPATCH
> >>+ /*
> >>+* Save sechdrs, indices, and other data from info
> >>+* in order to patch to-be-loaded modules.
> >>+* Do not call free_copy() for livepatch modules.
> >>+*/
> >>+ if (get_modinfo((struct load_info *)info, "livepatch"))
> >>+ klp_prepare_patch_module(mod, info);
> >>+ else
> >>+ free_copy(info);
> >>+#else
> >>/* Get rid of temporary copy. */
> >>free_copy(info);
> >>+#endif
> >
> >Maybe I am missing something but isn't it necessary to call vfree() on
> >info somewhere in the end?
>
> So free_copy() will call vfree(info->hdr), except in livepatch modules
> we want to keep all the elf section information stored there, so we
> avoid calling free_copy(), As for the info struct itself, if you look
> at the init_module and finit_module syscall definitions in
> kernel/module.c, you will see that info is actually a local function
> variable, simply passed in to the call to load_module(), and will be
> automatically deallocated when the syscall returns. :-) No need to
> explicitly free info.
We still have to free the copied or preserved structures when
the module is unloaded.
Thank you,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3 v4] livepatch: add old_sympos as disambiguator field to klp_reloc
On Wed, 11 Nov 2015, Chris J Arges wrote: > In cases of duplicate symbols, sympos will be used to disambiguate instead > of val. By default old_sympos will be 0, and patching will only succeed if > the symbol is unique. Specifying a positive value will ensure that > occurrence of the symbol will be used for patching if it is valid. Again "...occurrence of the symbol in kallsyms for the patched object will be used..." > 2 files changed, 18 insertions(+), 61 deletions(-) And this is indeed great. Miroslav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] FS-Cache: Add missing initialization of ret in cachefiles_write_page()
Hi David,
On Thu, Nov 12, 2015 at 11:15 AM, David Howells wrote:
> Geert Uytterhoeven wrote:
>
>> - int ret;
>> + int ret = 0;
>
> This isn't quite the right solution. The uninitialised error path needs to
> set -ENOBUFS.
That's what your commit 102f4d900c9c8f5e ("FS-Cache: Handle a write to the
page immediately beyond the EOF marker") does, and is also in its commit
description:
Whilst we're at it, change the triggered assertion in CacheFiles to just
return -ENOBUFS instead.
"ret" is used only to print the original error in a debug message.
> Unfortunately, my compiler doesn't show a warning:-/
Need old gcc (4.1.2 ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3 v4] livepatch: add old_sympos as disambiguator field to klp_func
Next to Josh's remarks I have some more (mainly nitpicks, so it is often up to you). On Wed, 11 Nov 2015, Chris J Arges wrote: > In cases of duplicate symbols, old_sympos will be used to disambiguate > instead of old_addr. By default old_sympos will be 0, and patching will > only succeed if the symbol is unique. Specifying a positive value will > ensure that occurrence of the symbol will be used for patching if it is "...occurrence of the symbol in kallsyms for the patched object will be used..." Just to have it even in the changelog for clarity. > valid. Finally, old_addr is now an internal structure element and not to > be specified by the user. > @@ -159,36 +160,45 @@ static int klp_find_callback(void *data, const char > *name, > return 0; > > /* > - * args->addr might be overwritten if another match is found > - * but klp_find_object_symbol() handles this and only returns the > - * addr if count == 1. > + * increment and assign address, return only if checking pos and > + * it matches count. >*/ > - args->addr = addr; > args->count++; > + args->addr = addr; I guess that this row swap is remnant of a rebase. Anyway it is superfluous. > + if ((args->pos > 0) && (args->count == args->pos)) > + return 1; We could add an optimization here. If args->pos == 0 and args->count > 1 we can return 1, because the symbol is not unique. The case is then correctly handled in klp_find_object_symbol. There is no need to walk through the rest of kallsyms. Thanks, Miroslav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 4/4] iio: ina2xx: add SOFTWARE buffer mode using an iio kfifo.
On 11/12/2015 11:18 AM, Marc Titinger wrote: [...] >> Slightly OT, but do you already have some Sigrok IIO support? I have this >> scheduled for end of the month, maybe we can align our strategies here and >> avoid duplicated work. > > How fortunate! I've started some preliminary work like cloning the demo > driver into a skeletton for 'hardware/generic-iio/api.c', adding the > build/ac plumbing, and linking to libiio with the idea of using iio_info to > create a generic enumeration of the iio-context into sigrok channels. > > Now, I'm not familiar with Glib and it might not be my prio until a couple > of weeks, so I'd be super happy to wait for you if you are keen to do that > part :) > > What would be the best spot to chat about this ? #sigrok on irc.freenode.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next RFC V3 0/3] basic busy polling support for vhost_net
On 11/12/2015 06:16 PM, Jason Wang wrote: > Hi all: > > This series tries to add basic busy polling for vhost net. The idea is > simple: at the end of tx/rx processing, busy polling for new tx added > descriptor and rx receive socket for a while. The maximum number of > time (in us) could be spent on busy polling was specified ioctl. > > Test were done through: > > - 50 us as busy loop timeout > - Netperf 2.6 > - Two machines with back to back connected ixgbe > - Guest with 1 vcpu and 1 queue > > Results: > - For stream workload, ioexits were reduced dramatically in medium > size (1024-2048) of tx (at most -39%) and almost all rx (at most > -79%) as a result of polling. This compensate for the possible > wasted cpu cycles more or less. That porbably why we can still see > some increasing in the normalized throughput in some cases. > - Throughput of tx were increased (at most 105%) expect for the huge > write (16384). And we can send more packets in the case (+tpkts were > increased). > - Very minor rx regression in some cases. > - Improvemnt on TCP_RR (at most 16%). Forget to mention, the following test results by order are: 1) Guest TX 2) Guest RX 3) TCP_RR > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ >64/ 1/ +9%/ -17%/ +5%/ +10%/ -2% >64/ 2/ +8%/ -18%/ +6%/ +10%/ -1% >64/ 4/ +4%/ -21%/ +6%/ +10%/ -1% >64/ 8/ +9%/ -17%/ +6%/ +9%/ -2% > 256/ 1/ +20%/ -1%/ +15%/ +11%/ -9% > 256/ 2/ +15%/ -6%/ +15%/ +8%/ -8% > 256/ 4/ +17%/ -4%/ +16%/ +8%/ -8% > 256/ 8/ -61%/ -69%/ +16%/ +10%/ -10% > 512/ 1/ +15%/ -3%/ +19%/ +18%/ -11% > 512/ 2/ +19%/0%/ +19%/ +13%/ -10% > 512/ 4/ +18%/ -2%/ +18%/ +15%/ -10% > 512/ 8/ +17%/ -1%/ +18%/ +15%/ -11% > 1024/ 1/ +25%/ +4%/ +27%/ +16%/ -21% > 1024/ 2/ +28%/ +8%/ +25%/ +15%/ -22% > 1024/ 4/ +25%/ +5%/ +25%/ +14%/ -21% > 1024/ 8/ +27%/ +7%/ +25%/ +16%/ -21% > 2048/ 1/ +32%/ +12%/ +31%/ +22%/ -38% > 2048/ 2/ +33%/ +12%/ +30%/ +23%/ -36% > 2048/ 4/ +31%/ +10%/ +31%/ +24%/ -37% > 2048/ 8/ +105%/ +75%/ +33%/ +23%/ -39% > 16384/ 1/0%/ -14%/ +2%/0%/ +19% > 16384/ 2/0%/ -13%/ +19%/ -13%/ +17% > 16384/ 4/0%/ -12%/ +3%/0%/ +2% > 16384/ 8/0%/ -11%/ -2%/ +1%/ +1% > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ >64/ 1/ -7%/ -23%/ +4%/ +6%/ -74% >64/ 2/ -2%/ -12%/ +2%/ +2%/ -55% >64/ 4/ +2%/ -5%/ +10%/ -2%/ -43% >64/ 8/ -5%/ -5%/ +11%/ -34%/ -59% > 256/ 1/ -6%/ -16%/ +9%/ +11%/ -60% > 256/ 2/ +3%/ -4%/ +6%/ -3%/ -28% > 256/ 4/0%/ -5%/ -9%/ -9%/ -10% > 256/ 8/ -3%/ -6%/ -12%/ -9%/ -40% > 512/ 1/ -4%/ -17%/ -10%/ +21%/ -34% > 512/ 2/0%/ -9%/ -14%/ -3%/ -30% > 512/ 4/0%/ -4%/ -18%/ -12%/ -4% > 512/ 8/ -1%/ -4%/ -1%/ -5%/ +4% > 1024/ 1/0%/ -16%/ +12%/ +11%/ -10% > 1024/ 2/0%/ -11%/0%/ +5%/ -31% > 1024/ 4/0%/ -4%/ -7%/ +1%/ -22% > 1024/ 8/ -5%/ -6%/ -17%/ -29%/ -79% > 2048/ 1/0%/ -16%/ +1%/ +9%/ -10% > 2048/ 2/0%/ -12%/ +7%/ +9%/ -26% > 2048/ 4/0%/ -7%/ -4%/ +3%/ -64% > 2048/ 8/ -1%/ -5%/ -6%/ +4%/ -20% > 16384/ 1/0%/ -12%/ +11%/ +7%/ -20% > 16384/ 2/0%/ -7%/ +1%/ +5%/ -26% > 16384/ 4/0%/ -5%/ +12%/ +22%/ -23% > 16384/ 8/0%/ -1%/ -8%/ +5%/ -3% > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ > 1/ 1/ +9%/ -29%/ +9%/ +9%/ +9% > 1/25/ +6%/ -18%/ +6%/ +6%/ -1% > 1/50/ +6%/ -19%/ +5%/ +5%/ -2% > 1/ 100/ +5%/ -19%/ +4%/ +4%/ -3% >64/ 1/ +10%/ -28%/ +10%/ +10%/ +10% >64/25/ +8%/ -18%/ +7%/ +7%/ -2% >64/50/ +8%/ -17%/ +8%/ +8%/ -1% >64/ 100/ +8%/ -17%/ +8%/ +8%/ -1% > 256/ 1/ +10%/ -28%/ +10%/ +10%/ +10% > 256/25/ +15%/ -13%/ +15%/ +15%/0% > 256/50/ +16%/ -14%/ +18%/ +18%/ +2% > 256/ 100/ +15%/ -13%/ +12%/ +12%/ -2% > > Changes from V2: > - poll also at the end of rx handling > - factor out the polling logic and optimize the code a little bit > - add two ioctls to get and set the busy poll timeout > - test on ixgbe (which can give more stable and reproducable numbers) > instead of mlx4. > > Changes from V1: > - Add a comment for vhost_has_work() to explain why it could be > lockless > - Add param description for busyloop_timeout > - Split out the busy polling logic into a new helper > - Check and exit the loop when there's a pending signal > - Disable preemption during busy looping to make sure lock_clock() was > correctly
Re: MIPS: BMIPS: Enable GZIP ramdisk and timed printks
Hi Florian, your patch "MIPS: BMIPS: Enable GZIP ramdisk and timed printks" showed up as commit fb9e5642aa9e in linux-next today (that is, next-20151112). I noticed it because we (a research group from Erlangen[0]) are running daily checks on linux-next. Your commit adds two entries to arch/mips/configs/bmips_stb_defconfig, but one of them has a typo (line 37): CONFIG_PRINK_TIME=y which should instead say (notice the missing 'T'): CONFIG_PRINTK_TIME=y Not sure how this got two Reviewed-by's, as this simple mistake could have been easily spotted by running scripts/checkkconfigsymbols.py on the patch. Regards, Andreas [0] https://cados.cs.fau.de Original patchwork: https://patchwork.linux-mips.org/patch/11307/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 4/4] iio: ina2xx: add SOFTWARE buffer mode using an iio kfifo.
On 10/11/2015 19:23, Lars-Peter Clausen wrote: On 11/10/2015 05:07 PM, Marc Titinger wrote: Capture the active scan_elements into a kfifo. The capture thread will compute the remaining time until the next capture tick, and do an active wait (udelay). This will produce a stream of up to fours channels plus a 64bits timestamps (ns). # iio_readdev ina226 | od -x WARNING: High-speed mode not enabled 000 042f 0d5a 002e 010c 4be8 4eb4 0013 020 0430 0d5a 002e 010c a704 4f3e 0013 040 0430 0d5a 002e 010c b477 4fc7 0013 060 042f 0d5b 002e 010c 8052 5050 0013 100 042f 0d5b 002e 010c 5d92 50d8 0013 120 0430 0d5a 002e 010c fa59 515e 0013 140 0430 0d5b 002e 010c 95d2 51e5 0013 Signed-off-by: Marc Titinger Hi Lars, Interesting approach. I think if we are going to due this we want to make this kind of emulation generic. Have you seen the software trigger and configfs support patches[1] from Daniel? It kind of achieves the same as you do, but using hrtimers. I totally agree, let me have a look on those patches maybe I could add an active waiting scheme for platforms w/o hrtimers ? --- Ina2xx does not support auto-increment, hence the capture threads sticks with single register reads instead of regmap_bulk_read. The proper scales must be applied to those raw register values, I'm in favor of doing the conversion in userland in a client plugin Yes, conversion should not be done in kernel space, we don't want to impose the performance penalty on users which don't need it and you can typically do it faster in userspace anyway where you have floats and SSE and what not. for instance a sigrok Slightly OT, but do you already have some Sigrok IIO support? I have this scheduled for end of the month, maybe we can align our strategies here and avoid duplicated work. How fortunate! I've started some preliminary work like cloning the demo driver into a skeletton for 'hardware/generic-iio/api.c', adding the build/ac plumbing, and linking to libiio with the idea of using iio_info to create a generic enumeration of the iio-context into sigrok channels. Now, I'm not familiar with Glib and it might not be my prio until a couple of weeks, so I'd be super happy to wait for you if you are keen to do that part :) What would be the best spot to chat about this ? Marc. - Lars [1] https://lkml.org/lkml/2015/8/10/877 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next RFC V3 2/3] vhost: introduce vhost_vq_more_avail()
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 26 +-
drivers/vhost/vhost.h | 1 +
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 163b365..b86c5aa 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1633,10 +1633,25 @@ void vhost_add_used_and_signal_n(struct vhost_dev *dev,
}
EXPORT_SYMBOL_GPL(vhost_add_used_and_signal_n);
+bool vhost_vq_more_avail(struct vhost_dev *dev, struct vhost_virtqueue *vq)
+{
+ __virtio16 avail_idx;
+ int r;
+
+ r = __get_user(avail_idx, &vq->avail->idx);
+ if (r) {
+ vq_err(vq, "Failed to check avail idx at %p: %d\n",
+ &vq->avail->idx, r);
+ return false;
+ }
+
+ return vhost16_to_cpu(vq, avail_idx) != vq->avail_idx;
+}
+EXPORT_SYMBOL_GPL(vhost_vq_more_avail);
+
/* OK, now we need to know about added descriptors. */
bool vhost_enable_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
{
- __virtio16 avail_idx;
int r;
if (!(vq->used_flags & VRING_USED_F_NO_NOTIFY))
@@ -1660,14 +1675,7 @@ bool vhost_enable_notify(struct vhost_dev *dev, struct
vhost_virtqueue *vq)
/* They could have slipped one in as we were doing that: make
* sure it's written, then check again. */
smp_mb();
- r = __get_user(avail_idx, &vq->avail->idx);
- if (r) {
- vq_err(vq, "Failed to check avail idx at %p: %d\n",
- &vq->avail->idx, r);
- return false;
- }
-
- return vhost16_to_cpu(vq, avail_idx) != vq->avail_idx;
+ return vhost_vq_more_avail(dev, vq);
}
EXPORT_SYMBOL_GPL(vhost_enable_notify);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index ea0327d..5983a13 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -159,6 +159,7 @@ void vhost_add_used_and_signal_n(struct vhost_dev *, struct
vhost_virtqueue *,
struct vring_used_elem *heads, unsigned count);
void vhost_signal(struct vhost_dev *, struct vhost_virtqueue *);
void vhost_disable_notify(struct vhost_dev *, struct vhost_virtqueue *);
+bool vhost_vq_more_avail(struct vhost_dev *, struct vhost_virtqueue *);
bool vhost_enable_notify(struct vhost_dev *, struct vhost_virtqueue *);
int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next RFC V3 3/3] vhost_net: basic polling support
This patch tries to poll for new added tx buffer or socket receive
queue for a while at the end of tx/rx processing. The maximum time
spent on polling were specified through a new kind of vring ioctl.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c| 77 +++---
drivers/vhost/vhost.c | 15 +
drivers/vhost/vhost.h | 1 +
include/uapi/linux/vhost.h | 11 +++
4 files changed, 99 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9eda69e..a38fa32 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -287,6 +287,45 @@ static void vhost_zerocopy_callback(struct ubuf_info
*ubuf, bool success)
rcu_read_unlock_bh();
}
+static inline unsigned long busy_clock(void)
+{
+ return local_clock() >> 10;
+}
+
+static bool vhost_can_busy_poll(struct vhost_dev *dev,
+ unsigned long endtime)
+{
+ return likely(!need_resched()) &&
+ likely(!time_after(busy_clock(), endtime)) &&
+ likely(!signal_pending(current)) &&
+ !vhost_has_work(dev) &&
+ single_task_running();
+}
+
+static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
+ struct vhost_virtqueue *vq,
+ struct iovec iov[], unsigned int iov_size,
+ unsigned int *out_num, unsigned int *in_num)
+{
+ unsigned long uninitialized_var(endtime);
+
+ if (vq->busyloop_timeout) {
+ preempt_disable();
+ endtime = busy_clock() + vq->busyloop_timeout;
+ }
+
+ while (vq->busyloop_timeout &&
+ vhost_can_busy_poll(vq->dev, endtime) &&
+ !vhost_vq_more_avail(vq->dev, vq))
+ cpu_relax();
+
+ if (vq->busyloop_timeout)
+ preempt_enable();
+
+ return vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
+out_num, in_num, NULL, NULL);
+}
+
/* Expects to be always run from workqueue - which acts as
* read-size critical section for our kind of RCU. */
static void handle_tx(struct vhost_net *net)
@@ -331,10 +370,9 @@ static void handle_tx(struct vhost_net *net)
% UIO_MAXIOV == nvq->done_idx))
break;
- head = vhost_get_vq_desc(vq, vq->iov,
-ARRAY_SIZE(vq->iov),
-&out, &in,
-NULL, NULL);
+ head = vhost_net_tx_get_vq_desc(net, vq, vq->iov,
+ ARRAY_SIZE(vq->iov),
+ &out, &in);
/* On error, stop handling until the next kick. */
if (unlikely(head < 0))
break;
@@ -435,6 +473,35 @@ static int peek_head_len(struct sock *sk)
return len;
}
+static int vhost_net_peek_head_len(struct vhost_net *net, struct sock *sk)
+{
+ struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
+ struct vhost_virtqueue *vq = &nvq->vq;
+ unsigned long uninitialized_var(endtime);
+
+ if (vq->busyloop_timeout) {
+ mutex_lock(&vq->mutex);
+ vhost_disable_notify(&net->dev, vq);
+ preempt_disable();
+ endtime = busy_clock() + vq->busyloop_timeout;
+ }
+
+ while (vq->busyloop_timeout &&
+ vhost_can_busy_poll(&net->dev, endtime) &&
+ skb_queue_empty(&sk->sk_receive_queue) &&
+ !vhost_vq_more_avail(&net->dev, vq))
+ cpu_relax();
+
+ if (vq->busyloop_timeout) {
+ preempt_enable();
+ if (vhost_enable_notify(&net->dev, vq))
+ vhost_poll_queue(&vq->poll);
+ mutex_unlock(&vq->mutex);
+ }
+
+ return peek_head_len(sk);
+}
+
/* This is a multi-buffer version of vhost_get_desc, that works if
* vq has read descriptors only.
* @vq - the relevant virtqueue
@@ -553,7 +620,7 @@ static void handle_rx(struct vhost_net *net)
vq->log : NULL;
mergeable = vhost_has_feature(vq, VIRTIO_NET_F_MRG_RXBUF);
- while ((sock_len = peek_head_len(sock->sk))) {
+ while ((sock_len = vhost_net_peek_head_len(net, sock->sk))) {
sock_len += sock_hlen;
vhost_len = sock_len + vhost_hlen;
headcount = get_rx_bufs(vq, vq->heads, vhost_len,
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index b86c5aa..8f9a64c 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -285,6 +285,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->memory = NULL;
vq->is_le = virtio_legacy_is_little_endian();
vhost_vq_reset_user_be(vq);
+ vq->busyloop_timeout = 0;
}
static int vho
[PATCH net-next RFC V3 1/3] vhost: introduce vhost_has_work()
This path introduces a helper which can give a hint for whether or not
there's a work queued in the work list.
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 7 +++
drivers/vhost/vhost.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index eec2f11..163b365 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -245,6 +245,13 @@ void vhost_work_queue(struct vhost_dev *dev, struct
vhost_work *work)
}
EXPORT_SYMBOL_GPL(vhost_work_queue);
+/* A lockless hint for busy polling code to exit the loop */
+bool vhost_has_work(struct vhost_dev *dev)
+{
+ return !list_empty(&dev->work_list);
+}
+EXPORT_SYMBOL_GPL(vhost_has_work);
+
void vhost_poll_queue(struct vhost_poll *poll)
{
vhost_work_queue(poll->dev, &poll->work);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 4772862..ea0327d 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -37,6 +37,7 @@ struct vhost_poll {
void vhost_work_init(struct vhost_work *work, vhost_work_fn_t fn);
void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work);
+bool vhost_has_work(struct vhost_dev *dev);
void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn,
unsigned long mask, struct vhost_dev *dev);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next RFC V3 0/3] basic busy polling support for vhost_net
Hi all: This series tries to add basic busy polling for vhost net. The idea is simple: at the end of tx/rx processing, busy polling for new tx added descriptor and rx receive socket for a while. The maximum number of time (in us) could be spent on busy polling was specified ioctl. Test were done through: - 50 us as busy loop timeout - Netperf 2.6 - Two machines with back to back connected ixgbe - Guest with 1 vcpu and 1 queue Results: - For stream workload, ioexits were reduced dramatically in medium size (1024-2048) of tx (at most -39%) and almost all rx (at most -79%) as a result of polling. This compensate for the possible wasted cpu cycles more or less. That porbably why we can still see some increasing in the normalized throughput in some cases. - Throughput of tx were increased (at most 105%) expect for the huge write (16384). And we can send more packets in the case (+tpkts were increased). - Very minor rx regression in some cases. - Improvemnt on TCP_RR (at most 16%). size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ 64/ 1/ +9%/ -17%/ +5%/ +10%/ -2% 64/ 2/ +8%/ -18%/ +6%/ +10%/ -1% 64/ 4/ +4%/ -21%/ +6%/ +10%/ -1% 64/ 8/ +9%/ -17%/ +6%/ +9%/ -2% 256/ 1/ +20%/ -1%/ +15%/ +11%/ -9% 256/ 2/ +15%/ -6%/ +15%/ +8%/ -8% 256/ 4/ +17%/ -4%/ +16%/ +8%/ -8% 256/ 8/ -61%/ -69%/ +16%/ +10%/ -10% 512/ 1/ +15%/ -3%/ +19%/ +18%/ -11% 512/ 2/ +19%/0%/ +19%/ +13%/ -10% 512/ 4/ +18%/ -2%/ +18%/ +15%/ -10% 512/ 8/ +17%/ -1%/ +18%/ +15%/ -11% 1024/ 1/ +25%/ +4%/ +27%/ +16%/ -21% 1024/ 2/ +28%/ +8%/ +25%/ +15%/ -22% 1024/ 4/ +25%/ +5%/ +25%/ +14%/ -21% 1024/ 8/ +27%/ +7%/ +25%/ +16%/ -21% 2048/ 1/ +32%/ +12%/ +31%/ +22%/ -38% 2048/ 2/ +33%/ +12%/ +30%/ +23%/ -36% 2048/ 4/ +31%/ +10%/ +31%/ +24%/ -37% 2048/ 8/ +105%/ +75%/ +33%/ +23%/ -39% 16384/ 1/0%/ -14%/ +2%/0%/ +19% 16384/ 2/0%/ -13%/ +19%/ -13%/ +17% 16384/ 4/0%/ -12%/ +3%/0%/ +2% 16384/ 8/0%/ -11%/ -2%/ +1%/ +1% size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ 64/ 1/ -7%/ -23%/ +4%/ +6%/ -74% 64/ 2/ -2%/ -12%/ +2%/ +2%/ -55% 64/ 4/ +2%/ -5%/ +10%/ -2%/ -43% 64/ 8/ -5%/ -5%/ +11%/ -34%/ -59% 256/ 1/ -6%/ -16%/ +9%/ +11%/ -60% 256/ 2/ +3%/ -4%/ +6%/ -3%/ -28% 256/ 4/0%/ -5%/ -9%/ -9%/ -10% 256/ 8/ -3%/ -6%/ -12%/ -9%/ -40% 512/ 1/ -4%/ -17%/ -10%/ +21%/ -34% 512/ 2/0%/ -9%/ -14%/ -3%/ -30% 512/ 4/0%/ -4%/ -18%/ -12%/ -4% 512/ 8/ -1%/ -4%/ -1%/ -5%/ +4% 1024/ 1/0%/ -16%/ +12%/ +11%/ -10% 1024/ 2/0%/ -11%/0%/ +5%/ -31% 1024/ 4/0%/ -4%/ -7%/ +1%/ -22% 1024/ 8/ -5%/ -6%/ -17%/ -29%/ -79% 2048/ 1/0%/ -16%/ +1%/ +9%/ -10% 2048/ 2/0%/ -12%/ +7%/ +9%/ -26% 2048/ 4/0%/ -7%/ -4%/ +3%/ -64% 2048/ 8/ -1%/ -5%/ -6%/ +4%/ -20% 16384/ 1/0%/ -12%/ +11%/ +7%/ -20% 16384/ 2/0%/ -7%/ +1%/ +5%/ -26% 16384/ 4/0%/ -5%/ +12%/ +22%/ -23% 16384/ 8/0%/ -1%/ -8%/ +5%/ -3% size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ 1/ 1/ +9%/ -29%/ +9%/ +9%/ +9% 1/25/ +6%/ -18%/ +6%/ +6%/ -1% 1/50/ +6%/ -19%/ +5%/ +5%/ -2% 1/ 100/ +5%/ -19%/ +4%/ +4%/ -3% 64/ 1/ +10%/ -28%/ +10%/ +10%/ +10% 64/25/ +8%/ -18%/ +7%/ +7%/ -2% 64/50/ +8%/ -17%/ +8%/ +8%/ -1% 64/ 100/ +8%/ -17%/ +8%/ +8%/ -1% 256/ 1/ +10%/ -28%/ +10%/ +10%/ +10% 256/25/ +15%/ -13%/ +15%/ +15%/0% 256/50/ +16%/ -14%/ +18%/ +18%/ +2% 256/ 100/ +15%/ -13%/ +12%/ +12%/ -2% Changes from V2: - poll also at the end of rx handling - factor out the polling logic and optimize the code a little bit - add two ioctls to get and set the busy poll timeout - test on ixgbe (which can give more stable and reproducable numbers) instead of mlx4. Changes from V1: - Add a comment for vhost_has_work() to explain why it could be lockless - Add param description for busyloop_timeout - Split out the busy polling logic into a new helper - Check and exit the loop when there's a pending signal - Disable preemption during busy looping to make sure lock_clock() was correctly used. Jason Wang (3): vhost: introduce vhost_has_work() vhost: introduce vhost_vq_more_avail() vhost_net: basic polling support drivers/vhost/net.c| 77 +++--- drivers/vhost/vhost.c | 48 +++-- drivers/vhost/vhost.h | 3 ++ include/uapi/linux/vhost.h
Re: [PATCH] FS-Cache: Add missing initialization of ret in cachefiles_write_page()
Geert Uytterhoeven wrote: > - int ret; > + int ret = 0; This isn't quite the right solution. The uninitialised error path needs to set -ENOBUFS. Unfortunately, my compiler doesn't show a warning:-/ David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
