[PATCH v2] tty: rocket: Fix a kernel address leak in rp_ioctl
If the cmd is RCPK_GET_STRUCT, copy_to_user will copy
info to user space. As info->port.ops is the address of
a constant object rocket_port_ops (assigned in init_r_port),
a kernel address leakage happens.
This patch sets all the pointer fields to NULL before copy the
object to user space to avoid kernel address leakage.
Signed-off-by: Fuqian Huang
---
drivers/tty/rocket.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index b121d8f8f3d7..a7bcf44b61bd 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -1271,6 +1271,34 @@ static int get_version(struct r_port *info, struct
rocket_version __user *retver
return 0;
}
+static int get_struct(struct r_port *info, void *argp)
+{
+ struct r_port *new;
+ int ret = 0;
+
+ new = kzalloc(sizeof (struct r_port), GFP_KERNEL);
+ if (!new)
+ return -ENOMEM;
+ memcpy(new, info, sizeof (struct r_port));
+ new->port.tty = NULL;
+ new->port.itty = NULL;
+ new->port.ops = NULL;
+ new->port.client_ops = NULL;
+ memset(>port.open_wait.head, 0, sizeof (struct list_head));
+ memset(>port.delta_msr_wait.head, 0, sizeof (struct list_head));
+ memset(>port.mutex.wait_list, 0, sizeof (struct list_head));
+ memset(>port.buf_mutex.wait_list, 0, sizeof (struct list_head));
+ new->port.xmit_buf = NULL;
+ new->port.client_data = NULL;
+ new->ctlp = NULL;
+ new->xmit_buf = NULL;
+ memset(>write_mtx.wait_list, 0, sizeof (struct list_head));
+ if (copy_to_user(argp, new, sizeof (struct r_port)))
+ ret = -EFAULT;
+ kfree(new);
+ return ret;
+}
+
/* IOCTL call handler into the driver */
static int rp_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg)
@@ -1284,8 +1312,7 @@ static int rp_ioctl(struct tty_struct *tty,
switch (cmd) {
case RCKP_GET_STRUCT:
- if (copy_to_user(argp, info, sizeof (struct r_port)))
- ret = -EFAULT;
+ ret = get_struct(info, argp);
break;
case RCKP_GET_CONFIG:
ret = get_config(info, argp);
--
2.11.0
[PATCH] Staging: greybus: usb: Fixed a coding style error
Line was >80 characters.
Signed-off-by: Will Cunningham
---
drivers/staging/greybus/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/usb.c b/drivers/staging/greybus/usb.c
index 1c246c73a085..5b4cbec88159 100644
--- a/drivers/staging/greybus/usb.c
+++ b/drivers/staging/greybus/usb.c
@@ -169,8 +169,8 @@ static int gb_usb_probe(struct gbphy_device *gbphy_dev,
return -ENOMEM;
connection = gb_connection_create(gbphy_dev->bundle,
-
le16_to_cpu(gbphy_dev->cport_desc->id),
- NULL);
+ le16_to_cpu(gbphy_dev->cport_desc->id),
+ NULL);
if (IS_ERR(connection)) {
retval = PTR_ERR(connection);
goto exit_usb_put;
--
2.19.2
Re: WARNING in free_loaded_vmcs (2)
syzbot has bisected this bug to:
commit 8fcc4b5923af5de58b80b53a069453b135693304
Author: Jim Mattson
Date: Tue Jul 10 09:27:20 2018 +
kvm: nVMX: Introduce KVM_CAP_NESTED_STATE
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17fba63f20
start commit: 60c1f892 Merge tag 'dma-mapping-4.19-2' of git://git.infra..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1407a63f20
console output: https://syzkaller.appspot.com/x/log.txt?x=1007a63f20
kernel config: https://syzkaller.appspot.com/x/.config?x=4c7e83258d6e0156
dashboard link: https://syzkaller.appspot.com/bug?extid=01bc9e7a8a3f138b71cf
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a6513e40
Reported-by: syzbot+01bc9e7a8a3f138b7...@syzkaller.appspotmail.com
Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sun, Mar 31, 2019 at 6:08 AM Joel Fernandes wrote: > On Sun, Mar 31, 2019 at 04:34:57AM +0200, Jann Horn wrote: > > On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes > > wrote: > > > As I said I don't really care about "pidfd" solving any racing issues with > > > /proc//* accesses - because I still find it hard to imagine that the > > > pid > > > number can be reused easily from the time you know which to deal > > > with, > > > to the time when you want to read, say, the /proc//status file. > > > > There have been several Android security bugs related to PID reuse. > > Yes PID reuse will be a problem till we have pidfd_clone and > pidfd_send_signal (and any other pidfd related syscalls). I've never denied > PID reuse is *currently* a problem and the set of pidfd syscalls being > proposed are designed to avoid those. So I'm not fully sure what you mean. > Anyway, I would love to see those security bugs you mentioned if you could > point me to them. https://bugs.chromium.org/p/project-zero/issues/detail?id=851 "Android: racy getpidcon usage permits binder service replacement" https://bugs.chromium.org/p/project-zero/issues/detail?id=853 "Android: debuggerd mitigation bypass and infoleak" https://bugs.chromium.org/p/project-zero/issues/detail?id=1404 "Android: Hardware Service Manager Arbitrary Service Replacement due to getpidcon" https://bugs.chromium.org/p/project-zero/issues/detail?id=1406 "Android: Permission bypass in KeyStore service due to getpidcon" https://bugs.chromium.org/p/project-zero/issues/detail?id=1741 "Android: getpidcon() usage in hardware binder servicemanager permits ACL bypass" > > > I am yet > > > to see any real data to show that such overflow happens - you literally > > > need > > > 32k process deaths and forks in such a short time frame > > > > This seems very inaccurate to me. > > > > The time frame in which the PID has to wrap around is not the time > > between process death and use of the PID. It is the time between *the > > creation* of the old process and the use of the PID. Consider the > > following sequence of events: > > > > - process A starts with PID 1000 > > - some time passes in which some process repeatedly forks, with PIDs > > wrapping around to 999 > > - process B starts an attempt to access process A (using PID 1000) > > - process A dies > > - process C spawns with PID 1000 > > - process B accidentally accesses process C > > > > Also, it's probably worth clarifying that here, "processes" means "threads". > > > > If there are a lot of active processes, that reduces the number of > > times you have to clone() to get the PID to wrap around. > > Ok, that's fair and I take your point. But I wonder what access you're > talking about, is it killing the process? If yes, pidfd_clone + > pidfd_send_signal will solve that in the race free way without relying on the > PID number. Sure, given a pidfd_clone() syscall, as long as the parent of the process is giving you a pidfd for it and you don't have to deal with grandchildren created by fork() calls outside your control, that works. > Is it accessing /proc//? then see below. > > > and on 64-bit, that > > > number is really high > > > > Which number is really high on 64-bit? Checking on a walleye phone, > > pid_max is still only 32768: > > > > walleye:/ # cat /proc/sys/kernel/pid_max > > 32768 > > walleye:/ # > > Ok. I was talking about the theoretical limit of pid_max on a 64-bit > platform. But since we are talking about NOT relying on the PID number in the > first place, we can move on from this point. (pid_t is a signed 32-bit value, that's UAPI.) > > > that its not even an issue. And if this is really an > > > issue, then you can just open a handle to /proc/ at process creation > > > time and keep it around. If the is reused, you can still use > > > openat(2) > > > on that handle without any races. > > > > But not if you want to implement something like killall in a > > race-free way, for example. > > I am not at all talking about killing processes in your last quote of my > email above, I'm talking about access to /proc// files. > > As I said, at the time of process creation, you can obtain an fd by opening > /proc// and keep it open. Then you can do an openat(2) on that fd > without worrying at reuse, no? And then access all the files that way. Yeah, if you're the parent of a process with a termination signal, that works. > As for killall in Android. I don't think that "killing processes by name" is > relied on for the runtime operation of Android. That would be a very bad > idea. Low memory killer does not kill processes by name. It kills processes > by the PID number using kill(2) which we'd like to replace with > pidfd_send_signal. Yeah, I somehow lost context when replying to your mail here; sorry about that. I didn't mean to imply that this is a usecase on Android.
(.init.text+0x134): multiple definition of `plat_irq_setup'
Hi Takashi, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b5c8314f0ebadb6d8a9789cb2d646cbef8448073 commit: c97617a81a7616d49bc3700959e08c6c6f447093 ALSA: hda/ca0132 - Fix build error without CONFIG_PCI date: 8 weeks ago config: sh-allyesconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout c97617a81a7616d49bc3700959e08c6c6f447093 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=sh All errors (new ones prefixed by >>): arch/sh/boards/of-generic.o: In function `plat_irq_setup': >> (.init.text+0x134): multiple definition of `plat_irq_setup' arch/sh/kernel/cpu/sh2/setup-sh7619.o:(.init.text+0x30): first defined here arch/sh/boards/of-generic.o: In function `arch_init_clk_ops': >> (.init.text+0x118): multiple definition of `arch_init_clk_ops' arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.init.text+0x0): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sun, Mar 31, 2019 at 04:34:57AM +0200, Jann Horn wrote: > On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes wrote: > > As I said I don't really care about "pidfd" solving any racing issues with > > /proc//* accesses - because I still find it hard to imagine that the > > pid > > number can be reused easily from the time you know which to deal with, > > to the time when you want to read, say, the /proc//status file. > > There have been several Android security bugs related to PID reuse. Yes PID reuse will be a problem till we have pidfd_clone and pidfd_send_signal (and any other pidfd related syscalls). I've never denied PID reuse is *currently* a problem and the set of pidfd syscalls being proposed are designed to avoid those. So I'm not fully sure what you mean. Anyway, I would love to see those security bugs you mentioned if you could point me to them. > > I am yet > > to see any real data to show that such overflow happens - you literally need > > 32k process deaths and forks in such a short time frame > > This seems very inaccurate to me. > > The time frame in which the PID has to wrap around is not the time > between process death and use of the PID. It is the time between *the > creation* of the old process and the use of the PID. Consider the > following sequence of events: > > - process A starts with PID 1000 > - some time passes in which some process repeatedly forks, with PIDs > wrapping around to 999 > - process B starts an attempt to access process A (using PID 1000) > - process A dies > - process C spawns with PID 1000 > - process B accidentally accesses process C > > Also, it's probably worth clarifying that here, "processes" means "threads". > > If there are a lot of active processes, that reduces the number of > times you have to clone() to get the PID to wrap around. Ok, that's fair and I take your point. But I wonder what access you're talking about, is it killing the process? If yes, pidfd_clone + pidfd_send_signal will solve that in the race free way without relying on the PID number. Is it accessing /proc//? then see below. > > and on 64-bit, that > > number is really high > > Which number is really high on 64-bit? Checking on a walleye phone, > pid_max is still only 32768: > > walleye:/ # cat /proc/sys/kernel/pid_max > 32768 > walleye:/ # Ok. I was talking about the theoretical limit of pid_max on a 64-bit platform. But since we are talking about NOT relying on the PID number in the first place, we can move on from this point. > > that its not even an issue. And if this is really an > > issue, then you can just open a handle to /proc/ at process creation > > time and keep it around. If the is reused, you can still use openat(2) > > on that handle without any races. > > But not if you want to implement something like killall in a > race-free way, for example. I am not at all talking about killing processes in your last quote of my email above, I'm talking about access to /proc// files. As I said, at the time of process creation, you can obtain an fd by opening /proc// and keep it open. Then you can do an openat(2) on that fd without worrying at reuse, no? And then access all the files that way. As for killall in Android. I don't think that "killing processes by name" is relied on for the runtime operation of Android. That would be a very bad idea. Low memory killer does not kill processes by name. It kills processes by the PID number using kill(2) which we'd like to replace with pidfd_send_signal. Again if you want to convince Linus about having a "pidfd to procfd" conversion mechanism, then by all means go for it. I just don't think it is urgently necessary (and others may disagree with me on this), but I wouldn't care if such a mechanism existed either. Whatever we do, I just want the notion of "pidfd" to be consistent as I mentioned in my previous email. thank you! - Joel
Re: [PATCH v2] irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init()
Acked-by: Jiaxun Yang
Thanks!
--
Jiaxun Yang
在 2019/3/29 14:21, Dan Carpenter 写道:
Currently, when irq_domain_add_linear() fails, the error code does not
get so it returns zero which is wrong. Fix it by setting appropriate
error code.
Fixes: 9e543e22e204 ("irqchip: Add driver for Loongson-1 interrupt controller")
Signed-off-by: Dan Carpenter
Reviewed-by: Mukesh Ojha
---
V2: Improve the commit message
drivers/irqchip/irq-ls1x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-ls1x.c b/drivers/irqchip/irq-ls1x.c
index 86b72fbd3b45..353111a10413 100644
--- a/drivers/irqchip/irq-ls1x.c
+++ b/drivers/irqchip/irq-ls1x.c
@@ -130,6 +130,7 @@ static int __init ls1x_intc_of_init(struct device_node
*node,
NULL);
if (!priv->domain) {
pr_err("ls1x-irq: cannot add IRQ domain\n");
+ err = -ENOMEM;
goto out_iounmap;
}
Re: fs/coda oops bisected to (925b9cd1b8) "locking/rwsem: Make owner store task pointer of last owni
On Fri, Mar 29, 2019 at 05:53:22PM +, Waiman Long wrote:
> On 03/29/2019 12:10 PM, Jan Harkes wrote:
> > I knew I definitely had never seen this problem with the stable kernel
> > on Ubuntu xenial (4.4) so I bisected between v4.4 and v5.1-rc2 and ended
> > up at
> >
> > # first bad commit: [925b9cd1b89a94b7124d128c80dfc48f78a63098]
> > # locking/rwsem: Make owner store task pointer of last owning reader
> >
> > When I revert this particular commit on 5.1-rc2, I am not able to
> > reproduce the problem anymore.
>
> Without CONFIG_DEBUG_RWSEMS, the only behavioral change of this patch is
> to do an unconditional write of task_structure pointer into sem->owner
> after acquiring the read lock in down_read(). Before this patch, it does
I tried with just that change, but that is not at fault. It is also hard
to believe we have a use-after-free issue, because we are using a
spinlock on the inode that is held in place by the file we are releasing.
After trying various variations the minimal change that fixes the soft
lockup is as follows. Without this patch I get a reliable lockup, with
the patch everything works as expected.
diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
index bad2bca..0cc437d 100644
--- a/kernel/locking/rwsem.h
+++ b/kernel/locking/rwsem.h
@@ -61,8 +61,7 @@ static inline void rwsem_clear_owner(struct rw_semaphore
*sem)
static inline void __rwsem_set_reader_owned(struct rw_semaphore *sem,
struct task_struct *owner)
{
- unsigned long val = (unsigned long)owner | RWSEM_READER_OWNED
-| RWSEM_ANONYMOUSLY_OWNED;
+ unsigned long val = RWSEM_READER_OWNED | RWSEM_ANONYMOUSLY_OWNED;
WRITE_ONCE(sem->owner, (struct task_struct *)val);
}
I'll continue digging if I can find a reason why. So far I've only found
one place where rwsem->owner is modified while not holding a lock, but
changing that doesn't make a difference for my particular case.
diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 03cb4b6f842e..fe696a8b57f3 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -114,11 +114,11 @@ extern void percpu_free_rwsem(struct
percpu_rw_semaphore *);
static inline void percpu_rwsem_release(struct percpu_rw_semaphore *sem,
bool read, unsigned long ip)
{
- lock_release(>rw_sem.dep_map, 1, ip);
#ifdef CONFIG_RWSEM_SPIN_ON_OWNER
if (!read)
sem->rw_sem.owner = RWSEM_OWNER_UNKNOWN;
#endif
+ lock_release(>rw_sem.dep_map, 1, ip);
}
static inline void percpu_rwsem_acquire(struct percpu_rw_semaphore *sem,
Jan
[PATCH] dt-bindings: arm: correct dt_binding_check parse error
'make dt_binding_check' fails with the following error:
Documentation/devicetree/bindings/arm/cpus.yaml: while scanning a
plain scalar
in "", line 231, column 19
found a tab character that violates indentation
in "", line 232, column 1
make[1]: *** [Documentation/devicetree/bindings/Makefile:12:
Documentation/devicetree/bindings/arm/cpus.example.dts] Error 1
Correct the parse error by replacing the tabs with spaces to keep
'make dt_binding_check' happy.
Signed-off-by: Brian Masney
Fixes: fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for Milbeaut")
---
Issue is in linux-next-20190329.
Documentation/devicetree/bindings/arm/cpus.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml
b/Documentation/devicetree/bindings/arm/cpus.yaml
index 60eab6dc3c0b..591bbd012d63 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -229,7 +229,7 @@ patternProperties:
- renesas,r9a06g032-smp
- rockchip,rk3036-smp
- rockchip,rk3066-smp
- - socionext,milbeaut-m10v-smp
+- socionext,milbeaut-m10v-smp
- ste,dbx500-smp
cpu-release-addr:
--
2.20.1
[GIT PULL]: dmaengine fixes v5.1-rc3
Hi Linus, Here is the pull request fro v5.1-rc3. This includes revery of patch due to reported regression and fix on MAINTAINER file for uniphier-mdmac.c file path. The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-5.1-rc3 for you to fetch changes up to d498bc0ce8acb4a1bb80d6089d1932d919dc2532: MAINTAINERS: Fix uniphier-mdmac.c file path (2019-03-26 10:55:47 +0530) dmaengine-5.10-rc3 dmaengine fixes for v5.10-rc3 - Revert dmaengine: stm32-mdma: Add a check on read_u32_array as that caused regression - Fix MAINTAINER file uniphier-mdmac.c file path Pierre-Yves MORDRET (1): dmaengine: stm32-mdma: Revert "dmaengine: stm32-mdma: Add a check on read_u32_array" Vinod Koul (1): MAINTAINERS: Fix uniphier-mdmac.c file path MAINTAINERS | 2 +- drivers/dma/stm32-mdma.c | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) Thanks -- ~Vinod
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes wrote: > As I said I don't really care about "pidfd" solving any racing issues with > /proc//* accesses - because I still find it hard to imagine that the pid > number can be reused easily from the time you know which to deal with, > to the time when you want to read, say, the /proc//status file. There have been several Android security bugs related to PID reuse. > I am yet > to see any real data to show that such overflow happens - you literally need > 32k process deaths and forks in such a short time frame This seems very inaccurate to me. The time frame in which the PID has to wrap around is not the time between process death and use of the PID. It is the time between *the creation* of the old process and the use of the PID. Consider the following sequence of events: - process A starts with PID 1000 - some time passes in which some process repeatedly forks, with PIDs wrapping around to 999 - process B starts an attempt to access process A (using PID 1000) - process A dies - process C spawns with PID 1000 - process B accidentally accesses process C Also, it's probably worth clarifying that here, "processes" means "threads". If there are a lot of active processes, that reduces the number of times you have to clone() to get the PID to wrap around. > and on 64-bit, that > number is really high Which number is really high on 64-bit? Checking on a walleye phone, pid_max is still only 32768: walleye:/ # cat /proc/sys/kernel/pid_max 32768 walleye:/ # > that its not even an issue. And if this is really an > issue, then you can just open a handle to /proc/ at process creation > time and keep it around. If the is reused, you can still use openat(2) > on that handle without any races. But not if you want to implement something like killall in a race-free way, for example.
'reg: property has invalid length' with new JSON-schema bindings
Hi Rob,
I'm finishing up a patch series that adds device tree support for a
backlight driver and I made the bindings use the new JSON schema. I'm
running into a problem with the reg property in the examples and I can
reproduce the issue by adding an example to the trivial bindings:
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml
b/Documentation/devicetree/bindings/trivial-devices.yaml
index d79fb22bde39..bdab6a015db4 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -341,4 +341,10 @@ required:
- compatible
- reg
+examples:
+ - |
+isl29028@38 {
+compatible = "isil,isl29028";
+reg = <0x38>;
+};
...
'make dt_binding_check' fails with the following error:
Documentation/devicetree/bindings/trivial-devices.example.dts:11.5-18:
Warning (reg_format): /isl29028@38:reg: property has invalid length
(4 bytes) (#address-cells == 1, #size-cells == 1)
...
Documentation/devicetree/bindings/trivial-devices.example.dtb:
Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
I see that dt-extract-example hard codes those two cell values to 1:
https://github.com/robherring/yaml-bindings/blob/master/tools/dt-extract-example
The I2C buses for my board (qcom-msm8974) sets #size-cells to 0. Do you
have any suggestions for how I can correct this issue? I can make the
binding check happy by adding a length (reg = <0x38 0x4>;) but I assume
that we shouldn't do that for I2C addresses like this.
Brian
Re: BUG: MAX_STACK_TRACE_ENTRIES too low! (2)
On 3/30/19 2:58 PM, syzbot wrote:
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f1bacd20
start commit: 0e40da3e Merge tag 'kbuild-fixes-v5.1' of
git://git.kernel..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=1409bacd20
console output: https://syzkaller.appspot.com/x/log.txt?x=1009bacd20
kernel config: https://syzkaller.appspot.com/x/.config?x=8dcdce25ea72bedf
dashboard link:
https://syzkaller.appspot.com/bug?extid=6f39a9deb697359fe520
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e1bacd20
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1120fe0f20
Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
workqueues")
For information about bisection process see:
https://goo.gl/tpsmEJ#bisection
Hi Dmitry,
This bisection result doesn't make sense to me. As one can see, the
message "BUG: MAX_STACK_TRACE_ENTRIES too low!" does not occur in the
console output the above console output URL points at.
Bart.
Re: [PATCH 0/2] Add Updown Counter support for Milbeaut M10V SoC
On Sat, Mar 30, 2019 at 06:36:03PM +, Jonathan Cameron wrote: > On Tue, 26 Mar 2019 15:32:34 +0900 > Shinji Kanematsu wrote: > > > This is a series of patch which adds Updown Counter support on > > Milbeaut M10V SoC. > > > > The Updown Counter counts input pulse signal from external quadrature > > encoder. > > It also has input pulse signal counter function. > Hi Shinji, > > Are you aware of the counter subsystem that has been proposed (and > as far as I am concerned is ready to be merged)? > > https://patchwork.kernel.org/project/linux-iio/list/?series=147 > (I think that's the latest version posted).. > William, perhaps you could give an update? > > (bad luck, you are getting popular ;) > > I'll take a quick review as it stands, as some issues may carry over. > I appreciate that it's always unfortunate to try to upstream stuff at the > same time as a new framework is being developed / upstreamed, but I don't > intend to take any additional counter drivers into IIO. We just > end up having to maintain old interfaces in more and more drivers. > > Thanks, > > Jonathan Shinji, If you reimplement this driver to use the new Generic Counter API, I can pick it up and include it with my next patchset submission. Please base your patches ontop of the "generic_counter_v10" branch from my personal repository: https://gitlab.com/vilhelmgray/iio/commits/generic_counter_v10 Documentation can be found at: Documentation/driver-api/generic-counter.rst Documentation/ABI/testing/sysfs-bus-counter Look at the existing drivers inside the drivers/counter directory to serve as references: drivers/counter/ftm-quaddec.c drivers/counter/stm32-timer-cnt.c If you have any troubles or difficulties with the API, send me a message and I will be happy to help. :-) Thank you, William Breathitt Gray > > > > > Shinji Kanematsu (2): > > dt-bindings: iio: counter: Add Milbeaut Updown Counter > > iio: counter: Add support for Milbeaut Updown Counter > > > > .../bindings/iio/counter/milbeaut-updown_cnt.txt | 22 ++ > > drivers/iio/counter/Kconfig| 12 + > > drivers/iio/counter/Makefile | 1 + > > drivers/iio/counter/milbeaut-updown.h | 38 ++ > > drivers/iio/counter/milbeaut-updown_cnt.c | 385 > > + > > 5 files changed, 458 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt > > create mode 100644 drivers/iio/counter/milbeaut-updown.h > > create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c > > >
MTCN#: 2501757333
-- Attn E-mail Address Owner,Website: www.westernunion.com Address: Plot 1261, Adela Hopewell Street CO/B/REP, Republic Of Benin . Contact person: . Mrs. Joy Isa Email: ((westernunion...@gmail.com) We have concluded to effect your total payment of $4.5m USD through Western Union Money Transfer, $5,000 daily until the total sum of your compensation fund is transferred to you. This is your first payment information: MTCN#: 2501757333 Sender's First Name: Alian Sender's Last Name: Evans Text Question: Code? Answer? Amount Programmed: $5.000 Track your first payment on-line nowhttps://www.westernunion.com/global-service/track-transfer 1.Your Full Name_ 2.Your Home AND Address__ 3.Your Phone and Cell Number 4.A Copy of Your Picture 5.Your Age/Sex__ 6.Your Country_ 7.Your Occupation_ You are advised to get back to the contact person through the email address below for more direction on how to be receiving your payment Contact person: . Mrs.Joy Isa Email address: (westernunion...@gmail.com Thanks, Mrs. Joy Isa Director Western Union Money Transfer Head Office Benin Republic.
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 09:18:12AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 9:16 AM Linus Torvalds
> wrote:
> >
> > And no, we are *NOT* making pidfd_open() into some "let's expose /proc
> > even when it's not mounted" horror. Seriously. That's disgusting,
> > wrong, insecure and stupid.
>
> And btw, this is not debatable. In fact, this whole discussion is
> making me feel like I should just revert pidfd, not because the code I
> merged is wrong, but because people are clearly intending to do
> completely inappropriate things with this.
>
> Get your act together. Stop hacking up garbage.
>
>Linus
I am supportive of Linus's view of keeping /proc separate from pidfd. I
didn't really care about "pidfd" solving any racing issues with /proc//*
access. My main interest in pidfd is because we can implement "waiting"
semantics in the future using something like a pidfd_wait call, which solves
one of the issues of Android's low-memory where it needs to be notified as
quickly as possible about a non-child process's death. Android Low memory
killer right now just keeps checking for /proc/ 's existence which is
slow and more CPU intense for this.
As I said I don't really care about "pidfd" solving any racing issues with
/proc//* accesses - because I still find it hard to imagine that the pid
number can be reused easily from the time you know which to deal with,
to the time when you want to read, say, the /proc//status file. I am yet
to see any real data to show that such overflow happens - you literally need
32k process deaths and forks in such a short time frame, and on 64-bit, that
number is really high that its not even an issue. And if this is really an
issue, then you can just open a handle to /proc/ at process creation
time and keep it around. If the is reused, you can still use openat(2)
on that handle without any races.
What I think will be most immediately valuable for Android in my opinion is
the pidfd_open() and pidfd_send_signal() syscalls, along with the future
pidfd_wait() that we're working on to solve the issue with Android's Low
memory killer I mentioned above.
Now, in relation to Daniel's concern with procfs, I feel we need to be clear
what is the meaning of a "pidfd" and it should consistently work across all
APIs no matter how pidfd is obtained. There shouldn't be like "if you obtain
pidfd using this method and it only works with these APIs", that's just plain
wrong IMO.
For example: with pidfd_open() or whatever that ends up being called is
available, the pidfd obtained is not tied to /proc. However, if one obtained
a pidfd using open("/proc//", ..), then that pidfd *is* tied to /proc.
pidfd_send_signal will happily work on this "pidfd". Both these methods of
obtainings pidfd(s) make openat(2) work on them inconsistently. In one case
openat(2) fails, and in the other case it succeeds. I feel there should be no
ambiguity between how "pidfd" works with openat(2). Either make openat(2)
never work on any "pidfd", or always make it work on it.
I would say, don't call a /proc/ file descriptor as a "pidfd". Next, to
remedy all this, I feel pidfd_send_signal *should not* work on fds that are
obtained by opening of /proc/ if we can agree those are not pidfds.
Only the ones obtained using the proposed pidfd_open (or pidfd_clone) should
be allowed to be used with pidfd_send_signal.
So I believe the call to tgid_pidfd_to_pid() from pidfd_to_pid in Christian's
patch 3/5 needs to go away.
+static struct pid *pidfd_to_pid(const struct file *file)
+{
+ if (file->f_op == _fops)
+ return file->private_data;
+
+ return tgid_pidfd_to_pid(file); < Should just return error
+}
+
I agree with Christian that lets not put pidfd_send_signal at risk. Let us
make the notion of a pidfd and the APIs that work on it *consistent* and make
it do just what we really need for our usescases. Which for Android, is,
pidfd_open/clone, pidfd_send_signal and pidfd_wait. I hope I added some
clarity around the usecases.
thanks,
- Joel
Re:Hello
Hello this is Mr Wong again from hongkong,Can we send the Swift as discuss best regards. Mr Wong Cheng --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH] PCI: mediatek: get optional clock by devm_clk_get_optional()
On Sat, 2019-03-30 at 18:00 +0800, Chunfeng Yun wrote:
> Use devm_clk_get_optional() to get optional clock
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/pci/controller/pcie-mediatek.c | 46 ++
> 1 file changed, 11 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c
> b/drivers/pci/controller/pcie-mediatek.c
> index 0b6c72804e03..9a66a018489b 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -915,49 +915,25 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>
> /* sys_ck might be divided into the following parts in some chips */
> snprintf(name, sizeof(name), "ahb_ck%d", slot);
> - port->ahb_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->ahb_ck)) {
> - if (PTR_ERR(port->ahb_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->ahb_ck = NULL;
> - }
> + port->ahb_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->ahb_ck))
> + return PTR_ERR(port->ahb_ck);
>
> snprintf(name, sizeof(name), "axi_ck%d", slot);
> - port->axi_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->axi_ck)) {
> - if (PTR_ERR(port->axi_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->axi_ck = NULL;
> - }
> + port->axi_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->axi_ck);
>
> snprintf(name, sizeof(name), "aux_ck%d", slot);
> - port->aux_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->aux_ck)) {
> - if (PTR_ERR(port->aux_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->aux_ck = NULL;
> - }
> + port->aux_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->aux_ck);
>
> snprintf(name, sizeof(name), "obff_ck%d", slot);
> - port->obff_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->obff_ck)) {
> - if (PTR_ERR(port->obff_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->obff_ck = NULL;
> - }
> + port->obff_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->obff_ck);
>
> snprintf(name, sizeof(name), "pipe_ck%d", slot);
> - port->pipe_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->pipe_ck)) {
> - if (PTR_ERR(port->pipe_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->pipe_ck = NULL;
> - }
> + port->pipe_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->pipe_ck);
>
Hi, Chunfeng,
Thanks for this patch, I had not noticed that the devm_clk_get_optional
have been applied, I like this change.
Acked-by: Honghui Zhang
> snprintf(name, sizeof(name), "pcie-rst%d", slot);
> port->reset = devm_reset_control_get_optional_exclusive(dev, name);
Re: [PATCH v2 1/4] cpufreq: mediatek: add mt8183 cpufreq support
On Thu, Mar 28, 2019 at 11:46 PM Andrew-sh.Cheng
wrote:
>
> For new mediatek chip mt8183,
> cci and little cluster share the same buck,
> so need to modify the attribute of regulator from exclusive to optional
>
> Intermediate clock is not always enabled by ccf in different projects,
> so cpufreq should always enable it by itself.
One comment, otherwise the changes look good. However, I feel that
this patch should be split in 3:
1. Change to regulator_get_optional
2. Enable inter_clk
3. Add support for 8183
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> drivers/cpufreq/mediatek-cpufreq.c | 12 ++--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 47729a2..53ea52b 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -117,6 +117,7 @@
> { .compatible = "mediatek,mt817x", },
> { .compatible = "mediatek,mt8173", },
> { .compatible = "mediatek,mt8176", },
> + { .compatible = "mediatek,mt8183", },
>
> { .compatible = "nvidia,tegra124", },
> { .compatible = "nvidia,tegra210", },
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> b/drivers/cpufreq/mediatek-cpufreq.c
> index 48e9829..7cd01d3 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -346,7 +346,7 @@ static int mtk_cpu_dvfs_info_init(struct
> mtk_cpu_dvfs_info *info, int cpu)
> goto out_free_resources;
> }
>
> - proc_reg = regulator_get_exclusive(cpu_dev, "proc");
> + proc_reg = regulator_get_optional(cpu_dev, "proc");
> if (IS_ERR(proc_reg)) {
> if (PTR_ERR(proc_reg) == -EPROBE_DEFER)
> pr_warn("proc regulator for cpu%d not ready,
> retry.\n",
> @@ -376,13 +376,17 @@ static int mtk_cpu_dvfs_info_init(struct
> mtk_cpu_dvfs_info *info, int cpu)
> goto out_free_resources;
> }
>
> + ret = clk_prepare_enable(inter_clk);
Should you disable the clock in mtk_cpu_dvfs_info_release?
> + if (ret)
> + goto out_free_opp_table;
> +
> /* Search a safe voltage for intermediate frequency. */
> rate = clk_get_rate(inter_clk);
> opp = dev_pm_opp_find_freq_ceil(cpu_dev, );
> if (IS_ERR(opp)) {
> pr_err("failed to get intermediate opp for cpu%d\n", cpu);
> ret = PTR_ERR(opp);
> - goto out_free_opp_table;
> + goto out_disable_clock;
> }
> info->intermediate_voltage = dev_pm_opp_get_voltage(opp);
> dev_pm_opp_put(opp);
> @@ -401,6 +405,9 @@ static int mtk_cpu_dvfs_info_init(struct
> mtk_cpu_dvfs_info *info, int cpu)
>
> return 0;
>
> +out_disable_clock:
> + clk_disable_unprepare(inter_clk);
> +
> out_free_opp_table:
> dev_pm_opp_of_cpumask_remove_table(>cpus);
>
> @@ -543,6 +550,7 @@ static int mtk_cpufreq_probe(struct platform_device *pdev)
> { .compatible = "mediatek,mt817x", },
> { .compatible = "mediatek,mt8173", },
> { .compatible = "mediatek,mt8176", },
> + { .compatible = "mediatek,mt8183", },
>
> { }
> };
> --
> 1.8.1.1.dirty
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2] gcov: fix when CONFIG_MODULES is not set
On Fri, Mar 29, 2019 at 1:53 PM Randy Dunlap wrote:
>
> On 3/29/19 11:18 AM, Nick Desaulniers wrote:
> > Fixes commit 8c3d220cb6b5 ("gcov: clang support")
>
> There is a certain format for Fixes: and that's not quite it. :(
>
> > Cc: Greg Hackmann
> > Cc: Tri Vo
> > Cc: Peter Oberparleiter
> > Cc: linux...@kvack.org
> > Cc: kbuild-...@01.org
> > Reported-by: Randy Dunlap
> > Reported-by: kbuild test robot
> > Link: https://marc.info/?l=linux-mm=155384681109231=2
> > Signed-off-by: Nick Desaulniers
>
> Acked-by: Randy Dunlap # build-tested
>
> Thanks.
>
> > ---
> > kernel/gcov/gcc_3_4.c | 4
> > kernel/gcov/gcc_4_7.c | 4
> > 2 files changed, 8 insertions(+)
Thanks for taking a look at this Nick! I believe same fix should be
applied to kernel/gcov/clang.c. I'll send out an updated version later
today.
Re: [RFCv2] string: Use faster alternatives when constant arguments are used
On Mon, Mar 25, 2019 at 10:24:00PM +0100, Rasmus Villemoes wrote: > What I'm worried about is your patch changing every single strcmp(, > "literal") into a memcmp, with absolutely no way of knowing or checking > anything about the other buffer. And actually, it doesn't have to be a > BE arch with a word-at-a-time memcmp. > If (as is usually the case) the strcmp() result is compared to zero, after you > change > > !strcmp(buf, "literal") > > into > > !memcmp(buf, "literal", 8) > > the compiler may (exactly as you want it to) change that into a single > 8-byte load (or two 4-byte loads) and comparisons to literals, no > memcmp() involved. And how do you know that _that_ is ok, for every one > of the hundreds, if not thousands, of instances in the tree? When would this not be ok though? From what I've always known, strcmp(terminated_buf1, terminated_buf2) is equivalent to memcmp(terminated_buf1, terminated_buf2, strlen(terminated_buf1)) and memcmp(terminated_buf1, terminated_buf2, strlen(terminated_buf2)) regardless of whether or not one side is a literal (my patch just leverages the compiler's ability to recognize strlen called on literals and optimize it out). The latter memcmp instances would indeed perform worse than the first strcmp when neither arguments are literals, but I don't see what makes the memcmp usage "dangerous". How can the memcmps cross a page boundary when memcmp itself will only read in large buffers of data at word boundaries? And if there are concerns for some arches but not others, then couldn't this be a feasible optimization for those which would work well with it? Sultan
[PATCH v2] ARCH: Use the correct style for SPDX License Identifier
This patch corrects the SPDX License Identifier style in the Hardware Architecture subsystem. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 and making some manual changes. Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar --- Changes in v2: - Added a note in the patch description. --- arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 2 +- arch/arm64/include/asm/pointer_auth.h | 2 +- arch/arm64/include/asm/sdei.h | 2 +- arch/arm64/include/asm/vmap_stack.h | 2 +- arch/nds32/include/asm/assembler.h| 2 +- arch/nds32/include/asm/barrier.h | 2 +- arch/nds32/include/asm/bitfield.h | 2 +- arch/nds32/include/asm/cache.h| 2 +- arch/nds32/include/asm/cache_info.h | 2 +- arch/nds32/include/asm/cacheflush.h | 2 +- arch/nds32/include/asm/current.h | 2 +- arch/nds32/include/asm/delay.h| 2 +- arch/nds32/include/asm/elf.h | 2 +- arch/nds32/include/asm/fixmap.h | 2 +- arch/nds32/include/asm/futex.h| 2 +- arch/nds32/include/asm/highmem.h | 2 +- arch/nds32/include/asm/io.h | 2 +- arch/nds32/include/asm/irqflags.h | 2 +- arch/nds32/include/asm/l2_cache.h | 2 +- arch/nds32/include/asm/linkage.h | 2 +- arch/nds32/include/asm/memory.h | 2 +- arch/nds32/include/asm/mmu.h | 2 +- arch/nds32/include/asm/mmu_context.h | 2 +- arch/nds32/include/asm/module.h | 2 +- arch/nds32/include/asm/nds32.h| 2 +- arch/nds32/include/asm/page.h | 2 +- arch/nds32/include/asm/pgalloc.h | 2 +- arch/nds32/include/asm/pgtable.h | 2 +- arch/nds32/include/asm/proc-fns.h | 2 +- arch/nds32/include/asm/processor.h| 2 +- arch/nds32/include/asm/ptrace.h | 2 +- arch/nds32/include/asm/shmparam.h | 2 +- arch/nds32/include/asm/string.h | 2 +- arch/nds32/include/asm/swab.h | 2 +- arch/nds32/include/asm/syscall.h | 2 +- arch/nds32/include/asm/syscalls.h | 2 +- arch/nds32/include/asm/thread_info.h | 2 +- arch/nds32/include/asm/tlb.h | 2 +- arch/nds32/include/asm/tlbflush.h | 2 +- arch/nds32/include/asm/uaccess.h | 2 +- arch/nds32/include/asm/unistd.h | 2 +- arch/nds32/include/asm/vdso.h | 2 +- arch/nds32/include/asm/vdso_datapage.h| 2 +- arch/nds32/include/asm/vdso_timer_info.h | 2 +- arch/nds32/include/uapi/asm/auxvec.h | 2 +- arch/nds32/include/uapi/asm/byteorder.h | 2 +- arch/nds32/include/uapi/asm/cachectl.h| 2 +- arch/nds32/include/uapi/asm/param.h | 2 +- arch/nds32/include/uapi/asm/ptrace.h | 2 +- arch/nds32/include/uapi/asm/sigcontext.h | 2 +- arch/nds32/include/uapi/asm/unistd.h | 2 +- arch/powerpc/include/asm/pnv-ocxl.h | 2 +- arch/sh/drivers/pci/pci-sh5.h | 4 ++-- arch/sh/drivers/pci/pci-sh7751.h | 4 ++-- arch/sh/drivers/pci/pci-sh7780.h | 4 ++-- arch/sh/drivers/pci/pcie-sh7786.h | 4 ++-- arch/sh/include/asm/addrspace.h | 4 ++-- arch/sh/include/asm/bl_bit_64.h | 4 ++-- arch/sh/include/asm/cache_insns_64.h | 4 ++-- arch/sh/include/asm/device.h | 4 ++-- arch/sh/include/asm/dma-register.h| 4 ++-- arch/sh/include/asm/dma.h | 4 ++-- arch/sh/include/asm/dwarf.h | 4 ++-- arch/sh/include/asm/fixmap.h | 4 ++-- arch/sh/include/asm/flat.h| 4 ++-- arch/sh/include/asm/freq.h| 4 ++-- arch/sh/include/asm/gpio.h| 4 ++-- arch/sh/include/asm/machvec.h | 4 ++-- arch/sh/include/asm/pgtable.h | 4 ++-- arch/sh/include/asm/sfp-machine.h | 4 ++-- arch/sh/include/asm/shmparam.h| 4 ++-- arch/sh/include/asm/siu.h | 4 ++-- arch/sh/include/asm/spinlock-cas.h| 4 ++-- arch/sh/include/asm/spinlock-llsc.h | 4 ++-- arch/sh/include/asm/spinlock.h| 4 ++-- arch/sh/include/asm/switch_to.h | 4 ++-- arch/sh/include/asm/switch_to_64.h| 4
[PATCH v2] ARCH: Use the correct style for SPDX License Identifier
This patch corrects the SPDX License Identifier style in the Hardware Architecture subsystem. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 and making some manual changes. Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar --- arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 2 +- arch/arm64/include/asm/pointer_auth.h | 2 +- arch/arm64/include/asm/sdei.h | 2 +- arch/arm64/include/asm/vmap_stack.h | 2 +- arch/nds32/include/asm/assembler.h| 2 +- arch/nds32/include/asm/barrier.h | 2 +- arch/nds32/include/asm/bitfield.h | 2 +- arch/nds32/include/asm/cache.h| 2 +- arch/nds32/include/asm/cache_info.h | 2 +- arch/nds32/include/asm/cacheflush.h | 2 +- arch/nds32/include/asm/current.h | 2 +- arch/nds32/include/asm/delay.h| 2 +- arch/nds32/include/asm/elf.h | 2 +- arch/nds32/include/asm/fixmap.h | 2 +- arch/nds32/include/asm/futex.h| 2 +- arch/nds32/include/asm/highmem.h | 2 +- arch/nds32/include/asm/io.h | 2 +- arch/nds32/include/asm/irqflags.h | 2 +- arch/nds32/include/asm/l2_cache.h | 2 +- arch/nds32/include/asm/linkage.h | 2 +- arch/nds32/include/asm/memory.h | 2 +- arch/nds32/include/asm/mmu.h | 2 +- arch/nds32/include/asm/mmu_context.h | 2 +- arch/nds32/include/asm/module.h | 2 +- arch/nds32/include/asm/nds32.h| 2 +- arch/nds32/include/asm/page.h | 2 +- arch/nds32/include/asm/pgalloc.h | 2 +- arch/nds32/include/asm/pgtable.h | 2 +- arch/nds32/include/asm/proc-fns.h | 2 +- arch/nds32/include/asm/processor.h| 2 +- arch/nds32/include/asm/ptrace.h | 2 +- arch/nds32/include/asm/shmparam.h | 2 +- arch/nds32/include/asm/string.h | 2 +- arch/nds32/include/asm/swab.h | 2 +- arch/nds32/include/asm/syscall.h | 2 +- arch/nds32/include/asm/syscalls.h | 2 +- arch/nds32/include/asm/thread_info.h | 2 +- arch/nds32/include/asm/tlb.h | 2 +- arch/nds32/include/asm/tlbflush.h | 2 +- arch/nds32/include/asm/uaccess.h | 2 +- arch/nds32/include/asm/unistd.h | 2 +- arch/nds32/include/asm/vdso.h | 2 +- arch/nds32/include/asm/vdso_datapage.h| 2 +- arch/nds32/include/asm/vdso_timer_info.h | 2 +- arch/nds32/include/uapi/asm/auxvec.h | 2 +- arch/nds32/include/uapi/asm/byteorder.h | 2 +- arch/nds32/include/uapi/asm/cachectl.h| 2 +- arch/nds32/include/uapi/asm/param.h | 2 +- arch/nds32/include/uapi/asm/ptrace.h | 2 +- arch/nds32/include/uapi/asm/sigcontext.h | 2 +- arch/nds32/include/uapi/asm/unistd.h | 2 +- arch/powerpc/include/asm/pnv-ocxl.h | 2 +- arch/sh/drivers/pci/pci-sh5.h | 4 ++-- arch/sh/drivers/pci/pci-sh7751.h | 4 ++-- arch/sh/drivers/pci/pci-sh7780.h | 4 ++-- arch/sh/drivers/pci/pcie-sh7786.h | 4 ++-- arch/sh/include/asm/addrspace.h | 4 ++-- arch/sh/include/asm/bl_bit_64.h | 4 ++-- arch/sh/include/asm/cache_insns_64.h | 4 ++-- arch/sh/include/asm/device.h | 4 ++-- arch/sh/include/asm/dma-register.h| 4 ++-- arch/sh/include/asm/dma.h | 4 ++-- arch/sh/include/asm/dwarf.h | 4 ++-- arch/sh/include/asm/fixmap.h | 4 ++-- arch/sh/include/asm/flat.h| 4 ++-- arch/sh/include/asm/freq.h| 4 ++-- arch/sh/include/asm/gpio.h| 4 ++-- arch/sh/include/asm/machvec.h | 4 ++-- arch/sh/include/asm/pgtable.h | 4 ++-- arch/sh/include/asm/sfp-machine.h | 4 ++-- arch/sh/include/asm/shmparam.h| 4 ++-- arch/sh/include/asm/siu.h | 4 ++-- arch/sh/include/asm/spinlock-cas.h| 4 ++-- arch/sh/include/asm/spinlock-llsc.h | 4 ++-- arch/sh/include/asm/spinlock.h| 4 ++-- arch/sh/include/asm/switch_to.h | 4 ++-- arch/sh/include/asm/switch_to_64.h| 4 ++-- arch/sh/include/asm/tlb_64.h | 4
Re: [PATCH] ARCH: Use the correct style for SPDX License Identifier
On Sat, Mar 23, 2019 at 09:59:37PM +0100, Uwe Kleine-König wrote: > Hello, > > On Sat, Mar 23, 2019 at 06:58:14PM +0530, Nishad Kamdar wrote: > > This patch corrects the SPDX License Identifier style > > in the Hardware Architecture subsystem. > > > > Changes made by using a script provided by Joe Perches here: > > https://lkml.org/lkml/2019/2/7/46 > > and making some manual changes. > > Adding a note here that for C header files > Documentation/process/license-rules.rst mandates C-like comments > (opposed to C source files where C++ style should be used) would be a > good idea I think. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | http://www.pengutronix.de/ | Sorry for the late reply. Ok, I'll do that. Thanks for the review. Thanks and regards, Nishad
Re: BUG: MAX_STACK_TRACE_ENTRIES too low! (2)
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f1bacd20
start commit: 0e40da3e Merge tag 'kbuild-fixes-v5.1' of git://git.kernel..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1409bacd20
console output: https://syzkaller.appspot.com/x/log.txt?x=1009bacd20
kernel config: https://syzkaller.appspot.com/x/.config?x=8dcdce25ea72bedf
dashboard link: https://syzkaller.appspot.com/bug?extid=6f39a9deb697359fe520
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e1bacd20
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1120fe0f20
Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
workqueues")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH] spi: oc-tiny: fix negative loop bound error on for loop
From: Colin Ian King
Currently the for-loop using an unsigned int for the loop counter
which is problematic when comparing it to the signed int
gt->gpio_cs_count. This is an issue because if the signed int is
negative (for example, the call to of_gpio_count failed) then
the negative loop bound is implicitly cast to an unsigned int on
the comparison to loop counter i and will yield a very large value,
eventually causing an array bounds overflow on hw->gpio_cs.
Fix this by simply making the loop counter i a signed int;
Fixes: ca632f556697 ("spi: reorganize drivers")
Signed-off-by: Colin Ian King
---
drivers/spi/spi-oc-tiny.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-oc-tiny.c b/drivers/spi/spi-oc-tiny.c
index 085f580be7ec..81f74b938dc9 100644
--- a/drivers/spi/spi-oc-tiny.c
+++ b/drivers/spi/spi-oc-tiny.c
@@ -206,7 +206,7 @@ static int tiny_spi_of_probe(struct platform_device *pdev)
{
struct tiny_spi *hw = platform_get_drvdata(pdev);
struct device_node *np = pdev->dev.of_node;
- unsigned int i;
+ int i;
u32 val;
if (!np)
--
2.20.1
[PATCH] lib: Fix possible incorrect result from rational fractions helper
In some cases the previous algorithm would not return the closest
approximation. This would happen when a semi-convergent was the
closest, as the previous algorithm would only consider convergents.
As an example, consider an initial value of 5/4, and trying to find the
closest approximation with a maximum of 4 for numerator and denominator.
The previous algorithm would return 1/1 as the closest approximation,
while this version will return the correct answer of 4/3.
To do this, the main loop performs effectively the same operations as it
did before. It must now keep track of the last three approximations,
n2/d2 .. n0/d0, while before it only needed the last two.
If an exact answer is not found, the algorithm will now calculate the
best semi-convergent term, t, which is a single expression with two
divisions:
min((max_numerator - n0) / n1, (max_denominator - d0) / d1)
This will be used if it is better than previous convergent. The test
for this is generally a simple comparison, 2*t > a. But in an edge
case, where the convergent's final term is even and the best allowable
semi-convergent has a final term of exactly half the convergent's final
term, the more complex comparison (d0*dp > d1*d) is used.
I also wrote some comments explaining the code. While one still needs
to look up the math elsewhere, they should help a lot to follow how the
code relates to that math.
Cc: Oskar Schirmer
Signed-off-by: Trent Piepho
---
lib/rational.c | 63 +++---
1 file changed, 50 insertions(+), 13 deletions(-)
diff --git a/lib/rational.c b/lib/rational.c
index ba7443677c90..31fb27db2deb 100644
--- a/lib/rational.c
+++ b/lib/rational.c
@@ -3,6 +3,7 @@
* rational fractions
*
* Copyright (C) 2009 emlix GmbH, Oskar Schirmer
+ * Copyright (C) 2019 Trent Piepho
*
* helper functions when coping with rational numbers
*/
@@ -10,6 +11,7 @@
#include
#include
#include
+#include
/*
* calculate best rational approximation for a given fraction
@@ -33,30 +35,65 @@ void rational_best_approximation(
unsigned long max_numerator, unsigned long max_denominator,
unsigned long *best_numerator, unsigned long *best_denominator)
{
- unsigned long n, d, n0, d0, n1, d1;
+ /* n/d is the starting rational, which is continually
+* decreased each iteration using the Euclidean algorithm.
+*
+* dp is the value of d from the prior iteration.
+*
+* n2/d2, n1/d1, and n0/d0 are our successively more accurate
+* approximations of the rational. They are, respectively,
+* the current, previous, and two prior iterations of it.
+*
+* a is current term of the continued fraction.
+*/
+ unsigned long n, d, n0, d0, n1, d1, n2, d2;
n = given_numerator;
d = given_denominator;
n0 = d1 = 0;
n1 = d0 = 1;
+
for (;;) {
- unsigned long t, a;
- if ((n1 > max_numerator) || (d1 > max_denominator)) {
- n1 = n0;
- d1 = d0;
- break;
- }
+ unsigned long dp, a;
+
if (d == 0)
break;
- t = d;
+ /* Find next term in continued fraction, 'a', via
+* Euclidean algorithm.
+*/
+ dp = d;
a = n / d;
d = n % d;
- n = t;
- t = n0 + a * n1;
+ n = dp;
+
+ /* Calculate the current rational approximation (aka
+* convergent), n2/d2, using the term just found and
+* the two prior approximations.
+*/
+ n2 = n0 + a * n1;
+ d2 = d0 + a * d1;
+
+ /* If the current convergent exceeds the maxes, then
+* return either the previous convergent or the
+* largest semi-convergent, the final term of which is
+* found below as 't'.
+*/
+ if ((n2 > max_numerator) || (d2 > max_denominator)) {
+ unsigned long t = min((max_numerator - n0) / n1,
+ (max_denominator - d0) / d1);
+
+ /* This tests if the semi-convergent is closer
+* than the previous convergent.
+*/
+ if (2u * t > a || (2u * t == a && d0 * dp > d1 * d)) {
+ n1 = n0 + t * n1;
+ d1 = d0 + t * d1;
+ }
+ break;
+ }
n0 = n1;
- n1 = t;
- t = d0 + a * d1;
+ n1 = n2;
d0 = d1;
- d1 = t;
+ d1 = d2;
}
*best_numerator = n1;
*best_denominator = d1;
--
Re: [PATCH v5 13/25] m68k: add asm/syscall.h
CC Steven
On Fri, Mar 29, 2019 at 11:04 PM Dmitry V. Levin wrote:
> On Wed, Dec 12, 2018 at 11:55:16AM +0300, Dmitry V. Levin wrote:
> > On Mon, Dec 10, 2018 at 04:30:25PM +0300, Dmitry V. Levin wrote:
> > > On Mon, Dec 10, 2018 at 02:06:28PM +0100, Geert Uytterhoeven wrote:
> > > > On Mon, Dec 10, 2018 at 1:41 PM Dmitry V. Levin
> > > > wrote:
> > > > > On Mon, Dec 10, 2018 at 09:45:42AM +0100, Geert Uytterhoeven wrote:
> > > > > > On Mon, Dec 10, 2018 at 5:30 AM Dmitry V. Levin
> > > > > > wrote:
> > > > > > > syscall_get_* functions are required to be implemented on all
> > > > > > > architectures in order to extend the generic ptrace API with
> > > > > > > PTRACE_GET_SYSCALL_INFO request.
> > > > > > >
> > > > > > > This introduces asm/syscall.h on m68k implementing all 5
> > > > > > > syscall_get_*
> > > > > > > functions as documented in asm-generic/syscall.h: syscall_get_nr,
> > > > > > > syscall_get_arguments, syscall_get_error,
> > > > > > > syscall_get_return_value,
> > > > > > > and syscall_get_arch.
> > > > > > >
> > > > > > > Cc: Geert Uytterhoeven
> > > > > > > Cc: Oleg Nesterov
> > > > > > > Cc: Andy Lutomirski
> > > > > > > Cc: Elvira Khabirova
> > > > > > > Cc: Eugene Syromyatnikov
> > > > > > > Cc: linux-m...@lists.linux-m68k.org
> > > > > > > Signed-off-by: Dmitry V. Levin
> > > > > > > ---
> > > > > > >
> > > > > > > Notes:
> > > > > > > v5: added syscall_get_nr, syscall_get_arguments,
> > > > > > > syscall_get_error,
> > > > > > > and syscall_get_return_value
> > > > > > > v1: added syscall_get_arch
> > > > > >
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/m68k/include/asm/syscall.h
> > > > > > > @@ -0,0 +1,39 @@
> > > > > >
> > > > > > > +static inline void
> > > > > > > +syscall_get_arguments(struct task_struct *task, struct pt_regs
> > > > > > > *regs,
> > > > > > > + unsigned int i, unsigned int n, unsigned
> > > > > > > long *args)
> > > > > > > +{
> > > > > > > + BUG_ON(i + n > 6);
> > > > > >
> > > > > > Does this have to crash the kernel?
> > > > >
> > > > > This is what most of other architectures do, but we could choose
> > > > > a softer approach, e.g. use WARN_ON_ONCE instead.
> > > > >
> > > > > > Perhaps you can return an error code instead?
> > > > >
> > > > > That would be problematic given the signature of this function
> > > > > and the nature of the potential bug which would most likely be a
> > > > > usage error.
> > > >
> > > > Of course to handle that, the function's signature need to be changed.
> > > > Changing it has the advantage that the error handling can be done at the
> > > > caller, in common code, instead of duplicating it for all
> > > > architectures, possibly
> > > > leading to different semantics.
> > >
> > > Given that *all* current users of syscall_get_arguments specify i == 0
> > > (and there is an architecture that has BUG_ON(i)),
> > > it should be really a usage error to get into situation where i + n > 6,
> > > I wish a BUILD_BUG_ON could be used here instead.
> > >
> > > I don't think it worths pushing the change of API just to convert
> > > a "cannot happen" assertion into an error that would have to be dealt with
> > > on the caller side.
> >
> > I suggest the following BUG_ON replacement for syscall_get_arguments:
> >
> > #define SYSCALL_MAX_ARGS 6
> >
> > static inline void
> > syscall_get_arguments(struct task_struct *task, struct pt_regs *regs,
> > unsigned int i, unsigned int n, unsigned long *args)
> > {
> > /*
> >* Ideally there should have been
> >* BUILD_BUG_ON(i + n > SYSCALL_MAX_ARGS);
> >* instead of these checks.
> >*/
> > if (unlikely(i > SYSCALL_MAX_ARGS)) {
> > WARN_ONCE(1, "i > SYSCALL_MAX_ARGS");
> > return;
> > }
> > if (unlikely(n > SYSCALL_MAX_ARGS - i)) {
> > WARN_ONCE(1, "i + n > SYSCALL_MAX_ARGS");
> > n = SYSCALL_MAX_ARGS - i;
> > }
> > BUILD_BUG_ON(sizeof(regs->d1) != sizeof(args[0]));
> > memcpy(args, >d1 + i, n * sizeof(args[0]));
> > }
>
> There seems to be a more straightforward approach to this issue.
>
> Assuming there is a general consensus [1] to get rid of "i" and "n"
> arguments of syscall_get_arguments(), the implementation could be
> simplified to
>
> static inline void
> syscall_get_arguments(struct task_struct *task, struct pt_regs *regs,
> unsigned long *args)
> {
> memcpy(args, >d1, 6 * sizeof(args[0]));
> }
>
> [1] https://lore.kernel.org/lkml/20190328230512.486297...@goodmis.org/
Yeah, no longer a need for all these ugly checks, good.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
[PATCH] leds: blinkm: clean up double assignment to data->i2c_addr
From: Colin Ian King Currently data->i2c_addr is being assigned twice, first with the value 0x09 and then immediately afterwards with the value 0x08. The first assignment is redundant and can be removed. Signed-off-by: Colin Ian King --- drivers/leds/leds-blinkm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/leds/leds-blinkm.c b/drivers/leds/leds-blinkm.c index 851c1920b63c..11b771fb933b 100644 --- a/drivers/leds/leds-blinkm.c +++ b/drivers/leds/leds-blinkm.c @@ -594,7 +594,6 @@ static int blinkm_probe(struct i2c_client *client, goto exit; } - data->i2c_addr = 0x09; data->i2c_addr = 0x08; /* i2c addr - use fake addr of 0x08 initially (real is 0x09) */ data->fw_ver = 0xfe; -- 2.20.1
Re: [Letux-kernel] [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
Hi Andreas, > Am 30.03.2019 um 19:33 schrieb Andreas Kemnade : > > On Sun, 24 Mar 2019 07:56:17 +0100 > "H. Nikolaus Schaller" wrote: > >> Hi Linus, >> >>> Am 24.03.2019 um 05:15 schrieb Linus Walleij : >>> >>> On Sat, Mar 23, 2019 at 3:40 PM H. Nikolaus Schaller >>> wrote: >>> (1) c1c04cea13dc gpio: of: Fix logic inversion together with the basic patch (2) 6953c57ab172 gpio: of: Handle SPI chipselect legacy bindings leads to a severe regression for our GTA04 board. >>> >>> Sorry! :( >>> >>> I found the same problem on my Nomadik board. >>> >>> But I fixed it in that case by introducing a spi-cs-high into the DTS file: >>> https://marc.info/?l=linux-arm-kernel=155292310015309=2 >> >> Yes, that of course works and is our temporary solution. >> >> And I see that you also have it on the controller node and not the slave >> node. >> > So if I get it right is a check added for undocumented properties > (nothing about spi-cs-high in controller node in the bindings > documentation, only in the slave node) in the two patches mentioned. > > And then you add that undocumented property to a dts file in your "fix". > > That all sounds strange to me. > >>> I learned that it tries to handle a legacy "spi-cs-high" property of SPI slaves, but was stopped from doing so by a bug (1). So only with both patches, the legacy handler becomes active which explains why it was not noticed earlier. Now, our GTA04 device tree from 2014 (v3.16-rc1) was already written without any legacy spi properties in mind >>> >>> I'm sorry about that, however if you look at the DT binding document: >>> Documentation/devicetree/bindings/spi/spi-bus.txt >> >> Shouldn't it be a property of the slave node and not the controller node? >> >>> >>> You will see that spi-cs-high is mandatory. So these DTS files are >>> incorrect. >> >> How do you read that it is mandatory from >> >> "All slave nodes can contain the following optional properties: >> - spi-cs-high - Empty property indicating device requires chip select >> active high." >> >> I read it as optional and indicative. Equal priority to cs-gpios. >> > Well, it is in the list of optional properties. So the question is how > that "optional" is interpreted. Is it optional because you only use it > if cs is active high or is it optional because you can either indicate > that fact here or via gpio definition. > > But again that flags makes no sense in the controller node. I have already prepared some fix for this controller/slave node issue and a new CONFIG option to enable the legacy "spi-cs-high" only if needed. Seems to be common practice that legacy API support (and legacy DTB compatibility is also "API") is only enabled by CONFIGs on demand. This can then replace our current GTA04 hack. Will post ASAP to LKML. BR, Nikolaus
Re: Possible UDF locking error?
Jan -
On 3/25/19 11:42 AM, Jan Kara wrote:
Hi!
On Sat 23-03-19 15:14:05, Steve Magnani wrote:
I have been hunting a UDF bug that occasionally results in generation
of an Allocation Extent Descriptor with an incorrect tagLocation. So
far I haven't been able to see a path through the code that could
cause that. But, I noticed some inconsistency in locking during
AED generation and wonder if it could result in random corruption.
The function udf_update_inode() has this general pattern:
bh = udf_tgetblk(...); // calls sb_getblk()
lock_buffer(bh);
memset(bh->b_data, 0, inode->i_sb->s_blocksize);
// other code to populate FE/EFE data in the block
set_buffer_uptodate(bh);
unlock_buffer(bh);
mark_buffer_dirty(bh);
This I can understand - the lock is held for as long as the buffer
contents are being assembled.
In contrast, udf_setup_indirect_aext(), which constructs an AED,
has this sequence:
bh = udf_tgetblk(...); // calls sb_getblk()
lock_buffer(bh);
memset(bh->b_data, 0, inode->i_sb->s_blocksize);
set_buffer_uptodate(bh);
unlock_buffer(bh);
mark_buffer_dirty_inode(bh);
// other code to populate AED data in the block
In this case the population of the block occurs without
the protection of the lock.
Because the block has been marked dirty, does this mean that
writeback could occur at any point during population?
Yes. Thanks for noticing this!
There is one path through udf_setup_indirect_aext() where
mark_buffer_dirty_inode() gets called again after population is
complete, which I suppose could heal a partial writeout, but there is
also another path in which the buffer does not get marked dirty again.
Generally, we add new extents to the created indirect extent which dirties
the buffer and that should fix the problem. But you are definitely right
that the code is suspicious and should be fixed. Will you send a patch?
I did a little archaeology to see how the code evolved to this point.
It's been like this a long time.
I also did some research to understand why filesystems use lock_buffer()
sometimes but not others. For example, the FAT driver never calls it. I
ran across this thread from 2011:
https://lkml.org/lkml/2011/5/16/402
...from which I conclude that while it is correct in a strict sense to
hold a lock on a buffer any time its contents are being modified,
performance considerations make it preferable (or at least reasonable)
to make some modifications without a lock provided it's known that a
subsequent write-out will "fix" any potential partial write out before
anyone else tries to read the block. I doubt that UDF sees common use
with DIF/DIX block devices, which might make a decision in favor of
performance a little easier. Since the FAT driver doesn't contain
Darrick's proposed changes I assume a decision was made that performance
was more important there.
Certainly the call to udf_setup_indirect_aext() from udf_add_aext()
meets those criteria. But udf_table_free_blocks() may not dirty the AED
block.
So if this looks reasonable I will resend as a formal patch:
--- a/fs/udf/inode.c2019-03-30 11:28:38.637759458 -0500
+++ b/fs/udf/inode.c2019-03-30 11:33:00.357761250 -0500
@@ -1873,9 +1873,6 @@ int udf_setup_indirect_aext(struct inode
return -EIO;
lock_buffer(bh);
memset(bh->b_data, 0x00, sb->s_blocksize);
- set_buffer_uptodate(bh);
- unlock_buffer(bh);
- mark_buffer_dirty_inode(bh, inode);
aed = (struct allocExtDesc *)(bh->b_data);
if (!UDF_QUERY_FLAG(sb, UDF_FLAG_STRICT)) {
@@ -1890,6 +1887,9 @@ int udf_setup_indirect_aext(struct inode
udf_new_tag(bh->b_data, TAG_IDENT_AED, ver, 1, block,
sizeof(struct tag));
+ set_buffer_uptodate(bh);
+ unlock_buffer(bh);
+
nepos.block = neloc;
nepos.offset = sizeof(struct allocExtDesc);
nepos.bh = bh;
@@ -1913,6 +1913,8 @@ int udf_setup_indirect_aext(struct inode
} else {
__udf_add_aext(inode, epos, ,
sb->s_blocksize | EXT_NEXT_EXTENT_ALLOCDECS, 0);
+ /* Make sure completed AED gets written out */
+ mark_buffer_dirty_inode(nepos.bh, inode);
}
brelse(epos->bh);
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include
Re: [PATCH v2] trace: events: fix error directive in argument list
On Sat, Mar 30, 2019 at 11:48:23PM +0530, Hariprasad Kelam wrote:
> This patch fixes below spare errors.
>
> Sparse error:
> make C=2 CF=-D__CHECK_ENDIAN__ M=net/core
> ./include/trace/events/neigh.h:73:1: error: directive in argument list
> ./include/trace/events/neigh.h:78:1: error: directive in argument list
> ./include/trace/events/neigh.h:150:1: error: directive in argument list
> ./include/trace/events/neigh.h:155:1: error: directive in argument list
>
> Changes below two lines to signle line to avoid sparse error
>if (n->tbl->family == AF_INET6) {
> to if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6)
>
> Signed-off-by: Hariprasad Kelam
Thanks,
Reviewed-by: Luc Van Oostenryck
-- Luc
Re: [PATCH] arm64/vdso: don't leak kernel addresses
On 3/31/2019 12:16 AM, Matteo Croce wrote:
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
two obfuscated kernel pointer are printed at every boot:
vdso: 2 pages (1 code @ (ptrval), 1 data @ (ptrval))
Remove the addresses from the print, which turns into a more discrete:
vdso: 2 pages (1 code, 1 data)
Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Matteo Croce
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
arch/arm64/kernel/vdso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 2d419006ad43..fdfee0ef5bc5 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -146,8 +146,8 @@ static int __init vdso_init(void)
}
vdso_pages = (vdso_end - vdso_start) >> PAGE_SHIFT;
- pr_info("vdso: %ld pages (%ld code @ %p, %ld data @ %p)\n",
- vdso_pages + 1, vdso_pages, vdso_start, 1L, vdso_data);
+ pr_info("vdso: %ld pages (%ld code, %ld data)\n",
+ vdso_pages + 1, vdso_pages, 1L);
/* Allocate the vDSO pagelist, plus a page for the data. */
vdso_pagelist = kcalloc(vdso_pages + 1, sizeof(struct page *),
Re: [PATCH] [V2] x86/asm: add __user on copy_user_handle_tail() pointers
On 3/30/2019 5:26 PM, Ben Dooks wrote:
The copy_user_handle_tail() clearly uses both from and to as pointers
to user-space memory. This triggers sparse warning on using the calls
to get and put to user-space. This can be fixed easily by changing the
call to take __user annotated pointer.s
arch/x86/lib/usercopy_64.c:68:21: warning: incorrect type in argument 1
(different address spaces)
arch/x86/lib/usercopy_64.c:68:21:expected void const volatile [noderef]
*
arch/x86/lib/usercopy_64.c:68:21:got char *
arch/x86/lib/usercopy_64.c:70:21: warning: incorrect type in argument 1
(different address spaces)
arch/x86/lib/usercopy_64.c:70:21:expected void const volatile [noderef]
*
arch/x86/lib/usercopy_64.c:70:21:got char *to
From Linus Torvalds:
On Thu, Mar 28, 2019 at 12:24 AM Borislav Petkov wrote:
Well, but copy_user_generic() (which ends up calling the
copy_user_handle_tail() eventually) casts those __user pointers to
(__force void *). Converting them back to __user looks strange to me.
Linus?
Well, it does that because the x86 version of copy_user_generic() can
work in either direction, so it works when either the source or
destination (or both) are user pointers, but they don't _have_ to be.
So the "userness" of a pointer in that context is a bit ambiguous, and
so we've picked the pointers to be just plain "void *".
That said, arguably we should have gone the other way and just made
them both "__user" pointers, and do the cast the other way around.
But there's no absolutely right answer here, and nobody should ever
use copy_user_generic() directly (ie it is very much meant to be only
used as a internal helper for the cases that get the pointer
annotations right).
Signed-off-by: Ben Dooks
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
arch/x86/include/asm/uaccess_64.h | 2 +-
arch/x86/lib/usercopy_64.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess_64.h
b/arch/x86/include/asm/uaccess_64.h
index a9d637bc301d..cbca2cb28939 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -208,7 +208,7 @@ __copy_from_user_flushcache(void *dst, const void __user
*src, unsigned size)
}
unsigned long
-copy_user_handle_tail(char *to, char *from, unsigned len);
+copy_user_handle_tail(char __user *to, char __user *from, unsigned len);
unsigned long
mcsafe_handle_tail(char *to, char *from, unsigned len);
diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
index ee42bb0cbeb3..aa180424e77a 100644
--- a/arch/x86/lib/usercopy_64.c
+++ b/arch/x86/lib/usercopy_64.c
@@ -60,7 +60,7 @@ EXPORT_SYMBOL(clear_user);
* it is not necessary to optimize tail handling.
*/
__visible unsigned long
-copy_user_handle_tail(char *to, char *from, unsigned len)
+copy_user_handle_tail(char __user *to, char __user *from, unsigned len)
{
for (; len; --len, to++) {
char c;
Re: [GIT PULL] LED fixes for 5.1-rc3
The pull request you sent on Sat, 30 Mar 2019 19:39:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > tags/led-fixes-for-5.1-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b5c8314f0ebadb6d8a9789cb2d646cbef8448073 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 0/1] pwm: meson: fix scheduling while atomic issue
Hello Uwe,
On Mon, Mar 25, 2019 at 9:07 PM Uwe Kleine-König
wrote:
[...]
> > > - Does stopping the PWM (i.e. clearing MISC_{A,B}_EN in the MISC_AB
> > >register) freeze the output, or is the currently running period
> > >completed first? (The latter is the right behaviour.)
> > I don't know, I would have to measure this with a logic analyzer.
>
> In practise you can do this with a multimeter, too. Just do something
> like:
>
> pwm_apply_state({ .enabled = true, .period = 5s, .duty_cycle = 5s,
> .polarity = PWM_POLARITY_NORMAL });
> pwm_apply_state({ .enabled = false, .period = 5s, .duty_cycle = 5s,
> .polarity = PWM_POLARITY_NORMAL });
>
> (assuming the PWM supports periods that long). The expectation is that
> the last command takes nearly 5 s to complete and while it waits the
> output is high and on return it's low. If that isn't the case, there is
> a bug somewhere.
the longest supported period (using the 24MHz crystal as input, which
is the slowest input clock and thus gives the longest possible
duration) is 349514407ns (that's approx. 0.35 seconds). my multimeter
isn't fast enough to measure this so I'm using my logic analyzer with
puleseview instead: [0]
I added the following code to meson_pwm_request:
struct pwm_state enable = {
.enabled = true,
.period = 349514407U,
.duty_cycle = 349514407U,
.polarity = PWM_POLARITY_NORMAL };
struct pwm_state disable = {
.enabled = false,
.period = 349514407U,
.duty_cycle = 349514407U,
.polarity = PWM_POLARITY_NORMAL };
pwm_apply_state(pwm, );
pwm_apply_state(pwm, );
this returns immediately. my logic analyzer doesn't see signal change
(I'm sampling at 1MHz).
can you please confirm that my test code and measurement procedure is correct?
if it is then my observation is that disabling the PWM does so
immediately, without waiting for the current period to complete
Regards
Martin
[0] https://sigrok.org/wiki/Lcsoft_Mini_Board
Re: INFO: rcu detected stall in corrupted (3)
On Sat, Mar 30, 2019 at 11:07:40PM +0900, Tetsuo Handa wrote: > I think that syzbot should for now refrain from testing syscalls that change > scheduling related attributes, And how would we know about problems there, otherwise? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
Hi Rasmus! > From: Rasmus Villemoes > Sent: Saturday, March 30, 2019 12:53:51 AM > To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko > Cc: Yury Norov; linux-kernel@vger.kernel.org > Subject: [PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by > CONFIG_NUMA > > The bitmap_remap, _bitremap, _onto and _fold functions are only used, > via their node_ wrappers, in mm/mempolicy.c, which is only built for > CONFIG_NUMA. The helper bitmap_ord_to_pos used by these functions is > global, but its only external caller is node_random() in lib/nodemask.c, > which is also guarded by CONFIG_NUMA. Nice catch. I think you should protect declaration of those functions in include/linux/bitmap.h as well. I'm concerned about pollution of such a generic portion of code with subsystem-related #ifdefs. Would it make more sense to move numa-specific stuff to lib/bitmap_numa.c and include/linux/bitmap_numa.h (or *_nodemask.h, or whatever)? Yury > For !CONFIG_NUMA: > > add/remove: 0/6 grow/shrink: 0/0 up/down: 0/-621 (-621) > Function old new delta > bitmap_pos_to_ord 20 - -20 > bitmap_ord_to_pos 70 - -70 > bitmap_bitremap 81 - -81 > bitmap_fold 113 --113 > bitmap_onto 123 --123 > bitmap_remap 214 --214 > Total: Before=4776, After=4155, chg -13.00% > > Signed-off-by: Rasmus Villemoes > --- > lib/bitmap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/bitmap.c b/lib/bitmap.c > index 66421f304f7d..3f3b8051f342 100644 > --- a/lib/bitmap.c > +++ b/lib/bitmap.c > @@ -649,6 +649,7 @@ int bitmap_parselist_user(const char __user *ubuf, > EXPORT_SYMBOL(bitmap_parselist_user); > > > +#ifdef CONFIG_NUMA > /** > * bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap > * @buf: pointer to a bitmap > @@ -952,6 +953,7 @@ void bitmap_fold(unsigned long *dst, const unsigned long > *orig, > for_each_set_bit(oldbit, orig, nbits) > set_bit(oldbit % sz, dst); > } > +#endif /* CONFIG_NUMA */ > > /* > * Common code for bitmap_*_region() routines. > -- > 2.20.1 >
Re: [GIT PULL] TTY/Serial fixes for 5.1-rc3
The pull request you sent on Sat, 30 Mar 2019 10:04:00 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-5.1-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/52afe190ff034f25546fb0a2cb7380dcb896d371 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] GPIO fixes for the v5.1 series
The pull request you sent on Sat, 30 Mar 2019 16:04:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > tags/gpio-v5.1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3af9a5256f448e3d0405f7905c430ef2f9f32b9c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Staging driver fixes for 5.1-rc3
The pull request you sent on Sat, 30 Mar 2019 10:04:21 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > tags/staging-5.1-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/32faca66bd3f6aa7ec4212d20c7b2d45657fab10 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH] arm64/vdso: don't leak kernel addresses
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
two obfuscated kernel pointer are printed at every boot:
vdso: 2 pages (1 code @ (ptrval), 1 data @ (ptrval))
Remove the addresses from the print, which turns into a more discrete:
vdso: 2 pages (1 code, 1 data)
Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Matteo Croce
---
arch/arm64/kernel/vdso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 2d419006ad43..fdfee0ef5bc5 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -146,8 +146,8 @@ static int __init vdso_init(void)
}
vdso_pages = (vdso_end - vdso_start) >> PAGE_SHIFT;
- pr_info("vdso: %ld pages (%ld code @ %p, %ld data @ %p)\n",
- vdso_pages + 1, vdso_pages, vdso_start, 1L, vdso_data);
+ pr_info("vdso: %ld pages (%ld code, %ld data)\n",
+ vdso_pages + 1, vdso_pages, 1L);
/* Allocate the vDSO pagelist, plus a page for the data. */
vdso_pagelist = kcalloc(vdso_pages + 1, sizeof(struct page *),
--
2.19.1
Re: [RFC PATCH] iio: core: fix a possible circular locking dependency
On Mon, 25 Mar 2019 13:51:17 +0100
Fabrice Gasnier wrote:
> On 3/24/19 4:47 PM, Jonathan Cameron wrote:
> > On Fri, 22 Mar 2019 14:54:06 +0100
> > Fabrice Gasnier wrote:
> >
> >> This fixes a possible circular locking dependency detected warning seen
> >> with:
> >> - CONFIG_PROVE_LOCKING=y
> >> - consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
> >>
> >> When using the IIO consumer interface, e.g. iio_channel_get(),
> >> the consumer device will likely call iio_read_channel_raw() or similar that
> >> rely on 'info_exist_lock' mutex.
> >>
> >> typically:
> >> ...
> >>mutex_lock(>indio_dev->info_exist_lock);
> >>if (chan->indio_dev->info == NULL) {
> >>ret = -ENODEV;
> >>goto err_unlock;
> >>}
> >>ret = do_some_ops()
> >> err_unlock:
> >>mutex_unlock(>indio_dev->info_exist_lock);
> >>return ret;
> >> ...
> >>
> >> Same mutex is also hold in iio_device_unregister().
> >>
> >> The following deadlock warning happens when:
> >> - the consumer device has called an API like iio_read_channel_raw()
> >> at least once.
> >> - the consumer driver is unregistered, removed (unbind from sysfs)
> >>
> >> ==
> >> WARNING: possible circular locking dependency detected
> >> 4.19.24 #577 Not tainted
> >> --
> >> sh/372 is trying to acquire lock:
> >> (kn->count#30){}, at: kernfs_remove_by_name_ns+0x3c/0x84
> >>
> >> but task is already holding lock:
> >> (>info_exist_lock){+.+.}, at: iio_device_unregister+0x18/0x60
> >>
> >> which lock already depends on the new lock.
> >>
> >> the existing dependency chain (in reverse order) is:
> >>
> >> -> #1 (>info_exist_lock){+.+.}:
> >>__mutex_lock+0x70/0xa3c
> >>mutex_lock_nested+0x1c/0x24
> >>iio_read_channel_raw+0x1c/0x60
> >>iio_read_channel_info+0xa8/0xb0
> >>dev_attr_show+0x1c/0x48
> >>sysfs_kf_seq_show+0x84/0xec
> >>seq_read+0x154/0x528
> >>__vfs_read+0x2c/0x15c
> >>vfs_read+0x8c/0x110
> >>ksys_read+0x4c/0xac
> >>ret_fast_syscall+0x0/0x28
> >>0xbedefb60
> >>
> >> -> #0 (kn->count#30){}:
> >>lock_acquire+0xd8/0x268
> >>__kernfs_remove+0x288/0x374
> >>kernfs_remove_by_name_ns+0x3c/0x84
> >>remove_files+0x34/0x78
> >>sysfs_remove_group+0x40/0x9c
> >>sysfs_remove_groups+0x24/0x34
> >>device_remove_attrs+0x38/0x64
> >>device_del+0x11c/0x360
> >>cdev_device_del+0x14/0x2c
> >>iio_device_unregister+0x24/0x60
> >>release_nodes+0x1bc/0x200
> >>device_release_driver_internal+0x1a0/0x230
> >>unbind_store+0x80/0x130
> >>kernfs_fop_write+0x100/0x1e4
> >>__vfs_write+0x2c/0x160
> >>vfs_write+0xa4/0x17c
> >>ksys_write+0x4c/0xac
> >>ret_fast_syscall+0x0/0x28
> >>0xbe906840
> >>
> >> other info that might help us debug this:
> >>
> >> Possible unsafe locking scenario:
> >>
> >>CPU0CPU1
> >>
> >> lock(>info_exist_lock);
> >>lock(kn->count#30);
> >>lock(>info_exist_lock);
> >> lock(kn->count#30);
> >>
> >> *** DEADLOCK ***
> >> ...
> >>
> >> So only hold the mutex to:
> >> - disable all buffers while 'info' is available
> >> - set 'info' to NULL
> >> Then release it to call cdev_device_del and so on.
> >>
> >> Help to reproduce:
> >> See example: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> >> sysv {
> >>compatible = "voltage-divider";
> >>io-channels = < 0>;
> >>output-ohms = <22>;
> >>full-ohms = <222>;
> >> };
> >>
> >> First, go to iio:deviceX for the "voltage-divider", do one read:
> >> $ cd /sys/bus/iio/devices/iio:deviceX
> >> $ cat in_voltage0_raw
> >>
> >> Then, unbind the consumer driver. It triggers above deadlock warning.
> >> $ cd /sys/bus/platform/drivers/iio-rescale/
> >> $ echo sysv > unbind
> >>
> >> Signed-off-by: Fabrice Gasnier
> > I'm not in principle against the fix. However it is reordering the
> > remove wrt to the probe which I'm not so keen on.
> >
>
> Hi Jonathan,
>
> I also had it in mind. Just one thing confused me:
> - The ->info struct is filled in by the device driver before calling one
> of the "iio_device_register" routines.
> - But it's assigned to NULL inside the unregister routine.
> That's also why I've sent it as RFC.
Yeah, IIRC we debated whether this was fair use of the pointer
when this handling was originally introduced. The arguement Lars
(I think) made was that we always knew this pointer had no valid
use after this call, so why not use it even if we break the balance
of probe / remove.
>
> > The cdev register is fundamentally the point where the device
> > becomes exposed to userspace, so we naturally want to do it last
> > (and
Re: [PATCH] drivers/tty: fix kernel address leaks in rp_ioctl
On Sat, Mar 30, 2019 at 06:33:44PM +0800, Fuqian Huang wrote:
> The RCKP_GET_STRUCT case in rp_ioctl will copy a kernel
> pointer(info->port.ops) to user space. The info->port.ops points to a
> constant object 'rocket_port_ops' during the initialization. (init_r_port
> in drivers/tty/rocket.c:633)
>
> Add a function clear_pointer_fields to set the pointer fields of struct
> r_port to NULL before copy_to_user.
>
> Signed-off-by: Fuqian Huang
> Reported-by: Fuqian Huang
> --
> diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
> index b121d8f..28016e1 100644
> --- a/drivers/tty/rocket.c
> +++ b/drivers/tty/rocket.c
> @@ -1271,21 +1271,42 @@ static int get_version(struct r_port *info, struct
> rocket_version __user *retver
> return 0;
> }
>
> +static void clear_pointer_fields(struct r_port *old, struct r_port *new)
> +{
> + memcpy(new, old, sizeof (struct r_port));
> + new->port.tty = NULL;
> + new->port.itty = NULL;
> + new->port.ops = NULL;
> + new->port.client_ops = NULL;
> + memset(>port.open_wait.head, 0, sizeof(struct list_head));
> + memset(>port.delta_msr_wait.head, 0, sizeof(struct list_head));
> + memset(>port.mutex.wait_list, 0, sizeof(struct list_head));
> + memset(>port.buf_mutex.wait_list, 0, sizeof(struct list_head));
> + new->port.xmit_buf = NULL;
> + new->port.client_data = NULL;
> + new->ctlp = NULL;
> + new->xmit_buf = NULL;
> + memset(>write_mtx.wait_list, 0, sizeof(struct list_head));
> +}
> +
> /* IOCTL call handler into the driver */
> static int rp_ioctl(struct tty_struct *tty,
> unsigned int cmd, unsigned long arg)
> {
> struct r_port *info = tty->driver_data;
> + struct r_port *masked_info;
> void __user *argp = (void __user *)arg;
> int ret = 0;
>
> if (cmd != RCKP_GET_PORTS && rocket_paranoia_check(info, "rp_ioctl"))
> return -ENXIO;
> -
> switch (cmd) {
> case RCKP_GET_STRUCT:
> - if (copy_to_user(argp, info, sizeof (struct r_port)))
> + masked_info = kzalloc(sizeof (struct r_port), GFP_KERNEL);
> + clear_pointer_fields(info, masked_info);
> + if (copy_to_user(argp, masked_info, sizeof (struct r_port)))
> ret = -EFAULT;
> + kfree(masked_info);
> break;
> case RCKP_GET_CONFIG:
> ret = get_config(info, argp);
The patch is totally whitespace corrupted and can not be applied :(
You can not cut/paste in gmail when sending a patch.
Also, your change leaks memory on the error path :(
Please fix up and try again.
thanks,
greg k-h
Re: [PATCH 2/2] iio: counter: Add support for Milbeaut Updown Counter
On Tue, 26 Mar 2019 15:33:32 +0900
Shinji Kanematsu wrote:
> Add support for Milbeaut Updown Counter, that can be used as counter
> or quadrature encoder.
>
> Signed-off-by: Shinji Kanematsu
A few minor comments inline. The counter subsystem will provide a cleaner
way of describing this. Please look to that for v2.
Hopefully William will give some feedback as well.
Jonathan
> ---
> drivers/iio/counter/Kconfig | 12 +
> drivers/iio/counter/Makefile | 1 +
> drivers/iio/counter/milbeaut-updown.h | 38 +++
> drivers/iio/counter/milbeaut-updown_cnt.c | 385
> ++
> 4 files changed, 436 insertions(+)
> create mode 100644 drivers/iio/counter/milbeaut-updown.h
> create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c
>
> diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
> index bf1e559..a665f61 100644
> --- a/drivers/iio/counter/Kconfig
> +++ b/drivers/iio/counter/Kconfig
> @@ -31,4 +31,16 @@ config STM32_LPTIMER_CNT
>
> To compile this driver as a module, choose M here: the
> module will be called stm32-lptimer-cnt.
> +
> +config MILBEAUT_UPDOWN_CNT
> + tristate "Milbeaut Updown Counter driver"
> + depends on OF
> + depends on ARCH_MILBEAUT || COMPILE_TEST
> + help
> + Select this option to enable Milbeaut Updown Counter quadrature
> encoder
> + and counter driver.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called milbeaut-updown-cnt.
> +
> endmenu
> diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
> index 1b9a896..0cb708b 100644
> --- a/drivers/iio/counter/Makefile
> +++ b/drivers/iio/counter/Makefile
> @@ -6,3 +6,4 @@
>
> obj-$(CONFIG_104_QUAD_8) += 104-quad-8.o
> obj-$(CONFIG_STM32_LPTIMER_CNT) += stm32-lptimer-cnt.o
> +obj-$(CONFIG_MILBEAUT_UPDOWN_CNT)+= milbeaut-updown_cnt.o
> diff --git a/drivers/iio/counter/milbeaut-updown.h
> b/drivers/iio/counter/milbeaut-updown.h
> new file mode 100644
> index 000..9a038ad
> --- /dev/null
> +++ b/drivers/iio/counter/milbeaut-updown.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Milbeaut Updown parent driver
> + * Copyright (C) 2019 Socionext Inc.
> + */
> +
> +#ifndef _LINUX_MILBEAUT_UPDOWN_H_
> +#define _LINUX_MILBEAUT_UPDOWN_H_
> +
> +#define MLB_UPDOWN_UDCR 0x0 /* Updown Count Reg
> */
> +#define MLB_UPDOWN_RCR 0x4 /* Reload Compare Reg
> */
> +#define MLB_UPDOWN_CSR 0xC /* Counter Status Reg
> */
> +#define MLB_UPDOWN_CCR 0x14/* Counter Control Reg */
> +
> +/* MLB_UPDOWN_CSR - bit fields */
> +#define MLB_UPDOWN_CSTR BIT(7)
> +#define MLB_UPDOWN_UDIE BIT(5)
> +#define MLB_UPDOWN_CMPF BIT(4)
> +#define MLB_UPDOWN_OVFF BIT(3)
> +#define MLB_UPDOWN_UDFF BIT(2)
> +
> +/* MLB_UPDOWN_CCR - bit fields */
> +#define MLB_UPDOWN_FIXED BIT(15)
> +#define MLB_UPDOWN_CMS GENMASK(11, 10)
> +#define MLB_UPDOWN_CES GENMASK(9, 8)
> +#define MLB_UPDOWN_CTUT BIT(6)
> +#define MLB_UPDOWN_RLDE BIT(4)
> +
> +/* MLB_UPDOWN max count value */
> +#define MLB_UPDOWN_MAX_COUNT 0x
> +
> +/* MLB_UPDOWN rising edge detection */
> +#define MLB_UPDOWN_RISING_EDGE BIT(9)
> +
> +/* MLB_UPDOWN mode */
> +#define MLB_UPDOWN_MODE 1
> +
> +#endif
> diff --git a/drivers/iio/counter/milbeaut-updown_cnt.c
> b/drivers/iio/counter/milbeaut-updown_cnt.c
> new file mode 100644
> index 000..a58709a
> --- /dev/null
> +++ b/drivers/iio/counter/milbeaut-updown_cnt.c
> @@ -0,0 +1,385 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Milbeaut Updown counter driver
> + *
> + * Copyright (C) 2019 Socionext Inc.
I'm fussy about pointless lines. The one below doesn't add anything ;)
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "milbeaut-updown.h"
> +
> +#define MILBEAUT_UPDOWN_IRQ_NAME "milbeaut_updown_event"
> +#define MILBEAUT_UPDOWN_MAX_REGISTER 0x1f
> +
> +static const struct regmap_config milbeaut_updown_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = MILBEAUT_UPDOWN_MAX_REGISTER,
> +};
> +struct milbeaut_updown_cnt {
> + struct device *dev;
> + struct regmap *regmap;
> + struct clk *clk;
> + u32 preset;
> + u32 polarity;
> + u32 quadrature_mode;
> +};
> +
> +static int milbeaut_updown_is_enabled(struct milbeaut_updown_cnt *priv)
> +{
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(priv->regmap, MLB_UPDOWN_CSR, );
> + if (ret)
> + return ret;
> +
> + return FIELD_GET(MLB_UPDOWN_CSTR, val);
> +}
> +
> +static int
[GIT PULL] LED fixes for 5.1-rc3
Hi Linus, Please pull LED fixes for 5.1-rc3. ledtrig-netdev fixes: - fix refcnt leak on interface rename - use memcpy in device_name_store() to avoid including garbage from a previous, longer value in the device_name leds-pca9532: - fix a potential NULL pointer dereference in case of_match_device() cannot find a match The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/led-fixes-for-5.1-rc3 for you to fetch changes up to 909346433064b8d840dc82af26161926b8d37558: leds: trigger: netdev: use memcpy in device_name_store (2019-03-30 19:09:32 +0100) Thanks, Jacek Anaszewski LED fixes for 5.1-rc3 Kangjie Lu (1): leds: pca9532: fix a potential NULL pointer dereference Rafał Miłecki (1): leds: trigger: netdev: fix refcnt leak on interface rename Rasmus Villemoes (1): leds: trigger: netdev: use memcpy in device_name_store drivers/leds/leds-pca9532.c | 8 ++-- drivers/leds/trigger/ledtrig-netdev.c | 16 +++- 2 files changed, 13 insertions(+), 11 deletions(-)
Re: [PATCH v2] trace: events: fix error directive in argument list
On 3/30/2019 11:48 PM, Hariprasad Kelam wrote:
This patch fixes below spare errors.
Sparse error:
make C=2 CF=-D__CHECK_ENDIAN__ M=net/core
./include/trace/events/neigh.h:73:1: error: directive in argument list
./include/trace/events/neigh.h:78:1: error: directive in argument list
./include/trace/events/neigh.h:150:1: error: directive in argument list
./include/trace/events/neigh.h:155:1: error: directive in argument list
Changes below two lines to signle line to avoid sparse error
if (n->tbl->family == AF_INET6) {
to if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6)
Signed-off-by: Hariprasad Kelam
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
Changes in V2:
-Divide patch to only address spare error
---
include/trace/events/neigh.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/neigh.h b/include/trace/events/neigh.h
index 0bdb085..2ca0180 100644
--- a/include/trace/events/neigh.h
+++ b/include/trace/events/neigh.h
@@ -70,12 +70,10 @@ TRACE_EVENT(neigh_update,
else
*p32 = 0;
-#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl->family == AF_INET6) {
+ if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6) {
pin6 = (struct in6_addr *)__entry->primary_key6;
*pin6 = *(struct in6_addr *)n->primary_key;
} else
-#endif
{
ipv6_addr_set_v4mapped(*p32, pin6);
}
@@ -147,12 +145,10 @@ DECLARE_EVENT_CLASS(neigh__update,
else
*p32 = 0;
-#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl->family == AF_INET6) {
+ if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6) {
pin6 = (struct in6_addr *)__entry->primary_key6;
*pin6 = *(struct in6_addr *)n->primary_key;
} else
-#endif
{
ipv6_addr_set_v4mapped(*p32, pin6);
}
Re: [PATCH] clk: rockchip: Fix video codec clocks on rk3288
Hi,
On Sat, Mar 30, 2019 at 7:25 AM Ezequiel Garcia
wrote:
>
> On Fri, 29 Mar 2019 at 20:28, Ezequiel Garcia
> wrote:
> >
> > On Fri, 29 Mar 2019 at 18:55, Douglas Anderson
> > wrote:
> > >
> > > It appears that there is a typo in the rk3288 TRM. For
> > > GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's
> > > the other way around.
> > >
> > > How do I know? Here's my evidence:
> > >
> > > 1. Prior to commit 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec
> > >using the new muxgrf type on rk3288") we always pretended that we
> > >were using "aclk_vdpu" and the comment in the code said that this
> > >matched the default setting in the system. In fact the default
> > >setting is 0 according to the TRM and according to reading memory
> > >at bootup. In addition rk3288-based Chromebooks ran like this and
> > >the video codecs worked.
> > > 2. With the existing clock code if you boot up and try to enable the
> > >new VIDEO_ROCKCHIP_VPU as a module (and without "clk_ignore_unused"
> > >on the command line), you get errors like "failed to get ack on
> > >domain 'pd_video', val=0x80208". After flipping vepu/vdpu things
> > >init OK.
> > > 3. If I export and add both the vepu and vdpu to the list of clocks
> > >for RK3288_PD_VIDEO I can get past the power domain errors, but now
> > >I freeze when the vpu_mmu gets initted.
> > > 4. If I just mark the "vdpu" as IGNORE_UNUSED then everything boots up
> > >and probes OK showing that somehow the "vdpu" was important to keep
> > >enabled. This is because we were actually using it as a parent.
> > > 5. After this change I can hack "aclk_vcodec_pre" to parent from
> > >"aclk_vepu" using assigned-clocks and the video codec still probes
> > >OK.
> > >
> > > Fixes: 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec using the new
> > > muxgrf type on rk3288")
> > > Signed-off-by: Douglas Anderson
> > > ---
> > > I currently have no way to test the JPEG mem2mem driver, so hopefully
> > > others can test this and make sure it's happy for them. I'm just
> > > happy not to get strange errors at boot anymore.
> > >
> >
> > I won't have access to this hardware for a few days, but I am happy
> > to provide a simple test tool.
> >
> > Still haven't reviewed this, but thanks for chasing it down!
> >
>
> Here's a simple tool that tests JPEG encoding. There are two branches,
> with request API and without request API:
>
> https://gitlab.collabora.com/ezequiel/v4l-jpeg
>
> Usage is fairly simple, there's a test.sh that runs three tests,
> writing three JPEG images.
Didn't work for me. I got:
unable to allocate media request 25
===
OK, after a bunch of debugging, I realized that I needed your series
from
Re: [PATCH 0/2] Add Updown Counter support for Milbeaut M10V SoC
On Tue, 26 Mar 2019 15:32:34 +0900 Shinji Kanematsu wrote: > This is a series of patch which adds Updown Counter support on > Milbeaut M10V SoC. > > The Updown Counter counts input pulse signal from external quadrature encoder. > It also has input pulse signal counter function. Hi Shinji, Are you aware of the counter subsystem that has been proposed (and as far as I am concerned is ready to be merged)? https://patchwork.kernel.org/project/linux-iio/list/?series=147 (I think that's the latest version posted).. William, perhaps you could give an update? (bad luck, you are getting popular ;) I'll take a quick review as it stands, as some issues may carry over. I appreciate that it's always unfortunate to try to upstream stuff at the same time as a new framework is being developed / upstreamed, but I don't intend to take any additional counter drivers into IIO. We just end up having to maintain old interfaces in more and more drivers. Thanks, Jonathan > > Shinji Kanematsu (2): > dt-bindings: iio: counter: Add Milbeaut Updown Counter > iio: counter: Add support for Milbeaut Updown Counter > > .../bindings/iio/counter/milbeaut-updown_cnt.txt | 22 ++ > drivers/iio/counter/Kconfig| 12 + > drivers/iio/counter/Makefile | 1 + > drivers/iio/counter/milbeaut-updown.h | 38 ++ > drivers/iio/counter/milbeaut-updown_cnt.c | 385 > + > 5 files changed, 458 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt > create mode 100644 drivers/iio/counter/milbeaut-updown.h > create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c >
Re: [Letux-kernel] [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
On Sun, 24 Mar 2019 07:56:17 +0100 "H. Nikolaus Schaller" wrote: > Hi Linus, > > > Am 24.03.2019 um 05:15 schrieb Linus Walleij : > > > > On Sat, Mar 23, 2019 at 3:40 PM H. Nikolaus Schaller > > wrote: > > > >> (1) c1c04cea13dc gpio: of: Fix logic inversion > >> > >> together with the basic patch > >> > >> (2) 6953c57ab172 gpio: of: Handle SPI chipselect legacy bindings > >> > >> leads to a severe regression for our GTA04 board. > > > > Sorry! :( > > > > I found the same problem on my Nomadik board. > > > > But I fixed it in that case by introducing a spi-cs-high into the DTS file: > > https://marc.info/?l=linux-arm-kernel=155292310015309=2 > > Yes, that of course works and is our temporary solution. > > And I see that you also have it on the controller node and not the slave node. > So if I get it right is a check added for undocumented properties (nothing about spi-cs-high in controller node in the bindings documentation, only in the slave node) in the two patches mentioned. And then you add that undocumented property to a dts file in your "fix". That all sounds strange to me. > > > >> I learned that it tries to handle a legacy "spi-cs-high" property of SPI > >> slaves, but was stopped > >> from doing so by a bug (1). So only with both patches, the legacy handler > >> becomes active which > >> explains why it was not noticed earlier. > >> > >> Now, our GTA04 device tree from 2014 (v3.16-rc1) was already written > >> without any legacy spi properties > >> in mind > > > > I'm sorry about that, however if you look at the DT binding document: > > Documentation/devicetree/bindings/spi/spi-bus.txt > > Shouldn't it be a property of the slave node and not the controller node? > > > > > You will see that spi-cs-high is mandatory. So these DTS files are > > incorrect. > > How do you read that it is mandatory from > > "All slave nodes can contain the following optional properties: > - spi-cs-high - Empty property indicating device requires chip select > active high." > > I read it as optional and indicative. Equal priority to cs-gpios. > Well, it is in the list of optional properties. So the question is how that "optional" is interpreted. Is it optional because you only use it if cs is active high or is it optional because you can either indicate that fact here or via gpio definition. But again that flags makes no sense in the controller node. Regards, Andreas
[RFC PATCH 1/7] rslib: Add tests for the encoder and decoder
A Reed-Solomon code with minimum distance d can correct any error and
erasure pattern that satisfies 2 * #error + #erasures < d. If the
error correction capacity is exceeded, then correct decoding cannot be
guaranteed. The decoder must, however, return a valid codeword or report
failure.
There are two main tests:
- Check for correct behaviour up to the error correction capacity
- Check for correct behaviour beyond error corrupted capacity
Both tests are simple:
1. Generate random data
2. Encode data with the chosen code
3. Add errors and erasures to data
4. Decode the corrupted word
5. Check for correct behaviour
When testing up to capacity we test for:
- Correct decoding
- Correct return value (i.e. the number of corrected symbols)
- That the returned error positions are correct
There are two kinds of erasures; the erased symbol can be corrupted or
not. When counting the number of corrected symbols, erasures without
symbol corruption should not be counted. Similarly, the returned error
positions should only include positions where a correction is necessary.
We run the up to capacity tests for three different interfaces of
decode_rs:
- Use the correction buffers
- Use the correction buffers with syndromes provided by the caller
- Error correction in place (does not check the error positions)
When testing beyond capacity we test for silent failures. A silent
failure is when the decoder returns success but the returned word is not
a valid codeword.
There are a couple of options for the tests:
- Verbosity.
- Whether to test for correct behaviour beyond capacity. Default is to
test beyond capacity.
- Whether to allow erasures without symbol corruption. Defaults to yes.
Note that the tests take a couple of minutes to complete.
Signed-off-by: Ferdinand Blomqvist
---
lib/Kconfig.debug | 12 +
lib/reed_solomon/Makefile | 2 +-
lib/reed_solomon/test_rslib.c | 519 ++
3 files changed, 532 insertions(+), 1 deletion(-)
create mode 100644 lib/reed_solomon/test_rslib.c
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0d9e81779e37..48f43583b3b6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1726,6 +1726,18 @@ config RBTREE_TEST
A benchmark measuring the performance of the rbtree library.
Also includes rbtree invariant checks.
+config REED_SOLOMON_TEST
+ tristate "Reed-Solomon library test"
+ depends on DEBUG_KERNEL || m
+ select REED_SOLOMON
+ select REED_SOLOMON_ENC16
+ select REED_SOLOMON_DEC16
+ help
+ This option enables the self-test function of rslib at boot,
+ or at module load time.
+
+ If unsure, say N.
+
config INTERVAL_TREE_TEST
tristate "Interval tree test"
depends on DEBUG_KERNEL
diff --git a/lib/reed_solomon/Makefile b/lib/reed_solomon/Makefile
index c3d7136827ed..e84ce076c6e5 100644
--- a/lib/reed_solomon/Makefile
+++ b/lib/reed_solomon/Makefile
@@ -3,4 +3,4 @@
#
obj-$(CONFIG_REED_SOLOMON) += reed_solomon.o
-
+obj-$(CONFIG_REED_SOLOMON_TEST) += test_rslib.o
diff --git a/lib/reed_solomon/test_rslib.c b/lib/reed_solomon/test_rslib.c
new file mode 100644
index ..c97b1dbadd4e
--- /dev/null
+++ b/lib/reed_solomon/test_rslib.c
@@ -0,0 +1,519 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Tests for Generic Reed Solomon encoder / decoder library
+ *
+ * Written by Ferdinand Blomqvist
+ * Based on previous work by Phil Karn, KA9Q
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum verbosity {
+ V_SILENT,
+ V_PROGRESS,
+ V_CSUMMARY
+};
+
+enum method {
+ CORR_BUFFER,
+ CALLER_SYNDROME,
+ IN_PLACE
+};
+
+#define __param(type, name, init, msg) \
+ static type name = init;\
+ module_param(name, type, 0444); \
+ MODULE_PARM_DESC(name, msg)
+
+__param(int, v, V_PROGRESS, "Verbosity level");
+__param(int, ewsc, 1, "Erasures without symbol corruption");
+__param(int, bc, 1, "Test for correct behaviour beyond error correction
capacity");
+
+struct etab {
+ int symsize;
+ int genpoly;
+ int fcs;
+ int prim;
+ int nroots;
+ int ntrials;
+};
+
+/* List of codes to test */
+static struct etab Tab[] = {
+ {2, 0x7,1, 1, 1, 10 },
+ {3, 0xb,1, 1, 2, 10 },
+ {3, 0xb,1, 1, 3, 10 },
+ {3, 0xb,2, 1, 4, 10 },
+ {4, 0x13, 1, 1, 4, 1 },
+ {5, 0x25, 1, 1, 6, 1000},
+ {6, 0x43, 3, 1, 8, 100 },
+ {7, 0x89, 1, 1, 10, 100 },
+ {8, 0x11d, 1, 1, 32, 100 },
+ {8, 0x187, 112,11, 32, 100 },
+ /*
+* {9, 0x211, 1, 1, 32, 100 },
+* {10, 0x409,
[RFC PATCH 6/7] rslib: Update documentation
The decoder returns the number of corrected symbols, not bits. The caller provided syndrome must be in index form. Signed-off-by: Ferdinand Blomqvist --- lib/reed_solomon/reed_solomon.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/lib/reed_solomon/reed_solomon.c b/lib/reed_solomon/reed_solomon.c index e5fdc8b9e856..bbc01bad3053 100644 --- a/lib/reed_solomon/reed_solomon.c +++ b/lib/reed_solomon/reed_solomon.c @@ -340,7 +340,8 @@ EXPORT_SYMBOL_GPL(encode_rs8); * @data: data field of a given type * @par: received parity data field * @len: data length - * @s:syndrome data field (if NULL, syndrome is calculated) + * @s:syndrome data field, must be in index form + * (if NULL, syndrome is calculated) * @no_eras: number of erasures * @eras_pos: position of erasures, can be NULL * @invmsk: invert data mask (will be xored on data, not on parity!) @@ -354,7 +355,8 @@ EXPORT_SYMBOL_GPL(encode_rs8); * decoding, so the caller has to ensure that decoder invocations are * serialized. * - * Returns the number of corrected bits or -EBADMSG for uncorrectable errors. + * Returns the number of corrected symbols or -EBADMSG for uncorrectable + * errors. The count includes errors in the parity. */ int decode_rs8(struct rs_control *rsc, uint8_t *data, uint16_t *par, int len, uint16_t *s, int no_eras, int *eras_pos, uint16_t invmsk, @@ -391,7 +393,8 @@ EXPORT_SYMBOL_GPL(encode_rs16); * @data: data field of a given type * @par: received parity data field * @len: data length - * @s:syndrome data field (if NULL, syndrome is calculated) + * @s:syndrome data field, must be in index form + * (if NULL, syndrome is calculated) * @no_eras: number of erasures * @eras_pos: position of erasures, can be NULL * @invmsk: invert data mask (will be xored on data, not on parity!) @@ -403,7 +406,8 @@ EXPORT_SYMBOL_GPL(encode_rs16); * decoding, so the caller has to ensure that decoder invocations are * serialized. * - * Returns the number of corrected bits or -EBADMSG for uncorrectable errors. + * Returns the number of corrected symbols or -EBADMSG for uncorrectable + * errors. The count includes errors in the parity. */ int decode_rs16(struct rs_control *rsc, uint16_t *data, uint16_t *par, int len, uint16_t *s, int no_eras, int *eras_pos, uint16_t invmsk, -- 2.17.2
[RFC PATCH 7/7] rslib: Fix remaining decoder flaws
The decoder is flawed in the following ways:
- The decoder sometimes fails silently, i.e. it announces success but
returns a word that is not a codeword.
- The return value of the decoder is incoherent with respect to how
fixed erasures are counted. If the word to be decoded is a codeword,
then the decoder always returns zero even if some erasures are given.
On the other hand, if the word to be decoded contains errors, then the
number of erasures is always included in the count of corrected
symbols. So the decoder handles erasures without symbol corruption
inconsistently. This inconsistency probably doesn't affect anyone
using the decoder, but it is inconsistent with the documentation.
- The error positions returned in eras_pos include all erasures, but the
corrections are only set in the correction buffer if there actually is
a symbol error. So if there are erasures without symbol corruption,
then the correction buffer will contain errors (unless initialized to
zero before calling the decoder) or some values will be unset (if the
correction buffer is uninitialized).
- When correcting data in-place the decoder does not correct errors in
the parity. On the other hand, when returning the errors in correction
buffers, errors in the parity are included.
The respective fixed are:
- The syndrome of a codeword is always zero, and the syndrome is linear,
.i.e, S(x+e) = S(x) + S(e). So compute the syndrome for the error and
check whether it equals the syndrome of the received word. If it does,
then we have decoded to a valid codeword, otherwise we know that we
have an uncorrectable error. Fortunately, some unrecoverable error
conditions can be detected earlier in the decoding, which saves some
processing power.
- Simply count and return the number of symbols actually corrected.
- Make sure to only return positions where symbols were corrected.
- Also fix errors in parity when correcting in-place. Another option
would be to completely disregard errors in the parity, but then the
interface makes it impossible to write tests that test for silent
failures.
Other changes:
- Only fill the correction buffer and error position buffer if both of
them are provided. Otherwise correct in place. Previously the error
position buffer was always populated with the positions of the
corrected errors, irrespective of whether a correction buffer was
supplied or not. The rationale for this change is that there seems to
be two use cases for the decoder; correct in-place or use the
correction buffers. The caller does not need the positions of the
corrected errors when in-place correction is used. If in-place
correction is not used, then both the correction buffer and error
position buffer need to be populated.
Signed-off-by: Ferdinand Blomqvist
---
lib/reed_solomon/decode_rs.c | 87 +++-
1 file changed, 67 insertions(+), 20 deletions(-)
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 7ecc449e57e9..33621ea67f67 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -22,6 +22,7 @@
uint16_t *index_of = rs->index_of;
uint16_t u, q, tmp, num1, num2, den, discr_r, syn_error;
int count = 0;
+ int num_corrected;
uint16_t msk = (uint16_t) rs->nn;
/*
@@ -182,6 +183,15 @@
if (lambda[i] != nn)
deg_lambda = i;
}
+
+ if (deg_lambda == 0) {
+ /*
+* deg(lambda) is zero even though the syndrome is non-zero
+* => uncorrectable error detected
+*/
+ return -EBADMSG;
+ }
+
/* Find roots of error+erasure locator polynomial by Chien search */
memcpy([1], [1], nroots * sizeof(reg[0]));
count = 0; /* Number of roots of lambda(x) */
@@ -195,6 +205,12 @@
}
if (q != 0)
continue; /* Not a root */
+
+ if (k < pad) {
+ /* Impossible error location. Uncorrectable error. */
+ return -EBADMSG;
+ }
+
/* store root (index-form) and error location number */
root[count] = i;
loc[count] = k;
@@ -229,7 +245,9 @@
/*
* Compute error values in poly-form. num1 = omega(inv(X(l))), num2 =
* inv(X(l))**(fcr-1) and den = lambda_pr(inv(X(l))) all in poly-form
+* Note: we reuse the buffer for b to store the correction pattern
*/
+ num_corrected = 0;
for (j = count - 1; j >= 0; j--) {
num1 = 0;
for (i = deg_omega; i >= 0; i--) {
@@ -237,6 +255,12 @@
num1 ^= alpha_to[rs_modnn(rs, omega[i] +
i * root[j])];
}
+
+ if (num1 ==
[RFC PATCH 5/7] rslib: Fix handling of of caller provided syndrome
Check if the syndrome provided by the caller is zero, and act
accordingly.
Signed-off-by: Ferdinand Blomqvist
---
lib/reed_solomon/decode_rs.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 78629bbe6590..7ecc449e57e9 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -42,8 +42,16 @@
BUG_ON(pad < 0 || pad >= nn - nroots);
/* Does the caller provide the syndrome ? */
- if (s != NULL)
- goto decode;
+ if (s != NULL) {
+ for (i = 0; i < nroots; i++) {
+ /* The syndrome is in index form, so nn represents zero */
+ if (s[i] != nn)
+ goto decode;
+ }
+
+ /* syndrome is zero, no errors to correct */
+ return 0;
+ }
/* form the syndromes; i.e., evaluate data(x) at roots of
* g(x) */
--
2.17.2
[RFC PATCH 2/7] rslib: Fix decoding of shortened codes
The decoder is broken. It only works with full length codes.
Signed-off-by: Ferdinand Blomqvist
---
lib/reed_solomon/decode_rs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 1db74eb098d0..3313bf944ff1 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -99,9 +99,9 @@
if (no_eras > 0) {
/* Init lambda to be the erasure locator polynomial */
lambda[1] = alpha_to[rs_modnn(rs,
- prim * (nn - 1 - eras_pos[0]))];
+ prim * (nn - 1 - (eras_pos[0] + pad)))];
for (i = 1; i < no_eras; i++) {
- u = rs_modnn(rs, prim * (nn - 1 - eras_pos[i]));
+ u = rs_modnn(rs, prim * (nn - 1 - (eras_pos[i] + pad)));
for (j = i + 1; j > 0; j--) {
tmp = index_of[lambda[j - 1]];
if (tmp != nn) {
--
2.17.2
[RFC PATCH 4/7] rslib: decode_rs: code cleanup
Nothing useful was done after the finish label when count is negative so
return directly instead of jumping to finish.
Signed-off-by: Ferdinand Blomqvist
---
lib/reed_solomon/decode_rs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 22006eaa41e6..78629bbe6590 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -88,8 +88,7 @@
/* if syndrome is zero, data[] is a codeword and there are no
* errors to correct. So return data[] unmodified
*/
- count = 0;
- goto finish;
+ return 0;
}
decode:
@@ -202,8 +201,7 @@
* deg(lambda) unequal to number of roots => uncorrectable
* error detected
*/
- count = -EBADMSG;
- goto finish;
+ return -EBADMSG;
}
/*
* Compute err+eras evaluator poly omega(x) = s(x)*lambda(x) (modulo
@@ -261,7 +259,6 @@
}
}
-finish:
if (eras_pos != NULL) {
for (i = 0; i < count; i++)
eras_pos[i] = loc[i] - pad;
--
2.17.2
[RFC PATCH 3/7] rslib: decode_rs: Fix length parameter check
The length of the data load must be at least one. Or in other words, there must be room for at least 1 data and nroots parity symbols after shortening the RS code. Signed-off-by: Ferdinand Blomqvist --- lib/reed_solomon/decode_rs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c index 3313bf944ff1..22006eaa41e6 100644 --- a/lib/reed_solomon/decode_rs.c +++ b/lib/reed_solomon/decode_rs.c @@ -39,7 +39,7 @@ /* Check length parameter for validity */ pad = nn - nroots - len; - BUG_ON(pad < 0 || pad >= nn); + BUG_ON(pad < 0 || pad >= nn - nroots); /* Does the caller provide the syndrome ? */ if (s != NULL) -- 2.17.2
[RFC PATCH 0/7] rslib: RS decoder is severely broken
The Reed_Solomon library used in the kernel is based on Phil Karn's fec library. When playing with this library I found a couple of bugs. It turn out that all of these bugs, and some additional flaws, are present in rslib. The Reed-Solomon decoder has several bugs/flaws: - Decoding of shortened codes is broken. - The decoder sometimes fails silently, i.e. it announces success but returns a word that is not a codeword. - The return value of the decoder is incoherent with respect to how fixed erasures are counted. If the word to be decoded is a codeword, then the decoder always returns zero even if some erasures are given. On the other hand, if the word to be decoded contains errors, then the number of erasures is always included in the count of corrected symbols. So the decoder handles erasures without symbol corruption inconsistently. This inconsistency probably doesn't affect anyone using the decoder, but it is inconsistent with the documentation. - The error positions returned in eras_pos include all erasures, but the corrections are only set in the correction buffer if there actually is a symbol error. So if there are erasures without symbol corruption, then the correction buffer will contain errors (unless initialized to zero before calling the decoder) or some values will be unset (if the correction buffer is uninitialized). - Assumes that the syndromes provided by callers are in index form. This is simply undocumented. - When correcting data in-place the decoder does not correct errors in the parity. On the other hand, when returning the errors in correction buffers, errors in the parity are included. This series provides a module with tests for rslib and fixes all the bugs/flaws. I am not sure that the provided self tests are written in the 'right way'. I just looked at other self tests in lib and implemented something similar. The fixes are tested with the self tests. They should probably also be tested with drivers etc. that use rslib, but it is unclear to me how to do this. I looked a bit on two of the drivers that use rslib: drivers/mtd/nand/raw/cafe_nand.c drivers/mtd/nand/raw/diskonchip.c Both of them seem to do some additional error checking after calling decode_rs16. Maybe this is needed because of the bugs in the decoder? Ferdinand Blomqvist (7): rslib: Add tests for the encoder and decoder rslib: Fix decoding of shortened codes rslib: decode_rs: Fix length parameter check rslib: decode_rs: code cleanup rslib: Fix handling of of caller provided syndrome rslib: Update documentation rslib: Fix remaining decoder flaws lib/Kconfig.debug | 12 + lib/reed_solomon/Makefile | 2 +- lib/reed_solomon/decode_rs.c| 112 +-- lib/reed_solomon/reed_solomon.c | 12 +- lib/reed_solomon/test_rslib.c | 519 5 files changed, 622 insertions(+), 35 deletions(-) create mode 100644 lib/reed_solomon/test_rslib.c -- 2.17.2
Re: [PATCH] iio: imu: mpu6050: Fix FIFO layout for ICM20602
On Tue, 26 Mar 2019 02:01:45 -0700
stev...@skydio.com wrote:
+CC Randolph, who I think introduced the support.
> From: Steve Moskovchenko
>
> The MPU6050 driver has recently gained support for the
> ICM20602 IMU, which is very similar to MPU6xxx. However,
> the ICM20602's Gyro data specifically includes temperature
> readings, which were not present on MPU6xxx parts. As a
> result, the driver will under-read the ICM20602's FIFO
> register, causing the same (partial) sample to be returned
> for all reads, until the FIFO overflows.
>
> Fix this by adding a table of scan elements speciically for
> the ICM20602, which takes the extra temperature data into
> consideration.
>
> While we're at it, fix the temperature offset and scaling
> on ICM20602, since it uses different scale/offset constants
> than the rest of the MPU6xxx devices.
>
> Signed-off-by: Steve Moskovchenko
Hi Steve
This all looks sensible to me. Ideally should have had a fixes tag.
If no one shouts in the next few days I'll pick this up and add one.
Give me a poke if I seem to have forgotten it in a week or so.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 46 --
> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 20 +-
> drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 8 +++-
> 3 files changed, 67 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index 650de0fefb7b..fedd3f2b0135 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -471,7 +471,10 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT_PLUS_MICRO;
> case IIO_TEMP:
> *val = 0;
> - *val2 = INV_MPU6050_TEMP_SCALE;
> + if (st->chip_type == INV_ICM20602)
> + *val2 = INV_ICM20602_TEMP_SCALE;
> + else
> + *val2 = INV_MPU6050_TEMP_SCALE;
>
> return IIO_VAL_INT_PLUS_MICRO;
> default:
> @@ -480,7 +483,10 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_OFFSET:
> switch (chan->type) {
> case IIO_TEMP:
> - *val = INV_MPU6050_TEMP_OFFSET;
> + if (st->chip_type == INV_ICM20602)
> + *val = INV_ICM20602_TEMP_OFFSET;
> + else
> + *val = INV_MPU6050_TEMP_OFFSET;
>
> return IIO_VAL_INT;
> default:
> @@ -845,6 +851,32 @@ static const struct iio_chan_spec inv_mpu_channels[] = {
> INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_MPU6050_SCAN_ACCL_Z),
> };
>
> +static const struct iio_chan_spec inv_icm20602_channels[] = {
> + IIO_CHAN_SOFT_TIMESTAMP(INV_ICM20602_SCAN_TIMESTAMP),
> + {
> + .type = IIO_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
> + | BIT(IIO_CHAN_INFO_OFFSET)
> + | BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = INV_ICM20602_SCAN_GYRO_TEMP,
> + .scan_type = {
> + .sign = 's',
> + .realbits = 16,
> + .storagebits = 16,
> + .shift = 0,
> + .endianness = IIO_BE,
> + },
> + },
> +
> + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_X, INV_ICM20602_SCAN_GYRO_X),
> + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_Y, INV_ICM20602_SCAN_GYRO_Y),
> + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_Z, INV_ICM20602_SCAN_GYRO_Z),
> +
> + INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Y, INV_ICM20602_SCAN_ACCL_Y),
> + INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_X, INV_ICM20602_SCAN_ACCL_X),
> + INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_ICM20602_SCAN_ACCL_Z),
> +};
> +
> /*
> * The user can choose any frequency between INV_MPU6050_MIN_FIFO_RATE and
> * INV_MPU6050_MAX_FIFO_RATE, but only these frequencies are matched by the
> @@ -1100,8 +1132,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq,
> const char *name,
> indio_dev->name = name;
> else
> indio_dev->name = dev_name(dev);
> - indio_dev->channels = inv_mpu_channels;
> - indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels);
> +
> + if (chip_type == INV_ICM20602) {
> + indio_dev->channels = inv_icm20602_channels;
> + indio_dev->num_channels = ARRAY_SIZE(inv_icm20602_channels);
> + } else {
> + indio_dev->channels = inv_mpu_channels;
> + indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels);
> + }
>
> indio_dev->info = _info;
> indio_dev->modes = INDIO_BUFFER_TRIGGERED;
> diff --git
[PATCH v2] trace: events: fix error directive in argument list
This patch fixes below spare errors.
Sparse error:
make C=2 CF=-D__CHECK_ENDIAN__ M=net/core
./include/trace/events/neigh.h:73:1: error: directive in argument list
./include/trace/events/neigh.h:78:1: error: directive in argument list
./include/trace/events/neigh.h:150:1: error: directive in argument list
./include/trace/events/neigh.h:155:1: error: directive in argument list
Changes below two lines to signle line to avoid sparse error
if (n->tbl->family == AF_INET6) {
to if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6)
Signed-off-by: Hariprasad Kelam
---
Changes in V2:
-Divide patch to only address spare error
---
include/trace/events/neigh.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/neigh.h b/include/trace/events/neigh.h
index 0bdb085..2ca0180 100644
--- a/include/trace/events/neigh.h
+++ b/include/trace/events/neigh.h
@@ -70,12 +70,10 @@ TRACE_EVENT(neigh_update,
else
*p32 = 0;
-#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl->family == AF_INET6) {
+ if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6) {
pin6 = (struct in6_addr *)__entry->primary_key6;
*pin6 = *(struct in6_addr *)n->primary_key;
} else
-#endif
{
ipv6_addr_set_v4mapped(*p32, pin6);
}
@@ -147,12 +145,10 @@ DECLARE_EVENT_CLASS(neigh__update,
else
*p32 = 0;
-#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl->family == AF_INET6) {
+ if (IS_ENABLED(CONFIG_IPV6) && n->tbl->family == AF_INET6) {
pin6 = (struct in6_addr *)__entry->primary_key6;
*pin6 = *(struct in6_addr *)n->primary_key;
} else
-#endif
{
ipv6_addr_set_v4mapped(*p32, pin6);
}
--
2.7.4
Re: [PATCH] jbd2: do not start commit when t_updates does not back tozero
On Sat, Mar 30, 2019 at 03:24:44PM +0800, liu.son...@zte.com.cn wrote: > > When we unzipped bunch of files under ext4, sometimes got hungtask warning > which indicate process was waiting on "j_wait_transaction_locked". Can you give a clean repro of this? What sort of storage device are you using, and what sort of file systems and mount options are you using? I unzip files under ext4 all the time w/o any problems - Ted
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 05:59:34PM +, Jonathan Kowalski wrote:
> On Sat, Mar 30, 2019 at 5:52 PM Christian Brauner
> wrote:
> >
> > On Sat, Mar 30, 2019 at 05:50:20PM +, Jonathan Kowalski wrote:
> > > On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
> > > wrote:
> > > >
> > > > On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> > > > wrote:
> > > > >
> > > > >
> > > > > To clarify, what the Android guys really wanted to be part of the api
> > > > > is
> > > > > a way to get race-free access to metadata associated with a given
> > > > > pidfd.
> > > > > And the idea was that *if and only if procfs is mounted* you could do:
> > > > >
> > > > > int pidfd = pidfd_open(1234, 0);
> > > > >
> > > > > int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> > > > > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
> > > >
> > > > And my claim is that this is three system calls - one of them very
> > > > hacky - to just do
> > > >
> > > > int pidfd = open("/proc/%d", O_PATH);
> > > >
> > > > and you're done. It acts as the pidfd _and_ the way to get the
> > > > associated status files etc.
> > > >
> > > > So there is absolutely zero advantage to going through pidfd_open().
> > > >
> > > > No. No. No.
> > > >
> > > > So the *only* reason for "pidfd_open()" is if you don't have /proc in
> > > > the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
> > > >
> > > > Yeah, yeah, if you want to avoid going through the pathname
> > > > translation, that's one thing, but if that's your aim, then you again
> > > > should also just admit that PIDFD_TO_PROCFD is disgusting and wrong,
> > > > and you're basically saying "ok, I'm not going to do /proc at all".
> > > >
> > > > So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it
> > > > really has to be *SIMPLER* and *NO PROCFS*.
> > > >
> > >
> > > (Resending because accidently it wasn't a reply-all)
> > >
> > > If you go with pidfd_open, that should also mean you remove the
> > > ability to be able to use /proc/ dir fds in pidfd_send_signal.
> > >
> > > Otherwise the semantics are hairy: I can only pidfd_open a task
> > > reachable from my active namespace, but somehow also be able to open a
> >
> > You can easily setns() to another pid namespace and get a pidfd there.
> > That's how most namespace interactions work right now. We already had
> > that discussion.
>
> Only if it is a child namespace, or you have the relevant capabilities to
> setns.
>
> Currently, if I just put a task in PID namespace, it can see /proc of
> an ancestor PID namespace, and opendir /proc/, this is accepted
> by pidfd_send_signal.
>
> If you ever allow signalling across PID namespaces (because file
That's not on the plate for now and pidfd_send_signal() is checking for
that to not allow it.
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 6:24 PM Linus Torvalds
wrote:
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And the idea was that *if and only if procfs is mounted* you could do:
> >
> > int pidfd = pidfd_open(1234, 0);
> >
> > int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
>
> And my claim is that this is three system calls - one of them very
> hacky - to just do
>
> int pidfd = open("/proc/%d", O_PATH);
>
> and you're done. It acts as the pidfd _and_ the way to get the
> associated status files etc.
>
> So there is absolutely zero advantage to going through pidfd_open().
>
> No. No. No.
>
> So the *only* reason for "pidfd_open()" is if you don't have /proc in
> the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
So if, in the future, there is some sort of "create a new task and
return an fd to it" syscall, do you think it should always return
pidfds, or do you think it should return fds to /proc if procfs is
available? And if it should return fds to /proc, does that mean that
this "create a task" API should take an extra argument with a file
descriptor to the procfs instance you want to use?
(This can't always be implemented easily in userspace on top of normal
clone(), because if you create a task without a termination signal -
like a thread -, its PID can be recycled under you.)
An API like this would have less complexity stuffed into a single
syscall if it always returns pidfds, and if you then actually want an
fd to procfs, you can do the conversion that requires specifying a
procfs instance separately.
Of course, if you think that we shouldn't add an API for
pidfd-to-procfs conversion before we have an API for
clone()-with-an-fd-retval, that's understandable.
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 5:52 PM Christian Brauner wrote:
>
> On Sat, Mar 30, 2019 at 05:50:20PM +, Jonathan Kowalski wrote:
> > On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
> > wrote:
> > >
> > > On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> > > wrote:
> > > >
> > > >
> > > > To clarify, what the Android guys really wanted to be part of the api is
> > > > a way to get race-free access to metadata associated with a given pidfd.
> > > > And the idea was that *if and only if procfs is mounted* you could do:
> > > >
> > > > int pidfd = pidfd_open(1234, 0);
> > > >
> > > > int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> > > > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
> > >
> > > And my claim is that this is three system calls - one of them very
> > > hacky - to just do
> > >
> > > int pidfd = open("/proc/%d", O_PATH);
> > >
> > > and you're done. It acts as the pidfd _and_ the way to get the
> > > associated status files etc.
> > >
> > > So there is absolutely zero advantage to going through pidfd_open().
> > >
> > > No. No. No.
> > >
> > > So the *only* reason for "pidfd_open()" is if you don't have /proc in
> > > the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
> > >
> > > Yeah, yeah, if you want to avoid going through the pathname
> > > translation, that's one thing, but if that's your aim, then you again
> > > should also just admit that PIDFD_TO_PROCFD is disgusting and wrong,
> > > and you're basically saying "ok, I'm not going to do /proc at all".
> > >
> > > So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it
> > > really has to be *SIMPLER* and *NO PROCFS*.
> > >
> >
> > (Resending because accidently it wasn't a reply-all)
> >
> > If you go with pidfd_open, that should also mean you remove the
> > ability to be able to use /proc/ dir fds in pidfd_send_signal.
> >
> > Otherwise the semantics are hairy: I can only pidfd_open a task
> > reachable from my active namespace, but somehow also be able to open a
>
> You can easily setns() to another pid namespace and get a pidfd there.
> That's how most namespace interactions work right now. We already had
> that discussion.
Only if it is a child namespace, or you have the relevant capabilities to setns.
Currently, if I just put a task in PID namespace, it can see /proc of
an ancestor PID namespace, and opendir /proc/, this is accepted
by pidfd_send_signal.
If you ever allow signalling across PID namespaces (because file
descriptors should be able to do that, they are not namespaced, see
files, sockets, etc), it will become a problem. Getting pidfds from
outside my active namespace should require userspace cooperation.
So, opening a pidfd should be limited to what *I* can see in my
namespace, like every other namespace. That is what a namespace is,
and PIDs have their own namespace, they're not exposed in the
filesystem namespace.
Re: [PATCH 2/4] PCI: Fix comment typos
On 3/25/2019 11:44 PM, helg...@kernel.org wrote:
From: Bjorn Helgaas
Fix spelling errors and format function comments consistently. Changes
whitespace and comments only; no functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
drivers/pci/controller/dwc/pci-keystone.c | 2 +-
drivers/pci/controller/pci-host-generic.c | 2 +-
drivers/pci/controller/pcie-iproc-msi.c | 2 +-
drivers/pci/pci.c | 328 +++---
4 files changed, 173 insertions(+), 161 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c
b/drivers/pci/controller/dwc/pci-keystone.c
index 14f2b0b4ed5e..9b4112095658 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -661,7 +661,7 @@ static int ks_pcie_get_irq_controller_info(struct
keystone_pcie *ks_pcie,
(legacy ? "legacy" : "MSI"), temp);
/*
-* support upto max_host_irqs. In dt from index 0 to 3 (legacy) or 0 to
+* support up to max_host_irqs. In DT from index 0 to 3 (legacy) or 0 to
* 7 (MSI)
*/
for (temp = 0; temp < max_host_irqs; temp++) {
diff --git a/drivers/pci/controller/pci-host-generic.c
b/drivers/pci/controller/pci-host-generic.c
index dea3ec7592a2..75a2fb930d4b 100644
--- a/drivers/pci/controller/pci-host-generic.c
+++ b/drivers/pci/controller/pci-host-generic.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Simple, generic PCI host controller driver targetting firmware-initialised
+ * Simple, generic PCI host controller driver targeting firmware-initialised
* systems and virtual machines (e.g. the PCI emulation provided by kvmtool).
*
* Copyright (C) 2014 ARM Limited
diff --git a/drivers/pci/controller/pcie-iproc-msi.c
b/drivers/pci/controller/pcie-iproc-msi.c
index cb3401a931f8..0a3f61be5625 100644
--- a/drivers/pci/controller/pcie-iproc-msi.c
+++ b/drivers/pci/controller/pcie-iproc-msi.c
@@ -367,7 +367,7 @@ static void iproc_msi_handler(struct irq_desc *desc)
/*
* Now go read the tail pointer again to see if there are new
-* oustanding events that came in during the above window.
+* outstanding events that came in during the above window.
*/
} while (true);
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7c1b362f599a..530eec3191e7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -197,8 +197,8 @@ EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
/**
* pci_dev_str_match_path - test if a path string matches a device
- * @dev:the PCI device to test
- * @path: string to match the device against
+ * @dev: the PCI device to test
+ * @path: string to match the device against
* @endptr: pointer to the string after the match
*
* Test if a string (typically from a kernel parameter) formatted as a
@@ -280,8 +280,8 @@ static int pci_dev_str_match_path(struct pci_dev *dev,
const char *path,
/**
* pci_dev_str_match - test if a string matches a device
- * @dev:the PCI device to test
- * @p: string to match the device against
+ * @dev: the PCI device to test
+ * @p: string to match the device against
* @endptr: pointer to the string after the match
*
* Test if a string (typically from a kernel parameter) matches a specified
@@ -341,7 +341,7 @@ static int pci_dev_str_match(struct pci_dev *dev, const
char *p,
} else {
/*
* PCI Bus, Device, Function IDs are specified
-* (optionally, may include a path of devfns following it)
+* (optionally, may include a path of devfns following it)
*/
ret = pci_dev_str_match_path(dev, p, );
if (ret < 0)
@@ -425,7 +425,7 @@ static int __pci_bus_find_cap_start(struct pci_bus *bus,
* Tell if a device supports a given PCI capability.
* Returns the address of the requested capability structure within the
* device's PCI configuration space or 0 in case the device does not
- * support it. Possible values for @cap:
+ * support it. Possible values for @cap include:
*
* %PCI_CAP_ID_PM Power Management
* %PCI_CAP_ID_AGP Accelerated Graphics Port
@@ -450,11 +450,11 @@ EXPORT_SYMBOL(pci_find_capability);
/**
* pci_bus_find_capability - query for devices' capabilities
- * @bus: the PCI bus to query
+ * @bus: the PCI bus to query
* @devfn: PCI device to query
- * @cap: capability code
+ * @cap: capability code
*
- * Like pci_find_capability() but works for pci devices that do not have a
+ * Like pci_find_capability() but works for PCI devices that do not have a
* pci_dev structure set up yet.
*
* Returns the address of the requested capability structure within the
@@ -535,7 +535,7 @@ EXPORT_SYMBOL_GPL(pci_find_next_ext_capability);
*
* Returns the address of the
Re: [PATCH v2] MAINTAINERS: Fix the link to ad7606 dt-bindings
On Tue, 26 Mar 2019 12:59:52 +0200
Stefan Popa wrote:
> The devicetree bindings documentation for ad7606 should also include
> the vendor prefix: ad7606.txt -> adi,ad7606.txt
>
> Fixes: 6e33a125df66 ("dt-bindings: iio: adc: Add docs for AD7606 ADC")
> Signed-off-by: Stefan Popa
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v2:
> - Added Fixes tag
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ff2c2f2..4f81cdc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -860,7 +860,7 @@ L:linux-...@vger.kernel.org
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/adc/ad7606.c
> -F: Documentation/devicetree/bindings/iio/adc/ad7606.txt
> +F: Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
>
> ANALOG DEVICES INC AD7768-1 DRIVER
> M: Stefan Popa
Re: [PATCH v7 3/3] iio:temperature: Add MAX31856 thermocouple support
On Tue, 26 Mar 2019 12:18:42 +0100
Patrick Havelange wrote:
> From: Paresh Chaudhary
>
> This patch adds support for Maxim MAX31856 thermocouple
> temperature sensor support.
>
> More information can be found in:
> https://www.maximintegrated.com/en/ds/MAX31856.pdf
>
> NOTE: Driver support only Comparator Mode.
>
> Signed-off-by: Paresh Chaudhary
> Signed-off-by: Matt Weber
> Signed-off-by: Patrick Havelange
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes
> v1 -> v2
> [Peter
> 1. Fixed all space & 'return' related comments
> 2. Removed 'sysfs_create_group' api because
> iio_device_register function is handling sysfs entry
> 3. Return -EIO if there is any fault
> 4. Added check for 'read_size' before spi read call
> 5. Removed license text from the source file
> 6. Added .o file in alphabetic order
> 7. Used #defines instead of magic bits
>
> v2 -> v3
> [Jonathan
> 1. Used bool for fault_oc and fault_ovuv
> 2. Changed 'max31856_read' function and use byte array to
> store registers value.
> 3. Used 'GENMASK' where required
> 4. Changed logic 'max31856_thermocouple_read' function. Used
> array to read registers value.
> 5. Used 'devm_iio_device_register' and removed 'max31856_remove'.
> 6. Fixed other cosmetic changes.
> 7. Added 'sysfs-bus-iio-temperature-max31856' file and updated
> 'MAINTAINERS' file.
>
> v3 -> v4
> [Jonathan
> 1. Removed unwanted logic
> 2. Updated code to handle return value of max31856_read call
> 3. Added devicetree id table
> 4. Removed one-shot support from driver as this support was not
> implemented with correct design.
>
> v4 -> v5
> [Patrick
> 1. Rename thermocouple type to maxim,thermocouple-type for DT entry
> 2. Don't cache values from the Fault Status Register
> 3. Simplify a bit max31856_init()
> 4. Use IIO_NO_MOD in switch case + default error case
> 5. Use dev_*() instead of pr_*()
> 6. Fix missing space in comments
> 7. Removed iio_info.driver_module assignment as no longer present
> 8. Don't keep read/write buffer into the internal driver struct
> 9. Updated kernel version, add missing space in documentation
>10. Updated (c) year
>11. Removed linux/init.h #include
>12. More use of BIT() macro
>13. Removed iio_chan_spec.address assignment as not used
>14. In max31856_thermocouple_read(), same switch case order as
> channels definition
>15. Refactor show_fault_*() functions
>16. Use u8 as register type in max31856_{read,write}()
>
> v5 -> v6
> [Patrick
> 1. Use generic thermocouple-type property
> 2. Fix doc for fault_ovuv entry
> 3. Add check for supported thermocouple-types in probe()
>
> v6 -> v7
> [Patrick
> 1. None
> ---
> .../sysfs-bus-iio-temperature-max31856| 24 ++
> drivers/iio/temperature/Kconfig | 10 +
> drivers/iio/temperature/Makefile | 1 +
> drivers/iio/temperature/max31856.c| 353 ++
> 4 files changed, 388 insertions(+)
> create mode 100644
> Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
> create mode 100644 drivers/iio/temperature/max31856.c
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
> b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
> new file mode 100644
> index ..3b3509a3ef2f
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
> @@ -0,0 +1,24 @@
> +What:/sys/bus/iio/devices/iio:deviceX/fault_oc
> +KernelVersion: 5.1
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Open-circuit fault. The detection of open-circuit faults,
> + such as those caused by broken thermocouple wires.
> + Reading returns either '1' or '0'.
> + '1' = An open circuit such as broken thermocouple wires
> + has been detected.
> + '0' = No open circuit or broken thermocouple wires are detected
> +
> +What:/sys/bus/iio/devices/iio:deviceX/fault_ovuv
> +KernelVersion: 5.1
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Overvoltage or Undervoltage Input Fault. The internal circuitry
> + is protected from excessive voltages applied to the thermocouple
> + cables by integrated MOSFETs at the T+ and T- inputs, and the
> + BIAS output. These MOSFETs turn off when the input voltage is
> + negative or greater than VDD.
> + Reading returns either '1' or '0'.
> + '1' = The input voltage is negative or greater than VDD.
> + '0' = The input voltage is positive and less than VDD
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 05:50:20PM +, Jonathan Kowalski wrote:
> On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
> wrote:
> >
> > On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> > wrote:
> > >
> > >
> > > To clarify, what the Android guys really wanted to be part of the api is
> > > a way to get race-free access to metadata associated with a given pidfd.
> > > And the idea was that *if and only if procfs is mounted* you could do:
> > >
> > > int pidfd = pidfd_open(1234, 0);
> > >
> > > int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> > > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
> >
> > And my claim is that this is three system calls - one of them very
> > hacky - to just do
> >
> > int pidfd = open("/proc/%d", O_PATH);
> >
> > and you're done. It acts as the pidfd _and_ the way to get the
> > associated status files etc.
> >
> > So there is absolutely zero advantage to going through pidfd_open().
> >
> > No. No. No.
> >
> > So the *only* reason for "pidfd_open()" is if you don't have /proc in
> > the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
> >
> > Yeah, yeah, if you want to avoid going through the pathname
> > translation, that's one thing, but if that's your aim, then you again
> > should also just admit that PIDFD_TO_PROCFD is disgusting and wrong,
> > and you're basically saying "ok, I'm not going to do /proc at all".
> >
> > So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it
> > really has to be *SIMPLER* and *NO PROCFS*.
> >
>
> (Resending because accidently it wasn't a reply-all)
>
> If you go with pidfd_open, that should also mean you remove the
> ability to be able to use /proc/ dir fds in pidfd_send_signal.
>
> Otherwise the semantics are hairy: I can only pidfd_open a task
> reachable from my active namespace, but somehow also be able to open a
You can easily setns() to another pid namespace and get a pidfd there.
That's how most namespace interactions work right now. We already had
that discussion.
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
wrote:
>
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> >
> >
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And the idea was that *if and only if procfs is mounted* you could do:
> >
> > int pidfd = pidfd_open(1234, 0);
> >
> > int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
>
> And my claim is that this is three system calls - one of them very
> hacky - to just do
>
> int pidfd = open("/proc/%d", O_PATH);
>
> and you're done. It acts as the pidfd _and_ the way to get the
> associated status files etc.
>
> So there is absolutely zero advantage to going through pidfd_open().
>
> No. No. No.
>
> So the *only* reason for "pidfd_open()" is if you don't have /proc in
> the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
>
> Yeah, yeah, if you want to avoid going through the pathname
> translation, that's one thing, but if that's your aim, then you again
> should also just admit that PIDFD_TO_PROCFD is disgusting and wrong,
> and you're basically saying "ok, I'm not going to do /proc at all".
>
> So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it
> really has to be *SIMPLER* and *NO PROCFS*.
>
(Resending because accidently it wasn't a reply-all)
If you go with pidfd_open, that should also mean you remove the
ability to be able to use /proc/ dir fds in pidfd_send_signal.
Otherwise the semantics are hairy: I can only pidfd_open a task
reachable from my active namespace, but somehow also be able to open a
pidfd if I happen to see someone's /proc in my mount namespace and
have the access to open it?
> PIDFD_TO_PROCFD violates *everything*.
>
> Linus
Re: [PATCH] mm: Fix build warning
On 3/30/2019 11:12 AM, Aneesh Kumar K.V wrote: mm/debug.c: In function ‘dump_mm’: include/linux/kern_levels.h:5:18: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 19 has type ‘long int’ [-Wformat=] ~~~^ Signed-off-by: Aneesh Kumar K.V Does it come even after this patch ? https://patchwork.kernel.org/patch/10846421/ Thanks. Mukesh --- mm/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/debug.c b/mm/debug.c index c0b31b6c3877..c134e76918dc 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -137,7 +137,7 @@ void dump_mm(const struct mm_struct *mm) "mmap_base %lu mmap_legacy_base %lu highest_vm_end %lu\n" "pgd %px mm_users %d mm_count %d pgtables_bytes %lu map_count %d\n" "hiwater_rss %lx hiwater_vm %lx total_vm %lx locked_vm %lx\n" - "pinned_vm %llx data_vm %lx exec_vm %lx stack_vm %lx\n" + "pinned_vm %lx data_vm %lx exec_vm %lx stack_vm %lx\n" "start_code %lx end_code %lx start_data %lx end_data %lx\n" "start_brk %lx brk %lx start_stack %lx\n" "arg_start %lx arg_end %lx env_start %lx env_end %lx\n"
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 10:24:19AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> >
> >
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And the idea was that *if and only if procfs is mounted* you could do:
> >
> > int pidfd = pidfd_open(1234, 0);
> >
> > int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
>
> And my claim is that this is three system calls - one of them very
> hacky - to just do
>
> int pidfd = open("/proc/%d", O_PATH);
>
> and you're done. It acts as the pidfd _and_ the way to get the
> associated status files etc.
>
> So there is absolutely zero advantage to going through pidfd_open().
>
> No. No. No.
>
> So the *only* reason for "pidfd_open()" is if you don't have /proc in
> the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
>
> Yeah, yeah, if you want to avoid going through the pathname
> translation, that's one thing, but if that's your aim, then you again
> should also just admit that PIDFD_TO_PROCFD is disgusting and wrong,
> and you're basically saying "ok, I'm not going to do /proc at all".
>
> So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it
Understood.
> really has to be *SIMPLER* and *NO PROCFS*.
>
> PIDFD_TO_PROCFD violates *everything*.
Re: [GIT PULL][UPDATED] security: yama and LSM config fixes
The pull request you sent on Sat, 30 Mar 2019 08:12:07 +1100 (AEDT): > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > fixes-v5.1-a has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/12195302ee6c32cf3c0fa947e17303ce583d41c9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] ACPI fix for v5.1-rc3
The pull request you sent on Sat, 30 Mar 2019 01:38:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-5.1-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/782492a7a4807317319a0b1832594d07ba79747d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Power management fixes for v5.1-rc3
The pull request you sent on Sat, 30 Mar 2019 01:37:43 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.1-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8e377a1c7e2465831b39dbe24ec04c0a8b36fc76 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] security: yama fix for v5.1
The pull request you sent on Sat, 30 Mar 2019 05:10:48 +1100 (AEDT): > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > fixes-v5.1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2623c4fbe2ad1341ff2d1e12410d0afdae2490ca Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner wrote:
>
>
> To clarify, what the Android guys really wanted to be part of the api is
> a way to get race-free access to metadata associated with a given pidfd.
> And the idea was that *if and only if procfs is mounted* you could do:
>
> int pidfd = pidfd_open(1234, 0);
>
> int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
> int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
And my claim is that this is three system calls - one of them very
hacky - to just do
int pidfd = open("/proc/%d", O_PATH);
and you're done. It acts as the pidfd _and_ the way to get the
associated status files etc.
So there is absolutely zero advantage to going through pidfd_open().
No. No. No.
So the *only* reason for "pidfd_open()" is if you don't have /proc in
the first place. In which case the whole PIDFD_TO_PROCFD is bogus.
Yeah, yeah, if you want to avoid going through the pathname
translation, that's one thing, but if that's your aim, then you again
should also just admit that PIDFD_TO_PROCFD is disgusting and wrong,
and you're basically saying "ok, I'm not going to do /proc at all".
So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it
really has to be *SIMPLER* and *NO PROCFS*.
PIDFD_TO_PROCFD violates *everything*.
Linus
Re: [PATCH 4.9 25/30] USB: core: only clean up what we allocated
On Tue, Mar 26, 2019 at 03:30:04PM +0900, Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Andrey Konovalov
>
> commit 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3 upstream.
>
> When cleaning up the configurations, make sure we only free the number
> of configurations and interfaces that we could have allocated.
>
> Reported-by: Andrey Konovalov
> Cc: stable
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/usb/core/config.c |9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> --- a/drivers/usb/core/config.c
> +++ b/drivers/usb/core/config.c
> @@ -763,18 +763,21 @@ void usb_destroy_configuration(struct us
> return;
>
> if (dev->rawdescriptors) {
> - for (i = 0; i < dev->descriptor.bNumConfigurations; i++)
> + for (i = 0; i < dev->descriptor.bNumConfigurations &&
> + i < USB_MAXCONFIG; i++)
> kfree(dev->rawdescriptors[i]);
>
> kfree(dev->rawdescriptors);
> dev->rawdescriptors = NULL;
> }
>
> - for (c = 0; c < dev->descriptor.bNumConfigurations; c++) {
> + for (c = 0; c < dev->descriptor.bNumConfigurations &&
> + c < USB_MAXCONFIG; c++) {
> struct usb_host_config *cf = >config[c];
>
> kfree(cf->string);
> - for (i = 0; i < cf->desc.bNumInterfaces; i++) {
> + for (i = 0; i < cf->desc.bNumInterfaces &&
> + i < USB_MAXINTERFACES; i++) {
> if (cf->intf_cache[i])
> kref_put(>intf_cache[i]->ref,
> usb_release_interface_cache);
>
>
You reverted this upstream in commit cf4df407e0d7 ("Revert "USB: core:
only clean up what we allocated"") in favor of commit 48a4ff1c7bb5
("USB: core: prevent malicious bNumInterfaces overflow"), which has been
in this tree since 4.9.71.
Sorry for not catching this earlier,
Nathan
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 10:04:33AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 9:34 AM Daniel Colascione wrote:
> >
> > Just to be clear, I'm not proposing granting secret access to procfs,
> > and as far as I can see, nobody else is either. We've been talking
> > about making it easier to avoid races when you happen to want a pidfd
> > and a procfs fd that point to the same process
>
> So I thought that was the whole point of just opening /proc/.
> Exactly because that way you can then use openat() from there on.
To clarify, what the Android guys really wanted to be part of the api is
a way to get race-free access to metadata associated with a given pidfd.
And the idea was that *if and only if procfs is mounted* you could do:
int pidfd = pidfd_open(1234, 0);
int procfd = open("/proc", O_RDONLY | O_CLOEXEC);
int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd);
and then we internally verify that the struct pid that the pidfd is
refering to, is still the same as the one that /proc/ is refering
to and only then do we return an fd for the process /proc/
directory which would then allow you to do, e.g.:
int statusfd = openat(procpidfd, "status", O_RDONLY | O_CLOEXEC);
this would provide race-free access to metadat but again, only if /proc
is mounted and available to the user. But if that's an instant NAK we
will definitely *not* do this.
Re: [PATCH v2 1/6] ARM: davinci: add missing sentinels to GPIO lookup tables
sob., 30 mar 2019 o 14:45 Sasha Levin napisał(a):
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.0.5, v4.19.32, v4.14.109,
> v4.9.166, v4.4.177, v3.18.137.
>
> v5.0.5: Failed to apply! Possible dependencies:
> 1703cf5d4fc0 ("ARM: davinci: da830-evm: use gpio lookup entries for usb
> gpios")
> c08df69149db ("ARM: davinci: omapl138-hawk: use gpio lookup entries for
> usb gpios")
>
> v4.19.32: Failed to apply! Possible dependencies:
> 1703cf5d4fc0 ("ARM: davinci: da830-evm: use gpio lookup entries for usb
> gpios")
> c08df69149db ("ARM: davinci: omapl138-hawk: use gpio lookup entries for
> usb gpios")
>
> v4.14.109: Failed to apply! Possible dependencies:
> 1703cf5d4fc0 ("ARM: davinci: da830-evm: use gpio lookup entries for usb
> gpios")
> c08df69149db ("ARM: davinci: omapl138-hawk: use gpio lookup entries for
> usb gpios")
> cd2428c368a6 ("i2c: davinci: switch to using gpiod for bus recovery
> gpios")
> e53537653791 ("i2c/ARM: davinci: Deep refactoring of I2C recovery")
>
> v4.9.166: Failed to apply! Possible dependencies:
> 1703cf5d4fc0 ("ARM: davinci: da830-evm: use gpio lookup entries for usb
> gpios")
> 1b6fe9798af8 ("ARM: davinci: board-da850-evm: fix WP pin polarity for
> MMC/SD")
> 51e9f1216322 ("ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD")
> 67c6b6ff221f ("ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD")
> b5e1438cf98a ("ARM: davinci: da830-evm: use gpio descriptor for mmc pins")
> bdf0e8364fd3 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins")
> c08df69149db ("ARM: davinci: omapl138-hawk: use gpio lookup entries for
> usb gpios")
> cd2428c368a6 ("i2c: davinci: switch to using gpiod for bus recovery
> gpios")
> e53537653791 ("i2c/ARM: davinci: Deep refactoring of I2C recovery")
>
> v4.4.177: Failed to apply! Possible dependencies:
> 1703cf5d4fc0 ("ARM: davinci: da830-evm: use gpio lookup entries for usb
> gpios")
> 1b6fe9798af8 ("ARM: davinci: board-da850-evm: fix WP pin polarity for
> MMC/SD")
> 51e9f1216322 ("ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD")
> 67c6b6ff221f ("ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD")
> b5e1438cf98a ("ARM: davinci: da830-evm: use gpio descriptor for mmc pins")
> bdf0e8364fd3 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins")
> c08df69149db ("ARM: davinci: omapl138-hawk: use gpio lookup entries for
> usb gpios")
> cd2428c368a6 ("i2c: davinci: switch to using gpiod for bus recovery
> gpios")
> e53537653791 ("i2c/ARM: davinci: Deep refactoring of I2C recovery")
>
> v3.18.137: Failed to apply! Possible dependencies:
> 1703cf5d4fc0 ("ARM: davinci: da830-evm: use gpio lookup entries for usb
> gpios")
> 1b6fe9798af8 ("ARM: davinci: board-da850-evm: fix WP pin polarity for
> MMC/SD")
> 2c6ef04ffaf7 ("i2c: davinci: switch to use platform_get_irq")
> 2e65676f710e ("i2c: davinci: use bus recovery infrastructure")
> 51e9f1216322 ("ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD")
> 67c6b6ff221f ("ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD")
> 7ef97e9a312c ("i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus
> recovery")
> a7ca2bcf2d2e ("ARM: davinci: Use standard logging styles")
> b5e1438cf98a ("ARM: davinci: da830-evm: use gpio descriptor for mmc pins")
> bdf0e8364fd3 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins")
> c08df69149db ("ARM: davinci: omapl138-hawk: use gpio lookup entries for
> usb gpios")
> cd2428c368a6 ("i2c: davinci: switch to using gpiod for bus recovery
> gpios")
> e53537653791 ("i2c/ARM: davinci: Deep refactoring of I2C recovery")
>
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
Different GPIO lookup tables were added at different points and
backporting this patch will be a mess. I guess - since nobody
complained so far about any breakage - we can simply drop the stable
tag and treat it as an improvement of existing code.
Bart
[PATCH] arm64: dts: imx8qxp: Add lpuart1/lpuart2/lpuart3 nodes
lpuart nodes are part of the ADMA subsystem. See Audio DMA
memory map in iMX8 QXP RM [1]
This patch is based on the dtsi file initially submitted by
Teo Hall in i.MX NXP internal tree.
[1] https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Signed-off-by: Teo Hall
Signed-off-by: Daniel Baluta
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 33 ++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0cb939861a60..1adfe15c2ea5 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -193,6 +193,39 @@
status = "disabled";
};
+ adma_lpuart1: serial@5a07 {
+ compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ reg = <0x5a07 0x1000>;
+ interrupts = ;
+ interrupt-parent = <>;
+ clocks = <_lpcg IMX_ADMA_LPCG_UART1_BAUD_CLK>;
+ clock-names = "ipg";
+ power-domains = < IMX_SC_R_UART_1>;
+ status = "disabled";
+ };
+
+ adma_lpuart2: serial@5a08 {
+ compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ reg = <0x5a08 0x1000>;
+ interrupts = ;
+ interrupt-parent = <>;
+ clocks = <_lpcg IMX_ADMA_LPCG_UART2_BAUD_CLK>;
+ clock-names = "ipg";
+ power-domains = < IMX_SC_R_UART_2>;
+ status = "disabled";
+ }
+
+ adma_lpuart3: serial@5a09 {
+ compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ reg = <0x5a09 0x1000>;
+ interrupts = ;
+ interrupt-parent = <>;
+ clocks = <_lpcg IMX_ADMA_LPCG_UART3_BAUD_CLK>;
+ clock-names = "ipg";
+ power-domains = < IMX_SC_R_UART_3>;
+ status = "disabled";
+ }
+
adma_i2c0: i2c@5a80 {
compatible = "fsl,imx8qxp-lpi2c", "fsl,imx7ulp-lpi2c";
reg = <0x5a80 0x4000>;
--
2.17.1
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 9:34 AM Daniel Colascione wrote: > > Just to be clear, I'm not proposing granting secret access to procfs, > and as far as I can see, nobody else is either. We've been talking > about making it easier to avoid races when you happen to want a pidfd > and a procfs fd that point to the same process So I thought that was the whole point of just opening /proc/. Exactly because that way you can then use openat() from there on. Linus
Re: [PATCH v2 1/3] arm64: dts: imx8mq: Fix the fsl,imx8mq-sdma compatible string
On Fri, Mar 29, 2019 at 5:22 PM Angus Ainslie (Purism) wrote:
>
> Fix a typo in the compatible string
>
> Signed-off-by: Angus Ainslie (Purism)
Reviewed-by: Daniel Baluta
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 81d5ce1b1ec1..06158625f24f 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -720,7 +720,7 @@
> };
>
> sdma1: sdma@30bd {
> - compatible = "fsl,
> imx8mq-sdma","fsl,imx7d-sdma";
> + compatible =
> "fsl,imx8mq-sdma","fsl,imx7d-sdma";
> reg = <0x30bd 0x1>;
> interrupts = ;
> clocks = < IMX8MQ_CLK_SDMA1_ROOT>,
> --
> 2.17.1
>
Re: [PATCH v7 2/3] iio:temperature:max31856:Add device tree bind info
On Tue, 26 Mar 2019 12:18:41 +0100
Patrick Havelange wrote:
> From: Paresh Chaudhary
>
> This patch added device tree binding info for MAX31856 driver.
>
> Signed-off-by: Paresh Chaudhary
> Signed-off-by: Matt Weber
> Signed-off-by: Patrick Havelange
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes
> v1 -> v2
> [Matt
> - Removed comment block and added possibilities of
>thermocouple type in device tree binding doc.
>
> v2 -> v3
> - Rebased
>
> v3 -> v4
> - Removed one-shot property related information.
> - Used standard name 'temp-sensor'
>
> v4 -> v5
> [Patrick
> - Rename thermocouple type to maxim,thermocouple-type for DT entry
>
> v5 -> v6
> [Patrick
> - use generic thermocouple-type for DT entry
>
> v6 -> v7
> [Patrick
> - None
> ---
> .../bindings/iio/temperature/max31856.txt | 24 +++
> 1 file changed, 24 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/temperature/max31856.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/temperature/max31856.txt
> b/Documentation/devicetree/bindings/iio/temperature/max31856.txt
> new file mode 100644
> index ..06ab43bb4de8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/temperature/max31856.txt
> @@ -0,0 +1,24 @@
> +Maxim MAX31856 thermocouple support
> +
> +https://datasheets.maximintegrated.com/en/ds/MAX31856.pdf
> +
> +Optional property:
> + - thermocouple-type: Type of thermocouple (THERMOCOUPLE_TYPE_K if
> + omitted). Supported types are B, E, J, K, N, R, S, T.
> +
> +Required properties:
> + - compatible: must be "maxim,max31856"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: As per datasheet max. supported freq is 500
> + - spi-cpha: must be defined for max31856 to enable SPI mode 1
> +
> + Refer to spi/spi-bus.txt for generic SPI slave bindings.
> +
> + Example:
> + temp-sensor@0 {
> + compatible = "maxim,max31856";
> + reg = <0>;
> + spi-max-frequency = <500>;
> + spi-cpha;
> + thermocouple-type = ;
> + };
[PATCH 4/5] ubifs: find.c: replace swap function with built-in one
Replace swap_dirty_idx function with built-in one,
because swap_dirty_idx does only a simple byte to byte swap.
Signed-off-by: Andrey Abramov
---
fs/ubifs/find.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/fs/ubifs/find.c b/fs/ubifs/find.c
index f9646835b026..5deaae7fcead 100644
--- a/fs/ubifs/find.c
+++ b/fs/ubifs/find.c
@@ -747,12 +747,6 @@ static int cmp_dirty_idx(const struct ubifs_lprops **a,
return lpa->dirty + lpa->free - lpb->dirty - lpb->free;
}
-static void swap_dirty_idx(struct ubifs_lprops **a, struct ubifs_lprops **b,
- int size)
-{
- swap(*a, *b);
-}
-
/**
* ubifs_save_dirty_idx_lnums - save an array of the most dirty index LEB nos.
* @c: the UBIFS file-system description object
@@ -772,8 +766,7 @@ int ubifs_save_dirty_idx_lnums(struct ubifs_info *c)
sizeof(void *) * c->dirty_idx.cnt);
/* Sort it so that the dirtiest is now at the end */
sort(c->dirty_idx.arr, c->dirty_idx.cnt, sizeof(void *),
-(int (*)(const void *, const void *))cmp_dirty_idx,
-(void (*)(void *, void *, int))swap_dirty_idx);
+(int (*)(const void *, const void *))cmp_dirty_idx, NULL);
dbg_find("found %d dirty index LEBs", c->dirty_idx.cnt);
if (c->dirty_idx.cnt)
dbg_find("dirtiest index LEB is %d with dirty %d and free %d",
--
2.21.0
Re: [PATCH v7 1/3] dt-bindings: iio/temperature: Add thermocouple types (and doc)
On Tue, 26 Mar 2019 12:18:40 +0100 Patrick Havelange wrote: > This patch introduces common thermocouple types used by various > temperature sensors. Also a brief documentation explaining this > "thermocouple-type" property. > > Signed-off-by: Patrick Havelange You have addressed all of Rob's feedback I think, so I'll not pester Rob for any follow up (always welcome of course if he wants to give it!) Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > Changes v7 > - Merge header and doc in same patch > - Doc:add it's a single cell entry > - Doc:removed non complete example > > Changes v6 > - Add this file > --- > .../iio/temperature/temperature-bindings.txt | 7 +++ > .../dt-bindings/iio/temperature/thermocouple.h | 16 > 2 files changed, 23 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt > create mode 100644 include/dt-bindings/iio/temperature/thermocouple.h > > diff --git > a/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt > b/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt > new file mode 100644 > index ..8f339cab74ae > --- /dev/null > +++ > b/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt > @@ -0,0 +1,7 @@ > +If the temperature sensor device can be configured to use some specific > +thermocouple type, you can use the defined types provided in the file > +"include/dt-bindings/iio/temperature/thermocouple.h". > + > +Property: > +thermocouple-type: A single cell representing the type of the thermocouple > + used by the device. > diff --git a/include/dt-bindings/iio/temperature/thermocouple.h > b/include/dt-bindings/iio/temperature/thermocouple.h > new file mode 100644 > index ..ce037f5238ac > --- /dev/null > +++ b/include/dt-bindings/iio/temperature/thermocouple.h > @@ -0,0 +1,16 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef _DT_BINDINGS_TEMPERATURE_THERMOCOUPLE_H > +#define _DT_BINDINGS_TEMPERATURE_THERMOCOUPLE_H > + > + > +#define THERMOCOUPLE_TYPE_B 0x00 > +#define THERMOCOUPLE_TYPE_E 0x01 > +#define THERMOCOUPLE_TYPE_J 0x02 > +#define THERMOCOUPLE_TYPE_K 0x03 > +#define THERMOCOUPLE_TYPE_N 0x04 > +#define THERMOCOUPLE_TYPE_R 0x05 > +#define THERMOCOUPLE_TYPE_S 0x06 > +#define THERMOCOUPLE_TYPE_T 0x07 > + > +#endif /* _DT_BINDINGS_TEMPERATURE_THERMOCOUPLE_H */
Re: [PATCH] PCI: rockchip: fix bitwise operations on status and ROCKCHIP_PCIE_EP_CMD_STATUS_IS
On 3/30/2019 8:39 PM, Colin King wrote:
From: Colin Ian King
Currently the bitwise operations on the u16 variable 'status' with
the setting ROCKCHIP_PCIE_EP_CMD_STATUS_IS are incorrect because
ROCKCHIP_PCIE_EP_CMD_STATUS_IS is 1UL<<19 which is wider than the
u16 variable. Fix this by making status a u32. (Not tested).
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe
controller")
Signed-off-by: Colin Ian King
---
drivers/pci/controller/pcie-rockchip-ep.c | 2 +-
Looks valid to me.
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c
b/drivers/pci/controller/pcie-rockchip-ep.c
index a5d799e2dff2..d743b0a48988 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -350,7 +350,7 @@ static void rockchip_pcie_ep_assert_intx(struct
rockchip_pcie_ep *ep, u8 fn,
struct rockchip_pcie *rockchip = >rockchip;
u32 r = ep->max_regions - 1;
u32 offset;
- u16 status;
+ u32 status;
u8 msg_code;
if (unlikely(ep->irq_pci_addr != ROCKCHIP_PCIE_EP_PCI_LEGACY_IRQ_ADDR ||
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 09:34:02AM -0700, Daniel Colascione wrote: > On Sat, Mar 30, 2019 at 9:24 AM Linus Torvalds > wrote: > > > > On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner > > wrote: > > > > > > From pure API perspective that's all I care about: independence of procfs. > > > Once we have pidfd_open() we can cleanly signal threads etc. > > > > But "independence from procfs" means that you damn well don't then do > > "oh, now I have a pidfd, I want to turn it into a /proc fd and then > > munge around there". > > > > So I'm literally saying that it had better really *be* independent > > from /proc. It is the standalone version, but it's most definitely > > also the version that doesn't then give you secret access to /proc. > > Just to be clear, I'm not proposing granting secret access to procfs, > and as far as I can see, nobody else is either. We've been talking > about making it easier to avoid races when you happen to want a pidfd > and a procfs fd that point to the same process, not granting access > that you didn't have before. If you'd rather not connect procfs and > pidfds, we can take this functionality off the table. This is dead! Nothing like this will make it through this tree. I have no intention of endangering pidfd_send_signal(). Christian
Re: [PATCH] iio: adc: stm32: fix sleep inside atomic section when using DMA
On Tue, 26 Mar 2019 13:44:04 +0100
Fabrice Gasnier wrote:
> Enabling CONFIG_DEBUG_ATOMIC_SLEEP=y triggers this BUG message:
> BUG: sleeping function called from invalid context at kernel/irq/chip.c...
>
> Call stack is as follows:
> - __might_sleep
> - handle_nested_irq <-- Expects threaded irq
> - iio_trigger_poll_chained
> - stm32_adc_dma_buffer_done
> - vchan_complete
> - tasklet_action_common
> - tasklet_action
> - __do_softirq <-- DMA completion raises a tasklet
> - irq_exit
> - __handle_domain_irq<-- DMA IRQ
> - gic_handle_irq
>
> IIO expects threaded interrupt context when calling:
> - iio_trigger_poll_chained()
> Or it expects interrupt context when calling:
> - iio_trigger_poll()
>
> This patch triggers an IRQ upon stm32_adc_dma_buffer_done() DMA callback
> call, so the IIO trigger poll API gets called from IRQ context.
>
> Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
>
> Signed-off-by: Fabrice Gasnier
An irq_work is a very heavy weight solution.
Perhaps we need a iio_trigger_poll* that can be called from a tasklet?
Or indeed a generic irq function that can be.
Hmm. This isn't actually a 'real' trigger (I think) anyway as it's
only ever calling it's own irq thread. In this case we could just
bypass and call that function directly.
Sometimes the trigger infrastructure of IIO is just not suited to
how a particular device works!
We need to maintain the trigger infrastructure for it's ability to
select the trigger, but not necessarily push the data through it.
So I think it would be safe to just call the block for dma_chan
being set in _adc_trigger_handler directly.
If you take this approach, make sure there are comments saying why.
I don't want people to cut and paste it into new driver unless they
understand the reasoning!
We have had drivers do this in the past, though I can't find one
right now (am335x used to do this for example, but got reworked
to suport the touchscreen at the same time and this path went
away).
Jonathan
> ---
> drivers/iio/adc/Kconfig | 1 +
> drivers/iio/adc/stm32-adc.c | 32 ++--
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 76db6e5..059407a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -775,6 +775,7 @@ config STM32_ADC_CORE
> select MFD_STM32_TIMERS
> select IIO_STM32_TIMER_TRIGGER
> select IIO_TRIGGERED_BUFFER
> + select IRQ_WORK
> help
> Select this option to enable the core driver for STMicroelectronics
> STM32 analog-to-digital converter (ADC).
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 205e169..1aa3189 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -297,6 +298,7 @@ struct stm32_adc_cfg {
> * @smpr_val:sampling time settings (e.g. smpr1 / smpr2)
> * @cal: optional calibration data on some devices
> * @chan_name: channel name array
> + * @work:irq work used to call trigger poll routine
> */
> struct stm32_adc {
> struct stm32_adc_common *common;
> @@ -320,6 +322,7 @@ struct stm32_adc {
> u32 smpr_val[2];
> struct stm32_adc_calib cal;
> charchan_name[STM32_ADC_CH_MAX][STM32_ADC_CH_SZ];
> + struct irq_work work;
> };
>
> struct stm32_adc_diff_channel {
> @@ -1473,11 +1476,32 @@ static unsigned int stm32_adc_dma_residue(struct
> stm32_adc *adc)
> return 0;
> }
>
> +static void stm32_adc_dma_irq_work(struct irq_work *work)
> +{
> + struct stm32_adc *adc = container_of(work, struct stm32_adc, work);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> +
> + /*
> + * iio_trigger_poll calls generic_handle_irq(). So, it requires hard
> + * irq context, and cannot be called directly from dma callback,
> + * dma cb has to schedule this work instead.
> + */
> + iio_trigger_poll(indio_dev->trig);
> +}
> +
> static void stm32_adc_dma_buffer_done(void *data)
> {
> struct iio_dev *indio_dev = data;
> + struct stm32_adc *adc = iio_priv(indio_dev);
>
> - iio_trigger_poll_chained(indio_dev->trig);
> + /*
> + * Invoques iio_trigger_poll() from hard irq context: We can't
> + * call iio_trigger_poll() nor iio_trigger_poll_chained()
> + * directly from DMA callback (under tasklet e.g. softirq).
> + * They require respectively HW IRQ and threaded IRQ context
> + * as it might sleep.
> + */
> + irq_work_queue(>work);
> }
>
> static int stm32_adc_dma_start(struct iio_dev *indio_dev)
> @@ -1585,8 +1609,10 @@ static void __stm32_adc_buffer_predisable(struct
> iio_dev *indio_dev)
> if (!adc->dma_chan)
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 09:24:23AM -0700, Linus Torvalds wrote: > On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner > wrote: > > > > From pure API perspective that's all I care about: independence of procfs. > > Once we have pidfd_open() we can cleanly signal threads etc. > > But "independence from procfs" means that you damn well don't then do > "oh, now I have a pidfd, I want to turn it into a /proc fd and then > munge around there". > > So I'm literally saying that it had better really *be* independent > from /proc. It is the standalone version, but it's most definitely > also the version that doesn't then give you secret access to /proc. > > And it weorries me a lot that people are trying to play these kinds of > games. I'm just seeing some android patch that adds this horror and > then starts using it. The original need for this conversion thing came from Android indeed. I won't go forward with any such patches. Christian
[PATCH 0/5] simple sort swap function usage improvements
This is the logical continuation of sort improvements by George Spelvin "lib/sort & lib/list_sort: faster and smaller" series (added to the linux-next really recently). Patches from 1 to 4 replace simple swap functions with the built-in (which is now much faster) and grouped by subsystem (after that only 3 files implement custom swap - arch/x86/kernel/unwind_orc.c, kernel/jump_label.c and lib/extable.c). Patch #5 replaces the int type with the size_t type of the size argument in the swap function. Andrey Abramov (5): arch/arc: unwind.c: replace swap function with built-in one powerpc: module_[32|64].c: replace swap function with built-in one ocfs2: dir,refcounttree,xattr: replace swap functions with built-in one ubifs: find.c: replace swap function with built-in one Lib: sort.h: replace int size with size_t size in the swap function arch/arc/kernel/unwind.c| 20 ++-- arch/powerpc/kernel/module_32.c | 17 + arch/powerpc/kernel/module_64.c | 17 + arch/x86/kernel/unwind_orc.c| 2 +- fs/ocfs2/dir.c | 13 + fs/ocfs2/refcounttree.c | 13 +++-- fs/ocfs2/xattr.c| 15 +++ fs/ubifs/find.c | 9 + include/linux/sort.h| 2 +- kernel/jump_label.c | 2 +- lib/extable.c | 2 +- lib/sort.c | 6 +++--- 12 files changed, 19 insertions(+), 99 deletions(-) -- 2.21.0
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 9:24 AM Linus Torvalds wrote: > > On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner > wrote: > > > > From pure API perspective that's all I care about: independence of procfs. > > Once we have pidfd_open() we can cleanly signal threads etc. > > But "independence from procfs" means that you damn well don't then do > "oh, now I have a pidfd, I want to turn it into a /proc fd and then > munge around there". > > So I'm literally saying that it had better really *be* independent > from /proc. It is the standalone version, but it's most definitely > also the version that doesn't then give you secret access to /proc. Just to be clear, I'm not proposing granting secret access to procfs, and as far as I can see, nobody else is either. We've been talking about making it easier to avoid races when you happen to want a pidfd and a procfs fd that point to the same process, not granting access that you didn't have before. If you'd rather not connect procfs and pidfds, we can take this functionality off the table.
Re: [PATCH v3] HID: intel-ish-hid: ISH firmware loader client driver
On Sat, 2019-03-30 at 15:52 +0530, Rushikesh S Kadam wrote:
> On Fri, Mar 29, 2019 at 04:30:18PM -0700, Nick Crews wrote:
> > On Fri, Mar 29, 2019 at 1:03 PM Rushikesh S Kadam
> > wrote:
> > > + ldr_xfer_ipc_frag = kzalloc(LOADER_SHIM_IPC_BUF_SIZE, GFP_KERNEL);
> > > + if (!ldr_xfer_ipc_frag) {
> > Log error here.
> The error code is logged in calling function
> load_fw_from_host(). Is that good enough?
>
> I believe the checkpatch script too, would
> recommend against adding debug print for ENOMEM
> error.
The generic kernel allocation functions already do
a dump_stack() on OOM conditions when called without
__GFP_NOWARN so any additional OOM message isn't
particularly useful.
> Again, I thought it was against practise to log
> "out of memory" debug prints in probe()
Or anywhere else given the generic OOM stack dump.
> But will add if you tell me this is the right way.
>
> > > + return -ENOMEM;
> > > +
> > > + loader_ishtp_cl = ishtp_cl_allocate(cl_device);
> > > + if (!loader_ishtp_cl)
> >
> > log error here
The ishtp_cl_allocate function just calls kmalloc then
initializes the struct so an additional OOM message
isn't useful here either.
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner wrote: > > From pure API perspective that's all I care about: independence of procfs. > Once we have pidfd_open() we can cleanly signal threads etc. But "independence from procfs" means that you damn well don't then do "oh, now I have a pidfd, I want to turn it into a /proc fd and then munge around there". So I'm literally saying that it had better really *be* independent from /proc. It is the standalone version, but it's most definitely also the version that doesn't then give you secret access to /proc. And it weorries me a lot that people are trying to play these kinds of games. I'm just seeing some android patch that adds this horror and then starts using it. Linus
Re: [PATCH v2 0/5] pid: add pidfd_open()
On March 30, 2019 5:09:10 PM GMT+01:00, Linus Torvalds wrote: >On Fri, Mar 29, 2019 at 8:54 AM Christian Brauner > wrote: >> >> /* Introduction */ >> This adds the pidfd_open() syscall. >> pidfd_open() allows to retrieve file descriptors for a given pid. >This >> includes both file descriptors for processes and file descriptors for >> threads. > >I'm ok with the pidfd_open() call to just get a pidfd, but that From pure API perspective that's all I care about: independence of procfs. Once we have pidfd_open() we can cleanly signal threads etc. >"pidfd_to_profs()" needs to go away. > >If you want to open the /proc//status file, then just do that. >This whole "do one and convert to the other" needs to die. No, no, no. > > Linus
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 9:16 AM Linus Torvalds wrote: > > And no, we are *NOT* making pidfd_open() into some "let's expose /proc > even when it's not mounted" horror. Seriously. That's disgusting, > wrong, insecure and stupid. And btw, this is not debatable. In fact, this whole discussion is making me feel like I should just revert pidfd, not because the code I merged is wrong, but because people are clearly intending to do completely inappropriate things with this. Get your act together. Stop hacking up garbage. Linus
Re: [PATCH] fs/binfmt_elf.c: fix GPF when dereferencing invalid interpreter
On 3/30/2019 7:30 PM, Nikitas Angelinas wrote:
Syzkaller found an issue where an invalid interpreter pointer is
dereferenced in load_elf_binary()->allow_write_access()
please mention here on failure path inside allow_write_access
as there are two path it gets called.
. Fix this by
jumping to a different label in the cleanup path.
This patch applies against the latest linux-next tree. I have not tested
that the patch addresses the issue, but it should, imho.
This should not be written in commit text body.
please fix.
Signed-off-by: Nikitas Angelinas
Reported-by: syzbot+0d1fcd7268b21bace...@syzkaller.appspotmail.com
Fixes: 44e63c4a0263 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")
---
Patch looks valid to me as interpreter may be NULL and it later get
tried to dereferencing inside allow_write_access
under label out_free_dentry.
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
fs/binfmt_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 51bc894..09e76b2 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -777,7 +777,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
kfree(elf_interpreter);
retval = PTR_ERR(interpreter);
if (IS_ERR(interpreter))
- goto out_free_dentry;
+ goto out_free_ph;
/*
* If the binary is not readable then enforce
Re: [PATCH v2 0/5] pid: add pidfd_open()
On Sat, Mar 30, 2019 at 9:11 AM Daniel Colascione wrote: > > How do you propose that someone open the /proc//status file in a > race-free manner starting with the result of calling pidfd_open? CXhrist. If you want to open a /proc file, then open a /proc file. Don't use pidfd_open(). Just open /proc// Then you can use openat() to open whatever sub-files you want. You have two choices: either you use /proc, or you don't. Don't mix the two. And no, we are *NOT* making pidfd_open() into some "let's expose /proc even when it's not mounted" horror. Seriously. That's disgusting, wrong, insecure and stupid. Linus
Re: [RESEND PATCH v6 12/12] x86/fsgsbase/64: Add documentation for FSGSBASE
On 3/15/19 1:06 PM, Chang S. Bae wrote:
> From: Andi Kleen
>
> v2: Minor updates to documentation requested in review.
> v3: Update for new gcc and various improvements.
>
> Signed-off-by: Andi Kleen
> Signed-off-by: Chang S. Bae
> Cc: Andy Lutomirski
> Cc: H. Peter Anvin
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> ---
> Documentation/x86/fsgs.txt | 104 +
> 1 file changed, 104 insertions(+)
> create mode 100644 Documentation/x86/fsgs.txt
>
Globally s/64bit/64-bit/ and s/32bit/32-bit/.
More comments below.
> diff --git a/Documentation/x86/fsgs.txt b/Documentation/x86/fsgs.txt
> new file mode 100644
> index ..7a973a5c1767
> --- /dev/null
> +++ b/Documentation/x86/fsgs.txt
> @@ -0,0 +1,104 @@
> +
> +Using FS and GS prefixes on 64bit x86 linux
> +
> +The x86 architecture supports segment prefixes per instruction to add an
> +offset to an address. On 64bit x86, these are mostly nops, except for FS
> +and GS.
> +
> +This offers an efficient way to reference a global pointer.
> +
> +The compiler has to generate special code to use these base registers,
> +or they can be accessed with inline assembler.
> +
> + mov %gs:offset,%reg
> + mov %fs:offset,%reg
> +
> +On 64bit code, FS is used to address the thread local segment (TLS),
> declared using
> +__thread. The compiler then automatically generates the correct prefixes and
> +relocations to access these values.
> +
> +FS is normally managed by the runtime code or the threading library
library.
> +Overwriting it can break a lot of things (including syscalls and gdb),
> +but it can make sense to save/restore it for threading purposes.
> +
> +GS is freely available, but may need special (compiler or inline assembler)
> +code to use.
> +
> +Traditionally 64bit FS and GS could be set by the arch_prctl system call
> +
> + arch_prctl(ARCH_SET_GS, value)
> + arch_prctl(ARCH_SET_FS, value)
> +
> +[There was also an older method using modify_ldt(), inherited from 32bit,
> +but this is not discussed here.]
> +
> +However using a syscall is problematic for user space threading libraries
However,
> +that want to context switch in user space. The whole point of them
> +is avoiding the overhead of a syscall. It's also cleaner for compilers
> +wanting to use the extra register to use instructions to write
> +it, or read it directly to compute addresses and offsets.
> +
> +Newer Intel CPUs (Ivy Bridge and later) added new instructions to directly
> +access these registers quickly from user context
context. {or context:}
> +
> + RDFSBASE %reg read the FS base(or _readfsbase_u64)
> + RDGSBASE %reg read the GS base(or _readgsbase_u64)
> +
> + WRFSBASE %reg write the FS base (or _writefsbase_u64)
> + WRGSBASE %reg write the GS base (or _writegsbase_u64)
> +
> +If you use the intrinsics include and set the -mfsgsbase
> option.
intrinsics,
> +
> +The instructions are supported by the CPU when the "fsgsbase" string is
> shown in
> +/proc/cpuinfo (or directly retrieved through the CPUID instruction,
> +7:0 (ebx), word 9, bit 0)
add ending '.' above.
> +
> +The instructions are only available to 64bit binaries.
> +
> +In addition the kernel needs to explicitly enable these instructions, as it
> +may otherwise not correctly context switch the state. Newer Linux
> +kernels enable this. When the kernel did not enable the instruction
does not
> +they will fault with an #UD exception.
well, I would say "with a #UD exception."
> +
> +An FSGSBASE enabled kernel can be detected by checking the AT_HWCAP2
FSGSBASE-enabled
> +bitmask in the aux vector. When the HWCAP2_FSGSBASE bit is set the
> +kernel supports FSGSBASE.
> +
> + #include
> + #include
> +
> + /* Will be eventually in asm/hwcap.h */
> + #define HWCAP2_FSGSBASE(1 << 1)
> +
> +unsigned val = getauxval(AT_HWCAP2);
> +if (val & HWCAP2_FSGSBASE) {
> +asm("wrgsbase %0" :: "r" (ptr));
> +}
> +
> +No extra CPUID check needed as the kernel will not set this bit if the CPU
CPUID check is needed
> +does not support it.
> +
> +gcc 6 will have special support to directly access data relative
"will have"? future? or:
gcc 6 has special support
> +to fs/gs using the __seg_fs and __seg_gs address space pointer
> +modifiers.
> +
> +#ifndef __SEG_GS
> +#error "Need gcc 6 or later"
> +#endif
> +
> +struct gsdata {
> + int a;
> + int b;
> +} gsdata = { 1, 2 };
> +
> +int __seg_gs *valp = 0; /* offset relative to GS */
> +
> + /* Check if kernel supports FSGSBASE as above */
> +
> + /* Set up new GS */
> + asm("wrgsbase %0" :: "r" ());
> +
> + /* Now the global pointer can be used normally */
> +
missing patch
Hi back in the December of 2016 there was commit "1c52d859cb2d417e7216d3e56bb7fea88444cec9" witch was followed shortly by "c198b121b1a1d7a7171770c634cd49191bac4477" Unfortunately only the first commit was later included in long-term kernel branches such as 4.4 and 4.9 witch left some of microcode functionality broken on 32 bit systems I guess it should be easily fixed by including "c198b121b1a1d7a7171770c634cd49191bac4477" in those branches
Re: [PATCH v2] devantech-srf04.yaml: transform DT binding to YAML
On Wed, 27 Mar 2019 08:13:17 -0500 Rob Herring wrote: > On Tue, Mar 26, 2019 at 8:40 AM Andreas Klinger wrote: > > > > devantech-srf04.yaml: yaml devicetree binding for iio ultrasonic > > proximity driver of devantech srf04 > > > > use devantech-srf04.txt, transform binding into yaml and remove the > > outdated DT documentation > > > > Signed-off-by: Andreas Klinger > > --- > > .../bindings/iio/proximity/devantech-srf04.txt | 28 -- > > .../bindings/iio/proximity/devantech-srf04.yaml| 59 > > ++ > > 2 files changed, 59 insertions(+), 28 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt > > create mode 100644 > > Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml > > Reviewed-by: Rob Herring Given I've been feeling guilty for ages about never reviewing Rob's original work on this (it sat in my todo list for a large number of months before I dropped it because it had already merged), I'm very happy to see that it ends up being this simple! I guess we have a lot of these change over patches to go ;) Applied to the togreg branch of iio.git and pushed out as testing. Does anyone check these yet? Thanks, Jonathan
