Once the driver gets sync_reset_request from firmware it prepares for the
coming reset and sends acknowledge.
After getting this event the driver expects device reset, either it will
trigger PCI reset on sync_reset_now event or such PCI reset will be
triggered by another PF of the same device. So
Add support for devlink reload action fw_activate. To activate firmware
image the mlx5 driver resets the firmware and reloads it from flash. If
a new image was stored on flash it will be loaded. Once this reload
command is executed the driver initiates fw sync reset flow, where the
firmware
Add devlink reload action to allow the user to request a specific reload
action. The action parameter is optional, if not specified then devlink
driver re-init action is used (backward compatible).
Note that when required to do firmware activation some drivers may need
to reload the driver. On the
Introduce new options on devlink reload API to enable the user to select
the reload action required and constrains limits on these actions that he
may want to ensure. Complete support for reload actions in mlx5.
The following reload actions are supported:
driver_reinit: driver entities
Change devlink_reload_supported() function to get devlink_ops pointer
param instead of devlink pointer param.
This change will be used in the next patch to check if devlink reload is
supported before devlink instance is allocated.
Signed-off-by: Moshe Shemesh
Reviewed-by: Jakub Kicinski
Add remote reload stats to hold the history of actions performed due
devlink reload commands initiated by remote host. For example, in case
firmware activation with reset finished successfully but was initiated
by remote host.
The function devlink_remote_reload_actions_performed() is exported to
The enable_remote_dev_reset devlink param flags that the host admin
allows device resets that can be initiated by other hosts. This
parameter is useful for setups where a device is shared by different
hosts, such as multi-host setup. Once the user set this parameter to
false, the driver should
Add reload limit to demand restrictions on reload actions.
Reload limits supported:
no_reset: No reset allowed, no down time allowed, no link flap and no
configuration is lost.
By default reload limit is unspecified and so no constraints on reload
actions are required.
Some
Add functions to query and set the MFRL reset options supported by
firmware.
Signed-off-by: Moshe Shemesh
Reviewed-by: Saeed Mahameed
---
RFCv5 -> v1:
- Renamed non-static functions to have module prefix
---
.../net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
Add reload stats to hold the history per reload action type and limit.
For example, the number of times fw_activate has been performed on this
device since the driver module was added or if the firmware activation
was performed with or without reset.
Add devlink notification on stats update.
Set capability to notify the firmware that this host driver is capable
of handling pci sync for firmware update events.
Signed-off-by: Moshe Shemesh
Reviewed-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
The enable_remote_dev_reset devlink param flags that the host admin
allows resets by other hosts. In case it is cleared mlx5 host PF driver
will send NACK on pci sync for firmware update reset request and the
command will fail.
By default enable_remote_dev_reset parameter is true, so pci sync for
If firmware sends sync_reset_abort to driver the driver should clear the
reset requested mode as reset is not expected any more.
Signed-off-by: Moshe Shemesh
Reviewed-by: Saeed Mahameed
---
.../net/ethernet/mellanox/mlx5/core/fw_reset.c| 15 +++
1 file changed, 15 insertions(+)
On sync_reset_now event the driver does reload and PCI link toggle to
activate firmware upgrade reset. When the firmware sends this event it
syncs the event on all PFs, so all PFs will do PCI link toggle at once.
To do PCI link toggle, the driver ensures that no other device ID under
the same
On 28-09-20, 12:44, Sudeep Holla wrote:
> The MHU drives the signal using a 32-bit register, with all 32 bits
> logically ORed together. The MHU provides a set of registers to enable
> software to set, clear, and check the status of each of the bits of this
> register independently. The use of 32
'--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Srinivasa-Rao-Mandadapu/arm64-dts-qcom-sc7180-trogdor-Add-lpass-dai-link-for-I2S-driver/20201007-004745
base:a804ab086e9de200e2e70600996db7fc14c91959
config: arm64-allyesconfig
Dear Friend,
I am Mr. Dawuda Usman working with the department of Audit and
accounting manager here in the Bank, There is this fund that was keep in
my custody years ago,please I need your assistance for the transferring
of this fund to your bank account
for both of us benefit for life time
On 10/6/20 7:16 PM, Randy Dunlap wrote:
Fix build errors in kernel/bpf/verifier.c when CONFIG_NET is
not enabled.
../kernel/bpf/verifier.c:3995:13: error: ‘btf_sock_ids’ undeclared here (not in
a function); did you mean ‘bpf_sock_ops’?
.btf_id = _sock_ids[BTF_SOCK_TYPE_SOCK_COMMON],
Add support for devlink reload action fw_activate with reload limit
no_reset which does firmware live patching, updating the firmware image
without reset, no downtime and no configuration lose. The driver checks
if the firmware is capable of handling the pending firmware changes as a
live patch.
Add devlink reload rst documentation file.
Update index file to include it.
Signed-off-by: Moshe Shemesh
---
v1 -> v2:
- Split first paragraph of devlink reload description to 2 sentences
RFCv5 -> v1:
- Rename reload_action_limit_level to reload_limit
RFCv4 -> RFCv5:
- Rephrase namespace change
Firmware live patch event notifies the driver that the firmware was just
updated using live patch. In such case the driver should not reload or
re-initiate entities, part to updating the firmware version and
re-initiate the firmware tracer which can be updated by live patch with
new strings
On Wed, Oct 07, 2020 at 02:45:39AM +0200, Jann Horn wrote:
> > I think arch_validate_prot() is still the right hook to validate the
> > protection bits. sparc_validate_prot() can iterate over VMAs with read
> > lock. This will, of course, require range as well to be passed to
> >
On Tue, Oct 06, 2020 at 10:56:04PM +0200, Tomasz Figa wrote:
> > Yes. And make sure the API isn't implemented when VIVT caches are
> > used, but that isn't really different from the current interface.
>
> Okay, thanks. Let's see if we can make necessary changes to the videobuf2.
>
> +Sergey
On Tue, Oct 06, 2020 at 09:19:32AM -0400, Jonathan Marek wrote:
> One example why drm/msm can't use DMA API is multiple page table support
> (that is landing in 5.10), which is something that definitely couldn't work
> with DMA API.
>
> Another one is being able to choose the address for
On Mon, 5 Oct 2020 at 22:36, Alexander Dahl wrote:
>
> The node names for devices using the pwm-leds driver follow a certain
> naming scheme (now). Parent node name is not enforced, but recommended
> by DT project.
>
> DTC arch/arm/boot/dts/exynos5410-odroidxu.dt.yaml
> CHECK
On Tue, 2020-10-06 at 10:10 +0300, Kalle Valo wrote:
> Lee Jones writes:
>
> > On Tue, 06 Oct 2020, Kalle Valo wrote:
> >
> > > Lee Jones writes:
> > >
> > > > On Thu, 10 Sep 2020, Lee Jones wrote:
> > > >
> > > > > This is a rebased/re-worked set of patches which have been
> > > > >
On Wed, Oct 7, 2020 at 8:17 AM Christoph Hellwig wrote:
> On Wed, Oct 07, 2020 at 02:45:39AM +0200, Jann Horn wrote:
> > > I think arch_validate_prot() is still the right hook to validate the
> > > protection bits. sparc_validate_prot() can iterate over VMAs with read
> > > lock. This will, of
The author signed-off-by checks are currently very vague.
Cases like same name or same address are not handled separately.
For example, running checkpatch on commit be6577af0cef
("parisc: Add atomic64_set_release() define to avoid CPU soft lockups"),
gives:
WARNING: Missing Signed-off-by: line
On Tue, 6 Oct 2020 at 21:59, Nathan Chancellor wrote:
>
> Clang warns:
>
> crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used
> here [-Wuninitialized]
> count++;
> ^
> crypto/xor.c:86:17: note: initialize the variable
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
testing/drm/amd/pm/phm_ppt_v1_mm
branch HEAD: b83c3eff4d97ce6ceaa11209ad8af4831f93a4be drm/amd/pm: Replace
one-element array with flexible-array in struct
phm_ppt_v1_mm_clock_voltage_dependency_table
elapsed
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
testing/drm/amd/pm/phm_ppt_v1
branch HEAD: dc151e43a9835a68c4c612dfa38b5c6b7d99079e drm/amd/pm: Replace
one-element array with flexible-array in struct
phm_ppt_v1_clock_voltage_dependency_table
elapsed time:
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
testing/drm/amd/pm/ATOM_Vega10
branch HEAD: 797ab03c31b7210c513e520b166919770cc7c6ab drm/amd/pm: Replace
one-element array with flexible-array in struct
ATOM_Vega10_GFXCLK_Dependency_Table
elapsed time: 722m
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
testing/drm/amd/pm/phm_ppt_v1_vol
branch HEAD: a8e30a030d28c6ad94dbcec885536fd7bb8947f2 drm/amd/pm: Replace
one-element array with flexible-array in struct phm_ppt_v1_voltage_lookup_table
elapsed time: 722m
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.9b-rc9-tag
xen: branch for v5.9-rc9
It contains one fix for a regression when booting as a Xen guest on
ARM64 introduced probably during the 5.9 cycle. It is very low risk as
it is
On Wed, Oct 7, 2020 at 12:03 PM Dwaipayan Ray wrote:
>
> The author signed-off-by checks are currently very vague.
> Cases like same name or same address are not handled separately.
>
> For example, running checkpatch on commit be6577af0cef
> ("parisc: Add atomic64_set_release() define to avoid
Remove propmt for selecting MLX5_VDPA by the user and modify
MLX5_VDPA_NET to select MLX5_VDPA. Also modify MLX5_VDPA_NET to depend
on mlx5_core.
This fixes an issue where configuration sets 'y' for MLX5_VDPA_NET while
MLX5_CORE is compiled as a module causing link errors.
Reported-by: kernel
On Tue, Oct 06, 2020 at 06:11:04PM -0700, Mike Travis wrote:
> I thought there was more references to the UVY class which currently has
> only UV5 as a member. There might be UV5 references where they should be
> UVY. The struct references use "uvy" as the selector so the grep should
> look for
On 30-09-20, 12:14, Peter Ujfalusi wrote:
> Glue layer users should use the device of the DMA for DMA mapping and
> allocations as it is the DMA which accesses to descriptors and buffers,
> not the clients
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/ti/k3-udma-glue.c| 14
On 10/6/20 12:08 AM, Alejandro Colomar wrote:
> Hi Michael,
>
> On 2020-10-03 13:39, Michael Kerrisk (man-pages) wrote:
>> Hi Alex,
> [...]
>>
>> off_t would be great.
>>
>> In case you are looking for some other candidates, some others
>> that I would be interested to see go into the page would
On 10/6/20 12:12 AM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
Hi Alex,
Thanks, patch applied. And I trimmed the "See also" a little.
I'd hold off on documenting loff_t and off64_t for the
moment. As you note in another mail, the *lseek* man page
situation is a bit of a mess.
On 10/6/20 12:12 AM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
Thanks, Alex. Patch applied.
Cheers,
Michael
> ---
> man3/off_t.3 | 1 +
> 1 file changed, 1 insertion(+)
> create mode 100644 man3/off_t.3
>
> diff --git a/man3/off_t.3 b/man3/off_t.3
> new file mode 100644
>
On Tue, 06 Oct 2020, David E. Box wrote:
> On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote:
> > On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
> > > Hi Bjorn,
> > >
> > > This patch has been acked and unchanged for weeks. Is it possible
> > > to
> > > get this pulled into
On Wed, Oct 07, 2020 at 10:11:46AM +0800, Huacai Chen wrote:
> s/used/unused/g, but it is too late, I'm sorry.
d'oh, I should probably wait a day longer before applying. Thank you for
your feedback.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good
Sending the updated version to the lists too so that it gets archived
properly.
---
From: Mike Travis
Date: Tue, 6 Oct 2020 16:34:27 -0500
Subject: [PATCH] drivers/misc/sgi-xp: Adjust references in UV kernel modules
Remove the define is_uv() is_uv_system and just use the latter as is.
This
On Fri, 02 Oct 2020, David E. Box wrote:
> Intel Platform Monitoring Technology (PMT) is an architecture for
> enumerating and accessing hardware monitoring facilities. PMT supports
> multiple types of monitoring capabilities. This driver creates platform
> devices for each type so that they may
HP DreamColor panel needs to be controlled via AUX interface. However,
it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
HP DreamColor panel, which is used by new HP ZBook Studio, needs to use
DPCD to control brightness.
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index
On Fri, 02 Oct 2020, Russ Weight wrote:
> Add macros and definitions required by the MAX10 BMC
> Security Engine driver.
>
> Signed-off-by: Russ Weight
> ---
> v2:
> - These functions and macros were previously distributed among
> the patches that needed them. They are now grouped
> On Apr 8, 2020, at 15:22, Jani Nikula wrote:
>
> On Tue, 07 Apr 2020, Kai-Heng Feng wrote:
>>> On Mar 27, 2020, at 19:03, Kai-Heng Feng
>>> wrote:
>>>
>>> Hi,
>>>
On Mar 23, 2020, at 13:35, Kai-Heng Feng
wrote:
There's another OLED panel needs to use DPCD aux
> On Apr 8, 2020, at 15:23, Jani Nikula wrote:
>
> On Tue, 07 Apr 2020, Kai-Heng Feng wrote:
>> There's another Samsung OLED panel needs to use DPCD aux interface to
>> control backlight.
>
> Acked-by: Jani Nikula
David,
Can you please merge this patch? Thanks.
Kai-Heng
>
>>
>>
On 05-10-20, 08:11, Dave Jiang wrote:
> == Background ==
> A typical DMA device requires the driver to translate application buffers to
> hardware addresses,
> and a kernel-user transition to notify the hardware of new work. Shared
> Virtual Addressing (SVA)
> allows the processor and device to
On Tue, Oct 06, 2020 at 01:11:15PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> security/security.c:1716:59: warning: implicit conversion from
> enumeration type 'enum kernel_load_data_id' to different enumeration
> type 'enum kernel_read_file_id' [-Wenum-conversion]
> ret =
On Tue, Oct 06, 2020 at 06:21:14PM -0700, Mike Travis wrote:
> When the UV BIOS starts the kernel it passes the UVsystab info struct to the
> kernel
Oh wow, *now* I get it. There is no "patch" being passed - your initial
commit message simply states that this is a patch to add and process...
Hi Catalin,
On Tue, Oct 6, 2020 at 11:30 PM Catalin Marinas wrote:
>
> On Mon, Oct 05, 2020 at 11:12:10PM +0530, Bhupesh Sharma wrote:
> > I think my earlier email with the test results on this series bounced
> > off the mailing list server (for some weird reason), but I still see
> > several
On Tue, 06 Oct 2020, Michael Brunner wrote:
> On Tue, 2020-10-06 at 07:53 +0100, Lee Jones wrote:
> > On Mon, 05 Oct 2020, Michael Brunner wrote:
> >
> > > On Fri, 2020-10-02 at 08:01 +0100, Lee Jones wrote:
> > > > On Thu, 01 Oct 2020, Michael Brunner wrote:
> > > >
> > > > > The Intel 0-DAY
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 7a6d94f0ed957fb667d4d74c5c6c640a26e87c8f
Gitweb:
https://git.kernel.org/tip/7a6d94f0ed957fb667d4d74c5c6c640a26e87c8f
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:29 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 6a7cf55e9f2b743695adac84375548aa18112327
Gitweb:
https://git.kernel.org/tip/6a7cf55e9f2b743695adac84375548aa18112327
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:27 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: c4d98077443adf61268ffb8b2c5d63c6176d845f
Gitweb:
https://git.kernel.org/tip/c4d98077443adf61268ffb8b2c5d63c6176d845f
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:18 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 8540b2cf0de09b6d96b7dce56a16e26ab4fe8a9b
Gitweb:
https://git.kernel.org/tip/8540b2cf0de09b6d96b7dce56a16e26ab4fe8a9b
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:24 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: d6922effe4f3d5c643c8c05d51a572d6db4c9cb3
Gitweb:
https://git.kernel.org/tip/d6922effe4f3d5c643c8c05d51a572d6db4c9cb3
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:26 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: a74a7e992caf0745f548a63b263ac34c6a4a29dd
Gitweb:
https://git.kernel.org/tip/a74a7e992caf0745f548a63b263ac34c6a4a29dd
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:25 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: ae5f8ce3c247b8d937782e76802a9036c09998ad
Gitweb:
https://git.kernel.org/tip/ae5f8ce3c247b8d937782e76802a9036c09998ad
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:28 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 39297dde7390e01bfd737052fbb5313a09062e2d
Gitweb:
https://git.kernel.org/tip/39297dde7390e01bfd737052fbb5313a09062e2d
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:17 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 1e61f5a95f1913c015a2d6a1544c108248b3971c
Gitweb:
https://git.kernel.org/tip/1e61f5a95f1913c015a2d6a1544c108248b3971c
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:22 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 6c7794423a998478f6df0234d2dd5baa3ccbdb1d
Gitweb:
https://git.kernel.org/tip/6c7794423a998478f6df0234d2dd5baa3ccbdb1d
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:21 -05:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 788b66e34e8ab82a93c63a83ba5a9d04f2f4ae26
Gitweb:
https://git.kernel.org/tip/788b66e34e8ab82a93c63a83ba5a9d04f2f4ae26
Author:Mike Travis
AuthorDate:Tue, 06 Oct 2020 16:34:27 -05:00
On Tue, Oct 6, 2020 at 9:12 PM Palmer Dabbelt wrote:
>
> On Tue, 06 Oct 2020 09:49:33 PDT (-0700), guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > As Aurelien has reported:
> >
> > [3.484586] AppArmor: AppArmor sha1 policy hashing enabled
> > [4.749835] Freeing unused kernel memory:
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: ffe2febca4304b9288e2d274d2ece5e66c125441
Gitweb:
https://git.kernel.org/tip/ffe2febca4304b9288e2d274d2ece5e66c125441
Author:Mike Travis
AuthorDate:Mon, 05 Oct 2020 15:39:23 -05:00
On Tue, Oct 06, 2020 at 05:52:20PM +0200, Christoph Hellwig wrote:
> Hi WeiXiong, hi Kees,
>
> what is the use case for the code added in commit 17639f67c1d6
> ("pstore/blk: Introduce backend for block devices").
>
> This still doesn't have a user, and the API looks really odd to me.
pstore is
Add YAML schema for Tegra audio graph sound card DT bindings. It uses the
same DT bindings provided by generic audio graph driver. Along with this
few standard clock DT bindings are added which are specifically required
for Tegra audio.
Signed-off-by: Sameer Pujar
---
On Tue, Oct 06, 2020 at 09:34:32PM +0200, Pavel Machek wrote:
> Hi!
>
> > [ Upstream commit 17dd1367389cfe7f150790c83247b68e0c19d106 ]
> >
> > Before to call vdev->config->reset(vdev) we need to be sure that
> > no one is accessing the device, for this reason, we add new variables
> > in the
From: SeongJae Park
NOTE: This is only an RFC for future features of DAMON patchset[1], which is
not merged in the mainline yet. The aim of this RFC is to show how DAMON would
be evolved once it is merged in. So, if you have some interest in this RFC,
please consider reviewing the DAMON
From: SeongJae Park
Some 'damon-dbgfs' users would want to monitor only a part of the entire
virtual memory address space. The framework users in the kernel space
could use '->init_target_regions' callback or even set the regions
inside the context struct as they want, but 'damon-dbgfs' users
From: SeongJae Park
This commit updates the damon user space tool to support the initial
monitoring target regions specification.
Signed-off-by: SeongJae Park
---
tools/damon/_damon.py | 39 +++
tools/damon/record.py | 12 +++-
On Tue, Oct 06, 2020 at 09:28:17AM -0700, Joe Perches wrote:
> Convert the various uses of sprintf/snprintf/scnprintf to
> format sysfs output to sysfs_emit and sysfs_emit_at to make
> clear the output is sysfs related and to avoid any possible
> buffer overrun of the PAGE_SIZE buffer.
>
> Done
From: SeongJae Park
This commit adds another test case for the new feature, 'init_regions'.
Signed-off-by: SeongJae Park
Reviewed-by: Brendan Higgins
---
mm/damon/dbgfs-test.h | 55 +++
1 file changed, 55 insertions(+)
diff --git
From: SeongJae Park
Now the regions can be explicitly set as users want. Therefore checking
the number of gaps doesn't make sense. Remove the condition.
Signed-off-by: SeongJae Park
---
tools/testing/selftests/damon/_chk_record.py | 6 --
1 file changed, 6 deletions(-)
diff --git
From: SeongJae Park
This commit adds description of the 'init_regions' feature in the DAMON
usage document.
Signed-off-by: SeongJae Park
---
Documentation/admin-guide/mm/damon/usage.rst | 41 +++-
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git
From: SeongJae Park
This commit implements the primitives for the basic access monitoring of
the physical memory address space. By using this, users can easily
monitor the accesses to the physical memory.
Internally, it uses the PTE Accessed bit, as similar to that of the
virtual memory
From: SeongJae Park
This commit makes the 'damon-dbgfs' to support the physical memory
monitoring, in addition to the virtual memory monitoring.
Users can do the physical memory monitoring by writing a special
keyword, 'paddr\n' to the 'pids' debugfs file. Then, DAMON will check
the special
From: SeongJae Park
This commit updates the DAMON user space tool (damo-record) for NUMA
specific physical memory monitoring. With this change, users can
monitor accesses to physical memory of specific NUMA node.
Signed-off-by: SeongJae Park
---
tools/damon/_paddr_layout.py | 147
From: SeongJae Park
This commit allows users to record the data accesses on physical memory
address space by passing 'paddr' as target to 'damo-record'. If the
init regions are given, the regions will be monitored. Else, it will
monitor biggest conitguous 'System RAM' region in '/proc/iomem'
From: SeongJae Park
This commit updates the DAMON documents for the physical memory
monitoring support.
Signed-off-by: SeongJae Park
---
Documentation/admin-guide/mm/damon/usage.rst | 42
Documentation/vm/damon/design.rst| 29 +-
This patch is against to mkp's 5.10/scsi-staging.
1. Use upper_32_bits() instead of dma_addr_hi32().
2. Use round_up() instead of logical operation.
---
Hi Peter,
On 2020-10-04 15:31, Peter Geis wrote:
> Good Day,
>
> This series introduces upstream kernel support for the Ouya game
> console device. Please review and apply. Thank you in advance.
Interesting patchset, maybe I can give my Ouya a second live now :-) Do
you happen to have (a link)
On Tue, Oct 06, 2020 at 04:55:27PM +0100, Qais Yousef wrote:
> > +int cpumask_any_distribute(const struct cpumask *srcp)
> > +{
> > + int next, prev;
> > +
> > + /* NOTE: our first selection will skip 0. */
> > + prev = __this_cpu_read(distribute_cpu_mask_prev);
>
> We had a discussion then
Hello,
On Tue, Oct 6, 2020 at 8:11 PM Jiri Olsa wrote:
>
> On Tue, Oct 06, 2020 at 06:39:44AM +, Song Bao Hua (Barry Song) wrote:
>
> SNIP
>
> > > > Andi, thanks! Could you share the link or the commit ID? I'd like to
> > > > take a
> > > look at the fix.
> > > > I could still reproduce
From: ching Huang
Use upper_32_bits() instead of dma_addr_hi32().
Signed-off-by: ching Huang
---
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index d13d672..55d85c9 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@
On Wed 2020-10-07 02:15:04, Sergey Senozhatsky wrote:
> On (20/10/06 18:35), Petr Mladek wrote:
> > > > Whatever is decided, I'd like to have it made official and documented to
> > > > avoid a similar problem in the future.
> >
> > Sigh, it is even bigger mess than I expected. There is a magic
>
On 10/6/20 8:48 PM, Pratyush Yadav wrote:
> On 06/10/20 03:23PM, Bert Vermeulen wrote:
>> If a flash chip has more than 16MB capacity but its BFPT reports
>> BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3.
>>
>> The check in spi_nor_set_addr_width() doesn't catch it
From: ching Huang
Use round_up() instead of logical operation.
Reported-by: Martin K. Petersen
Signed-off-by: ching Huang
---
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 55d85c9..1e358d9 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++
Tuesday, October 6, 2020, 4:19:15 PM, Mauro Carvalho Chehab wrote:
>> diff --git a/Documentation/w1/slaves/w1_therm.rst
>> b/Documentation/w1/slaves/w1_therm.rst
>> index f1148181f53e..00376501a5ef 100644
>> --- a/Documentation/w1/slaves/w1_therm.rst
>> +++ b/Documentation/w1/slaves/w1_therm.rst
Raj,
On Sun, Oct 4, 2020 at 12:57 PM Raj, Ashok wrote:
>
> Hi Ethan
>
> On Sat, Oct 03, 2020 at 03:55:09AM -0400, Ethan Zhao wrote:
> > Hi,folks,
> >
> > This simple patch set fixed some serious security issues found when DPC
> > error injection and NVMe SSD hotplug brute force test were doing
On Wed, Oct 07, 2020 at 12:13:27AM -0700, Kees Cook wrote:
> On Tue, Oct 06, 2020 at 05:52:20PM +0200, Christoph Hellwig wrote:
> > Hi WeiXiong, hi Kees,
> >
> > what is the use case for the code added in commit 17639f67c1d6
> > ("pstore/blk: Introduce backend for block devices").
> >
> > This
On Tue, Oct 06, 2020 at 09:34:19PM -0700, Sean Christopherson wrote:
> On Wed, Oct 07, 2020 at 06:14:02AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 06, 2020 at 06:17:38PM -0700, Sean Christopherson wrote:
> > > On Wed, Oct 07, 2020 at 03:22:36AM +0300, Jarkko Sakkinen wrote:
> > > > > And then
arch_validate_prot() is a hook that can validate whether a given set of
protection flags is valid in an mprotect() operation. It is given the set
of protection flags and the address being modified.
However, the address being modified can currently not actually be used in
a meaningful way because:
sparc_validate_prot() is called from do_mprotect_pkey() as
arch_validate_prot(); it tries to ensure that an mprotect() call can't
enable ADI on incompatible VMAs.
The current implementation only checks that the VMA at the start address
matches the rules for ADI mappings; instead, check all VMAs
syzbot has found a reproducer for the following issue on:
HEAD commit:c85fb28b Merge tag 'arm64-fixes' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17406d7050
kernel config:
On Wed, 2020-10-07 at 00:54 +0200, Jann Horn wrote:
> Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
> of the old mm (in dup_mmap() and in UML's activate_mm()).
> A following patch will change the exec path to very broadly lock the
> nascent mm, but fine-grained
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d3d45f8220d60a0b2cf8fb2be4e6ffd9008e
commit: 2c855d73f2f6107f5b8ebc45f8b934bf7f4419e0 bnx2x: Remove read_status_t
function casts
config: x86_64-randconfig-m001-20201003 (attached as .config)
compiler:
1 - 100 of 1114 matches
Mail list logo
