Re: [PATCH v2 0/4] crypto: async crypto op fixes

On Thu, May 18, 2017 at 04:29:22PM +0300, Gilad Ben-Yossef wrote: > This patch set fixes various usage and documentation errors > in waiting for async crypto op to complete which can result > in data corruption. > > Note: these were discovered in the process of working on a > patch set that

Re: [PATCH] input: edt-ft5x06: increase allowed data range for threshold parameter

On Mon, May 08, 2017 at 11:11:46AM -0500, Rob Herring wrote: > On Tue, May 02, 2017 at 05:00:59PM +0200, Martin Kepplinger wrote: > > The datasheet and application note does not mention an allowed range for > > the M09_REGISTER_THRESHOLD parameter. One of our customers needs to set > > lower

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 4:07 PM, Kees Cook wrote: > On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote: >> On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote: >>> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote: > On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote: >> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer

Re: [PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction

On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni wrote: > [...] > diff --git a/kernel/module.c b/kernel/module.c > index 4a3665f..ce7a146 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -282,6 +282,8 @@ module_param(sig_enforce, bool_enable_only, 0644); > > /* Block

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni wrote: > This is a preparation patch for the module auto-load restriction feature. > > In order to restrict module auto-load operations we need to check if the > caller has CAP_SYS_MODULE capability. This allows to align security >

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote: > On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: >> On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote: >> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: >> >> *)

[GIT PULL] Power management updates for v4.12-rc3

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.12-rc3 with top-most commit bb47e964175e5fb4c163066e4373fac055fe5da0 Merge branches 'pm-sleep' and 'powercap' on top of commit 08332893e37af6ae779367e78e444f8f9571511d Linux

Re: [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

On Mon, May 22, 2017 at 07:07:51PM +0100, Alan Cox wrote: > On Mon, 22 May 2017 16:06:36 +0200 > Rasmus Villemoes wrote: > > > If a watchdog driver tells the framework that the device is running, > > the framework takes care of feeding the watchdog until userspace

Re: [PATCH 23/29] vfio-mediated-device.txt: standardize document format

On 5/19/2017 6:56 AM, Mauro Carvalho Chehab wrote: > Each text file under Documentation follows a different > format. Some doesn't even have titles! > > In this specific document, the title, copyright and authorship > are added as if it were a C file! > > Change its representation to follow

Re: [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

On Mon, 22 May 2017 16:06:36 +0200 Rasmus Villemoes wrote: > If a watchdog driver tells the framework that the device is running, > the framework takes care of feeding the watchdog until userspace opens > the device. If the userspace application which is supposed to

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 05/22/2017 01:13 PM, Waiman Long wrote: > On 05/19/2017 04:26 PM, Tejun Heo wrote: >>> @@ -2982,22 +3010,48 @@ static int cgroup_enable_threaded(struct cgroup >>> *cgrp) >>> LIST_HEAD(csets); >>> struct cgrp_cset_link *link; >>> struct css_set *cset, *cset_next; >>> + struct

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 05/19/2017 04:26 PM, Tejun Heo wrote: > Hello, Waiman. > > On Mon, May 15, 2017 at 09:34:10AM -0400, Waiman Long wrote: >> Now we could have something like >> >> R -- A -- B >> \ >>T1 -- T2 >> >> where R is the thread root, A and B are non-threaded cgroups, T1 and >> T2 are

Re: [RFC PATCH] mm, oom: cgroup-aware OOM-killer

On Sat, May 20, 2017 at 09:37:29PM +0300, Vladimir Davydov wrote: > Hello Roman, Hi Vladimir! > > On Thu, May 18, 2017 at 05:28:04PM +0100, Roman Gushchin wrote: > ... > > +5-2-4. Cgroup-aware OOM Killer > > + > > +Cgroup v2 memory controller implements a cgroup-aware OOM killer. > > +It means

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: > On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote: > > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > >> *) When modules_autoload_mode is set to (2), automatic module loading is > >>

Re: [PATCH v4 2/3] usb: gadget: f_uac2: split out audio core

On Thu, May 18, 2017 at 4:07 AM, Ruslan Bilovol wrote: > Abstract the peripheral side ALSA sound card code from > the f_uac2 function into a component that can be called > by various functions, so the various flavors can be split > apart and selectively reused. > >

[PATCH v5 2/3] watchdog: introduce watchdog.open_timeout commandline parameter

The watchdog framework takes care of feeding a hardware watchdog until userspace opens /dev/watchdogN. If that never happens for some reason (buggy init script, corrupt root filesystem or whatnot) but the kernel itself is fine, the machine stays up indefinitely. This patch allows setting an upper

[PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

If a watchdog driver tells the framework that the device is running, the framework takes care of feeding the watchdog until userspace opens the device. If the userspace application which is supposed to do that never comes up properly, the watchdog is fed indefinitely by the kernel. This can be

[PATCH v5 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT

This allows setting a default value for the watchdog.open_timeout commandline parameter via Kconfig. Signed-off-by: Rasmus Villemoes --- Documentation/watchdog/watchdog-parameters.txt | 9 + drivers/watchdog/Kconfig | 9 +

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

Hi Alexander, On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote: > Hi Djalal, > > Thank you for your work on this! > > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: >> *) When modules_autoload_mode is set to (2), automatic module loading is >> disabled

Re: [PATCH 00/41] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

Hi, On Saturday 20 May 2017 03:43 AM, Tony Lindgren wrote: > Hi, > > * Kishon Vijay Abraham I [170519 01:19]: >> This series adds UHS, HS200, DDR mode and ADMA support to >> omap_hsmmc driver used to improve the throughput of MMC/SD in dra7 >> SoCs. > > Certainly seems way less

[PATCH v8 4/9] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.

From: Anurup M Documentation for perf usage and Hisilicon SoC PMU uncore events. The Hisilicon SOC has event counters for hardware modules like L3 cache, Miscellaneous node etc. These events are all uncore. Signed-off-by: Anurup M Signed-off-by:

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

Hi Djalal, Thank you for your work on this! On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > *) When modules_autoload_mode is set to (2), automatic module loading is > disabled for all. Once set, this value can not be changed. What purpose does this securelevel-like property

[PATCH v4 next 0/3] modules: automatic module loading restrictions

of documentation and code comments. All suggestions were improved and fixed. Please see changelog for more details. These patches are against next-20170522 == Currently, an explicit call to load or unload kernel modules require CAP_SYS_MODULE capability. However unprivileged users have always

[PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction

Currently, an explicit call to load or unload kernel modules require CAP_SYS_MODULE capability. However unprivileged users have always been able to load some modules using the implicit auto-load operation. An automatic module loading happens when programs request a kernel feature from a module

[PATCH v4 next 3/3] modules:capabilities: add a per-task modules auto-load mode

Previous patches added the global sysctl "modules_autoload_mode". This patch make it possible to support process trees, containers, and sandboxes by providing an inherited per-task "modules_autoload_mode" flag that cannot be re-enabled once disabled. This allows to restrict automatic module

[PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

This is a preparation patch for the module auto-load restriction feature. In order to restrict module auto-load operations we need to check if the caller has CAP_SYS_MODULE capability. This allows to align security checks of automatic module loading with the checks of the explicit operations.

Re: [PATCH v2] kexec/kdump: Minor Documentation updates for arm64 and Image

On Mon, May 22, 2017 at 12:39:59PM +0530, Pratyush Anand wrote: > > > On Thursday 18 May 2017 04:23 PM, Bharat Bhushan wrote: > >This patch have minor updates in Documentation for arm64i as > arm64 > >relocatable kernel. > >Also this patch

Re: [PATCH v10 02/10] doc: Add documentation for Coresight CPU debug

On Mon, May 22, 2017 at 11:16:00AM +0100, Liviu Dudau wrote: > On Fri, May 19, 2017 at 12:25:49PM +0800, Leo Yan wrote: > > Add detailed documentation for Coresight CPU debug driver, which > > contains the info for driver implementation, Mike Leach excellent > > summary for "clock and power

Re: [PATCH v10 02/10] doc: Add documentation for Coresight CPU debug

On Fri, May 19, 2017 at 12:25:49PM +0800, Leo Yan wrote: > Add detailed documentation for Coresight CPU debug driver, which > contains the info for driver implementation, Mike Leach excellent > summary for "clock and power domain". At the end some examples on how > to enable the debugging

Re: [PATCH v2 00/10] Initial Allwinner R40 support

On Thu, May 4, 2017 at 3:49 PM, Icenowy Zheng wrote: > This is the first non-RFC version of this patchset, which added basical > support including I2C, UART and MMC to the mainline Linux. > > The pinctrl driver of A20 is also merged into the one of A10 before > R40 support is

Re: [PATCH v2] kexec/kdump: Minor Documentation updates for arm64 and Image

On Thursday 18 May 2017 04:23 PM, Bharat Bhushan wrote: This patch have minor updates in Documentation for arm64i as arm64 relocatable kernel. Also this patch updates documentation for using uncompressed image "Image" which is used for

Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

On Monday 22 May 2017 12:19 PM, Bharat Bhushan wrote: On Friday 19 May 2017 09:15 AM, AKASHI Takahiro wrote: +to load dump-capture kernel. + + kexec -p \ + --initrd= \ + --append="root= " For uncompressed Image, dtb is not necessary? Just for clarification, dtb is optional for both

RE: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

> -Original Message- > From: Pratyush Anand [mailto:pan...@redhat.com] > Sent: Monday, May 22, 2017 12:09 PM > To: AKASHI Takahiro ; Dave Young > ; Bharat Bhushan ; > b...@redhat.com; vgo...@redhat.com;

Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

On Friday 19 May 2017 09:15 AM, AKASHI Takahiro wrote: +to load dump-capture kernel. + + kexec -p \ + --initrd= \ + --append="root= " For uncompressed Image, dtb is not necessary? Just for clarification, dtb is optional for both vmlinux and Image on arm64. (This means you can specify

Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c

Hi Guenter, > > Note that some files don't seem to have upstream > > users in board code, so they maybe could even be removed? I didn't check for > > While I understand where you are coming from, I am not typically that > aggressive. > Such removals force vendors who are not really forthcoming