Ben,
Am Samstag, 28. Juli 2018, 03:28:58 CEST schrieb Ben Hutchings:
> > > Isn't there a risk here, that a read error leads to erasing data that
> > > might be recoverable if the read is retried?
> >
> > Well, read error means that already something went very wrong. At other
> > places
> > in
Ben,
Am Samstag, 28. Juli 2018, 03:28:58 CEST schrieb Ben Hutchings:
> > > Isn't there a risk here, that a read error leads to erasing data that
> > > might be recoverable if the read is retried?
> >
> > Well, read error means that already something went very wrong. At other
> > places
> > in
Srinivas Pandruvada writes:
> Enable HWP boost on Skylake server and workstations.
>
Please revert this series, it led to significant energy usage and
graphics performance regressions [1]. The reasons are roughly the ones
we discussed by e-mail off-list last April: This causes the intel_pstate
Srinivas Pandruvada writes:
> Enable HWP boost on Skylake server and workstations.
>
Please revert this series, it led to significant energy usage and
graphics performance regressions [1]. The reasons are roughly the ones
we discussed by e-mail off-list last April: This causes the intel_pstate
2018-07-26 0:01 GMT+09:00 Jeremy Cline :
> On 07/25/2018 10:39 AM, Masahiro Yamada wrote:
>> 2018-07-21 4:35 GMT+09:00 Jeremy Cline :
>>> Use the print function. This maintains Python 2 support and should have
>>> no functional change.
>>>
>>> Signed-off-by: Jeremy Cline
>>> ---
>>>
2018-07-26 0:01 GMT+09:00 Jeremy Cline :
> On 07/25/2018 10:39 AM, Masahiro Yamada wrote:
>> 2018-07-21 4:35 GMT+09:00 Jeremy Cline :
>>> Use the print function. This maintains Python 2 support and should have
>>> no functional change.
>>>
>>> Signed-off-by: Jeremy Cline
>>> ---
>>>
On Fri, Jul 27, 2018 at 10:31:48AM -0700, Guenter Roeck wrote:
> On Fri, Jul 27, 2018 at 11:44:53AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.11 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one.
On Fri, Jul 27, 2018 at 10:31:48AM -0700, Guenter Roeck wrote:
> On Fri, Jul 27, 2018 at 11:44:53AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.11 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one.
On Fri, Jul 27, 2018 at 01:49:42PM -0600, Shuah Khan wrote:
> On 07/27/2018 03:44 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.11 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Fri, Jul 27, 2018 at 01:49:42PM -0600, Shuah Khan wrote:
> On 07/27/2018 03:44 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.11 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any
From: Todd Poynor
Apex chips with class 0 (PCI_CLASS_NOT_DEFINED) fixed up to
PCI_CLASS_SYSTEM_OTHER to enable PCI resource assignments.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: Todd Poynor
The device pointer passed into get_mapping() will never be NULL; the
check is unnecessary.
Reported-by: Greg Kroah-Hartman
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_sysfs.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Todd Poynor
Remove the check for refcount already zero, which shouldn't be
necessary.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_sysfs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/gasket/gasket_sysfs.c
b/drivers/staging/gasket/gasket_sysfs.c
From: Todd Poynor
The fun continues with gasket+apex: remove dead code and unnecessary
stuff, fixup apex PCI class for devices that advertise class 0
(undefined), and make sure the struct device doesn't go away on us.
Most of these from review comments of previous patch series.
Todd Poynor (5):
From: Todd Poynor
The device pointer passed into get_mapping() will never be NULL; the
check is unnecessary.
Reported-by: Greg Kroah-Hartman
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_sysfs.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Todd Poynor
Remove the check for refcount already zero, which shouldn't be
necessary.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_sysfs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/gasket/gasket_sysfs.c
b/drivers/staging/gasket/gasket_sysfs.c
From: Todd Poynor
The fun continues with gasket+apex: remove dead code and unnecessary
stuff, fixup apex PCI class for devices that advertise class 0
(undefined), and make sure the struct device doesn't go away on us.
Most of these from review comments of previous patch series.
Todd Poynor (5):
From: Todd Poynor
Apex chips with class 0 (PCI_CLASS_NOT_DEFINED) fixed up to
PCI_CLASS_SYSTEM_OTHER to enable PCI resource assignments.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: Todd Poynor
Remove code with TODOs on it for working around apparent problems
previously seen in a qemu environment where dma_ops was not set
correctly. There is no user of this in the current code.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 2 +-
From: Todd Poynor
Hold a reference on the struct device kobject while a pointer to that
device is in use by gasket.
Reported-by: Greg Kroah-Hartman
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Todd Poynor
Remove code with TODOs on it for working around apparent problems
previously seen in a qemu environment where dma_ops was not set
correctly. There is no user of this in the current code.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 2 +-
From: Todd Poynor
Hold a reference on the struct device kobject while a pointer to that
device is in use by gasket.
Reported-by: Greg Kroah-Hartman
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
On 7/27/2018 8:39 PM, Pierre-Louis Bossart wrote:
> On 7/27/18 5:13 AM, Akshu Agrawal wrote:
>> There are cases where a pointer function populates
>> runtime->delay, such as:
>> ./sound/pci/hda/hda_controller.c
>> ./sound/soc/intel/atom/sst-mfld-platform-pcm.c
>>
>> Also, in some cases cpu dai
On 7/27/2018 8:39 PM, Pierre-Louis Bossart wrote:
> On 7/27/18 5:13 AM, Akshu Agrawal wrote:
>> There are cases where a pointer function populates
>> runtime->delay, such as:
>> ./sound/pci/hda/hda_controller.c
>> ./sound/soc/intel/atom/sst-mfld-platform-pcm.c
>>
>> Also, in some cases cpu dai
From: "Joel Fernandes (Google)"
The 0-day bot caught an issue which all my tests missed (will add it
into my tests) where this_cpu_ptr is incorrectly returning the wrong
pointer from get_lock_stats. Fix it.
Fixes: f4ac253a8df0 ("lockdep: use this_cpu_ptr instead of get_cpu_var stats")
From: "Joel Fernandes (Google)"
The 0-day bot caught an issue which all my tests missed (will add it
into my tests) where this_cpu_ptr is incorrectly returning the wrong
pointer from get_lock_stats. Fix it.
Fixes: f4ac253a8df0 ("lockdep: use this_cpu_ptr instead of get_cpu_var stats")
Many CPU architectures have caches that can scale independent of the CPUs.
Frequency scaling of the caches is necessary to make sure the cache is not
a performance bottleneck that leads to poor performance and power. The same
idea applies for RAM/DDR.
To achieve this, this patch adds a generic
Many CPU architectures have caches that can scale independent of the CPUs.
Frequency scaling of the caches is necessary to make sure the cache is not
a performance bottleneck that leads to poor performance and power. The same
idea applies for RAM/DDR.
To achieve this, this patch adds a generic
> ACPI Warning: \_SB.IETM._ART: Return Package type mismatch ..
_ART is the AML method for "Active Cooling Relationship Table".
iIt tells the system how fans are related to temperature sensors.
It is likely that Windows uses DPTF on this platform, and since DPTF
is not using _ART, Linux may be
> ACPI Warning: \_SB.IETM._ART: Return Package type mismatch ..
_ART is the AML method for "Active Cooling Relationship Table".
iIt tells the system how fans are related to temperature sensors.
It is likely that Windows uses DPTF on this platform, and since DPTF
is not using _ART, Linux may be
Hello Dear, I am Miss Lisa. I have very important thing to discuss
with you. please, this information is very vital. Contact me with my
private email so we can talk ( lisajoh...@hotmail.com ) I find your
email when I was searching for some that will understand me.
Lisa
Hello Dear, I am Miss Lisa. I have very important thing to discuss
with you. please, this information is very vital. Contact me with my
private email so we can talk ( lisajoh...@hotmail.com ) I find your
email when I was searching for some that will understand me.
Lisa
On 2018/07/28 2:32, David Howells wrote:
> Implement the security hook to check the creation of a new mountpoint for
> Tomoyo.
>
> As far as I can tell, Tomoyo doesn't make use of the mount data or parse
> any mount options, so I haven't implemented any of the fs_context hooks for
> it.
>
>
On 2018/07/28 2:32, David Howells wrote:
> Implement the security hook to check the creation of a new mountpoint for
> Tomoyo.
>
> As far as I can tell, Tomoyo doesn't make use of the mount data or parse
> any mount options, so I haven't implemented any of the fs_context hooks for
> it.
>
>
On Fri, 27 Jul 2018 10:31:45 -0400
Steven Rostedt wrote:
> On Fri, 27 Jul 2018 08:26:40 -0600
> Shuah Khan wrote:
>
> > Masami,
> >
> > The patch isn't in my Inbox. Could you please send it.
>
> You don't subscribe to LKML? ;-)
>
> I just bounced it to you.
>
> -- Steve
Sorry Shuah and
On Fri, 27 Jul 2018 10:31:45 -0400
Steven Rostedt wrote:
> On Fri, 27 Jul 2018 08:26:40 -0600
> Shuah Khan wrote:
>
> > Masami,
> >
> > The patch isn't in my Inbox. Could you please send it.
>
> You don't subscribe to LKML? ;-)
>
> I just bounced it to you.
>
> -- Steve
Sorry Shuah and
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
Changes in v3:
- Fix probepoint testcase too.
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
Changes in v3:
- Fix probepoint testcase too.
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
Prohibit kprobe-events probing on notrace function.
Since probing on the notrace function can cause recursive
event call. In most case those are just skipped, but
in some case it falls into infinit recursive call.
This protection can be disabled by the kconfig
CONFIG_KPROBE_EVENTS_ON_NOTRACE=y,
Prohibit kprobe-events probing on notrace function.
Since probing on the notrace function can cause recursive
event call. In most case those are just skipped, but
in some case it falls into infinit recursive call.
This protection can be disabled by the kconfig
CONFIG_KPROBE_EVENTS_ON_NOTRACE=y,
From: Francis Deslauriers
Move selftest function to its own compile unit so it can be compiled
with the ftrace cflags (CC_FLAGS_FTRACE) allowing it to be probed
during the ftrace startup tests.
Signed-off-by: Francis Deslauriers
Signed-off-by: Masami Hiramatsu
---
kernel/trace/Makefile
From: Francis Deslauriers
Move selftest function to its own compile unit so it can be compiled
with the ftrace cflags (CC_FLAGS_FTRACE) allowing it to be probed
during the ftrace startup tests.
Signed-off-by: Francis Deslauriers
Signed-off-by: Masami Hiramatsu
---
kernel/trace/Makefile
Hello,
This is the 3rd version of the series to prohibit kprobe
on notrace functions which Francis sent before.
This version fixes some issues on previous version. Fix
to handle the no-symbol kprobe-events correctly and Fix
probepoint.tc testcase to not use notrace function as
a probe point.
Hello,
This is the 3rd version of the series to prohibit kprobe
on notrace functions which Francis sent before.
This version fixes some issues on previous version. Fix
to handle the no-symbol kprobe-events correctly and Fix
probepoint.tc testcase to not use notrace function as
a probe point.
On Sat, Jul 28, 2018 at 12:07:19AM +, David Chen wrote:
> Hi Paul,
>
> I wasn't talking about the xchg() though.
>
> The smp_mb__after_atomic() is not for xchg(), it's for `*tail =
> rdp->nocb_gp_head;`
> it's stated so in the comment. And I do think we need ordering between
> `*tail =
On Sat, Jul 28, 2018 at 12:07:19AM +, David Chen wrote:
> Hi Paul,
>
> I wasn't talking about the xchg() though.
>
> The smp_mb__after_atomic() is not for xchg(), it's for `*tail =
> rdp->nocb_gp_head;`
> it's stated so in the comment. And I do think we need ordering between
> `*tail =
On Fri, Jul 27, 2018 at 5:02 PM Schmauss, Erik wrote:
>
> The patch below should be able to fix this.
Yes, the error messages seem gone with this.
I see another ACPI warning, but that one has always been there:
acpi INT33D5:00: intel-hid: created platform device
ACPI Warning:
On Fri, Jul 27, 2018 at 5:02 PM Schmauss, Erik wrote:
>
> The patch below should be able to fix this.
Yes, the error messages seem gone with this.
I see another ACPI warning, but that one has always been there:
acpi INT33D5:00: intel-hid: created platform device
ACPI Warning:
On Thu, 2018-07-26 at 08:25 +0200, Richard Weinberger wrote:
> Ben,
>
> Am Donnerstag, 26. Juli 2018, 04:12:54 CEST schrieb Ben Hutchings:
> > On Tue, 2018-07-10 at 20:24 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me
> > > know.
> >
On Thu, 2018-07-26 at 08:25 +0200, Richard Weinberger wrote:
> Ben,
>
> Am Donnerstag, 26. Juli 2018, 04:12:54 CEST schrieb Ben Hutchings:
> > On Tue, 2018-07-10 at 20:24 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me
> > > know.
> >
HELLO DEAR MY DONATION TO YOU.
May the peace of the Almighty God be with you and your Family,
With Due Respect and Humility, I was compelled to write you under humanitarian
ground. My name is Mrs Rosareio Romarinhio. TIMOR Origin but married with Late
Sir Ratnavale from MALAYSIA. I have took a
HELLO DEAR MY DONATION TO YOU.
May the peace of the Almighty God be with you and your Family,
With Due Respect and Humility, I was compelled to write you under humanitarian
ground. My name is Mrs Rosareio Romarinhio. TIMOR Origin but married with Late
Sir Ratnavale from MALAYSIA. I have took a
On Thu, 26 Jul 2018 14:53:27 +0900
Masami Hiramatsu wrote:
> Prohibit kprobe-events probing on notrace function.
> Since probing on the notrace function can cause recursive
> event call. In most case those are just skipped, but
> in some case it falls into infinit recursive call.
>
> This
On Thu, 26 Jul 2018 14:53:27 +0900
Masami Hiramatsu wrote:
> Prohibit kprobe-events probing on notrace function.
> Since probing on the notrace function can cause recursive
> event call. In most case those are just skipped, but
> in some case it falls into infinit recursive call.
>
> This
2018-07-27 16:48 GMT+09:00 Christoph Hellwig :
> On Fri, Jul 27, 2018 at 10:32:19AM +0900, Masahiro Yamada wrote:
>> This will just add a new unmet dependency warning.
>> CONFIG_PREEMPT_COUNT will be still selected.
>
> True. I guess we simply need to prohibit CONFIG_DEBUG_ATOMIC_SLEEP
>
2018-07-27 16:48 GMT+09:00 Christoph Hellwig :
> On Fri, Jul 27, 2018 at 10:32:19AM +0900, Masahiro Yamada wrote:
>> This will just add a new unmet dependency warning.
>> CONFIG_PREEMPT_COUNT will be still selected.
>
> True. I guess we simply need to prohibit CONFIG_DEBUG_ATOMIC_SLEEP
>
Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires,
we should sync its ->expires_seq too. However it is missing
for distribute_cfs_runtime(), especially the slack timer call path.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Cc: Xunlei Pang
Cc:
Hi David,
> On 28 Jul 2018, at 00:49, David Howells wrote:
> Jann Horn wrote:
>>> +static int fsinfo_generic_name_encoding(struct dentry *dentry, char *buf)
>>> +{
>>> + static const char encoding[] = "utf8";
>>> +
>>> + if (buf)
>>> + memcpy(buf, encoding,
Hi David,
> On 28 Jul 2018, at 00:49, David Howells wrote:
> Jann Horn wrote:
>>> +static int fsinfo_generic_name_encoding(struct dentry *dentry, char *buf)
>>> +{
>>> + static const char encoding[] = "utf8";
>>> +
>>> + if (buf)
>>> + memcpy(buf, encoding,
Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires,
we should sync its ->expires_seq too. However it is missing
for distribute_cfs_runtime(), especially the slack timer call path.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Cc: Xunlei Pang
Cc:
On Fri, Jul 27, 2018 at 01:34:31PM -0700, Sodagudi Prasad wrote:
> > The error should be pretty clear: "Inode table for bg 0 marked as
> > needing zeroing". That should never happen.
>
> Can you provide any debug patch to detect when this corruption is happening?
> Source of this corruption and
On Fri, Jul 27, 2018 at 01:34:31PM -0700, Sodagudi Prasad wrote:
> > The error should be pretty clear: "Inode table for bg 0 marked as
> > needing zeroing". That should never happen.
>
> Can you provide any debug patch to detect when this corruption is happening?
> Source of this corruption and
On 2018-05-23 07:39, Rob Herring wrote:
Reviving an old thread. Sorry about the late reply. Got busy.
On Tue, May 22, 2018 at 1:30 PM, Saravana Kannan
wrote:
On 05/22/2018 11:08 AM, Rob Herring wrote:
On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
The firmware present
On 2018-05-23 07:39, Rob Herring wrote:
Reviving an old thread. Sorry about the late reply. Got busy.
On Tue, May 22, 2018 at 1:30 PM, Saravana Kannan
wrote:
On 05/22/2018 11:08 AM, Rob Herring wrote:
On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
The firmware present
Jann Horn wrote:
> > fs/fat/inode.c: sprintf(buf, "cp%d", sbi->options.codepage);
>
> sprintf(buf, "cp%d", sbi->options.codepage);
> sbi->nls_disk = load_nls(buf);
> if (!sbi->nls_disk) {
> fat_msg(sb, KERN_ERR, "codepage %s not found", buf);
>
Jann Horn wrote:
> > fs/fat/inode.c: sprintf(buf, "cp%d", sbi->options.codepage);
>
> sprintf(buf, "cp%d", sbi->options.codepage);
> sbi->nls_disk = load_nls(buf);
> if (!sbi->nls_disk) {
> fat_msg(sb, KERN_ERR, "codepage %s not found", buf);
>
Hi Paul,
I wasn't talking about the xchg() though.
The smp_mb__after_atomic() is not for xchg(), it's for `*tail =
rdp->nocb_gp_head;`
it's stated so in the comment. And I do think we need ordering between
`*tail = rdp->nocb_gp_head;` and wake up, because the waiter is checking on
head not
Hi Paul,
I wasn't talking about the xchg() though.
The smp_mb__after_atomic() is not for xchg(), it's for `*tail =
rdp->nocb_gp_head;`
it's stated so in the comment. And I do think we need ordering between
`*tail = rdp->nocb_gp_head;` and wake up, because the waiter is checking on
head not
On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > That said, I would assume that
> > > other Android utilities are using other debugfs files
On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > That said, I would assume that
> > > other Android utilities are using other debugfs files
On 7/26/18 7:38 AM, Christoph Hellwig wrote:
This patch adds a driver for the Platform Level Interrupt Controller (PLIC)
specified as part of the RISC-V supervisor level ISA manual, in the memory
layout implemented by SiFive and qemu.
The PLIC connects global interrupt sources to the local
On 7/26/18 7:38 AM, Christoph Hellwig wrote:
This patch adds a driver for the Platform Level Interrupt Controller (PLIC)
specified as part of the RISC-V supervisor level ISA manual, in the memory
layout implemented by SiFive and qemu.
The PLIC connects global interrupt sources to the local
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Schmauss, Erik
> Sent: Friday, July 27, 2018 2:51 PM
> To: Linus Torvalds ; Rafael J. Wysocki
>
> Cc: Linux ACPI ; Linux Kernel Mailing List ker...@vger.kernel.org>
>
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Schmauss, Erik
> Sent: Friday, July 27, 2018 2:51 PM
> To: Linus Torvalds ; Rafael J. Wysocki
>
> Cc: Linux ACPI ; Linux Kernel Mailing List ker...@vger.kernel.org>
>
On Fri, 27 Jul 2018 17:43:07 -0400
Steven Rostedt wrote:
> On Thu, 26 Jul 2018 14:54:23 +0900
> Masami Hiramatsu wrote:
>
> > Fix kprobe string argument testcase to not probe notrace
> > function. Instead, it probes tracefs function which must
> > be available with ftrace.
>
> Hi Masami,
>
>
On Fri, 27 Jul 2018 17:43:07 -0400
Steven Rostedt wrote:
> On Thu, 26 Jul 2018 14:54:23 +0900
> Masami Hiramatsu wrote:
>
> > Fix kprobe string argument testcase to not probe notrace
> > function. Instead, it probes tracefs function which must
> > be available with ftrace.
>
> Hi Masami,
>
>
On Sat, Jul 28, 2018 at 1:51 AM David Howells wrote:
> David Howells wrote:
>
> > One thing I'm confused about is that fat has both a codepage and a charset
> > and
> > I'm not sure of the difference.
>
> In fact, it's not clear that the codepage is actually used.
>
> warthog>git grep
On Sat, Jul 28, 2018 at 1:51 AM David Howells wrote:
> David Howells wrote:
>
> > One thing I'm confused about is that fat has both a codepage and a charset
> > and
> > I'm not sure of the difference.
>
> In fact, it's not clear that the codepage is actually used.
>
> warthog>git grep
David Howells wrote:
> One thing I'm confused about is that fat has both a codepage and a charset and
> I'm not sure of the difference.
In fact, it's not clear that the codepage is actually used.
warthog>git grep '[.>]codepage'
fs/fat/inode.c: opts->codepage =
David Howells wrote:
> One thing I'm confused about is that fat has both a codepage and a charset and
> I'm not sure of the difference.
In fact, it's not clear that the codepage is actually used.
warthog>git grep '[.>]codepage'
fs/fat/inode.c: opts->codepage =
Jann Horn wrote:
> > +static int fsinfo_generic_name_encoding(struct dentry *dentry, char *buf)
> > +{
> > + static const char encoding[] = "utf8";
> > +
> > + if (buf)
> > + memcpy(buf, encoding, sizeof(encoding) - 1);
> > + return sizeof(encoding) - 1;
> > +}
>
Jann Horn wrote:
> > +static int fsinfo_generic_name_encoding(struct dentry *dentry, char *buf)
> > +{
> > + static const char encoding[] = "utf8";
> > +
> > + if (buf)
> > + memcpy(buf, encoding, sizeof(encoding) - 1);
> > + return sizeof(encoding) - 1;
> > +}
>
On Fri, Jul 27, 2018 at 11:16:39PM +, David Chen wrote:
> Hi Paul,
>
> Thanks for the advice.
> The bug is kind of hard to hit, so I can't say for certain yet.
Well, you can always remove the "tail == >nocb_follower_head" as an
extra belt-and-suspenders safety net. I am not putting that in
On Fri, Jul 27, 2018 at 11:16:39PM +, David Chen wrote:
> Hi Paul,
>
> Thanks for the advice.
> The bug is kind of hard to hit, so I can't say for certain yet.
Well, you can always remove the "tail == >nocb_follower_head" as an
extra belt-and-suspenders safety net. I am not putting that in
On Thu, Jul 26, 2018 at 1:07 PM, Johannes Weiner wrote:
> On Thu, Jul 26, 2018 at 11:07:32AM +1000, Singh, Balbir wrote:
>> On 7/25/18 1:15 AM, Johannes Weiner wrote:
>> > On Tue, Jul 24, 2018 at 07:14:02AM +1000, Balbir Singh wrote:
>> >> Does the mechanism scale? I am a little concerned about
On Thu, Jul 26, 2018 at 1:07 PM, Johannes Weiner wrote:
> On Thu, Jul 26, 2018 at 11:07:32AM +1000, Singh, Balbir wrote:
>> On 7/25/18 1:15 AM, Johannes Weiner wrote:
>> > On Tue, Jul 24, 2018 at 07:14:02AM +1000, Balbir Singh wrote:
>> >> Does the mechanism scale? I am a little concerned about
Hi Paul,
Thanks for the advice.
The bug is kind of hard to hit, so I can't say for certain yet.
Though after another look at the code, I found out the `smp_mb__after_atomic();`
seems to be only a compiler barrier on x86.
tail = xchg(>nocb_follower_tail, rdp->nocb_gp_tail);
Hi Paul,
Thanks for the advice.
The bug is kind of hard to hit, so I can't say for certain yet.
Though after another look at the code, I found out the `smp_mb__after_atomic();`
seems to be only a compiler barrier on x86.
tail = xchg(>nocb_follower_tail, rdp->nocb_gp_tail);
The enumerated type dm_dig_connect_e is only used to group constant
values, as the actual type is never used as the type for the variables
which use the defined constants (cur_connect_state and pre_connect_state).
These two member variables have had there defined types changed to
properly reflect
The enumerated type dm_dig_connect_e is only used to group constant
values, as the actual type is never used as the type for the variables
which use the defined constants (cur_connect_state and pre_connect_state).
These two member variables have had there defined types changed to
properly reflect
Remove the enumerated type dm_dig_op_e. The type is only used as a
parameter to the function dm_change_dynamic_initgain_thresh(), but
that function is never referenced in the code at all.
I would consider this to be a coding style change as the function is
never referenced and as a result the
Remove the enumerated type dm_dig_op_e. The type is only used as a
parameter to the function dm_change_dynamic_initgain_thresh(), but
that function is never referenced in the code at all.
I would consider this to be a coding style change as the function is
never referenced and as a result the
The enumerated type dm_dig_alg_e is only used by one variable in the
code, 'dig_algorithm', a member variable of the structure dig. That
member variable was defined to be of type 'u8' thus negating any
advantage of the use of an enumerated type, (compiler type-checking).
The type of the variable
The enumerated type dm_dig_cs_ratio_e is never actually used as a type,
but only as a collection of related constants. This is because the
variables, which use the defined constant values, are defined as being
of type u8 rather then enum dm_dig_cs_ratio_e. This omission negates
the possibility of
Refactor the use of the enumerated type dm_dig_sta_e, which is not
actually used for type checking by the compiler.
The enumerated type defines values for the enumeration, which are used
by both dig_state and dig_highpwr_state, (members of the struct dig).
Both of those variables were defined as
The enumerated type dm_ratr_sta_e was defined in the file
drivers/staging/rtl8192u/r8192U_dm.h but never actually used in that
file. The only variable which uses this enumerated type is 'ratr_state',
a member variable of the _rate_adaptive structure defined in the file
The enumerated type dm_dig_alg_e is only used by one variable in the
code, 'dig_algorithm', a member variable of the structure dig. That
member variable was defined to be of type 'u8' thus negating any
advantage of the use of an enumerated type, (compiler type-checking).
The type of the variable
The enumerated type dm_dig_cs_ratio_e is never actually used as a type,
but only as a collection of related constants. This is because the
variables, which use the defined constant values, are defined as being
of type u8 rather then enum dm_dig_cs_ratio_e. This omission negates
the possibility of
1 - 100 of 1556 matches
Mail list logo
