On Wed, 15 May 2019 16:38:58 -0500, Sean Christopherson
wrote:
On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote:
2) Just like any other DSO, there are potential issues with how
enclaves deal with writable vs executable memory. This takes two
forms. First, a task should proba
On Wed, May 15, 2019 at 5:25 PM Verma, Vishal L
wrote:
>
> On Wed, 2019-05-15 at 16:25 -0700, Dan Williams wrote:
> >
> > > diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
> > > index 4671776f5623..9f02a99cfac0 100644
> > > --- a/drivers/nvdimm/btt.c
> > > +++ b/drivers/nvdimm/btt.c
> > >
On Wed, May 15, 2019 at 5:27 PM Steven Rostedt wrote:
>
> I can do this, but it needs testing and all that before sending to you,
> and may not make the merge window. Is that fine?
It's fine. The warning is annoying, but that's my own fault for
updating my system just before the merge window.
>>}
>>
>> diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
>> index 7ff684159f29..2eb6a6cfe9e4 100644
>> --- a/drivers/nvdimm/bus.c
>> +++ b/drivers/nvdimm/bus.c
>> @@ -642,7 +642,7 @@ static struct attribute *nd_device_attributes[] = {
>>NULL,
>> };
>>
>> -/**
>
> On May 15, 2019, at 7:25 PM, Dan Williams wrote:
>
> On Tue, May 14, 2019 at 8:08 AM Qian Cai wrote:
>>
>> Several places (dimm_devs.c, core.c etc) include label.h but only
>> label.c uses NSINDEX_SIGNATURE, so move its definition to label.c
>> instead.
>> In file included from drivers/nvd
+#ifndef _SOC_QCOM_RMNET_H_
+#define _SOC_QCOM_RMNET_H_
+
+#include
+
+/* Header structure that precedes packets in ETH_P_MAP protocol */
+struct rmnet_map_header {
+ u8 pad_len : 6;
+ u8 reserved_bit: 1;
+ u8 cd_bit : 1;
+ u8 mux_id;
+
On Wed, 15 May 2019 16:31:34 -0700
Linus Torvalds wrote:
> On Wed, May 15, 2019 at 4:29 PM Linus Torvalds
> wrote:
> >
> > One option is to just rewrite it something like
> >
> > const unsigned int offset = offsetof(struct trace_iterator, seq);
> > memset(offset+(void *)&iter, 0,
在 2019年05月15日 21:30, Borislav Petkov 写道:
> On Tue, Apr 30, 2019 at 03:44:20PM +0800, Lianbo Jiang wrote:
>> When SEV is active, the second kernel image is loaded into the
>> encrypted memory. Lets make sure that when kexec builds the
>> identity mapping page table it adds the memory encryption mask
Fix build warning,
kernel/fork.c:125:5: warning: symbol 'max_threads' was not declared. Should it
be static?
Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index b4cba953040a
On Wed, 2019-05-15 at 17:26 -0700, Dan Williams wrote:
> On Wed, May 15, 2019 at 5:25 PM Verma, Vishal L
> wrote:
> > On Wed, 2019-05-15 at 16:25 -0700, Dan Williams wrote:
> > > > diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
> > > > index 4671776f5623..9f02a99cfac0 100644
> > > > ---
Hi all,
Today's linux-next merge of the ftrace tree got a conflict in:
include/linux/compiler.h
between commit:
37686b1353cf ("tracing: Improve "if" macro code generation")
from Linus' tree and commit:
a15fd609ad53 ("tracing: Simplify "if" macro code")
from the ftrace tree.
I fixed it
On Thu, 16 May 2019 at 02:42, Ankur Arora wrote:
>
> On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
> > On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
> >> On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
> >>>
> >>>
> >>> Certain workloads perform poorly on KVM compared to baremetal
On Wed, 2019-05-15 at 06:20 +, Christophe Leroy wrote:
> Strict module RWX is just like strict kernel RWX, but for modules -
> so
> loadable modules aren't marked both writable and executable at the
> same
> time. This is handled by the generic code in kernel/module.c, and
> simply requires th
On Wed, May 15, 2019 at 04:44:19PM -0600, shuah wrote:
Hi Sasha and Dhaval,
On 4/11/19 11:37 AM, Dhaval Giani wrote:
Hi Folks,
This is a call for participation for the Linux Testing microconference
at LPC this year.
For those who were at LPC last year, as the closing panel mentioned,
testing
On 2019/5/16 7:48, Mao, Chenxi wrote:
> Hi Yann and Xiang:
> For this FAST_DEC_LOOP change, I only pick up decompress related patches to
> current kernel LZ4 implementation(based on 1.8.3).
> Here is my cherry-pick list:
> 2589c44 created LZ4_FAST_DEC_LOOP build macro
> 605d811 enable LZ4_FAST_
On Wed, May 15, 2019 at 11:12 AM Pavel Tatashin
wrote:
>
> > Hi Pavel,
> >
> > I am working on adding this sort of a workflow into a new daxctl command
> > (daxctl-reconfigure-device)- this will allow changing the 'mode' of a
> > dax device to kmem, online the resulting memory, and with your patch
> -Original Message-
> From: Sasha Levin
>
> On Fri, Apr 26, 2019 at 02:02:53PM -0700, Tim Bird wrote:
...
> >
> >With regards to the Testing microconference at Plumbers, I would like
> >to do a presentation on the current status of test standards and test
> >framework interoperability
On Fri, Apr 26, 2019 at 02:02:53PM -0700, Tim Bird wrote:
I'm in the process now of planning Automated Testing Summit 2019,
which is tentatively planned for Lyon, France on October 31. This is
the day after Embedded Linux Conference Europe and Open Source Summit
Europe, in Lyon. I've been worki
> -Original Message-
> From: Sumit Garg
> Sent: Tuesday, May 14, 2019 7:02 PM
> To: Sasha Levin
> Cc: Jarkko Sakkinen ; peterhu...@gmx.de;
> j...@ziepe.ca; cor...@lwn.net; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-...@vger.kernel.org; linux-
> integr...@vger.kernel.org;
On Wed, May 15, 2019 at 12:28 PM Vivek Goyal wrote:
>
> From: Stefan Hajnoczi
>
> Although struct dax_device itself is not tied to a block device, some
> DAX code assumes there is a block device. Make block devices optional
> by allowing bdev to be NULL in commonly used DAX APIs.
>
> When there
On Wed, May 15, 2019 at 4:29 PM Linus Torvalds
wrote:
>
> One option is to just rewrite it something like
>
> const unsigned int offset = offsetof(struct trace_iterator, seq);
> memset(offset+(void *)&iter, 0, sizeof(iter) - offset);
Side note: make it a well-named helper function
On Wed, May 15, 2019 at 10:36 AM Steven Rostedt wrote:
>
> The major changes in this tracing update includes:
This is not directly related to this pull request, but newer versions
of gcc hate your trace_iterator clearing trick.
This code:
/* reset all but tr, trace, and overruns
On Wed, May 15, 2019 at 04:44:19PM -0600, shuah wrote:
> Hi Sasha and Dhaval,
>
> On 4/11/19 11:37 AM, Dhaval Giani wrote:
> > Hi Folks,
> >
> > This is a call for participation for the Linux Testing microconference
> > at LPC this year.
> >
> > For those who were at LPC last year, as the closin
Hi Richard,
On 5/15/19, 2:01 PM, "Richard Weinberger" wrote:
> On Wed, May 15, 2019 at 10:45 PM Shreya Gangan (shgangan)
> wrote:
> >
> > Hi,
> >
> > /fs/ubifs/io.c has dump_stack() in multiple functions upon errors and
> > sometimes warnings.
> > Since the error and warning messages seem to
On Tue, May 14, 2019 at 8:08 AM Qian Cai wrote:
>
> Several places (dimm_devs.c, core.c etc) include label.h but only
> label.c uses NSINDEX_SIGNATURE, so move its definition to label.c
> instead.
> In file included from drivers/nvdimm/dimm_devs.c:23:
> drivers/nvdimm/label.h:41:19: warning: 'NSIN
On Wed, May 15, 2019 at 09:17:59AM -0700, Ravi Chandra Sadineni wrote:
> Hi Dmitry,
>
> On Mon, May 13, 2019 at 4:29 PM Dmitry Torokhov
> wrote:
> >
> > Hi Ravi,
> >
> > On Mon, May 13, 2019 at 3:06 PM Ravi Chandra Sadineni
> > wrote:
> > >
> > > Notify the PM core that this dev is the wake sour
On Wed, May 15, 2019 at 3:46 PM James Morris wrote:
>
> On Wed, 15 May 2019, Andy Lutomirski wrote:
>
> > > Why not just use an xattr, like security.sgx ?
> >
> > Wouldn't this make it so that only someone with CAP_MAC_ADMIN could
> > install an enclave? I think that this decision should be left
On Thu, May 16, 2019 at 7:10 AM wrote:
>
> From: Long Li
>
> An IOCTL uses up to 2 iovs. The 1st iov is the command itself, the 2nd iov is
> optional data for that command. The 1st iov is always allocated on the heap
> but the 2nd iov may point to a variable on the stack. This will trigger an
> e
On Wed, 15 May 2019, Andy Lutomirski wrote:
> > Why not just use an xattr, like security.sgx ?
>
> Wouldn't this make it so that only someone with CAP_MAC_ADMIN could
> install an enclave? I think that this decision should be left up the
> administrator, and it should be easy to set up a loose p
Hi Sasha and Dhaval,
On 4/11/19 11:37 AM, Dhaval Giani wrote:
Hi Folks,
This is a call for participation for the Linux Testing microconference
at LPC this year.
For those who were at LPC last year, as the closing panel mentioned,
testing is probably the next big push needed to improve quality.
- Ursprüngliche Mail -
> Von: "Joe Perches"
> An: "richard" , "linux-mtd"
> CC: "linux-kernel"
> Gesendet: Donnerstag, 16. Mai 2019 00:29:48
> Betreff: Re: [PATCH] MAINTAINERS: Update UBI/UBIFS git tree location
> On Wed, 2019-05-15 at 22:04 +0200, Richard Weinberger wrote:
>> Linus ask
On Wed, 2019-05-15 at 22:04 +0200, Richard Weinberger wrote:
> Linus asked to use kernel.org.
>
> Signed-off-by: Richard Weinberger
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5c38f21aee78..ba428cd613b8 100644
>
ср, 15 мая 2019 г. в 14:10, :
>
> From: Long Li
>
> An IOCTL uses up to 2 iovs. The 1st iov is the command itself, the 2nd iov is
> optional data for that command. The 1st iov is always allocated on the heap
> but the 2nd iov may point to a variable on the stack. This will trigger an
> error when
From: Enric Balletbo i Serra
The OTG disconnection event is generated after the presence/absence of
an ID connection, but some platforms don't have the ID pin connected, so
the event is not generated. In such case, for detecting the
disconnection event, we can get the cable state from an extcon d
Hi!
Thanks for the reminder to review this code. :) Sorry for the delay!
On Thu, Feb 14, 2019 at 11:49 PM Yue Hu wrote:
>
> From: Yue Hu
>
> Sometimes we hope to check boot loader log messages (e.g. Android
> Verified Boot status) when kernel is coming up. Generally it does
> depend on serial d
Instead of registering the hmat cache attributes in line with parsing
the table, save the attributes in the memory target and register them
after parsing completes. This will make it easier to register the
attributes later when hot add is supported.
Signed-off-by: Keith Busch
---
v1 -> v2:
Fix
Some of the memory nodes described in HMAT may not be online at the
time the hmat subsystem parses their nodes' attributes. Should the node be
set to online later, as can happen when using PMEM as RAM after boot, the
nodes will be missing their initiator links and performance attributes.
Regsiter
Hi,
On Tue, May 14, 2019 at 9:10 PM Rob Clark wrote:
> On Mon, May 13, 2019 at 3:48 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, May 9, 2019 at 11:44 AM Rob Clark wrote:
> >
> > > From: Douglas Anderson
> > >
> > > Let's fixup the reserved memory to re-add the things we deleted in
> >
On Wed, May 15, 2019 at 11:30:12AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 15, 2019 at 8:31 AM Matthias Kaehlcke wrote:
>
> > Raise the temperature of the GPU thermal trip point for speedy
> > to 80°C. This is the value used by the downstream Chrome OS 3.14
> > kernel, the 'official' k
Hi,
On Thu, May 9, 2019 at 12:08 PM Rob Clark wrote:
> From: Rob Clark
>
> This is unused on cheza. Delete the node to get rid of the reserved-
> memory section, and to avoid the driver from attempting to load a zap
> shader that doesn't exist every time it powers up the GPU.
>
> Signed-off-by
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
> Thanks for pointing this out. I think the ideal fix would be to
> correctly initialize/cleanup the coresched attributes in the cpu
> hotplug code path so that lock could be taken successfully if the
> sibling is offlined/onlined after coresched was enabled. We are
> working on another bug related
On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote:
> 2) Just like any other DSO, there are potential issues with how
> enclaves deal with writable vs executable memory. This takes two
> forms. First, a task should probably require EXECMEM, EXECMOD, or
> similar permission to run an
Hi Doug,
thanks for the review!
On Wed, May 15, 2019 at 11:30:24AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 15, 2019 at 8:31 AM Matthias Kaehlcke wrote:
>
> > This value matches what is used by the downstream Chrome OS 3.14
> > kernel, the 'official' kernel for veyron devices.
> >
> >
On Wed, 2019-05-15 at 15:10 +0200, Takashi Iwai wrote:
> On Mon, 13 May 2019 22:30:05 +0200,
> Ayman Bagabas wrote:
> > This update brings on the use of WMI BIOS management interface
> > found on
> > Huawei laptops. This interface can control the micmute LED found on
> > most
> > of these laptops,
> It's clear now, thanks.
> I don't immediately see how my isolation fix would make your fix stop
> working, will need to check. But I'm busy with other stuffs so it will
> take a while.
>
We have identified the issue and have a fix for this. The issue is
same as before, forced idle sibling has a r
The kheaders archive consisting of the kernel headers used for compiling
bpf programs is in /proc. However there is concern that moving it here
will make it permanent. Let us move it to /sys/kernel as discussed [1].
[1] https://lore.kernel.org/patchwork/patch/1067310/#1265969
Suggested-by: Steven
Hi,
Missatge de Rushikesh S Kadam del dia
dc., 15 de maig 2019 a les 12:41:
>
> This driver implements a slim layer to enable the ChromeOS
> EC kernel stack (cros_ec) to communicate with ChromeOS EC
> firmware running on the Intel Integrated Sensor Hub (ISH).
>
> The driver registers a ChromeOS E
Missatge de Enric Balletbo i Serra del
dia dc., 15 de maig 2019 a les 15:00:
>
> Hi,
>
> On 4/5/19 15:34, Rushikesh S Kadam wrote:
> > This driver implements a slim layer to enable the ChromeOS
> > EC kernel stack (cros_ec) to communicate with ChromeOS EC
> > firmware running on the Intel Integrat
Hi Neil,
On Wed, May 15, 2019 at 2:45 PM Neil Armstrong wrote:
>
> On 14/05/2019 19:58, Martin Blumenstingl wrote:
> > Hi Neil,
> >
> > On Mon, May 13, 2019 at 11:16 AM Neil Armstrong
> > wrote:
> > [...]
> >> @@ -1158,15 +1183,27 @@ static int meson_mmc_probe(struct platform_device
> >> *pdev
On Sat, May 11, 2019 at 6:29 AM Michael Witten wrote:
>
> What is the correct way to think about this?
>
> * Should the UAPI make no reference to build-time configurations?
Right, with the exception of uses inside of #ifdef __KERNEL__.
> * Should the UAPI headers include sanity checks on be
From: Long Li
An IOCTL uses up to 2 iovs. The 1st iov is the command itself, the 2nd iov is
optional data for that command. The 1st iov is always allocated on the heap
but the 2nd iov may point to a variable on the stack. This will trigger an
error when passing the 2nd iov for RDMA I/O.
Fix this
From: Long Li
SMBDirect manages its own ports in the transport layer, there is no need to
check the port to find a connection.
Signed-off-by: Long Li
---
fs/cifs/connect.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 0b3ac8b76d18..8c4121da
On Mon, May 6, 2019 at 11:24 PM Vandana BN wrote:
>
> fs/ubifs/xattr.c:615:58: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Vandana BN
> ---
> fs/ubifs/xattr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
> index
From: Kan Liang
A fast path will be introduced in the following patches to speed up the
cgroup events sched in, which only needs a simpler filter_match().
Add filter_match() as a parameter for pinned/flexible_sched_in().
No functional change.
Signed-off-by: Kan Liang
---
kernel/events/core.c
From: Kan Liang
Current RB tree for pinned/flexible groups doesn't take cgroup into
account. All events on a given CPU will be fed to
pinned/flexible_sched_in(), which relies on perf_cgroup_match() to
filter the events for a specific cgroup. The method has high overhead,
especially in frequent co
From: Kan Liang
Generic visit_groups_merge() is used in cgroup context switch to sched
in cgroup events, which has high overhead especially in frequent context
switch with several events and cgroups involved. Because it feeds all
events on a given CPU to pinned/flexible_sched_in() regardless the
From: Michele Dionisio
zstd shows a good compression rate and is faster than lzo,
also on slow ARM cores.
Cc: Sebastian Andrzej Siewior
Signed-off-by: Michele Dionisio
[rw: rewrote commit message]
Signed-off-by: Richard Weinberger
---
fs/ubifs/Kconfig | 10 ++
fs/ubifs/compress
From: Kan Liang
Changes since V1:
- Add new event_type to indicate cgroup only switch
Add cgrp_event_type to track event type of a cgroup
Extend ctx_pinned/flexible_sched_in and struct sched_in_data to pass
the event_type
- If the new cgroup has pinned events, schedule out all flexible even
From: Kan Liang
When counting system-wide events and cgroup events simultaneously, the
value of system-wide events are miscounting. For example,
perf stat -e cycles,instructions -e cycles,instructions -G
cgroup1,cgroup1,cgroup2,cgroup2 -a -e cycles,instructions -I 1000
1.096265502
On Wed, May 15, 2019 at 10:45 PM Shreya Gangan (shgangan)
wrote:
>
> Hi,
>
> /fs/ubifs/io.c has dump_stack() in multiple functions upon errors and
> sometimes warnings.
> Since the error and warning messages seem to be unique, the functional value
> of these dump_stacks is not apparent.
> Why a
Pass the server and volume break counts from before the status fetch
operation that queried the attributes of a file into afs_iget5_set() so
that the new vnode's break counters can be initialised appropriately.
This allows detection of a volume or server break that happened whilst we
were fetching
Don't save callback version and type fields as the version is about the
format of the callback information and the type is relative to the
particular RPC call.
Signed-off-by: David Howells
---
fs/afs/afs.h |4 ++--
fs/afs/fsclient.c |4 ++--
fs/afs/inode.c |8 +---
fs
Split afs_validate() so that the part that decides if the vnode is still
valid can be used under LOOKUP_RCU conditions from afs_d_revalidate().
Signed-off-by: David Howells
---
fs/afs/inode.c| 37 -
fs/afs/internal.h |1 +
2 files changed, 25 insert
Fix afs_do_lookup() such that when it does an inline bulk status fetch op,
it will update inodes that are already extant (something that afs_iget()
doesn't do) and to cache permits for each inode created (thereby avoiding a
follow up FS.FetchStatus call to determine this).
Extant inodes need looki
Make use of the status update for the target file that the YFS.RemoveFile2
RPC op returns to correctly update the vnode as to whether the file was
actually deleted or just had nlink reduced.
Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client")
Signed-off-by: David Howells
---
fs/
Fix afs_validate() to clear AFS_VNODE_CB_PROMISED on a vnode if we detect
any condition that causes the callback promise to be broken implicitly,
including server break (cb_s_break), volume break (cb_v_break) or callback
expiry.
Fixes: ae3b7361dc0e ("afs: Fix validation/callback interaction")
Repo
When applying the status and callback in the response of an operation,
apply them in the same critical section so that there's no race between
checking the callback state and checking status-dependent state (such as
the data version).
Fix this by:
(1) Allocating a joint {status,callback} record
afs_do_lookup() will do an order-1 allocation to allocate status records if
there are more than 39 vnodes to stat.
Fix this by allocating an array of {status,callback} records for each vnode
we want to examine using vmalloc() if larger than a page.
This not only gets rid of the order-1 allocation
Use RCU-based freeing for afs_cb_interest struct objects and use RCU on
vnode->cb_interest. Use that change to allow afs_check_validity() to use
read_seqbegin_or_lock() instead of read_seqlock_excl().
This also requires the caller of afs_check_validity() to hold the RCU read
lock across the call.
Always ask for the reply time from AF_RXRPC as it's used to calculate the
callback expiry time and lock expiry times, so it's needed by most FS
operations.
Signed-off-by: David Howells
---
fs/afs/fsclient.c |9 -
fs/afs/internal.h |2 +-
fs/afs/rxrpc.c |4 ++--
fs/afs/
Replace the afs_call::reply[] array with a bunch of typed members so that
the compiler can use type-checking on them. It's also easier for the eye
to see what's going on.
Signed-off-by: David Howells
---
fs/afs/cmservice.c | 14 +--
fs/afs/file.c |2
fs/afs/flock.c |2
fs/
Don't pass the vnode pointer through into the inline bulk status op. We
want to process the status records outside of it anyway.
Signed-off-by: David Howells
---
fs/afs/fsclient.c |7 +--
fs/afs/yfsclient.c | 10 +-
2 files changed, 2 insertions(+), 15 deletions(-)
diff --g
k() from the operation wrapper rather than
from the delivery function.
(F) Don't store the version and type from a callback promise in a reply as
the information in them is of very limited use.
The patches can be found here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/l
Hi Sakari,
On Wednesday, May 15, 2019 9:16:02 AM CEST Sakari Ailus wrote:
> Hi Janusz,
>
> On Wed, May 15, 2019 at 12:48:21AM +0200, Janusz Krzysztofik wrote:
> > -static int check_crop(struct v4l2_subdev *sd, struct v4l2_subdev_crop
*crop)
> > +static inline int check_pad(struct v4l2_subdev *sd
On Wed, 2019-05-15 at 15:11 +0200, Takashi Iwai wrote:
> On Mon, 13 May 2019 22:30:06 +0200,
> Ayman Bagabas wrote:
> > Since this LED is found on huawei laptops, we can hook it to
> > huawei-wmi platform driver which uses the common WMI interface
> > present
> > in these laptops to control the LED
Hi,
/fs/ubifs/io.c has dump_stack() in multiple functions upon errors and
sometimes warnings.
Since the error and warning messages seem to be unique, the functional value of
these dump_stacks is not apparent.
Why are these dump_stacks required and what issues might occur upon the removal
On Wed, May 15, 2019 at 2:26 PM Alex Elder wrote:
> On 5/15/19 2:34 AM, Arnd Bergmann wrote:
> >> +/* Cancel a channel's pending transactions */
> >> +void gsi_channel_trans_cancel_pending(struct gsi_channel *channel)
> >> +{
> >> + struct gsi_trans_info *trans_info = &channel->trans_info;
>
On Wed, May 15, 2019 at 12:55:55PM +0200, Greg Kroah-Hartman wrote:
> From: "Tobin C. Harding"
>
> [ Upstream commit bdfad5aec1392b93495b77b864d58d7f101dc1c1 ]
Greg you are not going to back port all of these kobject fixes are you?
There is going to be a _lot_ of them. I'm not super comfortable
[ add Mike and dm-devel ]
Mike, any concerns with the below addition to the device-mapper-dax
implementation?
On Tue, May 14, 2019 at 7:58 AM Pankaj Gupta wrote:
>
> This patch sets dax device 'DAXDEV_SYNC' flag if all the target
> devices of device mapper support synchrononous DAX. If device
> -Original Message-
> From: Alex Williamson
> Sent: Tuesday, May 14, 2019 5:20 PM
> To: Parav Pandit
> Cc: Cornelia Huck ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; kwankh...@nvidia.com; c...@nvidia.com; Tony
> Krowiak ; Pierre Morel ;
> Halil Pasic
> Subject: Re: [PATCH
On Wed, May 15, 2019 at 12:58 PM James Morris wrote:
>
> On Wed, 15 May 2019, Andy Lutomirski wrote:
>
> > There are two issues with how this interacts with LSMs:
> >
> > 1) LSMs might want to be able to whitelist, blacklist, or otherwise
> > restrict what enclaves can run at all. The current pro
O_TMPFILE files can change their link count back to non-zero.
This corner case needs to get addressed in the orphans subsystem
too.
Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE")
Reported-by: Lars Persson
Signed-off-by: Richard Weinberger
---
fs/ubifs/orphan.c | 39 +
On Fri, 3 May 2019, Andrea Arcangeli wrote:
> This reverts commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2.
>
> commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2 was rightfully applied
> to avoid the risk of a severe regression that was reported by the
> kernel test robot at the end of the merge wi
On Mon, Mar 11, 2019 at 5:08 PM Linus Torvalds
wrote:
>
> On Mon, Mar 11, 2019 at 8:37 AM Dan Williams wrote:
> >
> > Another feature the userspace tooling can support for the PMEM as RAM
> > case is the ability to complete an Address Range Scrub of the range
> > before it is added to the core-mm
On Wed, May 15, 2019 at 09:42:48AM +0800, Wanpeng Li wrote:
> On Wed, 15 May 2019 at 02:20, Marcelo Tosatti wrote:
> >
> > On Tue, May 14, 2019 at 11:20:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, May 14, 2019 at 10:50:23AM -0300, Marcelo Tosatti wrote:
> > > > On Mon, May 13, 2019 at 0
On Wed, 15 May 2019 11:52:57 -0700
Sultan Alsawaf wrote:
> On Wed, May 15, 2019 at 02:32:48PM -0400, Steven Rostedt wrote:
> > I'm confused why you did this?
>
> Oleg said that debug_locks_off() could've been called and thus prevented
> lockdep complaints about simple_lmk from appearing. To el
Linus asked to use kernel.org.
Signed-off-by: Richard Weinberger
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c38f21aee78..ba428cd613b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15879,7 +15879,7 @@ M: Richard Weinb
On Wed, 15 May 2019, Andy Lutomirski wrote:
> There are two issues with how this interacts with LSMs:
>
> 1) LSMs might want to be able to whitelist, blacklist, or otherwise
> restrict what enclaves can run at all. The current proposal that
> everyone seems to dislike the least is to have a .sig
On Wed, 15 May 2019 at 17:04, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.1.3 release.
> There are 46 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 know.
>
> Respo
On Tue, May 14, 2019 at 9:11 PM Richard Weinberger wrote:
>
> CONFIG_UBIFS_FS_ENCRYPTION is gone, fscrypt is now
> controlled via CONFIG_FS_ENCRYPTION.
> This problem slipped into the tree because of a mis-merge on
> my side.
>
> Reported-by: Eric Biggers
> Fixes: eea2c05d927b ("ubifs: Remove #if
On Wed, 15 May 2019 at 16:45, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.177 release.
> There are 51 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 know.
>
> Res
If an orphan has child orphans (xattrs), and due
to a commit the parent orpahn cannot get free()'ed immediately,
put also all child orphans on the erase list.
Otherwise UBIFS will free() them only upon unmount and we
waste memory.
Fixes: 988bec41318f ("ubifs: orphan: Handle xattrs like files")
Sig
Commit 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to
link VDSO") switched to using LD explicitly. The --build-id option
needs to be passed explicitly, similar to x86. Add this option.
Fixes: 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
Signed-off-by: Laura Abbo
stable-rc/linux-5.0.y boot: 139 boots: 0 failed, 136 passed with 1 offline, 1
untried/unknown, 1 conflict (v5.0.16-138-g174f1e44d016)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.0.y/kernel/v5.0.16-138-g174f1e44d016/
Full Build Summary:
https://kernelci.org/buil
Commit c877154d307f fixed an uninitialized variable and optimized
the function to not call tnc_next() in the first iteration of the
loop. While this seemed perfectly legit and wise, it turned out to
be illegal.
If the lookup function does not find an exact match it will rewind
the cursor by 1.
The
Em Fri, Apr 12, 2019 at 09:59:46PM +0800, Jin Yao escreveu:
> The 'percore' event qualifier which sums up the event counts for both
> hardware threads in a core. For example,
>
> perf stat -e cpu/event=0,umask=0x3,percore=1/,cpu/event=0,umask=0x3/
>
> In this example, we count the event 'ref-cycl
On Wed, May 15, 2019 at 06:11:15PM +0300, Kirill Tkhai wrote:
> This patchset adds a new syscall, which makes possible
> to clone a mapping from a process to another process.
> The syscall supplements the functionality provided
> by process_vm_writev() and process_vm_readv() syscalls,
> and it may
On Sun, May 12, 2019 at 3:25 AM Alex Elder wrote:
> +static int gsi_ring_alloc(struct gsi *gsi, struct gsi_ring *ring, u32 count)
> +{
> + size_t size = roundup_pow_of_two(count * sizeof(struct gsi_tre));
> + dma_addr_t addr;
> +
> + /* Hardware requires a power-of-2 ring size (
Hi Linus,
Here is the power-supply pull request for the 5.2 merge window.
Everything except for a few small fixes have been in linux-next
for > 10 days. The pull request is touching some bits in x86 for
the OLPC changes and some bits in IIO for the new Ingenic JZ47xx
battery driver, that have been
101 - 200 of 1544 matches
Mail list logo
