There is a potential execution path in which variable *resp_buftype*
is passed as an argument to function free_rsp_buf(), in which it is
used in a comparison without being properly initialized previously.
Fix this by initializing variable *resp_buftype* to CIFS_NO_BUFFER
in order to avoid
There is a potential execution path in which variable *resp_buftype*
is passed as an argument to function free_rsp_buf(), in which it is
used in a comparison without being properly initialized previously.
Fix this by initializing variable *resp_buftype* to CIFS_NO_BUFFER
in order to avoid
Hi Babu,
On 10/9/2018 2:17 PM, Moger, Babu wrote:
> On 10/09/2018 11:39 AM, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 10/5/2018 1:55 PM, Moger, Babu wrote:
>>> New generation of AMD processors start support RDT(or QOS) features.
>>> With more than one vendors supporting these features, it seems
Hi Babu,
On 10/9/2018 2:17 PM, Moger, Babu wrote:
> On 10/09/2018 11:39 AM, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 10/5/2018 1:55 PM, Moger, Babu wrote:
>>> New generation of AMD processors start support RDT(or QOS) features.
>>> With more than one vendors supporting these features, it seems
USLUGI REPETITORA 1-7 klass.
Nizkie ceni
12:55:46 AM
USLUGI REPETITORA 1-7 klass.
Nizkie ceni
12:55:46 AM
Hey Ronnie,
On 10/9/18 11:47 PM, Ronnie Sahlberg wrote:
> Good catch, but I think it should be :
>
> int resp_buftype = CIFS_NO_BUFFER;
>
Oh okay. I'll send v3 shortly.
Thanks for the feedback.
--
Gustavo
Hey Ronnie,
On 10/9/18 11:47 PM, Ronnie Sahlberg wrote:
> Good catch, but I think it should be :
>
> int resp_buftype = CIFS_NO_BUFFER;
>
Oh okay. I'll send v3 shortly.
Thanks for the feedback.
--
Gustavo
Present base_frequency to user space via cpufreq sysfs when HWP is in
use.
This HWP base frequency is read from HWP Capabilities MSR, if platform
doesn't have ACPI _CPC object. On most of the HWP platforms the _CPC
object will point to the HWP Capabilities MSR using address space id as
The Continuous Performance Control Package can have guaranteed performance
field. Add support to read guaranteed performance.
Signed-off-by: Srinivas Pandruvada
---
drivers/acpi/cppc_acpi.c | 8 ++--
include/acpi/cppc_acpi.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff
Good catch, but I think it should be :
int resp_buftype = CIFS_NO_BUFFER;
- Original Message -
From: "Gustavo A. R. Silva"
To: "Steve French" , "Ronnie Sahlberg"
Cc: linux-c...@vger.kernel.org, samba-techni...@lists.samba.org,
linux-kernel@vger.kernel.org, "Gustavo A. R. Silva"
Present base_frequency to user space via cpufreq sysfs when HWP is in
use.
This HWP base frequency is read from HWP Capabilities MSR, if platform
doesn't have ACPI _CPC object. On most of the HWP platforms the _CPC
object will point to the HWP Capabilities MSR using address space id as
The Continuous Performance Control Package can have guaranteed performance
field. Add support to read guaranteed performance.
Signed-off-by: Srinivas Pandruvada
---
drivers/acpi/cppc_acpi.c | 8 ++--
include/acpi/cppc_acpi.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff
Good catch, but I think it should be :
int resp_buftype = CIFS_NO_BUFFER;
- Original Message -
From: "Gustavo A. R. Silva"
To: "Steve French" , "Ronnie Sahlberg"
Cc: linux-c...@vger.kernel.org, samba-techni...@lists.samba.org,
linux-kernel@vger.kernel.org, "Gustavo A. R. Silva"
This series presents base frequency to cpufreq sysfs when intel_pstate
is in use in HWP mode.
Changes:
v2
- Removed guaranteed attribute addition to acpi_cppc sysfs
- Using the cppc_acpi interface to get base frequency and present
Srinivas Pandruvada (2):
ACPI / CPPC: Add support for
This series presents base frequency to cpufreq sysfs when intel_pstate
is in use in HWP mode.
Changes:
v2
- Removed guaranteed attribute addition to acpi_cppc sysfs
- Using the cppc_acpi interface to get base frequency and present
Srinivas Pandruvada (2):
ACPI / CPPC: Add support for
On Tue, Oct 09, 2018 at 08:47:26AM +0800, kbuild test robot wrote:
> Hi pascal,
>
> Thank you for the patch! Perhaps something to improve:
>
[ ... ]
> 42
> 43static int pmic_wdt_stop(struct watchdog_device *wdd)
> 44{
> 45struct
On Tue, Oct 09, 2018 at 08:47:26AM +0800, kbuild test robot wrote:
> Hi pascal,
>
> Thank you for the patch! Perhaps something to improve:
>
[ ... ]
> 42
> 43static int pmic_wdt_stop(struct watchdog_device *wdd)
> 44{
> 45struct
On Tue, Oct 09, 2018 at 03:18:12PM -0500, Anthony LaTorre wrote:
> Ok, I can reliably reproduce it by profiling the following program:
>
> #include
>
> int main(int argc, char **argv)
> {
> int i;
> double sum;
>
> while (1) {
> sum += exp(++i);
> }
>
> return 0;
>
On Tue, Oct 09, 2018 at 03:18:12PM -0500, Anthony LaTorre wrote:
> Ok, I can reliably reproduce it by profiling the following program:
>
> #include
>
> int main(int argc, char **argv)
> {
> int i;
> double sum;
>
> while (1) {
> sum += exp(++i);
> }
>
> return 0;
>
On 09.10.2018 16:40, Chris Clayton wrote:
> Thanks to Maciej and Heiner for their replies.
>
> On 09/10/2018 13:32, Maciej S. Szmigiero wrote:
>> On 07.10.2018 21:36, Chris Clayton wrote:
>>> Hi again,
>>>
>>> I didn't think there was anything in 4.19-rc7 to fix this regression, but
>>> tried it
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
head: b69c2e20f6e4046da84ce5b33ba1ef89cb087b40
commit: 010a93bf97c72f43aac664d0a685942f83d1a103 [3/4] resource: Fix
find_next_iomem_res() iteration issue
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
On 09.10.2018 16:40, Chris Clayton wrote:
> Thanks to Maciej and Heiner for their replies.
>
> On 09/10/2018 13:32, Maciej S. Szmigiero wrote:
>> On 07.10.2018 21:36, Chris Clayton wrote:
>>> Hi again,
>>>
>>> I didn't think there was anything in 4.19-rc7 to fix this regression, but
>>> tried it
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
head: b69c2e20f6e4046da84ce5b33ba1ef89cb087b40
commit: 010a93bf97c72f43aac664d0a685942f83d1a103 [3/4] resource: Fix
find_next_iomem_res() iteration issue
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
On Tue, 9 Oct 2018 13:14:00 -0700 "Joel Fernandes (Google)"
wrote:
> Android needs to mremap large regions of memory during memory management
> related operations. The mremap system call can be really slow if THP is
> not enabled. The bottleneck is move_page_tables, which is copying each
> pte
On Tue, 9 Oct 2018 13:14:00 -0700 "Joel Fernandes (Google)"
wrote:
> Android needs to mremap large regions of memory during memory management
> related operations. The mremap system call can be really slow if THP is
> not enabled. The bottleneck is move_page_tables, which is copying each
> pte
On Tue, Oct 09, 2018 at 01:54:48PM -0500, Anthony LaTorre wrote:
> Can you reproduce the segfault from the perf.data file I provided?
nope, but if it's dwarf callchain related I'd need perf archive
output to reproduce.. please run:
---
$ perf record ...
$ perf archive
Now please run:
$
On Tue, Oct 09, 2018 at 01:54:48PM -0500, Anthony LaTorre wrote:
> Can you reproduce the segfault from the perf.data file I provided?
nope, but if it's dwarf callchain related I'd need perf archive
output to reproduce.. please run:
---
$ perf record ...
$ perf archive
Now please run:
$
Enable eMMC support for rv1108 evaluation board.
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/rv1108-evb.dts | 8
arch/arm/boot/dts/rv1108.dtsi| 29 +
2 files changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/rv1108-evb.dts
Enable eMMC support for rv1108 evaluation board.
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/rv1108-evb.dts | 8
arch/arm/boot/dts/rv1108.dtsi| 29 +
2 files changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/rv1108-evb.dts
On Tue, 9 Oct 2018 22:50:19 +0200
Borislav Petkov wrote:
> From: Borislav Petkov
>
> If a call to panic() terminates the string with a \n, the result puts
> the closing brace ']---' on a newline because panic() itself adds \n
> too.
>
> Now, if one goes and removes the newline chars from all
On Tue, 9 Oct 2018 22:50:19 +0200
Borislav Petkov wrote:
> From: Borislav Petkov
>
> If a call to panic() terminates the string with a \n, the result puts
> the closing brace ']---' on a newline because panic() itself adds \n
> too.
>
> Now, if one goes and removes the newline chars from all
On Tue, Oct 09, 2018 at 12:01:44PM +0200, Jiri Olsa wrote:
> On Wed, Oct 03, 2018 at 07:45:50AM -0700, Andi Kleen wrote:
> > > note there's couple of changes that actually changed
> > > the number completely, like:
> > >
> > > -"Filter": "edge=1,filter_band2=4000",
> > > +
On Tue, Oct 9, 2018 at 1:34 PM Alexander Duyck
wrote:
>
> On 10/9/2018 11:04 AM, Dan Williams wrote:
> > On Tue, Oct 9, 2018 at 3:21 AM Yi Zhang wrote:
[..]
> > That comment is incorrect, device-pages are never onlined. So I think
> > we can just skip that call to __SetPageReserved() unless the
On Tue, Oct 09, 2018 at 12:01:44PM +0200, Jiri Olsa wrote:
> On Wed, Oct 03, 2018 at 07:45:50AM -0700, Andi Kleen wrote:
> > > note there's couple of changes that actually changed
> > > the number completely, like:
> > >
> > > -"Filter": "edge=1,filter_band2=4000",
> > > +
On Tue, Oct 9, 2018 at 1:34 PM Alexander Duyck
wrote:
>
> On 10/9/2018 11:04 AM, Dan Williams wrote:
> > On Tue, Oct 9, 2018 at 3:21 AM Yi Zhang wrote:
[..]
> > That comment is incorrect, device-pages are never onlined. So I think
> > we can just skip that call to __SetPageReserved() unless the
On 2018/10/09 23:52, Petr Mladek wrote:
> On Tue 2018-10-09 05:48:33, Tetsuo Handa wrote:
>> On 2018/10/09 1:03, Petr Mladek wrote:
>>> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
A structure named "struct printk_buffer" is introduced for buffering
up to LOG_LINE_MAX bytes of
On 2018/10/09 23:52, Petr Mladek wrote:
> On Tue 2018-10-09 05:48:33, Tetsuo Handa wrote:
>> On 2018/10/09 1:03, Petr Mladek wrote:
>>> On Mon 2018-10-08 19:31:58, Tetsuo Handa wrote:
A structure named "struct printk_buffer" is introduced for buffering
up to LOG_LINE_MAX bytes of
Hi,
On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2018-10-09 10:48:55)
> >
> > Ah, you're suggesting separating the platform_get_irq() and the
> > request_irq() so that we call platform_get_irq() as the first thing in
> > the function but don't do the
Hi,
On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2018-10-09 10:48:55)
> >
> > Ah, you're suggesting separating the platform_get_irq() and the
> > request_irq() so that we call platform_get_irq() as the first thing in
> > the function but don't do the
Hi Reinette,
On 10/09/2018 11:39 AM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/5/2018 1:55 PM, Moger, Babu wrote:
>> New generation of AMD processors start support RDT(or QOS) features.
>> With more than one vendors supporting these features, it seems more
>> appropriate to rename these files.
Hi Reinette,
On 10/09/2018 11:39 AM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/5/2018 1:55 PM, Moger, Babu wrote:
>> New generation of AMD processors start support RDT(or QOS) features.
>> With more than one vendors supporting these features, it seems more
>> appropriate to rename these files.
On Tue, Oct 9, 2018 at 1:50 PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> If a call to panic() terminates the string with a \n, the result puts
> the closing brace ']---' on a newline because panic() itself adds \n
> too.
>
> Now, if one goes and removes the newline chars from all
On Tue, Oct 9, 2018 at 1:50 PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> If a call to panic() terminates the string with a \n, the result puts
> the closing brace ']---' on a newline because panic() itself adds \n
> too.
>
> Now, if one goes and removes the newline chars from all
On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.13 release.
> There are 168 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.13 release.
> There are 168 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:30:41PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.75 release.
> There are 94 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:30:41PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.75 release.
> There are 94 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:31:07PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.132 release.
> There are 59 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:31:07PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.132 release.
> There are 59 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Hi Will,
This is regarding - thread "try to fix contention between expire_timers
and try_to_del_timer_sync".
https://lkml.org/lkml/2017/7/28/172
I think this live lockup issue was discussed earlier but the final set
of changes were not concluded.
I would like to check whether you have new
Hi Will,
This is regarding - thread "try to fix contention between expire_timers
and try_to_del_timer_sync".
https://lkml.org/lkml/2017/7/28/172
I think this live lockup issue was discussed earlier but the final set
of changes were not concluded.
I would like to check whether you have new
Quoting Taniya Das (2018-10-09 10:26:38)
> Hello Stephen,
>
> On 10/8/2018 8:14 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-10-04 05:02:26)
> >> Add support for the lpass clock controller found on SDM845 based devices.
> >> This would allow lpass peripheral loader drivers to control the
Quoting Taniya Das (2018-10-09 10:26:38)
> Hello Stephen,
>
> On 10/8/2018 8:14 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-10-04 05:02:26)
> >> Add support for the lpass clock controller found on SDM845 based devices.
> >> This would allow lpass peripheral loader drivers to control the
From: Borislav Petkov
If a call to panic() terminates the string with a \n, the result puts
the closing brace ']---' on a newline because panic() itself adds \n
too.
Now, if one goes and removes the newline chars from all panic()
invocations - and the stats right now look like this:
~300 calls
From: Borislav Petkov
If a call to panic() terminates the string with a \n, the result puts
the closing brace ']---' on a newline because panic() itself adds \n
too.
Now, if one goes and removes the newline chars from all panic()
invocations - and the stats right now look like this:
~300 calls
Quoting Taniya Das (2018-10-09 06:57:46)
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index 6e3bd19..ca6142f 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
Can you
Quoting Taniya Das (2018-10-09 06:57:46)
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index 6e3bd19..ca6142f 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
Can you
On 10/09/2018 12:18 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/5/2018 1:55 PM, Moger, Babu wrote:
>> diff --git a/arch/x86/kernel/cpu/rdt_ctrlmondata.c
>> b/arch/x86/kernel/cpu/rdt_ctrlmondata.c
>> index 812cc5c5e39e..ee3e8389d8d2 100644
>> --- a/arch/x86/kernel/cpu/rdt_ctrlmondata.c
>>
On 10/09/2018 12:18 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/5/2018 1:55 PM, Moger, Babu wrote:
>> diff --git a/arch/x86/kernel/cpu/rdt_ctrlmondata.c
>> b/arch/x86/kernel/cpu/rdt_ctrlmondata.c
>> index 812cc5c5e39e..ee3e8389d8d2 100644
>> --- a/arch/x86/kernel/cpu/rdt_ctrlmondata.c
>>
On Tue, 2018-10-09 at 09:35 +0200, Rafael J. Wysocki wrote:
> On Mon, Oct 8, 2018 at 6:55 PM Srinivas Pandruvada
> wrote:
> >
> > The Continuous Performance Control Package can have guaranteed
> > performance
> > field. Add support to read guaranteed performance.
>
> The spec says that it is
On Tue, 2018-10-09 at 09:35 +0200, Rafael J. Wysocki wrote:
> On Mon, Oct 8, 2018 at 6:55 PM Srinivas Pandruvada
> wrote:
> >
> > The Continuous Performance Control Package can have guaranteed
> > performance
> > field. Add support to read guaranteed performance.
>
> The spec says that it is
There is a potential execution path in which variable *resp_buftype*
is passed as an argument to function free_rsp_buf(), in which it is
used in a comparison without being properly initialized previously.
Fix this by initializing variable *resp_buftype* to -1 in order to
avoid unpredictable or
There is a potential execution path in which variable *resp_buftype*
is passed as an argument to function free_rsp_buf(), in which it is
used in a comparison without being properly initialized previously.
Fix this by initializing variable *resp_buftype* to -1 in order to
avoid unpredictable or
On 09.10.2018 16:40, Chris Clayton wrote:
> Thanks to Maciej and Heiner for their replies.
>
> On 09/10/2018 13:32, Maciej S. Szmigiero wrote:
>> On 07.10.2018 21:36, Chris Clayton wrote:
>>> Hi again,
>>>
>>> I didn't think there was anything in 4.19-rc7 to fix this regression, but
>>> tried it
On 09.10.2018 16:40, Chris Clayton wrote:
> Thanks to Maciej and Heiner for their replies.
>
> On 09/10/2018 13:32, Maciej S. Szmigiero wrote:
>> On 07.10.2018 21:36, Chris Clayton wrote:
>>> Hi again,
>>>
>>> I didn't think there was anything in 4.19-rc7 to fix this regression, but
>>> tried it
Quoting Taniya Das (2018-10-09 06:57:47)
> diff --git a/drivers/clk/qcom/dispcc-sdm845.c
> b/drivers/clk/qcom/dispcc-sdm845.c
> index 0cc4909..6d3136a 100644
> --- a/drivers/clk/qcom/dispcc-sdm845.c
> +++ b/drivers/clk/qcom/dispcc-sdm845.c
> @@ -128,6 +144,100 @@ enum {
> },
> };
>
>
Quoting Taniya Das (2018-10-09 06:57:47)
> diff --git a/drivers/clk/qcom/dispcc-sdm845.c
> b/drivers/clk/qcom/dispcc-sdm845.c
> index 0cc4909..6d3136a 100644
> --- a/drivers/clk/qcom/dispcc-sdm845.c
> +++ b/drivers/clk/qcom/dispcc-sdm845.c
> @@ -128,6 +144,100 @@ enum {
> },
> };
>
>
Ok, I can reliably reproduce it by profiling the following program:
#include
int main(int argc, char **argv)
{
int i;
double sum;
while (1) {
sum += exp(++i);
}
return 0;
}
compiled with:
$ cc -o test test.c -lm
with the following command:
$ perf record -F 99
Ok, I can reliably reproduce it by profiling the following program:
#include
int main(int argc, char **argv)
{
int i;
double sum;
while (1) {
sum += exp(++i);
}
return 0;
}
compiled with:
$ cc -o test test.c -lm
with the following command:
$ perf record -F 99
Foremost, we introduce this commission, The INTERPOL. We fight global crime
including internet fraud and money laundering. Our commission has rounded-up
well over 27,000 fraudsters and we are still battling these nefarious
individuals. We are aware that quite a lot of people have been conned
Foremost, we introduce this commission, The INTERPOL. We fight global crime
including internet fraud and money laundering. Our commission has rounded-up
well over 27,000 fraudsters and we are still battling these nefarious
individuals. We are aware that quite a lot of people have been conned
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slow across a large map. Turning on THP
may not
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slow across a large map. Turning on THP
may not
On 10/9/18 10:07 PM, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *resp_buftype*
> is passed as an argument to function free_rsp_buf(), in which is used
> without being properly initialized previously.
>
> Fix this by initializing variable *resp_buftype*
On 10/9/18 10:07 PM, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *resp_buftype*
> is passed as an argument to function free_rsp_buf(), in which is used
> without being properly initialized previously.
>
> Fix this by initializing variable *resp_buftype*
There is a potential execution path in which variable *resp_buftype*
is passed as an argument to function free_rsp_buf(), in which is used
without being properly initialized previously.
Fix this by initializing variable *resp_buftype* to -1 in order to
avoid unpredictable or unintended results.
There is a potential execution path in which variable *resp_buftype*
is passed as an argument to function free_rsp_buf(), in which is used
without being properly initialized previously.
Fix this by initializing variable *resp_buftype* to -1 in order to
avoid unpredictable or unintended results.
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in glibc,
>> the question came up if we will ever care about baud rates in excess of
>> 4
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in glibc,
>> the question came up if we will ever care about baud rates in excess of
>> 4
Hi Bjorn,
On Tue, 2018-10-09 at 12:56 -0500, Bjorn Helgaas wrote:
> On Tue, Sep 04, 2018 at 12:33:09PM -0600, Jon Derrick wrote:
> > During probe, the port driver will disable error reporting and
> > assumes
> > it will be enabled later by the AER driver's pci_walk_bus()
> > sequence.
> > This
Hi Bjorn,
On Tue, 2018-10-09 at 12:56 -0500, Bjorn Helgaas wrote:
> On Tue, Sep 04, 2018 at 12:33:09PM -0600, Jon Derrick wrote:
> > During probe, the port driver will disable error reporting and
> > assumes
> > it will be enabled later by the AER driver's pci_walk_bus()
> > sequence.
> > This
On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
>
On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
>
Quoting Doug Anderson (2018-10-09 10:48:55)
>
> Ah, you're suggesting separating the platform_get_irq() and the
> request_irq() so that we call platform_get_irq() as the first thing in
> the function but don't do the request_irq() until later. Yeah, that
> could be done and I guess if you feel
Quoting Doug Anderson (2018-10-09 10:48:55)
>
> Ah, you're suggesting separating the platform_get_irq() and the
> request_irq() so that we call platform_get_irq() as the first thing in
> the function but don't do the request_irq() until later. Yeah, that
> could be done and I guess if you feel
On Tue, 2018-10-09 at 22:38 +0300, Laurent Pinchart wrote:
> Hi Josh,
>
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
> > On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> > > Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> > > > On Sat, Oct 06, 2018
On Tue, 2018-10-09 at 22:38 +0300, Laurent Pinchart wrote:
> Hi Josh,
>
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
> > On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> > > Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> > > > On Sat, Oct 06, 2018
In case memory resources for *fw* were successfully allocated,
release them before return.
Addresses-Coverity-ID: 1473968 ("Resource leak")
Fixes: 00d70d8e0e78 ("net: phy: mscc: add support for VSC8574 PHY")
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/phy/mscc.c | 4 ++--
1 file changed,
In case memory resources for *fw* were successfully allocated,
release them before return.
Addresses-Coverity-ID: 1473968 ("Resource leak")
Fixes: 00d70d8e0e78 ("net: phy: mscc: add support for VSC8574 PHY")
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/phy/mscc.c | 4 ++--
1 file changed,
Hi Josh,
On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> > Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> >> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> >>> The current code of
Currently, the error handling for the call to function
phy_read_paged() doesn't work because *reg_val* is of
type u16 (16 bits, unsigned), which makes it impossible
for it to hold a value less than 0.
Fix this by changing the type of variable *reg_val* to int.
Addresses-Coverity-ID: 1473970
Hi Josh,
On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> > Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> >> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> >>> The current code of
Currently, the error handling for the call to function
phy_read_paged() doesn't work because *reg_val* is of
type u16 (16 bits, unsigned), which makes it impossible
for it to hold a value less than 0.
Fix this by changing the type of variable *reg_val* to int.
Addresses-Coverity-ID: 1473970
This patchset aims to fix a signedness bug in function
vsc85xx_downshift_get() and a memory leak in function
vsc8574_config_pre_init().
Thanks
Gustavo A. R. Silva (2):
net: phy: mscc: fix signedness bug in vsc85xx_downshift_get
net: phy: mscc: fix memory leak in vsc8574_config_pre_init
This patchset aims to fix a signedness bug in function
vsc85xx_downshift_get() and a memory leak in function
vsc8574_config_pre_init().
Thanks
Gustavo A. R. Silva (2):
net: phy: mscc: fix signedness bug in vsc85xx_downshift_get
net: phy: mscc: fix memory leak in vsc8574_config_pre_init
Em Tue, Oct 09, 2018 at 05:36:24PM +0300, Alexey Budankov escreveu:
>
> Store -k clockid frequency into Perf trace to enable timestamps
> derived metrics conversion into wall clock time on reporting stage.
>
> Below is the example of perf report output:
Applied, building, lets see this time.
Em Tue, Oct 09, 2018 at 05:36:24PM +0300, Alexey Budankov escreveu:
>
> Store -k clockid frequency into Perf trace to enable timestamps
> derived metrics conversion into wall clock time on reporting stage.
>
> Below is the example of perf report output:
Applied, building, lets see this time.
201 - 300 of 1434 matches
Mail list logo
