RE: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios communication over WMI

> -Original Message- > From: Limonciello, Mario > Sent: Wednesday, October 18, 2017 8:56 AM > To: 'Pali Rohár' ; Greg KH ; Alan Cox > > Cc: dvh...@infradead.org; Andy Shevchenko ; > LKML

RE: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios communication over WMI

> -Original Message- > From: Limonciello, Mario > Sent: Wednesday, October 18, 2017 8:56 AM > To: 'Pali Rohár' ; Greg KH ; Alan Cox > > Cc: dvh...@infradead.org; Andy Shevchenko ; > LKML ; platform-driver-...@vger.kernel.org; Andy > Lutomirski ; quasi...@google.com; r...@rjwysocki.net; >

Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission

Hi Richard, On 09/18/2017 12:41 AM, Richard Cochran wrote: > This series is an early RFC that introduces a new socket option > allowing time based transmission of packets. This option will be > useful in implementing various real time protocols over Ethernet, > including but not limited to

Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission

Hi Richard, On 09/18/2017 12:41 AM, Richard Cochran wrote: > This series is an early RFC that introduces a new socket option > allowing time based transmission of packets. This option will be > useful in implementing various real time protocols over Ethernet, > including but not limited to

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote: > [...] > > >> > >> The reason why pm_runtime_force_* needs to respects the hierarchy of > >> the RPM callbacks, is because otherwise it can't safely update the > >> runtime PM status of the device. > > > > I'm not sure I follow

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote: > [...] > > >> > >> The reason why pm_runtime_force_* needs to respects the hierarchy of > >> the RPM callbacks, is because otherwise it can't safely update the > >> runtime PM status of the device. > > > > I'm not sure I follow

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Wednesday, October 18, 2017 2:34:10 PM CEST Ulf Hansson wrote: > [...] > > >> Are there any major reasons why the appended patch (obviously untested) > >> won't > >> work, then? > > > > OK, there is a reason, which is the optimizations bundled into > > pm_runtime_force_*, because (a) the

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Wednesday, October 18, 2017 2:34:10 PM CEST Ulf Hansson wrote: > [...] > > >> Are there any major reasons why the appended patch (obviously untested) > >> won't > >> work, then? > > > > OK, there is a reason, which is the optimizations bundled into > > pm_runtime_force_*, because (a) the

Re: [PATCH 1/1] net: ethtool: add support for reset of AP inside NIC interface.

+net...@vger.kernel.org On 17-10-18 09:01 AM, Scott Branden wrote: Add ETH_RESET_AP to reset the application processor inside the NIC interface. Signed-off-by: Scott Branden --- include/uapi/linux/ethtool.h | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH 1/1] net: ethtool: add support for reset of AP inside NIC interface.

+net...@vger.kernel.org On 17-10-18 09:01 AM, Scott Branden wrote: Add ETH_RESET_AP to reset the application processor inside the NIC interface. Signed-off-by: Scott Branden --- include/uapi/linux/ethtool.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/ethtool.h

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

+net...@vger.kernel.org On 17-10-18 02:30 PM, Andy Gospodarek wrote: On Wed, Oct 18, 2017 at 12:31:28PM -0700, Scott Branden wrote: Hi Andrew, On 17-10-18 12:16 PM, Andrew Lunn wrote: Yes, there is also a management processor. O.K. Maybe it would be nice to add some more text to the

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

+net...@vger.kernel.org On 17-10-18 02:30 PM, Andy Gospodarek wrote: On Wed, Oct 18, 2017 at 12:31:28PM -0700, Scott Branden wrote: Hi Andrew, On 17-10-18 12:16 PM, Andrew Lunn wrote: Yes, there is also a management processor. O.K. Maybe it would be nice to add some more text to the

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote: > > On 10/18/2017 09:11 AM, Ulf Hansson wrote: [...] > >>> That's the point. We know pm_runtime_force_* works nicely for the > >>> trivial middle-layer cases. > >> > >> In which cases the middle-layer callbacks don't exist,

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote: > > On 10/18/2017 09:11 AM, Ulf Hansson wrote: [...] > >>> That's the point. We know pm_runtime_force_* works nicely for the > >>> trivial middle-layer cases. > >> > >> In which cases the middle-layer callbacks don't exist,

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

