One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
On Thu, 23 Aug 2018 07:13:13 -0700
Dmitry Vyukov wrote:
> On Thu, May 10, 2018 at 7:23 AM, Steven Rostedt wrote:
> > On Thu, 10 May 2018 07:14:26 +0200
> > Dmitry Vyukov wrote:
> >
> >> > IMPORTANT: if you fix the bug, please add the following tag to the
> >> > commit:
> >> > Reported-by:
On Thu, 23 Aug 2018 07:13:13 -0700
Dmitry Vyukov wrote:
> On Thu, May 10, 2018 at 7:23 AM, Steven Rostedt wrote:
> > On Thu, 10 May 2018 07:14:26 +0200
> > Dmitry Vyukov wrote:
> >
> >> > IMPORTANT: if you fix the bug, please add the following tag to the
> >> > commit:
> >> > Reported-by:
>-Original Message-
>From: Dmitry Torokhov
>Sent: Thursday, August 23, 2018 5:08 PM
>To: Mark Brown
>Cc: Ryan Lee ; Liam Girdwood
>; Jaroslav Kysela ; Takashi Iwai
>; Kuninori Morimoto ;
>alsa-de...@alsa-project.org; lkml ;
>ryan.lee.ma...@gmail.com
>Subject: Re: [PATCH] ASoC: max98373:
>-Original Message-
>From: Dmitry Torokhov
>Sent: Thursday, August 23, 2018 5:08 PM
>To: Mark Brown
>Cc: Ryan Lee ; Liam Girdwood
>; Jaroslav Kysela ; Takashi Iwai
>; Kuninori Morimoto ;
>alsa-de...@alsa-project.org; lkml ;
>ryan.lee.ma...@gmail.com
>Subject: Re: [PATCH] ASoC: max98373:
On Thu, 23 Aug 2018 13:25:34 +0300
Pavel Tikhomirov wrote:
> Then tracing syscall exit event it is extremely useful to filter exit
> codes equal to some negative value, to react only to required errors.
> But negative numbers does not work:
>
> [root@snorch sys_exit_read]# echo "ret == -1" >
On Thu, 23 Aug 2018 13:25:34 +0300
Pavel Tikhomirov wrote:
> Then tracing syscall exit event it is extremely useful to filter exit
> codes equal to some negative value, to react only to required errors.
> But negative numbers does not work:
>
> [root@snorch sys_exit_read]# echo "ret == -1" >
On Thu, Aug 23, 2018 at 07:03:34PM +0900, Dae R. Jeong wrote:
> > Could you test this patch? I found that bug a month ago but didn't submit
> > yet.
>
> I don't have a reproducer now. I manually analzed a root cause of the
> crash using a fuzzer's log. The log reported a race on 'alloc->vma'.
>
On Thu, Aug 23, 2018 at 07:03:34PM +0900, Dae R. Jeong wrote:
> > Could you test this patch? I found that bug a month ago but didn't submit
> > yet.
>
> I don't have a reproducer now. I manually analzed a root cause of the
> crash using a fuzzer's log. The log reported a race on 'alloc->vma'.
>
On Thu, 23 Aug 2018 09:31:09 +
Tiejun Chen wrote:
> Steven,
>
> commit 7f11a591bbdb111792298144c3476506aa7f1ca8 (HEAD ->
> v4.14.63-rt40-rebase, tag: v4.14.63-rt40-rebase, origin/v4.14-rt-rebase)
> Author: Steven Rostedt (VMware)
> Date: Wed May 16 09:33:00 2018 -0400
>
> Linux
On Thu, 23 Aug 2018 09:31:09 +
Tiejun Chen wrote:
> Steven,
>
> commit 7f11a591bbdb111792298144c3476506aa7f1ca8 (HEAD ->
> v4.14.63-rt40-rebase, tag: v4.14.63-rt40-rebase, origin/v4.14-rt-rebase)
> Author: Steven Rostedt (VMware)
> Date: Wed May 16 09:33:00 2018 -0400
>
> Linux
On Thu, Aug 23, 2018 at 12:26:10PM -0400, Waiman Long wrote:
> Running the AIM7 fserver workload on a 2-socket 24-core 48-thread
> Broadwell system, it was found that there were severe spinlock contention
> in the XFS code. In particular, native_queued_spin_lock_slowpath()
> consumes 69.7% of cpu
On Thu, Aug 23, 2018 at 12:26:10PM -0400, Waiman Long wrote:
> Running the AIM7 fserver workload on a 2-socket 24-core 48-thread
> Broadwell system, it was found that there were severe spinlock contention
> in the XFS code. In particular, native_queued_spin_lock_slowpath()
> consumes 69.7% of cpu
David Rientjes wrote:
> On Fri, 24 Aug 2018, Tetsuo Handa wrote:
>
> > > For those of us who are tracking CVE-2016-10723 which has peristently
> > > been
> > > labeled as "disputed" and with no clear indication of what patches
> > > address
> > > it, I am assuming that commit 9bfe5ded054b
David Rientjes wrote:
> On Fri, 24 Aug 2018, Tetsuo Handa wrote:
>
> > > For those of us who are tracking CVE-2016-10723 which has peristently
> > > been
> > > labeled as "disputed" and with no clear indication of what patches
> > > address
> > > it, I am assuming that commit 9bfe5ded054b
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
The mm-of-the-moment snapshot 2018-08-23-17-26 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-08-23-17-26 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code [1].
It is assumed that commas in objdump comments could occur in other arches
now or in the future, so this fix is arch-independent.
The fix could have been
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code [1].
It is assumed that commas in objdump comments could occur in other arches
now or in the future, so this fix is arch-independent.
The fix could have been
On Thu, Aug 23, 2018 at 10:51:07AM +0100, Mark Brown wrote:
> On Wed, Aug 22, 2018 at 05:31:04PM -0700, Dmitry Torokhov wrote:
> > On Wed, Aug 22, 2018 at 5:21 PM Ryan Lee
> > wrote:
> > > + mdelay(10);
>
> > Is it really necessary for the CPU to spin for 10msec here?
> > usleep_range()
On Thu, Aug 23, 2018 at 10:51:07AM +0100, Mark Brown wrote:
> On Wed, Aug 22, 2018 at 05:31:04PM -0700, Dmitry Torokhov wrote:
> > On Wed, Aug 22, 2018 at 5:21 PM Ryan Lee
> > wrote:
> > > + mdelay(10);
>
> > Is it really necessary for the CPU to spin for 10msec here?
> > usleep_range()
(CCed related people)
Hi Mizuma-san,
Thank you for the report.
The mentioned patch was created based on feedbacks from reviewers/maintainers,
so I'd like to hear from them about how we should handle the issue.
And one note is that there is a follow-up patch for "x86/e820: put
!E820_TYPE_RAM
(CCed related people)
Hi Mizuma-san,
Thank you for the report.
The mentioned patch was created based on feedbacks from reviewers/maintainers,
so I'd like to hear from them about how we should handle the issue.
And one note is that there is a follow-up patch for "x86/e820: put
!E820_TYPE_RAM
On Fri, 24 Aug 2018 00:27:05 +0100
Will Deacon wrote:
> Hi Linus,
>
> On Thu, Aug 23, 2018 at 12:37:58PM -0700, Linus Torvalds wrote:
> > On Thu, Aug 23, 2018 at 12:15 PM Linus Torvalds
> > wrote:
> > >
> > > So right now my "tlb-fixes" branch looks like this:
> > > [..]
> > >
> > > I'll do
On Fri, 24 Aug 2018 00:27:05 +0100
Will Deacon wrote:
> Hi Linus,
>
> On Thu, Aug 23, 2018 at 12:37:58PM -0700, Linus Torvalds wrote:
> > On Thu, Aug 23, 2018 at 12:15 PM Linus Torvalds
> > wrote:
> > >
> > > So right now my "tlb-fixes" branch looks like this:
> > > [..]
> > >
> > > I'll do
On Thu, Aug 23, 2018 at 1:51 PM, Ghannam, Yazen wrote:
>> -Original Message-
>> From: Michael Jin
>> Sent: Thursday, August 16, 2018 2:29 PM
>> To: Borislav Petkov ; Ghannam, Yazen
>> ; Mauro Carvalho Chehab
>>
>> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
On Thu, Aug 23, 2018 at 1:51 PM, Ghannam, Yazen wrote:
>> -Original Message-
>> From: Michael Jin
>> Sent: Thursday, August 16, 2018 2:29 PM
>> To: Borislav Petkov ; Ghannam, Yazen
>> ; Mauro Carvalho Chehab
>>
>> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
On Thu, 23 Aug 2018 12:15:37 -0700
Linus Torvalds wrote:
> On Thu, Aug 23, 2018 at 1:47 AM Nicholas Piggin wrote:
> >
> > These are split from some patches I posted a while back, I was going
> > to take a look and revive the series again after your fixes go in,
> > but having another look, it
On Thu, 23 Aug 2018 12:15:37 -0700
Linus Torvalds wrote:
> On Thu, Aug 23, 2018 at 1:47 AM Nicholas Piggin wrote:
> >
> > These are split from some patches I posted a while back, I was going
> > to take a look and revive the series again after your fixes go in,
> > but having another look, it
For real now...
On Thu, Aug 23, 2018 at 04:32:11PM -0700, Dmitry Torokhov wrote:
> Let's add Elan folks to the discussion.
>
> On Thu, Aug 23, 2018 at 04:30:28PM -0700, Dmitry Torokhov wrote:
> > Hi Derek,
> >
> > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
> > > We only
For real now...
On Thu, Aug 23, 2018 at 04:32:11PM -0700, Dmitry Torokhov wrote:
> Let's add Elan folks to the discussion.
>
> On Thu, Aug 23, 2018 at 04:30:28PM -0700, Dmitry Torokhov wrote:
> > Hi Derek,
> >
> > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
> > > We only
Let's add Elan folks to the discussion.
On Thu, Aug 23, 2018 at 04:30:28PM -0700, Dmitry Torokhov wrote:
> Hi Derek,
>
> On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
> > We only need to wait 10ms instead of 30ms before starting fastboot or
> > sending IAP on the touchscreen.
Let's add Elan folks to the discussion.
On Thu, Aug 23, 2018 at 04:30:28PM -0700, Dmitry Torokhov wrote:
> Hi Derek,
>
> On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
> > We only need to wait 10ms instead of 30ms before starting fastboot or
> > sending IAP on the touchscreen.
On Wed, Aug 22, 2018 at 05:55:27PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If
On Wed, Aug 22, 2018 at 05:55:27PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If
On Thu, 2018-08-23 at 16:12 -0700, Nick Desaulniers wrote:
> On Thu, Aug 23, 2018 at 2:19 PM Joe Perches wrote:
> >
> > On Thu, 2018-08-23 at 14:03 -0700, Nick Desaulniers wrote:
> > > One reply for a bunch of the various threads, to keep the number of
> > > emails down:
> > >
> > > On Wed,
On Thu, 2018-08-23 at 16:12 -0700, Nick Desaulniers wrote:
> On Thu, Aug 23, 2018 at 2:19 PM Joe Perches wrote:
> >
> > On Thu, 2018-08-23 at 14:03 -0700, Nick Desaulniers wrote:
> > > One reply for a bunch of the various threads, to keep the number of
> > > emails down:
> > >
> > > On Wed,
Hi Derek,
On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
> We only need to wait 10ms instead of 30ms before starting fastboot or
> sending IAP on the touchscreen. Also, instead of delaying everytime
> sw_reset is called, this delays 10ms in the function that starts
> fastboot.
Hi Derek,
On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote:
> We only need to wait 10ms instead of 30ms before starting fastboot or
> sending IAP on the touchscreen. Also, instead of delaying everytime
> sw_reset is called, this delays 10ms in the function that starts
> fastboot.
Hi Linus,
On Thu, Aug 23, 2018 at 12:37:58PM -0700, Linus Torvalds wrote:
> On Thu, Aug 23, 2018 at 12:15 PM Linus Torvalds
> wrote:
> >
> > So right now my "tlb-fixes" branch looks like this:
> > [..]
> >
> > I'll do a few more test builds and boots, but I think I'm going to
> > merge it in
Hi Linus,
On Thu, Aug 23, 2018 at 12:37:58PM -0700, Linus Torvalds wrote:
> On Thu, Aug 23, 2018 at 12:15 PM Linus Torvalds
> wrote:
> >
> > So right now my "tlb-fixes" branch looks like this:
> > [..]
> >
> > I'll do a few more test builds and boots, but I think I'm going to
> > merge it in
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add
additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add
additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.
Commit 06c5040cdb13 ("kbuild: enable 'make
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add
additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add
additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.
Commit 06c5040cdb13 ("kbuild: enable 'make
Since commit 0fbe9a245c60 ("microblaze: add endianness options to
LDFLAGS instead of LD"), you cannot build the kernel for microblaze
with CONFIG_DYNAMIC_FTRACE.
Fixes: 0fbe9a245c60 ("microblaze: add endianness options to LDFLAGS instead of
LD")
Signed-off-by: Masahiro Yamada
---
Changes in
Since commit 0fbe9a245c60 ("microblaze: add endianness options to
LDFLAGS instead of LD"), you cannot build the kernel for microblaze
with CONFIG_DYNAMIC_FTRACE.
Fixes: 0fbe9a245c60 ("microblaze: add endianness options to LDFLAGS instead of
LD")
Signed-off-by: Masahiro Yamada
---
Changes in
Hi all,
Today's linux-next merge of the nios2 tree got a conflict in:
arch/nios2/Kconfig.debug
between commit:
06ec64b84c35 ("Kconfig: consolidate the "Kernel hacking" menu")
from Linus' tree and commit:
93bdd8902339 ("nios2: kconfig: remove duplicate DEBUG_STACK_USAGE symbol
Hi all,
Today's linux-next merge of the nios2 tree got a conflict in:
arch/nios2/Kconfig.debug
between commit:
06ec64b84c35 ("Kconfig: consolidate the "Kernel hacking" menu")
from Linus' tree and commit:
93bdd8902339 ("nios2: kconfig: remove duplicate DEBUG_STACK_USAGE symbol
On Thu, Aug 23, 2018 at 4:06 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 4:06 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Wed, Aug 22 2018, NeilBrown wrote:
>
> Oh dear.
> nfs4_alloc_lockdata contains:
> memcpy(>fl, fl, sizeof(p->fl));
>
> so any list_heads that are valid in fl will be invalid in p->fl.
>
> Maybe I should initialize the relevant list_heads at the start of wait
> functions.
> I should look
On Wed, Aug 22 2018, NeilBrown wrote:
>
> Oh dear.
> nfs4_alloc_lockdata contains:
> memcpy(>fl, fl, sizeof(p->fl));
>
> so any list_heads that are valid in fl will be invalid in p->fl.
>
> Maybe I should initialize the relevant list_heads at the start of wait
> functions.
> I should look
On Thu, Aug 23, 2018 at 4:04 PM Evan Green wrote:
>
> On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
> wrote:
> >
> > From: Channagoud Kadabi
Also checkpatch.pl complains a bit about this patch:
WARNING: Non-standard signature: Co-developed-by:
#14:
On Thu, Aug 23, 2018 at 4:04 PM Evan Green wrote:
>
> On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
> wrote:
> >
> > From: Channagoud Kadabi
Also checkpatch.pl complains a bit about this patch:
WARNING: Non-standard signature: Co-developed-by:
#14:
On Thu, Aug 23, 2018 at 2:19 PM Joe Perches wrote:
>
> On Thu, 2018-08-23 at 14:03 -0700, Nick Desaulniers wrote:
> > One reply for a bunch of the various threads, to keep the number of emails
> > down:
> >
> > On Wed, Aug 22, 2018 at 5:20 PM Joe Perches wrote:
> > > On Wed, 2018-08-22 at 16:37
On Thu, Aug 23, 2018 at 2:19 PM Joe Perches wrote:
>
> On Thu, 2018-08-23 at 14:03 -0700, Nick Desaulniers wrote:
> > One reply for a bunch of the various threads, to keep the number of emails
> > down:
> >
> > On Wed, Aug 22, 2018 at 5:20 PM Joe Perches wrote:
> > > On Wed, 2018-08-22 at 16:37
We only need to wait 10ms instead of 30ms before starting fastboot or
sending IAP on the touchscreen. Also, instead of delaying everytime
sw_reset is called, this delays 10ms in the function that starts
fastboot. There's also an explicit 20ms delay before sending IAP when
updating the firmware, so
We only need to wait 10ms instead of 30ms before starting fastboot or
sending IAP on the touchscreen. Also, instead of delaying everytime
sw_reset is called, this delays 10ms in the function that starts
fastboot. There's also an explicit 20ms delay before sending IAP when
updating the firmware, so
On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
wrote:
>
> Cache error reporting controller is to detect and report single
Should be "Cache error reporting controller detects and reports single"...
Other than that:
Reviewed-by: Evan Green
On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
wrote:
>
> Cache error reporting controller is to detect and report single
Should be "Cache error reporting controller detects and reports single"...
Other than that:
Reviewed-by: Evan Green
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
wrote:
>
> From: Channagoud Kadabi
>
> Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
> Errors (DBEs). As of now, this driver supports erp for Last Level Cache
> Controller (LLCC). This driver takes care of
On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
wrote:
>
> From: Channagoud Kadabi
>
> Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
> Errors (DBEs). As of now, this driver supports erp for Last Level Cache
> Controller (LLCC). This driver takes care of
In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single interrupt call. It happens much more in multi-master
environment than single-master. For an example,
In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single interrupt call. It happens much more in multi-master
environment than single-master. For an example,
On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
wrote:
>
> Currently, boradcast base is set to end of the LLCC banks, which may
s/boradcast/broadcast/
> not be correct always. As the number of banks may vary for each chipset
> and the broadcast base could be at a different address
On Fri, Aug 17, 2018 at 5:08 PM Venkata Narendra Kumar Gutta
wrote:
>
> Currently, boradcast base is set to end of the LLCC banks, which may
s/boradcast/broadcast/
> not be correct always. As the number of banks may vary for each chipset
> and the broadcast base could be at a different address
Perf can record user stack data in response to a synchronous request, such
as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we
end up reading user stack data using __copy_from_user_inatomic() under
set_fs(KERNEL_DS). I think this conflicts with the intention of using
Perf can record user stack data in response to a synchronous request, such
as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we
end up reading user stack data using __copy_from_user_inatomic() under
set_fs(KERNEL_DS). I think this conflicts with the intention of using
On Thu, 23 Aug 2018 14:29:34 +0200
Martin Liška wrote:
> The patch changes interpretation of:
> callq *0x8(%rbx)
>
> from:
> 0.26 │ → callq *8
> to:
> 0.26 │ → callq *0x8(%rbx)
>
> in this can an address is followed by a register, thus
> one can't parse only address.
>
>
On Thu, 23 Aug 2018 14:29:34 +0200
Martin Liška wrote:
> The patch changes interpretation of:
> callq *0x8(%rbx)
>
> from:
> 0.26 │ → callq *8
> to:
> 0.26 │ → callq *0x8(%rbx)
>
> in this can an address is followed by a register, thus
> one can't parse only address.
>
>
Hi
On 07/31/2018 05:52 PM, Frederic Weisbecker wrote:
> Before updating the full nohz tick or the idle time on IRQ exit, we
> check first if we are not in a nesting interrupt, whether the inner
> interrupt is a hard or a soft IRQ.
>
> There is a historical reason for that: the dyntick idle mode
Hi
On 07/31/2018 05:52 PM, Frederic Weisbecker wrote:
> Before updating the full nohz tick or the idle time on IRQ exit, we
> check first if we are not in a nesting interrupt, whether the inner
> interrupt is a hard or a soft IRQ.
>
> There is a historical reason for that: the dyntick idle mode
On Fri, 24 Aug 2018, Tetsuo Handa wrote:
> > For those of us who are tracking CVE-2016-10723 which has peristently been
> > labeled as "disputed" and with no clear indication of what patches address
> > it, I am assuming that commit 9bfe5ded054b ("mm, oom: remove sleep from
> > under
On Fri, 24 Aug 2018, Tetsuo Handa wrote:
> > For those of us who are tracking CVE-2016-10723 which has peristently been
> > labeled as "disputed" and with no clear indication of what patches address
> > it, I am assuming that commit 9bfe5ded054b ("mm, oom: remove sleep from
> > under
Hi all,
Today's linux-next merge of the mips tree got a conflict in:
include/linux/compiler_types.h
between commit:
815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
exclusive")
from Linus' tree and commit:
04f264d3a8b0 ("compiler.h: Allow arch-specific
Hi all,
Today's linux-next merge of the mips tree got a conflict in:
include/linux/compiler_types.h
between commit:
815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
exclusive")
from Linus' tree and commit:
04f264d3a8b0 ("compiler.h: Allow arch-specific
Nick Desaulniers wrote on Thu, Aug 23, 2018:
> > On a side note, I noticed tools/include/linux/compiler.h includes
> > linux/compiler-gcc.h but maybe it should include linux/compiler_types.h?
> > (I'm not sure at who uses that header, so it really is an open question
> > here)
>
> Without looking
Nick Desaulniers wrote on Thu, Aug 23, 2018:
> > On a side note, I noticed tools/include/linux/compiler.h includes
> > linux/compiler-gcc.h but maybe it should include linux/compiler_types.h?
> > (I'm not sure at who uses that header, so it really is an open question
> > here)
>
> Without looking
On Thu, Aug 23, 2018 at 10:05:20PM +0200, Michal Hocko wrote:
> On Thu 23-08-18 12:38:33, Andi Kleen wrote:
> > > There are people who care about L1TF mitigations. I am not going to
> > > question their motivation. In any case a hint how to make the mitigation
> > > active again sounds more useful
On Thu, Aug 23, 2018 at 10:05:20PM +0200, Michal Hocko wrote:
> On Thu 23-08-18 12:38:33, Andi Kleen wrote:
> > > There are people who care about L1TF mitigations. I am not going to
> > > question their motivation. In any case a hint how to make the mitigation
> > > active again sounds more useful
On 8/23/18 3:56 PM, Kees Cook wrote:
>>
>> - clk_data = kzalloc(sizeof(*clk_data) + (sizeof(*clk_data->hws) * 2),
>> - GFP_KERNEL);
>> + clk_data = kzalloc(struct_size(clk_data, hws, 2), GFP_KERNEL);
>> if (!clk_data) {
>>
On 8/23/18 3:56 PM, Kees Cook wrote:
>>
>> - clk_data = kzalloc(sizeof(*clk_data) + (sizeof(*clk_data->hws) * 2),
>> - GFP_KERNEL);
>> + clk_data = kzalloc(struct_size(clk_data, hws, 2), GFP_KERNEL);
>> if (!clk_data) {
>>
On Thu, Aug 23, 2018 at 11:51 AM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 11:51 AM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 12:33 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 12:33 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
If gcc (e.g. 4.1.2) decides not to inline init_mtd_structs() and
read_id_reg(), this will cause section mismatches, and crashes:
WARNING: drivers/mtd/nand/raw/docg4.o(.text+0xc10): Section mismatch in
reference from the function docg4_attach_chip() to the function
If gcc (e.g. 4.1.2) decides not to inline init_mtd_structs() and
read_id_reg(), this will cause section mismatches, and crashes:
WARNING: drivers/mtd/nand/raw/docg4.o(.text+0xc10): Section mismatch in
reference from the function docg4_attach_chip() to the function
On 8/23/2018 2:18 PM, Brendan Higgins wrote:
On Thu, Aug 23, 2018 at 1:56 PM Jae Hyun Yoo
wrote:
In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single
On 8/23/2018 2:18 PM, Brendan Higgins wrote:
On Thu, Aug 23, 2018 at 1:56 PM Jae Hyun Yoo
wrote:
In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single
On Thu, Aug 23, 2018 at 8:21 PM John Johansen
wrote:
>
> On 08/23/2018 07:09 AM, Arnd Bergmann wrote:
>
> thank you for the patch, but a fix for this issue was pushed to apparmor-next
> yesterday
>
Ok, good. As several people pointed out, my patch was also wrong, so that
saves me doing another
On Thu, Aug 23, 2018 at 8:21 PM John Johansen
wrote:
>
> On 08/23/2018 07:09 AM, Arnd Bergmann wrote:
>
> thank you for the patch, but a fix for this issue was pushed to apparmor-next
> yesterday
>
Ok, good. As several people pointed out, my patch was also wrong, so that
saves me doing another
With gcc 4.1.2:
drivers/tty/serial/qcom_geni_serial.c: In function ‘qcom_geni_serial_probe’:
drivers/tty/serial/qcom_geni_serial.c:1261: warning: ‘drv’ may be used
uninitialized in this function
Indeed, if dev.of_node is NULL, drv will be used uninitialized, and
dereferenced in
With gcc 4.1.2:
drivers/tty/serial/qcom_geni_serial.c: In function ‘qcom_geni_serial_probe’:
drivers/tty/serial/qcom_geni_serial.c:1261: warning: ‘drv’ may be used
uninitialized in this function
Indeed, if dev.of_node is NULL, drv will be used uninitialized, and
dereferenced in
101 - 200 of 2464 matches
Mail list logo
