[PATCH] watchdog: constify watchdog_ops structures

Declare watchdog_ops structures as const as they are only stored in the ops field of a watchdog_device structure. This field is of type const, so watchdog_ops structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier x; position p; @@

[PATCH] watchdog: constify watchdog_ops structures

Declare watchdog_ops structures as const as they are only stored in the ops field of a watchdog_device structure. This field is of type const, so watchdog_ops structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier x; position p; @@

WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

Running Steven's hotplug stress script in tip.today. Config is NOPREEMPT, tune for maximum build time (enterprise default-ish). [ 75.268049] x86: Booting SMP configuration: [ 75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4 [

WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

Running Steven's hotplug stress script in tip.today. Config is NOPREEMPT, tune for maximum build time (enterprise default-ish). [ 75.268049] x86: Booting SMP configuration: [ 75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4 [

Re: [PATCH] IB/cma: Fix reversed test

On Fri, Jan 27, 2017 at 07:05:52PM -0500, Doug Ledford wrote: > > Do you think this patch needs "Fixes:" and "Cc: stable" tags? > > It does not. We always should have fixes tags. When I'm reviewing, I try to look up the patch which introduced the bug so I can figure out what the intent was.

Re: [PATCH] IB/cma: Fix reversed test

On Fri, Jan 27, 2017 at 07:05:52PM -0500, Doug Ledford wrote: > > Do you think this patch needs "Fixes:" and "Cc: stable" tags? > > It does not. We always should have fixes tags. When I'm reviewing, I try to look up the patch which introduced the bug so I can figure out what the intent was.

[PATCH v2] Staging: speakup - syle fix permissions to octal

A style fix across whole driver. changed permissions to octal style, found using checkpatch Signed-off-by: Derek Robson --- First version had spaces before praenthesis, now fixed in this version. drivers/staging/speakup/main.c | 4 ++--

[PATCH v2] Staging: speakup - syle fix permissions to octal

A style fix across whole driver. changed permissions to octal style, found using checkpatch Signed-off-by: Derek Robson --- First version had spaces before praenthesis, now fixed in this version. drivers/staging/speakup/main.c | 4 ++-- drivers/staging/speakup/speakup.h| 4

Re: [PATCH] prctl.2: Document new PR_SET_CHILD_SUBREAPER semantics

On 01/28/2017 01:47 AM, Michael Kerrisk (man-pages) wrote: Hello Pavel, On 27 January 2017 at 23:11, Pavel Tikhomirov wrote: old semantics was non deterministic and worked differently depending on the external factors, but nothing changes if process first sets

Re: [PATCH] prctl.2: Document new PR_SET_CHILD_SUBREAPER semantics

On 01/28/2017 01:47 AM, Michael Kerrisk (man-pages) wrote: Hello Pavel, On 27 January 2017 at 23:11, Pavel Tikhomirov wrote: old semantics was non deterministic and worked differently depending on the external factors, but nothing changes if process first sets itself subreaper and only after

Re: [PATCH] Staging: speakup - syle fix permissions to octal

On Sat, 2017-01-28 at 19:05 +1300, Derek Robson wrote: > A style fix across whole driver. > changed permissions to octal style, found using checkpatch [] > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c [] > @@ -58,8 +58,8 @@ MODULE_LICENSE("GPL"); >

Re: [PATCH] Staging: speakup - syle fix permissions to octal

On Sat, 2017-01-28 at 19:05 +1300, Derek Robson wrote: > A style fix across whole driver. > changed permissions to octal style, found using checkpatch [] > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c [] > @@ -58,8 +58,8 @@ MODULE_LICENSE("GPL"); >

[PATCH] Staging: speakup - syle fix permissions to octal

A style fix across whole driver. changed permissions to octal style, found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/speakup/main.c | 4 ++-- drivers/staging/speakup/speakup.h| 4 ++-- drivers/staging/speakup/speakup_acntpc.c | 26