On Wed 2017-10-18 23:26:45, Alexandre Belloni wrote: > On 18/10/2017 at 23:08:28 +0200, Pavel Machek wrote: > > On Wed 2017-10-18 21:34:49, Alan Cox wrote: > > > > And even the boring ones have pretty imprecise RTCs... For example > > > > Nokia N9. > > > > I only power it up from time to time, I

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

On Wed 2017-10-18 23:26:45, Alexandre Belloni wrote: > On 18/10/2017 at 23:08:28 +0200, Pavel Machek wrote: > > On Wed 2017-10-18 21:34:49, Alan Cox wrote: > > > > And even the boring ones have pretty imprecise RTCs... For example > > > > Nokia N9. > > > > I only power it up from time to time, I

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On 10/18/17 11:30, Rob Herring wrote: > On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou > wrote: >> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: On Tue, Oct 17, 2017 at 6:51

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On 10/18/17 11:30, Rob Herring wrote: > On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou > wrote: >> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand wrote: > On 10/17/17

Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat

Hi Daniel and Tejun, On Wed, Oct 18, 2017 at 06:25:26AM -0700, Tejun Heo wrote: > > Daniel Borkmann (3): > > mm, percpu: add support for __GFP_NOWARN flag > > This looks fine. > Looks good to me too. > > bpf: fix splat for illegal devmap percpu allocation > > bpf: do not test for

Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat

Hi Daniel and Tejun, On Wed, Oct 18, 2017 at 06:25:26AM -0700, Tejun Heo wrote: > > Daniel Borkmann (3): > > mm, percpu: add support for __GFP_NOWARN flag > > This looks fine. > Looks good to me too. > > bpf: fix splat for illegal devmap percpu allocation > > bpf: do not test for

Re: [PATCH v4 pci 0/2] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Lorenzo, On Wed, Oct 18, 2017 at 2:26 AM, Lorenzo Pieralisi wrote: > [removed unintended disclaimer] > > On Tue, Oct 17, 2017 at 10:45:35PM -0700, Khuong Dinh wrote: >> Hi Lorenzo, >> >> On Tue, Oct 17, 2017 at 6:38 AM, Lorenzo Pieralisi >>

Re: [PATCH v4 pci 0/2] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Lorenzo, On Wed, Oct 18, 2017 at 2:26 AM, Lorenzo Pieralisi wrote: > [removed unintended disclaimer] > > On Tue, Oct 17, 2017 at 10:45:35PM -0700, Khuong Dinh wrote: >> Hi Lorenzo, >> >> On Tue, Oct 17, 2017 at 6:38 AM, Lorenzo Pieralisi >> wrote: >> > Hi Khuong, >> > >> > On Mon, Oct 16,

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On 10/18/17 11:39, Alan Tull wrote: > On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou > wrote: >> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: On Tue, Oct 17, 2017 at 6:51

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On 10/18/17 11:39, Alan Tull wrote: > On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou > wrote: >> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand wrote: > On 10/17/17

Re: [PATCH] zswap: Same-filled pages handling

