[ adding Jeff directly since he has also been looking at
infrastructure to track when MAP_SYNC should be disabled ]
On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams wrote:
> On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote:
>> This patch adds virtio-pmem driver for KVM
>> guest.
>
> Minor nit, p
On Wed, Apr 25, 2018 at 12:26 AM, Kalle Valo wrote:
> I have already applied an almost identical patch:
>
> ath9k: dfs: remove accidental use of stack VLA
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=9c27489a34548913baaaf3b2776e05d4a9389e3e
Ah! Cool, no
On 4/25/2018 10:23 AM, Jiri Olsa wrote:
On Wed, Apr 25, 2018 at 06:50:18AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf stat doesn't count the uncore event aliases from the same uncore
block in a group, for example:
perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a
On 04/18/2018 04:10 PM, Jakob Unterwurzacher wrote:
> bus-off is usually caused by hardware malfunction or
> configuration error (baud rate mismatch) and causes a
> complete loss of communication.
>
> Increase the "bus-off" message's severity from netdev_dbg
> to netdev_info to make it visible to
On Wed, Apr 25, 2018 at 12:33:40PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.37 release.
> There are 183 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 kno
Never directly free @dev after calling device_register(), even
if it returned an error. Always use put_device() to give up the
reference initialized.
Signed-off-by: Arvind Yadav
---
arch/arm/common/locomo.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/c
On Wed, 25 Apr 2018 22:20:50 +0900
DaeRyong Jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But tty_insert_flip_string_fixed_flag() can be executed concurrently and
> tb->used can be updated improperly.
The tty input l
Include SDM845 APSS shared to the list of possible bindings
Signed-off-by: Sibi Sankar
---
.../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt| 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
b/Documentation/de
This patch add the node to support APSS shared
mailbox on SDM845
Signed-off-by: Sibi Sankar
---
This patch depends on https://patchwork.kernel.org/patch/10276419/
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
Add the corresponding APSS shared offset for SDM845 SoC
Signed-off-by: Sibi Sankar
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
index 57bde0dfd12f..75da44d25fac 1
- Original Message -
> From: "Catalin Marinas"
> To: "Chunyu Hu"
> Cc: "Michal Hocko" , "Chunyu Hu" ,
> "Dmitry Vyukov" ,
> "LKML" , "Linux-MM"
> Sent: Wednesday, April 25, 2018 8:51:55 PM
> Subject: Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in
> gfp_kmemleak_mask
>
Hi Jerome:
On 04/25/2018 09:05 PM, Jerome Brunet wrote:
> On Thu, 2018-04-19 at 21:54 +0800, Yixun Lan wrote:
>> This patch try to add AO clock and Reset driver for Amlogic's
>> Meson-AXG SoC.
>> Please note that patch 7 need to wait for the DTS changes[3] merged
>> into mainline first, otherw
It currently only works if the parent bus uses "simple-bus". We
currently try to probe children with non-existing compatible values.
And we're missing .probe.
I noticed this while testing devices configured to probe using ti-sysc
interconnect target module driver. For that we also may want to rebi
On 04/25/2018 06:24 AM, Pankaj Gupta wrote:
> This patch adds virtio-pmem Qemu device.
>
> This device presents memory address range
> information to guest which is backed by file
> backend type. It acts like persistent memory
> device for KVM guest. Guest can perform read
> and persistent wri
On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote:
> This patch adds functionality to perform
> flush from guest to hosy over VIRTIO
> when 'ND_REGION_VIRTIO'flag is set on
> nd_negion. Flag is set by 'virtio-pmem'
> driver.
>
> Signed-off-by: Pankaj Gupta
> ---
> drivers/nvdimm/region_devs.c
On 04/25/2018 06:58 AM, Pankaj Gupta wrote:
>
> Hi,
>
> Compile failures are because Qemu 'Memory-Device changes' are not yet
> in qemu master. As mentioned in Qemu patch message patch is
> dependent on 'Memeory-device' patches by 'David Hildenbrand'.
On 04/25/2018 06:24 AM, Pankaj Gupta wrote:
On Wed, Apr 25, 2018 at 06:50:18AM -0700, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> Perf stat doesn't count the uncore event aliases from the same uncore
> block in a group, for example:
>
> perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000
> # time
Commit-ID: 51fc4be41c7ea7a00f6a17ad15ac9ea684d07921
Gitweb: https://git.kernel.org/tip/51fc4be41c7ea7a00f6a17ad15ac9ea684d07921
Author: Thomas Gleixner
AuthorDate: Tue, 24 Apr 2018 21:22:18 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 25 Apr 2018 16:11:58 +0200
tick/sched: Do not
On 04/25/2018 09:55 AM, Oleg Nesterov wrote:
On 04/24, Eric W. Biederman wrote:
Let me respectfully suggest that the wait_event_killable on that code
path is wrong.
I tend to agree even if I don't know this code.
But if it can be called from f_op->release() then any usage of "current" or
sig
On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote:
> This patch adds virtio-pmem driver for KVM
> guest.
Minor nit, please expand your changelog line wrapping to 72 columns.
>
> Guest reads the persistent memory range
> information from Qemu over VIRTIO and registers
> it on nvdimm_bus. It als
On Tue, Apr 24, 2018 at 07:30:43PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> We want to add support for device tree based early platform devices.
>
> In order not to introduce additional bloat for all users when we extend
> struct device to accomodate early platform DT su
Apologies for any problems my patch may be causing.
I'm unclear on what is the proposed fix, other than reverting the commit.
In the problem scenario, is a --symfs option used? Is the debug info being
obtained from the symfs directory?
Unfortunately, I've had to change my focus for the time be
On 04/25, Daniel Vetter wrote:
>
> On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote:
> > On 04/24, Daniel Vetter wrote:
> >>
> >> wait_event_killabel doesn't check for fatal_signal_pending before calling
> >> schedule, so definitely has a nice race there.
> >
> > This is fine. See the signal_p
On Tue, Apr 24, 2018 at 4:15 PM, Luc Van Oostenryck
wrote:
> The method struct vga_switcheroo_handler::get_client_id() is defined
> as returning an 'enum vga_switcheroo_client_id' but the implementation
> in this driver, gmux_get_client_id(), returns an 'int'.
>
> Fix this by returning 'enum vga_s
On Wed, Apr 25, 2018 at 07:36:21PM +0900, Tetsuo Handa wrote:
> Kees Cook wrote:
> > On Tue, Apr 24, 2018 at 12:58 PM, Serge E. Hallyn wrote:
> > > Quoting Tycho Andersen (ty...@tycho.ws):
> > >> On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote:
> > >> > Tycho Andersen wrote:
> > >> >
Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
filesystem with huge page support anymore. tmpfs can use huge page via
THP when mounting by "huge=" mount option.
When applications use huge page on hugetlbfs, it just need check the
filesystem magic number, but it is not enough for t
On Wed, Apr 25, 2018 at 05:25:47PM +0800, Leo Yan wrote:
>
> If we have concern for security issue, should we remove support for
> 'bpf_jit_enable = 2' and modify the doc to reflect this change?
I suggest to fix the doc.
On 4/23/2018 3:10 PM, Alex Williamson wrote:
>> Do we need a retrain API with the speed that driver wants to reach to?
>> API can return what was actually accomplished. The quirk from Alex can
>> run inside this API to make a decision on what speed do we actually want
>> to reach to for a given PCI
On 04/24/2018 11:22 AM, David Howells wrote:
> Stephen Smalley wrote:
>
>> Neither fsopen() nor fscontext_fs_write() appear to perform any kind of
>> up-front permission checking (DAC or MAC), although some security hooks may
>> be ultimately called to allocate structures, parse security options,
Enable the clock prior to calling clk_get_rate(), because clk_get_rate()
should only be called if the clock is enabled.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 142168eba9dc ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver")
Signed-off-by: Stefan Potyra
---
drivers/sp
On 24 April 2018 11:41:29 AM GMT-07:00, "Michael S. Tsirkin"
wrote:
>On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote:
>> Turns out virtio console tries to take a buffer out of an active vq.
>> Works by sheer luck, and is explicitly forbidden by spec. And while
>> going over
On Mon, Apr 23, 2018 at 11:19:25PM -0500, Alex G. wrote:
> That tells you what FFS said about the error.
I betcha those status and command values have a human-readable counterparts.
Btw, what do you abbreviate with "FFS"?
> It's immediately obvious if there's a glaring FFS bug and if we get bogu
Hi everyone,
A lot of things have happened in the move to make the kernel y2038
ready in recent times. I've sent out new patches recently but will be
on vacation for the next few weeks, so here's a quick update on where
we are today with recent changes and work in progress:
- A large number of sm
On 25/04/2018 10:48, Cornelia Huck wrote:
On Thu, 19 Apr 2018 16:48:13 +0200
Pierre Morel wrote:
In the current implementation, we do not want to start a new SSCH
command before the last one ends.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_fsm.c | 3 +++
drivers/s390/c
On Wed, Apr 25, 2018 at 04:47:01PM +0300, Jani Nikula wrote:
> On Fri, 06 Apr 2018, Heikki Krogerus wrote:
> > Using reStructuredText literal-block element with ascii-art.
> > That prevents the ascii art from being processed as
> > reStructuredText.
> >
> > Reported-by: Masanari Iida
> > Fixes: b
On Wed, Apr 25, 2018 at 8:39 PM, Maxime Ripard
wrote:
> On Wed, Apr 25, 2018 at 11:19:20AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Apr 25, 2018 at 3:37 AM, Maxime Ripard
>> wrote:
>> > On Tue, Apr 24, 2018 at 08:17:11PM +0800, Chen-Yu Tsai wrote:
>> >> On Tue, Apr 24, 2018 at 8:13 PM, Maxime Ripard
Eyal Reizer writes:
> pm_runtime handles sdio power on and power off transitions.
> An old workaround for trying to control the power explicitly from the
> driver was in fact causing failures on suspend/resume as the mmc layer
> already power the module on resume.
>
> In case of resume pm_runtime
On 25/04/2018 10:44, Cornelia Huck wrote:
On Thu, 19 Apr 2018 16:48:12 +0200
Pierre Morel wrote:
VFIO_CCW_STATE_BOXED and VFIO_CCW_STATE_BUSY are the same
states.
Let's only keep one: VFIO_CCW_STATE_BUSY
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_fsm.c | 9 -
dr
* Eyal Reizer [180425 13:43]:
> pm_runtime handles sdio power on and power off transitions.
> An old workaround for trying to control the power explicitly from the
> driver was in fact causing failures on suspend/resume as the mmc layer
> already power the module on resume.
>
> In case of resume
On Wed, Apr 25, 2018 at 06:29:05PM +0530, Jagan Teki wrote:
> On Tue, Apr 24, 2018 at 7:38 PM, Maxime Ripard
> wrote:
> > On Tue, Apr 24, 2018 at 07:04:12PM +0530, Jagan Teki wrote:
> >> Allwinner A64 has display engine pipeline like other Allwinner SOC's
> >> A83T/H3/H5.
> >>
> >> A64 DE2 behavi
On 04/24, Eric W. Biederman wrote:
>
> Let me respectfully suggest that the wait_event_killable on that code
> path is wrong.
I tend to agree even if I don't know this code.
But if it can be called from f_op->release() then any usage of "current" or
signals looks suspicious. Simply because "curre
On Wed, 25 Apr 2018 16:47:01 +0300
Jani Nikula wrote:
> On Fri, 06 Apr 2018, Heikki Krogerus wrote:
> > Using reStructuredText literal-block element with ascii-art.
> > That prevents the ascii art from being processed as
> > reStructuredText.
> >
> > Reported-by: Masanari Iida
> > Fixes: bdecb3
On 25/04/2018 10:25, Cornelia Huck wrote:
On Thu, 19 Apr 2018 16:48:06 +0200
Pierre Morel wrote:
The Sub channel event callback is threaded using workqueues.
The work uses the FSM introducing the VFIO_CCW_EVENT_SCH_EVENT
event.
I don't think this is a good name; after all, all of the events a
From: Kan Liang
Perf stat doesn't count the uncore event aliases from the same uncore
block in a group, for example:
perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000
# time counts unit events
1.000447342unc_m_cas_count.all
1.000
On Tue, Apr 24, 2018 at 03:18:21PM +0200, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
Hello Alex,
I have already proposed it few weeks ago.
https://lkml.org/lkml/2018/4/10/192
could you ack it, if you test it on your side?
Thanks,
Arnaud
On 04/25/2018 03:36 PM, Alex Elder wrote:
> The last commit to "remoteproc_core.c":
> 880f5b388252 remoteproc: eAPass type of shutdown to su
There is no reason to initialize uartclk to BASE_BAUD * 16 for DT based
systems.
Signed-off-by: Michal Simek
Tested-by: Matt Redfearn
---
It looks like from history that portclk = BASE_BAUD * 16 was setup to
get on calculation on x86 (divisor = 1) but it shouldn't be needed on DT based
system.
> On 25 Apr 2018, at 13:22, Dag Moxnes wrote:
>
> The function rds_ib_setup_qp is calling rds_ib_get_client_data and
> should correspondingly call rds_ib_dev_put. This call was lost in
> the non-error path with the introduction of error handling done in
> commit 3b12f73a5c29 ("rds: ib: add erro
Hi Anson,
On Wed, Apr 25, 2018 at 2:36 AM, Anson Huang wrote:
> Sorry, I made a mistake here, the MAX7320 IO0 is for adjusting FEC1's voltage,
In this case you need to pass the 'phy-supply' property inside the fec
node and add a regulator that is controlled via MAX7320 IO0 pin.
Hi Vaishali,
On Wednesday, 25 April 2018 16:42:59 EEST Vaishali Thakkar wrote:
> On Wed, Apr 25, 2018 at 7:02 PM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote:
> >> As specified in drm_drv.c, drm_dev_unref is a compatibility alias
> >> for drm_dev_pu
On Fri, 06 Apr 2018, Heikki Krogerus wrote:
> Using reStructuredText literal-block element with ascii-art.
> That prevents the ascii art from being processed as
> reStructuredText.
>
> Reported-by: Masanari Iida
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C
> Multiplexers")
On 04/24/2018 05:40 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On
On Wed, Apr 25, 2018 at 7:02 PM, Laurent Pinchart
wrote:
> Hi Vaishali,
>
> Thank you for the patch.
>
> On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote:
>> As specified in drm_drv.c, drm_dev_unref is a compatibility alias
>> for drm_dev_put and shouldn't be used in new code. So,
On Wed, 25 Apr 2018 14:38:36 +0200,
Paul Menzel wrote:
>
> Dear Takashi,
>
>
> On 04/25/18 14:34, Takashi Iwai wrote:
> > On Wed, 25 Apr 2018 14:29:31 +0200, Paul Menzel wrote:
>
> >> On 04/25/18 13:58, Takashi Iwai wrote:
> >>> On Wed, 25 Apr 2018 13:48:27 +0200, Paul Menzel wrote:
> >>
>
On 04/24/2018 10:27 PM, Eric Dumazet wrote:
> When adding tcp mmap() implementation, I forgot that socket lock
> had to be taken before current->mm->mmap_sem. syzbot eventually caught
> the bug.
> +
...
> + down_read(¤t->mm->mmap_sem);
> +
> + ret = -EINVAL;
> + vma = find_vma(c
pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.
In case of resume pm_runtime_get sync returns a positive devi
On Wed, Apr 25, 2018 at 10:20:50PM +0900, DaeRyong Jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But tty_insert_flip_string_fixed_flag() can be executed concurrently and
> tb->used can be updated improperly.
> It leads
On 4/25/2018 8:59 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Apr 25, 2018 at 08:27:31AM -0400, Liang, Kan escreveu:
On 4/24/2018 3:29 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Apr 24, 2018 at 03:23:06PM -0400, Liang, Kan escreveu:
On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote:
E
The last commit to "remoteproc_core.c":
880f5b388252 remoteproc: Pass type of shutdown to subdev remove
added a Boolean flag to the subdevice remove method, to distinguish
between graceful shutdown and a crash. Unfortunately, the names of
the parameters were inconsistent, and in fact have opposi
On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote:
> On 04/24, Daniel Vetter wrote:
>>
>> wait_event_killabel doesn't check for fatal_signal_pending before calling
>> schedule, so definitely has a nice race there.
>
> This is fine. See the signal_pending_state() check in __schedule().
>
> And t
* Kishon Vijay Abraham I [180425 12:57]:
> --- a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
> +++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
> @@ -49,6 +49,17 @@
> >;
> };
>
> + mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
> + pinctrl-single,pins
>From 4.18 kernel, all the MMC controller instances in DRA7
are programmed using sdhci based driver (sdhci-omap.c). Document
this new requirement here. Both omap2plus_defconfig and
multi_v7_defconfig has CONFIG_MMC_SDHCI_OMAP enabled.
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v3:
Add
Hi Vaishali,
Thank you for the patch.
On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote:
> As specified in drm_drv.c, drm_dev_unref is a compatibility alias
> for drm_dev_put and shouldn't be used in new code. So, use
> drm_dev_put instead.
This looks good to me. However, how abou
Use sdhci-omap programming model based on the generic sdhci
library for programming the MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/keystone-k2g.dtsi | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g
Enable CONFIG_MMC_SDHCI_OMAP so that TI's K2G SoC
can use sdhci-omap driver for MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/configs/keystone_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig
b/arch/arm/configs/keystone
Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
binding.
I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
Everyone who use a custom .config should also enable
CONFIG_MMC_SDHCI_OMAP for MMC to work.
This series should be merged only after [1]
[1] -> https://
Add "vqmmc-supply" property for mmc0/mmc1 to indicate the supply connected
to the IO lines. Also add dt node for ldo1 regulator required for mmc1
vqmmc-supply.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 10 ++
1 file changed, 10 insertions(+)
diff
Signed-off-by: Thiebaud Weksteen
---
drivers/char/tpm/tpm_eventlog_of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_eventlog_of.c
b/drivers/char/tpm/tpm_eventlog_of.c
index 96fd5646f866..ea0f16f19d73 100644
--- a/drivers/char/tpm/tpm_eventlog_of.c
The ia64 ipcbuf/msgbuf/sembuf/shmbuf header files are all identical
to the version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements as part of the y2038 changes. While ia64 no longer has
a compat mode and doesn't need the file any more, it seem nicer
to
Both 32-bit amd 64-bit ARM use the asm-generic header files for their
sysvipc data structures, so no special care is needed to make those
work beyond y2038, with the one exception of compat mode: Since there
is no asm-generic definition of the compat mode IPC structures, ARM64
provides its own copy
The s390 msgbuf/sembuf/shmbuf header files are all identical to the
version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements, to avoid having to modify each copy when we extend sysvipc
to deal with 64-bit time_t in 32-bit user space.
Note that unlike al
The alpha ipcbuf/msgbuf/sembuf/shmbuf header files are all identical
to the version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements as part of the y2038 series. Since there is no 32-bit
syscall support for alpha, we don't need the other changes, but
it'
MIPS is the weirdest case for sysvipc, because each of the
three data structures is done differently:
* msqid64_ds has padding in the right place so we could in theory
extend this one to just have 64-bit values instead of time_t.
As this does not work for most of the other combinations,
we j
xtensa, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
xtensa tries hard to define the structures so they work
in both big-endian and little-endian systems with
Hi Thomas,
This is a small update to last week's patch series, I hope I
have worked out all the remaining issues now. If nothing else
comes up, please pull into tip for 4.18. The commits are
based on top of what you already pulled into timers/core, so
you can either add these to the same branch or
parisc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
Unlike most architectures, parisc actually succeeded in
defining this right for big-endian CPUs, but as ev
powerpc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
powerpc has the same definition as parisc and sparc, but now also
supports little-endian mode, which is n
32-bit architectures implementing 64BIT_TIME and COMPAT_32BIT_TIME
need to have the traditional semtimedop() behavior with 32-bit timestamps
for sys_ipc() by calling compat_ksys_semtimedop(), while those that
are not yet converted need to keep using ksys_semtimedop() like
64-bit architectures do.
sparc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
Unlike most architectures, sparc actually succeeded in
defining this right for big-endian CPUs, but as ever
Most architectures now use the asm-generic copy of the sysvipc data
structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
__kernel_time_t on 32-bit architectures but have padding behind them to
allow extending the type to 64-bit.
Unfortunately, that fails on all big-endian architecture
This extends the x86 copy of the sysvipc data structures to deal with
32-bit user space that has 64-bit time_t and wants to see timestamps
beyond 2038.
Fortunately, x86 has padding for this purpose in all the data structures,
so we can just add extra fields. With msgid64_ds and shmid64_ds, the
dat
On Fri 2018-04-20 10:52:21, Sergey Senozhatsky wrote:
> On (04/19/18 12:02), Petr Mladek wrote:
> > On Thu 2018-04-19 10:42:50, Sergey Senozhatsky wrote:
> > > We wake up klogd very late - only when current console_sem owner
> > > is done pushing pending kernel messages to the serial/net consoles.
The shmid64_ds/semid64_ds/msqid64_ds data structures have been extended
to contain extra fields for storing the upper bits of the time stamps,
this patch does the other half of the job and and fills the new fields on
32-bit architectures as well as 32-bit tasks running on a 64-bit kernel
in compat
This is a preparatation for changing over __kernel_timespec to 64-bit
times, which involves assigning new system call numbers for mq_timedsend(),
mq_timedreceive() and semtimedop() for compatibility with future y2038
proof user space.
The existing ABIs will remain available through compat code.
S
Three ipc syscalls (mq_timedsend, mq_timedreceive and and semtimedop)
take a timespec argument. After we move 32-bit architectures over to
useing 64-bit time_t based syscalls, we need seperate entry points for
the old 32-bit based interfaces.
This changes the #ifdef guards for the existing 32-bit
In some places, we still used get_seconds() instead of
ktime_get_real_seconds(), and I'm changing the remaining ones now to
all use ktime_get_real_seconds() so we use the full available range for
timestamps instead of overflowing the 'unsigned long' return value in
year 2106 on 32-bit kernels.
Sig
On Tue, Apr 24, 2018 at 09:22:18PM +0200, Thomas Gleixner wrote:
> Kaike reported that in tests rdma hrtimers occasionaly stopped working. He
> did great debugging, which provided enough context to decode the problem.
>
> CPU 3 CPU 2
>
> idle
> start sched_tim
On 04/24, Daniel Vetter wrote:
>
> wait_event_killabel doesn't check for fatal_signal_pending before calling
> schedule, so definitely has a nice race there.
This is fine. See the signal_pending_state() check in __schedule().
And this doesn't differ from wait_event_interruptible(), it too doesn't
Hi, Robin,
Thanks for the patch. It was some time since I put together that code,
but I remember hitting something similar to
https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964/
Even if it's clear from the documentation that orig_nents sho
tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
by th->used and updates tb->used.
But tty_insert_flip_string_fixed_flag() can be executed concurrently and
tb->used can be updated improperly.
It leads slab-out-of-bound write in tty_insert_flip_string_fixed_flag or
slab-out-o
Hi Dan,
On Thu, Apr 19, 2018 at 08:15:10AM +0300, Dan Carpenter wrote:
> Several people have asked me to write this and I think one person was
> maybe working on writing it themselves...
>
> The point of this check is to find place which might be vulnerable to
> the Spectre vulnerability. In the
On Tuesday, April 24, 2018 10:32:35 PM Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
Thanks for doing this.
> Signed-off-by: Krzysztof K
On Wed, Apr 25, 2018 at 05:48:42PM +0800, Qu Wenruo wrote:
> Hi,
>
> When testing IO heavy work on my VM backed by Ryzen 1700 CPU, I turned
> to brd modules, but surprisingly, the speed is even slower than some HDD:
>
> ---
> $ sudo modprobe brd rd_nr=1 rd_size=1048576
> $ dd if=/dev/zero of=/dev
Hi Philippe,
On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
> On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
> >> Add optional power supplies using the description found in
> >> "SiI9022A/SiI9024A HDMI Transmitte
On 04/24, Andrey Grodzovsky wrote:
>
> Currently calling wait_event_killable as part of exiting process
> will stall forever since SIGKILL generation is suppresed by PF_EXITING.
See my reply to 2/3,
> In our partilaur case AMDGPU driver wants to flush all GPU jobs in
> flight before shutting down
On 25 April 2018 13:31, Greg Kroah-Hartman wrote:
> On Wed, Apr 25, 2018 at 01:26:33AM +0200, Sebastian Reichel wrote:
> > Hi Greg,
> >
> > On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > > > This patch set
On Wed, 2018-04-25 at 13:12 +0200, Petr Mladek wrote:
> Move the non-trivial code from the long pointer() function. We are
> going
> to add a check for the access to the address that will make it even
> more
> complicated.
>
> Also it is better to warn about unknown specifier instead of falling
>
On 04/25/2018 03:14 AM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote:
On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer
On Wed, 2018-04-25 at 13:12 +0200, Petr Mladek wrote:
> There are few printk formats that make sense only with two or more
> specifiers. Also some specifiers make sense only when a kernel feature
> is enabled.
>
> The handling of unknown specifiers is strange, inconsistent, and
> even leaking the
On 04/24, Andrey Grodzovsky wrote:
>
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct
> drm_gpu_scheduler *sched,
> return;
> /**
>* The client will not que
701 - 800 of 1348 matches
Mail list logo