[PATCH] Staging: speakup - syle fix permissions to octal

A style fix across whole driver. changed permissions to octal style, found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/speakup/main.c | 4 ++-- drivers/staging/speakup/speakup.h| 4 ++-- drivers/staging/speakup/speakup_acntpc.c | 26

Re: [HMM v17 00/14] HMM (Heterogeneous Memory Management) v17

On 01/27/2017 02:52 PM, Jérôme Glisse wrote: Cliff note: HMM offers 2 things (each standing on its own). First it allows to use device memory transparently inside any process without any modifications to process program code. Second it allows to mirror process address space on a device. Change

Re: [HMM v17 00/14] HMM (Heterogeneous Memory Management) v17

On 01/27/2017 02:52 PM, Jérôme Glisse wrote: Cliff note: HMM offers 2 things (each standing on its own). First it allows to use device memory transparently inside any process without any modifications to process program code. Second it allows to mirror process address space on a device. Change

Re: ibmvtpm byteswapping inconsistency

On Fri, 2017-01-27 at 12:32 -0800, Tyrel Datwyler wrote: > Its possible being the end of the week I'm just a little dense, but > wouldn't be64_to_cpu() imply that we are byte-swapping something that is > already, or supposedly already, in BE format to cpu endianness? Which on > a BE cpu I would

Re: ibmvtpm byteswapping inconsistency

On Fri, 2017-01-27 at 12:32 -0800, Tyrel Datwyler wrote: > Its possible being the end of the week I'm just a little dense, but > wouldn't be64_to_cpu() imply that we are byte-swapping something that is > already, or supposedly already, in BE format to cpu endianness? Which on > a BE cpu I would

[PATCH] hwmon: Relax name attribute validation for new APIs

While invalid name attributes are really not desirable and do mess up libsensors, enforcing valid names has the detrimental effect of driving users away from using the new hardware monitoring API, especially those registering name attributes violating the ABI restrictions. Another undesirable side

[PATCH] hwmon: Relax name attribute validation for new APIs

While invalid name attributes are really not desirable and do mess up libsensors, enforcing valid names has the detrimental effect of driving users away from using the new hardware monitoring API, especially those registering name attributes violating the ABI restrictions. Another undesirable side

Re: [PATCH v9] fs: clear file privilege bits when mmap writing

On Wed, May 25, 2016 at 2:49 PM, Al Viro wrote: > On Wed, May 25, 2016 at 02:36:57PM -0700, Kees Cook wrote: > >> Hm, this didn't end up getting picked up. (This jumped out at me again >> because i_mutex just vanished...) >> >> Al, what's the right way to update the

Re: [PATCH v9] fs: clear file privilege bits when mmap writing

On Wed, May 25, 2016 at 2:49 PM, Al Viro wrote: > On Wed, May 25, 2016 at 02:36:57PM -0700, Kees Cook wrote: > >> Hm, this didn't end up getting picked up. (This jumped out at me again >> because i_mutex just vanished...) >> >> Al, what's the right way to update the locking in this patch? > >

Re: [PATCH] doc: convert UIO howto from docbook to sphinx

Hi Alexander, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc5] [cannot apply to next-20170125] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] doc: convert UIO howto from docbook to sphinx

Hi Alexander, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc5] [cannot apply to next-20170125] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [RFC] [PATCH] audit: log module name on init_module

Hi RGB! This should get acked by the new module maintainer (and your RH peer!) Jeyu, cc'd. Cheers, Rusty. Richard Guy Briggs writes: > This adds a new auxiliary record MODULE_INIT to the SYSCALL event. > > We get finit_module for free since it made most sense

Re: [RFC] [PATCH] audit: log module name on init_module

Hi RGB! This should get acked by the new module maintainer (and your RH peer!) Jeyu, cc'd. Cheers, Rusty. Richard Guy Briggs writes: > This adds a new auxiliary record MODULE_INIT to the SYSCALL event. > > We get finit_module for free since it made most sense to hook this in to

