Hi Uffe,
Thanks for the review. Please find my comments below.
> -Original Message-
> From: Ulf Hansson
> Sent: Monday, June 17, 2019 8:29 PM
> To: Michal Simek
> Cc: Manish Narani ; Rob Herring
> ; Mark Rutland ; Adrian
> Hunter ; Rajan Vaja ; Jolly
> Shah ; Nava kishore Manne ; Olof
On Wed, 12 Jun 2019 21:59:03 -0700 Nadav Amit wrote:
> For efficient search of resources, as needed to determine the memory
> type for dax page-faults, introduce a cache of the most recently used
> top-level resource. Caching the top-level should be safe as ranges in
> that level do not overlap
On 14-06-19, 15:20, Srinivas Kandagatla wrote:
> For some reason arguments to most of the circular buffers
> macros are used in reverse, tail is used for head and vice versa.
>
> This leads to bam thinking that there is an extra descriptor at the
> end and leading to retransmitting descriptor
This adds an x86-specific test for pinned cr4 bits. A successful test
will validate pinning and check the ROP-style call-middle-of-function
defense, if needed. For example, in the case of native_write_cr4()
looking like this:
8171bce0 :
8171bce0: 48 8b 35 79 46 f2 00mov
With sensitive CR4 bits pinned now, it's possible that the WP bit for
CR0 might become a target as well. Following the same reasoning for
the CR4 pinning, this pins CR0's WP bit (but this can be done with a
static value).
Suggested-by: Peter Zijlstra
Signed-off-by: Kees Cook
---
Hi,
This updates the cr pinning series to allow for no silent papering-over
of pinning bugs (thanks to tglx to pointing out where I needed to poke
cr4 harder). I've tested with under normal boot and hibernation.
-Kees
Kees Cook (3):
lkdtm: Check for SMEP clearing protections
x86/asm: Pin
Several recent exploits have used direct calls to the native_write_cr4()
function to disable SMEP and SMAP before then continuing their exploits
using userspace memory access. This pins bits of CR4 so that they cannot
be changed through a common function. This is not intended to be general
ROP
Hello John,
On (06/07/19 18:29), John Ogness wrote:
[..]
> + struct prb_reserved_entry e;
> + char *s;
> +
> + s = prb_reserve(, , 32);
> + if (s) {
> + sprintf(s, "Hello, world!");
> + prb_commit();
> + }
A nit: snprintf().
sprintf() is tricky, it
On 6/13/2019 11:54 PM, Vidya Sagar wrote:
On 6/7/2019 6:43 PM, Vidya Sagar wrote:
On 5/27/2019 4:39 PM, Vidya Sagar wrote:
On 5/7/2019 12:25 PM, Vidya Sagar wrote:
On 5/7/2019 11:19 AM, Vidya Sagar wrote:
On 5/3/2019 4:53 PM, Lorenzo Pieralisi wrote:
On Thu, May 02, 2019 at 10:34:25PM
On 17-06-19, 12:37, Sameer Pujar wrote:
>
> On 6/13/2019 10:13 AM, Vinod Koul wrote:
> > On 06-06-19, 09:19, Sameer Pujar wrote:
> >
> > > > you are really going other way around about the whole picture. FWIW that
> > > > is how *other* folks do audio with dmaengine!
> > > I discussed this
The usage of BUG() macro is generally discouraged in kernel, unless
it's a problem that results in a physical damage or loss of data.
This patch removes unnecessary BUG() macros and replaces the rest
with warning.
Signed-off-by: Bitan Biswas
---
drivers/i2c/busses/i2c-tegra.c | 49
On 6/17/19 12:28 PM, Dmitry Osipenko wrote:
17.06.2019 21:41, Bitan Biswas пишет:
On 6/17/19 5:13 AM, Dmitry Osipenko wrote:
17.06.2019 8:09, Bitan Biswas пишет:
Remove BUG, BUG_ON as it makes system usable:
- Remove redundant BUG_ON calls or replace with WARN_ON_ONCE
as needed.
do_dabr() was renamed with do_break() long ago. But I still see
some comments mentioning do_dabr(). Replace it.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/hw_breakpoint.c | 2 +-
arch/powerpc/kernel/ptrace.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Watchpoint match range is always doubleword(8 bytes) aligned on
powerpc. If the given range is crossing doubleword boundary, we
need to increase the length such that next doubleword also get
covered. Ex,
address len = 6 bytes
|=.
Remove unnecessary comments. Code itself is self explanatory.
And, ISA already talks about MRD field. I Don't think we need
to re-describe it.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/process.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git
Move feature availability check at the start of the function.
Rearrange comment to it's associated code. Use hw->address and
hw->len in the 512 bytes boundary check(to write if statement
in a single line). Add spacing between code blocks.
Signed-off-by: Ravi Bangoria
---
patch 1-3: Code refactor
patch 4: Speedup disabling breakpoint
patch 5: Fix length calculation for unaligned targets
Ravi Bangoria (5):
Powerpc/hw-breakpoint: Replace stale do_dabr() with do_break()
Powerpc/hw-breakpoint: Refactor hw_breakpoint_arch_parse()
Powerpc/hw-breakpoint: Refactor
Directly setting dawr and dawrx with 0 should be enough to
disable watchpoint. No need to reset individual bits in
variable and then set in hw.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 3 ++-
arch/powerpc/kernel/process.c| 12
2 files
On Wed, 12 Jun 2019 21:59:01 -0700 Nadav Amit wrote:
> Since resources can be removed, locking should ensure that the resource
> is not removed while accessing it. However, find_next_iomem_res() does
> not hold the lock while copying the data of the resource.
Looks right to me.
> Keep holding
+Uwe who had interest in 4bit block protection support
On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote:
> Implement a locking scheme for ISSI devices based on stm_lock mechanism.
> The is25x devices have 4 bits for selecting the range of blocks to
> be locked/protected from erase/write
On Mon, Jun 17, 2019 at 7:11 PM Kai Huang wrote:
>
> On Mon, 2019-06-17 at 18:50 -0700, Andy Lutomirski wrote:
> > On Mon, Jun 17, 2019 at 5:48 PM Kai Huang wrote:
> > >
> > >
> > > >
> > > > > And another silly argument: if we had /dev/mktme, then we could
> > > > > possibly get away with
Add initial version of device tree for Facebook Minipack ast2500 BMC.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/aspeed-bmc-facebook-minipack.dts | 429 ++
2 files changed, 430 insertions(+)
create mode 100644
Callers of hrtimer_forward_now() should save the return value in u64.
function rtc_pie_update_irq() stores it in variable 'count' of type int
change type of count from unsigned long to u64 to solve the issue.
Signed-off-by: Puranjay Mohan
---
RESEND - Added required mailing lists in CC
On Mon, Jun 17, 2019 at 6:45 PM Andrew Morton wrote:
>
> On Mon, 17 Jun 2019 06:23:07 -0700 Shakeel Butt wrote:
>
> > > Here is a patch to use CSS_TASK_ITER_PROCS.
> > >
> > > From 415e52cf55bc4ad931e4f005421b827f0b02693d Mon Sep 17 00:00:00 2001
> > > From: Tetsuo Handa
> > > Date: Mon, 17 Jun
> > Right, but regardless of the spec we have to consider that the
> > behaviour of XFS comes from it's Irix heritage (actually from EFS,
> > the predecessor of XFS from the late 1980s)
>
> Sure. And as I mentioned, I think it's technically the nicer guarantee.
>
> That said, it's a pretty
Callers of hrtimer_forward_now() should save the return value in u64.
change type of missed from unsigned long to u64.
Signed-off-by: Puranjay Mohan
---
RESEND - Added required mailing lists in CC
drivers/media/pci/cx88/cx88-input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Mon, Jun 17, 2019 at 6:40 PM Andy Lutomirski wrote:
>
> On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas
> wrote:
> >
> > On 6/17/19 6:59 PM, Kai Huang wrote:
> > > On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>
> > >
> > > And yes from my reading (better to have AMD guys to confirm)
On Mon, 2019-06-17 at 23:36 +0200, Takashi Iwai wrote:
> On Mon, 17 Jun 2019 22:51:42 +0200,
> Ranjani Sridharan wrote:
> >
> > On Mon, 2019-06-17 at 13:36 +0200, Amadeusz Sławiński wrote:
> > > When we unload Skylake driver we may end up calling
> > > hdac_component_master_unbind(), it uses
From: Saravana Kannan
From: Saravana Kannan
Many CPU architectures have caches that can scale independent of the CPUs.
Frequency scaling of the caches is necessary to make sure the cache is not
a performance bottleneck that leads to poor performance and power. The same
idea applies for
From: Hsin-Yi Wang
This is based on mediatek's devfreq patches[1].
In MT8183 SoC, CCI and little core cluster share same regulator. In original
implementation, CCI frequency depends on regulator voltage, which results in
bad memory access performance if tasks are loaded on other cpus other than
From: Hsin-Yi Wang
This series uses cpufreq-map governor for mt8183-cci to improve performance.
Hsin-Yi Wang (1):
devfreq: mt8183-cci: using cpufreq-map governor in cci dvfs driver
Saravana Kannan (1):
PM / devfreq: Generic CPU frequency to device frequency mapping
governor
Fix CRAMFS_BLK_FLAG_UNCOMPRESSED to use "U" cast to avoid shifting signed
32-bit value by 31 bits problem. This isn't a problem for kernel builds
with gcc.
This could be problem since this header is part of public API which
could be included for builds using compilers that don't handle this
On Mon, Jun 17, 2019 at 12:26:01AM +0200, Thomas Gleixner wrote:
> Nah. The straight forward approach is to do right when the secondary CPU
> comes into life, before it does any cr4 write (except for the code in
> entry_64.S), something like the below.
Okay, will do; thanks! :) I'll respin things
On Mon, Jun 17, 2019 at 9:28 PM Andrew Lunn wrote:
>
> On Mon, Jun 17, 2019 at 09:49:27AM +0530, Yash Shah wrote:
...
> > static const struct macb_config at91sam9260_config = {
> > .caps = MACB_CAPS_USRIO_HAS_CLKEN |
> > MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
> > .clk_init =
Hi Linus,
Please pull this fix for what I'm calling "meminit" (the compiler-based
variable-init stuff) for v5.2-rc6. This is a small update to the stack
auto-initialization self-test code to deal with the Clang initialization
pattern. It's been in linux-next for a couple weeks; I had waited a bit
Hi Jiada
> From: Nilkanth Ahirrao
>
> commit 7e4f3419ebfe ("ASoC: rsnd: add .get_id/.get_id_sub")
> introduces rsnd_ctu_id which calcualates and gives
> the main Device id of the CTU by dividing the id by 4.
> rsnd_mod_id uses this interface to get the CTU main
> Device id. But this commit
Hello Joe,
Thanks for reviewing the patch.
On Tue, Jun 18, 2019 at 5:55 AM Joe Perches wrote:
>
> On Mon, 2019-06-17 at 21:10 +0530, Sagar Kadam wrote:
> > On Sun, Jun 16, 2019 at 6:35 PM Vignesh Raghavendra wrote:
> []
> > > > +static int issi_unlock(struct spi_nor *nor, loff_t ofs, uint64_t
On Wed, Jun 05, 2019 at 02:58:32PM -0700, Dan Williams wrote:
>Given there are no more usages of is_dev_zone() outside of 'ifdef
>CONFIG_ZONE_DEVICE' protection, kill off the compilation helper.
>
>Cc: Michal Hocko
>Cc: Logan Gunthorpe
>Acked-by: David Hildenbrand
>Reviewed-by: Oscar Salvador
On 6/17/19 5:35 PM, Douglas Gilbert wrote:
For sg3_utils:
$ find . -name '*.c' -exec grep "/proc/scsi" {} \; -print
static const char * proc_allow_dio = "/proc/scsi/sg/allow_dio";
./src/sg_read.c
static const char * proc_allow_dio = "/proc/scsi/sg/allow_dio";
./src/sgp_dd.c
static const char *
On Mon, 17 Jun 2019, Alistair Francis wrote:
> > The legacy M-mode U-boot handles the phy reset already, and I’ve been
> > able to load upstream S-mode uboot as a payload via TFTP, and then
> > load and boot a 4.19 kernel.
> >
> > It would be nice to get this all working with 5.x, however
On Mon, Jun 17, 2019 at 08:01:52PM -0700, Alexei Starovoitov wrote:
> On Mon, Jun 17, 2019 at 6:54 PM Kris Van Hees
> wrote:
> >
> > It is not hypothetical. The folowing example works fine:
> >
> > static int noinline bpf_action(void *ctx, long fd, long buf, long count)
> > {
> > int
After commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
it will print "ptrval" instead of actual addresses when mbigen
create domain fails,
Hisilicon MBIGEN-V2 HISI0152:00: Failed to create mbi-gen@(ptrval)
irqdomain
Hisilicon MBIGEN-V2: probe of HISI0152:00
From: Wanpeng Li
On a machine, cpu 0 is used for housekeeping, other 39 cpus are in
nohz_full mode. We can observe huge time burn in the loop for seaching
nearest busy housekeeper cpu by ftrace.
2) |get_nohz_timer_target() {
2) 0.240 us|
+Rafael
On 17-06-19, 17:02, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 08:22:04AM +0530, Viresh Kumar wrote:
> > Hmm, even if the values are same currently I am not sure if we want
> > the same for ever. I will write a patch for it though, if Peter/Rafael
> > feel the same as you.
>
> Is it
Linux kernel tolerates C++ style comments these days. Actually, the
SPDX License tags for .c files start with //.
On the other hand, uapi headers are written in more strict C, where
the C++ comment style is forbidden.
I simply dropped these lines instead of fixing the comment style.
This code
On 6/17/2019 11:32 AM, Xiaoyao Li wrote:
On 6/16/2019 5:55 PM, Tao Xu wrote:
UMWAIT and TPAUSE instructions use IA32_UMWAIT_CONTROL at MSR index E1H
to determines the maximum time in TSC-quanta that the processor can
reside
in either C0.1 or C0.2.
This patch emulates MSR
On Mon, Jun 17, 2019 at 6:54 PM Kris Van Hees wrote:
>
> It is not hypothetical. The folowing example works fine:
>
> static int noinline bpf_action(void *ctx, long fd, long buf, long count)
> {
> int cpu = bpf_get_smp_processor_id();
> struct data {
>
From: Nilkanth Ahirrao
commit 7e4f3419ebfe ("ASoC: rsnd: add .get_id/.get_id_sub")
introduces rsnd_ctu_id which calcualates and gives
the main Device id of the CTU by dividing the id by 4.
rsnd_mod_id uses this interface to get the CTU main
Device id. But this commit forgets to revert the main
On Mon, Jun 17, 2019 at 05:19:02PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 5:09 PM Fenghua Yu wrote:
> But you're already using a mutex and a comment. And you're hoping
> that the syscore resume callback reads something sensible despite the
> lack of READ_ONCE / WRITE_ONCE. The
On 6/17/2019 11:50 PM, Radim Krčmář wrote:
2019-06-17 14:31+0800, Xiaoyao Li:
On 6/17/2019 11:32 AM, Xiaoyao Li wrote:
On 6/16/2019 5:55 PM, Tao Xu wrote:
+ if (vmx->msr_ia32_umwait_control != host_umwait_control)
+ add_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL,
+
Remove function ODM_ConfigMACWithHeaderFile as trace is not necessary
and as it is getting called only once and call direct function
"ODM_ReadAndConfig_MP_8723B_MAC_REG"
Issue identified by coccicheck
Signed-off-by: Hariprasad Kelam
changes v2: fixed typo in commit message
changes v3:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/hpet
head: e68a1d0fce032346dbfeca0140d90da75796bab9
commit: 64cdfa23aeb4a6be1a3c0d84bc3fd269581767e5 [14/29] x86/hpet: Remove not
required includes
config: i386-randconfig-n004-201924 (attached as .config)
compiler:
When building with clang, the following modpost warning occurs:
WARNING: vmlinux.o(.text+0x974dbc): Section mismatch in reference from
the function imx6q_obtain_fixed_clk_hw() to the function
.init.text:imx_obtain_fixed_clock_hw()
The function imx6q_obtain_fixed_clk_hw() references
the function
The supported formats are S16_LE and S24_LE now. However, S24_LE is
not supported when TDM is 0 and it is not in the right justified mode.
We should remove 24-bit format in that situation to avoid triggering
error.
Signed-off-by: Yu-Hsuan Hsu
---
Changed the order of the conditional.
Remove the
On Mon, 2019-06-17 at 18:43 -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 6:35 PM Kai Huang wrote:
> >
> >
> > > > >
> > > > > I'm having a hard time imagining that ever working -- wouldn't it blow
> > > > > up if someone did:
> > > > >
> > > > > fd = open("/dev/anything987");
> > >
On Sat, 1 Jun 2019 00:19:17 +0900
Masami Hiramatsu wrote:
> +static bool trace_uprobe_match_command_head(struct trace_uprobe *tu,
> + int argc, const char **argv)
> +{
> + char buf[MAX_ARGSTR_LEN + 1];
> + int len;
> +
> + if (!argc)
> +
From: Anson Huang
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system
On Mon, 2019-06-17 at 18:50 -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 5:48 PM Kai Huang wrote:
> >
> >
> > >
> > > > And another silly argument: if we had /dev/mktme, then we could
> > > > possibly get away with avoiding all the keyring stuff entirely.
> > > > Instead, you open
stable-rc/linux-4.19.y boot: 110 boots: 1 failed, 109 passed
(v4.19.52-76-ge7db76b325b2)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.52-76-ge7db76b325b2/
Full Build Summary:
stable-rc/linux-5.1.y boot: 118 boots: 1 failed, 117 passed
(v5.1.11-116-ga1610563f19b)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.1.y/kernel/v5.1.11-116-ga1610563f19b/
Full Build Summary:
clang warns:
arch/arm/mach-iop13xx/pci.c:292:7: warning: logical not is only applied
to the left hand side of this comparison [-Wlogical-not-parentheses]
if (!iop13xx_atux_pci_status(1) == 0)
^ ~~
arch/arm/mach-iop13xx/pci.c:439:7:
On 6/17/19 8:40 PM, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas
> wrote:
>>
>> On 6/17/19 6:59 PM, Kai Huang wrote:
>>> On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>
>>>
>>> And yes from my reading (better to have AMD guys to confirm) SEV guest uses
>>>
On Fri, Jun 14, 2019 at 02:24:09PM -1000, Linus Torvalds wrote:
> On Fri, Jun 14, 2019 at 1:08 PM Casey Schaufler
> wrote:
> >
> > Al, are you going to take this, or should I find another way
> > to get it in for 5.2?
>
> I guess I can take it directly.
>
> I was assuming it would come through
On Sat, 15 Jun 2019 10:06:54 +0200 Christophe Leroy
wrote:
>
>
> Le 14/06/2019 à 21:00, Andrew Morton a écrit :
> > On Fri, 14 Jun 2019 12:01:09 +0200 David Hildenbrand
> > wrote:
> >
> >> We are using a mixture of "int" and "unsigned long". Let's make this
> >> consistent by using
On Sat, 1 Jun 2019 00:18:16 +0900
Masami Hiramatsu wrote:
> Split the trace_event related data from trace_probe data structure
> and introduce trace_probe_event data structure for its folder.
> This trace_probe_event data structure can have multiple trace_probe.
>
> Signed-off-by: Masami
On Mon, Jun 17, 2019 at 06:32:22PM -0700, Alexei Starovoitov wrote:
> On Mon, Jun 17, 2019 at 6:25 PM Kris Van Hees
> wrote:
> >
> > On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:
> >
> > << stuff skipped because it is not relevant to the technical discussion...
> > >>
> >
On 17/6/19 2:41 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
If an OpenCAPI context is to be used directly by a kernel driver, there
may not be a suitable mm to use.
The patch makes the mm parameter to ocxl_context_attach optional.
Signed-off-by: Alastair D'Silva
The one issue I can
On Mon, Jun 17, 2019 at 5:48 PM Kai Huang wrote:
>
>
> >
> > > And another silly argument: if we had /dev/mktme, then we could
> > > possibly get away with avoiding all the keyring stuff entirely.
> > > Instead, you open /dev/mktme and you get your own key under the hook.
> > > If you want two
On 6/17/19 6:02 AM, Borislav Petkov wrote:
> On Fri, Jun 14, 2019 at 09:15:19PM +, Lendacky, Thomas wrote:
>> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
>> index ca2252ca6ad7..a7aa65b44c71 100644
>> --- a/arch/x86/kernel/vmlinux.lds.S
>> +++
Hi all,
A 32-bit ARM allyesconfig fails to link after commit 992aa864dca0
("mlxsw: spectrum_ptp: Add implementation for physical hardware clock
operations") because of 64-bit division:
arm-linux-gnueabi-ld:
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.o: in function
On Mon, 17 Jun 2019 06:23:07 -0700 Shakeel Butt wrote:
> > Here is a patch to use CSS_TASK_ITER_PROCS.
> >
> > From 415e52cf55bc4ad931e4f005421b827f0b02693d Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Mon, 17 Jun 2019 00:09:38 +0900
> > Subject: [PATCH] mm: memcontrol: Use
On Mon, Jun 17, 2019 at 6:35 PM Kai Huang wrote:
>
>
> > > >
> > > > I'm having a hard time imagining that ever working -- wouldn't it blow
> > > > up if someone did:
> > > >
> > > > fd = open("/dev/anything987");
> > > > ptr1 = mmap(fd);
> > > > ptr2 = mmap(fd);
> > > > sys_encrypt(ptr1);
> > >
kmalloc with memset can be replaced with kzalloc.
Signed-off-by: Hariprasad Kelam
-
changes in v2: Replace rtw_zmalloc with kzalloc
---
---
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git
On 6/17/19 5:47 AM, Borislav Petkov wrote:
> On Fri, Jun 14, 2019 at 09:15:18PM +, Lendacky, Thomas wrote:
>> The memory occupied by the kernel is reserved using memblock_reserve()
>> in setup_arch(). Currently, the area is from symbols _text to __bss_stop.
>> Everything after __bss_stop
On Wed, Jun 05, 2019 at 02:58:04PM -0700, Dan Williams wrote:
>Sub-section hotplug support reduces the unit of operation of hotplug
>from section-sized-units (PAGES_PER_SECTION) to sub-section-sized units
>(PAGES_PER_SUBSECTION). Teach shrink_{zone,pgdat}_span() to consider
>PAGES_PER_SUBSECTION
On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas
wrote:
>
> On 6/17/19 6:59 PM, Kai Huang wrote:
> > On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
> >
> > And yes from my reading (better to have AMD guys to confirm) SEV guest uses
> > anonymous memory, but it
> > also pins all guest
> > >
> > > I'm having a hard time imagining that ever working -- wouldn't it blow
> > > up if someone did:
> > >
> > > fd = open("/dev/anything987");
> > > ptr1 = mmap(fd);
> > > ptr2 = mmap(fd);
> > > sys_encrypt(ptr1);
> > >
> > > So I think it really has to be:
> > > fd =
On 6/17/19 6:59 PM, Kai Huang wrote:
> On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>> Tom Lendacky, could you take a look down in the message to the talk of
>> SEV? I want to make sure I'm not misrepresenting what it does today.
Sorry, I'm traveling this week, so responses will be
> On Jun 17, 2019, at 5:55 PM, Sasha Levin wrote:
>
> On Mon, Jun 17, 2019 at 07:14:53PM +, Nadav Amit wrote:
>>> On Jun 15, 2019, at 3:15 PM, Sasha Levin wrote:
>>>
>>> Hi,
>>>
>>> [This is an automated email]
>>>
>>> This commit has been processed because it contains a "Fixes:" tag,
On Mon, Jun 17, 2019 at 6:25 PM Kris Van Hees wrote:
>
> On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:
>
> << stuff skipped because it is not relevant to the technical discussion... >>
>
> > > > In particular you brought up a good point that there is a use case
> > > > for
Before this patch, USB storage devices disabled VPD check by always setting
skip_vpd_check.
The first patch add a new entry to scsi_static_device_list related to SanDisk
Cruzer Blade, which have VPD, adding BLIST_TRY_VPD_PAGES flag, which implies
try_vpd_pages.
The second patch check
Currently, all USB devices skip VPD pages, even when the device supports
them (SPC-3 and later), but some of them support VPD, like Cruzer Blade.
Signed-off-by: Marcos Paulo de Souza
---
drivers/scsi/scsi_devinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
If BLIST_TRY_VPD_PAGES is set for a device, even for an USB, it should
be honored, so only set skip_vpd_pages is try_vpd_pages is not set.
Signed-off-by: Marcos Paulo de Souza
---
drivers/usb/storage/scsiglue.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
stable-rc/linux-4.14.y boot: 105 boots: 0 failed, 105 passed
(v4.14.127-54-g1ed3ad23f285)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.127-54-g1ed3ad23f285/
Full Build Summary:
On Sun, Jun 16, 2019 at 10:15:22AM +0300, Dan Carpenter wrote:
> On Sun, Jun 16, 2019 at 11:02:50AM +0530, Hariprasad Kelam wrote:
> > rtw_malloc with memset can be replace with rtw_zmalloc.
> >
> > Signed-off-by: Hariprasad Kelam
> > ---
> > drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 12
Hello dear,
We are in the market for your products after meeting at your stand during last
expo.
Please kindly send us your latest catalog and price list so as to start a new
project/order as promised during the exhibition.
I would appreciate your response about the above details required
On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:
<< stuff skipped because it is not relevant to the technical discussion... >>
> > > In particular you brought up a good point that there is a use case
> > > for sharing a piece of bpf program between kprobe and tracepoint
Hi Miquel,
>
> > > > > > > > +static void mxic_nand_select_chip(struct nand_chip *chip,
int
> >
> > > > chipnr)
> > > > > > >
> > > > > > > _select_target() is preferred now
> > > > > >
> > > > > > Do you mean I implement mxic_nand_select_target() to control
#CS ?
> > > > > >
> > > >
ERROR: spaces required around that '<<' (ctx:VxV)
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c
Remove variable pHalData as it is not being used in function.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
This patch tries to fix below issues reported by checkpatch
CHECK: Using comparison to true is error prone
CHECK: Using comparison to true is false prone
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 38 +++
1 file changed, 19
On Mon, 17 Jun 2019, Douglas Gilbert wrote:
> On 2019-06-17 5:11 p.m., Bart Van Assche wrote:
> > On 6/12/19 6:59 AM, Marc Gonzalez wrote:
> > > According to the option's help message, SCSI_PROC_FS has been
> > > superseded for ~15 years. Don't select it by default anymore.
> > >
> > >
This patch tries to fix below issues reported by checkpatch
CHECK: Comparison to NULL could be written "!efuseTbl"
CHECK: Comparison to NULL could be written "!psta"
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 4 ++--
1 file changed, 2 insertions(+),
On Mon, Jun 17, 2019 at 03:32:45PM -0700, Dan Williams wrote:
>On Mon, Jun 17, 2019 at 3:22 PM Wei Yang wrote:
>>
>> On Wed, Jun 05, 2019 at 02:57:59PM -0700, Dan Williams wrote:
>> >Prepare for hot{plug,remove} of sub-ranges of a section by tracking a
>> >sub-section active bitmask, each bit
On Tue, 18 Jun 2019 at 08:44, Wanpeng Li wrote:
>
> On Tue, 18 Jun 2019 at 05:32, Radim Krčmář wrote:
> >
> > 2019-06-17 19:24+0800, Wanpeng Li:
> > > From: Wanpeng Li
> > >
> > > Wait before calling posted-interrupt deliver function directly to add
> > > advance timer support to
On Mon, Jun 17, 2019 at 07:14:53PM +, Nadav Amit wrote:
On Jun 15, 2019, at 3:15 PM, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ff3cc952d3f0 resource: Add remove_resource interface.
The bot has
>
> > And another silly argument: if we had /dev/mktme, then we could
> > possibly get away with avoiding all the keyring stuff entirely.
> > Instead, you open /dev/mktme and you get your own key under the hook.
> > If you want two keys, you open /dev/mktme twice. If you want some
> > other
On Mon, Jun 17, 2019 at 8:21 PM Christoph Hellwig wrote:
>
> When using a virt_boundary_mask, as done for NVMe devices attached to
> mpt3sas controllers we require an unlimited max_segment_size, as the
> virt boundary merging code assumes that. But we also need to propagate
> that to the DMA
The flag is very easy to understand but the interface is not,
especially the assumption that add_timer_on() must be used to
guarantee a correct behavior.
For example, currently if we setup a pinned timer but later on we call
mod_timer() upon the pinned timer, the mod_timer() will still try to
run
On Tue, 18 Jun 2019 at 05:32, Radim Krčmář wrote:
>
> 2019-06-17 19:24+0800, Wanpeng Li:
> > From: Wanpeng Li
> >
> > Wait before calling posted-interrupt deliver function directly to add
> > advance timer support to pi_inject_timer.
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Cc:
1 - 100 of 1494 matches
Mail list logo
