Due to commit fb5841091f28 ("apparmor: remove no-op permission check
in policy_unpack"), there is some leftover code.
Coverity reports this issue as Structurally dead code. Fix this by
removing such code.
Addresses-Coverity-ID: 1472998 ("Structurally dead code")
Fixes: fb5841091f28 ("apparmor:
On 23.08.2018 15:22, Halil Pasic wrote:
>
>
> On 08/23/2018 02:47 PM, Pierre Morel wrote:
>> On 23/08/2018 13:12, David Hildenbrand wrote:
> [..]
>>
>> I'm confused, which 128 bit?
>
>
> Me too :) , I was assuming this block to be 128bit, but the qci block
> has 128
On 23 August 2018 at 18:51, Rob Herring wrote:
> On Thu, Aug 23, 2018 at 12:38 AM Jassi Brar
> wrote:
>> On 23 August 2018 at 10:48, Masahiro Yamada
>> >
>> > If desired, I will export of_irq_count()
>> > and use it from my driver.
>> >
>> If you don't want to leave too much footprint, you
Em Thu, Aug 23, 2018 at 02:29:34PM +0200, Martin Liška escreveu:
> 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 8/23/18 12:25 PM, Pierre Morel wrote:
> When entering the SIE the CRYCB validation better
> be done independently of the instruction's
> availability.
>
> Signed-off-by: Pierre Morel
> ---
> arch/s390/kvm/vsie.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff
On Wed, Aug 22, 2018 at 05:30:14PM +0200, Peter Zijlstra wrote:
> Will noted that only checking mm_users is incorrect; we should also
> check mm_count in order to cover CPUs that have a lazy reference to
> this mm (and could do speculative TLB operations).
>
> If removing this turns out to be a
On Wed, Aug 22, 2018 at 10:11:41PM -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Thu, Aug 23, 2018 at 06:47:08PM +1000, Nicholas Piggin wrote:
> There is no need to call this from tlb_flush_mmu_tlbonly, it
> logically belongs with tlb_flush_mmu_free. This allows some
> code consolidation with a subsequent fix.
>
> Signed-off-by: Nicholas Piggin
> ---
> mm/memory.c | 6
Two users have reported [1] that they have an "extremely unlikely" system
with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact
it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to holes
in the e820 map, the main region is almost 500MB over the 32GB limit:
[
After the corresponding 'goto' was removed, we get a warning
for the 'fail' label:
security/apparmor/policy_unpack.c: In function 'unpack_dfa':
security/apparmor/policy_unpack.c:426:1: error: label 'fail' defined but not
used [-Werror=unused-label]
Fixes: fb5841091f28 ("apparmor: remove no-op
Hello,
syzbot found the following crash on:
HEAD commit:899fbc33fd77 Merge tag 'platform-drivers-x86-v4.19-1' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11a98c0a40
kernel config: https://syzkaller.appspot.com/x/.config?x=e408e8a7bf8306cb
On Wed, Aug 22, 2018 at 11:16:31PM -0700, Eric Biggers wrote:
> Hello RDMA / InfiniBand maintainers,
>
> This is an RDMA bug and it still occurs on Linus' tree as of today
> (commit 815f0ddb346c1960).
>
> I've also simplified the reproducer for it; see below after the original
> report.
>
Hi Linus,
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
tags/pwm/for-4.19-rc1
for you to fetch
On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote:
> The generic tlb_end_vma does not call invalidate_range mmu notifier,
> and it resets resets the mmu_gather range, which means the notifier
> won't be called on part of the range in case of an unmap that spans
> multiple vmas.
>
>
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: syzbot+5702a7e6d4a13b3ac...@syzkaller.appspotmail.com
>> > It will help syzbot
On 08/23/2018 06:25 AM, Cornelia Huck wrote:
On Wed, 22 Aug 2018 15:16:19 -0400
Tony Krowiak wrote:
One of the things I suggested in a private conversation with Christian
earlier
today was to provide an additional rw sysfs attribute - a boolean - that
indicates
whether all usage domains
On Thu, Aug 23, 2018 at 7:09 AM, Arnd Bergmann wrote:
> After the corresponding 'goto' was removed, we get a warning
> for the 'fail' label:
>
> security/apparmor/policy_unpack.c: In function 'unpack_dfa':
> security/apparmor/policy_unpack.c:426:1: error: label 'fail' defined but not
> used
> xtensa: platform-specific handling of coherent memory
How is this supposed to be used? For the nommu version there only
are __weak stubs, but no actual implementation.
Hi Amit,
Thanks for fixing this.
On Thu, Aug 23, 2018 at 02:23:29PM +0530, Amit Kucheria wrote:
> The idle-states binding documentation[1] mentions that the
> 'entry-method' property is required on 64-bit platforms and must be
> set to "psci".
>
> commit a13f18f59d26 ("Documentation: arm: Fix
Em Wed, Aug 22, 2018 at 10:36:12AM -0400, Steven Rostedt escreveu:
> On Sat, 18 Aug 2018 04:53:45 -0700
> "tip-bot for Tzvetomir Stoyanov (VMware)" wrote:
>
> > Commit-ID: 413af01c8d9d5d688df3244401cbddfe98bafe2a
> > Gitweb:
> >
Two users have reported [1] that they have an "extremely unlikely" system
with more than MAX_PA/2 memory and L1TF mitigation is not effective. Let's
make the warning more helpful by suggesting the proper mem=X kernel boot param,
a rough calculation of how much RAM can be lost (not precise if
On 2018/08/23 23:21, Kees Cook wrote:
> On Thu, Aug 23, 2018 at 7:09 AM, Arnd Bergmann wrote:
>> After the corresponding 'goto' was removed, we get a warning
>> for the 'fail' label:
>>
>> security/apparmor/policy_unpack.c: In function 'unpack_dfa':
>> security/apparmor/policy_unpack.c:426:1:
Hi All,
On arm64 platform I have booted Linux only with > 32-bit
Address i.e from 0x8 (reg = <0x8 0x 0x0 0x8000>)
In my driver, I am using dma_set_mask_and_coherent(>dev,
DMA_BIT_MASK(32)); which should fail if I boot Linux
with the above configuration but the
On 23/08/2018 15:38, David Hildenbrand wrote:
On 23.08.2018 15:22, Halil Pasic wrote:
On 08/23/2018 02:47 PM, Pierre Morel wrote:
On 23/08/2018 13:12, David Hildenbrand wrote:
[..]
I'm confused, which 128 bit?
Me too :) , I was assuming this block to be 128bit, but the qci block
has
On a system with X86_FEATURE_ARCH_PERFMON disabled
and with a model not known by family PMU drivers,
user gets a kernel message log like the following:
[ 0.100114] Performance Events: unsupported p6 CPU model 85 no PMU driver,
software events only.
The "unsupported .. CPU" part may be confusing
On 08/23/2018 02:56 PM, Greg Kroah-Hartman wrote:
> On Thu, Aug 23, 2018 at 01:17:28PM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Aug 23, 2018 at 01:57:35PM +0300, Sergei Shtylyov wrote:
>>> On 08/23/2018 10:55 AM, Greg Kroah-Hartman wrote:
>>>
4.14-stable review patch. If anyone has any
On 08/23/2018 06:27 PM, Greg Kroah-Hartman wrote:
> On Thu, Aug 23, 2018 at 06:20:31PM +0300, Sergei Shtylyov wrote:
>> On 08/23/2018 02:56 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Aug 23, 2018 at 01:17:28PM +0200, Greg Kroah-Hartman wrote:
On Thu, Aug 23, 2018 at 01:57:35PM +0300, Sergei
On Thu, Aug 23, 2018 at 06:33:47PM +0300, Sergei Shtylyov wrote:
> On 08/23/2018 06:27 PM, Greg Kroah-Hartman wrote:
> > On Thu, Aug 23, 2018 at 06:20:31PM +0300, Sergei Shtylyov wrote:
> >> On 08/23/2018 02:56 PM, Greg Kroah-Hartman wrote:
> >>> On Thu, Aug 23, 2018 at 01:17:28PM +0200, Greg
20.07.2018 03:07, Andrew Jeffery wrote:
>> Andrew, can you start with a list that shows what you expect us to need
>> on our systems ?
>>
> Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500
> currently need the following tuneables exposed:
>
> From the SCU:
> - Debug UART
Em Thu, Aug 23, 2018 at 01:21:45PM +0200, Martin Liška escreveu:
> May I please ping this.
I was waiting for someone to give some ack, perhaps Will Cohen can take
a brief look and provide that? Will?
Thanks,
- Arnaldo
> Thanks,
> Martin
>
> On 08/06/2018 10:42 AM, Martin Liška wrote:
> >
Arnd Bergmann writes:
> After the corresponding 'goto' was removed, we get a warning
> for the 'fail' label:
>
> security/apparmor/policy_unpack.c: In function 'unpack_dfa':
> security/apparmor/policy_unpack.c:426:1: error: label 'fail' defined but not
> used [-Werror=unused-label]
>
> Fixes:
Apologies, I messed up my pull request. The result was just a few
commits mentioned in the tag description but missing from the tip of the
branch, and I thought simplest was to make a new tag and a new pull
request with the additional commits, I hope that works OK. Thanks to
Chuck for noticing
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> On 22/08/2018 22:11, Brijesh Singh wrote:
> >
> > Yes, this is one of approach I have in mind. It will avoid splitting
> > the larger pages; I am thinking that early in boot code we can lookup
> > for this special section and
/linux/commits/Daniel-Kurtz/pinctrl-amd-use-byte-access-to-clear-irq-wake-status-bits/20180823-103347
base:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF
On 08/22/2018 11:53 AM, David Hildenbrand wrote:
> When DATA exceptions and vector-processing exceptions (program interrupts)
> are injected, the DXC/VXC is also to be stored in the fpc, if AFP is
> enabled in CR0.
>
> This can happen inside KVM when reinjecting an interrupt during program
>
On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
> Two users have reported [1] that they have an "extremely unlikely" system
> with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact
> it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to holes
>
On Thu, Aug 23, 2018 at 04:28:12PM +0200, Vlastimil Babka wrote:
> Two users have reported [1] that they have an "extremely unlikely" system
> with more than MAX_PA/2 memory and L1TF mitigation is not effective. Let's
> make the warning more helpful by suggesting the proper mem=X kernel boot
>
Hello James,
On Thu, Aug 23, 2018 at 5:29 AM James Morse wrote:
> On 19/07/18 19:36, Tyler Baicar wrote:
> > On 7/19/2018 10:46 AM, James Morse wrote:
> >> On 19/07/18 15:01, Borislav Petkov wrote:
> >>> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
> Enable per-layer error
Greetings
Please assist me to receive about 15 million euros into your personal
account. I will give you details as I hear from you.
Send me the followings,
Age
Nationality
Occupation
Telephone Line
Regard,
Mr Ahmed Zama
Em Thu, Aug 23, 2018 at 01:30:47PM +0300, Alexey Budankov escreveu:
> +++ b/tools/perf/util/evlist.c
> @@ -718,6 +718,8 @@ static void perf_evlist__munmap_nofree(struct perf_evlist
> *evlist)
> void perf_evlist__munmap(struct perf_evlist *evlist)
> {
> perf_evlist__munmap_nofree(evlist);
On 08/20/2018 10:44 PM, Roy Im wrote:
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index ca59a2b..6e0de69 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -851,4 +851,16 @@ config INPUT_SC27XX_VIBRA
> To compile this driver as a
On Thu, Aug 23, 2018 at 09:38:31AM -0400, Scott French wrote:
> Please remove the stfrench @ gmail address. I am not Steve
Now removed, sorry for the noise.
greg k-h
On Thu 23-08-18 15:44:18, Vlastimil Babka wrote:
> Two users have reported [1] that they have an "extremely unlikely" system
> with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact
> it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to holes
> in the e820
On Wed, 22 Aug 2018, Serge E. Hallyn wrote:
> Quoting Christian Brauner (christ...@brauner.io):
> > bprm_caps_from_vfs_caps() never returned -EINVAL so remove the
> > rc == -EINVAL check.
> >
> > Signed-off-by: Christian Brauner
>
> Thanks.
>
> Reviewed-by: Serge Hallyn
Thanks, I'll queue
Since copy_optimized_instructions() misses to update real RIP
address while copying several instructions to working buffer,
it adjusts RIP-relative instruction with wrong RIP address for
the 2nd and subsequent instructions.
This may break the kernel (like kernel freeze) because
probed instruction
On Thu, Aug 23, 2018 at 04:39:29PM +, Parav Pandit wrote:
>
>
> > From: Jason Gunthorpe
> > Sent: Thursday, August 23, 2018 9:55 AM
> > To: Eric Biggers
> > Cc: Doug Ledford ; linux-r...@vger.kernel.org;
> > dasaratharaman.chandramo...@intel.com; Leon Romanovsky
> > ;
Replace all usages of ERR_MSG with with dev_ without __func__
or __LINE__ or current->comm and current->pid. Remove the do {}
while(0) loop for the single statement macro. Delete commented
ERR_MSG() usage. Drop ERR_MSG from dbg.h. Issue found by checkpatch.
Signed-off-by: Nishad Kamdar
---
On 08/23/2018 10:59 AM, Pierre Morel wrote:
On 23/08/2018 15:38, David Hildenbrand wrote:
On 23.08.2018 15:22, Halil Pasic wrote:
On 08/23/2018 02:47 PM, Pierre Morel wrote:
On 23/08/2018 13:12, David Hildenbrand wrote:
[..]
I'm confused, which 128 bit?
Me too :) , I was assuming this
On 23.08.2018 17:43, Christian Borntraeger wrote:
>
>
> On 08/22/2018 11:53 AM, David Hildenbrand wrote:
>> When DATA exceptions and vector-processing exceptions (program interrupts)
>> are injected, the DXC/VXC is also to be stored in the fpc, if AFP is
>> enabled in CR0.
>>
>> This can happen
From: Randy Dunlap
When $DEPMOD is not found, only print a warning instead of exiting
with an error message and error status.
Warning: 'make modules_install' requires /sbin/depmod. Please install it.
This is probably in the kmod package.
Signed-off-by: Randy Dunlap
---
v2: add missing "exit
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
> After the corresponding 'goto' was removed, we get a warning
> for the 'fail' label:
>
> security/apparmor/policy_unpack.c: In function 'unpack_dfa':
>
On 8/23/18 1:21 PM, John Johansen wrote:
> On 08/23/2018 06:42 AM, Gustavo A. R. Silva wrote:
>
> thank you for the patch, but a fix for this issue was pushed to apparmor-next
> yesterday
>
That's great. Good to know.
Thanks
--
Gustavo
Quoting Taniya Das (2018-08-08 03:15:26)
>
>
> On 8/8/2018 11:52 AM, Stephen Boyd wrote:
> >>
> >> Binding describes hardware controllable by the OS. That's the reality.
> >> Let's not add mandatory clock bindings for clocks that the OS can't do
> >> anything about.
> >>
> >
> > It seems that
Hi Arnaldo,
On 23.08.2018 17:30, Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 23, 2018 at 01:30:47PM +0300, Alexey Budankov escreveu:
>> +++ b/tools/perf/util/evlist.c
>> @@ -718,6 +718,8 @@ static void perf_evlist__munmap_nofree(struct
>> perf_evlist *evlist)
>> void
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 time. The xlog_grant_head_check() function call and
its sub-function
The use of wake_q_add() and wake_up_q() functions help to do task wakeup
without holding lock can help to reduce lock hold time. They should be
available to kernel modules as well.
A new wake_q_empty() inline function is also added.
Signed-off-by: Waiman Long
---
include/linux/sched/wake_q.h |
On 23/08/2018 18:24, Vitaly Kuznetsov wrote:
> nested_run_pending is set 20 lines above and check_vmentry_prereqs()/
> check_vmentry_postreqs() don't seem to be resetting it (the later, however,
> checks it).
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/vmx.c | 3 ---
> 1 file
While running the AIM7 microbenchmark, it was found that there was
a severe spinlock contention problem in the current XFS log space
reservation code. To alleviate the problem, the log space waiter
waiting and waking functions are modified to use the wake_q for waking
up waiters without holding
On 08/23/2018 01:21 AM, Kirill A. Shutemov wrote:
> On Thu, Aug 23, 2018 at 09:30:35AM +0200, Michal Hocko wrote:
>> On Wed 22-08-18 09:48:16, Mike Kravetz wrote:
>>> On 08/22/2018 05:28 AM, Michal Hocko wrote:
On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
[...]
> diff --git
From: Andy Lutomirski
ptrace can read FS/GS base using the register access API
(PTRACE_PEEKUSER, etc) or PTRACE_ARCH_PRCTL. Make both of these
mechanisms return the actual FS/GS base.
This will improve debuggability by providing the correct information
to ptracer (GDB and etc).
Signed-off-by:
The FS/GS base helper functions are used on ptrace APIs
(PTRACE_ARCH_PRCTL, PTRACE_SETREG, PTRACE_GETREG, etc).
The FS/GS-update mechanism is now a bit organized.
Based-on-code-from: Andy Lutomirski
Signed-off-by: Chang S. Bae
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Dave
64-bit doesn't use the entry for per CPU data, but for CPU
(and node) numbers. The change will clarify the real usage
of this entry in GDT.
Suggested-by: H. Peter Anvin
Signed-off-by: Chang S. Bae
Acked-by: Andy Lutomirski
Reviewed-by: Thomas Gleixner
Cc: Ingo Molnar
Cc: Andi Kleen
Cc: Dave
The CPU initialization in vDSO is now a bit cleaned up by
the new helper functions. The helper functions will take
care of combining CPU and node number and reading each from
the combined value.
Suggested-by: Andy Lutomirski
Suggested-by: Thomas Gleixner
Signed-off-by: Chang S. Bae
Cc: H.
The open coded access is now replaced, that might prevent
from using the enhanced FSGSBASE mechanism.
Based-on-code-from: Andy Lutomirski
Signed-off-by: Chang S. Bae
Reviewed-by: Andi Kleen
Reviewed-by: Andy Lutomirski
Reviewed-by: Thomas Gleixner
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc:
Instead of open coding the calls to load_seg_legacy(), add a
load_fsgs() helper to handle fs and gs. When FSGSBASE is enabled,
load_fsgs() will be updated.
Signed-off-by: Chang S. Bae
Reviewed-by: Andi Kleen
Reviewed-by: Andy Lutomirski
Reviewed-by: Thomas Gleixner
Cc: H. Peter Anvin
Cc:
On Thu, Aug 23, 2018 at 06:24:24PM +0200, Vitaly Kuznetsov wrote:
> nested_run_pending is set 20 lines above and check_vmentry_prereqs()/
> check_vmentry_postreqs() don't seem to be resetting it (the later, however,
> checks it).
>
Reviewed-by: Eduardo Valentin
> Signed-off-by: Vitaly
Resending the patchset that was posted before [6].
Given feedbacks from [1], it was suggested to separate two parts
and to (re-)submit this patchset first.
To facilitate FSGSBASE, Andy's FS/GS base read fix is first
ordered, then some helper functions and refactoring work
are included. Cleanup
I am not able to reproduce when I booted my test system with "mem=8G
memmap=4G!8G". I ended up with a single pmem:
[ 57.750556] nd_pmem namespace0.0: unable to guarantee persistence of
writes
[ 57.881573] pmem0: detected capacity change from 0 to 4294967296
However in the reported kmsg, it
On Thu, 2018-08-23 at 16:39 +, Parav Pandit wrote:
> > -Original Message-
> > From: Jason Gunthorpe
> > Sent: Thursday, August 23, 2018 9:55 AM
> > To: Eric Biggers
> > Cc: Doug Ledford ; linux-r...@vger.kernel.org;
> > dasaratharaman.chandramo...@intel.com; Leon Romanovsky
> > ;
On Thu, Aug 23, 2018 at 09:30:21AM -0700, Guenter Roeck wrote:
> On Thu, Aug 23, 2018 at 09:52:36AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.152 release.
> > There are 79 patches in this series, all will be posted as a response
> > to this one.
On 08/23/2018 05:48 AM, Michal Hocko wrote:
> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> [...]
>
> OK, after burning myself when trying to be clever here it seems like
> your proposed solution is indeed simpler.
>
>> +bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
>> +
On Wed, Aug 22, 2018 at 12:13:42PM +0300, Dan Carpenter wrote:
> On Wed, Aug 22, 2018 at 02:13:07PM +0530, Nishad Kamdar wrote:
> > diff --git a/drivers/staging/mt7621-mmc/sd.c
> > b/drivers/staging/mt7621-mmc/sd.c
> > index 04d23cc7cd4a..6b2c72fc61f2 100644
> > ---
The patchset fixes the four debug macros N_MSG, ERR_MSG, INIT_MSG and
IRQ_MSG. Each patch fixes one particular macro and its usages.
For N_MSG, removes the commented code in dbg.h.
For ERR_MSG and IRQ_MSG, replaces printk with dev_ without __func__ or
__LINE__ or current->comm and current->pid.
Removed all usages of INIT_MSG and dropped it from dbg.h.
Signed-off-by: Nishad Kamdar
---
Changes in v5:
- No change
---
drivers/staging/mt7621-mmc/dbg.h | 7 ---
drivers/staging/mt7621-mmc/sd.c | 16
2 files changed, 23 deletions(-)
diff --git
Hello!
Does anyone do kernel-only deployments, for example, setting up an
embedded device having a Linux kernel and absolutely no userspace
whatsoever?
The reason I as is that such a mode would be mildly useful for rcutorture.
You see, rcutorture runs entirely out of initrd, never mounting a
On 08/23/2018 10:01 AM, Mike Kravetz wrote:
> On 08/23/2018 05:48 AM, Michal Hocko wrote:
>> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
>> [...]
>>
>> OK, after burning myself when trying to be clever here it seems like
>> your proposed solution is indeed simpler.
>>
>>> +bool
Hi Paul,
On Thu, Aug 23, 2018 at 7:44 PM Paul E. McKenney
wrote:
> Does anyone do kernel-only deployments, for example, setting up an
> embedded device having a Linux kernel and absolutely no userspace
> whatsoever?
Isn't that basically the original porting guide from VxWorks to Linux?
Quoting Taniya Das (2018-08-22 03:28:31)
>
> >
> > H. Ok. That won't work then. recalc_rate() better not try to
> > populate the frequency table then or it will not work. So I suppose it
> > needs to fallback to reading the registers and assuming the parent_rate
> > coming in is the actual
From: Naoya Horiguchi
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: [#1]
I notice that Linux 4.18 has the following changeset which changes the
user visible perf_event.h file
commit 6cbc304f2f360f25cc8607817239d6f4a2fd3dc5
Author: Peter Zijlstra
Date: Thu May 10 15:48:41 2018 +0200
perf/x86/intel: Fix unwind errors from PEBS entries
From: Masayoshi Mizuma
commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
memblock.reserved") breaks movable_node kernel option because it
changed the memory gap range to reserved memblock. So, the node
is marked as Normal zone even if the SRAT has Hot plaggable affinity.
On Thu, Aug 23, 2018 at 8:21 AM, Christoph Hellwig wrote:
>> xtensa: platform-specific handling of coherent memory
>
> How is this supposed to be used? For the nommu version there only
> are __weak stubs, but no actual implementation.
The idea is that nommu xtensa platforms that have two
On Thu, Aug 23, 2018 at 05:38:27PM +0900, Masahiro Yamada wrote:
> Hi Randy,
>
>
> 2018-08-23 8:33 GMT+09:00 Randy Dunlap :
> > On 08/22/2018 11:53 AM, H. Nikolaus Schaller wrote:
> >> This patch requires that /sbin/depmod is installed and installable on
> >> the build host.
> >>
> >> But not
On Wed, Aug 22, 2018 at 04:12:13PM +0200, Michal Hocko wrote:
> On Tue 21-08-18 14:35:57, Roman Gushchin wrote:
> > If CONFIG_VMAP_STACK is set, kernel stacks are allocated
> > using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
> > stack pages are charged against corresponding memory
nested_run_pending is set 20 lines above and check_vmentry_prereqs()/
check_vmentry_postreqs() don't seem to be resetting it (the later, however,
checks it).
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/vmx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c
The CPU and node number will be written, as early enough,
to the segment limit of per CPU data and TSC_AUX MSR entry.
The information has been retrieved by vgetcpu in user space
and will be also loaded from the paranoid entry, when
FSGSBASE enabled.
The new setup function is named after the
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Thursday, August 23, 2018 7:24 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH 1/2]
From: Randy Dunlap
When $DEPMOD is not found, only print a warning instead of exiting
with an error message and error status.
Warning: 'make modules_install' requires /sbin/depmod. Please install it.
This is probably in the kmod package.
Signed-off-by: Randy Dunlap
Fixes: 934193a654c1
On 08/23/2018 06:42 AM, Gustavo A. R. Silva wrote:
thank you for the patch, but a fix for this issue was pushed to apparmor-next
yesterday
> Due to commit fb5841091f28 ("apparmor: remove no-op permission check
> in policy_unpack"), there is some leftover code.
>
> Coverity reports this issue
Hi Brendan,
On 8/22/2018 11:46 PM, Brendan Higgins wrote:
On Mon, Aug 20, 2018 at 1:16 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
There are three features used by various Logitech mice for
high-resolution scrolling: the fast scrolling bit in HID++ 1.0, and the
x2120 and x2121 features in HID++ 2.0 and above. This patch supports
all three, and uses the multiplier reported by the mouse for the HID++
2.0+ features.
The full
To avoid code duplication, this class counts high-resolution scroll
movements and emits the legacy low-resolution events when appropriate.
Drivers should create one instance for each scroll wheel that they
need to handle.
Signed-off-by: Harry Cutts
---
drivers/hid/hid-input.c | 44
On Thu, 23 Aug 2018, Paul E. McKenney wrote:
> Hello!
>
> Does anyone do kernel-only deployments, for example, setting up an
> embedded device having a Linux kernel and absolutely no userspace
> whatsoever?
Not that I know of. For one thing, you'd lose the ability to license
your application
On 8/23/18 8:15 AM, Oleg Nesterov wrote:
On 08/22, Srikar Dronamraju wrote:
* Vlastimil Babka [2018-08-22 12:55:59]:
On 08/15/2018 08:49 PM, Yang Shi wrote:
We need check if mm or vma has uprobes in the following patch to check
if a vma could be unmapped with holding read mmap_sem.
On 23/08/2018 17:29, Sean Christopherson wrote:
> On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
>> On 22/08/2018 22:11, Brijesh Singh wrote:
>>>
>>> Yes, this is one of approach I have in mind. It will avoid splitting
>>> the larger pages; I am thinking that early in boot code we
Roman Kagan writes:
> On Wed, Aug 22, 2018 at 12:18:32PM +0200, Vitaly Kuznetsov wrote:
>> Using hypercall for sending IPIs is faster because this allows to specify
>> any number of vCPUs (even > 64 with sparse CPU set), the whole procedure
>> will take only one VMEXIT.
>>
>> Current Hyper-V
On 08/23/2018 10:31 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 23, 2018 at 01:21:45PM +0200, Martin Liška escreveu:
>> May I please ping this.
>
> I was waiting for someone to give some ack, perhaps Will Cohen can take
> a brief look and provide that? Will?
>
> Thanks,
>
> - Arnaldo
>
On Thu, Aug 23, 2018 at 09:52:36AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.152 release.
> There are 79 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
The data buffer and accompanying AIO control block are allocated at
perf_mmap object and the mapped data buffer size is equal to
the kernel one.
The buffer is then used to preserve profiling data ready for dumping
and queue it for asynchronous writing into perf trace thru implemented
On Wed, Aug 22, 2018 at 01:26:41PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 22, 2018 at 04:40:56PM +0530, Nishad Kamdar wrote:
> > On Wed, Aug 22, 2018 at 12:09:36PM +0300, Dan Carpenter wrote:
> > > On Wed, Aug 22, 2018 at 02:04:55PM +0530, Nishad Kamdar wrote:
> > > > This patch fixes the
1 - 100 of 2464 matches
Mail list logo