> +static int zswap_is_page_same_filled(void *ptr, unsigned long *value) > +{ > + unsigned int pos; > + unsigned long *page; > + > + page = (unsigned long *)ptr; > + for (pos = 1; pos < PAGE_SIZE / sizeof(*page); pos++) { > + if (page[pos] != page[0]) > +

Re: [PATCH] zswap: Same-filled pages handling

> +static int zswap_is_page_same_filled(void *ptr, unsigned long *value) > +{ > + unsigned int pos; > + unsigned long *page; > + > + page = (unsigned long *)ptr; > + for (pos = 1; pos < PAGE_SIZE / sizeof(*page); pos++) { > + if (page[pos] != page[0]) > +

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

On Wed, Oct 18, 2017 at 12:31:28PM -0700, Scott Branden wrote: > Hi Andrew, > > > On 17-10-18 12:16 PM, Andrew Lunn wrote: > > > Yes, there is also a management processor. > > O.K. > > > > Maybe it would be nice to add some more text to the commit message to > > make this clear. Define what an

[PATCH v5] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

On Wed, Oct 18, 2017 at 12:31:28PM -0700, Scott Branden wrote: > Hi Andrew, > > > On 17-10-18 12:16 PM, Andrew Lunn wrote: > > > Yes, there is also a management processor. > > O.K. > > > > Maybe it would be nice to add some more text to the commit message to > > make this clear. Define what an

[PATCH v5] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

On 18/10/2017 at 23:08:28 +0200, Pavel Machek wrote: > On Wed 2017-10-18 21:34:49, Alan Cox wrote: > > > And even the boring ones have pretty imprecise RTCs... For example Nokia > > > N9. > > > I only power it up from time to time, I believe it drifts something like > > > minute per month... For

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

On 18/10/2017 at 23:08:28 +0200, Pavel Machek wrote: > On Wed 2017-10-18 21:34:49, Alan Cox wrote: > > > And even the boring ones have pretty imprecise RTCs... For example Nokia > > > N9. > > > I only power it up from time to time, I believe it drifts something like > > > minute per month... For

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

On Oct 18 2017 or thereabouts, Andrew Duggan wrote: > > > On 10/18/2017 07:13 AM, Jiri Kosina wrote: > > On Wed, 18 Oct 2017, Benjamin Tissoires wrote: > > > > > > The hid-rmi driver may handle non rmi devices on composite USB devices. > > > > Callbacks need to make sure that the current device

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

On Oct 18 2017 or thereabouts, Andrew Duggan wrote: > > > On 10/18/2017 07:13 AM, Jiri Kosina wrote: > > On Wed, 18 Oct 2017, Benjamin Tissoires wrote: > > > > > > The hid-rmi driver may handle non rmi devices on composite USB devices. > > > > Callbacks need to make sure that the current device

Re: Linux-kernel examples for LKMM recipes

On Wed, 18 Oct 2017, Paul E. McKenney wrote: > > Well, you could explicitly mention that in the multi-thread case, this > > means all accesses to the shared variable had better use READ_ONCE() or > > WRITE_ONCE(). > > Like this? > > Thanx,

Re: Linux-kernel examples for LKMM recipes

On Wed, 18 Oct 2017, Paul E. McKenney wrote: > > Well, you could explicitly mention that in the multi-thread case, this > > means all accesses to the shared variable had better use READ_ONCE() or > > WRITE_ONCE(). > > Like this? > > Thanx,

Re: [PATCH v2] i2c: aspeed: Deassert reset in probe

On Wed, Oct 18, 2017 at 4:29 PM, Joel Stanley wrote: > In order to use i2c from a cold boot, the i2c peripheral must be taken > out of reset. We request a shared reset controller each time a bus > driver is loaded, as the reset is shared between the 14 i2c buses. > > On remove the

Re: [PATCH v2] i2c: aspeed: Deassert reset in probe

On Wed, Oct 18, 2017 at 4:29 PM, Joel Stanley wrote: > In order to use i2c from a cold boot, the i2c peripheral must be taken > out of reset. We request a shared reset controller each time a bus > driver is loaded, as the reset is shared between the 14 i2c buses. > > On remove the reset is

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

On Wed 2017-10-18 21:34:49, Alan Cox wrote: > > And even the boring ones have pretty imprecise RTCs... For example Nokia N9. > > I only power it up from time to time, I believe it drifts something like > > minute per month... For normal use with SIM card, it can probably correct > > from GSM

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

On Wed 2017-10-18 21:34:49, Alan Cox wrote: > > And even the boring ones have pretty imprecise RTCs... For example Nokia N9. > > I only power it up from time to time, I believe it drifts something like > > minute per month... For normal use with SIM card, it can probably correct > > from GSM

Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot

On Mon, 9 Oct 2017, Pavel Tatashin wrote: > > Urgh, that's horrific. > > > > Can't we simply make sched_clock() go earlier? (we're violating "notsc" > > in any case and really should kill that option). > > > > Then we can do something like so on top... > > > > Hi Peter, > > I've been thinking

Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot

On Mon, 9 Oct 2017, Pavel Tatashin wrote: > > Urgh, that's horrific. > > > > Can't we simply make sched_clock() go earlier? (we're violating "notsc" > > in any case and really should kill that option). > > > > Then we can do something like so on top... > > > > Hi Peter, > > I've been thinking

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

On Wed, Oct 18, 2017 at 1:50 PM, Johannes Berg wrote: > On Wed, 2017-10-18 at 07:19 -0700, Kees Cook wrote: >> On Wed, Oct 18, 2017 at 3:29 AM, Johannes Berg >> wrote: >> > > This has been the least trivial timer conversion yet. Given the use

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

On Wed, Oct 18, 2017 at 1:50 PM, Johannes Berg wrote: > On Wed, 2017-10-18 at 07:19 -0700, Kees Cook wrote: >> On Wed, Oct 18, 2017 at 3:29 AM, Johannes Berg >> wrote: >> > > This has been the least trivial timer conversion yet. Given the use of >> > > RCU and other things I may not even know

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

On 18/10/17 16:13, Jiri Kosina wrote: > On Wed, 18 Oct 2017, Benjamin Tissoires wrote: > >>> The hid-rmi driver may handle non rmi devices on composite USB devices. >>> Callbacks need to make sure that the current device is a RMI device before >>> calling RMI specific functions. Most callbacks

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

On 18/10/17 16:13, Jiri Kosina wrote: > On Wed, 18 Oct 2017, Benjamin Tissoires wrote: > >>> The hid-rmi driver may handle non rmi devices on composite USB devices. >>> Callbacks need to make sure that the current device is a RMI device before >>> calling RMI specific functions. Most callbacks

[PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

Enable panic and disk activity triggers to tie to LED activity Signed-off-by: Amit Kucheria --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 34480e9..4ed357f 100644

[PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

Enable panic and disk activity triggers to tie to LED activity Signed-off-by: Amit Kucheria --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 34480e9..4ed357f 100644 ---

[PATCH 2/4] arm64: dts: qcom: apq8016-sbc: Allow USR4 LED to notify kernel panic

Blink the LED on a kernel panic. Signed-off-by: Amit Kucheria --- arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi index 1d63e6b..e4a6850

[PATCH 4/4] arm64: dts: hisilicon: hi3660-hikey960: Allow USR4 LED to notify kernel panic

Blink the LED on a kernel panic. Signed-off-by: Amit Kucheria --- arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts

[PATCH 2/4] arm64: dts: qcom: apq8016-sbc: Allow USR4 LED to notify kernel panic

Blink the LED on a kernel panic. Signed-off-by: Amit Kucheria --- arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi index 1d63e6b..e4a6850 100644 ---

[PATCH 4/4] arm64: dts: hisilicon: hi3660-hikey960: Allow USR4 LED to notify kernel panic

Blink the LED on a kernel panic. Signed-off-by: Amit Kucheria --- arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts index fd4705c..febbcb5

[PATCH 3/4] arm64: dts: hisilicon: hi6220-hikey: Allow USR1 LED to notify kernel panic

Blink the LED on a kernel panic. Signed-off-by: Amit Kucheria --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts index

[PATCH 3/4] arm64: dts: hisilicon: hi6220-hikey: Allow USR1 LED to notify kernel panic

Blink the LED on a kernel panic. Signed-off-by: Amit Kucheria --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts index 2b52630..c536403 100644 ---

[PATCH 0/4] arm64 defconfig: enable additional led triggers

This patchset enables the kernel panic and disk-activity trigger for LEDs and then enables the panic trigger for three 96Boards - DB410c, Hikey and Hikey960. DB410c and Hikey panic behaviour has been tested by triggering a panic through /proc/sysrq-trigger, while Hikey960 is only compile-tested.

[PATCH 0/4] arm64 defconfig: enable additional led triggers

This patchset enables the kernel panic and disk-activity trigger for LEDs and then enables the panic trigger for three 96Boards - DB410c, Hikey and Hikey960. DB410c and Hikey panic behaviour has been tested by triggering a panic through /proc/sysrq-trigger, while Hikey960 is only compile-tested.

Re: RFC(v2): Audit Kernel Container IDs

On Tue, Oct 17, 2017 at 11:44 AM, James Bottomley wrote: > On Tue, 2017-10-17 at 11:28 -0400, Simo Sorce wrote: >> > Without a *kernel* policy on containerIDs you can't say what >> > security policy is being exempted. >> >> The policy has been basically

Re: mainline build: 8 warnings 0 failures (mainline/v4.14-rc5-22-g3e0cc09)

On Wed, Oct 18, 2017 at 5:45 PM, Olof's autobuilder wrote: > Here are the build results from automated periodic testing. > > Warnings: > 2 samples/trace_events/trace-events-sample.c:104:6: warning: decrement > of a boolean expression [-Wbool-operation] > 2

Re: mainline build: 8 warnings 0 failures (mainline/v4.14-rc5-22-g3e0cc09)

On Wed, Oct 18, 2017 at 5:45 PM, Olof's autobuilder wrote: > Here are the build results from automated periodic testing. > > Warnings: > 2 samples/trace_events/trace-events-sample.c:104:6: warning: decrement > of a boolean expression [-Wbool-operation] > 2

Re: RFC(v2): Audit Kernel Container IDs

On Tue, Oct 17, 2017 at 11:44 AM, James Bottomley wrote: > On Tue, 2017-10-17 at 11:28 -0400, Simo Sorce wrote: >> > Without a *kernel* policy on containerIDs you can't say what >> > security policy is being exempted. >> >> The policy has been basically stated earlier. >> >> A way to track a set

Re: [PATCH v3] staging: ccree: fix boolreturn.cocci warning

Hi Suniel, Well done with you continued versions. I am being particularly nit picky here but since we are striving for perfection I'm sure will humour me. If English is not your first language please forgive me for picking you up on language subtleties. On Wed, Oct 18, 2017 at 12:11:55PM

Re: [PATCH v3] staging: ccree: fix boolreturn.cocci warning

Hi Suniel, Well done with you continued versions. I am being particularly nit picky here but since we are striving for perfection I'm sure will humour me. If English is not your first language please forgive me for picking you up on language subtleties. On Wed, Oct 18, 2017 at 12:11:55PM

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

On Wed, 2017-10-18 at 07:19 -0700, Kees Cook wrote: > On Wed, Oct 18, 2017 at 3:29 AM, Johannes Berg > wrote: > > > This has been the least trivial timer conversion yet. Given the use of > > > RCU and other things I may not even know about, I'd love to get a close > > >

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

On Wed, 2017-10-18 at 07:19 -0700, Kees Cook wrote: > On Wed, Oct 18, 2017 at 3:29 AM, Johannes Berg > wrote: > > > This has been the least trivial timer conversion yet. Given the use of > > > RCU and other things I may not even know about, I'd love to get a close > > > look at this. I *think*

Re: Memory-ordering recipes

On Wed, Oct 18, 2017 at 03:07:48AM +0200, Andrea Parri wrote: > On Tue, Oct 17, 2017 at 02:01:37PM -0700, Paul E. McKenney wrote: > > On Sun, Sep 17, 2017 at 04:05:09PM -0700, Paul E. McKenney wrote: > > > Hello! > > > > > > The topic of memory-ordering recipes came up at the Linux Plumbers > > >

Re: Memory-ordering recipes

On Wed, Oct 18, 2017 at 03:07:48AM +0200, Andrea Parri wrote: > On Tue, Oct 17, 2017 at 02:01:37PM -0700, Paul E. McKenney wrote: > > On Sun, Sep 17, 2017 at 04:05:09PM -0700, Paul E. McKenney wrote: > > > Hello! > > > > > > The topic of memory-ordering recipes came up at the Linux Plumbers > > >

Re: Restriction on setting debug registers (HW breakpoint) at kernel space

On Fri, 13 Oct 2017, Probir Roy wrote: > I am patching the perf tool of linux to set HW breakpoints at kernel > space. I found that there is an interface for user-space > (modify_user_hw_breakpoint) but no interface for system wide > breakpoint modification. Older version of linux had this support

Re: Restriction on setting debug registers (HW breakpoint) at kernel space

On Fri, 13 Oct 2017, Probir Roy wrote: > I am patching the perf tool of linux to set HW breakpoints at kernel > space. I found that there is an interface for user-space > (modify_user_hw_breakpoint) but no interface for system wide > breakpoint modification. Older version of linux had this support

Re: [PATCH] zswap: Same-filled pages handling

Srividya Desireddy writes: > > On a ARM Quad Core 32-bit device with 1.5GB RAM by launching and > relaunching different applications, out of ~64000 pages stored in > zswap, ~11000 pages were same-value filled pages (including zero-filled > pages) and ~9000 pages were

Re: [PATCH] rcu: do not include rtmutex_common.h unconditionally

On Wed, Oct 18, 2017 at 06:16:21PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-10-18 08:39:46 [-0700], Paul E. McKenney wrote: > > Thank you very much, hand-applied as a preparatory patch for > > "Suppress lockdep false-positive ->boost_mtx complaints", please see > > below. > okay. > > >

Re: [PATCH] zswap: Same-filled pages handling

Srividya Desireddy writes: > > On a ARM Quad Core 32-bit device with 1.5GB RAM by launching and > relaunching different applications, out of ~64000 pages stored in > zswap, ~11000 pages were same-value filled pages (including zero-filled > pages) and ~9000 pages were zero-filled pages. What are

Re: [PATCH] rcu: do not include rtmutex_common.h unconditionally

On Wed, Oct 18, 2017 at 06:16:21PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-10-18 08:39:46 [-0700], Paul E. McKenney wrote: > > Thank you very much, hand-applied as a preparatory patch for > > "Suppress lockdep false-positive ->boost_mtx complaints", please see > > below. > okay. > > >

Re: [PATCH 1/3] Documentation/devicetree: Add pcie-reset-suspend property

On Wed, Oct 18, 2017 at 11:17 AM, Bjorn Helgaas wrote: > On Tue, Oct 17, 2017 at 04:39:05PM -0700, Brian Norris wrote: >> On Fri, Oct 13, 2017 at 11:51:52AM -0500, Bjorn Helgaas wrote: >> > On Thu, Oct 12, 2017 at 01:52:18PM -0700, Brian Norris wrote: >> > > The patch is

Re: [PATCH 1/3] Documentation/devicetree: Add pcie-reset-suspend property

On Wed, Oct 18, 2017 at 11:17 AM, Bjorn Helgaas wrote: > On Tue, Oct 17, 2017 at 04:39:05PM -0700, Brian Norris wrote: >> On Fri, Oct 13, 2017 at 11:51:52AM -0500, Bjorn Helgaas wrote: >> > On Thu, Oct 12, 2017 at 01:52:18PM -0700, Brian Norris wrote: >> > > The patch is self-descriptive. I've

[PATCH 0/4][PoC][RFC] Add rlimit-resources change notification mechanism

This is a Proof of Concept and RFC of rlimit-events - generic, low-overhead notification mechanism for monitoring process-level resources. This series is not ready for submission. Its main purpose is to share the overall idea and collect feedback from the community. All comments are very welcome.

[PATCH 0/4][PoC][RFC] Add rlimit-resources change notification mechanism

This is a Proof of Concept and RFC of rlimit-events - generic, low-overhead notification mechanism for monitoring process-level resources. This series is not ready for submission. Its main purpose is to share the overall idea and collect feedback from the community. All comments are very welcome.

[PATCH 4/4][PoC][RFC] Allow to trace fd usage with rlimit-events

Add rlimit-events calls to file descriptors management code to allow tracing of FD usage. This allows userspace process (monitor) to get notification when other process (subject) uses given amount of file descriptors. This can be used to for example asynchronously monitor number of open FD's in

[PATCH 4/4][PoC][RFC] Allow to trace fd usage with rlimit-events

Add rlimit-events calls to file descriptors management code to allow tracing of FD usage. This allows userspace process (monitor) to get notification when other process (subject) uses given amount of file descriptors. This can be used to for example asynchronously monitor number of open FD's in

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

> And even the boring ones have pretty imprecise RTCs... For example Nokia N9. > I only power it up from time to time, I believe it drifts something like > minute per month... For normal use with SIM card, it can probably correct > from GSM network if you happen to have a cell phone signal, but...

[PATCH] scsi: gdth: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen

Re: Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

> And even the boring ones have pretty imprecise RTCs... For example Nokia N9. > I only power it up from time to time, I believe it drifts something like > minute per month... For normal use with SIM card, it can probably correct > from GSM network if you happen to have a cell phone signal, but...

[PATCH] scsi: gdth: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen --- This is a resend to tglx, with Reviews/Acks.

Re: [PATCH 1/3] clocksource/mips-gic-timer: Fix rcu_sched timeouts from multithreading

On Wed, 11 Oct 2017, Matt Redfearn wrote: > When the MIPS GIC clockevent code was written, it appears to have > inherited the 0x300 cycle min delta from the MIPS CPU timer driver. This > is suboptimal for two reasons. > > Firstly, the CPU timer counts once every other cycle (i.e. half the >

Re: [PATCH 1/3] clocksource/mips-gic-timer: Fix rcu_sched timeouts from multithreading

On Wed, 11 Oct 2017, Matt Redfearn wrote: > When the MIPS GIC clockevent code was written, it appears to have > inherited the 0x300 cycle min delta from the MIPS CPU timer driver. This > is suboptimal for two reasons. > > Firstly, the CPU timer counts once every other cycle (i.e. half the >

[PATCH] i40e/virtchnl: fix application of sizeof to pointer

sizeof when applied to a pointer typed expression gives the size of the pointer. The proper fix in this particular case is to code sizeof(*vfres) instead of sizeof(vfres). This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- This

[PATCH] i40e/virtchnl: fix application of sizeof to pointer

sizeof when applied to a pointer typed expression gives the size of the pointer. The proper fix in this particular case is to code sizeof(*vfres) instead of sizeof(vfres). This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- This code was tested by

[PATCH 2/4][PoC][RFC] Add rlimit-events framework

Add a framework which allows to notify userspace programs about change of resource (the same as in rlimits) usage. To monitor some process, monitor FD has to be obtained from kernel using rlimit-events netlink interface. Then monitor can issue ioctls() to subscribe for a particular usage level of

[PATCH 2/4][PoC][RFC] Add rlimit-events framework

Add a framework which allows to notify userspace programs about change of resource (the same as in rlimits) usage. To monitor some process, monitor FD has to be obtained from kernel using rlimit-events netlink interface. Then monitor can issue ioctls() to subscribe for a particular usage level of

[PATCH 3/4][PoC][RFC] Connect rlimit-events with process life cycle

Add rlimit-events call to process lifecycle to ensure that we get notified whenever process dies (to cleanup our watch levels) or forks (to implement watch levels inheritance). Signed-off-by: Krzysztof Opasiak --- kernel/exit.c | 4 kernel/fork.c | 16

[PATCH 3/4][PoC][RFC] Connect rlimit-events with process life cycle

Add rlimit-events call to process lifecycle to ensure that we get notified whenever process dies (to cleanup our watch levels) or forks (to implement watch levels inheritance). Signed-off-by: Krzysztof Opasiak --- kernel/exit.c | 4 kernel/fork.c | 16 +++- 2 files changed, 19

[PATCH 1/4][PoC][RFC] sched: Allow to get() and put() signal struct

Allow to get() and put() signal struct from different parts of kernel core, not only from signal.c. Signed-off-by: Krzysztof Opasiak --- include/linux/sched/signal.h | 13 + kernel/fork.c| 9 ++--- 2 files changed, 15 insertions(+), 7

[PATCH 1/4][PoC][RFC] sched: Allow to get() and put() signal struct

Allow to get() and put() signal struct from different parts of kernel core, not only from signal.c. Signed-off-by: Krzysztof Opasiak --- include/linux/sched/signal.h | 13 + kernel/fork.c| 9 ++--- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git

[PATCH] scsi: dc395x: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen

[PATCH] scsi: dc395x: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen --- This is a resend to tglx, with Reviews/Acks.

[PATCH] scsi: libiscsi: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen

[PATCH] scsi: aic94xx: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen

[PATCH] scsi: libiscsi: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen Reviewed-by: Chris Leech --- This is a resend

[PATCH] scsi: aic94xx: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen --- This is a resend to tglx, with Reviews/Acks.

[PATCH] scsi: smartpqi: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen

[PATCH] scsi: smartpqi: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Signed-off-by: Kees Cook Reviewed-by: Martin K. Petersen Acked-by: Don Brace --- This is a resend to

<    1   2   3   4   5   6   7   8   9   10   >