Re: Linux messages full of `random: get_random_u32 called from`

> Hmm, can you let the boot hang for a while? It should continue after > a few minutes if you wait long enough, but wait a minute or two, then > give it entropy so the boot can continue. Then can you use > "systemd-analyze blame" or "systemd-analyize critical-chain" and we > can see what process

Re: Linux messages full of `random: get_random_u32 called from`

> Hmm, can you let the boot hang for a while? It should continue after > a few minutes if you wait long enough, but wait a minute or two, then > give it entropy so the boot can continue. Then can you use > "systemd-analyze blame" or "systemd-analyize critical-chain" and we > can see what process

Re: [PATCH] f2fs: clear page_error for all the writebacking pages

On 04/24, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/4/24 6:49, Jaegeuk Kim wrote: > > This patch clear page_error bit, if the page is going to be writebacked. > > This patch is similar to previous patch ("f2fs: clear PageError on > writepage"), > only coverage is different, could you merge them?

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote: > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: > > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with > > fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00 > > [1.176161]

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote: > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: > > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with > > fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00 > > [1.176161]

Re: [PATCH] f2fs: clear page_error for all the writebacking pages

On 04/24, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/4/24 6:49, Jaegeuk Kim wrote: > > This patch clear page_error bit, if the page is going to be writebacked. > > This patch is similar to previous patch ("f2fs: clear PageError on > writepage"), > only coverage is different, could you merge them?

Re: [PATCH 8/8] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control

