On 07.08.24 17:49, Steven Rostedt wrote:
> [...]
>
> So I could use destroy_inode() for the removing of the link list, and then
> free_inode to free it. Something like:
>
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index 1028ab6d9a74..ae2cb2221acd 100644
> --- a/fs/tracefs/inode.c
>
On 07.08.24 15:44, Al Viro wrote:
> On Wed, Aug 07, 2024 at 09:35:45AM -0400, Steven Rostedt wrote:
>
>> Perhaps:
>>
>> diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
>> index f704d8348357..ab6d6c3d835d 100644
>> --- a/fs/tracefs/internal.h
>> +++ b/fs/tracefs/internal.h
>> @@ -10,12 +
On 07.08.24 15:35, Steven Rostedt wrote:
> On Wed, 7 Aug 2024 13:51:39 +0200
> Mathias Krause wrote:
>
>> diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
>> index f704d8348357..a7769857962a 100644
>> --- a/fs/tracefs/internal.h
>> +++ b/fs/trac
kgid_t i_gid;
unsigned inti_flags;
@@ -690,7 +691,6 @@ struct inode {
u16 i_wb_frn_avg_time;
u16 i_wb_frn_history;
#endif
- struct list_headi_lru; /* inode LRU list */
stru
Kaher
Cc: Al Viro
Fixes: ba37ff75e04b ("eventfs: Implement tracefs_inode_cache")
Signed-off-by: Mathias Krause
---
fs/tracefs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 7c29f4afc23d..a9279810158c 100644
--- a/
may also be the cause for what
Ilkka is seeing[1].
Please apply!
Thanks,
Mathias
[1]
https://lore.kernel.org/all/cae4varezy+a2pvqjyjbfh8dwb4op7kuczg-e28h22xywob1...@mail.gmail.com/
Mathias Krause (2):
tracefs: Fix inode allocation
tracefs: Don't overlay 'struct inode'
ot;eventfs/tracing: Add callback for release of an
>> eventfs_inode")
>> Reported-by: Mathias Krause
>> Tested-by: Mathias Krause
>
> Hi Mathias,
>
> I kept your "Tested-by" tag because you did test the part that fixes the
> bug you reported. I j
On 26.07.24 16:52, Steven Rostedt wrote:
> On Fri, 26 Jul 2024 12:16:16 +0200
> Mathias Krause wrote:
>
>>>
>>> With KASAN memory checking, it would trigger a use-after-free bug. This was
>>>
>>
>> The UAF bug is there even without KASAN. It
event itself. Not the meta data to free. This would either cause a
> memory leak (the meta data never was freed) or a crash as it could have
> incorrectly freed the event itself.
>
> Link:
> https://lore.kernel.org/all/20240719204701.1605950-1-mini...@grsecurity.net/
>
> Cc: sta...@vger.ker
On 26.07.24 01:06, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 23:32:30 +0200
> Mathias Krause wrote:
>
>> That was for a single run of
>> tools/testing/selftests/user_events/ftrace_test with the read loop of
>> /sys/kernel/tracing/events/user_events/__test_event/for
On 25.07.24 22:15, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 21:42:41 +0200
> Mathias Krause wrote:
>
>> Right. But the point is, that 'event_call' is really some '&user->call'.
>> With 'user' being free'd memory, what gives? Der
On 25.07.24 21:05, Steven Rostedt wrote:
> Here's the proper fix:
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 6ef29eba90ce..3a2d2ff1625b 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -3140,8 +3140,10 @@ EXPORT_SYMBOL_GPL(
On 25.07.24 21:05, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 20:12:33 +0200
> Mathias Krause wrote:
>>>> @@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t bytes, struct
>>>> iov_iter *i)
>>>> static struct list_head *user_event_get_
On 25.07.24 19:16, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 13:10:21 -0400
> Steven Rostedt wrote:
>>
>> diff --git a/kernel/trace/trace_events_user.c
>> b/kernel/trace/trace_events_user.c
>> index 3a2b46847c8b..e9ed2826ff46 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trac
lds
Fixes: 43aa6f97c2d0 ("eventfs: Get rid of dentry pointers without refcounts")
Signed-off-by: Mathias Krause
---
fs/tracefs/event_inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index a9c28a1d5dc8..01e99e98457d 100
On 23.07.24 16:43, Steven Rostedt wrote:
> On Fri, 19 Jul 2024 22:47:01 +0200
> Mathias Krause wrote:
>
>> Beside the obvious bug, I noticed the following (not fixing the issue,
>> tho):
>>
>> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
&g
tfs: Test for ei->is_freed when accessing ei->dentry")
Reviewed-by: Dan Carpenter
Reviewed-by: Ajay Kaher
Signed-off-by: Mathias Krause
---
v2: send as a separate patch, picking up review tags from Dan and Ajay
fs/tracefs/event_inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
xpect it to either return a valid pointer or an error pointer,
at least since commit 5264a2f4bb3b ("tracing: Fix a NULL vs IS_ERR() bug
in event_subsystem_dir()"). Returning NULL will therefore fail the error
condition check in the caller.
Fix this by substituting the NULL return value
On 08.09.23 17:02, Saurabh Singh Sengar wrote:
> On Fri, Sep 08, 2023 at 12:26:10PM +0200, Mathias Krause wrote:
>> Booting a CONFIG_HYPERV_VTL_MODE=y enabled kernel on bare metal or a
>> non-Hyper-V hypervisor leads to serve memory corruption as
>
> FWIW, CONFIG_HYPERV_VTL
Hi Jessica,
On Mon, 21 Jan 2019 at 12:39, Mathias Krause wrote:
>
> On Wed, 2 Jan 2019 at 21:29, Jessica Yu wrote:
> >
> > +++ Mathias Krause [30/12/18 13:40 +0100]:
> > >The reference to '__vermagic' is a relict from v2.5 times. And even
> > >the
On Wed, 2 Jan 2019 at 21:29, Jessica Yu wrote:
>
> +++ Mathias Krause [30/12/18 13:40 +0100]:
> >The reference to '__vermagic' is a relict from v2.5 times. And even
> >there it had a very short life time, from v2.5.59 (commit 1d411b80ee18
> >("Module
er current kernels nor modules contain a '__vermagic' section any
more, so get rid of it.
Signed-off-by: Mathias Krause
Cc: Rusty Russell
Cc: Jessica Yu
---
include/asm-generic/vmlinux.lds.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-
es for 32 bit builds or 256 bytes for 64 bit
builds.
Fix this by switching to '.balign' instead which is consistent
across all architectures.
Signed-off-by: Mathias Krause
Cc: Catalin Marinas
Cc: Will Deacon
---
scripts/kallsyms.c | 4 ++--
1 file changed, 2 insertions(+), 2 dele
On 9 March 2018 at 13:21, Andreas Christoforou
wrote:
> The kernel would like to have all stack VLA usage removed[1].
>
> Signed-off-by: Andreas Christoforou
> ---
> net/ipv6/xfrm6_state.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/xfrm6_state.c b/ne
Commit-ID: 6b32c126d33d5cb379bca280ab8acedc1ca978ff
Gitweb: https://git.kernel.org/tip/6b32c126d33d5cb379bca280ab8acedc1ca978ff
Author: Mathias Krause
AuthorDate: Thu, 5 Oct 2017 20:30:12 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 9 Oct 2017 13:35:17 +0200
x86/alternatives: Fix
quot; value of -1 for the < operator ... *sigh*
Btw., the one in asm/alternative-asm.h is correct. And, apparently,
all current users of ALTERNATIVE_2() pass same sized alternatives,
avoiding to hit the bug.
[1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
Fixes: dbe40
On 5 October 2017 at 14:52, Michael Matz wrote:
> On Thu, 5 Oct 2017, Borislav Petkov wrote:
>> On Thu, Oct 05, 2017 at 02:35:33PM +0200, Mathias Krause wrote:
>> > Note the "<"! ...comment is wrong, though the implementation works!
>>
>> I know, I reali
On 5 October 2017 at 09:58, Mathias Krause wrote:
> On 5 October 2017 at 09:38, Borislav Petkov wrote:
>> On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote:
>>> diff --git a/arch/x86/include/asm/alternative.h
>>> b/arch/x86/include/asm/alternati
On 5 October 2017 at 09:38, Borislav Petkov wrote:
> On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote:
>> The alt_max_short() macro in asm/alternative.h does not work as
>> intended, leading to nasty bugs. E.g. alt_max_short("1", "3")
>>
quot; value of -1 for the < operator ... *sigh*
Btw., the one in asm/alternative-asm.h is correct. And, apparently,
all current users of ALTERNATIVE_2() pass same sized alternatives,
avoiding to hit the bug.
[1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
Fixes: dbe4058a6
Commit-ID: c06989da39cdb10604d572c8c7ea8c8c97f3c483
Gitweb: http://git.kernel.org/tip/c06989da39cdb10604d572c8c7ea8c8c97f3c483
Author: Mathias Krause
AuthorDate: Mon, 10 Apr 2017 17:14:27 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 10 Apr 2017 18:31:41 +0200
x86/vdso: Ensure
On 7 April 2017 at 15:14, Thomas Gleixner wrote:
> On Fri, 7 Apr 2017, Mathias Krause wrote:
>> On 7 April 2017 at 11:46, Thomas Gleixner wrote:
>> > Whether protected by preempt_disable or local_irq_disable, to make that
>> > work it needs CR0 handling in the excepti
On 7 April 2017 at 11:46, Thomas Gleixner wrote:
> On Fri, 7 Apr 2017, Mathias Krause wrote:
>> On 6 April 2017 at 17:59, Andy Lutomirski wrote:
>> > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote:
>> >> static __always_inline rare_write_begin(void)
>
On 6 April 2017 at 17:59, Andy Lutomirski wrote:
> On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote:
>> On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote:
>>> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote:
On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski
wrote:
> On Wed, M
utomirski
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Roland McGrath
Signed-off-by: Mathias Krause
---
arch/x86/entry/vdso/vdso32-setup.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32-setup.c
b/arc
It had no use since it's introduction in v2.4.1.2. Get rid of it.
Cc: Mikael Starvik
Signed-off-by: Mathias Krause
Acked-by: Jesper Nilsson
---
Same patch as v1 but as the tip folks took only the x86 parts, I think,
this one should go through the CRIS tree.
Cheers,
Mathias
arch/cris/in
It's unused for ages, used to be required for ksyms.c back in the v1.1
times.
Signed-off-by: Mathias Krause
Acked-by: David S. Miller
---
Hi Dave,
same patch as v1 but as the tip folks took only the x86 parts, I think,
this one should go through the SPARC tree.
Cheers,
Mathias
arch/
Commit-ID: 6415813bae75feba10b8ca3ed6634a72c2a4d313
Gitweb: http://git.kernel.org/tip/6415813bae75feba10b8ca3ed6634a72c2a4d313
Author: Mathias Krause
AuthorDate: Sun, 12 Feb 2017 22:12:08 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:30:24 +0100
x86/cpu: Drop
Commit-ID: 04402116846f36adea9503d7cd5104a7ed27a1a6
Gitweb: http://git.kernel.org/tip/04402116846f36adea9503d7cd5104a7ed27a1a6
Author: Mathias Krause
AuthorDate: Sun, 12 Feb 2017 22:12:07 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 14:30:23 +0100
x86/cpu: Drop
On 14 February 2017 at 22:42, Mathias Krause wrote:
> On 14 February 2017 at 19:13, H. Peter Anvin wrote:
>> On 02/12/17 13:12, Mathias Krause wrote:
>>> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove
>>> CONFIG_X86_WP_WORKS_OK") the kernel won't
On 14 February 2017 at 19:13, H. Peter Anvin wrote:
> On 02/12/17 13:12, Mathias Krause wrote:
>> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove
>> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't working
>> correctly. This makes a
On 14 February 2017 at 17:20, Borislav Petkov wrote:
> On Sun, Feb 12, 2017 at 10:12:09PM +0100, Mathias Krause wrote:
>> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove
>> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't working
>> cor
On 14 February 2017 at 17:17, Borislav Petkov wrote:
> On Sun, Feb 12, 2017 at 10:12:07PM +0100, Mathias Krause wrote:
>> Those member serve no purpose -- not even fill padding for alignment or
>> such. So just get rid of them.
>
> Well, almost. You need the wp_works
rnd Hannemann
Cc: Jeremy Fitzhardinge
Signed-off-by: Mathias Krause
---
arch/x86/include/asm/processor.h |4 +---
arch/x86/kernel/cpu/proc.c |5 ++---
arch/x86/kernel/setup.c | 11 ---
arch/x86/mm/init_32.c|9 +
arch/x86/xen/enlighten.c
It's unused for ages, used to be required for ksyms.c back in the v1.1
times.
Cc: David S. Miller
Signed-off-by: Mathias Krause
---
arch/sparc/include/asm/processor_32.h |6 --
arch/sparc/include/asm/processor_64.h |4
2 files changed, 10 deletions(-)
diff --git a/arch/
s status line in /proc/cpuinfo serves no purpose for quite some
time now, get rid of it.
Cc: Borislav Petkov
Cc: H. Peter Anvin
Signed-off-by: Mathias Krause
---
arch/x86/kernel/cpu/proc.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/ar
The macro TEST_VERIFY_AREA can never be defined as there's no
wp_works_ok variable. So just remove the dead code.
Cc: Geert Uytterhoeven
Signed-off-by: Mathias Krause
---
arch/m68k/mm/sun3mmu.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m6
It had no use since it's introduction in v2.4.1.2. Get rid of it.
Cc: Jesper Nilsson
Cc: Mikael Starvik
Signed-off-by: Mathias Krause
---
arch/cris/include/arch-v10/arch/processor.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/cris/include/arch-v10/arch/processor.h
b
times are long gone, so we can get rid of that ancient hackery.
Therefore patches 4, 5 and 6 are independent of the x86 specific changes
and could be taken by the individual arch maintainers if they prefer to.
Please apply,
Mathias
Mathias Krause (6):
x86: drop unneded members of struct cpuinfo
Those member serve no purpose -- not even fill padding for alignment or
such. So just get rid of them.
Cc: Borislav Petkov
Cc: H. Peter Anvin
Signed-off-by: Mathias Krause
---
arch/x86/include/asm/processor.h |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch
Hi Emese,
On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote:
> I would like to introduce the initify gcc plugin. The kernel already has
> a mechanism to free up code and data memory that is only used during kernel
> or module initialization.
> This plugin will teach the compiler to find
Commit-ID: 67d7a982bab6702d84415ea889996fae72a7d3b2
Gitweb: http://git.kernel.org/tip/67d7a982bab6702d84415ea889996fae72a7d3b2
Author: Mathias Krause
AuthorDate: Tue, 10 May 2016 23:07:02 +0200
Committer: Ingo Molnar
CommitDate: Wed, 11 May 2016 11:14:06 +0200
x86/extable: Ensure
On 11 May 2016 at 07:46, Ard Biesheuvel wrote:
> On 10 May 2016 at 23:07, Mathias Krause wrote:
>> The x86 exception table sorting was changed in commit 29934b0fb8ff
>> ("x86/extable: use generic search and sort routines") to use the arch
>> independent code in li
iding a swap_ex_entry_fixup() macro that takes care of
the 'handler' member.
[1] https://lkml.org/lkml/2016/1/27/232
Signed-off-by: Mathias Krause
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Linus Torvalds
On 28 April 2016 at 23:30, Andrew Morton wrote:
> On Thu, 28 Apr 2016 21:04:18 +0200 Mathias Krause
> wrote:
>
>> If /proc//environ gets read before the envp[] array is fully set
>> up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying
>> to read m
On 28 April 2016 at 23:26, Andrew Morton wrote:
> On Thu, 28 Apr 2016 21:04:18 +0200 Mathias Krause
> wrote:
>
>> If /proc//environ gets read before the envp[] array is fully set
>> up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying
>> to read m
On 28 April 2016 at 21:20, Mateusz Guzik wrote:
> In this case get_cmdline in mm/util.c should also be patched for
> completness. It tests for arg_end, but later accesses env_end.
But it'll do this only when argv[] was modified from what the kernel
initially wrote, which, in turn, either requires
v_end - (env_start + src)' when
env_end is still zero.
Reported-at: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause
Cc: Emese Revfy
Cc: Pax Team
Cc: Al Viro
Cc: Mateusz Guzik
Cc: Alexe
is no longer available. Discussion of
> sanitization was brough up in a thread about CVEs
> (lkml.kernel.org/g/<20160119112812.GA10818@mwanda>)
>
> I eventually expect Kconfig names will want to be changed and or moved if this
> is going to be used for security but that can happen later.
On 2 January 2016 at 03:10, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add kerneldoc comments to acpi_os_map_iomem() and acpi_os_unmap_iomem()
> and explain why the latter needs the __ref annotation in one of them
> (as suggested by Mathias Krause).
>
> Si
On 22 December 2015 at 21:01, Christoph Lameter wrote:
> On Tue, 22 Dec 2015, Mathias Krause wrote:
>
>> How many systems, do you think, are running with enabled DEBUG_SLAB /
>> SLUB_DEBUG in production? Not so many, I'd guess. And the ones running
>> into issues pro
On 22 December 2015 at 18:51, Laura Abbott wrote:
>> [snip]
>>
>> Related to this, have you checked that the sanitization doesn't
>> interfere with the various slab handling schemes, namely RCU related
>> specialties? Not all caches are marked SLAB_DESTROY_BY_RCU, some use
>> call_rcu() instead, i
On 22 December 2015 at 04:40, Laura Abbott wrote:
>
> The SL[AOU]B allocators all behave differently w.r.t. to what happen
> an object is freed. CONFIG_SLAB_SANITIZATION introduces a common
> mechanism to control what happens on free. When this option is
> enabled, objects may be poisoned accordin
On 29 November 2015 at 16:39, Ingo Molnar wrote:
>
> * PaX Team wrote:
>
>> On 29 Nov 2015 at 9:08, Ingo Molnar wrote:
>>
>> >
>> > * PaX Team wrote:
>> >
>> > > i don't see the compile time vs. runtime detection as 'competing'
>> > > approaches,
>> > > both have their own role. [...]
>> >
>> >
On 24 November 2015 at 22:38, Kees Cook wrote:
> Many things are written to only during __init, and never changed
> again. These cannot be made "const" since the compiler will do the wrong
> thing (we do actually need to write to them). Instead, move these items
> into a memory region that will be
he truncation early.
Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause
Cc: Greg Kroah-Hartman
Cc: Petr Mladek
Cc: Alex Elder
Cc: Joe Perches
Cc: Kay Sievers
---
Might be worth to apply to stable, too. Don't know. Prior to co
t; + remove_wait_queue(&unix_sk(other)->peer_wait,
> &u->wait);
> unix_state_unlock(sk);
>
> unix_dgram_disconnected(sk, other);
> @@ -2441,7 +2472,6 @@ static unsigned int unix_dgram_poll(struct f
On Do, Okt 01, 2015 at 08:29:50 -0500, Josh Poimboeuf wrote:
> On Thu, Oct 01, 2015 at 08:10:26AM +0200, mini...@ld-linux.so wrote:
> > On Tue, Sep 22, 2015 at 10:47:04AM -0500, Josh Poimboeuf wrote:
> > > ENTRY(aesni_set_key)
> > > + FRAME_BEGIN
> > > #ifndef __x86_64__
> > > pushl KEYP
> > >
On 30 September 2015 at 15:25, Rainer Weikusat
wrote:
> Mathias Krause writes:
>> On 30 September 2015 at 12:56, Rainer Weikusat
>> wrote:
>>> In case you want some information on this: This is a kernel warning I
>>> could trigger (more than once) on th
On 30 September 2015 at 12:56, Rainer Weikusat
wrote:
> Mathias Krause writes:
>> On 29 September 2015 at 21:09, Jason Baron wrote:
>>> However, if we call connect on socket 's', to connect to a new socket 'o2',
>>> we
>>> drop the refe
On 29 September 2015 at 21:09, Jason Baron wrote:
> However, if we call connect on socket 's', to connect to a new socket 'o2', we
> drop the reference on the original socket 'o'. Thus, we can now close socket
> 'o' without unregistering from epoll. Then, when we either close the ep
> or unregiste
On 14 September 2015 at 04:39, Eric Wong wrote:
> +cc Jason Baron since he might be able to provide more insight into
> epoll.
>
> Mathias Krause wrote:
>> Hi,
>>
>> this is an attempt to resurrect the thread initially started here:
>>
>> http://t
On Tue, Sep 15, 2015 at 06:07:05PM +0100, Rainer Weikusat wrote:
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> -2233,10 +2233,14 static unsigned int
> unix_dgram_poll(struct file *file, struct socket *sock,
> writable = unix_writable(sk);
> other = unix_peer_get(sk)
Hi,
this is an attempt to resurrect the thread initially started here:
http://thread.gmane.org/gmane.linux.network/353003
As that patch fixed the issue for the mentioned reproducer, it did not
fix the bug for the production code Olivier is using. :(
Changing the reproducer only slightly allow
Commit-ID: b1c599b8ff80ea79b9f8277a3f9f36a7b0cfedce
Gitweb: http://git.kernel.org/tip/b1c599b8ff80ea79b9f8277a3f9f36a7b0cfedce
Author: Mathias Krause
AuthorDate: Fri, 24 Jul 2015 09:15:11 +0200
Committer: Ingo Molnar
CommitDate: Fri, 31 Jul 2015 10:34:07 +0200
x86/cpufeature: Add
Commit-ID: 4daa832d99871356f5fdc52372c975e40f73a15e
Gitweb: http://git.kernel.org/tip/4daa832d99871356f5fdc52372c975e40f73a15e
Author: Mathias Krause
AuthorDate: Mon, 20 Jul 2015 18:32:53 +0200
Committer: Ingo Molnar
CommitDate: Mon, 20 Jul 2015 18:57:20 +0200
x86: Drop bogus __ref
legitimate sections mismatches, we better get
rid of them.
Signed-off-by: Mathias Krause
Cc: "Rafael J. Wysocki"
Cc: Paul Gortmaker
Cc: Borislav Petkov
---
v2: squashed all patches into one (as per Ingo)
arch/x86/kernel/acpi/boot.c |8 +---
arch/x86/k
On 20 July 2015 at 09:40, Ingo Molnar wrote:
> * Mathias Krause wrote:
>> arch/x86/kernel/cpu/microcode/core.c|2 +-
>> arch/x86/kernel/cpu/microcode/intel_early.c |2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Please merge this into
Add a CPUID feature bit for the SDBG (Silicon Debug) CPU feature found
on recent Intel systems starting with Haswell.
Using the IA32_DEBUG_INTERFACE MSR (index C80H) one can at least detect
if SDBG has been enabled by the firmware and if it has been used or not.
Signed-off-by: Mathias Krause
Cc
ed the x86 maintainers, just in case...
Please apply or tell me where to send to the patches to instead.
Thanks,
Mathias Krause (2):
cpu: Remove bogus __ref annotation of cpu_subsys_online()
kernel, cpu: Remove bogus __ref annotations
drivers/base/cpu.c |2 +-
kernel/cpu.c
ot wrongly hide section mismatches.
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
Cc: Thomas Gleixner
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Linus Torvalds
---
kernel/cpu.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/cpu.c b/kernel/c
In commit 0db0628d9012 ("kernel: delete __cpuinit usage from all core
kernel files") cpu_up() lost its __cpuinit annotation, vanishing the
need for cpu_subsys_online() to have a __ref annotation. Just drop it
to be able to catch real section mismatches in the future.
Signed-off-by: Math
The __cpuinit annotation was dropped from mc_cpu_callback() in commit
148f9bb87745 ("x86: delete __cpuinit usage from all x86 files"),
vanishing the need for the __refdata annotation of mc_cpu_notifier.
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
Cc: Thomas Gleixner
Cc: H. Peter
Hi Boris,
two small cleanups for wrongly annotated variables / functions. They
used to require that annotation for __cpuinit but as that one is gone
since v3.11 we can drop the __ref / __refdata annotation, too.
Please apply.
Mathias Krause (2):
x86, microcode: Drop bogus __refdata
show_saved_mc() does not reference any .init / .exit sections. Drop the
bogus annotation.
Signed-off-by: Mathias Krause
Cc: Thomas Gleixner
Cc: H. Peter Anvin
Cc: Ingo Molnar
---
Test build with '#define DEBUG'.
arch/x86/kernel/cpu/microcode/intel_early.c |2 +-
1 file
Just drop the unneded __refdata annotations to be able to catch future
section mismatches.
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
---
drivers/acpi/acpi_processor.c |2 +-
drivers/acpi/processor_driver.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
ional error source, hiding legitimate section mismatches.
This series drops the unneeded annotations and adds a comment to the
last legitimate remaining one below drivers/acpi/.
Please apply.
Mathias Krause (2):
ACPI / processor: remove bogus __refdata annotations
ACPI / OSL: add comment for th
Add a comment clarifying the need for the __ref annotation of
acpi_os_unmap_iomem(). It's safe, however, as acpi_early_init() will set
acpi_gbl_permanent_mmap to 1, disabling the problematic branch.
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
---
drivers/acpi/osl.c |3 +++
1
The __cpuinit annotation was dropped from update_clusterinfo() in commit
148f9bb87745 ("x86: delete __cpuinit usage from all x86 files"),
vanishing the need for the __refdata annotation of x2apic_cpu_notifier.
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
---
arch/x86/k
of them.
Please apply.
Mathias Krause (5):
x86, ACPI: Get rid of the acpi_map_cpu() wrapper
x86, apic: Drop bogus __refdata annotation of cpu notifier
x86, cpuid: Drop bogus __refdata annotation of cpu notifier
x86, smpboot: Drop bogus __ref annotation from remove_cpu_from_maps()
x86
The __cpuinit annotation of numa_remove_cpu() was dropped in commit
148f9bb87745 ("x86: delete __cpuinit usage from all x86 files"),
vanishing the need for the __ref annotation of remove_cpu_from_maps().
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
---
arch/x86/kernel/smpboo
The __cpuinit annotation was dropped from acpi_processor_set_pdc()
in commit fe7bf106ebc2 ("acpi: delete __cpuinit usage from all acpi
files"), vanishing the need for the __ref annotated acpi_map_cpu()
wrapper.
Signed-off-by: Mathias Krause
Cc: "Rafael J. Wysocki"
Cc: Paul
The __cpuinit annotation was dropped from cpuid_class_cpu_callback()
in commit 148f9bb87745 ("x86: delete __cpuinit usage from all x86
files"), vanishing the need for the __refdata annotation of
cpuid_class_cpu_notifier.
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
---
arch/
)
lost its __cpuinit annotation in commit ia83048ebd449 ("drivers: delete
__cpuinit usage from all remaining drivers files"), allowing us to drop
the __ref annotation of _debug_hotplug_cpu() and arch_register_cpu().
Signed-off-by: Mathias Krause
Cc: Paul Gortmaker
---
arch/x86/kernel/topology.c
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause
Cc: Yang, Bin
Cc: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/dr
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause
---
drivers/char/ipmi/ipmi_ssif.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 207689c
On 11 May 2015 at 16:33, Jiri Olsa wrote:
> On Mon, May 11, 2015 at 09:35:26AM +, He Kuang wrote:
>> Traceevent plugins need dynamic symbols exported from libtraceevent.a,
>> otherwise a dlopen error will occur during plugins loading.
>>
>> This patch uses dynamic-list-file to export dynamic s
On 18 April 2015 at 17:46, Jiri Olsa wrote:
> On Fri, Apr 17, 2015 at 11:01:07PM +0200, Mathias Krause wrote:
>> On 17 April 2015 at 17:34, Jiri Olsa wrote:
>> > On Sun, Apr 12, 2015 at 06:00:51PM +0200, Mathias Krause wrote:
>> >> When building perf with perl o
On 17 April 2015 at 17:34, Jiri Olsa wrote:
> On Sun, Apr 12, 2015 at 06:00:51PM +0200, Mathias Krause wrote:
>> When building perf with perl or python support it implicitly gets linked
>> with the -export-dynamic linker option through the additional linker
>> flags, namely
valho de Melo
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Signed-off-by: Mathias Krause
---
This patch should go on top of tip.git#perf/core
tools/perf/Makefile.perf |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.perf
1 - 100 of 295 matches
Mail list logo
