* [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400
From: Stefano Stabellini @ 2016-11-08 19:42 UTC (permalink / raw)
To: xen-devel; +Cc: julien.grall, sstabellini, wei.liu2
In-Reply-To: <1478634163-27368-1-git-send-email-sstabellini@kernel.org>
Commit 21550029f709072aacf3b90edd574e7d3021b400 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.
However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the case for some versions of
XGene.
Fix the issue by partially reverting
21550029f709072aacf3b90edd574e7d3021b400:
- reintroduce PLATFORM_QUIRK_GIC_64K_STRIDE for XGene
- force csize and vsize to SZ_128K if csize is initially 4K and if
PLATFORM_QUIRK_GIC_64K_STRIDE
Also add a warning in case GICC is SZ_128K but not aliased.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v3:
- add a warning when enabling the quirk
- update comment to match the new behavior of the quirk
Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased
---
xen/arch/arm/gic-v2.c | 12 ++++++++++--
xen/arch/arm/platforms/xgene-storm.c | 6 ++++++
xen/include/asm-arm/platform.h | 7 +++++++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9bd9d0b..bca6d27 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -965,7 +965,12 @@ static void __init gicv2_dt_init(void)
printk(XENLOG_WARNING "GICv2: WARNING: "
"The GICC size is too small: %#"PRIx64" expected %#x\n",
csize, SZ_8K);
- csize = SZ_8K;
+ if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
+ {
+ printk(XENLOG_WARNING "GICv2: enable platform quirk: 64K stride\n");
+ vsize = csize = SZ_128K;
+ } else
+ csize = SZ_8K;
}
/*
@@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
printk(XENLOG_WARNING
"GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
cbase + aliased_offset);
- }
+ } else if ( csize == SZ_128K )
+ printk(XENLOG_WARNING
+ "GICv2: GICC size=%lu but not aliased\n",
+ csize);
gicv2.map_hbase = ioremap_nocache(hbase, PAGE_SIZE);
if ( !gicv2.map_hbase )
diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 686b19b..c795a95 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -67,6 +67,11 @@ static void __init xgene_check_pirq_eoi(void)
"Please upgrade your firmware to the latest version");
}
+static uint32_t xgene_storm_quirks(void)
+{
+ return PLATFORM_QUIRK_GIC_64K_STRIDE;
+}
+
static void xgene_storm_reset(void)
{
void __iomem *addr;
@@ -116,6 +121,7 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
.compatible = xgene_storm_dt_compat,
.init = xgene_storm_init,
.reset = xgene_storm_reset,
+ .quirks = xgene_storm_quirks,
PLATFORM_END
/*
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index c6e5010..08010ba 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -39,6 +39,13 @@ struct platform_desc {
const struct dt_device_match *blacklist_dev;
};
+/*
+ * Quirk for platforms where device tree incorrectly reports 4K GICC
+ * size, but actually the two GICC register ranges are placed at 64K
+ * stride.
+ */
+#define PLATFORM_QUIRK_GIC_64K_STRIDE (1 << 0)
+
void __init platform_init(void);
int __init platform_init_time(void);
int __init platform_specific_mapping(struct domain *d);
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v3 1/2] Revert "xen/arm: platform: Drop the quirks callback"
From: Stefano Stabellini @ 2016-11-08 19:42 UTC (permalink / raw)
To: xen-devel; +Cc: julien.grall, sstabellini, wei.liu2
In-Reply-To: <alpine.DEB.2.10.1611081139280.3491@sstabellini-ThinkPad-X260>
This reverts commit 14fa16961b03a23e9b883e5f0ed06b6837a489d8.
Do not reintroduce platform_dom0_evtchn_ppi.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/arm/platform.c | 10 ++++++++++
xen/include/asm-arm/platform.h | 7 +++++++
2 files changed, 17 insertions(+)
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index b0bfaa9..0af6d57 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,6 +127,16 @@ void platform_poweroff(void)
platform->poweroff();
}
+bool_t platform_has_quirk(uint32_t quirk)
+{
+ uint32_t quirks = 0;
+
+ if ( platform && platform->quirks )
+ quirks = platform->quirks();
+
+ return !!(quirks & quirk);
+}
+
bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
{
const struct dt_device_match *blacklist = NULL;
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index f97315d..c6e5010 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -27,6 +27,12 @@ struct platform_desc {
/* Platform power-off */
void (*poweroff)(void);
/*
+ * Platform quirks
+ * Defined has a function because a platform can support multiple
+ * board with different quirk on each
+ */
+ uint32_t (*quirks)(void);
+ /*
* Platform blacklist devices
* List of devices which must not pass-through to a guest
*/
@@ -42,6 +48,7 @@ int platform_cpu_up(int cpu);
#endif
void platform_reset(void);
void platform_poweroff(void);
+bool_t platform_has_quirk(uint32_t quirk);
bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
#define PLATFORM_START(_name, _namestr) \
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCH v1] ufs: introduce UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR quirk
From: Subhash Jadavani @ 2016-11-08 19:42 UTC (permalink / raw)
To: Kiwoong Kim
Cc: James E.J. Bottomley, linux-scsi, Martin K. Petersen,
vinholikatti, 추헌광, linux-scsi-owner
In-Reply-To: <002201d23994$d0aae750$7200b5f0$@samsung.com>
On 2016-11-07 23:50, Kiwoong Kim wrote:
> Some UFS host controllers may clear a transfer request slot
> by setting an associated bit in UTLRCLR/UTMLRCLR to 1, not 0.
s/UTLRCLR/UTRLCLR
s/UTMLRCLR/UTMRLCLR
> That's opposite to what UFS spec decribes.
>
> Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
> ---
> drivers/scsi/ufs/ufshcd.c | 32 ++++++++++++++++++++++++++++----
> drivers/scsi/ufs/ufshcd.h | 1 +
> 2 files changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 549e3e8..24d6ea7 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -392,7 +392,31 @@ static inline void ufshcd_put_tm_slot(struct
> ufs_hba *hba, int slot)
> */
> static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
> {
> - ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
> + u32 clear;
> +
> + if (hba->quirks & UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR)
> + clear = (1 << pos);
> + else
> + clear = ~(1 << pos);
> +
> + ufshcd_writel(hba, clear, REG_UTP_TRANSFER_REQ_LIST_CLEAR);
> +}
> +
> +/**
> + * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
> + * @hba: per adapter instance
> + * @pos: position of the bit to be cleared
> + */
> +static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
> +{
> + u32 clear;
> +
> + if (hba->quirks & UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR)
> + clear = (1 << pos);
> + else
> + clear = ~(1 << pos);
> +
> + ufshcd_writel(hba, clear, REG_UTP_TASK_REQ_LIST_CLEAR);
> }
>
> /**
> @@ -1147,7 +1171,7 @@ ufshcd_send_uic_cmd(struct ufs_hba *hba, struct
> uic_command *uic_cmd)
> *
> * Returns 0 in case of success, non-zero value in case of failure
> */
> -static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
> +static int ufshcd_map_sg(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
unrelated change. Please remove it.
> {
> struct ufshcd_sg_entry *prd_table;
> struct scatterlist *sg;
> @@ -1529,7 +1553,7 @@ static int ufshcd_queuecommand(struct Scsi_Host
> *host, struct scsi_cmnd *cmd)
>
> ufshcd_comp_scsi_upiu(hba, lrbp);
>
> - err = ufshcd_map_sg(lrbp);
> + err = ufshcd_map_sg(hba, lrbp);
unrelated change. Please remove it.
> if (err) {
> lrbp->cmd = NULL;
> clear_bit_unlock(tag, &hba->lrb_in_use);
> @@ -4329,7 +4353,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba
> *hba, int tag)
> goto out;
>
> spin_lock_irqsave(hba->host->host_lock, flags);
> - ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
> + ufshcd_utmrl_clear(hba, tag);
> spin_unlock_irqrestore(hba->host->host_lock, flags);
>
> /* poll for max. 1 sec to clear door bell register by h/w */
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 565f005..c4abd76 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -495,6 +495,7 @@ struct ufs_hba {
>
> #define UFSHCD_QUIRK_GET_VS_RESULT UFS_BIT(6)
> #define UFSHCD_QUIRK_BROKEN_DWORD_UTRD UFS_BIT(7)
> + #define UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR UFS_BIT(8)
>
>
> unsigned int quirks; /* Deviations from standard UFSHCI spec. */
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2] irqchip/renesas-irqc: Postpone driver initialization
From: Florian Fainelli @ 2016-11-08 19:42 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Simon Horman, Magnus Damm, linux-renesas-soc, linux-kernel,
netdev
In-Reply-To: <1478633747-26878-1-git-send-email-geert+renesas@glider.be>
On 11/08/2016 11:35 AM, Geert Uytterhoeven wrote:
> Currently the renesas-irqc driver uses postcore_initcall().
>
> However, the new CPG/MSSR driver uses subsys_initcall(). Hence the
> IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to
> not find its interrupt on R-Car Gen2 and RZ/G, as the of_mdio subsystem
> does not support deferred probe yet.
Is not that the more correct fix to implement though?
--
Florian
^ permalink raw reply
* [PATCH v3 0/2] Fix Xen boot on XGene
From: Stefano Stabellini @ 2016-11-08 19:42 UTC (permalink / raw)
To: xen-devel; +Cc: julien.grall, sstabellini, wei.liu2
Hi all,
the following commit:
commit 21550029f709072aacf3b90edd574e7d3021b400
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 8 19:23:53 2015 +0100
xen/arm: gic-v2: Automatically detect aliased GIC400
removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an heuristic to
check whether the two GICC pages have a 64K stride. However the
heuristic needs device tree to report a GICC region size of 128K to work
properly. That is not the case for some versions of XGene (including the
one I am using, kindly provided by CloudLab.us).
The patch series fixes the issue by reintroducing platform quirks,
PLATFORM_QUIRK_GIC_64K_STRIDE, and forcing GICC size to 128K if
PLATFORM_QUIRK_GIC_64K_STRIDE.
We should consider this series for 4.8.
Changes in v3:
- add a warning when enabling the quirk
- update comment to match the new behavior of the quirk
Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased
Stefano Stabellini (2):
Revert "xen/arm: platform: Drop the quirks callback"
Partially revert 21550029f709072aacf3b90edd574e7d3021b400
xen/arch/arm/gic-v2.c | 12 ++++++++++--
xen/arch/arm/platform.c | 10 ++++++++++
xen/arch/arm/platforms/xgene-storm.c | 6 ++++++
xen/include/asm-arm/platform.h | 14 ++++++++++++++
4 files changed, 40 insertions(+), 2 deletions(-)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/3] [RFC] Add HAX support
From: Vincent Palatin @ 2016-11-08 19:41 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <5a5399c5-a8bb-bfcb-8bc5-8aaad9749aa0@redhat.com>
On Tue, Nov 8, 2016 at 6:43 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
>
> On 08/11/2016 16:39, Vincent Palatin wrote:
> > I took a stab at trying to rebase/upstream the support for Intel HAXM.
> > (Hardware Accelerated Execution Manager).
> > Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.
> >
> > I have based my work on the last version of the source code I found:
> > the emu-2.2-release branch in the external/qemu-android repository as used by
> > the Android emulator.
> > In patch 2/3, I have forward-ported the core HAX code mostly unmodified from
> > there, I just did some minor touch up to make it build and run properly.
> > So it might contain some outdated constructs and probably requires more
> > attention (thus the 'RFC' for this patchset).
>
> Does HAXM support the "unrestricted guest" feature in Westmere and more
> recent processors?
Yes it does, as mentioned in the last paragraph of my message, I have
actually done a fair chunk of my testing in UG mode.
>
> If so, I think we should only support those
> processors and slash all the part related to HAX_EMULATE_STATE_INITIAL
> and HAX_EMULATE_STATE_REAL. This would probably let us make patch 3
> much less intrusive.
Sure the whole patchset would be lighter, not sure which proportion of
user have VT machines without UG support though.
>
> That said, patch 3's cpu-exec.c surgery is much nicer on the surface
> than if you look in depth, :) and since you don't look in depth if you
> steer clear of target-i386/hax*, I think it's okay to start with your
> patches and clean up progressively. Others may disagree... Also, we're
> now in soft freeze so the patches wouldn't be merged anyway for a few weeks.
>
> Paolo
^ permalink raw reply
* Re: [PATCH] stubdom: remove EXTRA_CFLAGS meant for building tools
From: Samuel Thibault @ 2016-11-08 19:41 UTC (permalink / raw)
To: Wei Liu; +Cc: Juergen Gross, xen-devel
In-Reply-To: <20161108104718.GC31926@citrix.com>
Wei Liu, on Tue 08 Nov 2016 10:47:18 +0000, wrote:
> On Tue, Nov 08, 2016 at 10:09:41AM +0100, Juergen Gross wrote:
> > When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
> > EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
> > flags not suitable for all stubdom builds (e.g. "-m64" often to be
> > found in $RPM_OPT_FLAGS will break building 32 bit stubdoms).
> >
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> > ---
> > stubdom/Makefile | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/stubdom/Makefile b/stubdom/Makefile
> > index 2921f30..c89e353 100644
> > --- a/stubdom/Makefile
> > +++ b/stubdom/Makefile
> > @@ -4,6 +4,10 @@ MINI_OS = $(XEN_ROOT)/extras/mini-os
> > export XEN_ROOT
> > export XEN_OS=MiniOS
> >
> > +# Remove flags which are meant for tools, e.g. "-m64"
> > +export EXTRA_CFLAGS_XEN_TOOLS=
> > +export EXTRA_CFLAGS_QEMU_TRADITIONAL=
> > +
>
> I can't think of a better way to deal with this. This is in line with
> how it is done in firmware build, so
>
> Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> > export stubdom=y
> > export debug=y
> > # Moved from config/StdGNU.mk
> > --
> > 2.6.6
> >
>
--
Samuel
* D a decide de peter un cable dans son rapport de pfp
<c> et il a bien raison ;-)
<c> tu vas dire quoi ?
<D> j'ai mis les paroles de "le coq est mort" en en-tete
-+- #ens-mim et la peufeupeu -+-
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [RFC] Split up policycoreutils
From: Stephen Smalley @ 2016-11-08 19:42 UTC (permalink / raw)
To: SELinux
In-Reply-To: <be8528f1-50ee-98da-91ea-0d0b0dfe0398@tycho.nsa.gov>
On 10/31/2016 02:05 PM, Stephen Smalley wrote:
> On 10/21/2016 01:47 PM, Stephen Smalley wrote:
>> Hi,
>>
>> policycoreutils started life as a small set of utilities that were
>> necessary or at least widely used in production on a SELinux system.
>> Over time though it has grown to include many optional components, and
>> even within a given subdirectory (e.g. sepolicy) there seem to be a
>> number of components that should be optional (e.g. the dbus service).
>> I'd like to propose that we move a number of components out of
>> policycoreutils into their own top-level subdirectory (possibly grouping
>> some of the related ones together).
>>
>> Some possible components to move and the rationale for doing so include:
>>
>> - gui: not required for operation. Unsure if this is even used outside
>> of Fedora, or how widely it is used within Fedora compared to the
>> command line tools. Packaged separately by Fedora as part of
>> policycoreutils-gui.
>>
>> - mcstrans: not required for operation outside of MLS environments (and
>> even there, only if using that label encoding functionality), not built
>> by default even upstream (omitted from policycoreutils/Makefile).
>> Packaged separately in Fedora as mcstrans.
>>
>> - restorecond: not required for operation, adds dbus and glib
>> dependencies, largely obsoleted by name-based type transition support in
>> the kernel. Packaged separately in Fedora as policycoreutils-restorecond.
>>
>> - sandbox: not required for basic operation of SELinux. Packaged
>> separately by Fedora as policycoreutils-sandbox.
>> restorecond
>> - semodule_deps/expand/link: developer tools only, not required for
>> operation, unlike semodule. Packaged separately by Fedora as part of
>> policycoreutils-devel.
>>
>> - sepolicy/{org.selinux*,selinux_client.py,selinux_server.py}: D-BUS
>> service for managing SELinux, not required for basic operation, not
>> desirable in high security environments. Packaged separately by Fedora
>> as part of policycoreutils-gui. Could perhaps be combined with the gui
>> above, although I think they are logically distinct.
>>
>> We could of course go further, but those seem to be the most obvious
>> candidates.
>>
>> Thoughts?
>
> For discussion purposes, I've pushed a splitpolicycoreutils branch that
> moves the above components and others identified in the discussion
> thread, and makes it easy to omit the non-core components from the
> build. Take a look and see what you think. Known issues:
>
> - I did not deal with splitting the policycoreutils/po files and moving
> them around. Not sure what the best way to handle that is.
>
> - python/sepolicy likely needs further rearrangement. I am unclear on
> the purpose/use of the desktop file and pixmaps; if those are only for
> the gui, then they can be moved to gui/, but I don't understand why they
> are called sepolicy* or located here. Also, should
> python/sepolicy/sepolicy/sedbus.py be moved over to dbus/ or stay here?
> Dan?
>
> - dbus/selinux_client.py (formerly
> policycoreutils/sepolicy/selinux_client.py) seems like leftover testing
> cruft. Remove?
>
> - restorecond presently reuses source code directly from setfiles, so
> building it as a separate package may be a nuisance. OTOH, I'm not
> entirely clear on whether restorecond needs to be kept around at all
> anymore?
>
> - policycoreutils/sepolgen-ifgen contains a single C program,
> sepolgen-ifgen-attr-helper, that is only used by
> python/audit2allow/sepolgen-ifgen. Any reason to not just coalesce it
> into python/audit2allow even though it is not python itself?
>
> - After the restructuring, the only script left in policycoreutils is
> fixfiles. Technically, that's not required for production either as one
> can always just run setfiles or restorecon directly, but distros seem to
> rely on it. Is it worth moving just to free policycoreutils of any bash
> dependencies, and if so, where?
>
> - I moved policycoreutils/semodule_{deps,expand,link} into a new
> semodule-utils directory. This might however be slightly confusing
> since semodule and semodule_package remain in policycoreutils since they
> are required and not merely for developers. Feel free to suggest
> another name or structure. Actually, I guess semodule_package might be
> optional now with CIL, so perhaps that one can be moved too.
I've made further changes on the splitpolicycoreutils branch based on
the discussion (as well as rebasing it on latest master). This is a
call for final comments or objections before merging it to master. With
the current branch, we will have the following source tar files in a
release:
Unchanged:
* libsepol
* libselinux
* libsemanage
* checkpolicy
* secilc
Modified or new:
* policycoreutils (containing only hll, load_policy, newrole, run_init,
scripts/fixfiles, secon, semodule, sestatus, setfiles, setsebool)
* mcstrans
* restorecond
* semodule-utils (containing semodule_package, semodule_link,
semodule_expand, semodule_deps)
* selinux-dbus (containing org.selinux DBus configuration and python files)
- selinux-gui (containing system-config-selinux aka selinux polgengui)
- selinux-python (containing audit2allow, including its
sepolgen-ifgen-attr-helper helper program, chcat, semanage, sepolgen,
sepolicy)
- selinux-sandbox (containing sandbox)
No longer separate:
* sepolgen (moved inside of selinux-python)
Note that the release script will add the selinux- prefix for dbus, gui,
python, and sandbox when generating the source tarballs so that they
have unique names suitable for source packages.
Feel free to suggest changes in structure, naming, or whatever.
^ permalink raw reply
* Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support
From: Kyle Huey @ 2016-11-08 19:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Robert O'Callahan, Andy Lutomirski, Ingo Molnar,
H. Peter Anvin, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Paolo Bonzini, Radim Krčmář, Jeff Dike,
Richard Weinberger, Alexander Viro, Shuah Khan, Dave Hansen,
Borislav Petkov, Peter Zijlstra, Boris Ostrovsky, Len Brown,
Rafael J. Wysocki, Dmitry Safonov
In-Reply-To: <alpine.DEB.2.20.1611082002160.3501@nanos>
On Tue, Nov 8, 2016 at 11:06 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 8 Nov 2016, Kyle Huey wrote:
>
>> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
>> When enabled, the processor will fault on attempts to execute the CPUID
>> instruction with CPL>0. This will allow a ptracer to emulate the CPUID
>> instruction.
>>
>> Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
>> documented in detail in Section 2.3.2 of
>> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
Done. https://bugzilla.kernel.org/attachment.cgi?id=243991
> Can you please stick that document into the kernel bugzilla, as it's going
> to be on a different place before this gets merged into Linus tree?
>
> See: http://lkml.kernel.org/r/1478631281-5061-1-git-send-email-kan.liang@intel.com
>
>> + static const struct msr_bit msr_bits[] = {
>> + { X86_FEATURE_CPUID_FAULT, MSR_PLATFORM_INFO, 31 },
>
> Can you please make that PLATINFO_CPUID_FAULT_BIT instead of 31?
Sure.
- Kyle
^ permalink raw reply
* Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support
From: Kyle Huey @ 2016-11-08 19:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Robert O'Callahan, Andy Lutomirski, Ingo Molnar,
H. Peter Anvin, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Paolo Bonzini, Radim Krčmář, Jeff Dike,
Richard Weinberger, Alexander Viro, Shuah Khan, Dave Hansen,
Borislav Petkov, Peter Zijlstra, Boris Ostrovsky, Len Brown,
Rafael J. Wysocki, Dmitry Safonov, David Matlack, open list,
open list:USER-MODE LINUX (UML), open list:USER-MODE LINUX (UML),
open list:FILESYSTEMS (VFS and infrastructure),
open list:KERNEL SELFTEST FRAMEWORK, kvm list
In-Reply-To: <alpine.DEB.2.20.1611082002160.3501@nanos>
On Tue, Nov 8, 2016 at 11:06 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 8 Nov 2016, Kyle Huey wrote:
>
>> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
>> When enabled, the processor will fault on attempts to execute the CPUID
>> instruction with CPL>0. This will allow a ptracer to emulate the CPUID
>> instruction.
>>
>> Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
>> documented in detail in Section 2.3.2 of
>> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
Done. https://bugzilla.kernel.org/attachment.cgi?id=243991
> Can you please stick that document into the kernel bugzilla, as it's going
> to be on a different place before this gets merged into Linus tree?
>
> See: http://lkml.kernel.org/r/1478631281-5061-1-git-send-email-kan.liang@intel.com
>
>> + static const struct msr_bit msr_bits[] = {
>> + { X86_FEATURE_CPUID_FAULT, MSR_PLATFORM_INFO, 31 },
>
> Can you please make that PLATINFO_CPUID_FAULT_BIT instead of 31?
Sure.
- Kyle
^ permalink raw reply
* [PATCH 2/2] kasan: improve error reports
From: Andrey Konovalov @ 2016-11-08 19:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, kasan-dev,
linux-mm, linux-kernel, mingo
Cc: kcc, Andrey Konovalov
In-Reply-To: <cover.1478632698.git.andreyknvl@google.com>
1. Change header format.
2. Unify header format between different kinds of bad accesses.
3. Add empty lines between parts of the report to improve readability.
4. Improve slab object description.
5. Improve mm/kasan/report.c readability.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/kasan/report.c | 246 ++++++++++++++++++++++++++++++++++++------------------
1 file changed, 165 insertions(+), 81 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 24c1211..a2ebea0 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -48,7 +48,7 @@ static const void *find_first_bad_addr(const void *addr, size_t size)
return first_bad_addr;
}
-static void print_error_description(struct kasan_access_info *info)
+static const char *get_shadow_bug_type(struct kasan_access_info *info)
{
const char *bug_type = "unknown-crash";
u8 *shadow_addr;
@@ -92,53 +92,82 @@ static void print_error_description(struct kasan_access_info *info)
break;
}
- pr_err("BUG: KASAN: %s in %pS at addr %p\n",
- bug_type, (void *)info->ip,
- info->access_addr);
- pr_err("%s of size %zu by task %s/%d\n",
- info->is_write ? "Write" : "Read",
- info->access_size, current->comm, task_pid_nr(current));
+ return bug_type;
}
-static inline bool kernel_or_module_addr(const void *addr)
+static const char *get_wild_bug_type(struct kasan_access_info *info)
{
- if (addr >= (void *)_stext && addr < (void *)_end)
- return true;
- if (is_module_address((unsigned long)addr))
- return true;
- return false;
+ const char *bug_type;
+
+ if ((unsigned long)info->access_addr < PAGE_SIZE)
+ bug_type = "null-ptr-deref";
+ else if ((unsigned long)info->access_addr < TASK_SIZE)
+ bug_type = "user-memory-access";
+ else
+ bug_type = "wild-memory-access";
+
+ return bug_type;
}
-static inline bool init_task_stack_addr(const void *addr)
+static bool addr_has_shadow(struct kasan_access_info *info)
{
- return addr >= (void *)&init_thread_union.stack &&
- (addr <= (void *)&init_thread_union.stack +
- sizeof(init_thread_union.stack));
+ return (info->access_addr >=
+ kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
}
-static DEFINE_SPINLOCK(report_lock);
+static const char *get_bug_type(struct kasan_access_info *info)
+{
+ if (addr_has_shadow(info))
+ return get_shadow_bug_type(info);
+ return get_wild_bug_type(info);
+}
-static void kasan_start_report(unsigned long *flags)
+static void print_report_header(struct kasan_access_info *info)
{
- /*
- * Make sure we don't end up in loop.
- */
- kasan_disable_current();
- spin_lock_irqsave(&report_lock, *flags);
- pr_err("==================================================================\n");
+ const char *bug_type = get_bug_type(info);
+
+ pr_err("BUG: KASAN: %s in %pS\n",
+ bug_type, (void *)info->ip);
+ pr_err("%s of size %zu at addr %p by task %s/%d\n",
+ info->is_write ? "Write" : "Read", info->access_size,
+ info->access_addr, current->comm, task_pid_nr(current));
}
-static void kasan_end_report(unsigned long *flags)
+static void describe_object_addr(struct kmem_cache *cache, void *object,
+ const void *addr)
{
- pr_err("==================================================================\n");
- add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
- spin_unlock_irqrestore(&report_lock, *flags);
- kasan_enable_current();
+ unsigned long access_addr = (unsigned long)addr;
+ unsigned long object_addr = (unsigned long)object;
+ const char *rel_type;
+ int rel_bytes;
+
+ pr_err("The buggy address belongs to the object at %p\n"
+ " which belongs to the cache %s of size %d\n",
+ object, cache->name, cache->object_size);
+
+ if (!addr)
+ return;
+
+ if (access_addr < object_addr) {
+ rel_type = "to the left";
+ rel_bytes = object_addr - access_addr;
+ } else if (access_addr >= object_addr + cache->object_size) {
+ rel_type = "to the right";
+ rel_bytes = access_addr - (object_addr + cache->object_size);
+ } else {
+ rel_type = "inside";
+ rel_bytes = access_addr - object_addr;
+ }
+
+ pr_err("The buggy address %p is located %d bytes %s\n"
+ " of %d-byte region [%p, %p)\n", addr,
+ rel_bytes, rel_type, cache->object_size, (void *)object_addr,
+ (void *)(object_addr + cache->object_size));
}
-static void print_track(struct kasan_track *track)
+static void print_track(struct kasan_track *track, const char *prefix)
{
- pr_err("PID = %u\n", track->pid);
+ pr_err("%s by task %u:\n", prefix, track->pid);
if (track->stack) {
struct stack_trace trace;
@@ -149,39 +178,28 @@ static void print_track(struct kasan_track *track)
}
}
-static void kasan_object_err(struct kmem_cache *cache, void *object)
+static void describe_object(struct kmem_cache *cache, void *object,
+ const void *addr)
{
struct kasan_alloc_meta *alloc_info = get_alloc_info(cache, object);
- dump_stack();
- pr_err("Object at %p, in cache %s size: %d\n", object, cache->name,
- cache->object_size);
+ describe_object_addr(cache, object, addr);
+ pr_err("\n");
if (!(cache->flags & SLAB_KASAN))
return;
- pr_err("Allocated:\n");
- print_track(&alloc_info->alloc_track);
- pr_err("Freed:\n");
- print_track(&alloc_info->free_track);
-}
-
-void kasan_report_double_free(struct kmem_cache *cache, void *object,
- s8 shadow)
-{
- unsigned long flags;
+ if (alloc_info->free_track.stack) {
+ print_track(&alloc_info->free_track, "Freed");
+ pr_err("\n");
+ }
- kasan_start_report(&flags);
- pr_err("BUG: Double free or freeing an invalid pointer\n");
- pr_err("Unexpected shadow byte: 0x%hhX\n", shadow);
- kasan_object_err(cache, object);
- kasan_end_report(&flags);
+ print_track(&alloc_info->alloc_track, "Allocated");
+ pr_err("\n");
}
-static void print_address_description(struct kasan_access_info *info)
+static bool try_describe_object(const void *addr)
{
- const void *addr = info->access_addr;
-
if ((addr >= (void *)PAGE_OFFSET) &&
(addr < high_memory)) {
struct page *page = virt_to_head_page(addr);
@@ -189,19 +207,62 @@ static void print_address_description(struct kasan_access_info *info)
if (PageSlab(page)) {
void *object;
struct kmem_cache *cache = page->slab_cache;
- object = nearest_obj(cache, page,
- (void *)info->access_addr);
- kasan_object_err(cache, object);
- return;
+ object = nearest_obj(cache, page, (void *)addr);
+ describe_object(cache, object, addr);
+ return true;
}
+ }
+
+ return false;
+}
+
+static void try_describe_page(const void *addr)
+{
+ if ((addr >= (void *)PAGE_OFFSET) &&
+ (addr < high_memory)) {
+ struct page *page = virt_to_head_page(addr);
dump_page(page, "kasan: bad access detected");
+ pr_err("\n");
}
+}
+
+static inline bool kernel_or_module_addr(const void *addr)
+{
+ if (addr >= (void *)_stext && addr < (void *)_end)
+ return true;
+ if (is_module_address((unsigned long)addr))
+ return true;
+ return false;
+}
+
+static inline bool init_task_stack_addr(const void *addr)
+{
+ return addr >= (void *)&init_thread_union.stack &&
+ (addr <= (void *)&init_thread_union.stack +
+ sizeof(init_thread_union.stack));
+}
+static void try_describe_variable(const void *addr)
+{
if (kernel_or_module_addr(addr)) {
if (!init_task_stack_addr(addr))
- pr_err("Address belongs to variable %pS\n", addr);
+ pr_err("The buggy address %p belongs to\n"
+ " the variable %pS\n", addr, addr);
+ pr_err("\n");
}
+}
+
+static void describe_address(const void *addr)
+{
+ try_describe_page(addr);
+
dump_stack();
+ pr_err("\n");
+
+ if (try_describe_object(addr))
+ return;
+
+ try_describe_variable(addr);
}
static bool row_is_guilty(const void *row, const void *guilty)
@@ -256,35 +317,58 @@ static void print_shadow_for_address(const void *addr)
}
}
+static DEFINE_SPINLOCK(report_lock);
+
+static void start_report(unsigned long *flags)
+{
+ /*
+ * Make sure we don't end up in loop.
+ */
+ kasan_disable_current();
+ spin_lock_irqsave(&report_lock, *flags);
+ pr_err("==================================================================\n");
+}
+
+static void end_report(unsigned long *flags)
+{
+ pr_err("==================================================================\n");
+ add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
+ spin_unlock_irqrestore(&report_lock, *flags);
+ kasan_enable_current();
+}
+
+void kasan_report_double_free(struct kmem_cache *cache, void *object,
+ s8 shadow)
+{
+ unsigned long flags;
+
+ start_report(&flags);
+ pr_err("BUG: double-free or invalid-free\n");
+ pr_err("Unexpected shadow byte: 0x%hhX\n", shadow);
+ pr_err("\n");
+ dump_stack();
+ pr_err("\n");
+ describe_object(cache, object, NULL);
+ end_report(&flags);
+}
+
static void kasan_report_error(struct kasan_access_info *info)
{
unsigned long flags;
- const char *bug_type;
- kasan_start_report(&flags);
-
- if (info->access_addr <
- kasan_shadow_to_mem((void *)KASAN_SHADOW_START)) {
- if ((unsigned long)info->access_addr < PAGE_SIZE)
- bug_type = "null-ptr-deref";
- else if ((unsigned long)info->access_addr < TASK_SIZE)
- bug_type = "user-memory-access";
- else
- bug_type = "wild-memory-access";
- pr_err("BUG: KASAN: %s on address %p\n",
- bug_type, info->access_addr);
- pr_err("%s of size %zu by task %s/%d\n",
- info->is_write ? "Write" : "Read",
- info->access_size, current->comm,
- task_pid_nr(current));
- dump_stack();
- } else {
- print_error_description(info);
- print_address_description(info);
+ start_report(&flags);
+
+ print_report_header(info);
+ pr_err("\n");
+
+ if (addr_has_shadow(info)) {
+ describe_address(info->access_addr);
print_shadow_for_address(info->first_bad_addr);
+ } else {
+ dump_stack();
}
- kasan_end_report(&flags);
+ end_report(&flags);
}
void kasan_report(unsigned long addr, size_t size,
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice
From: Andrey Konovalov @ 2016-11-08 19:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, kasan-dev,
linux-mm, linux-kernel, mingo
Cc: kcc, Andrey Konovalov
In-Reply-To: <cover.1478632698.git.andreyknvl@google.com>
Right now print_stack_trace prints timestamp twice, the first time
it's done by printk when printing spaces, the second - by print_ip_sym.
As a result, stack traces in KASAN reports have double timestamps:
[ 18.822232] Allocated by task 3838:
[ 18.822232] [ 18.822232] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 18.822232] [ 18.822232] [<ffffffff81509bd6>] save_stack+0x46/0xd0
[ 18.822232] [ 18.822232] [<ffffffff81509e4b>] kasan_kmalloc+0xab/0xe0
....
Fix by calling printk only once.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
kernel/stacktrace.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index b6e4c16..56f510f 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -14,13 +14,15 @@
void print_stack_trace(struct stack_trace *trace, int spaces)
{
int i;
+ unsigned long ip;
if (WARN_ON(!trace->entries))
return;
for (i = 0; i < trace->nr_entries; i++) {
- printk("%*c", 1 + spaces, ' ');
- print_ip_sym(trace->entries[i]);
+ ip = trace->entries[i];
+ printk("%*c[<%p>] %pS\n", 1 + spaces, ' ',
+ (void *) ip, (void *) ip);
}
}
EXPORT_SYMBOL_GPL(print_stack_trace);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/2] kasan: improve error reports
From: Andrey Konovalov @ 2016-11-08 19:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, kasan-dev,
linux-mm, linux-kernel, mingo
Cc: kcc, Andrey Konovalov
In-Reply-To: <cover.1478632698.git.andreyknvl@google.com>
1. Change header format.
2. Unify header format between different kinds of bad accesses.
3. Add empty lines between parts of the report to improve readability.
4. Improve slab object description.
5. Improve mm/kasan/report.c readability.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/kasan/report.c | 246 ++++++++++++++++++++++++++++++++++++------------------
1 file changed, 165 insertions(+), 81 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 24c1211..a2ebea0 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -48,7 +48,7 @@ static const void *find_first_bad_addr(const void *addr, size_t size)
return first_bad_addr;
}
-static void print_error_description(struct kasan_access_info *info)
+static const char *get_shadow_bug_type(struct kasan_access_info *info)
{
const char *bug_type = "unknown-crash";
u8 *shadow_addr;
@@ -92,53 +92,82 @@ static void print_error_description(struct kasan_access_info *info)
break;
}
- pr_err("BUG: KASAN: %s in %pS at addr %p\n",
- bug_type, (void *)info->ip,
- info->access_addr);
- pr_err("%s of size %zu by task %s/%d\n",
- info->is_write ? "Write" : "Read",
- info->access_size, current->comm, task_pid_nr(current));
+ return bug_type;
}
-static inline bool kernel_or_module_addr(const void *addr)
+static const char *get_wild_bug_type(struct kasan_access_info *info)
{
- if (addr >= (void *)_stext && addr < (void *)_end)
- return true;
- if (is_module_address((unsigned long)addr))
- return true;
- return false;
+ const char *bug_type;
+
+ if ((unsigned long)info->access_addr < PAGE_SIZE)
+ bug_type = "null-ptr-deref";
+ else if ((unsigned long)info->access_addr < TASK_SIZE)
+ bug_type = "user-memory-access";
+ else
+ bug_type = "wild-memory-access";
+
+ return bug_type;
}
-static inline bool init_task_stack_addr(const void *addr)
+static bool addr_has_shadow(struct kasan_access_info *info)
{
- return addr >= (void *)&init_thread_union.stack &&
- (addr <= (void *)&init_thread_union.stack +
- sizeof(init_thread_union.stack));
+ return (info->access_addr >=
+ kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
}
-static DEFINE_SPINLOCK(report_lock);
+static const char *get_bug_type(struct kasan_access_info *info)
+{
+ if (addr_has_shadow(info))
+ return get_shadow_bug_type(info);
+ return get_wild_bug_type(info);
+}
-static void kasan_start_report(unsigned long *flags)
+static void print_report_header(struct kasan_access_info *info)
{
- /*
- * Make sure we don't end up in loop.
- */
- kasan_disable_current();
- spin_lock_irqsave(&report_lock, *flags);
- pr_err("==================================================================\n");
+ const char *bug_type = get_bug_type(info);
+
+ pr_err("BUG: KASAN: %s in %pS\n",
+ bug_type, (void *)info->ip);
+ pr_err("%s of size %zu at addr %p by task %s/%d\n",
+ info->is_write ? "Write" : "Read", info->access_size,
+ info->access_addr, current->comm, task_pid_nr(current));
}
-static void kasan_end_report(unsigned long *flags)
+static void describe_object_addr(struct kmem_cache *cache, void *object,
+ const void *addr)
{
- pr_err("==================================================================\n");
- add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
- spin_unlock_irqrestore(&report_lock, *flags);
- kasan_enable_current();
+ unsigned long access_addr = (unsigned long)addr;
+ unsigned long object_addr = (unsigned long)object;
+ const char *rel_type;
+ int rel_bytes;
+
+ pr_err("The buggy address belongs to the object at %p\n"
+ " which belongs to the cache %s of size %d\n",
+ object, cache->name, cache->object_size);
+
+ if (!addr)
+ return;
+
+ if (access_addr < object_addr) {
+ rel_type = "to the left";
+ rel_bytes = object_addr - access_addr;
+ } else if (access_addr >= object_addr + cache->object_size) {
+ rel_type = "to the right";
+ rel_bytes = access_addr - (object_addr + cache->object_size);
+ } else {
+ rel_type = "inside";
+ rel_bytes = access_addr - object_addr;
+ }
+
+ pr_err("The buggy address %p is located %d bytes %s\n"
+ " of %d-byte region [%p, %p)\n", addr,
+ rel_bytes, rel_type, cache->object_size, (void *)object_addr,
+ (void *)(object_addr + cache->object_size));
}
-static void print_track(struct kasan_track *track)
+static void print_track(struct kasan_track *track, const char *prefix)
{
- pr_err("PID = %u\n", track->pid);
+ pr_err("%s by task %u:\n", prefix, track->pid);
if (track->stack) {
struct stack_trace trace;
@@ -149,39 +178,28 @@ static void print_track(struct kasan_track *track)
}
}
-static void kasan_object_err(struct kmem_cache *cache, void *object)
+static void describe_object(struct kmem_cache *cache, void *object,
+ const void *addr)
{
struct kasan_alloc_meta *alloc_info = get_alloc_info(cache, object);
- dump_stack();
- pr_err("Object at %p, in cache %s size: %d\n", object, cache->name,
- cache->object_size);
+ describe_object_addr(cache, object, addr);
+ pr_err("\n");
if (!(cache->flags & SLAB_KASAN))
return;
- pr_err("Allocated:\n");
- print_track(&alloc_info->alloc_track);
- pr_err("Freed:\n");
- print_track(&alloc_info->free_track);
-}
-
-void kasan_report_double_free(struct kmem_cache *cache, void *object,
- s8 shadow)
-{
- unsigned long flags;
+ if (alloc_info->free_track.stack) {
+ print_track(&alloc_info->free_track, "Freed");
+ pr_err("\n");
+ }
- kasan_start_report(&flags);
- pr_err("BUG: Double free or freeing an invalid pointer\n");
- pr_err("Unexpected shadow byte: 0x%hhX\n", shadow);
- kasan_object_err(cache, object);
- kasan_end_report(&flags);
+ print_track(&alloc_info->alloc_track, "Allocated");
+ pr_err("\n");
}
-static void print_address_description(struct kasan_access_info *info)
+static bool try_describe_object(const void *addr)
{
- const void *addr = info->access_addr;
-
if ((addr >= (void *)PAGE_OFFSET) &&
(addr < high_memory)) {
struct page *page = virt_to_head_page(addr);
@@ -189,19 +207,62 @@ static void print_address_description(struct kasan_access_info *info)
if (PageSlab(page)) {
void *object;
struct kmem_cache *cache = page->slab_cache;
- object = nearest_obj(cache, page,
- (void *)info->access_addr);
- kasan_object_err(cache, object);
- return;
+ object = nearest_obj(cache, page, (void *)addr);
+ describe_object(cache, object, addr);
+ return true;
}
+ }
+
+ return false;
+}
+
+static void try_describe_page(const void *addr)
+{
+ if ((addr >= (void *)PAGE_OFFSET) &&
+ (addr < high_memory)) {
+ struct page *page = virt_to_head_page(addr);
dump_page(page, "kasan: bad access detected");
+ pr_err("\n");
}
+}
+
+static inline bool kernel_or_module_addr(const void *addr)
+{
+ if (addr >= (void *)_stext && addr < (void *)_end)
+ return true;
+ if (is_module_address((unsigned long)addr))
+ return true;
+ return false;
+}
+
+static inline bool init_task_stack_addr(const void *addr)
+{
+ return addr >= (void *)&init_thread_union.stack &&
+ (addr <= (void *)&init_thread_union.stack +
+ sizeof(init_thread_union.stack));
+}
+static void try_describe_variable(const void *addr)
+{
if (kernel_or_module_addr(addr)) {
if (!init_task_stack_addr(addr))
- pr_err("Address belongs to variable %pS\n", addr);
+ pr_err("The buggy address %p belongs to\n"
+ " the variable %pS\n", addr, addr);
+ pr_err("\n");
}
+}
+
+static void describe_address(const void *addr)
+{
+ try_describe_page(addr);
+
dump_stack();
+ pr_err("\n");
+
+ if (try_describe_object(addr))
+ return;
+
+ try_describe_variable(addr);
}
static bool row_is_guilty(const void *row, const void *guilty)
@@ -256,35 +317,58 @@ static void print_shadow_for_address(const void *addr)
}
}
+static DEFINE_SPINLOCK(report_lock);
+
+static void start_report(unsigned long *flags)
+{
+ /*
+ * Make sure we don't end up in loop.
+ */
+ kasan_disable_current();
+ spin_lock_irqsave(&report_lock, *flags);
+ pr_err("==================================================================\n");
+}
+
+static void end_report(unsigned long *flags)
+{
+ pr_err("==================================================================\n");
+ add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
+ spin_unlock_irqrestore(&report_lock, *flags);
+ kasan_enable_current();
+}
+
+void kasan_report_double_free(struct kmem_cache *cache, void *object,
+ s8 shadow)
+{
+ unsigned long flags;
+
+ start_report(&flags);
+ pr_err("BUG: double-free or invalid-free\n");
+ pr_err("Unexpected shadow byte: 0x%hhX\n", shadow);
+ pr_err("\n");
+ dump_stack();
+ pr_err("\n");
+ describe_object(cache, object, NULL);
+ end_report(&flags);
+}
+
static void kasan_report_error(struct kasan_access_info *info)
{
unsigned long flags;
- const char *bug_type;
- kasan_start_report(&flags);
-
- if (info->access_addr <
- kasan_shadow_to_mem((void *)KASAN_SHADOW_START)) {
- if ((unsigned long)info->access_addr < PAGE_SIZE)
- bug_type = "null-ptr-deref";
- else if ((unsigned long)info->access_addr < TASK_SIZE)
- bug_type = "user-memory-access";
- else
- bug_type = "wild-memory-access";
- pr_err("BUG: KASAN: %s on address %p\n",
- bug_type, info->access_addr);
- pr_err("%s of size %zu by task %s/%d\n",
- info->is_write ? "Write" : "Read",
- info->access_size, current->comm,
- task_pid_nr(current));
- dump_stack();
- } else {
- print_error_description(info);
- print_address_description(info);
+ start_report(&flags);
+
+ print_report_header(info);
+ pr_err("\n");
+
+ if (addr_has_shadow(info)) {
+ describe_address(info->access_addr);
print_shadow_for_address(info->first_bad_addr);
+ } else {
+ dump_stack();
}
- kasan_end_report(&flags);
+ end_report(&flags);
}
void kasan_report(unsigned long addr, size_t size,
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice
From: Andrey Konovalov @ 2016-11-08 19:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, kasan-dev,
linux-mm, linux-kernel, mingo
Cc: kcc, Andrey Konovalov
In-Reply-To: <cover.1478632698.git.andreyknvl@google.com>
Right now print_stack_trace prints timestamp twice, the first time
it's done by printk when printing spaces, the second - by print_ip_sym.
As a result, stack traces in KASAN reports have double timestamps:
[ 18.822232] Allocated by task 3838:
[ 18.822232] [ 18.822232] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 18.822232] [ 18.822232] [<ffffffff81509bd6>] save_stack+0x46/0xd0
[ 18.822232] [ 18.822232] [<ffffffff81509e4b>] kasan_kmalloc+0xab/0xe0
....
Fix by calling printk only once.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
kernel/stacktrace.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index b6e4c16..56f510f 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -14,13 +14,15 @@
void print_stack_trace(struct stack_trace *trace, int spaces)
{
int i;
+ unsigned long ip;
if (WARN_ON(!trace->entries))
return;
for (i = 0; i < trace->nr_entries; i++) {
- printk("%*c", 1 + spaces, ' ');
- print_ip_sym(trace->entries[i]);
+ ip = trace->entries[i];
+ printk("%*c[<%p>] %pS\n", 1 + spaces, ' ',
+ (void *) ip, (void *) ip);
}
}
EXPORT_SYMBOL_GPL(print_stack_trace);
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 0/2] kasan,stacktrace: improve error reports
From: Andrey Konovalov @ 2016-11-08 19:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, kasan-dev,
linux-mm, linux-kernel, mingo
Cc: kcc, Andrey Konovalov
This patchset improves KASAN reports by making the following changes:
1. Changes header format from:
[ 24.247214] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan] at addr ffff88006bbb38a8
[ 24.247301] Write of size 1 by task insmod/3852
to
[ 19.338308] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] Write of size 1 at addr ffff88006af77968 by task insmod/3840
2. Unifies header format between different kinds of bad accesses.
3. Adds empty lines between parts of the report to improve readability.
4. Improves slab object description, before:
[ 24.247301] Object at ffff88006bbb38a0, in cache kmalloc-16 size: 16
now:
[ 19.338387] The buggy address belongs to the object at ffff88006af77960
[ 19.338387] which belongs to the cache kmalloc-16 of size 16
[ 19.338387] The buggy address ffff88006af77968 is located 8 bytes inside
[ 19.338387] of 16-byte region [ffff88006af77960, ffff88006af77970)
5. Fixes printing timeframes twice in alloc and free stack traces.
6. Improves mm/kasan/report.c readability.
This is what a test use-after-free report looks like now:
[ 19.337402] ==================================================================
[ 19.338308] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] Write of size 1 at addr ffff88006af77968 by task insmod/3840
[ 19.338387]
[ 19.338387] page:ffffea0001abddc0 count:1 mapcount:0 mapping: (null) index:0x0
[ 19.338387] flags: 0x100000000000080(slab)
[ 19.338387] page dumped because: kasan: bad access detected
[ 19.338387]
[ 19.338387] CPU: 0 PID: 3840 Comm: insmod Tainted: G B 4.9.0-rc4+ #394
[ 19.338387] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 19.338387] ffff880063d6f9a8 ffffffff81b46b74 ffff880063d6fa38 ffff88006af77968
[ 19.338387] 00000000000000fa 00000000000000fb ffff880063d6fa28 ffffffff8150aa92
[ 19.338387] ffffffff8120812d ffff880063d6fa00 0000000000000282 0000000000000296
[ 19.338387] Call Trace:
[ 19.338387] [<ffffffff81b46b74>] dump_stack+0xb3/0x10f
[ 19.338387] [<ffffffff8150aa92>] kasan_report_error+0x122/0x560
[ 19.338387] [<ffffffff8120812d>] ? trace_hardirqs_on+0xd/0x10
[ 19.338387] [<ffffffffa001928c>] ? copy_user_test+0x24f/0x24f [test_kasan]
[ 19.338387] [<ffffffff8150b04e>] __asan_report_store1_noabort+0x3e/0x40
[ 19.338387] [<ffffffffa0018609>] ? kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa0018609>] kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 19.338387] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 19.338387] [<ffffffff810004c0>] ? initcall_blacklisted+0x170/0x170
[ 19.338387] [<ffffffff81509e1b>] ? kasan_kmalloc+0xab/0xe0
[ 19.338387] [<ffffffff81509cb5>] ? kasan_unpoison_shadow+0x35/0x50
[ 19.338387] [<ffffffff81509d4c>] ? __asan_register_globals+0x7c/0xa0
[ 19.338387] [<ffffffff8140d696>] do_init_module+0x1c1/0x516
[ 19.338387] [<ffffffff812bbe1d>] load_module+0x65ed/0x8f90
[ 19.338387] [<ffffffff812b2f70>] ? __symbol_put+0xb0/0xb0
[ 19.338387] [<ffffffffa001002d>] ? __UNIQUE_ID_vermagic8+0x36ff9f20d843/0x36ff9f20d846 [test_kasan]
[ 19.338387] [<ffffffff812b5830>] ? module_frob_arch_sections+0x20/0x20
[ 19.338387] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 19.338387] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 19.338387] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 19.338387] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 19.338387] [<ffffffff812be97c>] SYSC_init_module+0x1bc/0x1d0
[ 19.338387] [<ffffffff812be7c0>] ? load_module+0x8f90/0x8f90
[ 19.338387] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 19.338387] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 19.338387] [<ffffffff812beaf9>] SyS_init_module+0x9/0x10
[ 19.338387] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 19.338387]
[ 19.338387] The buggy address belongs to the object at ffff88006af77960
[ 19.338387] which belongs to the cache kmalloc-16 of size 16
[ 19.338387] The buggy address ffff88006af77968 is located 8 bytes inside
[ 19.338387] of 16-byte region [ffff88006af77960, ffff88006af77970)
[ 19.338387]
[ 19.338387] Freed by task 3840:
[ 19.338387] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 19.338387] [<ffffffff81509ba6>] save_stack+0x46/0xd0
[ 19.338387] [<ffffffff8150a403>] kasan_slab_free+0x73/0xc0
[ 19.338387] [<ffffffff815068e8>] kfree+0xe8/0x2b0
[ 19.338387] [<ffffffffa00185e1>] kmalloc_uaf+0x85/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 19.338387] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 19.338387] [<ffffffff8140d696>] do_init_module+0x1c1/0x516
[ 19.338387] [<ffffffff812bbe1d>] load_module+0x65ed/0x8f90
[ 19.338387] [<ffffffff812be97c>] SYSC_init_module+0x1bc/0x1d0
[ 19.338387] [<ffffffff812beaf9>] SyS_init_module+0x9/0x10
[ 19.338387] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 19.338387]
[ 19.338387] Allocated by task 3840:
[ 19.338387] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 19.338387] [<ffffffff81509ba6>] save_stack+0x46/0xd0
[ 19.338387] [<ffffffff81509e1b>] kasan_kmalloc+0xab/0xe0
[ 19.338387] [<ffffffff8150554c>] kmem_cache_alloc_trace+0xec/0x270
[ 19.338387] [<ffffffffa00185b2>] kmalloc_uaf+0x56/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 19.338387] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 19.338387] [<ffffffff8140d696>] do_init_module+0x1c1/0x516
[ 19.338387] [<ffffffff812bbe1d>] load_module+0x65ed/0x8f90
[ 19.338387] [<ffffffff812be97c>] SYSC_init_module+0x1bc/0x1d0
[ 19.338387] [<ffffffff812beaf9>] SyS_init_module+0x9/0x10
[ 19.338387] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 19.338387]
[ 19.338387] Memory state around the buggy address:
[ 19.338387] ffff88006af77800: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] ffff88006af77880: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] >ffff88006af77900: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] ^
[ 19.338387] ffff88006af77980: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
[ 19.338387] ffff88006af77a00: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] ==================================================================
This is what a test use-after-free report looked like before:
[ 24.246351] ==================================================================
[ 24.247214] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan] at addr ffff88006bbb38a8
[ 24.247301] Write of size 1 by task insmod/3852
[ 24.247301] CPU: 1 PID: 3852 Comm: insmod Tainted: G B 4.9.0-rc4+ #393
[ 24.247301] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 24.247301] ffff88006a647980 ffffffff81b46a64 ffff88006c801b40 ffff88006bbb38a0
[ 24.247301] ffff88006bbb38b0 ffff88006bbb38a0 ffff88006a6479a8 ffffffff8150a86c
[ 24.247301] ffff88006a647a38 ffff88006c801b40 ffff8800ebbb38a8 ffff88006a647a28
[ 24.247301] Call Trace:
[ 24.247301] [<ffffffff81b46a64>] dump_stack+0xb3/0x10f
[ 24.247301] [<ffffffff8150a86c>] kasan_object_err+0x1c/0x70
[ 24.247301] [<ffffffff8150ab07>] kasan_report_error+0x1f7/0x4d0
[ 24.247301] [<ffffffff8120812d>] ? trace_hardirqs_on+0xd/0x10
[ 24.247301] [<ffffffffa001928c>] ? copy_user_test+0x24f/0x24f [test_kasan]
[ 24.247301] [<ffffffff8150af5e>] __asan_report_store1_noabort+0x3e/0x40
[ 24.247301] [<ffffffffa0018609>] ? kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 24.247301] [<ffffffffa0018609>] kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 24.247301] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 24.247301] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 24.247301] [<ffffffff810004c0>] ? initcall_blacklisted+0x170/0x170
[ 24.247301] [<ffffffff81509e4b>] ? kasan_kmalloc+0xab/0xe0
[ 24.247301] [<ffffffff81509ce5>] ? kasan_unpoison_shadow+0x35/0x50
[ 24.247301] [<ffffffff81509d7c>] ? __asan_register_globals+0x7c/0xa0
[ 24.247301] [<ffffffff8140d6c6>] do_init_module+0x1c1/0x516
[ 24.247301] [<ffffffff812bbe4d>] load_module+0x65ed/0x8f90
[ 24.247301] [<ffffffff812b2fa0>] ? __symbol_put+0xb0/0xb0
[ 24.247301] [<ffffffffa001002d>] ? __UNIQUE_ID_vermagic8+0x36ff9f26d843/0x36ff9f26d846 [test_kasan]
[ 24.247301] [<ffffffff812b5860>] ? module_frob_arch_sections+0x20/0x20
[ 24.247301] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 24.247301] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 24.247301] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 24.247301] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 24.247301] [<ffffffff812be9ac>] SYSC_init_module+0x1bc/0x1d0
[ 24.247301] [<ffffffff812be7f0>] ? load_module+0x8f90/0x8f90
[ 24.247301] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 24.247301] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 24.247301] [<ffffffff812beb29>] SyS_init_module+0x9/0x10
[ 24.247301] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 24.247301] Object at ffff88006bbb38a0, in cache kmalloc-16 size: 16
[ 24.247301] Allocated:
[ 24.247301] PID = 3852
[ 24.247301] [ 24.247301] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 24.247301] [ 24.247301] [<ffffffff81509bd6>] save_stack+0x46/0xd0
[ 24.247301] [ 24.247301] [<ffffffff81509e4b>] kasan_kmalloc+0xab/0xe0
[ 24.247301] [ 24.247301] [<ffffffff8150557c>] kmem_cache_alloc_trace+0xec/0x270
[ 24.247301] [ 24.247301] [<ffffffffa00185b2>] kmalloc_uaf+0x56/0xb9 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 24.247301] [ 24.247301] [<ffffffff8140d6c6>] do_init_module+0x1c1/0x516
[ 24.247301] [ 24.247301] [<ffffffff812bbe4d>] load_module+0x65ed/0x8f90
[ 24.247301] [ 24.247301] [<ffffffff812be9ac>] SYSC_init_module+0x1bc/0x1d0
[ 24.247301] [ 24.247301] [<ffffffff812beb29>] SyS_init_module+0x9/0x10
[ 24.247301] [ 24.247301] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 24.247301] Freed:
[ 24.247301] PID = 3852
[ 24.247301] [ 24.247301] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 24.247301] [ 24.247301] [<ffffffff81509bd6>] save_stack+0x46/0xd0
[ 24.247301] [ 24.247301] [<ffffffff8150a433>] kasan_slab_free+0x73/0xc0
[ 24.247301] [ 24.247301] [<ffffffff81506918>] kfree+0xe8/0x2b0
[ 24.247301] [ 24.247301] [<ffffffffa00185e1>] kmalloc_uaf+0x85/0xb9 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 24.247301] [ 24.247301] [<ffffffff8140d6c6>] do_init_module+0x1c1/0x516
[ 24.247301] [ 24.247301] [<ffffffff812bbe4d>] load_module+0x65ed/0x8f90
[ 24.247301] [ 24.247301] [<ffffffff812be9ac>] SYSC_init_module+0x1bc/0x1d0
[ 24.247301] [ 24.247301] [<ffffffff812beb29>] SyS_init_module+0x9/0x10
[ 24.247301] [ 24.247301] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 24.247301] Memory state around the buggy address:
[ 24.247301] ffff88006bbb3780: fb fb fc fc fb fb fc fc 00 00 fc fc 00 00 fc fc
[ 24.247301] ffff88006bbb3800: 00 00 fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 24.247301] >ffff88006bbb3880: fb fb fc fc fb fb fc fc 00 00 fc fc fb fb fc fc
[ 24.247301] ^
[ 24.247301] ffff88006bbb3900: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
[ 24.247301] ffff88006bbb3980: 00 00 fc fc 00 00 fc fc fb fb fc fc 00 00 fc fc
[ 24.247301] ==================================================================
Andrey Konovalov (2):
stacktrace: fix print_stack_trace printing timestamp twice
kasan: improve error reports
kernel/stacktrace.c | 6 +-
mm/kasan/report.c | 246 +++++++++++++++++++++++++++++++++++-----------------
2 files changed, 169 insertions(+), 83 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [PATCH 0/2] kasan,stacktrace: improve error reports
From: Andrey Konovalov @ 2016-11-08 19:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, kasan-dev,
linux-mm, linux-kernel, mingo
Cc: kcc, Andrey Konovalov
This patchset improves KASAN reports by making the following changes:
1. Changes header format from:
[ 24.247214] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan] at addr ffff88006bbb38a8
[ 24.247301] Write of size 1 by task insmod/3852
to
[ 19.338308] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] Write of size 1 at addr ffff88006af77968 by task insmod/3840
2. Unifies header format between different kinds of bad accesses.
3. Adds empty lines between parts of the report to improve readability.
4. Improves slab object description, before:
[ 24.247301] Object at ffff88006bbb38a0, in cache kmalloc-16 size: 16
now:
[ 19.338387] The buggy address belongs to the object at ffff88006af77960
[ 19.338387] which belongs to the cache kmalloc-16 of size 16
[ 19.338387] The buggy address ffff88006af77968 is located 8 bytes inside
[ 19.338387] of 16-byte region [ffff88006af77960, ffff88006af77970)
5. Fixes printing timeframes twice in alloc and free stack traces.
6. Improves mm/kasan/report.c readability.
This is what a test use-after-free report looks like now:
[ 19.337402] ==================================================================
[ 19.338308] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] Write of size 1 at addr ffff88006af77968 by task insmod/3840
[ 19.338387]
[ 19.338387] page:ffffea0001abddc0 count:1 mapcount:0 mapping: (null) index:0x0
[ 19.338387] flags: 0x100000000000080(slab)
[ 19.338387] page dumped because: kasan: bad access detected
[ 19.338387]
[ 19.338387] CPU: 0 PID: 3840 Comm: insmod Tainted: G B 4.9.0-rc4+ #394
[ 19.338387] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 19.338387] ffff880063d6f9a8 ffffffff81b46b74 ffff880063d6fa38 ffff88006af77968
[ 19.338387] 00000000000000fa 00000000000000fb ffff880063d6fa28 ffffffff8150aa92
[ 19.338387] ffffffff8120812d ffff880063d6fa00 0000000000000282 0000000000000296
[ 19.338387] Call Trace:
[ 19.338387] [<ffffffff81b46b74>] dump_stack+0xb3/0x10f
[ 19.338387] [<ffffffff8150aa92>] kasan_report_error+0x122/0x560
[ 19.338387] [<ffffffff8120812d>] ? trace_hardirqs_on+0xd/0x10
[ 19.338387] [<ffffffffa001928c>] ? copy_user_test+0x24f/0x24f [test_kasan]
[ 19.338387] [<ffffffff8150b04e>] __asan_report_store1_noabort+0x3e/0x40
[ 19.338387] [<ffffffffa0018609>] ? kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa0018609>] kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 19.338387] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 19.338387] [<ffffffff810004c0>] ? initcall_blacklisted+0x170/0x170
[ 19.338387] [<ffffffff81509e1b>] ? kasan_kmalloc+0xab/0xe0
[ 19.338387] [<ffffffff81509cb5>] ? kasan_unpoison_shadow+0x35/0x50
[ 19.338387] [<ffffffff81509d4c>] ? __asan_register_globals+0x7c/0xa0
[ 19.338387] [<ffffffff8140d696>] do_init_module+0x1c1/0x516
[ 19.338387] [<ffffffff812bbe1d>] load_module+0x65ed/0x8f90
[ 19.338387] [<ffffffff812b2f70>] ? __symbol_put+0xb0/0xb0
[ 19.338387] [<ffffffffa001002d>] ? __UNIQUE_ID_vermagic8+0x36ff9f20d843/0x36ff9f20d846 [test_kasan]
[ 19.338387] [<ffffffff812b5830>] ? module_frob_arch_sections+0x20/0x20
[ 19.338387] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 19.338387] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 19.338387] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 19.338387] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 19.338387] [<ffffffff812be97c>] SYSC_init_module+0x1bc/0x1d0
[ 19.338387] [<ffffffff812be7c0>] ? load_module+0x8f90/0x8f90
[ 19.338387] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 19.338387] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 19.338387] [<ffffffff812beaf9>] SyS_init_module+0x9/0x10
[ 19.338387] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 19.338387]
[ 19.338387] The buggy address belongs to the object at ffff88006af77960
[ 19.338387] which belongs to the cache kmalloc-16 of size 16
[ 19.338387] The buggy address ffff88006af77968 is located 8 bytes inside
[ 19.338387] of 16-byte region [ffff88006af77960, ffff88006af77970)
[ 19.338387]
[ 19.338387] Freed by task 3840:
[ 19.338387] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 19.338387] [<ffffffff81509ba6>] save_stack+0x46/0xd0
[ 19.338387] [<ffffffff8150a403>] kasan_slab_free+0x73/0xc0
[ 19.338387] [<ffffffff815068e8>] kfree+0xe8/0x2b0
[ 19.338387] [<ffffffffa00185e1>] kmalloc_uaf+0x85/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 19.338387] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 19.338387] [<ffffffff8140d696>] do_init_module+0x1c1/0x516
[ 19.338387] [<ffffffff812bbe1d>] load_module+0x65ed/0x8f90
[ 19.338387] [<ffffffff812be97c>] SYSC_init_module+0x1bc/0x1d0
[ 19.338387] [<ffffffff812beaf9>] SyS_init_module+0x9/0x10
[ 19.338387] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 19.338387]
[ 19.338387] Allocated by task 3840:
[ 19.338387] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 19.338387] [<ffffffff81509ba6>] save_stack+0x46/0xd0
[ 19.338387] [<ffffffff81509e1b>] kasan_kmalloc+0xab/0xe0
[ 19.338387] [<ffffffff8150554c>] kmem_cache_alloc_trace+0xec/0x270
[ 19.338387] [<ffffffffa00185b2>] kmalloc_uaf+0x56/0xb9 [test_kasan]
[ 19.338387] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 19.338387] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 19.338387] [<ffffffff8140d696>] do_init_module+0x1c1/0x516
[ 19.338387] [<ffffffff812bbe1d>] load_module+0x65ed/0x8f90
[ 19.338387] [<ffffffff812be97c>] SYSC_init_module+0x1bc/0x1d0
[ 19.338387] [<ffffffff812beaf9>] SyS_init_module+0x9/0x10
[ 19.338387] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 19.338387]
[ 19.338387] Memory state around the buggy address:
[ 19.338387] ffff88006af77800: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] ffff88006af77880: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] >ffff88006af77900: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] ^
[ 19.338387] ffff88006af77980: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
[ 19.338387] ffff88006af77a00: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc
[ 19.338387] ==================================================================
This is what a test use-after-free report looked like before:
[ 24.246351] ==================================================================
[ 24.247214] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan] at addr ffff88006bbb38a8
[ 24.247301] Write of size 1 by task insmod/3852
[ 24.247301] CPU: 1 PID: 3852 Comm: insmod Tainted: G B 4.9.0-rc4+ #393
[ 24.247301] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 24.247301] ffff88006a647980 ffffffff81b46a64 ffff88006c801b40 ffff88006bbb38a0
[ 24.247301] ffff88006bbb38b0 ffff88006bbb38a0 ffff88006a6479a8 ffffffff8150a86c
[ 24.247301] ffff88006a647a38 ffff88006c801b40 ffff8800ebbb38a8 ffff88006a647a28
[ 24.247301] Call Trace:
[ 24.247301] [<ffffffff81b46a64>] dump_stack+0xb3/0x10f
[ 24.247301] [<ffffffff8150a86c>] kasan_object_err+0x1c/0x70
[ 24.247301] [<ffffffff8150ab07>] kasan_report_error+0x1f7/0x4d0
[ 24.247301] [<ffffffff8120812d>] ? trace_hardirqs_on+0xd/0x10
[ 24.247301] [<ffffffffa001928c>] ? copy_user_test+0x24f/0x24f [test_kasan]
[ 24.247301] [<ffffffff8150af5e>] __asan_report_store1_noabort+0x3e/0x40
[ 24.247301] [<ffffffffa0018609>] ? kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 24.247301] [<ffffffffa0018609>] kmalloc_uaf+0xad/0xb9 [test_kasan]
[ 24.247301] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 24.247301] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 24.247301] [<ffffffff810004c0>] ? initcall_blacklisted+0x170/0x170
[ 24.247301] [<ffffffff81509e4b>] ? kasan_kmalloc+0xab/0xe0
[ 24.247301] [<ffffffff81509ce5>] ? kasan_unpoison_shadow+0x35/0x50
[ 24.247301] [<ffffffff81509d7c>] ? __asan_register_globals+0x7c/0xa0
[ 24.247301] [<ffffffff8140d6c6>] do_init_module+0x1c1/0x516
[ 24.247301] [<ffffffff812bbe4d>] load_module+0x65ed/0x8f90
[ 24.247301] [<ffffffff812b2fa0>] ? __symbol_put+0xb0/0xb0
[ 24.247301] [<ffffffffa001002d>] ? __UNIQUE_ID_vermagic8+0x36ff9f26d843/0x36ff9f26d846 [test_kasan]
[ 24.247301] [<ffffffff812b5860>] ? module_frob_arch_sections+0x20/0x20
[ 24.247301] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 24.247301] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 24.247301] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 24.247301] [<ffffffff83fc1f5f>] ? retint_kernel+0x10/0x10
[ 24.247301] [<ffffffff812be9ac>] SYSC_init_module+0x1bc/0x1d0
[ 24.247301] [<ffffffff812be7f0>] ? load_module+0x8f90/0x8f90
[ 24.247301] [<ffffffff81207f90>] ? trace_hardirqs_on_caller+0x420/0x5b0
[ 24.247301] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 24.247301] [<ffffffff812beb29>] SyS_init_module+0x9/0x10
[ 24.247301] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 24.247301] Object at ffff88006bbb38a0, in cache kmalloc-16 size: 16
[ 24.247301] Allocated:
[ 24.247301] PID = 3852
[ 24.247301] [ 24.247301] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 24.247301] [ 24.247301] [<ffffffff81509bd6>] save_stack+0x46/0xd0
[ 24.247301] [ 24.247301] [<ffffffff81509e4b>] kasan_kmalloc+0xab/0xe0
[ 24.247301] [ 24.247301] [<ffffffff8150557c>] kmem_cache_alloc_trace+0xec/0x270
[ 24.247301] [ 24.247301] [<ffffffffa00185b2>] kmalloc_uaf+0x56/0xb9 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 24.247301] [ 24.247301] [<ffffffff8140d6c6>] do_init_module+0x1c1/0x516
[ 24.247301] [ 24.247301] [<ffffffff812bbe4d>] load_module+0x65ed/0x8f90
[ 24.247301] [ 24.247301] [<ffffffff812be9ac>] SYSC_init_module+0x1bc/0x1d0
[ 24.247301] [ 24.247301] [<ffffffff812beb29>] SyS_init_module+0x9/0x10
[ 24.247301] [ 24.247301] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 24.247301] Freed:
[ 24.247301] PID = 3852
[ 24.247301] [ 24.247301] [<ffffffff8107e236>] save_stack_trace+0x16/0x20
[ 24.247301] [ 24.247301] [<ffffffff81509bd6>] save_stack+0x46/0xd0
[ 24.247301] [ 24.247301] [<ffffffff8150a433>] kasan_slab_free+0x73/0xc0
[ 24.247301] [ 24.247301] [<ffffffff81506918>] kfree+0xe8/0x2b0
[ 24.247301] [ 24.247301] [<ffffffffa00185e1>] kmalloc_uaf+0x85/0xb9 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffffa00192db>] kmalloc_tests_init+0x4f/0x79 [test_kasan]
[ 24.247301] [ 24.247301] [<ffffffff81000560>] do_one_initcall+0xa0/0x230
[ 24.247301] [ 24.247301] [<ffffffff8140d6c6>] do_init_module+0x1c1/0x516
[ 24.247301] [ 24.247301] [<ffffffff812bbe4d>] load_module+0x65ed/0x8f90
[ 24.247301] [ 24.247301] [<ffffffff812be9ac>] SYSC_init_module+0x1bc/0x1d0
[ 24.247301] [ 24.247301] [<ffffffff812beb29>] SyS_init_module+0x9/0x10
[ 24.247301] [ 24.247301] [<ffffffff83fc1581>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 24.247301] Memory state around the buggy address:
[ 24.247301] ffff88006bbb3780: fb fb fc fc fb fb fc fc 00 00 fc fc 00 00 fc fc
[ 24.247301] ffff88006bbb3800: 00 00 fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 24.247301] >ffff88006bbb3880: fb fb fc fc fb fb fc fc 00 00 fc fc fb fb fc fc
[ 24.247301] ^
[ 24.247301] ffff88006bbb3900: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
[ 24.247301] ffff88006bbb3980: 00 00 fc fc 00 00 fc fc fb fb fc fc 00 00 fc fc
[ 24.247301] ==================================================================
Andrey Konovalov (2):
stacktrace: fix print_stack_trace printing timestamp twice
kasan: improve error reports
kernel/stacktrace.c | 6 +-
mm/kasan/report.c | 246 +++++++++++++++++++++++++++++++++++-----------------
2 files changed, 169 insertions(+), 83 deletions(-)
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Fuego] LPC Increase Test Coverage in a Linux-based OS
From: Guillermo Adrian Ponce Castañeda @ 2016-11-08 19:38 UTC (permalink / raw)
To: Bird, Timothy; +Cc: fuego@lists.linuxfoundation.org
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF0ABAB262@USCULXMSG01.am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 8568 bytes --]
Hello Tim and Victor,
I am a co-author of this code and I must confess that it was more or less
my fault that it was made on Perl.
Regarding how many logs the program analyzes, I think it is nowhere near
5000, it is much less, but taking in count that some logs are similar I
think it is possible that some logs that haven't been tested are going to
work, but who knows :).
And about the output file, right now it delivers a comma separated list of
numbers, without headers, this is because this code is part of a bigger
tool, I think that code is not open source yet, but that doesn't matter I
guess, the thing here is that I think the output could be changed into a
json like you suggested and i can try to translate the code from Perl to
Python, still not sure how long it's gonna take, but I can sure try.
Thanks.
- Guillermo Ponce
On Mon, Nov 7, 2016 at 6:26 PM, Bird, Timothy <Tim.Bird@am.sony.com> wrote:
> Victor,
>
> Thanks for raising this topic. I think it's an important one. I have
> some comments below, inline.
>
> > -----Original Message-----
> > From: Victor Rodriguez on Saturday, November 05, 2016 10:15 AM
> >
> > This week I presented a case of study for the problem of lack of test
> > log output standardization in the majority of packages that are used
> > to build the current Linux distributions. This was presented as a BOF
> > ( https://www.linuxplumbersconf.org/2016/ocw/proposals/3555) during
> > the Linux Plumbers Conference.
> >
> > it was a productive discussion that let us share the problem that we
> > have in the current projects that we use every day to build a
> > distribution ( either in embedded as in a cloud base distribution).
> > The open source projects don't follow a standard output log format to
> > print the passing and failing tests that they run during packaging
> > time ( "make test" or "make check" )
> >
> > The Clear Linux project is using a simple Perl script that helps them
> > to count the number of passing and failing tests (which should be
> > trivial if could have a single standard output among all the projects,
> > but we don’t):
> >
> > https://github.com/clearlinux/autospec/blob/master/autospec/count.pl
> >
> > # perl count.pl <build.log>
>
> A few remarks about this. This will be something of a stream of ideas, not
> very well organized. I'd like to prevent requiring too many different
> language skills in Fuego. In order to write a test for Fuego, we already
> require
> knowledge of shell script, python (for the benchmark parsers) and json
> formats
> (for the test specs and plans). I'd be hesitant to adopt something in
> perl, but maybe
> there's a way to leverage the expertise embedded in your script.
>
> I'm not that fond of the idea of integrating all the parsers into a single
> program.
> I think it's conceptually simpler to have a parser per log file format.
> However,
> I haven't looked in detail at your parser, so I can't really comment on
> it's
> complexity. I note that 0day has a parser per test (but I haven't checked
> to
> see if they re-use common parsers between tests.) Possibly some
> combination
> of code-driven and data-driven parsers is best, but I don't have the
> experience
> you guys do with your parser.
>
> If I understood your presentation, you are currently parsing
> logs for thousands of packages. I thought you said that about half of the
> 20,000 packages in a distro have unit tests, and I thought you said that
> your parser was covering about half of those (so, about 5000 packages
> currently).
> And this is with 26 log formats parsed so far.
>
> I'm guessing that packages have a "long tail" of formats, with them getting
> weirder and weirder the farther out on the tail of formats you get.
>
> Please correct my numbers if I'm mistaken.
>
> > Examples of real packages build logs:
> >
> > https://kojipkgs.fedoraproject.org//packages/
> gcc/6.2.1/2.fc25/data/logs/x8
> > 6_64/build.log
> > https://kojipkgs.fedoraproject.org//packages/
> acl/2.2.52/11.fc24/data/logs/x
> > 86_64/build.log
> >
> > So far that simple (and not well engineered) parser has found 26
> > “standard” outputs ( and counting ) .
>
> This is actually remarkable, as Fuego is only handing the formats for the
> standalone tests we ship with Fuego. As I stated in the BOF, we have two
> mechanisms, one for functional tests that uses shell, grep and diff, and
> one for benchmark tests that uses a very small python program that uses
> regexes. So, currently we only have 50 tests covered, but many of these
> parsers use very simple one-line grep regexes.
>
> Neither of these Fuego log results parser methods supports tracking
> individual
> subtest results.
>
> > The script has the fail that it
> > does not recognize the name of the tests in order to detect
> > regressions. Maybe one test was passing in the previous release and in
> > the new one is failing, and then the number of failing tests remains
> > the same.
>
> This is a concern with the Fuego log parsing as well.
>
> I would like to modify Fuego's parser to not just parse out counts, but to
> also convert the results to something where individual sub-tests can be
> tracked over time. Daniel Sangorrin's recent work converting the output
> of LTP into excel format might be one way to do this (although I'm not
> that comfortable with using a proprietary format - I would prefer CSV
> or json, but I think Daniel is going for ease of use first.)
>
> I need to do some more research, but I'm hoping that there are Jenkins
> plugins (maybe xUnit) that will provide tools to automatically handle
> visualization of test and sub-test results over time. If so, I might
> try converting the Fuego parsers to product that format.
>
> > To be honest, before presenting at LPC I was very confident that this
> > script ( or another version of it , much smarter ) could be beginning
> > of the solution to the problem we have. However, during the discussion
> > at LPC I understand that this might be a huge effort (not sure if
> > bigger) in order to solve the nightmare we already have.
>
> So far, I think you're solving a bit different problem than Fuego is, and
> in one sense are
> much farther along than Fuego. I'm hoping we can learn from your
> experience with this.
>
> I do think we share the goal of producing a standard, or at least a
> recommendation,
> for a common test log output format. This would help the industry going
> forward.
> Even if individual tests don't produce the standard format, it will help
> 3rd parties
> write parsers that conform the test output to the format, as well as
> encourage the
> development of tools that utilize the format for visualization or
> regression checking.
>
> Do you feel confident enough to propose a format? I don't at the moment.
> I'd like to survey the industry for 1) existing formats produced by tests
> (which you have good experience
> with, which is already maybe capture well by your perl script), and 2)
> existing tools
> that use common formats as input (e.g. the Jenkins xunit plugin). From
> this I'd like
> to develop some ideas about the fields that are most commonly used, and a
> good language to
> express those fields. My preference would be JSON - I'm something of an
> XML naysayer, but
> I could be talked into YAML. Under no circumstances do I want to invent a
> new language for
> this.
>
> > Tim Bird participates at the BOF and recommends me to send a mail to
> > the Fuego project team in order to look for more inputs and ideas bout
> > this topic.
> >
> > I really believe in the importance of attack this problem before we
> > have a bigger problem
> >
> > All feedback is more than welcome
>
> Here is how I propose moving forward on this. I'd like to get a group
> together to study this
> issue. I wrote down a list of people at LPC who seem to be working on
> test issues. I'd like to
> do the following:
> 1) perform a survey of the areas I mentioned above
> 2) write up a draft spec
> 3) send it around for comments (to what individual and lists? is an open
> issue)
> 4) discuss it at a future face-to-face meeting (probably at ELC or maybe
> next year's plumbers)
> 5) publish it as a standard endorsed by the Linux Foundation
>
> Let me know what you think, and if you'd like to be involved.
>
> Thanks and regards,
> -- Tim
>
>
--
- Guillermo Ponce
[-- Attachment #2: Type: text/html, Size: 10161 bytes --]
^ permalink raw reply
* [Bug 187321] Give Intel's docs for cpuid faulting a permanent home
From: bugzilla-daemon @ 2016-11-08 19:37 UTC (permalink / raw)
To: kvm
In-Reply-To: <bug-187321-28872@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=187321
Kyle Huey <me@kylehuey.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 187321] New: Give Intel's docs for cpuid faulting a permanent home
From: bugzilla-daemon @ 2016-11-08 19:37 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=187321
Bug ID: 187321
Summary: Give Intel's docs for cpuid faulting a permanent home
Product: Virtualization
Version: unspecified
Kernel Version: 4.9
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: kvm
Assignee: virtualization_kvm@kernel-bugs.osdl.org
Reporter: me@kylehuey.com
Regression: No
Created attachment 243991
--> https://bugzilla.kernel.org/attachment.cgi?id=243991&action=edit
Intel's VT docs
Per https://lkml.org/lkml/2016/11/8/782
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH v4 3/8] iio: mcp4531: provide range of available raw values
From: Peter Rosin @ 2016-11-08 11:58 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Daniel Baluta,
Slawomir Stepien, Thomas Gleixner, linux-iio, devicetree
In-Reply-To: <1478606339-31253-1-git-send-email-peda@axentia.se>
Example:
$ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available'
[0 1 256]
Meaning: min 0, step 1 and max 256.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../testing/sysfs-bus-iio-potentiometer-mcp4531 | 8 ++
MAINTAINERS | 1 +
drivers/iio/potentiometer/mcp4531.c | 104 ++++++++++++---------
3 files changed, 71 insertions(+), 42 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-potentiometer-mcp4531
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-potentiometer-mcp4531 b/Documentation/ABI/testing/sysfs-bus-iio-potentiometer-mcp4531
new file mode 100644
index 000000000000..2a91fbe394fc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-potentiometer-mcp4531
@@ -0,0 +1,8 @@
+What: /sys/bus/iio/devices/iio:deviceX/out_resistance_raw_available
+Date: October 2016
+KernelVersion: 4.9
+Contact: Peter Rosin <peda@axentia.se>
+Description:
+ The range of available values represented as the minimum value,
+ the step and the maximum value, all enclosed in square brackets.
+ Example: [0 1 256]
diff --git a/MAINTAINERS b/MAINTAINERS
index 411e3b87b8c2..2409e1d79cb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7707,6 +7707,7 @@ MCP4531 MICROCHIP DIGITAL POTENTIOMETER DRIVER
M: Peter Rosin <peda@axentia.se>
L: linux-iio@vger.kernel.org
S: Maintained
+F: Documentation/ABI/testing/sysfs-bus-iio-potentiometer-mcp4531
F: drivers/iio/potentiometer/mcp4531.c
MEASUREMENT COMPUTING CIO-DAC IIO DRIVER
diff --git a/drivers/iio/potentiometer/mcp4531.c b/drivers/iio/potentiometer/mcp4531.c
index 13b6ae2fcf7b..0d1bcf89ae17 100644
--- a/drivers/iio/potentiometer/mcp4531.c
+++ b/drivers/iio/potentiometer/mcp4531.c
@@ -38,7 +38,7 @@
struct mcp4531_cfg {
int wipers;
- int max_pos;
+ int avail[3];
int kohms;
};
@@ -78,38 +78,38 @@ enum mcp4531_type {
};
static const struct mcp4531_cfg mcp4531_cfg[] = {
- [MCP453x_502] = { .wipers = 1, .max_pos = 128, .kohms = 5, },
- [MCP453x_103] = { .wipers = 1, .max_pos = 128, .kohms = 10, },
- [MCP453x_503] = { .wipers = 1, .max_pos = 128, .kohms = 50, },
- [MCP453x_104] = { .wipers = 1, .max_pos = 128, .kohms = 100, },
- [MCP454x_502] = { .wipers = 1, .max_pos = 128, .kohms = 5, },
- [MCP454x_103] = { .wipers = 1, .max_pos = 128, .kohms = 10, },
- [MCP454x_503] = { .wipers = 1, .max_pos = 128, .kohms = 50, },
- [MCP454x_104] = { .wipers = 1, .max_pos = 128, .kohms = 100, },
- [MCP455x_502] = { .wipers = 1, .max_pos = 256, .kohms = 5, },
- [MCP455x_103] = { .wipers = 1, .max_pos = 256, .kohms = 10, },
- [MCP455x_503] = { .wipers = 1, .max_pos = 256, .kohms = 50, },
- [MCP455x_104] = { .wipers = 1, .max_pos = 256, .kohms = 100, },
- [MCP456x_502] = { .wipers = 1, .max_pos = 256, .kohms = 5, },
- [MCP456x_103] = { .wipers = 1, .max_pos = 256, .kohms = 10, },
- [MCP456x_503] = { .wipers = 1, .max_pos = 256, .kohms = 50, },
- [MCP456x_104] = { .wipers = 1, .max_pos = 256, .kohms = 100, },
- [MCP463x_502] = { .wipers = 2, .max_pos = 128, .kohms = 5, },
- [MCP463x_103] = { .wipers = 2, .max_pos = 128, .kohms = 10, },
- [MCP463x_503] = { .wipers = 2, .max_pos = 128, .kohms = 50, },
- [MCP463x_104] = { .wipers = 2, .max_pos = 128, .kohms = 100, },
- [MCP464x_502] = { .wipers = 2, .max_pos = 128, .kohms = 5, },
- [MCP464x_103] = { .wipers = 2, .max_pos = 128, .kohms = 10, },
- [MCP464x_503] = { .wipers = 2, .max_pos = 128, .kohms = 50, },
- [MCP464x_104] = { .wipers = 2, .max_pos = 128, .kohms = 100, },
- [MCP465x_502] = { .wipers = 2, .max_pos = 256, .kohms = 5, },
- [MCP465x_103] = { .wipers = 2, .max_pos = 256, .kohms = 10, },
- [MCP465x_503] = { .wipers = 2, .max_pos = 256, .kohms = 50, },
- [MCP465x_104] = { .wipers = 2, .max_pos = 256, .kohms = 100, },
- [MCP466x_502] = { .wipers = 2, .max_pos = 256, .kohms = 5, },
- [MCP466x_103] = { .wipers = 2, .max_pos = 256, .kohms = 10, },
- [MCP466x_503] = { .wipers = 2, .max_pos = 256, .kohms = 50, },
- [MCP466x_104] = { .wipers = 2, .max_pos = 256, .kohms = 100, },
+ [MCP453x_502] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 5, },
+ [MCP453x_103] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 10, },
+ [MCP453x_503] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 50, },
+ [MCP453x_104] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 100, },
+ [MCP454x_502] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 5, },
+ [MCP454x_103] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 10, },
+ [MCP454x_503] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 50, },
+ [MCP454x_104] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 100, },
+ [MCP455x_502] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 5, },
+ [MCP455x_103] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 10, },
+ [MCP455x_503] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 50, },
+ [MCP455x_104] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 100, },
+ [MCP456x_502] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 5, },
+ [MCP456x_103] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 10, },
+ [MCP456x_503] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 50, },
+ [MCP456x_104] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 100, },
+ [MCP463x_502] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 5, },
+ [MCP463x_103] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 10, },
+ [MCP463x_503] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 50, },
+ [MCP463x_104] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 100, },
+ [MCP464x_502] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 5, },
+ [MCP464x_103] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 10, },
+ [MCP464x_503] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 50, },
+ [MCP464x_104] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 100, },
+ [MCP465x_502] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 5, },
+ [MCP465x_103] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 10, },
+ [MCP465x_503] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 50, },
+ [MCP465x_104] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 100, },
+ [MCP466x_502] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 5, },
+ [MCP466x_103] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 10, },
+ [MCP466x_503] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 50, },
+ [MCP466x_104] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms = 100, },
};
#define MCP4531_WRITE (0 << 2)
@@ -124,13 +124,14 @@ struct mcp4531_data {
const struct mcp4531_cfg *cfg;
};
-#define MCP4531_CHANNEL(ch) { \
- .type = IIO_RESISTANCE, \
- .indexed = 1, \
- .output = 1, \
- .channel = (ch), \
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+#define MCP4531_CHANNEL(ch) { \
+ .type = IIO_RESISTANCE, \
+ .indexed = 1, \
+ .output = 1, \
+ .channel = (ch), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .info_mask_shared_by_type_available = BIT(IIO_CHAN_INFO_RAW), \
}
static const struct iio_chan_spec mcp4531_channels[] = {
@@ -156,13 +157,31 @@ static int mcp4531_read_raw(struct iio_dev *indio_dev,
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
*val = 1000 * data->cfg->kohms;
- *val2 = data->cfg->max_pos;
+ *val2 = data->cfg->avail[2];
return IIO_VAL_FRACTIONAL;
}
return -EINVAL;
}
+static int mcp4531_read_avail(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ const int **vals, int *type, int *length,
+ long mask)
+{
+ struct mcp4531_data *data = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ *length = ARRAY_SIZE(data->cfg->avail);
+ *vals = data->cfg->avail;
+ *type = IIO_VAL_INT;
+ return IIO_AVAIL_RANGE;
+ }
+
+ return -EINVAL;
+}
+
static int mcp4531_write_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int val, int val2, long mask)
@@ -172,7 +191,7 @@ static int mcp4531_write_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_RAW:
- if (val > data->cfg->max_pos || val < 0)
+ if (val > data->cfg->avail[2] || val < 0)
return -EINVAL;
break;
default:
@@ -186,6 +205,7 @@ static int mcp4531_write_raw(struct iio_dev *indio_dev,
static const struct iio_info mcp4531_info = {
.read_raw = mcp4531_read_raw,
+ .read_avail = mcp4531_read_avail,
.write_raw = mcp4531_write_raw,
.driver_module = THIS_MODULE,
};
--
2.1.4
^ permalink raw reply related
* [PATCH v4 6/8] iio: dpot-dac: DAC driver based on a digital potentiometer
From: Peter Rosin @ 2016-11-08 11:58 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Daniel Baluta,
Slawomir Stepien, Thomas Gleixner, linux-iio, devicetree
In-Reply-To: <1478606339-31253-1-git-send-email-peda@axentia.se>
It is assumed that the dpot is used as a voltage divider between the
current dpot wiper setting and the maximum resistance of the dpot. The
divided voltage is provided by a vref regulator.
.------.
.-----------. | |
| vref |--' .---.
| regulator |--. | |
'-----------' | | d |
| | p |
| | o | wiper
| | t |<---------+
| | |
| '---' dac output voltage
| |
'------+------------+
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../ABI/testing/sysfs-bus-iio-dac-dpot-dac | 8 +
MAINTAINERS | 2 +
drivers/iio/dac/Kconfig | 10 +
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/dpot-dac.c | 266 +++++++++++++++++++++
5 files changed, 287 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
create mode 100644 drivers/iio/dac/dpot-dac.c
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac b/Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
new file mode 100644
index 000000000000..580e93f373f6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
@@ -0,0 +1,8 @@
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw_available
+Date: October 2016
+KernelVersion: 4.9
+Contact: Peter Rosin <peda@axentia.se>
+Description:
+ The range of available values represented as the minimum value,
+ the step and the maximum value, all enclosed in square brackets.
+ Example: [0 1 256]
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ff9c12b1313..583c6c93b6f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6128,7 +6128,9 @@ IIO DIGITAL POTENTIOMETER DAC
M: Peter Rosin <peda@axentia.se>
L: linux-iio@vger.kernel.org
S: Maintained
+F: Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
+F: drivers/iio/dac/dpot-dac.c
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron <jic23@kernel.org>
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 120b24478469..d3084028905b 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -200,6 +200,16 @@ config AD8801
To compile this driver as a module choose M here: the module will be called
ad8801.
+config DPOT_DAC
+ tristate "DAC emulation using a DPOT"
+ depends on OF
+ help
+ Say yes here to build support for DAC emulation using a digital
+ potentiometer.
+
+ To compile this driver as a module, choose M here: the module will be
+ called dpot-dac.
+
config LPC18XX_DAC
tristate "NXP LPC18xx DAC driver"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 27642bbf75f2..f01bf4a99867 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AD5686) += ad5686.o
obj-$(CONFIG_AD7303) += ad7303.o
obj-$(CONFIG_AD8801) += ad8801.o
obj-$(CONFIG_CIO_DAC) += cio-dac.o
+obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
obj-$(CONFIG_M62332) += m62332.o
obj-$(CONFIG_MAX517) += max517.o
diff --git a/drivers/iio/dac/dpot-dac.c b/drivers/iio/dac/dpot-dac.c
new file mode 100644
index 000000000000..eb1f0509a3ec
--- /dev/null
+++ b/drivers/iio/dac/dpot-dac.c
@@ -0,0 +1,266 @@
+/*
+ * IIO DAC emulation driver using a digital potentiometer
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * It is assumed that the dpot is used as a voltage divider between the
+ * current dpot wiper setting and the maximum resistance of the dpot. The
+ * divided voltage is provided by a vref regulator.
+ *
+ * .------.
+ * .-----------. | |
+ * | vref |--' .---.
+ * | regulator |--. | |
+ * '-----------' | | d |
+ * | | p |
+ * | | o | wiper
+ * | | t |<---------+
+ * | | |
+ * | '---' dac output voltage
+ * | |
+ * '------+------------+
+ */
+
+#include <linux/err.h>
+#include <linux/iio/consumer.h>
+#include <linux/iio/iio.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+
+struct dpot_dac {
+ struct regulator *vref;
+ struct iio_channel *dpot;
+ u32 max_ohms;
+};
+
+static const struct iio_chan_spec dpot_dac_iio_channel = {
+ .type = IIO_VOLTAGE,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
+ | BIT(IIO_CHAN_INFO_SCALE),
+ .info_mask_separate_available = BIT(IIO_CHAN_INFO_RAW),
+ .output = 1,
+ .indexed = 1,
+};
+
+static int dpot_dac_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct dpot_dac *dac = iio_priv(indio_dev);
+ int ret;
+ unsigned long long tmp;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ return iio_read_channel_raw(dac->dpot, val);
+
+ case IIO_CHAN_INFO_SCALE:
+ ret = iio_read_channel_scale(dac->dpot, val, val2);
+ switch (ret) {
+ case IIO_VAL_FRACTIONAL_LOG2:
+ tmp = *val * 1000000000LL;
+ do_div(tmp, dac->max_ohms);
+ tmp *= regulator_get_voltage(dac->vref) / 1000;
+ do_div(tmp, 1000000000LL);
+ *val = tmp;
+ return ret;
+ case IIO_VAL_INT:
+ /*
+ * Convert integer scale to fractional scale by
+ * setting the denominator (val2) to one...
+ */
+ *val2 = 1;
+ ret = IIO_VAL_FRACTIONAL;
+ /* ...and fall through. */
+ case IIO_VAL_FRACTIONAL:
+ *val *= regulator_get_voltage(dac->vref) / 1000;
+ *val2 *= dac->max_ohms;
+ break;
+ }
+
+ return ret;
+ }
+
+ return -EINVAL;
+}
+
+static int dpot_dac_read_avail(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ const int **vals, int *type, int *length,
+ long mask)
+{
+ struct dpot_dac *dac = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ *type = IIO_VAL_INT;
+ return iio_read_avail_channel_raw(dac->dpot, vals, length);
+ }
+
+ return -EINVAL;
+}
+
+static int dpot_dac_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct dpot_dac *dac = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ return iio_write_channel_raw(dac->dpot, val);
+ }
+
+ return -EINVAL;
+}
+
+static const struct iio_info dpot_dac_info = {
+ .read_raw = dpot_dac_read_raw,
+ .read_avail = dpot_dac_read_avail,
+ .write_raw = dpot_dac_write_raw,
+ .driver_module = THIS_MODULE,
+};
+
+static int dpot_dac_channel_max_ohms(struct iio_dev *indio_dev)
+{
+ struct device *dev = &indio_dev->dev;
+ struct dpot_dac *dac = iio_priv(indio_dev);
+ unsigned long long tmp;
+ int ret;
+ int val;
+ int val2;
+ int max;
+
+ ret = iio_read_max_channel_raw(dac->dpot, &max);
+ if (ret < 0) {
+ dev_err(dev, "dpot does not indicate its raw maximum value\n");
+ return ret;
+ }
+
+ switch (iio_read_channel_scale(dac->dpot, &val, &val2)) {
+ case IIO_VAL_INT:
+ return max * val;
+ case IIO_VAL_FRACTIONAL:
+ tmp = (unsigned long long)max * val;
+ do_div(tmp, val2);
+ return tmp;
+ case IIO_VAL_FRACTIONAL_LOG2:
+ tmp = val * 1000000000LL * max >> val2;
+ do_div(tmp, 1000000000LL);
+ return tmp;
+ default:
+ dev_err(dev, "dpot has a scale that is too weird\n");
+ }
+
+ return -EINVAL;
+}
+
+static int dpot_dac_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct iio_dev *indio_dev;
+ struct dpot_dac *dac;
+ enum iio_chan_type type;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*dac));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, indio_dev);
+ dac = iio_priv(indio_dev);
+
+ indio_dev->name = dev_name(dev);
+ indio_dev->dev.parent = dev;
+ indio_dev->info = &dpot_dac_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = &dpot_dac_iio_channel;
+ indio_dev->num_channels = 1;
+
+ dac->vref = devm_regulator_get(dev, "vref");
+ if (IS_ERR(dac->vref)) {
+ if (PTR_ERR(dac->dpot) != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "failed to get vref regulator\n");
+ return PTR_ERR(dac->vref);
+ }
+
+ dac->dpot = devm_iio_channel_get(dev, "dpot");
+ if (IS_ERR(dac->dpot)) {
+ if (PTR_ERR(dac->dpot) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get dpot input channel\n");
+ return PTR_ERR(dac->dpot);
+ }
+
+ ret = iio_get_channel_type(dac->dpot, &type);
+ if (ret < 0)
+ return ret;
+
+ if (type != IIO_RESISTANCE) {
+ dev_err(dev, "dpot is of the wrong type\n");
+ return -EINVAL;
+ }
+
+ ret = dpot_dac_channel_max_ohms(indio_dev);
+ if (ret < 0)
+ return ret;
+ dac->max_ohms = ret;
+
+ ret = regulator_enable(dac->vref);
+ if (ret) {
+ dev_err(dev, "failed to enable the vref regulator\n");
+ return ret;
+ }
+
+ ret = iio_device_register(indio_dev);
+ if (ret) {
+ dev_err(dev, "failed to register iio device\n");
+ goto disable_reg;
+ }
+
+ return 0;
+
+disable_reg:
+ regulator_disable(dac->vref);
+ return ret;
+}
+
+static int dpot_dac_remove(struct platform_device *pdev)
+{
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct dpot_dac *dac = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+ regulator_disable(dac->vref);
+
+ return 0;
+}
+
+static const struct of_device_id dpot_dac_match[] = {
+ { .compatible = "dpot-dac" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, dpot_dac_match);
+
+static struct platform_driver dpot_dac_driver = {
+ .probe = dpot_dac_probe,
+ .remove = dpot_dac_remove,
+ .driver = {
+ .name = "iio-dpot-dac",
+ .of_match_table = dpot_dac_match,
+ },
+};
+module_platform_driver(dpot_dac_driver);
+
+MODULE_DESCRIPTION("DAC emulation driver using a digital potentiometer");
+MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
+MODULE_LICENSE("GPL v2");
--
2.1.4
^ permalink raw reply related
* [PATCH v2] irqchip/renesas-irqc: Postpone driver initialization
From: Geert Uytterhoeven @ 2016-11-08 19:35 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Florian Fainelli, Simon Horman, Magnus Damm, linux-renesas-soc,
linux-kernel, netdev, Geert Uytterhoeven
Currently the renesas-irqc driver uses postcore_initcall().
However, the new CPG/MSSR driver uses subsys_initcall(). Hence the
IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to
not find its interrupt on R-Car Gen2 and RZ/G, as the of_mdio subsystem
does not support deferred probe yet.
Replace postcore_initcall() by device_initcall() to work around this.
Note that on R-Mobile APE6, where the PFC/GPIO combo uses the IRQC as
its parent interrupt controller, this does cause a few additional probe
deferrals (for SCIFA0, SD0, SD1, and MMC). But the affected drivers
handle that fine.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
v2:
- Drop RFC state,
- Add Tested-by,
- Improved description.
---
drivers/irqchip/irq-renesas-irqc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-renesas-irqc.c b/drivers/irqchip/irq-renesas-irqc.c
index 52304b139aa46a60..992849e54d00ea77 100644
--- a/drivers/irqchip/irq-renesas-irqc.c
+++ b/drivers/irqchip/irq-renesas-irqc.c
@@ -295,7 +295,7 @@ static int __init irqc_init(void)
{
return platform_driver_register(&irqc_device_driver);
}
-postcore_initcall(irqc_init);
+device_initcall(irqc_init);
static void __exit irqc_exit(void)
{
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/4] dma-buf/fence: make timeout handling in fence_default_wait consistent (v2)
From: Sumit Semwal @ 2016-11-08 19:35 UTC (permalink / raw)
To: Alex Deucher; +Cc: Alex Deucher, DRI mailing list, amd-gfx list
In-Reply-To: <1478553376-18575-1-git-send-email-alexander.deucher@amd.com>
Hi Alex, Christian,
On 8 November 2016 at 02:46, Alex Deucher <alexdeucher@gmail.com> wrote:
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
>
> v2: agd: rebase on drm-next
>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> Signen-off-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>
> These are the same patches Christian sent out previously, just
> rebased on the fence naming changes in drm-next.
>
Series applied to drm-misc; Thanks!
Best,
Sumit.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [U-Boot] U-Boot overlaps BSS and initrd on arm64
From: Will Deacon @ 2016-11-08 19:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161108180440.GD6637@bill-the-cat>
On Tue, Nov 08, 2016 at 01:04:40PM -0500, Tom Rini wrote:
> On Tue, Nov 08, 2016 at 06:01:42PM +0000, Will Deacon wrote:
> > On Tue, Nov 08, 2016 at 12:51:44PM -0500, Tom Rini wrote:
> > > On Tue, Nov 08, 2016 at 09:41:13AM -0800, Dmitry Vyukov wrote:
> > > > Hello,
> > > >
> > > > We've got a boot problem on arm64 devices. Here is boot log:
> > > > https://storage.kernelci.org/mainline/v4.9-rc4/arm64-defconfig+CONFIG_KASAN=y/lab-baylibre-seattle/boot-juno-r2.txt
> > > > https://kernelci.org/boot/id/581ece5a59b514e448f03bd7/
> > > >
> > > > Here is some debugging that Andrey and Mark did:
> > > >
> > > > On Tue, Nov 8, 2016 at 2:00 AM, Andrey Ryabinin wrote:
> > > > > I've looked at juno-r2: https://kernelci.org/boot/id/581ece5a59b514e448f03bd7/
> > > > > So we have
> > > > > Dtb address 0x81f00000
> > > > > Load address 0x80000000
> > > > > Which gives us 31Mb for kernel.
> > > > >
> > > > > It says that Kernel image is 24.62 MiB, but that's without BSS.
> > > > > If bss is big enough it might overwrite dtb.
> > > > > And indeed, build details -
> > > > > https://kernelci.org/build/id/581e850959b514e564f03bdc/
> > > > > shows that bss is 8.5 Mb which is enough to overlap with dtb.
> > > >
> > > > On Tue, Nov 8, 2016 at 3:21 AM, Mark Rutland wrote:
> > > > > FWIW, since v3.17 we've had an image_size field in the arm64 Image
> > > > > header which describes the "real" size of the Image, BSS included. See
> > > > > [1,2].
> > > > > It should be possible to modify U-Boot to use that to automatically
> > > > > place the DTB and initrd at non-clashing locations (or at least to
> > > > > expose the value somehow).
> > > > > I had assumed U-Boot already did that, but it doesn't seem to be the
> > > > > case.
> > >
> > > Yes, we've supported the image_size field since v2016.07 and that board
> > > is running v2016.01. Unfortunately the booting.txt changes that added
> > > the image_size field weren't publicized widely so we didn't see it until
> > > someone else ran into the problem you're describing.
> >
> > Hmm, that's a good point. If you like, I could add something to that file
> > asking for all changes to CC the u-boot list? We should probably do the
> > same for edk2.
>
> That would be nice, sure. I was even thinking that something like the
> cross-distro or boot-architecture lists that linaro runs would have had
> this info go by as well. Thanks!
D'oh, the u-boot list seems to be subscriber-only, so I'm not going to make
a whole lot of friends if I ask kernel devs to add it to cc.
Also, you apparently Acked the image_size change:
http://git.kernel.org/linus/a2c1d73b94ed
so it was at least partially publicized ;)
Will
^ permalink raw reply
* [PATCH v4 4/8] dt-bindings: add axentia to vendor-prefixes
From: Peter Rosin @ 2016-11-08 11:58 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Daniel Baluta,
Slawomir Stepien, Thomas Gleixner, linux-iio, devicetree
In-Reply-To: <1478606339-31253-1-git-send-email-peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..a437120a7eee 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -39,6 +39,7 @@ auo AU Optronics Corporation
auvidea Auvidea GmbH
avago Avago Technologies
avic Shanghai AVIC Optoelectronics Co., Ltd.
+axentia Axentia Technologies AB
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
bosch Bosch Sensortec GmbH
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.