On Tue, Apr 24, 2018 at 2:06 PM, Baolin Wang wrote: > -struct snd_pcm_mmap_status { > +/* > + * For mmap operations, we need the 64-bit layout, both for compat mode, > + * and for y2038 compatibility. For 64-bit applications, the two definitions > + * are identical, so we

Re: [PATCH 8/8] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control

On Tue, Apr 24, 2018 at 2:06 PM, Baolin Wang wrote: > -struct snd_pcm_mmap_status { > +/* > + * For mmap operations, we need the 64-bit layout, both for compat mode, > + * and for y2038 compatibility. For 64-bit applications, the two definitions > + * are identical, so we keep the traditional

[PATCH] Revert "x86/mm: implement free pmd/pte page interfaces"

From: Joerg Roedel This reverts commit 28ee90fe6048fa7b7ceaeb8831c0e4e454a4cf89. This commit is broken for x86, as it unmaps the PTE and PMD pages and immediatly frees them without doing a TLB flush. Further this lacks synchronization with other page-tables in the system when

[PATCH] Revert "x86/mm: implement free pmd/pte page interfaces"

From: Joerg Roedel This reverts commit 28ee90fe6048fa7b7ceaeb8831c0e4e454a4cf89. This commit is broken for x86, as it unmaps the PTE and PMD pages and immediatly frees them without doing a TLB flush. Further this lacks synchronization with other page-tables in the system when the PMD pages are

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 25, 2018, at 7:13 PM, Joel Fernandes joe...@google.com wrote: > Hi Mathieu, > > On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers > wrote: >> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote: >> >>> On Tue, Apr 24, 2018 at

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 25, 2018, at 7:13 PM, Joel Fernandes joe...@google.com wrote: > Hi Mathieu, > > On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers > wrote: >> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote: >> >>> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney >>>

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 05:01:37PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:56 PM, Vivek Goyal wrote: > > On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > >> On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > >> > On Thu,

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 05:01:37PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:56 PM, Vivek Goyal wrote: > > On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > >> On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > >> > On Thu, Apr 12, 2018 at 05:08:00PM +0200,

Re: [PATCH 2/5] ide: kill ide_toggle_bounce

On 4/26/18 1:20 AM, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 08:02:56PM -0600, Jens Axboe wrote: >> On 4/24/18 12:16 PM, Christoph Hellwig wrote: >>> ide_toggle_bounce did select various strange block bounce limits, including >>> not bouncing at all as soon as an iommu is present in the

Re: [PATCH 2/5] ide: kill ide_toggle_bounce

On 4/26/18 1:20 AM, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 08:02:56PM -0600, Jens Axboe wrote: >> On 4/24/18 12:16 PM, Christoph Hellwig wrote: >>> ide_toggle_bounce did select various strange block bounce limits, including >>> not bouncing at all as soon as an iommu is present in the

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

On 04/26, Kirill Tkhai wrote: > > We can rework this simply by adding a list of tasks to mm. Perhaps, but then I think this list should not depend on mm->owner. I mean, mm->list_of_group_leaders_which_use_this_mm can be used by coredump and oom-killer at least. But this is not that simple...

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

On 04/26, Kirill Tkhai wrote: > > We can rework this simply by adding a list of tasks to mm. Perhaps, but then I think this list should not depend on mm->owner. I mean, mm->list_of_group_leaders_which_use_this_mm can be used by coredump and oom-killer at least. But this is not that simple...

Re: issues with suspend on Dell XPS 13 2-in-1

On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote: > Hi Srinivas, > > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas escribió: > > Hi Dennis, > > > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote: > > > Hi Srinivas, > > > > > > Yes I have latest bios, I have version

Re: issues with suspend on Dell XPS 13 2-in-1

On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote: > Hi Srinivas, > > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas escribió: > > Hi Dennis, > > > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote: > > > Hi Srinivas, > > > > > > Yes I have latest bios, I have version

Re: [PATCH v4 6/8] drm/panel: Add Ilitek ILI9881c panel driver

On Wed, Apr 04, 2018 at 11:57:14AM +0200, Maxime Ripard wrote: > The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is > based on the Ilitek ILI9881c Controller. Add a driver for it, modelled > after the other Ilitek controller drivers. > > Signed-off-by: Maxime Ripard

Re: [PATCH v4 6/8] drm/panel: Add Ilitek ILI9881c panel driver

On Wed, Apr 04, 2018 at 11:57:14AM +0200, Maxime Ripard wrote: > The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is > based on the Ilitek ILI9881c Controller. Add a driver for it, modelled > after the other Ilitek controller drivers. > > Signed-off-by: Maxime Ripard >

[PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages

From: Michel Dänzer GFP_TRANSHUGE tries very hard to allocate huge pages, which can result in long delays with high memory pressure. I have observed firefox freezing for up to around a minute due to this while restic was taking a full system backup. Since we don't really

[PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages

From: Michel Dänzer GFP_TRANSHUGE tries very hard to allocate huge pages, which can result in long delays with high memory pressure. I have observed firefox freezing for up to around a minute due to this while restic was taking a full system backup. Since we don't really need huge pages, use

[PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

From: Michel Dänzer When it's set, TTM tries to allocate huge pages if possible. Drivers which can take advantage of huge pages should set it. Drivers not setting this flag no longer incur any overhead related to allocating or freeing huge pages. Cc:

[PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

From: Michel Dänzer When it's set, TTM tries to allocate huge pages if possible. Drivers which can take advantage of huge pages should set it. Drivers not setting this flag no longer incur any overhead related to allocating or freeing huge pages. Cc: sta...@vger.kernel.org Signed-off-by:

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, James Bottomley wrote: > On Thu, 2018-04-26 at 10:28 -0400, Mikulas Patocka wrote: > > > > On Thu, 26 Apr 2018, Michal Hocko wrote: > > > > > On Wed 25-04-18 18:42:57, Mikulas Patocka wrote: > > > >  > > > >  > > > > On Wed, 25 Apr 2018, James Bottomley wrote: > > > [...]

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, James Bottomley wrote: > On Thu, 2018-04-26 at 10:28 -0400, Mikulas Patocka wrote: > > > > On Thu, 26 Apr 2018, Michal Hocko wrote: > > > > > On Wed 25-04-18 18:42:57, Mikulas Patocka wrote: > > > >  > > > >  > > > > On Wed, 25 Apr 2018, James Bottomley wrote: > > > [...]

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote: > On Wed, 25 Apr 2018 17:40:56 -0400 (EDT) > Mathieu Desnoyers wrote: > >> One problem with your approach is that you can have multiple callers >> for the same tracepoint name, where some could

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote: > On Wed, 25 Apr 2018 17:40:56 -0400 (EDT) > Mathieu Desnoyers wrote: > >> One problem with your approach is that you can have multiple callers >> for the same tracepoint name, where some could be non-preemptible and >>

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 4:56 PM, Vivek Goyal wrote: > On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: >> On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: >> > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: >> > >> > [..]

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 4:56 PM, Vivek Goyal wrote: > On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: >> On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: >> > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: >> > >> > [..] >> >> diff --git a/fs/overlayfs/file.c

Re: [PATCH 1/4] exit: Move read_unlock() up in mm_update_next_owner()

On 04/26, Kirill Tkhai wrote: > > @@ -464,18 +464,15 @@ void mm_update_next_owner(struct mm_struct *mm) > return; > > assign_new_owner: > - BUG_ON(c == p); > get_task_struct(c); > + read_unlock(_lock); > + BUG_ON(c == p); > + > /* >* The task_lock protects

Re: [PATCH 1/4] exit: Move read_unlock() up in mm_update_next_owner()

On 04/26, Kirill Tkhai wrote: > > @@ -464,18 +464,15 @@ void mm_update_next_owner(struct mm_struct *mm) > return; > > assign_new_owner: > - BUG_ON(c == p); > get_task_struct(c); > + read_unlock(_lock); > + BUG_ON(c == p); > + > /* >* The task_lock protects

[PATCH V2 3/3] usb: xhci: tegra: Add support for managing powergates

The Tegra XHCI controller requires that the XUSBA (for superspeed) and XUSBC (for host) power-domains are enabled. Commit 8df127456f29 ("soc/tegra: pmc: Enable XUSB partitions on boot") was added to force on these power-domains if the XHCI driver is enabled while proper power-domain support is

[PATCH V2 3/3] usb: xhci: tegra: Add support for managing powergates

The Tegra XHCI controller requires that the XUSBA (for superspeed) and XUSBC (for host) power-domains are enabled. Commit 8df127456f29 ("soc/tegra: pmc: Enable XUSB partitions on boot") was added to force on these power-domains if the XHCI driver is enabled while proper power-domain support is

[PATCH V2 2/3] usb: xhci: tegra: Add runtime PM support

Add runtime PM support to the Tegra XHCI driver and move the function calls to enable/disable the clocks, regulators and PHY into the runtime PM callbacks. Signed-off-by: Jon Hunter --- Changes since V1: - Re-worked change to handle case where runtime PM is disabled.

[PATCH V2 2/3] usb: xhci: tegra: Add runtime PM support

Add runtime PM support to the Tegra XHCI driver and move the function calls to enable/disable the clocks, regulators and PHY into the runtime PM callbacks. Signed-off-by: Jon Hunter --- Changes since V1: - Re-worked change to handle case where runtime PM is disabled.

[PATCH V2 1/3] usb: xhci: tegra: Prepare for adding runtime PM support

When adding runtime PM support to the Tegra XHCI driver, it is desirable to move the function calls to enable the clocks, regulators and PHY from the tegra_xusb_probe into the runtime PM handlers. Currently, the clocks, regulators and PHY are all enabled before we call usb_create_hcd() in

[PATCH V2 1/3] usb: xhci: tegra: Prepare for adding runtime PM support

When adding runtime PM support to the Tegra XHCI driver, it is desirable to move the function calls to enable the clocks, regulators and PHY from the tegra_xusb_probe into the runtime PM handlers. Currently, the clocks, regulators and PHY are all enabled before we call usb_create_hcd() in

NVMe Poll CQ on timeout

Hi, We are testing NVMe cards on ARM64 platform, the card uses legacy interrupts. Intermittently we are hitting following case in drivers/nvme/host/pci.c /* * Did we miss an interrupt? */ if (__nvme_poll(nvmeq, req->tag)) {

NVMe Poll CQ on timeout

Hi, We are testing NVMe cards on ARM64 platform, the card uses legacy interrupts. Intermittently we are hitting following case in drivers/nvme/host/pci.c /* * Did we miss an interrupt? */ if (__nvme_poll(nvmeq, req->tag)) {

Re: [PATCH v3 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

On Thu, Apr 26, 2018 at 10:50 AM, 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. > > Since we can not lock the socket in tcp mmap() handler we have to >

Re: [PATCH v3 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

On Thu, Apr 26, 2018 at 10:50 AM, 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. > > Since we can not lock the socket in tcp mmap() handler we have to > split the operation

Re: [PATCH v3 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

On Thu, Apr 26, 2018 at 10:50 AM, Eric Dumazet wrote: > After prior kernel change, mmap() on TCP socket only reserves VMA. > > We have to use getsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) > to perform the transfert of pages from skbs in TCP receive queue into such >

Re: [PATCH v3 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

On Thu, Apr 26, 2018 at 10:50 AM, Eric Dumazet wrote: > After prior kernel change, mmap() on TCP socket only reserves VMA. > > We have to use getsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) > to perform the transfert of pages from skbs in TCP receive queue into such > VMA. > > struct

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: > > > > [..] > >> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > >> new file mode

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: > > > > [..] > >> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > >> new file mode 100644 > >> index

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

On 04/25/2018 06:20 PM, Soheil Hassas Yeganeh wrote: > > Acked-by: Soheil Hassas Yeganeh > > Thanks Soheil for reviewing. I have changed setsockopt() to getsockopt() so chose to not carry your Acked-by Please add it back if you agree, thanks !

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

On 04/25/2018 06:20 PM, Soheil Hassas Yeganeh wrote: > > Acked-by: Soheil Hassas Yeganeh > > Thanks Soheil for reviewing. I have changed setsockopt() to getsockopt() so chose to not carry your Acked-by Please add it back if you agree, thanks !

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with fb: > size=800x600@32, offset=0, pitch 3200, size 0x1d4c00 > [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] creating > preallocated stolen

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with fb: > size=800x600@32, offset=0, pitch 3200, size 0x1d4c00 > [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] creating > preallocated stolen

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, James Bottomley wrote: > > BTW. even developers who compile their own kernel should have this > > enabled by a CONFIG option - because if the developer sees the option > > when browsing through menuconfig, he may enable it. If he doesn't see > > the option, he won't even

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, James Bottomley wrote: > > BTW. even developers who compile their own kernel should have this > > enabled by a CONFIG option - because if the developer sees the option > > when browsing through menuconfig, he may enable it. If he doesn't see > > the option, he won't even

Re: [PATCH v2] HISI LPC: Add Kconfig MFD_CORE dependency

On Thu, Apr 19, 2018 at 4:14 PM, John Garry wrote: > For ACPI support of the HiSilicon LPC driver we depend > on MFD_CORE config. > > Currently the HiSi LPC Kconfig entry does not define this > dependency, so add it. > > The reason for depending on MFD_CORE in the driver is

Re: [PATCH v2] HISI LPC: Add Kconfig MFD_CORE dependency

On Thu, Apr 19, 2018 at 4:14 PM, John Garry wrote: > For ACPI support of the HiSilicon LPC driver we depend > on MFD_CORE config. > > Currently the HiSi LPC Kconfig entry does not define this > dependency, so add it. > > The reason for depending on MFD_CORE in the driver is > that we model the

Re: [PATCH v3 07/12] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

Hi Christoffer, On 04/26/2018 12:06 PM, Christoffer Dall wrote: > On Thu, Apr 26, 2018 at 10:29:35AM +0200, Auger Eric wrote: >> Hi Christoffer, >> On 04/24/2018 11:07 PM, Christoffer Dall wrote: >>> On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote: We introduce a new helper to

Re: [PATCH v3 07/12] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

Hi Christoffer, On 04/26/2018 12:06 PM, Christoffer Dall wrote: > On Thu, Apr 26, 2018 at 10:29:35AM +0200, Auger Eric wrote: >> Hi Christoffer, >> On 04/24/2018 11:07 PM, Christoffer Dall wrote: >>> On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote: We introduce a new helper to

[PATCH v3 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

When adding tcp mmap() implementation, I forgot that socket lock had to be taken before current->mm->mmap_sem. syzbot eventually caught the bug. Since we can not lock the socket in tcp mmap() handler we have to split the operation in two phases. 1) mmap() on a tcp socket simply reserves VMA

[PATCH v3 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

When adding tcp mmap() implementation, I forgot that socket lock had to be taken before current->mm->mmap_sem. syzbot eventually caught the bug. Since we can not lock the socket in tcp mmap() handler we have to split the operation in two phases. 1) mmap() on a tcp socket simply reserves VMA

[PATCH v3 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

After prior kernel change, mmap() on TCP socket only reserves VMA. We have to use getsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) to perform the transfert of pages from skbs in TCP receive queue into such VMA. struct tcp_zerocopy_receive { __u64 address; /* in: address of

[PATCH v3 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

After prior kernel change, mmap() on TCP socket only reserves VMA. We have to use getsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) to perform the transfert of pages from skbs in TCP receive queue into such VMA. struct tcp_zerocopy_receive { __u64 address; /* in: address of

[PATCH v3 net-next 0/2] tcp: mmap: rework zerocopy receive

syzbot reported a lockdep issue caused by tcp mmap() support. I implemented Andy Lutomirski nice suggestions to resolve the issue and increase scalability as well. First patch is adding a new getsockopt() operation and changes mmap() behavior. Second patch changes tcp_mmap reference program.

[PATCH v3 net-next 0/2] tcp: mmap: rework zerocopy receive

syzbot reported a lockdep issue caused by tcp mmap() support. I implemented Andy Lutomirski nice suggestions to resolve the issue and increase scalability as well. First patch is adding a new getsockopt() operation and changes mmap() behavior. Second patch changes tcp_mmap reference program.

Re: [PATCH] MAINTAINERS: Remove myself as maintainer

On Tue, Apr 17, 2018 at 2:53 PM, Niklas Cassel wrote: > From: Niklas Cassel > > I am leaving Axis, so this address will bounce in the not too > distant future. > > Fortunately, I will still be working with the community. > > Signed-off-by: Niklas Cassel

Re: [PATCH] MAINTAINERS: Remove myself as maintainer

On Tue, Apr 17, 2018 at 2:53 PM, Niklas Cassel wrote: > From: Niklas Cassel > > I am leaving Axis, so this address will bounce in the not too > distant future. > > Fortunately, I will still be working with the community. > > Signed-off-by: Niklas Cassel > --- > Hello arm-soc, could you please

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 2018-04-26 at 10:28 -0400, Mikulas Patocka wrote: > > On Thu, 26 Apr 2018, Michal Hocko wrote: > > > On Wed 25-04-18 18:42:57, Mikulas Patocka wrote: > > >  > > >  > > > On Wed, 25 Apr 2018, James Bottomley wrote: > > [...] > > > > Kconfig proliferation, conversely, is a bit of a

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 2018-04-26 at 10:28 -0400, Mikulas Patocka wrote: > > On Thu, 26 Apr 2018, Michal Hocko wrote: > > > On Wed 25-04-18 18:42:57, Mikulas Patocka wrote: > > >  > > >  > > > On Wed, 25 Apr 2018, James Bottomley wrote: > > [...] > > > > Kconfig proliferation, conversely, is a bit of a

[GIT PULL] ACPI fixes for v4.17-rc3

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.17-rc3 with top-most commit bd6dff55de7acb2e5065e69706400c41b1bd0521 Merge branches 'acpi-watchdog', 'acpi-button' and 'acpi-video' on top of commit

[GIT PULL] ACPI fixes for v4.17-rc3

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.17-rc3 with top-most commit bd6dff55de7acb2e5065e69706400c41b1bd0521 Merge branches 'acpi-watchdog', 'acpi-button' and 'acpi-video' on top of commit

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: > > [..] >> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c >> new file mode 100644 >> index ..a0b606885c41 >> --- /dev/null >> +++

Re: [RFC PATCH 09/35] ovl: stack file ops

On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: > > [..] >> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c >> new file mode 100644 >> index ..a0b606885c41 >> --- /dev/null >> +++ b/fs/overlayfs/file.c >> @@

[GIT PULL] Power management fixes for v4.17-rc3

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.17-rc3 with top-most commit e140c4af1b63125dff629e8339793390201e2470 Merge branches 'acpi-pm' and 'pm-cpufreq' on top of commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e Linux

[GIT PULL] Power management fixes for v4.17-rc3

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.17-rc3 with top-most commit e140c4af1b63125dff629e8339793390201e2470 Merge branches 'acpi-pm' and 'pm-cpufreq' on top of commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e Linux

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Vincent, Thanks for all your help. On 2018-04-26 12:31:33 +0200, Vincent Guittot wrote: > Hi Niklas, > > Le Thursday 26 Apr 2018 à 00:56:03 (+0200), Niklas Söderlund a écrit : > > Hi Vincent, > > > > Here are the result, sorry for the delay. > > > > On 2018-04-23 11:54:20 +0200, Vincent

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Vincent, Thanks for all your help. On 2018-04-26 12:31:33 +0200, Vincent Guittot wrote: > Hi Niklas, > > Le Thursday 26 Apr 2018 à 00:56:03 (+0200), Niklas Söderlund a écrit : > > Hi Vincent, > > > > Here are the result, sorry for the delay. > > > > On 2018-04-23 11:54:20 +0200, Vincent

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

On Thu, Apr 26, 2018 at 03:23:17PM +0100, John Garry wrote: > Not that I know about. Can you describe this method? I guess I also don't > need to set the mfd_cell pnpid either for this special case device. There is some documentation in "MFD devices" chapter of Documentation/acpi/enumeration.txt

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

On Thu, Apr 26, 2018 at 03:23:17PM +0100, John Garry wrote: > Not that I know about. Can you describe this method? I guess I also don't > need to set the mfd_cell pnpid either for this special case device. There is some documentation in "MFD devices" chapter of Documentation/acpi/enumeration.txt

Re: [PATCHv2 1/3] dt-bindings: misc: achc: Make ezport distinguishable

Hi, On Fri, Apr 13, 2018 at 10:33:05AM -0500, Rob Herring wrote: > On Mon, Apr 9, 2018 at 4:13 PM, Sebastian Reichel > wrote: > > Hi, > > > > On Mon, Apr 09, 2018 at 01:57:27PM -0500, Rob Herring wrote: > >> On Tue, Mar 27, 2018 at 03:52:57PM +0200, Sebastian

Re: [PATCHv2 1/3] dt-bindings: misc: achc: Make ezport distinguishable

Hi, On Fri, Apr 13, 2018 at 10:33:05AM -0500, Rob Herring wrote: > On Mon, Apr 9, 2018 at 4:13 PM, Sebastian Reichel > wrote: > > Hi, > > > > On Mon, Apr 09, 2018 at 01:57:27PM -0500, Rob Herring wrote: > >> On Tue, Mar 27, 2018 at 03:52:57PM +0200, Sebastian Reichel wrote: > >> > This updates

Re: [PATCH v3] PCI / PM: Always check PME wakeup capability for runtime wakeup support

On Thursday, April 26, 2018 3:55:45 PM CEST Bjorn Helgaas wrote: > On Fri, Apr 13, 2018 at 09:29:56AM +0200, Rafael J. Wysocki wrote: > > On Friday, April 13, 2018 8:58:11 AM CEST Kai Heng Feng wrote: > > > Hi Bjorn and Rafael, > > > > > > > On Apr 1, 2018, at 12:40 AM, Kai-Heng Feng > > > >

Re: [PATCH v3] PCI / PM: Always check PME wakeup capability for runtime wakeup support

On Thursday, April 26, 2018 3:55:45 PM CEST Bjorn Helgaas wrote: > On Fri, Apr 13, 2018 at 09:29:56AM +0200, Rafael J. Wysocki wrote: > > On Friday, April 13, 2018 8:58:11 AM CEST Kai Heng Feng wrote: > > > Hi Bjorn and Rafael, > > > > > > > On Apr 1, 2018, at 12:40 AM, Kai-Heng Feng > > > >

Re: [PATCH V2 1/2] sched/fair: Rearrange select_task_rq_fair() to optimize it

Hi, LGTM. Tiny inline comment but TBH might not be worth it. FWIW: Reviewed-by: Valentin Schneider On 26/04/18 11:30, Viresh Kumar wrote: > Rearrange select_task_rq_fair() a bit to avoid executing some > conditional statements in few specific code-paths. That gets

Re: [PATCH V2 1/2] sched/fair: Rearrange select_task_rq_fair() to optimize it

Hi, LGTM. Tiny inline comment but TBH might not be worth it. FWIW: Reviewed-by: Valentin Schneider On 26/04/18 11:30, Viresh Kumar wrote: > Rearrange select_task_rq_fair() a bit to avoid executing some > conditional statements in few specific code-paths. That gets rid of the > goto as well. >

[RFC PATCH 9/9] mm: migrate: enable thp migration for all possible architectures.

From: Zi Yan Remove CONFIG_ARCH_ENABLE_THP_MIGRATION. thp migration is enabled along with transparent hugepage and can be toggled via /sys/kernel/mm/transparent_hugepage/enable_thp_migration. Signed-off-by: Zi Yan Cc: linux...@kvack.org Cc: Vineet

[RFC PATCH 9/9] mm: migrate: enable thp migration for all possible architectures.

From: Zi Yan Remove CONFIG_ARCH_ENABLE_THP_MIGRATION. thp migration is enabled along with transparent hugepage and can be toggled via /sys/kernel/mm/transparent_hugepage/enable_thp_migration. Signed-off-by: Zi Yan Cc: linux...@kvack.org Cc: Vineet Gupta Cc: linux-snps-...@lists.infradead.org

Re: [PATCH 0/4] ALSA: Fix year 2038 issue for sound subsystem, alternative

On Thu, Apr 26, 2018 at 3:30 PM, Jaroslav Kysela wrote: > Dne 26.4.2018 v 14:44 Arnd Bergmann napsal(a): >> I've tried the suggestion from Jaroslaw, doing a minimal change to the >> UAPI headers to keep the existing binary interface. As he predicted, >> this is a much simpler set

Re: [PATCH 0/4] ALSA: Fix year 2038 issue for sound subsystem, alternative

On Thu, Apr 26, 2018 at 3:30 PM, Jaroslav Kysela wrote: > Dne 26.4.2018 v 14:44 Arnd Bergmann napsal(a): >> I've tried the suggestion from Jaroslaw, doing a minimal change to the >> UAPI headers to keep the existing binary interface. As he predicted, >> this is a much simpler set of kernel

[RFC PATCH 8/9] sparc: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan Signed-off-by: Zi Yan Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org Cc: linux...@kvack.org --- arch/sparc/include/asm/pgtable_32.h | 2 ++ arch/sparc/include/asm/pgtable_64.h | 2 ++ 2 files changed, 4

[RFC PATCH 8/9] sparc: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan Signed-off-by: Zi Yan Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org Cc: linux...@kvack.org --- arch/sparc/include/asm/pgtable_32.h | 2 ++ arch/sparc/include/asm/pgtable_64.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/sparc/include/asm/pgtable_32.h

Re: [patch V2 3/7] LICENSES: Add Apache 2.0 license text

On Thu, Apr 26, 2018 at 2:00 AM, Greg Kroah-Hartman wrote: > On Wed, Apr 25, 2018 at 10:30:23PM +0200, Thomas Gleixner wrote: >> Add the full text of the Apache License version 2 to the kernel tree. It >> was copied directly from: >> >>

Re: [patch V2 3/7] LICENSES: Add Apache 2.0 license text

On Thu, Apr 26, 2018 at 2:00 AM, Greg Kroah-Hartman wrote: > On Wed, Apr 25, 2018 at 10:30:23PM +0200, Thomas Gleixner wrote: >> Add the full text of the Apache License version 2 to the kernel tree. It >> was copied directly from: >> >>https://spdx.org/licenses/Apache-2.0.html#licenseText >>

[RFC PATCH 5/9] mips: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan Signed-off-by: Zi Yan Cc: Ralf Baechle Cc: James Hogan Cc: Michal Hocko Cc: Ingo Molnar Cc: Andrew Morton Cc:

[RFC PATCH 5/9] mips: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan Signed-off-by: Zi Yan Cc: Ralf Baechle Cc: James Hogan Cc: Michal Hocko Cc: Ingo Molnar Cc: Andrew Morton Cc: linux-m...@linux-mips.org Cc: linux...@kvack.org --- arch/mips/include/asm/pgtable-64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[RFC PATCH 4/9] i386: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan Signed-off-by: Zi Yan Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "Kirill A. Shutemov" Cc: x...@kernel.org Cc: linux...@kvack.org ---

[RFC PATCH 4/9] i386: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan Signed-off-by: Zi Yan Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "Kirill A. Shutemov" Cc: x...@kernel.org Cc: linux...@kvack.org --- arch/x86/include/asm/pgtable-2level.h | 2 ++ arch/x86/include/asm/pgtable-3level.h | 2 ++ 2 files changed, 4 insertions(+) diff --git

[RFC PATCH 0/9] Enable THP migration for all possible architectures

From: Zi Yan Hi all, THP migration is only enabled on x86_64 with a special ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for all architectures that uses transparent hugepage, so that special macro can be dropped. Instead, THP migration is

[RFC PATCH 7/9] s390: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan pmd swap soft dirty support is added, too. Signed-off-by: Zi Yan Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Janosch Frank Cc: Naoya Horiguchi

[RFC PATCH 0/9] Enable THP migration for all possible architectures

From: Zi Yan Hi all, THP migration is only enabled on x86_64 with a special ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for all architectures that uses transparent hugepage, so that special macro can be dropped. Instead, THP migration is enabled/disabled via

[RFC PATCH 7/9] s390: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan pmd swap soft dirty support is added, too. Signed-off-by: Zi Yan Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Janosch Frank Cc: Naoya Horiguchi Cc: linux-s...@vger.kernel.org Cc: linux...@kvack.org --- arch/s390/include/asm/pgtable.h | 5 + 1 file changed, 5

<    8   9   10   11   12   13   14   15   16   17   >