[tip:sched/core] stop_machine: Reflow cpu_stop_queue_two_works()
Commit-ID: b80a2bfce85e1051056d98d04ecb2d0b55cbbc1c
Gitweb: https://git.kernel.org/tip/b80a2bfce85e1051056d98d04ecb2d0b55cbbc1c
Author: Peter Zijlstra
AuthorDate: Mon, 30 Jul 2018 13:21:40 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 2 Aug 2018 15:25:20 +0200
stop_machine: Reflow cpu_stop_queue_two_works()
The code flow in cpu_stop_queue_two_works() is a little arcane; fix this by
lifting the preempt_disable() to the top to create more natural nesting wrt
the spinlocks and make the wake_up_q() and preempt_enable() unconditional
at the end.
Furthermore, enable preemption in the -EDEADLK case, such that we spin-wait
with preemption enabled.
Suggested-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Cc: Sebastian Andrzej Siewior
Cc: isa...@codeaurora.org
Cc: m...@codeblueprint.co.uk
Cc: psoda...@codeaurora.org
Cc: gre...@linuxfoundation.org
Cc: pkond...@codeaurora.org
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/20180730112140.gh2...@hirez.programming.kicks-ass.net
---
kernel/stop_machine.c | 41 +++--
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index e190d1ef3a23..34b6652e8677 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -236,13 +236,24 @@ static int cpu_stop_queue_two_works(int cpu1, struct
cpu_stop_work *work1,
struct cpu_stopper *stopper2 = per_cpu_ptr(&cpu_stopper, cpu2);
DEFINE_WAKE_Q(wakeq);
int err;
+
retry:
+ /*
+* The waking up of stopper threads has to happen in the same
+* scheduling context as the queueing. Otherwise, there is a
+* possibility of one of the above stoppers being woken up by another
+* CPU, and preempting us. This will cause us to not wake up the other
+* stopper forever.
+*/
+ preempt_disable();
raw_spin_lock_irq(&stopper1->lock);
raw_spin_lock_nested(&stopper2->lock, SINGLE_DEPTH_NESTING);
- err = -ENOENT;
- if (!stopper1->enabled || !stopper2->enabled)
+ if (!stopper1->enabled || !stopper2->enabled) {
+ err = -ENOENT;
goto unlock;
+ }
+
/*
* Ensure that if we race with __stop_cpus() the stoppers won't get
* queued up in reverse order leading to system deadlock.
@@ -253,36 +264,30 @@ retry:
* It can be falsely true but it is safe to spin until it is cleared,
* queue_stop_cpus_work() does everything under preempt_disable().
*/
- err = -EDEADLK;
- if (unlikely(stop_cpus_in_progress))
- goto unlock;
+ if (unlikely(stop_cpus_in_progress)) {
+ err = -EDEADLK;
+ goto unlock;
+ }
err = 0;
__cpu_stop_queue_work(stopper1, work1, &wakeq);
__cpu_stop_queue_work(stopper2, work2, &wakeq);
- /*
-* The waking up of stopper threads has to happen
-* in the same scheduling context as the queueing.
-* Otherwise, there is a possibility of one of the
-* above stoppers being woken up by another CPU,
-* and preempting us. This will cause us to n ot
-* wake up the other stopper forever.
-*/
- preempt_disable();
+
unlock:
raw_spin_unlock(&stopper2->lock);
raw_spin_unlock_irq(&stopper1->lock);
if (unlikely(err == -EDEADLK)) {
+ preempt_enable();
+
while (stop_cpus_in_progress)
cpu_relax();
+
goto retry;
}
- if (!err) {
- wake_up_q(&wakeq);
- preempt_enable();
- }
+ wake_up_q(&wakeq);
+ preempt_enable();
return err;
}
Re: [PATCH RFC] x86/kvm/lapic: always disable MMIO interface in x2APIC mode
Paolo Bonzini writes:
> On 30/07/2018 11:14, Vitaly Kuznetsov wrote:
>> Paolo Bonzini writes:
>>
>>> On 27/07/2018 18:48, Jim Mattson wrote:
On a physical machine, I would expect the default local APIC page to
fall in the PCI hole, so it would be correct to sink writes and to
return all ones for reads. Does qemu implement a PCI hole, and does
this address fall into it?
>>>
>>> It does implement a PCI hole, but when using the kernel LAPIC it expects
>>> that only devices write to that range; therefore that address doesn't
>>> fall into the PCI hole, and instead it generates an MSIs.
>>
>> Yes, and that's why I believe it's correct to never forward lapic
>> reads/writes from KVM to userspace when lapic is in kernel.
>>
>> "RFC" was mostly about the inconsistency with the case when APIC access
>> page is in use. To be 100% correct I would suggest to somehow make it
>> behave like MMIO hole in case we're in x2APIC/disabled mode too.
>>
>
> FWIW it is possible to move the MSI memory region from system memory to
> the PCI address space in QEMU, however I'm worried about backwards
> compatibility.
>
You know better :-)
> Vitaly, perhaps you could resubmit this patch, and provide a
> KVM_CAP_DISABLE_QUIRKS switch that would make apic_mmio_{read,write}
> return -EOPNOTSUPP in this case?
Just to make sure I understand,
we introduce a KVM_QUIRK_LAPIC_DISABLED_MMIO bit and will be emulating
MMIO hole in KVM till Qemu is able to deal with reads/writes passed to
it correctly?
--
Vitaly
Re: [RFC PATCH 0/4] file: export functions for binder module
On Mon, Jul 30, 2018 at 10:41:09PM +0100, Al Viro wrote: > On Mon, Jul 30, 2018 at 10:28:40PM +0200, Christian Brauner wrote: > > On Mon, Jul 30, 2018 at 01:19:47PM -0700, Matthew Wilcox wrote: > > > On Mon, Jul 30, 2018 at 10:12:24PM +0200, Christian Brauner wrote: > > > > > I don't expect this patch to be mergeable but rather to kick-off a > > > > > discussion if we can either simply export them as they are or how we > > > > > can > > > > > get supportable exports that allow access to struct files_struct. > > > > > > > > Maybe that wasn't obvious from the first message. Is there any way we > > > > can come up with a way to have versions of these functions that you > > > > would be fine with exporting? > > > > The point is that otherwise we would have to either duplicate the code > > > > or come up with something way more complex. If you have any pointer that > > > > would already help. > > > > > > He said in the first reply this should probably be using an anonfd. > > > If you do that, I think all four of these exports go away. > > > > I try and see if that is possible. > > > > > > > > And there was really no reason to post each of the four exports as > > > separate patches. That just makes review harder on everyone. > > > > Sorry about that. It usually depends on the preferences of each > > maintainer how fine-grained such minor changes should be. > > The fundamental problem here (besides "who the hell thought that this Fine > Piece > Of Software belongs anywhere other than in /dev/null?") is that messing with > other's descriptor table is Fucking Wrong(tm). It's not going to become > a general-purpose interface. That kludge is just that - a kludge caused by > atrocious API design. > > Exports NAKed, and if brought again they'll get NAKed with extreme prejudice That's fair. When this discussion of turning them into modules was started it was expected that this would never fly as is. The question was whether there's any way for binder to touch struct_files of another process directly at all. Now we know, there isn't. What I was hoping for is that this would cause a redesign that avoids touching these helpers. There's an effort from the Android folks now, which is good! Thanks! Christian signature.asc Description: PGP signature
Re: [Question] A novel case happened when using mempool allocate memory.
On Thu, Aug 02, 2018 at 02:22:03PM +0800, zhong jiang wrote: > On 2018/8/1 23:37, Matthew Wilcox wrote: > > Please post the code. > > when module is loaded. we create the specific mempool. The code flow is as > follows. I actually meant "post the code you are testing", not "write out some pseudocode".
Re: [PATCH] nfsd: use true and false for boolean values
OK, applied for for-4.19, thanks.--b.
On Wed, Aug 01, 2018 at 07:44:05PM -0500, Gustavo A. R. Silva wrote:
> Return statements in functions returning bool should use true or false
> instead of an integer value.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> fs/nfsd/nfsfh.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> index a008e76..b319080 100644
> --- a/fs/nfsd/nfsfh.c
> +++ b/fs/nfsd/nfsfh.c
> @@ -451,7 +451,7 @@ static bool fsid_type_ok_for_exp(u8 fsid_type, struct
> svc_export *exp)
> switch (fsid_type) {
> case FSID_DEV:
> if (!old_valid_dev(exp_sb(exp)->s_dev))
> - return 0;
> + return false;
> /* FALL THROUGH */
> case FSID_MAJOR_MINOR:
> case FSID_ENCODE_DEV:
> @@ -461,13 +461,13 @@ static bool fsid_type_ok_for_exp(u8 fsid_type, struct
> svc_export *exp)
> case FSID_UUID8:
> case FSID_UUID16:
> if (!is_root_export(exp))
> - return 0;
> + return false;
> /* fall through */
> case FSID_UUID4_INUM:
> case FSID_UUID16_INUM:
> return exp->ex_uuid != NULL;
> }
> - return 1;
> + return true;
> }
>
>
> --
> 2.7.4
Re: [PATCH RFC] x86/kvm/lapic: always disable MMIO interface in x2APIC mode
On 02/08/2018 15:30, Vitaly Kuznetsov wrote:
>
>> Vitaly, perhaps you could resubmit this patch, and provide a
>> KVM_CAP_DISABLE_QUIRKS switch that would make apic_mmio_{read,write}
>> return -EOPNOTSUPP in this case?
> Just to make sure I understand,
>
> we introduce a KVM_QUIRK_LAPIC_DISABLED_MMIO bit and will be emulating
> MMIO hole in KVM till Qemu is able to deal with reads/writes passed to
> it correctly?
Yes, or forever, whichever comes first.
Paolo
Re: [PATCH v3 1/3] spi: spi-mem: Fix a typo in the documentation of struct spi_mem
Hi Boris, hi Mark,
On 02.08.2018 15:09, Boris Brezillon wrote:
On Thu, 2 Aug 2018 14:53:52 +0200
Frieder Schrempf wrote:
We usually try to avoid empty commit message, even if this one is
pretty obvious, I'd suggest adding something here.
"
Fix a typo in the @drvpriv description.
"
?
Forgot the commit message, sorry.
Mark, can you add it when you apply the patch or should I send a new
version?
Thanks,
Frieder
Signed-off-by: Frieder Schrempf
Acked-by: Boris Brezillon
---
include/linux/spi/spi-mem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 4fa34a2..72cc9bc 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -124,7 +124,7 @@ struct spi_mem_op {
/**
* struct spi_mem - describes a SPI memory device
* @spi: the underlying SPI device
- * @drvpriv: spi_mem_drviver private data
+ * @drvpriv: spi_mem_driver private data
*
* Extra information that describe the SPI memory device and may be needed by
* the controller to properly handle this device should be placed here.
Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag
On Thu, 2 Aug 2018 09:59:38 +0800
piaojun wrote:
> Hi Dominique,
>
> On 2018/8/2 9:54, Dominique Martinet wrote:
> > piaojun wrote on Thu, Aug 02, 2018:
> >> chan->tag is Non-null terminated which will result in printing messy code
> >> when debugging code. So we should add '\0' for tag to make the code more
> >> convenient and robust. In addition, I drop char->tag_len to simplify the
> >> code.
> >
> > Some new lines in commit message would be appreciated.
> >
> > That aside, I have a couple of nitpicks, but it looks good to me - thanks
> >
> >>
> >> Signed-off-by: Jun Piao
> >> ---
> >> net/9p/trans_virtio.c | 15 +--
> >> 1 file changed, 5 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> >> index d422bfc..0fe9c37 100644
> >> --- a/net/9p/trans_virtio.c
> >> +++ b/net/9p/trans_virtio.c
> >> @@ -89,10 +89,8 @@ struct virtio_chan {
> >>unsigned long p9_max_pages;
> >>/* Scatterlist: can be too big for stack. */
> >>struct scatterlist sg[VIRTQUEUE_NUM];
> >> -
> >> - int tag_len;
> >>/*
> >> - * tag name to identify a mount Non-null terminated
> >> + * tag name to identify a mount null terminated
> >> */
> >>char *tag;
> >>
> >> @@ -529,10 +527,9 @@ static ssize_t p9_mount_tag_show(struct device *dev,
> >>vdev = dev_to_virtio(dev);
> >>chan = vdev->priv;
> >>
> >> - memcpy(buf, chan->tag, chan->tag_len);
> >> - buf[chan->tag_len] = 0;
> >> + memcpy(buf, chan->tag, strlen(chan->tag) + 1);
> >>
> >> - return chan->tag_len + 1;
> >> + return strlen(chan->tag) + 1;
> >
> > Use a local variable for strlen(chan->tag)?
> >
> Yes, local variable looks better.
>
> >> }
> >>
> >> static DEVICE_ATTR(mount_tag, 0444, p9_mount_tag_show, NULL);
> >> @@ -585,7 +582,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
> >>err = -EINVAL;
> >>goto out_free_vq;
> >>}
> >> - tag = kmalloc(tag_len, GFP_KERNEL);
> >> + tag = kzalloc(tag_len + 1, GFP_KERNEL);
> >>if (!tag) {
> >>err = -ENOMEM;
> >>goto out_free_vq;
> >> @@ -594,7 +591,6 @@ static int p9_virtio_probe(struct virtio_device *vdev)
> >>virtio_cread_bytes(vdev, offsetof(struct virtio_9p_config, tag),
> >> tag, tag_len);
> >>chan->tag = tag;
> >> - chan->tag_len = tag_len;
> >>err = sysfs_create_file(&(vdev->dev.kobj), &dev_attr_mount_tag.attr);
> >>if (err) {
> >>goto out_free_tag;
> >> @@ -654,8 +650,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
> >>
> >>mutex_lock(&virtio_9p_lock);
> >>list_for_each_entry(chan, &virtio_chan_list, chan_list) {
> >> - if (!strncmp(devname, chan->tag, chan->tag_len) &&
> >> - strlen(devname) == chan->tag_len) {
> >> + if (!strncmp(devname, chan->tag, strlen(chan->tag) + 1)) {
> >
> > strncmp(x, y, strlen(y)+1) is precisely what strcmp does so let's use
> > the simpler version
> >
> strcmp looks simpler, and I will wait for a while to hear more
> suggestions, and then post another patch for these fixes.
>
Nothing more to add. Please go ahead.
> Thanks,
> Jun
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> V9fs-developer mailing list
> v9fs-develo...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/v9fs-developer
Re: [PATCH v2] mfd: dt-bindings: Add rk808 PMIC reset property
Hi Daniel, Am Donnerstag, 29. März 2018, 16:44:43 CEST schrieb Daniel Schultz: > Add documentation about a new rk808 devicetree property. This can enable > the rk805/rk808/rk818 PMIC reset, instead of using soft resets from the > Control and Reset Module. > > Signed-off-by: Daniel Schultz Is this patch still current? Normally they go through the relevant subsystem tree but I don't see Lee Jones in the list of recipients. So you might want to resend with him (and Rob's Ack) added? Heiko
[rt-patch 1/3 v2] arm64/acpi/perf: move pmu allocation to an early CPU up hook
(bah, make a clean The End to adventures in arm-land)
RT cannot allocate while irqs are disabled.
BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:974
in_atomic(): 0, irqs_disabled(): 128, pid: 25, name: cpuhp/0
CPU: 0 PID: 25 Comm: cpuhp/0 Not tainted 4.16.18-rt10-rt #2
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.32 08/22/2017
Call trace:
dump_backtrace+0x0/0x188
show_stack+0x24/0x30
dump_stack+0x9c/0xd0
___might_sleep+0x124/0x188
rt_spin_lock+0x40/0x80
pcpu_alloc+0x104/0x7a0
__alloc_percpu_gfp+0x38/0x48
__armpmu_alloc+0x44/0x168
armpmu_alloc_atomic+0x1c/0x28
arm_pmu_acpi_cpu_starting+0x1cc/0x210
cpuhp_invoke_callback+0xb8/0x820
cpuhp_thread_fun+0xc0/0x1e0
smpboot_thread_fn+0x1ac/0x2c8
kthread+0x134/0x138
ret_from_fork+0x10/0x18
Do the allocation and other preparation for probe along with the other
CPUHP_PERF_{ARCH}_PREPARE stages, where we'll be preemptible, thus no
longer requiring a GFP_ATOMIC allocation either.
Signed-off-by: Mike Galbraith
---
drivers/perf/arm_pmu_acpi.c | 12 ++--
include/linux/cpuhotplug.h |2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/perf/arm_pmu_acpi.c
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -135,10 +135,10 @@ static struct arm_pmu *arm_pmu_acpi_find
return pmu;
}
- pmu = armpmu_alloc_atomic();
+ pmu = armpmu_alloc();
if (!pmu) {
pr_warn("Unable to allocate PMU for CPU%d\n",
- smp_processor_id());
+ raw_smp_processor_id());
return NULL;
}
@@ -185,7 +185,7 @@ static bool pmu_irq_matches(struct arm_p
* coming up. The perf core won't open events while a hotplug event is in
* progress.
*/
-static int arm_pmu_acpi_cpu_starting(unsigned int cpu)
+static int arm_pmu_acpi_cpu_prepare(unsigned int cpu)
{
struct arm_pmu *pmu;
struct pmu_hw_events __percpu *hw_events;
@@ -283,9 +283,9 @@ static int arm_pmu_acpi_init(void)
if (ret)
return ret;
- ret = cpuhp_setup_state(CPUHP_AP_PERF_ARM_ACPI_STARTING,
- "perf/arm/pmu_acpi:starting",
- arm_pmu_acpi_cpu_starting, NULL);
+ ret = cpuhp_setup_state(CPUHP_PERF_ARM_PMU_ACPI_PREPARE,
+ "perf/arm/pmu_acpi:prepare",
+ arm_pmu_acpi_cpu_prepare, NULL);
return ret;
}
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -29,6 +29,7 @@ enum cpuhp_state {
CPUHP_PERF_PREPARE,
CPUHP_PERF_X86_PREPARE,
CPUHP_PERF_X86_AMD_UNCORE_PREP,
+ CPUHP_PERF_ARM_PMU_ACPI_PREPARE,
CPUHP_PERF_BFIN,
CPUHP_PERF_POWER,
CPUHP_PERF_SUPERH,
@@ -114,7 +115,6 @@ enum cpuhp_state {
CPUHP_AP_ARM_VFP_STARTING,
CPUHP_AP_ARM64_DEBUG_MONITORS_STARTING,
CPUHP_AP_PERF_ARM_HW_BREAKPOINT_STARTING,
- CPUHP_AP_PERF_ARM_ACPI_STARTING,
CPUHP_AP_PERF_ARM_STARTING,
CPUHP_AP_ARM_L2X0_STARTING,
CPUHP_AP_ARM_ARCH_TIMER_STARTING,
[PATCH] Kbuild: Makefile.modbuiltin: include auto.conf and tristate.conf mandatory
The files auto.conf and tristate.conf are mandatory for building modules.builtin files, therefore include them as such. Usually, the top-level Makefile ensures that those files exist but we want to make sure we get noticed if they are missing for whatever reason. Signed-off-by: Dirk Gouders --- scripts/Makefile.modbuiltin | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.modbuiltin b/scripts/Makefile.modbuiltin index 40867a41615b..a072a4267746 100644 --- a/scripts/Makefile.modbuiltin +++ b/scripts/Makefile.modbuiltin @@ -8,10 +8,10 @@ src := $(obj) PHONY := __modbuiltin __modbuiltin: --include include/config/auto.conf +include include/config/auto.conf # tristate.conf sets tristate variables to uppercase 'Y' or 'M' # That way, we get the list of built-in modules in obj-Y --include include/config/tristate.conf +include include/config/tristate.conf include scripts/Kbuild.include -- 2.16.4
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thu, 2 Aug 2018 at 15:19, Quentin Perret wrote:
>
> On Thursday 02 Aug 2018 at 15:08:01 (+0200), Peter Zijlstra wrote:
> > On Thu, Aug 02, 2018 at 02:03:38PM +0100, Quentin Perret wrote:
> > > On Thursday 02 Aug 2018 at 14:26:29 (+0200), Peter Zijlstra wrote:
> > > > On Tue, Jul 24, 2018 at 01:25:16PM +0100, Quentin Perret wrote:
> > > > > @@ -5100,8 +5118,17 @@ enqueue_task_fair(struct rq *rq, struct
> > > > > task_struct *p, int flags)
> > > > > update_cfs_group(se);
> > > > > }
> > > > >
> > > > > - if (!se)
> > > > > + if (!se) {
> > > > > add_nr_running(rq, 1);
> > > > > + /*
> > > > > +* The utilization of a new task is 'wrong' so wait
> > > > > for it
> > > > > +* to build some utilization history before trying to
> > > > > detect
> > > > > +* the overutilized flag.
> > > > > +*/
> > > > > + if (flags & ENQUEUE_WAKEUP)
> > > > > + update_overutilized_status(rq);
> > > > > +
> > > > > + }
> > > > >
> > > > > hrtick_update(rq);
> > > > > }
> > > >
> > > > That is a somewhat dodgy hack. There is no guarantee what so ever that
> > > > when the task wakes next its history is any better. The comment doesn't
> > > > reflect this I feel.
> > >
> > > AFAICT the main use-case here is to avoid re-enabling the load balance
> > > and ruining all the task placement because of a tiny task. I don't
> > > really see how we can do that differently ...
> >
> > Sure I realize that.. but it doesn't completely avoid it. Suppose this
> > new task instantly blocks and wakes up again. Then its util signal will
> > be exactly what you didn't want but we'll account it and cause the above
> > scenario you wanted to avoid.
>
> That is true. ... I also realize now that this patch was written long
> before util_est, and that also has an impact here, especially in the
> scenario you described where the task blocks. So any wake-up after the
> first enqueue will risk to overutilize the system, even if the task
> blocked for ages.
>
> Hmm ...
Does a init value set to 0 for util_avg for newly created task can
help in EAS in this case ?
Current initial value is computed to prevent packing newly created
tasks on same CPUs because it hurts performance of some benches. In
fact it somehow assumes that newly created task will use significant
part of the remaining capacity of a CPU and want to spread tasks. In
EAS case, it seems that it prefer to assume that newly created task
are small and we can pack them and wait a bit to make sure the new
task will be a big task and will overload the CPU
Re: [PATCH v2 1/6] iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer
On Jo, 2018-08-02 at 14:05 +0100, Jonathan Cameron wrote: > On Wed, 1 Aug 2018 18:13:09 +0300 > Stefan Popa wrote: > > > > > This patch adds basic support for Analog Devices ADXL372 SPI-Bus > > Three-Axis Digital Accelerometer. > > > > The device is probed and configured the with some initial default > > values. With this basic driver, it is possible to read raw acceleration > > data. > > > > Datasheet: > > http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL > > 372.pdf > > > > Signed-off-by: Stefan Popa > Hi Stefan, > > I would have preferred a cover letter (if nothing else it keeps them > together in > a thread in people's email clients) > > I've just reviewed all of these and I think the only real outstanding > issue > is Mark's requests for small changes in the regmap stuff. > > The open question on what to do long term about 'peak' and similar > derived > channels can probably wait for another day. > > Thanks, > Hi Jonathan, Thank you very much for your review! If you agree, let's leave the 'peak' mode out of this first version of the driver. -Stefan > > > > > --- > > Changes in v2: > > - removed ADXL372_RD_FLAG_MSK and ADXL372_WR_FLAG_MSK macros. > > - handled regmap read/write by setting reg_bits and pad_bits > > fields in regmap_config struct. > > - removed the buffer specifications when defining the channels. > > - changed the activity and inactivity thresholds. > > - added two new functions for setting the activity and inactivity > > timers: adxl372_set_inactivity_time_ms() and > > adxl372_set_activity_time_ms(). > > > > MAINTAINERS | 6 + > > drivers/iio/accel/Kconfig | 11 + > > drivers/iio/accel/Makefile | 1 + > > drivers/iio/accel/adxl372.c | 530 > > > > 4 files changed, 548 insertions(+) > > create mode 100644 drivers/iio/accel/adxl372.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 60b1028..2ba47bb 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -543,6 +543,12 @@ W: http://ez.analog.com/community/linux-dev > > ice-drivers > > S: Supported > > F: drivers/input/misc/adxl34x.c > > > > +ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER > > +M: Stefan Popa > > +W: http://ez.analog.com/community/linux-device-drivers > > +S: Supported > > +F: drivers/iio/accel/adxl372.c > > + > > AF9013 MEDIA DRIVER > > M: Antti Palosaari > > L: linux-me...@vger.kernel.org > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > > index 62ae7e5..1b496ef 100644 > > --- a/drivers/iio/accel/Kconfig > > +++ b/drivers/iio/accel/Kconfig > > @@ -60,6 +60,17 @@ config ADXL345_SPI > > will be called adxl345_spi and you will also get > > adxl345_core > > for the core module. > > > > +config ADXL372 > > + tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver" > > + depends on SPI > > + select IIO_BUFFER > > + select IIO_TRIGGERED_BUFFER > > + help > > + Say yes here to add support for the Analog Devices ADXL372 > > triaxial > > + acceleration sensor. > > + To compile this driver as a module, choose M here: the > > + module will be called adxl372. > > + > > config BMA180 > > tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver" > > depends on I2C > > diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile > > index 636d4d1..5758ffc 100644 > > --- a/drivers/iio/accel/Makefile > > +++ b/drivers/iio/accel/Makefile > > @@ -9,6 +9,7 @@ obj-$(CONFIG_ADIS16209) += adis16209.o > > obj-$(CONFIG_ADXL345) += adxl345_core.o > > obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o > > obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o > > +obj-$(CONFIG_ADXL372) += adxl372.o > > obj-$(CONFIG_BMA180) += bma180.o > > obj-$(CONFIG_BMA220) += bma220_spi.o > > obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o > > diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c > > new file mode 100644 > > index 000..7d5092d > > --- /dev/null > > +++ b/drivers/iio/accel/adxl372.c > > @@ -0,0 +1,530 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * ADXL372 3-Axis Digital Accelerometer SPI driver > > + * > > + * Copyright 2018 Analog Devices Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > + > > +/* ADXL372 registers definition */ > > +#define ADXL372_DEVID 0x00 > > +#define ADXL372_DEVID_MST 0x01 > > +#define ADXL372_PARTID 0x02 > > +#define ADXL372_REVID 0x03 > > +#define ADXL372_STATUS_1 0x04 > > +#define ADXL372_STATUS_2 0x05 > > +#define ADXL372_FIFO_ENTRIES_2 0x06 > > +#define ADXL372_FIFO_ENTRIES_1 0x07 > > +#define ADXL372_X_DATA_H 0x08 > > +#define ADXL372_X_DATA_L 0x09 > > +#define ADXL372_Y_DATA_H 0x0A > > +#define ADXL372_Y_DATA_L 0x0B
Re: [PATCH v5 12/14] sched/fair: Select an energy-efficient CPU on task wake-up
On Tue, Jul 24, 2018 at 01:25:19PM +0100, Quentin Perret wrote:
> @@ -6385,18 +6492,26 @@ static int
> select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int
> wake_flags)
> {
> struct sched_domain *tmp, *sd = NULL;
> + struct freq_domain *fd;
> int cpu = smp_processor_id();
> int new_cpu = prev_cpu;
> - int want_affine = 0;
> + int want_affine = 0, want_energy = 0;
> int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING);
>
> + rcu_read_lock();
> if (sd_flag & SD_BALANCE_WAKE) {
> record_wakee(p);
> - want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu)
> - && cpumask_test_cpu(cpu, &p->cpus_allowed);
> + fd = rd_freq_domain(cpu_rq(cpu)->rd);
> + want_energy = fd && !READ_ONCE(cpu_rq(cpu)->rd->overutilized);
> + want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu) &&
> + cpumask_test_cpu(cpu, &p->cpus_allowed);
> + }
> +
> + if (want_energy) {
> + new_cpu = find_energy_efficient_cpu(p, prev_cpu, fd);
> + goto unlock;
> }
>
And I suppose you rely on the compiler to optimize that for the static
key inside rd_freq_domain()... Does it do a good job of that?
That is, would not something like:
rcu_read_lock();
if (sd_flag & SD_BALANCE_WAKE) {
record_wakee(p);
if (static_branch_unlikely(&sched_energy_present)) {
struct root_domain *rd = cpu_rq(cpu)->rd;
struct freq_domain *fd = rd_freq_domain(rd);
if (fd && !READ_ONCE(rd->overutilized)) {
new_cpu = find_energy_efficient_cpu(p,
prev_cpu, fd);
goto unlock;
}
}
/* ... */
}
Be far more clear ?
Re: [PATCH v2 1/6] iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer
On Thu, 2 Aug 2018 13:52:54 + "Popa, Stefan Serban" wrote: > On Jo, 2018-08-02 at 14:05 +0100, Jonathan Cameron wrote: > > On Wed, 1 Aug 2018 18:13:09 +0300 > > Stefan Popa wrote: > > > > > > > > This patch adds basic support for Analog Devices ADXL372 SPI-Bus > > > Three-Axis Digital Accelerometer. > > > > > > The device is probed and configured the with some initial default > > > values. With this basic driver, it is possible to read raw acceleration > > > data. > > > > > > Datasheet: > > > http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL > > > 372.pdf > > > > > > Signed-off-by: Stefan Popa > > Hi Stefan, > > > > I would have preferred a cover letter (if nothing else it keeps them > > together in > > a thread in people's email clients) > > > > I've just reviewed all of these and I think the only real outstanding > > issue > > is Mark's requests for small changes in the regmap stuff. > > > > The open question on what to do long term about 'peak' and similar > > derived > > channels can probably wait for another day. > > > > Thanks, > > > Hi Jonathan, > > Thank you very much for your review! > > If you agree, let's leave the 'peak' mode out of this first version of the > driver. > That makes life easier, so let's go that way. This has missed the coming merge window, so we might even get that sorted before the following window anyway! Jonathan > -Stefan > > > > > > > > > --- > > > Changes in v2: > > > - removed ADXL372_RD_FLAG_MSK and ADXL372_WR_FLAG_MSK macros. > > > - handled regmap read/write by setting reg_bits and pad_bits > > > fields in regmap_config struct. > > > - removed the buffer specifications when defining the channels. > > > - changed the activity and inactivity thresholds. > > > - added two new functions for setting the activity and inactivity > > > timers: adxl372_set_inactivity_time_ms() and > > > adxl372_set_activity_time_ms(). > > > > > > MAINTAINERS | 6 + > > > drivers/iio/accel/Kconfig | 11 + > > > drivers/iio/accel/Makefile | 1 + > > > drivers/iio/accel/adxl372.c | 530 > > > > > > 4 files changed, 548 insertions(+) > > > create mode 100644 drivers/iio/accel/adxl372.c > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 60b1028..2ba47bb 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -543,6 +543,12 @@ W: http://ez.analog.com/community/linux-dev > > > ice-drivers > > > S: Supported > > > F: drivers/input/misc/adxl34x.c > > > > > > +ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER > > > +M: Stefan Popa > > > +W: http://ez.analog.com/community/linux-device-drivers > > > +S: Supported > > > +F: drivers/iio/accel/adxl372.c > > > + > > > AF9013 MEDIA DRIVER > > > M: Antti Palosaari > > > L: linux-me...@vger.kernel.org > > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > > > index 62ae7e5..1b496ef 100644 > > > --- a/drivers/iio/accel/Kconfig > > > +++ b/drivers/iio/accel/Kconfig > > > @@ -60,6 +60,17 @@ config ADXL345_SPI > > > will be called adxl345_spi and you will also get > > > adxl345_core > > > for the core module. > > > > > > +config ADXL372 > > > + tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver" > > > + depends on SPI > > > + select IIO_BUFFER > > > + select IIO_TRIGGERED_BUFFER > > > + help > > > + Say yes here to add support for the Analog Devices ADXL372 > > > triaxial > > > + acceleration sensor. > > > + To compile this driver as a module, choose M here: the > > > + module will be called adxl372. > > > + > > > config BMA180 > > > tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver" > > > depends on I2C > > > diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile > > > index 636d4d1..5758ffc 100644 > > > --- a/drivers/iio/accel/Makefile > > > +++ b/drivers/iio/accel/Makefile > > > @@ -9,6 +9,7 @@ obj-$(CONFIG_ADIS16209) += adis16209.o > > > obj-$(CONFIG_ADXL345) += adxl345_core.o > > > obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o > > > obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o > > > +obj-$(CONFIG_ADXL372) += adxl372.o > > > obj-$(CONFIG_BMA180) += bma180.o > > > obj-$(CONFIG_BMA220) += bma220_spi.o > > > obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o > > > diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c > > > new file mode 100644 > > > index 000..7d5092d > > > --- /dev/null > > > +++ b/drivers/iio/accel/adxl372.c > > > @@ -0,0 +1,530 @@ > > > +// SPDX-License-Identifier: GPL-2.0+ > > > +/* > > > + * ADXL372 3-Axis Digital Accelerometer SPI driver > > > + * > > > + * Copyright 2018 Analog Devices Inc. > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include > > > +#include > > > + > > > +/* ADXL372 registers definition */ > > > +#define ADXL372_DEVID0x00 > >
Re: [PATCH v3 1/2] iio: light: Add support for vishay vcnl4035
Hi Jonathan, General query, for threshold events and persistence value (period) we don't have any direct MACROS similar to IIO_CONST_ATTR_INT_TIME_AVAIL as ABI to show the available/range of values. For most light and proximity sensors, I could see this value of threshold configuration to limit the amount of interrupts. But there isn't direct way to show the available range for threshold or periods available in sysfs. Can we consider presenting it as separate device attribute? Like, For threshold: in_intensity_thresh_range_available in_proximity_thresh_range_available For period: in_device_persistence/period_available On 08/02/2018 02:49 PM, Jonathan Cameron wrote: On Thu, 2 Aug 2018 11:52:29 +0200 Parthiban Nallathambi wrote: Add support for VCNL4035, which is capable of Ambient light sensing (ALS) and proximity function. This patch adds support only for ALS function Signed-off-by: Parthiban Nallathambi Hi Parthiban, Please avoid replying to a previous thread when sending a new version. It tends to lead to several things: 1. Really deep threads that are very hard to follow. 2. In some email clients, your email appears many pages back in the history. Sure, will send as fresh v4 next. Anyhow... I'm confused how the runtime pm in here is supposed to work. There seems to none of the usual calls to turn the device on when needed. I was expected a pm_runtime_get_sync or similar in the read_raw path. Yes, I missed it. Thanks, will add in v4. A few other bits and bobs inline. Thanks, Jonathan --- Changelog since v1: 1. Fixed 0-day warning on le16_to_cpu usage 2. Persistence value is directly mapped to datasheet's value to avoid confusions of usage from sysfs Changelog in v3: - Usage of lock is not needed, removed mutex locking - ALS threshold and persistence configuration available as events and threshold events are notified to userspace - Usage of devm_ is re-ordered and exit handling updated - Complexity in timestamp calculation is removed and used iio_get_time_ns --- drivers/iio/light/Kconfig| 12 + drivers/iio/light/Makefile | 1 + drivers/iio/light/vcnl4035.c | 619 +++ 3 files changed, 632 insertions(+) create mode 100644 drivers/iio/light/vcnl4035.c diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index c7ef8d1862d6..b7069a4c28a2 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -447,6 +447,18 @@ config VCNL4000 To compile this driver as a module, choose M here: the module will be called vcnl4000. +config VCNL4035 + tristate "VCNL4035 combined ALS and proximity sensor" + select REGMAP_I2C + depends on I2C + help +Say Y here if you want to build a driver for the Vishay VCNL4035, +combined ambient light (ALS) and proximity sensor. Currently only ALS +function is available. + +To compile this driver as a module, choose M here: the +module will be called vcnl4035. + config VEML6070 tristate "VEML6070 UV A light sensor" depends on I2C diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile index 80943af5d627..dce98511a59b 100644 --- a/drivers/iio/light/Makefile +++ b/drivers/iio/light/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_TSL2772) += tsl2772.o obj-$(CONFIG_TSL4531) += tsl4531.o obj-$(CONFIG_US5182D) += us5182d.o obj-$(CONFIG_VCNL4000)+= vcnl4000.o +obj-$(CONFIG_VCNL4035) += vcnl4035.o obj-$(CONFIG_VEML6070)+= veml6070.o obj-$(CONFIG_VL6180) += vl6180.o obj-$(CONFIG_ZOPT2201)+= zopt2201.o diff --git a/drivers/iio/light/vcnl4035.c b/drivers/iio/light/vcnl4035.c new file mode 100644 index ..d2b5ae32baa8 --- /dev/null +++ b/drivers/iio/light/vcnl4035.c @@ -0,0 +1,619 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * VCNL4035 Ambient Light and Proximity Sensor - 7-bit I2C slave address 0x60 + * + * Copyright (c) 2018, DENX Software Engineering GmbH + * Author: Parthiban Nallathambi + * + * + * TODO: Proximity + */ +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#define VCNL4035_DRV_NAME "vcnl4035" +#define VCNL4035_IRQ_NAME "vcnl4035_event" +#define VCNL4035_REGMAP_NAME "vcnl4035_regmap" + +/* Device registers */ +#define VCNL4035_ALS_CONF 0x00 +#define VCNL4035_ALS_THDH 0x01 +#define VCNL4035_ALS_THDL 0x02 +#define VCNL4035_ALS_DATA 0x0B +#define VCNL4035_INT_FLAG 0x0D +#define VCNL4035_DEV_ID0x0E + +/* Register masks */ +#define VCNL4035_MODE_ALS_MASK BIT(0) +#define VCNL4035_MODE_ALS_INT_MASK BIT(1) +#define VCNL4035_ALS_IT_MASK GENMASK(7, 5) +#define VCNL4035_ALS_PERS_MASK GENMASK(3, 2) +#define VCNL4035_INT_ALS_IF_H_MASK BIT(12) +#define VCNL4035_INT_ALS_IF_L_MASK BIT(13
Re: [PATCH] tty: rocket: Fix possible buffer overwrite on register_PCI
On Fri, 27 Jul 2018 16:39:31 +0300 Anton Vasilyev wrote: > If number of isa and pci boards exceed NUM_BOARDS on the path > rp_init()->init_PCI()->register_PCI() then buffer overwrite occurs > in register_PCI() on assign rcktpt_io_addr[i]. > > The patch adds check on upper bound for index of registered > board in register_PCI. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Anton Vasilyev > --- > drivers/tty/rocket.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c > index bdd17d2aaafd..b121d8f8f3d7 100644 > --- a/drivers/tty/rocket.c > +++ b/drivers/tty/rocket.c > @@ -1881,7 +1881,7 @@ static __init int register_PCI(int i, struct pci_dev > *dev) > ByteIO_t UPCIRingInd = 0; > > if (!dev || !pci_match_id(rocket_pci_ids, dev) || > - pci_enable_device(dev)) > + pci_enable_device(dev) || i >= NUM_BOARDS) > return 0; > > rcktpt_io_addr[i] = pci_resource_start(dev, 0); This is a real fix but you want to check i >= NUM_BOARDS before you enable the device Alan
Re: [RFC PATCH v2 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Hi Boris
On 08/02/2018 05:50 AM, Boris Brezillon wrote:
> Hi Yixun,
>
> On Thu, 19 Jul 2018 17:46:12 +0800
> Yixun Lan wrote:
>
> I haven't finished reviewing the driver yet (I'll try to do that later
> this week), but I already pointed a few things to fix/improve.
>
thanks for the fully review, we really appreciate your time ;-)
I will comment on a few general items first, then clarify others after
talking to the NAND/ASIC team
>> +
>> +static int meson_nfc_exec_op(struct nand_chip *chip,
>> + const struct nand_operation *op, bool check_only)
>> +{
>> +
>> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
>> +{
>> +struct nand_chip *nand = mtd_to_nand(mtd);
>> +struct meson_nfc *nfc = nand_get_controller_data(nand);
>> +int info_bytes, page_bytes;
>> +int nsectors;
>> +
>> +nsectors = mtd->writesize / nand->ecc.size;
>> +info_bytes = nsectors * PER_INFO_BYTE;
>> +page_bytes = mtd->writesize + mtd->oobsize;
>> +
>> +if (nfc->data_buf && nfc->info_buf)
>> +return 0;
>> +
>> +nfc->data_buf = kmalloc(page_bytes, GFP_KERNEL);
>
> I'm pretty sure that does not work if you have several chips. Either
> you have one buffer tied to the NFC, and it has to be large enough to
> handle the NAND with the largest page, or you have one buffer per chip.
>
em, we will fix this in next version,
>> +if (!nfc->data_buf)
>> +return -ENOMEM;
>> +
>> +nfc->info_buf = kmalloc(info_bytes, GFP_KERNEL);
>> +if (!nfc->info_buf) {
>> +kfree(nfc->data_buf);
>> +return -ENOMEM;
>> +}
>> +
>
> Those buffers are not removed in the cleanup/error path.
>
indeed, thanks for pointing out.
we actually realized this error after sent out this patch ..
>> +return 0;
>> +}
>> +
>> +static int meson_nfc_calc_set_timing(struct meson_nfc *nfc,
>> + int rc_min, int rea_max, int rhoh_min)
..
>> +
>> +static int
>> +meson_nfc_nand_chip_init(struct device *dev,
>> + struct meson_nfc *nfc, struct device_node *np)
>> +{
>> +struct meson_nfc_nand_chip *chip;
>> +struct nand_chip *nand;
>> +struct mtd_info *mtd;
>> +int ret, nsels, i, len = 0;
>> +char cs_id[16];
>> +u32 tmp;
>> +
>> +if (!of_get_property(np, "reg", &nsels))
>> +return -EINVAL;
>> +
>> +nsels /= sizeof(u32);
>> +if (!nsels || nsels > MAX_CE_NUM) {
>> +dev_err(dev, "invalid reg property size\n");
>> +return -EINVAL;
>> +}
>> +
>> +chip = devm_kzalloc(dev, sizeof(*chip) + (nsels * sizeof(u8)),
>> +GFP_KERNEL);
>> +if (!chip)
>> +return -ENOMEM;
>> +
>> +chip->nsels = nsels;
>> +
>> +for (i = 0; i < nsels; i++) {
>> +ret = of_property_read_u32_index(np, "reg", i, &tmp);
>> +if (ret) {
>> +dev_err(dev, "could not retrieve reg property: %d\n",
>> +ret);
>> +return ret;
>> +}
>> +chip->sels[i] = tmp;
>
> You should probably keep track of all the already assigned CS lines, to
> prevent situations where the same controller-CS is used twice
> (copy&paste error when writing the DT).
>
will do in next version, we would consider to use a bitmap for tracking
this ..
>> +len += snprintf(cs_id + len, 16, "%s%d", i ? "-" : ".", tmp);
>
> Hm, do we really need to be that accurate? I'd suggest using the first
> CS only.
>
ok, this would much simple..
thanks for the suggestion and the detail sample code in the following
section ;-)
>> +}
>> +
>> +chip->is_scramble =
>> +of_property_read_bool(np, "amlogic,nand-enable-scrambler");
>
> I think I already complained about that :P. If you think this is still
> needed (meaning that the autodetection + NAND_NEED_SCRAMBLING flag are
> not enough), I'll need a detailed explanation ;-).
>
yes, we saw this kind comment in DT patch already, we will try to fix this..
>> +
>> +nand = &chip->nand;
>> +nand_set_flash_node(nand, np);
>> +nand_set_controller_data(nand, nfc);
>> +
>> +nand->options |= NAND_USE_BOUNCE_BUFFER;
>> +nand->select_chip = meson_nfc_select_chip;
>> +nand->exec_op = meson_nfc_exec_op;
>> +nand->setup_data_interface = meson_nfc_setup_data_interface;
>> +
>> +nand->ecc.mode = NAND_ECC_HW;
>> +
>> +nand->ecc.write_page_raw = meson_nfc_write_page_raw;
>> +nand->ecc.write_page = meson_nfc_write_page_hwecc;
>> +nand->ecc.write_oob_raw = nand_write_oob_std;
>> +nand->ecc.write_oob = nand_write_oob_std;
>> +
>> +nand->ecc.read_page_raw = meson_nfc_read_page_raw;
>> +nand->ecc.read_page = meson_nfc_read_page_hwecc;
>> +nand->ecc.read_oob_raw = meson_nfc_read_oob_raw;
>> +nand->ecc.read_oob = meson_nfc_read_oob;
>
> We usually setup the ECC fields after the identification phase. This
> way, if you ever want/need to support SW
Re: [PATCH v2 01/10] ASoC: dt-bindings: add dt bindings for wcd9335 audio codec
On Thu, Aug 2, 2018 at 1:33 AM Srinivas Kandagatla wrote: > > Thanks for review, > > On 01/08/18 23:20, Rob Herring wrote: > +- qcom,ifd: > +Usage: required > +Value type: > +Definition: SLIM interface device > >>> Wouldn't this be the parent? > >>> > >> No, Interface device is just like other slim device and is part of > >> SLIMbus Component and has a unique address. Every SLIMbus component has > >> one interface device. > > I still don't understand what this means. If this is SLIMbus specific, > > then maybe it should be named that way? Or it is QCom specific? > > It is SLIMbus specific, I will rename this to "slim,ifd" in next version > which makes it clear! 'slim' is not a vendor. So 'slim-ifc-dev' perhaps. Unless IFD is a well known acronym for someone familiar with SLIMbus. Rob
[PATCH v4 1/7] dmaengine: xilinx_dma: commonize DMA copy size calculation
This patch removes a bit of duplicated code by introducing a new
function that implements calculations for DMA copy size.
Suggested-by: Vinod Koul
Signed-off-by: Andrea Merello
---
Changes in v4:
- introduce this patch in the patch series
---
drivers/dma/xilinx/xilinx_dma.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 27b523530c4a..a3aaa0e34cc7 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -952,6 +952,19 @@ static int xilinx_dma_alloc_chan_resources(struct dma_chan
*dchan)
return 0;
}
+/**
+ * xilinx_dma_calc_copysize - Calculate the amount of data to copy
+ * @size: Total data that needs to be copied
+ * @done: Amount of data that has been already copied
+ *
+ * Return: Amount of data that has to be copied
+ */
+static int xilinx_dma_calc_copysize(int size, int done)
+{
+ return min_t(size_t, size - done,
+XILINX_DMA_MAX_TRANS_LEN);
+}
+
/**
* xilinx_dma_tx_status - Get DMA transaction status
* @dchan: DMA channel
@@ -1791,8 +1804,8 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_slave_sg(
* Calculate the maximum number of bytes to transfer,
* making sure it is less than the hw limit
*/
- copy = min_t(size_t, sg_dma_len(sg) - sg_used,
-XILINX_DMA_MAX_TRANS_LEN);
+ copy = xilinx_dma_calc_copysize(sg_dma_len(sg),
+ sg_used);
hw = &segment->hw;
/* Fill in the descriptor */
@@ -1896,8 +1909,7 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_dma_cyclic(
* Calculate the maximum number of bytes to transfer,
* making sure it is less than the hw limit
*/
- copy = min_t(size_t, period_len - sg_used,
-XILINX_DMA_MAX_TRANS_LEN);
+ copy = xilinx_dma_calc_copysize(period_len, sg_used);
hw = &segment->hw;
xilinx_axidma_buf(chan, hw, buf_addr, sg_used,
period_len * i);
--
2.17.1
[PATCH v4 3/7] dt-bindings: dmaengine: xilinx_dma: add optional xlnx,sg-length-width property
The width of the "length register" cannot be autodetected, and it is now
specified with a DT property. Add DOC for it.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v2:
- change property name
- property is now optional
- cc DT maintainer
Changes in v3:
- reword
- cc DT maintainerS and ML
Changes in v4:
- specify the unit, the valid range and the default value
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfaec43c..aec4a41a03ae 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -41,6 +41,10 @@ Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for AXI DMA:
+- xlnx,sg-length-width: Should be set to the width in bits of the length
+ register as configured in h/w. Takes values {8...26}. If the property
+ is missing or invalid then the default value 23 is used. This is the
+ maximum value that is supported by all IP versions.
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
--
2.17.1
[PATCH v4 4/7] dmaengine: xilinx_dma: program hardware supported buffer length
From: Radhey Shyam Pandey
AXI-DMA IP supports configurable (c_sg_length_width) buffer length
register width, hence read buffer length (xlnx,sg-length-width) DT
property and ensure that driver doesn't program buffer length
exceeding the supported limit. For VDMA and CDMA there is no change.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Michal Simek
Signed-off-by: Andrea Merello [rebase, reword]
---
Changes in v2:
- drop original patch and replace with the one in Xilinx tree
Changes in v3:
- cc DT maintainers/ML
Changes in v4:
- upper bound for the property should be 26, not 23
- add warn for width > 23 as per xilinx original patch
- rework due to changes introduced in 1/6
---
drivers/dma/xilinx/xilinx_dma.c | 36 +
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index aaa6de8a70e4..b17f24e4ec35 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -158,7 +158,9 @@
#define XILINX_DMA_REG_BTT 0x28
/* AXI DMA Specific Masks/Bit fields */
-#define XILINX_DMA_MAX_TRANS_LEN GENMASK(22, 0)
+#define XILINX_DMA_MAX_TRANS_LEN_MIN 8
+#define XILINX_DMA_MAX_TRANS_LEN_MAX 23
+#define XILINX_DMA_V2_MAX_TRANS_LEN_MAX26
#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
#define XILINX_DMA_CR_CYCLIC_BD_EN_MASKBIT(4)
#define XILINX_DMA_CR_COALESCE_SHIFT 16
@@ -418,6 +420,7 @@ struct xilinx_dma_config {
* @rxs_clk: DMA s2mm stream clock
* @nr_channels: Number of channels DMA device supports
* @chan_id: DMA channel identifier
+ * @max_buffer_len: Max buffer length
*/
struct xilinx_dma_device {
void __iomem *regs;
@@ -437,6 +440,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ u32 max_buffer_len;
};
/* Macros */
@@ -964,7 +968,7 @@ static int xilinx_dma_calc_copysize(struct xilinx_dma_chan
*chan,
int size, int done)
{
size_t copy = min_t(size_t, size - done,
-XILINX_DMA_MAX_TRANS_LEN);
+ chan->xdev->max_buffer_len);
if ((copy + done < size) &&
chan->xdev->common.copy_align) {
@@ -1011,7 +1015,7 @@ static enum dma_status xilinx_dma_tx_status(struct
dma_chan *dchan,
list_for_each_entry(segment, &desc->segments, node) {
hw = &segment->hw;
residue += (hw->control - hw->status) &
- XILINX_DMA_MAX_TRANS_LEN;
+ chan->xdev->max_buffer_len;
}
}
spin_unlock_irqrestore(&chan->lock, flags);
@@ -1263,7 +1267,7 @@ static void xilinx_cdma_start_transfer(struct
xilinx_dma_chan *chan)
/* Start the transfer */
dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
- hw->control & XILINX_DMA_MAX_TRANS_LEN);
+ hw->control & chan->xdev->max_buffer_len);
}
list_splice_tail_init(&chan->pending_list, &chan->active_list);
@@ -1366,7 +1370,7 @@ static void xilinx_dma_start_transfer(struct
xilinx_dma_chan *chan)
/* Start the transfer */
dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
- hw->control & XILINX_DMA_MAX_TRANS_LEN);
+ hw->control & chan->xdev->max_buffer_len);
}
list_splice_tail_init(&chan->pending_list, &chan->active_list);
@@ -1727,7 +1731,7 @@ xilinx_cdma_prep_memcpy(struct dma_chan *dchan,
dma_addr_t dma_dst,
struct xilinx_cdma_tx_segment *segment;
struct xilinx_cdma_desc_hw *hw;
- if (!len || len > XILINX_DMA_MAX_TRANS_LEN)
+ if (!len || len > chan->xdev->max_buffer_len)
return NULL;
desc = xilinx_dma_alloc_tx_descriptor(chan);
@@ -2596,7 +2600,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
struct xilinx_dma_device *xdev;
struct device_node *child, *np = pdev->dev.of_node;
struct resource *io;
- u32 num_frames, addr_width;
+ u32 num_frames, addr_width, len_width;
int i, err;
/* Allocate and initialize the DMA engine structure */
@@ -2628,8 +2632,24 @@ static int xilinx_dma_probe(struct platform_device *pdev)
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
- if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
+ xdev->max_buffer_len = GENMASK(XILINX_DMA_MAX_TRANS_LEN_MAX - 1, 0);
+
+ if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
xdev->mcdma = of_property_read
[PATCH v4 6/7] dt-bindings: dmaengine: xilinx_dma: drop has-sg property
This property is not needed anymore, because the driver now autodetects it.
Delete references in documentation.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
Reviewed-by: Rob Herring
---
Changes in v2:
- cc DT maintainer
Changes in v3:
- cc DT maintainerS/ML
Changes in v4:
None
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index aec4a41a03ae..3051bc3713c6 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -37,9 +37,6 @@ Required properties:
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
-Optional properties:
-- xlnx,include-sg: Tells configured for Scatter-mode in
- the hardware.
Optional properties for AXI DMA:
- xlnx,sg-length-width: Should be set to the width in bits of the length
register as configured in h/w. Takes values {8...26}. If the property
--
2.17.1
[PATCH v4 7/7] dmaengine: xilinx_dma: Drop SG support for VDMA IP
xilinx_vdma_start_transfer() is used only for VDMA IP, still it contains
conditional code on has_sg variable. has_sg is set only whenever the HW
does support SG mode, that is never true for VDMA IP.
This patch drops the never-taken branches.
Signed-off-by: Andrea Merello
---
Changes in V4: introduced this patch in series
---
drivers/dma/xilinx/xilinx_dma.c | 84 +
1 file changed, 32 insertions(+), 52 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 78d0f2f8225e..07ceadef0a00 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1093,6 +1093,8 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
struct xilinx_dma_tx_descriptor *desc, *tail_desc;
u32 reg, j;
struct xilinx_vdma_tx_segment *tail_segment;
+ struct xilinx_vdma_tx_segment *segment, *last = NULL;
+ int i = 0;
/* This function was invoked with lock held */
if (chan->err)
@@ -1112,14 +1114,6 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
tail_segment = list_last_entry(&tail_desc->segments,
struct xilinx_vdma_tx_segment, node);
- /*
-* If hardware is idle, then all descriptors on the running lists are
-* done, start new transfers
-*/
- if (chan->has_sg)
- dma_ctrl_write(chan, XILINX_DMA_REG_CURDESC,
- desc->async_tx.phys);
-
/* Configure the hardware using info in the config structure */
reg = dma_ctrl_read(chan, XILINX_DMA_REG_DMACR);
@@ -1128,15 +1122,11 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
else
reg &= ~XILINX_DMA_DMACR_FRAMECNT_EN;
- /*
-* With SG, start with circular mode, so that BDs can be fetched.
-* In direct register mode, if not parking, enable circular mode
-*/
- if (chan->has_sg || !config->park)
- reg |= XILINX_DMA_DMACR_CIRC_EN;
-
+ /* If not parking, enable circular mode */
if (config->park)
reg &= ~XILINX_DMA_DMACR_CIRC_EN;
+ else
+ reg |= XILINX_DMA_DMACR_CIRC_EN;
dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
@@ -1158,48 +1148,38 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
return;
/* Start the transfer */
- if (chan->has_sg) {
- dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
- tail_segment->phys);
- list_splice_tail_init(&chan->pending_list, &chan->active_list);
- chan->desc_pendingcount = 0;
- } else {
- struct xilinx_vdma_tx_segment *segment, *last = NULL;
- int i = 0;
-
- if (chan->desc_submitcount < chan->num_frms)
- i = chan->desc_submitcount;
-
- list_for_each_entry(segment, &desc->segments, node) {
- if (chan->ext_addr)
- vdma_desc_write_64(chan,
- XILINX_VDMA_REG_START_ADDRESS_64(i++),
- segment->hw.buf_addr,
- segment->hw.buf_addr_msb);
- else
- vdma_desc_write(chan,
+ if (chan->desc_submitcount < chan->num_frms)
+ i = chan->desc_submitcount;
+
+ list_for_each_entry(segment, &desc->segments, node) {
+ if (chan->ext_addr)
+ vdma_desc_write_64(chan,
+ XILINX_VDMA_REG_START_ADDRESS_64(i++),
+ segment->hw.buf_addr,
+ segment->hw.buf_addr_msb);
+ else
+ vdma_desc_write(chan,
XILINX_VDMA_REG_START_ADDRESS(i++),
segment->hw.buf_addr);
- last = segment;
- }
-
- if (!last)
- return;
+ last = segment;
+ }
- /* HW expects these parameters to be same for one transaction */
- vdma_desc_write(chan, XILINX_DMA_REG_HSIZE, last->hw.hsize);
- vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
- last->hw.stride);
- vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
+ if (!last)
+ return;
- chan->desc_submitcount++;
- chan->desc_pendingcount--;
- list_del(&desc->node);
- list_add_tail(&desc->node, &chan->active_list);
- if (chan->desc_submitcount == chan->num_frms)
- chan->desc_submitcount = 0;
- }
+ /
[PATCH v4 5/7] dmaengine: xilinx_dma: autodetect whether the HW supports scatter-gather
The AXIDMA and CDMA HW can be either direct-access or scatter-gather
version. These are SW incompatible.
The driver can handle both versions: a DT property was used to
tell the driver whether to assume the HW is in scatter-gather mode.
This patch makes the driver to autodetect this information. The DT
property is not required anymore.
No changes for VDMA.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v2:
- autodetect only in !VDMA case
Changes in v3:
- cc DT maintainers/ML
Changes in v4:
- fix typos in commit message
---
drivers/dma/xilinx/xilinx_dma.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index b17f24e4ec35..78d0f2f8225e 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -86,6 +86,7 @@
#define XILINX_DMA_DMASR_DMA_DEC_ERR BIT(6)
#define XILINX_DMA_DMASR_DMA_SLAVE_ERR BIT(5)
#define XILINX_DMA_DMASR_DMA_INT_ERR BIT(4)
+#define XILINX_DMA_DMASR_SG_MASK BIT(3)
#define XILINX_DMA_DMASR_IDLE BIT(1)
#define XILINX_DMA_DMASR_HALTEDBIT(0)
#define XILINX_DMA_DMASR_DELAY_MASKGENMASK(31, 24)
@@ -407,7 +408,6 @@ struct xilinx_dma_config {
* @dev: Device Structure
* @common: DMA device structure
* @chan: Driver specific DMA channel
- * @has_sg: Specifies whether Scatter-Gather is present or not
* @mcdma: Specifies whether Multi-Channel is present or not
* @flush_on_fsync: Flush on frame sync
* @ext_addr: Indicates 64 bit addressing is supported by dma device
@@ -427,7 +427,6 @@ struct xilinx_dma_device {
struct device *dev;
struct dma_device common;
struct xilinx_dma_chan *chan[XILINX_DMA_MAX_CHANS_PER_DEVICE];
- bool has_sg;
bool mcdma;
u32 flush_on_fsync;
bool ext_addr;
@@ -2400,7 +2399,6 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device
*xdev,
chan->dev = xdev->dev;
chan->xdev = xdev;
- chan->has_sg = xdev->has_sg;
chan->desc_pendingcount = 0x0;
chan->ext_addr = xdev->ext_addr;
/* This variable ensures that descriptors are not
@@ -2493,6 +2491,15 @@ static int xilinx_dma_chan_probe(struct
xilinx_dma_device *xdev,
chan->stop_transfer = xilinx_dma_stop_transfer;
}
+ /* check if SG is enabled (only for AXIDMA and CDMA) */
+ if (xdev->dma_config->dmatype != XDMA_TYPE_VDMA) {
+ if (dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
+ XILINX_DMA_DMASR_SG_MASK)
+ chan->has_sg = true;
+ dev_dbg(chan->dev, "ch %d: SG %s\n", chan->id,
+ chan->has_sg ? "enabled" : "disabled");
+ }
+
/* Initialize the tasklet */
tasklet_init(&chan->tasklet, xilinx_dma_do_tasklet,
(unsigned long)chan);
@@ -2631,7 +2638,6 @@ static int xilinx_dma_probe(struct platform_device *pdev)
return PTR_ERR(xdev->regs);
/* Retrieve the DMA engine properties from the device tree */
- xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
xdev->max_buffer_len = GENMASK(XILINX_DMA_MAX_TRANS_LEN_MAX - 1, 0);
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
--
2.17.1
[PATCH v4 2/7] dmaengine: xilinx_dma: in axidma slave_sg and dma_cylic mode align split descriptors
Whenever a single or cyclic transaction is prepared, the driver
could eventually split it over several SG descriptors in order
to deal with the HW maximum transfer length.
This could end up in DMA operations starting from a misaligned
address. This seems fatal for the HW if DRE is not enabled.
This patch eventually adjusts the transfer size in order to make sure
all operations start from an aligned address.
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v2:
- don't introduce copy_mask field, rather rely on already-esistent
copy_align field. Suggested by Radhey Shyam Pandey
- reword title
Changes in v3:
- fix bug introduced in v2: wrong copy size when DRE is enabled
- use implementation suggested by Radhey Shyam Pandey
Changes in v4:
- rework on the top of 1/6
---
drivers/dma/xilinx/xilinx_dma.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index a3aaa0e34cc7..aaa6de8a70e4 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -954,15 +954,28 @@ static int xilinx_dma_alloc_chan_resources(struct
dma_chan *dchan)
/**
* xilinx_dma_calc_copysize - Calculate the amount of data to copy
+ * @chan: Driver specific DMA channel
* @size: Total data that needs to be copied
* @done: Amount of data that has been already copied
*
* Return: Amount of data that has to be copied
*/
-static int xilinx_dma_calc_copysize(int size, int done)
+static int xilinx_dma_calc_copysize(struct xilinx_dma_chan *chan,
+ int size, int done)
{
- return min_t(size_t, size - done,
+ size_t copy = min_t(size_t, size - done,
XILINX_DMA_MAX_TRANS_LEN);
+
+ if ((copy + done < size) &&
+ chan->xdev->common.copy_align) {
+ /*
+* If this is not the last descriptor, make sure
+* the next one will be properly aligned
+*/
+ copy = rounddown(copy,
+(1 << chan->xdev->common.copy_align));
+ }
+ return copy;
}
/**
@@ -1804,7 +1817,7 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_slave_sg(
* Calculate the maximum number of bytes to transfer,
* making sure it is less than the hw limit
*/
- copy = xilinx_dma_calc_copysize(sg_dma_len(sg),
+ copy = xilinx_dma_calc_copysize(chan, sg_dma_len(sg),
sg_used);
hw = &segment->hw;
@@ -1909,7 +1922,8 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_dma_cyclic(
* Calculate the maximum number of bytes to transfer,
* making sure it is less than the hw limit
*/
- copy = xilinx_dma_calc_copysize(period_len, sg_used);
+ copy = xilinx_dma_calc_copysize(chan,
+ period_len, sg_used);
hw = &segment->hw;
xilinx_axidma_buf(chan, hw, buf_addr, sg_used,
period_len * i);
--
2.17.1
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thursday 02 Aug 2018 at 15:48:01 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 15:19, Quentin Perret wrote:
> >
> > On Thursday 02 Aug 2018 at 15:08:01 (+0200), Peter Zijlstra wrote:
> > > On Thu, Aug 02, 2018 at 02:03:38PM +0100, Quentin Perret wrote:
> > > > On Thursday 02 Aug 2018 at 14:26:29 (+0200), Peter Zijlstra wrote:
> > > > > On Tue, Jul 24, 2018 at 01:25:16PM +0100, Quentin Perret wrote:
> > > > > > @@ -5100,8 +5118,17 @@ enqueue_task_fair(struct rq *rq, struct
> > > > > > task_struct *p, int flags)
> > > > > > update_cfs_group(se);
> > > > > > }
> > > > > >
> > > > > > - if (!se)
> > > > > > + if (!se) {
> > > > > > add_nr_running(rq, 1);
> > > > > > + /*
> > > > > > +* The utilization of a new task is 'wrong' so wait
> > > > > > for it
> > > > > > +* to build some utilization history before trying
> > > > > > to detect
> > > > > > +* the overutilized flag.
> > > > > > +*/
> > > > > > + if (flags & ENQUEUE_WAKEUP)
> > > > > > + update_overutilized_status(rq);
> > > > > > +
> > > > > > + }
> > > > > >
> > > > > > hrtick_update(rq);
> > > > > > }
> > > > >
> > > > > That is a somewhat dodgy hack. There is no guarantee what so ever that
> > > > > when the task wakes next its history is any better. The comment
> > > > > doesn't
> > > > > reflect this I feel.
> > > >
> > > > AFAICT the main use-case here is to avoid re-enabling the load balance
> > > > and ruining all the task placement because of a tiny task. I don't
> > > > really see how we can do that differently ...
> > >
> > > Sure I realize that.. but it doesn't completely avoid it. Suppose this
> > > new task instantly blocks and wakes up again. Then its util signal will
> > > be exactly what you didn't want but we'll account it and cause the above
> > > scenario you wanted to avoid.
> >
> > That is true. ... I also realize now that this patch was written long
> > before util_est, and that also has an impact here, especially in the
> > scenario you described where the task blocks. So any wake-up after the
> > first enqueue will risk to overutilize the system, even if the task
> > blocked for ages.
> >
> > Hmm ...
>
> Does a init value set to 0 for util_avg for newly created task can
> help in EAS in this case ?
> Current initial value is computed to prevent packing newly created
> tasks on same CPUs because it hurts performance of some benches. In
> fact it somehow assumes that newly created task will use significant
> part of the remaining capacity of a CPU and want to spread tasks. In
> EAS case, it seems that it prefer to assume that newly created task
> are small and we can pack them and wait a bit to make sure the new
> task will be a big task and will overload the CPU
Good point, setting the util_avg to 0 for new tasks should help
filtering out those tiny tasks too. And that would match with the idea
of letting tasks build their history before looking at their util_avg ...
But there is one difference w.r.t frequency selection. The current code
won't mark the system overutilized, but will let sugov raise the
frequency when a new task is enqueued. So in case of a fork bomb, we
sort of fallback on the existing mainline strategy for both task
placement (because forkees don't go in find_energy_efficient_cpu) and
frequency selection. And I would argue this is the right thing to do
since EAS can't really help in this case.
Thoughts ?
Thanks,
Quentin
Re: [Question] A novel case happened when using mempool allocate memory.
On 2018/8/2 21:31, Matthew Wilcox wrote:
> On Thu, Aug 02, 2018 at 02:22:03PM +0800, zhong jiang wrote:
>> On 2018/8/1 23:37, Matthew Wilcox wrote:
>>> Please post the code.
>> when module is loaded. we create the specific mempool. The code flow is as
>> follows.
> I actually meant "post the code you are testing", not "write out some
> pseudocode".
>
> .
>
The source code is as follow about mempool utility.
**
* @brief 元素的类型顺序与 @smio_mem_type_t的定义顺序一致
*/
static smio_mem_mng_t g_smio_mem[] =
{
{
.name = "MEDIA_INFO",
.min_pool_size = 128,
.item_size = sizeof(smio_media_info_t),
.slab_cache = NULL,
},
{
.name = "DSW_IO_REQ",
.min_pool_size = 1024,
.item_size = sizeof(dsw_io_req_t),
.slab_cache = NULL,
},
{
.name = "DSW_IO_PAGE",
.min_pool_size = 1024,
.item_size = sizeof(dsw_page_t) * DSW_MAX_PAGE_PER_REQ,
.slab_cache = NULL,
},
{
.name = "32_ARRAY",
.min_pool_size = 1024,
.item_size = sizeof(void *) * 32,
.slab_cache = NULL,
},
{
.name = "SCSI_SENSE_BUF",
.min_pool_size = 1024,
.item_size = sizeof(char) * SCSI_SENSE_BUFFERSIZE,
.slab_cache = NULL,
},
};
/**
* @brief 申请数据类型内存
*
* @param id 申请者模块ID
* @param type 申请内存的类型
*
* @return 成功返回内存块的首地址;失败返回NULL
*/
void *smio_mem_alloc(smio_module_id_t id, smio_mem_type_t type)
{
void *m = NULL;
smio_mem_mng_t *pool_mng = NULL;
SMIO_ASSERT_RETURN(id < SMIO_MOD_ID_BUTT, NULL);
SMIO_ASSERT_RETURN(type < SMIO_MEM_TYPE_BUTT, NULL);
pool_mng = &g_smio_mem[type];
SMIO_LOG_DEBUG("alloc %s, size: %d\n", pool_mng->name, pool_mng->item_size);
m = mempool_alloc(pool_mng->pool, GFP_KERNEL);
if (NULL == m)
{
return NULL;
}
memset(m, 0, pool_mng->item_size);
atomic_inc(&pool_mng->statistics[id]);
return m;
}
EXPORT_SYMBOL(smio_mem_alloc);
/**
* @brief 释放内存块
*
* @param id 申请者的模块ID
* @param type 内存块的类型
* @param m 内在的首地址
*/
void smio_mem_free(smio_module_id_t id, smio_mem_type_t type, void *m)
{
smio_mem_mng_t *pool_mng = NULL;
SMIO_ASSERT(NULL != m);
SMIO_ASSERT(id < SMIO_MOD_ID_BUTT);
SMIO_ASSERT(type < SMIO_MEM_TYPE_BUTT);
pool_mng = &g_smio_mem[type];
mempool_free(m, pool_mng->pool);
atomic_dec(&pool_mng->statistics[id]);
}
EXPORT_SYMBOL(smio_mem_free);
/**
* @brief 创建管理内在池
*
* @param pool_mng 内存类型管理结构
*
* @return 成功返回@SMIO_OK;失败返回@SMIO_ERR
*/
static int smio_mem_pool_create(smio_mem_mng_t *pool_mng)
{
int i;
SMIO_ASSERT_RETURN(NULL != pool_mng, SMIO_ERR);
pool_mng->slab_cache = kmem_cache_create(pool_mng->name,
pool_mng->item_size, 0, 0, NULL);
if (SMIO_IS_ERR_OR_NULL(pool_mng->slab_cache))
{
SMIO_LOG_ERR("kmem_cache_create for %s failed\n", pool_mng->name);
return SMIO_ERR;
}
pool_mng->pool = mempool_create(pool_mng->min_pool_size, mempool_alloc_slab,
mempool_free_slab, pool_mng->slab_cache);
if (NULL == pool_mng->pool)
{
SMIO_LOG_ERR("pool create for %s failed\n", pool_mng->name);
kmem_cache_destroy(pool_mng->slab_cache);
return SMIO_ERR;
}
for (i = 0; i < SMIO_MOD_ID_BUTT; i++)
{
atomic_set(&pool_mng->statistics[i], 0);
}
return SMIO_OK;
}
/**
* @brief 清除内存池
*
* @param pool_mng 所要清除的内存池
*/
void smio_mem_pool_destroy(smio_mem_mng_t *pool_mng)
{
SMIO_ASSERT(NULL != pool_mng);
if (NULL != pool_mng->pool)
{
mempool_destroy(pool_mng->pool);
pool_mng->pool = NULL;
}
if (NULL != pool_mng->slab_cache)
{
kmem_cache_destroy(pool_mng->slab_cache);
pool_mng->slab_cache = NULL;
}
}
/**
* @brief 内存管理单元初始化
*
* @return 成功返回@SMIO_OK;失败返回@SMIO_ERR
*/
int smio_mem_init(void)
{
int i;
int pool_num = (int) SMIO_ARRAY_SIZE(g_smio_mem);
int ret = SMIO_OK;
bool free = SMIO_FALSE;
for (i = 0; i < pool_num; i++)
{
SMIO_LOG_INFO("memory of %s initialize, min_pool_size: %d, item_size: %d\n",
g_smio_mem[i].name, g_smio_mem[i].min_pool_size, g_smio_mem[i].item_size);
if (SMIO_OK != smio_mem_pool_create(&g_smio_mem[i]))
{
SMIO_LOG_ERR("memory of %s initialize failed\n", g_smio_mem[i].name);
ret = SMIO_ERR;
free = SMIO_TRUE;
break;
}
}
/* clean if smio_mem_pool_create failed*/
while ((SMIO_TRUE == free) && (--i >= 0))
{
smio_mem_pool_destroy(&g_smio_mem[i]);
}
return ret;
}
/**
* @brief 内存管理模块清除退出
*/
void smio_mem_exit(void)
{
int i;
int pool_num = (int) SMIO_ARRAY_SIZE(g_smio_mem);
for (i = 0; i < pool_num; i++)
{
smio_mem_pool_destroy(&g_smio_mem[i]);
}
}
Re: [PATCH] ALSA: usb-audio: Fix wrong sizeof argument
On Thu, 02 Aug 2018 16:17:23 +0200,
Gustavo A. R. Silva wrote:
>
> The correct argument to be passed to kzalloc is sizeof(*pd)
>
> Addresses-Coverity-ID: 1472224 ("Wrong sizeof argument")
> Fixes: 7edf3b5e6a45 ("ALSA: usb-audio: AudioStreaming Power Domain parsing")
> Signed-off-by: Gustavo A. R. Silva
It's already fixed, thanks.
Takashi
your photos need edit
As a boutique team, we work personally with our clients to ensure the good results. Having over a decade of hands-on experience in photography and retouching, we have been inspired to expand our services to the public. We are team of artists who have excelled in fields such as art, photography, retouching, graphics and design. No matter what your field of interest is in, we can learn to work with your style to give you the best product. We provide below image editing services: Clipping path Image cut out Image shadow creation Image masking Photo retouching Beauty retouching (skin, face, body retouching) Glamour retouching Product retouching Color correction and others We provide testing for our services. Thanks, Sam
Re: [RFC 1/2] slub: Avoid trying to allocate memory on offline nodes
On Wed, 1 Aug 2018, Jeremy Linton wrote:
> diff --git a/mm/slub.c b/mm/slub.c
> index 51258eff4178..e03719bac1e2 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2519,6 +2519,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t
> gfpflags, int node,
> if (unlikely(!node_match(page, searchnode))) {
> stat(s, ALLOC_NODE_MISMATCH);
> deactivate_slab(s, page, c->freelist, c);
> + if (!node_online(searchnode))
> + node = NUMA_NO_NODE;
> goto new_slab;
> }
> }
>
Would it not be better to implement this check in the page allocator?
There is also the issue of how to fallback to the nearest node.
NUMA_NO_NODE should fallback to the current memory allocation policy but
it seems by inserting it here you would end up just with the default node
for the processor.
[PATCH] ALSA: usb-audio: Fix wrong sizeof argument
The correct argument to be passed to kzalloc is sizeof(*pd)
Addresses-Coverity-ID: 1472224 ("Wrong sizeof argument")
Fixes: 7edf3b5e6a45 ("ALSA: usb-audio: AudioStreaming Power Domain parsing")
Signed-off-by: Gustavo A. R. Silva
---
sound/usb/stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/usb/stream.c b/sound/usb/stream.c
index 8fe3b0e..67cf849 100644
--- a/sound/usb/stream.c
+++ b/sound/usb/stream.c
@@ -1037,7 +1037,7 @@ snd_usb_get_audioformat_uac3(struct snd_usb_audio *chip,
fp->rate_max = UAC3_BADD_SAMPLING_RATE;
fp->rates = SNDRV_PCM_RATE_CONTINUOUS;
- pd = kzalloc(sizeof(pd), GFP_KERNEL);
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
kfree(fp->rate_table);
kfree(fp);
--
2.7.4
[GIT PULL] PCI fixes for v4.18
PCI fixes: - Fix integer overflow in new mobiveil driver (Dan Carpenter) - Fix race during NVMe removal/rescan (Hari Vyas) The following changes since commit bd91b56cb3b27492963caeb5fccefe20a986ca8d: PCI/AER: Work around use-after-free in pcie_do_fatal_recovery() (2018-07-26 12:13:04 -0500) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.18-fixes-5 for you to fetch changes up to 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76: PCI: Fix is_added/is_busmaster race condition (2018-07-31 11:27:54 -0500) pci-v4.18-fixes-5 Dan Carpenter (1): PCI: mobiveil: Avoid integer overflow in IB_WIN_SIZE Hari Vyas (1): PCI: Fix is_added/is_busmaster race condition arch/powerpc/kernel/pci-common.c | 4 +++- arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++- arch/powerpc/platforms/pseries/setup.c| 3 ++- drivers/pci/bus.c | 6 +++--- drivers/pci/controller/pcie-mobiveil.c| 2 +- drivers/pci/hotplug/acpiphp_glue.c| 2 +- drivers/pci/pci.h | 11 +++ drivers/pci/probe.c | 4 ++-- drivers/pci/remove.c | 5 +++-- include/linux/pci.h | 1 - 10 files changed, 28 insertions(+), 13 deletions(-)
Re: [PATCH v3 1/3] spi: spi-mem: Fix a typo in the documentation of struct spi_mem
On Thu, Aug 02, 2018 at 03:39:18PM +0200, Frieder Schrempf wrote: > Mark, can you add it when you apply the patch or should I send a new > version? I'd applied before I saw this subthread, Boris is right that it is better but for something this obvious I'm not sufficiently bothered by the missing log. signature.asc Description: PGP signature
Re: linux-next: build warning after merge of the sound-asoc tree
On Thu, Aug 02, 2018 at 02:06:30PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the sound-asoc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: I was sent a patch for this already, should be fixed tomorrow. Thanks for reporting. signature.asc Description: PGP signature
Re: [PATCH 6/6] dt-bindings: interrupt-controller: RISC-V PLIC documentation
On Thu, Aug 2, 2018 at 3:50 AM Christoph Hellwig wrote: > > On Wed, Aug 01, 2018 at 12:26:31PM -0600, Rob Herring wrote: > > Not really my problem that they didn't follow the process and upstream > > their binding first. But this alone is just a string identifier, so I > > don't really care that much. If things are really a mess, then the > > next implementations will have to have better compatible strings. More > > likely, I'll just see folks trying to add various properties to deal > > with all the differences. > > > > You could always define a better compatible and leave 'riscv,plic0' as > > a fallback to avoid breaking things. > > Is there any better way to define a compatible other than having > duplicate IRQCHIP_DECLARE() statements? No, but you only need the fallback if the compatible is '"sifive,plic0", "riscv,plic0";'. Rob
Re: [PATCH] watchdog: Reduce message verbosity
On 8/2/2018 5:18 AM, Thomas Gleixner wrote: On Mon, 30 Jul 2018, Sinan Kaya wrote: Reducing the verbosity level to debug for people that are interested in debugging watchdog issues. [0.152492] NMI watchdog: Perf event create on CPU 0 failed with -2 [0.156002] NMI watchdog: Perf NMI watchdog permanently disabled This changelog is utterly useless. I'll capture my conversation with Don into the commit message and post post V2. Thanks, tglx
Re: [PATCH v12 0/3] tracing: Centralize preemptirq tracepoints and unify their usage
Hi Joel, I found this caused several issues when testing ftrace. #1) ftrace boottest (FTRACE_STARTUP_TEST) fails #2) mmiotrace reports "IRQs not enabled as expected" error #3) lock subsystem event boottest causes "IRQs not disabled as expected" error (sometimes) #4) ftracetest test.d/event/toplevel-enable.tc causes "suspicious RCU usage" warning #1-#3 were resolved if I reverted this [3/3] patch. #4 is resolved if I revered this [2/3] patch. See attached logs for details. I also attached my kernel .config. I guess the first one comes from PREEMPTIRQ_TRACEPOINTS=n, so it should also disable preemptirq tracer. But #2-#4 we should look into it. Could you help us to solve these issues? Thank you, On Mon, 30 Jul 2018 15:24:20 -0700 Joel Fernandes wrote: > From: "Joel Fernandes (Google)" > > This series contains the last 2 patches with minor changes suggested by Peter > and Steven, and an additional clean up of get_lock_stats as suggested by > Peter. > > The preempt/irq tracepoints exist but not everything in the kernel is using it > whenever they need to be notified that a preempt disable/enable or an irq > disable/enable has occurred. This makes things not work simultaneously (for > example, only either lockdep or irqsoff trace-events can be used at a time). > > This is particularly painful to deal with, since turning on lockdep breaks > tracers that install probes on IRQ events, such as the BCC atomic critical > section tracer [1]. This constraint also makes it not possible to use > synthetic > events to trace irqsoff sections with lockdep simulataneously turned on. > > This series solves that, and also results in a nice clean up of relevant parts > of the kernel. Several ifdefs are simpler, and the design is more unified and > better. Also as a result of this, we also speeded performance all rcuidle > tracepoints since their handling is simpler. > > [1] https://github.com/iovisor/bcc/pull/1801/ > > v11->v12: > - minor corrections to changelog > - Added PeterZ's Acks > - Squashed in fix for get_lock_stats > > v10->v11: > - Dropped extra unneeded else statement since > rcu_read_lock_sched_notrace is same as prempt_disable_notrace (PeterZ) > > v9->v10: > - Dropped first 3 and last 2 patches that were applied previously > - Folded SPDK license into the main patch introducing trace_preemptirq.c > (Steve) > - Dropped lockdep_recursing & use simplify get_cpu_var instead (PeterZ) > - Simplify __DO_TRACE and use rcu_dereference_raw for both RCU and SRCU > (PeterZ) > > v8->v9: > - Small style changes to tracepoint code (Mathieu) > - Minor style fix to use PTR_ERR_OR_ZERO (0-day bot) > - Minor fix to test_atomic_sections to use unsigned long. > - Added Namhyung's, Mathieu's Reviewed-by to some patches. > > v7->v8: > - Refactored irqsoff tracer probe defines (Namhyung) > > v6->v7: > - Added a module to simulate an atomic section, a kselftest to load and > and trigger it which verifies the preempt-tracer and this series. > > - Fixed a new warning after I rebased in early boot, this is because > early_boot_irqs_disabled was set too early, I moved it after the lockdep > initialization. > > - added back the softirq fix since it appears it wasn't picked up. > > - Ran Ingo's locking API selftest suite which are passing with this > series. > > - Mathieu suggested ifdef'ing the tracepoint_synchronize_unregister > function incase tracepoints aren't enabled, did that. > > Joel Fernandes (Google) (3): > lockdep: use this_cpu_ptr instead of get_cpu_var stats > tracepoint: Make rcuidle tracepoint callers use SRCU > tracing: Centralize preemptirq tracepoints and unify their usage > > include/linux/ftrace.h| 11 +- > include/linux/irqflags.h | 11 +- > include/linux/lockdep.h | 8 +- > include/linux/preempt.h | 2 +- > include/linux/tracepoint.h| 41 -- > include/trace/events/preemptirq.h | 23 +-- > init/main.c | 5 +- > kernel/locking/lockdep.c | 45 ++ > kernel/sched/core.c | 2 +- > kernel/trace/Kconfig | 22 ++- > kernel/trace/Makefile | 2 +- > kernel/trace/trace_irqsoff.c | 231 -- > kernel/trace/trace_preemptirq.c | 72 ++ > kernel/tracepoint.c | 16 ++- > 14 files changed, 244 insertions(+), 247 deletions(-) > create mode 100644 kernel/trace/trace_preemptirq.c > > -- > 2.18.0.345.g5c9ce644c3-goog -- Masami Hiramatsu [2.271078] Testing tracer preemptirqsoff: .. no entries found ..FAILED! [2.381015] WARNING: CPU: 0 PID: 1 at /home/mhiramat/ksrc/linux/kernel/trace/trace.c:1512 run_tracer_selftest+0xf3/0x154 [2.382000] Modules linked in: [2.382000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc6+ #15 [2.382000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [2.382000] RIP: 0010:run_tracer_selftest+0xf3/0x
Applied "mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name" to the spi tree
The patch mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From b02b17f55b2e789b9747cf4dd2eaaa110439a4cc Mon Sep 17 00:00:00 2001 From: Frieder Schrempf Date: Thu, 2 Aug 2018 14:53:54 +0200 Subject: [PATCH] mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name By calling spi_mem_get_name(), the driver of the (Q)SPI controller can set a custom name for the memory device if necessary. This is useful to keep mtdparts compatible when controller drivers are ported from the MTD to the SPI layer. Suggested-by: Boris Brezillon Signed-off-by: Frieder Schrempf Acked-by: Boris Brezillon Signed-off-by: Mark Brown --- drivers/mtd/devices/m25p80.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index e84563d2067f..aac488008216 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -202,6 +202,9 @@ static int m25p_probe(struct spi_mem *spimem) if (data && data->name) nor->mtd.name = data->name; + if (!nor->mtd.name) + nor->mtd.name = spi_mem_get_name(spimem); + /* For some (historical?) reason many platforms provide two different * names in flash_platform_data: "name" and "type". Quite often name is * set to "m25p80" and then "type" provides a real chip name. -- 2.18.0
Applied "spi: spi-mem: Fix a typo in the documentation of struct spi_mem" to the spi tree
The patch
spi: spi-mem: Fix a typo in the documentation of struct spi_mem
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 06bcb5168d7d49aa3ed449ff13a6d13c30afc3f0 Mon Sep 17 00:00:00 2001
From: Frieder Schrempf
Date: Thu, 2 Aug 2018 14:53:52 +0200
Subject: [PATCH] spi: spi-mem: Fix a typo in the documentation of struct
spi_mem
Fix a typo in the @drvpriv description.
Signed-off-by: Frieder Schrempf
Acked-by: Boris Brezillon
Signed-off-by: Mark Brown
---
include/linux/spi/spi-mem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index bb4bd15ae1f6..951a2e949d5f 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -122,7 +122,7 @@ struct spi_mem_op {
/**
* struct spi_mem - describes a SPI memory device
* @spi: the underlying SPI device
- * @drvpriv: spi_mem_drviver private data
+ * @drvpriv: spi_mem_driver private data
*
* Extra information that describe the SPI memory device and may be needed by
* the controller to properly handle this device should be placed here.
--
2.18.0
[PATCH 3/3] ASoC: core: remove support for card rebind using component framework
DRM based audio components get registered inside the component framework
bind callback. However component framework has a big mutex lock taken for
every call to component_add, component_del and bind, unbind callbacks.
This can lead to deadlock situation if we are trying to add new/remove
component within a bind/unbind callbacks. Which is what was happening
with bcm2837 rpi 3.
Revert this change till we sort out the mutex issue.
Reported-by: Guillaume Tucker
Reported-by: Stefan Wahren
Signed-off-by: Srinivas Kandagatla
---
include/sound/soc.h | 7 --
sound/soc/soc-core.c | 62
2 files changed, 69 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index ace474e8649e..41cec42fb456 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1091,12 +1090,6 @@ struct snd_soc_card {
struct work_struct deferred_resume_work;
- /* component framework related */
- bool components_added;
- /* set in machine driver to enable/disable auto re-binding */
- bool auto_bind;
- struct component_match *match;
-
/* lists of probed devices belonging to this card */
struct list_head component_dev_list;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 81b27923303d..82eb3868be67 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -279,28 +279,11 @@ static inline void snd_soc_debugfs_exit(void)
#endif
-static int snd_soc_card_comp_compare(struct device *dev, void *data)
-{
- struct snd_soc_component *component;
-
- lockdep_assert_held(&client_mutex);
- list_for_each_entry(component, &component_list, list) {
- if (dev == component->dev) {
- if (!strcmp(component->name, data))
- return 1;
- break;
- }
- }
-
- return 0;
-}
-
static int snd_soc_rtdcom_add(struct snd_soc_pcm_runtime *rtd,
struct snd_soc_component *component)
{
struct snd_soc_rtdcom_list *rtdcom;
struct snd_soc_rtdcom_list *new_rtdcom;
- char *cname;
for_each_rtdcom(rtd, rtdcom) {
/* already connected */
@@ -317,13 +300,6 @@ static int snd_soc_rtdcom_add(struct snd_soc_pcm_runtime
*rtd,
list_add_tail(&new_rtdcom->list, &rtd->component_list);
- if (rtd->card->auto_bind && !rtd->card->components_added) {
- cname = devm_kasprintf(rtd->card->dev, GFP_KERNEL,
- "%s", component->name);
- component_match_add(rtd->card->dev, &rtd->card->match,
- snd_soc_card_comp_compare, cname);
- }
-
return 0;
}
@@ -859,25 +835,6 @@ static bool soc_is_dai_link_bound(struct snd_soc_card
*card,
return false;
}
-static int snd_soc_card_comp_bind(struct device *dev)
-{
- struct snd_soc_card *card = dev_get_drvdata(dev);
-
- if (card->instantiated)
- return 0;
-
- return snd_soc_register_card(card);
-}
-
-static void snd_soc_card_comp_unbind(struct device *dev)
-{
-}
-
-static const struct component_master_ops snd_soc_card_comp_ops = {
- .bind = snd_soc_card_comp_bind,
- .unbind = snd_soc_card_comp_unbind,
-};
-
static int soc_bind_dai_link(struct snd_soc_card *card,
struct snd_soc_dai_link *dai_link)
{
@@ -2169,12 +2126,6 @@ static int snd_soc_instantiate_card(struct snd_soc_card
*card)
card->instantiated = 1;
snd_soc_dapm_sync(&card->dapm);
- if (card->auto_bind && !card->components_added) {
- component_master_add_with_match(card->dev,
- &snd_soc_card_comp_ops,
- card->match);
- card->components_added = true;
- }
mutex_unlock(&card->mutex);
mutex_unlock(&client_mutex);
@@ -2820,9 +2771,6 @@ int snd_soc_unregister_card(struct snd_soc_card *card)
dev_dbg(card->dev, "ASoC: Unregistered card '%s'\n",
card->name);
}
- if (!card->auto_bind && card->components_added)
- component_master_del(card->dev, &snd_soc_card_comp_ops);
-
return 0;
}
EXPORT_SYMBOL_GPL(snd_soc_unregister_card);
@@ -3235,17 +3183,8 @@ int snd_soc_add_component(struct device *dev,
snd_soc_component_add(component);
- ret = component_add(dev, NULL);
- if (ret < 0) {
- dev_err(dev, "ASoC: Failed to add Component: %d\n", ret);
- goto err_comp;
- }
-
return 0;
-err_comp:
- soc_remove_component(component);
- snd_soc_unregister_dais(component);
err_cleanup:
snd_soc_component_cleanup(component);
err_free:
@@ -3293,7 +3232,6 @@ static int __snd_soc_unregister_c
[PATCH 0/3] ASoC: core: remove support for card rebind using component framework
DRM based audio components get registered inside the component framework bind callback. However component framework has a big mutex lock taken for every call to component_add, component_del and bind, unbind callbacks. This can lead to deadlock situation if we are trying to add new/remove component within a bind/unbind callbacks. Which is what was happening with bcm2837 rpi 3. Revert this change till we sort out the mutex issue. Thanks, srini Srinivas Kandagatla (3): ASoC: apq8096: remove auto rebinding ASoC: smd845: remove auto rebinding ASoC: core: remove support for card rebind using component framework include/sound/soc.h | 7 -- sound/soc/qcom/apq8096.c | 2 -- sound/soc/qcom/sdm845.c | 2 -- sound/soc/soc-core.c | 62 4 files changed, 73 deletions(-) -- 2.16.2
[PATCH 1/3] ASoC: apq8096: remove auto rebinding
Remove auto rebinding support, as component framework can deadlock
in few usecases if we are trying to add new/remove component within
a bind/unbind callbacks.
Card rebinding is ASoC core feature so all the previous component
framework stuff in q6dsp remains removed.
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/apq8096.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
index 1e4a90d59228..6ee7e66cbaaa 100644
--- a/sound/soc/qcom/apq8096.c
+++ b/sound/soc/qcom/apq8096.c
@@ -48,7 +48,6 @@ static int apq8096_platform_probe(struct platform_device
*pdev)
return -ENOMEM;
card->dev = dev;
- card->auto_bind = true;
dev_set_drvdata(dev, card);
ret = qcom_snd_parse_of(card);
if (ret) {
@@ -74,7 +73,6 @@ static int apq8096_platform_remove(struct platform_device
*pdev)
{
struct snd_soc_card *card = dev_get_drvdata(&pdev->dev);
- card->auto_bind = false;
snd_soc_unregister_card(card);
kfree(card->dai_link);
kfree(card);
--
2.16.2
[PATCH 2/3] ASoC: smd845: remove auto rebinding
Remove auto rebinding support, as component framework can deadlock
in few usecases if we are trying to add new/remove component within
a bind/unbind callbacks.
Card rebinding is ASoC core feature so all the previous component
framework stuff in q6dsp remains removed.
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/sdm845.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index bf4ec4646906..be0cb1122036 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -226,7 +226,6 @@ static int sdm845_snd_platform_probe(struct platform_device
*pdev)
return -ENOMEM;
card->dev = dev;
- card->auto_bind = true;
dev_set_drvdata(dev, card);
ret = qcom_snd_parse_of(card);
if (ret) {
@@ -258,7 +257,6 @@ static int sdm845_snd_platform_remove(struct
platform_device *pdev)
struct snd_soc_card *card = dev_get_drvdata(&pdev->dev);
struct sdm845_snd_data *data = snd_soc_card_get_drvdata(card);
- card->auto_bind = false;
snd_soc_unregister_card(card);
kfree(card->dai_link);
kfree(data);
--
2.16.2
[PATCH] x86/kvm/lapic: always disable MMIO interface in x2APIC mode
When VMX is used with flexpriority disabled (because of no support or
if disabled with module parameter) MMIO interface to lAPIC is still
available in x2APIC mode while it shouldn't be (kvm-unit-tests):
PASS: apic_disable: Local apic enabled in x2APIC mode
PASS: apic_disable: CPUID.1H:EDX.APIC[bit 9] is set
FAIL: apic_disable: *0xfee00030: 50014
The issue appears because we basically do nothing while switching to
x2APIC mode when APIC access page is not used. apic_mmio_{read,write}
only check if lAPIC is disabled before proceeding to actual write.
When APIC access is virtualized we correctly manipulate with VMX controls
in vmx_set_virtual_apic_mode() and we don't get vmexits from memory writes
in x2APIC mode so there's no issue.
Disabling MMIO interface seems to be easy. The question is: what do we
do with these reads and writes? If we add apic_x2apic_mode() check to
apic_mmio_in_range() and return -EOPNOTSUPP these reads and writes will
go to userspace. When lAPIC is in kernel, Qemu uses this interface to
inject MSIs only (see kvm_apic_mem_write() in hw/i386/kvm/apic.c). This
somehow works with disabled lAPIC but when we're in xAPIC mode we will
get a real injected MSI from every write to lAPIC. Not good.
The simplest solution seems to be to just ignore writes to the region
and return ~0 for all reads when we're in x2APIC mode. This is what this
patch does. However, this approach is inconsistent with what currently
happens when flexpriority is enabled: we allocate APIC access page and
create KVM memory region so in x2APIC modes all reads and writes go to
this pre-allocated page which is, btw, the same for all vCPUs.
Signed-off-by: Vitaly Kuznetsov
---
Changes since RFC:
- add KVM_X86_QUIRK_LAPIC_MMIO_HOLE disabling the newly introduced
'MMIO hole' behavior [Paolo Bonzini]
---
arch/x86/include/uapi/asm/kvm.h | 1 +
arch/x86/kvm/lapic.c| 22 +++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 86299efa804a..fd23d5778ea1 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -377,6 +377,7 @@ struct kvm_sync_regs {
#define KVM_X86_QUIRK_LINT0_REENABLED (1 << 0)
#define KVM_X86_QUIRK_CD_NW_CLEARED(1 << 1)
+#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE (1 << 2)
#define KVM_STATE_NESTED_GUEST_MODE0x0001
#define KVM_STATE_NESTED_RUN_PENDING 0x0002
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index b5cd8465d44f..83c4e8cc7eb9 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1291,9 +1291,8 @@ EXPORT_SYMBOL_GPL(kvm_lapic_reg_read);
static int apic_mmio_in_range(struct kvm_lapic *apic, gpa_t addr)
{
- return kvm_apic_hw_enabled(apic) &&
- addr >= apic->base_address &&
- addr < apic->base_address + LAPIC_MMIO_LENGTH;
+ return addr >= apic->base_address &&
+ addr < apic->base_address + LAPIC_MMIO_LENGTH;
}
static int apic_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
@@ -1305,6 +1304,15 @@ static int apic_mmio_read(struct kvm_vcpu *vcpu, struct
kvm_io_device *this,
if (!apic_mmio_in_range(apic, address))
return -EOPNOTSUPP;
+ if (!kvm_apic_hw_enabled(apic) || apic_x2apic_mode(apic)) {
+ if (!kvm_check_has_quirk(vcpu->kvm,
+KVM_X86_QUIRK_LAPIC_MMIO_HOLE))
+ return -EOPNOTSUPP;
+
+ memset(data, 0xff, len);
+ return 0;
+ }
+
kvm_lapic_reg_read(apic, offset, len, data);
return 0;
@@ -1864,6 +1872,14 @@ static int apic_mmio_write(struct kvm_vcpu *vcpu, struct
kvm_io_device *this,
if (!apic_mmio_in_range(apic, address))
return -EOPNOTSUPP;
+ if (!kvm_apic_hw_enabled(apic) || apic_x2apic_mode(apic)) {
+ if (!kvm_check_has_quirk(vcpu->kvm,
+KVM_X86_QUIRK_LAPIC_MMIO_HOLE))
+ return -EOPNOTSUPP;
+
+ return 0;
+ }
+
/*
* APIC register must be aligned on 128-bits boundary.
* 32/64/128 bits registers must be accessed thru 32 bits.
--
2.14.4
Re: Can we fix samples/ dependency on headers please?
Hi. 2018-08-01 22:58 GMT+09:00 David Howells : > Hi, > > I'm currently having to mark various userspace programs I've added to the > samples/ directory as BROKEN in samples/Kconfig because the root Makefile > mucks up the dependencies between building samples and headers_install. > > The main culprit seems to be: > > commit dd92478a15fa3bfd746ee08b4ef59401c1537804 > Author: Nicolas Pitre > Date: Sun Feb 28 22:00:00 2016 -0500 > kbuild: build sample modules along with the rest of the kernel > > which make the samples build in parallel with the build, thereby voiding the > explicit dependency: > > Documentation/ samples/: headers_install > > and thereby breaking: > > commit ddea05fa148b4d8e66498e522a616d87f9cf81e3 > Author: Arnd Bergmann > Date: Mon Jul 4 16:39:35 2016 +0200 > kbuild: make samples depend on headers_install > > The obvious fix is to revert commit dd92478a15fa3bfd746ee08b4ef59401c1537804 > (see attached patch). > > David > --- > commit 5c186b58db93e2644012e2fcb4c6ca2e74c6754b > Author: David Howells > Date: Wed Aug 1 14:48:22 2018 +0100 > > Revert "kbuild: build sample modules along with the rest of the kernel" > > This reverts commit dd92478a15fa3bfd746ee08b4ef59401c1537804. > > The problem with this commit is that some of the samples require the > header > installation to occur first, but building them in parallel with the rest > of > the build breaks that requirement. > > Signed-off-by: David Howells > > diff --git a/Makefile b/Makefile > index ca2af1ab91eb..30fc0a37ad41 100644 > --- a/Makefile > +++ b/Makefile > @@ -1009,16 +1009,14 @@ vmlinux: scripts/link-vmlinux.sh autoksyms_recursive > $(vmlinux-deps) FORCE > ifdef CONFIG_HEADERS_CHECK > $(Q)$(MAKE) -f $(srctree)/Makefile headers_check > endif > +ifdef CONFIG_SAMPLES > + $(Q)$(MAKE) $(build)=samples > +endif > ifdef CONFIG_GDB_SCRIPTS > $(Q)ln -fsn $(abspath $(srctree)/scripts/gdb/vmlinux-gdb.py) > endif > +$(call if_changed,link-vmlinux) > > -# Build samples along the rest of the kernel > -ifdef CONFIG_SAMPLES > -vmlinux-dirs += samples > -endif > - > # The actual objects are generated when descending, > # make sure no implicit rule kicks in > $(sort $(vmlinux-deps)): $(vmlinux-dirs) ; > -- I dot not understand why this would fix your problem. Does the combination of CONFIG_SAMPLES=y and CONFIG_HEADERS_CHECK=n still fail to build? If you need to install headers before building samples, this should work: diff --git a/Makefile b/Makefile index b47af5a..555ee84 100644 --- a/Makefile +++ b/Makefile @@ -1023,6 +1023,7 @@ endif # Build samples along the rest of the kernel ifdef CONFIG_SAMPLES vmlinux-dirs += samples +samples: headers_install endif # The actual objects are generated when descending, Please note Arnd's patch only works for single targets. 'samples/' and 'samples' are different targets. -- Best Regards Masahiro Yamada
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thu, 2 Aug 2018 at 16:14, Quentin Perret wrote:
>
> On Thursday 02 Aug 2018 at 15:48:01 (+0200), Vincent Guittot wrote:
> > On Thu, 2 Aug 2018 at 15:19, Quentin Perret wrote:
> > >
> > > On Thursday 02 Aug 2018 at 15:08:01 (+0200), Peter Zijlstra wrote:
> > > > On Thu, Aug 02, 2018 at 02:03:38PM +0100, Quentin Perret wrote:
> > > > > On Thursday 02 Aug 2018 at 14:26:29 (+0200), Peter Zijlstra wrote:
> > > > > > On Tue, Jul 24, 2018 at 01:25:16PM +0100, Quentin Perret wrote:
> > > > > > > @@ -5100,8 +5118,17 @@ enqueue_task_fair(struct rq *rq, struct
> > > > > > > task_struct *p, int flags)
> > > > > > > update_cfs_group(se);
> > > > > > > }
> > > > > > >
> > > > > > > - if (!se)
> > > > > > > + if (!se) {
> > > > > > > add_nr_running(rq, 1);
> > > > > > > + /*
> > > > > > > +* The utilization of a new task is 'wrong' so
> > > > > > > wait for it
> > > > > > > +* to build some utilization history before
> > > > > > > trying to detect
> > > > > > > +* the overutilized flag.
> > > > > > > +*/
> > > > > > > + if (flags & ENQUEUE_WAKEUP)
> > > > > > > + update_overutilized_status(rq);
> > > > > > > +
> > > > > > > + }
> > > > > > >
> > > > > > > hrtick_update(rq);
> > > > > > > }
> > > > > >
> > > > > > That is a somewhat dodgy hack. There is no guarantee what so ever
> > > > > > that
> > > > > > when the task wakes next its history is any better. The comment
> > > > > > doesn't
> > > > > > reflect this I feel.
> > > > >
> > > > > AFAICT the main use-case here is to avoid re-enabling the load balance
> > > > > and ruining all the task placement because of a tiny task. I don't
> > > > > really see how we can do that differently ...
> > > >
> > > > Sure I realize that.. but it doesn't completely avoid it. Suppose this
> > > > new task instantly blocks and wakes up again. Then its util signal will
> > > > be exactly what you didn't want but we'll account it and cause the above
> > > > scenario you wanted to avoid.
> > >
> > > That is true. ... I also realize now that this patch was written long
> > > before util_est, and that also has an impact here, especially in the
> > > scenario you described where the task blocks. So any wake-up after the
> > > first enqueue will risk to overutilize the system, even if the task
> > > blocked for ages.
> > >
> > > Hmm ...
> >
> > Does a init value set to 0 for util_avg for newly created task can
> > help in EAS in this case ?
> > Current initial value is computed to prevent packing newly created
> > tasks on same CPUs because it hurts performance of some benches. In
> > fact it somehow assumes that newly created task will use significant
> > part of the remaining capacity of a CPU and want to spread tasks. In
> > EAS case, it seems that it prefer to assume that newly created task
> > are small and we can pack them and wait a bit to make sure the new
> > task will be a big task and will overload the CPU
>
> Good point, setting the util_avg to 0 for new tasks should help
> filtering out those tiny tasks too. And that would match with the idea
> of letting tasks build their history before looking at their util_avg ...
>
> But there is one difference w.r.t frequency selection. The current code
> won't mark the system overutilized, but will let sugov raise the
> frequency when a new task is enqueued. So in case of a fork bomb, we
If the initial value of util_avg is 0, we should not have any impact
on the util_avg of the cfs rq on which the task is attached, isn't it
? so this should not impact both the over utilization state and the
frequency selected by sugov or I'm missing something ?
Then, select_task_rq_fair is called for a new task but util_avg is
still 0 at that time in the current code so you will have consistent
util_avg of the new task before and after calling
find_energy_efficient_cpu
> sort of fallback on the existing mainline strategy for both task
> placement (because forkees don't go in find_energy_efficient_cpu) and
> frequency selection. And I would argue this is the right thing to do
> since EAS can't really help in this case.
>
> Thoughts ?
>
> Thanks,
> Quentin
Re: [PATCHv4 01/12] sched: Add static_key for asymmetric cpu capacity optimizations
On Tue, Jul 31, 2018 at 12:59:16PM +0200, Peter Zijlstra wrote: > > Combined with that SD_ASYM.. rework I ended up with the below. > > Holler if you want it changed :-) Looks good to me. Thanks, Morten
[PATCH] reiserfs: fix broken xattr handling (heap corruption, bad retval)
This fixes the following issues:
- When a buffer size is supplied to reiserfs_listxattr() such that each
individual name fits, but the concatenation of all names doesn't
fit, reiserfs_listxattr() overflows the supplied buffer. This leads to
a kernel heap overflow (verified using KASAN) followed by an
out-of-bounds usercopy and is therefore a security bug.
- When a buffer size is supplied to reiserfs_listxattr() such that a name
doesn't fit, -ERANGE should be returned. But reiserfs instead just
truncates the list of names; I have verified that if the only xattr on
a file has a longer name than the supplied buffer length, listxattr()
incorrectly returns zero.
With my patch applied, -ERANGE is returned in both cases and the memory
corruption doesn't happen anymore.
Credit for making me clean this code up a bit goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Triggering the bug:
root@debian:/home/user# mount -o user_xattr reiserimg reisermount/
root@debian:/home/user# cd reisermount/
root@debian:/home/user/reisermount# touch test_file
root@debian:/home/user/reisermount# setfattr -n user.foo1 -v A test_file
root@debian:/home/user/reisermount# setfattr -n user.foo2 -v A test_file
root@debian:/home/user/reisermount# setfattr -n user.foo3 -v A test_file
root@debian:/home/user/reisermount# setfattr -n user.foo4 -v A test_file
root@debian:/home/user/reisermount# setfattr -n user.foo5 -v A test_file
root@debian:/home/user/reisermount# setfattr -n user.foo6 -v A test_file
root@debian:/home/user/reisermount# cat xattr_test.c
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
if (argc != 2) errx(1, "bad invocation");
char list[10];
int res = listxattr(argv[1], list, sizeof(list));
if (res == -1)
err(1, "listxattr failed");
printf("listxattr returned %d\n", res);
for (char *p = list; p < list+res-1; p = p + strlen(p) + 1) {
printf("list entry: %s\n", p);
}
}
root@debian:/home/user/reisermount# gcc -o xattr_test xattr_test.c
root@debian:/home/user/reisermount# ./xattr_test test_file
Segmentation fault
root@debian:/home/user/reisermount#
Result:
[ 122.071318]
==
[ 122.072334] BUG: KASAN: slab-out-of-bounds in listxattr_filler+0x170/0x1b0
[ 122.073173] Write of size 9 at addr 8801c43b474a by task xattr_test/923
[ 122.074030]
[ 122.074223] CPU: 1 PID: 923 Comm: xattr_test Not tainted 4.18.0-rc7+ #67
[ 122.075050] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 122.076107] Call Trace:
[ 122.076453] dump_stack+0x71/0xab
[ 122.076900] print_address_description+0x6a/0x250
[ 122.077514] kasan_report+0x258/0x380
[ 122.077961] ? listxattr_filler+0x170/0x1b0
[ 122.078469] memcpy+0x34/0x50
[ 122.078894] listxattr_filler+0x170/0x1b0
[...]
fs/reiserfs/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/reiserfs/xattr.c b/fs/reiserfs/xattr.c
index ff94fad477e4..48cdfc81fe10 100644
--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -792,8 +792,10 @@ static int listxattr_filler(struct dir_context *ctx, const
char *name,
return 0;
size = namelen + 1;
if (b->buf) {
- if (size > b->size)
+ if (b->pos + size > b->size) {
+ b->pos = -ERANGE;
return -ERANGE;
+ }
memcpy(b->buf + b->pos, name, namelen);
b->buf[b->pos + namelen] = 0;
}
--
2.18.0.597.ga71716f1ad-goog
LVM snapshot broke between 4.14 and 4.16
On 08/02/2018 04:31 PM, Ilya Dryomov wrote: > On Thu, Aug 2, 2018 at 2:26 PM WGH wrote: >> (I originally reported this problem here: >> https://bugzilla.kernel.org/show_bug.cgi?id=200439) >> >> When I updated from 4.14 to 4.16, my LVM snapshotting script broke for >> no apparent reason. >> >> My script has the following line, and it fails like this: >> + lvcreate --size 5G --snapshot --name snap0 --permission r >> /dev/mapper/vg0-lvol_rootfs >> device-mapper: create ioctl on >> vg0-snap0-cowLVM-sDdIeh9cecWdaNyRfZC31mxgfwTa4sOeHMJXVOykGVRtfP6Aii7IHvwS066AOLOM-cow >> failed: Device or resource busy >> Failed to lock logical volume vg0/lvol_rootfs. >> Aborting. Manual intervention required. >> >> At the same time, some errors appear in dmesg as well: >> [ 26.145279] generic_make_request: Trying to write to read-only >> block-device dm-3 (partno 0) >> [ 26.145288] device-mapper: persistent snapshot: write_header failed >> [ 26.145847] device-mapper: table: 253:4: snapshot: Failed to read >> snapshot metadata >> [ 26.145851] device-mapper: ioctl: error adding target to table >> >> I bisected the vanilla kernel, and the first bad commit is >> [721c7fc701c71f693307d274d2b346a1ecd4a534] block: fail op_is_write() >> requests to read-only partitions > Adding Mike and dm-devel. > > From a quick look, --permission r sets DM_READONLY_FLAG, which makes dm > mark the disk read-only with set_disk_ro(dm_disk(md), 1) in do_resume(). > A bit later it tries to write to the disk from write_header(): > > return chunk_io(ps, ps->header_area, 0, REQ_OP_WRITE, 0, 1); > > Thanks, > > Ilya After further investigation, this was fixed on lvm2 side (userspace) in https://sourceware.org/git/?p=lvm2.git;a=commit;h=a6fdb9d9d70f51c49ad11a87ab4243344e6701a3 (snapshot: keep COW writable for read-only volumes). So I guess that's it. Time to poke my distribution package maintainers to bump the package version.
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Thursday 02 Aug 2018 at 14:45:11 (+0200), Peter Zijlstra wrote: > On Thu, Aug 02, 2018 at 02:33:15PM +0200, Peter Zijlstra wrote: > > On Mon, Jul 30, 2018 at 12:35:27PM -0700, skan...@codeaurora.org wrote: > > > On 2018-07-24 05:25, Quentin Perret wrote: > > > If it's going to be a different aggregation from what's done for frequency > > > guidance, I don't see the point of having this inside schedutil. Why not > > > keep it inside the scheduler files? Also, it seems weird to use a > > > governor's > > > code when it might not actually be in use. What if someone is using > > > ondemand, conservative, performance, etc? > > > > EAS hard relies on schedutil -- I suppose we need a check for that > > somewhere and maybe some infrastructure to pin the cpufreq governor. > > Either that or disable EAS when another governor is selected. > > > We're simply not going to support it for anything else. > > To clarify, it makes absolutely no sense what so ever to attempt EAS > when the DVFS control is not coordinated. I tend to agree with that, but at the same time even if we create a very strong dependency on schedutil, we will have no guarantee that the actual frequencies used on the platform are the ones we predicted in EAS. There are a number of reasons why a frequency request might not be served (throttling, thermal capping, something HW-related, ...), so it's hard to enforce the EAS model in practice. The way I see things, EAS needs to assume that OPPs follow utilization. Sugov does something that looks like that too, and it's also in the scheduler, so that makes sense to try and factorize things, especially for maintenance purpose. But I feel like the correlation between the two could stop here. If you use some sort HW governor that tries to always have some idle time on the CPUs, then the assumption that OPPs follow utilization isn't _totally_ wrong. There should be a (loose) relation between what EAS 'thinks' and the reality. And if this isn't true, then you might make slightly sub-optimal decisions, but I'm not sure if there is anything we can do about it :/ The scheduler works with various models which, by definition, don't always perfectly reflect the reality. But those models are useful because they enable us to reason about things and make decisions. EAS uses a model where OPPs follow utilization. I think it's just another model to the list, and we can't really enforce it strictly in practice anyway, so we will have to live with its inaccuracies I suppose ... I hope that makes sense :-) Thanks, Quentin
[PATCH v2] RISC-V: Add the directive for alignment of stvec's value
The stvec's value must be 4 byte alignment by specification definition. These directives avoid to stvec be set the non-alignment value. Signed-off-by: Zong Li --- arch/riscv/kernel/head.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S index 3b6293f..11066d5 100644 --- a/arch/riscv/kernel/head.S +++ b/arch/riscv/kernel/head.S @@ -94,6 +94,7 @@ relocate: or a0, a0, a1 sfence.vma csrw sptbr, a0 +.align 2 1: /* Set trap vector to spin forever to help debug */ la a0, .Lsecondary_park @@ -143,6 +144,7 @@ relocate: tail smp_callin #endif +.align 2 .Lsecondary_park: /* We lack SMP support or have too many harts, so park this hart */ wfi -- 2.7.4
[PATCH] RISC-V: Add preprocessor directives for boot_sec_cpu
The boot_sec_cpu is for hutplug CPU on SMP system. It should be conditional compiling. Otherwise, it causes undefined reference to `smp_callin' when compiling uniprocessor kernel. Signed-off-by: Zong Li --- arch/riscv/kernel/head.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S index 11066d5..9b6f601 100644 --- a/arch/riscv/kernel/head.S +++ b/arch/riscv/kernel/head.S @@ -154,6 +154,7 @@ END(_start) .section .text .global boot_sec_cpu +#ifdef CONFIG_HOTPLUG_CPU boot_sec_cpu: /* clear all pending flags */ csrw sip, zero @@ -162,6 +163,7 @@ boot_sec_cpu: fence tail smp_callin +#endif __PAGE_ALIGNED_BSS /* Empty zero page */ -- 2.7.4
Re: ovl: hash non-dir by lower inode for fsnotify
On 08/01/2018 11:05 PM, Greg KH wrote:
On Wed, Aug 01, 2018 at 02:29:01PM -0700, Mark Salyzyn wrote:
764baba80168ad3adafb521d2ab483ccbc49e344 ovl: hash non-dir by lower inode
for fsnotify is not part of 4.14 stable and yet it was marked for 4.13
stable merge when committed.
Please evaluate.
Why not try applying it yourself to 4.14.y and note that it does not
apply at all and then provide a working backport so that we can skip at
least one email cycle here? :)
thanks,
greg k-h
Because I am embarrassed by the backport (!) perhaps? :-)
+linux-kernel list and authors/approvers for clearance.
I took some liberty with sb = dentry_d_sb and then sprinkled it in,
upstream passes sb to the function and the conflicts assumed so.
--> snip <-
From 764baba80168ad3adafb521d2ab483ccbc49e344 Mon Sep 17 00:00:00 2001
From: Amir Goldstein
Date: Sun, 4 Feb 2018 15:35:09 +0200
Subject: ovl: hash non-dir by lower inode for fsnotify
(cherry pick from commit 764baba80168ad3adafb521d2ab483ccbc49e344)
Commit 31747eda41ef ("ovl: hash directory inodes for fsnotify")
fixed an issue of inotify watch on directory that stops getting
events after dropping dentry caches.
A similar issue exists for non-dir non-upper files, for example:
$ mkdir -p lower upper work merged
$ touch lower/foo
$ mount -t overlay -o
lowerdir=lower,workdir=work,upperdir=upper none merged
$ inotifywait merged/foo &
$ echo 2 > /proc/sys/vm/drop_caches
$ cat merged/foo
inotifywait doesn't get the OPEN event, because ovl_lookup() called
from 'cat' allocates a new overlay inode and does not reuse the
watched inode.
Fix this by hashing non-dir overlay inodes by lower real inode in
the following cases that were not hashed before this change:
- A non-upper overlay mount
- A lower non-hardlink when index=off
A helper ovl_hash_bylower() was added to put all the logic and
documentation about which real inode an overlay inode is hashed by
into one place.
The issue dates back to initial version of overlayfs, but this
patch depends on ovl_inode code that was introduced in kernel v4.13.
Signed-off-by: Amir Goldstein
Signed-off-by: Miklos Szeredi
Cc: #v4.13
Signed-off-by: Mark Salyzyn #v4.14
---
fs/overlayfs/inode.c | 62 +++-
1 file changed, 44 insertions(+), 18 deletions(-)
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index 28a320464609a..7cfef4152e9a4 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -14,6 +14,7 @@
#include
#include
#include "overlayfs.h"
+#include "ovl_entry.h"
int ovl_setattr(struct dentry *dentry, struct iattr *attr)
{
@@ -608,39 +609,63 @@ static bool ovl_verify_inode(struct inode *inode,
struct dentry *lowerdentry,
return true;
}
+/*
+ * Does overlay inode need to be hashed by lower inode?
+ */
+static bool ovl_hash_bylower(struct super_block *sb, struct dentry *upper,
+ struct dentry *lower, struct dentry *index)
+{
+ struct ovl_fs *ofs = sb->s_fs_info;
+
+ /* No, if pure upper */
+ if (!lower)
+ return false;
+
+ /* Yes, if already indexed */
+ if (index)
+ return true;
+
+ /* Yes, if won't be copied up */
+ if (!ofs->upper_mnt)
+ return true;
+
+ /* No, if lower hardlink is or will be broken on copy up */
+ if ((upper || !ovl_indexdir(sb)) &&
+ !d_is_dir(lower) && d_inode(lower)->i_nlink > 1)
+ return false;
+
+ /* No, if non-indexed upper with NFS export */
+ if (sb->s_export_op && upper)
+ return false;
+
+ /* Otherwise, hash by lower inode for fsnotify */
+ return true;
+}
+
struct inode *ovl_get_inode(struct dentry *dentry, struct dentry
*upperdentry,
struct dentry *index)
{
+ struct super_block *sb = dentry->d_sb;
struct dentry *lowerdentry = ovl_dentry_lower(dentry);
struct inode *realinode = upperdentry ? d_inode(upperdentry) : NULL;
struct inode *inode;
- /* Already indexed or could be indexed on copy up? */
- bool indexed = (index || (ovl_indexdir(dentry->d_sb) && !upperdentry));
- struct dentry *origin = indexed ? lowerdentry : NULL;
+ bool bylower = ovl_hash_bylower(sb, upperdentry, lowerdentry, index);
bool is_dir;
- if (WARN_ON(upperdentry && indexed && !lowerdentry))
- return ERR_PTR(-EIO);
-
if (!realinode)
realinode = d_inode(lowerdentry);
/*
- * Copy up origin (lower) may exist for non-indexed non-dir upper, but
- * we must not use lower as hash key in that case.
- * Hash non-dir that is or could be indexed by origin inode.
- * Hash dir that is or could be merged by origin inode.
- * Hash pure upper and non-indexed non-dir by upper inode.
+ * Copy up origin (lower) may exist for non-indexed upper, but we must
+ * not use lower as hash key if this is a broken hardlink.
*/
is_dir = S_ISDIR(realinode->i_mode);
- if (is_dir)
- origin = lowerdentry;
-
Re: [PATCH v12 1/7] dt-bindings: net: bluetooth: Add device tree bindings for QTI chip wcn3990
Quoting Balakrishna Godavarthi (2018-08-02 06:25:12) > This patch enables regulators for the Qualcomm Bluetooth wcn3990 > controller. > > Signed-off-by: Balakrishna Godavarthi > Reviewed-by: Rob Herring > --- Reviewed-by: Stephen Boyd
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > On Thu, 2 Aug 2018 at 16:14, Quentin Perret wrote: > > Good point, setting the util_avg to 0 for new tasks should help > > filtering out those tiny tasks too. And that would match with the idea > > of letting tasks build their history before looking at their util_avg ... > > > > But there is one difference w.r.t frequency selection. The current code > > won't mark the system overutilized, but will let sugov raise the > > frequency when a new task is enqueued. So in case of a fork bomb, we > > If the initial value of util_avg is 0, we should not have any impact > on the util_avg of the cfs rq on which the task is attached, isn't it > ? so this should not impact both the over utilization state and the > frequency selected by sugov or I'm missing something ? What I tried to say is that setting util_avg to 0 for new tasks will prevent schedutil from raising the frequency in case of a fork bomb, and I think that could be an issue. And I think this isn't an issue with the patch as-is ... Sorry if that wasn't clear > Then, select_task_rq_fair is called for a new task but util_avg is > still 0 at that time in the current code so you will have consistent > util_avg of the new task before and after calling > find_energy_efficient_cpu New tasks don't go in find_energy_efficient_cpu(), because, as you said, they have no consistent util_avg yet when select_task_rq_fair() is called for the first time. Thanks, Quentin
Re: [TRIVIAL RFC PATCH] Kconfigs - reduce use of "depends on EXPERT"
2018-07-29 7:13 GMT+09:00 Joe Perches : > Most uses of EXPERT are in the form > > bool "something" if EXPERT > > but some are > > depends on EXPERT > > The difference is the the 'depends on' use makes it > easier to select the CONFIG_EXPERT option. I could not understand why 'if EXPERT' is preferred to 'depends on EXPERT' 'depends on EXPERT' hides the symbol. ' if EXPERT' keeps the symbol visible, but forbid users from changing the value. Both have appropriate usage. > $ git grep "if EXPERT" -- "*/Kconfig*" | wc -l > 155 > $ git grep "depends on.*EXPERT" -- "*/Kconfig*" | wc -l > 26 > > Some of the 'depends on' uses with EXPERT are more menus > or complex logic with || and can not easily be modified, > but it's perhaps reasonable to modify the simpler ones > to the "if EXPERT" form. > --- > arch/x86/Kconfig.debug | 3 +-- > drivers/char/Kconfig | 4 ++-- > drivers/gpu/drm/i915/Kconfig.debug | 3 +-- > drivers/gpu/drm/msm/Kconfig| 4 ++-- > drivers/net/wireless/intel/iwlwifi/Kconfig | 4 ++-- > drivers/ssb/Kconfig| 4 ++-- > drivers/video/fbdev/Kconfig| 4 ++-- > init/Kconfig | 10 -- > kernel/power/Kconfig | 7 +++ > net/wireless/Kconfig | 3 +-- > security/Kconfig | 3 +-- > 11 files changed, 21 insertions(+), 28 deletions(-) > > diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug > index c6dd1d980081..f175c00c3786 100644 > --- a/arch/x86/Kconfig.debug > +++ b/arch/x86/Kconfig.debug > @@ -393,8 +393,7 @@ config UNWINDER_FRAME_POINTER > reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE). > > config UNWINDER_GUESS > - bool "Guess unwinder" > - depends on EXPERT > + bool "Guess unwinder" if EXPERT > depends on !STACKDEPOT > ---help--- > This option enables the "guess" unwinder for unwinding kernel stack > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig > index ce277ee0a28a..c1c231a32521 100644 > --- a/drivers/char/Kconfig > +++ b/drivers/char/Kconfig > @@ -52,8 +52,8 @@ source "drivers/tty/serial/Kconfig" > source "drivers/tty/serdev/Kconfig" > > config TTY_PRINTK > - tristate "TTY driver to output user messages via printk" > - depends on EXPERT && TTY > + tristate "TTY driver to output user messages via printk" if EXPERT > + depends on TTY > default n > ---help--- > If you say Y here, the support for writing user messages (i.e. > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 459f8f88a34c..cbf61c0d3917 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -1,8 +1,7 @@ > config DRM_I915_WERROR > -bool "Force GCC to throw an error instead of a warning when > compiling" > +bool "Force GCC to throw an error instead of a warning when > compiling" if EXPERT > # As this may inadvertently break the build, only allow the user > # to shoot oneself in the foot iff they aim really hard > -depends on EXPERT > # We use the dependency on !COMPILE_TEST to not be enabled in > # allmodconfig or allyesconfig configurations > depends on !COMPILE_TEST > diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig > index 843a9d40c05e..4fe57693005f 100644 > --- a/drivers/gpu/drm/msm/Kconfig > +++ b/drivers/gpu/drm/msm/Kconfig > @@ -30,8 +30,8 @@ config DRM_MSM_REGISTER_LOGGING > logging can be switched on via msm.reglog=y module param. > > config DRM_MSM_GPU_SUDO > - bool "Enable SUDO flag on submits" > - depends on DRM_MSM && EXPERT > + bool "Enable SUDO flag on submits" if EXPERT > + depends on DRM_MSM > default n > help > Enable userspace that has CAP_SYS_RAWIO to submit GPU commands > diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig > b/drivers/net/wireless/intel/iwlwifi/Kconfig > index e5a2fc738ac3..d82d0bdd837e 100644 > --- a/drivers/net/wireless/intel/iwlwifi/Kconfig > +++ b/drivers/net/wireless/intel/iwlwifi/Kconfig > @@ -89,8 +89,8 @@ config IWLWIFI_BCAST_FILTERING > expect incoming broadcasts for their normal operations. > > config IWLWIFI_PCIE_RTPM > - bool "Enable runtime power management mode for PCIe devices" > - depends on IWLMVM && PM && EXPERT > + bool "Enable runtime power management mode for PCIe devices" if EXPERT > + depends on IWLMVM && PM > help > Say Y here to enable runtime power management for PCIe > devices. If enabled, the device will go into low power mode > diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig > index c574dd210500..e6036784c260 100644 > --- a/drivers/ssb/Kconfig > +++ b/drivers/ssb/Kconfig > @@ -90,8 +
[PATCH] lib/ubsan: remove null-pointer checks.
With gcc-8 fsanitize=null become very noisy. GCC started to complain about things like &a->b, where 'a' is NULL pointer. There is no NULL dereference, we just calculate address to struct member. It's technically undefined behavior so UBSAN is correct to report it. But as long as there is no real NULL-dereference, I think, we should be fine. -fno-delete-null-pointer-checks compiler flag should protect us from any consequences. So let's just no use -fsanitize=null as it's not useful for us. If there is a real NULL-deref we will see crash. Even if userspace mapped something at NULL (root can do this), with things like SMAP should catch the issue. Signed-off-by: Andrey Ryabinin --- arch/parisc/Kconfig| 1 - arch/s390/Kconfig | 1 - lib/Kconfig.ubsan | 11 --- scripts/Makefile.ubsan | 4 4 files changed, 17 deletions(-) diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index c11d9939c1db..e21751fb24aa 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -11,7 +11,6 @@ config PARISC select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_UBSAN_SANITIZE_ALL - select ARCH_WANTS_UBSAN_NO_NULL select ARCH_SUPPORTS_MEMORY_FAILURE select RTC_CLASS select RTC_DRV_GENERIC diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 184ea341437b..515240576930 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -106,7 +106,6 @@ config S390 select ARCH_USE_BUILTIN_BSWAP select ARCH_USE_CMPXCHG_LOCKREF select ARCH_WANTS_DYNAMIC_TASK_STRUCT - select ARCH_WANTS_UBSAN_NO_NULL select ARCH_WANT_IPC_PARSE_VERSION select BUILDTIME_EXTABLE_SORT select CLONE_BACKWARDS2 diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan index 19d42ea75ec2..98fa559ebd80 100644 --- a/lib/Kconfig.ubsan +++ b/lib/Kconfig.ubsan @@ -1,9 +1,6 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL bool -config ARCH_WANTS_UBSAN_NO_NULL - def_bool n - config UBSAN bool "Undefined behaviour sanity checker" help @@ -39,14 +36,6 @@ config UBSAN_ALIGNMENT Enabling this option on architectures that support unaligned accesses may produce a lot of false positives. -config UBSAN_NULL - bool "Enable checking of null pointers" - depends on UBSAN - default y if !ARCH_WANTS_UBSAN_NO_NULL - help - This option enables detection of memory accesses via a - null pointer. - config TEST_UBSAN tristate "Module for testing for undefined behavior detection" depends on m && UBSAN diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan index b593b36ccff8..38b2b4818e8e 100644 --- a/scripts/Makefile.ubsan +++ b/scripts/Makefile.ubsan @@ -14,10 +14,6 @@ ifdef CONFIG_UBSAN_ALIGNMENT CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment) endif -ifdef CONFIG_UBSAN_NULL - CFLAGS_UBSAN += $(call cc-option, -fsanitize=null) -endif - # -fsanitize=* options makes GCC less smart than usual and # increase number of 'maybe-uninitialized false-positives CFLAGS_UBSAN += $(call cc-option, -Wno-maybe-uninitialized) -- 2.16.4
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Thursday 02 Aug 2018 at 15:04:40 (+0200), Peter Zijlstra wrote: > On Wed, Aug 01, 2018 at 10:23:27AM +0100, Quentin Perret wrote: > > On Wednesday 01 Aug 2018 at 10:35:32 (+0200), Rafael J. Wysocki wrote: > > > On Wed, Aug 1, 2018 at 10:23 AM, Quentin Perret > > > wrote: > > > > On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote: > > > >> On Tue, Jul 31, 2018 at 9:31 PM, wrote: > > > >> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org > > > >> >> wrote: > > > >> >>> If it's going to be a different aggregation from what's done for > > > >> >>> frequency > > > >> >>> guidance, I don't see the point of having this inside schedutil. > > > >> >>> Why not > > > >> >>> keep it inside the scheduler files? > > > >> >> > > > >> >> This code basically results from a discussion we had with Peter on > > > >> >> v4. > > > >> >> Keeping everything centralized can make sense from a maintenance > > > >> >> perspective, I think. That makes it easy to see the impact of any > > > >> >> change > > > >> >> to utilization signals for both EAS and schedutil. > > > >> > > > > >> > In that case, I'd argue it makes more sense to keep the code > > > >> > centralized in > > > >> > the scheduler. The scheduler can let schedutil know about the > > > >> > utilization > > > >> > after it aggregates them. There's no need for a cpufreq governor to > > > >> > know > > > >> > that there are scheduling classes or how many there are. And the > > > >> > scheduler > > > >> > can then choose to aggregate one way for task packing and another > > > >> > way for > > > >> > frequency guidance. > > > >> > > > >> Also the aggregate utilization may be used by cpuidle governors in > > > >> principle to decide how deep they can go with idle state selection. > > > > > > > > The only issue I see with this right now is that some of the things done > > > > in this function are policy decisions which really belong to the > > > > governor, > > > > I think. > > > > > > Well, the scheduler makes policy decisions too, in quite a few places. :-) > > > > That is true ... ;-) But not so much about frequency selection yet I guess > > Well, sugov is part of the scheduler :-) It being so allows for the > co-ordinated decision making required for EAS. > > > > The really important consideration here is whether or not there may be > > > multiple governors making different policy decisions in that respect. > > > If not, then where exactly the single policy decision is made doesn't > > > particularly matter IMO. > > > > I think some users of the aggregated utilization signal do want to make > > slightly different decisions (I'm thinking about the RT-go-to-max thing > > again which makes perfect sense in sugov, but could possibly hurt EAS). > > > > So the "hard" part of this work is to figure out what really is a > > governor-specific policy decision, and what is common between all users. > > I put "hard" between quotes because I only see the case of RT as truly > > sugov-specific for now. > > > > If we also want a special case for DL, Peter's enum should work OK, and > > enable to add more special cases for new users (cpuidle ?) if needed. > > But maybe that is something for later ? > > Right, I don't mind moving the function. What I do oppose is having two > very similar functions in different translation units -- because then > they _will_ diverge and result in 'funny' things. Sounds good :-) Would kernel/sched/pelt.c be the right place then ? It's cross-class and kinda pelt-related I guess Thanks, Quentin
Re: [PATCH 4.9 000/144] 4.9.117-stable review
On Wed, Aug 01, 2018 at 06:50:27PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.117 release. > There are 144 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Aug 3 16:49:15 UTC 2018. > Anything received after that time might be too late. > Build results: total: 148 pass: 148 fail: 0 Qemu test results: total: 190 pass: 190 fail: 0 Details are available at http://kerneltests.org/builders/. Guenter
Re: [PATCH 4.14 000/246] 4.14.60-stable review
On Wed, Aug 01, 2018 at 06:48:30PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.60 release. > There are 246 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Aug 3 16:49:18 UTC 2018. > Anything received after that time might be too late. > Build results: total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0 Details are available at http://kerneltests.org/builders/. Guenter
Re: [PATCH 4.17 000/336] 4.17.12-stable review
On Wed, Aug 01, 2018 at 06:45:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.17.12 release. > There are 336 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Aug 3 16:49:21 UTC 2018. > Anything received after that time might be too late. > Build results: total: 134 pass: 134 fail: 0 Qemu test results: total: 201 pass: 201 fail: 0 Details are available at http://kerneltests.org/builders/. Guenter
Re: [PATCH] Kbuild: Makefile.modbuiltin: include auto.conf and tristate.conf mandatory
2018-08-02 22:47 GMT+09:00 Dirk Gouders : > The files auto.conf and tristate.conf are mandatory for building > modules.builtin files, therefore include them as such. > > Usually, the top-level Makefile ensures that those files exist but we > want to make sure we get noticed if they are missing for whatever > reason. > > Signed-off-by: Dirk Gouders > --- Applied. Thanks! > scripts/Makefile.modbuiltin | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/Makefile.modbuiltin b/scripts/Makefile.modbuiltin > index 40867a41615b..a072a4267746 100644 > --- a/scripts/Makefile.modbuiltin > +++ b/scripts/Makefile.modbuiltin > @@ -8,10 +8,10 @@ src := $(obj) > PHONY := __modbuiltin > __modbuiltin: > > --include include/config/auto.conf > +include include/config/auto.conf > # tristate.conf sets tristate variables to uppercase 'Y' or 'M' > # That way, we get the list of built-in modules in obj-Y > --include include/config/tristate.conf > +include include/config/tristate.conf > > include scripts/Kbuild.include > > -- > 2.16.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Cleanup synic memory free path
> -Original Message-
> From: Dan Carpenter
> Sent: Wednesday, August 1, 2018 11:42 PM
> To: Michael Kelley (EOSG)
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; jasow...@redhat.com;
> marcelo.ce...@canonical.com; Stephen Hemminger
> ; KY Srinivasan
> Subject: Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Cleanup synic
> memory free path
>
> On Wed, Aug 01, 2018 at 03:45:13PM -0700, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > clk_evt memory is not being freed when the synic is shutdown
> > or when there is an allocation error. Add the appropriate
> > kfree() call, along with a comment to clarify how the memory
> > gets freed after an allocation error. Make the free path
> > consistent by removing checks for NULL since kfree() and
> > free_page() already do the check.
> >
> > Signed-off-by: Michael Kelley
> > Reported-by: Dan Carpenter
> > ---
> > drivers/hv/hv.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> > index 8d4fe0e..1fb9a6b 100644
> > --- a/drivers/hv/hv.c
> > +++ b/drivers/hv/hv.c
> > @@ -240,6 +240,10 @@ int hv_synic_alloc(void)
> >
> > return 0;
> > err:
> > + /*
> > +* Any memory allocations that succeeded will be freed when
> > +* the caller cleans up by calling hv_synic_free()
> > +*/
> > return -ENOMEM;
> > }
> >
> > @@ -252,12 +256,10 @@ void hv_synic_free(void)
> > for_each_present_cpu(cpu) {
> > struct hv_per_cpu_context *hv_cpu
> > = per_cpu_ptr(hv_context.cpu_context, cpu);
> >
> > - if (hv_cpu->synic_event_page)
> > - free_page((unsigned long)hv_cpu-
> >synic_event_page);
> > - if (hv_cpu->synic_message_page)
> > - free_page((unsigned long)hv_cpu-
> >synic_message_page);
> > - if (hv_cpu->post_msg_page)
> > - free_page((unsigned long)hv_cpu-
> >post_msg_page);
> > + kfree(hv_cpu->clk_evt);
> > + free_page((unsigned long)hv_cpu->synic_event_page);
> > + free_page((unsigned long)hv_cpu->synic_message_page);
> > + free_page((unsigned long)hv_cpu->post_msg_page);
>
> This looks buggy.
>
> We can pass NULLs to free_page() so that's fine. So the error handling
> assumes
> that hv_cpu->clk_evt is either NULL or allocated. Here is how it is
> allocated:
>
>189 int hv_synic_alloc(void)
>190 {
>191 int cpu;
>192
>193 hv_context.hv_numa_map = kcalloc(nr_node_ids, sizeof(struct
> cpumask),
>194 GFP_KERNEL);
>195 if (hv_context.hv_numa_map == NULL) {
>196 pr_err("Unable to allocate NUMA map\n");
>197 goto err;
>198 }
>199
>200 for_each_present_cpu(cpu) {
> ^^^
> We loop over each CPU.
>
>201 struct hv_per_cpu_context *hv_cpu
>202 = per_cpu_ptr(hv_context.cpu_context, cpu);
>203
>204 memset(hv_cpu, 0, sizeof(*hv_cpu));
> ^^
> We set this cpu memory to NULL.
>
>205 tasklet_init(&hv_cpu->msg_dpc,
>206 vmbus_on_msg_dpc, (unsigned long)
> hv_cpu);
>207
>208 hv_cpu->clk_evt = kzalloc(sizeof(struct
> clock_event_device),
>209GFP_KERNEL);
>210 if (hv_cpu->clk_evt == NULL) {
> ^^^
> Let's assume this fails on the first iteration through the loop. We
> haven't memset the next cpu to NULL or allocated it. But we loop over
> all the cpus in the error handling. Since we didn't set everything to NULL in
> hv_synic_free() then it seems like this could be a double free. It's
> possible I
> am misreading the code, but either it's buggy or the memset() can be
> removed.
>
> This is a very typical bug for this style of error handling where we free
> things which were never allocated.
Thanks Dan! We will fix this issue soon.
K. Y
>
>211 pr_err("Unable to allocate clock event
> device\n");
>212 goto err;
>213 }
>
> regards,
> dan carpenter
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thu, 2 Aug 2018 at 17:30, Quentin Perret wrote: > > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret wrote: > > > Good point, setting the util_avg to 0 for new tasks should help > > > filtering out those tiny tasks too. And that would match with the idea > > > of letting tasks build their history before looking at their util_avg ... > > > > > > But there is one difference w.r.t frequency selection. The current code > > > won't mark the system overutilized, but will let sugov raise the > > > frequency when a new task is enqueued. So in case of a fork bomb, we > > > > If the initial value of util_avg is 0, we should not have any impact > > on the util_avg of the cfs rq on which the task is attached, isn't it > > ? so this should not impact both the over utilization state and the > > frequency selected by sugov or I'm missing something ? > > What I tried to say is that setting util_avg to 0 for new tasks will > prevent schedutil from raising the frequency in case of a fork bomb, and > I think that could be an issue. And I think this isn't an issue with the > patch as-is ... ok. So you also want to deal with fork bomb Not sure that you don't have some problem with current proposal too because select_task_rq_fair will always return prev_cpu because util_avg and util_est are 0 at that time > > Sorry if that wasn't clear > > > Then, select_task_rq_fair is called for a new task but util_avg is > > still 0 at that time in the current code so you will have consistent > > util_avg of the new task before and after calling > > find_energy_efficient_cpu > > New tasks don't go in find_energy_efficient_cpu(), because, as you said, > they have no consistent util_avg yet when select_task_rq_fair() is called > for the first time. > > Thanks, > Quentin
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote: > On Thu, 2 Aug 2018 at 17:30, Quentin Perret wrote: > > > > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret > > > wrote: > > > > Good point, setting the util_avg to 0 for new tasks should help > > > > filtering out those tiny tasks too. And that would match with the idea > > > > of letting tasks build their history before looking at their util_avg > > > > ... > > > > > > > > But there is one difference w.r.t frequency selection. The current code > > > > won't mark the system overutilized, but will let sugov raise the > > > > frequency when a new task is enqueued. So in case of a fork bomb, we > > > > > > If the initial value of util_avg is 0, we should not have any impact > > > on the util_avg of the cfs rq on which the task is attached, isn't it > > > ? so this should not impact both the over utilization state and the > > > frequency selected by sugov or I'm missing something ? > > > > What I tried to say is that setting util_avg to 0 for new tasks will > > prevent schedutil from raising the frequency in case of a fork bomb, and > > I think that could be an issue. And I think this isn't an issue with the > > patch as-is ... > > ok. So you also want to deal with fork bomb > Not sure that you don't have some problem with current proposal too > because select_task_rq_fair will always return prev_cpu because > util_avg and util_est are 0 at that time But find_idlest_cpu() should select a CPU using load in case of a forkee no ? Thanks, Quentin
Re: [PATCH 3/4] aio: implement IOCB_CMD_POLL
On Thu, Aug 02, 2018 at 11:22:34AM +0200, Christoph Hellwig wrote: > Yes, I think you are right. I'll see how I could handle that case. > One of the easiest options would be to just support aio poll on > file ops that support keyed wakeups, we'd just need to pass that > information up. BTW, what happens if we insert into one queue and immediately get woken up, even before the damn thing gets to the end of ->poll(), which proceeds to call poll_wait() again (on another queue)? AFAICS, apt.error will be set by the second callback and completely ignored. And so will the return value of ->poll()... Sigh... Analysis of that thing is bloody painful, mostly because it's hard to describe the state...
Re: [PATCH 3/4] aio: implement IOCB_CMD_POLL
On Thu, Aug 02, 2018 at 05:00:32PM +0100, Al Viro wrote: > BTW, what happens if we insert into one queue and immediately get > woken up, even before the damn thing gets to the end of ->poll(), > which proceeds to call poll_wait() again (on another queue)? > AFAICS, apt.error will be set by the second callback and completely > ignored. And so will the return value of ->poll()... > > Sigh... Analysis of that thing is bloody painful, mostly because > it's hard to describe the state... That's the problem with the ->poll interface. We call it, then have magic happen underneath where it might or might not get added to one (or more if we didn't exclude that) waitqueues, and might have actually been worken before return. I can't really think of a good way to do that entirely sanely. Best I can think of is to only allow using file ops that do keyed wakeups and rely on the keyed wakeups alone. I've started coming up with a version of that, but it won't be until tomorrow at least that I can post it.
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thu, 2 Aug 2018 at 18:00, Quentin Perret wrote: > > On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote: > > On Thu, 2 Aug 2018 at 17:30, Quentin Perret wrote: > > > > > > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > > > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret > > > > wrote: > > > > > Good point, setting the util_avg to 0 for new tasks should help > > > > > filtering out those tiny tasks too. And that would match with the idea > > > > > of letting tasks build their history before looking at their util_avg > > > > > ... > > > > > > > > > > But there is one difference w.r.t frequency selection. The current > > > > > code > > > > > won't mark the system overutilized, but will let sugov raise the > > > > > frequency when a new task is enqueued. So in case of a fork bomb, we > > > > > > > > If the initial value of util_avg is 0, we should not have any impact > > > > on the util_avg of the cfs rq on which the task is attached, isn't it > > > > ? so this should not impact both the over utilization state and the > > > > frequency selected by sugov or I'm missing something ? > > > > > > What I tried to say is that setting util_avg to 0 for new tasks will > > > prevent schedutil from raising the frequency in case of a fork bomb, and > > > I think that could be an issue. And I think this isn't an issue with the > > > patch as-is ... > > > > ok. So you also want to deal with fork bomb > > Not sure that you don't have some problem with current proposal too > > because select_task_rq_fair will always return prev_cpu because > > util_avg and util_est are 0 at that time > > But find_idlest_cpu() should select a CPU using load in case of a forkee > no ? So you have to wait for the next tick that will set the overutilized and disable the want_energy. Until this point, all new tasks will be put on the current cpu > > Thanks, > Quentin
Re: [PATCH 3/4] aio: implement IOCB_CMD_POLL
On Thu, Aug 02, 2018 at 06:08:16PM +0200, Christoph Hellwig wrote: > On Thu, Aug 02, 2018 at 05:00:32PM +0100, Al Viro wrote: > > BTW, what happens if we insert into one queue and immediately get > > woken up, even before the damn thing gets to the end of ->poll(), > > which proceeds to call poll_wait() again (on another queue)? > > AFAICS, apt.error will be set by the second callback and completely > > ignored. And so will the return value of ->poll()... > > > > Sigh... Analysis of that thing is bloody painful, mostly because > > it's hard to describe the state... > > That's the problem with the ->poll interface. We call it, then > have magic happen underneath where it might or might not get added > to one (or more if we didn't exclude that) waitqueues, and might > have actually been worken before return. I can't really think of > a good way to do that entirely sanely. > > Best I can think of is to only allow using file ops that do keyed > wakeups and rely on the keyed wakeups alone. I've started coming > up with a version of that, but it won't be until tomorrow at least > that I can post it. What does it buy you? You still have to deal with trylock failures in wakeup...
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thursday 02 Aug 2018 at 18:07:49 (+0200), Vincent Guittot wrote: > On Thu, 2 Aug 2018 at 18:00, Quentin Perret wrote: > > > > On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote: > > > On Thu, 2 Aug 2018 at 17:30, Quentin Perret > > > wrote: > > > > > > > > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > > > > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret > > > > > wrote: > > > > > > Good point, setting the util_avg to 0 for new tasks should help > > > > > > filtering out those tiny tasks too. And that would match with the > > > > > > idea > > > > > > of letting tasks build their history before looking at their > > > > > > util_avg ... > > > > > > > > > > > > But there is one difference w.r.t frequency selection. The current > > > > > > code > > > > > > won't mark the system overutilized, but will let sugov raise the > > > > > > frequency when a new task is enqueued. So in case of a fork bomb, we > > > > > > > > > > If the initial value of util_avg is 0, we should not have any impact > > > > > on the util_avg of the cfs rq on which the task is attached, isn't it > > > > > ? so this should not impact both the over utilization state and the > > > > > frequency selected by sugov or I'm missing something ? > > > > > > > > What I tried to say is that setting util_avg to 0 for new tasks will > > > > prevent schedutil from raising the frequency in case of a fork bomb, and > > > > I think that could be an issue. And I think this isn't an issue with the > > > > patch as-is ... > > > > > > ok. So you also want to deal with fork bomb > > > Not sure that you don't have some problem with current proposal too > > > because select_task_rq_fair will always return prev_cpu because > > > util_avg and util_est are 0 at that time > > > > But find_idlest_cpu() should select a CPU using load in case of a forkee > > no ? > > So you have to wait for the next tick that will set the overutilized > and disable the want_energy. Until this point, all new tasks will be > put on the current cpu want_energy should always be false for forkees, because we set it only for SD_BALANCE_WAKE.
Re: [PATCH 3/4] aio: implement IOCB_CMD_POLL
On Thu, Aug 02, 2018 at 05:08:38PM +0100, Al Viro wrote: > On Thu, Aug 02, 2018 at 06:08:16PM +0200, Christoph Hellwig wrote: > > On Thu, Aug 02, 2018 at 05:00:32PM +0100, Al Viro wrote: > > > BTW, what happens if we insert into one queue and immediately get > > > woken up, even before the damn thing gets to the end of ->poll(), > > > which proceeds to call poll_wait() again (on another queue)? > > > AFAICS, apt.error will be set by the second callback and completely > > > ignored. And so will the return value of ->poll()... > > > > > > Sigh... Analysis of that thing is bloody painful, mostly because > > > it's hard to describe the state... > > > > That's the problem with the ->poll interface. We call it, then > > have magic happen underneath where it might or might not get added > > to one (or more if we didn't exclude that) waitqueues, and might > > have actually been worken before return. I can't really think of > > a good way to do that entirely sanely. > > > > Best I can think of is to only allow using file ops that do keyed > > wakeups and rely on the keyed wakeups alone. I've started coming > > up with a version of that, but it won't be until tomorrow at least > > that I can post it. > > What does it buy you? You still have to deal with trylock failures > in wakeup... But we'll never re-add an iocb once it has been removed from the waitqueue.
Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.
Udit Agarwal wrote: > +== > +Secure Key > +== > + > +Secure key is the new type added to kernel key ring service. > +Secure key is a symmetric type key of minimum length 32 bytes > +and with maximum possible length to be 128 bytes. It is produced > +in kernel using the CAAM crypto engine. Userspace can only see > +the blob for the corresponding key. All the blobs are displayed > +or loaded in hex ascii. To echo Mimi, this sounds suspiciously like it should have a generic interface, not one that's specifically tied to one piece of hardware - particularly if it's named with generic "secure". Can you convert this into a "symmetric" type and make the backend pluggable? > + keyctl add secure "new " > + keyctl load secure "load " > + keyctl print There isn't a "keyctl load" that I recall. Did you mean "keyctl add"? I wonder if it makes sense to actually add "create" and "load" interfaces for asymmetric and symmetric key types to aid in key management, e.g.: keyctl create symmetric.caam foo_munging_key len=128 @s keyctl load symmetric.caam foo_munging_key id=xxx @s keyctl create asymmetric.tpm foo_signing_key "rsa len=4096" @s keyctl load asymmetric.tpm foo_signing_key id=xxx @s Note the subtype extension added to the type. This is something I've been meaning to add to add_key() and request_key(). It means that we don't have to try and divine the nature of the key from the payload, but can leave the payload as just the data if data is needed. This might look something like: key = keyctl_create(const char *type, const char *desc, const char *data, key_serial_t keyring); key = keyctl_load(const char *type, const char *desc, const char *id, key_serial_t keyring); There would probably need to be a way to query the ID of a created key also, so that you can then pass that ID back to the loader. keyctl_get_id(key_serial_t key, char *buf, size_t buf_size); David
Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf
Hi Peter, On 8/2/2018 5:39 AM, Peter Zijlstra wrote: > On Tue, Jul 31, 2018 at 12:38:27PM -0700, Reinette Chatre wrote: >> Dear Maintainers, >> >> The success of Cache Pseudo-Locking can be measured via the use of >> performance events. Specifically, the number of cache hits and misses >> reading a memory region after it has been pseudo-locked to cache. This >> measurement is triggered via the resctrl debugfs interface. >> >> To ensure most accurate results the performance counters and their >> configuration registers are accessed directly. > > NAK on that. > After data is locked to cache we need to measure the success of that. There is no instruction that we can use to query if a memory address has been cached but we can use performance monitoring events that are especially valuable on the platforms where they are precise event capable. To ensure that we are only measuring the presence of data that should be locked to cache we need to tightly control how this measurement is done. For example, on my test system I locked 256KB to the cache and with the current implementation (tip.git on branch x86/cache) I am able to accurately measure that this was successful as seen below (each cache line within the 256KB is accessed while the performance monitoring events are active): pseudo_lock_mea-26090 [002] 61838.488027: pseudo_lock_l2: hits=4096 miss=0 pseudo_lock_mea-26097 [002] 61843.689381: pseudo_lock_l2: hits=4096 miss=0 pseudo_lock_mea-26100 [002] 61848.751411: pseudo_lock_l2: hits=4096 miss=0 pseudo_lock_mea-26108 [002] 61853.820361: pseudo_lock_l2: hits=4096 miss=0 pseudo_lock_mea-26111 [002] 61858.880364: pseudo_lock_l2: hits=4096 miss=0 pseudo_lock_mea-26118 [002] 61863.937343: pseudo_lock_l2: hits=4096 miss=0 pseudo_lock_mea-26121 [002] 61869.008341: pseudo_lock_l2: hits=4096 miss=0 The current implementation does not coordinate with perf and this is what I am trying to fix in this series. I do respect your NAK but it is not clear to me how to proceed after obtaining it. Could you please elaborate on what you would prefer as a solution to ensure accurate measurement of cache-locked data that is better integrated? Thank you very much Reinette
Re: [PATCH] kernel/module: Use kmemdup to replace kmalloc+memcpy
+++ zhong jiang [01/08/18 00:56 +0800]:
we prefer to the kmemdup rather than kmalloc+memcpy. so just
replace them.
Signed-off-by: zhong jiang
Applied, thanks.
Jessica
---
kernel/module.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 20344e4..6746c85 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2057,21 +2057,19 @@ static int copy_module_elf(struct module *mod, struct
load_info *info)
/* Elf section header table */
size = sizeof(*info->sechdrs) * info->hdr->e_shnum;
- mod->klp_info->sechdrs = kmalloc(size, GFP_KERNEL);
+ mod->klp_info->sechdrs = kmemdup(info->sechdrs, size, GFP_KERNEL);
if (mod->klp_info->sechdrs == NULL) {
ret = -ENOMEM;
goto free_info;
}
- memcpy(mod->klp_info->sechdrs, info->sechdrs, size);
/* Elf section name string table */
size = info->sechdrs[info->hdr->e_shstrndx].sh_size;
- mod->klp_info->secstrings = kmalloc(size, GFP_KERNEL);
+ mod->klp_info->secstrings = kmemdup(info->secstrings, size, GFP_KERNEL);
if (mod->klp_info->secstrings == NULL) {
ret = -ENOMEM;
goto free_sechdrs;
}
- memcpy(mod->klp_info->secstrings, info->secstrings, size);
/* Elf symbol section index */
symndx = info->index.sym;
--
1.7.12.4
Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf
On Thu, Aug 02, 2018 at 09:14:10AM -0700, Reinette Chatre wrote: > The current implementation does not coordinate with perf and this is > what I am trying to fix in this series. > > I do respect your NAK but it is not clear to me how to proceed after > obtaining it. Could you please elaborate on what you would prefer as a > solution to ensure accurate measurement of cache-locked data that is > better integrated? We have an in-kernel interface to perf, use that if you want access to the PMU. You will not directly stomp on PMU registers.
Applied "ASoC: core: remove support for card rebind using component framework" to the asoc tree
The patch
ASoC: core: remove support for card rebind using component framework
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 611cbc8799b672f41b6ba7afed758ad9efb959a7 Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla
Date: Thu, 2 Aug 2018 16:03:38 +0100
Subject: [PATCH] ASoC: core: remove support for card rebind using component
framework
DRM based audio components get registered inside the component framework
bind callback. However component framework has a big mutex lock taken for
every call to component_add, component_del and bind, unbind callbacks.
This can lead to deadlock situation if we are trying to add new/remove
component within a bind/unbind callbacks. Which is what was happening
with bcm2837 rpi 3.
Revert this change till we sort out the mutex issue.
Reported-by: Guillaume Tucker
Reported-by: Stefan Wahren
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Mark Brown
---
include/sound/soc.h | 7 -
sound/soc/soc-core.c | 62
2 files changed, 69 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index ace474e8649e..41cec42fb456 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1091,12 +1090,6 @@ struct snd_soc_card {
struct work_struct deferred_resume_work;
- /* component framework related */
- bool components_added;
- /* set in machine driver to enable/disable auto re-binding */
- bool auto_bind;
- struct component_match *match;
-
/* lists of probed devices belonging to this card */
struct list_head component_dev_list;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 81b27923303d..82eb3868be67 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -279,28 +279,11 @@ static inline void snd_soc_debugfs_exit(void)
#endif
-static int snd_soc_card_comp_compare(struct device *dev, void *data)
-{
- struct snd_soc_component *component;
-
- lockdep_assert_held(&client_mutex);
- list_for_each_entry(component, &component_list, list) {
- if (dev == component->dev) {
- if (!strcmp(component->name, data))
- return 1;
- break;
- }
- }
-
- return 0;
-}
-
static int snd_soc_rtdcom_add(struct snd_soc_pcm_runtime *rtd,
struct snd_soc_component *component)
{
struct snd_soc_rtdcom_list *rtdcom;
struct snd_soc_rtdcom_list *new_rtdcom;
- char *cname;
for_each_rtdcom(rtd, rtdcom) {
/* already connected */
@@ -317,13 +300,6 @@ static int snd_soc_rtdcom_add(struct snd_soc_pcm_runtime
*rtd,
list_add_tail(&new_rtdcom->list, &rtd->component_list);
- if (rtd->card->auto_bind && !rtd->card->components_added) {
- cname = devm_kasprintf(rtd->card->dev, GFP_KERNEL,
- "%s", component->name);
- component_match_add(rtd->card->dev, &rtd->card->match,
- snd_soc_card_comp_compare, cname);
- }
-
return 0;
}
@@ -859,25 +835,6 @@ static bool soc_is_dai_link_bound(struct snd_soc_card
*card,
return false;
}
-static int snd_soc_card_comp_bind(struct device *dev)
-{
- struct snd_soc_card *card = dev_get_drvdata(dev);
-
- if (card->instantiated)
- return 0;
-
- return snd_soc_register_card(card);
-}
-
-static void snd_soc_card_comp_unbind(struct device *dev)
-{
-}
-
-static const struct component_master_ops snd_soc_card_comp_ops = {
- .bind = snd_soc_card_comp_bind,
- .unbind = snd_soc_card_comp_unbind,
-};
-
static int soc_bind_dai_link(struct snd_soc_card *card,
struct snd_soc_dai_link *dai_link)
{
@@ -2169,12 +2126,6 @@ static int snd_soc_instantiate_card(struct snd_soc_card
*card)
card->instantiated = 1;
snd_soc_dapm_sync(&card->dapm);
- if (card->auto_bind && !card->components_added) {
- component_mast
Applied "ASoC: apq8096: remove auto rebinding" to the asoc tree
The patch
ASoC: apq8096: remove auto rebinding
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 1eb576881ff884dd6d10272b96cc336d156492c2 Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla
Date: Thu, 2 Aug 2018 16:03:36 +0100
Subject: [PATCH] ASoC: apq8096: remove auto rebinding
Remove auto rebinding support, as component framework can deadlock
in few usecases if we are trying to add new/remove component within
a bind/unbind callbacks.
Card rebinding is ASoC core feature so all the previous component
framework stuff in q6dsp remains removed.
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Mark Brown
---
sound/soc/qcom/apq8096.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
index 1e4a90d59228..6ee7e66cbaaa 100644
--- a/sound/soc/qcom/apq8096.c
+++ b/sound/soc/qcom/apq8096.c
@@ -48,7 +48,6 @@ static int apq8096_platform_probe(struct platform_device
*pdev)
return -ENOMEM;
card->dev = dev;
- card->auto_bind = true;
dev_set_drvdata(dev, card);
ret = qcom_snd_parse_of(card);
if (ret) {
@@ -74,7 +73,6 @@ static int apq8096_platform_remove(struct platform_device
*pdev)
{
struct snd_soc_card *card = dev_get_drvdata(&pdev->dev);
- card->auto_bind = false;
snd_soc_unregister_card(card);
kfree(card->dai_link);
kfree(card);
--
2.18.0
Applied "ASoC: smd845: remove auto rebinding" to the asoc tree
The patch
ASoC: smd845: remove auto rebinding
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 62121debfb31a8700e387bd2987779b3a98bc520 Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla
Date: Thu, 2 Aug 2018 16:03:37 +0100
Subject: [PATCH] ASoC: smd845: remove auto rebinding
Remove auto rebinding support, as component framework can deadlock
in few usecases if we are trying to add new/remove component within
a bind/unbind callbacks.
Card rebinding is ASoC core feature so all the previous component
framework stuff in q6dsp remains removed.
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Mark Brown
---
sound/soc/qcom/sdm845.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index bf4ec4646906..be0cb1122036 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -226,7 +226,6 @@ static int sdm845_snd_platform_probe(struct platform_device
*pdev)
return -ENOMEM;
card->dev = dev;
- card->auto_bind = true;
dev_set_drvdata(dev, card);
ret = qcom_snd_parse_of(card);
if (ret) {
@@ -258,7 +257,6 @@ static int sdm845_snd_platform_remove(struct
platform_device *pdev)
struct snd_soc_card *card = dev_get_drvdata(&pdev->dev);
struct sdm845_snd_data *data = snd_soc_card_get_drvdata(card);
- card->auto_bind = false;
snd_soc_unregister_card(card);
kfree(card->dai_link);
kfree(data);
--
2.18.0
[PATCH] lightnvm: combine 1.2 and 2.0 command flags
Avoid targets open-code the nvm_rq command flag for version 1.2 and
2.0. The core should have this responsibility.
When moved into core, the flags parameter can be distilled into
access hint, scrambling, and program/erase suspend. Replace the
access hint with a "is_seq" parameter, and let the rest be
dependent on the command opcode, which is trivial to detect and
set.
Signed-off-by: Matias Bjørling
---
drivers/lightnvm/core.c | 20
drivers/lightnvm/pblk-core.c | 13 -
drivers/lightnvm/pblk-read.c | 8 +---
drivers/lightnvm/pblk-recovery.c | 14 --
drivers/lightnvm/pblk-write.c| 2 +-
drivers/lightnvm/pblk.h | 38 --
include/linux/lightnvm.h | 2 ++
7 files changed, 32 insertions(+), 65 deletions(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 60aa7bc5a630..68553c7ae937 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -752,6 +752,24 @@ int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct
ppa_addr *ppas,
}
EXPORT_SYMBOL(nvm_set_tgt_bb_tbl);
+static int nvm_set_flags(struct nvm_geo *geo, struct nvm_rq *rqd)
+{
+ int flags = 0;
+
+ if (geo->version == NVM_OCSSD_SPEC_20)
+ return 0;
+
+ if (rqd->is_seq)
+ flags |= geo->pln_mode >> 1;
+
+ if (rqd->opcode == NVM_OP_PREAD)
+ flags |= (NVM_IO_SCRAMBLE_ENABLE | NVM_IO_SUSPEND);
+ else if (rqd->opcode == NVM_OP_PWRITE)
+ flags |= NVM_IO_SCRAMBLE_ENABLE;
+
+ return flags;
+}
+
int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
{
struct nvm_dev *dev = tgt_dev->parent;
@@ -763,6 +781,7 @@ int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct
nvm_rq *rqd)
nvm_rq_tgt_to_dev(tgt_dev, rqd);
rqd->dev = tgt_dev;
+ rqd->flags = nvm_set_flags(&tgt_dev->geo, rqd);
/* In case of error, fail with right address format */
ret = dev->ops->submit_io(dev, rqd);
@@ -783,6 +802,7 @@ int nvm_submit_io_sync(struct nvm_tgt_dev *tgt_dev, struct
nvm_rq *rqd)
nvm_rq_tgt_to_dev(tgt_dev, rqd);
rqd->dev = tgt_dev;
+ rqd->flags = nvm_set_flags(&tgt_dev->geo, rqd);
/* In case of error, fail with right address format */
ret = dev->ops->submit_io_sync(dev, rqd);
diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
index 00984b486fea..72acf2f6dbd6 100644
--- a/drivers/lightnvm/pblk-core.c
+++ b/drivers/lightnvm/pblk-core.c
@@ -688,7 +688,7 @@ static int pblk_line_submit_emeta_io(struct pblk *pblk,
struct pblk_line *line,
if (dir == PBLK_WRITE) {
struct pblk_sec_meta *meta_list = rqd.meta_list;
- rqd.flags = pblk_set_progr_mode(pblk, PBLK_WRITE);
+ rqd.is_seq = 1;
for (i = 0; i < rqd.nr_ppas; ) {
spin_lock(&line->lock);
paddr = __pblk_alloc_page(pblk, line, min);
@@ -703,11 +703,9 @@ static int pblk_line_submit_emeta_io(struct pblk *pblk,
struct pblk_line *line,
for (i = 0; i < rqd.nr_ppas; ) {
struct ppa_addr ppa = addr_to_gen_ppa(pblk, paddr, id);
int pos = pblk_ppa_to_pos(geo, ppa);
- int read_type = PBLK_READ_RANDOM;
if (pblk_io_aligned(pblk, rq_ppas))
- read_type = PBLK_READ_SEQUENTIAL;
- rqd.flags = pblk_set_read_mode(pblk, read_type);
+ rqd.is_seq = 1;
while (test_bit(pos, line->blk_bitmap)) {
paddr += min;
@@ -787,17 +785,14 @@ static int pblk_line_submit_smeta_io(struct pblk *pblk,
struct pblk_line *line,
__le64 *lba_list = NULL;
int i, ret;
int cmd_op, bio_op;
- int flags;
if (dir == PBLK_WRITE) {
bio_op = REQ_OP_WRITE;
cmd_op = NVM_OP_PWRITE;
- flags = pblk_set_progr_mode(pblk, PBLK_WRITE);
lba_list = emeta_to_lbas(pblk, line->emeta->buf);
} else if (dir == PBLK_READ_RECOV || dir == PBLK_READ) {
bio_op = REQ_OP_READ;
cmd_op = NVM_OP_PREAD;
- flags = pblk_set_read_mode(pblk, PBLK_READ_SEQUENTIAL);
} else
return -EINVAL;
@@ -822,7 +817,7 @@ static int pblk_line_submit_smeta_io(struct pblk *pblk,
struct pblk_line *line,
rqd.bio = bio;
rqd.opcode = cmd_op;
- rqd.flags = flags;
+ rqd.is_seq = 1;
rqd.nr_ppas = lm->smeta_sec;
for (i = 0; i < lm->smeta_sec; i++, paddr++) {
@@ -885,7 +880,7 @@ static void pblk_setup_e_rq(struct pblk *pblk, struct
nvm_rq *rqd,
rqd->opcode = NVM_OP_ERASE;
rqd->ppa_addr = ppa;
rqd->nr_ppas = 1;
- rqd->flags = pblk_set_progr_mode(pblk, PBLK_ERAS
Re: [PATCH v5 12/14] sched/fair: Select an energy-efficient CPU on task wake-up
On Thursday 02 Aug 2018 at 15:54:26 (+0200), Peter Zijlstra wrote:
> On Tue, Jul 24, 2018 at 01:25:19PM +0100, Quentin Perret wrote:
> > @@ -6385,18 +6492,26 @@ static int
> > select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int
> > wake_flags)
> > {
> > struct sched_domain *tmp, *sd = NULL;
> > + struct freq_domain *fd;
> > int cpu = smp_processor_id();
> > int new_cpu = prev_cpu;
> > - int want_affine = 0;
> > + int want_affine = 0, want_energy = 0;
> > int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING);
> >
> > + rcu_read_lock();
> > if (sd_flag & SD_BALANCE_WAKE) {
> > record_wakee(p);
> > - want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu)
> > - && cpumask_test_cpu(cpu, &p->cpus_allowed);
> > + fd = rd_freq_domain(cpu_rq(cpu)->rd);
> > + want_energy = fd && !READ_ONCE(cpu_rq(cpu)->rd->overutilized);
> > + want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu) &&
> > + cpumask_test_cpu(cpu, &p->cpus_allowed);
> > + }
> > +
> > + if (want_energy) {
> > + new_cpu = find_energy_efficient_cpu(p, prev_cpu, fd);
> > + goto unlock;
> > }
> >
>
> And I suppose you rely on the compiler to optimize that for the static
> key inside rd_freq_domain()... Does it do a good job of that?
I does for sure when CONFIG_ENERGY_MODEL=n since rd_freq_domain() is
stubbed to false, but that's an easy one ;-)
>
> That is, would not something like:
>
>
> rcu_read_lock();
> if (sd_flag & SD_BALANCE_WAKE) {
> record_wakee(p);
>
> if (static_branch_unlikely(&sched_energy_present)) {
> struct root_domain *rd = cpu_rq(cpu)->rd;
> struct freq_domain *fd = rd_freq_domain(rd);
>
> if (fd && !READ_ONCE(rd->overutilized)) {
> new_cpu = find_energy_efficient_cpu(p,
> prev_cpu, fd);
> goto unlock;
> }
> }
>
> /* ... */
> }
>
>
> Be far more clear ?
It is clearer. Having the static key check in rd_freq_domain() makes
the change to find_busiest_group() smaller, but I can totally change it
with something like the above.
I'll do that in v6.
Thanks,
Quentin
Re: [rt-patch 4/3] arm,KVM: Move phys_timer handling to hard irq context
On Thu, 02 Aug 2018 08:56:20 +0200 Mike Galbraith wrote: > (arm-land adventures 1/3 take2 will have to wait, my cup runeth over) > > v4.14..v4.15 timer handling changes including calling kvm_timer_vcpu_load() I take it that this should be added to v4.16-rt and marked stable-rt? -- Steve > during kvm_preempt_ops.sched_in and taking vgic_dist.lpi_list_lock in the > timer interrupt handler required locks for which locking rules/context had > been changed be converted to raw_spinlock_t... > > Quoting virt/kvm/arm/vgic/vgic.c: > * Locking order is always: > * kvm->lock (mutex) > * its->cmd_lock (mutex) > * its->its_lock (mutex) > * vgic_cpu->ap_list_lock must be taken with IRQs disabled > * kvm->lpi_list_lock must be taken with IRQs disabled > * vgic_irq->irq_lock must be taken with IRQs disabled > * > * As the ap_list_lock might be taken from the timer interrupt handler, > * we have to disable IRQs before taking this lock and everything lower > * than it. > > ...and fixed the obvious bricking consequence of those changes for RT, > but left an RT specific kvm unit test timer failure in its wake. Handling > phys_timer in hard interrupt context as expected cures that failure. > > Pre: > PASS selftest-setup (2 tests) > PASS selftest-vectors-kernel (2 tests) > PASS selftest-vectors-user (2 tests) > PASS selftest-smp (65 tests) > PASS pci-test (1 tests) > PASS pmu (3 tests) > PASS gicv2-ipi (3 tests) > PASS gicv3-ipi (3 tests) > PASS gicv2-active (1 tests) > PASS gicv3-active (1 tests) > PASS psci (4 tests) > FAIL timer (8 tests, 1 unexpected failures) > > Post: > PASS selftest-setup (2 tests) > PASS selftest-vectors-kernel (2 tests) > PASS selftest-vectors-user (2 tests) > PASS selftest-smp (65 tests) > PASS pci-test (1 tests) > PASS pmu (3 tests) > PASS gicv2-ipi (3 tests) > PASS gicv3-ipi (3 tests) > PASS gicv2-active (1 tests) > PASS gicv3-active (1 tests) > PASS psci (4 tests) > PASS timer (8 tests) > > Signed-off-by: Mike Galbraith > --- > virt/kvm/arm/arch_timer.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/virt/kvm/arm/arch_timer.c > +++ b/virt/kvm/arm/arch_timer.c > @@ -634,7 +634,7 @@ void kvm_timer_vcpu_init(struct kvm_vcpu > hrtimer_init(&timer->bg_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS); > timer->bg_timer.function = kvm_bg_timer_expire; > > - hrtimer_init(&timer->phys_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS); > + hrtimer_init(&timer->phys_timer, CLOCK_MONOTONIC, > HRTIMER_MODE_ABS_HARD); > timer->phys_timer.function = kvm_phys_timer_expire; > > vtimer->irq.irq = default_vtimer_irq.irq;
[PATCH] reiserfs: propagate errors from fill_with_dentries properly
fill_with_dentries() failed to propagate errors up to
reiserfs_for_each_xattr() properly. Plumb them through.
Note that reiserfs_for_each_xattr() is only used by
reiserfs_delete_xattrs() and reiserfs_chown_xattrs().
The result of reiserfs_delete_xattrs() is discarded anyway, the only
difference there is whether a warning is printed to dmesg.
The result of reiserfs_chown_xattrs() does matter because it can block
chowning of the file to which the xattrs belong; but either way, the
resulting state can have misaligned ownership, so my patch doesn't improve
things greatly.
Credit for making me look at this code goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Signed-off-by: Jann Horn
---
I have tested this by manually patching error injection into
fill_with_dentries().
Opinions? Is this a sensible change?
Because the changes in this patch are more superficial than the changes
in the other one, I split this out so that the security patch is a
clean change that obviously belongs in stable and can hopefully go in
quickly.
After the cases I can see where errors are returned improperly are
cleaned up, I plan to change the calling convention for ->actor as
suggested by Al Viro.
fs/reiserfs/xattr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/reiserfs/xattr.c b/fs/reiserfs/xattr.c
index ff94fad477e4..ae4a28410dbd 100644
--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -185,6 +185,7 @@ struct reiserfs_dentry_buf {
struct dir_context ctx;
struct dentry *xadir;
int count;
+ int err;
struct dentry *dentries[8];
};
@@ -207,6 +208,7 @@ fill_with_dentries(struct dir_context *ctx, const char
*name, int namelen,
dentry = lookup_one_len(name, dbuf->xadir, namelen);
if (IS_ERR(dentry)) {
+ dbuf->err = PTR_ERR(dentry);
return PTR_ERR(dentry);
} else if (d_really_is_negative(dentry)) {
/* A directory entry exists, but no file? */
@@ -215,6 +217,7 @@ fill_with_dentries(struct dir_context *ctx, const char
*name, int namelen,
"not found for file %pd.\n",
dentry, dbuf->xadir);
dput(dentry);
+ dbuf->err = -EIO;
return -EIO;
}
@@ -262,6 +265,10 @@ static int reiserfs_for_each_xattr(struct inode *inode,
err = reiserfs_readdir_inode(d_inode(dir), &buf.ctx);
if (err)
break;
+ if (buf.err) {
+ err = buf.err;
+ break;
+ }
if (!buf.count)
break;
for (i = 0; !err && i < buf.count && buf.dentries[i]; i++) {
--
2.18.0.597.ga71716f1ad-goog
Re: [PATCH 2/2] staging:r8188eu: Use lib80211 to encrypt (CCMP) tx frames
On 07/16/18 15:30, Michael Straube wrote: On 07/14/18 19:54, Ivan Safonov wrote: Put data to skb, decrypt with lib80211_crypt_ccmp, and place back to tx buffer. Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_security.c | 778 +++--- 1 file changed, 72 insertions(+), 706 deletions(-) Hi Ivan, with this applied I get the following in dmesg: [ 3.901334] [drm] Initialized amdgpu 3.26.0 20150101 for :07:00.0 on minor 0 [ 4.108904] IPv6: ADDRCONF(NETDEV_UP): enp6s0: link is not ready [ 4.185502] r8169 :06:00.0 enp6s0: link down [ 4.185564] IPv6: ADDRCONF(NETDEV_UP): enp6s0: link is not ready [ 4.193647] IPv6: ADDRCONF(NETDEV_UP): wlp1s0f0u9: link is not ready [ 17.741809] MAC Address = 7c:8b:ca:08:80:7e [ 17.828850] IPv6: ADDRCONF(NETDEV_UP): wlp1s0f0u9: link is not ready [ 17.969593] R8188EU: indicate disassoc [ 18.081923] IPv6: ADDRCONF(NETDEV_UP): wlp1s0f0u9: link is not ready [ 18.123036] IPv6: ADDRCONF(NETDEV_UP): wlp1s0f0u9: link is not ready [ 23.034084] R8188EU: assoc success [ 23.085043] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0f0u9: link becomes ready [ 23.093587] BUG: scheduling while atomic: NetworkManager/495/0x0202 [ 23.093590] Modules linked in: amdkfd amd_iommu_v2 amdgpu nls_iso8859_1 nls_cp437 vfat fat r8188eu(C) lib80211 snd_hda_codec_realtek cfg80211 snd_hda_codec_generic edac_mce_amd chash snd_hda_codec_hdmi gpu_sched kvm_amd i2c_algo_bit ttm ccp snd_hda_intel rng_core drm_kms_helper kvm snd_hda_codec input_leds led_class joydev mousedev drm rfkill irqbypass snd_hda_core crct10dif_pclmul agpgart crc32_pclmul snd_hwdep ghash_clmulni_intel syscopyarea sysfillrect sysimgblt pcbc wmi_bmof snd_pcm aesni_intel snd_timer aes_x86_64 crypto_simd cryptd k10temp fb_sys_fops snd r8169 sp5100_tco pcspkr glue_helper soundcore mii i2c_piix4 rtc_cmos pinctrl_amd evdev gpio_amdpt wmi mac_hid acpi_cpufreq crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sd_mod hid_generic usbhid hid ahci libahci [ 23.093655] xhci_pci xhci_hcd libata crc32c_intel usbcore scsi_mod usb_common [ 23.093661] Preemption disabled at: [ 23.093667] [] __dev_queue_xmit+0x74/0x910 [ 23.093672] CPU: 7 PID: 495 Comm: NetworkManager Tainted: G C 4.18.0-rc5-staging+ #1 [ 23.093673] Hardware name: Gigabyte Technology Co., Ltd. A320M-S2H/A320M-S2H-CF, BIOS F23d 04/17/2018 [ 23.093675] Call Trace: [ 23.093683] dump_stack+0x5c/0x80 [ 23.093686] ? __dev_queue_xmit+0x74/0x910 [ 23.093691] __schedule_bug.cold.14+0x82/0x9b [ 23.093696] __schedule+0x705/0x8b0 [ 23.093700] ? enqueue_task_fair+0xc3/0x730 [ 23.093704] schedule+0x32/0x90 [ 23.093707] schedule_timeout+0x311/0x4a0 [ 23.093710] ? _raw_spin_unlock_irqrestore+0x20/0x40 [ 23.093713] ? try_to_wake_up+0x23a/0x490 [ 23.093716] wait_for_common+0x15f/0x190 [ 23.093719] ? wake_up_q+0x70/0x70 [ 23.093736] ? rtw_aes_encrypt+0x26f/0x290 [r8188eu] [ 23.093739] wait_for_completion_killable+0x19/0x30 [ 23.093743] call_usermodehelper_exec+0x115/0x160 [ 23.093747] __request_module+0x1ac/0x3e2 [ 23.093764] rtw_aes_encrypt+0x26f/0x290 [r8188eu] [ 23.093778] ? rtw_get_stainfo+0xe6/0x130 [r8188eu] [ 23.093793] rtw_xmitframe_coalesce+0x950/0xb00 [r8188eu] [ 23.093799] ? _raw_spin_lock_irqsave+0x25/0x50 [ 23.093812] rtw_hal_xmit+0x83/0x130 [r8188eu] [ 23.093826] rtw_xmit+0x258/0x5d0 [r8188eu] [ 23.093840] rtw_xmit_entry+0xe8/0x2e7 [r8188eu] [ 23.093845] dev_hard_start_xmit+0xa5/0x240 [ 23.093849] sch_direct_xmit+0x150/0x340 [ 23.093852] __dev_queue_xmit+0x2f6/0x910 [ 23.093856] packet_sendmsg+0x945/0x1592 [ 23.093860] ? attach_to_pi_state+0x18/0x110 [ 23.093862] ? preempt_count_sub+0x60/0x90 [ 23.093866] ? ep_item_poll.isra.1+0x40/0xc0 [ 23.093871] sock_sendmsg+0x33/0x40 [ 23.093874] __sys_sendto+0xee/0x160 [ 23.093879] ? memzero_explicit+0xa/0x10 [ 23.093883] ? urandom_read+0x120/0x270 [ 23.093887] __x64_sys_sendto+0x24/0x30 [ 23.093890] do_syscall_64+0x5b/0x170 [ 23.093893] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 23.093896] RIP: 0033:0x7fac0b700c12 [ 23.093897] Code: 48 83 ec 18 44 89 4c 24 08 e8 9a f5 ff ff 44 8b 4c 24 08 4d 89 f8 45 89 f2 89 c5 4c 89 ea 4c 89 e6 89 df b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3a 89 ef 48 89 44 24 08 e8 ca f5 ff ff 48 8b [ 23.093935] RSP: 002b:7fffc46321b0 EFLAGS: 0293 ORIG_RAX: 002c [ 23.093938] RAX: ffda RBX: 0011 RCX: 7fac0b700c12 [ 23.093939] RDX: 0148 RSI: 55f8a5417c70 RDI: 0011 [ 23.093940] RBP: R08: 55f8a54154c0 R09: 0014 [ 23.093942] R10: R11: 0293 R12: 55f8a5417c70 [ 23.093943] R13: 0148 R14: R15: 55f8a54154c0 [ 23.096167] lib80211_crypt: registered algorithm 'CCMP' [ 23.096544] [ cut here
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thu, 2 Aug 2018 at 18:10, Quentin Perret wrote: > > On Thursday 02 Aug 2018 at 18:07:49 (+0200), Vincent Guittot wrote: > > On Thu, 2 Aug 2018 at 18:00, Quentin Perret wrote: > > > > > > On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote: > > > > On Thu, 2 Aug 2018 at 17:30, Quentin Perret > > > > wrote: > > > > > > > > > > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > > > > > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret > > > > > > wrote: > > > > > > > Good point, setting the util_avg to 0 for new tasks should help > > > > > > > filtering out those tiny tasks too. And that would match with the > > > > > > > idea > > > > > > > of letting tasks build their history before looking at their > > > > > > > util_avg ... > > > > > > > > > > > > > > But there is one difference w.r.t frequency selection. The > > > > > > > current code > > > > > > > won't mark the system overutilized, but will let sugov raise the > > > > > > > frequency when a new task is enqueued. So in case of a fork bomb, > > > > > > > we > > > > > > > > > > > > If the initial value of util_avg is 0, we should not have any impact > > > > > > on the util_avg of the cfs rq on which the task is attached, isn't > > > > > > it > > > > > > ? so this should not impact both the over utilization state and the > > > > > > frequency selected by sugov or I'm missing something ? > > > > > > > > > > What I tried to say is that setting util_avg to 0 for new tasks will > > > > > prevent schedutil from raising the frequency in case of a fork bomb, > > > > > and > > > > > I think that could be an issue. And I think this isn't an issue with > > > > > the > > > > > patch as-is ... > > > > > > > > ok. So you also want to deal with fork bomb > > > > Not sure that you don't have some problem with current proposal too > > > > because select_task_rq_fair will always return prev_cpu because > > > > util_avg and util_est are 0 at that time > > > > > > But find_idlest_cpu() should select a CPU using load in case of a forkee > > > no ? > > > > So you have to wait for the next tick that will set the overutilized > > and disable the want_energy. Until this point, all new tasks will be > > put on the current cpu > > want_energy should always be false for forkees, because we set it only > for SD_BALANCE_WAKE. Ah yes I forgot that point. But doesn't this break the EAS policy ? I mean each time a new task is created, we use the load to select the best CPU
Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf
On 8/2/2018 9:18 AM, Peter Zijlstra wrote: > On Thu, Aug 02, 2018 at 09:14:10AM -0700, Reinette Chatre wrote: > >> The current implementation does not coordinate with perf and this is >> what I am trying to fix in this series. >> >> I do respect your NAK but it is not clear to me how to proceed after >> obtaining it. Could you please elaborate on what you would prefer as a >> solution to ensure accurate measurement of cache-locked data that is >> better integrated? > > We have an in-kernel interface to perf, use that if you want access to > the PMU. You will not directly stomp on PMU registers. I do not see how I can do so without incurring the cache hits and misses from the data needed and instructions run by this interface. Could you please share how I can do so and still obtain the accurate measurement of cache residency of a specific memory region? Reinette
Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai wrote: > In case of shrink_slab_memcg() we do not zero nid, when shrinker > is not numa-aware. This is not a real problem, since currently > all memcg-aware shrinkers are numa-aware too (we have two: Actually, this is not true. huge_zero_page_shrinker is NOT numa-aware. deferred_split_shrinker is numa-aware. Thanks, Yang > super_block shrinker and workingset shrinker), but something may > change in the future. > > (Andrew, this may be merged to > mm-iterate-only-over-charged-shrinkers-during-memcg-shrink_slab) > > Signed-off-by: Kirill Tkhai > --- > mm/vmscan.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index ea0a46166e8e..0d980e801b8a 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -455,6 +455,9 @@ static unsigned long do_shrink_slab(struct shrink_control > *shrinkctl, > : SHRINK_BATCH; > long scanned = 0, next_deferred; > > + if (!(shrinker->flags & SHRINKER_NUMA_AWARE)) > + nid = 0; > + > freeable = shrinker->count_objects(shrinker, shrinkctl); > if (freeable == 0 || freeable == SHRINK_EMPTY) > return freeable; > @@ -680,9 +683,6 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid, > .memcg = memcg, > }; > > - if (!(shrinker->flags & SHRINKER_NUMA_AWARE)) > - sc.nid = 0; > - > ret = do_shrink_slab(&sc, shrinker, priority); > if (ret == SHRINK_EMPTY) > ret = 0; >
Re: [rt-patch 4/3] arm,KVM: Move phys_timer handling to hard irq context
On Thu, 2018-08-02 at 12:31 -0400, Steven Rostedt wrote: > On Thu, 02 Aug 2018 08:56:20 +0200 > Mike Galbraith wrote: > > > (arm-land adventures 1/3 take2 will have to wait, my cup runeth over) > > > > v4.14..v4.15 timer handling changes including calling kvm_timer_vcpu_load() > > I take it that this should be added to v4.16-rt and marked stable-rt? Yeah, barring way sexier ideas of course. -Mike
Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote: > > On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai wrote: > > In case of shrink_slab_memcg() we do not zero nid, when shrinker > > is not numa-aware. This is not a real problem, since currently > > all memcg-aware shrinkers are numa-aware too (we have two: > > Actually, this is not true. huge_zero_page_shrinker is NOT numa-aware. > deferred_split_shrinker is numa-aware. > But both huge_zero_page_shrinker and huge_zero_page_shrinker are not memcg-aware shrinkers. I think Kirill is saying all memcg-aware shrinkers are also numa-aware shrinkers. Shakeel
Re: [PATCH v2 3/3] mm, oom: introduce memory.oom.group
On Thu, Aug 02, 2018 at 07:53:13PM +0900, Tetsuo Handa wrote:
> On 2018/08/02 9:32, Roman Gushchin wrote:
> > For some workloads an intervention from the OOM killer
> > can be painful. Killing a random task can bring
> > the workload into an inconsistent state.
> >
> > Historically, there are two common solutions for this
> > problem:
> > 1) enabling panic_on_oom,
> > 2) using a userspace daemon to monitor OOMs and kill
> >all outstanding processes.
> >
> > Both approaches have their downsides:
> > rebooting on each OOM is an obvious waste of capacity,
> > and handling all in userspace is tricky and requires
> > a userspace agent, which will monitor all cgroups
> > for OOMs.
>
> We could start a one-time userspace agent which handles
> an cgroup OOM event and then terminates...
That might be not so trivial if there is a shortage of memory.
>
>
>
> > +/**
> > + * mem_cgroup_get_oom_group - get a memory cgroup to clean up after OOM
> > + * @victim: task to be killed by the OOM killer
> > + * @oom_domain: memcg in case of memcg OOM, NULL in case of system-wide OOM
> > + *
> > + * Returns a pointer to a memory cgroup, which has to be cleaned up
> > + * by killing all belonging OOM-killable tasks.
> > + *
> > + * Caller has to call mem_cgroup_put() on the returned non-NULL memcg.
> > + */
> > +struct mem_cgroup *mem_cgroup_get_oom_group(struct task_struct *victim,
> > + struct mem_cgroup *oom_domain)
> > +{
> > + struct mem_cgroup *oom_group = NULL;
> > + struct mem_cgroup *memcg;
> > +
> > + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys))
> > + return NULL;
> > +
> > + if (!oom_domain)
> > + oom_domain = root_mem_cgroup;
> > +
> > + rcu_read_lock();
> > +
> > + memcg = mem_cgroup_from_task(victim);
>
> Isn't this racy? I guess that memcg of this "victim" can change to
> somewhere else from the one as of determining the final candidate.
> This "victim" might have already passed exit_mm()/cgroup_exit() from
> do_exit().
> This "victim" might be moving to a memcg which is different from the one
> determining the final candidate.
It is, as well as _all_ OOM handling code.
E.g. what if a user will set oom_score_adj to -1000 in the last moment?
It really doesn't matter, OOM killer should guarantee
forward progress without making too stupid decisions.
It doesn't provide any strict guarantees and really
shouldn't.
>
> > + if (memcg == root_mem_cgroup)
> > + goto out;
> > +
> > + /*
> > +* Traverse the memory cgroup hierarchy from the victim task's
> > +* cgroup up to the OOMing cgroup (or root) to find the
> > +* highest-level memory cgroup with oom.group set.
> > +*/
> > + for (; memcg; memcg = parent_mem_cgroup(memcg)) {
> > + if (memcg->oom_group)
> > + oom_group = memcg;
> > +
> > + if (memcg == oom_domain)
> > + break;
> > + }
> > +
> > + if (oom_group)
> > + css_get(&oom_group->css);
> > +out:
> > + rcu_read_unlock();
> > +
> > + return oom_group;
> > +}
>
>
>
> > @@ -974,7 +988,23 @@ static void oom_kill_process(struct oom_control *oc,
> > const char *message)
> > }
> > read_unlock(&tasklist_lock);
> >
> > + /*
> > +* Do we need to kill the entire memory cgroup?
> > +* Or even one of the ancestor memory cgroups?
> > +* Check this out before killing the victim task.
> > +*/
> > + oom_group = mem_cgroup_get_oom_group(victim, oc->memcg);
> > +
> > __oom_kill_process(victim);
> > +
> > + /*
> > +* If necessary, kill all tasks in the selected memory cgroup.
> > +*/
> > + if (oom_group) {
>
> Isn't "killing a child process of the biggest memory hog" and "killing all
> processes which belongs to a memcg which the child process of the biggest
> memory hog belongs to" strange? The intent of selecting a child is to try
> to minimize lost work while the intent of oom_cgroup is to try to discard
> all work. If oom_cgroup is enabled, I feel that we should
>
> pr_err("%s: Kill all processes in ", message);
> pr_cont_cgroup_path(memcg->css.cgroup);
> pr_cont(" due to memory.oom.group set\n");
>
> without
>
> pr_err("%s: Kill process %d (%s) score %u or sacrifice child\n", message,
> task_pid_nr(p), p->comm, points);
>
> (I mean, don't try to select a child).
We can do this optimization, but I would be accurate with changing
dmesg output format. Although it never was a part of ABI, I wonder,
how many users are using something like "kill process [0-9]+ or
sacrifice child" regexps?
Thanks!
Re: [PATCH 2/2] clk: qcom: Add camera clock controller driver for SDM845
Quoting Amit Nischal (2018-07-30 00:20:52)
> On 2018-07-26 22:52, Stephen Boyd wrote:
> > Quoting Amit Nischal (2018-07-23 04:26:33)
> >> diff --git a/drivers/clk/qcom/camcc-sdm845.c
> >> b/drivers/clk/qcom/camcc-sdm845.c
> >> new file mode 100644
> >> index 000..61e5ec2
> >> --- /dev/null
> >> +++ b/drivers/clk/qcom/camcc-sdm845.c
> >> +static struct clk_rcg2 cam_cc_bps_clk_src = {
> >> + .cmd_rcgr = 0x600c,
> >> + .mnd_width = 0,
> >> + .hid_width = 5,
> >> + .parent_map = cam_cc_parent_map_0,
> >> + .freq_tbl = ftbl_cam_cc_bps_clk_src,
> >> + .clkr.hw.init = &(struct clk_init_data){
> >> + .name = "cam_cc_bps_clk_src",
> >> + .parent_names = cam_cc_parent_names_0,
> >> + .num_parents = 6,
> >> + .flags = CLK_SET_RATE_PARENT,
> >> + .ops = &clk_rcg2_shared_ops,
> >
> > Why are shared ops used in this driver?
> >
>
> As per HW design, most of the CAMCC RCGs needs to move to
> XO during clock disable so because of this we have used the
> shared ops.
Please add a comment to this effect in this driver and also mention this
in the commit text. I guess the camera firmware is also doing clk
control and so it wants the clk to be on at some basic rate in case
that's happening?
> >> +
> >> +static struct clk_rcg2 cam_cc_slow_ahb_clk_src = {
> >> + .cmd_rcgr = 0x6054,
> >> + .mnd_width = 0,
> >> + .hid_width = 5,
> >> + .parent_map = cam_cc_parent_map_0,
> >> + .freq_tbl = ftbl_cam_cc_slow_ahb_clk_src,
> >> + .clkr.hw.init = &(struct clk_init_data){
> >> + .name = "cam_cc_slow_ahb_clk_src",
> >> + .parent_names = cam_cc_parent_names_0,
> >> + .num_parents = 6,
> >> + .flags = CLK_SET_RATE_PARENT,
> >
> > Is CLK_SET_RATE_PARENT intentionally set on these RCGs so that they can
> > reconfigure the PLL frequency? Wouldn't that be a fixed rate PLL
> > frequency?
> >
>
> PLL2_OUT_EVEN requires to be reconfigure to 480MHz so clock sources
> which
> are using PLL2 in their frequency table requires 'CLK_SET_RATE_PARENT'
> flag to be set.
Ok.
Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator
On Thursday 02 Aug 2018 at 18:38:01 (+0200), Vincent Guittot wrote: > On Thu, 2 Aug 2018 at 18:10, Quentin Perret wrote: > > > > On Thursday 02 Aug 2018 at 18:07:49 (+0200), Vincent Guittot wrote: > > > On Thu, 2 Aug 2018 at 18:00, Quentin Perret > > > wrote: > > > > > > > > On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote: > > > > > On Thu, 2 Aug 2018 at 17:30, Quentin Perret > > > > > wrote: > > > > > > > > > > > > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote: > > > > > > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret > > > > > > > wrote: > > > > > > > > Good point, setting the util_avg to 0 for new tasks should help > > > > > > > > filtering out those tiny tasks too. And that would match with > > > > > > > > the idea > > > > > > > > of letting tasks build their history before looking at their > > > > > > > > util_avg ... > > > > > > > > > > > > > > > > But there is one difference w.r.t frequency selection. The > > > > > > > > current code > > > > > > > > won't mark the system overutilized, but will let sugov raise the > > > > > > > > frequency when a new task is enqueued. So in case of a fork > > > > > > > > bomb, we > > > > > > > > > > > > > > If the initial value of util_avg is 0, we should not have any > > > > > > > impact > > > > > > > on the util_avg of the cfs rq on which the task is attached, > > > > > > > isn't it > > > > > > > ? so this should not impact both the over utilization state and > > > > > > > the > > > > > > > frequency selected by sugov or I'm missing something ? > > > > > > > > > > > > What I tried to say is that setting util_avg to 0 for new tasks will > > > > > > prevent schedutil from raising the frequency in case of a fork > > > > > > bomb, and > > > > > > I think that could be an issue. And I think this isn't an issue > > > > > > with the > > > > > > patch as-is ... > > > > > > > > > > ok. So you also want to deal with fork bomb > > > > > Not sure that you don't have some problem with current proposal too > > > > > because select_task_rq_fair will always return prev_cpu because > > > > > util_avg and util_est are 0 at that time > > > > > > > > But find_idlest_cpu() should select a CPU using load in case of a forkee > > > > no ? > > > > > > So you have to wait for the next tick that will set the overutilized > > > and disable the want_energy. Until this point, all new tasks will be > > > put on the current cpu > > > > want_energy should always be false for forkees, because we set it only > > for SD_BALANCE_WAKE. > > Ah yes I forgot that point. > But doesn't this break the EAS policy ? I mean each time a new task is > created, we use the load to select the best CPU If you really keep spawning new tasks all the time, yes EAS won't help you, but there isn't a lot we can do :/. We need to have an idea of how big a task is for EAS, and we obviously don't know that for new tasks, so it's hard/dangerous to make assumptions. So the proposal here is that if you only have forkees once in a while, then those new tasks (and those new tasks only) will be placed using load the first time, and then they'll fall under EAS control has soon as they have at least a little bit of history. This _should_ happen without re-enabling load balance spuriously too often, and that _should_ prevent it from ruining the placement of existing tasks ... As Peter already mentioned, a better way of solving this issue would be to try to find the moment when the utilization signal has converged to something stable (assuming that it converges), but that, I think, isn't straightforward at all ... Does that make any sense ? Thanks, Quentin
Re: [PATCH v2] clk: qcom: Add camera clock controller driver for SDM845
Quoting Amit Nischal (2018-07-30 02:22:20)
> diff --git a/drivers/clk/qcom/camcc-sdm845.c b/drivers/clk/qcom/camcc-sdm845.c
> new file mode 100644
> index 000..702ca66
> --- /dev/null
> +++ b/drivers/clk/qcom/camcc-sdm845.c
> @@ -0,0 +1,1744 @@
> + },
> +};
> +
> +static const struct freq_tbl ftbl_cam_cc_bps_clk_src[] = {
> + F(1920, P_BI_TCXO, 1, 0, 0),
> + F(1, P_CAM_CC_PLL0_OUT_EVEN, 6, 0, 0),
> + F(2, P_CAM_CC_PLL0_OUT_EVEN, 3, 0, 0),
> + F(40400, P_CAM_CC_PLL1_OUT_EVEN, 2, 0, 0),
> + F(48000, P_CAM_CC_PLL2_OUT_EVEN, 1, 0, 0),
> + F(6, P_CAM_CC_PLL0_OUT_EVEN, 1, 0, 0),
> + { }
> +};
> +
> +/*
> + * As per HW design, some of the CAMCC RCGs needs to
> + * move to XO clock during their clock disable so using
Per hw design sure, but what about hw design is causing this?
> + * clk_rcg2_shared_ops for such RCGs.
> + * Also, use CLK_SET_RATE_PARENT flag for the RCGs which
> + * have non-fixed PLL as parent source and requires
Mention the PLL that isn't fixed?
> + * reconfiguration of the PLL frequency.
> + */
> +static struct clk_rcg2 cam_cc_bps_clk_src = {
> + .cmd_rcgr = 0x600c,
> + .mnd_width = 0,
Re: [PATCH v12 7/7] Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990
Hi Balakrishna,
only two minor comments, though I hate to make you respin once more
for nits. I also noticed a possible error in the DT bindings, so maybe
you'd have to respin anyway ...
On Thu, Aug 02, 2018 at 06:55:18PM +0530, Balakrishna Godavarthi wrote:
> Add support to set voltage/current of various regulators
> to power up/down Bluetooth chip wcn3990.
>
> Signed-off-by: Balakrishna Godavarthi
> ---
> Changes in v12:
> * removed retrying iteration loop in qca_wcn3990_init.
>
> Changes in v11:
> * removed support to read regulator currents from dts.
> * updated review comments.
>
> Changes in v10:
> * added support to read regulator currents from dts.
> * added support to try to connect with chip if it fails to respond to
> initial commands
> * updated review comments.
>
> changes in v9:
> * moved flow control to vendor and set_baudarte functions.
> * removed parent regs.
>
> changes in v8:
> * closing qca buffer, if qca_power_setup fails
> * chnaged ibs start timer function call location.
> * updated review comments.
>
> changes in v7:
> * addressed review comments.
>
> changes in v6:
> * Hooked up qca_power to qca_serdev.
> * renamed all the naming inconsistency functions with qca_*
> * leveraged common code of ROME for wcn3990.
> * created wrapper functions for re-usable blocks.
> * updated function of _*regulator_enable and _*regualtor_disable.
> * removed redundant comments and functions.
> * addressed review comments.
>
> Changes in v5:
> * updated regulator vddpa min_uV to 1304000.
> * addressed review comments.
>
> Changes in v4:
> * Segregated the changes of btqca from hci_qca
> * rebased all changes on top of bluetooth-next.
> * addressed review comments.
>
> ---
> drivers/bluetooth/btqca.h | 3 +
> drivers/bluetooth/hci_qca.c | 404 +++-
> 2 files changed, 360 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> index a9c2779f3e07..0c01f375fe83 100644
> --- a/drivers/bluetooth/btqca.h
> +++ b/drivers/bluetooth/btqca.h
> @@ -37,6 +37,9 @@
> #define EDL_TAG_ID_HCI (17)
> #define EDL_TAG_ID_DEEP_SLEEP(27)
>
> +#define QCA_WCN3990_POWERON_PULSE0xFC
> +#define QCA_WCN3990_POWEROFF_PULSE 0xC0
> +
> enum qca_bardrate {
> QCA_BAUDRATE_115200 = 0,
> QCA_BAUDRATE_57600,
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index a6e7d38ef931..24ce42babe6d 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
>
> ...
>
> +static int qca_wcn3990_init(struct hci_uart *hu, u32 *soc_ver)
> +{
> + struct hci_dev *hdev = hu->hdev;
> + int ret;
> +
> + /* Forcefully enable wcn3990 to enter in to boot mode. */
> + host_set_baudrate(hu, 2400);
> + ret = qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE);
> + if (ret)
> + return ret;
> +
> + qca_set_speed(hu, QCA_INIT_SPEED);
> + ret = qca_send_power_pulse(hdev, QCA_WCN3990_POWERON_PULSE);
> + if (ret)
> + return ret;
> +
> + /* Wait for 100 ms for SoC to boot */
> + msleep(100);
> +
> + /* Now the device is in ready state to communicate with host.
> + * To sync host with device we need to reopen port.
> + * Without this, we will have RTS and CTS synchronization
> + * issues.
> + */
> + serdev_device_close(hu->serdev);
> + ret = serdev_device_open(hu->serdev);
> + if (ret) {
> + bt_dev_err(hu->hdev, "failed to open port");
> + return ret;
> + }
> +
> + hci_uart_set_flow_control(hu, false);
> + ret = qca_read_soc_version(hdev, soc_ver);
> +
> + return ret;
return qca_read_soc_version(hdev, soc_ver);
> +static int qca_power_setup(struct hci_uart *hu, bool on)
> +{
> + struct qca_vreg *vregs;
> + struct regulator_bulk_data *vreg_bulk;
> + struct qca_serdev *qcadev;
> + int i, num_vregs, ret = 0;
> +
> + qcadev = serdev_device_get_drvdata(hu->serdev);
> + if (!qcadev || !qcadev->bt_power || !qcadev->bt_power->vreg_data ||
> + !qcadev->bt_power->vreg_bulk)
> + return -EINVAL;
> +
> + vregs = qcadev->bt_power->vreg_data->vregs;
> + vreg_bulk = qcadev->bt_power->vreg_bulk;
> + num_vregs = qcadev->bt_power->vreg_data->num_vregs;
> + BT_DBG("on: %d", on);
> + if (on && !qcadev->bt_power->vregs_on) {
Remove extra blank after 'on'
Other than that:
Reviewed-by: Matthias Kaehlcke
Thanks for following through!
[PATCH 1/6] staging: rtl8188eu: use is_multicast_ether_addr
Use is_multicast_ether_addr instead of custom IS_MCAST in
os_dep/recv_linux.c.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/os_dep/recv_linux.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/recv_linux.c
b/drivers/staging/rtl8188eu/os_dep/recv_linux.c
index deadf26ea2aa..6f74f49bf3ab 100644
--- a/drivers/staging/rtl8188eu/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/recv_linux.c
@@ -84,11 +84,11 @@ int rtw_recv_indicatepkt(struct adapter *padapter,
struct sta_info *psta = NULL;
struct sta_priv *pstapriv = &padapter->stapriv;
struct rx_pkt_attrib *pattrib = &precv_frame->attrib;
- int bmcast = IS_MCAST(pattrib->dst);
+ bool mcast = is_multicast_ether_addr(pattrib->dst);
if (memcmp(pattrib->dst, myid(&padapter->eeprompriv),
ETH_ALEN)) {
- if (bmcast) {
+ if (mcast) {
psta = rtw_get_bcmc_stainfo(padapter);
pskb2 = skb_clone(skb, GFP_ATOMIC);
} else {
@@ -104,7 +104,7 @@ int rtw_recv_indicatepkt(struct adapter *padapter,
rtw_xmit_entry(skb, pnetdev);
- if (bmcast)
+ if (mcast)
skb = pskb2;
else
goto _recv_indicatepkt_end;
--
2.18.0
[PATCH 6/6] staging: rtl8188eu: remove whitespace, add missing blank line
Replace tabs with spaces and/or remove spaces where appropriate.
Add a missing blank line after declarations.
Also clears checkpatch warnings.
WARNING: Statements should start on a tabstop
WARNING: suspect code indent for conditional statements (8, 17)
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 37 ++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index 34c3e2af63c1..f12a12b19d3f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -18,7 +18,7 @@ static void _rtw_init_stainfo(struct sta_info *psta)
{
memset((u8 *)psta, 0, sizeof(struct sta_info));
-spin_lock_init(&psta->lock);
+ spin_lock_init(&psta->lock);
INIT_LIST_HEAD(&psta->list);
INIT_LIST_HEAD(&psta->hash_list);
_rtw_init_queue(&psta->sleep_q);
@@ -55,7 +55,7 @@ static void _rtw_init_stainfo(struct sta_info *psta)
#endif /* CONFIG_88EU_AP_MODE */
}
-u32_rtw_init_sta_priv(struct sta_priv *pstapriv)
+u32 _rtw_init_sta_priv(struct sta_priv *pstapriv)
{
struct sta_info *psta;
s32 i;
@@ -127,15 +127,15 @@ inline struct sta_info *rtw_get_stainfo_by_offset(struct
sta_priv *stapriv, int
return (struct sta_info *)(stapriv->pstainfo_buf + offset *
sizeof(struct sta_info));
}
-u32_rtw_free_sta_priv(struct sta_priv *pstapriv)
+u32 _rtw_free_sta_priv(struct sta_priv *pstapriv)
{
struct list_head *phead, *plist;
struct sta_info *psta = NULL;
struct recv_reorder_ctrl *preorder_ctrl;
- int index;
+ int index;
if (pstapriv) {
- /* delete all reordering_ctrl_timer*/
+ /* delete all reordering_ctrl_timer */
spin_lock_bh(&pstapriv->sta_hash_lock);
for (index = 0; index < NUM_STA; index++) {
phead = &pstapriv->sta_hash[index];
@@ -171,7 +171,7 @@ struct sta_info *rtw_alloc_stainfo(struct sta_priv
*pstapriv, u8 *hwaddr)
struct __queue *pfree_sta_queue;
struct recv_reorder_ctrl *preorder_ctrl;
int i = 0;
- u16 wRxSeqInitialValue = 0x;
+ u16 wRxSeqInitialValue = 0x;
pfree_sta_queue = &pstapriv->free_sta_queue;
@@ -243,14 +243,14 @@ struct sta_info *rtw_alloc_stainfo(struct sta_priv
*pstapriv, u8 *hwaddr)
}
/* using pstapriv->sta_hash_lock to protect */
-u32rtw_free_stainfo(struct adapter *padapter, struct sta_info *psta)
+u32 rtw_free_stainfo(struct adapter *padapter, struct sta_info *psta)
{
int i;
struct __queue *pfree_sta_queue;
struct recv_reorder_ctrl *preorder_ctrl;
- struct sta_xmit_priv *pstaxmitpriv;
- struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
- struct sta_priv *pstapriv = &padapter->stapriv;
+ struct sta_xmit_priv *pstaxmitpriv;
+ struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
+ struct sta_priv *pstapriv = &padapter->stapriv;
if (!psta)
goto exit;
@@ -376,9 +376,9 @@ u32 rtw_free_stainfo(struct adapter *padapter, struct
sta_info *psta)
void rtw_free_all_stainfo(struct adapter *padapter)
{
struct list_head *plist, *phead;
- s32 index;
+ s32 index;
struct sta_info *psta = NULL;
- struct sta_priv *pstapriv = &padapter->stapriv;
+ struct sta_priv *pstapriv = &padapter->stapriv;
struct sta_info *pbcmc_stainfo = rtw_get_bcmc_stainfo(padapter);
if (pstapriv->asoc_sta_count == 1)
@@ -407,7 +407,7 @@ struct sta_info *rtw_get_stainfo(struct sta_priv *pstapriv,
u8 *hwaddr)
{
struct list_head *plist, *phead;
struct sta_info *psta = NULL;
- u32 index;
+ u32 index;
u8 *addr;
u8 bc_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
@@ -443,10 +443,10 @@ struct sta_info *rtw_get_stainfo(struct sta_priv
*pstapriv, u8 *hwaddr)
u32 rtw_init_bcmc_stainfo(struct adapter *padapter)
{
- struct sta_info *psta;
+ struct sta_info *psta;
u32 res = _SUCCESS;
unsigned char bcast_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff,
0xff};
- struct sta_priv *pstapriv = &padapter->stapriv;
+ struct sta_priv *pstapriv = &padapter->stapriv;
psta = rtw_alloc_stainfo(pstapriv, bcast_addr);
@@ -465,9 +465,10 @@ u32 rtw_init_bcmc_stainfo(struct adapter *padapter)
struct sta_info *rtw_get_bcmc_stainfo(struct adapter *padapter)
{
- struct sta_priv *pstapriv = &padapter->stapriv;
+ struct sta_priv *pstapriv = &padapter->stapriv;
u8 bc_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-return rtw_get_stainfo(pstapriv, bc_addr);
+
+ return rtw_get_stainfo(pstapriv, bc_addr);
}
u8 rtw_access_ctrl(struct adapter *pad
[PATCH 2/6] staging: rtl8188eu: use is_multicast_ether_addr
Use is_multicast_ether_addr instead of custom IS_MCAST in
hal/rtl8188eu_xmit.c.
There is only one use, so remove the extra variable for the
result of IS_MCAST.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 14622eee56ca..82fc5075e0a6 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -167,7 +167,6 @@ static s32 update_txdesc(struct xmit_frame *pxmitframe, u8
*pmem, s32 sz, u8 bag
struct tx_desc *ptxdesc = (struct tx_desc *)pmem;
struct mlme_ext_priv*pmlmeext = &adapt->mlmeextpriv;
struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
- int bmcst = IS_MCAST(pattrib->ra);
if (adapt->registrypriv.mp_mode == 0) {
if ((!bagg_pkt) && (urb_zero_packet_chk(adapt, sz) == 0)) {
@@ -186,7 +185,7 @@ static s32 update_txdesc(struct xmit_frame *pxmitframe, u8
*pmem, s32 sz, u8 bag
ptxdesc->txdw0 |= cpu_to_le32(((offset) << OFFSET_SHT) & 0x00ff);/*
32 bytes for TX Desc */
- if (bmcst)
+ if (is_multicast_ether_addr(pattrib->ra))
ptxdesc->txdw0 |= cpu_to_le32(BMC);
if (adapt->registrypriv.mp_mode == 0) {
--
2.18.0
[PATCH 5/6] staging: rtl8188eu: use is_multicast_ether_addr
Use is_multicast_ether_addr instead of custom IS_MCAST in core/rtw_sta_mgt.c. Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c index 53e518148ae5..34c3e2af63c1 100644 --- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c +++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c @@ -414,7 +414,7 @@ struct sta_info *rtw_get_stainfo(struct sta_priv *pstapriv, u8 *hwaddr) if (!hwaddr) return NULL; - if (IS_MCAST(hwaddr)) + if (is_multicast_ether_addr(hwaddr)) addr = bc_addr; else addr = hwaddr; -- 2.18.0
[PATCH 4/6] staging: rtl8188eu: remove whitespace - style
Replace tabs with spaces and/or remove spaces where appropriate.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/hal/rtl8188eu_xmit.c| 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 6925ec48dff1..a11bee16d070 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -15,7 +15,7 @@
s32 rtw_hal_init_xmit_priv(struct adapter *adapt)
{
- struct xmit_priv*pxmitpriv = &adapt->xmitpriv;
+ struct xmit_priv *pxmitpriv = &adapt->xmitpriv;
tasklet_init(&pxmitpriv->xmit_tasklet,
(void(*)(unsigned long))rtl8188eu_xmit_tasklet,
@@ -30,8 +30,8 @@ static u8 urb_zero_packet_chk(struct adapter *adapt, int sz)
static void rtl8188eu_cal_txdesc_chksum(struct tx_desc *ptxdesc)
{
- u16 *usptr = (u16 *)ptxdesc;
- u32 count = 16; /* (32 bytes / 2 bytes per XOR) => 16 times */
+ u16 *usptr = (u16 *)ptxdesc;
+ u32 count = 16; /* (32 bytes / 2 bytes per XOR) => 16 times */
u32 index;
u16 checksum = 0;
@@ -160,15 +160,15 @@ static void fill_txdesc_phy(struct pkt_attrib *pattrib,
__le32 *pdw)
static s32 update_txdesc(struct xmit_frame *pxmitframe, u8 *pmem, s32 sz, u8
bagg_pkt)
{
- int pull = 0;
- uintqsel;
+ int pull = 0;
+ uint qsel;
u8 data_rate, pwr_status, offset;
- struct adapter *adapt = pxmitframe->padapter;
- struct pkt_attrib *pattrib = &pxmitframe->attrib;
+ struct adapter *adapt = pxmitframe->padapter;
+ struct pkt_attrib *pattrib = &pxmitframe->attrib;
struct odm_dm_struct *odmpriv = &adapt->HalData->odmpriv;
- struct tx_desc *ptxdesc = (struct tx_desc *)pmem;
- struct mlme_ext_priv*pmlmeext = &adapt->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct tx_desc *ptxdesc = (struct tx_desc *)pmem;
+ struct mlme_ext_priv *pmlmeext = &adapt->mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
if (adapt->registrypriv.mp_mode == 0) {
if ((!bagg_pkt) && (urb_zero_packet_chk(adapt, sz) == 0)) {
@@ -328,7 +328,7 @@ static s32 update_txdesc(struct xmit_frame *pxmitframe, u8
*pmem, s32 sz, u8 bag
return pull;
}
-/* for non-agg data frame or management frame */
+/* for non-agg data frame or management frame */
static s32 rtw_dump_xframe(struct adapter *adapt, struct xmit_frame
*pxmitframe)
{
s32 ret = _SUCCESS;
--
2.18.0
[PATCH 3/6] staging: rtl8188eu: cleanup block comment - style
Cleanup a block comment to conform with kernel coding style.
Also cleans 'line over 80 characters' checkpatch warnings.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 82fc5075e0a6..6925ec48dff1 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -43,9 +43,11 @@ static void rtl8188eu_cal_txdesc_chksum(struct tx_desc
*ptxdesc)
ptxdesc->txdw7 |= cpu_to_le32(0x & checksum);
}
-/* Description: In normal chip, we should send some packet to Hw which will
be used by Fw */
-/* in FW LPS mode. The function is to fill the Tx
descriptor of this packets, then */
-/* Fw can tell Hw to send these packet derectly. */
+/*
+ * In normal chip, we should send some packet to Hw which will be used by Fw
+ * in FW LPS mode. The function is to fill the Tx descriptor of this packets,
+ * then Fw can tell Hw to send these packet derectly.
+ */
void rtl8188e_fill_fake_txdesc(struct adapter *adapt, u8 *desc, u32 BufferLen,
u8 ispspoll, u8 is_btqosnull)
{
struct tx_desc *ptxdesc;
--
2.18.0
