Hi Dave,
On 10/2/2017 1:30 PM, Santosh Shilimkar wrote:
On 10/1/2017 10:56 PM, David Miller wrote:
From: David Miller
[...]
Actually, reverted, this breaks the build.
net/rds/rdma_transport.c:38:10: fatal error: ib.h: No such file or
directory
#include "ib.h"
Although I can't see how
Hi Jaegeuk,
On 2017/10/4 4:16, Jaegeuk Kim wrote:
> On 09/19, Chao Yu wrote:
>> From: Chao Yu
>>
>> Fstrim intends to trim invalid blocks of filesystem only with specified
>> range and granularity, but actually, it will issue all previous cached
>> discard commands which may be out-of-range and b
Jerome Glisse wrote:
> On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote:
>
>> I'd like some more explanation about the inner working of "that new
>> user" as per comment above.
>>
>> It would be enough to drop mmu_notifier_invalidate_range from above
>> without adding it to the
On Tue, Oct 03, 2017 at 11:15:07PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> > On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > > Now that all filesystems which used to rely on kthread
> > > freezing have been co
Hi Jaegeuk,
On 2017/10/4 4:52, Jaegeuk Kim wrote:
> Hi Chao,
>
> Could you please rebase the following patches on top of dev-test?
>
> f2fs-support-issuing-waiting-discard-in-range
> f2fs-wrap-discard-policy
> f2fs-split-discard-policy
> f2fs-reduce-cmd_lock-coverage-in-__issue_discard_cmd
> f2f
Hi Ju Hyung, Jaegeuk,
On 2017/10/4 4:17, Jaegeuk Kim wrote:
> On 10/04, Ju Hyung Park wrote:
>> Hi Chao.
>>
>> Yep, that patch seems to have fixed it.
>> Doing "while true; do fstrim -v /; done" while "rm -rf"ing a 2GB
>> kbuild directory
>> (with lots of small .o files and stuff) ended flawlessly
Use max_1m_mrs/max_8k_mrs while setting max_items, as the former
variables are set based on the underlying device attricutes.
Signed-off-by: Avinash Repaka
---
net/rds/ib_rdma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 9a
Hi Guenter,
On 09/28/2017 06:35 AM, Guenter Roeck wrote:
On 09/28/2017 05:55 AM, Alexandre Belloni wrote:
On 04/09/2017 at 22:37:27 -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
Removed redundant IPC helper functions and refactored the driver to
Hi,
On 10/01/2017 07:34 AM, Andy Shevchenko wrote:
On Tue, Sep 5, 2017 at 8:37 AM,
wrote:
From: Kuppuswamy Sathyanarayanan
This patch cleans up unnecessary free/alloc calls in ipc_plat_probe(),
ipc_pci_probe() and ipc_plat_get_res() functions by using devm_*
calls.
This patch also adds pro
Hi Andy,
On 10/01/2017 07:44 AM, Andy Shevchenko wrote:
On Tue, Sep 5, 2017 at 8:37 AM,
wrote:
From: Kuppuswamy Sathyanarayanan
Currently, we have lot of repetitive code in dependent device resource
allocation and device creation handling code. This logic can be improved if
we use MFD frame
On Wed, 2017-10-04 at 02:47 +0200, Luis R. Rodriguez wrote:
> 3) Lookup for kthreads which seem to generate IO -- address / review if
> removal of the freezer API can be done somehow with a quescing. This
> is currently for example being done on SCSI / md.
> 4) Only after all the above
On Wed, Aug 30, 2017 at 09:41:59AM +0200, Peter Zijlstra wrote:
On Wed, Aug 30, 2017 at 08:29:47AM +0200, Peter Zijlstra wrote:
On Wed, Aug 30, 2017 at 11:37:21AM +0800, kernel test robot wrote:
> [0.004000]
-
> [0.004000]
On Sun, 1 Oct 2017 15:30:40 -0400
Jérémy Lefaure wrote:
> It is useless to re-invent the ARRAY_SIZE macro so let's use it instead
> of DATA_CNT.
>
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
> (sizeof(E)@
Hi Andy,
Thanks for the review. I really appreciate you taking the time to review
such big chunk of code changes.
On 10/01/2017 07:46 AM, Andy Shevchenko wrote:
On Tue, Sep 5, 2017 at 8:37 AM,
wrote:
From: Kuppuswamy Sathyanarayanan
Hi All,
Currently intel_pmc_ipc.c, intel_punit_ipc.c,
Hi,
On 10/01/2017 07:59 AM, Andy Shevchenko wrote:
On Tue, Sep 5, 2017 at 8:37 AM,
wrote:
From: Kuppuswamy Sathyanarayanan
Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c
redundantly implements the same IPC features and has lot of code
duplication between them. This driver
Hi Avinash,
On 10/3/2017 5:50 PM, Avinash Repaka wrote:
Use max_1m_mrs/max_8k_mrs while setting max_items, as the former
variables are set based on the underlying device attricutes.
s/attricutes/attributes
Signed-off-by: Avinash Repaka
---
net/rds/ib_rdma.c | 4 ++--
1 file changed, 2 in
From: Chao Yu
This patch adds tracepoint to trace f2fs_remove_discard.
Signed-off-by: Chao Yu
---
v2:
- rebase on last codes of Jaegeuk's dev-test branch.
fs/f2fs/segment.c | 2 ++
include/trace/events/f2fs.h | 7 +++
2 files changed, 9 insertions(+)
diff --git a/fs/f2fs/segment
From: Chao Yu
__submit_discard_cmd may lead long latency due to exhaustion of I/O
request resource in block layer, so issuing all discard under cmd_lock
may lead to hangtask, in order to avoid that, let's reduce it's coverage.
Signed-off-by: Chao Yu
---
v2:
- rebase on last codes of Jaegeuk's d
From: Chao Yu
In ->umount, once we drop remained discard entries, we should not
set CP_TRIMMED_FLAG with another checkpoint.
Signed-off-by: Chao Yu
---
v2:
- rebase on last codes of Jaegeuk's dev-test branch.
fs/f2fs/f2fs.h| 2 +-
fs/f2fs/segment.c | 15 +++
fs/f2fs/super.c
From: Chao Yu
This patch wraps scattered optional parameters into discard policy as
below, later, with it we expect that we can adjust these parameters with
proper strategy in different scenario.
struct discard_policy {
unsigned int min_interval; /* used for candidates exist */
From: Chao Yu
There are many different scenarios such as fstrim, umount, urgent or
background where we will issue discards, actually, they need use
different policy in aspect of io aware, discard granularity, delay
interval and so on. But now they just share one common discard policy,
so there wi
From: Chao Yu
Fstrim intends to trim invalid blocks of filesystem only with specified
range and granularity, but actually, it will issue all previous cached
discard commands which may be out-of-range and be with unmatched
granularity, it's unneeded.
In order to fix above issues, this patch intro
With CONFIG_ORC_UNWINDER, if the user doesn't have libelf-devel
installed, and they don't see the make warning, their ORC unwinder will
be silently broken. Upgrade the warning to an error.
Reported-and-tested-by: Borislav Petkov
Signed-off-by: Josh Poimboeuf
---
Makefile | 6 +-
1 file cha
Hi Andy,
On 10/01/2017 07:48 AM, Andy Shevchenko wrote:
On Tue, Sep 5, 2017 at 8:37 AM,
wrote:
From: Kuppuswamy Sathyanarayanan
Currently, update_no_reboot_bit() function implemented in this driver
uses mutex_lock to protect its register updates. But this function is
called with in atomic c
On Tue, Oct 03, 2017 at 05:43:47PM -0700, Nadav Amit wrote:
> Jerome Glisse wrote:
>
> > On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote:
> >
> >> I'd like some more explanation about the inner working of "that new
> >> user" as per comment above.
> >>
> >> It would be enough t
On Tue, Oct 3, 2017 at 5:20 PM, Luis R. Rodriguez wrote:
> the ordering devised currently there is:
>
> o device driver pm ops called
> o notifier for suspend issued - *going to suspend*
> o userspace frozen
> o filesystem freeze
>
> On the way back up this order is inverted:
>
> o files
Hi Jaegeuk,
When I rebase on last dev-test branch, I found that there are splitted codes
from this patch which contains fixing codes for recovery flow. I guess you
have missed this v2 patch.
Could you merge and test this v2?
Thanks,
On 2017/9/6 21:59, Chao Yu wrote:
> From: Chao Yu
>
> Now, i
On Mon, Sep 18, 2017 at 06:20:29PM +0200, Nicolas Ferre wrote:
> From: Nicolas Ferre
>
> Arnd, Olof,
>
> Here are some fixes for 4.14. I send them while Alexandre is in the US. The
> most of this PR are modifications to the sama5d27 SOM1 EK board that was
> introducts lately. These modifications
On Mon, Sep 18, 2017 at 05:47:50PM +0200, Arnd Bergmann wrote:
> It is no longer possible to load this at runtime, so let's
> change the few remaining users to have it built-in all
> the time.
>
> arch/arm/configs/zeus_defconfig:115:warning: symbol value 'm' invalid for
> FRAMEBUFFER_CONSOLE
> ar
The driver may sleep under a RCU lock, and the function call path is:
drbd_sync_handshake (acquire the RCU lock)
drbd_asb_recover_1p
drbd_khelper
drbd_bcast_event
genlmsg_new(GFP_NOIO) --> may sleep
To fix it, GFP_NOIO is replaced with GFP_ATOMIC.
This bug is found by my static
The driver may sleep under a RCU lock, and the function call path is:
drbd_sync_handshake (acquire the RCU lock)
drbd_asb_recover_1p
drbd_khelper
notify_helper
genlmsg_new(GFP_NOIO) --> may sleep
To fix it, GFP_NOIO is replaced with GFP_ATOMIC.
This bug is found by my static an
The driver may sleep under a RCU lock, and the function call path is:
drbd_sync_handshake (acquire the RCU lock)
drbd_asb_recover_1p
drbd_khelper
notify_helper
mutex_lock --> may sleep
I hope to fix it, but I do not find a proper way at present ...
This bug is found by my stat
On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
> This commit allows a wakeup parent interrupt to be shared between
> instances.
>
> It also removes the redundant can_wake member of the private data
> structure by using whether the parent_wake_irq has been defined to
> indicate that the GPIO d
On Tue, Oct 03, 2017 at 10:13:21PM +0200, Luis R. Rodriguez wrote:
> > After we remove add the NEEDS_RECOVERY flag, we need to make sure
> > recovery flag is pushed out to disk before any other changes are
> > allowed to be pushed out to disk. That's why we originally did the
> > update synchronou
2017-10-04 1:05 GMT+08:00 Radim Krčmář :
> 2017-09-28 18:04-0700, Wanpeng Li:
>> From: Wanpeng Li
>>
>> SDM 10.5.4.1 TSC-Deadline Mode mentioned that "Transitioning between
>> TSC-Deadline
>> mode and other timer modes also disarms the timer". So the APIC Timer
>> Initial Count
>> Register for o
2017-10-04 1:06 GMT+08:00 Radim Krčmář :
> 2017-09-28 18:04-0700, Wanpeng Li:
>> From: Wanpeng Li
>>
>> If we take TSC-deadline mode timer out of the picture, the Intel SDM
>> does not say that the timer is disable when the timer mode is change,
>> either from one-shot to periodic or vice versa.
>
Hi Doug,
On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
> The basic memory-mapped GPIO controller lock must be released
> before calling the registered GPIO interrupt handlers to allow
> the interrupt handlers to access the hardware. Otherwise, the
> hardware accesses will deadlock when the
2017-10-04 1:28 GMT+08:00 Radim Krčmář :
> 2017-09-28 18:04-0700, Wanpeng Li:
>> From: Wanpeng Li
>>
>> The description in the Intel SDM of how the divide configuration
>> register is used: "The APIC timer frequency will be the processor's bus
>> clock or core crystal clock frequency divided by th
On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
> Reading and writing the gpio bank status register each time a pending
> interrupt bit is serviced could cause new pending bits to be cleared
> without servicing the associated interrupts.
>
> By using the handle_level_irq flow instead of the ha
On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
> This commit corrects a bug when configuring the GPIO hardware for
> IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH interrupt types. The
> hardware is now correctly configured to support those types.
>
> Fixes: 19a7b6940b78 ("gpio: brcmstb: Add inte
On Mon, Oct 02, 2017 at 10:12:49AM -0700, Jacob Pan wrote:
> On Sat, 30 Sep 2017 01:21:43 +0200
> "Rafael J. Wysocki" wrote:
>
> > On Sat, Sep 30, 2017 at 12:01 AM, Michael S. Tsirkin
> > wrote:
> > > intel idle driver does not DTRT when running within a VM:
> > > when going into a deep power st
Hi Fengguang,
On 10/03/2017 07:24 AM, Fengguang Wu wrote:
> Hi Florian,
>
> FYI we see this BUG in latest RC kernel and linux-next.
> Have it been fixed somewhere else?
The purpose of the test module is to make tests for CONFIG_DEBUG_VIRTUAL
trigger such warnings/VIRTUAL_BUG_ON, because of how t
On 10/03/2017 06:55 PM, Gregory Fong wrote:
> Hi Doug,
>
> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
>> The basic memory-mapped GPIO controller lock must be released
>> before calling the registered GPIO interrupt handlers to allow
>> the interrupt handlers to access the hardware. Othe
On Tue, Oct 03, 2017 at 11:02:55PM +0200, Thomas Gleixner wrote:
> On Mon, 2 Oct 2017, Jacob Pan wrote:
> > On Sat, 30 Sep 2017 01:21:43 +0200
> > "Rafael J. Wysocki" wrote:
> >
> > > On Sat, Sep 30, 2017 at 12:01 AM, Michael S. Tsirkin
> > > wrote:
> > > > intel idle driver does not DTRT when r
Hi Doug,
On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
> Mask the GPIO interrupt while its type is being changed, just in case
> it can prevent a spurious interrupt.
"Just in case"? I don't have access to hardware documentation for
this anymore, but I'd expect to some stronger claim that
On 10/03/2017 07:10 PM, Gregory Fong wrote:
> Hi Doug,
>
> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
>> Mask the GPIO interrupt while its type is being changed, just in case
>> it can prevent a spurious interrupt.
>
> "Just in case"? I don't have access to hardware documentation for
>
On Tue, Oct 03, 2017 at 07:09:37PM -0700, Florian Fainelli wrote:
Hi Fengguang,
On 10/03/2017 07:24 AM, Fengguang Wu wrote:
Hi Florian,
FYI we see this BUG in latest RC kernel and linux-next.
Have it been fixed somewhere else?
The purpose of the test module is to make tests for CONFIG_DEBUG_
On most small systems, the deadline scheduler class is a luxury that
rarely gets used if at all. It is preferable to have the ability to
configure it out to reduce the kernel size in that case.
Before:
$ size -t kernel/sched/built-in.o
textdata bss dec hex filename
[...]
2443
On Tue, Oct 03, 2017 at 11:42:18AM +0200, Paolo Bonzini wrote:
> On 01/10/2017 01:22, Nick Desaulniers wrote:
> > I don't follow (but I also don't know what any of these three letter
> > acryonyms acronyms stand for), does svm depend on vmx or vice-versa?
> Neither, one is Intel (VMX), the other is
- avi
I think an extra `did not` made it in to that last email...sorry!
On Tue, Oct 3, 2017 at 7:54 PM, Nick Desaulniers
wrote:
> On Tue, Oct 03, 2017 at 11:42:18AM +0200, Paolo Bonzini wrote:
>> On 01/10/2017 01:22, Nick Desaulniers wrote:
>> > I don't follow (but I also don't know what any of
Hi Doug,
On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
> The GPIOLIB IRQ chip helpers were very appealing, but badly broke
> the 1:1 mapping between a GPIO controller's device_node and its
> interrupt domain.
Out of curiosity, what sort of problems have you seen from this?
>
> This commit
On Tue, Oct 3, 2017 at 1:48 PM, Douglas Anderson wrote:
> The main Linux Makefiles and the tools sub-Makefiles have different
> conventions for passing in CC / CFLAGS.
>
> Here's brief summary for the kernel:
> * CC: target C compiler (must be passed as an argument to make to
> override)
> * HOS
On Tue, Oct 3, 2017 at 1:48 PM, Douglas Anderson wrote:
> If the top-level tools build is called to build a tool and is passed
> CC, AS, or LD on the command line then someone wants to use a
> different compiler, assembler, or linker. Let's honor that.
>
> This together with the change ("kbuild:
Make kvm_stat support Python 3 by changing the use of "print" to a
function rather than a statement, switching from "iteritems" and
"iterkeys" (removed in Python 3) to "items" and "keys" respectively,
and decoding bytes to strings when dealing with text.
With this change, kvm_stat is usable with P
On Tue, Oct 3, 2017 at 7:09 PM, Doug Berger wrote:
> On 10/03/2017 06:55 PM, Gregory Fong wrote:
>> Hi Doug,
>>
>> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
>>> The basic memory-mapped GPIO controller lock must be released
>>> before calling the registered GPIO interrupt handlers to all
On Tue, Oct 03, 2017 at 05:27:25PM -0700, Darren Hart wrote:
> On Wed, Oct 04, 2017 at 08:39:34AM +1030, Jonathan Woithe wrote:
> > :
> > Reviewed-by: Jonathan Woithe
>
> Thanks for the due diligence here Jonathan, but for stable backport
> announcements, you don't need to speak up unless you hav
On Tue, Oct 3, 2017 at 7:22 PM, Doug Berger wrote:
> On 10/03/2017 07:10 PM, Gregory Fong wrote:
>> Hi Doug,
>>
>> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
>>> Mask the GPIO interrupt while its type is being changed, just in case
>>> it can prevent a spurious interrupt.
>>
>> "Just in
2017-10-04 5:48 GMT+09:00 Douglas Anderson :
> The main Linux Makefiles and the tools sub-Makefiles have different
> conventions for passing in CC / CFLAGS.
>
> Here's brief summary for the kernel:
> * CC: target C compiler (must be passed as an argument to make to
> override)
> * HOSTCC: host C
On Thu, 2017-09-28 at 17:21 +0930, Joel Stanley wrote:
> > From: Andrew Jeffery
>
> Moving the subnodes out of the pinctrl node declaration to a reference
> allows easier access to the remaining parts of the devicetree.
>
> > Signed-off-by: Andrew Jeffery
> > Reviewed-by: Xo Wang
> > Signed-of
On Thu, 2017-09-28 at 17:21 +0930, Joel Stanley wrote:
> We try to keep the nodes in address order. The ADC node was out of
> place.
>
> Signed-off-by: Joel Stanley
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 16
> arch/arm/boot/dts/aspeed-g5.dtsi | 16
> 2 files
Understanding what it represents helps a lot when reading the code, and
it's not obvious, so document it.
The ROOT_MENU flag is only set and tested by the gconf and qconf front
ends, so leave it undocumented here. The obvious guess for what it means
is correct.
Signed-off-by: Ulf Magnusson
---
The function insn_get_addr_ref() is capable of handling only 64-bit
addresses. A previous commit introduced a function to handle 32-bit
addresses. Invoke these two functions from a third wrapper function that
calls the appropriate routine based on the address size specified in the
instruction struc
In its current form, user_64bit_mode() can only be used when CONFIG_X86_64
is selected. This implies that code built with CONFIG_X86_64=n cannot use
it. If a piece of code needs to be built for both CONFIG_X86_64=y and
CONFIG_X86_64=n and wants to use this function, it needs to wrap it in
an #ifdef
32-bit and 64-bit address encodings are identical. Thus, the same logic
could be used to resolve the effective address. However, there are two key
differences: address size and enforcement of segment limits.
If running a 32-bit process on a 64-bit kernel, it is best to perform
the address calculat
Certain user space programs that run on virtual-8086 mode may utilize
instructions protected by the User-Mode Instruction Prevention (UMIP)
security feature present in new Intel processors: SGDT, SIDT and SMSW. In
such a case, a general protection fault is issued if UMIP is enabled. When
such a fau
The instructions str and sldt are not recognized when running on virtual-
8086 mode and generate an invalid operand exception. These two
instructions are protected by the Intel User-Mode Instruction Prevention
(UMIP) security feature. In protected mode, if UMIP is enabled, these
instructions genera
User-Mode Instruction Prevention (UMIP) is enabled by setting/clearing a
bit in %cr4.
It makes sense to enable UMIP at some point while booting, before user
spaces come up. Like SMAP and SMEP, is not critical to have it enabled
very early during boot. This is because UMIP is relevant only when the
If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP, fixup_umip_e
When errors occur in the computation of the linear address, -1L is
returned. Rather than having a separate return path for errors, the
variable used to return the computed linear address can be initialized
with the error value. Hence, only one return path is needed. This makes
the function easier t
Since commit 5e53879008b9 ("sparc,sparc64: unify Makefile"), hdr-arch
and SRCARCH always match.
Signed-off-by: Masahiro Yamada
---
Makefile | 21 +
scripts/Makefile.headersinst | 2 +-
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/Make
User-Mode Instruction Prevention is a security feature present in new
Intel processors that, when set, prevents the execution of a subset of
instructions if such instructions are executed in user mode (CPL > 0).
Attempting to execute such instructions causes a general protection
exception.
The sub
$(call cc-option,...) is costly because it invokes the C compiler.
Given that only some targets need compiler flags, it is pointless
to compute them all the time.
The variable no-dot-config-targets lists the targets we can run
without the .config file, such as "make clean", "make help", etc.
My
The feature User-Mode Instruction Prevention present in recent Intel
processor prevents a group of instructions (sgdt, sidt, sldt, smsw, and
str) from being executed with CPL > 0. Otherwise, a general protection
fault is issued.
Rather than relaying to the user space the general protection fault c
The first "_all" occurrence around line 120 is only visible when
KBUILD_SRC is unset.
If O=... is specified, the working directory is relocated, then the
only second occurrence around line 193 is visible, that is not set
to PHONY.
Move the first one to an always visible place. This clarifies "_a
The top Makefile is divided into some sections such as mixed targets,
config targets, build targets, etc.
When we build mixed targets, Kbuild just invokes submake to process
them one by one. In this case, compiler-related variables like CC,
KBUILD_CFLAGS, etc. are unneeded.
Check what kind of ta
fixup_umip_exception() will be called from do_general_protection(). If the
former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV.
However, when emulation is successful but the emulated result cannot be
copied to user space memory, it is more accurate to issue a SIGSEGV with
SEGV_
Obtain the default values of the address and operand sizes as specified in
the D and L bits of the the segment descriptor selected by the register
CS. The function can be used for both protected and long modes.
For virtual-8086 mode, the default address and operand sizes are always 2
bytes.
The re
Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when ModRM.mod is zero and
ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means
that none of the registers are used in the computation of the effective
address. A return v
It is possible to utilize 32-bit address encodings in virtual-8086 mode via
an address override instruction prefix. However, the range of the
effective address is still limited to [0x-0x]. In such a case, return
error.
Also, linear addresses in virtual-8086 mode are limited to 20 bits. Enforce
Tasks running in virtual-8086 mode, in protected mode with code segment
descriptors that specify 16-bit default address sizes via the
D bit, or via an address override prefix will use 16-bit addressing form
encodings as described in the Intel 64 and IA-32 Architecture Software
Developer's Manual Vo
insn_get_addr_ref() returns the effective address as defined by the
section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software
Developer's Manual. In order to compute the linear address, we must add
to the effective address the segment base address as set in the segment
descriptor. The
Rather than using hard-coded values of the segment override prefixes,
leverage the existing definitions provided in inat.h.
Suggested-by: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andrew Morton
Cc: Borislav Petkov
Cc: Masami Hiramatsu
Cc: Denys Vlasenko
Cc: Srikar Dronamraju
Cc: Ravi V. Shank
When computing a linear address and segmentation is used, we need to know
the base address of the segment involved in the computation. In most of
the cases, the segment base address will be zero as in USER_DS/USER32_DS.
However, it may be possible that a user space program defines its own
segments
The segment descriptor contains information that is relevant to how linear
addresses need to be computed. It contains the default size of addresses
as well as the base address of the segment. Thus, given a segment
selector, we ought to look at segment descriptor to correctly calculate
the linear ad
String instructions are special because, in protected mode, the linear
address is always obtained via the ES segment register in operands that
use the (E)DI register; the DS segment register in operands that use
the (E)SI register. Furthermore, segment override prefixes are ignored
when calculating
With segmentation, the base address of the segment is needed to compute a
linear address. This base address is obtained from the applicable segment
descriptor. Such segment descriptor is referenced from a segment selector.
These new functions obtain the segment base and limit of the segment
selecto
The function get_reg_offset() returns the offset to the register the
argument specifies as indicated in an enumeration of type offset. Callers
of this function would need the definition of such enumeration. This is
not needed. Instead, add helper functions for this purpose. These functions
are usef
Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when ModRM.mod !=11b and
ModRM.rm = 100b indexed register-indirect addressing is used. In other
words, a SIB byte follows the ModRM byte. In the specific case of
SIB.index = 100b, the scale*ind
Even though memory addresses are unsigned, the operands used to compute the
effective address do have a sign. This is true for ModRM.rm, SIB.base,
SIB.index as well as the displacement bytes. Thus, signed variables shall
be used when computing the effective address from these operands. Once the
sig
Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that if a SIB byte is used and
SIB.base is 101b and ModRM.mod is zero, then the base part of the base
part of the effective address computation is null. To signal this
situation, a -EDOM error is re
Other kernel submodules can benefit from using the utility functions
defined in mpx.c to obtain the addresses and values of operands contained
in the general purpose registers. An instance of this is the emulation code
used for instructions protected by the Intel User-Mode Instruction
Prevention fe
We are not in a critical failure path. The invalid register type is caused
when trying to decode invalid instruction bytes from a user-space program.
Thus, simply print an error message. To prevent this warning from being
abused from user space programs, use the rate-limited variant of pr_err().
al
This is v9 of this series. The seven previous submissions can be found
here [1], here [2], here[3], here[4], here[5], here[6], here[7] and here[8].
This version addresses the feedback comments from Borislav Petkov received on
v7. Please see details in the change log.
=== What is UMIP?
User-Mode I
Both head_32.S and head_64.S utilize the same value to initialize the
control register CR0. Also, other parts of the kernel might want to access
this initial definition (e.g., emulation code for User-Mode Instruction
Prevention uses this state to provide a sane dummy value for CR0 when
emulating th
Up to this point, only fault.c used the definitions of the page fault error
codes. Thus, it made sense to keep them within such file. Other portions of
code might be interested in those definitions too. For instance, the User-
Mode Instruction Prevention emulation code will use such definitions to
From: Santosh Shilimkar
Date: Tue, 3 Oct 2017 17:42:39 -0700
> Hi Dave,
>
> On 10/2/2017 1:30 PM, Santosh Shilimkar wrote:
>> On 10/1/2017 10:56 PM, David Miller wrote:
>>> From: David Miller
> [...]
>
>>>
>>> Actually, reverted, this breaks the build.
>>>
>>> net/rds/rdma_transport.c:38:10: f
Hi Douglas,
2017-09-27 2:55 GMT+09:00 Douglas Anderson :
> While timing a "no-op" build of the kernel (incrementally building the
> kernel even though nothing changed) in the Chrome OS build system I
> found that it was much slower than I expected.
>
> Digging into things a bit, I found that quit
On Tue, Oct 3, 2017 at 8:20 PM, Masahiro Yamada
wrote:
> 2017-10-04 5:48 GMT+09:00 Douglas Anderson :
>> The main Linux Makefiles and the tools sub-Makefiles have different
>> conventions for passing in CC / CFLAGS.
>>
>> Here's brief summary for the kernel:
>> * CC: target C compiler (must be pas
The target "dtbs" should depend on "scripts" because it needs to
build dtc. The "prepare" target is unneeded here.
Signed-off-by: Masahiro Yamada
---
arch/arm/Makefile | 2 +-
arch/arm64/Makefile | 2 +-
arch/nios2/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On Thu, 2017-09-28 at 11:35 -0700, Brendan Higgins wrote:
> > On Thu, Sep 28, 2017 at 12:51 AM, Joel Stanley wrote:
> > Now with an upstream i2c bus driver, we can add the 14 i2c buses that
> > exist in ASPEED G4 and G5 generation SoCs.
> >
> > It also adds aliases for the 14 built-in I2C busses
1 - 100 of 1098 matches
Mail list logo
