* [PATCH 1/2] libselinux,libsemanage: fall back to gcc in exception.sh
From: Nicolas Iooss @ 2016-11-14 21:57 UTC (permalink / raw)
To: selinux
clang does not support -aux-info option. When exception.sh is run with
CC=clang, use gcc to build selinuxswig_python_exception.i and
semanageswig_python_exception.i.
This does not solve the issue of building libselinux and libsemanage
Python wrappers on a system without gcc. However parsing the result of
"gcc -aux-info" is easier than parsing the header files so stay with
this command at least for now.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
libselinux/src/exception.sh | 6 +++++-
libsemanage/src/exception.sh | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libselinux/src/exception.sh b/libselinux/src/exception.sh
index a58bf3f45778..a3ff83235ced 100755
--- a/libselinux/src/exception.sh
+++ b/libselinux/src/exception.sh
@@ -15,6 +15,10 @@ echo "
;;
esac
}
-${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/selinux/selinux.h
+if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/selinux/selinux.h
+then
+ # clang does not support -aux-info so fall back to gcc
+ gcc -x c -c -I../include - -aux-info temp.aux < ../include/selinux/selinux.h
+fi
for i in `awk '/<stdin>.*extern int/ { print $6 }' temp.aux`; do except $i ; done
rm -f -- temp.aux -.o
diff --git a/libsemanage/src/exception.sh b/libsemanage/src/exception.sh
index d18959cbe85d..a4095f4f8ba6 100644
--- a/libsemanage/src/exception.sh
+++ b/libsemanage/src/exception.sh
@@ -9,6 +9,10 @@ echo "
}
"
}
-${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/semanage/semanage.h
+if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/semanage/semanage.h
+then
+ # clang does not support -aux-info so fall back to gcc
+ gcc -x c -c -I../include - -aux-info temp.aux < ../include/semanage/semanage.h
+fi
for i in `awk '/extern int/ { print $6 }' temp.aux`; do except $i ; done
rm -f -- temp.aux -.o
--
2.10.2
^ permalink raw reply related
* Re: [Xenomai] irqchip missing?
From: Lowell Gilbert @ 2016-11-14 21:56 UTC (permalink / raw)
To: xenomai
In-Reply-To: <d9406df2-c733-579b-8494-036c7e138e7b@xenomai.org>
Philippe Gerum <rpm@xenomai.org> writes:
> On 11/07/2016 11:11 PM, Lowell Gilbert wrote:
>> Lowell Gilbert <kludge@be-well.ilk.org> writes:
>>
>>> I have a system based on a Cortex A9. When I was running under Xenomai
>>> 2.6, I was able to grab interrupts in RTDM. A few months ago, I updated
>>> from a 3.16 Linux kernel and 2.6.4 Xenomai to a 4.1 kernel with 3.0.2
>>> Xenomai. I'm trying to grab the same IRQ now, and the irqchip doesn't
>>> seem to have a set_affinity callback, so I get a kernel dump.
>>
>> ipipe_set_irq_affinity() is being called with a GPIO chip, instead of
>> the GIC that I expect. Why would that be?
>>
>
> ipipe_set_irq_affinity() receives an interrupt number, not an IC
> descriptor. Are you referring to the irq_set_affinity() handler from the
> irq_chip descriptor instead? Please be specific about the code you refer
> to (call site).
In ipipe_set_irq_affinity(), I checked irq_get_chip(irq)->name. That
gave me "gpio-dwapb" rather than "GIC". There is no irq_set_affinity
driver on that chip, and so it crashes.
I haven't figured out how the chip table gets set up.
Be well.
^ permalink raw reply
* [Buildroot] [PATCH] package/gcc: backport xtensa trap pattern for 5.x
From: Thomas Petazzoni @ 2016-11-14 21:55 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479117941-14895-1-git-send-email-jcmvbkbc@gmail.com>
Hello,
On Mon, 14 Nov 2016 02:05:41 -0800, Max Filippov wrote:
> gcc 5.x uses trap pattern extensively to mark locations where program
> execution should never get. Default pattern implementation emits a call
> to 'abort' function. This function however is not always available, e.g.
> it's not available for the libc dynamic linker. Backport implementation
> of the trap pattern for xtensa that does not result in a call to
> 'abort'.
>
> Fixes:
> http://autobuild.buildroot.net/results/0fbcc4475545904bf88f25a3bdf3ee552bf4960e
> http://autobuild.buildroot.net/results/cb7f5bdfac615d774f3bcd1b802f8d74460bc557
> http://autobuild.buildroot.net/results/cf3dc9ae4f74ff28b285f1a862b71d96384d7651
>
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
> .../5.4.0/875-xtensa-implement-trap-pattern.patch | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch
Applied to master, thanks. However, I'm wondering if this backport
should also be done on gcc versions earlier than 5.x. Could you clarify
this point?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [U-Boot] [RFC 1/1] image: Add TEE loading to FIT loadable processing
From: Andrew F. Davis @ 2016-11-14 21:55 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ0dALeZqUkgE7sD-bpoV7NRqjoQKUmpF=Hjz76o3LpNRQ@mail.gmail.com>
On 11/14/2016 02:44 PM, Simon Glass wrote:
> Hi Andrew,
>
> On 14 November 2016 at 12:49, Andrew F. Davis <afd@ti.com> wrote:
>> To help automate the loading of a TEE image during the boot we add a new
>> FIT section type 'tee', when we see this type while loading the loadable
>> sections we automatically call the platforms TEE processing function on
>> this image section.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>> Kconfig | 10 ++++++++++
>> common/image.c | 18 ++++++++++++++++++
>> include/image.h | 15 +++++++++++++++
>> 3 files changed, 43 insertions(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index 1263d0b..97cf7c8 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -291,6 +291,16 @@ config FIT_IMAGE_POST_PROCESS
>> injected into the FIT creation (i.e. the blobs would have been pre-
>> processed before being added to the FIT image).
>>
>> +config FIT_IMAGE_TEE_PROCESS
>> + bool "Enable processing of TEE images during FIT loading by U-Boot"
>> + depends on FIT && TI_SECURE_DEVICE
>
> This is a generic option so I don't think it should depend on TI.
>
This was based on FIT_IMAGE_POST_PROCESS which is also generic but
depends on TI as we currently are the only users.
I think it should be removed from both, so I'll remove it here at least.
>> + help
>> + Allows platforms to perform processing, such as authentication and
>> + installation, on TEE images extracted from FIT images in a platform
>> + or board specific way. In order to use this feature a platform or
>> + board-specific implementation of board_tee_image_process() must be
>> + provided.
>> +
>> config SPL_DFU_SUPPORT
>> bool "Enable SPL with DFU to load binaries to memory device"
>> depends on USB
>> diff --git a/common/image.c b/common/image.c
>> index 7604494..4552ca5 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -165,6 +165,7 @@ static const table_entry_t uimage_type[] = {
>> { IH_TYPE_ZYNQIMAGE, "zynqimage", "Xilinx Zynq Boot Image" },
>> { IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image" },
>> { IH_TYPE_FPGA, "fpga", "FPGA Image" },
>> + { IH_TYPE_TEE, "tee", "TEE OS Image",},
>
> Perhaps write out TEE in full? It's a bit cryptic.
>
Will do.
>> { -1, "", "", },
>> };
>>
>> @@ -1408,6 +1409,8 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
>> int fit_img_result;
>> const char *uname;
>>
>> + uint8_t img_type;
>> +
>> /* Check to see if the images struct has a FIT configuration */
>> if (!genimg_has_config(images)) {
>> debug("## FIT configuration was not specified\n");
>> @@ -1447,6 +1450,21 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
>> /* Something went wrong! */
>> return fit_img_result;
>> }
>> +
>> + fit_img_result = fit_image_get_node(buf, uname);
>> + if (fit_img_result < 0) {
>> + /* Something went wrong! */
>> + return fit_img_result;
>> + }
>> + fit_img_result = fit_image_get_type(buf, fit_img_result, &img_type);
>> + if (fit_img_result < 0) {
>> + /* Something went wrong! */
>> + return fit_img_result;
>> + }
>> +#if defined(CONFIG_FIT_IMAGE_TEE_PROCESS)
>> + if (img_type == IH_TYPE_TEE)
>> + board_tee_image_process(img_data, img_len);
>> +#endif
>
> Instead of putting this here, I think it would be better for
> boot_get_loadable() to return the correct values for ld_start and
> ld_len. Perhaps you need to pass it the loadable index to load, so it
> is called multiple times? The only caller is bootm_find_images().
>
Something like how boot_get_fpga() does it? This seems like a lot of
code duplication between boot_get_fpga() and boot_get_loadable(), and
both ignore ld_start and ld_len.
Does it not make more sense to have a single function for loadable
components like we have now? The loadables themselves have a type we can
switch on and then call a platform specific hook for that loadable type.
I don't want a big TI specific function in common/image.c, but if this
is okay I'll move it out of platform and into here.
> It is too ugly, I think, to check the image type in the 'load'
> function, and do special things.
>
The alternative is a boot_get_<type> function for each type. All called
from bootm_find_images().
>> }
>> break;
>> default:
>> diff --git a/include/image.h b/include/image.h
>> index 2b1296c..57084c8 100644
>> --- a/include/image.h
>> +++ b/include/image.h
>> @@ -279,6 +279,7 @@ enum {
>> IH_TYPE_ZYNQMPIMAGE, /* Xilinx ZynqMP Boot Image */
>> IH_TYPE_FPGA, /* FPGA Image */
>> IH_TYPE_VYBRIDIMAGE, /* VYBRID .vyb Image */
>> + IH_TYPE_TEE, /* Trusted Execution Environment OS Image */
>>
>> IH_TYPE_COUNT, /* Number of image types */
>> };
>> @@ -1263,4 +1264,18 @@ int board_fit_config_name_match(const char *name);
>> void board_fit_image_post_process(void **p_image, size_t *p_size);
>> #endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
>>
>> +#ifdef CONFIG_FIT_IMAGE_TEE_PROCESS
>
> I don't think you should have this #ifdef in the header file.
>
Then board_tee_image_process would always have a deceleration, even on
boards without a definition of it.
>> +/**
>> + * board_fit_tee_process() - Do any needed processing on a loaded TEE image
>> + *
>> + * This is used to verify, decrypt, and/or install a TEE in a platform or
>> + * board specific way.
>
> nit: board-specific
>
>
>> + *
>> + * @tee_image: pointer to the image
>
> What format is the image?
>
Platform specific. Different TEEs have different header types and our
platforms require different signing headers.
>> + * @tee_size: the image size
>> + * @return no return value (failure should be handled internally)
>> + */
>> +void board_tee_image_process(void *tee_image, size_t tee_size);
>
> I think it's a good idea to return an error code here, since the
> function may fail.
>
>> +#endif /* CONFIG_FIT_IMAGE_TEE_PROCESS */
>> +
>> #endif /* __IMAGE_H__ */
>> --
>> 2.10.1
>>
>
> Regards,
> SImon
>
^ permalink raw reply
* [PATCH] ti-ipc: update to include -pthread fixes
From: Denys Dmytriyenko @ 2016-11-14 21:55 UTC (permalink / raw)
To: meta-ti
From: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
recipes-ti/ipc/ti-ipc.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-ti/ipc/ti-ipc.inc b/recipes-ti/ipc/ti-ipc.inc
index 869dada..488e0fc 100644
--- a/recipes-ti/ipc/ti-ipc.inc
+++ b/recipes-ti/ipc/ti-ipc.inc
@@ -9,7 +9,7 @@ TI_IPC_GIT_PROTOCOL = "git"
TI_IPC_GIT_BRANCH = "ipc-next"
#Corresponds to 3.44.00.00
-TI_IPC_SRCREV = "e6f64d4b04f1c929366c922a2e5a4728fbb4d919"
+TI_IPC_SRCREV = "a1852fc8b254ed207bd1c1c88f5b362c9b6cc454"
BRANCH = "${TI_IPC_GIT_BRANCH}"
SRC_URI = "${TI_IPC_GIT_URI};protocol=${TI_IPC_GIT_PROTOCOL};branch=${BRANCH};name=ipcdev"
@@ -17,7 +17,7 @@ SRCREV = "${TI_IPC_SRCREV}"
S = "${WORKDIR}/git"
PV = "3.44.00.00"
-INC_PR = "r0"
+INC_PR = "r1"
PACKAGE_ARCH = "${MACHINE_ARCH}"
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/3] boot/uboot: bump to version 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:55 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479144385-27214-1-git-send-email-festevam@gmail.com>
Hello,
On Mon, 14 Nov 2016 15:26:23 -0200, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
> boot/uboot/Config.in | 4 ++--
> boot/uboot/uboot.hash | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
All three applied to next. Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [autobuild.buildroot.net] Build results for 2016-11-13
From: Thomas Petazzoni @ 2016-11-14 21:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479160383.4567.1.camel@embedded.rocks>
Hello,
On Mon, 14 Nov 2016 22:53:03 +0100, J?rg Krause wrote:
> > ?????????arm |???????????????????tremor-19427 | NOK |
> > http://autobuild.buildroot.net/results/054f1c77b0e5d46b2dc53769469c0e
> > d03e6b79ef
>
> The ARM Cortex-M4 toolchain supports *only* Thumb-2 instructions,
> whereas tremor has ARM assembly code and therefore cannot be build with
> this toolchain.
>
> I would just exclude the relevant CPU ARMv7-M (BR2_ARM_CPU_ARMV7M) for
> simplicity, right?
Or, better, make tremor not use ARM-only instructions, by disabling the
optimized code. The benefit of this approach is that you don't have to
propagate the !BR2_ARM_CPU_ARMV7M dependency to the reverse
dependencies of tremor.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* qed, qedi patchset submission
From: Arun Easi @ 2016-11-14 21:53 UTC (permalink / raw)
To: Martin K. Petersen, David Miller, linux-scsi, netdev
Hi Martin, David,
This is regarding the submission of the recent patch series we have posted
to linux-scsi and netdev:
[PATCH v2 0/6] Add QLogic FastLinQ iSCSI (qedi) driver.
[PATCH v2 1/6] qed: Add support for hardware offloaded iSCSI.
[PATCH v2 2/6] qed: Add iSCSI out of order packet handling.
[PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
[PATCH v2 4/6] qedi: Add LL2 iSCSI interface for offload iSCSI.
[PATCH v2 5/6] qedi: Add support for iSCSI session management.
[PATCH v2 6/6] qedi: Add support for data path.
Patches 1 & 2 are "qed" module patches that goes under
drivers/net/ethernet/qlogic/qed/ and include/linux/qed/ directory.
- These are the iSCSI enablement changes to the common "qed"
module. There is no dependency for these patches and so
can go independently.
Patches 3, 4, 5 & 6 are the qedi patches that is aimed towards
drivers/scsi/qedi/ directory.
- These are the core qedi changes and is dependent on the
qed changes (invokes qed_XXX functions).
As qed sits in the net tree, the patches are usually submitted via netdev.
Do you have any preference or thoughts on how the "qed" patches be
approached? Just as a reference, our rdma driver "qedr" went through
something similar[1], and eventually "qed" patches were taken by David
in the net tree and "qedr", in the rdma tree (obviously) by Doug L.
Hi David,
For the "qed" enablement sent with the v2 series, we did not prefix the
qed patches with "[PATCH net-next]" prefix, so netdev folks may have
failed to notice/review that, sorry about that. We will send the next (v3)
series with that corrected.
Right now, we are basing the "qed" patches on top of latest net + net-next
tree. FYI, I tried a test merge of net-next/master + qed patches with
"net/master" and I see no conflict in qed.
Regards,
-Arun
[1] http://marc.info/?l=linux-rdma&m=147509152719831&w=2
^ permalink raw reply
* [Buildroot] [git commit] package/gcc: backport xtensa trap pattern for 5.x
From: Thomas Petazzoni @ 2016-11-14 21:53 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=d3f0d52144f27097bba225bdb2a3b1620d44ab5a
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
gcc 5.x uses trap pattern extensively to mark locations where program
execution should never get. Default pattern implementation emits a call
to 'abort' function. This function however is not always available, e.g.
it's not available for the libc dynamic linker. Backport implementation
of the trap pattern for xtensa that does not result in a call to
'abort'.
Fixes:
http://autobuild.buildroot.net/results/0fbcc4475545904bf88f25a3bdf3ee552bf4960e
http://autobuild.buildroot.net/results/cb7f5bdfac615d774f3bcd1b802f8d74460bc557
http://autobuild.buildroot.net/results/cf3dc9ae4f74ff28b285f1a862b71d96384d7651
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../5.4.0/875-xtensa-implement-trap-pattern.patch | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch b/package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch
new file mode 100644
index 0000000..870b079
--- /dev/null
+++ b/package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch
@@ -0,0 +1,67 @@
+From 2b4b5775554c91a63ccae4ee566db696b633652e Mon Sep 17 00:00:00 2001
+From: jcmvbkbc <jcmvbkbc@138bc75d-0d04-0410-961f-82ee72b054a4>
+Date: Wed, 10 Jun 2015 15:07:40 +0000
+Subject: [PATCH] xtensa: implement trap pattern
+
+2015-06-10 Max Filippov <jcmvbkbc@gmail.com>
+gcc/
+ * config/xtensa/xtensa.h (TARGET_DEBUG): New definition.
+ * config/xtensa/xtensa.md (define_attr "type"): New type "trap".
+ (define_insn "trap"): New definition.
+
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk at 224330 138bc75d-0d04-0410-961f-82ee72b054a4
+---
+ gcc/config/xtensa/xtensa.h | 1 +
+ gcc/config/xtensa/xtensa.md | 15 ++++++++++++++-
+ 2 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
+index 615f741..fb8702c 100644
+--- a/gcc/config/xtensa/xtensa.h
++++ b/gcc/config/xtensa/xtensa.h
+@@ -67,6 +67,7 @@ extern unsigned xtensa_current_frame_size;
+ #define TARGET_THREADPTR XCHAL_HAVE_THREADPTR
+ #define TARGET_LOOPS XCHAL_HAVE_LOOPS
+ #define TARGET_WINDOWED_ABI (XSHAL_ABI == XTHAL_ABI_WINDOWED)
++#define TARGET_DEBUG XCHAL_HAVE_DEBUG
+
+ #define TARGET_DEFAULT \
+ ((XCHAL_HAVE_L32R ? 0 : MASK_CONST16) | \
+diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
+index 6d84384..a577aa3 100644
+--- a/gcc/config/xtensa/xtensa.md
++++ b/gcc/config/xtensa/xtensa.md
+@@ -86,7 +86,7 @@
+ ;; Attributes.
+
+ (define_attr "type"
+- "unknown,jump,call,load,store,move,arith,multi,nop,farith,fmadd,fconv,fload,fstore,mul16,mul32,div32,mac16,rsr,wsr,entry"
++ "unknown,jump,call,load,store,move,arith,multi,nop,farith,fmadd,fconv,fload,fstore,mul16,mul32,div32,mac16,rsr,wsr,entry,trap"
+ (const_string "unknown"))
+
+ (define_attr "mode"
+@@ -1764,6 +1764,19 @@
+ [(set_attr "length" "0")
+ (set_attr "type" "nop")])
+
++(define_insn "trap"
++ [(trap_if (const_int 1) (const_int 0))]
++ ""
++{
++ if (TARGET_DEBUG)
++ return "break\t1, 15";
++ else
++ return (TARGET_DENSITY ? "ill.n" : "ill");
++}
++ [(set_attr "type" "trap")
++ (set_attr "mode" "none")
++ (set_attr "length" "3")])
++
+ ;; Setting up a frame pointer is tricky for Xtensa because GCC doesn't
+ ;; know if a frame pointer is required until the reload pass, and
+ ;; because there may be an incoming argument value in the hard frame
+--
+2.1.4
+
^ permalink raw reply related
* [Buildroot] [autobuild.buildroot.net] Build results for 2016-11-13
From: Jörg Krause @ 2016-11-14 21:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114073015.24C9A20BE0@mail.free-electrons.com>
On Mon, 2016-11-14 at 08:30 +0100, Thomas Petazzoni wrote:
> Hello,
>
> Build statistics for 2016-11-13
> ================================
>
> ??????successes : 220
> ???????failures : 52?
> ???????timeouts : 0??
> ??????????TOTAL : 272
>
[snip]
> ?????????arm |???????????????????tremor-19427 | NOK |
> http://autobuild.buildroot.net/results/054f1c77b0e5d46b2dc53769469c0e
> d03e6b79ef
The ARM Cortex-M4 toolchain supports *only* Thumb-2 instructions,
whereas tremor has ARM assembly code and therefore cannot be build with
this toolchain.
I would just exclude the relevant CPU ARMv7-M (BR2_ARM_CPU_ARMV7M) for
simplicity, right?
Best regards,
J?rg Krause
^ permalink raw reply
* Re: [PATCH v2 04/12] PCI: iproc: Fix exception with multi-function devices
From: Bjorn Helgaas @ 2016-11-14 21:52 UTC (permalink / raw)
To: Ray Jui
Cc: Bjorn Helgaas, linux-kernel, bcm-kernel-feedback-list, linux-pci,
Alex Barba, Oza Oza
In-Reply-To: <1477960721-17649-5-git-send-email-ray.jui@broadcom.com>
On Mon, Oct 31, 2016 at 05:38:33PM -0700, Ray Jui wrote:
> During enumeration with multi-function EP devices, access to the
> configuration space of a non-exist function results in an unsupported
> request being returned as expected. By default the PAXB based iProc
> PCIe controller forwards this as an APB error to the host system and
> that causes an exception, which is undesired
>
> This patch disables this undesired behaviour and lets the kernel PCI
> stack deals with an access to the non-exist function, in which case
> a vendor ID of 0xffff is returned and handled gracefully
>
> Reported-by: JD Zheng <jiandong.zheng@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: JD Zheng <jiandong.zheng@broadcom.com>
> Reviewed-by: Oza Oza <oza.oza@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> ---
> drivers/pci/host/pcie-iproc.c | 58 +++++++++++++++++++++++++++++++++++++++++--
> drivers/pci/host/pcie-iproc.h | 3 +++
> 2 files changed, 59 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index f3b3340..07ec478 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -58,6 +58,9 @@
> #define PCIE_DL_ACTIVE_SHIFT 2
> #define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)
>
> +#define APB_ERR_EN_SHIFT 0
> +#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
> +
> #define OARR_VALID_SHIFT 0
> #define OARR_VALID BIT(OARR_VALID_SHIFT)
> #define OARR_SIZE_CFG_SHIFT 1
> @@ -96,6 +99,9 @@ enum iproc_pcie_reg {
> /* link status */
> IPROC_PCIE_LINK_STATUS,
>
> + /* enable APB error for unsupported requests */
> + IPROC_PCIE_APB_ERR_EN,
> +
> /* total number of core registers */
> IPROC_PCIE_MAX_NUM_REG,
> };
> @@ -124,6 +130,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
> [IPROC_PCIE_OMAP_LO] = 0xd40,
> [IPROC_PCIE_OMAP_HI] = 0xd44,
> [IPROC_PCIE_LINK_STATUS] = 0xf0c,
> + [IPROC_PCIE_APB_ERR_EN] = 0xf40,
> };
>
> /* iProc PCIe PAXC v1 registers */
> @@ -181,6 +188,28 @@ static inline void iproc_pcie_write_reg(struct iproc_pcie *pcie,
> writel(val, pcie->base + offset);
> }
>
> +/**
> + * APB error forwarding can be disabled during access of configuration
> + * registers of the endpoint device, to prevent unsupported requests
> + * (typically seen during enumeration with multi-function devices) from
> + * triggering a system exception
> + */
> +static inline void iproc_pcie_apb_err_disable(struct pci_bus *bus,
> + bool disable)
> +{
> + struct iproc_pcie *pcie = iproc_data(bus);
> + u32 val;
> +
> + if (bus->number && pcie->has_apb_err_disable) {
> + val = iproc_pcie_read_reg(pcie, IPROC_PCIE_APB_ERR_EN);
> + if (disable)
> + val &= ~APB_ERR_EN;
> + else
> + val |= APB_ERR_EN;
> + iproc_pcie_write_reg(pcie, IPROC_PCIE_APB_ERR_EN, val);
> + }
> +}
> +
> static inline void iproc_pcie_ob_write(struct iproc_pcie *pcie,
> enum iproc_pcie_reg reg,
> unsigned window, u32 val)
> @@ -244,10 +273,34 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct pci_bus *bus,
> return (pcie->base + offset);
> }
>
> +static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> + int where, int size, u32 *val)
> +{
> + int ret;
> +
> + iproc_pcie_apb_err_disable(bus, true);
> + ret = pci_generic_config_read32(bus, devfn, where, size, val);
> + iproc_pcie_apb_err_disable(bus, false);
I guess this means that any other APB errors (unrelated to this config
access, e.g., a driver doing MMIo to a device at the same time the user is
doing "lspci") that happen to occur during this window will also be
ignored.
> +
> + return ret;
> +}
> +
> +static int iproc_pcie_config_write32(struct pci_bus *bus, unsigned int devfn,
> + int where, int size, u32 val)
> +{
> + int ret;
> +
> + iproc_pcie_apb_err_disable(bus, true);
> + ret = pci_generic_config_write32(bus, devfn, where, size, val);
> + iproc_pcie_apb_err_disable(bus, false);
> +
> + return ret;
> +}
> +
> static struct pci_ops iproc_pcie_ops = {
> .map_bus = iproc_pcie_map_cfg_bus,
> - .read = pci_generic_config_read32,
> - .write = pci_generic_config_write32,
> + .read = iproc_pcie_config_read32,
> + .write = iproc_pcie_config_write32,
> };
>
> static void iproc_pcie_reset(struct iproc_pcie *pcie)
> @@ -485,6 +538,7 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
> break;
> case IPROC_PCIE_PAXB:
> regs = iproc_pcie_reg_paxb;
> + pcie->has_apb_err_disable = true;
> break;
> case IPROC_PCIE_PAXC:
> regs = iproc_pcie_reg_paxc;
> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
> index 768be05..711dd3a 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -57,6 +57,8 @@ struct iproc_msi;
> * @phy: optional PHY device that controls the Serdes
> * @map_irq: function callback to map interrupts
> * @ep_is_internal: indicates an internal emulated endpoint device is connected
> + * @has_apb_err_disable: indicates the controller can be configured to prevent
> + * unsupported request from being forwarded as an APB bus error
> * @need_ob_cfg: indicates SW needs to configure the outbound mapping window
> * @ob: outbound mapping parameters
> * @msi: MSI data
> @@ -74,6 +76,7 @@ struct iproc_pcie {
> struct phy *phy;
> int (*map_irq)(const struct pci_dev *, u8, u8);
> bool ep_is_internal;
> + bool has_apb_err_disable;
> bool need_ob_cfg;
> struct iproc_pcie_ob ob;
> struct iproc_msi *msi;
> --
> 2.1.4
>
^ permalink raw reply
* [Buildroot] [git commit branch/next] configs/warp7: Bump to U-Boot 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:52 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=87f1bdda38b43192908dab585dc6b4fc3e39ffe5
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
configs/warp7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index a55a504..fca7a1d 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -25,7 +25,7 @@ BR2_LINUX_KERNEL_INTREE_DTS_NAME="imx7s-warp"
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BOARDNAME="warp7_secure"
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.09.01"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.11"
BR2_TARGET_UBOOT_FORMAT_IMX=y
# wifi firmware for brcm43430
^ permalink raw reply related
* [Buildroot] [git commit branch/next] uboot-tools: bump to version 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:52 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=99fd3bae35f9971544990c1869933b8ae22832ec
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/uboot-tools/uboot-tools.hash | 2 +-
package/uboot-tools/uboot-tools.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/uboot-tools/uboot-tools.hash b/package/uboot-tools/uboot-tools.hash
index db60dab..5b2c3bf 100644
--- a/package/uboot-tools/uboot-tools.hash
+++ b/package/uboot-tools/uboot-tools.hash
@@ -1,2 +1,2 @@
# Locally computed:
-sha256 95728e89dd476d17428f94080752ab48884be477b6a678941582aeef618b70bb u-boot-2016.09.01.tar.bz2
+sha256 45813e6565dcc0436abe6752624324cdbf5f3ac106570d76d32b46ec529bcdc8 u-boot-2016.11.tar.bz2
diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
index a3335a5..bb0cba8 100644
--- a/package/uboot-tools/uboot-tools.mk
+++ b/package/uboot-tools/uboot-tools.mk
@@ -4,7 +4,7 @@
#
################################################################################
-UBOOT_TOOLS_VERSION = 2016.09.01
+UBOOT_TOOLS_VERSION = 2016.11
UBOOT_TOOLS_SOURCE = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2
UBOOT_TOOLS_SITE = ftp://ftp.denx.de/pub/u-boot
UBOOT_TOOLS_LICENSE = GPLv2+
^ permalink raw reply related
* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Julia Lawall @ 2016-11-14 21:52 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <20161114214037.GE9868@bhelgaas-glaptop.roam.corp.google.com>
On Mon, 14 Nov 2016, Bjorn Helgaas wrote:
> On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> > source code, improves readbility, and reduces the chance of
> > inconsistencies.
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @rw@
> > declarer name DEVICE_ATTR;
> > identifier x,x_show,x_store;
> > @@
> >
> > DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> >
> > @script:ocaml@
> > x << rw.x;
> > x_show << rw.x_show;
> > x_store << rw.x_store;
> > @@
> >
> > if not (x^"_show" = x_show && x^"_store" = x_store)
> > then Coccilib.include_match false
> >
> > @@
> > declarer name DEVICE_ATTR_RW;
> > identifier rw.x,rw.x_show,rw.x_store;
> > @@
> >
> > - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> > + DEVICE_ATTR_RW(x);
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> I applied this to pci/aspm to follow the herd, although it looks
> pretty similar to the ill-fated "Replace numeric parameter like 0444
> with macro" series (http://lwn.net/Articles/696229/). Maybe this is
> different because everybody except me knows what ATTR_RW means? To
> me, "0644" contained more information than "_RW" does.
>
> I do certainly like the removal of the "_show" and "_store"
> redundancy.
I think that the point is the latter. There were also a couple of cases
where the permissions didn't match with the set of provided functions.
julia
>
> > ---
> > drivers/pci/pcie/aspm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 0ec649d..3b14d9e 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> > return n;
> > }
> >
> > -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> > -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> > +static DEVICE_ATTR_RW(link_state);
> > +static DEVICE_ATTR_RW(clk_ctl);
> >
> > static char power_group[] = "power";
> > void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
> >
>
^ permalink raw reply
* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Julia Lawall @ 2016-11-14 21:52 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <20161114214037.GE9868@bhelgaas-glaptop.roam.corp.google.com>
On Mon, 14 Nov 2016, Bjorn Helgaas wrote:
> On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> > source code, improves readbility, and reduces the chance of
> > inconsistencies.
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @rw@
> > declarer name DEVICE_ATTR;
> > identifier x,x_show,x_store;
> > @@
> >
> > DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> >
> > @script:ocaml@
> > x << rw.x;
> > x_show << rw.x_show;
> > x_store << rw.x_store;
> > @@
> >
> > if not (x^"_show" = x_show && x^"_store" = x_store)
> > then Coccilib.include_match false
> >
> > @@
> > declarer name DEVICE_ATTR_RW;
> > identifier rw.x,rw.x_show,rw.x_store;
> > @@
> >
> > - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> > + DEVICE_ATTR_RW(x);
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> I applied this to pci/aspm to follow the herd, although it looks
> pretty similar to the ill-fated "Replace numeric parameter like 0444
> with macro" series (http://lwn.net/Articles/696229/). Maybe this is
> different because everybody except me knows what ATTR_RW means? To
> me, "0644" contained more information than "_RW" does.
>
> I do certainly like the removal of the "_show" and "_store"
> redundancy.
I think that the point is the latter. There were also a couple of cases
where the permissions didn't match with the set of provided functions.
julia
>
> > ---
> > drivers/pci/pcie/aspm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 0ec649d..3b14d9e 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> > return n;
> > }
> >
> > -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> > -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> > +static DEVICE_ATTR_RW(link_state);
> > +static DEVICE_ATTR_RW(clk_ctl);
> >
> > static char power_group[] = "power";
> > void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
> >
>
^ permalink raw reply
* [Buildroot] [git commit branch/next] boot/uboot: bump to version 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:52 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=ce7b0b8dfba9832169d80916b9adf83ef27dbb04
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
boot/uboot/Config.in | 4 ++--
boot/uboot/uboot.hash | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index fabf27d..3b4bfac 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -38,7 +38,7 @@ choice
Select the specific U-Boot version you want to use
config BR2_TARGET_UBOOT_LATEST_VERSION
- bool "2016.09.01"
+ bool "2016.11"
config BR2_TARGET_UBOOT_CUSTOM_VERSION
bool "Custom version"
@@ -86,7 +86,7 @@ endif
config BR2_TARGET_UBOOT_VERSION
string
- default "2016.09.01" if BR2_TARGET_UBOOT_LATEST_VERSION
+ default "2016.11" if BR2_TARGET_UBOOT_LATEST_VERSION
default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE \
if BR2_TARGET_UBOOT_CUSTOM_VERSION
default "custom" if BR2_TARGET_UBOOT_CUSTOM_TARBALL
diff --git a/boot/uboot/uboot.hash b/boot/uboot/uboot.hash
index db60dab..5b2c3bf 100644
--- a/boot/uboot/uboot.hash
+++ b/boot/uboot/uboot.hash
@@ -1,2 +1,2 @@
# Locally computed:
-sha256 95728e89dd476d17428f94080752ab48884be477b6a678941582aeef618b70bb u-boot-2016.09.01.tar.bz2
+sha256 45813e6565dcc0436abe6752624324cdbf5f3ac106570d76d32b46ec529bcdc8 u-boot-2016.11.tar.bz2
^ permalink raw reply related
* [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math
From: Dhinakaran Pandiyan @ 2016-11-14 21:50 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
In-Reply-To: <1479159735-29364-1-git-send-email-dhinakaran.pandiyan@intel.com>
We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.
E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.
But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps
v2: Changed to DIV_ROUND_UP() and comment changes (Ville)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
Fixed a typo that snuck in.
drivers/gpu/drm/i915/intel_dp.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..bdef314 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-/*
- * The units on the numbers in the next two are... bizarre. Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 270000 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits. ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000. At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
static int
intel_dp_link_required(int pixel_clock, int bpp)
{
- return (pixel_clock * bpp + 9) / 10;
+ /* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+ return DIV_ROUND_UP(pixel_clock * bpp, 8);
}
static int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
- return (max_link_clock * max_lanes * 8) / 10;
+ /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+ * link rate that is generally expressed in Gbps. Since, 8 bits of data
+ * is transmitted every LS_Clk per lane, there is no need to account for
+ * the channel encoding that is done in the PHY layer here.
+ */
+
+ return max_link_clock * max_lanes;
}
static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (val == 0)
break;
- /* Value read is in kHz while drm clock is saved in deca-kHz */
+ /* Value read multiplied by 200kHz gives the per-lane
+ * link rate in kHz. The source rates are, however,
+ * stored in terms of LS_Clk kHz. The full conversion
+ * back to symbols is
+ * (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+ */
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* perf: fuzzer KASAN slab-out-of-bounds in snb_uncore_imc_event_del
From: Vince Weaver @ 2016-11-14 21:49 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo, davej,
dvyukov, Stephane Eranian
After turning modversions off I finally managed to get a 4.9-rc kernel to
boot.
Anyway as per the suggestion at Linux Plumbers I enabled KASAN and on my
haswell machine it falls over in a few minutes of running the perf_fuzzer.
[ 205.740194] ==================================================================
[ 205.748005] BUG: KASAN: slab-out-of-bounds in snb_uncore_imc_event_del+0x6c/0xa0 at addr ffff8800caa43768
[ 205.758324] Read of size 8 by task perf_fuzzer/6618
[ 205.763589] CPU: 0 PID: 6618 Comm: perf_fuzzer Not tainted 4.9.0-rc5 #4
[ 205.770721] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014
[ 205.778689] ffff8800c3c479b8 ffffffff816bb796 ffff88011ec00600 ffff8800caa43580
[ 205.786759] ffff8800c3c479e0 ffffffff812fb961 ffff8800c3c47a78 ffff8800caa43580
[ 205.794850] ffff8800caa43580 ffff8800c3c47a68 ffffffff812fbbd8 ffff8800c3c47a28
[ 205.802911] Call Trace:
[ 205.805559] [<ffffffff816bb796>] dump_stack+0x63/0x8d
[ 205.811135] [<ffffffff812fb961>] kasan_object_err+0x21/0x70
[ 205.817267] [<ffffffff812fbbd8>] kasan_report_error+0x1d8/0x4c0
[ 205.823752] [<ffffffff81133275>] ? __lock_is_held+0x75/0xc0
[ 205.829868] [<ffffffff81025b12>] ? snb_uncore_imc_read_counter+0x42/0x50
[ 205.837198] [<ffffffff810222e2>] ? uncore_perf_event_update+0xe2/0x160
[ 205.844337] [<ffffffff812fc319>] kasan_report+0x39/0x40
[ 205.850085] [<ffffffff81025e3c>] ? snb_uncore_imc_event_del+0x6c/0xa0
[ 205.857114] [<ffffffff812fa8fe>] __asan_load8+0x5e/0x70
[ 205.862874] [<ffffffff81025e3c>] snb_uncore_imc_event_del+0x6c/0xa0
[ 205.869727] [<ffffffff81241bd2>] event_sched_out.isra.89+0x192/0x690
[ 205.876664] [<ffffffff81242167>] group_sched_out+0x97/0x170
[ 205.882760] [<ffffffff81242810>] __perf_event_disable+0x140/0x1b0
[ 205.889395] [<ffffffff812384e7>] event_function+0x117/0x1f0
[ 205.895503] [<ffffffff812426d0>] ? task_ctx_sched_out+0x60/0x60
[ 205.901959] [<ffffffff812383d0>] ? update_group_times+0x50/0x50
[ 205.908425] [<ffffffff8123b020>] ? perf_cgroup_attach+0xb0/0xb0
[ 205.914937] [<ffffffff8123b096>] remote_function+0x76/0xa0
[ 205.920955] [<ffffffff8118da7c>] generic_exec_single+0xfc/0x170
[ 205.927434] [<ffffffff8123b020>] ? perf_cgroup_attach+0xb0/0xb0
[ 205.933883] [<ffffffff8118dc30>] smp_call_function_single+0x140/0x1b0
[ 205.940967] [<ffffffff8118daf0>] ? generic_exec_single+0x170/0x170
[ 205.947776] [<ffffffff81238e48>] event_function_call+0x268/0x270
[ 205.954336] [<ffffffff812426d0>] ? task_ctx_sched_out+0x60/0x60
[ 205.960806] [<ffffffff81238be0>] ? task_function_call+0xc0/0xc0
[ 205.967276] [<ffffffff812426d0>] ? task_ctx_sched_out+0x60/0x60
[ 205.973740] [<ffffffff81238e79>] ? _perf_event_disable+0x29/0x70
[ 205.980300] [<ffffffff812383d0>] ? update_group_times+0x50/0x50
[ 205.986750] [<ffffffff81238e97>] ? _perf_event_disable+0x47/0x70
[ 205.993338] [<ffffffff8113a4d7>] ? do_raw_spin_unlock+0x97/0x130
[ 205.999906] [<ffffffff81238e50>] ? event_function_call+0x270/0x270
[ 206.006674] [<ffffffff81238ea8>] _perf_event_disable+0x58/0x70
[ 206.013069] [<ffffffff812386a3>] perf_event_for_each_child+0x53/0xd0
[ 206.019990] [<ffffffff81247a51>] perf_event_task_disable+0x61/0xc0
[ 206.026759] [<ffffffff810daee2>] SyS_prctl+0x3f2/0x690
[ 206.032409] [<ffffffff810daaf0>] ? SyS_umask+0x40/0x40
[ 206.038059] [<ffffffff81b8dabb>] entry_SYSCALL_64_fastpath+0x1e/0xb2
[ 206.045007] Object at ffff8800caa43580, in cache kmalloc-512 size: 512
[ 206.052015] Allocated:
[ 206.054565] PID = 1
[ 206.056842] [ 206.058367] [<ffffffff8105fcdb>] save_stack_trace+0x1b/0x20
[ 206.064410] [ 206.065933] [<ffffffff812facc6>] save_stack+0x46/0xd0
[ 206.071416] [ 206.072953] [<ffffffff812faf3d>] kasan_kmalloc+0xad/0xe0
[ 206.078683] [ 206.080214] [<ffffffff812f7e3a>] __kmalloc_node+0x4a/0x60
[ 206.086061] [ 206.087590] [<ffffffff81020799>] uncore_alloc_box+0x39/0x150
[ 206.093685] [ 206.095208] [<ffffffff81020b8f>] uncore_pci_probe+0xff/0x4f0
[ 206.101357] [ 206.102879] [<ffffffff8172bc7a>] local_pci_probe+0x7a/0xd0
[ 206.108816] [ 206.110347] [<ffffffff8172df6e>] pci_device_probe+0x19e/0x1f0
[ 206.116553] [ 206.118073] [<ffffffff818a9a1d>] driver_probe_device+0x25d/0x400
[ 206.124566] [ 206.126087] [<ffffffff818a9c9c>] __driver_attach+0xdc/0xe0
[ 206.132021] [ 206.133534] [<ffffffff818a653b>] bus_for_each_dev+0xeb/0x150
[ 206.139654] [ 206.141184] [<ffffffff818a8f2b>] driver_attach+0x2b/0x30
[ 206.146948] [ 206.148493] [<ffffffff818a8900>] bus_add_driver+0x2b0/0x330
[ 206.154519] [ 206.156042] [<ffffffff818aa9f3>] driver_register+0xd3/0x190
[ 206.164160] [ 206.165688] [<ffffffff8172b2b4>] __pci_register_driver+0xb4/0xc0
[ 206.174265] [ 206.175783] [<ffffffff8261553b>] intel_uncore_init+0x2f3/0x388
[ 206.184162] [ 206.185672] [<ffffffff81002258>] do_one_initcall+0xa8/0x210
[ 206.193721] [ 206.195261] [<ffffffff8260e4c2>] kernel_init_freeable+0x27c/0x312
[ 206.203821] [ 206.205349] [<ffffffff81b80b13>] kernel_init+0x13/0x120
[ 206.212889] [ 206.214439] [<ffffffff81b8dd35>] ret_from_fork+0x25/0x30
[ 206.222067] Freed:
[ 206.226172] PID = 0
[ 206.230341] (stack is not available)
[ 206.236044] Memory state around the buggy address:
[ 206.243157] ffff8800caa43600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 206.252788] ffff8800caa43680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 206.262437] >ffff8800caa43700: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
[ 206.272071] ^
[ 206.281005] ffff8800caa43780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 206.290640] ffff8800caa43800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 206.300302]
==================================================================
^ permalink raw reply
* Re: [dm-crypt] License Clarification
From: Nathaniel McCallum @ 2016-11-14 21:47 UTC (permalink / raw)
To: Milan Broz; +Cc: dm-crypt, Sorce, Simo
In-Reply-To: <5f467a08-bb2f-7919-cd91-45933ec47f00@gmail.com>
Thanks for the response. My particular concern is the ability to link
to both libcryptsetup and openssl higher up in the stack.
On Mon, Nov 14, 2016 at 3:22 PM, Milan Broz <gmazyland@gmail.com> wrote:
> The original intention is documented here
> http://www.saout.de/pipermail/dm-crypt/2012-December/002992.html
>
> Anyway, I have contacted lawyers to check it and for possible
> guidance if a fix is needed.
>
> Thanks,
> Milan
>
> On 11/10/2016 08:41 PM, Nathaniel McCallum wrote:
>> In reviewing the license choices of a set of my projects, I have
>> noticed an inconsistency in licensing and I would like to receive some
>> clarification.
>>
>> There is a commit that changes some of the code to LGPLv2.1+:
>> https://gitlab.com/cryptsetup/cryptsetup/commit/7eccb7ff5031a4f42f1ae8f7ffaefe80ba0d53dd
>>
>> However, the main header still reads GPLv2+:
>> https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/libcryptsetup.h
>>
>> Further, the API examples have LGPLv2.1+:
>> https://gitlab.com/cryptsetup/cryptsetup/wikis/API/index.html
>>
>> Again, the openssl crypto backend are licensed as LGPLv2.1+ w/ openssl
>> exception. However, this exception doesn't seem to apply to the whole
>> library:
>> https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/crypto_backend/crypto_openssl.c
>>
>> In short, it is very unclear to me how this licensing is supposed to work.
>>
>> The best I can ascertain is this:
>>
>> crypto-backend (LGPLv2+) ==> libcryptsetup (GPLv2+) ==> API examples (LGPLv2+)
>>
>> It would, thus, seem to me that the API examples are incompatibly
>> licensed and cannot actually link against libcryptsetup.
>>
>> Further, it seems to me that the crypto-backend can link against
>> openssl, but not libcryptsetup itself. This further implies that
>> consumers of libcryptsetup cannot link against openssl.
>>
>> Have I understood this correctly?
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
^ permalink raw reply
* Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred
From: Stratos Karafotis @ 2016-11-14 21:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Viresh Kumar, linux-pm@vger.kernel.org, LKML
In-Reply-To: <CAJZ5v0hREE4Q72XXqJS5ub+GEqw8=R111Svd2Z+A9pKuE3btcQ@mail.gmail.com>
On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
> On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis
> <stratosk@semaphore.gr> wrote:
>> Conservative governor changes the CPU frequency in steps.
>> That means that if a CPU runs at max frequency, it will need several
>> sampling periods to return to min frequency when the workload
>> is finished.
>>
>> If the update function that calculates the load and target frequency
>> is deferred, the governor might need even more time to decrease the
>> frequency.
>>
>> This may have impact to power consumption and after all conservative
>> should decrease the frequency if there is no workload at every sampling
>> rate.
>>
>> To resolve the above issue calculate the number of sampling periods
>> that the update is deferred. Considering that for each sampling period
>> conservative should drop the frequency by a freq_step because the
>> CPU was idle apply the proper subtraction to requested frequency.
>>
>> Below, the kernel trace with and without this patch. First an
>> intensive workload is applied on a specific CPU. Then the workload
>> is removed and the CPU goes to idle.
>>
>> WITHOUT
>>
>> <idle>-0 [007] dN.. 620.329153: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 620.350857: cpu_frequency: state=1700000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.370856: cpu_frequency: state=1900000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.390854: cpu_frequency: state=2100000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.411853: cpu_frequency: state=2200000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.432854: cpu_frequency: state=2400000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.453854: cpu_frequency: state=2600000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.494856: cpu_frequency: state=2900000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.515856: cpu_frequency: state=3100000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.536858: cpu_frequency: state=3300000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.557857: cpu_frequency: state=3401000 cpu_id=7
>> <idle>-0 [007] d... 669.591363: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 669.591939: cpu_idle: state=4294967295 cpu_id=7
>> <idle>-0 [007] d... 669.591980: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] dN.. 669.591989: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 670.201224: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 670.221975: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 670.222016: cpu_frequency: state=3300000 cpu_id=7
>> <idle>-0 [007] d... 670.222026: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 670.234964: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 670.801251: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.236046: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 671.236073: cpu_frequency: state=3100000 cpu_id=7
>> <idle>-0 [007] d... 671.236112: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.393437: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 671.401277: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.404083: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 671.404111: cpu_frequency: state=2900000 cpu_id=7
>> <idle>-0 [007] d... 671.404125: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.404974: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 671.501180: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.995414: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 671.995459: cpu_frequency: state=2800000 cpu_id=7
>> <idle>-0 [007] d... 671.995469: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.996287: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.001305: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.078374: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.078410: cpu_frequency: state=2600000 cpu_id=7
>> <idle>-0 [007] d... 672.078419: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.158020: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.158040: cpu_frequency: state=2400000 cpu_id=7
>> <idle>-0 [007] d... 672.158044: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.160038: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.234557: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.237121: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.237174: cpu_frequency: state=2100000 cpu_id=7
>> <idle>-0 [007] d... 672.237186: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.237778: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.267902: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.269860: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.269906: cpu_frequency: state=1900000 cpu_id=7
>> <idle>-0 [007] d... 672.269914: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.271902: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.751342: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.823056: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.823095: cpu_frequency: state=1600000 cpu_id=7
>>
>> WITH
>>
>> <idle>-0 [007] dN.. 4380.928009: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4380.949767: cpu_frequency: state=2000000 cpu_id=7
>> kworker/7:2-399 [007] .... 4380.969765: cpu_frequency: state=2200000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.009766: cpu_frequency: state=2500000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.029767: cpu_frequency: state=2600000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.049769: cpu_frequency: state=2800000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.069769: cpu_frequency: state=3000000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.089771: cpu_frequency: state=3100000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.109772: cpu_frequency: state=3400000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.129773: cpu_frequency: state=3401000 cpu_id=7
>> <idle>-0 [007] d... 4428.226159: cpu_idle: state=1 cpu_id=7
>> <idle>-0 [007] d... 4428.226176: cpu_idle: state=4294967295 cpu_id=7
>> <idle>-0 [007] d... 4428.226181: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.227177: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 4428.551640: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.649239: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4428.649268: cpu_frequency: state=2800000 cpu_id=7
>> <idle>-0 [007] d... 4428.649278: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.689856: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 4428.799542: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.801683: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4428.801748: cpu_frequency: state=1700000 cpu_id=7
>> <idle>-0 [007] d... 4428.801761: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.806545: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 4429.051880: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4429.086240: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4429.086293: cpu_frequency: state=1600000 cpu_id=7
>>
>> Without the patch the CPU dropped to min frequency after 3.2s
>> With the patch applied the CPU dropped to min frequency after 0.86s
>>
>> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
>> ---
>> v1 -> v2
>> - Use correct terminology in change log
>> - Change the member variable name from 'deferred_periods' to 'idle_periods'
>> - Fix format issue
>>
>> drivers/cpufreq/cpufreq_conservative.c | 14 +++++++++++++-
>> drivers/cpufreq/cpufreq_governor.c | 18 +++++++++++++-----
>> drivers/cpufreq/cpufreq_governor.h | 1 +
>> 3 files changed, 27 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
>> index fa5ece3..d787772 100644
>> --- a/drivers/cpufreq/cpufreq_conservative.c
>> +++ b/drivers/cpufreq/cpufreq_conservative.c
>> @@ -73,7 +73,19 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
>> */
>> if (cs_tuners->freq_step == 0)
>> goto out;
>> -
>> + /*
>> + * Decrease requested_freq for each idle period that we didn't
>> + * update the frequency
>> + */
>> + if (policy_dbs->idle_periods < UINT_MAX) {
>> + unsigned int freq_target = policy_dbs->idle_periods *
>> + get_freq_target(cs_tuners, policy);
>> + if (requested_freq > freq_target)
>> + requested_freq -= freq_target;
>> + else
>> + requested_freq = policy->min;
>> + policy_dbs->idle_periods = UINT_MAX;
>> + }
>> /*
>> * If requested_freq is out of range, it is likely that the limits
>> * changed in the meantime, so fall back to current frequency in that
>> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
>> index 3729474..1bc7137 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++ b/drivers/cpufreq/cpufreq_governor.c
>> @@ -117,7 +117,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> struct policy_dbs_info *policy_dbs = policy->governor_data;
>> struct dbs_data *dbs_data = policy_dbs->dbs_data;
>> unsigned int ignore_nice = dbs_data->ignore_nice_load;
>> - unsigned int max_load = 0;
>> + unsigned int max_load = 0, idle_periods = UINT_MAX;
>> unsigned int sampling_rate, io_busy, j;
>>
>> /*
>> @@ -163,8 +163,12 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> * calls, so the previous load value can be used then.
>> */
>> load = j_cdbs->prev_load;
>> - } else if (unlikely(time_elapsed > 2 * sampling_rate &&
>> - j_cdbs->prev_load)) {
>> + } else if (unlikely(time_elapsed > 2 * sampling_rate)) {
>> + unsigned int periods = time_elapsed / sampling_rate;
>> +
>> + if (periods < idle_periods)
>> + idle_periods = periods;
>> +
>> /*
>> * If the CPU had gone completely idle and a task has
>> * just woken up on this CPU now, it would be unfair to
>> @@ -189,8 +193,10 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> * 'time_elapsed' (as compared to the sampling rate)
>> * indicates this scenario.
>> */
>> - load = j_cdbs->prev_load;
>> - j_cdbs->prev_load = 0;
>> + if (j_cdbs->prev_load) {
>> + load = j_cdbs->prev_load;
>> + j_cdbs->prev_load = 0;
>> + }
>> } else {
>> if (time_elapsed >= idle_time) {
>> load = 100 * (time_elapsed - idle_time) / time_elapsed;
>> @@ -218,6 +224,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> if (load > max_load)
>> max_load = load;
>> }
>> + policy_dbs->idle_periods = idle_periods;
>> +
>> return max_load;
>> }
>> EXPORT_SYMBOL_GPL(dbs_update);
>
> I have a murky suspicion that the changes in dbs_update() are going to
> break something. I need to recall what it was, though.
The only change in dbs_update() is the calculation of 'idle_periods'.
If I don't miss something I left current functionality untouched.
But you know better. :)
Please let me know if you want me to proceed with the changes that
Viresh suggested.
Thank you both for your time.
Regards,
Stratos
^ permalink raw reply
* [PATCH] devshell: list commands when throwing NoSupportedTerminals
From: Stephano Cetola @ 2016-11-14 21:45 UTC (permalink / raw)
To: openembedded-core
When attempting to run devshell, if no terminal is available, the
error being thrown was not very specific. This adds a list of
commands that failed, informing the user of what they can install to
fix the error.
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
---
meta/classes/terminal.bbclass | 7 +++++--
meta/lib/oe/terminal.py | 15 ++++++++++++---
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
index a94f755..5cfc7ac 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -88,8 +88,11 @@ def oe_terminal(command, title, d):
try:
oe.terminal.spawn_preferred(command, title, None, d)
- except oe.terminal.NoSupportedTerminals:
- bb.fatal('No valid terminal found, unable to open devshell')
+ except oe.terminal.NoSupportedTerminals as nosup:
+ cmds = '\n\t'.join(nosup.terms).replace("{command}",
+ "do_terminal").replace("{title}", title)
+ bb.fatal('No valid terminal found, unable to open devshell.\n' +
+ 'Tried the following commands:\n\t%s' % cmds)
except oe.terminal.ExecutionError as exc:
bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 7446c44..e772a37 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -11,7 +11,8 @@ class UnsupportedTerminal(Exception):
pass
class NoSupportedTerminals(Exception):
- pass
+ def __init__(self, terms):
+ self.terms = terms
class Registry(oe.classutils.ClassRegistry):
@@ -191,7 +192,7 @@ class Tmux(Terminal):
logger.warn(msg)
class Custom(Terminal):
- command = 'false' # This is a placeholder
+ command = None # This is a placeholder
priority = 3
def __init__(self, sh_cmd, title=None, env=None, d=None):
@@ -209,6 +210,14 @@ class Custom(Terminal):
def prioritized():
return Registry.prioritized()
+def get_cmd_list():
+ terms = Registry.prioritized()
+ cmds = []
+ for term in terms:
+ if term.command:
+ cmds.append(term.command)
+ return cmds
+
def spawn_preferred(sh_cmd, title=None, env=None, d=None):
"""Spawn the first supported terminal, by priority"""
for terminal in prioritized():
@@ -218,7 +227,7 @@ def spawn_preferred(sh_cmd, title=None, env=None, d=None):
except UnsupportedTerminal:
continue
else:
- raise NoSupportedTerminals()
+ raise NoSupportedTerminals(get_cmd_list())
def spawn(name, sh_cmd, title=None, env=None, d=None):
"""Spawn the specified terminal, by name"""
--
2.10.2
^ permalink raw reply related
* Re: [patch net] mlxsw: spectrum_router: Flush FIB tables during fini
From: David Miller @ 2016-11-14 21:46 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
In-Reply-To: <1479119192-1545-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 14 Nov 2016 11:26:32 +0100
> From: Ido Schimmel <idosch@mellanox.com>
>
> Since commit b45f64d16d45 ("mlxsw: spectrum_router: Use FIB notifications
> instead of switchdev calls") we reflect to the device the entire FIB
> table and not only FIBs that point to netdevs created by the driver.
>
> During module removal, FIBs of the second type are removed following
> NETDEV_UNREGISTER events sent. The other FIBs are still present in both
> the driver's cache and the device's table.
>
> Fix this by iterating over all the FIB tables in the device and flush
> them. There's no need to take locks, as we're the only writer.
>
> Fixes: b45f64d16d45 ("mlxsw: spectrum_router: Use FIB notifications instead of switchdev calls")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* [PATCH] cpufreq: Avoid a couple of races related to cpufreq_cpu_get()
From: Rafael J. Wysocki @ 2016-11-14 21:51 UTC (permalink / raw)
To: Linux PM list
Cc: Linux Kernel Mailing List, Viresh Kumar, Srinivas Pandruvada
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The cpumask_test_cpu() check in cpufreq_cpu_get_raw() is sort of
pointless, because it may be racy with respect to CPU online/offline
which sets/clears the policy->cpus mask.
For this reason, it is better to reserve cpufreq_cpu_get_raw() for
the ondemand governor, which calls it for online CPUs only with CPU
online/offline locked anyway, and move the cpumask_test_cpu() up the
call chain.
Moreover, the callers of cpufreq_cpu_get() that really care about
avoiding races with CPU online/offline should better carry out that
check under policy->rwsem.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/cpufreq/cpufreq.c | 46 +++++++++++++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 15 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -65,6 +65,12 @@ static struct cpufreq_driver *cpufreq_dr
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
static DEFINE_RWLOCK(cpufreq_driver_lock);
+struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
+{
+ return per_cpu(cpufreq_cpu_data, cpu);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
+
/* Flag to suspend/resume CPUFreq governors */
static bool cpufreq_suspended;
@@ -192,19 +198,12 @@ int cpufreq_generic_init(struct cpufreq_
}
EXPORT_SYMBOL_GPL(cpufreq_generic_init);
-struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
-{
- struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
-
- return policy && cpumask_test_cpu(cpu, policy->cpus) ? policy : NULL;
-}
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
-
unsigned int cpufreq_generic_get(unsigned int cpu)
{
- struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
- if (!policy || IS_ERR(policy->clk)) {
+ if (!policy || !cpumask_test_cpu(cpu, policy->cpus) ||
+ IS_ERR(policy->clk)) {
pr_err("%s: No %s associated to cpu: %d\n",
__func__, policy ? "clk" : "policy", cpu);
return 0;
@@ -240,7 +239,7 @@ struct cpufreq_policy *cpufreq_cpu_get(u
if (cpufreq_driver) {
/* get the CPU */
- policy = cpufreq_cpu_get_raw(cpu);
+ policy = per_cpu(cpufreq_cpu_data, cpu);
if (policy)
kobject_get(&policy->kobj);
}
@@ -1328,7 +1327,7 @@ static int cpufreq_offline(unsigned int
pr_debug("%s: unregistering CPU %u\n", __func__, cpu);
- policy = cpufreq_cpu_get_raw(cpu);
+ policy = per_cpu(cpufreq_cpu_data, cpu);
if (!policy) {
pr_debug("%s: No cpu_data found\n", __func__);
return 0;
@@ -1455,7 +1454,9 @@ unsigned int cpufreq_quick_get(unsigned
policy = cpufreq_cpu_get(cpu);
if (policy) {
- ret_freq = policy->cur;
+ if (cpumask_test_cpu(cpu, policy->cpus))
+ ret_freq = policy->cur;
+
cpufreq_cpu_put(policy);
}
@@ -1475,7 +1476,9 @@ unsigned int cpufreq_quick_get_max(unsig
unsigned int ret_freq = 0;
if (policy) {
- ret_freq = policy->max;
+ if (cpumask_test_cpu(cpu, policy->cpus))
+ ret_freq = policy->max;
+
cpufreq_cpu_put(policy);
}
@@ -1526,7 +1529,10 @@ unsigned int cpufreq_get(unsigned int cp
if (policy) {
down_read(&policy->rwsem);
- ret_freq = __cpufreq_get(policy);
+
+ if (cpumask_test_cpu(cpu, policy->cpus))
+ ret_freq = __cpufreq_get(policy);
+
up_read(&policy->rwsem);
cpufreq_cpu_put(policy);
@@ -2142,6 +2148,11 @@ int cpufreq_get_policy(struct cpufreq_po
if (!cpu_policy)
return -EINVAL;
+ if (!cpumask_test_cpu(cpu, policy->cpus)) {
+ cpufreq_cpu_put(cpu_policy);
+ return -EINVAL;
+ }
+
memcpy(policy, cpu_policy, sizeof(*policy));
cpufreq_cpu_put(cpu_policy);
@@ -2265,6 +2276,11 @@ int cpufreq_update_policy(unsigned int c
down_write(&policy->rwsem);
+ if (!cpumask_test_cpu(cpu, policy->cpus)) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+
pr_debug("updating policy for CPU %u\n", cpu);
memcpy(&new_policy, policy, sizeof(*policy));
new_policy.min = policy->user_policy.min;
^ permalink raw reply
* [Buildroot] [PATCH] openjpeg: security bump to version 2.1.2
From: Baruch Siach @ 2016-11-14 21:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114223404.7c3b88be@free-electrons.com>
Hi Thomas,
On Mon, Nov 14, 2016 at 10:34:04PM +0100, Thomas Petazzoni wrote:
> On Mon, 14 Nov 2016 22:47:43 +0200, Baruch Siach wrote:
> > See CHANGELOG.md for the full list of fixes, including security issues.
> >
> > See CVE number lists at [1] and [2].
> >
> > [1] http://advisories.mageia.org/MGASA-2016-0362.html
> > [2] https://lists.fedoraproject.org/archives/list/package-announce at lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > package/openjpeg/openjpeg.hash | 2 +-
> > package/openjpeg/openjpeg.mk | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
>
> Applied to master, thanks.
I mistakenly created this patch against -next. The newly added patches in
master don't apply to this version. I'll post a fix.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
From: Dhinakaran Pandiyan @ 2016-11-14 21:42 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
In-Reply-To: <1479159735-29364-1-git-send-email-dhinakaran.pandiyan@intel.com>
Not validating the mode rate against max. link rate results in not pruning
invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not
support 4k@60Hz. But, we do not reject this mode.
So, make use of the helpers in intel_dp to validate mode data rate against
max. link data rate of a configuration.
v2: Renamed mode data rate local variable to be more explanatory.
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0c5d4bd..a7393e8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-static int
+int
intel_dp_link_required(int pixel_clock, int bpp)
{
/* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
return DIV_ROUND_UP(pixel_clk * bpp, 8);
}
-static int
+int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..2c557d9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -335,7 +335,17 @@ static enum drm_mode_status
intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ int link_clock = intel_dp_max_link_rate(intel_dp);
+ int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+ int bpp = 24; /* MST uses fixed bpp */
+ int mode_data_rate;
+ int link_max_data_rate;
+
+ mode_data_rate = intel_dp_link_required(mode->clock, bpp);
+ link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
/* TODO - validate mode against available PBN for link */
if (mode->clock < 10000)
@@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
- if (mode->clock > max_dotclk)
+ if (mode_data_rate > link_max_data_rate || mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
return MODE_OK;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..313419d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
bool __intel_dp_read_desc(struct intel_dp *intel_dp,
struct intel_dp_desc *desc);
bool intel_dp_read_desc(struct intel_dp *intel_dp);
+int intel_dp_link_required(int pixel_clock, int bpp);
+int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
/* intel_dp_aux_backlight.c */
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.