On Wed, Jul 29, 2020 at 9:13 PM Vinicius Costa Gomes
wrote:
>
> Hi,
>
> "Zhang, Qiang" writes:
>
> >
> > 发件人: linux-kernel-ow...@vger.kernel.org
> > 代表 syzbot
> >
> > 发送时间: 2020年7月29日 13:53
> > 收件人: da...@davemloft.net; fweis...@gmail.com;
On Tue, 14 Jul 2020, Mrinal Pandey wrote:
> The usage of "capture group (...)" in the immediate condition after `&&`
> results in `$1` being uninitialized. This issues a warning "Use of
> uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
> line 2638".
>
> I noticed this
On Mon, Jul 27, 2020 at 11:02:26AM +0530, Srikar Dronamraju wrote:
> Currently "CACHE" domain happens to be the 2nd sched domain as per
> powerpc_topology. This domain will collapse if cpumask of l2-cache is
> same as SMT domain. However we could generalize this domain such that it
> could mean
Hi Jiada,
On Wed, Jul 29, 2020 at 06:22:52PM +0900, Jiada Wang wrote:
> From: Jiada wang
>
> Some I2C controllers constrain maximum transferred data in an I2C
> transaction by set max_[read|write]_len of i2c_adapter_quirk.
> Large i2c transfer transaction beyond this limitation may fail to
allnoconfig
x86_64 randconfig-a004-20200729
x86_64 randconfig-a005-20200729
x86_64 randconfig-a002-20200729
x86_64 randconfig-a006-20200729
x86_64 randconfig-a003-20200729
x86_64 randconfig-a001-20200729
i386
Hello,
syzbot found the following issue on:
HEAD commit:d3590ebf Merge tag 'audit-pr-20200729' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1797d38890
kernel config: https://syzkaller.appspot.com/x/.config?x=812bbfcb6ae2cd60
From: "Gautham R. Shenoy"
We are currently assuming that CEDE(0) has exit latency 10us, since
there is no way for us to query from the platform. However, if the
wakeup latency of an Extended CEDE state is smaller than 10us, then we
can be sure that the exit latency of CEDE(0) cannot be more
On Thu, Jul 30, 2020 at 03:46:26AM +0200, Paul Cercueil wrote:
> Instead of keeping the IPU clock enabled constantly, enable and disable
> it on demand, when the IPU plane is used.
This explains what the patch does - but fails to mention why.
Could you please add the why part too.
With the
From: "Gautham R. Shenoy"
This is a v3 of the patch series to parse the extended CEDE
information in the pseries-cpuidle driver.
The previous two versions of the patches can be found here:
v2:
https://lore.kernel.org/lkml/1596005254-25753-1-git-send-email-...@linux.vnet.ibm.com/
v1:
From: "Gautham R. Shenoy"
Currently we use CEDE with latency-hint 0 as the only other idle state
on a dedicated LPAR apart from the polling "snooze" state.
The platform might support additional extended CEDE idle states, which
can be discovered through the "ibm,get-system-parameter" rtas-call
From: "Gautham R. Shenoy"
As per the PAPR, each H_CEDE call is associated with a latency-hint to
be passed in the VPA field "cede_latency_hint". The CEDE states that
we were implicitly entering so far is CEDE with latency-hint = 0.
This patch explicitly sets the latency hint corresponding to
On 23. 07. 20 1:25, Amit Sunil Dhamne wrote:
> From: Rajan Vaja
>
> Initially all devices are in power up state. Firmware expect that
> processor should call InitFinalize API once it have requested devices
> which are required so that it can turn off all unused devices and
> save power. From
On Wed, Jul 29, 2020 at 05:54:35PM -0300, Daniel Gutson wrote:
> On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson wrote:
> >
> > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann wrote:
> > >
> > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson
> > > wrote:
> > > > On Sun, Jul 26, 2020 at 4:17 AM
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d3590ebf6f91350192737dd1d1b219c05277f067
commit: f86dc5bde18e540743eaef20529d9f2b67283abd rtc: pcf85063: return
meaningful value for RTC_VL_READ
date: 8 months ago
compiler: or1k-linux-gcc (GCC) 9.3.0
If
On Thu, Jul 30, 2020 at 03:46:25AM +0200, Paul Cercueil wrote:
> When configuring the IPU for packed YUV 4:2:2, depending on the scaling
> ratios given by the source and destination resolutions, it is possible
> to crash the IPU block beyond repair, to the point where a software
> reset of the IP
On Thu, Jul 30, 2020 at 03:46:24AM +0200, Paul Cercueil wrote:
> On older SoCs, it is necessary to restart manually the IPU when a frame
> is done processing. Doing so on newer SoCs (JZ4760/70) kinds of work
> too, until the input or output resolutions or the framerate are too
> high.
>
> Make it
On Wed, Jul 29, 2020 at 06:45:46PM -0500, John Donnelly wrote:
>
>
> On 7/29/20 9:16 AM, Mike Snitzer wrote:
> > On Wed, Jul 29 2020 at 7:55am -0400,
> > Greg KH wrote:
> >
> > > On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote:
> > > > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike
From: Chris Lew
In high traffic scenarios a remote may request extra intents to send
data faster. If the work thread that handles these intent requests is
starved of cpu time, then these requests can build up. Some remote
procs may not be able to handle this burst of built up intent requests.
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Hi all,
Today's linux-next merge of the iommu tree got a conflict in:
drivers/iommu/Kconfig
between commit:
2f9237d4f6df ("dma-mapping: make support for dma ops optional")
from the dma-mapping tree and commit:
ab65ba57e3ac ("iommu/vt-d: Move Kconfig and Makefile bits down into intel
From: Arun Kumar Neelakantam
Un-register and register of rpmsg driver is sending invalid open_ack
on closed channel.
To avoid sending invalid open_ack case unregister the rpmsg device
after receiving the local_close_ack from remote side.
Signed-off-by: Deepak Kumar Singh
signed-off-by: Arun
From: Arun Kumar Neelakantam
With current design the transport can send packets of size upto
FIFO_SIZE which is 16k and return failure for all packets above 16k.
Add TX_DATA_CONT command to send packets greater than 16k by splitting
into 8K chunks.
Signed-off-by: Arun Kumar Neelakantam
From: Arun Kumar Neelakantam
The current design sleeps unconditionally in TX FIFO full case and
wakeup only after sleep timer expires which adds random delays in
clients TX path.
Avoid sleep and use READ_NOTIFY command so that writer can be woken up
when remote notifies about read completion by
From: Chris Lew
If a channel is being rapidly restarting and the kobj release worker
is busy, there is a chance the the rpdev_release function will run
after the channel struct itself has been released.
There should not be a need to decouple the channel from rpdev in the
rpdev release since
From: Konstantin Dorfman
When rpmsg client driver destroys last channel endpoint, remove rpmsg
device is triggered. In both cases (destroy endpoint and remove device)
a glink close command sent to the remote peer.
This change, when for removing rpmsg device endpoint already destroyed
will avoid
Includes fixes for -
Few race conditions while channel release and close
Proper unregistration of rpmsg device to avoid use of stale device
Send notify command to remote when glink fifo is full
Handling packet size larger that 16K
Arun Kumar Neelakantam (3):
rpmsg: glink: Add TX_DATA_CONT
On 22-07-20, 11:00, Viresh Kumar wrote:
> On 21-07-20, 07:28, Rob Clark wrote:
> > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> > tree and merge it via msm-next -> drm-next -> linus
>
> I wanted to send it via my tree, but its okay. Pick this patch from
> linux-next and
From: Daeho Jeong
When we use F2FS_IOC_RELEASE_COMPRESS_BLOCKS ioctl, if we can't find
any compressed blocks in the file even with large file size, the
ioctl just ends up without changing the file's status as immutable.
It makes the user, who expects that the file is immutable when it
returns
On Wed, Jul 29, 2020 at 02:09:48PM +, Roy Im wrote:
> Hello Dmitry and Uwe,
>
> Wednesday, July 29, 2020 3:37 PM, Dmitry Torokhov wrote:
>
> > On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote:
> > > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple
> > > mode and
Hi Uwe,
On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote:
> > > v9:
> > > - Removed the header file and put the definitions into the c file.
> > > - Updated the pwm code and error logs with %pE
> >
Hello,
syzbot found the following issue on:
HEAD commit:26027945 Add linux-next specific files for 20200724
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15d5c5d890
kernel config: https://syzkaller.appspot.com/x/.config?x=785eb1cc9c75f625
dashboard
Hi Stephen,
On Thu, 30 Jul 2020 12:59:04 +1000 Stephen Rothwell
wrote:
>
> Hi James,
>
> On Thu, 30 Jul 2020 12:35:03 +1000 (AEST) James Morris
> wrote:
> >
> > On Thu, 30 Jul 2020, Stephen Rothwell wrote:
> >
> > > > I am still applying the above patch ...
> > >
> > > The merge
> Page fault error handling behavior in kvm seems little inconsistent when
> page fault reports error. If we are doing fault synchronously
> then we capture error (-EFAULT) returned by __gfn_to_pfn_memslot() and
> exit to user space and qemu reports error, "error: kvm run failed Bad
> address".
>
On 22-07-20, 10:37, Ionela Voinescu wrote:
> From: Valentin Schneider
>
> schedutil is already a hard-requirement for EAS, which has lead to making
> it default on arm (when CONFIG_BIG_LITTLE), see:
>
> commit 8fdcca8e254a ("cpufreq: Select schedutil when using big.LITTLE")
>
> One thing
On Sun, Jul 26, 2020 at 03:01:00PM -0700, Guenter Roeck wrote:
> -ENOTSUPP is not a SUSV4 error code and should not be used. Use
> -ENOPROTOOPT instead to report EC_RES_INVALID_VERSION responses
> from the EC. This matches match the NFS response for unsupported
> protocol versions.
>
> Cc:
: use-after-free Read in delete_and_unsubscribe_port (2)
syzbot has found a reproducer for the following issue on:
HEAD commit:d3590ebf Merge tag 'audit-pr-20200729' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1207e0b890
kernel
On 22-07-20, 10:37, Ionela Voinescu wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3497c1cd6818..1d0b046fe8e9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -61,6 +61,9 @@ static struct cpufreq_driver *cpufreq_driver;
> static
> The error-number passed into xas_set_err() should be negative. Otherwise,
> the xas_error() will return 0, and grab_mapping_entry() will return the
> found entry instead of a SIGBUS error when the entry is not a value.
> And then, the subsequent code path would be wrong.
>
> Signed-off-by: Hao
On Wed, Jul 29, 2020 at 7:18 PM Logan Gunthorpe wrote:
>
> In order to avoid needing to add every new AMD CPU host bridge to the list
> every cycle, allow P2PDMA if the CPUs vendor is AMD and family is
> greater than 0x17 (Zen).
Might want to say "greater than or equal to" to clarify that all
> Let's clean it up a bit, simplifying error handling and getting rid of
> the label.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
> Signed-off-by: David Hildenbrand
> ---
> mm/page_isolation.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
On 22-07-20, 10:37, Ionela Voinescu wrote:
> +++ b/drivers/base/arch_topology.c
> @@ -27,6 +27,7 @@ __weak bool arch_freq_counters_available(struct cpumask
> *cpus)
> }
> DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE;
>
> +#ifndef CONFIG_BL_SWITCHER
> void
> Right now, if we have two isolations racing, we might trigger the
> WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just
> return directly.
>
> In the future, we might want to report -EAGAIN to the caller instead, as
> this could indicate a temporary isolation failure only.
>
>
From: Nick Dyer
This patch outputs status from T42 touch suppression
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
(cherry picked from ndyer/linux/for-upstream commit
ab95b5a30d2c098daaa9f88d9fcfae7eb516)
Signed-off-by: George G. Davis
[jiada: Replace dev_info()
From: Nick Dyer
This patch outputs status from T48 Noise Suppression
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
(cherry picked from ndyer/linux/for-upstream commit
2895a6ff150a49f27a02938f8d262be238b296d8)
Signed-off-by: George G. Davis
[jiada: Replace bits with
Hi Abhishek,
> On Jul 30, 2020, at 07:17, Abhishek Pandit-Subedi
> wrote:
>
> This reverts commit 7ecacafc240638148567742cca41aa7144b4fe1e.
>
> Testing this change on a board with RTL8822CE, I found that enabling
> autosuspend has no effect on the stability of the system. The board
>
On 22-07-20, 10:37, Ionela Voinescu wrote:
> While the move of the invariance setter calls (arch_set_freq_scale())
> from cpufreq drivers to cpufreq core maintained the previous
> functionality for existing drivers that use target_index() and
> fast_switch() for frequency switching, it also gives
It is not possible for cached_resolved_idx to be invalid here as the
cpufreq core always sets index to a positive value.
Change its type to unsigned int and fix qcom usage a bit.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/qcom-cpufreq-hw.c | 5 +
include/linux/cpufreq.h | 2
> -Original Message-
> From: Marc Zyngier
> Sent: 2020年7月30日 1:00
> To: Wei Yongjun
> Cc: Hulk Robot ; Thomas Gleixner ;
> Jason Cooper ; Shawn Guo ;
> Sascha Hauer ; Joakim Zhang
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH -next]
In the error case, where a power domain cannot be powered on
successfully at boot time (in mtk_register_power_domains),
pm_genpd_init would still be called with is_off=false, and the
system would later try to disable the power domain again, triggering
warnings as disabled clocks are disabled again
-20200729
x86_64 randconfig-a005-20200729
x86_64 randconfig-a002-20200729
x86_64 randconfig-a006-20200729
x86_64 randconfig-a003-20200729
x86_64 randconfig-a001-20200729
i386 randconfig-a003-20200729
i386
SELinux configuration and policy are some of the critical data for this
security module that needs to be measured. This measurement can be used
by an attestation service, for instance, to verify if the configuration
and policies have been setup correctly and that they haven't been tampered
with at
Critical data structures of security modules are currently not measured.
Therefore an attestation service, for instance, would not be able to
attest whether the security modules are always operating with the policies
and configuration that the system administrator had setup. The policies
and
IMA subsystem needs to define IMA hooks that the security modules can
call to measure state and policy data.
Define two new IMA hooks, namely ima_lsm_state() and ima_lsm_policy(),
that the security modules can call to measure LSM state and LSM policy
respectively. Return the status of the
Critical data structures of security modules need to be measured to
enable an attestation service to verify if the configuration and
policies for the security modules have been setup correctly and
that they haven't been tampered with at runtime. A new IMA policy is
required for handling this
The current implementation of early boot measurement in
the IMA subsystem is very specific to asymmetric keys. It does not
handle measurement of other data such as Linux Security Module (LSM)
data. Since most security modules are initialized very early in
the boot cycle, data provided by those
On Tue, 14 Jul 2020, Roman Gushchin wrote:
> I've noticed a number of warnings like "vmstat_refresh: nr_free_cma
> -5" or "vmstat_refresh: nr_zone_write_pending -11" on our production
> hosts. The numbers of these warnings were relatively low and stable,
> so it didn't look like we are
On 27-07-20, 15:48, Rafael J. Wysocki wrote:
> On Wed, Jul 22, 2020 at 11:38 AM Ionela Voinescu
> wrote:
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 036f4cc42ede..bac4101546db 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> >
On 2020/7/30 11:19, Matthew Wilcox wrote:
Maybe let the discussion on removing the ->uptodate array finish
before posting another patch for review?
Hi, Matthew!
Of course, I missed the discussion thread before sending this path.
And thanks for your suggestions.
Best regards,
Yu Kuai
Hi Guenter,
I see that Hans is saying that he has submitted some patch here.
https://lore.kernel.org/lkml/65f27abc-69c8-3877-be5b-e5e478153...@redhat.com/
But, haven't found the actual patches yet !
Thanks,
Badhri
On Wed, Jul 29, 2020 at 8:03 PM Guenter Roeck wrote:
>
> On 7/29/20 7:28 PM,
The pci_generic_config_write32() function will give warning messages
whenever writing less than 4 bytes at a time. As there is nothing we can
do about this without changing the hardware, the message is just a
nuisance. So instead of using the generic functions, use the functions
that have already
The core interrupt code expects the irq_set_affinity call to update the
effective affinity for the interrupt. This was not being done, so update
iproc_msi_irq_set_affinity() to do so.
Signed-off-by: Mark Tomlinson
---
drivers/pci/controller/pcie-iproc-msi.c | 13 +
1 file changed, 9
This makes the read/write functions more generic, allowing them to be
used from other places.
Signed-off-by: Mark Tomlinson
---
drivers/pci/controller/pcie-iproc.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
syzbot has found a reproducer for the following issue on:
HEAD commit:d3590ebf Merge tag 'audit-pr-20200729' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1207e0b890
kernel config: https://syzkaller.appspot.com/x/.config?x
*** BLURB HERE ***
Li Heng (3):
scsi: Remove superfluous memset()
scsi: Remove superfluous memset()
scsi: Remove superfluous memset()
drivers/scsi/mpt3sas/mpt3sas_base.c | 1 -
drivers/scsi/pmcraid.c | 1 -
drivers/scsi/qla2xxx/qla_mbx.c | 2 --
3 files changed, 4
Fixes coccicheck warning:
./drivers/scsi/mpt3sas/mpt3sas_base.c:5247:16-34: WARNING: dma_alloc_coherent
use in ioc -> request already zeroes out memory, so memset is not needed
dma_alloc_coherent use in status already zeroes out memory, so memset is not
needed
Signed-off-by: Li Heng
---
Fixes coccicheck warning:
./drivers/scsi/pmcraid.c:4709:3-21: WARNING: dma_alloc_coherent use in
pinstance -> hrrq_start [ i ] already zeroes out memory, so memset is not
needed
dma_alloc_coherent use in status already zeroes out memory, so memset is not
needed
Signed-off-by: Li Heng
---
Fixes coccicheck warning:
./drivers/scsi/qla2xxx/qla_mbx.c:4928:15-33: WARNING: dma_alloc_coherent use in
els_cmd_map already zeroes out memory, so memset is not needed
dma_alloc_coherent use in status already zeroes out memory, so memset is not
needed
Signed-off-by: Li Heng
---
From: Qianli Zhao
There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer
This is a long life mode set in the factory for extended warranty
battery, the power charging rate is customized so that battery at
work last longer.
Presently switching to a different battery charging mode is through
EC PID 0x0710 to configure the battery firmware, this operation will
be blocked
On Wed, Jul 29, 2020 at 11:02 PM Joel Fernandes (Google)
wrote:
>
> At least since v4.19, the FQS loop no longer reports quiescent states
I meant here, "FQS loop no longer reports quiescent states for offline CPUs."
Sorry,
- Joel
> unless it is a dire situation where an offlined CPU failed
On Wed, Jul 15, 2020 at 10:45 PM Suren Baghdasaryan wrote:
>
> syzbot report [1] describes a deadlock when write operation against an
> ashmem fd executed at the time when ashmem is shrinking its cache results
> in the following lock sequence:
>
> Possible unsafe locking scenario:
>
>
Hi Kees,
On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
> And just another heads-up, the patch[1] (which was never sent to a public
> list) also breaks arm64 (circular header needs?):
(...)
Definitely, we've just got a report about this, I'll have a look once
I'm at the office. I'd
On Wed, Jul 29, 2020 at 02:45:10PM -0700, Andrew Morton wrote:
> On Wed, 29 Jul 2020 14:21:12 -0700 Kees Cook wrote:
>
> > On Sun, Jul 26, 2020 at 01:01:17PM +0200, Alexander A. Klimov wrote:
> > > Rationale:
> > > Reduces attack surface on kernel devs opening the links for MITM
> > > as HTTPS
On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
> +++ b/fs/iomap/buffered-io.c
> @@ -29,7 +29,9 @@ struct iomap_page {
> atomic_tread_count;
> atomic_twrite_count;
> spinlock_t uptodate_lock;
> + spinlock_t
On Wed, Jul 29, 2020 at 04:43:04PM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 4:08 PM Stephen Rothwell
> wrote:
> >
> > include/linux/random.h:123:24: error: variable 'net_rand_state' with
> > 'latent_entropy' attribute must not be local
> > 123 | DECLARE_PER_CPU(struct rnd_state,
On 2020/7/30 10:27, Gao Xiang wrote:
Hi Kuai,
On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
commit 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O
without buffer heads") replace the per-block structure buffer_head with
the per-page structure iomap_page. However,
This warning should be fixed also.
Should I send another patch?
Thanks !
On Thu, 2020-07-30 at 12:55 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/acpi/processor_idle.c: In function
Make use of the flex_array_size() helper to calculate the size of a
flexible array member within an enclosing structure.
This helper offers defense-in-depth against potential integer
overflows, while at the same time makes it explicitly clear that
we are dealing with a flexible array member.
Hi Greg,
On 7/28/20 11:17 PM, Greg KH wrote:
On Tue, Jul 28, 2020 at 08:46:35PM -0700, Hemant Kumar wrote:
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Device file node is created with format
/dev/mhi__
On 7/29/20 7:28 PM, Badhri Jagan Sridharan wrote:
> Hi Greg,
>
> Sure just sent the new patch v3.
>
> Patch applies cleanly on my end. So wondering what I am missing.
I expected your patch to conflict with Hans' patch series.
Maybe those are in a different tree/branch ?
Guenter
> Just in case
At least since v4.19, the FQS loop no longer reports quiescent states
unless it is a dire situation where an offlined CPU failed to report
a quiescent state. Let us clarify the comment in rcu_gp_init() inorder
to keep the comment current.
Signed-off-by: Joel Fernandes (Google)
---
Fixes coccicheck warning:
./drivers/scsi/mvsas/mv_init.c:244:11-29: WARNING: dma_alloc_coherent use in
mvi -> tx already zeroes out memory, so memset is not needed
./drivers/scsi/mvsas/mv_init.c:250:15-33: WARNING: dma_alloc_coherent use in
mvi -> rx_fis already zeroes out memory, so memset
Add a warning if CPU being onlined did not report QS already. This is to
simplify the code in the CPU onlining path and also to make clear about
where QS is reported. The act of QS reporting in CPU onlining path is
is likely unnecessary as shown by code reading and testing with
rcutorture's TREE03
Hi James,
On Thu, 30 Jul 2020 12:35:03 +1000 (AEST) James Morris
wrote:
>
> On Thu, 30 Jul 2020, Stephen Rothwell wrote:
>
> > > I am still applying the above patch ...
> >
> > The merge window is coming up fast ... is anything happening about this
> > failure?
>
> A new patch is coming,
Lee Jones 於 2020年7月29日 週三 下午6:12寫道：
>
> On Wed, 29 Jul 2020, Gene Chen wrote:
>
> > Lee Jones 於 2020年7月27日 週一 下午8:43寫道：
> > >
> > > On Fri, 17 Jul 2020, Gene Chen wrote:
> > >
> > > > From: Gene Chen
> > > >
> > > > Remove unuse register definition.
> > >
> > > This should not be in here.
> > >
Hi,
Summary should specified this patch is for MediaTek:
dt-bindings: add MediaTek keypad devicetree documentation
On Mon, 2020-07-27 at 19:45 +0800, Fengping Yu wrote:
> From: "fengping.yu"
> Add Mediatek matrix keypad dt-bindings doc as yaml schema.
>
> Signed-off-by: fengping.yu
> ---
>
Hi all,
After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/acpi/processor_idle.c: In function 'acpi_idle_enter_s2idle':
drivers/acpi/processor_idle.c:666:4: warning: 'return' with no value, in
function returning non-void [-Wreturn-type]
Hi Alex,
On 7/30/20 4:32 AM, Alex Williamson wrote:
On Tue, 14 Jul 2020 13:57:03 +0800
Lu Baolu wrote:
Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
vfio_group data structure so that it could be
From: Zhang Qiang
Due to cpu hotplug, the "cpuup_canceled" func be called, it's currently
manipulating the alien cache for the canceled cpu's node and this node
may be the same as the node which node's alien cache being operated in
the "__cache_free_alien" func, so we should add a protect for
Hi Greg,
Sure just sent the new patch v3.
Patch applies cleanly on my end. So wondering what I am missing.
Just in case if you are still noticing merge conflicts.
Here is the git log of my local tree:
633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate
workqueue to RT priority for
On Tue, 2020-07-28 at 20:30 +0800, Qii Wang wrote:
> Newer MTK chip support more than 8GB of dram. Replace support_33bits
> with more general dma_max_support and remove mtk_i2c_set_4g_mode.
>
> Signed-off-by: Qii Wang
Qii,
After you remove I2C_DMA_4G_MODE Matthias mentioned, you can have:
On Wed, Jul 29, 2020 at 06:23:41PM -0400, Arvind Sankar wrote:
> On Wed, Jul 29, 2020 at 03:04:43PM -0700, Kees Cook wrote:
> > On Fri, Jul 17, 2020 at 04:17:54PM -0400, Arvind Sankar wrote:
> > > Same as v5 previously posted, but rebased onto next-20200717.
> > >
> > > v5:
> > >
On Thu, 30 Jul 2020, Stephen Rothwell wrote:
> > I am still applying the above patch ...
>
> The merge window is coming up fast ... is anything happening about this
> failure?
A new patch is coming, but I'm not sure this code has had enough review
from the core VFS folk.
Please drop
defconfig
x86_64 randconfig-a004-20200729
x86_64 randconfig-a005-20200729
x86_64 randconfig-a002-20200729
x86_64 randconfig-a006-20200729
x86_64 randconfig-a003-20200729
x86_64 randconfig-a001-20200729
i386
allnoconfig
x86_64 randconfig-a004-20200729
x86_64 randconfig-a005-20200729
x86_64 randconfig-a002-20200729
x86_64 randconfig-a006-20200729
x86_64 randconfig-a003-20200729
x86_64 randconfig-a001
On Wed, Jul 29, 2020 at 07:12:58PM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 5:09 PM Linus Torvalds
> wrote:
> >
> > Removing the __latent_entropy marker obviously fixes things.
>
> Ok, I did that for now. I spent a few minutes looking at the gcc
> plugin in case I'd be hit by some
On Wed, 29 Jul 2020, Kees Cook wrote:
> In preparation for adding partial read support, add an optional output
> argument to kernel_read_file*() that reports the file size so callers
> can reason more easily about their reading progress.
>
> Acked-by: Scott Branden
> Reviewed-by: Mimi Zohar
>
Fix below warnings reported by coccicheck:
./arch/um/drivers/vector_user.c:403:2-7: WARNING: NULL check before some
freeing functions is not needed.
Signed-off-by: Li Heng
---
arch/um/drivers/vector_user.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Hi Kuai,
On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
> commit 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O
> without buffer heads") replace the per-block structure buffer_head with
> the per-page structure iomap_page. However, iomap_page can't track the
> dirty
On Wed, 29 Jul 2020, Kees Cook wrote:
> In preparation for further refactoring of kernel_read_file*(), rename
> the "max_size" argument to the more accurate "buf_size", and correct
> its type to size_t. Add kerndoc to explain the specifics of how the
> arguments will be used. Note that with
1 - 100 of 1239 matches
Mail list logo
