On 2018-06-26 14:28:26 [-0700], Isaac J. Manjarres wrote:
> Remove CPU ID swapping in stop_two_cpus() so that the
> source CPU's stopper thread is added to the wake queue last,
> so that the source CPU's stopper thread is woken up last,
> ensuring that all other threads that it depends on are
On 2018-06-26 14:28:26 [-0700], Isaac J. Manjarres wrote:
> Remove CPU ID swapping in stop_two_cpus() so that the
> source CPU's stopper thread is added to the wake queue last,
> so that the source CPU's stopper thread is woken up last,
> ensuring that all other threads that it depends on are
> Because, thinking more about it, the problem with those allocs are not
> related to the locking details; adding another trylock to the mix just
> makes it so much more obvious. I mean, first we would specifically
> handle atomic/irq context with a trylock "documenting" that atomic/irq
> users
> Because, thinking more about it, the problem with those allocs are not
> related to the locking details; adding another trylock to the mix just
> makes it so much more obvious. I mean, first we would specifically
> handle atomic/irq context with a trylock "documenting" that atomic/irq
> users
Hi Guenter
On 06/25/2018 05:42 PM, Ludovic Barre wrote:
From: Ludovic Barre
This patch series updates stm32_iwdg driver to manage pclk
clock by compatible. stm32mp1 requires a pclk clock.
v5:
-update stm32f429.dtsi
v4:
-dt-bindings: split and review
v3:
-remove stm32_iwdg_config structure,
Hi Guenter
On 06/25/2018 05:42 PM, Ludovic Barre wrote:
From: Ludovic Barre
This patch series updates stm32_iwdg driver to manage pclk
clock by compatible. stm32mp1 requires a pclk clock.
v5:
-update stm32f429.dtsi
v4:
-dt-bindings: split and review
v3:
-remove stm32_iwdg_config structure,
Al, can you pick up this fix from Chunyu?
On Tue, Jun 26, 2018 at 08:20:52AM -0400, Chunyu Hu wrote:
>
>
> - Original Message -
> > From: "Christoph Hellwig"
> > To: "Chunyu Hu"
> > Cc: v...@zeniv.linux.org.uk, h...@lst.de, linux-fsde...@vger.kernel.org,
> >
Al, can you pick up this fix from Chunyu?
On Tue, Jun 26, 2018 at 08:20:52AM -0400, Chunyu Hu wrote:
>
>
> - Original Message -
> > From: "Christoph Hellwig"
> > To: "Chunyu Hu"
> > Cc: v...@zeniv.linux.org.uk, h...@lst.de, linux-fsde...@vger.kernel.org,
> >
On Tue, Jun 26, 2018 at 02:03:38PM +0800, Ye Xiaolong wrote:
> Hi,
>
> On 06/22, Christoph Hellwig wrote:
> >Hi Xiaolong,
> >
> >can you retest this workload on the following branch:
> >
> >git://git.infradead.org/users/hch/vfs.git remove-get-poll-head
> >
> >Gitweb:
> >
> >
> >
On Tue, Jun 26, 2018 at 02:03:38PM +0800, Ye Xiaolong wrote:
> Hi,
>
> On 06/22, Christoph Hellwig wrote:
> >Hi Xiaolong,
> >
> >can you retest this workload on the following branch:
> >
> >git://git.infradead.org/users/hch/vfs.git remove-get-poll-head
> >
> >Gitweb:
> >
> >
> >
You allergic to using a GPT solution? It will get away from some of the evils
that RDB has inherent in it because they are also features? (Loading a
filesystem or DriveInit code from RDBs is just asking for a nearly impossible to
remove malware infection.) Furthermore, any 32 bit system that
You allergic to using a GPT solution? It will get away from some of the evils
that RDB has inherent in it because they are also features? (Loading a
filesystem or DriveInit code from RDBs is just asking for a nearly impossible to
remove malware infection.) Furthermore, any 32 bit system that
Hi Ethan,
On mar., juin 19 2018, Ethan Tuttle wrote:
> With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to
> detect buffer overflows. If src or dest is declared as a char, attempts to
> copy more than byte will result in a fortify_panic().
>
> Address this problem in
Hi Ethan,
On mar., juin 19 2018, Ethan Tuttle wrote:
> With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to
> detect buffer overflows. If src or dest is declared as a char, attempts to
> copy more than byte will result in a fortify_panic().
>
> Address this problem in
Hi Georgi
On Wed, 20 Jun 2018 at 14:11, Georgi Djakov wrote:
[snip]
> +
> +static struct icc_path *path_allocate(struct icc_node *dst, ssize_t
> num_nodes)
> +{
> + struct icc_node *node = dst;
> + struct icc_path *path;
> + size_t i;
> +
> + path =
Hi Georgi
On Wed, 20 Jun 2018 at 14:11, Georgi Djakov wrote:
[snip]
> +
> +static struct icc_path *path_allocate(struct icc_node *dst, ssize_t
> num_nodes)
> +{
> + struct icc_node *node = dst;
> + struct icc_path *path;
> + size_t i;
> +
> + path =
Thanks for all the replies, let me add some background around the
motivation for this change.
On some systems we have seen large delays in boot time, due to
blocking on a call to getrandom() before the entropy pool has been
initialized. On these systems the usual sources of entropy are not
Thanks for all the replies, let me add some background around the
motivation for this change.
On some systems we have seen large delays in boot time, due to
blocking on a call to getrandom() before the entropy pool has been
initialized. On these systems the usual sources of entropy are not
Hi Dennis,
On mar., juin 05 2018, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
>
Hi Dennis,
On mar., juin 05 2018, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
>
Hi sorry I'm not sure I understand; I based the change on linux-next
master, let me know if I should be using something else. The change is
not dependent on https://patchwork.kernel.org/patch/10453893/
On Wed, Jun 27, 2018 at 1:28 PM, Louis Collard
wrote:
> Hi sorry I'm not sure I understand; I
Hi sorry I'm not sure I understand; I based the change on linux-next
master, let me know if I should be using something else. The change is
not dependent on https://patchwork.kernel.org/patch/10453893/
On Wed, Jun 27, 2018 at 1:28 PM, Louis Collard
wrote:
> Hi sorry I'm not sure I understand; I
]
url:
https://github.com/0day-ci/linux/commits/Saravanan-Sekar/Add-clock-driver-for-Actions-S700-SoC/20180627-033122
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce
]
url:
https://github.com/0day-ci/linux/commits/Saravanan-Sekar/Add-clock-driver-for-Actions-S700-SoC/20180627-033122
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce
]
url:
https://github.com/0day-ci/linux/commits/Saravanan-Sekar/Add-clock-driver-for-Actions-S700-SoC/20180627-033122
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce
]
url:
https://github.com/0day-ci/linux/commits/Saravanan-Sekar/Add-clock-driver-for-Actions-S700-SoC/20180627-033122
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce
://github.com/0day-ci/linux/commits/Rik-van-Riel/mm-allocate-mm_cpumask-dynamically-based-on-nr_cpu_ids/20180627-021116
config: arm-keystone_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp
://github.com/0day-ci/linux/commits/Rik-van-Riel/mm-allocate-mm_cpumask-dynamically-based-on-nr_cpu_ids/20180627-021116
config: arm-keystone_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp
1001 - 1028 of 1028 matches
Mail list logo