[PATCH v2 1/2] fs: Check f_cred as well as of current's creds in should_remove_suid()

If an unprivileged program opens a setgid file for write and passes the fd to a privileged program and the privileged program writes to it, we currently fail to clear the setgid bit. Fix it by checking f_cred in addition to current's creds whenever a struct file is involved. I'm checking both

[PATCH v2 1/2] fs: Check f_cred as well as of current's creds in should_remove_suid()

If an unprivileged program opens a setgid file for write and passes the fd to a privileged program and the privileged program writes to it, we currently fail to clear the setgid bit. Fix it by checking f_cred in addition to current's creds whenever a struct file is involved. I'm checking both

[PATCH v2 0/2] setgid hardening

The kernel has some dangerous behavior involving the creation and modification of setgid executables. These issues aren't kernel security bugs per se, but they have been used to turn various filesystem permission oddities into reliably privilege escalation exploits. See

[PATCH v2 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory

Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a directory that is setgid and owned by a different gid than current's fsgid, you end up with an SGID executable that is owned by the directory's GID. This is a Bad Thing (tm). Exploiting this is nontrivial because most ways of

[PATCH v2 0/2] setgid hardening

The kernel has some dangerous behavior involving the creation and modification of setgid executables. These issues aren't kernel security bugs per se, but they have been used to turn various filesystem permission oddities into reliably privilege escalation exploits. See

[PATCH v2 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory

Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a directory that is setgid and owned by a different gid than current's fsgid, you end up with an SGID executable that is owned by the directory's GID. This is a Bad Thing (tm). Exploiting this is nontrivial because most ways of

Re: [PATCH 1/2] dt-bindings: Document the VC4 DSI module nodes.

Rob Herring writes: > Need to cc DT list if you want it in my queue. > > On Mon, Jan 23, 2017 at 6:38 PM, Eric Anholt wrote: >> These are part of the vc4 display pipeline. >> >> Signed-off-by: Eric Anholt >> --- >>

Re: [PATCH 1/2] dt-bindings: Document the VC4 DSI module nodes.

Rob Herring writes: > Need to cc DT list if you want it in my queue. > > On Mon, Jan 23, 2017 at 6:38 PM, Eric Anholt wrote: >> These are part of the vc4 display pipeline. >> >> Signed-off-by: Eric Anholt >> --- >> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 35 >>

[PATCH 08/10] perf, tools: Add a simple expression parser for JSON

From: Andi Kleen Add a simple expression parser good enough to parse JSON relation expressions. The parser is implemented using bison. Signed-off-by: Andi Kleen --- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++

[PATCH 08/10] perf, tools: Add a simple expression parser for JSON

From: Andi Kleen Add a simple expression parser good enough to parse JSON relation expressions. The parser is implemented using bison. Signed-off-by: Andi Kleen --- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++ tools/perf/tests/expr.c | 48

[PATCH 05/10] perf, tools: Add debug support for outputing alias string

From: Andi Kleen For debugging and testing it is useful to see the converted alias string. Add support to perf stat/record and perf list to print the alias conversion. The text string is saved in the alias structure. For perf stat/record it is folded into the normal -v. For

[PATCH 05/10] perf, tools: Add debug support for outputing alias string

From: Andi Kleen For debugging and testing it is useful to see the converted alias string. Add support to perf stat/record and perf list to print the alias conversion. The text string is saved in the alias structure. For perf stat/record it is folded into the normal -v. For perf list -v was

[PATCH 07/10] perf, tools: Expand PMU events by prefix match

From: Andi Kleen When the user specifies a pmu directly, expand it automatically with a prefix match, similar as we do for the normal aliases now. This allows to specify attributes for duplicated boxes quickly. For example uncore_cbox_{0,6}/.../ can be now specified as

[PATCH 07/10] perf, tools: Expand PMU events by prefix match

From: Andi Kleen When the user specifies a pmu directly, expand it automatically with a prefix match, similar as we do for the normal aliases now. This allows to specify attributes for duplicated boxes quickly. For example uncore_cbox_{0,6}/.../ can be now specified as cbox/.../ and it gets

[PATCH 10/10] perf, tools, stat: Output JSON MetricExpr metric

From: Andi Kleen Add generic infrastructure to perf stat to output ratios for "MetricExpr" entries in the event lists. Many events are more useful as ratios than in raw form, typically some count in relation to total ticks. Transfer the MetricExpr information from the

[PATCH 10/10] perf, tools, stat: Output JSON MetricExpr metric

From: Andi Kleen Add generic infrastructure to perf stat to output ratios for "MetricExpr" entries in the event lists. Many events are more useful as ratios than in raw form, typically some count in relation to total ticks. Transfer the MetricExpr information from the alias to the evsel. We

[PATCH 09/10] perf, tools: Support MetricExpr header in JSON event list

From: Andi Kleen Add support for parsing the MetricExpr header in the JSON event lists and storing them in the alias structure. Used in the next patch. v2: Change DividedBy to MetricExpr Signed-off-by: Andi Kleen --- tools/perf/pmu-events/jevents.c

[PATCH 09/10] perf, tools: Support MetricExpr header in JSON event list

From: Andi Kleen Add support for parsing the MetricExpr header in the JSON event lists and storing them in the alias structure. Used in the next patch. v2: Change DividedBy to MetricExpr Signed-off-by: Andi Kleen --- tools/perf/pmu-events/jevents.c| 18 ++

[PATCH 06/10] perf, tools: Collapse identically named events in perf stat

From: Andi Kleen The uncore PMU has a lot of duplicated PMUs for different subsystems. When expanding an uncore alias we usually end up with a large number of identically named aliases, which makes perf stat output difficult to read. Automatically sum them up in perf stat,

[PATCH 06/10] perf, tools: Collapse identically named events in perf stat

From: Andi Kleen The uncore PMU has a lot of duplicated PMUs for different subsystems. When expanding an uncore alias we usually end up with a large number of identically named aliases, which makes perf stat output difficult to read. Automatically sum them up in perf stat, unless --no-merge is

[PATCH 02/10] perf, tools: Add support for parsing uncore json files

From: Andi Kleen Handle the Unit field, which is needed to find the right PMU for an event. We call it "pmu" and convert it to the perf pmu name with an uncore prefix. Handle the ExtSel field, which just extends the event mask with an additional bit. Handle the Filter

[PATCH 02/10] perf, tools: Add support for parsing uncore json files

From: Andi Kleen Handle the Unit field, which is needed to find the right PMU for an event. We call it "pmu" and convert it to the perf pmu name with an uncore prefix. Handle the ExtSel field, which just extends the event mask with an additional bit. Handle the Filter field which adds

[PATCH 03/10] perf, tools: Support per pmu json aliases

From: Andi Kleen Add support for registering json aliases per PMU. Any alias with an unit matching the prefix is registered to the PMU. Uncore has multiple instances of most units, so all these aliases get registered for each individual PMU (this is important later to run

[PATCH 03/10] perf, tools: Support per pmu json aliases

From: Andi Kleen Add support for registering json aliases per PMU. Any alias with an unit matching the prefix is registered to the PMU. Uncore has multiple instances of most units, so all these aliases get registered for each individual PMU (this is important later to run the event on every

[PATCH 01/10] perf, tools: Parse eventcode as number in jevents

From: Andi Kleen The next patch needs to modify event code. Previously eventcode was just passed through as a string. Now parse it as a number. v2: Don't special case 0 Acked-by: Jiri Olsa Signed-off-by: Andi Kleen ---

[PATCH 04/10] perf, tools: Support event aliases for non cpu// pmus

From: Andi Kleen The code for handling pmu aliases without specifying the PMU hardcoded only supported the cpu PMU. This patch extends it to work for all PMUs. We always duplicate the event for all PMUs that have an matching alias. This allows to automatically expand an

[PATCH 01/10] perf, tools: Parse eventcode as number in jevents

From: Andi Kleen The next patch needs to modify event code. Previously eventcode was just passed through as a string. Now parse it as a number. v2: Don't special case 0 Acked-by: Jiri Olsa Signed-off-by: Andi Kleen --- tools/perf/pmu-events/jevents.c | 10 +- 1 file changed, 9

[PATCH 04/10] perf, tools: Support event aliases for non cpu// pmus

From: Andi Kleen The code for handling pmu aliases without specifying the PMU hardcoded only supported the cpu PMU. This patch extends it to work for all PMUs. We always duplicate the event for all PMUs that have an matching alias. This allows to automatically expand an alias for all instances

Support Intel uncore event lists

This adds uncore support on top of the recently merged JSON event list infrastructure for core events. Uncore is everything outside the core, including memory controllers, PCI, interconnect etc. Uncore is more complicated to handle than core events because it uses many duplicated PMUs, which

Support Intel uncore event lists

This adds uncore support on top of the recently merged JSON event list infrastructure for core events. Uncore is everything outside the core, including memory controllers, PCI, interconnect etc. Uncore is more complicated to handle than core events because it uses many duplicated PMUs, which

Re: net: suspicious RCU usage in nf_hook

On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: > On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > > Oh well, I forgot to submit the official patch I think, Jan 9th. > > > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > > > > Hmm, but why only

Re: net: suspicious RCU usage in nf_hook

On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: > On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > > Oh well, I forgot to submit the official patch I think, Jan 9th. > > > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > > > > Hmm, but why only fragments need

[PATCH 0/2] Add session handling to tpm spaces

Here's round two of the session handling patches. I folded in the review feedback (really all to patch 1) and tidied up a few parts of patch 2. James --- James Bottomley (2): tpm2: add session handle context saving and restoring to the space code tpm2-space: add handling for global session

[PATCH 0/2] Add session handling to tpm spaces

Here's round two of the session handling patches. I folded in the review feedback (really all to patch 1) and tidied up a few parts of patch 2. James --- James Bottomley (2): tpm2: add session handle context saving and restoring to the space code tpm2-space: add handling for global session

Re: [PATCH v2 4/4] mfd: cros_ec: add RTC as mfd subdevice

Hi Enric, On Thu, Jan 19, 2017 at 01:30:32PM +0100, Enric Balletbo i Serra wrote: > From: Stephen Barber > > If the EC supports RTC host commands, expose an RTC device. > > Signed-off-by: Stephen Barber > Signed-off-by: Enric Balletbo i Serra

Re: [PATCH v2 4/4] mfd: cros_ec: add RTC as mfd subdevice

Hi Enric, On Thu, Jan 19, 2017 at 01:30:32PM +0100, Enric Balletbo i Serra wrote: > From: Stephen Barber > > If the EC supports RTC host commands, expose an RTC device. > > Signed-off-by: Stephen Barber > Signed-off-by: Enric Balletbo i Serra Acked-by: Benson Leung Sorry for the delay on

[PATCH V2 1/1] percpu-refcount: fix reference leak during percpu-atomic transition

percpu_ref_tryget() and percpu_ref_tryget_live() should return "true" IFF they acquire a reference. But the return value from atomic_long_inc_not_zero() is a long and may have high bits set, e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines is bool so the reference may actually

[PATCH V2 1/1] percpu-refcount: fix reference leak during percpu-atomic transition

percpu_ref_tryget() and percpu_ref_tryget_live() should return "true" IFF they acquire a reference. But the return value from atomic_long_inc_not_zero() is a long and may have high bits set, e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines is bool so the reference may actually

[GIT PULL][PATCH 0/3] Timekeeping items for 4.11

Hey Thomas, Ingo, Just a few items I have queued for 4.11. Let me know if you have any objections thanks -john Cc: Thomas Gleixner Cc: Richard Cochran Cc: Prarit Bhargava Cc: Ingo Molnar The following

[GIT PULL][PATCH 0/3] Timekeeping items for 4.11

Hey Thomas, Ingo, Just a few items I have queued for 4.11. Let me know if you have any objections thanks -john Cc: Thomas Gleixner Cc: Richard Cochran Cc: Prarit Bhargava Cc: Ingo Molnar The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88: Linux 4.10-rc2

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > Oh well, I forgot to submit the official patch I think, Jan 9th. > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > Hmm, but why only fragments need skb_orphan()? It seems like any kfree_skb() inside

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > Oh well, I forgot to submit the official patch I think, Jan 9th. > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > Hmm, but why only fragments need skb_orphan()? It seems like any kfree_skb() inside a nf hook needs to have

[PATCH 3/3] timers: Omit POSIX timer stuff from task_struct when disabled

From: Nicolas Pitre When CONFIG_POSIX_TIMERS is disabled, it is preferable to remove related structures from struct task_struct and struct signal_struct as they won't contain anything useful and shouldn't be relied upon by mistake. Code still referencing those

[PATCH 3/3] timers: Omit POSIX timer stuff from task_struct when disabled

From: Nicolas Pitre When CONFIG_POSIX_TIMERS is disabled, it is preferable to remove related structures from struct task_struct and struct signal_struct as they won't contain anything useful and shouldn't be relied upon by mistake. Code still referencing those structures is also disabled here.

[PATCH 2/3] delay: Add explanation of udelay() inaccuracy

From: Russell King There seems to be some misunderstanding that udelay() and friends will always guarantee the specified delay. This is a false understanding. When udelay() is based on CPU cycles, it can return early for many reasons which are detailed by Linus'

[PATCH 1/3] timekeeping: Remove unused timekeeping_{get,set}_tai_offset()

From: Stephen Boyd The last caller to timekeeping_set_tai_offset() was in commit 0b5154fb9040 (timekeeping: Simplify tai updating from do_adjtimex, 2013-03-22) and the last caller to timekeeping_get_tai_offset() was in commit 76f4108892d9 (hrtimer: Cleanup hrtimer accessors

[PATCH 2/3] delay: Add explanation of udelay() inaccuracy

From: Russell King There seems to be some misunderstanding that udelay() and friends will always guarantee the specified delay. This is a false understanding. When udelay() is based on CPU cycles, it can return early for many reasons which are detailed by Linus' reply to me in a thread in 2011:

[PATCH 1/3] timekeeping: Remove unused timekeeping_{get,set}_tai_offset()

From: Stephen Boyd The last caller to timekeeping_set_tai_offset() was in commit 0b5154fb9040 (timekeeping: Simplify tai updating from do_adjtimex, 2013-03-22) and the last caller to timekeeping_get_tai_offset() was in commit 76f4108892d9 (hrtimer: Cleanup hrtimer accessors to the timekepeing

[PATCH V2 0/1] percpu-refcount: fix reference leak during percpu-atomic transition

Removed extraneous parentheses. Did not switch to "bool" as that would necessitate more testing and raises the question whether other platforms might have a different definition for "bool" that would not fix this problem.

[PATCH V2 0/1] percpu-refcount: fix reference leak during percpu-atomic transition

Removed extraneous parentheses. Did not switch to "bool" as that would necessitate more testing and raises the question whether other platforms might have a different definition for "bool" that would not fix this problem.

Re: ibmvtpm byteswapping inconsistency

On 01/27/2017 01:03 AM, Michal Suchanek wrote: > On 27 January 2017 at 02:50, Benjamin Herrenschmidt > wrote: >> On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote: >>> On 01/26/2017 12:22 PM, Michal Suchánek wrote: Hello, building ibmvtpm I noticed

Re: ibmvtpm byteswapping inconsistency

On 01/27/2017 01:03 AM, Michal Suchanek wrote: > On 27 January 2017 at 02:50, Benjamin Herrenschmidt > wrote: >> On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote: >>> On 01/26/2017 12:22 PM, Michal Suchánek wrote: Hello, building ibmvtpm I noticed gcc warning complaining

[GIT PULL] ARM: at91: drivers for 4.11 #2

Arnd, Olof The EBI was requiring more fixing than expected in preparation of the NAND driver rework for 4.12. The following changes since commit ee194289502a6901cc77dc9a893bf2afd351ac5e: memory/atmel-ebi: Fix ns <-> cycles conversions (2017-01-10 16:01:34 +0100) are available in the git

[GIT PULL] ARM: at91: drivers for 4.11 #2

Arnd, Olof The EBI was requiring more fixing than expected in preparation of the NAND driver rework for 4.12. The following changes since commit ee194289502a6901cc77dc9a893bf2afd351ac5e: memory/atmel-ebi: Fix ns <-> cycles conversions (2017-01-10 16:01:34 +0100) are available in the git

Re: ibmvtpm byteswapping inconsistency

Hello, On 2017-01-27 21:32, Tyrel Datwyler wrote: On 01/27/2017 11:58 AM, Benjamin Herrenschmidt wrote: On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote: The problem is that we are packing an in-memory structure into 2 registers and it's expected that this structure is laid out in the

Re: ibmvtpm byteswapping inconsistency

Hello, On 2017-01-27 21:32, Tyrel Datwyler wrote: On 01/27/2017 11:58 AM, Benjamin Herrenschmidt wrote: On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote: The problem is that we are packing an in-memory structure into 2 registers and it's expected that this structure is laid out in the

[PATCH 2/2] tpm2-space: add handling for global session exhaustion

In a TPM2, sessions can be globally exhausted once there are TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved). The Strategy for handling this is to keep a global count of all the sessions along with their creation time. Then if we see the TPM run out of sessions (via the

[PATCH 2/2] tpm2-space: add handling for global session exhaustion

In a TPM2, sessions can be globally exhausted once there are TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved). The Strategy for handling this is to keep a global count of all the sessions along with their creation time. Then if we see the TPM run out of sessions (via the

[PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

sessions are different from transient objects in that their handles may not be virtualized (because they're used for some hmac calculations). Additionally when a session is context saved, a vestigial memory remains in the TPM and if it is also flushed, that will be lost and the session context

[PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

sessions are different from transient objects in that their handles may not be virtualized (because they're used for some hmac calculations). Additionally when a session is context saved, a vestigial memory remains in the TPM and if it is also flushed, that will be lost and the session context

Re: [PATCH] platform: chrome: Add Tablet Switch ACPI driver

Hi Gwendal, Thanks for sending this! On Mon, Jan 23, 2017 at 03:39:55PM -0800, Gwendal Grignou wrote: > Add a kernel driver for GOOG0006, an ACPI driver reporting an event when > the tablet switch status changes. > > On an ACPI based convertible chromebook check evtest display tablet mode >

Re: [PATCH] platform: chrome: Add Tablet Switch ACPI driver

Hi Gwendal, Thanks for sending this! On Mon, Jan 23, 2017 at 03:39:55PM -0800, Gwendal Grignou wrote: > Add a kernel driver for GOOG0006, an ACPI driver reporting an event when > the tablet switch status changes. > > On an ACPI based convertible chromebook check evtest display tablet mode >

Re: [PATCH V2 0/1] percpu-refcount: fix reference leak during percpu-atomic transition

I will re-test and post the patch using "bool" when finished. On 01/27/2017 06:13 PM, Tejun Heo wrote: On Fri, Jan 27, 2017 at 05:32:15PM -0600, Douglas Miller wrote: Removed extraneous parentheses. Did not switch to "bool" as that would necessitate more testing and raises the question

Re: [PATCH V2 0/1] percpu-refcount: fix reference leak during percpu-atomic transition

I will re-test and post the patch using "bool" when finished. On 01/27/2017 06:13 PM, Tejun Heo wrote: On Fri, Jan 27, 2017 at 05:32:15PM -0600, Douglas Miller wrote: Removed extraneous parentheses. Did not switch to "bool" as that would necessitate more testing and raises the question

Re: [PATCH V2 0/1] percpu-refcount: fix reference leak during percpu-atomic transition

On Fri, Jan 27, 2017 at 05:32:15PM -0600, Douglas Miller wrote: > Removed extraneous parentheses. Did not switch to "bool" as that would > necessitate > more testing and raises the question whether other platforms might have a > different > definition for "bool" that would not fix this problem.

Re: [PATCH V2 0/1] percpu-refcount: fix reference leak during percpu-atomic transition

On Fri, Jan 27, 2017 at 05:32:15PM -0600, Douglas Miller wrote: > Removed extraneous parentheses. Did not switch to "bool" as that would > necessitate > more testing and raises the question whether other platforms might have a > different > definition for "bool" that would not fix this problem.

Re: [PATCH] IB/cma: Fix reversed test

On Fri, 2017-01-27 at 21:31 +, Bart Van Assche wrote: > On Fri, 2017-01-27 at 14:15 +0100, Christophe JAILLET wrote: > > > > This test looks reverted. > > We should log an error message only if 'ib_attach_mcast()' fails. > > > > Signed-off-by: Christophe JAILLET

Re: [PATCH] IB/cma: Fix reversed test

On Fri, 2017-01-27 at 21:31 +, Bart Van Assche wrote: > On Fri, 2017-01-27 at 14:15 +0100, Christophe JAILLET wrote: > > > > This test looks reverted. > > We should log an error message only if 'ib_attach_mcast()' fails. > > > > Signed-off-by: Christophe JAILLET > > --- > >  

[PATCH 3/6] ARCv2: IRQ: Add macro for the first external interrupt number

Signed-off-by: Yuriy Kolerov --- arch/arc/include/asm/irq.h | 1 + arch/arc/kernel/intc-arcv2.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h index c0fa0d2..e61ad30 100644 ---

[PATCH 3/6] ARCv2: IRQ: Add macro for the first external interrupt number

Signed-off-by: Yuriy Kolerov --- arch/arc/include/asm/irq.h | 1 + arch/arc/kernel/intc-arcv2.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h index c0fa0d2..e61ad30 100644 --- a/arch/arc/include/asm/irq.h +++

[PATCH 1/6] ARCv2: IRQ: Move structures for core intc to the header

Also add new macro ARC_REG_STATUS32 for the address of STATUS32 auxiliary register. It is better to use it instead of magic numbers. Signed-off-by: Yuriy Kolerov --- arch/arc/include/asm/arcregs.h | 26 ++ arch/arc/kernel/intc-arcv2.c | 23

[PATCH 0/6] Use build registers for getting numbers of interrupts

A summary: * Use build registers for getting numbers of interrupts both for core interrupt controller and for IDU interrupt controller. * Set a default priority for all core interrupt to prevent unexpected switching of banks of registers. * Remove option for setting number of

[PATCH 4/6] ARCv2: IRQ: Remove option for setting number of interrupts

When you set a value of ARC_NUMBER_OF_INTERRUPTS option it affects only a size of the interrupts table but macros for number of virtual interrupts (NR_IRQS) and for number of hardware interrupts (NR_CPU_IRQS) remain unchanged. Moreover usage of ARC_NUMBER_OF_INTERRUPTS is bad for portability since

[PATCH 1/6] ARCv2: IRQ: Move structures for core intc to the header

Also add new macro ARC_REG_STATUS32 for the address of STATUS32 auxiliary register. It is better to use it instead of magic numbers. Signed-off-by: Yuriy Kolerov --- arch/arc/include/asm/arcregs.h | 26 ++ arch/arc/kernel/intc-arcv2.c | 23 +++ 2

  1   2   3   4   5   6   7   8   9   10   >