On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 16, 2021 at 10:39 AM Willy Tarreau wrote:
> >
> > resources usage, I'm really not convinced at all it's suited for
> > low-level development. I understand the interest of the experiment
> > to help the language evolve
The cache function can be turned ON and OFF by writing to the CACHE_CTRL
byte (EXT_CSD byte [33]). However, card->ext_csd.cache_ctrl is only
set on init if cache size > 0.
Fix that by explicitly setting ext_csd.cache_ctrl on ext-csd write.
Signed-off-by: Avri Altman
---
The cache may be flushed to the nonvolatile storage by writing to
FLUSH_CACHE byte (EXT_CSD byte [32]). When in command queueing mode, the
cache may be flushed by issuing a CMDQ_TASK_ DEV_MGMT (CMD48) with a
FLUSH_CACHE op-code. Either way, verify that The cache function is
turned ON before doing
v2 -> v3:
- rebase onto recent cache changes
v1 -> v2:
- Attend Adrian's comments
Cache is a temporary storage space in an eMMC device. Volatile by
nature, the cache should in typical case reduce the access time compared
to an access to the main nonvolatile storage.
The cache function can be
On Mon, Apr 19, 2021 at 10:36:48PM CDT, Guenter Roeck wrote:
On Mon, Apr 19, 2021 at 08:29:53PM -0500, Zev Weiss wrote:
On Tue, Mar 30, 2021 at 02:38:10PM CDT, Guenter Roeck wrote:
> On Tue, Mar 30, 2021 at 07:02:00PM +0100, Mark Brown wrote:
> > On Tue, Mar 30, 2021 at 12:56:56PM -0500, Zev
Hi,
I'm learning about qemu KVM, looking into code and experimenting on
it. I have the following doubts regarding it, I would be grateful if
you help me to get some idea on them.
1. I observe that KVM allocates memory to guests when it needs it but
doesn't take it back (except for ballooning
Hi Guenter,
On 2021-03-11 01:53, Guenter Roeck wrote:
On Thu, Mar 11, 2021 at 01:50:04AM +0530, Sai Prakash Ranjan wrote:
During suspend/resume usecases and tests, it is common to see issues
such as lockups either in suspend path or resume path because of the
bugs in the corresponding device
Direct page mapping in bottom-up way will allocate memory from low
address for page structures in a range, which is the *bottom*,
not the *end*.
Signed-off-by: Cao jin
---
arch/x86/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/init.c
On Tue, 2021-04-20 at 15:18 +1000, Alexey Kardashevskiy wrote:
>
> On 20/04/2021 14:54, Leonardo Bras wrote:
> > As of today, if the DDW is big enough to fit (1 << MAX_PHYSMEM_BITS) it's
> > possible to use direct DMA mapping even with pmem region.
> >
> > But, if that happens, the window size
On 19.04.2021 10:17, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/mfd/sec-core.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/sec-core.c
nabling device ( -> 0001)
Bisect log is attached.
Guenter
---
# bad: [50b8b1d699ac313c0a07a3c185ffb23aecab8abb] Add linux-next specific files
for 20210419
# good: [bf05bf16c76bb44ab5156223e1e58e26dfe30a88] Linux 5.12-rc8
git bisect start 'HEAD' 'v5.12-rc8'
# bad: [c4bb91fc07e59241cde97f913
Hi, Jiaxun
On 04/20/2021 09:11 AM, Jiaxun Yang wrote:
在 2021/4/19 18:56, Youling Tang 写道:
From: Huacai Chen
kexec-tools use mem=X@Y to pass usable memories to crash kernel, but in
commit a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map") all
BIOS passed memories are removed by
On 20/04/2021 14:54, Leonardo Bras wrote:
As of today, if the DDW is big enough to fit (1 << MAX_PHYSMEM_BITS) it's
possible to use direct DMA mapping even with pmem region.
But, if that happens, the window size (len) is set to
(MAX_PHYSMEM_BITS - page_shift) instead of MAX_PHYSMEM_BITS,
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a003-20210419
x86_64 randconfig-a001-20210419
x86_64 randconfig-a005-20210419
x86_64 randconfig-a002-20210419
x86_64
Hello,
syzbot found the following issue on:
HEAD commit:bf05bf16 Linux 5.12-rc8
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16a00dfed0
kernel config: https://syzkaller.appspot.com/x/.config?x=9404cfa686df2c05
dashboard link:
jin yiting wrote:
[...]
>> The described issue is a race condition (in that
>> ad_agg_selection_logic clears agg->is_active under mode_lock, but
>> bond_open -> bond_update_slave_arr is inspecting agg->is_active outside
>> the lock). I don't see how the above change will reliably manage
Le 19/04/2021 à 23:39, Randy Dunlap a écrit :
On 4/19/21 6:16 AM, Michael Ellerman wrote:
Randy Dunlap writes:
Sure. I'll post them later today.
They keep FPU and ALTIVEC as independent (build) features.
Those patches look OK.
But I don't think it makes sense to support that
On Wed, Dec 23, 2020 at 9:56 PM Ricardo Ribalda wrote:
>
> Hi again
>
> On Wed, Dec 23, 2020 at 9:31 AM Ricardo Ribalda wrote:
> >
> > Hi Laurent
> >
> > On Wed, Dec 23, 2020 at 9:05 AM Laurent Pinchart
> > wrote:
> > >
> > > Hi Ricardo,
> > >
> > > On Tue, Dec 22, 2020 at 09:04:19PM +0100,
As of today, if the DDW is big enough to fit (1 << MAX_PHYSMEM_BITS) it's
possible to use direct DMA mapping even with pmem region.
But, if that happens, the window size (len) is set to
(MAX_PHYSMEM_BITS - page_shift) instead of MAX_PHYSMEM_BITS, causing a
pagesize times smaller DDW to be
On Mon, Apr 19, 2021 at 04:56:41PM -0700, Samuel Mendoza-Jonas wrote:
> The 4.14 backport of 9d7eceede ("bpf: restrict unknown scalars of mixed
> signed bounds for unprivileged") adds the PTR_TO_MAP_VALUE check to the
> wrong location in adjust_ptr_min_max_vals(), most likely because 4.14
>
From: Andrea Parri (Microsoft) Sent: Monday, April 19,
2021 6:44 PM
>
> If a malicious or compromised Hyper-V sends a spurious message of type
> CHANNELMSG_UNLOAD_RESPONSE, the function vmbus_unload_response() will
> call complete() on an uninitialized event, and cause an oops.
>
>
When running in Azure, disks may be connected to a Linux VM with
read/write caching enabled. If a VM panics and issues a VMbus
UNLOAD request to Hyper-V, the response is delayed until all dirty
data in the disk cache is flushed. In extreme cases, this flushing
can take 10's of seconds, depending
On Mon, Apr 19, 2021 at 5:18 AM Kumar Kartikeya Dwivedi
wrote:
>
> This adds some basic tests for the low level bpf_tc_cls_* API.
>
> Reviewed-by: Toke Høiland-Jørgensen
> Signed-off-by: Kumar Kartikeya Dwivedi
> ---
> .../selftests/bpf/prog_tests/test_tc_bpf.c| 112 ++
>
On Tue, Mar 30, 2021 at 9:53 AM Sahil Malhotra
wrote:
>
> From: Sahil Malhotra
>
> optee node was disabled by default, enabling it for ls1028a-rdb.
>
> Signed-off-by: Michael Walle
> Signed-off-by: Sahil Malhotra
Acked-by: Li Yang
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts |
From: Pawel Laszczak
Patch fixes lack of removing request from ep->pending_list on failure
of the stop endpoint command. Driver even after failing this command
must remove request from ep->pending_list.
Without this fix driver can stuck in cdnsp_gadget_ep_disable function
in loop:
while
On 4/20/21 1:50 AM, Jens Axboe wrote:
> On 4/19/21 10:26 AM, Coly Li wrote:
>> On 4/19/21 11:40 PM, Randy Dunlap wrote:
>>> On 4/19/21 3:23 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20210416:
>>>
>>> on x86_64:
>>>
>>> when
>>> # CONFIG_BLK_DEV is not set
>>>
>>>
>>>
On Sun, Apr 18, 2021 at 4:59 PM Alexandre Ghiti wrote:
>
> The 32b kernel mapping lies in the linear mapping, there is no point in
> printing its address in page table dump, so remove this leftover that
> comes from moving the kernel mapping outside the linear mapping for 64b
> kernel.
>
> Fixes:
On Sat, Apr 17, 2021 at 10:52 PM Alexandre Ghiti wrote:
>
> Fix multiple leftovers when moving the kernel mapping outside the linear
> mapping for 64b kernel that left the 32b kernel unusable.
>
> Fixes: 4b67f48da707 ("riscv: Move kernel mapping outside of linear mapping")
> Signed-off-by:
On 20/04/21 12:53 am, Asutosh Das (asd) wrote:
> On 4/19/2021 11:37 AM, Adrian Hunter wrote:
>> On 16/04/21 10:49 pm, Asutosh Das wrote:
>>>
>>> Co-developed-by: Can Guo
>>> Signed-off-by: Can Guo
>>> Signed-off-by: Asutosh Das
>>> ---
>>
>> I came across 3 issues while testing. See comments
Hi all,
Today's linux-next merge of the ftrace tree got a conflict in:
kernel/trace/bpf_trace.c
between commit:
d9c9e4db186a ("bpf: Factorize bpf_trace_printk and bpf_seq_printf")
from the bpf-next tree and commit:
f2cc020d7876 ("tracing: Fix various typos in comments")
from the
"Matthew Wilcox (Oracle)" writes:
> The first patch here fixes two bugs on ppc32, and mips32. It fixes one
> bug on arc and arm32 (in certain configurations). It probably makes
> sense to get it in ASAP through the networking tree. I'd like to see
> testing on those four architectures if
>On 21-04-19 09:50:53, Pawel Laszczak wrote:
>> From: Pawel Laszczak
>>
>> Patch adds disabling endpoint before enabling it during changing
>> alternate setting. Lack of this functionality causes that in some
>> cases uac2 queue the same request multiple time.
>> Such situation can occur when
During system resume, mhi driver triggers M3->M0 transition and then waits
for target device to enter M0 state. Once done, the device queues a state
change event into ctrl event ring and notify mhi dirver by raising an
interrupt, where a tasklet is scheduled to process this event. In most cases,
On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao wrote:
> @@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
> else
> err = -ENOTSUPP;
> break;
> + case MTK_PIN_CONFIG_RSEL:
> + if
Hi all,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
In file included from include/linux/printk.h:409,
from include/linux/kernel.h:16,
from include/linux/clk.h:13,
from
Hi Nick,
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> I don't think the introduction of Rust made Firefox _more_ insecure.
> https://wiki.mozilla.org/Oxidation#Within_Firefox
Browsers are human interfaces and do not fundamentally require low
level access to
On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao wrote:
>
> This patch provides the advanced drive raw data setting version
> for I2C used pins on MT8195.
>
> Signed-off-by: Zhiyong Tao
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/pinctrl-mt8195.c | 22 +++
>
Shifted the closing */ of multiline comment to a new line
This is done to maintain code uniformity
Signed-off-by: Shubhankar Kuranagatti
---
drivers/regulator/core.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/core.c
On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao wrote:
>
> This commit includes pinctrl driver for mt8195.
>
> Signed-off-by: Zhiyong Tao
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/Kconfig |6 +
> drivers/pinctrl/mediatek/Makefile |1 +
>
Tyrel Datwyler writes:
> On 4/17/21 5:30 AM, Michael Ellerman wrote:
>> Tyrel Datwyler writes:
>>> On 4/1/21 5:13 PM, Tyrel Datwyler wrote:
Currently, neither the vio_bus or vio_driver structures provide support
for a shutdown() routine.
Add support for shutdown() by allowing
On Mon, Apr 19, 2021 at 06:09:11PM +0200, Christian Brauner wrote:
> On Mon, Apr 19, 2021 at 07:25:14AM -0500, Serge Hallyn wrote:
> > cap_setfcap is required to create file capabilities.
> >
> > Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
> > process running as uid 0 but
On 19-04-21, 13:52, Bjorn Andersson wrote:
> On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
> @Viresh, do you have any suggestion regarding my last comment?
> > static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev)
> > {
> > + const struct
On Mon, Apr 19, 2021 at 08:29:53PM -0500, Zev Weiss wrote:
> On Tue, Mar 30, 2021 at 02:38:10PM CDT, Guenter Roeck wrote:
> > On Tue, Mar 30, 2021 at 07:02:00PM +0100, Mark Brown wrote:
> > > On Tue, Mar 30, 2021 at 12:56:56PM -0500, Zev Weiss wrote:
> > >
> > > > Okay, to expand a bit on the
Qualcomm crypto engine does not handle the following scenarios and
will issue an abort. In such cases, pass on the transformation to
a fallback algorithm.
- DES3 algorithms with all three keys same.
- AES192 algorithms.
- 0 length messages.
Signed-off-by: Thara Gopinath
---
v1->v2:
-
Add register programming sequence for enabling AEAD
algorithms on the Qualcomm crypto engine.
Signed-off-by: Thara Gopinath
---
v2->v3:
- Made qce_be32_to_cpu_array truly be32 to cpu endian by using
be32_to_cpup
instead of cpu_to_be32p. Also remove the (u32 *) typcasting of
Remove various redundant checks in qce_auth_cfg. Also allow qce_auth_cfg
to take auth_size as a parameter which is a required setting for ccm(aes)
algorithms
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/common.c | 21 +
1 file changed, 9 insertions(+), 12
Qualcomm crypto engine allows for IV registers and status register
to be concatenated to the output. This option is enabled by setting the
RESULTS_DUMP field in GOPROC register. This is useful for most of the
algorithms to either retrieve status of operation or in case of
authentication
Introduce support to enable following algorithms in Qualcomm Crypto Engine.
- authenc(hmac(sha1),cbc(des))
- authenc(hmac(sha1),cbc(des3_ede))
- authenc(hmac(sha256),cbc(des))
- authenc(hmac(sha256),cbc(des3_ede))
- authenc(hmac(sha256),cbc(aes))
- ccm(aes)
- rfc4309(ccm(aes))
Signed-off-by:
rf4309 is the specification that uses aes ccm algorithms with IPsec
security packets. Add a submode to identify rfc4309 ccm(aes) algorithm
in the crypto driver.
Reviewed-by: Bjorn Andersson
Signed-off-by: Thara Gopinath
---
v1->v2:
- Moved up the QCE_ENCRYPT AND QCE_DECRYPT bit
Enable support for AEAD algorithms in Qualcomm CE driver. The first three
patches in this series are cleanups and add a few missing pieces required
to add support for AEAD algorithms. Patch 4 introduces supported AEAD
transformations on Qualcomm CE. Patches 5 and 6 implements the h/w
MAC_FAILED gets set in the status register if authenthication fails
for ccm algorithms(during decryption). Add support to catch and flag
this error.
Reviewed-by: Bjorn Andersson
Signed-off-by: Thara Gopinath
---
v1->v2:
- Split the error checking for -ENXIO and -EBADMSG into if-else
On Mon, Apr 19, 2021 at 5:45 PM David Miller wrote:
>
> From: Adam Ford
> Date: Sat, 17 Apr 2021 08:23:29 -0500
>
> > The call to clk_disable_unprepare() can happen before priv is
> > initialized. This means moving clk_disable_unprepare out of
> > out_release into a new label.
> >
> > Fixes:
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, March 19, 2021 11:02 PM
> To: Jonathan Cameron
> Cc: Song Bao Hua (Barry Song) ;
> tim.c.c...@linux.intel.com; catalin.mari...@arm.com; w...@kernel.org;
> r...@rjwysocki.net;
On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
wrote:
>
>
>
> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
> > On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet
> > wrote:
> >>
> >> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann
> >>> On 4/15/21 11:32 AM, Jianlin Lv wrote:
> For
在 2021/4/16 12:28, Jay Vosburgh 写道:
jinyiting wrote:
From: jin yiting
The bond works in mode 4, and performs down/up operations on the bond
that is normally negotiated. The probability of bond-> slave_arr is NULL
Test commands:
ifconfig bond1 down
ifconfig bond1 up
The conflict
From: Raphael Gault
Add documentation to describe the access to the pmu hardware counters from
userspace.
Signed-off-by: Raphael Gault
Signed-off-by: Rob Herring
---
v7:
- Merge into existing arm64 perf.rst
v6:
- Update the chained event section with attr.config1 details
v2:
- Update
Userspace counter access only works on heterogeneous systems with some
restrictions. The userspace process must be pinned to a homogeneous
subset of CPUs and must open the corresponding PMU for those CPUs. This
commit adds a test implementing these requirements.
Signed-off-by: Rob Herring
---
Add arm64 specific tests for 32-bit and 64-bit counter user access. On
arm64, counters default to 32-bit unless attr.config1:0 is set to 1. In
order to enable user access for 64-bit counters, attr.config1 must be set
to 3.
Signed-off-by: Rob Herring
---
v6:
- New patch
---
Add the arm64 variants for read_perf_counter() and read_timestamp().
Unfortunately the counter number is encoded into the instruction, so the
code is a bit verbose to enumerate all possible counters.
Signed-off-by: Rob Herring
---
v7:
- Move enabling of libperf user read test for arm64 to this
Like x86, some users may want to disable userspace PMU counter
altogether. Add a sysfs 'rdpmc' file to control userspace counter
access. The default is '1' which is enabled. Writing '0' disables
access.
In the case of multiple PMUs (i.e. big.LITTLE), the control is per PMU
and userspace must
From: Raphael Gault
Keep track of event opened with direct access to the hardware counters
and modify permissions while they are open.
The strategy used here is the same which x86 uses: every time an event
is mapped, the permissions are set if required. The atomic field added
in the mm_context
The arm64 PMU driver needs to retrieve the struct arm_pmu pointer for
the current CPU. As the common code already maintains this with the
percpu cpu_armpmu, let's make it global.
Signed-off-by: Rob Herring
---
drivers/perf/arm_pmu.c | 2 +-
include/linux/perf/arm_pmu.h | 2 ++
2 files
From: Raphael Gault
In order to be able to access the counter directly for userspace,
we need to provide the index of the counter using the userpage.
We thus need to override the event_idx function to retrieve and
convert the perf_event index to armv8 hardware index.
Since the arm_pmu driver
Hi all,
Another version of arm64 userspace counter access support. I sent out
the libperf bits separately and those are now applied (Thanks!), so this
is just the arm64 bits.
This originally resurrected Raphael's series[1] to enable userspace counter
access on arm64. My previous versions are
From: Raphael Gault
This commit modifies the mask of the mrs_hook declared in
arch/arm64/kernel/cpufeatures.c which emulates only feature register
access. This is necessary because this hook's mask was too large and
thus masking any mrs instruction, even if not related to the emulated
registers
On Thu, Apr 15, 2021 at 9:47 AM Thomas Gleixner wrote:
>
> On Wed, Apr 14 2021 at 11:49, Lorenzo Colitti wrote:
> > On Wed, Apr 14, 2021 at 2:14 AM Greg KH wrote:
> >> To give context, the commit is now 46eb1701c046 ("hrtimer: Update
> >> softirq_expires_next correctly after
On Tue, Apr 20, 2021 at 02:48:17AM +, Vineet Gupta wrote:
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > page inadvertently expanded in 2019.
>
> FWIW, ARC doesn't require 8 byte alignment
Hi Vladimir.
On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Oltean wrote:
>
>What is a scheduled queue? When time-aware scheduling is enabled on the port,
>why are some queues scheduled and some not?
The felix vsc9959 device can set SCH_TRAFFIC_QUEUES field bits to define which
queue is
在 2021/4/19 下午2:33, Zhu Lingshan 写道:
This commit deduces VIRTIO device ID as device type when probe,
then ifcvf_vdpa_get_device_id() can simply return the ID.
ifcvf_vdpa_get_features() and ifcvf_vdpa_get_config_size()
can work properly based on the device ID.
Signed-off-by: Zhu Lingshan
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error:
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Read] Request device [00:05.0] PASID
Currently, WriteBooster (WB) buffer is always flushed during hibern8. However,
this is inefficient because data in the WB buffer can be invalid due to
spatial locality of IO workload.
If the WB buffer flush is flushed in a batched manner, the amount of data
migration and power consumption can be
Our current MIPS platform `__div64_32' handler is inactive, because it
is incorrectly only enabled for 64-bit configurations, for which generic
`do_div' code does not call it anyway.
The handler is not suitable for being called from there though as it
only calculates 32 bits of the quotient
Implement a module for correctness and performance evaluation for the
`do_div' function, often handled in an optimised manner by platform
code. Use a somewhat randomly generated set of inputs that is supposed
to be representative, using the same set of divisors twice, expressed as
a constant
Correct inline documentation for `do_div', which is a function-like
macro the `n' parameter of which has the semantics of a C++ reference:
it is both read and written in the context of the caller without an
explicit dereference such as with a pointer.
In the C programming language it has no
We already check the high part of the divident against zero to avoid the
costly DIVU instruction in that case, needed to reduce the high part of
the divident, so we may well check against the divisor instead and set
the high part of the quotient to zero right away. We need to treat the
high
Hi,
As Huacai has recently discovered the MIPS backend for `do_div' has been
broken and inadvertently disabled with commit c21004cd5b4c ("MIPS: Rewrite
to work with gcc 4.4.0."). As it is code I have originally
written myself and Huacai had issues bringing it back to life leading to a
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error:
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Read] Request device [00:05.0] PASID
Hi,
On Mon, Apr 19, 2021 at 10:21:40PM +0800, Zhou Yanjie wrote:
> Hi
>
> On 2021/4/19 下午12:56, Huang Pei wrote:
> > On Sat, Apr 17, 2021 at 12:45:59AM +0800, Zhou Yanjie wrote:
> > > On 2021/4/16 下午5:20, 黄沛 wrote:
> > > > Is there any log about the panic?
> > >
> > > Yes, below is the log:
> >
Hi Matthew,
On 4/16/21 7:45 PM, Matthew Wilcox wrote:
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)"
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: bro...@redhat.com
> Cc:
On Sun, Apr 18, 2021 at 11:24 PM Bjørn Mork wrote:
>
> Ilya Lipnitskiy writes:
>
> > Add missing binding documentation for SoC support that has been in place
> > since v5.1
> >
> > Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet
> > hardware")
> > Cc: Bjørn Mork
> >
Revert commit 663148e48a66 ("Documentation: DT: net: add docs for
ralink/mediatek SoC ethernet binding")
No in-tree drivers use the compatible strings present in these bindings,
and some have been superseded by DSA-capable mtk_eth_soc driver, so
remove these obsolete bindings.
Cc: John Crispin
On Mon, Apr 19, 2021 at 11:48 PM Christophe Leroy
wrote:
>
> This patch makes use of trap types in head_8xx.S
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/interrupt.h | 29
> arch/powerpc/kernel/head_8xx.S | 49 ++--
> 2
Hi--
On 4/19/21 7:25 PM, Frank Zago wrote:
> From: frank zago
>
>
> Signed-off-by: Frank Zago
> Signed-off-by: frank zago
Don't think you need both of those.
> ---
> MAINTAINERS | 6 +
> drivers/usb/misc/Kconfig| 18 ++
> drivers/usb/misc/Makefile
From: frank zago
The 0x5512 USB PID is for the I2C/GPIO/SPI interfaces. UART is still
present but only the TX and RX pins are available; DTS, DTR, ... are
used for other things. Remove the PID, and let a I2C driver bind to
it.
Existing CH341 boards usually have physical jumpers to switch
From: frank zago
The CH341 is a multifunction chip, presenting 3 different USB PID. One
of these functions is for I2C/SPI/GPIO. This new driver manages I2C
and GPIO. A future update will manage the SPI part as well.
The I2C interface can run at 4 different speeds. This driver currently
only
On 2021/4/20 7:55, Michal Kubecek wrote:
> On Mon, Apr 19, 2021 at 05:29:46PM +0200, Michal Kubecek wrote:
>>
>> As pointed out in the discussion on v3, this patch may result in
>> significantly higher CPU consumption with multiple threads competing on
>> a saturated outgoing device. I missed this
Hi Keqian,
On 4/20/21 9:25 AM, Keqian Zhu wrote:
Hi Baolu,
On 2021/4/19 21:33, Lu Baolu wrote:
Hi Keqian,
On 2021/4/19 17:32, Keqian Zhu wrote:
+EXPORT_SYMBOL_GPL(iommu_split_block);
Do you really have any consumers of this interface other than the dirty
bit tracking? If not, I don't
On 4/19/21 10:01 AM, Maciej W. Rozycki wrote:
> On Mon, 19 Apr 2021, Khalid Aziz wrote:
>
>> On 4/18/21 2:21 PM, Ondrej Zary wrote:
>>>
>>> Found the 3000763 document here:
>>> https://doc.lagout.org/science/0_Computer Science/0_Computer
>>>
Hi, Jiaxun
On 04/20/2021 09:05 AM, Jiaxun Yang wrote:
在 2021/4/19 18:50, Youling Tang 写道:
This problem may only occur on NUMA platforms. When machine start
with the
"mem=" parameter on Loongson64, it cannot boot. When parsing the "mem="
parameter, first remove all RAM, and then add memory
On Mon, 2021-04-19 at 11:44 +0100, Lorenzo Pieralisi wrote:
> On Fri, Apr 16, 2021 at 02:21:00PM -0500, Bjorn Helgaas wrote:
> > On Wed, Mar 24, 2021 at 11:05:03AM +0800, Jianjun Wang wrote:
> > > These series patches add pcie-mediatek-gen3.c and dt-bindings file to
> > > support new generation
On Tue, 13 Apr 2021 07:43:20 +0900, Naoya Horiguchi wrote:
> This patch suggests to do page table walk to find the error virtual
> address. If we find multiple virtual addresses in walking, we now can't
> determine which one is correct, so we fall back to sending SIGBUS in
> kill_me_maybe()
On Mon, 2021-04-19 at 20:39 -0500, Rob Herring wrote:
> On Mon, Apr 19, 2021 at 7:35 PM Leonardo Bras wrote:
> >
> > On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote:
> > > On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote:
> > > >
> > > > Hello Rob, thanks for this feedback!
> > > >
>
On Mon, Apr 19, 2021 at 02:58:12PM -0500, Terry Bowman wrote:
> Turbostat fails to correctly collect and display RAPL summary information
> on Family 17h and 19h AMD processors. Running turbostat on these processors
> returns immediately. If turbostat is working correctly then RAPL summary
> data
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an
issue:
KASAN: null-ptr-deref Write in io_uring_cancel_sqpoll
==
BUG: KASAN: null-ptr-deref in instrument_atomic_read_write
>On Mon, Apr 19, 2021 at 07:27:25PM +0800, Wan Jiabing wrote:>> struct device
>is declared at 133rd line.
>> The declaration here is unnecessary. Remove it.
>>
>> Signed-off-by: Wan Jiabing
>> ---
>> include/linux/libnvdimm.h | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git
On 2021/4/20 0:57, Jaegeuk Kim wrote:
On 04/14, Chao Yu wrote:
As we did for other cases, in fix_curseg_write_pointer(), let's
change as below:
- use callback function s_ops->allocate_segment() instead of
raw function allocate_segment_by_default();
- cover allocate_segment() with curseg_lock
On Tue, 13 Apr 2021 07:43:20 +0900, Naoya Horiguchi wrote:
...
> + * This function is intended to handle "Action Required" MCEs on already
> + * hardware poisoned pages. They could happen, for example, when
> + * memory_failure() failed to unmap the error page at the first call, or
> + * when
On 2021/4/19 22:57, Michal Kubecek wrote:
> On Mon, Apr 19, 2021 at 10:04:27AM +0800, Yunsheng Lin wrote:
>>>
>>> I tried this patch o top of 5.12-rc7 with real devices. I used two
>>> machines with 10Gb/s Intel ixgbe NICs, sender has 16 CPUs (2 8-core CPUs
>>> with HT disabled) and 16 Rx/Tx
Proposal: Provide memory guarantees to userspace oom-killer.
Background:
Issues with kernel oom-killer:
1. Very conservative and prefer to reclaim. Applications can suffer
for a long time.
2. Borrows the context of the allocator which can be resource limited
(low sched priority or limited CPU
If a malicious or compromised Hyper-V sends a spurious message of type
CHANNELMSG_UNLOAD_RESPONSE, the function vmbus_unload_response() will
call complete() on an uninitialized event, and cause an oops.
Reported-by: Michael Kelley
Signed-off-by: Andrea Parri (Microsoft)
---
Changes since v1[1]:
1 - 100 of 1444 matches
Mail list logo
